Internet DRAFT - draft-folts-ohno-ieps-considerations
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
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]
