Internet DRAFT - draft-folts-ohno-ieps-considerations


Network Working Group                                          H. Folts
Internet-Draft                                                 NCS, USA
Expires: December 15, 2000                                      H. Ohno
                                     Communications Research Lab, Japan
                                                          June 16, 2000

                 Functional Requirements for
    Priority Services to Support Critical Communications


Status of this Memo

     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     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
     The list of current Internet-Drafts can be accessed at
     The list of Internet-Draft Shadow Directories can be
     accessed at
     This Internet-Draft will expire on December 12, 2000.

Copyright Notice
     Copyright (C) The Internet Society (2000). All Rights

     This draft requests development of detailed specifications for the
     technical and operational requirements for an Internet-based
     International Emergency Preparedness Scheme (IEPS) as

Folts and Ohno                                                [Page 1]

Internet draft      IEPS Considerations                   June 16, 2000

     defined by ITU-T Recommendation E.106. Public
     telecommunications services have long had such a
     scheme, to ensure priority handling of telephone
     communications, such as during natural disasters.  As a
     wide range of communication services increasingly rely
     upon the family of specifications related to Internet
     Protocol (IP), IETF work needs to include consideration
     and provision for supporting IEPS. This work needs to
     be addressed in two phases concurrently - 1) interface
     for transition from today's public switched telephone
     network (PSTN) to IP-based network telephony services,
     and 2) additional and enhanced capabilities, such as
     application-specific IEPS services.  An Email list for discussion
     and a Web site for background and documents has been established
     to assist the work

1.   Introduction
     There is a need for priority communications among
     governmental, civil, and other essential users of
     public telecommunications services in crisis
     situations, such as earthquakes, severe storms, and
     floods. Telecommunication services are often restricted
     during these events due to damage, congestion, and
     failures. ITU-T Recommendation E.106 describes an
     International Emergency Preparedness Scheme (IEPS) for
     telecommunications services that will support recovery
     activities during crisis situations.
     The IEPS will enable authorized users to have priority
     access to telecommunication services and priority
     processing of communications, in support of recovery
     operations during emergency events. It is essential
     that appropriate arrangements exist to permit these
     operations among the many communications service
     providers and nations of the world. While many
     countries have national preparedness schemes in
     existing telecommunication systems, the challenge at
     hand is provisioning appropriate priority mechanisms in
     the newly emerging generation of IP-based networks.
     There will be the challenge initially of interfacing
     the emergency handling process in existing telephony
     services with IP-based services during the transition
     period where both services will interwork. Measures will
     also need to be considered for security protection of IEPS
     communications passing through the IP-based network 
     In addition the broad range of IP-based services, with
     their enhanced capabilities, can significantly benefit

Folts and Ohno                                                [Page 2]

Internet draft      IEPS Considerations                   June 16, 2000

IEPS users and operations. These include:

          Web access              *    Instant messaging
     *    Remote printing         *    Email
     *    File transfer           *    Wireless access
     *    Multicast audio and     *    Interactive audio
          video                        and video
     *    Remote data base        *    DNS lookups
     *    Remote network          *    Prioritized and
          management interactions      differential IP handling
     All of these services could be considered for
     preferential treatment, authorization, and
     administration for IEPS. Considerable work is currently
     underway in many standards bodies to define new
     mechanisms, protocols, and procedures for advancing
     networking technology. It would be immensely beneficial
     to telecommunication users, service providers, and
     nations of the world to support IEPS within the rich
     communications capabilities inherent in the IP-based
     operating infrastructure.
     This draft suggests where work might be undertaken to
     introduce IEPS in the newly emerging telecommunications
     environment. The immediate focus needs to be on the
     interface between PSTN services and IP-based networks
     for supporting IEPS requirements. At the same time,
     consideration will need to be taken of the many
     additional services that will further enhance IEPS
     capabilities and operations. Realization of IEPS
     requirements in the next generation of
     telecommunication services should be accomplished by
     common mechanisms inherent in the new basic

