GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3690

Network Working Group K. Carlberg Request for Comments: 3690 UCL Category: Informational R. Atkinson

                                                      Extreme Networks
                                                         February 2004
                   IP Telephony Requirements for
             Emergency 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 in RFC 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 2004

1.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 2004

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 [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 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 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 to section 3 above.

6. References

6.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", BCP
      9, 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 2004

7. 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.com

Carlberg & Atkinson Informational [Page 6] RFC 3690 ETS Telephony Requirements February 2004

8. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3690.txt · Last modified: 2004/02/02 23:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki