draft-ietf-tsvwg-mlpp-that-works-02.txt   draft-ietf-tsvwg-mlpp-that-works-03.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Expires: February 20, 2006 Cisco Systems Expires: August 13, 2006 Cisco Systems
August 19, 2005 February 9, 2006
Implementing an Emergency Telecommunications Service for Real Time Implementing an Emergency Telecommunications Service for Real Time
Services in the Internet Protocol Suite Services in the Internet Protocol Suite
draft-ietf-tsvwg-mlpp-that-works-02 draft-ietf-tsvwg-mlpp-that-works-03
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 35 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 February 20, 2006. This Internet-Draft will expire on August 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
RFCs 3689 and 3690 detail requirements for an Emergency RFCs 3689 and 3690 detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preference Service (IEPS) would be a part. Some of these types of Preparedness Service (IEPS) would be a part. Some of these types of
services require call preemption; others call for call queuing or services require call preemption; others, call for call queuing or
other mechanisms. The key requirement is to guarantee an elevated other mechanisms. The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of probability of call completion to an authorized user in time of
crisis. crisis.
IEPS requires a Call Admission Control procedure and a Per Hop IEPS requires a Call Admission Control (CAC) procedure and a Per Hop
Behavior for the data which meet the needs of this architecture. Behavior for the data which meet the needs of this architecture.
Such a CAC procedure and PHB is appropriate to any service that might Such a CAC procedure and PHB is appropriate to any service that might
use H.323 or SIP to set up real time sessions. These obviously use H.323 or SIP to set up real time sessions. These obviously
include but are not limited to Voice and Video applications, although include, but are not limited to, Voice and Video applications,
at this writing the community is mostly thinking about Voice on IP although at this writing the community is mostly thinking about Voice
and many of the examples in the document are taken from that on IP and many of the examples in the 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 session 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
supersede 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.
Although this document primarily discusses requirements for the US
Government and NATO, the architecture described here is applicable
outside these two organizations.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview of the Internet Emergency Preference Service
problem and proposed solutions . . . . . . . . . . . . . . . . 4
1.1. Emergency Telecommunications Services . . . . . . . . . . 4 1.1. Emergency Telecommunications Services . . . . . . . . . . 4
1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 4 1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 5
1.1.2. Government Emergency Telecommunications Service . . . 6 1.1.2. Government Emergency Telecommunications Service . . . 7
1.2. Definition of Call Admission . . . . . . . . . . . . . . . 7 1.2. Definition of Call Admission . . . . . . . . . . . . . . . 7
1.3. Assumptions about the Network . . . . . . . . . . . . . . 7 1.3. Assumptions about the Network . . . . . . . . . . . . . . 7
1.4. Assumptions about application behavior . . . . . . . . . . 8 1.4. Assumptions about application behavior . . . . . . . . . . 8
1.5. Desired Characteristics in an Internet Environment . . . . 9 1.5. Desired Characteristics in an Internet Environment . . . . 9
1.6. The use of bandwidth as a solution for QoS . . . . . . . . 10 1.6. The use of bandwidth as a solution for QoS . . . . . . . . 10
2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 12 2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Call admission/preemption procedure . . . . . . . . . . . 13 2.1. Call admission/preemption procedure . . . . . . . . . . . 13
2.2. Voice handling characteristics . . . . . . . . . . . . . . 16 2.2. Voice handling characteristics . . . . . . . . . . . . . . 16
2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 17 2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 18
2.3.1. RSVP procedure: explicit call admission - RSVP 2.3.1. RSVP procedure: explicit call admission - RSVP
Admission using Policy . . . . . . . . . . . . . . . . 18 Admission using Policy for both unicast and
multicast sessions . . . . . . . . . . . . . . . . . . 18
2.3.2. RSVP Scaling Issues . . . . . . . . . . . . . . . . . 20 2.3.2. RSVP Scaling Issues . . . . . . . . . . . . . . . . . 20
2.3.3. RSVP Operation in backbones and VPNs . . . . . . . . . 20 2.3.3. RSVP Operation in backbones and VPNs . . . . . . . . . 20
2.3.4. Interaction with the Differentiated Services 2.3.4. Interaction with the Differentiated Services
Architecture . . . . . . . . . . . . . . . . . . . . . 21 Architecture . . . . . . . . . . . . . . . . . . . . . 21
2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 21 2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 22
2.3.5.1. Admission for variable rate codecs . . . . . . . . 22 2.3.5.1. Admission for variable rate codecs . . . . . . . . 22
2.3.5.2. Interaction with complex admission policies, 2.3.5.2. Interaction with complex admission policies,
AAA, and preemption of bandwidth . . . . . . . . . 23 AAA, and preemption of bandwidth . . . . . . . . . 23
2.4. Authentication and authorization of calls placed . . . . . 24 2.4. Authentication and authorization of calls placed . . . . . 24
2.5. Defined User Interface . . . . . . . . . . . . . . . . . . 24 2.5. Defined User Interface . . . . . . . . . . . . . . . . . . 24
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28 6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 28 6.2. Integrated Services Architecture References . . . . . . . 28
6.3. Differentiated Services Architecture References . . . . . 29
6.4. Session Initiation Protocol and related References . . . . 30
6.5. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 33 Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Overview 1. Overview of the Internet Emergency Preference Service problem and
proposed solutions
[RFC3689] and [RFC3690] detail requirements for an Emergency [RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preference Service (IEPS) would be a part. Some of these types of Preference Service (IEPS) would be a part. Some of these types of
services require call preemption; others call for call queuing or services require call preemption; others call for call queuing or
other mechanisms. The key requirement is to guarantee an elevated other mechanisms. The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of probability of call completion to an authorized user in time of
crisis. crisis.
IEPS requires a Call Admission Control procedure and a Per Hop IEPS requires a Call Admission Control procedure and a Per Hop
skipping to change at page 5, line 12 skipping to change at page 5, line 17
The Assured Service is designed as an IP implementation of an The Assured Service is designed as an IP implementation of an
existing ITU-T/NATO/DoD telephone system architecture known as Multi- existing ITU-T/NATO/DoD telephone system architecture known as Multi-
Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec] Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec]
[ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a [ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a
prioritized call handling service such that in times of emergency in prioritized call handling service such that in times of emergency in
the relevant NATO and DoD commands, the relative importance of the relevant NATO and DoD commands, the relative importance of
various kinds of communications is strictly defined, allowing higher various kinds of communications is strictly defined, allowing higher
precedence communication at the expense of lower precedence precedence communication at the expense of lower precedence
communications. These precedences, in descending order, are: 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
Defense, and Joint Chiefs of Staff, Commanders of combatant of Defense, and Joint Chiefs of Staff, Commanders of combatant
commands when declaring the existence of a state of war. commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other One or Defense Emergency or Air Defense Emergency and other
national authorities that the President may authorize in national authorities that the President may authorize in
conjunction with Worldwide Secure Voice Conferencing System conjunction with Worldwide Secure Voice Conferencing System
conferences. Flash Override Override cannot be preempted. This conferences. Flash Override Override cannot be preempted. This
precedence level is not enabled on all DoD networks. precedence level is not enabled on all DoD networks.
Flash Override: used by the Commander in Chief, Secretary of Defense, Flash Override: used by the Commander in Chief, Secretary of
and Joint Chiefs of Staff, Commanders of combatant commands when Defense, and Joint Chiefs of Staff, Commanders of combatant
declaring the existence of a state of war. Commanders of commands when declaring the existence of a state of war.
combatant commands when declaring Defense Condition One or Defense Commanders of combatant commands when declaring Defense Condition
Emergency and other national authorities the President may One or Defense Emergency and other national authorities the
authorize. Flash Override cannot be preempted in the DSN. President may authorize. Flash Override cannot be preempted in
the DSN.
Flash: reserved generally for telephone calls pertaining to command Flash: reserved generally for telephone calls pertaining to command
and control of military forces essential to defense and and control of military forces essential to defense and
retaliation, critical intelligence essential to national survival, retaliation, critical intelligence essential to national survival,
conduct of diplomatic negotiations critical to the arresting or conduct of diplomatic negotiations critical to the arresting or
limiting of hostilities, dissemination of critical civil alert limiting of hostilities, dissemination of critical civil alert
information essential to national survival, continuity of federal information essential to national survival, continuity of federal
government functions essential to national survival, fulfillment government functions essential to national survival, fulfillment
of critical internal security functions essential to national of critical internal security functions essential to national
survival, or catastrophic events of national or international survival, or catastrophic events of national or international
skipping to change at page 6, line 13 skipping to change at page 6, line 17
immediate effect on aircraft, spacecraft, or missile operations. immediate effect on aircraft, spacecraft, or missile operations.
Priority: reserved generally for telephone calls requiring Priority: reserved generally for telephone calls requiring
expeditious action by called parties and/or furnishing essential expeditious action by called parties and/or furnishing essential
information for the conduct of government operations. information for the conduct of government operations.
Routine: designation applied to those official government Routine: designation applied to those official government
communications that require rapid transmission by telephonic means communications that require rapid transmission by telephonic means
but do not require preferential handling. but do not require preferential handling.
The rule, in MLPP, is that more important calls override less MLPP is intended to deliver a higher probability of call completion
important calls when congestion occurs within a network. Station to the more important calls. The rule, in MLPP, is that more
based preemption is used when a more important call needs to be important calls override less important calls when congestion occurs
placed to either party in an existing call. Trunk based preemption within a network. Station based preemption is used when a more
is used when trunk bandwidth needs to be reallocated to facilitate a important call needs to be placed to either party in an existing
higher precedence call over a given path in the network. In both call. Trunk based preemption is used when trunk bandwidth needs to
station and trunk based preemption scenarios, preempted parties are be reallocated to facilitate a higher precedence call over a given
positively notified, via preemption tone, that their call can no path in the network. In both station and trunk based preemption
longer be supported. The same preemption tone is used, regardless of scenarios, preempted parties are positively notified, via preemption
whether calls are terminated for the purposes of station of trunk tone, that their call can no longer be supported. The same
based preemption. The remainder of this discussion focuses on trunk preemption tone is used, regardless of whether calls are terminated
based preemption issues. for the purposes of station of trunk based preemption. The remainder
of this discussion focuses on trunk based preemption issues.
MLPP is built as a proactive system in which callers must assign one MLPP is built as a proactive system in which callers must assign one
of the precedence levels listed above at call initiation; this of the precedence levels listed above at call initiation; this
precedence level cannot be changed throughout that call. If an precedence level cannot be changed throughout that call. If an
elevated status is not assigned by a user at call initiation time, elevated status is not assigned by a user at call initiation time,
the call is assumed to be "routine". If there is end to end capacity the call is assumed to be "routine". If there is end to end capacity
to place a call, any call may be placed at any time. However, when to place a call, any call may be placed at any time. However, when
any trunk (in the circuit world) or interface (in an IP world) any trunk group (in the circuit world) or interface (in an IP world)
reaches a utilization threshold, a choice must be made as to which reaches a utilization threshold, a choice must be made as to which
calls to accept or allow to continue. The system will seize the calls to accept or allow to continue. The system will seize the
trunks or bandwidth necessary to place the more important calls in trunk(s) or bandwidth necessary to place the more important calls in
preference to less important calls by preempting an existing call (or preference to less important calls by preempting an existing call (or
calls) of lower precedence to permit a higher precedence call to be calls) of lower precedence to permit a higher precedence call to be
placed. placed.
More than one call might properly be preempted if more trunks or More than one call might properly be preempted if more trunks or
bandwidth is necessary for this higher precedence call. A video call bandwidth is necessary for this higher precedence call. A video call
(perhaps of 384 KBPS, or 6 trunks) competing with several lower (perhaps of 384 KBPS, or 6 trunks) competing with several lower
precedence voice calls is a good example of this situation. precedence voice calls is a good example of this situation.
1.1.2. Government Emergency Telecommunications Service 1.1.2. Government Emergency Telecommunications Service
skipping to change at page 7, line 8 skipping to change at page 7, line 17
A US service similar to MLPP and using MLPP signaling technology, but A US service similar to MLPP and using MLPP signaling technology, but
built for use in civilian networks, is the Government Emergency built for use in civilian networks, is the Government Emergency
Telecommunications Service (GETS). This differs from MLPP in two Telecommunications Service (GETS). This differs from MLPP in two
ways: it does not use preemption, but rather reserves bandwidth or ways: it does not use preemption, but rather reserves bandwidth or
queues calls to obtain a high probability of call completion, and it queues calls to obtain a high probability of call completion, and it
has only two levels of service: "Routine" and "Priority". has only two levels of service: "Routine" and "Priority".
1.2. Definition of Call Admission 1.2. Definition of Call Admission
Traditionally, in the PSTN, Call Admission Control (CAC) has had the Traditionally, in the PSTN, Call Admission Control (CAC) has had the
responsibility of determining whether a caller has permission (e.g., responsibility of implementing bandwidth available thresholds (e.g.
is an identified subscriber, with identify attested to by appropriate to limit resources consumed by some traffic) and determining whether
credentials) to use an available circuit. IEPS, or any emergency a caller has permission (e.g., is an identified subscriber, with
telephone service, has additional options that it may employ to identify attested to by appropriate credentials) to use an available
improve the probability of call completion: 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 o The call may be authorized to use other networks that it would not
normally use normally use
o The network may preempt other calls to free bandwidth, o The network may preempt other calls to free bandwidth,
o The network may hold the call and place it when other calls o The network may hold the call and place it when other calls
complete, or complete, or
o The network may use different bandwidth availability thresholds o The network may use different bandwidth availability thresholds
skipping to change at page 7, line 50 skipping to change at page 8, line 12
(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
links", "access links" or "access networks", for various reasons links", "access links" or "access networks", for various reasons
including technology and cost, it is common to find links whose including technology (e.g. satellite links) and cost, it is common to
offered load can approximate or exceed the available capacity. Such find links whose offered load can approximate or exceed the available
events may be momentary, or may occur for extended periods of time. capacity. Such events may be momentary, or may occur for extended
periods of time.
In addition, primarily in tactical deployments, it is common to find In addition, primarily in tactical deployments, it is common to find
bandwidth constraints in the local infrastructure of networks. For bandwidth constraints in the local infrastructure of networks. For
example, the US Navy's network afloat connects approximately 300 example, the US Navy's network afloat connects approximately 300
ships, via satellite, to five network operation centers, and those ships, via satellite, to five network operation centers, and those
NOCs are in turn interconnected via the DISA backbone. A typical NOCs are in turn interconnected via the DISA backbone. A typical
ship may have between two and six radio systems aboard, often at ship may have between two and six radio systems aboard, often at
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.
skipping to change at page 8, line 45 skipping to change at page 9, line 9
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.
With the exception of systems that select rate options according to Voice and video systems, in the main, are designed to deliver a fixed
ambient loss characteristics, voice and video systems do not tune level of quality as perceived by the user. (Exceptions are systems
their behavior to that of the network. Rather, they send traffic at that select rate options over a broad range to adapt to ambient loss
a rate specified by the codec depending on what it perceives is characteristics. These deliver broadly fluctuating perceived quality
required. In an MPEG-4 system, for example, if the camera is pointed and have not found significant commercial applicability.) Rather,
at a wall, the codec determines that an 80 KBPS data stream will they send traffic at a rate specified by the codec depending on what
describe that wall, and issues that amount of traffic. If a person it perceives is required. In an MPEG-4 system, for example, if the
walks in front of the wall or the camera is pointed an a moving camera is pointed at a wall, the codec determines that an 80 KBPS
object, the codec may easily send 800 KBPS in its effort to data stream will describe that wall, and issues that amount of
accurately describe what it sees. In commercial broadcast sports, traffic. If a person walks in front of the wall or the camera is
which may line up periods in which advertisements are displayed, the pointed an a moving object, the codec may easily send 800 KBPS in its
effect is that traffic rates suddenly jump across all channels at effort to accurately describe what it sees. In commercial broadcast
certain times because the eye-catching ads require much more sports, which may line up periods in which advertisements are
bandwidth than the camera pointing at the green football field. displayed, the effect is that traffic rates suddenly jump across all
channels at certain times because the eye- catching ads require much
more bandwidth than the camera pointing at the green football field.
As described in [RFC1633], when dealing with a real-time application, 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
skipping to change at page 10, line 13 skipping to change at page 10, line 32
authorization is granted, other sessions will be preempted to make authorization is granted, other sessions will be preempted to make
way for a call of higher precedence. way for a call of higher precedence.
Authentication and Authorization of calls placed: Unauthorized Authentication and Authorization of calls placed: Unauthorized
attempts to place a call at an elevated status are not permitted. attempts to place a call at an elevated status are not permitted.
In the telephone system, this is managed by controlling the policy In the telephone system, this is managed by controlling the policy
applied to an instrument by its switch plus a code produced by the applied to an instrument by its switch plus a code produced by the
caller identifying himself or herself to the switch. In the caller identifying himself or herself to the switch. In the
Internet, such characteristics must be explicitly signaled. Internet, such characteristics must be explicitly signaled.
Voice handling characteristics: A call made, in the telephone system, Voice handling characteristics: A call made, in the telephone
gets a circuit, and provides the means for the callers to conduct system, gets a circuit, and provides the means for the callers to
their business without significant impact as long as their call is conduct their business without significant impact as long as their
not preempted. In a VoIP system, one would hope for essentially call is not preempted. In a VoIP system, one would hope for
the same service. essentially the same service.
Defined User Interface: If a call is preempted, the caller and the Defined User Interface: If a call is preempted, the caller and the
callee are notified via a defined signal, so that they know that callee are notified via a defined signal, so that they know that
their call has been preempted and that at this instant there is no their call has been preempted and that at this instant there is no
alternative circuit available to them at that precedence level. alternative circuit available to them at that precedence level.
A VoIP implementation of the Internet Emergency Preference Service A VoIP implementation of the Internet Emergency Preference Service
must, by definition, provide those characteristics. must, by definition, provide those characteristics.
1.6. The use of bandwidth as a solution for QoS 1.6. The use of bandwidth as a solution for QoS
skipping to change at page 12, line 38 skipping to change at page 12, line 38
SIP = SIP Proxy SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC) H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router R = Router
/---/ = Ethernet or Ethernet Switch /---/ = Ethernet or Ethernet Switch
Figure 1: Typical VoIP or Video/IP Network Figure 1: Typical VoIP or Video/IP Network
Reviewing that figure, it becomes obvious that Voice/IP and Video/IP Reviewing that figure, it becomes obvious that Voice/IP and Video/IP
call flows are very different than call flows in the PSTN. In the call flows are very different than call flows in the PSTN. In the
PSTN, call control traverses a switch, which in turn controls data PSTN, call control traverses a switch, which in turn controls data
handling services like ATM switches or circuit multiplexers. While handling services like ATM or TDM switches or multiplexers. While
they may not be physically co-located, the control plane software and they may not be physically co-located, the control plane software and
the data plane services are closely connected; the switch routes a the data plane services are closely connected; the switch routes a
call using bandwidth that it knows is available. In a voice/ call using bandwidth that it knows is available. In a voice/
video-on-IP network, call control is completely divorced from the video-on-IP network, call control is completely divorced from the
data plane: It is possible for a telephone instrument in the United data plane: It is possible for a telephone instrument in the United
States to have a Swedish telephone number if that is where its SIP States to have a Swedish telephone number if that is where its SIP
proxy happens to be, but on any given call to use only data paths in proxy happens to be, but on any given call to use only data paths in
the Asia/Pacific region, data paths provided by a different company, the Asia/Pacific region, data paths provided by a different company,
and often data paths provided by multiple companies/providers. and often data paths provided by multiple companies/providers.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
o May I make this call from an administrative policy perspective? o May I make this call from an administrative policy perspective?
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, or do other impairments (loss, delay)
make the call unusable?
2.1. Call admission/preemption procedure 2.1. Call admission/preemption procedure
Administrative Call Admission is the objective of SIP and H.323. It Administrative Call Admission is the objective of SIP and H.323. It
asks fundamental questions like "what IP address is the callee at?" asks fundamental questions like "what IP address is the callee at?"
and "Did you pay your bill?". and "Did you pay your bill?".
For specialized policy like call preemption, two capabilities are For specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: [I-D.ietf-sip-resource- necessary from an administrative perspective:
priority] provides a way to communicate policy-related information [I-D.ietf-sip-resource-priority] provides a way to communicate
regarding the precedence of the call; and [I-D.ietf-sipping-reason- policy-related information regarding the precedence of the call; and
header-for-preemption] provides a reason code when a call fails or is [I-D.ietf-sipping-reason-header-for-preemption] provides a reason
refused, indicating the cause of the event. If it is a failure, it code when a call fails or is refused, indicating the cause of the
may make sense to redial the call. If it is a policy-driven event. If it is a failure, it may make sense to redial the call. If
preemption, even if the call is redialed it may not be possible to it is a policy-driven preemption, even if the call is redialed it may
place the call. Requirements for this service are further discussed not be possible to place the call. Requirements for this service are
in [RFC3689]. 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 (telephone). If the receiving phone does destination (called) device (telephone). If the receiving phone does
skipping to change at page 14, line 7 skipping to change at page 14, line 8
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 requester's authorization this header would be compared to the requester's authorization
profile to use 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 requester 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 are not using a level they are not authorized to
use.)
The DSN has 5 precedence levels of IEPS in descending order: The DSN has 5 precedence levels of IEPS in descending order:
dsn.flash-override dsn.flash-override
dsn.flash dsn.flash
dsn.immediate dsn.immediate
dsn.priority dsn.priority
skipping to change at page 14, line 33 skipping to change at page 14, line 35
levels of precedence. The DRSN simply adds one higher precedence levels of precedence. The DRSN simply adds one higher precedence
level than flash-override: level than flash-override:
drsn.flash-override-override drsn.flash-override-override
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 The Resource-Priority Header (RPH) informs both the use of DSCPs by
the same DSCP as the caller to obtain the same data path service) and the callee (who needs to use the same DSCP as the caller to obtain
to facilitate policy-based preemption of calls in progress when the same data path service) and to facilitate policy-based preemption
appropriate. of calls in progress when appropriate.
Once a call is established in an IEPS domain, the Reason Header for Once a call is established in an IEPS domain, the Reason Header for
Preemption, described in [I-D.ietf-sipping-reason-header-for- Preemption, described in
preemption], ensures that all SIP nodes are synchronized to a [I-D.ietf-sipping-reason-header-for-preemption], ensures that all SIP
preemption event occurring either at the endpoint or in a router that nodes are synchronized to a preemption event occurring either at the
experiences congestion. In SIP, the normal indication for the end of endpoint or in a router that experiences congestion. In SIP, the
a session is for one end system to send a BYE Method request as normal indication for the end of a session is for one end system to
specified in [RFC3261]. This, too, is the proper means for signaling send a BYE Method request as specified in [RFC3261]. This, too, is
a termination of a call due to a preemption event, as it essentially the proper means for signaling a termination of a call due to a
performs a normal termination with additional information informing preemption event, as it essentially performs a normal termination
the peer of the reason for the abrupt end - it indicates that a with additional information informing the peer of the reason for the
preemption occurred. This will be used to inform all relevant SIP abrupt end - it indicates that a preemption occurred. This will be
entities, and whether this was a endpoint generated preemption event, used to inform all relevant SIP entities, and whether this was a
or that the preemption event occurred within a router along the endpoint generated preemption event, or that the preemption event
communications path (described in Section 2.3.1 ). occurred within a router along the communications path (described in
Section 2.3.1 ).
Figure X is a simple example of a SIP call set-up that includes the Figure 2 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 IEPS networks is a accepting the call from Carol. That choice in IEPS networks is a
comparison of Resource Priority headers. Alice, who controlled the comparison of Resource Priority headers. Alice, who controlled the
skipping to change at page 15, line 40 skipping to change at page 16, line 21
|--------------------------->| | |--------------------------->| |
| 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:Generic_preemption) | | BYE (Reason: UA preemption) |
|<---------------------------| | |<---------------------------| |
| | 200 OK | | | 200 OK |
| |---------------------------->| | |---------------------------->|
| 200 OK (BYE) | | | 200 OK (BYE) | |
|--------------------------->| | |--------------------------->| |
| | ACK | | | ACK |
| |<----------------------------| | |<----------------------------|
| | RTP | | | RTP |
| |<===========================>| | |<===========================>|
| | | | | |
skipping to change at page 16, line 4 skipping to change at page 16, line 34
| |---------------------------->| | |---------------------------->|
| 200 OK (BYE) | | | 200 OK (BYE) | |
|--------------------------->| | |--------------------------->| |
| | ACK | | | ACK |
| |<----------------------------| | |<----------------------------|
| | RTP | | | RTP |
| |<===========================>| | |<===========================>|
| | | | | |
Figure 2: Priority Call Establishment and Termination at SIP Layer Figure 2: Priority Call Establishment and Termination at SIP Layer
Nothing in this example involved mechanisms other than SIP. It is Nothing in this example involved mechanisms other than SIP. It is
also assumed each user agent recognized the Resource-Priority also assumed each user agent recognized the Resource-Priority header
header's namespace value. Therefore, it is assumed that the domain namespace value in each message. Therefore, it is assumed that the
allowed Alice, Bob and Carol to communicate. Authentication and domain allowed Alice, Bob and Carol to communicate. Authentication
Authorization are discussed later in this document. and Authorization are discussed later in this document.
2.2. Voice handling characteristics 2.2. Voice handling characteristics
The Quality of Service architecture used in the data path is that of The Quality of Service architecture used in the data path is that of
[RFC2475]. Differentiated Services uses a flag in the IP header [RFC2475]. Differentiated Services uses a flag in the IP header
called the DSCP [RFC2474] to identify a data stream, and then applies called the DSCP [RFC2474] to identify a data stream, and then applies
a procedure called a Per Hop Behavior, or PHB, to it. This is a procedure called a Per Hop Behavior, or PHB, to it. This is
largely as described in the [RFC2998]. largely as described in the [RFC2998].
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247]
skipping to change at page 18, line 6 skipping to change at page 18, line 36
[RFC1633] provides for signaled admission for the use of capacity. [RFC1633] provides for signaled admission for the use of capacity.
The recommended approach is explicit capacity admission, supporting The recommended approach is explicit capacity admission, supporting
the concepts of preemption. An example of such a procedure uses the the concepts of preemption. An example of such a procedure uses the
Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of
Capacity Admission using RSVP with SIP is described in [RFC3312]. Capacity Admission using RSVP with SIP is described in [RFC3312].
While call counting is specified in H.323, network capacity admission While call counting is specified in H.323, network capacity admission
is not integrated with H.323 at this time. is not integrated with H.323 at this time.
2.3.1. RSVP procedure: explicit call admission - RSVP Admission using 2.3.1. RSVP procedure: explicit call admission - RSVP Admission using
Policy Policy for both unicast and multicast sessions
RSVP is a resource reservation setup protocol providing the one-way RSVP is a resource reservation setup protocol providing the one-way
(at a time) setup of resource reservations for multicast and unicast (at a time) setup of resource reservations for multicast and unicast
flows. Each reservation is set up in one direction (meaning one flows. Each reservation is set up in one direction (meaning one
reservation from each end system; in a multicast environment, N reservation from each end system; in a multicast environment, N
senders set up N reservations). These reservations complete a senders set up N reservations). These reservations complete a
communication path with a deterministic bandwidth allocation through communication path with a deterministic bandwidth allocation through
each router along that path between end systems. These reservations each router along that path between end systems. These reservations
setup a known quality of service for end-to-end communications and setup a known quality of service for end-to-end communications and
maintain a "soft-state" within a node. The meaning of the term "soft maintain a "soft-state" within a node. The meaning of the term "soft
skipping to change at page 18, line 30 skipping to change at page 19, line 13
30 seconds, but may be as long as appropriate. 30 seconds, but may be as long as appropriate.
RSVP is a locally-oriented process, not a globally- or domain- RSVP is a locally-oriented process, not a globally- or domain-
oriented one like a routing protocol or like H.323 Call Counting. oriented one like a routing protocol or like H.323 Call Counting.
Although it uses the local routing databases to determine the routing Although it uses the local routing databases to determine the routing
path, it is only concerned with the quality of service for a path, it is only concerned with the quality of service for a
particular or aggregate flow through a device. RSVP is not aware of particular or aggregate flow through a device. RSVP is not aware of
anything other than the local goal of QoS and its RSVP-enabled anything other than the local goal of QoS and its RSVP-enabled
adjacencies, operating below the network layer. The process by adjacencies, operating below the network layer. The process by
itself neither requires nor has any end-to-end network knowledge or itself neither requires nor has any end-to-end network knowledge or
state. Thus, RSVP can be enabled in a network without the need to state. Thus, RSVP can be effective when it is enabled at some nodes
have every node participate. in a network without the need to have every node participate.
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| _______ | | | | _______ | | |
| | | _______ | | _______ | | | | _______ | | _______ |
| |Appli- | | | |RSVP | | | | | |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <----------> | | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | | | | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ | | | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy|| | |_._____| | -->Policy| || <--> -->Policy||
skipping to change at page 21, line 17 skipping to change at page 21, line 29
router between each endpoint. Aggregation of flows reduces the router between each endpoint. Aggregation of flows reduces the
number of completely individual reservations into groups of number of completely individual reservations into groups of
individual flows that can act as one for part or all of the journey individual flows that can act as one for part or all of the journey
between end systems. Aggregates are not intended to be from the between end systems. Aggregates are not intended to be from the
first router to the last router within a flow, but to cover common first router to the last router within a flow, but to cover common
paths of a large number of individual flows. paths of a large number of individual flows.
Examples of aggregated data flows include streams of IP data that Examples of aggregated data flows include streams of IP data that
traverse common ingress and egress points in a network, and also traverse common ingress and egress points in a network, and also
include tunnels of various kinds. MPLS LSPs, IPSEC Security include tunnels of various kinds. MPLS LSPs, IPSEC Security
Associations between VPN edge routers, similar tunnels between HAIPE Associations between VPN edge routers, IP/IP tunnels, and GRE tunnels
encryptors and decryptors, IP/IP tunnels, and GRE tunnels all fall all fall into this general category. The distinguishing factor is
into this general category. The distinguishing factor is that the that the system injecting an aggregate into the aggregated network
system injecting an aggregate into the aggregated network sums the sums the PATH and RESV statistical information on the un- aggregated
PATH and RESV statistical information on the un-aggregated side and side and produces a reservation for the tunnel on the aggregated
produces a reservation for the tunnel on the aggregated side. If the side. If the bandwidth for the tunnel cannot be expanded, RSVP
bandwidth for the tunnel cannot be expanded, RSVP leaves the existing leaves the existing reservation in place and returns an error to the
reservation in place and returns an error to the aggregator, which aggregator, which can then apply a policy such as IEPS to determine
can then apply a policy such as IEPS to determine which session to which session to refuse. In the data plane, the DSCP for the traffic
refuse. In the data plane, the DSCP for the traffic must be copied must be copied from the inner to the outer header, to preserve the
from the inner to the outer header, to preserve the PHB's effect. 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
skipping to change at page 27, line 10 skipping to change at page 27, line 10
sense that a failure of the various authentication or authorization sense that a failure of the various authentication or authorization
procedures can cause a fundamental breakdown in communications. procedures can cause a fundamental breakdown in communications.
However, the issues are internal to the various component protocols, However, the issues are internal to the various component protocols,
and are covered by their various security procedures. and are covered by their various security procedures.
5. Acknowledgements 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, Subha Dhesikan, and Tony
Babendreier, Ken Carlberg, and Mike Pierce provided useful reviews. De Simone. Pete 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 [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, Emergency Telecommunication Service (ETS)", RFC 3689,
February 2004. February 2004.
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunication Service (ETS)", RFC 3690, for Emergency Telecommunication Service (ETS)", RFC 3690,
February 2004. February 2004.
6.2. Informative References 6.2. Integrated Services Architecture References
[ANSI.MLPP.Spec]
American National Standards Institute, "Telecommunications
- Integrated Services Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability",
ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement]
American National Standards Institute, "MLPP Service
Domain Cause Value Changes", ANSI ANSI T1.619a-1994
(R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", 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]
Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
draft-ietf-sip-resource-priority-10 (work in progress),
July 2005.
[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Extending the Session Initiation Protocol
Reason Header for Preemption Events",
draft-ietf-sipping-reason-header-for-preemption-03 (work
in progress), July 2005.
[I-D.pierce-tsvwg-assured-service-arch]
Pierce, M., "Architecture for Assured Service Capabilities
in Voice over IP",
draft-pierce-tsvwg-assured-service-arch-01 (work in
progress), October 2004.
[I-D.pierce-tsvwg-assured-service-req]
Pierce, M., "Requirements for Assured Service Capabilities
in Voice over IP",
draft-pierce-tsvwg-assured-service-req-01 (work in
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]
International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", ITU-
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
skipping to change at page 30, line 28 skipping to change at page 28, line 40
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,
M., Romanow, A., Weinrib, A., and L. Zhang, "Resource M., Romanow, A., Weinrib, A., and L. Zhang, "Resource
ReSerVation Protocol (RSVP) Version 1 Applicability ReSerVation Protocol (RSVP) Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208, Statement Some Guidelines on Deployment", RFC 2208,
September 1997. 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
Protocol", RFC 2327, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000. "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000. RFC 2750, January 2000.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, for Policy-based Admission Control", RFC 2753,
January 2000. January 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000. November 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC 2998, November 2000. over Diffserv Networks", RFC 2998, November 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
skipping to change at page 31, line 31 skipping to change at page 29, line 28
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for Herzog, S., and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001. RSVP", RFC 3182, October 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
6.3. Differentiated Services Architecture References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Ramakrishnan, "Supplemental Information for the New
Definition of the EF PHB (Expedited Forwarding Per-Hop Definition of the EF PHB (Expedited Forwarding Per-Hop
Behavior)", RFC 3247, March 2002. Behavior)", RFC 3247, March 2002.
6.4. Session Initiation Protocol and related References
[I-D.ietf-sip-resource-priority]
Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
draft-ietf-sip-resource-priority-10 (work in progress),
July 2005.
[I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Extending the Session Initiation Protocol
Reason Header for Preemption Events",
draft-ietf-sipping-reason-header-for-preemption-04 (work
in progress), September 2005.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
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.5. Informative References
[ANSI.MLPP.Spec]
American National Standards Institute, "Telecommunications
- Integrated Services Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability",
ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement]
American National Standards Institute, "MLPP Service
Domain Cause Value Changes", ANSI ANSI T1.619a-1994
(R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", 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>.
[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]
International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", ITU-
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.
[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.
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],
preemption], [I-D.ietf-sip-resource-priority]. There will be some [I-D.ietf-sipping-reason-header-for-preemption],
discussion on basic RSVP operations regarding reservation paths, this [I-D.ietf-sip-resource-priority]. There will be some discussion on
will be mostly from [RFC2205]. basic RSVP operations regarding reservation paths, this will be
mostly from [RFC2205].
SIP signaling occurs at layer 7, riding on a UDP/IP or TCP/IP SIP signaling occurs at the Application Layer, riding on a UDP/IP or
(including TLS/TCP/IP) transport that is bound by routing protocols TCP/IP (including TLS/TCP/IP) transport that is bound by routing
such as BGP and OSPF to determine the route the packets traverse protocols such as BGP and OSPF to determine the route the packets
through a network between source and destination devices. RSVP is traverse through a network between source and destination devices.
riding on top of IP as well, which means RSVP is at the mercy of the RSVP is riding on top of IP as well, which means RSVP is at the mercy
IP routing protocols to determine a path through the network between of the IP routing protocols to determine a path through the network
endpoints. RSVP is not a routing protocol. In this appendix there between endpoints. RSVP is not a routing protocol. In this appendix
will be a escalation of building blocks getting to how the many there will be a escalation of building blocks getting to how the many
layers are involved in SIP with QoS Preconditions requiring layers are involved in SIP with QoS Preconditions requiring
successful RSVP signaling between endpoints prior to SIP successfully successful RSVP signaling between endpoints prior to SIP successfully
acknowledging the set-up of the session (for voice or video or both). acknowledging the set-up of the session (for voice or video or both).
Then we will present what occurs when a network overload occurs Then we will present what occurs when a network overload occurs
(congestion), causing a SIP session to be preempted. (congestion), causing a SIP session to be preempted.
There are 3 diagrams in this appendix to show multiple views of the There are three diagrams in this appendix to show multiple views of
same example of connectivity for discussion throughout this appendix. the same example of connectivity for discussion throughout this
The first diagram (Figure 5) is of many routers between many appendix. The first diagram (Figure 5) is of many routers between
endpoints (SIP user agents, or UAs). There are 4 UAs of interest, many endpoints (SIP user agents, or UAs). There are 4 UAs of
those are for users Alice, Bob, Carol and Dave. When a user (the interest, those are for users Alice, Bob, Carol and Dave. When a
human) of a UA gets involved and must do something to a UA to user (the human) of a UA gets involved and must do something to a UA
progress a SIP process, this will be explicitly mentioned to avoid to progress a SIP process, this will be explicitly mentioned to avoid
confusion; otherwise, when Alice is referred to - this means Alice's confusion; otherwise, when Alice is referred to - this means Alice's
UA (her phone) in the text here. UA (her phone) in the text here.
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
skipping to change at page 36, line 13 skipping to change at page 35, line 13
RSVP will be initiated. That messaging will also be discussed below. RSVP will be initiated. That messaging will also be discussed below.
UA Alice UA Bob UA Alice UA Bob
| | | |
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | Note 1 | | Note 1
|<------(2) 183 Session Progress SDP2--------| | |<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+ ***|********************************************|***<-+
* |----------------(3) PRACK------------------>| * * |----------------(3) PRACK------------------>| *
* | | * When * | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP * |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is * | | * is
* | | * signaled * | | * signaled
***|********************************************|*** ***|********************************************|***
|-------------(5) UPDATE SDP3--------------->| |-------------(5) UPDATE SDP3--------------->|
| | | |
|<--------(6) 200 OK (UPDATE) SDP4-----------| |<--------(6) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-------------(7) 180 Ringing---------------| |<-------------(7) 180 Ringing---------------|
| | | |
skipping to change at page 37, line 14 skipping to change at page 36, line 14
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory] [M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0 INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil> To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE CSeq: 31862 INVITE
Requires: 100rel Requires: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil> Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 191 Content-Length: 191
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 8 m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper From the INVITE above, Alice is inviting Bob to a session. The upper
skipping to change at page 37, line 32 skipping to change at page 36, line 31
c=IN IP4 10.1.3.33 c=IN IP4 10.1.3.33
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 4 8 m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper From the INVITE above, Alice is inviting Bob to a session. The upper
half of the lines (above the line 'v=0') are SIP headers and header half of the lines (above the line 'v=0') are SIP headers and header
values, the lower half of the lines above are Session Description values, the lower half of the lines above are Session Description
Protocol (SDP) lines. SIP headers (after the first line) are not to Protocol (SDP) lines. SIP headers (after the first line, called the
be in any particular order, with one exception: the Via header. It Status line) are not mandated in any particular order, with one
is a SIP hop (through a SIP Proxy) route path that has a new Via exception: the Via header. It is a SIP hop (through a SIP Proxy)
header line added by each SIP proxy this message traverses. This is route path that has a new Via header line added by each SIP element
similar in function to an RSVP PATH message (building a reverse path this message traverses towards the destination UA. This is similar
back to the originator of the message). At any point in the in function to an RSVP PATH message (building a reverse path back to
message's path, a SIP element knows the path to the originator of the the originator of the message). At any point in the message's path,
message. There will be no SIP Proxies in this example, because for a SIP element knows the path to the originator of the message. There
Preconditions, Proxies only make more messages that look identical will be no SIP Proxies in this example, because for Preconditions,
(with the exception of the Via and Max-Forwards headers), and that is Proxies only make more messages that look identical (with the
not worth the space here to replicate what has been done in SIP RFCs exception of the Via and Max-Forwards headers), and that is not worth
already. the space here to replicate what has been done in SIP RFCs already.
SIP headers that are used for Preconditions are the: SIP headers that are used for Preconditions are 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), mandates that preconditions are attempted, and
mandates support for the Resource-Priority header. Each of these
option-tags can be explicitly identified in a message failure
indication from the called UA to tell the calling UA what was not
supported.
This will result in the 183 "Session Progress" message from Bob's UA Provided this INVITE message is received as acceptable, this will
as a reliable confirmation that preconditions are required for this result in the 183 "Session Progress" message from Bob's UA as a
call. reliable confirmation that preconditions are required for this call.
- Resource-Priority header - which denotes the domain namespace - Resource-Priority header - which denotes the domain namespace
and precedence level of the call on an end-to-end basis. and precedence level of the call on an end-to-end basis.
And that's it for SIP. Preconditions is requested, required and This completes SIPs functions in session initiation. Preconditions
signaled for in the SDP portion of the message. SDP is carried in are requested, required and signaled for in the SDP portion of the
what's called a SIP message body (much like the text in an email message. SDP is carried in what's called a SIP message body (much
message is carried). SDP has special properties [see [RFC2327] for like the text in an email message is carried). SDP has special
more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP]. properties [see [RFC2327] for more on SDP, or the MMUSIC WG for
SDP lines are in a specific order for parsing reasons by end systems. ongoing efforts regarding SDP]. SDP lines are in a specific order
Dialog (Call) generating SDP message bodies all must have an "m" line for parsing reasons by end systems. Dialog (Call) generating SDP
(or media description line). Following the "m" line is zero or more message bodies all must have an "m" line (or media description line).
"a" lines (or Attribute lines). The m-line in Alice's INVITE calls Following the "m" line is zero or more "a" lines (or Attribute
for a voice session (this is where video is identified also) using lines). The m-line in Alice's INVITE calls for a voice session (this
one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723 is where video is identified also) using one of 3 different codecs
and 18 = G.729) that Bob gets to choose from for this session. Bob that Alice supports (0 = G.711, 4 = G.723 and 18 = G.729) that Bob
can choose any of the 3. The first a=rtpmap line is specific to the gets to choose from for this session. Bob can choose any of the 3.
type of codec these 3 are (PCMU). The next two a-lines are the only The first a=rtpmap line is specific to the type of codec these 3 are
identifiers that RSVP is to be used for this call. The second (PCMU). The next two a-lines are the only identifiers that RSVP is
a-line: to be used for this call. The second a-line:
a=curr:qos e2e none a=curr:qos e2e none
identifies the "current" status of qos at Alice's UA. Note: identifies the "current" status of qos at Alice's UA. Note:
everything in SDP is with respect to the sender of the SDP message everything in SDP is with respect to the sender of the SDP message
body (Alice will never tell Bob how his SDP is, she will only tell body (Alice will never tell Bob how his SDP is, she will only tell
Bob about her SDP). Bob about her SDP).
"e2e" means that capacity assurance is required from Alice's UA to "e2e" means that capacity assurance is required from Alice's UA to
Bob's UA; meaning a lack of available capacity assurance in either Bob's UA; meaning a lack of available capacity assurance in either
skipping to change at page 39, line 29 skipping to change at page 38, line 32
;branch=z9hG4bK74bf9 ;received=10.1.3.33 ;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356 To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE CSeq: 31862 INVITE
RSeq: 813520 RSeq: 813520
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil> Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 210 Content-Length: 210
v=0 v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 172.16.1.36 c=IN IP4 10.100.50.51
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=curr:qos e2e none a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv a=conf:qos e2e recv
Figure 9 Figure 9
The only interesting header in the SIP portion of this message is the The only interesting header in the SIP portion of this message is the
skipping to change at page 44, line 31 skipping to change at page 43, line 7
travels downstream towards the originator of the RESV message (Bob). travels downstream towards the originator of the RESV message (Bob).
This clears the reservation in all routers downstream of R2 (meaning This clears the reservation in all routers downstream of R2 (meaning
R3 and R4). Once Bob receives the ResvErr message indicating R3 and R4). Once Bob receives the ResvErr message indicating
preemption has occurred on this reservation, Bob's UA transmits a SIP preemption has occurred on this reservation, Bob's UA transmits a SIP
preemption indication back towards Alice's UA. This accomplishes two preemption indication back towards Alice's UA. This accomplishes two
things: first it informs all SIP Servers that were in the session things: first it informs all SIP Servers that were in the session
set-up path that wanted to remain "dialog stateful" per [RFC3261]], 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, "Reserved
"Generic_preemption". Here is that message from Bob to Alice that Resources Preempted". 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: preemption ;cause=2 ;text=network preemption Reason: preemption ;cause=2 ;text=reserved resourced preempted
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
skipping to change at page 45, line 16 skipping to change at page 43, line 40
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 router
this example) generating a syslog message to the domain administrator R2 (in this example) generating a syslog message to the domain
to properly manage and track such events within this domain. This administrator to properly manage and track such events within this
will ensure the domain administrators have recorded knowledge of domain. This will ensure the domain administrators have recorded
where such events occur, and what the conditions were that caused knowledge of where such events occur, and what the conditions were
them. that caused them.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Fax: +1-413-473-2403 Fax: +1-413-473-2403
Email: fred@cisco.com Email: fred@cisco.com
James Polk James Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
Phone: +1-469-255-5208 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
skipping to change at page 47, line 29 skipping to change at page 45, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 67 change blocks. 
311 lines changed or deleted 325 lines changed or added

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