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 draft-folts-ohno-ieps-considerations-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. This Internet-Draft will expire on December 12, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract 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 queries * 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 infrastructure. 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 schemes 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 registered. 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 services: 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 conditions. 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 include: * 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 infrastructure * Status of recover actions * Interchange of critical data related to recovery operations * 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 video. 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 networks. 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) Multi-Queue 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 (spirits) - 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 - ieps@listserv.gsfc.nasa.gov, to subscribe send Email to majordomo@listserv.gsfc.nasa.gov indicating: subscribe ieps - in the body (do not include any other text in the body). The Web Site at http://www.iepscheme.net 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 foltsh@ncs.gov Hiroyuki Ohno, PhD Emergency Communications Section Communications Research Laboratory, MTP 4-2-1 Nukui-kitamachi, Koganei, Tokyo 184-8795, Japan hohno@ohnolab.org 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 English. 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 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE. Folts and Ohno [Page 12]