2.   IEPS Services Today
     ITU-T Recommendation E.106 addresses IEPS in terms of
     the Public Switched Telephone Network (PSTN) and
     Integrated Services Digital Network (ISDN). Today's
     systems are based primarily upon well-established circuit-
     switched technology and principles. The essential
     features described by E.106 for the successful
     operation of IEPS are:
     a)   Priority dial tone
     b)   Priority call set-up, including priority queuing

Folts and Ohno                                                [Page 3]

Internet draft      IEPS Considerations                   June 16, 2000

c)   Exemption from restrictive management controls
     The following paragraphs provide some examples of IEPS services
     available today. These examples cover both PSTN and Internet-based
     implementations. They represent the point of departure into the
     technical work of the IETF to support IEPS requirements in the
     next generation of specifications.

 2.1 In the United States, the Government Emergency
     Telecommunications Service (GETS) uses High Probability
     of Completion (HPC) network capability for marking
     emergency calls. In accordance with ANSI T1.631-1993,
     the Calling Party's Category parameter is used to mark
     emergency calls within the initial address message
     (IAM) for call set-up in Signalling System No 7 (SS7).
     This specific parameter has been set aside by the ITU-T
     in Recommendation Q.763 for national use. This
     parameter is used to trigger special applications
     within the U.S. PSTN to enhance call completion.
     Alternate carrier routing (ACR) is also employed in the
     GETS because there are multiple inter-exchange carriers
     (IXC) supporting the service in the United States. If
     one IXC is not available, the call is redirected to
     another IXC until all possibilities are exhausted.
 2.2 For the past five years an emergency communications system has
     been under development in Japan to support recovery from major
     disasters such as the devastating earthquake that hit the city
     of Kobe in 1995.  The WIDE (Widely Integrated Distributed
     Environment) project, a well-known research consortium on
     Internet technologies in Japan, developed an emergency system
     called IAA ("I am alive").  This is a scalable and robust
     distributed database system that supports voice, touch-tone,
     cell phone, facsimile, www, and other user interfaces for 
     emergency communications. IAA supports registration and retrieval
     of information for victims and to support the many recovery
     activities in a disaster area. It is based upon Internet
     technology to provide the diversity and flexibility required
     for supporting emergency communications under the most severe
     conditions. The development of IAA has been a cooperative effort
     of Japanese universities, industry, and the Communication Research
     Laboratory (CRL), Ministry of Posts and Telecommunications.

2.3 Other countries also have national operational IEPS capabilities,
     or ones under development. They employ various access
     schemes for telephony services. Some identify access
     lines where all calls originated on that line are
     treated with priority service. Another approach
     activates priority service on a per-call basis only

Folts and Ohno                                                [Page 4]

Internet draft      IEPS Considerations                   June 16, 2000

     The dialing plan for GETS uses a universal access
     number with a non-geographic, toll free Numbering Plan
     Area (NPA) code that has been assigned by the North
     American Numbering Plan Administration (NANPA) to the
     United States Government. After dialing the universal
     access number, the user is prompted for a Personal
     Identification Number (PIN). When the PIN is
     authenticated, the originator will then be requested to
     enter the destination number.
     Fulfillment of the basic IEPS capabilities by today's
     telephony services has required addition of special
     provisions to existing implementations. They have
     proven successful and effective, but they have resulted
     in considerable expenditure of effort and resources. It
     would be much more desirable that basic mechanisms,
     which are implemented as an inherent part of the
     emerging network infrastructure, be used to also
     support the IEPS communication capabilities. These
     mechanisms could be adapted from those implemented or
     under development for other service offerings.

3.   Next Generation Networks
     The IEPS requirements of E.106 also need to be
     fulfilled by the next generation of telecommunications
     services, which are based upon packet-switched
     technology. Packet technology provides a significantly
     different operational environment than exists for
     today's circuit-oriented telecommunications. As a
     result, there are many new aspects that must be
     considered in satisfying IEPS requirements. There is
     also opportunity for adapting many innovative service
     features and capabilities that are becoming available
     to enhance IEPS operations.
     Implementation of IEPS requirements in IP-based
     networks ideally should be incorporated into the common
     mechanisms that are built into the infrastructure as
     they are being developed and deployed. IEPS
     requirements should be viewed as another communication
     service being offered by service providers as part of
     their business structure. For example, efforts already
     underway to develop mechanisms for selecting and
     managing different levels of quality, grade and classes
     of service could be applied to IEPS. The flexibility of
     emerging object-oriented and distributed technologies
     might have the potential for readily and economically
     supporting a diversity of service features. At a

