draft-ietf-tsvwg-mlpp-that-works-03.txt   draft-ietf-tsvwg-mlpp-that-works-04.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Expires: August 13, 2006 Cisco Systems Intended status: Experimental Cisco Systems
February 9, 2006 Expires: August 31, 2006 February 27, 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-03 draft-ietf-tsvwg-mlpp-that-works-04
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 August 13, 2006. This Internet-Draft will expire on August 31, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
RFCs 3689 and 3690 detail requirements for an Emergency RFCs 3689 and 3690 detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preparedness Service (IEPS) would be a part. Some of these types of Preparedness Service (IEPS) would be a part. Some of these types of
services require call preemption; others, call for call queuing or services require call preemption; others call for call queuing or
other mechanisms. The key requirement is to guarantee an elevated other mechanisms. IEPS requires a Call Admission Control (CAC)
probability of call completion to an authorized user in time of procedure and a Per Hop Behavior for the data which meet the needs of
crisis. this architecture. Such a CAC procedure and PHB is appropriate to
any service that might use H.323 or SIP to set up real time sessions.
IEPS requires a Call Admission Control (CAC) procedure and a Per Hop The key requirement is to guarantee an elevated probability of call
Behavior for the data which meet the needs of this architecture. completion to an authorized user in time of crisis.
Such a CAC procedure and PHB is appropriate to any service that might
use H.323 or SIP to set up real time sessions. These obviously
include, but are not limited to, Voice and Video applications,
although at this writing the community is mostly thinking about Voice
on IP and many of the examples in the document are taken from that
environment.
In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be
sufficient. However, in a network where session status can be
reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls
supersede existing calls), maintaining a continuing model of the
status of the various calls is required.
Although this document primarily discusses requirements for the US This document primarily discusses supporting ETS in the context of
Government and NATO, the architecture described here is applicable the US Government and NATO, because it focuses on the MLPP and GETS
outside these two organizations. standards. The architectures described here are applicable beyond
these organizations.
Table of Contents Table of Contents
1. Overview of the Internet Emergency Preference Service 1. Overview of the Internet Emergency Preference Service
problem and proposed solutions . . . . . . . . . . . . . . . . 4 problem and proposed solutions . . . . . . . . . . . . . . . . 4
1.1. Emergency Telecommunications Services . . . . . . . . . . 4 1.1. Emergency Telecommunications Services . . . . . . . . . . 4
1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 5 1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 5
1.1.2. Government Emergency Telecommunications Service . . . 7 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 . . . . . . . . . . . . . . 8
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 . . . . 10
1.6. The use of bandwidth as a solution for QoS . . . . . . . . 10 1.6. The use of bandwidth as a solution for QoS . . . . . . . . 11
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 . . . . . . . . . . . . . . 18 2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 17
2.3.1. RSVP procedure: explicit call admission - RSVP 2.3.1. RSVP procedure: explicit call admission - RSVP
Admission using Policy for both unicast and Admission using Policy for both unicast and
multicast sessions . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 22 2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 21
2.3.5.1. Admission for variable rate codecs . . . . . . . . 22
2.3.5.2. Interaction with complex admission policies,
AAA, and preemption of bandwidth . . . . . . . . . 23
2.4. Authentication and authorization of calls placed . . . . . 24 2.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. Integrated Services Architecture References . . . . . . . 28 6.2. Integrated Services Architecture References . . . . . . . 28
6.3. Differentiated Services Architecture References . . . . . 29 6.3. Differentiated Services Architecture References . . . . . 29
6.4. Session Initiation Protocol and related References . . . . 30 6.4. Session Initiation Protocol and related References . . . . 30
6.5. Informative References . . . . . . . . . . . . . . . . . . 30 6.5. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 32 Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Overview of the Internet Emergency Preference Service problem and 1. Overview of the Internet Emergency Preference Service problem and
proposed solutions proposed solutions
[RFC3689] and [RFC3690] detail requirements for an Emergency [RFC3689] and [RFC3690] detail requirements for an Emergency
Telecommunications Service (ETS), of which an Internet Emergency Telecommunications Service (ETS), of which an Internet Emergency
Preference Service (IEPS) would be a part. Some of these types of Preference Service (IEPS) would be a part. Some of these types of
services require call preemption; others call for call queuing or services require call preemption; others 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.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
1.1.1. Multi-Level Preemption and Precedence 1.1.1. Multi-Level Preemption and Precedence
The Assured Service is designed as an IP implementation of an The Assured Service is designed as an IP implementation of an
existing ITU-T/NATO/DoD telephone system architecture known as Multi- existing ITU-T/NATO/DoD telephone system architecture known as 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. This document describes NATO and U.S. Department of
Defense uses of MLPP, but the architecture and standard are
applicable outside of these organizations.
These precedences, in descending order, are:
Flash Override Override: used by the Commander in Chief, Secretary Flash Override Override: used by the Commander in Chief, Secretary
of Defense, and Joint Chiefs of Staff, Commanders of combatant of Defense, and Joint Chiefs of Staff, Commanders of combatant
commands when declaring the existence of a state of war. commands when declaring the existence of a state of war.
Commanders of combatant commands when declaring Defense Condition Commanders of combatant commands when declaring Defense Condition
One or Defense Emergency or Air Defense Emergency and other One or Defense Emergency or Air Defense Emergency and other
national authorities that the President may authorize in national authorities that the President may authorize in
conjunction with Worldwide Secure Voice Conferencing System conjunction with Worldwide Secure Voice Conferencing System
conferences. Flash Override Override cannot be preempted. This conferences. Flash Override Override cannot be preempted. This
precedence level is not enabled on all DoD networks. precedence level is not enabled on all DoD networks.
skipping to change at page 7, line 14 skipping to change at page 7, line 19
1.1.2. Government Emergency Telecommunications Service 1.1.2. Government Emergency Telecommunications Service
A US service similar to MLPP and using MLPP signaling technology, but A US service similar to MLPP and using MLPP signaling technology, but
built for use in civilian networks, is the Government Emergency built for use in civilian networks, is the Government Emergency
Telecommunications Service (GETS). This differs from MLPP in two Telecommunications Service (GETS). This differs from MLPP in two
ways: it does not use preemption, but rather reserves bandwidth or ways: it does not use preemption, but rather reserves bandwidth or
queues calls to obtain a high probability of call completion, and it queues calls to obtain a high probability of call completion, and it
has only two levels of service: "Routine" and "Priority". has only two levels of service: "Routine" and "Priority".
GETS is described here as another example. Similar architectures are
applied by other governments and organizations.
1.2. Definition of Call Admission 1.2. Definition of Call Admission
Traditionally, in the PSTN, Call Admission Control (CAC) has had the Traditionally, in the PSTN, Call Admission Control (CAC) has had the
responsibility of implementing bandwidth available thresholds (e.g. responsibility of implementing bandwidth available thresholds (e.g.
to limit resources consumed by some traffic) and determining whether to limit resources consumed by some traffic) and determining whether
a caller has permission (e.g., is an identified subscriber, with a caller has permission (e.g., is an identified subscriber, with
identify attested to by appropriate credentials) to use an available identify attested to by appropriate credentials) to use an available
circuit. IEPS, or any emergency telephone service, has additional circuit. IEPS, or any emergency telephone service, has additional
options that it may employ to improve the probability of call options that it may employ to improve the probability of call
completion: completion:
skipping to change at page 11, line 15 skipping to change at page 11, line 23
a server, the simplest and cheapest solution is to buy the next a server, the simplest and cheapest solution is to buy the next
faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1 faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1
Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit
Ethernet. Similarly, in optical networking environments, the Ethernet. Similarly, in optical networking environments, the
simplest and cheapest solution is often to increase the data rate of simplest and cheapest solution is often to increase the data rate of
the optical path either by selecting a faster optical carrier or the optical path either by selecting a faster optical carrier or
deploying an additional lambda. In places where the bandwidth can be deploying an additional lambda. In places where the bandwidth can be
over-provisioned to a point where loss or queuing delay are over-provisioned to a point where loss or queuing delay are
negligible, 10:1 over-provisioning is often the cheapest and surest negligible, 10:1 over-provisioning is often the cheapest and surest
solution, and by the way offers a growth path for future solution, and by the way offers a growth path for future
requirements. However, there are places in communication networks requirements. However, there are many places in communication
where bandwidth is not free and is therefore not effectively networks where the provision of effectively infinite bandwidth is not
infinite. It is in these places, and only these places, where the feasible, including many access networks, satellite communications,
question of resource management is relevant. fixed wireless, airborn and marine communications, island
connections, and connections to regions in which fiber optic
The places where bandwidth constriction takes place is typically connections are not cost-effective. It is in these places where the
where one pays a significant amount for bandwidth, such as in access question of resource management is relevant. Specifically, we do not
paths, or where available technology limits the options. In military recommend the deployment of significant QoS procedures on links in
networks, Type 1 encryption often presents such a barrier, as do excess of 100 MBPS apart from the provision of aggregated services
satellite links and various kinds of radio systems. that provide specific protection to the stability of the network or
the continuity of real-time traffic as a class, as the mathematics of
such circuits do not support this as a requirement.
In short, the fact that we are discussing this class of policy In short, the fact that we are discussing this class of policy
control says that such constrictions in the network exist and must be control says that such constrictions in the network exist and must be
dealt with. However much we might like to, in those places we are dealt with. However much we might like to, in those places we are
not solving the problem with bandwidth. not solving the problem with bandwidth.
2. Solution Proposal 2. Solution Proposal
A typical voice or video network, including a backbone domain, is A typical voice or video network, including a backbone domain, is
shown in Figure 1. shown in Figure 1.
skipping to change at page 13, line 24 skipping to change at page 13, line 24
o Does the call actually work, or do other impairments (loss, delay) o Does the call actually work, or do other impairments (loss, delay)
make the call unusable? make the call unusable?
2.1. Call admission/preemption procedure 2.1. Call admission/preemption procedure
Administrative Call Admission is the objective of SIP and H.323. It Administrative Call Admission is the objective of SIP and H.323. It
asks fundamental questions like "what IP address is the callee at?" asks fundamental questions like "what IP address is the callee at?"
and "Did you pay your bill?". and "Did you pay your bill?".
For specialized policy like call preemption, two capabilities are For specialized policy like call preemption, two capabilities are
necessary from an administrative perspective: necessary from an administrative perspective: [RFC4412] provides a
[I-D.ietf-sip-resource-priority] provides a way to communicate way to communicate policy-related information regarding the
policy-related information regarding the precedence of the call; and precedence of the call; and [RFC4411] provides a reason code when a
[I-D.ietf-sipping-reason-header-for-preemption] provides a reason call fails or is refused, indicating the cause of the event. If it
code when a call fails or is refused, indicating the cause of the is a failure, it may make sense to redial the call. If it is a
event. If it is a failure, it may make sense to redial the call. If policy-driven preemption, even if the call is redialed it may not be
it is a policy-driven preemption, even if the call is redialed it may possible to place the call. Requirements for this service are
not be possible to place the call. Requirements for this service are
further discussed in [RFC3689]. further discussed in [RFC3689].
The Communications Resource Priority Header (or RP Header) serves the The 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
skipping to change at page 14, line 24 skipping to change at page 14, line 23
dsn.flash dsn.flash
dsn.immediate dsn.immediate
dsn.priority dsn.priority
dsn.routine dsn.routine
The US Defense Red Switched Network (DRSN), as another example that The US Defense Red Switched Network (DRSN), as another example that
is to be IANA registered in [I-D.ietf-sip-resource-priority], has 6 is to be IANA registered in [RFC4412], has 6 levels of precedence.
levels of precedence. The DRSN simply adds one higher 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.
The Resource-Priority Header (RPH) informs both the use of DSCPs by The Resource-Priority Header (RPH) informs both the use of DSCPs by
the callee (who needs to use the same DSCP as the caller to obtain the callee (who needs to use the same DSCP as the caller to obtain
the same data path service) and to facilitate policy-based preemption the same data path service) and to facilitate policy-based preemption
of calls in progress when 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 Preemption, described in [RFC4411], ensures that all SIP nodes are
[I-D.ietf-sipping-reason-header-for-preemption], ensures that all SIP synchronized to a preemption event occurring either at the endpoint
nodes are synchronized to a preemption event occurring either at the or in a router that experiences congestion. In SIP, the normal
endpoint or in a router that experiences congestion. In SIP, the indication for the end of a session is for one end system to send a
normal indication for the end of a session is for one end system to BYE Method request as specified in [RFC3261]. This, too, is the
send a BYE Method request as specified in [RFC3261]. This, too, is proper means for signaling a termination of a call due to a
the proper means for signaling a termination of a call due to a
preemption event, as it essentially performs a normal termination preemption event, as it essentially performs a normal termination
with additional information informing the peer of the reason for the with additional information informing the peer of the reason for the
abrupt end - it indicates that a preemption occurred. This will be abrupt end - it indicates that a preemption occurred. This will be
used to inform all relevant SIP entities, and whether this was a used to inform all relevant SIP entities, and whether this was a
endpoint generated preemption event, or that the preemption event endpoint generated preemption event, or that the preemption event
occurred within a router along the communications path (described in occurred within a router along the communications path (described in
Section 2.3.1 ). Section 2.3.1 ).
Figure 2 is a simple example of a SIP call set-up that includes the Figure 2 is a simple example of a SIP call 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
skipping to change at page 17, line 4 skipping to change at page 16, line 22
The Quality of Service architecture used in the data path is that of The Quality of Service architecture used in the data path is that of
[RFC2475]. Differentiated Services uses a flag in the IP header [RFC2475]. Differentiated Services uses a flag in the IP header
called the DSCP [RFC2474] to identify a data stream, and then applies called the DSCP [RFC2474] to identify a data stream, and then applies
a procedure called a Per Hop Behavior, or PHB, to it. This is a procedure called a Per Hop Behavior, or PHB, to it. This is
largely as described in the [RFC2998]. largely as described in the [RFC2998].
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247]
describes the fundamental needs of voice and video traffic. This PHB describes the fundamental needs of voice and video traffic. This PHB
entails ensuring that sufficient bandwidth is dedicated to real-time entails ensuring that sufficient bandwidth is dedicated to real-time
traffic to ensure minimal variation in delay and a minimal loss rate, traffic to ensure minimal variation in delay and a minimal loss rate,
as codecs are hampered by excessive loss [G711.1] [G711.2] [G711.3] as codecs are hampered by excessive loss [G711.1][G711.2][G711.3].
.In parts of the network where bandwidth is heavily over-provisioned, In parts of the network where bandwidth is heavily over-provisioned,
there may be no remaining concern. In places in the network where there may be no remaining concern. In places in the network where
bandwidth is more constrained, this may require the use of a priority bandwidth is more constrained, this may require the use of a priority
queue. If a priority queue is used, the potential for abuse exists, queue. If a priority queue is used, the potential for abuse exists,
meaning that it is also necessary to police traffic placed into the meaning that it is also necessary to police traffic placed into the
queue to detect and manage abuse. A fundamental question is "where queue to detect and manage abuse. A fundamental question is "where
does this policing need to take place?". The obvious places would be does this policing need to take place?". The obvious places would be
the first hop routers and any place where converging data streams the first hop routers and any place where converging data streams
might congest a link. might congest a link.
Some proposals mark traffic with various code points appropriate to Some proposals mark traffic with various code points appropriate to
skipping to change at page 19, line 33 skipping to change at page 19, line 22
| | | |process| _____ | ||Routing| |process| _____ | | | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy|| | |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____|| | |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========| |===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ | | | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis|| | | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____|| | | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
| |______| |________| |data | |______| |________| |data | |______| |________| |data | |______| |________| data
| | | | | | | |
|_____________________________| |____________________________| |_____________________________| |____________________________|
Figure 3: RSVP in Hosts and Routers Figure 3: RSVP in Hosts and Routers
Figure 3 shows the internal process of RSVP in both hosts (end Figure 3 shows the internal process of RSVP in both hosts (end
systems) and routers, as shown in [RFC2209]. systems) and routers, as shown in [RFC2209].
RSVP uses the phrase "traffic control" to describe the mechanisms of RSVP uses the phrase "traffic control" to describe the mechanisms of
how a data flow receives quality of service. There are 3 different how a data flow receives quality of service. There are 3 different
skipping to change at page 30, line 11 skipping to change at page 30, line 11
[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 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 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. 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.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP)
Header Field for the Session Initiation Protocol (SIP)", Reason Header for Preemption Events", RFC 4411,
RFC 3326, December 2002. February 2006.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
6.5. Informative References 6.5. Informative References
[ANSI.MLPP.Spec] [ANSI.MLPP.Spec] American National Standards Institute,
American National Standards Institute, "Telecommunications "Telecommunications - Integrated Services
- Integrated Services Digital Network (ISDN) - Multi-Level Digital Network (ISDN) - Multi-Level
Precedence and Preemption (MLPP) Service Capability", Precedence and Preemption (MLPP) Service
ANSI T1.619-1992 (R1999), 1992. Capability", ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Supplement] [ANSI.MLPP.Supplement] American National Standards Institute, "MLPP
American National Standards Institute, "MLPP Service Service Domain Cause Value Changes",
Domain Cause Value Changes", ANSI ANSI T1.619a-1994 ANSI ANSI T1.619a-1994 (R1999), 1990.
(R1999), 1990.
[G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, <h [G711.1] Viola Networks, "Netally VoIP Evaluator",
ttp://www.sygnusdata.co.uk/white_papers/viola/ January 2003, <http://www.sygnusdata.co.uk/
white_papers/viola/
netally_voip_sample_report_preliminary.pdf>. netally_voip_sample_report_preliminary.pdf>.
[G711.2] IEPSI Tiphon, "IEPSI Tiphon Temporary Document 64", [G711.2] IEPSI Tiphon, "IEPSI Tiphon Temporary
July 1999, <http://docbox.etsi.org/tiphon/tiphon/archives/ Document 64", July 1999, <http://
1999/05-9907-Amsterdam/14TD113.pdf>. docbox.etsi.org/tiphon/tiphon/archives/1999/
05-9907-Amsterdam/14TD113.pdf>.
[G711.3] Nortel Networks, "Packet Loss and Packet Loss [G711.3] Nortel Networks, "Packet Loss and Packet Loss
Concealment", 2000, <http://www.nortelnetworks.com/ Concealment", 2000, <http://
products/01/succession/es/collateral/tb_pktloss.pdf>. 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] [ITU.ETS.E106] International Telecommunications Union,
International Telecommunications Union, "Multilevel "International Emergency Preference Scheme
Precedence and Preemption Service (MLPP)", ITU- for disaster relief operations (IEPS)", ITU-
T Recommendation I.255.3, 1990. T Recommendation E.106, October 2003.
[Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor [ITU.MLPP.1990] International Telecommunications Union,
Sharing Approach to Flow Control in Integrated Services "Multilevel Precedence and Preemption Service
Networks: The Multiple Node Case", INFOCOM 1993: 521-530, (MLPP)", ITU-T Recommendation I.255.3, 1990.
1993.
[Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor [Parekh1] Parekh, A. and R. Gallager, "A Generalized
Sharing Approach to Flow Control in Integrated Services Processor Sharing Approach to Flow Control in
Networks: The Single Node Case", INFOCOM 1992: 915-924, Integrated Services Networks: The Multiple
1992. Node Case", INFOCOM 1993: 521-530, 1993.
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, [Parekh2] Parekh, A. and R. Gallager, "A Generalized
W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", Processor Sharing Approach to Flow Control in
RFC 3951, December 2004. Integrated Services Networks: The Single Node
Case", INFOCOM 1992: 915-924, 1992.
Appendix A. 2-Call Preemption Example using RSVP Appendix A. 2-Call Preemption Example using RSVP
This appendix will present a more complete view of the interaction This appendix will present a more complete view of the interaction
between SIP, SDP and RSVP. The bulk of the material is referenced between SIP, SDP and RSVP. The bulk of the material is referenced
from [RFC2327], [RFC3312], from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be
[I-D.ietf-sipping-reason-header-for-preemption], some discussion on basic RSVP operations regarding reservation paths,
[I-D.ietf-sip-resource-priority]. There will be some discussion on this will be mostly from [RFC2205].
basic RSVP operations regarding reservation paths, this will be
mostly from [RFC2205].
SIP signaling occurs at the Application Layer, riding on a UDP/IP or SIP signaling occurs at the Application Layer, riding on a UDP/IP or
TCP/IP (including TLS/TCP/IP) transport that is bound by routing TCP/IP (including TLS/TCP/IP) transport that is bound by routing
protocols such as BGP and OSPF to determine the route the packets protocols such as BGP and OSPF to determine the route the packets
traverse through a network between source and destination devices. traverse through a network between source and destination devices.
RSVP is riding on top of IP as well, which means RSVP is at the mercy RSVP is riding on top of IP as well, which means RSVP is at the mercy
of the IP routing protocols to determine a path through the network of the IP routing protocols to determine a path through the network
between endpoints. RSVP is not a routing protocol. In this appendix between endpoints. RSVP is not a routing protocol. In this appendix
there 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
skipping to change at page 42, line 52 skipping to change at page 42, line 52
equates to a precedence value of "immediate", which is a higher equates to a precedence value of "immediate", which is a higher
priority. Thus, R2 will preempt the reservation from Alice to Bob, priority. Thus, R2 will preempt the reservation from Alice to Bob,
and allow the reservation request from Dave to Carol. The proper and allow the reservation request from Dave to Carol. The proper
RSVP error is the ResvErr that indicates preemption. This message RSVP error is the ResvErr that indicates preemption. This message
travels downstream towards the originator of the RESV message (Bob). travels downstream towards the originator of the RESV message (Bob).
This clears the reservation in all routers downstream of R2 (meaning This clears the reservation in all routers downstream of R2 (meaning
R3 and R4). Once Bob receives the ResvErr message indicating R3 and R4). Once Bob receives the ResvErr message indicating
preemption has occurred on this reservation, Bob's UA transmits a SIP preemption has occurred on this reservation, Bob's UA transmits a SIP
preemption indication back towards Alice's UA. This accomplishes two preemption indication back towards Alice's UA. This accomplishes two
things: first it informs all SIP Servers that were in the session things: first it informs all SIP Servers that were in the session
set-up path that wanted to remain "dialog stateful" per [RFC3261]], 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, "Reserved Reason Header indicating why this occurred (in this case, "Reserved
Resources Preempted". Here is that message from Bob to Alice that Resources Preempted". Here is 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
skipping to change at page 44, line 15 skipping to change at page 44, line 15
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-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com EMail: jmpolk@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 45, line 45 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.
Acknowledgment Acknowledgements
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.31pre5 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
 End of changes. 36 change blocks. 
147 lines changed or deleted 107 lines changed or added

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