draft-ietf-tsvwg-mlpp-that-works-04.txt   rfc4542.txt 
Transport Working Group F. Baker Network Working Group F. Baker
Internet-Draft J. Polk Request for Comments: 4542 J. Polk
Intended status: Experimental Cisco Systems Category: Informational Cisco Systems
Expires: August 31, 2006 February 27, 2006 May 2006
Implementing an Emergency Telecommunications Service for Real Time Implementing an Emergency Telecommunications Service (ETS) for
Services in the Internet Protocol Suite Real-Time Services in the Internet Protocol Suite
draft-ietf-tsvwg-mlpp-that-works-04
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This memo provides information for the Internet community. It does
applicable patent or other IPR claims of which he or she is aware not specify an Internet standard of any kind. Distribution of this
have been or will be disclosed, and any of which he or she becomes memo is unlimited.
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 31, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
RFCs 3689 and 3690 detail requirements for an Emergency RFCs 3689 and 3690 detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preparedness Service (IEPS) would be a part. Some of these types of Preparedness Service (IEPS) would be a part. Some of these types of
services require call preemption; others call for call queuing or services require call preemption; others require call queuing or
other mechanisms. IEPS requires a Call Admission Control (CAC) other mechanisms. IEPS requires a Call Admission Control (CAC)
procedure and a Per Hop Behavior for the data which meet the needs of procedure and a Per Hop Behavior (PHB) for the data that meet the
this architecture. Such a CAC procedure and PHB is appropriate to needs of this architecture. Such a CAC procedure and PHB is
any service that might use H.323 or SIP to set up real time sessions. appropriate to any service that might use H.323 or SIP to set up
The key requirement is to guarantee an elevated probability of call real-time sessions. The key requirement is to guarantee an elevated
completion to an authorized user in time of crisis. probability of call completion to an authorized user in time of
crisis.
This document primarily discusses supporting ETS in the context of This document primarily discusses supporting ETS in the context of
the US Government and NATO, because it focuses on the MLPP and GETS the US Government and NATO, because it focuses on the Multi-Level
standards. The architectures described here are applicable beyond Precedence and Preemption (MLPP) and Government Emergency
these organizations. Telecommunication Service (GETS) standards. The architectures
described here are applicable beyond these organizations.
Table of Contents Table of Contents
1. Overview of the Internet Emergency Preference Service 1. Overview of the Internet Emergency Preference Service
problem and proposed solutions . . . . . . . . . . . . . . . . 4 Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services . . . . . . . . . . 4 1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 5 1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunications Service . . . 7 1.1.2. Government Emergency Telecommunications Service .....6
1.2. Definition of Call Admission . . . . . . . . . . . . . . . 7 1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network . . . . . . . . . . . . . . 8 1.3. Assumptions about the Network ..............................7
1.4. Assumptions about application behavior . . . . . . . . . . 8 1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment . . . . 10 1.5. Desired Characteristics in an Internet Environment .........9
1.6. The use of bandwidth as a solution for QoS . . . . . . . . 11 1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Call Admission/Preemption Procedure .......................12
2.1. Call admission/preemption procedure . . . . . . . . . . . 13 2.2. Voice Handling Characteristics ............................15
2.2. Voice handling characteristics . . . . . . . . . . . . . . 16 2.3. Bandwidth Admission Procedure .............................17
2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 17 2.3.1. RSVP Admission Using Policy for Both
2.3.1. RSVP procedure: explicit call admission - RSVP Unicast and Multicast Sessions .....................17
Admission using Policy for both unicast and 2.3.2. RSVP Scaling Issues ................................19
multicast sessions . . . . . . . . . . . . . . . . . . 18 2.3.3. RSVP Operation in Backbones and Virtual
2.3.2. RSVP Scaling Issues . . . . . . . . . . . . . . . . . 20 Private Networks (VPNs) ............................19
2.3.3. RSVP Operation in backbones and VPNs . . . . . . . . . 20 2.3.4. Interaction with the Differentiated
2.3.4. Interaction with the Differentiated Services Services Architecture ..............................21
Architecture . . . . . . . . . . . . . . . . . . . . . 21 2.3.5. Admission Policy ...................................21
2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 21 2.4. Authentication and Authorization of Calls Placed ..........23
2.4. Authentication and authorization of calls placed . . . . . 24 2.5. Defined User Interface ....................................23
2.5. Defined User Interface . . . . . . . . . . . . . . . . . . 24 3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. References .....................................................25
5.1. Normative References ......................................25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................29
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Integrated Services Architecture References . . . . . . . 28
6.3. Differentiated Services Architecture References . . . . . 29
6.4. Session Initiation Protocol and related References . . . . 30
6.5. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 32
1. Overview of the Internet Emergency Preference Service problem and 1. Overview of the Internet Emergency Preference Service Problem and
proposed solutions Proposed Solutions
[RFC3689] and [RFC3690] detail requirements for an Emergency [RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preference Service (IEPS) would be a part. Some of these types of Preference Service (IEPS) would be a part. Some of these types of
services require call preemption; others call for call queuing or services require call preemption; others require call queuing or
other mechanisms. The key requirement is to guarantee an elevated other mechanisms. The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of probability of call completion to an authorized user in time of
crisis. crisis.
IEPS requires a Call Admission Control procedure and a Per Hop IEPS requires a Call Admission Control procedure and a Per Hop
Behavior for the data which meet the needs of this architecture. Behavior for the data that meet the needs of this architecture. Such
Such a CAC procedure and PHB is appropriate to any service that might a CAC procedure and PHB is appropriate to any service that might use
use H.323 or SIP to set up real time sessions. These obviously H.323 or SIP to set up real-time sessions. These obviously include
include but are not limited to Voice and Video applications, although but are not limited to Voice and Video applications, although at this
at this writing the community is mostly thinking about Voice on IP writing the community is mostly thinking about Voice on IP, and many
and many of the examples in the document are taken from that of the examples in the document are taken from that environment.
environment.
In a network where a call permitted initially is not denied or In a network where a call permitted initially is not denied or
rejected at a later time, capacity admission procedures performed rejected at a later time, capacity admission procedures performed
only at the time of call setup may be sufficient. However in a only at the time of call setup may be sufficient. However, in a
network where sessions status can be reviewed by the network and network where session status can be reviewed by the network and
preempted or denied due to changes in routing (when the new routes preempted or denied due to changes in routing (when the new routes
lack capacity to carry calls switched to them) or changes in offered lack capacity to carry calls switched to them) or changes in offered
load (where higher precedence calls supersede existing calls), load (where higher precedence calls supersede existing calls),
maintaining a continuing model of the status of the various calls is maintaining a continuing model of the status of the various calls is
required. required.
1.1. Emergency Telecommunications Services 1.1. Emergency Telecommunications Services
Before doing so, however, let us discuss the problem that ETS (and Before doing so, however, let us discuss the problem that ETS (and
therefore IEPS) is intended to solve and the architecture of the therefore IEPS) is intended to solve and the architecture of the
system. The Emergency Telecommunications Service [ITU.ETS.E106] is a system. The Emergency Telecommunications Service [ITU.ETS.E106] is a
successor to and generalization of two services used in the United successor to and generalization of two services used in the United
States: Multilevel Preemption and Precedence (MLPP), and the States: Multi-Level Precedence and Preemption (MLPP), and the
Government Emergency Telecommunication Service (GETS). Services Government Emergency Telecommunication Service (GETS). Services
based on these models are also used in a variety of countries based on these models are also used in a variety of countries
throughout the world, both PSTN and GSM-based. Both of these throughout the world, both Public Switched Telephone Network (PSTN)
services are designed to enable an authorized user to obtain service and Global System for Mobile Communications (GSM)-based. Both of
from the telephone network in times of crisis. They differ primarily these services are designed to enable an authorized user to obtain
in the mechanisms used and number of levels of precedence service from the telephone network in times of crisis. They differ
primarily in the mechanisms used and number of levels of precedence
acknowledged. acknowledged.
1.1.1. Multi-Level Preemption and Precedence 1.1.1. Multi-Level Preemption and Precedence
The Assured Service is designed as an IP implementation of an The Assured Service is designed as an IP implementation of an
existing ITU-T/NATO/DoD telephone system architecture known as Multi- existing ITU-T/NATO/DoD telephone system architecture known as
Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec] Multi-Level Precedence and Preemption [ITU.MLPP.1990]
[ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a [ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP. MLPP is an architecture
prioritized call handling service such that in times of emergency in for a prioritized call handling service such that in times of
the relevant NATO and DoD commands, the relative importance of emergency in the relevant NATO and DoD commands, the relative
various kinds of communications is strictly defined, allowing higher importance of various kinds of communications is strictly defined,
precedence communication at the expense of lower precedence allowing higher-precedence communication at the expense of lower-
communications. This document describes NATO and U.S. Department of precedence communications. This document describes NATO and US
Defense uses of MLPP, but the architecture and standard are Department of Defense uses of MLPP, but the architecture and standard
applicable outside of these organizations. are applicable outside of these organizations.
These precedences, in descending order, are: These precedences, in descending order, are:
Flash Override Override: used by the Commander in Chief, Secretary Flash Override Override: used by the Commander in Chief, Secretary
of Defense, and Joint Chiefs of Staff, Commanders of combatant of Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war. commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other One or Defense Emergency or Air Defense Emergency and other
national authorities that the President may authorize in national authorities that the President may authorize in
conjunction with Worldwide Secure Voice Conferencing System conjunction with Worldwide Secure Voice Conferencing System
conferences. Flash Override Override cannot be preempted. This conferences. Flash Override Override cannot be preempted. This
precedence level is not enabled on all DoD networks. precedence level is not enabled on all DoD networks.
Flash Override: used by the Commander in Chief, Secretary of Flash Override: used by the Commander in Chief, Secretary of
Defense, and Joint Chiefs of Staff, Commanders of combatant Defense, and Joint Chiefs of Staff, commanders of combatant
commands when declaring the existence of a state of war. commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency and other national authorities the One or Defense Emergency and other national authorities the
President may authorize. Flash Override cannot be preempted in President may authorize. Flash Override cannot be preempted in
the DSN. the DSN.
Flash: reserved generally for telephone calls pertaining to command Flash: reserved generally for telephone calls pertaining to command
and control of military forces essential to defense and and control of military forces essential to defense and
retaliation, critical intelligence essential to national survival, retaliation, critical intelligence essential to national survival,
conduct of diplomatic negotiations critical to the arresting or conduct of diplomatic negotiations critical to the arresting or
skipping to change at page 6, line 28 skipping to change at page 5, line 24
expeditious action by called parties and/or furnishing essential expeditious action by called parties and/or furnishing essential
information for the conduct of government operations. information for the conduct of government operations.
Routine: designation applied to those official government Routine: designation applied to those official government
communications that require rapid transmission by telephonic means communications that require rapid transmission by telephonic means
but do not require preferential handling. but do not require preferential handling.
MLPP is intended to deliver a higher probability of call completion MLPP is intended to deliver a higher probability of call completion
to the more important calls. The rule, in MLPP, is that more to the more important calls. The rule, in MLPP, is that more
important calls override less important calls when congestion occurs important calls override less important calls when congestion occurs
within a network. Station based preemption is used when a more within a network. Station-based preemption is used when a more
important call needs to be placed to either party in an existing important call needs to be placed to either party in an existing
call. Trunk based preemption is used when trunk bandwidth needs to call. Trunk-based preemption is used when trunk bandwidth needs to
be reallocated to facilitate a higher precedence call over a given be reallocated to facilitate a higher-precedence call over a given
path in the network. In both station and trunk based preemption path in the network. In both station- and trunk-based preemption
scenarios, preempted parties are positively notified, via preemption scenarios, preempted parties are positively notified, via preemption
tone, that their call can no longer be supported. The same tone, that their call can no longer be supported. The same
preemption tone is used, regardless of whether calls are terminated preemption tone is used, regardless of whether calls are terminated
for the purposes of station of trunk based preemption. The remainder for the purposes of station- of trunk-based preemption. The
of this discussion focuses on trunk based preemption issues. remainder of this discussion focuses on trunk-based preemption
issues.
MLPP is built as a proactive system in which callers must assign one MLPP is built as a proactive system in which callers must assign one
of the precedence levels listed above at call initiation; this of the precedence levels listed above at call initiation; this
precedence level cannot be changed throughout that call. If an precedence level cannot be changed throughout that call. If an
elevated status is not assigned by a user at call initiation time, 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 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 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) 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 reaches a utilization threshold, a choice must be made as to which
calls to accept or allow to continue. The system will seize the calls to accept or allow to continue. The system will seize the
trunk(s) or bandwidth necessary to place the more important calls in trunk(s) or bandwidth necessary to place the more important calls in
preference to less important calls by preempting an existing call (or preference to less important calls by preempting an existing call (or
calls) of lower precedence to permit a higher precedence call to be calls) of lower precedence to permit a higher-precedence call to be
placed. placed.
More than one call might properly be preempted if more trunks or More than one call might properly be preempted if more trunks or
bandwidth is necessary for this higher precedence call. A video call bandwidth is necessary for this higher precedence call. A video call
(perhaps of 384 KBPS, or 6 trunks) competing with several lower (perhaps of 384 KBPS, or 6 trunks) competing with several lower-
precedence voice calls is a good example of this situation. precedence voice calls is a good example of this situation.
1.1.2. Government Emergency Telecommunications Service 1.1.2. Government Emergency Telecommunications Service
A US service similar to MLPP and using MLPP signaling technology, but A US service similar to MLPP and using MLPP signaling technology, but
built for use in civilian networks, is the Government Emergency built for use in civilian networks, is the Government Emergency
Telecommunications Service (GETS). This differs from MLPP in two Telecommunications Service (GETS). This differs from MLPP in two
ways: it does not use preemption, but rather reserves bandwidth or ways: it does not use preemption, but rather reserves bandwidth or
queues calls to obtain a high probability of call completion, and it queues calls to obtain a high probability of call completion, and it
has only two levels of service: "Routine" and "Priority". has only two levels of service: "Routine" and "Priority".
GETS is described here as another example. Similar architectures are GETS is described here as another example. Similar architectures are
applied by other governments and organizations. applied by other governments and organizations.
1.2. Definition of Call Admission 1.2. Definition of Call Admission
Traditionally, in the PSTN, Call Admission Control (CAC) has had the Traditionally, in the PSTN, Call Admission Control (CAC) has had the
responsibility of implementing bandwidth available thresholds (e.g. responsibility of implementing bandwidth available thresholds (e.g.,
to limit resources consumed by some traffic) and determining whether to limit resources consumed by some traffic) and determining whether
a caller has permission (e.g., is an identified subscriber, with a caller has permission (e.g., is an identified subscriber, with
identify attested to by appropriate credentials) to use an available identify attested to by appropriate credentials) to use an available
circuit. IEPS, or any emergency telephone service, has additional circuit. IEPS, or any emergency telephone service, has additional
options that it may employ to improve the probability of call options that it may employ to improve the probability of call
completion: completion:
o The call may be authorized to use other networks that it would not o The call may be authorized to use other networks that it would not
normally use normally use;
o The network may preempt other calls to free bandwidth, o The network may preempt other calls to free bandwidth;
o The network may hold the call and place it when other calls o The network may hold the call and place it when other calls
complete, or complete; or
o The network may use different bandwidth availability thresholds o The network may use different bandwidth availability thresholds
than are used for other calls. than are used for other calls.
At the completion of CAC, however, the caller either has a circuit 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 that he or she is authorized to use or has no circuit. Since the act
act of preemption or consideration of alternative bandwidth sources of preemption or consideration of alternative bandwidth sources is
is part and parcel of the problem of providing bandwidth, the part and parcel of the problem of providing bandwidth, the
authorization step in bandwidth provision also affects the choice of authorization step in bandwidth provision also affects the choice of
networks that may be authorized to be considered. The three cannot networks that may be authorized to be considered. The three cannot
be separated. The CAC procedure finds available bandwidth that the be separated. The CAC procedure finds available bandwidth that the
caller is authorized to use and preemption may in some networks be caller is authorized to use and preemption may in some networks be
part of making that happen. part of making that happen.
1.3. Assumptions about the Network 1.3. Assumptions about the Network
IP networks generally fall into two categories: those with IP networks generally fall into two categories: those with
constrained bandwidth, and those that are massively over-provisioned. constrained bandwidth, and those that are massively over-provisioned.
In a network wherein over any interval that can be measured In a network where over any interval that can be measured (including
(including sub-second intervals) capacity exceeds offered load by at sub-second intervals) capacity exceeds offered load by at least 2:1,
least 2:1, the jitter and loss incurred in transit are nominal. This the jitter and loss incurred in transit are nominal. This is
is generally a characteristic of properly engineered Ethernet LANs generally a characteristic of properly engineered Ethernet LANs and
and of optical networks (networks that measure their link speeds in of optical networks (networks that measure their link speeds in
multiples of 51 MBPS); in the latter, circuit-switched networking multiples of 51 MBPS); in the latter, circuit-switched networking
solutions such as ATM, MPLS, and GMPLS can be used to explicitly solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS
place routes, and so improve the odds a bit. can be used to explicitly place routes, which improves the odds a
bit.
Between those networks, in places commonly called "inter-campus Between those networks, in places commonly called "inter-campus
links", "access links" or "access networks", for various reasons links", "access links", or "access networks", for various reasons
including technology (e.g. satellite links) and cost, it is common to including technology (e.g., satellite links) and cost, it is common
find links whose offered load can approximate or exceed the available to find links whose offered load can approximate or exceed the
capacity. Such events may be momentary, or may occur for extended available capacity. Such events may be momentary or may occur for
periods of time. extended periods of time.
In addition, primarily in tactical deployments, it is common to find In addition, primarily in tactical deployments, it is common to find
bandwidth constraints in the local infrastructure of networks. For bandwidth constraints in the local infrastructure of networks. For
example, the US Navy's network afloat connects approximately 300 example, the US Navy's network afloat connects approximately 300
ships, via satellite, to five network operation centers, and those ships, via satellite, to five network operation centers (NOCs), and
NOCs are in turn interconnected via the DISA backbone. A typical those NOCs are in turn interconnected via the Defense Information
ship may have between two and six radio systems aboard, often at Systems Agency (DISA) backbone. A typical ship may have between two
speeds of 64 KBPS or less. In US Army networks, current radio and six radio systems aboard, often at speeds of 64 KBPS or less. In
technology likewise limits tactical communications to links below 100 US Army networks, current radio technology likewise limits tactical
KBPS. communications to links below 100 KBPS.
Over this infrastructure, military communications expect to deploy Over this infrastructure, military communications expect to deploy
voice communication systems (30-80 KBPS per session), video voice communication systems (30-80 KBPS per session) and video
conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800
KBPS), in addition to traditional mail, file transfer, and KBPS), in addition to traditional mail, file transfer, and
transaction traffic. transaction traffic.
1.4. Assumptions about application behavior 1.4. Assumptions about Application Behavior
Parekh and Gallagher published a series of papers [Parekh1] [Parekh2] Parekh and Gallagher published a series of papers [Parekh1] [Parekh2]
analyzing what is necessary to ensure a specified service level for a analyzing what is necessary to ensure a specified service level for a
stream of traffic. In a nutshell, they showed that to predict the 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 behavior of a stream of traffic in a network, one must know two
things: things:
o the rate and arrival distribution with which traffic in a class is o the rate and arrival distribution with which traffic in a class is
introduced to the network, and introduced to the network, and
o what network elements will do, in terms of the departure o what network elements will do, in terms of the departure
distribution, injected delay jitter and loss characteristics, with distribution, injected delay jitter, and loss characteristics,
the traffic they see. with the traffic they see.
For example, TCP tunes its effective window (the amount of data it 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 sends per round trip interval) so that the ratio of the window and
the round trip interval approximate the available capacity in the the round trip interval approximate the available capacity in the
network. As long as the round trip delay remains roughly stable and network. As long as the round trip delay remains roughly stable and
loss is nominal (which are primarily behaviors of the network), TCP loss is nominal (which are primarily behaviors of the network), TCP
is able to maintain a predictable level of throughput. In an is able to maintain a predictable level of throughput. In an
environment where loss is random or in which delays wildly vary, TCP environment where loss is random or in which delays wildly vary, TCP
behaves in a far less predictable manner. behaves in a far less predictable manner.
Voice and video systems, in the main, are designed to deliver a fixed Voice and video systems, in the main, are designed to deliver a fixed
level of quality as perceived by the user. (Exceptions are systems level of quality as perceived by the user. (Exceptions are systems
that select rate options over a broad range to adapt to ambient loss that select rate options over a broad range to adapt to ambient loss
characteristics. These deliver broadly fluctuating perceived quality characteristics. These deliver broadly fluctuating perceived quality
and have not found significant commercial applicability.) Rather, and have not found significant commercial applicability.) Rather,
they send traffic at a rate specified by the codec depending on what 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 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 camera is pointed at a wall, the codec determines that an 80 KBPS
data stream will describe that wall, and issues that amount of 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 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 pointed an a moving object, the codec may easily send 800 KBPS in its
effort to accurately describe what it sees. In commercial broadcast effort to accurately describe what it sees. In commercial broadcast
sports, which may line up periods in which advertisements are sports, which may line up periods in which advertisements are
displayed, the effect is that traffic rates suddenly jump across all displayed, the effect is that traffic rates suddenly jump across all
channels at certain times because the eye- catching ads require much channels at certain times because the eye- catching ads require much
more bandwidth than the camera pointing at the green football field. more bandwidth than the camera pointing at the green football field.
As described in [RFC1633], when dealing with a real-time application, As described in [RFC1633], when dealing with a real-time application,
there are basically two things one must do to ensure Parekh's first there are basically two things one must do to ensure Parekh's first
skipping to change at page 9, line 47 skipping to change at page 8, line 47
application is presenting, one must police (measure load offered and application is presenting, one must police (measure load offered and
discard excess) traffic entering the network. If that policing discard excess) traffic entering the network. If that policing
behavior has a debilitating effect on the application, as non- behavior has a debilitating effect on the application, as non-
negligible loss has on voice or video, one must admit sessions negligible loss has on voice or video, one must admit sessions
judiciously according to some policy. A key characteristic of that judiciously according to some policy. A key characteristic of that
policy must be that the offered load does not exceed the capacity policy must be that the offered load does not exceed the capacity
dedicated to the application. dedicated to the application.
In the network, the other thing one must do is ensure that the 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 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 end-to-end delay. One way to do this is to supply sufficient
bandwidth that loss and jitter are nominal. Where that cannot be bandwidth so that loss and jitter are nominal. Where that cannot be
accomplished, one must use queuing technology to deterministically accomplished, one must use queuing technology to deterministically
apply bandwidth to accomplish the goal. apply bandwidth to accomplish the goal.
1.5. Desired Characteristics in an Internet Environment 1.5. Desired Characteristics in an Internet Environment
The key elements of the Internet Emergency Preference Service include The key elements of the Internet Emergency Preference Service include
the following: the following:
Precedence Level Marking each call: Call initiators choose the Precedence Level Marking each call: Call initiators choose the
appropriate precedence level for each call based on user perceived appropriate precedence level for each call based on the user-
importance of the call. This level is not to be changed for the perceived importance of the call. This level is not to be changed
duration of the call. The call before, and the call after are for the duration of the call. The call before and the call after
independent with regard to this level choice. are independent with regard to this level choice.
Call Admission/Preemption Policy: There is likewise a clear policy Call Admission/Preemption Policy: There is likewise a clear policy
regarding calls that may be in progress at the called instrument. regarding calls that may be in progress at the called instrument.
During call admission (SIP/H.323), if they are of lower During call admission (SIP/H.323), if they are of lower
precedence, they must make way according to a prescribed precedence, they must make way according to a prescribed
procedure. All callers on the preempted call must be informed procedure. All callers on the preempted call must be informed
that the call has been preempted, and the call must make way for that the call has been preempted, and the call must make way for
the higher precedence call. the higher-precedence call.
Bandwidth Admission Policy: There is a clear bandwidth admission Bandwidth Admission Policy: There is a clear bandwidth admission
policy: sessions may be placed which assert any of several levels policy: sessions may be placed that assert any of several levels
of precedence, and in the event that there is demand and of precedence, and in the event that there is demand and
authorization is granted, other sessions will be preempted to make authorization is granted, other sessions will be preempted to make
way for a call of higher precedence. way for a call of higher precedence.
Authentication and Authorization of calls placed: Unauthorized Authentication and Authorization of calls placed: Unauthorized
attempts to place a call at an elevated status are not permitted. attempts to place a call at an elevated status are not permitted.
In the telephone system, this is managed by controlling the policy In the telephone system, this is managed by controlling the policy
applied to an instrument by its switch plus a code produced by the applied to an instrument by its switch plus a code produced by the
caller identifying himself or herself to the switch. In the caller identifying himself or herself to the switch. In the
Internet, such characteristics must be explicitly signaled. Internet, such characteristics must be explicitly signaled.
Voice handling characteristics: A call made, in the telephone Voice handling characteristics: A call made, in the telephone
system, gets a circuit, and provides the means for the callers to system, gets a circuit and provides the means for the callers to
conduct their business without significant impact as long as their conduct their business without significant impact as long as their
call is not preempted. In a VoIP system, one would hope for call is not preempted. In a VoIP system, one would hope for
essentially the same service. essentially the same service.
Defined User Interface: If a call is preempted, the caller and the Defined User Interface: If a call is preempted, the caller and the
callee are notified via a defined signal, so that they know that 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 their call has been preempted and that at this instant there is no
alternative circuit available to them at that precedence level. alternative circuit available to them at that precedence level.
A VoIP implementation of the Internet Emergency Preference Service A VoIP implementation of the Internet Emergency Preference Service
must, by definition, provide those characteristics. must, by definition, provide those characteristics.
1.6. The use of bandwidth as a solution for QoS 1.6. The Use of Bandwidth as a Solution for QoS
There is a discussion in Internet circles concerning the relationship There is a discussion in Internet circles concerning the relationship
of bandwidth to QoS procedures, which needs to be put to bed before 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 this procedure can be adequately analyzed. The issue is that it is
possible and common in certain parts of the Internet to solve the possible and common in certain parts of the Internet to solve the
problem with bandwidth. In LAN environments, for example, if there problem with bandwidth. In LAN environments, for example, if there
is significant loss between any two switches or between a switch and is significant loss between any two switches or between a switch and
a server, the simplest and cheapest solution is to buy the next a server, the simplest and cheapest solution is to buy the next
faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1 faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit
Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet.
Ethernet. Similarly, in optical networking environments, the Similarly, in optical networking environments, the simplest and
simplest and cheapest solution is often to increase the data rate of cheapest solution is often to increase the data rate of the optical
the optical path either by selecting a faster optical carrier or path either by selecting a faster optical carrier or deploying an
deploying an additional lambda. In places where the bandwidth can be additional lambda. In places where the bandwidth can be over-
over-provisioned to a point where loss or queuing delay are provisioned to a point where loss or queuing delay are negligible,
negligible, 10:1 over-provisioning is often the cheapest and surest 10:1 over-provisioning is often the cheapest and surest solution and,
solution, and by the way offers a growth path for future by the way, offers a growth path for future requirements. However,
requirements. However, there are many places in communication there are many places in communication networks where the provision
networks where the provision of effectively infinite bandwidth is not of effectively infinite bandwidth is not feasible, including many
feasible, including many access networks, satellite communications, access networks, satellite communications, fixed wireless, airborne
fixed wireless, airborn and marine communications, island and marine communications, island connections, and connections to
connections, and connections to regions in which fiber optic regions in which fiber optic connections are not cost-effective. It
connections are not cost-effective. It is in these places where the is in these places where the question of resource management is
question of resource management is relevant. Specifically, we do not relevant. Specifically, we do not recommend the deployment of
recommend the deployment of significant QoS procedures on links in significant QoS procedures on links in excess of 100 MBPS apart from
excess of 100 MBPS apart from the provision of aggregated services the provision of aggregated services that provide specific protection
that provide specific protection to the stability of the network or to the stability of the network or the continuity of real-time
the continuity of real-time traffic as a class, as the mathematics of traffic as a class, as the mathematics of such circuits do not
such circuits do not support this as a requirement. support this as a requirement.
In short, the fact that we are discussing this class of policy In short, the fact that we are discussing this class of policy
control says that such constrictions in the network exist and must be 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 dealt with. However much we might like to, in those places we are
not solving the problem with bandwidth. not solving the problem with bandwidth.
2. Solution Proposal 2. Solution Proposal
A typical voice or video network, including a backbone domain, is A typical voice or video network, including a backbone domain, is
shown in Figure 1. shown in Figure 1.
skipping to change at page 12, line 28 skipping to change at page 11, line 28
. R .. /. /----------/ . . R .. /. /----------/ .
..... ..\. R-----R . H H H H . ..... ..\. R-----R . H H H H .
...... .\ / \ . . ...... .\ / \ . .
. \ / \ . . . \ / \ . .
. R-----------R .................... . R-----------R ....................
. \ / . . \ / .
. \ / . . \ / .
. R-----R . . R-----R .
. . . .
............ ............
SIP = SIP Proxy SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC) H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router R = Router
/---/ = Ethernet or Ethernet Switch /---/ = Ethernet or Ethernet Switch
Figure 1: Typical VoIP or Video/IP Network Figure 1: Typical VoIP or Video/IP Network
Reviewing that figure, it becomes obvious that Voice/IP and Video/IP Reviewing the figure above, it becomes obvious that Voice/IP and
call flows are very different than call flows in the PSTN. In the Video/IP call flows are very different than call flows in the PSTN.
PSTN, call control traverses a switch, which in turn controls data In the PSTN, call control traverses a switch, which in turn controls
handling services like ATM or TDM switches or multiplexers. While data handling services like ATM or Time Division Multiplexing (TDM)
they may not be physically co-located, the control plane software and switches or multiplexers. While they may not be physically co-
the data plane services are closely connected; the switch routes a located, the control plane software and the data plane services are
call using bandwidth that it knows is available. In a voice/ closely connected; the switch routes a call using bandwidth that it
video-on-IP network, call control is completely divorced from the knows is available. In a voice/video-on-IP network, call control is
data plane: It is possible for a telephone instrument in the United completely divorced from the data plane: It is possible for a
States to have a Swedish telephone number if that is where its SIP telephone instrument in the United States to have a Swedish telephone
proxy happens to be, but on any given call to use only data paths in number if that is where its SIP proxy happens to be, but on any given
the Asia/Pacific region, data paths provided by a different company, call for it to use only data paths in the Asia/Pacific region, data
and often data paths provided by multiple companies/providers. paths provided by a different company, and, often, data paths provided
by multiple companies/providers.
Call management therefore addresses a variety of questions, all of Call management therefore addresses a variety of questions, all of
which must be answered: which must be answered:
o May I make this call from an administrative policy perspective? o May I make this call from an administrative policy perspective?
Am I authorized to make this call?
o What IP address correlates with this telephone number or SIP URI? o What IP address correlates with this telephone number or SIP URI?
o Is the other instrument "on hook"? If it is busy, under what o Is the other instrument "on hook"? If it is busy, under what
circumstances may I interrupt? circumstances may I interrupt?
o Is there bandwidth available to support the call? o Is there bandwidth available to support the call?
o Does the call actually work, or do other impairments (loss, delay) o Does the call actually work, or do other impairments (loss, delay)
make the call unusable? make the call unusable?
2.1. Call admission/preemption procedure 2.1. Call Admission/Preemption Procedure
Administrative Call Admission is the objective of SIP and H.323. It Administrative Call Admission is the objective of SIP and H.323. It
asks fundamental questions like "what IP address is the callee at?" asks fundamental questions like "What IP address is the callee at?"
and "Did you pay your bill?". and "Did you pay your bill?".
For specialized policy like call preemption, two capabilities are For a specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: [RFC4412] provides a necessary from an administrative perspective: [RFC4412] provides a
way to communicate policy-related information regarding the way to communicate policy-related information regarding the
precedence of the call; and [RFC4411] provides a reason code when a precedence of the call; and [RFC4411] provides a reason code when a
call fails or is refused, indicating the cause of the event. If it call fails or is refused, indicating the cause of the event. If it
is a failure, it may make sense to redial the call. If it is a is a failure, it may make sense to redial the call. If it is a
policy-driven preemption, even if the call is redialed it may not be policy-driven preemption, even if the call is redialed it may not be
possible to place the call. Requirements for this service are possible to place the call. Requirements for this service are
further discussed in [RFC3689]. further discussed in [RFC3689].
The Communications Resource Priority Header (or RP Header) serves the The SIP Communications Resource Priority Header (or RP Header) serves
call set-up process with the precedence level chosen by the initiator the call setup process with the precedence level chosen by the
of the call. The syntax is in the form: initiator of the call. The syntax is in the form:
Resource Priority : namespace.priority level Resource Priority : namespace.priority level
The "namespace" part of the syntax ensures the domain of significance The "namespace" part of the syntax ensures the domain of significance
to the originator of the call, and this travels end-to-end to the to the originator of the call, and this travels end-to-end to the
destination (called) device (telephone). If the receiving phone does destination (called) device (telephone). If the receiving phone does
not support the namespace, it can easily ignore the set-up request. not support the namespace, it can easily ignore the setup request.
This ability to denote the domain of origin allows SLAs to be in This ability to denote the domain of origin allows Service Level
place to limit the ability of an unknown requester to gain Agreements (SLAs) to be in place to limit the ability of an unknown
preferential treatment into an IEPS domain. requester to gain preferential treatment into an IEPS domain.
For the DSN infrastructure, this header would look like this: For the DSN infrastructure, the header would look like this for a
routine precedence level call:
Resource Priority : dsn.routine Resource Priority : dsn.routine
for a routine precedence level call. The precedence level chosen in The precedence level chosen in this header would be compared to the
this header would be compared to the requester's authorization requester's authorization profile to use that precedence level. This
profile to use that precedence level. This would typically occur in would typically occur in the SIP first-hop Proxy, which can challenge
the SIP first hop Proxy, which can challenge many aspects of the call many aspects of the call setup request including the requester's
set-up request including the requester choice of precedence levels choice of precedence levels (verifying that they are not using a
(verifying they are not using a level they are not authorized to level they are not authorized to use).
use.)
The DSN has 5 precedence levels of IEPS in descending order: The DSN has 5 precedence levels of IEPS, in descending order:
dsn.flash-override dsn.flash-override
dsn.flash dsn.flash
dsn.immediate dsn.immediate
dsn.priority dsn.priority
dsn.routine dsn.routine
The US Defense Red Switched Network (DRSN), as another example that The US Defense Red Switched Network (DRSN), as another example that
is to be IANA registered in [RFC4412], has 6 levels of precedence. was IANA-registered in [RFC4412], has 6 levels of precedence. The
The DRSN simply adds one higher precedence level than flash-override: DRSN simply adds one precedence level higher than flash-override to
be used by the President and a select few others:
drsn.flash-override-override drsn.flash-override-override
to be used by the President and a select few others. Note that the Note that the namespace changed for this level. The lower 5 levels
namespace changed for this level. The lower 5 levels within the DRSN within the DRSN would also have this as their namespace for all
would also have this as their namespace for all DRSN originated call DRSN-originated call setup requests.
set-up requests.
The Resource-Priority Header (RPH) informs both the use of DSCPs by The Resource-Priority Header (RPH) informs both the use of
the callee (who needs to use the same DSCP as the caller to obtain Differentiated Services Code Points (DSCPs) by the callee (who needs
the same data path service) and to facilitate policy-based preemption to use the same DSCP as the caller to obtain the same data path
of calls in progress when appropriate. service) and to facilitate policy-based preemption of calls in
progress, when appropriate.
Once a call is established in an IEPS domain, the Reason Header for Once a call is established in an IEPS domain, the Reason Header for
Preemption, described in [RFC4411], ensures that all SIP nodes are Preemption, described in [RFC4411], ensures that all SIP nodes are
synchronized to a preemption event occurring either at the endpoint synchronized to a preemption event occurring either at the endpoint
or in a router that experiences congestion. In SIP, the normal or in a router that experiences congestion. In SIP, the normal
indication for the end of a session is for one end system to send a indication for the end of a session is for one end system to send a
BYE Method request as specified in [RFC3261]. This, too, is the BYE Method request as specified in [RFC3261]. This, too, is the
proper means for signaling a termination of a call due to a proper means for signaling a termination of a call due to a
preemption event, as it essentially performs a normal termination preemption event, as it essentially performs a normal termination
with additional information informing the peer of the reason for the with additional information informing the peer of the reason for the
abrupt end - it indicates that a preemption occurred. This will be abrupt end: it indicates that a preemption occurred. This will be
used to inform all relevant SIP entities, and whether this was a used to inform all relevant SIP entities, and whether this was an
endpoint generated preemption event, or that the preemption event endpoint-generated preemption event, or that the preemption event
occurred within a router along the communications path (described in occurred within a router along the communications path (described in
Section 2.3.1 ). Section 2.3.1 ).
Figure 2 is a simple example of a SIP call set-up that includes the Figure 2 is a simple example of a SIP call setup that includes the
layer 7 precedence of a call between Alice and Bob. After Alice layer 7 precedence of a call between Alice and Bob. After Alice
successfully sets up a call to Bob at the "Routine" precedence level, successfully sets up a call to Bob at the "Routine" precedence level,
Carol calls Bob at a higher precedence level (Immediate). At the SIP Carol calls Bob at a higher precedence level (Immediate). At the SIP
layer (this has nothing to do with RSVP yet, that example involving layer (this has nothing to do with RSVP yet; that example, involving
SIP and RSVP signaling will be in the appendix), once Bob's user SIP and RSVP signaling, is in the appendix), once Bob's user agent
agent (phone) receives the INVITE message from Carol, his UA needs to (phone) receives the INVITE message from Carol, his UA needs to make
make a choice between retaining the call to Alice and sending Carol a a choice between retaining the call to Alice and sending Carol a
"busy" indication, or preempting the call to Alice in favor of "busy" indication, or preempting the call to Alice in favor of
accepting the call from Carol. That choice in IEPS networks is a accepting the call from Carol. That choice in IEPS networks is a
comparison of Resource Priority headers. Alice, who controlled the comparison of Resource Priority headers. Alice, who controlled the
precedence level of the call to Bob, sent the precedence level of her precedence level of the call to Bob, sent the precedence level of her
call to him at "Routine" (the lowest level within the network). call to him at "Routine" (the lowest level within the network).
Carol, who controls the priority of the call signal to Bob, sent her Carol, who controls the priority of the call signal to Bob, sent her
priority level to "Immediate" (higher than "Routine"). Bob's UA priority level to "Immediate" (higher than "Routine"). Bob's UA
needs to (under IEPS policy) preempt the call from Alice (and provide needs to (under IEPS policy) preempt the call from Alice (and provide
her with a preemption indication in the call termination message). her with a preemption indication in the call termination message).
Bob needs to successfully answer the call set-up from Carol. Bob needs to successfully answer the call setup from Carol.
UA Alice UA Bob UA Carol UA Alice UA Bob UA Carol
| INVITE (RP: Routine) | | | INVITE (RP: Routine) | |
|--------------------------->| | |--------------------------->| |
| 200 OK | | | 200 OK | |
|<---------------------------| | |<---------------------------| |
| ACK | | | ACK | |
|--------------------------->| | |--------------------------->| |
| RTP | | | RTP | |
|<==========================>| | |<==========================>| |
skipping to change at page 16, line 4 skipping to change at page 15, line 34
| |---------------------------->| | |---------------------------->|
| 200 OK (BYE) | | | 200 OK (BYE) | |
|--------------------------->| | |--------------------------->| |
| | ACK | | | ACK |
| |<----------------------------| | |<----------------------------|
| | RTP | | | RTP |
| |<===========================>| | |<===========================>|
| | | | | |
Figure 2: Priority Call Establishment and Termination at SIP Layer Figure 2: Priority Call Establishment and Termination at SIP Layer
Nothing in this example involved mechanisms other than SIP. It is Nothing in this example involved mechanisms other than SIP. It is
also assumed each user agent recognized the Resource-Priority header also assumed each user agent recognized the Resource-Priority header
namespace value in each message. Therefore, it is assumed that the namespace value in each message. Therefore, it is assumed that the
domain allowed Alice, Bob and Carol to communicate. Authentication domain allowed Alice, Bob, and Carol to communicate. Authentication
and Authorization are discussed later in this document. and Authorization are discussed later in this document.
2.2. Voice handling characteristics 2.2. Voice Handling Characteristics
The Quality of Service architecture used in the data path is that of The Quality of Service architecture used in the data path is that of
[RFC2475]. Differentiated Services uses a flag in the IP header [RFC2475]. Differentiated Services uses a flag in the IP header
called the DSCP [RFC2474] to identify a data stream, and then applies called the DSCP [RFC2474] to identify a data stream, and then applies
a procedure called a Per Hop Behavior, or PHB, to it. This is a procedure called a Per Hop Behavior, or PHB, to it. This is
largely as described in the [RFC2998]. largely as described in [RFC2998].
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247]
describes the fundamental needs of voice and video traffic. This PHB describes the fundamental needs of voice and video traffic. This PHB
entails ensuring that sufficient bandwidth is dedicated to real-time entails ensuring that sufficient bandwidth is dedicated to real-time
traffic to ensure minimal variation in delay and a minimal loss rate, traffic to ensure that variation in delay and loss rate are minimal,
as codecs are hampered by excessive loss [G711.1][G711.2][G711.3]. as codecs are hampered by excessive loss [G711.1] [G711.3]. In parts
In parts of the network where bandwidth is heavily over-provisioned, of the network where bandwidth is heavily over-provisioned, there may
there may be no remaining concern. In places in the network where be no remaining concern. In places in the network where bandwidth is
bandwidth is more constrained, this may require the use of a priority more constrained, this may require the use of a priority queue. If a
queue. If a priority queue is used, the potential for abuse exists, priority queue is used, the potential for abuse exists, meaning that
meaning that it is also necessary to police traffic placed into the it is also necessary to police traffic placed into the queue to
queue to detect and manage abuse. A fundamental question is "where detect and manage abuse. A fundamental question is "where does this
does this policing need to take place?". The obvious places would be policing need to take place?". The obvious places would be the
the first hop routers and any place where converging data streams first-hop routers and any place where converging data streams might
might congest a link. congest a link.
Some proposals mark traffic with various code points appropriate to Some proposals mark traffic with various code points appropriate to
the service precedence of the call. In normal service, if the the service precedence of the call. In normal service, if the
traffic is all in the same queue and EF service requirements are met traffic is all in the same queue and EF service requirements are met
(applied capacity exceeds offered load, variation in delay is (applied capacity exceeds offered load, variation in delay is
minimal, and loss is negligible), details of traffic marking should minimal, and loss is negligible), details of traffic marking should
be irrelevant, as long as packets get into the right service class. be irrelevant, as long as packets get into the right service class.
The major issues, then are primarily appropriate policing of traffic, Then, the major issues are appropriate policing of traffic,
especially around route changes, and ensuring that the path has especially around route changes, and ensuring that the path has
sufficient capacity. sufficient capacity.
The real time voice/video application should be generating traffic at The real-time voice/video application should be generating traffic at
a rate appropriate to its content and codec, which is either a a rate appropriate to its content and codec, which is either a
constant bit rate stream or a stream whose rate is variable within a constant bit rate stream or a stream whose rate is variable within a
specified range. The first hop router should be policing traffic specified range. The first-hop router should be policing traffic
originated by the application, as is performed in traditional virtual originated by the application, as is performed in traditional virtual
circuit networks like Frame Relay and ATM. Between these two checks circuit networks like Frame Relay and ATM. Between these two checks
(at what some networks call the DTE and DCE), the application traffic (at what some networks call the Data Terminal Equipment (DTE) and
should be guaranteed to be within acceptable limits. As such, given Data Communications Equipment (DCE)), the application traffic should
be guaranteed to be within acceptable limits. As such, given
bandwidth-aware call admission control, there should be minimal bandwidth-aware call admission control, there should be minimal
actual loss. The cases where loss would occur include cases where actual loss. The cases where loss would occur include cases where
routing has recently changed and CAC has not caught up, or cases routing has recently changed and CAC has not caught up, or cases
where statistical thresholds are in use in CAC and the data streams where statistical thresholds are in use in CAC and the data streams
happen to coincide at their peak rates. happen to coincide at their peak rates.
If it is demonstrated that routing transients and variable rate beat If it is demonstrated that routing transients and variable rate beat
frequencies present a sufficient problem, it is possible to provide a frequencies present a sufficient problem, it is possible to provide a
policing mechanism that isolates intentional loss among an ordered policing mechanism that isolates intentional loss among an ordered
set of classes. While the ability to do so, by various algorithms, set of classes. While the ability to do so, by various algorithms,
has been demonstrated, the technical requirement has not. If has been demonstrated, the technical requirement has not. If
dropping random packets from all calls is not appropriate, dropping random packets from all calls is not appropriate,
concentrating random loss in a subset of the calls makes the problem concentrating random loss in a subset of the calls makes the problem
for those calls worse; a superior approach would reject or preempt an for those calls worse; a superior approach would reject or preempt an
entire call. entire call.
Parekh's second condition has been met: we must know what the network Parekh's second condition has been met: we must know what the network
will do with the traffic. If the offered load exceeds the available will do with the traffic. If the offered load exceeds the available
bandwidth, the network will remark and drop the excess traffic. The bandwidth, the network will remark and drop the excess traffic. The
key questions become "How does one limit offered load to a rate less key questions become "How does one limit offered load to a rate less
than or equal to available bandwidth?" and "how much traffic does one than or equal to available bandwidth?" and "How much traffic does one
admit with each appropriate marking?" admit with each appropriate marking?"
2.3. Bandwidth admission procedure 2.3. Bandwidth Admission Procedure
Since the available voice and video codecs require a nominal loss Since many available voice and video codecs require a nominal loss
rate to deliver acceptable performance, Parekh's first requirement is rate to deliver acceptable performance, Parekh's first requirement is
that offered load be within the available capacity. There are that offered load be within the available capacity. There are
several possible approaches. several possible approaches.
An approach that is commonly used in H.323 networks is to limit the An approach that is commonly used in H.323 networks is to limit the
number of calls simultaneously accepted by the gatekeeper. SIP number of calls simultaneously accepted by the gatekeeper. SIP
networks do something similar when they place a stateful SIP proxy networks do something similar when they place a stateful SIP proxy
near a single ingress/egress to the network. This is able to impose near a single ingress/egress to the network. This is able to impose
an upper bound on the total number of calls in the network or the an upper bound on the total number of calls in the network or the
total number of calls crossing the significant link. However, the total number of calls crossing the significant link. However, the
gatekeeper has no knowledge of routing, so the engineering must be gatekeeper has no knowledge of routing, so the engineering must be
very conservative, and usually presumes a single ingress/egress or very conservative and usually presumes a single ingress/egress or the
the failure of one of its data paths. While this may serve as a failure of one of its data paths. While this may serve as a short-
short term work-around, it is not a general solution that is readily term work-around, it is not a general solution that is readily
deployed. This limits the options in network design. deployed. This limits the options in network design.
[RFC1633] provides for signaled admission for the use of capacity. [RFC1633] provides for signaled admission for the use of capacity.
The recommended approach is explicit capacity admission, supporting The recommended approach is explicit capacity admission, supporting
the concepts of preemption. An example of such a procedure uses the the concepts of preemption. An example of such a procedure uses the
Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of
Capacity Admission using RSVP with SIP is described in [RFC3312]. Capacity Admission using RSVP with SIP is described in [RFC3312].
While call counting is specified in H.323, network capacity admission While call counting is specified in H.323, network capacity admission
is not integrated with H.323 at this time. is not integrated with H.323 at this time.
2.3.1. RSVP procedure: explicit call admission - RSVP Admission using 2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast
Policy for both unicast and multicast sessions Sessions
RSVP is a resource reservation setup protocol providing the one-way RSVP is a resource reservation setup protocol providing the one-way
(at a time) setup of resource reservations for multicast and unicast (at a time) setup of resource reservations for multicast and unicast
flows. Each reservation is set up in one direction (meaning one flows. Each reservation is set up in one direction (meaning one
reservation from each end system; in a multicast environment, N reservation from each end system; in a multicast environment, N
senders set up N reservations). These reservations complete a senders set up N reservations). These reservations complete a
communication path with a deterministic bandwidth allocation through communication path with a deterministic bandwidth allocation through
each router along that path between end systems. These reservations each router along that path between end systems. These reservations
setup a known quality of service for end-to-end communications and setup a known quality of service for end-to-end communications and
maintain a "soft-state" within a node. The meaning of the term "soft maintain a "soft-state" within a node. The meaning of the term "soft
state" is that in the event of a network outage or change of routing, state" is that in the event of a network outage or change of routing,
these reservations are cleared without manual intervention, but must these reservations are cleared without manual intervention, but must
be periodically refreshed. In RSVP, the refresh period is by default be periodically refreshed. In RSVP, the refresh period is by default
30 seconds, but may be as long as appropriate. 30 seconds, but may be as long as is appropriate.
RSVP is a locally-oriented process, not a globally- or domain- RSVP is a locally-oriented process, not a globally- or domain-
oriented one like a routing protocol or like H.323 Call Counting. oriented one like a routing protocol or H.323 Call Counting.
Although it uses the local routing databases to determine the routing Although it uses the local routing databases to determine the routing
path, it is only concerned with the quality of service for a path, it is only concerned with the quality of service for a
particular or aggregate flow through a device. RSVP is not aware of particular or aggregate flow through a device. RSVP is not aware of
anything other than the local goal of QoS and its RSVP-enabled anything other than the local goal of QoS and its RSVP-enabled
adjacencies, operating below the network layer. The process by adjacencies, operating below the network layer. The process by
itself neither requires nor has any end-to-end network knowledge or itself neither requires nor has any end-to-end network knowledge or
state. Thus, RSVP can be effective when it is enabled at some nodes state. Thus, RSVP can be effective when it is enabled at some nodes
in a network without the need to have every node participate. in a network without the need to have every node participate.
HOST ROUTER HOST ROUTER
skipping to change at page 19, line 37 skipping to change at page 18, line 48
Figure 3: RSVP in Hosts and Routers Figure 3: RSVP in Hosts and Routers
Figure 3 shows the internal process of RSVP in both hosts (end Figure 3 shows the internal process of RSVP in both hosts (end
systems) and routers, as shown in [RFC2209]. systems) and routers, as shown in [RFC2209].
RSVP uses the phrase "traffic control" to describe the mechanisms of RSVP uses the phrase "traffic control" to describe the mechanisms of
how a data flow receives quality of service. There are 3 different how a data flow receives quality of service. There are 3 different
mechanisms to traffic control (shown in Figure 2 in both hosts and mechanisms to traffic control (shown in Figure 2 in both hosts and
routers). They are: routers). They are:
A packet classifier mechanism: which resolves the QoS class for each A packet classifier mechanism: This resolves the QoS class for each
packet; this can determine the route as well. packet; this can determine the route as well.
An admission control mechanism: this consists of two decision An admission control mechanism: This consists of two decision
modules: the admission control module and the policy control modules: admission control and policy control. Determining
module. Determining whether there is satisfactory resources for whether there are satisfactory resources for the requested QoS is
the requested QoS is the function of admission control. the function of admission control. Determining whether the user
Determining if the user has the authorization to request such has the authorization to request such resources is the function of
resources is the function of policy control. If the parameters policy control. If the parameters carried within this flow fail,
carried within this flow fail either of these two modules, RSVP either of these two modules errors the request using RSVP.
errors the request.
A packet scheduler mechanism: at each outbound interface, the A packet scheduler mechanism: At each outbound interface, the
scheduler attains the guaranteed QoS for that flow scheduler attains the guaranteed QoS for that flow.
2.3.2. RSVP Scaling Issues 2.3.2. RSVP Scaling Issues
As originally written, there was concern that RSVP had scaling As originally written, there was concern that RSVP had scaling
limitations due to its data plane behavior[RFC2208]. This has either limitations due to its data plane behavior [RFC2208]. This either
not proven to be the case or has in time largely been corrected. has not proven to be the case or has in time largely been corrected.
Telephony services generally require peak call admission rates on the Telephony services generally require peak call admission rates on the
order of thousands of calls per minute and peak call levels order of thousands of calls per minute and peak call levels
comparable to the capacities of the lines in question, which is comparable to the capacities of the lines in question, which is
generally on the order of thousands to tens of thousands of calls. generally on the order of thousands to tens of thousands of calls.
Current RSVP implementations admit calls at the rate of hundreds of Current RSVP implementations admit calls at the rate of hundreds of
calls per second and maintain as many calls in progress as memory calls per second and maintain as many calls in progress as memory
configurations allow. configurations allow.
In edge networks, RSVP is used to signal for individual microflows, In edge networks, RSVP is used to signal for individual microflows,
admitting the bandwidth. However, Differentiated Services is used admitting the bandwidth. However, Differentiated Services is used
for the data plane behavior. Admission and policing may be performed for the data plane behavior. Admission and policing may be performed
anywhere, but need only be performed in the first hop router (which, anywhere, but need only be performed in the first-hop router (which,
if the end system sending the traffic is a DTE, constitutes a DCE for if the end system sending the traffic is a DTE, constitutes a DCE for
the remaining network) and in routers that have interfaces threatened the remaining network) and in routers that have interfaces threatened
by congestion. In Figure 1, these would normally be the links that by congestion. In Figure 1, these would normally be the links that
cross network boundaries. cross network boundaries.
2.3.3. RSVP Operation in backbones and VPNs 2.3.3. RSVP Operation in Backbones and Virtual Private Networks (VPNs)
In backbone networks, networks that are normally awash in bandwidth, In backbone networks, networks that are normally awash in bandwidth,
RSVP and its affected data flows may be carried in a variety of ways. RSVP and its affected data flows may be carried in a variety of ways.
If the backbone is a maze of tunnels between its edges - true of MPLS If the backbone is a maze of tunnels between its edges (true of MPLS
networks and of networks that carry traffic from an encryptor to a networks, networks that carry traffic from an encryptor to a
decryptor, and also of VPNs - applicable technologies include decryptor, and also VPNs), applicable technologies include [RFC2207],
[RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is simplistically [RFC2746], and [RFC2983]. An IP tunnel is, simplistically put, a IP
a IP packet enveloped inside another IP packet as a payload. When packet enveloped inside another IP packet as a payload. When IPv6 is
IPv6 is transported over an IPv4 network, encapsulating the entire v6 transported over an IPv4 network, encapsulating the entire v6 packet
packet inside a v4 packet is an effective means to accomplish this inside a v4 packet is an effective means to accomplish this task. In
task. In this type of tunnel, the IPv6 packet is not read by any of this type of tunnel, the IPv6 packet is not read by any of the
the routers while inside the IPv4 envelope. If the inner packet is routers while inside the IPv4 envelope. If the inner packet is RSVP
RSVP enabled, there must be a active configuration to ensure that all enabled, there must be an active configuration to ensure that all
relevant backbone nodes read the RSVP fields; [RFC2746] describes relevant backbone nodes read the RSVP fields; [RFC2746] describes
this. this.
This is similar to how IPsec tunnels work. Encapsulating an RSVP This is similar to how IPsec tunnels work. Encapsulating an RSVP
packet inside an encrypted packet for security purposes without packet inside an encrypted packet for security purposes without
copying or conveying the RSVP indicators in the outside IP packet copying or conveying the RSVP indicators in the outside IP packet
header would make RSVP inoperable while in this form of a tunnel. header would make RSVP inoperable while in this form of a tunnel.
[RFC2207] describes how to modify an IPsec packet header to allow for [RFC2207] describes how to modify an IPsec packet header to allow for
RSVP awareness by nodes that need to provide QoS for the flow or RSVP awareness by nodes that need to provide QoS for the flow or
flows inside a tunnel. flows inside a tunnel.
skipping to change at page 21, line 15 skipping to change at page 20, line 28
reservation architecture is that each flow requires a non-trivial reservation architecture is that each flow requires a non-trivial
amount of message exchange, computation, and memory resources in each amount of message exchange, computation, and memory resources in each
router between each endpoint. Aggregation of flows reduces the router between each endpoint. Aggregation of flows reduces the
number of completely individual reservations into groups of number of completely individual reservations into groups of
individual flows that can act as one for part or all of the journey individual flows that can act as one for part or all of the journey
between end systems. Aggregates are not intended to be from the between end systems. Aggregates are not intended to be from the
first router to the last router within a flow, but to cover common first router to the last router within a flow, but to cover common
paths of a large number of individual flows. paths of a large number of individual flows.
Examples of aggregated data flows include streams of IP data that Examples of aggregated data flows include streams of IP data that
traverse common ingress and egress points in a network, and also traverse common ingress and egress points in a network and also
include tunnels of various kinds. MPLS LSPs, IPSEC Security include tunnels of various kinds. MPLS LSPs, IPsec Security
Associations between VPN edge routers, IP/IP tunnels, and GRE tunnels Associations between VPN edge routers, IP/IP tunnels, and Generic
all fall into this general category. The distinguishing factor is Routing Encapsulation (GRE) tunnels all fall into this general
that the system injecting an aggregate into the aggregated network category. The distinguishing factor is that the system injecting an
sums the PATH and RESV statistical information on the un- aggregated aggregate into the aggregated network sums the PATH and RESV
side and produces a reservation for the tunnel on the aggregated statistical information on the un-aggregated side and produces a
side. If the bandwidth for the tunnel cannot be expanded, RSVP reservation for the tunnel on the aggregated side. If the bandwidth
leaves the existing reservation in place and returns an error to the for the tunnel cannot be expanded, RSVP leaves the existing
aggregator, which can then apply a policy such as IEPS to determine reservation in place and returns an error to the aggregator, which
which session to refuse. In the data plane, the DSCP for the traffic can then apply a policy such as IEPS to determine which session to
must be copied from the inner to the outer header, to preserve the refuse. In the data plane, the DSCP for the traffic must be copied
PHB's effect. from the inner to the outer header, to preserve the PHB's effect.
One concern with this approach is that this leaks information into One concern with this approach is that this leaks information into
the aggregated zone concerning the number of active calls or the the aggregated zone concerning the number of active calls or the
bandwidth they consume. In fact, it does not, as the data itself is bandwidth they consume. In fact, it does not, as the data itself is
identifiable by aggregator address, deaggregator address, and DSCP. identifiable by aggregator address, deaggregator address, and DSCP.
As such, even if it is not advertised, such information is As such, even if it is not advertised, such information is
measurable. measurable.
2.3.4. Interaction with the Differentiated Services Architecture 2.3.4. Interaction with the Differentiated Services Architecture
In the PATH message, the DCLASS object described in [RFC2996] is used In the PATH message, the DCLASS object described in [RFC2996] is used
to carry the determined DSCP for the precedence level of that call in to carry the determined DSCP for the precedence level of that call in
the stream. This is reflected back in the RESV message. The DSCP the stream. This is reflected back in the RESV message. The DSCP
will be determined from the authorized SIP message exchange between will be determined from the authorized SIP message exchange between
end systems by using the R-P header. The DCLASS object permits both end systems by using the R-P header. The DCLASS object permits both
bandwidth admission within a class and the building up of the various bandwidth admission within a class and the building up of the various
rates or token buckets. rates or token buckets.
2.3.5. Admission policy 2.3.5. Admission Policy
RSVP's basic admission policy, as defined, is to grant any user RSVP's basic admission policy, as defined, is to grant any user
bandwidth if there is bandwidth available within the current bandwidth if there is bandwidth available within the current
configuration. In other words, if a new request arrives and the configuration. In other words, if a new request arrives and the
difference between the configured upper bound and the currently difference between the configured upper bound and the currently
reserved bandwidth is sufficiently large, RSVP grants use of that reserved bandwidth is sufficiently large, RSVP grants use of that
bandwidth. This basic policy may be augmented in various ways, such bandwidth. This basic policy may be augmented in various ways, such
as using a local or remote policy engine to apply AAA procedures and as using a local or remote policy engine to apply AAA procedures and
further qualify the reservation. further qualify the reservation.
2.3.5.1. Admission for variable rate codecs 2.3.5.1. Admission for Variable Rate Codecs
For certain applications, such as broadcast video using MPEG-1 or For certain applications, such as broadcast video using MPEG-1 or
voice without activity detection and using a constant bit rate codec voice without activity detection and using a constant bit rate codec
such as G.711, this basic policy is adequate apart from AAA. For such as G.711, this basic policy is adequate apart from AAA. For
variable rate codecs, such as MPEG-4 or a voice codec with Voice variable rate codecs, such as MPEG-4 or a voice codec with Voice
Activity Detection, however, this may be deemed too conservative. In Activity Detection, however, this may be deemed too conservative. In
such cases, two basic types of statistical policy have been studied such cases, two basic types of statistical policy have been studied
and reported on in the literature: simple over-provisioning, and and reported on in the literature: simple over-provisioning, and
approximation to ambient load. approximation to ambient load.
skipping to change at page 22, line 31 skipping to change at page 21, line 48
than the desired load, on the assumption that a session that admits a than the desired load, on the assumption that a session that admits a
certain bandwidth will in fact use a fraction of the bandwidth. For certain bandwidth will in fact use a fraction of the bandwidth. For
example, if MPEG-4 data streams are known to use data rates between example, if MPEG-4 data streams are known to use data rates between
80 and 800 KBPS and there is no obvious reason that sessions would 80 and 800 KBPS and there is no obvious reason that sessions would
synchronize (such as having commercial breaks on 15 minute synchronize (such as having commercial breaks on 15 minute
boundaries), one could imagine estimating that the average session boundaries), one could imagine estimating that the average session
consumes 400 KBPS and treating an admission of 800 KBPS as actually consumes 400 KBPS and treating an admission of 800 KBPS as actually
consuming half the amount. consuming half the amount.
One can also approximate to average load, which is perhaps a more One can also approximate to average load, which is perhaps a more
reliable procedure. In this case, one maintains a variable which reliable procedure. In this case, one maintains a variable that
measures actual traffic through the admitted data's queue, measures actual traffic through the admitted data's queue,
approximating it using an exponentially weighted moving average. approximating it using an exponentially weighted moving average.
When a new reservation request arrives, if the requested rate is less When a new reservation request arrives, if the requested rate is less
than the difference between the configured upper bound and the than the difference between the configured upper bound and the
current value of the moving average, the reservation is accepted and current value of the moving average, the reservation is accepted, and
the moving average is immediately increased by the amount of the the moving average is immediately increased by the amount of the
reservation to ensure that the bandwidth is not promised out to reservation to ensure that the bandwidth is not promised out to
several users simultaneously. In time, the moving average will decay several users simultaneously. In time, the moving average will decay
from this guard position to an estimate of true load, which may offer from this guard position to an estimate of true load, which may offer
a chance to another session to be reserved that would otherwise have a chance to another session to be reserved that would otherwise have
been refused. been refused.
Statistical reservation schemes such as these are overwhelmingly Statistical reservation schemes such as these are overwhelmingly
dependent on the correctness of their configuration and its dependent on the correctness of their configuration and its
appropriateness for the codecs in use. But they offer the appropriateness for the codecs in use. However, they offer the
opportunity to take advantage of statistical multiplexing gains that opportunity to take advantage of statistical multiplexing gains that
might otherwise be missed. might otherwise be missed.
2.3.5.2. Interaction with complex admission policies, AAA, and 2.3.5.2. Interaction with Complex Admission Policies, AAA, and
preemption of bandwidth Preemption of Bandwidth
Policy is carried and applied as described in [RFC2753]. Figure 4 Policy is carried and applied as described in [RFC2753]. Figure 4,
below is the basic conceptual model for policy decisions and below, is the basic conceptual model for policy decisions and
enforcement in an Integrated Services model. This model was created enforcement in an Integrated Services model. This model was created
to provide ability to monitor and control reservation flows based on to provide the ability to monitor and control reservation flows based
user identify, specific traffic and security requirements and on user identify, specific traffic and security requirements, and
conditions which might change for various reasons, including as a conditions that might change for various reasons, including a
reaction to a disaster or emergency event involving the network or reaction to a disaster or emergency event involving the network or
its users. its users.
Network Node Policy server Network Node Policy server
______________ ______________
| ______ | | ______ |
| | | | _____ | | | | _____
| | PEP | | | |-------------> | | PEP | | | |------------->
| |______|<---|------>| PDP |May use LDAP,SNMP,COPS... for accessing | |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc. | ^ | | | policy database, authentication, etc.
| | | |_____|-------------> | | | |_____|------------->
| __v___ | | __v___ |
| | | | PDP = Policy Decision Point | | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point | | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point | |______| | LPDP = Local Policy Decision Point
|______________| |______________|
Figure 4: Conceptual Model for Policy Control of Routers Figure 4: Conceptual Model for Policy Control of Routers
The Network Node represents a router in the network. The Policy The Network Node represents a router in the network. The Policy
Server represents the point of admission and policy control by the Server represents the point of admission and policy control by the
network operator. Policy Enforcement Point (PEP)(the router) is network operator. Policy Enforcement Point (PEP)(the router) is
where the policy action is carried out. Policy decisions can be where the policy action is carried out. Policy decisions can be
either locally present in the form of a Local Policy Decision Point either locally present in the form of a Local Policy Decision Point
(LPDP), or in a separate server on the network called the Policy (LPDP), or in a separate server on the network called the Policy
Decision Point. The easier the instruction set of rules, the more Decision Point. The easier the instruction set of rules, the more
likely this set can reside in the LDPD for speed of access reasons. likely this set can reside in the LPDP for speed of access reasons.
The more complex the rule set, the more likely this is active on a The more complex the rule set, the more likely this is active on a
remote server. The PDP will use other protocols (LDAP, SNMP, etc) to remote server. The PDP will use other protocols (LDAP, SNMP, etc.)
request information (e.g. user authentication and authorization for to request information (e.g., user authentication and authorization
precedence level usage) to be used in creating the rule sets of for precedence level usage) to be used in creating the rule sets of
network components. This remote PDP should also be considered where network components. This remote PDP should also be considered where
non-reactive policies are distributed out to the LPDPs. non-reactive policies are distributed out to the LPDPs.
Taking the above model as a framework, [RFC2750] extends RSVP's Taking the above model as a framework, [RFC2750] extends RSVP's
concept of a simple reservation to include policy controls, including concept of a simple reservation to include policy controls, including
the concepts of Preemption [RFC3181] and Identity [RFC3182], the concepts of Preemption [RFC3181] and Identity [RFC3182],
specifically speaking to the usage of policies which preempt calls specifically speaking to the usage of policies that preempt calls
under the control of either a local or remote policy manager. The under the control of either a local or remote policy manager. The
policy manager assigns a precedence level to the admitted data flow. policy manager assigns a precedence level to the admitted data flow.
If it admits a data flow that exceeds the available capacity of a If it admits a data flow that exceeds the available capacity of a
system, the expectation is that the RSVP affected RSVP process will system, the expectation is that the RSVP-affected RSVP process will
tear down a session among the lowest precedence sessions it has tear down a session among the lowest precedence sessions it has
admitted. The RESV Error resulting from that will go to the receiver admitted. The RESV Error resulting from that will go to the receiver
of the data flow, and be reported to the application (SIP or H.323). of the data flow and be reported to the application (SIP or H.323).
That application is responsible to disconnect its call, with a reason That application is responsible for disconnecting its call, with a
code of "bandwidth preemption". reason code of "bandwidth preemption".
2.4. Authentication and authorization of calls placed 2.4. Authentication and Authorization of Calls Placed
It will be necessary, of course, to ensure that any policy is applied It will be necessary, of course, to ensure that any policy is applied
to an authenticated user; it is the capabilities assigned to an to an authenticated user; the capabilities assigned to an
authenticated user that may be considered to have been authorized for authenticated user may be considered authorized for use in the
use in the network. For bandwidth admission, this will require the network. For bandwidth admission, this will require the utilization
utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures will also
will also be needed. be needed.
2.5. Defined User Interface 2.5. Defined User Interface
The user interface - the chimes and tones heard by the user - should The user interface -- the chimes and tones heard by the user --
ideally remain the same as in the PSTN for those indications that are should ideally remain the same as in the PSTN for those indications
still applicable to an IP network. There should be some new effort that are still applicable to an IP network. There should be some new
generated to update the list of announcements sent to the user which effort generated to update the list of announcements sent to the user
don't necessarily apply. All indications to the user, of course, that don't necessarily apply. All indications to the user, of
depend on positive signals, not unreliable measures based on changing course, depend on positive signals, not unreliable measures based on
measurements. changing measurements.
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations 3. Security Considerations
This document outlines a networking capability composed entirely of This document outlines a networking capability composed entirely of
existing specifications. It has significant security issues, in the existing specifications. It has significant security issues, in the
sense that a failure of the various authentication or authorization sense that a failure of the various authentication or authorization
procedures can cause a fundamental breakdown in communications. procedures can cause a fundamental breakdown in communications.
However, the issues are internal to the various component protocols, However, the issues are internal to the various component protocols
and are covered by their various security procedures. and are covered by their various security procedures.
5. Acknowledgements 4. Acknowledgements
This document was developed with the knowledge and input of many This document was developed with the knowledge and input of many
people, far too numerous to be mentioned by name. Key contributors people, far too numerous to be mentioned by name. However, key
of thoughts include, however, Francois Le Faucheur, Haluk Keskiner, contributors of thoughts include Francois Le Faucheur, Haluk
Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan, and Tony Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan,
De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce provided and Tony De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce
useful reviews. provided useful reviews.
6. References 5. References
6.1. Normative References 5.1. Normative References
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements
Emergency Telecommunication Service (ETS)", RFC 3689, for Emergency Telecommunication Service (ETS)", RFC
February 2004. 3689, February 2004.
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony
for Emergency Telecommunication Service (ETS)", RFC 3690, Requirements for Emergency Telecommunication
February 2004. Service (ETS)", RFC 3690, February 2004.
6.2. Integrated Services Architecture References Integrated Services Architecture References
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an
RFC 1633, June 1994. Overview", RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Functional Specification", RFC 2205, September 1997. Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for
Data Flows", RFC 2207, September 1997. IPSEC Data Flows", RFC 2207, September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S.,
M., Romanow, A., Weinrib, A., and L. Zhang, "Resource O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
ReSerVation Protocol (RSVP) Version 1 Applicability "Resource ReSerVation Protocol (RSVP) Version 1
Statement Some Guidelines on Deployment", RFC 2208, Applicability Statement Some Guidelines on
September 1997. Deployment", RFC 2208, September 1997.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, Protocol (RSVP) -- Version 1 Message Processing
September 1997. Rules", RFC 2209, September 1997.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000. Cryptographic Authentication", RFC 2747, January
2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000. RFC 2750, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
for Policy-based Admission Control", RFC 2753, Framework for Policy-based Admission Control", RFC
January 2000. 2753, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
November 2000. 2996, November 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Zhang, L., Speer, M., Braden, R., Davie, B.,
Felstaine, "A Framework for Integrated Services Operation Wroclawski, J., and E. Felstaine, "A Framework for
over Diffserv Networks", RFC 2998, November 2000. Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC
April 2001. 3097, April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
"Aggregation of RSVP for IPv4 and IPv6 Reservations", Davie, "Aggregation of RSVP for IPv4 and IPv6
RFC 3175, September 2001. Reservations", RFC 3175, September 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy
RFC 3181, October 2001. Element", RFC 3181, October 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
Herzog, S., and R. Hess, "Identity Representation for Moore, T., Herzog, S., and R. Hess, "Identity
RSVP", RFC 3182, October 2001. Representation for RSVP", RFC 3182, October 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session
Protocol (SIP)", RFC 3312, October 2002. Initiation Protocol (SIP)", RFC 3312, October 2002.
6.3. Differentiated Services Architecture References Differentiated Services Architecture References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field
Field) in the IPv4 and IPv6 Headers", RFC 2474, (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E.,
and W. Weiss, "An Architecture for Differentiated Wang, Z., and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998. Differentiated Services", RFC 2475, December 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, October 2000.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
J., Courtney, W., Davari, S., Firoiu, V., and D. Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
Stiliadis, "An Expedited Forwarding PHB (Per-Hop and D. Stiliadis, "An Expedited Forwarding PHB
Behavior)", RFC 3246, March 2002. (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J.,
Definition of the EF PHB (Expedited Forwarding Per-Hop Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
Behavior)", RFC 3247, March 2002. Kalmanek, C., and K. Ramakrishnan, "Supplemental
Information for the New Definition of the EF PHB
(Expedited Forwarding Per-Hop Behavior)", RFC 3247,
March 2002.
6.4. Session Initiation Protocol and related References Session Initiation Protocol and Related References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Johnston, A., Peterson, J., Sparks, R., Handley,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, M., and E. Schooler, "SIP: Session Initiation
June 2002. Protocol", RFC 3261, June 2002.
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) [RFC4411] Polk, J., "Extending the Session Initiation
Reason Header for Preemption Events", RFC 4411, Protocol (SIP) Reason Header for Preemption
February 2006. Events", RFC 4411, February 2006.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications
Priority for the Session Initiation Protocol (SIP)", Resource Priority for the Session Initiation
RFC 4412, February 2006. Protocol (SIP)", RFC 4412, February 2006.
6.5. Informative References 5.2. Informative References
[ANSI.MLPP.Spec] American National Standards Institute, [ANSI.MLPP.Spec] American National Standards Institute,
"Telecommunications - Integrated Services "Telecommunications - Integrated Services Digital
Digital Network (ISDN) - Multi-Level Network (ISDN) - Multi-Level Precedence and
Precedence and Preemption (MLPP) Service Preemption (MLPP) Service Capability", ANSI
Capability", ANSI T1.619-1992 (R1999), 1992. T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement] American National Standards Institute, "MLPP
Service Domain Cause Value Changes",
ANSI ANSI T1.619a-1994 (R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", [ANSI.MLPP.Supp] American National Standards Institute, "MLPP
January 2003, <http://www.sygnusdata.co.uk/ Service Domain Cause Value Changes", ANSI ANSI
white_papers/viola/ T1.619a-1994 (R1999), 1990.
netally_voip_sample_report_preliminary.pdf>.
[G711.2] IEPSI Tiphon, "IEPSI Tiphon Temporary [G711.1] Viola Networks, "Netally VoIP Evaluator", January
Document 64", July 1999, <http:// 2003, <http://www.brainworks.de/Site/hersteller/
docbox.etsi.org/tiphon/tiphon/archives/1999/ viola_networks/Dokumente/Compr_Report_Sample.pdf>.
05-9907-Amsterdam/14TD113.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss [G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http:// Concealment", 2000, <http://www.nortelnetworks.com/
www.nortelnetworks.com/products/01/ products/01/succession/es/collateral/
succession/es/collateral/tb_pktloss.pdf>. tb_pktloss.pdf>.
[ITU.ETS.E106] International Telecommunications Union, [ITU.ETS.E106] International Telecommunications Union,
"International Emergency Preference Scheme "International Emergency Preference Scheme for
for disaster relief operations (IEPS)", ITU- disaster relief operations (IEPS)", ITU-T
T Recommendation E.106, October 2003. Recommendation E.106, October 2003.
[ITU.MLPP.1990] International Telecommunications Union, [ITU.MLPP.1990] International Telecommunications Union, "Multilevel
"Multilevel Precedence and Preemption Service Precedence and Preemption Service (MLPP)", ITU-T
(MLPP)", ITU-T Recommendation I.255.3, 1990. Recommendation I.255.3, 1990.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized [Parekh1] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Multiple Integrated Services Networks: The Multiple Node
Node Case", INFOCOM 1993: 521-530, 1993. Case", INFOCOM 1993: 521-530, 1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized [Parekh2] Parekh, A. and R. Gallager, "A Generalized
Processor Sharing Approach to Flow Control in Processor Sharing Approach to Flow Control in
Integrated Services Networks: The Single Node Integrated Services Networks: The Single Node
Case", INFOCOM 1992: 915-924, 1992. Case", INFOCOM 1992: 915-924, 1992.
Appendix A. 2-Call Preemption Example using RSVP Appendix A. 2-Call Preemption Example Using RSVP
This appendix will present a more complete view of the interaction This appendix will present a more complete view of the interaction
between SIP, SDP and RSVP. The bulk of the material is referenced among SIP, SDP, and RSVP. The bulk of the material is referenced
from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be
some discussion on basic RSVP operations regarding reservation paths, some discussion on basic RSVP operations regarding reservation paths;
this will be mostly from [RFC2205]. this will be mostly from [RFC2205].
SIP signaling occurs at the Application Layer, riding on a UDP/IP or SIP signaling occurs at the Application Layer, riding on a UDP/IP or
TCP/IP (including TLS/TCP/IP) transport that is bound by routing TCP/IP (including TLS/TCP/IP) transport that is bound by routing
protocols such as BGP and OSPF to determine the route the packets protocols such as BGP and OSPF to determine the route the packets
traverse through a network between source and destination devices. traverse through a network between source and destination devices.
RSVP is riding on top of IP as well, which means RSVP is at the mercy RSVP is riding on top of IP as well, which means RSVP is at the mercy
of the IP routing protocols to determine a path through the network of the IP routing protocols to determine a path through the network
between endpoints. RSVP is not a routing protocol. In this appendix between endpoints. RSVP is not a routing protocol. In this
there will be a escalation of building blocks getting to how the many appendix, there will be an escalation of building blocks getting to
layers are involved in SIP with QoS Preconditions requiring how the many layers are involved in SIP. QoS Preconditions require
successful RSVP signaling between endpoints prior to SIP successfully successful RSVP signaling between endpoints prior to SIP successfully
acknowledging the set-up of the session (for voice or video or both). acknowledging the setup of the session (for voice, video, or both).
Then we will present what occurs when a network overload occurs Then we will present what occurs when a network overload occurs
(congestion), causing a SIP session to be preempted. (congestion), causing a SIP session to be preempted.
There are three diagrams in this appendix to show multiple views of Three diagrams in this appendix show multiple views of the same
the same example of connectivity for discussion throughout this example of connectivity for discussion throughout this appendix. The
appendix. The first diagram (Figure 5) is of many routers between first diagram (Figure 5) is of many routers between many endpoints
many endpoints (SIP user agents, or UAs). There are 4 UAs of (SIP user agents, or UAs). There are 4 UAs of interest; those are
interest, those are for users Alice, Bob, Carol and Dave. When a for users Alice, Bob, Carol, and Dave. When a user (the human) of a
user (the human) of a UA gets involved and must do something to a UA UA gets involved and must do something to a UA to progress a SIP
to progress a SIP process, this will be explicitly mentioned to avoid process, this will be explicitly mentioned to avoid confusion;
confusion; otherwise, when Alice is referred to - this means Alice's otherwise, when Alice is referred to, it means Alice's UA (her
UA (her phone) in the text here. phone).
RSVP reserves bandwidth in one direction only (the direction of the RSVP reserves bandwidth in one direction only (the direction of the
RESV message), as has been discussed, IP forwarding of packets are RESV message), as has been discussed, IP forwarding of packets are
dictated by the routing protocol for that portion of the dictated by the routing protocol for that portion of the
infrastructure from the point of view of where the packet is to go infrastructure from the point of view of where the packet is to go
next. next.
The RESV message traverses the routers in the reverse path taken by The RESV message traverses the routers in the reverse path taken by
the PATH message. The PATH message establishes a record of the route the PATH message. The PATH message establishes a record of the route
taken through a network portion to the destination endpoint, but it taken through a network portion to the destination endpoint, but it
skipping to change at page 34, line 7 skipping to change at page 31, line 7
Dave to Carol will be through routers: Dave to Carol will be through routers:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol Dave -> R8 -> R3 -> R2 -> R5 -> Carol
The reservations from Alice to Bob traverse a common router link: The reservations from Alice to Bob traverse a common router link:
between R3 and R2 and thus a common interface at R2. Here is where between R3 and R2 and thus a common interface at R2. Here is where
there will be congestion in this example, on the link between R2 and there will be congestion in this example, on the link between R2 and
R3. Since the flow of data (in this case voice media packets) R3. Since the flow of data (in this case voice media packets)
travels the direction of the PATH message, and RSVP establishes travels the direction of the PATH message, and RSVP establishes
reservation of resources at the egress interface of a router, the reservation of resources at the egress interface of a router, the
interface in Figure 6 shows Int7 to be what will first know about a interface in Figure 6 shows that Int7 will be what first knows about
congestion condition. a congestion condition.
Alice Bob Alice Bob
\ / \ /
\ / \ /
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
| R2 | | R3 | | R2 | | R3 |
| Int7-------Int5 | | Int7-------Int5 |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
/ \ / \
/ \ / \
Carol Dave Carol Dave
Figure 6: Reduced Reservation Topology Figure 6: Reduced Reservation Topology
From Figure 6, the messaging between the UAs and the RSVP messages Figure 6 illustrates how the messaging between the UAs and the RSVP
between the relevant routers can be shown to understand the binding messages between the relevant routers can be shown to understand the
that was established in [RFC3312] "SIP Preconditions for QoS". binding that was established in [RFC3312] (more suitably titled "SIP
Preconditions for QoS" from this document's point of view).
We will assume all devices have powered up, and received whatever We will assume all devices have powered up and received whatever
registration or remote policy downloads were necessary for proper registration or remote policy downloads were necessary for proper
operation. The routing protocol of choice has performed its routing operation. The routing protocol of choice has performed its routing
table update throughout this part of the network. Now we are left to table update throughout this part of the network. Now we are left to
focus only on end-to-end communications and how that affects the focus only on end-to-end communications and how that affects the
infrastructure between endpoints. infrastructure between endpoints.
The next diagram (Figure 7 ) (nearly identical to Figure 1 from The next diagram (Figure 7 ) (nearly identical to Figure 1 from
[RFC3312])shows the minimum SIP messaging (at layer 7) between Alice [RFC3312])shows the minimum SIP messaging (at layer 7) between Alice
and Bob for a good quality voice call. The SIP messages are numbered and Bob for a good-quality voice call. The SIP messages are numbered
to identify special qualities are each. During the SIP signaling, to identify special qualities of each. During the SIP signaling,
RSVP will be initiated. That messaging will also be discussed below. RSVP will be initiated. That messaging will also be discussed below.
UA Alice UA Bob UA Alice UA Bob
| | | |
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | Note 1 | | Note 1
|<------(2) 183 Session Progress SDP2--------| | |<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+ ***|********************************************|***<-+
* |----------------(3) PRACK------------------>| * * |----------------(3) PRACK------------------>| *
skipping to change at page 35, line 47 skipping to change at page 32, line 47
Figure 7: SIP Reservation Establishment Using Preconditions Figure 7: SIP Reservation Establishment Using Preconditions
The session initiation starts with Alice wanting to communicate with The session initiation starts with Alice wanting to communicate with
Bob. Alice decides on an IEPS precedence level for their call (the Bob. Alice decides on an IEPS precedence level for their call (the
default is the "routine" level, which is for normal everyday calls, default is the "routine" level, which is for normal everyday calls,
but a priority level has to be chosen for each call). Alice puts but a priority level has to be chosen for each call). Alice puts
into her UA Bob's address and precedence level and (effectively) hits into her UA Bob's address and precedence level and (effectively) hits
the send button. This is reflected in SIP with an INVITE Method the send button. This is reflected in SIP with an INVITE Method
Request message [M1]. Below is what SIP folks call a well-formed SIP Request message [M1]. Below is what SIP folks call a well-formed SIP
message (meaning it has all the headers that are mandatory to message (meaning it has all the headers that are mandatory to
function properly). We will pick on the USMC for the addressing of function properly). We will pick on the US Marine Corps (USMC) for
this message exchange. the addressing of this message exchange.
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory] [M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0 INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil> To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE CSeq: 31862 INVITE
Requires: 100rel, preconditions, resource-priority Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil> Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 191 Content-Length: 191
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 8 m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper From the INVITE above, Alice is inviting Bob to a session. The upper
skipping to change at page 36, line 29 skipping to change at page 33, line 30
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 8 m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper From the INVITE above, Alice is inviting Bob to a session. The upper
half of the lines (above the line 'v=0') are SIP headers and header half of the lines (above the line "v=0") is SIP headers and header
values, the lower half of the lines above are Session Description values, and the lower half is Session Description Protocol (SDP)
Protocol (SDP) lines. SIP headers (after the first line, called the lines. SIP headers (after the first line, called the Status line)
Status line) are not mandated in any particular order, with one are not mandated in any particular order, with one exception: the Via
exception: the Via header. It is a SIP hop (through a SIP Proxy) header. It is a SIP hop (through a SIP Proxy) route path that has a
route path that has a new Via header line added by each SIP element new Via header line added by each SIP element this message traverses
this message traverses towards the destination UA. This is similar towards the destination UA. This is similar in function to an RSVP
in function to an RSVP PATH message (building a reverse path back to PATH message (building a reverse path back to the originator of the
the originator of the message). At any point in the message's path, message). At any point in the message's path, a SIP element knows
a SIP element knows the path to the originator of the message. There the path to the originator of the message. There will be no SIP
will be no SIP Proxies in this example, because for Preconditions, Proxies in this example, because for Preconditions, Proxies only make
Proxies only make more messages that look identical (with the more messages that look identical (with the exception of the Via and
exception of the Via and Max-Forwards headers), and that is not worth Max-Forwards headers), and it is not worth the space here to
the space here to replicate what has been done in SIP RFCs already. replicate what has been done in SIP RFCs already.
SIP headers that are used for Preconditions are the: SIP headers that are used for Preconditions are as follows:
Requires header - which mandates a reliable provisional response o Require header, which contains 3 option tags: "100rel" mandates a
message to the conditions requesting in this INVITE (knowing they reliable provisional response message to the conditions requesting
are special), mandates that preconditions are attempted, and in this INVITE (knowing they are special), "preconditions"
mandates that preconditions are attempted, and "resource-priority"
mandates support for the Resource-Priority header. Each of these mandates support for the Resource-Priority header. Each of these
option-tags can be explicitly identified in a message failure option tags can be explicitly identified in a message failure
indication from the called UA to tell the calling UA what was not indication from the called UA to tell the calling UA exactly what
supported. was not supported.
Provided this INVITE message is received as acceptable, this will Provided that this INVITE message is received as acceptable, this
result in the 183 "Session Progress" message from Bob's UA as a will result in the 183 "Session Progress" message from Bob's UA, a
reliable confirmation that preconditions are required for this call. reliable confirmation that preconditions are required for this
call.
- Resource-Priority header - which denotes the domain namespace o Resource-Priority header, which denotes the domain namespace and
and precedence level of the call on an end-to-end basis. precedence level of the call on an end-to-end basis.
This completes SIPs functions in session initiation. Preconditions This completes SIP's functions in session initiation. Preconditions
are requested, required and signaled for in the SDP portion of the are requested, required, and signaled for in the SDP portion of the
message. SDP is carried in what's called a SIP message body (much message. SDP is carried in what's called a SIP message body (much
like the text in an email message is carried). SDP has special like the text in an email message is carried). SDP has special
properties [see [RFC2327] for more on SDP, or the MMUSIC WG for properties (see [RFC2327] for more on SDP, or the MMUSIC WG for
ongoing efforts regarding SDP]. SDP lines are in a specific order ongoing efforts regarding SDP). SDP lines are in a specific order
for parsing reasons by end systems. Dialog (Call) generating SDP for parsing by end systems. Dialog-generating (or call-generating)
message bodies all must have an "m" line (or media description line). SDP message bodies all must have an "m=" line (or media description
Following the "m" line is zero or more "a" lines (or Attribute line). Following the "m=" line are zero or more "a=" lines (or
lines). The m-line in Alice's INVITE calls for a voice session (this Attribute lines). The "m=" line in Alice's INVITE calls for a voice
is where video is identified also) using one of 3 different codecs session (this is where video is identified also) using one of 3
that Alice supports (0 = G.711, 4 = G.723 and 18 = G.729) that Bob different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 =
gets to choose from for this session. Bob can choose any of the 3. G.729) that Bob gets to choose from for this session. Bob can choose
The first a=rtpmap line is specific to the type of codec these 3 are any of the 3. The first a=rtpmap line is specific to the type of
(PCMU). The next two a-lines are the only identifiers that RSVP is codec these 3 are (PCMU). The next two "a=" lines are the only
to be used for this call. The second a-line: identifiers that RSVP is to be used for this call. The second "a="
line:
a=curr:qos e2e none a=curr:qos e2e none
identifies the "current" status of qos at Alice's UA. Note: identifies the "current" status of qos at Alice's UA. Note:
everything in SDP is with respect to the sender of the SDP message everything in SDP is with respect to the sender of the SDP message
body (Alice will never tell Bob how his SDP is, she will only tell body (Alice will never tell Bob how his SDP is; she will only tell
Bob about her SDP). Bob about her SDP).
"e2e" means that capacity assurance is required from Alice's UA to "e2e" means that capacity assurance is required from Alice's UA to
Bob's UA; meaning a lack of available capacity assurance in either Bob's UA; thus, a lack of available capacity assurance in either
direction will fail the call attempt. direction will fail the call attempt.
"none" means there is no reservation at Alice's UA (to Bob) at "none" means there is no reservation at Alice's UA (to Bob) at
this time. this time.
The final a-line (a=des): The final "a=" line (a=des) identifies the "desired" level of qos:
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
identifies the "desired" level of qos "mandatory" means this request for qos MUST be successful, or the
"mandatory" means this request for qos MUST be successful or the
call fails. call fails.
"e2e" means RSVP is required from Alice's UA to Bob's UA "e2e" means RSVP is required from Alice's UA to Bob's UA.
"sendrecv" means the reservation is in both directions. "sendrecv" means the reservation is in both directions.
As discussed, RSVP does not reserve bandwidth in both directions, and As discussed, RSVP does not reserve bandwidth in both directions, and
that it is up to the endpoints to have 2 one-way reservations if that it is up to the endpoints to have 2 one-way reservations if that
particular application (here voice) requires it. Voice between Alice particular application (here, voice) requires it. Voice between
and Bob requires 2 one-way reservations. The UAs will be the focal Alice and Bob requires 2 one-way reservations. The UAs will be the
points for both reservations in both directions. focal points for both reservations in both directions.
Message 2 is the 183 "Session Progress" message sent by Bob to Alice Message 2 is the 183 "Session Progress" message sent by Bob to Alice,
that indicates to Alice that Bob understands that preconditions are which indicates to Alice that Bob understands that preconditions are
required for this call. required for this call.
[M2 - 183 "Session Progress"] [M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33 ;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356 To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE CSeq: 31862 INVITE
skipping to change at page 38, line 32 skipping to change at page 35, line 42
;branch=z9hG4bK74bf9 ;received=10.1.3.33 ;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356 To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE CSeq: 31862 INVITE
RSeq: 813520 RSeq: 813520
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil> Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 210 Content-Length: 210
v=0 v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51 c=IN IP4 10.100.50.51
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
Figure 9
The only interesting header in the SIP portion of this message is the The only interesting header in the SIP portion of this message is the
RSeq header, which is the "Reliable Sequence" header. The value is RSeq header, which is the "Reliable Sequence" header. The value is
incremented for every Reliable message that's sent in this call incremented for every Reliable message that's sent in this call setup
set-up (to make sure none are lost, or to ignore duplicates). (to make sure none are lost or to ignore duplicates).
Bob's SDP indicates several a-line statuses and picks a codec for the Bob's SDP indicates several "a=" line statuses and picks a codec for
call. The codec picked is in the m=audio line (the "0" at the end of the call. The codec picked is in the m=audio line (the "0" at the
this line means G.711 will be the codec). end of this line means G.711 will be the codec).
The a=curr line gives Alice Bob's status with regard to RSVP The a=curr line gives Alice Bob's status with regard to RSVP
(currently "none"). (currently "none").
The a=des line also states the desire for mandatory qos e2e in both The a=des line also states the desire for mandatory qos e2e in both
directions. directions.
The a=conf line is new. This line means Bob wants confirmation that The a=conf line is new. This line means Bob wants confirmation that
Alice has 2 one-way reservations before Bob's UA proceeds with the Alice has 2 one-way reservations before Bob's UA proceeds with the
SIP session set-up. SIP session setup.
This is where "Note-1" applies in Figure 7. At the point that Bob's This is where "Note-1" applies in Figure 7. At the point that Bob's
UA transmits this 183 message, Bob's UA (the one that picked the UA transmits this 183 message, Bob's UA (the one that picked the
codec, so it knows the amount of bandwidth to reserve) transmits an codec, so it knows the amount of bandwidth to reserve) transmits an
RSVP PATH message to Alice's UA. This PATH message will take the RSVP PATH message to Alice's UA. This PATH message will take the
route previously discussed in Figure 5: route previously discussed in Figure 5:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice Bob -> R4 -> R3 -> R2 -> R1 -> Alice
This is the path of the PATH message, and the reverse will be the This is the path of the PATH message, and the reverse will be the
path of the reservation set up RESV message, or: path of the reservation set up RESV message, or:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Immediately after Alice transmits the RESV message towards Bob, Alice Immediately after Alice transmits the RESV message towards Bob, Alice
sends her own PATH message to initiate the other one-way reservation. sends her own PATH message to initiate the other one-way reservation.
Bob, receiving that PATH message, will reply with a RESV. Bob, receiving that PATH message, will reply with a RESV.
All this is independent of SIP. But during this time of reservation All this is independent of SIP. However, during this time of
establishment, a Provisional Acknowledgment (PRACK) [M3] is sent from reservation establishment, a Provisional Acknowledgement (PRACK) [M3]
Alice to Bob to confirm the request for confirmation of 2 one-way is sent from Alice to Bob to confirm the request for confirmation of
reservations at Alice's UA. This message is acknowledged with a 2 one-way reservations at Alice's UA. This message is acknowledged
normal 200 OK message [M4]. This is shown in Figure 7. with a normal 200 OK message [M4]. This is shown in Figure 7.
As soon as the RSVP is successfully completed at Alice's UA (knowing As soon as the RSVP is successfully completed at Alice's UA (knowing
it was the last in the two way cycle or reservation establishment), that it was the last in the two-way cycle or reservation
at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform establishment), at the SIP layer an UPDATE message [M5] is sent to
his UA that current status of RSVP (or qos) is "e2e" and "sendrecv". Bob's UA to inform his UA that the current status of RSVP (or qos) is
"e2e" and "sendrecv".
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv] [M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0 UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa ;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil> To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil> Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE CSeq: 10197 UPDATE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 191 Content-Length: 191
v=0 v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e send a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
Figure 10 This is shown by the matching table that can be built from the a=curr
This is shown by the matching table that can be build from the a=curr
line and a=des line. If the two lines match, then no further line and a=des line. If the two lines match, then no further
signaling need take place with regard to "qos". [M6] is the 200 OK signaling needs take place with regard to "qos". [M6] is the 200 OK
acknowledgment of this synchronization between the two UAs. acknowledgement of this synchronization between the two UAs.
[M6 - 200 OK to the UPDATE from Bob indicating synchronization] [M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa ;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil> To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil > Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE CSeq: 10197 UPDATE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 195 Content-Length: 195
v=0 v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
At this point, the reservation is operational and both UAs know it.
Figure 11 Bob's UA now rings, telling Bob the user that Alice is calling him.
At this point, the reservation is operational and both UA's know it, ([M7] is the SIP indication to Alice that this is taking place).
and Bob's UA now rings ([M7] is the SIP indication to Alice this is
taking place) telling Bob the user that Alice is calling her.
Nothing up until now has involved Bob the user. Bob picks up the Nothing up until now has involved Bob the user. Bob picks up the
phone (generating [M10], from which Alice's UA responds with the phone (generating [M10], from which Alice's UA responds with the
final ACK) and RTP is now operating within the reservations between final ACK), and RTP is now operating within the reservations between
the two UAs. the two UAs.
Now we get to Carol calling Dave. Figure 6 shows a common router Now we get to Carol calling Dave. Figure 6 shows a common router
interface for the reservation between Alice to Bob, and one that will interface for the reservation between Alice to Bob, and one that will
also be the route for one of the reservations between Carol to Dave. also be the route for one of the reservations between Carol to Dave.
This interface will experience congestion in our example here. This interface will experience congestion in our example.
Carol is now calling Dave at a Resource-Priority level of "Immediate" Carol is now calling Dave at a Resource-Priority level of
- which is higher in priority than Alice to Bob's "routine". In this "Immediate", which is higher in priority than Alice to Bob's
continuing example, Router 2's Interface-7 is congested and cannot "routine". In this continuing example, Router 2's Interface-7 is
accept any more RSVP traffic. Perhaps the offered load is at congested and cannot accept any more RSVP traffic. Perhaps the
interface capacity. Perhaps Interface-7 is configured with a fixed offered load is at interface capacity. Perhaps Interface-7 is
amount of bandwidth it can allocate for RSVP traffic and has reached configured with a fixed amount of bandwidth it can allocate for RSVP
its maximum without one of the reservations going away through normal traffic, and it has reached its maximum without one of the
termination or forced termination (preemption). reservations going away through normal termination or forced
termination (preemption).
Interface-7 is not so full of offered load that it cannot transmit Interface-7 is not so full of offered load that it cannot transmit
signaling packets, such as Carol's SIP messaging to set up a call to signaling packets, such as Carol's SIP messaging to set up a call to
Dave. This should be by design - that not all RSVP traffic can Dave. This should be by design (that not all RSVP traffic can starve
starve an interface from signaling packets. Carol sends her own an interface from signaling packets). Carol sends her own INVITE
INVITE with the following characteristics important here: with the following important characteristics:
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory] [M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
This packet does *not* affect the reservations between Alice and Bob This packet does *not* affect the reservations between Alice and Bob
(SIP and RSVP are at different layers, and all routers are passing (SIP and RSVP are at different layers, and all routers are passing
signaling packets without problems). Dave sends his M2: signaling packets without problems). Dave sends his M2:
[M2 - 183 "Session Progress"] [M2 - 183 "Session Progress"]
with the SDP chart of: with the SDP chart of:
skipping to change at page 41, line 47 skipping to change at page 39, line 4
[M2 - 183 "Session Progress"] [M2 - 183 "Session Progress"]
with the SDP chart of: with the SDP chart of:
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
indicating he understands RSVP reservations are required e2e for this indicating he understands RSVP reservations are required e2e for this
call to be considered successful. Dave sends his PATH message. The call to be considered successful. Dave sends his PATH message. The
PATH message does *not* affect Alice's reservation, it merely PATH message does *not* affect Alice's reservation; it merely
establishes a path for the RESV reservation set-up message to take. establishes a path for the RESV reservation setup message to take.
To keep this example simple, the PATH message from Dave to Carol took To keep this example simple, the PATH message from Dave to Carol took
this route (which we make different from the route in the reverse this route (which we make different from the route in the reverse
direction): direction):
Dave -> R8 -> R7 -> R6 -> R5 -> Carol Dave -> R8 -> R7 -> R6 -> R5 -> Carol
causing the reservation to be this route: causing the reservation to be this route:
Carol -> R5 -> R6 -> R7 -> R8 -> Dave Carol -> R5 -> R6 -> R7 -> R8 -> Dave
The reservation above in this direction (Dave to will not traverse The Carol-to-Dave reservation above will not traverse any of the same
any of the same routers as the Alice to Bob reservations. When Carol routers as the Alice-to-Bob reservation. When Carol transmits her
transmits her RESV message towards Dave, she immediately transmits RESV message towards Dave, she immediately transmits her PATH message
her PATH message to set up the complementary reservation. to set up the complementary reservation.
The PATH message from Carol to Dave be through routers: The PATH message from Carol to Dave be through routers:
Carol -> R5 -> R2 -> R3 -> R8 -> Dave Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Thus, the RESV message will be through routers: Thus, the RESV message will be through routers:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol Dave -> R8 -> R3 -> R2 -> R5 -> Carol
This RESV message will traverse the same routers R3 and R2 as the This RESV message will traverse the same routers, R3 and R2, as the
Alice to Bob reservation. This RESV message, when received at Int-7 Alice-to-Bob reservation. This RESV message, when received at
of R2, will create a congestion situation such that R2 will need to Interface-7 of R2, will create a congestion situation such that R2
make a decision on whether: will need to make a decision on whether:
o to keep the Alice to Bob reservation and error the new RESV from o to keep the Alice-to-Bob reservation and error the new RESV from
Dave, or Dave, or
o to error the reservation from Alice to Bob in order to make room o to error the reservation from Alice to Bob in order to make room
for the Carol to Dave reservation for the Carol-to-Dave reservation.
Alice's reservation was set up in SIP at the "routine" precedence Alice's reservation was set up in SIP at the "routine" precedence
level. This will equate to a comparable RSVP priority number (RSVP level. This will equate to a comparable RSVP priority number (RSVP
has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV
equates to a precedence value of "immediate", which is a higher equates to a precedence value of "immediate", which is a higher
priority. Thus, R2 will preempt the reservation from Alice to Bob, priority. Thus, R2 will preempt the reservation from Alice to Bob
and allow the reservation request from Dave to Carol. The proper and allow the reservation request from Dave to Carol. The proper
RSVP error is the ResvErr that indicates preemption. This message RSVP error is the ResvErr that indicates preemption. This message
travels downstream towards the originator of the RESV message (Bob). travels downstream towards the originator of the RESV message (Bob).
This clears the reservation in all routers downstream of R2 (meaning This clears the reservation in all routers downstream of R2 (meaning
R3 and R4). Once Bob receives the ResvErr message indicating R3 and R4). Once Bob receives the ResvErr message indicating
preemption has occurred on this reservation, Bob's UA transmits a SIP preemption has occurred on this reservation, Bob's UA transmits a SIP
preemption indication back towards Alice's UA. This accomplishes two preemption indication back towards Alice's UA. This accomplishes two
things: first it informs all SIP Servers that were in the session things: first, it informs all SIP Servers that were in the session
set-up path that wanted to remain "dialog stateful" per [RFC3261], setup path that wanted to remain "dialog stateful" per [RFC3261], and
and informs Alice's UA that this was a purposeful termination, and to second, it informs Alice's UA that this was a purposeful termination,
play a preemption tone. The proper indication in SIP of this and to play a preemption tone. The proper indication in SIP of this
termination due to preemption is a BYE Method message that includes a termination due to preemption is a BYE Method message that includes a
Reason Header indicating why this occurred (in this case, "Reserved Reason Header indicating why this occurred (in this case, "Reserved
Resources Preempted". Here is that message from Bob to Alice that Resources Preempted"). Here is the message from Bob to Alice that
terminates the call in SIP. terminates the call in SIP.
BYE sip:alice@usmc.example.mil SIP/2.0 BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma ;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil> To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774 From: Bob <sip:bob@usmc.example.mil>;tag=192820774
Reason: preemption ;cause=2 ;text=reserved resourced preempted Reason: preemption ;cause=2 ;text=reserved resourced preempted
Call-ID: a84b4c76e66710@swp34.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 6187 BYE CSeq: 6187 BYE
Contact: <sip:bob@usmc.example.mil> Contact: <sip:bob@usmc.example.mil>
When Alice's UA receives this message, her UA terminates the call, When Alice's UA receives this message, her UA terminates the call,
sends a 200 OK to Bob to confirm reception of the BYE message, and sends a 200 OK to Bob to confirm reception of the BYE message, and
plays a preemption tone to Alice the user. plays a preemption tone to Alice the user.
The RESV message from Dave successfully traverses R2 and Carol's UA The RESV message from Dave successfully traverses R2, and Carol's UA
receives it. Just as with the Alice to Bob call set-up, Carol sends receives it. Just as with the Alice-to-Bob call setup, Carol sends
an UPDATE message to Dave confirming she has QoS "e2e" in "sendrecv" an UPDATE message to Dave, confirming she has QoS "e2e" in "sendrecv"
directions. Bob acknowledges this with a 200 OK that gives his directions. Bob acknowledges this with a 200 OK that gives his
current status (QoS "e2e" and "sendrecv"), and the call set-up in SIP current status (QoS "e2e" and "sendrecv"), and the call setup in SIP
continues to completion. continues to completion.
In summary, Alice set up a call to Bob with RSVP at a priority level In summary, Alice set up a call to Bob with RSVP at a priority level
of Routine. When Carol called Dave at a high priority, their call of Routine. When Carol called Dave at a high priority, their call
will preempt any lower priority calls where these is a contention for would have preempted any lower priority calls if there were a
resources. In this case, it occurred and affected the call between contention for resources. In this case, it occurred and affected the
Alice and Bob. A router at this congestion point preempted Alice's call between Alice and Bob. A router at this congestion point
call to Bob in order to place the higher priority call between Carol preempted Alice's call to Bob in order to place the higher-priority
and Dave. Alice and Bob were both informed of the preemption event. call between Carol and Dave. Alice and Bob were both informed of the
Both Alice and Bob's UAs played preemption indications. What was not preemption event. Both Alice and Bob's UAs played preemption
mentioned in this appendix was that this document RECOMMENDS router indications. What was not mentioned in this appendix was that this
R2 (in this example) generating a syslog message to the domain document RECOMMENDS that router R2 (in this example) generate a
administrator to properly manage and track such events within this syslog message to the domain administrator to properly manage and
domain. This will ensure the domain administrators have recorded track such events within this domain. This will ensure that the
knowledge of where such events occur, and what the conditions were domain administrators have recorded knowledge of where such events
that caused them. occur, and what the conditions were that caused them.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
skipping to change at page 45, line 45 skipping to change at page 42, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced Administrative Support Activity (IASA).
using xml2rfc v1.31pre5 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
 End of changes. 204 change blocks. 
607 lines changed or deleted 579 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/