Folts and Ohno                                                [Page 5]

Internet draft      IEPS Considerations                   June 16, 2000

     minimum, an IEPS indicator to identify emergency
     communications needs to be defined and conveyed in the
     IP-based network environment. The IEPS indicator could
     be similar to the HPC code point used in SS7 for call
     set-up in traditional PSTN operations. However, the
     IEPS indicator in IP-based networks must also be
     applied throughout the duration of the communication
     and other indicators, such as at the application level,
     might also be appropriate.
     Extensive activities are underway in international,
     regional, and national industry standards bodies to
     develop specifications for next generation networks.
     These bodies include IETF, ETSI TIPHON, and ITU-T.
     Close cooperation needs to be maintained among these
     organizations to facilitate consistent results and
     global agreement. There is also considerable ongoing
     work underway to define the many features and
     mechanisms needed to support diverse services that will
     be provided by evolving telecommunications
     capabilities. While ITU-T Recommendation E.106 is based
     on PSTN/ISDN services, it is imperative that early
     attention be given to meeting the IEPS requirements in
     future telecommunication services supported by next
     generation of networks. Now is the time to ensure full
     consideration of the IEPS requirements in both the
     current and the future IP-based network endeavors
     before results fully mature and are deployed.

4.   Issues to be Addressed
     Compared with circuit-based systems, packet-switched
     environments often display better statistical
     reliability and performance, but far less specific
     predictability.  The packet-switched environment
     introduces many additional variables in processing of
     supported services. The "send and pray" nature of
     typical connectionless packet mode is being adapted to
     support a variety of performance levels required by
     various communicating applications. For instance, new
     quality-of-service mechanisms are being developed to
     support telephony and interactive video applications.
     Features needed to support IEPS emergency
     communications on an end-to-end basis include priority
     access, routing, processing, and egress for the
     duration of the communication. Important issues include
     the evolution of services transitioning from today's
     PSTN/ISDN to the new IP-based environment as
     illustrated in the TIPHON scenarios defined in ETSI

Folts and Ohno                                                [Page 6]

Internet draft      IEPS Considerations                   June 16, 2000

     Document TR 101 300 v2.1.1.
     Transition of the existing service requires that an
     interface between the SS7 HPC code point in the IAM for
     call set-up and the IP-based network protocols be
     developed. Most likely is that an IEPS indicator needs
     to be defined and appropriate protocol fields need to
     be identified to carry the code point information. Next
     the code point needs to be recognized, processed, and
     conveyed through an IP-based network, either to the end
     application directly or to another interface with SS7.
     The IEPS indicator must also be recognized and
     processed during the entire period of the communication
     in the IP-based environment.
 4.1 Specific issues to be considered initially to facilitate
     a transition from PSTN to IP telephony services include the following:

  4.1.1 - Technical Issues

     a)   The protocol mechanisms of IP-based networks in
          operation and under development that could convey an HPC-
          type IEPS indicator to identify set-up of an emergency
          telephone communication. This would enable priority routing
          and processing ahead of other traffic being offered.
     b)   A field in the header of any candidate protocol that
          might be involved in conveying an emergency communication
          indication needs to be identified and space reserved for a
          code point.
     c)   Appropriate code point(s) to be used to convey the IEPS
          indicator through the IP-based environment needs to be

     d)   Measures for security protection of IEPS communications
          transiting IP-environments. Issues that need to be considered
          include authentication/authorization for call initiation and
          protection of IEPS communications from cyber attacks in
          IP-based networks.

  4.1.2 - Operational Issues

     a)   Procedures and processes for handling the IEPS
          indicator in the IP-based environment. This includes
          priority routing of packets as well as alternate routing
          capabilities when congestion or outage is encountered during
          the communication.
 4.2 Further work will be needed to define specifications for special
     handling of new IP-based applications, of the type

