[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             Cory Beard
INTERNET DRAFT                           Univ. of Missouri-Kansas City
Expires: November 2002                                        May 2002


     Network Requirements for Internet Emergency Preparedness Services
                  draft-beard-ieprep-requirements-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   This document outlines requirements that need to be met in IP-based
   networks to enable and support communications for National
   Security/Emergency Preparedness (NS/EP) operations.  It provides a
   template from which an emergency service can be negotiated and
   provides a set of requirements that should be met for acceptable
   emergency communication services.  The focus here is on network
   requirements, rather than requirements for particular applications.
   The requirements are general and are intended to provide wide
   latitude in implementation options for service providers.

Table of Contents

   1. Introduction...................................................2
      1.1 Current PSTN Capabilities..................................3
      1.2 Purpose and Scope of this Document.........................3
      1.3 Fundamental Approaches.....................................4
   2. General Requirements...........................................4
      2.1 Availability...............................................5
      2.2 Dependability..............................................5
      2.3 Authorized Access..........................................6
      2.4 Privacy....................................................6
   3. Technical Requirements.........................................6
      3.1 Identification of Priority Traffic.........................7


Beard                  Expires - November 2002                [Page 1]


Internet-Draft          Emergency Requirements                May 2002


      3.2 Signalling for Resource Requests...........................7
      3.3 Better Then Best Effort Service............................7
   4. Special Requirements...........................................7
      4.1 Traffic Types..............................................8
      4.2 Network Areas..............................................8
      4.3 Application-Specific Support...............................9
   5. Policy Decisions..............................................10
      5.1 Services Always Available or Only Enabled Upon Emergency
      Declaration...................................................10
      5.2 Restoration Procedures....................................10
      5.3 Preemption................................................10
      5.4 Cooperation Between Service Providers.....................10
   6. Security Considerations.......................................11
   References.......................................................11
   Author's Address.................................................12

1. Introduction

   This document outlines requirements that need to be met in public
   and private IP-based networks to enable communications for National
   Security/Emergency Preparedness (NS/EP) operations.  These
   activities seek to return the population to normal living conditions
   after serious disasters and events, such as floods, earthquakes,
   hurricanes, and terrorist attacks.  Communication activities can
   involve person-to-person communications, group coordination,
   disaster assessment application execution, remote information
   retrieval, etc.

   Disaster situations can occur unexpectedly at any time and at any
   place.  These events often cause significant damage to the community
   infrastructure, including network infrastructure, and severely
   disrupt daily living.  Recovery requires rapid response by local
   authorities, immediate reaction from utility service providers, and
   support from medical, construction, fire, and police resources.
   Effective communications are essential to facilitate the
   coordination of lifesaving activities concurrent with reestablishing
   control in the disaster area. Following a disaster, immediate
   response operations focus on saving lives, protecting property, and
   meeting basic human needs.

   From a network perspective, communications can be particularly
   difficult even if the network infrastructure has not been the target
   of a terrorist or affected by a natural disaster.  This is because
   there can be a drastic surge in the network load in response to a
   disaster.  In recent years the Public Switched Telephone Network
   (PSTN) has experienced load levels three to five times normal
   immediately after an event [1], and the same is expected for the
   Internet, especially as IP telephony becomes more prevalent.





Beard                  Expires - November 2002                [Page 2]


Internet-Draft          Emergency Requirements                May 2002


1.1 Current PSTN Capabilities

   One model to consider for emergency communication services is the
   existing service in the United States PSTN, the Government
   Emergency Telecommunications Service (GETS).  Some other countries
   have equivalent services.

   The purpose of GETS is to increase the probability that phone
   service will be available to selected government agency personnel in
   times of emergencies.  It does not guarantee that service will be
   available, but it does implement a series of functions that increase
   the likelihood of finding an available circuit.

   The key aspects of GETS are as follows:

     o  Personnel gain access to GETS by calling a specified telephone
        number and presenting a credit-card type of authentication.

     o  Having authenticated themselves, the call is completed on a
        preferential basis.  If calls are initially blocked, they can
        be queued and can use alternate carriers.

     o  If fundamental telephone services are compromised, services
        contracted under GETS are restored first.

   These features enhance the capability of NS/EP calls to be completed
   in congested networks.  GETS will not preempt public telephone
   calls, nor are there levels of precedence within GETS.

   The approach of GETS is based on a preferential treatment model.
   This model may also be used by providers of Internet network
   services.  Other models could also be used and are introduced in a
   later section.

1.2 Purpose and Scope of this Document

   The purpose of this document is to provide a template from which an
   emergency service can be specified and negotiated between network
   service providers and customers.  It provides a set of requirements
   that would need to be met for a service to acceptably support
   emergency communications.  The focus here is on network
   requirements, rather than requirements for particular applications.
   For particular requirements related to IP Telephony, see [2].

   More importantly, however, the requirements given here are quite
   general and it is intended that wide latitude be available to
   service providers to implement services as they consider
   appropriate.  In [3], recommendations are provided as to how best to
   implement these services, but in this document requirements are
   stated so that service providers need not necessarily follow [3].



Beard                  Expires - November 2002                [Page 3]


Internet-Draft          Emergency Requirements                May 2002


   Section 2 provides general requirements that give high-level service
   capabilities that must be provided.  Section 3 then provides a
   minimal set of specific technical requirements for meeting the
   general requirements.  Section 4 gives special considerations that
   may optionally be addressed in an agreement for emergency services.
   And finally, Section 5 provides a list of policy decisions that need
   to be made and explained to customers by a service provider, but no
   specific requirements are given for policy issues.

1.3 Fundamental Approaches

   Before the requirements are discussed, it is first useful, however,
   to briefly outline the basic approaches that could be used by a
   provider in offering emergency services.  These are as follows.

     o  Best Effort Provisioning - Service providers may wish to
        provide emergency services by using sufficient capacity such
        that emergency services are provided acceptable quality without
        using additional mechanisms beyond best effort traffic handling
        [4].  One way this could be implemented would be to size links
        such that no congestion would be experienced, even if all
        traffic that would traverse a link would be multiplexed
        together.  Another approach could be to use a VPN-based
        approach to partition the capacity to at least keep emergency
        traffic from experiencing congestion.  In either approach, a
        service provider must be able to provide sufficient confidence
        that congestion would not be seen by emergency traffic even in
        the heavily overloaded conditions following disasters.

     o  Service Guarantees - Service providers may wish to provide
        emergency services that give some measure of service
        guarantees.  For example, they may provide specified upper
        bounds on delay for audio or video traffic.  They would agree
        to meet such requirements for a certain percentage of packets
        regardless of network conditions.

     o  Preferential Treatment - In contrast to service guarantees,
        however, service providers may wish to only provide services
        that in some way provide preferential treatment for emergency
        traffic without explicit guarantees.  If network congestion
        increases dramatically, the performance for emergency traffic
        might degrade right along with normal traffic, but would still
        receive some form of preference.  Although the traffic would
        not be immune to the effects of overloads, GETS has used this
        approach and it has proven to be acceptable.

2. General Requirements

   This section outlines four requirements for services that aim to
   provide emergency communications for the Internet (or any
   communication medium for that manner).  They pertain to the ability


Beard                  Expires - November 2002                [Page 4]


Internet-Draft          Emergency Requirements                May 2002


   to begin communications, complete communications successfully, and
   conduct them in an authorized and private manner.

2.1 Availability

   The most fundamental requirement for emergency communication
   services is that emergency-related users must have a high likelihood
   of network resources being available to them when they need them.
   Priority users must have a high probability of being able to
   initiate a communication session.

   Two interpretations of the concept of "high availability" could be
   applied, either in a relative sense or an absolute sense.  Such
   options on interpretation give latitude in implementation
   possibilities for emergency services.  The first interprets "high
   availability" in a preferential or relative sense.  Priority users
   would have preferred access to resources over normal users.  A
   service provider would implement mechanisms to identify and treat
   priority traffic in special ways.  Such an approach would allow a
   service provider to avoid having to meet specific availability
   targets (e.g., 95% availability) through an assurance that is given
   to priority customers that their traffic is being treated
   preferentially.  If the network is stressed, availability for
   priority users may decrease, but it would still be relatively higher
   (even much higher) than for normal users.

   In the second interpretation, high availability would mean absolute
   availability levels that would be provided regardless of the network
   operating conditions.  Service providers may choose to provide high
   availability levels through best effort provisioning even when the
   network is stressed.  They could choose to avoid using any
   mechanisms to identify or preferentially treat priority traffic,
   because priority traffic requirements would be met by the default
   operation of their network.

2.2 Dependability

   Priority users must not only be able to initiate communication
   sessions; they must also be able to successfully complete their
   intended activities.  While PSTN communications provide such
   dependability by default, Internet communications might be affected
   by a variety of network operating conditions, such as congestion or
   link failures.  An emergency communication service must protect
   priority communications from being affected by those conditions, at
   least to the extent that the communication session can still be
   conducted acceptably.  Definitions of acceptable performance will
   vary depending on the application.






Beard                  Expires - November 2002                [Page 5]


Internet-Draft          Emergency Requirements                May 2002


2.3 Authorized Access

   Mechanisms must be implemented so that only authorized users have
   access to priority communications services.  Such authorization
   could be PIN-based or based on assignment of cryptographic keys [5].
   Authorization protects network resources from excessive use and
   abuse.  The two purposes for this requirement are to restrict usage
   of network resources only to those who are allowed to use them and
   to enable proper billing.  Even when using a best effort
   provisioning approach where emergency users are not provided special
   services, proper billing necessitates authorized access.

   Such authorization mechanisms should be flexible enough to provide
   various levels of restriction and authorization depending on the
   expectations of a particular service or customer.  For example, it
   might be desirable to provide access to emergency communications
   differently after a hurricane where the emergency was caused by a
   natural disaster as compared to after a terrorist attack that was
   caused by humans.  In the hurricane scenario, members of the general
   public might be given access (e.g., at a lower priority level than
   emergency response organizations) where after a terrorist attack
   security concerns might necessitate highly restrictive access to
   emergency services.

   In the case of 911-type services, authorization is also applicable.
   In such cases, users self-authorize themselves by deciding that they
   have an urgent need that warrants special attention.  If they abuse
   the service, they also understand that they could be held
   accountable for such abuse.

   Further requirements and recommended procedures are given in [5].

2.4 Privacy

   Emergency communications will frequently have a requirement that
   they not be susceptible to viewing or modification by others, due to
   the sensitive and urgent nature of emergency response activities.
   An emergency communications service should be able to protect the
   integrity of user communication with options to encrypt user
   traffic.

3. Technical Requirements

   The following technical requirements represent the mechanisms that
   must be in operation to enable the general requirements listed above
   to be realized.  For several of the requirements below, it is
   assumed that networks will experience temporary scarcity of
   resources, especially because of damaged infrastructure and high
   demand immediately following a disaster.  If a service provider
   employs a best effort provisioning approach to provide emergency



Beard                  Expires - November 2002                [Page 6]


Internet-Draft          Emergency Requirements                May 2002


   services so that resources are never scarce, some of the following
   requirements will not be necessary.

3.1 Identification of Priority Traffic

   Priority traffic must be recognized in the forwarding plane.  An
   emergency communication service must have procedures by which
   emergency traffic is marked so that it can be identified throughout
   the network.  The decisions about who does such marking (i.e., end
   users or the network), where it occurs, who recognizes such marking,
   whether re-marking might occur, and at what layer or layers marking
   is implemented are left to the discretion of the service provider.

3.2 Signalling for Resource Requests

   Priority traffic must be recognized in the control plane.  For
   applications where sessions need to be established or network
   resources reserved, signalling mechanisms must be used that support
   the differentiation of priority signalling messages.

3.3 Better Then Best Effort Service

   The default best-effort forwarding behavior available in existing
   routers as standardized in [4] does not provide performance
   assurances.  This is especially true for emergency services where
   severe congestion that accompanies disasters can cause the
   performance of best-effort delivery to degrade well below acceptable
   levels.

   Quality of service for emergency communication services does not
   necessarily mean better quality of voice/video as compared to what
   is available to normal users. The same QoS classes, which are
   already defined for normal traffic, can be utilized for emergency
   traffic as well.

   The fundamental quality of service requirement for priority traffic
   is this - better than best effort service.  Service providers have
   the freedom to implement special quality of service mechanisms to
   meet this requirement, but other approaches may be effective as
   well.

   Better than best effort service is provided to emergency traffic so
   that it will receive guaranteed performance levels that are at or
   above a minimum performance level.  Without such a requirement, the
   dependability requirement outlined above could not be met.

4. Special Requirements

   In addition to the general and technical requirements given above,
   this section provides additional requirements that may optionally be
   requested for particular service agreements.  They primarily involve


Beard                  Expires - November 2002                [Page 7]


Internet-Draft          Emergency Requirements                May 2002


   the specification of the particular approach that is being used by
   service providers for particular networks, applications, and types
   of traffic.

4.1 Traffic Types

   A service provider may choose to provide an emergency service that
   supports different traffic types in different ways with customized
   levels of availability and dependability.  The three types of
   traffic that may be treated in distinctive ways are as follows.

     o  Inelastic traffic - As defined in [6], inelastic traffic is
        traffic which has a firm delay bound.  If packets arrive after
        a maximum acceptable delay, the packets are essentially
        worthless to the receiver.  Real-time audio and video are
        examples of inelastic traffic.

     o  Interactive elastic traffic - Elastic applications are
        generally those which wait for data to arrive and do not
        discard it if it is late.  This does not mean that applications
        are insensitive to delay, however, because such delays could
        hurt application performance significantly.  In particular,
        interactive elastic traffic requires reasonable delays because
        of the user interaction that is involved.  Examples of
        interactive elastic traffic include HTTP and instant messaging
        traffic.

     o  Bulk transfer elastic traffic - Some elastic applications,
        however, do not involve direct user interaction.  In such
        cases, delay is not so much a concern as average throughput.
        Bulk transfers can have large variations in delay as long as an
        expected average throughput is obtained.  For example, if a
        file can be downloaded in 100 seconds, it does not matter if
        for part of the transfer the throughput was virtually zero.
        Examples of bulk transfer traffic are FTP and SMTP.

   As an example of how service providers may wish to support the above
   types of traffic, they may wish to provide service guarantees for
   inelastic traffic using Diffserv [7] but use best effort
   provisioning for both types of elastic traffic.

4.2 Network Areas

   It is not expected that service providers use the same approach to
   supporting emergency traffic in all parts of their network.  They
   are free to provide services differently based on whether traffic is
   traversing core, distribution, or access layers of the service
   provider's network.  Specifications may also differ depending on the
   type of access technology that is being used (e.g., LAN, wireless,
   or DSL).



Beard                  Expires - November 2002                [Page 8]


Internet-Draft          Emergency Requirements                May 2002


   For example, a service provider may wish to identify and provide
   specialized treatment of emergency traffic in access networks and
   use best effort treatment in core networks.

4.3 Application-Specific Support

   In addition to the above requirements for network layer mechanisms
   to support priority services, specific applications may have
   additional requirements to be acceptable for emergency users.  Such
   requirements might include additional signalling or mechanisms to
   provide preferential performance or dependability to priority users.
   Examples of applications include the following.

     o  Voice on IP, using such signaling architectures as H.323 or SIP
        [8].

     o  Shared real-time whiteboard.

     o  Instant messaging and presence.

     o  Databases such as the Japanese "I am Alive" [9] service, for
        communication with persons not involved in the crisis.

     o  Database services for managing the crisis, including
        calendaring, contact management, order and trouble report
        management, legal services, medical services, etc.

     o  Electronic mail.

     o  Damage assessment applications.

     o  File transfer.

     o  World Wide Web.

   However, this document does not address requirements for
   applications.  The focus of this document is to provide requirements
   for network service providers.  Requirements for the applications
   should be met by content providers and end users.  However, network
   service providers may wish to provide network-based services which
   could improve the performance of particular applications, for
   example by providing web caching.

   Of specific interest to current emergency management organizations
   are IP Telephony and Voice on IP.  Further requirements and
   recommended procedures for these applications in particular are
   given in [2].






Beard                  Expires - November 2002                [Page 9]


Internet-Draft          Emergency Requirements                May 2002


5. Policy Decisions

   The above general and technical requirements provide wide latitude
   for creativity on the part of service providers to implement
   emergency services.  In addition to meeting the requirements above,
   a series of policy decisions should be made in the implementation of
   emergency services.  No particular approach is prescribed regarding
   these policies.  However, the policies used by a service provider to
   addressing the following issues should be clearly defined and
   communicated.

5.1 Services Always Available or Only Enabled Upon Emergency
    Declaration

   Providers of an emergency service should specify whether emergency
   treatment is always available within the network or whether the
   service is only activated upon declaration of emergency conditions
   by an appropriate authority.  Service providers may also choose to
   provide a minimal service that is available at all times, but which
   could be expanded once an emergency declaration was made.

5.2 Restoration Procedures

   Service providers should describe the restoration procedures they
   will use when substantial damage is experienced in their network.
   They should provide plans and estimates in advance of how damaged
   facilities will affect the availability of emergency services and,
   if a critical relationship exists, how prioritized restoration of
   those vital facilities will be accomplished.  Service providers may,
   of course, choose to rely upon rerouting mechanisms that would make
   the restoration procedures they use irrelevant to the continued
   dependability of emergency services.  The only concern in that case
   is when damage could be so extensive that rerouting mechanisms would
   be ineffective.

5.3 Preemption

   Service providers may wish to provide resources for emergency
   communications by interrupting particular non-emergency traffic
   flows.  If such an approach is used, this should be explicitly
   stated and details should be given on how preemption is carried out.
   Regulatory guidelines in some jurisdictions may prohibit the use of
   preemption to support emergency traffic.

5.4 Cooperation Between Service Providers

   Emergency users will only be concerned with the quality of the end-
   to-end communications they are provided.  However, it is possible
   that no one particular service provider will be able to support that
   service end-to-end.  Emergency services could be carried over a



Beard                  Expires - November 2002               [Page 10]


Internet-Draft          Emergency Requirements                May 2002


   combination of service providers, some of which would provide
   emergency capabilities and some of which may not.

   Service providers which do provide emergency services may choose to
   provide services that are only operative within their networks and
   are independent of other service providers.  Alternatively, service
   providers may employ mechanisms to cooperate with other service
   providers to provide emergency services.  This would result in a
   considerable portion of the end-to-end path being administered in a
   cooperative fashion.  If so, service providers should specify the
   mechanisms they would use and the extent to which they would
   cooperate with other service providers to support emergency
   services.

6. Security Considerations

   Authorized access and privacy are presented here as general security
   requirements for emergency services in Section 2.  Further
   requirements are given in [5].

References

   1  B. Brewin, "Nation's Networks See Large Volume Spikes After
      Attacks,", Computerworld, September 17, 2001.

   2  Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP
      Telephony," draft-ietf-ieprep-framework-00 (work in progress),
      February 2002.

   3  Work-in-progress.

   4  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
      June 1995.

   5  Brown, I., "Securing prioritised emergency traffic", draft-brown-
      ieprep-sec-00 (work in progress), February 2002.

   6  Braden, R, Clark, D., and Shenkar, S., "Integrated Services in
      the Internet Architecture: an Overview", RFC 1633, June 1994.

   7  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
      Weiss, "An Architecture for Differentiated Services", RFC 2475,
      December 1998.

   8  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
      "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   9  , "IAA System (I Am Alive): The Experiences of the Internet
      Disaster Drills", INET 2000, June 2000.




Beard                  Expires - November 2002               [Page 11]


Internet-Draft          Emergency Requirements                May 2002


   Author's Address

      Cory Beard
      School of Interdisciplinary Computing and Engineering
      University of Missouri-Kansas City
      5100 Rockhill Road
      Kansas City, MO  64110

      Phone:  1-816-235-1550
      Email:  beardc@umkc.edu











































Beard                  Expires - November 2002               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/