Movatterモバイル変換

Network Working Group                                        K. CarlbergRequest for Comments: 3690                                           UCLCategory: Informational                                      R. Atkinson                                                        Extreme Networks                                                           February 2004IP Telephony Requirements forEmergency Telecommunication Service (ETS)Status of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2004).  All Rights Reserved.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 inRFC 3689.   Solutions to these requirements are not presented in this document.1.  Introduction   Effective telecommunications capabilities can be imperative to   facilitate immediate recovery operations for serious disaster events,   such as, hurricanes, floods, earthquakes, and terrorist attacks.   Disasters can happen unexpectedly, at any time or place.  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.   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].Carlberg & Atkinson          Informational                      [Page 1]

RFC 3690               ETS Telephony Requirements          February 20041.1.  Problem   Standards have been developed by other standards bodies concerning   emergency communications.  As discussed in [3], some of these   standards, such as T1.631 [5], 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   [3] 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 [4], Requirements for Resource Priority Mechanisms for the   Session Initiation Protocol (SIP), is an RFC that shares some overlap   with this document.  However, [4] 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   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.Carlberg & Atkinson          Informational                      [Page 2]

RFC 3690               ETS Telephony Requirements          February 20043.  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 [3].  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      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).Carlberg & Atkinson          Informational                      [Page 3]

RFC 3690               ETS Telephony Requirements          February 2004      Additional comments on this topic are presented below in item 2 ofsection 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 ofsection 3 above, we discuss the requirement of      supporting best available service.  We note that in this 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      cause an effect on corresponding data or bearer flows).Carlberg & Atkinson          Informational                      [Page 4]

RFC 3690               ETS Telephony Requirements          February 2004      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 is 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 [3], which   applies tosection 3 above.6.  References6.1.  Normative Reference   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.6.2.  Informative References   [2]  Bradner, S., "The Internet Standards Process -- Revision 3",BCP9,RFC 2026, October 1996.   [3]  Carlberg, K. and R. Atkinson, "General System Requirements for        Emergency Telecommunications Service",RFC 3689, February 2004.   [4]  Schulzrinne, H., "Requirements for Resource Priority Mechanisms        for the Session Initiation Protocol (SIP)",RFC 3487, February        2003.   [5]  ANSI, "Signaling System No. 7(SS7): High Probability of        Completion (HPC) Network Capability", ANSI T1.631, 1993.Carlberg & Atkinson          Informational                      [Page 5]

RFC 3690               ETS Telephony Requirements          February 20047.  Authors' Addresses   Ken Carlberg   University College London   Department of Computer Science   Gower Street   London, WC1E 6BT   United Kingdom   EMail: k.carlberg@cs.ucl.ac.uk   Ran Atkinson   Extreme Networks   3585 Monroe Street   Santa Clara, CA   95051  USA   EMail: rja@extremenetworks.comCarlberg & Atkinson          Informational                      [Page 6]

RFC 3690               ETS Telephony Requirements          February 20048.  Full Copyright Statement   Copyright (C) The Internet Society (2004).  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 assignees.   This document and the information contained herein is provided on 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 OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Carlberg & Atkinson          Informational                      [Page 7]