2.6.20 International Emergency Preparedness Scheme (ieps) bof

Current Meeting Report

IEPS BOF- 8/1/00

The published agenda was:
1) Hal Folts: Discuss the draft & GETS
2) Hiroyuki Ohno: discuss similar efforts in Japan
3) Ken Carlberg: discuss a proposed Framework/architecture for IEPS
4) General discussion
5) Proposal and discussion of an action plan.

The first item on the agenda was Hal Folts's presentation on the technical and operational requirements for an Internet-based International Emergency Preparedness Scheme (IEPS). (draft-folts-ohno-ieps-considerations-00.txt) See the ID for specific details.

IEPS follows the ITU E.106 recommendation for emergency communications and much of the issues it addresses are operational, policy, and political and thus are not IETF issues but IEPS may need some protocol mechanisms in IP-based networks to convey an IEPS indicator of some type and to act on the indicator when it is present.

Currently the US uses the Government Emergency Telecommunications Service (GETS) which purchased from a number of telecommunications providers. GETS provides for expeditious call placement (not call preemption) and is accessed using a credit-card mechanism and a special area code.

Hal is requesting that the IETF explore the issues and to develop new technology if needed. Specifically he suggested the development of a RFC that would:

Hiroyuki Ohno then presented a description of the IAA (I Am Alive) system that was developed in Japan following the Kobe earthquake. The presentation included a short video of the system in operation. IAA is basically a system to facilitate people effected by a disaster finding each other. It is a victim information registration and retrieval system that can be quickly setup in a disaster zone.

There were some questions from the floor:
Q - Is IAA doing anything special at the transport level? - A. no

Q - This a deployed application - would private links work just as well as a private net? (or the Internet) - A. private links do work just fine

Q - Could right thing be just operations procedures without any protocol changes - A. maybe

Q - There needs to be a way to signal from PSTN to the Internet - that may require new technology, in addition there may need to be a BCP on operations procedures.

Ken Carlberg then offered a presentation on a proposed framework for the IEPS work in the IETF.

The objective is the support of emergency communications and use existing technology where possible.

The framework must take into account two possible voice over IP architectures. First, IP could be used within a telecommunications provider to connect parts of its infrastructure. In this case the issues are internal to the telecommunications provider. The second architecture makes direct use of IP -based telephony to the user and is voice over the Internet.

One approach to the issue would be to enable signaling of IEPS traffic by adding to the SIP priority field. Another approach could be to use MPLS.

The existing GETS may act as a good target model, among other things it does not depend on ubiquitous support to work.

IEPS enabling technology may require a new diffserv codepoint.

there were some questions and comments from the floor

Q- why add IP telephony? Why not just use the PSTN? A - First to get ready to future and second, there is no reason to bring both a PBX and Internet equipment into the disaster location (Internet access is needed in any case) when IP telephony would work over one set of equipment.

C - The proposal is not focused yet.

C - Congestion is an issue so one needs to prioritize but security is an issue.

C - Authentication etc is an issue - the call flows will have to be authenticated.

At this point Fred Baker as the BOF chair proposed that two new Internet Drafts be developed. One should cover the functional requirements in more detail for interfacing and processing emergency calls between the public switched telephone network and IP-telephony services. This should focus on the first stages of work to ensure an orderly transition of services from today's public network to the emerging telecommunications infrastructure based upon Internet technology. Means for identifying packets and packet flows that carry IEPS communications needs to be identified and agreed upon.

The second ID should present a high-level narrative of the requirements for processing emergency communications in public networks from today through a convergence period into next generation networks. The objective is to provide a view from the user and operational prospective on the functions required or desired for supporting emergency communications that will facilitate recovery for disaster situations. Hopefully this ID will provide a basis to drill down to the technical mechanisms that are needed to support emergency operations.


None received.