Current Meeting Report

2.7.6 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 22-Feb-02
Fred Baker <>
Transport Area Director(s):
Scott Bradner <>
Allison Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
To Subscribe:
In Body: subscribe ieprep
Description of Working Group:
Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.

Three examples of emergency communications include:

1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN.

2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health.

3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging.

Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document.

The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups.

The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations.


Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done.

Informationals: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony.

Goals and Milestones:
Mar 02   Submit initial I-D of Requirements
Mar 02   Submit initial I-D of Framework
Mar 02   Submit initial I-D of Recommendations BCP
Aug 02   Submit Requirements I-D to IESG for publication as an Informational RFC.
Aug 02   Submit Framework I-D to IESG for publication as an Informational RFC.
Aug 02   Submit Recommendations I-D to IESG for publication as a BCP.
No Request For Comments

Current Meeting Report

Internet Emergency Preparedness WG (ieprep)

Minutes for Monday, March 18 at 1530-1730

CHAIR: Fred Baker <>

Fred presented an overview and indicated that the BCP RFC should be completed by next IETF in Yokohama. Therefore, lots of work to be done on the mail list. Need to get documents in place so service providers can begin working with their governments on what is possible and how to contact for such emergency services.

Currently 4 internet drafts have been submitted.

Comment: How can we get BCP without current practices? BCP is best way we know how to do something rather than the best way we ARE doing something.

Kimberly King presented overview on GETS.
· GETS call is binary preferential treatment during call setup. No preemption of existing calls.
· 1 out of 1000 calls was GETS call during 911 in NY, NY.
· Converged Architecture with packet network presents new problems but similar to GETS.

· Is GETS supported throughout the US? It is supported to some extent throughout US, but only has contracts with three of the service providers.
· Issue raised on tracking emergency calls in Internet and attack those calls.
· Question of authorization? GETS is SS7 centric not the same congestion issues for circuit switch vs. packet switching.
· Question on how many GETS calls did not get through during 911. Statistics will be published to the list.
· Is GETS all that emergency services want or what other services are being considered?
· GETS has approximately 60,000 users in the US.
· GETS does not help the case where you cannot get a dial tone.

Ken Carlberg presented Framework for IEPREP Telephony

GETS is target model, but mimics neither GETS nor the PSTN architecture.
Framework looks at near and mid-term

Core Objectives
· High probability of call completion
· Distinguish IEPS traffic
· Interaction with PSTN
· Non-preemptive action
· Non-ubiquitous service
· Authenticated service

Value Added Objectives
· Alternate path routing
o Solutions using BGP are dead on arrival
o One possible approach is application layer routing (e.g., TRIP)
· End-to-End Fault Tolerance (FEC, redundant transmissions, etc…

Functional Requirements
· Signals and Signaling: Conveying information
§ Resource Header Draft
· <draft-polk-sipping-resource-01.txt>
· NameSpace.Priority; values registered with IANA
· DSN namespace for (5) priority values of MLPP
§ Proposed IEPS NameSpace to IANA
· (1) value of "authorized-emergency"
· Previous IEPS draft proposed (3) values
o "authorized-emergency"
o "general-emergency" e.g., 911
o "normal"
§ Comment: no relationship between 911 service and GETS
§ Comment: need to get ieprep information to SIP
§ GSN standards include 5 levels of priority
o Diff-serv
§ Should be able to use existing code points
§ E.g., AF for SIP signaling, EF for voice
§ Data merge points in the cloud? Issue that needs to be revisited.
§ Should there be a new class for AF
· More drop precedence values for emergency-type traffic?
· Comment: What problems are trying to be solved by this? Also, research has shown than humans cannot distinguish between more than 3 or 4 levels of priority.
· Comment: Question of QoS, generally emergency services does not require different QoS versus ability to complete call / message transfer?
· Comment: How do we authenticate the request? Needs to be addressed.
§ Comment: Are we talking about diff-serv for signaling or diff-serv for data stream? Answer, Probably both, but needs some deep thought.
§ Propose a "Classifier" extension
§ To be removed from the framework draft
§ Downside
· Potential reliance of S-RTP for authentication
· Policy
o Defining actions on what has been conveyed
o E.g., preemption, resource allocation (and constraints)
· Traffic Engineering
· Security

· Backbone
o NGN PSTN: e.g., IP at the core, SS7 at the edges
o Stub domain: e.g. VoIP
Things to do
· Incorporate comments for IEPREP mail list
Appendix Stuff
· Describe Government Telephone Preference Scheme (GTPS) of the UK
· Mention current snapshot of SG-11 & SG-16 work on priority/label field and relation to SIP R-P field
· Comment: Next IETF and ITU Study Group 11 meetings may be in conflict.
· Comment: ITU Study Group 16 is just beginning to look at emergency telecommunications and the study group 16 will be focal point for all emergency telecommunications within the ITU.
Comment: ITU temporary documents are accessible to general public.

James Polk provided overview of SIP resource Priority (Ongoing MLPP discussions in SIP)
· Resource-Priority Header
o Goal:
§ Establish preferential (or differential…) treatment
Comment: Optional field. Lack of the option implies certain actions.
Comment: STP is generally not accepted by proxies. Thus, it is rather hard to do authentication with STP.

Open Discussion:

Comment: We need to distinguish voice, data and other services when we discuss the drafts.
Fred: Need to distinguish policy from labels
Comment: How should be handle policy? We need to separate policy from labeling.
Comment: Service definition is done by the service provider.
Fred: Policy is something we DO NOT want to specify in the standard.
Comment: It appears we are assuming that the network is in working order. It appears there should be considerations of fallback positions. Should we consider backup systems, local hardening of the network, or other? Answers: That should be the service providers job. We shouldn't have to operate differently in an emergency.
Comment: Public switch network is so large and calls turn over so fast that there is not need for multiple levels of priorities. However, we need multiple priorities in the landline network with limited resources so we need more levels of priority to ensure high probability of success.
Comment: Issue of GETS to multiple levels in IP.
Comment: How does mobile phone fit in? If there are no resource available in access network, then what?

Fred will arrange an interim meeting in May/June in San Jose or Washington DC to discuss documents that are being worked.


Framework for Supporting IEPS in IP Telephony
Government Emergency Telecommunications Service (GETS)