draft-ietf-tsvwg-mlpp-that-works-01.txt   draft-ietf-tsvwg-mlpp-that-works-02.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Expires: January 7, 2006 Cisco Systems Expires: February 20, 2006 Cisco Systems
July 6, 2005 August 19, 2005
Implementing MLPP for Voice and Video in the Internet Protocol Suite Implementing an Emergency Telecommunications Service for Real Time
draft-ietf-tsvwg-mlpp-that-works-01 Services in the Internet Protocol Suite
draft-ietf-tsvwg-mlpp-that-works-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2006. This Internet-Draft will expire on February 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Defense Information Systems Agency of the United States RFCs 3689 and 3690 detail requirements for an Emergency
Department of Defense, with its contractors, has proposed a service Telecommunications Service (ETS), of which an Internet Emergency
architecture for military (NATO and related agencies) telephone Preference Service (IEPS) would be a part. Some of these types of
systems. This is called the Assured Service, and is defined in two services require call preemption; others call for call queuing or
documents: "Architecture for Assured Service Capabilities in Voice other mechanisms. The key requirement is to guarantee an elevated
over IP" and "Requirements for Assured Service Capabilities in Voice probability of call completion to an authorized user in time of
over IP". Responding to these are two documents: "Extending the crisis.
Session Initiation Protocol Reason Header to account for Preemption
Events", "Communications Resource Priority for the Session Initiation
Protocol".
What remains to this specification is to provide a Call Admission IEPS requires a Call Admission Control procedure and a Per Hop
Control procedure and a Per Hop Behavior for the data which meet the Behavior for the data which meet the needs of this architecture.
needs of this architecture. Such a CAC procedure and PHB is Such a CAC procedure and PHB is appropriate to any service that might
appropriate to any service that might use H.323 or SIP to set up real use H.323 or SIP to set up real time sessions. These obviously
time sessions. These obviously include but are not limited to Voice include but are not limited to Voice and Video applications, although
and Video applications, although at this writing the community is at this writing the community is mostly thinking about Voice on IP
mostly thinking about Voice on IP and many of the examples in the and many of the examples in the document are taken from that
document are taken from that environment. environment.
In a network where a call that is permitted initially and is not In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be procedures performed only at the time of call setup may be
sufficient. However in a network where sessions' status can be sufficient. However in a network where sessions status can be
reviewed by the network and preempted or denied due to changes in reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls them) or changes in offered load (where higher precedence calls
supercede existing calls), maintaining a continuing model of the supersede existing calls), maintaining a continuing model of the
status of the various calls is required. status of the various calls is required.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4 1.1. Emergency Telecommunications Services . . . . . . . . . . 4
1.2 Definition of Call Admission . . . . . . . . . . . . . . . 6 1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 4
1.3 Assumptions about the Network . . . . . . . . . . . . . . 7 1.1.2. Government Emergency Telecommunications Service . . . 6
1.4 Assumptions about application behavior . . . . . . . . . . 7 1.2. Definition of Call Admission . . . . . . . . . . . . . . . 7
1.5 Desired Characteristics in an Internet Environment . . . . 8 1.3. Assumptions about the Network . . . . . . . . . . . . . . 7
1.6 The use of bandwidth as a solution for QoS . . . . . . . . 9 1.4. Assumptions about application behavior . . . . . . . . . . 8
1.5. Desired Characteristics in an Internet Environment . . . . 9
2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 11 1.6. The use of bandwidth as a solution for QoS . . . . . . . . 10
2.1 Call admission/preemption procedure . . . . . . . . . . . 12
2.2 Voice handling characteristics . . . . . . . . . . . . . . 15
2.3 Bandwidth admission procedure . . . . . . . . . . . . . . 17
2.3.1 Recommended procedure: explicit call admission -
RSVP Admission using Policy . . . . . . . . . . . . . 17
2.3.2 RSVP Scaling Issues . . . . . . . . . . . . . . . . . 19
2.3.3 RSVP Operation in backbones and VPNs . . . . . . . . . 19
2.3.4 Interaction with the Differentiated Services
Architecture . . . . . . . . . . . . . . . . . . . . . 20
2.3.5 Admission policy . . . . . . . . . . . . . . . . . . . 20
2.3.5.1 Admission for variable rate codecs . . . . . . . . 21
2.3.5.2 Interaction with complex admission policies,
AAA, and preemption of bandwidth . . . . . . . . . 22
2.4 Authentication and authorization of calls placed . . . . . 23
2.5 Defined User Interface . . . . . . . . . . . . . . . . . . 23
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Call admission/preemption procedure . . . . . . . . . . . 13
2.2. Voice handling characteristics . . . . . . . . . . . . . . 16
2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 17
2.3.1. RSVP procedure: explicit call admission - RSVP
Admission using Policy . . . . . . . . . . . . . . . . 18
2.3.2. RSVP Scaling Issues . . . . . . . . . . . . . . . . . 20
2.3.3. RSVP Operation in backbones and VPNs . . . . . . . . . 20
2.3.4. Interaction with the Differentiated Services
Architecture . . . . . . . . . . . . . . . . . . . . . 21
2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 21
2.3.5.1. Admission for variable rate codecs . . . . . . . . 22
2.3.5.2. Interaction with complex admission policies,
AAA, and preemption of bandwidth . . . . . . . . . 23
2.4. Authentication and authorization of calls placed . . . . . 24
2.5. Defined User Interface . . . . . . . . . . . . . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Normative References . . . . . . . . . . . . . . . . . . . 27
6.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 28
A. 2-Call Preemption Example using RSVP . . . . . . . . . . . . . 32 Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Overview 1. Overview
The Defense Information Systems Agency of the United States [RFC3689] and [RFC3690] detail requirements for an Emergency
Department of Defense, with is contractors, has proposed a service Telecommunications Service (ETS), of which an Internet Emergency
architecture for military (NATO and related agencies) telephone Preference Service (IEPS) would be a part. Some of these types of
systems. This is called the Assured Service, and is defined in two services require call preemption; others call for call queuing or
documents: [I-D.pierce-ieprep-assured-service-arch] and [I-D.pierce- other mechanisms. The key requirement is to guarantee an elevated
ieprep-assured-service-req]. Responding to these are two documents: probability of call completion to an authorized user in time of
[I-D.ietf-sipping-reason-header-for-preemption] and [I-D.ietf-sip- crisis.
resource-priority].
What remains to this specification is to provide a Call Admission IEPS requires a Call Admission Control procedure and a Per Hop
Control procedure and a Per Hop Behavior for the data which meet the Behavior for the data which meet the needs of this architecture.
needs of this architecture. Such a CAC procedure and PHB is Such a CAC procedure and PHB is appropriate to any service that might
appropriate to any service that might use H.323 or SIP to set up real use H.323 or SIP to set up real time sessions. These obviously
time sessions. These obviously include but are not limited to Voice include but are not limited to Voice and Video applications, although
and Video applications, although at this writing the community is at this writing the community is mostly thinking about Voice on IP
mostly thinking about Voice on IP and many of the examples in the and many of the examples in the document are taken from that
document are taken from that environment. environment.
In a network where a call that is permitted initially and is not In a network where a call permitted initially is not denied or
denied or rejected at a later time, call and capacity admission rejected at a later time, capacity admission procedures performed
procedures performed only at the time of call setup may be only at the time of call setup may be sufficient. However in a
sufficient. However in a network where sessions' status can be network where sessions status can be reviewed by the network and
reviewed by the network and preempted or denied due to changes in preempted or denied due to changes in routing (when the new routes
routing (when the new routes lack capacity to carry calls switched to lack capacity to carry calls switched to them) or changes in offered
them) or changes in offered load (where higher precedence calls load (where higher precedence calls supersede existing calls),
supercede existing calls), maintaining a continuing model of the maintaining a continuing model of the status of the various calls is
status of the various calls is required. required.
1.1 Multi-Level Preemption and Precedence 1.1. Emergency Telecommunications Services
Before doing so, however, let us discuss the problem that MLPP is Before doing so, however, let us discuss the problem that ETS (and
intended to solve and the architecture of the system. The Assured therefore IEPS) is intended to solve and the architecture of the
Service is designed as an IP implementation of an existing ITU-T/ system. The Emergency Telecommunications Service [ITU.ETS.E106] is a
NATO/DoD telephone system architecture known as [ITU.MLPP.1990] successor to and generalization of two services used in the United
[ANSI.MLPP.Spec] [ANSI.MLPP.Supplement], or MLPP. MLPP is an States: Multilevel Preemption and Precedence (MLPP), and the
architecture for a prioritized call handling service such that in Government Emergency Telecommunication Service (GETS). Services
times of emergency in the relevant NATO and DoD commands, the based on these models are also used in a variety of countries
relative importance of various kinds of communications is strictly throughout the world, both PSTN and GSM-based. Both of these
defined, allowing higher precedence communication at the expense of services are designed to enable an authorized user to obtain service
lower precedence communications. These precedences, in descending from the telephone network in times of crisis. They differ primarily
order, are: in the mechanisms used and number of levels of precedence
acknowledged.
1.1.1. Multi-Level Preemption and Precedence
The Assured Service is designed as an IP implementation of an
existing ITU-T/NATO/DoD telephone system architecture known as Multi-
Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec]
[ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a
prioritized call handling service such that in times of emergency in
the relevant NATO and DoD commands, the relative importance of
various kinds of communications is strictly defined, allowing higher
precedence communication at the expense of lower precedence
communications. These precedences, in descending order, are:
Flash Override Override: used by the Commander in Chief, Secretary of Flash Override 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 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.
skipping to change at page 6, line 32 skipping to change at page 6, line 45
trunks or bandwidth necessary to place the more important calls in trunks 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.2 Definition of Call Admission 1.1.2. Government Emergency Telecommunications Service
Traditionally, in the PSTN, "Call Admission Control", or CAC, has had A US service similar to MLPP and using MLPP signaling technology, but
the responsibility of determining whether a caller has permission (an built for use in civilian networks, is the Government Emergency
identified subscriber, with identify attested to by appropriate Telecommunications Service (GETS). This differs from MLPP in two
credentials, is authorized) to use an available circuit. MLPP, or ways: it does not use preemption, but rather reserves bandwidth or
any emergency telephone service, creates two feedback paths in the queues calls to obtain a high probability of call completion, and it
algorithm: if a caller is authorized to use a higher precedence and has only two levels of service: "Routine" and "Priority".
is asserting that the advanced precedence applies to a given call, he
may also be authorized to use other networks, or the PSTN may be
obligated to preempt a call if possible and necessary to create
appropriate bandwidth, or it may be authorized to use a guard band of
bandwidth that other callers are not. At the completion of CAC,
however, the caller either has a circuit that he or she is authorized
to use, or has no circuit. Since the act of preemption or
consideration of alternative bandwidth sources is part and parcel of
the problem of providing bandwidth, the authorization step in
bandwidth provision also affects the choice of networks that may be
authorized to be considered. The three cannot be separated. The CAC
procedure finds available bandwidth that the caller is authorized to
use and preemption may in some networks be part of making that
happen.
1.3 Assumptions about the Network 1.2. Definition of Call Admission
Traditionally, in the PSTN, Call Admission Control (CAC) has had the
responsibility of determining whether a caller has permission (e.g.,
is an identified subscriber, with identify attested to by appropriate
credentials) to use an available circuit. IEPS, or any emergency
telephone service, has additional options that it may employ to
improve the probability of call completion:
o The call may be authorized to use other networks that it would not
normally use
o The network may preempt other calls to free bandwidth,
o The network may hold the call and place it when other calls
complete, or
o The network may use different bandwidth availability thresholds
than are used for other calls.
At the completion of CAC, however, the caller either has a circuit
that he or she is authorized to use, or has no circuit. Since the
act of preemption or consideration of alternative bandwidth sources
is part and parcel of the problem of providing bandwidth, the
authorization step in bandwidth provision also affects the choice of
networks that may be authorized to be considered. The three cannot
be separated. The CAC procedure finds available bandwidth that the
caller is authorized to use and preemption may in some networks be
part of making that happen.
1.3. Assumptions about the Network
IP networks generally fall into two categories: those with IP networks generally fall into two categories: those with
constrained bandwidth, and those that are massively overprovisioned. constrained bandwidth, and those that are massively over-provisioned.
In a network wherein over any interval that can be measured In a network wherein over any interval that can be measured
(including sub-second intervals) capacity exceeds offered load by at (including sub-second intervals) capacity exceeds offered load by at
least 2:1, the jitter and loss incurred in transit are nominal. This least 2:1, the jitter and loss incurred in transit are nominal. This
is generally a characteristic of properly engineered Ethernet LANs is generally a characteristic of properly engineered Ethernet LANs
and of optical networks (networks that measure their link speeds in and 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 ATM, MPLS, and GMPLS can be used to explicitly
place routes, and so improve the odds a bit. place routes, and so improve the odds a bit.
Between those networks, in places commonly called "inter-campus Between those networks, in places commonly called "inter-campus
skipping to change at page 7, line 42 skipping to change at page 8, line 21
speeds of 64 KBPS or less. In US Army networks, current radio speeds of 64 KBPS or less. In US Army networks, current radio
technology likewise limits tactical communications to links below 100 technology likewise limits tactical communications to links below 100
KBPS. 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), 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, with
the traffic they see. 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
skipping to change at page 8, line 17 skipping to change at page 8, line 45
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 do not tune their behavior to that of the With the exception of systems that select rate options according to
network. Rather, they send traffic at a rate specified by the codec ambient loss characteristics, voice and video systems do not tune
depending on what it perceives is required. In an MPEG-4 system, for their behavior to that of the network. Rather, they send traffic at
example, if the camera is pointed at a wall, the codec determines a rate specified by the codec depending on what it perceives is
that an 80 KBPS data stream will describe that wall, and issues that required. In an MPEG-4 system, for example, if the camera is pointed
amount of traffic. If a person walks in front of the wall or the at a wall, the codec determines that an 80 KBPS data stream will
camera is pointed an a moving object, the codec may easily send 800 describe that wall, and issues that amount of traffic. If a person
KBPS in its effort to accurately describe what it sees. In walks in front of the wall or the camera is pointed an a moving
commercial broadcast sports, which may line up periods in which object, the codec may easily send 800 KBPS in its effort to
advertisements are displayed, the effect is that traffic rates accurately describe what it sees. In commercial broadcast sports,
suddenly jump across all channels at certain times because the eye- which may line up periods in which advertisements are displayed, the
catching ads require much more bandwidth than the camera pointing at effect is that traffic rates suddenly jump across all channels at
the green football field. certain times because the eye-catching ads require much more
bandwidth than the camera pointing at the green football field.
As described in [RFC1633], when dealing with a real-time application, 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
requirement. To ensure that one knows how much offered load the requirement. To ensure that one knows how much offered load the
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 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 MLPP service include the following: The key elements of the Internet Emergency Preference Service include
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 user perceived
importance of the call. This level is not to be changed for the importance of the call. This level is not to be changed for the
duration of the call. The call before, and the call after are duration of the call. The call before, and the call after are
independent with regard to this level choice. 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
skipping to change at page 9, line 43 skipping to change at page 10, line 24
gets a circuit, and provides the means for the callers to conduct gets a circuit, and provides the means for the callers to conduct
their business without significant impact as long as their call is their business without significant impact as long as their call is
not preempted. In a VoIP system, one would hope for essentially not preempted. In a VoIP system, one would hope for essentially
the same service. 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 MLPP service must, by definition, A VoIP implementation of the Internet Emergency Preference Service
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 for 100 MBPS, or for that matter upgrade to a ten gigabit Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit
Ethernet. Similarly, in optical networking environments, the Ethernet. Similarly, in optical networking environments, the
simplest and cheapest solution is often to increase the data rate of simplest and cheapest solution is often to increase the data rate of
the optical path either by selecting a faster optical carrier or the optical path either by selecting a faster optical carrier or
deploying an additional lambda. In places where the bandwidth can be deploying an additional lambda. In places where the bandwidth can be
overprovisioned to a point where loss or queuing delay are over-provisioned to a point where loss or queuing delay are
negligible, 10:1 overprovisioning is often the cheapest and surest negligible, 10:1 over-provisioning is often the cheapest and surest
solution, and by the way offers a growth path for future solution, and by the way offers a growth path for future
requirements. However, there are places in communication networks requirements. However, there are places in communication networks
where bandwidth is not free and is therefore not effectively where bandwidth is not free and is therefore not effectively
infinite. It is in these places, and only these places, where the infinite. It is in these places, and only these places, where the
question of resource management is relevant. question of resource management is relevant.
The places where bandwidth constriction takes place is typically The places where bandwidth constriction takes place is typically
where one pays a significant amount for bandwidth, such as in access where one pays a significant amount for bandwidth, such as in access
paths, or where available technology limits the options. In military paths, or where available technology limits the options. In military
networks, Type 1 encryption often presents such a barrier, as do networks, Type 1 encryption often presents such a barrier, as do
skipping to change at page 12, line 16 skipping to change at page 13, line 16
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? o Does the call actually work?
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 specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: [I-D.ietf-sip-resource- necessary from an administrative perspective: [I-D.ietf-sip-resource-
priority] provides a way to communicate policy-related information priority] provides a way to communicate policy-related information
regarding the precedence of the call; and [I-D.ietf-sipping-reason- regarding the precedence of the call; and [I-D.ietf-sipping-reason-
header-for-preemption] provides a reason code when a call fails or is header-for-preemption] provides a reason code when a call fails or is
refused, indicating the cause of the event. If it is a failure, it refused, indicating the cause of the event. If it is a failure, it
may make sense to redial the call. If it is a policy-driven may make sense to redial the call. If it is a policy-driven
preemption, even if the call is redialed it may not be possible to preemption, even if the call is redialed it may not be possible to
place the call. place the call. Requirements for this service are further discussed
in [RFC3689].
The Communications Resource Priority Header (or RP Header) serves the The Communications Resource Priority Header (or RP Header) serves the
call set-up process with the precedence level chosen by the initiator call set-up process with the precedence level chosen by the initiator
of the call. The syntax is in the form: 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 (phone). If the receiving phone does not destination (called) device (telephone). If the receiving phone does
support the namespace, it can easily ignore (what [I-D.ietf-sip- not support the namespace, it can easily ignore the set-up request.
resource-priority] calls "loose mode") or errors (what [I-D.ietf-sip- This ability to denote the domain of origin allows SLAs to be in
resource-priority] calls "strict mode") the set-up request. This place to limit the ability of an unknown requester to gain
ability to denote the domain of origin allows SLAs to be in place to preferential treatment into an IEPS domain.
limit the ability of an unknown requestor to gain preferential
treatment into an MLPP domain.
For the DSN infrastructure, this header would look like this: For the DSN infrastructure, this header would look like this:
Resource Priority : dsn.routine Resource Priority : dsn.routine
for a routine precedence level call. The precedence level chosen in for a routine precedence level call. The precedence level chosen in
this header would be compared to the requestor's authorization this header would be compared to the requester's authorization
profile to user that precedence level. This would typically occur in profile to use that precedence level. This would typically occur in
the SIP first hop Proxy, which can challenge many aspects of the call the SIP first hop Proxy, which can challenge many aspects of the call
set-up request including the requestor choice of precedence levels set-up request including the requester choice of precedence levels
(verifying they aren't using a level they are not authorized to use.) (verifying they aren't using a level they are not authorized to use.)
The DSN has 5 precedence levels of MLPP 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
skipping to change at page 13, line 40 skipping to change at page 14, line 38
to be used by the President and a select few others. Note that the to be used by the President and a select few others. Note that the
namespace changed for this level. The lower 5 levels within the DRSN namespace changed for this level. The lower 5 levels within the DRSN
would also have this as their namespace for all DRSN originated call would also have this as their namespace for all DRSN originated call
set-up requests. set-up requests.
This informs both the use of DSCPs by the callee (who needs to use This informs both the use of DSCPs by the callee (who needs to use
the same DSCP as the caller to obtain the same data path service) and the same DSCP as the caller to obtain the same data path service) and
to facilitate policy-based preemption of calls in progress when to facilitate policy-based preemption of calls in progress when
appropriate. appropriate.
Once a call is established in an MLPP domain, the Reason Header for Once a call is established in an IEPS domain, the Reason Header for
Preemption, described in [I-D.ietf-sipping-reason-header-for- Preemption, described in [I-D.ietf-sipping-reason-header-for-
preemption], ensures that all SIP nodes are synchronized to a preemption], ensures that all SIP nodes are synchronized to a
preemption event occurring either at the endpoint or in a router that preemption event occurring either at the endpoint or in a router that
experiences congestion. In SIP, the normal indication for the end of experiences congestion. In SIP, the normal indication for the end of
a session is for one end system to send a BYE Method request as a session is for one end system to send a BYE Method request as
specified in [RFC3261]. This, too, is the proper means for signaling specified in [RFC3261]. This, too, is the proper means for signaling
a termination of a call due to a preemption event, as it essentially a termination of a call due to a preemption event, as it essentially
performs a normal termination with additional information informing performs a normal termination with additional information informing
the peer of the reason for the abrupt end - it indicates that a the peer of the reason for the abrupt end - it indicates that a
preemption occurred. This will be used to inform all relevant SIP preemption occurred. This will be used to inform all relevant SIP
skipping to change at page 14, line 16 skipping to change at page 15, line 14
Figure X is a simple example of a SIP call set-up that includes the Figure X is a simple example of a SIP call set-up 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 will be in the appendix), once Bob's user
agent (phone) receives the INVITE message from Carol, his UA needs to agent (phone) receives the INVITE message from Carol, his UA needs to
make a choice between retaining the call to Alice and sending Carol a make 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 MLPP 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 MLPP 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 set-up 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 | |
|<==========================>| | |<==========================>| |
| | | | | |
| | INVITE (RP: Immediate) | | | INVITE (RP: Immediate) |
skipping to change at page 15, line 22 skipping to change at page 15, line 40
|--------------------------->| | |--------------------------->| |
| RTP | | | RTP | |
|<==========================>| | |<==========================>| |
| | | | | |
| | INVITE (RP: Immediate) | | | INVITE (RP: Immediate) |
| |<----------------------------| | |<----------------------------|
| ************************************************ | | ************************************************ |
| *Resource Priority value comparison by Bob's UA* | | *Resource Priority value comparison by Bob's UA* |
| ************************************************ | | ************************************************ |
| | | | | |
| BYE (Reason:UA_preemption) | | | BYE (Reason:Generic_preemption) |
|<---------------------------| | |<---------------------------| |
| | 200 OK | | | 200 OK |
| |---------------------------->| | |---------------------------->|
| 200 OK (BYE) | | | 200 OK (BYE) | |
|--------------------------->| | |--------------------------->| |
| | ACK | | | ACK |
| |<----------------------------| | |<----------------------------|
| | RTP | | | RTP |
| |<===========================>| | |<===========================>|
| | | | | |
skipping to change at page 15, line 35 skipping to change at page 16, line 4
| |---------------------------->| | |---------------------------->|
| 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 also assumed each user agent recognized the Resource-Priority
header's namespace value. Therefore, it is assumed that the domain header's namespace value. Therefore, it is assumed that the domain
allowed Alice, Bob and Carol to communicate. Authentication and allowed Alice, Bob and Carol to communicate. Authentication and
Authorization are discussed later in this document. 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 the [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 minimal variation in delay and a minimal loss rate,
as codecs are hampered by excessive loss [G711.1] [G711.2] [G711.3] . as codecs are hampered by excessive loss [G711.1] [G711.2] [G711.3]
In parts of the network where bandwidth is heavily overprovisioned, .In parts of the network where bandwidth is heavily over-provisioned,
there may be no remaining concern. In places in the network where there may be no remaining concern. In places in the network where
bandwidth is more constrained, this may require the use of a priority bandwidth is more constrained, this may require the use of a priority
queue. If a priority queue is used, the potential for abuse exists, queue. If a priority queue is used, the potential for abuse exists,
meaning that it is also necessary to police traffic placed into the meaning that it is also necessary to police traffic placed into the
queue to detect and manage abuse. A fundamental question is "where queue to detect and manage abuse. A fundamental question is "where
does this policing need to take place?". The obvious places would be does this policing need to take place?". The obvious places would be
the first hop routers and any place where converging data streams the first hop routers and any place where converging data streams
might congest a link. might congest a link.
For policy reasons, DISA would like to mark traffic with various code Some proposals mark traffic with various code points appropriate to
points appropriate to the service precedence of the call. In normal the service precedence of the call. In normal service, if the
service, if the traffic is all in the same queue and EF service traffic is all in the same queue and EF service requirements are met
requirements are met (applied capacity exceeds offered load, (applied capacity exceeds offered load, variation in delay is
variation in delay is minimal, and loss is negligible), details of minimal, and loss is negligible), details of traffic marking should
traffic marking should be irrelevant, as long as they get the packets be irrelevant, as long as packets get into the right service class.
into the right service class. The major issue, then is primarily one The major issues, then are primarily appropriate policing of traffic,
of appropriate policing of traffic, especially around route changes. especially around route changes, and ensuring that the path has
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, the circuit networks like Frame Relay and ATM. Between these two checks
application traffic should be guaranteed to be within acceptable (at what some networks call the DTE and DCE), the application traffic
limits. As such, given bandwidth-aware call admission control, there should be guaranteed to be within acceptable limits. As such, given
should be minimal actual loss. The cases where loss would occur bandwidth-aware call admission control, there should be minimal
include cases where routing has recently changed and CAC has not actual loss. The cases where loss would occur include cases where
caught up, or cases where statistical thresholds are in use in CAC routing has recently changed and CAC has not caught up, or cases
and the data streams happen to coincide at their peak rates. where statistical thresholds are in use in CAC and the data streams
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 the 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 SIP proxy near a networks do something similar when they place a stateful SIP proxy
single ingress/egress to the network. This is able to impose an near a single ingress/egress to the network. This is able to impose
upper bound on the total number of calls in the network or the total an upper bound on the total number of calls in the network or the
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 requires a single ingress/egress - a very conservative, and usually presumes a single ingress/egress or
single point of failure. While this may serve as a short term work- the failure of one of its data paths. While this may serve as a
around, it is not a general solution that is readily deployed. This short term work-around, it is not a general solution that is readily
limits the options in network design. deployed. This limits the options in network design.
The [RFC1633] provides for signalled admission for the use of [RFC1633] provides for signaled admission for the use of capacity.
capacity. This is currently implemented using the Resource The recommended approach is explicit capacity admission, supporting
Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Capacity the concepts of preemption. An example of such a procedure uses the
Admission with SIP is described in [RFC3312] ; at this writing, Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of
Capacity Admission is not integrated with H.323. Capacity Admission using RSVP with SIP is described in [RFC3312].
While call counting is specified in H.323, network capacity admission
is not integrated with H.323 at this time.
2.3.1 Recommended procedure: explicit call admission - RSVP Admission 2.3.1. RSVP procedure: explicit call admission - RSVP Admission using
using Policy Policy
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
skipping to change at page 18, line 20 skipping to change at page 19, line 13
have every node participate. have every node participate.
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| _______ | | | | _______ | | |
| | | _______ | | _______ | | | | _______ | | _______ |
| |Appli- | | | |RSVP | | | | | |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <----------> | | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | | | | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ | | | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Polcy|| || <--> -->Polcy|| | |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____|| | |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========| |===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ | | | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis|| | | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____|| | | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |data | |______| |________| |data | |______| |________| |data
skipping to change at page 19, line 11 skipping to change at page 20, line 5
module. Determining whether there is satisfactory resources for module. Determining whether there is satisfactory resources for
the requested QoS is the function of admission control. the requested QoS is the function of admission control.
Determining if the user has the authorization to request such Determining if the user has the authorization to request such
resources is the function of policy control. If the parameters resources is the function of policy control. If the parameters
carried within this flow fail either of these two modules, RSVP carried within this flow fail either of these two modules, RSVP
errors the request. 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, RSVP had scaling limitations due to its data As originally written, there was concern that RSVP had scaling
plane behavior. This has, in time, largely been corrected. In edge limitations due to its data plane behavior[RFC2208]. This has either
networks, RSVP is used to signal for individual microflows, admitting not proven to be the case or has in time largely been corrected.
the bandwidth. However, Differentiated Services is used for the data Telephony services generally require peak call admission rates on the
plane behavior. Admission and policing may be performed anywhere, order of thousands of calls per minute and peak call levels
but need only be performed in the first hop router (which, if the end comparable to the capacities of the lines in question, which is
system sending the traffic is a DTE, constitutes a DCE for the generally on the order of thousands to tens of thousands of calls.
remaining network) and in routers that have interfaces threatened by Current RSVP implementations admit calls at the rate of hundreds of
congestion. In Figure 1, these would normally be the links that calls per second and maintain as many calls in progress as memory
cross network boundaries, and may also include any type 1 encrypted configurations allow.
interface, as these are generally limited in bandwidth by the
encryption.
2.3.3 RSVP Operation in backbones and VPNs In edge networks, RSVP is used to signal for individual microflows,
admitting the bandwidth. However, Differentiated Services is used
for the data plane behavior. Admission and policing may be performed
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
the remaining network) and in routers that have interfaces threatened
by congestion. In Figure 1, these would normally be the links that
cross network boundaries.
2.3.3. RSVP Operation in backbones and 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 and of networks that carry traffic from an encryptor to a
decryptor, and also of VPNs - applicable technologies include decryptor, and also of VPNs - applicable technologies include
[RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is simplistically [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is simplistically
a IP packet enveloped inside another IP packet as a payload. When a IP packet enveloped inside another IP packet as a payload. When
IPv6 is transported over an IPv4 network, encapsulating the entire v6 IPv6 is transported over an IPv4 network, encapsulating the entire v6
packet inside a v4 packet is an effective means to accomplish this packet inside a v4 packet is an effective means to accomplish this
skipping to change at page 20, line 27 skipping to change at page 21, line 25
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, similar tunnels between HAIPE Associations between VPN edge routers, similar tunnels between HAIPE
encryptors and decryptors, IP/IP tunnels, and GRE tunnels all fall encryptors and decryptors, IP/IP tunnels, and GRE tunnels all fall
into this general category. The distinguishing factor is that the into this general category. The distinguishing factor is that the
system injecting an aggregate into the aggregated network sums the system injecting an aggregate into the aggregated network sums the
PATH and RESV statistical information on the un-aggregated side and PATH and RESV statistical information on the un-aggregated side and
produces a reservation for the tunnel on the aggregated side. If the produces a reservation for the tunnel on the aggregated side. If the
bandwidth for the tunnel cannot be expanded, RSVP leaves the existing bandwidth for the tunnel cannot be expanded, RSVP leaves the existing
reservation in place and returns an error to the aggregator, which reservation in place and returns an error to the aggregator, which
can then apply a policy such as MLPP to determine which session to can then apply a policy such as IEPS to determine which session to
refuse. In the data plane, the DSCP for the traffic must be copied refuse. In the data plane, the DSCP for the traffic must be copied
from the inner to the outer header, to preserve the 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 overprovisioning, and and reported on in the literature: simple over-provisioning, and
approximation to ambient load. approximation to ambient load.
Simple overprovisioning sets the bandwidth admission limit higher Simple over-provisioning sets the bandwidth admission limit higher
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
skipping to change at page 22, line 5 skipping to change at page 23, line 5
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. But 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 Int-Serv model. This model was created to provide enforcement in an Integrated Services model. This model was created
ability to monitor and control reservation flows based on user to provide ability to monitor and control reservation flows based on
identify, specific traffic and security requirements and conditions user identify, specific traffic and security requirements and
which might change for various reasons, including as a reaction to a conditions which might change for various reasons, including as a
disaster or emergency event involving the network or its users. reaction to a disaster or emergency event involving the network or
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___ |
skipping to change at page 23, line 4 skipping to change at page 24, line 5
precedence level usage) to be used in creating the rule sets of 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 which 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 to disconnect its call, with a reason
code of "bandwidth preemption". 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; it is the capabilities assigned to an
authenticated user that may be considered to have been authorized for authenticated user that may be considered to have been authorized for
use in the network. For bandwidth admission, this will require the use in the network. For bandwidth admission, this will require the
utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures
will also be needed. will also 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 - should
ideally remain the same as in the MLPP PSTN for those indications ideally remain the same as in the PSTN for those indications that are
that are still applicable to an IP network. There should be some new still applicable to an IP network. There should be some new effort
effort generated to update the list of announcements sent to the user generated to update the list of announcements sent to the user which
which don't necessarily apply. For example, in an end-to-end IP don't necessarily apply. All indications to the user, of course,
call, there is no known benefit to informing the user which Ethernet depend on positive signals, not unreliable measures based on changing
switch or router caused the call to fail - as is the equivalent case measurements.
if a TDM Switch were the cause. All indications to the user, of
course, depend on positive signals, not unreliable measures based on
changing measurements.
3. IANA Considerations 3. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
4. Security Considerations 4. Security Considerations
skipping to change at page 26, line 11 skipping to change at page 27, line 11
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 5. 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. Key contributors
of thoughts include, however, Francois Le Faucheur, Haluk Keskiner, of thoughts include, however, Francois Le Faucheur, Haluk Keskiner,
Rohan Mahy, Scott Bradner, Scott Morrison, and Subha Dhesikan. Pete Rohan Mahy, Scott Bradner, Scott Morrison, and Subha Dhesikan. Pete
Babendreier's review was especially useful. Babendreier, Ken Carlberg, and Mike Pierce provided useful reviews.
6. References 6. References
6.1 Normative References 6.1. Normative References
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689,
February 2004.
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690,
February 2004.
6.2. Informative References
[ANSI.MLPP.Spec] [ANSI.MLPP.Spec]
American National Standards Institute, "Telecommunications American National Standards Institute, "Telecommunications
- Integrated Services Digital Network (ISDN) - Multi-Level - Integrated Services Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability", Precedence and Preemption (MLPP) Service Capability",
ANSI T1.619-1992 (R1999), 1992. ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement] [ANSI.MLPP.Supplement]
American National Standards Institute, "MLPP Service American National Standards Institute, "MLPP Service
Domain Cause Value Changes", ANSI ANSI T1.619a-1994 Domain Cause Value Changes", ANSI ANSI T1.619a-1994
(R1999), 1990. (R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, <h
ttp://www.sygnusdata.co.uk/white_papers/viola/
netally_voip_sample_report_preliminary.pdf>.
[G711.2] IEPSI Tiphon, "IEPSI Tiphon Temporary Document 64",
July 1999, <http://docbox.etsi.org/tiphon/tiphon/archives/
1999/05-9907-Amsterdam/14TD113.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http://www.nortelnetworks.com/
products/01/succession/es/collateral/tb_pktloss.pdf>.
[G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and
recency on Subjective Voice Quality", 2000, <http://
www.telchemy.com/references/tech_papers/iptel2001.pdf>.
[G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware
Support, MOS, and Negotiation", 2003, <http://
www.cisco.com/en/US/tech/tk652/tk701/
technologies_tech_note09186a00800b6710.shtml#mos>.
[I-D.ietf-sip-resource-priority] [I-D.ietf-sip-resource-priority]
Schulzrinne, H. and J. Polk, "Communications Resource Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
draft-ietf-sip-resource-priority-09 (work in progress), draft-ietf-sip-resource-priority-10 (work in progress),
May 2005. July 2005.
[I-D.ietf-sipping-reason-header-for-preemption] [I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Extending the Session Initiation Protocol Polk, J., "Extending the Session Initiation Protocol
Reason Header for Preemption Events", Reason Header for Preemption Events",
draft-ietf-sipping-reason-header-for-preemption-02 (work draft-ietf-sipping-reason-header-for-preemption-03 (work
in progress), August 2004. in progress), July 2005.
[I-D.pierce-ieprep-assured-service-arch] [I-D.pierce-tsvwg-assured-service-arch]
Pierce, M. and D. Choi, "Architecture for Assured Service Pierce, M., "Architecture for Assured Service Capabilities
Capabilities in Voice over IP", in Voice over IP",
draft-pierce-ieprep-assured-service-arch-02 (work in draft-pierce-tsvwg-assured-service-arch-01 (work in
progress), January 2004. progress), October 2004.
[I-D.pierce-ieprep-assured-service-req] [I-D.pierce-tsvwg-assured-service-req]
Pierce, M. and D. Choi, "Requirements for Assured Service Pierce, M., "Requirements for Assured Service Capabilities
Capabilities in Voice over IP", in Voice over IP",
draft-pierce-ieprep-assured-service-req-02 (work in draft-pierce-tsvwg-assured-service-req-01 (work in
progress), January 2004. progress), October 2004.
[I-D.pierce-tsvwg-pref-treat-examples]
Pierce, M., "Examples for Provision of Preferential
Treatment in Voice over IP",
draft-pierce-tsvwg-pref-treat-examples-01 (work in
progress), October 2004.
[ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over
Networks With Bursty Packet Loss", July 2003.
[ITU.ETS.E106]
International Telecommunications Union, "International
Emergency Preference Scheme for disaster relief operations
(IEPS)", ITU-T Recommendation E.106, October 2003.
[ITU.MLPP.1990] [ITU.MLPP.1990]
International Telecommunications Union, "Multilevel International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", ITU- Precedence and Preemption Service (MLPP)", ITU-
T Recommendation I.255.3, 1990. T Recommendation I.255.3, 1990.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services
Networks: The Multiple Node Case", INFOCOM 1993: 521-530,
1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services
Networks: The Single Node Case", INFOCOM 1992: 915-924,
1992.
[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 Overview",
RFC 1633, June 1994. 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 S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. 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 IPSEC
Data Flows", RFC 2207, September 1997. Data Flows", RFC 2207, September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,
M., Romanow, A., Weinrib, A., and L. Zhang, "Resource
ReSerVation Protocol (RSVP) Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208,
September 1997.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
September 1997. September 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[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 (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
skipping to change at page 29, line 42 skipping to change at page 32, line 6
June 2002. June 2002.
[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 Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
6.2 Informative References
[G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, <h
ttp://www.sygnusdata.co.uk/white_papers/viola/
netally_voip_sample_report_preliminary.pdf>.
[G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64",
July 1999, <http://docbox.etsi.org/tiphon/tiphon/archives/
1999/05-9907-Amsterdam/14TD113.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http://www.nortelnetworks.com/
products/01/succession/es/collateral/tb_pktloss.pdf>.
[G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and
recency on Subjective Voice Quality", 2000, <http://
www.telchemy.com/references/tech_papers/iptel2001.pdf>.
[G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware
Support, MOS, and Negotiation", 2003, <http://
www.cisco.com/en/US/tech/tk652/tk701/
technologies_tech_note09186a00800b6710.shtml#mos>.
[ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over
Networks With Bursty Packet Loss", July 2003.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services
Networks: The Multiple Node Case", INFOCOM 1993: 521-530,
1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services
Networks: The Single Node Case", INFOCOM 1992: 915-924,
1992.
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, [RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn,
W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)",
RFC 3951, December 2004. RFC 3951, December 2004.
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Phone: +1-469-255-5208
Email: jmpolk@cisco.com
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 between SIP, SDP and RSVP. The bulk of the material is referenced
from [RFC2327], [RFC3312], [I-D.ietf-sipping-reason-header-for- from [RFC2327], [RFC3312], [I-D.ietf-sipping-reason-header-for-
preemption], [I-D.ietf-sip-resource-priority]. There will be some preemption], [I-D.ietf-sip-resource-priority]. There will be some
discussion on basic RSVP operations regarding reservation paths, this discussion on basic RSVP operations regarding reservation paths, this
will be mostly from [RFC2205]. will be mostly from [RFC2205].
SIP signaling occurs at layer 7, riding on a UDP/IP or TCP/IP SIP signaling occurs at layer 7, riding on a UDP/IP or TCP/IP
skipping to change at page 32, line 48 skipping to change at page 33, line 48
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
does not reserve resources (bandwidth). The RESV message back to the does not reserve resources (bandwidth). The RESV message back to the
original requestor of the RSVP flow requests for the bandwidth original requester of the RSVP flow requests for the bandwidth
resources. This means the endpoint that initiates the RESV message resources. This means the endpoint that initiates the RESV message
controls the parameters of the reservation. This document specifies controls the parameters of the reservation. This document specifies
in the body text that the SIP initiator (the UAC) establishes the in the body text that the SIP initiator (the UAC) establishes the
parameters of the session in an INVITE message, and that the INVITE parameters of the session in an INVITE message, and that the INVITE
recipient (the UAS) must follow the parameters established in that recipient (the UAS) must follow the parameters established in that
INVITE message. One exception to this is which codec to use if the INVITE message. One exception to this is which codec to use if the
UAC offered more than one to the UAS. This exception will be shown UAC offered more than one to the UAS. This exception will be shown
when the INVITE message is discussed in detail later in the appendix. when the INVITE message is discussed in detail later in the appendix.
If there was only one codec in the SDP of the INVITE message, the If there was only one codec in the SDP of the INVITE message, the
parameters of the reservation will follow what the UAC requested parameters of the reservation will follow what the UAC requested
skipping to change at page 33, line 43 skipping to change at page 34, line 43
Alice -> R1 -> R2 -> R3 -> R4 -> Bob Alice -> R1 -> R2 -> R3 -> R4 -> Bob
The RESV message (and therefore the reservation of resources) from The RESV message (and therefore the reservation of resources) from
Bob to Alice will be through routers: Bob to Alice will be through routers:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice Bob -> R4 -> R3 -> R2 -> R1 -> Alice
The PATH message from Carol to Dave (establishing the route for the The PATH message from Carol to Dave (establishing the route for the
RESV message) will be through routers: RESV message) will be through routers:
The reservation from Carol to Dave be through routers: Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Carol -> R6 -> R2 -> R3 -> R7 -> R11 -> Dave
The RESV message (and therefore the reservation of resources) from The RESV message (and therefore the reservation of resources) from
Dave to Carol will be through routers: Dave to Carol will be through routers:
Dave -> R11 -> R7 -> R3 -> R2 -> R6 -> 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 Int7 to be what will first know about a
congestion condition. congestion condition.
skipping to change at page 35, line 17 skipping to change at page 36, line 17
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | Note 1 | | Note 1
|<------(2) 183 Session Progress SDP2--------| | |<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+ ***|********************************************|***<-+
* |----------------(3) PRACK------------------>| * * |----------------(3) PRACK------------------>| *
* | | * When * | | * When
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP * |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is * | | * is
* | | * signaled * | | * signaled
+->***|********************************************|*** ***|********************************************|***
| |-------------(5) UPDATE SDP3--------------->| |-------------(5) UPDATE SDP3--------------->|
Note 2 | | | |
|<--------(6) 200 OK (UPDATE) SDP4-----------| |<--------(6) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-------------(7) 180 Ringing---------------| |<-------------(7) 180 Ringing---------------|
| | | |
|-----------------(8) PRACK----------------->| |-----------------(8) PRACK----------------->|
| | | |
|<------------(9) 200 OK (PRACK)-------------| |<------------(9) 200 OK (PRACK)-------------|
| | | |
| | | |
|<-----------(10) 200 OK (INVITE)------------| |<-----------(10) 200 OK (INVITE)------------|
| | | |
|------------------(11) ACK----------------->| |------------------(11) ACK----------------->|
| | | |
| RTP (within the reservation) | | RTP (within the reservation) |
|<==========================================>| |<==========================================>|
| | | |
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 MLPP 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 USMC for the addressing of
this message exchange. 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]
skipping to change at page 36, line 29 skipping to change at page 37, 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 (before the empty line in the middle) are SIP half of the lines (above the line 'v=0') are SIP headers and header
headers and header values, the lower half of the lines above are values, the lower half of the lines above are Session Description
Session Description Protocol (SDP) lines. SIP headers (after the Protocol (SDP) lines. SIP headers (after the first line) are not to
first line) are not to be in any particular order, with one be in any particular order, with one exception: the Via header. It
exception: the Via header. It is a SIP hop (through a SIP Proxy) is a SIP hop (through a SIP Proxy) route path that has a new Via
route path that has a new Via header line added by each SIP proxy header line added by each SIP proxy this message traverses. This is
this message traverses. This is similar in function to an RSVP PATH similar in function to an RSVP PATH message (building a reverse path
message (building a reverse path back to the originator of the back to the originator of the message). At any point in the
message). At any point in the message's path, a SIP element knows message's path, a SIP element knows the path to the originator of the
the path to the originator of the message. There will be not SIP message. There will be no SIP Proxies in this example, because for
Proxies in this example, because for Preconditions, Proxies only make Preconditions, Proxies only make more messages that look identical
more messages that look identical (with the exception of the Via and (with the exception of the Via and Max-Forwards headers), and that is
Max-Forwards headers), and that is not worth the space here to not worth the space here to replicate what has been done in SIP RFCs
replicate what has been done in SIP RFCs already. already.
SIP headers that are used for Preconditions are the: SIP headers that are used for Preconditions are the:
Requires header - which mandates a reliable provisional response Requires header - which mandates a reliable provisional response
message to the conditions requesting in this INVITE (knowing they message to the conditions requesting in this INVITE (knowing they
are special). are special).
This will result in the 183 "Session Progress" message from Bob's UA This will result in the 183 "Session Progress" message from Bob's UA
as a reliable confirmation that preconditions are required for this as a reliable confirmation that preconditions are required for this
call. call.
skipping to change at page 37, line 19 skipping to change at page 38, line 20
signaled for in the SDP portion of the message. SDP is carried in signaled for in the SDP portion of the message. SDP is carried in
what's called a SIP message body (much like the text in an email what's called a SIP message body (much like the text in an email
message is carried). SDP has special properties [see [RFC2327] for message is carried). SDP has special properties [see [RFC2327] for
more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP]. more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP].
SDP lines are in a specific order for parsing reasons by endsystems. SDP lines are in a specific order for parsing reasons by endsystems.
Dialog (Call) generating SDP message bodies all must have an "m" line Dialog (Call) generating SDP message bodies all must have an "m" line
(or media description line). Following the "m" line is zero or more (or media description line). Following the "m" line is zero or more
"a" lines (or Attribute lines). The m-line in Alice's INVITE calls "a" lines (or Attribute lines). The m-line in Alice's INVITE calls
for a voice session (this is where video is identified also) using for a voice session (this is where video is identified also) using
one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723 one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723
and 8 = G.729) that Bob gets to choose from for this session. Bob and 18 = G.729) that Bob gets to choose from for this session. Bob
can choose any of the 3. The first a=rtpmap line is specific to the can choose any of the 3. The first a=rtpmap line is specific to the
type of codec these 3 are (PCMU). The next two a-lines are the only type of codec these 3 are (PCMU). The next two a-lines are the only
identifiers that RSVP is to be used for this call. The second identifiers that RSVP is to be used for this call. The second
a-line: 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 RSVP is required from Alice's UA to Bob's UA; meaning "e2e" means that capacity assurance is required from Alice's UA to
an RSVP failure in either direction will fail the call attempt. Bob's UA; meaning a lack of available capacity assurance in either
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):
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
identifies the "desired" level of qos identifies the "desired" level of qos
skipping to change at page 39, line 28 skipping to change at page 40, line 31
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. But during this time of reservation
establishment, a Provisional Acknowledgement (PRACK) [M3] is sent establishment, a Provisional Acknowledgment (PRACK) [M3] is sent from
from Alice to Bob to confirm the request for confirmation of 2 one- Alice to Bob to confirm the request for confirmation of 2 one-way
way reservations at Alice's UA. This message is acknowledged with a reservations at Alice's UA. This message is acknowledged with a
normal 200 OK message [M4]. This is shown in Figure 7. 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), it was the last in the two way cycle or reservation establishment),
at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform
his UA that current status of RSVP (or qos) is "e2e" and "sendrecv". his UA that 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
skipping to change at page 40, line 30 skipping to change at page 41, line 31
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 Figure 10
This is shown by the matching table that can be build 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 need take place with regard to "qos". [M6] is the 200 OK
acknowledgement of this synchronization between the two UAs. acknowledgment 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>
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
skipping to change at page 41, line 24 skipping to change at page 42, line 46
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 here.
Carol is now calling Dave at a Resource-Priority level of "Immediate" Carol is now calling Dave at a Resource-Priority level of "Immediate"
- which is higher in priority than Alice to Bob's "routine". In this - which is higher in priority than Alice to Bob's "routine". In this
continuing example, Router 2's Interface-7 is congested and cannot continuing example, Router 2's Interface-7 is congested and cannot
accept any more RSVP traffic. Perhaps the offered load is at accept any more RSVP traffic. Perhaps the offered load is at
interface capacity. Perhaps Interface-7 is configured with a fixed interface capacity. Perhaps Interface-7 is configured with a fixed
amount of bandwidth is can allocate for RSVP traffic and has reached amount of bandwidth it can allocate for RSVP traffic and has reached
its maximum with one of the reservations going away through normal its maximum without one of the reservations going away through normal
termination or forced termination (preemption). 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 an interface from signaling packets. Carol sends her own starve an interface from signaling packets. Carol sends her own
INVITE with the following characteristics important here: INVITE with the following characteristics important here:
[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 area 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:
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
skipping to change at page 42, line 48 skipping to change at page 44, line 21
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 or 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 occur 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]], set-up path that wanted to remain "dialog stateful" per [RFC3261]],
and informs Alice's UA that this was a purposeful termination, and to and informs Alice's UA that this was a purposeful termination, and to
play a preemption tone. The proper indication in SIP of this 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, Reason Header indicating why this occurred (in this case,
"RSVP_Preemption". Here is that message from Bob to Alice that "Generic_preemption". Here is that 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: cause=2 ;text=RSVP preemption Reason: preemption ;cause=2 ;text=network preemption
Call-ID: a84b4c76e66710@swp34.usmc.example.mil Call-ID: a84b4c76e66710@swp34.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 set-up, 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 set-up 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 will preempt any lower priority calls where these is a contention for
resources. In this case, it occurred and affected the call between resources. In this case, it occurred and affected the call between
Alice and Bob. A router at this congestion point preempted Alice's Alice and Bob. A router at this congestion point preempted Alice's
call to Bob in order to place the higher priority call between Carol call to Bob in order to place the higher priority call between Carol
and Dave. Alice and Bob were both informed of the preemption event. and Dave. Alice and Bob were both informed of the preemption event.
Both Alice and Bob's UAs played preemption indications. What was not Both Alice and Bob's UAs played preemption indications. What was not
mentioned in this appendix was that this document RECOMMENDS R2 (in mentioned in this appendix was that this document RECOMMENDS R2 (in
this example) generating a syslog message to the domain administrator this example) generating a syslog message to the domain administrator
to properly manage and track such events within this domain. This to properly manage and track such events within this domain. This
will ensure the domain administrators have recorded knowledge of will ensure the domain administrators have recorded knowledge of
where such events occur, and what the conditions were that caused where such events occur, and what the conditions were that caused
them. them.
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Phone: +1-469-255-5208
Email: jmpolk@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/