ECRIT S. Norreys
Internet-Draft BT Group
Intended status: Informational H. Tschofenig
Expires: September 9, 2009 Nokia Siemens Networks
H. Schulzrinne
Columbia University
March 8, 2009
Authority-to-Individuals Communication for Emergency Situations:
Requirements, Terminology and Architecture
draft-norreys-ecrit-authority2individuals-requirements-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Norreys, et al. Expires September 9, 2009 [Page 1]
Internet-Draft Early Warning Communication March 2009
Abstract
Public safety agencies need to provide information to the general
public before and during large-scale emergencies. While many aspects
of such systems are specific to national or local jurisdictions,
emergencies span such boundaries and notifications need to reach
visitors from other jurisdictions. This document summarizes
requirements for protocols to alert individuals within a defined
geographic area.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Closed Warning Notification Provider and Aggregator
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Open Communication between Warning Notification
Provider and Aggregator . . . . . . . . . . . . . . . . . 6
3.3. Open Communication towards Warning Notification
Customers . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Notification Population . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Norreys, et al. Expires September 9, 2009 [Page 2]
Internet-Draft Early Warning Communication March 2009
1. Introduction
During large-scale emergencies, public safety authorities need to
reliably communicate with citizens in the affected areas, to provide
warnings, indicate whether citizens should evacuate and how, and to
dispel misinformation. Accurate information can reduce the impact of
such emergencies.
Traditionally, emergency alerting has used church bells, sirens,
loudspeakers, radio and television to warn citizens and to provide
information. However, techniques such as sirens and bells provide
limited information content; loud speakers cover only very small
areas and are often hard to understand, even for those not hearing
impaired or fluent in the local language. Radio and television offer
larger information volume, but are hard to target geographically and
do not work well to address the "walking wounded" or other
pedestrians. Both are not suitable for warnings, as many of those
needing the information will not be listening or watching at any
given time, particularly during work/school and sleep hours.
This problem has recently been illustrated by the London underground
bombing on July 7, 2006, as described in a government report [ref].
The UK authorities could only use broadcast media and could not, for
example, easily announce to the "walking wounded" where to assemble.
This document summarizes key requirements for IP-based protocols to
enhance and complement existing authority-to-citizen warning systems.
These protocols may either directly reach the citizen or may be used
to trigger more traditional alerts, such as, among many others,
displays in subway stations, electronic bill boards, or SMS.
Public safety authorities need to reach, with an appropriate message,
as many affected people as possible within the area impacted by the
emergency, including not just residents, but also workers and
travelers who may only be in the area temporarily.
In addition, people around the immediately affected area should be
able to receive information and differentiated instructions, such as
warnings to avoid travel or to clear roads.
Emergency alerts may be issued once for an emergency or authorities
may repeat or update information during an event.
Some messages are addressed to all individuals within a certain
geographic area. Other messages may target only specific individuals
or groups of individuals, such as medical personnel or those
particularly susceptible to an incident.
Norreys, et al. Expires September 9, 2009 [Page 3]
Internet-Draft Early Warning Communication March 2009
Machine-parseable alerts may also be used to trigger automated
behaviors, such as closing vents during a chemical spill or
activating sirens or other warning systems in commercial buildings.
At least initially, mobile and stationary devices may not have the
appropriate capabilities to receive such warnings. Thus, protocols
need to be designed to allow gatewaying to traditional systems, e.g.,
the PSTN.
We assume an event notification model, i.e., individuals subscribe to
warnings that affect their current location. As a mobile device
moves, the subscription may need to be updated. Thus, location
information needs to be available during the subscription process.
Users may want to subscribe to warnings that do not affect their
current location. For example, parents may want to be alerted of
emergencies affecting the school attended by their children and adult
children may need to know about emergencies affecting elderly
parents.
Some technologies may also support network-level broadcast or
multicast.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms
apply to the design of a protocol conveying emergency alerts and
early warning messages, not its implementation or application.
This document reuses the terminology introduced by [3GPP-TR-22.968]
and modifies it to fit to IETF terminology:
Notification Population:
The term notification population refers to the set of warning
notification consumers that receive a warning notification.
Public Warning System:
A public warning system delivers warning notifications provided by
warning notification providers to IP-capable end hosts within
notification areas.
Norreys, et al. Expires September 9, 2009 [Page 4]
Internet-Draft Early Warning Communication March 2009
Warning Notification:
Warning notifications inform recipients of the occurrence of
current or pending public safety-related events and additionally
may provide users with instructions on what to do and where to get
help for the duration of the emergency.
Warning Notification Provider:
A warning notification provider is an agency that injects warning
notifications in the communication system. Examples of such
agencies are branches of governments, public transport providers
or weather organizations. A private institution, such as a
university, hospital or enterprise, may also provide such warnings
to people located within their facilities.
Warning Notification Consumer: A warning notification consumer is
the final recipient of a warning notification from an IP
communication point of view. Examples are Web browsers and SIP
clients on mobile phones and laptops that process warning
notification messages. Once received such a warning is shown to
the user (a human) via an appropriately designed user interface to
ensure that it is properly understood.
Warning Notification Aggregator:
A warning notification aggregator receives alert notifications
from different providers, performs security functions (e.g.,
authentication, authorization) and may need to transform message
into a different format before forwarding them towards warning
notification consumers.
3. Architectures
The following sub-sections illustrate different architectural
approaches.
3.1. Closed Warning Notification Provider and Aggregator Groups
The first architectural variant allows the distribution of warning
notifications from warning notification providers to warning
notification aggregators. The communication is largely in a point-
to-point fashion and the number of involved players is rather small,
particularly on the side of the warning notification providers.
Furthermore, a new warning notification aggregator is allowed to
receive warning notifications only after certain verification
procedures are conducted and thereby the entire communication
Norreys, et al. Expires September 9, 2009 [Page 5]
Internet-Draft Early Warning Communication March 2009
infrastructure re-essembles a closed group. To ensure that the
content of the warning notifications is properly understood the
involved parties are very likely to agree on the detailed semantics
of the warning messages prior to distributing any alert.
Figure 1 shows the involved parties graphically.
+----------------------------------------+
| .--------------. |
| | Warning | Closed |
| | Notification |\ Federation |
| Aggregator A | \ |
| `--------------' \\ |
| \ |
| \\ |
| \ |
| \\ |
| \ |
| .--------------. .............. |
| | Warning | : Warning : |
| | Notification |-----: Notification : |
| Aggregator B | : Provider : |
| `--------------' `..............' |
| / |
| // |
| // |
| // |
| .--------------. // |
| | Warning | // |
| | Notification | / |
| Aggregator C | |
| `--------------' |
+----------------------------------------+
Figure 1: Closed Warning Notification Provider and Aggregator Groups
An example of this system can be seen in national early warning
systems where regulatory requirements force warning notification
provider and aggregators to work together.
3.2. Open Communication between Warning Notification Provider and
Aggregator
This model is similar to the closed group presented in the previous
section with a difference in the way how warning notification
aggregators can retrieve warning notifications from warning
Norreys, et al. Expires September 9, 2009 [Page 6]
Internet-Draft Early Warning Communication March 2009
notification providers. When the aggregator interacts with the
provider then no special client-side authentication procedure is
assumed and no access restrictions are enforced. As such, the
aggregator might be located anywhere on the Internet to retrieve the
warning notifications. Warning notification aggregators might offer
their subscribers the ability to receive warnings of a certain type
(e.g., weather alerts) for a specific region (e.g., for a specific
country or an entire continent). Hence, the aggregator might find
the relevant warning notification providers and interacts with them
to retrieve alerts. Finally, the aggregator might use different
protocol mechanisms (e.g., SMS, Web pages) towards the warning
notification customers, often depending on the client capabilities.
In general, the number of aggregators is very likely larger than in a
closed group but there are no significant challenges with respect to
scalability or congestion to expect.
Figure 2 shows the involved parties graphically.
o
\|/
| ..............
/ \ : Warning :
.--------------. : Notification :
| Warning | : Provider X :
| Notification |-- `..............'
Consumer (1)| -- --
`--------------' --- --- /
--- .--------------. --- /
-- | Warning | --- /
--| Notification |-- /
Aggregator A | \ /
...... `--------------' \\ /
\ //
X\
o / \
\|/ / \\
| / \
/ \ .--------------. / ..............
.--------------. | Warning |/ : Warning :
| Warning | ------- | Notification |-----: Notification :
| Notification |------ Aggregator B | : Provider Y :
Consumer (n)| `--------------' `..............'
`--------------'
Figure 2: Open Communication between Warning Notification Provider
and Aggregator
Norreys, et al. Expires September 9, 2009 [Page 7]
Internet-Draft Early Warning Communication March 2009
3.3. Open Communication towards Warning Notification Customers
In the following architectural variant the customers directly
interact with various warning notification providers that a relevant
for a specific type of alert type. In order to learn about the
relevant warning notification providers it may be necessary to
consult some form of discovery service; this may be done out-of-band
via manual configuration or via a protocol mechanism.
Scalability and congestion control concerns arise with this scenario
as this model assumes an opt-in approach from the customer. The
total number of warning notification customers are provider has to
serve may be considerable. There are a more security challenges
since there are no pre-established trust relationships between the
warning notification customers and the providers.
.-----------.
| Discovery |
| Service |
`-----------'
^
/
/ ..............
/ : Warning :
/ / : Notification :
/ // : Provider X :
/ // `..............'
/ //
o / //
\|/ / /
| / //
/ \ v //
.--------------. // ..............
| Warning | // : Warning :
| Notification |-------------------- : Notification :
Consumer (1)|-- : Provider Y :
`--------------' -- `..............'
---
--
---
--
---
-- : Warning :
--: Notification :
: Provider Y :
`..............'
Norreys, et al. Expires September 9, 2009 [Page 8]
Internet-Draft Early Warning Communication March 2009
Open Communication towards Warning Notification Customers
3.4. Notification Population
What warning notification customers are put into the notification
population is an important architectural aspect that is largely
orthongonal to the architecture presented in Section 3.1 and
Section 3.2.
In an opt-in model the the warning notification customer need to
provide information about what type of alerts it is interested in
and, in order for the warning notification aggregator or the warning
notification provider to be able to distribute warnings it is
necessary for them to know the context, such as the current location,
preferred language or device capabilities. This information may be
provided by the customer itself or by other entities, such as the
access provider.
Alternatively, the topological structure of networks is used to
distribute warning notifications to all hosts that are located within
a specific IP-subsetwork or hosts in a specific link layer broadcast
domain. This approach typically requires co-operation from the
network provider.
4. Requirements
The following requirements are related to the communication protocol
and the context.
Req-1:
The protocol mechanisms MUST allow targeting notifications to
specific individuals, groups of individuals or specific geographic
regions. Different regions or groups may receive different
instructions for the same disaster. (For example, people very
close to a chemical spill may be asked to evacuate, while those
further away may be asked to close windows.)
Req-2:
The protocol solution MUST provide real-time message delivery.
Req-3:
The solution MUST support the delivery of warning notifications
that allow for predictable or likely events.
Norreys, et al. Expires September 9, 2009 [Page 9]
Internet-Draft Early Warning Communication March 2009
Req-4
The protocol mechanisms MUST allow delivery of messages
simultaneously to a large audience.
Req-5
The protocol mechanisms MAY provide an option to return a receipt
on reading message. However, the confirmation SHOULD NOT be
required.
Req-6:
The protocol mechanism MUST be independent of the underlying
access network technology.
Req-7:
Protocol mechanisms MUST allow to tailor the message to the
language preferences of the receiver and/or deliver multiple
versions in different languages within the same message, so that
the recipient can choose the most appropriate one.
Req-8:
A user SHOULD be able to indicate the preferred method of
communication to the public warning service, such as notification
by email, different instant messaging protocols or automated voice
calls.
Req-9:
The protocol conveying warning notifications SHOULD identify the
warning notification provider in a secure manner.
Req-10:
The solution MUST provide a mechanism for transmitting warning
notification test messages.
Req-11:
A solution MUST support delivery of notification messages (e.g.,
with different media types) to those with special needs, such as
hearing and vision impaired.
Norreys, et al. Expires September 9, 2009 [Page 10]
Internet-Draft Early Warning Communication March 2009
5. IANA Considerations
This document does not require actions by IANA.
6. Security considerations
This document outlines requirements and security security
requirements are a part of them.
7. Acknowledgments
This document reuses requirements captured outside the IETF, namely
ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]).
We would like to thank the authors of these specifications for their
work. Note, however, that only a small subset of the requirements
have been reflected that do not relate to specific deployments, user
interface aspects, detailed regulatory requirements, management and
operational considerations, and non-IP specific technologies.
We would like to thank Leopold Murhammer for his review in July 2007.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[3GPP-TR-22.968]
, ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation
Partnership Project; Technical Specification Group
Services and System Aspects; Study for requirements for a
Public Warning System (PWS) Service (Release 8)",
December 2006.
[ETSI-TS-102-182]
, ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical
Specification, Emergency Communications (EMTEL);
Requirements for communications from authorities/
organizations to individuals, groups or the general public
during emergencies", December 2006.
Norreys, et al. Expires September 9, 2009 [Page 11]
Internet-Draft Early Warning Communication March 2009
Authors' Addresses
Steve Norreys
BT Group
1 London Road
Brentwood, Essex CM14 4QP
UK
Phone: +44 1277 32 32 20
Email: steve.norreys@bt.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Norreys, et al. Expires September 9, 2009 [Page 12]