Request for Comments: 4542 J. Polk
Category: Informational Cisco Systems
May 2006
Implementing an Emergency Telecommunications Service (ETS) for
Real-Time Services in the Internet Protocol Suite
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 (2006).
Abstract
RFCs 3689 and 3690 detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency
Preparedness Service (IEPS) would be a part. Some of these types of
services require call preemption; others require call queuing or
other mechanisms. IEPS requires a Call Admission Control (CAC)
procedure and a Per Hop Behavior (PHB) for the data that meet the
needs of this architecture. Such a CAC procedure and PHB is
appropriate to any service that might use H.323 or SIP to set up
real-time sessions. The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of
crisis.
This document primarily discusses supporting ETS in the context of
the US Government and NATO, because it focuses on the Multi-Level
Precedence and Preemption (MLPP) and Government Emergency
Telecommunication Service (GETS) standards. The architectures
described here are applicable beyond these organizations.
Table of Contents
1. Overview of the Internet Emergency Preference Service
Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunications Service .....6
1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network ..............................7
1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment .........9
1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2.1. Call Admission/Preemption Procedure .......................12
2.2. Voice Handling Characteristics ............................15
2.3. Bandwidth Admission Procedure .............................17
2.3.1. RSVP Admission Using Policy for Both
Unicast and Multicast Sessions .....................17
2.3.2. RSVP Scaling Issues ................................19
2.3.3. RSVP Operation in Backbones and Virtual
Private Networks (VPNs) ............................19
2.3.4. Interaction with the Differentiated
Services Architecture ..............................21
2.3.5. Admission Policy ...................................21
2.4. Authentication and Authorization of Calls Placed ..........23
2.5. Defined User Interface ....................................23
3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
5. References .....................................................25
5.1. Normative References ......................................25
5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................29
1. Overview of the Internet Emergency Preference Service Problem and
Proposed Solutions
[RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency
Preference Service (IEPS) would be a part. Some of these types of
services require call preemption; others require call queuing or
other mechanisms. The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of
crisis.
IEPS requires a Call Admission Control procedure and a Per Hop
Behavior for the data that meet the needs of this architecture. Such
a CAC procedure and PHB is appropriate to any service that might use
H.323 or SIP to set up real-time sessions. These obviously include
but are not limited to Voice and Video applications, although at this
writing the community is mostly thinking about Voice on IP, and many
of the examples in the document are taken from that environment.
In a network where a call permitted initially is not denied or
rejected at a later time, capacity admission procedures performed
only at the time of call setup may be sufficient. However, in a
network where session status can be reviewed by the network and
preempted or denied due to changes in routing (when the new routes
lack capacity to carry calls switched to them) or changes in offered
load (where higher precedence calls supersede existing calls),
maintaining a continuing model of the status of the various calls is
required.
1.1. Emergency Telecommunications Services
Before doing so, however, let us discuss the problem that ETS (and
therefore IEPS) is intended to solve and the architecture of the
system. The Emergency Telecommunications Service [ITU.ETS.E106] is a
successor to and generalization of two services used in the United
States: Multi-Level Precedence and Preemption (MLPP), and the
Government Emergency Telecommunication Service (GETS). Services
based on these models are also used in a variety of countries
throughout the world, both Public Switched Telephone Network (PSTN)
and Global System for Mobile Communications (GSM)-based. Both of
these services are designed to enable an authorized user to obtain
service from the telephone network in times of crisis. They differ
primarily in the mechanisms used and number of levels of precedence
acknowledged.
1.1.1. Multi-Level Preemption and Precedence
The Assured Service is designed as an IP implementation of an
existing ITU-T/NATO/DoD telephone system architecture known as
Multi-Level Precedence and Preemption [ITU.MLPP.1990]
[ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP. MLPP is an architecture
for a prioritized call handling service such that in times of
emergency in the relevant NATO and DoD commands, the relative
importance of various kinds of communications is strictly defined,
allowing higher-precedence communication at the expense of lower-
precedence communications. This document describes NATO and US
Department of Defense uses of MLPP, but the architecture and standard
are applicable outside of these organizations.
These precedences, in descending order, are:
Flash Override Override: used by the Commander in Chief, Secretary
of Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other
national authorities that the President may authorize in
conjunction with Worldwide Secure Voice Conferencing System
conferences. Flash Override Override cannot be preempted. This
precedence level is not enabled on all DoD networks.
Flash Override: used by the Commander in Chief, Secretary of
Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency and other national authorities the
President may authorize. Flash Override cannot be preempted in
the DSN.
Flash: reserved generally for telephone calls pertaining to command
and control of military forces essential to defense and
retaliation, critical intelligence essential to national survival,
conduct of diplomatic negotiations critical to the arresting or
limiting of hostilities, dissemination of critical civil alert
information essential to national survival, continuity of federal
government functions essential to national survival, fulfillment
of critical internal security functions essential to national
survival, or catastrophic events of national or international
significance.
Immediate: reserved generally for telephone calls pertaining to
situations that gravely affect the security of national and allied
forces, reconstitution of forces in a post-attack period,
intelligence essential to national security, conduct of diplomatic
negotiations to reduce or limit the threat of war, implementation
of federal government actions essential to national survival,
situations that gravely affect the internal security of the
nation, Civil Defense actions, disasters or events of extensive
seriousness having an immediate and detrimental effect on the
welfare of the population, or vital information having an
immediate effect on aircraft, spacecraft, or missile operations.
Priority: reserved generally for telephone calls requiring
expeditious action by called parties and/or furnishing essential
information for the conduct of government operations.
Routine: designation applied to those official government
communications that require rapid transmission by telephonic means
but do not require preferential handling.
MLPP is intended to deliver a higher probability of call completion
to the more important calls. The rule, in MLPP, is that more
important calls override less important calls when congestion occurs
within a network. Station-based preemption is used when a more
important call needs to be placed to either party in an existing
call. Trunk-based preemption is used when trunk bandwidth needs to
be reallocated to facilitate a higher-precedence call over a given
path in the network. In both station- and trunk-based preemption
scenarios, preempted parties are positively notified, via preemption
tone, that their call can no longer be supported. The same
preemption tone is used, regardless of whether calls are terminated
for the purposes of station- of trunk-based preemption. The
remainder of this discussion focuses on trunk-based preemption
issues.
MLPP is built as a proactive system in which callers must assign one
of the precedence levels listed above at call initiation; this
precedence level cannot be changed throughout that call. If an
elevated status is not assigned by a user at call initiation time,
the call is assumed to be "routine". If there is end-to-end capacity
to place a call, any call may be placed at any time. However, when
any trunk group (in the circuit world) or interface (in an IP world)
reaches a utilization threshold, a choice must be made as to which
calls to accept or allow to continue. The system will seize the
trunk(s) or bandwidth necessary to place the more important calls in
preference to less important calls by preempting an existing call (or
calls) of lower precedence to permit a higher-precedence call to be
placed.
More than one call might properly be preempted if more trunks or
bandwidth is necessary for this higher precedence call. A video call
(perhaps of 384 KBPS, or 6 trunks) competing with several lower-
precedence voice calls is a good example of this situation.
1.1.2. Government Emergency Telecommunications Service
A US service similar to MLPP and using MLPP signaling technology, but
built for use in civilian networks, is the Government Emergency
Telecommunications Service (GETS). This differs from MLPP in two
ways: it does not use preemption, but rather reserves bandwidth or
queues calls to obtain a high probability of call completion, and it
has only two levels of service: "Routine" and "Priority".
GETS is described here as another example. Similar architectures are
applied by other governments and organizations.
1.2. Definition of Call Admission
Traditionally, in the PSTN, Call Admission Control (CAC) has had the
responsibility of implementing bandwidth available thresholds (e.g.,
to limit resources consumed by some traffic) and determining whether
a caller has permission (e.g., is an identified subscriber, with
identify attested to by appropriate credentials) to use an available
circuit. IEPS, or any emergency telephone service, has additional
options that it may employ to improve the probability of call
completion:
o The call may be authorized to use other networks that it would not
normally use;
o The network may preempt other calls to free bandwidth;
o The network may hold the call and place it when other calls
complete; or
o The network may use different bandwidth availability thresholds
than are used for other calls.
At the completion of CAC, however, the caller either has a circuit
that he or she is authorized to use or has no circuit. Since the act
of preemption or consideration of alternative bandwidth sources is
part and parcel of the problem of providing bandwidth, the
authorization step in bandwidth provision also affects the choice of
networks that may be authorized to be considered. The three cannot
be separated. The CAC procedure finds available bandwidth that the
caller is authorized to use and preemption may in some networks be
part of making that happen.
1.3. Assumptions about the Network
IP networks generally fall into two categories: those with
constrained bandwidth, and those that are massively over-provisioned.
In a network where over any interval that can be measured (including
sub-second intervals) capacity exceeds offered load by at least 2:1,
the jitter and loss incurred in transit are nominal. This is
generally a characteristic of properly engineered Ethernet LANs and
of optical networks (networks that measure their link speeds in
multiples of 51 MBPS); in the latter, circuit-switched networking
solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS
can be used to explicitly place routes, which improves the odds a
bit.
Between those networks, in places commonly called "inter-campus
links", "access links", or "access networks", for various reasons
including technology (e.g., satellite links) and cost, it is common
to find links whose offered load can approximate or exceed the
available capacity. Such events may be momentary or may occur for
extended periods of time.
In addition, primarily in tactical deployments, it is common to find
bandwidth constraints in the local infrastructure of networks. For
example, the US Navy’s network afloat connects approximately 300
ships, via satellite, to five network operation centers (NOCs), and
those NOCs are in turn interconnected via the Defense Information
Systems Agency (DISA) backbone. A typical ship may have between two
and six radio systems aboard, often at speeds of 64 KBPS or less. In
US Army networks, current radio technology likewise limits tactical
communications to links below 100 KBPS.
Over this infrastructure, military communications expect to deploy
voice communication systems (30-80 KBPS per session) and video
conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800
KBPS), in addition to traditional mail, file transfer, and
transaction traffic.
1.4. Assumptions about Application Behavior
Parekh and Gallagher published a series of papers [Parekh1] [Parekh2]
analyzing what is necessary to ensure a specified service level for a
stream of traffic. In a nutshell, they showed that to predict the
behavior of a stream of traffic in a network, one must know two
things:
o the rate and arrival distribution with which traffic in a class is
introduced to the network, and
o what network elements will do, in terms of the departure
distribution, injected delay jitter, and loss characteristics,
with the traffic they see.
For example, TCP tunes its effective window (the amount of data it
sends per round trip interval) so that the ratio of the window and
the round trip interval approximate the available capacity in the
network. As long as the round trip delay remains roughly stable and
loss is nominal (which are primarily behaviors of the network), TCP
is able to maintain a predictable level of throughput. In an
environment where loss is random or in which delays wildly vary, TCP
behaves in a far less predictable manner.
Voice and video systems, in the main, are designed to deliver a fixed
level of quality as perceived by the user. (Exceptions are systems
that select rate options over a broad range to adapt to ambient loss
characteristics. These deliver broadly fluctuating perceived quality
and have not found significant commercial applicability.) Rather,
they send traffic at a rate specified by the codec depending on what
it perceives is required. In an MPEG-4 system, for example, if the
camera is pointed at a wall, the codec determines that an 80 KBPS
data stream will describe that wall and issues that amount of
traffic. If a person walks in front of the wall or the camera is
pointed an a moving object, the codec may easily send 800 KBPS in its
effort to accurately describe what it sees. In commercial broadcast
sports, which may line up periods in which advertisements are
displayed, the effect is that traffic rates suddenly jump across all
channels at certain times because the eye-catching ads require much
more bandwidth than the camera pointing at the green football field.
As described in [RFC1633], when dealing with a real-time application,
there are basically two things one must do to ensure Parekh’s first
requirement. To ensure that one knows how much offered load the
application is presenting, one must police (measure load offered and
discard excess) traffic entering the network. If that policing
behavior has a debilitating effect on the application, as non-
negligible loss has on voice or video, one must admit sessions
judiciously according to some policy. A key characteristic of that
policy must be that the offered load does not exceed the capacity
dedicated to the application.
In the network, the other thing one must do is ensure that the
application’s needs are met in terms of loss, variation in delay, and
end-to-end delay. One way to do this is to supply sufficient
bandwidth so that loss and jitter are nominal. Where that cannot be
accomplished, one must use queuing technology to deterministically
apply bandwidth to accomplish the goal.
1.5. Desired Characteristics in an Internet Environment
The key elements of the Internet Emergency Preference Service include
the following:
Precedence Level Marking each call: Call initiators choose the
appropriate precedence level for each call based on the user-
perceived importance of the call. This level is not to be changed
for the duration of the call. The call before and the call after
are independent with regard to this level choice.
Call Admission/Preemption Policy: There is likewise a clear policy
regarding calls that may be in progress at the called instrument.
During call admission (SIP/H.323), if they are of lower
precedence, they must make way according to a prescribed
procedure. All callers on the preempted call must be informed
that the call has been preempted, and the call must make way for
the higher-precedence call.
Bandwidth Admission Policy: There is a clear bandwidth admission
policy: sessions may be placed that assert any of several levels
of precedence, and in the event that there is demand and
authorization is granted, other sessions will be preempted to make
way for a call of higher precedence.
Authentication and Authorization of calls placed: Unauthorized
attempts to place a call at an elevated status are not permitted.
In the telephone system, this is managed by controlling the policy
applied to an instrument by its switch plus a code produced by the
caller identifying himself or herself to the switch. In the
Internet, such characteristics must be explicitly signaled.
Voice handling characteristics: A call made, in the telephone
system, gets a circuit and provides the means for the callers to
conduct their business without significant impact as long as their
call is not preempted. In a VoIP system, one would hope for
essentially the same service.
Defined User Interface: If a call is preempted, the caller and the
callee are notified via a defined signal, so that they know that
their call has been preempted and that at this instant there is no
alternative circuit available to them at that precedence level.
A VoIP implementation of the Internet Emergency Preference Service
must, by definition, provide those characteristics.
1.6. The Use of Bandwidth as a Solution for QoS
There is a discussion in Internet circles concerning the relationship
of bandwidth to QoS procedures, which needs to be put to bed before
this procedure can be adequately analyzed. The issue is that it is
possible and common in certain parts of the Internet to solve the
problem with bandwidth. In LAN environments, for example, if there
is significant loss between any two switches or between a switch and
a server, the simplest and cheapest solution is to buy the next
faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit
for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet.
Similarly, in optical networking environments, the simplest and
cheapest solution is often to increase the data rate of the optical
path either by selecting a faster optical carrier or deploying an
additional lambda. In places where the bandwidth can be over-
provisioned to a point where loss or queuing delay are negligible,
10:1 over-provisioning is often the cheapest and surest solution and,
by the way, offers a growth path for future requirements. However,
there are many places in communication networks where the provision
of effectively infinite bandwidth is not feasible, including many
access networks, satellite communications, fixed wireless, airborne
and marine communications, island connections, and connections to
regions in which fiber optic connections are not cost-effective. It
is in these places where the question of resource management is
relevant. Specifically, we do not recommend the deployment of
significant QoS procedures on links in excess of 100 MBPS apart from
the provision of aggregated services that provide specific protection
to the stability of the network or the continuity of real-time
traffic as a class, as the mathematics of such circuits do not
support this as a requirement.
In short, the fact that we are discussing this class of policy
control says that such constrictions in the network exist and must be
dealt with. However much we might like to, in those places we are
not solving the problem with bandwidth.
2. Solution Proposal
A typical voice or video network, including a backbone domain, is
shown in Figure 1.
............... ......................
. . . .
. H H H H . . H H H H .
. /----------/ . . /----------/ .
. R SIP . . R R .
. \ . . / \ .
. R H H H . ....... / \ .