[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 3690

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 [1].

   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 [2].
   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 [5].


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 [2], some of these
   standards, such as T1.631 [4], 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

   [2] 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 [3], Requirements for Resource Priority Mechanisms for the
   Session Initiation Protocol (SIP), is an RFC that shares some overlap
   with this document.  However, [3] 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 [2].  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 [2], 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
k.carlberg@cs.ucl.ac.uk                 rja@extremenetworks.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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/