2.8.4 Internet Emergency Preparedness (ieprep)

Last Modified: 2003-07-21

Chair(s):
Scott Bradner <sob@harvard.edu>
Kimberly King <kimberly.s.king@saic.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: ieprep@ietf.org
To Subscribe: ieprep-request@ietf.org
In Body: subscribe ieprep
Archive: ftp://ftp.ietf.org/ietf-mail-archive/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.

Deliverables

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.

Informational:
  Requirements for Internet Emergency Preparedness in the Internet.
  Framework for Supporting Internet Emergency Preparedness in IP
  Telephony.
Goals and Milestones:
Done  Submit initial I-D of Requirements
Done  Submit initial I-D of Framework
Done  Submit initial I-D of Recommendations BCP
Done  Submit Requirements I-D to IESG for publication as an Informational RFC.
Done  Submit Framework I-D to IESG for publication as an Informational RFC.
Dec 03  Submit Recommendations I-D to IESG for publication as a BCP.
Internet-Drafts:
  • - draft-ietf-ieprep-framework-05.txt
  • - draft-ietf-ieprep-requirements-01.txt
  • - draft-ietf-ieprep-reflexive-dscp-02.txt
  • - draft-ietf-ieprep-ets-telephony-05.txt
  • - draft-ietf-ieprep-ets-general-04.txt
  • Request For Comments:
    Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) (RFC 3487) (39615 bytes)
    Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology (RFC 3523) (10190 bytes)

    Current Meeting Report

    IEPREP Vienna meeting minutes**Carlberg presentation
    
    Basic telephony and general requirements were acceptable (i.e., no 
    objections) to the working group.  The framework will undergo another pass 
    through. Polk - raised the issue that the IETF use terms in alignment with 
    the ITU. The ITU uses the initialism TDR (telecommunications for 
    disaster relief) vs. ETS.  **
    
    Carlberg stub domain presentation
    
    Berg - wants to know if access links and transit are part of some IEPREP 
    document, Scott says within a domain but not in plan to go beyond single 
    domain.  Desire has been expressed but not enough meet in traction to go 
    further. Scott feels the intention is both stub domains and transit over a 
    single domain. Polk - wants to know EF relationship and things like MPLS 
    ideas.**
    
    Gunn presentation
    
    Polk - This document proposes extensions to a lot of existing 
    protocols, and a BCP is intended to use existing technology in its 
    practices. The ideas in this document might be better served if the ideas 
    were broken up, replaced by requirements, and moved into the 
    appropriate working groups for consideration. If the resulting 
    mechanisms are standardized, then the document can be revived in IEPREP for 
    consideration. Further, the point is that this document only proposed 
    solutions, which are not appropriate. In order for this document to have any 
    use it must be made up of requirements.
    
    Bradner - This document, as is, has no path forward. The use of 
    experimental codepoints makes it such that it won't be made into an RFC. 
    Also, a best common practices document must be possible with existing 
    technology, and due to the fact that you are using experimental 
    codepoints, you don't meet that requirement. If the media gateway is smart 
    enough to differentiate between ETS and non-ETS traffic, then the IP 
    portion is not relevant, as two tunnels can be created (1 - ETS; 1 - non 
    ETS), and manage the priority in that way.
    
    Henry (MCI) - There are no IP phones in the architecture, and 
    therefore the model is bad. Also, it doesn't consider cable networks at 
    all. Scott Bradner said that it was "a scenario that needs to be 
    addressed, but not the only one."
    
    Dick Knight - asked a clarification on the requirement in the proposed BCP 
    for the use of M2UA rather M3UA. Dick stated that M2UA emulates SS7 MTP2 
    level (Signaling Transport - Link Level) so that an existing SS7 MTP3 
    (Signaling Transport - Network Level) can be used without it knowing that it 
    is operating in an IP packet environment. Similarly, M3UA emulates the 
    Signaling Network Level of SS7, so that ISUP and other Application Parts of 
    the SS7 stack, can be used without knowledge of the underlying IP 
    network. Janet's presentation explicitly stated that M2UA MUST be used in 
    order to preserve SS7 ISUP parameters. Dick pointed out that whether M2UA or 
    M3UA is used, the ISUP parameters are unaffected. He asked for an 
    explanation of this requirement.
    
    Dick Knight also said  "People are using M3UA or M2PA. Nobody is using 
    M2UA."  Also "There is no point in using the (current) SIP emergency 
    header if you are going to a CSN phone. The SIP emergency 
    notification will never get there. The SIP emergency notification only 
    makes sense if it is going to a SIP phone." 
    

    Slides

    Agenda
    High Availability Networks
    IETF-Vienna IEPREP WG, July 2003
    MPLS IP Bridging Configuration Guidance for IEPREP