draft-ietf-tsvwg-mlpp-that-works-00.txt   draft-ietf-tsvwg-mlpp-that-works-01.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Expires: August 11, 2005 Cisco Systems Expires: January 7, 2006 Cisco Systems
February 7, 2005 July 6, 2005
Implementing MLPP for Voice and Video in the Internet Protocol Suite Implementing MLPP for Voice and Video in the Internet Protocol Suite
draft-ietf-tsvwg-mlpp-that-works-00 draft-ietf-tsvwg-mlpp-that-works-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 11, 2005. This Internet-Draft will expire on January 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Defense Information Systems Agency of the United States The Defense Information Systems Agency of the United States
Department of Defense, with its contractors, has proposed a service Department of Defense, with its contractors, has proposed a service
architecture for military (NATO and related agencies) telephone architecture for military (NATO and related agencies) telephone
skipping to change at page 2, line 21 skipping to change at page 2, line 19
needs of this architecture. Such a CAC procedure and PHB is needs of this architecture. Such a CAC procedure and PHB is
appropriate to any service that might use H.323 or SIP to set up real appropriate to any service that might use H.323 or SIP to set up real
time sessions. These obviously include but are not limited to Voice time sessions. These obviously include but are not limited to Voice
and Video applications, although at this writing the community is and Video applications, although at this writing the community is
mostly thinking about Voice on IP and many of the examples in the mostly thinking about Voice on IP and many of the examples in the
document are taken from that environment. document are taken from that environment.
In a network where a call that is permitted initially and is not In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be procedures performed only at the time of call setup may be
sufficient. However in a network where sessions status can be sufficient. However in a network where sessions' status can be
reviewed by the network and preempted or denied due to changes in reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls them) or changes in offered load (where higher precedence calls
supercede existing calls), maintaining a continuing model of the supercede existing calls), maintaining a continuing model of the
status of the various calls is required. status of the various calls is required.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4
skipping to change at page 3, line 46 skipping to change at page 3, line 46
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Normative References . . . . . . . . . . . . . . . . . . . 27 6.1 Normative References . . . . . . . . . . . . . . . . . . . 27
6.2 Informative References . . . . . . . . . . . . . . . . . . 29 6.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
A. 2-Call Preemption Example using RSVP . . . . . . . . . . . . . 32 A. 2-Call Preemption Example using RSVP . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . 44
1. Overview 1. Overview
The Defense Information Systems Agency of the United States The Defense Information Systems Agency of the United States
Department of Defense, with is contractors, has proposed a service Department of Defense, with is contractors, has proposed a service
architecture for military (NATO and related agencies) telephone architecture for military (NATO and related agencies) telephone
systems. This is called the Assured Service, and is defined in two systems. This is called the Assured Service, and is defined in two
documents: [I-D.pierce-ieprep-assured-service-arch] and documents: [I-D.pierce-ieprep-assured-service-arch] and [I-D.pierce-
[I-D.pierce-ieprep-assured-service-req]. Responding to these are two ieprep-assured-service-req]. Responding to these are two documents:
documents: [I-D.ietf-sipping-reason-header-for-preemption] and [I-D.ietf-sipping-reason-header-for-preemption] and [I-D.ietf-sip-
[I-D.ietf-sip-resource-priority]. resource-priority].
What remains to this specification is to provide a Call Admission What remains to this specification is to provide a Call Admission
Control procedure and a Per Hop Behavior for the data which meet the Control procedure and a Per Hop Behavior for the data which meet the
needs of this architecture. Such a CAC procedure and PHB is needs of this architecture. Such a CAC procedure and PHB is
appropriate to any service that might use H.323 or SIP to set up real appropriate to any service that might use H.323 or SIP to set up real
time sessions. These obviously include but are not limited to Voice time sessions. These obviously include but are not limited to Voice
and Video applications, although at this writing the community is and Video applications, although at this writing the community is
mostly thinking about Voice on IP and many of the examples in the mostly thinking about Voice on IP and many of the examples in the
document are taken from that environment. document are taken from that environment.
In a network where a call that is permitted initially and is not In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be procedures performed only at the time of call setup may be
sufficient. However in a network where sessions status can be sufficient. However in a network where sessions' status can be
reviewed by the network and preempted or denied due to changes in reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls them) or changes in offered load (where higher precedence calls
supercede existing calls), maintaining a continuing model of the supercede existing calls), maintaining a continuing model of the
status of the various calls is required. status of the various calls is required.
1.1 Multi-Level Preemption and Precedence 1.1 Multi-Level Preemption and Precedence
Before doing so, however, let us discuss the problem that MLPP is Before doing so, however, let us discuss the problem that MLPP is
intended to solve and the architecture of the system. The Assured intended to solve and the architecture of the system. The Assured
Service is designed as an IP implementation of an existing Service is designed as an IP implementation of an existing ITU-T/
ITU-T/NATO/DoD telephone system architecture known as NATO/DoD telephone system architecture known as [ITU.MLPP.1990]
[ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supplement], or MLPP. MLPP [ANSI.MLPP.Spec] [ANSI.MLPP.Supplement], or MLPP. MLPP is an
is an architecture for a prioritized call handling service such that architecture for a prioritized call handling service such that in
in times of emergency in the relevant NATO and DoD commands, the times of emergency in the relevant NATO and DoD commands, the
relative importance of various kinds of communications is strictly relative importance of various kinds of communications is strictly
defined, allowing higher precedence communication at the expense of defined, allowing higher precedence communication at the expense of
lower precedence communications. These precedences, in descending lower precedence communications. These precedences, in descending
order, are: order, are:
Flash Override Override: used by the Commander in Chief, Secretary of Flash Override Override: used by the Commander in Chief, Secretary of
Defense, and Joint Chiefs of Staff, Commanders of combatant Defense, and Joint Chiefs of Staff, Commanders of combatant
commands when declaring the existence of a state of war. commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other One or Defense Emergency or Air Defense Emergency and other
skipping to change at page 8, line 27 skipping to change at page 8, line 27
Voice and video systems do not tune their behavior to that of the Voice and video systems do not tune their behavior to that of the
network. Rather, they send traffic at a rate specified by the codec network. Rather, they send traffic at a rate specified by the codec
depending on what it perceives is required. In an MPEG-4 system, for depending on what it perceives is required. In an MPEG-4 system, for
example, if the camera is pointed at a wall, the codec determines example, if the camera is pointed at a wall, the codec determines
that an 80 KBPS data stream will describe that wall, and issues that that an 80 KBPS data stream will describe that wall, and issues that
amount of traffic. If a person walks in front of the wall or the amount of traffic. If a person walks in front of the wall or the
camera is pointed an a moving object, the codec may easily send 800 camera is pointed an a moving object, the codec may easily send 800
KBPS in its effort to accurately describe what it sees. In KBPS in its effort to accurately describe what it sees. In
commercial broadcast sports, which may line up periods in which commercial broadcast sports, which may line up periods in which
advertisements are displayed, the effect is that traffic rates advertisements are displayed, the effect is that traffic rates
suddenly jump across all channels at certain times because the suddenly jump across all channels at certain times because the eye-
eye-catching ads require much more bandwidth than the camera pointing catching ads require much more bandwidth than the camera pointing at
at the green football field. 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 behavior has a debilitating effect on the application, as non-
non-negligible loss has on voice or video, one must admit sessions negligible loss has on voice or video, one must admit sessions
judiciously according to some policy. A key characteristic of that judiciously according to some policy. A key characteristic of that
policy must be that the offered load does not exceed the capacity policy must be that the offered load does not exceed the capacity
dedicated to the application. dedicated to the application.
In the network, the other thing one must do is ensure that the In the network, the other thing one must do is ensure that the
application's needs are met in terms of loss, variation in delay, and application's needs are met in terms of loss, variation in delay, and
end to end delay. One way to do this is to supply sufficient end to end delay. One way to do this is to supply sufficient
bandwidth that loss and jitter are nominal. Where that cannot be bandwidth that loss and jitter are nominal. Where that cannot be
accomplished, one must use queuing technology to deterministically accomplished, one must use queuing technology to deterministically
apply bandwidth to accomplish the goal. apply bandwidth to accomplish the goal.
skipping to change at page 11, line 41 skipping to change at page 11, line 41
/---/ = 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 switches or circuit 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 call using bandwidth that it knows is available. In a voice/
voice/video-on-IP network, call control is completely divorced from video-on-IP network, call control is completely divorced from the
the data plane: It is possible for a telephone instrument in the data plane: It is possible for a telephone instrument in the United
United States to have a Swedish telephone number if that is where its States to have a Swedish telephone number if that is where its SIP
SIP proxy happens to be, but on any given call to use only data paths proxy happens to be, but on any given call to use only data paths in
in the Asia/Pacific region, data paths provided by a different the Asia/Pacific region, data paths provided by a different company,
company, and often data paths provided by multiple and often data paths provided by multiple companies/providers.
companies/providers.
Call management therefore addresses a variety of questions, all of Call management therefore addresses a variety of questions, all of
which must be answered: which must be answered:
o May I make this call from an administrative policy perspective? o May I make this call from an administrative policy perspective?
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?
skipping to change at page 12, line 23 skipping to change at page 12, line 23
o Does the call actually work? o Does the call actually work?
2.1 Call admission/preemption procedure 2.1 Call admission/preemption procedure
Administrative Call Admission is the objective of SIP and H.323. It Administrative Call Admission is the objective of SIP and H.323. It
asks fundamental questions like "what IP address is the callee at?" asks fundamental questions like "what IP address is the callee at?"
and "Did you pay your bill?". and "Did you pay your bill?".
For specialized policy like call preemption, two capabilities are For specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: necessary from an administrative perspective: [I-D.ietf-sip-resource-
[I-D.ietf-sip-resource-priority] provides a way to communicate priority] provides a way to communicate policy-related information
policy-related information regarding the precedence of the call; and regarding the precedence of the call; and [I-D.ietf-sipping-reason-
[I-D.ietf-sipping-reason-header-for-preemption] provides a reason header-for-preemption] provides a reason code when a call fails or is
code when a call fails or is refused, indicating the cause of the refused, indicating the cause of the event. If it is a failure, it
event. If it is a failure, it may make sense to redial the call. If may make sense to redial the call. If it is a policy-driven
it is a policy-driven preemption, even if the call is redialed it may preemption, even if the call is redialed it may not be possible to
not be possible to place the call. place the call.
The Communications Resource Priority Header (or RP Header) serves the The Communications Resource Priority Header (or RP Header) serves the
call set-up process with the precedence level chosen by the initiator call set-up process with the precedence level chosen by the initiator
of the call. The syntax is in the form: of the call. The syntax is in the form:
Resource Priority : namespace.priority level Resource Priority : namespace.priority level
The "namespace" part of the syntax ensures the domain of significance The "namespace" part of the syntax ensures the domain of significance
to the originator of the call, and this travels end-to-end to the to the originator of the call, and this travels end-to-end to the
destination (called) device (phone). If the receiving phone does not destination (called) device (phone). If the receiving phone does not
support the namespace, it can easily ignore (what support the namespace, it can easily ignore (what [I-D.ietf-sip-
[I-D.ietf-sip-resource-priority] calls "loose mode") or errors (what resource-priority] calls "loose mode") or errors (what [I-D.ietf-sip-
[I-D.ietf-sip-resource-priority] calls "strict mode") the set-up resource-priority] calls "strict mode") the set-up request. This
request. This ability to denote the domain of origin allows SLAs to ability to denote the domain of origin allows SLAs to be in place to
be in place to limit the ability of an unknown requestor to gain limit the ability of an unknown requestor to gain preferential
preferential treatment into an MLPP domain. treatment into an MLPP domain.
For the DSN infrastructure, this header would look like this: For the DSN infrastructure, this header would look like this:
Resource Priority : dsn.routine Resource Priority : dsn.routine
for a routine precedence level call. The precedence level chosen in for a routine precedence level call. The precedence level chosen in
this header would be compared to the requestor's authorization this header would be compared to the requestor's authorization
profile to user that precedence level. This would typically occur in profile to user that precedence level. This would typically occur in
the SIP first hop Proxy, which can challenge many aspects of the call the SIP first hop Proxy, which can challenge many aspects of the call
set-up request including the requestor choice of precedence levels set-up request including the requestor choice of precedence levels
(verifying they aren't using a level they are not authorized to use.) (verifying they aren't using a level they are not authorized to use.)
skipping to change at page 13, line 41 skipping to change at page 13, line 41
namespace changed for this level. The lower 5 levels within the DRSN namespace changed for this level. The lower 5 levels within the DRSN
would also have this as their namespace for all DRSN originated call would also have this as their namespace for all DRSN originated call
set-up requests. set-up requests.
This informs both the use of DSCPs by the callee (who needs to use This informs both the use of DSCPs by the callee (who needs to use
the same DSCP as the caller to obtain the same data path service) and the same DSCP as the caller to obtain the same data path service) and
to facilitate policy-based preemption of calls in progress when to facilitate policy-based preemption of calls in progress when
appropriate. appropriate.
Once a call is established in an MLPP domain, the Reason Header for Once a call is established in an MLPP domain, the Reason Header for
Preemption, described in Preemption, described in [I-D.ietf-sipping-reason-header-for-
[I-D.ietf-sipping-reason-header-for-preemption], ensures that all SIP preemption], ensures that all SIP nodes are synchronized to a
nodes are synchronized to a preemption event occurring either at the preemption event occurring either at the endpoint or in a router that
endpoint or in a router that experiences congestion. In SIP, the experiences congestion. In SIP, the normal indication for the end of
normal indication for the end of a session is for one end system to a session is for one end system to send a BYE Method request as
send a BYE Method request as specified in [RFC3261]. This, too, is specified in [RFC3261]. This, too, is the proper means for signaling
the proper means for signaling a termination of a call due to a a termination of a call due to a preemption event, as it essentially
preemption event, as it essentially performs a normal termination performs a normal termination with additional information informing
with additional information informing the peer of the reason for the the peer of the reason for the abrupt end - it indicates that a
abrupt end - it indicates that a preemption occurred. This will be preemption occurred. This will be used to inform all relevant SIP
used to inform all relevant SIP entities, and whether this was a entities, and whether this was a endpoint generated preemption event,
endpoint generated preemption event, or that the preemption event or that the preemption event occurred within a router along the
occurred within a router along the communications path (described in communications path (described in Section 2.3.1 ).
Section 2.3.1 ).
Figure X is a simple example of a SIP call set-up that includes the Figure X is a simple example of a SIP call set-up that includes the
layer 7 precedence of a call between Alice and Bob. After Alice layer 7 precedence of a call between Alice and Bob. After Alice
successfully sets up a call to Bob at the "Routine" precedence level, successfully sets up a call to Bob at the "Routine" precedence level,
Carol calls Bob at a higher precedence level (Immediate). At the SIP Carol calls Bob at a higher precedence level (Immediate). At the SIP
layer (this has nothing to do with RSVP yet, that example involving layer (this has nothing to do with RSVP yet, that example involving
SIP and RSVP signaling will be in the appendix), once Bob's user SIP and RSVP signaling will be in the appendix), once Bob's user
agent (phone) receives the INVITE message from Carol, his UA needs to agent (phone) receives the INVITE message from Carol, his UA needs to
make a choice between retaining the call to Alice and sending Carol a make a choice between retaining the call to Alice and sending Carol a
"busy" indication, or preempting the call to Alice in favor of "busy" indication, or preempting the call to Alice in favor of
skipping to change at page 17, line 22 skipping to change at page 17, line 22
several possible approaches. several possible approaches.
An approach that is commonly used in H.323 networks is to limit the An approach that is commonly used in H.323 networks is to limit the
number of calls simultaneously accepted by the gatekeeper. SIP number of calls simultaneously accepted by the gatekeeper. SIP
networks do something similar when they place a SIP proxy near a networks do something similar when they place a SIP proxy near a
single ingress/egress to the network. This is able to impose an single ingress/egress to the network. This is able to impose an
upper bound on the total number of calls in the network or the total upper bound on the total number of calls in the network or the total
number of calls crossing the significant link. However, the number of calls crossing the significant link. However, the
gatekeeper has no knowledge of routing, so the engineering must be gatekeeper has no knowledge of routing, so the engineering must be
very conservative, and usually requires a single ingress/egress - a very conservative, and usually requires a single ingress/egress - a
single point of failure. While this may serve as a short term single point of failure. While this may serve as a short term work-
work-around, it is not a general solution that is readily deployed. around, it is not a general solution that is readily deployed. This
This limits the options in network design. limits the options in network design.
The [RFC1633] provides for signalled admission for the use of The [RFC1633] provides for signalled admission for the use of
capacity. This is currently implemented using the Resource capacity. This is currently implemented using the Resource
Reservation Protocol [RFC2205][RFC2209] (RSVP). The use of Capacity Reservation Protocol [RFC2205][RFC2209] (RSVP). The use of Capacity
Admission with SIP is described in [RFC3312] ; at this writing, Admission with SIP is described in [RFC3312] ; at this writing,
Capacity Admission is not integrated with H.323. Capacity Admission is not integrated with H.323.
2.3.1 Recommended procedure: explicit call admission - RSVP Admission 2.3.1 Recommended procedure: explicit call admission - RSVP Admission
using Policy using Policy
skipping to change at page 17, line 49 skipping to change at page 17, line 49
senders set up N reservations). These reservations complete a senders set up N reservations). These reservations complete a
communication path with a deterministic bandwidth allocation through communication path with a deterministic bandwidth allocation through
each router along that path between end systems. These reservations each router along that path between end systems. These reservations
setup a known quality of service for end-to-end communications and setup a known quality of service for end-to-end communications and
maintain a "soft-state" within a node. The meaning of the term "soft maintain a "soft-state" within a node. The meaning of the term "soft
state" is that in the event of a network outage or change of routing, state" is that in the event of a network outage or change of routing,
these reservations are cleared without manual intervention, but must these reservations are cleared without manual intervention, but must
be periodically refreshed. In RSVP, the refresh period is by default be periodically refreshed. In RSVP, the refresh period is by default
30 seconds, but may be as long as appropriate. 30 seconds, but may be as long as appropriate.
RSVP is a locally-oriented process, not a globally- or RSVP is a locally-oriented process, not a globally- or domain-
domain-oriented one like a routing protocol or like H.323 Call oriented one like a routing protocol or like H.323 Call Counting.
Counting. Although it uses the local routing databases to determine Although it uses the local routing databases to determine the routing
the routing path, it is only concerned with the quality of service path, it is only concerned with the quality of service for a
for a particular or aggregate flow through a device. RSVP is not particular or aggregate flow through a device. RSVP is not aware of
aware of anything other than the local goal of QoS and its anything other than the local goal of QoS and its RSVP-enabled
RSVP-enabled adjacencies, operating below the network layer. The adjacencies, operating below the network layer. The process by
process by itself neither requires nor has any end-to-end network itself neither requires nor has any end-to-end network knowledge or
knowledge or state. Thus, RSVP can be enabled in a network without state. Thus, RSVP can be enabled in a network without the need to
the need to have every node participate. have every node participate.
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| _______ | | | | _______ | | |
| | | _______ | | _______ | | | | _______ | | _______ |
| |Appli- | | | |RSVP | | | | | |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <----------> | | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | | | | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ | | | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Polcy|| || <--> -->Polcy|| | |_._____| | -->Polcy|| || <--> -->Polcy||
skipping to change at page 27, line 23 skipping to change at page 27, line 23
ANSI T1.619-1992 (R1999), 1992. ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement] [ANSI.MLPP.Supplement]
American National Standards Institute, "MLPP Service American National Standards Institute, "MLPP Service
Domain Cause Value Changes", ANSI ANSI T1.619a-1994 Domain Cause Value Changes", ANSI ANSI T1.619a-1994
(R1999), 1990. (R1999), 1990.
[I-D.ietf-sip-resource-priority] [I-D.ietf-sip-resource-priority]
Schulzrinne, H. and J. Polk, "Communications Resource Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
Internet-Draft draft-ietf-sip-resource-priority-05, draft-ietf-sip-resource-priority-09 (work in progress),
October 2004. May 2005.
[I-D.ietf-sipping-reason-header-for-preemption] [I-D.ietf-sipping-reason-header-for-preemption]
Polk, J., "Extending the Session Initiation Protocol Polk, J., "Extending the Session Initiation Protocol
Reason Header for Preemption Events", Reason Header for Preemption Events",
, August 2004. draft-ietf-sipping-reason-header-for-preemption-02 (work
in progress), August 2004.
[I-D.pierce-ieprep-assured-service-arch] [I-D.pierce-ieprep-assured-service-arch]
Pierce, M. and D. Choi, "Architecture for Assured Service Pierce, M. and D. Choi, "Architecture for Assured Service
Capabilities in Voice over IP", Capabilities in Voice over IP",
. draft-pierce-ieprep-assured-service-arch-02 (work in
progress), January 2004.
[I-D.pierce-ieprep-assured-service-req] [I-D.pierce-ieprep-assured-service-req]
Pierce, M. and D. Choi, "Requirements for Assured Service Pierce, M. and D. Choi, "Requirements for Assured Service
Capabilities in Voice over IP", Capabilities in Voice over IP",
Internet-Draft draft-pierce-ieprep-assured-service-req-02, draft-pierce-ieprep-assured-service-req-02 (work in
January 2004. progress), January 2004.
[ITU.MLPP.1990] [ITU.MLPP.1990]
International Telecommunications Union, "Multilevel International Telecommunications Union, "Multilevel
Precedence and Preemption Service (MLPP)", Precedence and Preemption Service (MLPP)", ITU-
ITU-T Recommendation I.255.3, 1990. T Recommendation I.255.3, 1990.
[RFC1633] Braden, B., Clark, D. and S. Shenker, "Integrated Services [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
in the Internet Architecture: an Overview", RFC 1633, June Services in the Internet Architecture: an Overview",
1994. RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997. Data Flows", RFC 2207, September 1997.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
September 1997. September 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. 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, January for Policy-based Admission Control", RFC 2753,
2000. January 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. 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,
April 2001. April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"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.
[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. Stiliadis, J., Courtney, W., Davari, S., Firoiu, V., and D.
"An Expedited Forwarding PHB (Per-Hop Behavior)", Stiliadis, "An Expedited Forwarding PHB (Per-Hop
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.
[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. Schooler, A., Peterson, J., Sparks, R., Handley, M., and E.
"SIP: Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
of Resource Management and Session Initiation Protocol "Integration of Resource Management and Session Initiation
(SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3326] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
6.2 Informative References 6.2 Informative References
[G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, [G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, <h
<http://www.sygnusdata.co.uk/white_papers/viola/netally_vo ttp://www.sygnusdata.co.uk/white_papers/viola/
ip_sample_report_preliminary.pdf>. netally_voip_sample_report_preliminary.pdf>.
[G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July [G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64",
1999, July 1999, <http://docbox.etsi.org/tiphon/tiphon/archives/
<http://docbox.etsi.org/tiphon/tiphon/archives/1999/05-990 1999/05-9907-Amsterdam/14TD113.pdf>.
7-Amsterdam/14TD113.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss [G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, Concealment", 2000, <http://www.nortelnetworks.com/
<http://www.nortelnetworks.com/products/01/succession/es/c products/01/succession/es/collateral/tb_pktloss.pdf>.
ollateral/tb_pktloss.pdf>.
[G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and [G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and
recency on Subjective Voice Quality", 2000, recency on Subjective Voice Quality", 2000, <http://
<http://www.telchemy.com/references/tech_papers/iptel2001. www.telchemy.com/references/tech_papers/iptel2001.pdf>.
pdf>.
[G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware [G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware
Support, MOS, and Negotiation", 2003, Support, MOS, and Negotiation", 2003, <http://
<http://www.cisco.com/en/US/tech/tk652/tk701/technologies_ www.cisco.com/en/US/tech/tk652/tk701/
tech_note09186a00800b6710.shtml#mos>. technologies_tech_note09186a00800b6710.shtml#mos>.
[ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over [ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over
Networks With Bursty Packet Loss", July 2003. Networks With Bursty Packet Loss", July 2003.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor [Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services Sharing Approach to Flow Control in Integrated Services
Networks: The Multiple Node Case", INFOCOM 1993: 521-530, Networks: The Multiple Node Case", INFOCOM 1993: 521-530,
1993. 1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor [Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor
Sharing Approach to Flow Control in Integrated Services Sharing Approach to Flow Control in Integrated Services
Networks: The Single Node Case", INFOCOM 1992: 915-924, Networks: The Single Node Case", INFOCOM 1992: 915-924,
1992. 1992.
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W. [RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn,
and J. Linden, "Internet Low Bit Rate Codec (iLBC)", W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)",
RFC 3951, December 2004. RFC 3951, December 2004.
Authors' Addresses 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
skipping to change at page 32, line 9 skipping to change at page 32, line 9
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
Phone: +1-469-255-5208 Phone: +1-469-255-5208
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Appendix A. 2-Call Preemption Example using RSVP Appendix A. 2-Call Preemption Example using RSVP
This appendix will present a more complete view of the interaction This appendix will present a more complete view of the interaction
between SIP, SDP and RSVP. The bulk of the material is referenced between SIP, SDP and RSVP. The bulk of the material is referenced
from [RFC2327], [RFC3312], from [RFC2327], [RFC3312], [I-D.ietf-sipping-reason-header-for-
[I-D.ietf-sipping-reason-header-for-preemption], preemption], [I-D.ietf-sip-resource-priority]. There will be some
[I-D.ietf-sip-resource-priority]. There will be some discussion on discussion on basic RSVP operations regarding reservation paths, this
basic RSVP operations regarding reservation paths, this will be will be mostly from [RFC2205].
mostly from [RFC2205].
SIP signaling occurs at layer 7, riding on a UDP/IP or TCP/IP SIP signaling occurs at layer 7, riding on a UDP/IP or TCP/IP
(including TLS/TCP/IP) transport that is bound by routing protocols (including TLS/TCP/IP) transport that is bound by routing protocols
such as BGP and OSPF to determine the route the packets traverse such as BGP and OSPF to determine the route the packets traverse
through a network between source and destination devices. RSVP is through a network between source and destination devices. RSVP is
riding on top of IP as well, which means RSVP is at the mercy of the riding on top of IP as well, which means RSVP is at the mercy of the
IP routing protocols to determine a path through the network between IP routing protocols to determine a path through the network between
endpoints. RSVP is not a routing protocol. In this appendix there endpoints. RSVP is not a routing protocol. In this appendix there
will be a escalation of building blocks getting to how the many 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
skipping to change at page 39, line 34 skipping to change at page 39, line 29
path of the reservation set up RESV message, or: path of the reservation set up RESV message, or:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Immediately after Alice transmits the RESV message towards Bob, Alice Immediately after Alice transmits the RESV message towards Bob, Alice
sends her own PATH message to initiate the other one-way reservation. sends her own PATH message to initiate the other one-way reservation.
Bob, receiving that PATH message, will reply with a RESV. Bob, receiving that PATH message, will reply with a RESV.
All this is independent of SIP. But during this time of reservation All this is independent of SIP. But during this time of reservation
establishment, a Provisional Acknowledgement (PRACK) [M3] is sent establishment, a Provisional Acknowledgement (PRACK) [M3] is sent
from Alice to Bob to confirm the request for confirmation of 2 from Alice to Bob to confirm the request for confirmation of 2 one-
one-way reservations at Alice's UA. This message is acknowledged way reservations at Alice's UA. This message is acknowledged with a
with a normal 200 OK message [M4]. This is shown in Figure 7. normal 200 OK message [M4]. This is shown in Figure 7.
As soon as the RSVP is successfully completed at Alice's UA (knowing As soon as the RSVP is successfully completed at Alice's UA (knowing
it was the last in the two way cycle or reservation establishment), it was the last in the two way cycle or reservation establishment),
at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform
his UA that current status of RSVP (or qos) is "e2e" and "sendrecv". his UA that current status of RSVP (or qos) is "e2e" and "sendrecv".
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv] [M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0 UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa ;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil> To: Bob <sip:bob@usmc.example.mil>
Resource-Priority: dsn.routine Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil> Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE CSeq: 10197 UPDATE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 191 Content-Length: 191
 End of changes. 

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