IP Telephony Requirements for Emergency Telecommunication Service (ETS)
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 3690.
|Last updated||2015-10-14 (Latest revision 2003-12-02)|
|RFC stream||Internet Engineering Task Force (IETF)|
|Additional resources||Mailing list discussion|
|IESG||IESG state||RFC 3690 (Informational)|
|Responsible AD||Jon Peterson|
|Send notices to||<email@example.com>|
Internet Engineering Task Force Ken Carlberg INTERNET DRAFT UCL November 28, 2003 Ran Atkinson Extreme Networks IP Telephony Requirements for Emergency Telecommunication Service <draft-ietf-ieprep-ets-telephony-07.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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in . Solutions to these requirements are not presented in this document. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . 1. Introduction Effective telecommunications capabilities can be imperative to facilitate immediate recovery operations for serious disaster events, Carlberg & Atkinson Expires May 28, 2004 [Page 1] ^L Internet Draft ETS Telephony Requirements November 28, 2003 such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless Personal Digital Assistants (PDAs). The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. 1.1 Problem Standards have been developed by other standards bodies concerning emergency communications. As discussed in , some of these standards, such as T1.631 , define specific indicators or labels for emergency communications in Signaling System 7 (SS7) networks. Certain requirements must be defined in order to achieve peering across hybrid networks (networks that communicate between IP and other types of networks such as that realized by the Public Switched Telephone Network) in order to achieve an interworking of services. 2. Scope  has defined a set of general system requirements to support Emergency Telecommunications Service (ETS). This document defines an additional set of system requirements to achieve support for ETS within the specific context of IP telephony (note that this document views IP telephony within the context of an end-to-end application layer service). Solutions to requirements are not defined. The document does not specify protocol enhancements or specifications. Note that , Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP), is an RFC that shares some overlap with this document. However,  only applies to SIP and is not meant to be applied to a more general perspective of IP telephony as it relates to ETS. 2.1 Out of Scope An item that is not in scope of this document is mandating acceptance and support of the requirements presented in this document. The IETF does not mandate requirements or capabilities to independent networks that comprise the Internet. As an example, Internet Service Providers (ISP) may choose not to operate any telephony-related gateways or services. The IETF cannot and does not mandate that an ISP deploy either telephony-related gateways or telephony-related services. There is an expectation that business contracts, for Carlberg & Atkinson Expires May 28, 2004 [Page 2] ^L Internet Draft ETS Telephony Requirements November 28, 2003 example Service Level Agreements (SLA), will be used to satisfy those following requirements that apply to service providers. Absence of an SLA implies best effort service is provided. It is assumed that some ISPs will choose to offer ETS services and that other carriers will choose not to offer ETS services. These requirements do not apply to ISPs that have chosen not to offer ETS services. 3. IP Telephony Requirements The requirements in this section relate only to Telephony Signaling as used in Internet-based telephony services. They are an extension to the general requirements specified in . The following requirements explicitly do not relate to IP-layer mechanisms, such as Differentiated Services or Integrated Services. 1) Telephony signaling applications used with Internet-based telephony MUST be able to carry labels. 2) The ability to carry labels MUST be extensible to support various types and numbers of labels. A single binary value will not be sufficient given the various labeling standards in existence today. 3) Telephony signaling labels SHOULD have a mapping with the various emergency related labels/markings used in other telephony based networks, such as the Public Switched Telephone Network (PSTN). This ensures that a telephone call placed over a hybrid infrastructure (traditional PSTN over some portion(s) of the path, Internet telephony over some other portion(s) of the path) can carry the labels end-to-end with appropriate translation at PSTN/Internet boundaries. Absence of a mapping means that the signaling reverts to a default service (presumably one attributed to the general public). 4) Application layer IP telephony capabilities MUST NOT preclude the ability to do application layer accounting. Accounting is a useful feature in support of billing and tracking down abuse of service. If specific solutions or protocols in support of ETS require accounting, then this will be articulated in future document(s). 5) Application layer mechanisms in gateways and stateful proxies that are specifically in place to recognize ETS type labels MUST be able to support "best available" service (this will probably be realized as better than best effort). These labels MAY exist in Carlberg & Atkinson Expires May 28, 2004 [Page 3] ^L Internet Draft ETS Telephony Requirements November 28, 2003 the application layer headers of data (i.e., bearer) traffic or signaling traffic used for call completion. The support for best available service SHOULD focus on probability of forwarding packets. Probability MAY reach 100% depending on the local policy associated with the label. Local policy MUST also be used to determine if better than best effort is to be applied to a specific label (or related set of labels). Additional comments on this topic are presented below in item 2 of section 4. The above paragraphs MUST be taken in their entirety. The ability to support best available service does not mean that the application layer mechanism is expected to be activated. Further, we do not define the means by which best available service is realized. Application layer mechanisms that do not recognize ETS type labels are not subject to this requirement. 4. Issues This section presents issues that arise in considering solutions for the telephony requirements that have been defined for ETS. This section does not specify solutions nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues. 1) Alternate paths Experience with The Government Emergency Telecommunications Service (GETS) over the PSTN has shown the utility of alternate paths to a destination to help facilitate emergency-related communications. From the perspective of the Internet, this utility may be difficult to achieve and have a more limited benefit. Unlike the PSTN, which creates a fixed path during call setup phase, the Internet uses dynamic routing for IP packets. This dynamic routing capability automatically causes IP packets to travel the best current path. The Internet network infrastructure does not have the concept of a "call" or the concept of "call setup", though IP telephony applications might have application layer awareness of calls or the call setup concept. 2) Application of Best Available Service In item 5 of section 3 above, we discuss the requirement of supporting best available service. We note that in this Carlberg & Atkinson Expires May 28, 2004 [Page 4] ^L Internet Draft ETS Telephony Requirements November 28, 2003 document, the scope of that support is constrained to the application layer and flows that traverse that layer. This may involve direct support for the flow containing the ETS type label, or may involve indirect support (e.g., ETS labels in signaling messages that causes an effect on corresponding data or bearer flows). It is critical to understand that how the support for best available service can be realized is outside the scope of this document. In addition, the perceived effectiveness of a given approach or implementation also outside the scope of this document. 5. Security Only authorized users or operators SHOULD be able to create non- ordinary Labels (i.e., labels that may alter the default best effort service. Labels SHOULD be associated with mechanisms to provide strong end-to-end integrity during their transmission through the telephony systems. Finally, in cases where labels are expected to be acted upon by operators, these operators SHOULD have the capability of authenticating the label on a received message or transmission in order to prevent theft of service and reduce risk of denial of service (e.g. by unauthorized users consuming any limited resources). Security is also discussed in the general requirements of , which applies to section 3 above. Normative References There are no Normative References because this is an Informational document. Informative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Carlberg, K., Atkinson, R., "General System Requirements for Emergency Telecommunications Service", Internet Draft, Work In Progress, September, 2002 3 Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February, 2003. Carlberg & Atkinson Expires May 28, 2004 [Page 5] ^L Internet Draft ETS Telephony Requirements November 28, 2003 4 ANSI, "Signaling System No. 7(SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993. 5 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Author's Addresses Ken Carlberg Ran Atkinson University College London Extreme Networks Department of Computer Science 3585 Monroe Street Gower Street Santa Clara, CA London, WC1E 6BT 95051 USA United Kingdom firstname.lastname@example.org email@example.com Full Copyright Statement Copyright (C) The Internet Society (2003). 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 may 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 in which case the procedures for copyrights defined in the 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. Carlberg & Atkinson Expires May 28, 2004 [Page 6]