2.8.6 Internet Emergency Preparedness (ieprep)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-15


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: http://www.ietf.org/mail-archive/web/ieprep/index.html

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.

  Requirements for Internet Emergency Preparedness in the Internet.
  Framework for Supporting Internet Emergency Preparedness in IP

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.


  • draft-ietf-ieprep-framework-09.txt
  • draft-ietf-ieprep-domain-req-02.txt
  • draft-ietf-ieprep-domain-frame-02.txt

    Request For Comments:

    RFC3487 I Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
    RFC3523 I Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology
    RFC3689 I General Requirements for Emergency Telecommunication Service
    RFC3690 I IP Telephony Requirements for Emergency Telecommunication Service

    Current Meeting Report

    IEPREP - November 9, 2004 - 15:45-16:45 EST

    Notes taken by Aaron Falk

    - welcome - chairs
    - MLPP in IP networks
    - reading list:

    Scott: primary work today is to decide whether to proceed with the above

    Multi-Level Expedited Forwarding: Steve Silverman (draft-silverman-tsvwg-mlefphb-01.txt)

    Background: Sometimes there is insufficient bandwidth on a network. DOD and some other agencies need to prioritize users in those cases. This is done with five levels, the traffic on each level is normally less than 10% of the next lower level. Session control, e.g., Call Admission Control (CAC), is needed but may be of limited value since Silence Suppression may be in use (which can cause short term congestion).

    MLEF Overview: This is a simple cross between AF and EF. It uses a single queue with EF behavior and with multiple discard probabilities like AF. MLEF uses DiffServ with separate DiffServ codepoints for each class, but still one queue. As packets are queued, the classes are checked.

    Implementation: MLEF has been tested. It works with the high priority traffic getting through. It turned out to be easy to implement.

    We would like to get this approved as an experimental RFC.

    Chris Christou: What mechanism provides the ability to clear out the LP traffic in favor of the HP traffic?

    Steve: New packets get dropped at the bottleneck. Preemption may be used in the future to allow CAC to stop sessions, but not yet sure how this would work. However, at this time, the LP source is still sending.

    Sridam from NIST: Are different priorities in the same or different applications?

    Steve: All users are one of five priorities. I.e., the president never gets a busy signal.

    ??, BT: How do you get prioritized for HP traffic? By endpoint or session?

    Steve: On our closed military network, each user has a physical card which is used to authorize a user (common access code) and gets plugged into the phone. All of the users' traffic (voice only) gets the HP treatment. There is other non-voice traffic in the network.

    Scott: We need to be concerned about using this on non-military networks which may not use CAC.

    Pradeep, Lockheed: If all calls have CAC, how do you get overloaded?

    Steve: Id you assume you are using silence suppression and the network is fully loaded, then everyone says "wow" at the same time you'll get a momentary overload. MLEF results in the captain getting to continue his call.

    Pradeep: Does the DSCP identify the user?

    Steve: No, just which of the five or six precedence levels.

    ??: are you mixing voice with other traffic?

    Steve: The way EF works is that you configure a line to give EF a certain bandwidth. The other traffic gets the rest.

    Dennis Berg: In a circuit switch world, all the 5's get knocked out before impacting any 4's. Is this true for MLEF?

    Steve: yes.

    ??: Did you measure degradation as opposed to loss?

    Steve: We evaluated based on subjective impressions of voice quality.

    Fred Baker
    I have some slides but may not use them. My comments only apply to voice.

    Notice on this slide Flash Override, Override, and Routine: three levels of precedence

    Here's another approach which uses 11 levels of precedence.

    Watch this demo from CORVIL. Tool simulates an MPEG-4 datastream going by and shows queue lengths as packets arrive and depart as measured by MRTG. Notice as the number of flows goes up, the additional capacity needed to meet an SLA reduces (in ratio to the total capacity needed). (http://www.corvil.com)

    My concern is: under any circumstance where MLEF accomplishes something, it destroys an entire class of traffic. In video, it obliterates the entire screen, i.e., everything you've got going on. The idea is that one application shuts down and another will step in. The reality is that the old application will continue to send, and the new one will compete effectively. If you want the good one to get through, there is a different approach which I am nearly done writing a draft for, on elastic traffic.

    The mlef-concerns document describes why the telephony approach doesn't apply to IP networks.

    In the PSTN, there's nothing in the call itself which describes the precedence of the call, it's all in the control plane. Same for an ATM network. In the IP network, the principal difference is that our routing is done differently, even though it is just as deterministic as for ATM. So, the question becomes: if you don't need a DSCP in ATM or TDM, why do you need it in IP? Why does CAC suddenly not work? What you want is "path aware" and "loading aware" CAC that will allow us to decide whether to bring in a new call.

    Typically, we don't do bandwidth-aware CAC for VOIP. We do domain aware CAC which knows something about rules on how many calls are going on in the domain. But this is unaware of the routing of the call. The control path and the data path may be radically different. For the military network, you really need to know the routing of the data plane.

    In EF you run your network lightly loaded. For MLEF to accomplish anything, you need a queue. This adds latency, and delay variation.

    Steve: This has to do more with how you choose your packet limits.

    Joe Zebarth: What is your definition of significant latency?

    Fred: In our experiment it was 40 voice packets deep.

    Mary Lynch: Is the algorithm in hardware or software? Is it 'easy' to implement?

    Fred: yes (either): and its easy to implement. It drops based on thresholds. Similar to RED in behavior. The question is whether the algorithm accomplishes the right thing.

    Chris C: How do you configure your network? (to Steve)

    Steve: If you configure your network to configure a certain percentage of voice traffic, you can set sufficient amount.

    ??: With dynamic VPNs, you can apply different solutions. These can apply CAC within the VPN with the VPN meeting bandwidth limits.

    Fred: That is interesting but orthogonal to the problem at hand.

    Scott: Today's goal is to decide whether the ieprep WG recommends to the tsvw that the two docs on the agenda move forward.

    Fred: (responding to question from Dr. McGregor) Cisco is seeing, in some environments, that CAC is completely out of the picture. I don't think this will work. There needs to be an effective CAC and it needs to be aware of current routing.

    So what do I suggest? Fifteen years ago the Bob Braden and the IETF finished the first draft of the technology that solves this problem: RSVP. I propose this as the solution for the data path.

    You still need the SIP protocol to set up the session. You may need to express priority to the end system, too. This is another class of problem.

    You also may apply some policies, such as in Navy NCS network.

    NSIS doesn't at this time have the features that are needed for, e.g., preemption. So it is not a viable candidate today. If it did have these features, it might be a better candidate

    Scott: How many have read the drafts? - (About 1/4 the room.)

    How many of you think you understand Steve's proposal enough to express an opinion? (About 1/3 of the room.)

    Steve's proposal is qualified to apply only to a 'private, closed' networks. (I don't believe this is always going to hold.) The question of whether the IETF should standardize behavior in private networks has been under discussion for a long time but that aside should we tell tsvwg that Steve's proposal should be worked on? (Half of those knowledgeable, or 1/6th of the room)

    On Fred's proposal:
    How many of you have read Fred's document or understand its contents? (About 1/3 of the room.)

    How many of you think that we should tell tsvwg that we think they should work on that document? (About the same number supported this as answered yes to the last question.)


    Multi-Level Expedited Forwarding