Request for Comments: 4190 G11
Category: Informational I. Brown
UCL
C. Beard
UMKC
November 2005
Framework for Supporting
Emergency Telecommunications Service (ETS) in IP Telephony
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 (2005).
Abstract
This document presents a framework for supporting authorized,
emergency-related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today’s
IP architecture and service models. From these objectives, we
present a corresponding set of protocols and capabilities, which
provide a more specific set of recommendations regarding existing
IETF protocols. Finally, we present two scenarios that act as
guiding models for the objectives and functions listed in this
document. These models, coupled with an example of an existing
service in the Public Switched Telephone Network (PSTN), contribute
to a constrained solution space.
Table of Contents
1. Introduction ....................................................2
1.1. Emergency Related Data .....................................4
1.1.1. Government Emergency Telecommunications
Service (GETS) ......................................4
1.1.2. International Emergency Preparedness Scheme (IEPS) ..5
1.2. Scope of This Document .....................................5
2. Objective .......................................................7
3. Considerations ..................................................7
4. Protocols and Capabilities ......................................7
4.1. Signaling and State Information ............................8
4.1.1. SIP .................................................8
4.1.2. Diff-Serv ...........................................8
4.1.3. Variations Related to Diff-Serv and Queuing .........9
4.1.4. RTP ................................................10
4.1.5. GCP/H.248 ..........................................11
4.2. Policy ....................................................12
4.3. Traffic Engineering .......................................12
4.4. Security ..................................................13
4.4.1. Denial of Service ..................................13
4.4.2. User Authorization .................................14
4.4.3. Confidentiality and Integrity ......................15
4.5. Alternate Path Routing ....................................16
4.6. End-to-End Fault Tolerance ................................17
5. Key Scenarios ..................................................18
5.1. Single IP Administrative Domain ...........................18
5.2. Multiple IP Administrative Domains ........................19
6. Security Considerations ........................................20
7. Informative References .........................................20
Appendix A: Government Telephone Preference Scheme (GTPS) .........24
A.1. GTPS and the Framework Document ..........................24
Appendix B: Related Standards Work ................................24
B.1. Study Group 16 (ITU) .....................................25
Acknowledgements ..................................................26
1. Introduction
The Internet has become the primary target for worldwide
communications in terms of recreation, business, and various
imaginative reasons for information distribution. A constant fixture
in the evolution of the Internet has been the support of Best Effort
as the default service model. Best Effort, in general terms, implies
that the network will attempt to forward traffic to the destination
as best as it can, with no guarantees being made, nor any resources
reserved, to support specific measures of Quality of Service (QoS).
An underlying goal is to be "fair" to all the traffic in terms of the
resources used to forward it to the destination.
In an attempt to go beyond best effort service, [1] presented an
overview of Integrated Services (int-serv) and its inclusion into the
Internet architecture. This was followed by [2], which specified the
RSVP signaling protocol used to convey QoS requirements. With the
addition of [3] and [4], specifying controlled load (bandwidth
bounds) and guaranteed service (bandwidth & delay bounds),
respectively, a design existed to achieve specific measures of QoS
for an end-to-end flow of traffic traversing an IP network. In this
case, our reference to a flow is one that is granular in definition
and applies to specific application sessions.
From a deployment perspective (as of the date of this document),
int-serv has been predominantly constrained to intra-domain paths, at
best resembling isolated "island" reservations for specific types of
traffic (e.g., audio and video) by stub domains. [5] and [6] will
probably contribute to additional deployment of int-serv to Internet
Service Providers (ISP) and possibly some inter-domain paths, but it
seems unlikely that the original vision of end-to-end int-serv
between hosts in source and destination stub domains will become a
reality in the near future (the mid- to far-term is a subject for
others to contemplate).
In 1998, the IETF produced [7], which presented an architecture for
Differentiated Services (diff-serv). This effort focused on a more
aggregated perspective and classification of packets than that of
[1]. This is accomplished with the recent specification of the
diff-serv field in the IP header (in the case of IPv4, it replaced
the old ToS field). This new field is used for code points
established by IANA, or set aside as experimental. It can be
expected that sets of microflows, a granular identification of a set
of packets, will correspond to a given code point, thereby achieving
an aggregated treatment of data.
One constant in the introduction of new service models has been the
designation of Best Effort as the default service model. If traffic
is not, or cannot be, associated as diff-serv or int-serv, then it is
treated as Best Effort and uses what resources are made available to
it.
Beyond the introduction of new services, the continued pace of
additional traffic load experienced by ISPs over the years has
continued to place a high importance on intra-domain traffic
engineering. The explosion of IETF contributions, in the form of
drafts and RFCs produced in the area of Multi-Protocol Label
Switching (MPLS), exemplifies the interest in versatile and
manageable mechanisms for intra-domain traffic engineering. One
interesting observation is the work involved in supporting QoS
related traffic engineering. Specifically, we refer to MPLS support
of differentiated services [8], and the ongoing work in the inclusion
of fast bandwidth recovery of routing failures for MPLS [9].
1.1. Emergency Related Data
The evolution of the IP service model architecture has traditionally
centered on the type of application protocols used over a network.
By this we mean that the distinction, and possible bounds on QoS,
usually centers on the type of application (e.g., audio video tools)
that is being referred to.
[10] has defined a priority field for SMTP, but it is only for
mapping with X.400 and is not meant for general usage. SIP [11] has
an embedded field denoting "priority", but it is only targeted toward
the end-user and is not meant to provide an indication to the
underlying network or end-to-end applications.
Given the emergence of IP telephony, a natural inclusion of its
service is an ability to support existing emergency related services.
Typically, one associates emergency calls with "911" telephone
service in the U.S., or "999" in the U.K. -- both of which are
attributed to national boundaries and accessible by the general
public. Outside of this there exist emergency telephone services
that involve authorized usage, as described in the following
subsection.
1.1.1. Government Emergency Telecommunications Service (GETS)
GETS is an emergency telecommunications service available in the U.S.
and is overseen by the National Communications System (NCS) -- an
office established by the White House under an executive order [27]
and now a part of the Department of Homeland Security. Unlike "911",
it is only accessible by authorized individuals. The majority of
these individuals are from various government agencies like the
Department of Transportation, NASA, the Department of Defense, and
the Federal Emergency Management Agency (to name a few). In
addition, a select set of individuals from private industry
(telecommunications companies, utilities, etc.) that are involved in
critical infrastructure recovery operations are also provided access
to GETS.
The purpose of GETS is to achieve a high probability that phone
service will be available to selected authorized personnel in times
of emergencies, such as hurricanes, earthquakes, and other disasters,
that may produce a burden in the form of call blocking (i.e.,
congestion) on the U.S. Public Switched Telephone Network by the
general public.
GETS is based in part on the ANSI T1.631 standard, specifying a High
Probability of Completion (HPC) for SS7 signaling [12][24].
1.1.2. International Emergency Preparedness Scheme (IEPS)
[25] is a recent ITU standard that describes emergency-related
communications over the international telephone service. While
systems like GETS are national in scope, IEPS acts as an extension to
local or national authorized emergency call establishment and
provides a building block for a global service.
As in the case of GETS, IEPS promotes mechanisms like extended
queuing, alternate routing, and exemption from restrictive management
controls in order to increase the probability that international
emergency calls will be established. The specifics of how this is to
be accomplished are to be defined in future ITU document(s).
1.2. Scope of This Document
The scope of this document centers on the near and mid-term support
of ETS within the context of IP telephony versus Voice over IP. We
make a distinction between these two by treating IP telephony as a
subset of VoIP, where in the former case, we assume that some form of
application layer signaling is used to explicitly establish and
maintain voice data traffic. This explicit signaling capability
provides the hooks from which VoIP traffic can be bridged to the
PSTN.
An example of this distinction is when the Robust Audio Tool (RAT)
[13] begins sending VoIP packets to a unicast (or multicast)
destination. RAT does not use explicit signaling like SIP to
establish an end-to-end call between two users. It simply sends data
packets to the target destination. On the other hand, "SIP phones"
are host devices that use a signaling protocol to establish a call
before sending data towards the destination.
One other aspect we should probably assume exists with IP Telephony
is an association of a target level of QoS per session or flow. [28]
makes an argument that there is a maximum packet loss and delay for
VoIP traffic, and that both are interdependent. For delays of
~200ms, a corresponding drop rate of 5% is deemed acceptable. When
delay is lower, a 15-20% drop rate can be experienced and still be
considered acceptable. [29] discusses the same topic and makes an
argument that packet size plays a significant role in what users
tolerate as "intelligible" VoIP. The larger the packet, correlating
to a longer sampling rate, the lower the acceptable rate of loss.
Note that [28, 29] provide only two of several perspectives in
examining VoIP. A more in-depth discussion on this topic is outside
the scope of this document, though it should be noted that the choice
of codec can significantly alter the above results.
Regardless of a single and definitive characteristic for stressed
conditions, it would seem that interactive voice has a lower
threshold of some combinations of loss/delay/jitter than elastic
applications such as email or web browsers. This places a higher
burden on the problem of supporting VoIP over the Internet. This
problem is further compounded when toll-quality service is expected
because it assumes a default service model that is better than best
effort. This, in turn, can increase the probability that a form of
call-blocking can occur with VoIP or IP telephony traffic.
Beyond this, part of our motivation in writing this document is to
provide a framework for ISPs and telephony carriers to understand the
objectives used to support ETS-related IP telephony traffic. In
addition, we also wish to provide a reference point for potential
customers in order to constrain their expectations. In particular,
we wish to avoid any temptation of trying to replicate the exact
capabilities of existing emergency voice service that are currently
available in the PSTN to that of IP and the Internet. If nothing
else, intrinsic differences between the two communications
architectures precludes this from happening. Note, this does not
prevent us from borrowing design concepts or objectives from existing
systems.
Section 2 presents several primary objectives that articulate what is
considered important in supporting ETS-related IP telephony traffic.
These objectives represent a generic set of goals and desired
capabilities. Section 3 presents additional value-added objectives,
which are viewed as useful, but not critical. Section 4 presents
protocols and capabilities that relate or can play a role in support
of the objectives articulated in Section 2. Finally, Section 5
presents two scenarios that currently exist or are being deployed in
the near term over IP networks. These are not all-inclusive
scenarios, nor are they the only ones that can be articulated ([34]
provides a more extensive discussion on the topology scenarios
related to IP telephony). However, these scenarios do show cases
where some of the protocols discussed in Section 4 apply, and where
some do not.
Finally, we need to state that this document focuses its attention on
the IP layer and above. Specific operational procedures pertaining
to Network Operation Centers (NOC) or Network Information Centers
(NIC) are outside the scope of this document. This includes the
"bits" below IP, other specific technologies, and service-level
agreements between ISPs and telephony carriers with regard to
dedicated links.
2. Objective
The objective of this document is to present a framework that
describes how various protocols and capabilities (or mechanisms) can
facilitate and support the traffic from ETS users. In several cases,
we provide a bit of background in each area so that the reader is
given some context and a more in-depth understanding. We also
provide some discussion on aspects about a given protocol or
capability that could be explored and potentially advanced to support
ETS. This exploration is not to be confused with specific solutions
since we do not articulate exactly what must be done (e.g., a new
header field, or a new code point).
3. Considerations
When producing a solution, or examining existing protocols and
mechanisms, there are some things that should be considered. One is
that inter-domain ETS communications should not rely on ubiquitous or
even widespread support along the path between the end points.
Potentially, at the network layer there may exist islands of support
realized in the form of overlay networks. There may also be cases
where solutions may be constrained on an end-to-end basis (i.e., at
the transport or application layer). It is this diversity and
possibly partial support that needs to be taken into account by those
designing and deploying ETS-related solutions.
Another aspect to consider is that there are existing architectures
and protocols from other standards bodies that support emergency-
related communications. The effort in interoperating with these
systems, presumably through gateways or similar types of nodes with
IETF protocols, would foster a need to distinguish ETS flows from
other flows. One reason would be the scenario of triggering ETS
service from an IP network.
Finally, we take into consideration the requirements of [35, 36] in
discussing the protocols and mechanisms below in Section 4. In doing
this, we do not make a one-to-one mapping of protocol discussion a
requirement. Rather, we make sure the discussion of Section 4 does
not violate any of the requirements in [35, 36].
4. Protocols and Capabilities
In this section, we take the objectives presented above and present a
set of protocols and capabilities that can be used to achieve them.
Given that the objectives are predominantly atomic in nature, the
measures used to address them are to be viewed separately with no
specific dependency upon each other as a whole. Various protocols
and capabilities may be complimentary to each other, but there is no
need for all to exist, given different scenarios of operation; and
ETS support is not expected to be an ubiquitously available service.
We divide this section into 5 areas:
1) Signaling
2) Policy
3) Traffic Engineering
4) Security
5) Routing
4.1. Signaling and State Information
Signaling is used to convey various information to either
intermediate nodes or end nodes. It can be out-of-band of a data
flow, and thus in a separate flow of its own, such as SIP messages.
It can be in-band and part of the state information in a datagram
containing the voice data. This latter example could be realized in
the form of diff-serv code points in the IP packet.
In the following subsections, we discuss the current state of some
protocols and their use in providing support for ETS. We also
discuss potential augmentations to different types of signaling and
state information to help support the distinction of emergency-
related communications in general.
4.1.1. SIP
With respect to application-level signaling for IP telephony, we
focus our attention on the Session Initiation Protocol (SIP).
Currently, SIP has an existing "priority" field in the Request-
Header-Field that distinguishes different types of sessions. The
five values currently defined are: "emergency", "urgent", "normal",
"non-urgent", "other-priority". These values are meant to convey
importance to the end-user and have no additional semantics
associated with them.
[14] is an RFC that defines the requirements for a new header field
for SIP in reference to resource priority. The requirements are
meant to lead to a means of providing an additional measure of
distinction that can influence the behavior of gateways and SIP
proxies.
4.1.2. Diff-Serv
In accordance with [15], the differentiated services code point
(DSCP) field is divided into three sets of values. The first set is
assigned by IANA. Within this set, there are currently, three types
of Per Hop Behaviors that have been specified: Default (correlating
to best effort forwarding), Assured Forwarding, and Expedited
Forwarding. The second set of DSCP values are set aside for local or
experimental use. The third set of DSCP values are also set aside
for local or experimental use, but may later be reassigned to IANA if
the first set has been completely assigned.
One approach discussed on the IEPREP mailing list is the
specification of a new Per-Hop Behaviour (PHB) for emergency-related
flows. The rationale behind this idea is that it would provide a
baseline by which specific code points may be defined for various
emergency-related traffic: authorized emergency sessions (e.g., ETS),
general public emergency calls (e.g., "911"), Multi-Level Precedence
and Preemption (MLPP) [19], etc. However, in order to define a new
set of code points, a forwarding characteristic must also be defined.
In other words, one cannot simply identify a set of bits without
defining their intended meaning (e.g., the drop precedence approach
of Assured Forwarding). The one caveat to this statement are the set
of DSCP bits set aside for experimental purposes. But as the name
implies, experimental is for internal examination and use and not for
standardization.
Note:
It is important to note that at the time this document was
written, the IETF had been taking a conservative approach in
specifying new PHBs. This is because the number of code points
that can be defined is relatively small and is understandably
considered a scarce resource. Therefore, the possibility of a
new PHB being defined for emergency-related traffic is, at
best, a long term project that may or may not be accepted by
the IETF.
In the near term, we would initially suggest using the Assured
Forwarding (AF) PHB [18] for distinguishing emergency traffic
from other types of flows. At a minimum, AF could be used for
the different SIP call signaling messages. If the Expedited
Forwarding (EF) PHB [40] was also supported by the domain, then
it would be used for IP telephony data packets. Otherwise,
another AF class would be used for those data flows.
4.1.3. Variations Related to Diff-Serv and Queuing
Scheduling mechanisms like Weighted Fair Queueing and Class Based
Queueing are used to designate a percentage of the output link
bandwidth that would be used for each class if all queues were
backlogged. Its purpose, therefore, is to manage the rates and
delays experienced by each class. But emergency traffic may not
necessarily require QoS perform any better or differently than non-
emergency traffic. It may just need higher probability of being
forwarded to the next hop, which could be accomplished simply by
dropping precedences within a class.
To implement preferential dropping between classes of traffic, one of
which is emergency traffic, one would probably need to use a more
advanced form of Active Queue Management (AQM). Current
implementations use an overall queue fill measurement to make
decisions; this might cause emergency classified packets to be
dropped. One new form of AQM could be a Multiple Average-Multiple
Threshold approach, instead of the Single Average-Multiple Threshold
approach used today. This allows creation of drop probabilities
based on counting the number of packets in the queue for each drop
precedence individually.
So, it could be possible to use the current set of AF PHBs if each
class were reasonably homogenous in the traffic mix. But one might
still have a need to differentiate three drop precedences within
non-emergency traffic. If so, more drop precedences could be
implemented. Also, if one wanted discrimination within emergency
traffic, as with MLPP’s five levels of precedence, more drop
precedences might also be considered. The five levels would also
correlate to a recent effort in Study Group 11 of the ITU to define 5
levels for Emergency Telecommunications Service.