< draft-carlberg-ets-telephony-00.txt   draft-carlberg-ets-telephony-01.txt >
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT UCL INTERNET DRAFT UCL
September, 2002 Ran Atkinson December, 2002 Ran Atkinson
Extreme Networks Extreme Networks
IP Telephony Requirements for IP Telephony Requirements for
Emergency Telecommunication Service Emergency Telecommunication Service
<draft-carlberg-ets-telephony-00.txt> <draft-carlberg-ets-telephony-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 4 skipping to change at page 2, line 4
1. Introduction 1. Introduction
Effective telecommunications capabilities can be imperative to Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events, facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks. such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless PDAs. The access via online terminals, IP telephones, and wireless PDAs. The
^L
commercial telecommunications infrastructure is rapidly evolving to commercial telecommunications infrastructure is rapidly evolving to
Internet-based technology. Therefore, the Internet community needs to Internet-based technology. Therefore, the Internet community needs to
consider how it can best support emergency management and recovery consider how it can best support emergency management and recovery
operations. operations.
1.1 Problem 1.1 Problem
Standards have been developed by other standards bodies concerning Standards have been developed by other standards bodies concerning
emergency communications. As discussed in [2] and [3], some of these emergency communications. As discussed in [2] and [3], some of these
standards, such as T1.693 [4], define specific indicators or labels standards, such as T1.631 [4], define specific indicators or labels
for emergency communications in SS7 networks. Certain requirements for emergency communications in SS7 networks. Certain requirements
must be defined in order to achieve peering services across hybrid must be defined in order to achieve peering services across hybrid
networks (networks that communicate between IP and other types of networks (networks that communicate between IP and other types of
networks such as that realized by the Public Switched Telephone networks such as that realized by the Public Switched Telephone
Network). Network).
2. Scope 2. Scope
[2] has defined a set of general system requirements to support [2] has defined a set of general system requirements to support
Emergency Telecommunications Service (ETS). This document defines an Emergency Telecommunications Service (ETS). This document defines an
additional set of system requirements to achieve support for ETS additional set of system requirements to achieve support for ETS
within the specific context of IP telephony. Solutions to within the specific context of IP telephony (note that this document
requirements are not defined. The document does not specify protocol views IP telephony within the context of an end-to-end application
enhancements or specifications. layer service). Solutions to requirements are not defined. The
document does not specify protocol enhancements or specifications.
2.1 Out of Scope 2.1 Out of Scope
An item that is not in scope of this document is mandating acceptance An item that is not in scope of this document is mandating acceptance
and support of the requirements presented in this document. The IETF and support of the requirements presented in this document. The IETF
does not mandate requirements or capabilities to independent networks does not mandate requirements or capabilities to independent networks
that comprise the Internet. As an example, IP Carriers might choose that comprise the Internet. As an example, Internet Service
not to operate any telephony-related gateways or services. The IETF Providers (ISP) may choose not to operate any telephony-related
cannot and does not mandate that an IP Carrier deploy either gateways or services. The IETF cannot and does not mandate that an
telephony-related gateways or telephony-related services. There is ISP deploy either telephony-related gateways or telephony-related
an expectation that business contracts, for example Service Level services. There is an expectation that business contracts, for
Agreements (SLA), will be used to satisfy those following example Service Level Agreements (SLA), will be used to satisfy those
requirements that apply to service providers. Absence of an SLA following requirements that apply to service providers. Absence of
implies best effort service is provided. an SLA implies best effort service is provided.
It is assumed that some carriers will choose to offer ETS services It is assumed that some ISPs will choose to offer ETS services and
and that other carriers will choose not to offer ETS services. These that other carriers will choose not to offer ETS services. These
requirements do not apply to carriers that have chosen not to offer requirements do not apply to ISPs that have chosen not to offer ETS
ETS services. services.
3. IP Telephony Requirements 3. IP Telephony Requirements
The requirements in this section relate only to Telephony Signalling The requirements in this section relate only to Telephony Signalling
(e.g. SS7, DSS1, SIP) as used in Internet-based telephony services.
They are an extension to the general requirements specified in [2]. ^L
The following requirements explicitly do not relate to IP-layer as used in Internet-based telephony services. They are an extension
mechanisms, such as Differentiated Services or Integrated Services. 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 signalling applications used with Internet-based 1) Telephony signalling applications used with Internet-based
telephony MUST be able to carry labels. telephony MUST be able to carry labels.
2) The ability to carry labels MUST be extensible to support 2) The ability to carry labels MUST be extensible to support
various types and numbers of labels. A single binary value will various types and numbers of labels. A single binary value will
not be sufficient given the various labeling standards in existance not be sufficient given the various labeling standards in existance
today. today.
3) Telephony signalling labels MUST have a mapping with the various 3) Telephony signalling labels SHOULD have a mapping with the
labels/markings used in other telephony based networks. This various emergency related labels/markings used in other telephony
includes existing labels defined for the PSTN. This ensures that based networks, such as the PSTN. This ensures that a telephone
a telephone call that is placed over a hybrid infrastructure call placed over a hybrid infrastructure (traditional PSTN over
(traditional PSTN over some portion(s) of the path, Internet some portion(s) of the path, Internet telephony over some other
telephony over some other portion(s) of the path) can carry the portion(s) of the path) can carry the labels end-to-end with
labels end-to-end with appropriate translation at PSTN/Internet appropriate translation at PSTN/Internet boundaries. Absence of
boundaries. a mapping means that the signaling reverts to a default service
(presumably one attributed to the general public).
3.1 Value Added Requirements: 4) Hybrid infrastructures that include and support connectivity
to the PSTN MAY support application layer accounting within IP
telephony applications. These applications MUST NOT preclude
the ability to do accounting.
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 1) Alternate paths
Experience with GETS has shown the utility of alternate paths Experience with GETS over the PSTN has shown the utility of
to a destination to help facilitate emergency-related alternate paths to a destination to help facilitate
communications. From the perspective of the Internet, this emergency-related communications. From the perspective of the
utility may be difficult to achieve and have a more limited Internet, this utility may be difficult to achieve and have a
benefit. Hence, we present this requirement as one that is more limited benefit. Unlike the PSTN, which creates a fixed
value added, but not to considered critical in supporting ETS. path during call setup phase, the Internet uses dynamic routing
Unlike the PSTN, the Internet routing system maintains awareness for IP packets. This dynamic routing capability automatically
of all paths to a destination. Further the Internet is causes IP packets to travel the best current path. The Internet
packet-based, rather than circuit-switched, so existing flows
will automatically be rerouted if an initial route ceases to be
available and an alternate route exists.
4. Security ^L
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.
Alternate path routing at the application layer may be useful
in choosing one of possibly several egress points to the PSTN
from the Internet.
5. Security
Only authorised users or operators SHOULD be able to create non- Only authorised users or operators SHOULD be able to create non-
ordinary labels. Labels SHOULD have mechanisms to provide strong ordinary labels. Labels SHOULD have mechanisms to provide strong
end-to-end integrity during their transmission through the telephony end-to-end integrity during their transmission through the telephony
systems. Finally, in cases where labels are expected to be acted systems. Finally, in cases where labels are expected to be acted
upon by operators, these operators SHOULD have the capability of upon by operators, these operators SHOULD have the capability of
authenticating the label on a received message or transmission in authenticating the label on a received message or transmission in
order to prevent theft of service and reduce risk of denial of order to prevent theft of service and reduce risk of denial of
service (e.g. by unauthorised users consuming any limited resources). service (e.g. by unauthorised users consuming any limited resources).
Security is also discussed in the general requirements of [2], which Security is also discussed in the general requirements of [2], which
applies to section 3 above. applies to section 3 above.
5. References 6. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Carlberg, K., Atkinson, R., "General System Requirements for 2 Carlberg, K., Atkinson, R., "General System Requirements for
Emergency Telecommunications Service", Internet Draft, Emergency Telecommunications Service", Internet Draft,
Work In Progress, September, 2002 Work In Progress, September, 2002
3 Folts, H., et. al., "User Requirements for Emergency 3 Folts, H., et. al., "User Requirements for Emergency
Telecommunications Service", Internet Draft, Work In Telecommunications Service", Internet Draft, Work In
Progress, September 2002 Progress, September 2002
4 ANSI, "Signaling System No. 7(SS7): High Probability of 4 ANSI, "Signaling System No. 7(SS7): High Probability of
Completion (HPC) Network Capability, ANSI T1.631, 1993. Completion (HPC) Network Capability, ANSI T1.631, 1993.
Ken Carlberg Ran Atkinson ^L
University College London Extreme Networks
Department of Computer Science 3585 Monroe Street 7. Author's Addresses
Gower Street Santa Clara, CA
London, WC1E 6BT 95051 USA Ken Carlberg Ran Atkinson
United Kingdom University College London Extreme Networks
k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com 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 Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of
ing Internet standards in which case the procedures for copyrights developing Internet standards in which case the procedures for
defined in the Internet Standards process must be followed, or as copyrights defined in the Internet Standards process must be
required to translate it into languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR
CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
 End of changes. 17 change blocks. 
55 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/