Folts and Ohno                                                [Page 7]

Internet draft      IEPS Considerations                   June 16, 2000

     and range listed earlier in section 1.  At the same time,
     extension of the basic capability needs specified in the initial
     work described in 4.1 need to be considered for new features that
     become available in the new IP-based network environment.
     The following identifies a number of the technical and operational
     capabilities that should be studied for enhancing future IEPS
     a)   Maintenance of the priority status of a communication
          for its total duration.
     b)   Maintenance of the required quality of service to
          support the instance of communication.
     c)   Maintenance of the required grade of service to ensure
          a minimum bandwidth or throughput level during heavy traffic
     d)   Dynamic alternate routing of IEPS communications when
          congestion and failure occurs.  This may require quicker
          adaptation than typical IP-based adaptive routing affords.
     e)   Interchange of critical operational data across the
          interdomain Telecommunications Management Network (TMN) X-
          interface, as specified in ITU-T M.3010. Possible examples
          *    Registration of authorized users
          *    Monitoring of service performance
          *    Identification of security breaches and unauthorized
               use of IEPS
          *    Activation/deactivation of IEPS services or priority
               levels in specific regions
          *    Reports of failure points in telecommunications
          *    Status of recover actions
          *    Interchange of critical data related to recovery
          *    Reports of usage and billing information
     f)   Preferential treatment for IP-based applications, such
          as Email, instant messaging, remote printing, web access,
          file transfer, multi-cast video, interactive audio, remote
          network management, and DNS lookups.
     g)   Multicast and broadcast services for voice, data, and

     h)   Definition of multiple levels of emergency priority,

Folts and Ohno                                                [Page 8]

Internet draft      IEPS Considerations                   June 16, 2000

          possibly including different types of service as well as
          different degrees.
     i)   Interface for access by mobile and/or constrained IP-
          based devices, such as are developing with wireless access.
     As the telecommunications technologies continue to
     evolve innovations and further enhancements to IEPS
     support services will emerge. It is critical that
     efforts to address these many issues are established as
     early as possible in the work underway and in future
     work to develop specifications for next generation

5.   Candidate Work Areas
     The IEPS requirements could potentially touch on many of
     the IETF work areas. Initially, the focus should be on
     specific issues described in section 4 to facilitate the
     transition from the PSTN to IP telephone services. In particular,
     the following technology/protocol issues have been identified as
     initial candidate areas that should be examined:
          Session Initiation Protocol (SIP)
          Multimedia Gateway Control Protocol (MGCP)
          Differential Services (diffserv)
          Multi-Protocol Label Switching (MPLS)
          Aggregated RSVP
     It is plausible that IEPS requirements could have as pervasive an
     impact as security in IETF work.  Nearly all IETF working groups
     devoted to specification of infrastructure service, core
     applications, or reliability and other quality of service features
     are candidates.  Hence, although quite long, the following is
     merely representative of the range, and part of the early IETF
     work is to define the complete list:
     * Applications Area
     -    Common Name Resolution Protocol (cnrp)
     -    Extensions to FTP (ftpext)
     -    HyperText Transfer Protocol (http)
     -    Instant Messaging and Presence Protocol (impp)
     -    Internet Printing Protocol (ipp)
     -    LDAP Duplication/Replication/Update Protocols (ldup)
     -    Message Tracking Protocol (msgtrk)
     -    NNTP Extensions (nntpext)
     -    Web Replication and Caching (wrec)

Folts and Ohno                                                [Page 9]

Internet draft      IEPS Considerations                   June 16, 2000

* Internet Area
     -    DNS Extensions (dnsext)
     -    IPNG (ipngwg)
     -    Internationalized Domain Name (idn)
     -    Service Location Protocol (svrloc)
-    Zero Configuration Networking (zeroconf)
     *    Operations and Management Area
     -    Authentication, Authorization and Accounting (aaa)
     -    Domain Name Server Operations (dnsop)
     -    Internet Traffic Engineering (tewg)
     -    Network Access Server Requirements (nasreq)
     -    Next Generation Transition (ngtrans)
     -    Policy Framework (policy)
     -    Resource Allocation Protocol (rap)
     -    Roaming Operations (roamops)
     * Routing Area
     -    Border Gateway Multicast Protocol (bgmp)
     -    IP Routing for Wireless/Mobile Hosts (mobileip)
     -    IS-IS for IP Internets (isis)
     -    Inter-Domain Routing (idr)
     -    Multicast Source Discovery Protocol (msdp)
     -    Multiprotocol Label Switching (mpls)
     -    Open Shortest Path First IGP (ospf)
     -    UniDirectional Link Routing (udlr)
     -    Virtual Router Redundancy Protocol (vrrp)
     * Security Area
     -    Authenticated Firewall Traversal (aft)
     -    Common Authentication Technology (cat)
     -    IP Security Policy (ipsp)
     -    IP Security Remote Access (ipsra)
     -    Secure Network Time Protocol (stime)
     * Transport Area
     -    Audio/Video Transport (avt)
     -    Differentiated Services (diffserv)
     -    Endpoint Congestion Management (ecm)
     -    IP Telephony (iptel)
     -    Integrated Services (intserv)
     -    Integrated Services over Specific Link Layers (issll)
     -    Media Gateway Control (megaco)
     -    Multicast-Address Allocation (malloc)
     -    Network Address Translators (nat)
     -    PSTN and Internet Internetworking (pint)
     -    Resource Reservation Setup Protocol (rsvp)
     -    Service in the PSTN/IN Requesting InTernet Service
     -    Session Initiation Protocol (sip)

Folts and Ohno                                                [Page 10]

Internet draft      IEPS Considerations                   June 16, 2000

     -    Signaling Transport (sigtran)
     -    Telephone Number Mapping (enum)

     This list should be modified as other areas are identified as
     candidates and as development of specifications for these
     capabilities improve our understanding of them.

6.   Email List and Web Site

     An Email list has been established for discussion of the IEPS
     issues -, to subscribe send Email to indicating: subscribe ieps - in
     the body (do not include any other text in the body).

     The Web Site at provides background and
     access to working documents.

7.   Conclusion
     NS/EP capabilities within the telecommunications
     infrastructure can significantly benefit the nations of
     the world and the telecommunication service providers
     in recovery from extreme stress on operational
     facilities and recovery from major disasters.
     The NS/EP priority capability should be accomplished
     through application or adaptation of existing or newly
     developed mechanisms within the telecommunications
     infrastructure that have broader application within
     systems.  In addition, an assignment of the appropriate
     code points will be needed to invoke the services when
     and where required.

8.   Author's Address
     Hal Folts
     National Communications System
     701 Arlington South Court House Rd.
     Arlington VA 22204-2198

     Hiroyuki Ohno, PhD
     Emergency Communications Section
     Communications Research Laboratory, MTP
     4-2-1 Nukui-kitamachi, Koganei, Tokyo 184-8795, Japan

Folts and Ohno                                                [Page 11]

Internet draft      IEPS Considerations                   June 16, 2000

9.   References
     ITU-T Recommendation E.106 - Description of an
     International Emergency Preference Scheme (IEPS)
     ITU-T Recommendation M.3010 - Principles for a
     Telecommunications Management Network
     American National Standard, ANSI T1.631-1993, for
     Telecommunications - Signalling System No. 7 (SS7) -
     High Probability of Completion (HPC) Network Capability
     ETSI TR 101 300 v2.1.1 (1999-10) - Telecommunications
     and Internet Protocol Harmonization Over Networks
     (TIPHON); Description of Technical Issues

10.   Full Copyright Statement
     Copyright (C) The Internet Society (1999). All rights reserved.

     This document and translations of it may be copied and furnished
     to others, and derivative works that comment on or otherwise
     explain it or assist in its implementation my be prepared, copied,
     published and distributed, in whole or in part, without
     restriction of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and derivative
     works.  However, this document itself may not be modified in any
     way, such as by removing the copyright notice or references to the
     Internet Society or other Internet organizations, except as needed
     for the purpose of developing Internet Standards process must be
     followed, or as required to translate it into languages other than

     The limited permissions granted above are perpetual and will not
     be revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided as

Folts and Ohno                                                [Page 12]