draft-ietf-tsvwg-admitted-realtime-dscp-03.txt   draft-ietf-tsvwg-admitted-realtime-dscp-04.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Updates: 4542,4594 Cisco Systems Updates: 4542,4594 Cisco Systems
(if approved) M. Dolly (if approved) M. Dolly
Intended status: Best Current AT&T Labs Intended status: Standards Track AT&T Labs
Practice December 14, 2007 Expires: August 28, 2008 February 25, 2008
Expires: June 16, 2008
DSCPs for Capacity-Admitted Traffic DSCPs for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-03 draft-ietf-tsvwg-admitted-realtime-dscp-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
skipping to change at page 1, line 37 skipping to change at page 1, line 36
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 June 16, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document requests one DSCP from the IANA for real-time traffic This document requests one Differentiated Services Code Point (DSCP)
classes similar to voice conforming to the Expedited Forwarding Per from the Internet Assigned Numbers Authority (IANA) for real-time
Hop Behavior, and admitted using a CAC procedure involving traffic classes similar to voice conforming to the Expedited
authentication, authorization, and capacity admission, as compared to Forwarding Per Hop Behavior, and admitted using a call admission
a class of real-time traffic conforming to the Expedited Forwarding procedure involving authentication, authorization, and capacity
Per Hop Behavior but not subject to capacity admission or subject to admission.
very coarse capacity admission.
It also recommends that certain classes of video traffic described in It also recommends that certain classes of video traffic described in
RFC 4594 and which have similar requirements be require admission RFC 4594 and which have similar requirements be changed to require
using a CAC procedure involving authentication, authorization, and admission using a Call Admission Control (CAC) procedure involving
capacity admission. authentication, authorization, and capacity admission.
One of the reasons behind this is the need for classes of traffic
that are handled under special policies, such as the non-preemptive
Emergency Telecommunication Service, the US DoD's Assured Service
(which is similar to MLPP), or e-911. Capacity-admitted traffic
classes need separation from traffic not subject to admission
control, from which they can deterministically obtain their service
requirements, including SLA matters.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 8 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7
2. Implementation of the Admitted Service Classes . . . . . . . . 8 2. Implementation of the Admitted Service Classes . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 8 2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . . 10 2.2. Capacity admission control . . . . . . . . . . . . . . . . 9
2.2.1. Capacity admission control by assumption . . . . . . . 10 2.2.1. Capacity admission control by assumption . . . . . . . 10
2.2.2. Capacity admission control by call counting . . . . . 11 2.2.2. Capacity admission control by call counting . . . . . 10
2.2.3. End-point capacity admission performed by probing 2.2.3. End-point capacity admission performed by probing
the network . . . . . . . . . . . . . . . . . . . . . 11 the network . . . . . . . . . . . . . . . . . . . . . 11
2.2.4. Centralized capacity admission control . . . . . . . . 12 2.2.4. Centralized capacity admission control . . . . . . . . 11
2.2.5. Distributed capacity admission control . . . . . . . . 12 2.2.5. Distributed capacity admission control . . . . . . . . 12
2.3. Prioritized capacity admission control . . . . . . . . . . 13 2.3. Prioritized capacity admission control . . . . . . . . . . 12
3. Recommendations on implementation of an Admitted Telephony 3. Recommendations on implementation of an Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . . 14 Service Class . . . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This document requests one DSCP from the IANA for a class of real- This document requests one Differentiated Services Code Point (DSCP)
time traffic conforming to the Expedited Forwarding [RFC3246] from the Internet Assigned Numbers Authority (IANA) for a class of
[RFC3247] Per Hop Behavior and admitted using a CAC procedure real-time traffic. This class conforms to the Expedited Forwarding
involving authentication, authorization, and capacity admission, as [RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a
compared to a class of real-time traffic conforming to the Expedited CAC procedure involving authentication, authorization, and capacity
Forwarding Per Hop Behavior but not subject to capacity admission or admission. This differs from a real-time traffic class conforming to
subject to very coarse capacity admission. the Expedited Forwarding Per Hop Behavior but not subject to capacity
admission or subject to very coarse capacity admission.
It also recommends that certain classes of video described in It also recommends that certain classes of video described in
[RFC4594] be treated as requiring capacity admission as well. [RFC4594] be treated as requiring capacity admission as well.
These applications have one or more potential congestion points These applications have one or more potential congestion points
between the video distribution/conferencing bridge or gaming server between the video distribution/conferencing bridge or gaming server
and the user(s), and reserving capacity for them is important to and the user(s), and reserving capacity for them is important to
application performance. All of these applications have low application performance. All of these applications have low
tolerance to jitter (aka delay variation) and loss, as summarized in tolerance to jitter (aka delay variation) and loss, as summarized in
Section 2, and most (except for multimedia conferencing) have Section 2, and most (except for multimedia conferencing) have
inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow
behavior and low jitter/loss tolerance are the service behavior and low jitter/loss tolerance are the service
characteristics that define the need for admission control behavior. characteristics that define the need for admission control behavior.
One of the reasons behind this is the need for classes of traffic One of the reasons behind this is the need for classes of traffic
that are handled under special policies, such as the non-preemptive that are handled under special policies, such as the non-preemptive
Emergency Telecommunication Service, the US DoD's Assured Service Emergency Telecommunication Service, the US Department of Defense's
(which is similar to MLPP and uses preemption), or e-911, in addition Assured Service (which is similar to Multi-Level Precedence and
to normal routine calls that use call admission. It is possible to Preemption [ITU.MLPP.1990] procedure), or e-911, in addition to
use control plane protocols to generally restrict session admission normal routine calls that use call admission. It is possible to use
such that admitted traffic should receive the desired service, and control plane protocols to generally restrict session admission such
the policy (e.g. Routine, National Security or Emergency that admitted traffic should receive the desired service, and the
Preparedness [NS/EP] communications, e-911, etc) need not be signaled policy (e.g. Routine, National Security or Emergency Preparedness
in a DSCP. However, service providers need to distinguish between [NS/EP] communications, e-911, etc) need not be signaled in a DSCP.
special-policy traffic and other classes, particularly the existing However, service providers need to distinguish between special-policy
VoIP services that perform no capacity admission or only very coarse traffic and other classes, particularly the existing VoIP services
capacity admission and can exceed their allocated resources. that perform no capacity admission or only very coarse capacity
admission and can exceed their allocated resources.
The requested DSCP applies to the Telephony Service Class described The requested DSCP applies to the Telephony Service Class described
in [RFC4594]. The video classes addressed include the in [RFC4594]. The video classes addressed include the
o interactive real-time traffic (CS4, used for Video conferencing o interactive real-time traffic (CS4, used for Video conferencing
and Interactive gaming), and Interactive gaming),
o broadcast TV (CS3) for use in a video on demand context, and o broadcast TV (CS3) for use in a video on demand context, and
o AF4 Multimedia conferencing (video conferencing). o AF4 Multimedia conferencing (video conferencing).
Since the admitted video classes have not had the history of mixing Since the admitted video classes have not had the history of mixing
admitted and non-admitted traffic in the same PHB as has occurred for admitted and non-admitted traffic in the same Per-Hop Behavior (PHB)
EF, an additional DSCP code point is not recommended. Instead, the as has occurred for EF, an additional DSCP code point is not
recommended "best practice" is to perform admission control for the recommended. Instead, the recommended "best practice" is to perform
above video classes. admission control for the above video classes.
Other video classes are not believed to be required by the targeted Other video classes are not believed to be required by the targeted
services and to not have the current problem of confusion with services and to not have the current problem of confusion with
unadmitted traffic. Within an ISP and on inter-ISP links (i.e. unadmitted traffic. Within an ISP and on inter-ISP links (i.e.
within networks whose internal paths are uniform at hundreds of within networks whose internal paths are uniform at hundreds of
megabits or faster), one would expect all of this traffic to be megabits or faster), one would expect all of this traffic to be
carried in the Real Time Traffic Class described in carried in the Real Time Traffic Class described in [RFC5127].
[I-D.ietf-tsvwg-diffserv-class-aggr].
1.1. Definitions 1.1. Definitions
The following terms and acronyms are used in this document. The following terms and acronyms are used in this document.
PHB: A Per-Hop-Behavior (PHB) is the externally observable PHB: A Per-Hop-Behavior (PHB) is the externally observable
forwarding behavior applied at a DS-compliant node to a DS forwarding behavior applied at a Differentiated Services compliant
behavior aggregate [RFC2475]. It may be thought of as a program node to a DS behavior aggregate [RFC2475]. It may be thought of
configured on the interface of an Internet host or router, as a program configured on the interface of an Internet host or
specified drop probabilities, queuing priorities or rates, and router, specified drop probabilities, queuing priorities or rates,
other handling characteristics for the traffic class. and other handling characteristics for the traffic class.
DSCP: The Differentiated Services Codepoint (DSCP), as defined in DSCP: The Differentiated Services Code Point (DSCP), as defined in
[RFC2474], is a value which is encoded in the DS field, and which [RFC2474], is a value which is encoded in the DS field, and which
each DS Node MUST use to select the PHB which is to be experienced each DS Node MUST use to select the PHB which is to be experienced
by each packet it forwards [RFC3260]. It is a 6-bit number by each packet it forwards [RFC3260]. It is a 6-bit number
embedded into the 8-bit TOS field of an IPv4 datagram or the embedded into the 8-bit TOS field of an IPv4 datagram or the
Traffic Class field of an IPv6 datagram. Traffic Class field of an IPv6 datagram.
CAC: Call Admission Control, which includes concepts of CAC: Call Admission Control includes concepts of authorization and
authorization (an identified and authenticated user is determined capacity admission. "Authorization" includes and procedure
to also be authorized to use the service) and capacity admission identifies a user, verifies the authenticity of the
(at the present time, under some stated policy, capacity exists to identification, and determines whether the user is authorized to
support the call). In the Internet, these are separate functions, use the service. "Capacity Admission" refers to any procedure
while in the PSTN they and call routing are carried out together. that determines whether capacity exists supporting a session's
requirements under some policy.
In the Internet, these are separate functions, while in the PSTN
they and call routing are carried out together.
UNI: A User/Network Interface (UNI) is the interface (often a UNI: A User/Network Interface (UNI) is the interface (often a
physical link or its virtual equivalent) that connects two physical link or its virtual equivalent) that connects two
entities that do not trust each other, and in which one (the user) entities that do not trust each other, and in which one (the user)
purchases connectivity services from the other (the network). purchases connectivity services from the other (the network).
Figure 1 shows two user networks connected by what appears to each Figure 1 shows two user networks connected by what appears to each
of them to be a single network ("The Internet", access to which is of them to be a single network ("The Internet", access to which is
provided by their service provider) which provides connectivity provided by their service provider) that provides connectivity
services to other users. services to other users.
UNIs tend to be the bottlenecks in the Internet, where users UNIs tend to be the bottlenecks in the Internet, where users
purchase relatively low amounts of bandwidth for cost or service purchase relatively low amounts of bandwidth for cost or service
reasons, and as a result are most subject to congestion issues and reasons, and as a result are most subject to congestion issues and
therefore issues requiring traffic conditioning and service therefore issues requiring traffic conditioning and service
prioritization. prioritization.
NNI: A Network/Network Interface (NNI) is the interface (often a NNI: A Network/Network Interface (NNI) is the interface (often a
physical link or its virtual equivalent) that connects two physical link or its virtual equivalent) that connects two
entities that trust each other within limits, and in which the two entities that trust each other within limits, and in which the two
are seen as trading services for value. Figure 1 shows three are seen as trading services for value. Figure 1 shows three
service networks that together provide the connectivity services service networks that together provide the connectivity services
that we call "the Internet". They are different administrations that we call "the Internet". They are different administrations
and are very probably in competition, but exchange contracts for and are very probably in competition, but exchange contracts for
connectivity and capacity that enable them to offer specific connectivity and capacity that enable them to offer specific
services to their customers. services to their customers.
NNIs may not be bottlenecks in the Internet if service providers NNIs may not be bottlenecks in the Internet if service providers
contractually agree to provision excess capacity at them. contractually agree to provision excess capacity at them, as they
However, NNI performance may differ by ISP, and the performance commonly do. However, NNI performance may differ by ISP, and the
guarantee interval may also range from a month to a much shorter performance guarantee interval may range from a month to a much
period of time. Furthermore, a peering point NNI may not have shorter period. Furthermore, a peering point NNI may not have
contractual performance guarantees or may become overloaded during contractual performance guarantees or may become overloaded under
certain conditions. They are also policy-controlled interfaces, certain conditions. They are also policy-controlled interfaces,
especially in BGP. As a result, they may require policy to be especially in BGP. As a result, they may require traffic
applied in traffic prioritization. prioritization policy.
Queue: There are multiple ways to build a multi-queue scheduler. Queue: There are multiple ways to build a multi-queue scheduler.
Weighted Round Robin (WRR) literally builds multiple lists and Weighted Round Robin (WRR) literally builds multiple lists and
visits them in a specified order, while a calendar queue (often visits them in a specified order, while a calendar queue (often
used to implement Weighted Fair Queuing, or WFQ) builds a list for used to implement Weighted Fair Queuing, or WFQ) builds a list for
each time interval and enqueues at most a stated amount of data in each time interval and enqueues at most a stated amount of data in
each such list for transmission during that time interval. While each such list for transmission during that time interval. While
these differ dramatically in implementation, the external these differ dramatically in implementation, the external
difference in behavior is generally negligible when they are difference in behavior is generally negligible when they are
properly configured. Consistent with the definitions used in the properly configured. Consistent with the definitions used in the
skipping to change at page 8, line 7 skipping to change at page 7, line 7
However, services are being requested of the network that would However, services are being requested of the network that would
specifically make use of capacity admission, and would distinguish specifically make use of capacity admission, and would distinguish
among users or the uses of available Voice-on-IP or Video-on-IP among users or the uses of available Voice-on-IP or Video-on-IP
capacity in various ways. Various agencies would like to provide capacity in various ways. Various agencies would like to provide
services as described in section 2.6 of [RFC4504] or in [RFC4190]. services as described in section 2.6 of [RFC4504] or in [RFC4190].
This requires the use of capacity admission to differentiate among This requires the use of capacity admission to differentiate among
users (which might be 911 call centers, other offices with users (which might be 911 call centers, other offices with
preferential service contracts, or individual users gaining access preferential service contracts, or individual users gaining access
with special credentials) to provide services to them that are not with special credentials) to provide services to them that are not
afforded to routine customer-to-customer IP telephony sessions. afforded to non-capacity admitted customer-to-customer IP telephony
sessions.
1.3. Proposed Solution 1.3. Proposed Solution
The IETF is asked to differentiate, in the Telephony Service, between The IETF is asked to differentiate, in the Telephony Service, between
sessions that are originated without capacity admission or using sessions that are originated without capacity admission or using
traffic engineering and sessions that are originated using more traffic engineering and sessions that are originated using more
robust capacity admission procedures. Sessions of the first type use robust capacity admission procedures. Sessions of the first type use
a traffic class in which they compete without network-originated a traffic class in which they compete without network-originated
control as described in Section 2.2.1 or Section 2.2.2, and in the control as described in Section 2.2.1 or Section 2.2.2, and in the
worst case lose traffic due to policing. Sessions of the second type worst case lose traffic due to policing. Sessions of the second type
skipping to change at page 10, line 15 skipping to change at page 9, line 15
issues of loss due to policing and distribution of jitter. issues of loss due to policing and distribution of jitter.
If the two traffic classes are, for example, voice and video, If the two traffic classes are, for example, voice and video,
datagrams containing video data are relatively large (generally the datagrams containing video data are relatively large (generally the
size of the path MTU) while datagrams containing voice are relatively size of the path MTU) while datagrams containing voice are relatively
small, on the order of only 40 to 200 bytes, depending on the codec. small, on the order of only 40 to 200 bytes, depending on the codec.
On lower speed links (less than 10 MBPS), the jitter introduced by On lower speed links (less than 10 MBPS), the jitter introduced by
video to voice can be disruptive, while at higher speeds the jitter video to voice can be disruptive, while at higher speeds the jitter
is nominal compared to the jitter requirements of voice. At access is nominal compared to the jitter requirements of voice. At access
network speeds, therefore, [RFC4594] recommends separation of video network speeds, therefore, [RFC4594] recommends separation of video
and voice into separate queues, while at optical speeds and voice into separate queues, while at optical speeds [RFC5127]
[I-D.ietf-tsvwg-diffserv-class-aggr] recommends that they use a recommends that they use a common queue.
common queue.
If, on the other hand, the two traffic classes are carrying the same If, on the other hand, the two traffic classes are carrying the same
type of application with the same jitter requirements, then giving type of application with the same jitter requirements, then giving
one preference in this sense does not benefit the higher priority one preference in this sense does not benefit the higher priority
traffic and may harm the lower priority traffic. In such a case, traffic and may harm the lower priority traffic. In such a case,
using separate policers and a common queue is a superior approach. using separate policers and a common queue is a superior approach.
2.2. Capacity admission control 2.2. Capacity admission control
There are five major ways that capacity admission is done or has been There are five major ways that capacity admission is done or has been
proposed to be done in real-time applications: proposed to be done in real-time applications:
o Capacity admission control by assumption, o Capacity admission control by assumption,
o Capacity admission control by call counting, o Capacity admission control by call counting,
o End-point capacity admission performed by probing the network, o End-point capacity admission performed by probing the network,
o Centralized capacity admission control, and o Centralized capacity admission control, and
o Distributed capacity admission control o Distributed capacity admission control.
There is also a mechanism that has been proposed for enhancing the
probability of call completion in a preferential manner. This is not
capacity admission per se, since it never actually refuses a call
(although a session may be dropped by its user when the user finds
continuation untenable). The central notion is that when the
capacity available for a set of variable rate sessions has been
overbooked, traffic may be randomly dropped from lower precedence
sessions to allow a higher precedence session in. This has a number
of ramifications that make it inappropriate in the Internet. A key
issue is that it affects not a single session but a class of sessions
- all sessions of lower precedence than the protected session(s). A
video example will suffice for the present. Multimedia data streams
and sensor traffic often build on information in previous frames, and
their content spans multiple datagrams in the same frame. The loss
of a datagram forces the codec into a recovery mode that reduces
image quality for at least one frame, and may cause the image to
freeze for multiple seconds. This is readily observed on television,
where screen artifacts are very visible. Scattered random datagram
loss results in all sessions in the class being impacted to some
degree. Hence, it is far more suitable to drop an entire session
(and therefore impact only one session) than to impact all sessions
in a class in a manner that consumes the available bandwidth but
delivers sub-SLA service to an entire class of sessions. It also
exposes the precedence level of each session in the clear.
2.2.1. Capacity admission control by assumption 2.2.1. Capacity admission control by assumption
The first approach is to ignore the matter entirely. If one assumes The first approach is to ignore the matter entirely. If one assumes
that the capacity available to the application is uniformly far in that the capacity available to the application is uniformly far in
excess of its requirements, it is perhaps overhead that can be excess of its requirements, it is perhaps overhead that can be
ignored. This assumption is currently made in Internet VoIP ignored. This assumption is currently made in Internet VoIP
offerings such as Skype and Vonage; the end user is responsible to offerings such as Skype and Vonage; the end user is responsible to
place his service on a LAN connected to the Internet backbone by a place his service on a LAN connected to the Internet backbone by a
high speed broadband connection and use capable ISPs to deliver the high speed broadband connection and use capable ISPs to deliver the
service. There is an authorization step in the sense that the service. The only "authorization" verified is that the user pays his
service ensures that the user pays his bills, but no capacity bills; no capacity admission is considered because there is a clear
admission is considered because there is a clear separation from the separation from the application service provider admitting the calls
application service provider admitting the calls and the access and the access network provider admitting the traffic. The two have
network provider admitting the traffic. The two have no way of no way of knowing about each other, except in the abstract sense.
knowing about each other, except maybe in the abstract sense.
2.2.2. Capacity admission control by call counting 2.2.2. Capacity admission control by call counting
The H.323 gatekeeper, originally specified in 1996, operates on the The H.323 gatekeeper, originally specified in 1996, operates on the
model that the considerations of Section 2.2.1 generally apply, and model that the considerations of Section 2.2.1 generally apply, and
that it is therefore sufficient to count calls in order to ensure that it is therefore sufficient to count calls in order to ensure
that any bottlenecks in the network are never overloaded. Which that any bottlenecks in the network are never overloaded. Which
phone is calling which phone is configured information into the phone is calling which phone is configured information into the
Gatekeeper, ensuring it doesn't admit too many calls across a low Gatekeeper, ensuring it doesn't admit too many calls across a low
speed link. The area of influence of a Gatekeeper is called a Zone, speed link. The area of influence of a Gatekeeper is called a Zone,
skipping to change at page 12, line 16 skipping to change at page 11, line 39
The overview of one of the current proposals is provided by The overview of one of the current proposals is provided by
[I-D.chan-pcn-problem-statement]. With the pre-congestion [I-D.chan-pcn-problem-statement]. With the pre-congestion
notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An
initial deployment model provided by initial deployment model provided by
[I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in [I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in
[I-D.charny-pcn-single-marking]. Similar approaches have been [I-D.charny-pcn-single-marking]. Similar approaches have been
proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars
and Karlsson in their PBAC work, and many others. and Karlsson in their PBAC work, and many others.
Current simulation work have shown the pre-congestion notification
mechanism works well with large number of audio and video flows on
high speed lines. This work is ongoing.
2.2.4. Centralized capacity admission control 2.2.4. Centralized capacity admission control
The concept of a Bandwidth Broker was first discussed in the research The concept of a Bandwidth Broker was first discussed in the research
world surrounding ESNET and Internet II in the late 1990's, and has world surrounding ESNET and Internet II in the late 1990's, and has
been discussed in the literature pertaining to the Differentiated been discussed in the literature pertaining to the Differentiated
Services Architecture [RFC2475]. It is, in short, a central system Services Architecture [RFC2475]. It is, in short, a central system
that performs a variety of services on behalf of clients of a network that performs a variety of services on behalf of clients of a network
including applying AAA services (as in [RFC2904] )and authorizing including applying AAA services (as in [RFC2904] )and authorizing
them to use specified capacity at specified times. Its strength is them to use specified capacity at specified times. Its strength is
that it is relatively simple, at least in concept, and can keep track that it is relatively simple, at least in concept, and can keep track
of simple book-keeping functions apart from network elements such as of simple book-keeping functions apart from network elements such as
routers. Its weakness is that it has no idea what the specific routers. Its weakness is that it has no idea what the specific
routing of any stated data flow is, or its capacity apart from routing of any stated data flow is, or its capacity apart from
services such as MPLS Traffic Engineering or engineering assumptions services such as MPLS Traffic Engineering or engineering assumptions
specified by the designers of a network, and obtaining that specified by the designers of a network. Obtaining that information
information from the network via SNMP GET or other network management from the network via SNMP GET or other network management action can
action can impose a severe network overhead, and is obviously not in impose a severe network overhead, and is obviously not real-time.
real-time.
For scaling reasons, operational Bandwidth Brokers generally take on For scaling reasons, operational Bandwidth Brokers generally take on
a semi-distributed or fully distributed nature. They are implemented a semi-distributed or fully distributed nature. They are implemented
on a per-point-of-presence basis, and in satellite networks might be on a per-point-of-presence basis, and in satellite networks might be
implemented in each terminal. At this point, they become difficult implemented in each terminal. At this point, they become difficult
to operationally distinguish from distributed capacity admission to operationally distinguish from distributed capacity admission
services such as described in Section 2.2.5. services such as described in Section 2.2.5.
2.2.5. Distributed capacity admission control 2.2.5. Distributed capacity admission control
The IETF developed the Integrated Services Model [RFC1633] and the The IETF developed the Integrated Services Model [RFC1633] and the
RSVP capacity admission protocol [RFC2205] in the early 1990's, and RSVP capacity admission protocol [RFC2205] in the early 1990's, and
then integrated it with the Differentiated Services Architecture in then integrated it with the Differentiated Services Architecture in
[RFC2998]. Since then, the IETF has been working on a next [RFC2998]. Since then, the IETF has been working on a next
generation signaling protocol called NSIS that can be used for generation signaling protocol called NSIS [RFC4080] that can be used
capacity admission protocol, and which is limited in scope to for capacity admission protocol, and which is limited in scope to
considering unicast sessions. [RFC4542] looked at the issue of considering unicast sessions. [RFC4542] looked at the issue of
providing preferential services in the Internet, and determined that providing preferential services in the Internet, and determined that
RSVP with its defined extensions could provide those services to RSVP with its defined extensions could provide those services to
unicast and multicast sessions. unicast and multicast sessions.
As with the Bandwidth Broker model, there are concerns regarding As with the Bandwidth Broker model, there are concerns regarding
scaling, mentioned in [RFC2208]. Present implementations that have scaling, mentioned in [RFC2208]. Present implementations that have
been measured have been found to not display the scaling concerns, been measured have been found to not display the scaling concerns,
however, and in any event the use of RSVP Aggregation enables the however, and in any event the use of RSVP Aggregation enables the
backbone to handle such sessions in a manner similar to an ATM backbone to handle such sessions in a manner similar to an ATM
Virtual Path, bundling sessions together for capacity management Virtual Path, bundling sessions together for capacity management
purposes. purposes.
2.3. Prioritized capacity admission control 2.3. Prioritized capacity admission control
Emergency Telecommunication Service, the US DoD's Assured Service, Emergency Telecommunication Service, the US Department of Defense's
and e-911 each call for some form of prioritization of some calls Assured Service, and e-911 each call for some form of prioritization
over others. Prioritization of the use of bandwidth is fundamentally of some calls over others. Prioritization of the use of bandwidth is
a matter of choices - at a point where one has multiple choices, fundamentally a matter of choices - at a point where one has multiple
applying a policy that selects among them. In the PSTN, GETS choices, applying a policy that selects among them. In the PSTN,
operates in favor of an authorized caller either by routing a call GETS operates in favor of an authorized caller either by routing a
that would otherwise be refused by a path unavailable to the general call that would otherwise be refused by a path unavailable to the
public or by queuing the call until some existing call completes and general public or by queuing the call until some existing call
bandwidth becomes available. e-911 is similar, but the policy is completes and bandwidth becomes available. e-911 is similar, but the
based on the called party, the emergency call center. MLPP operates policy is based on the called party, the emergency call center. MLPP
by preempting an existing call to make way for the new one. operates by preempting an existing call to make way for the new one.
In the Internet, routing is not performed on a per-call basis, so, In the Internet, routing is not performed on a per-call basis, so,
apart from interconnections to the PSTN, re-routing isn't an option. apart from interconnections to the PSTN, re-routing isn't an option.
On the other hand, in the Internet there are more classes of traffic On the other hand, in the Internet there are more classes of traffic
than in the PSTN. In the PSTN, all calls are uses of circuits, while than in the PSTN. In the PSTN, all calls are uses of circuits, while
in the Internet some bandwidth is always reserved for elastic in the Internet some bandwidth is always reserved for elastic
applications - at least, it must be available for routing, and there applications - at least, it must be available for routing, and there
is generally significant consideration of the web, instant messaging, is generally significant consideration of the web, instant messaging,
and other applications. In essence, any capacity admission policy and other applications. In essence, any capacity admission policy
that differentiates between calls has the option of temporarily that differentiates between calls has the option of temporarily
borrowing bandwidth from the capacity reserved for elastic traffic by borrowing bandwidth from the capacity reserved for elastic traffic by
accepting new sessions under some prioritized policy while refusing accepting new sessions under some prioritized policy while refusing
sessions of lower priority because the threshold at that priority has sessions of lower priority because the threshold at that priority has
skipping to change at page 14, line 11 skipping to change at page 13, line 28
used (apart from "no admission process"), one might admit prioritized used (apart from "no admission process"), one might admit prioritized
sessions using a higher bandwidth threshold than one admits lower sessions using a higher bandwidth threshold than one admits lower
priority sessions. priority sessions.
If capacity admission as described in Section 2.2.2 is in use, the If capacity admission as described in Section 2.2.2 is in use, the
thresholds must be set low enough that bandwidth would be available thresholds must be set low enough that bandwidth would be available
anywhere in the network. This greatly limits the utility of such a anywhere in the network. This greatly limits the utility of such a
service due to the level of bandwidth waste that results. service due to the level of bandwidth waste that results.
If capacity admission as described in Section 2.2.3 is in use, then If capacity admission as described in Section 2.2.3 is in use, then
either multiple thresholds must be applied in marking the traffic, multiple thresholds must be applied in marking the traffic, multiple
multiple traffic marks must be applied, or there must be multiple traffic marks must be applied, or there must be multiple ways to
ways to interpret the result. In any event, this is only applicable interpret the result. In any event, this is only applicable in
in domains in which the law of large numbers applies. domains in which the law of large numbers applies.
If capacity admission as described in Section 2.2.4 is in use, If capacity admission as described in Section 2.2.4 is in use,
thresholds can be applied related to a general policy or SLA, or thresholds can be applied related to a general policy or SLA, or
related to the network ingress and egress in use. It requires them related to the network ingress and egress in use. It requires them
to maintain state regarding network traffic routing separate from the to maintain state regarding network traffic routing separate from the
network; to the extent that is variable, it requires direct network; to the extent that is variable, it requires direct
monitoring in the OSS. monitoring in the OSS.
If capacity admission as described in Section 2.2.5 is in use, If capacity admission as described in Section 2.2.5 is in use,
thresholds can be applied to the critical points of the path that the thresholds can be applied to the critical points of the path that the
traffic in question actually takes because one is asking the traffic in question actually takes because one is asking the
equipment that the path traverses. equipment that the path traverses.
3. Recommendations on implementation of an Admitted Telephony Service 3. Recommendations on implementation of an Admitted Telephony Service
Class Class
It is the belief of the authors that either data plane PHB described It is the belief of the authors that either data plane PHB described
in Section 2.1, if coupled with adequate AAA and capacity admission in Section 2.1, if coupled with adequate AAA and capacity admission
procedures as described in Section 2.2.5, are sufficient to provide procedures as described in Section 2.2.5, are sufficient to provide
the services required for an Admitted Telephony service class and an the services required for an Admitted Telephony service class and an
Admitted Multimedia Conferencing Service Class. If preemption is in Admitted Multimedia Conferencing Service Class. If preemption is
view, as described in section 2.3.5.2 of [RFC4542], this provides the required, as described in section 2.3.5.2 of [RFC4542], this provides
tools for carrying out the preemption. If preemption is not in view, the tools for carrying out the preemption. If preemption is not in
or in addition to preemptive services, the application of different view, or in addition to preemptive services, the application of
thresholds depending on call precedence has the effect of improving different thresholds depending on call precedence has the effect of
the probability of call completion by admitting preferred calls at a improving the probability of call completion by admitting preferred
time that other calls are being refused. Routine and priority calls at a time that other calls are being refused. Routine and
traffic can be admitted using the same DSCP value, as the choice of priority traffic can be admitted using the same DSCP value, as the
which calls are admitted is handled in the admission procedure choice of which calls are admitted is handled in the admission
executed in the control plane, not the policing of the data plane. procedure executed in the control plane, not the policing of the data
plane.
On the point of what protocols and procedures are required for On the point of what protocols and procedures are required for
authentication, authorization, and capacity admission, we note that authentication, authorization, and capacity admission, we note that
clear standards do not at this time exist for bandwidth brokers, NSIS clear standards do not at this time exist for bandwidth brokers, NSIS
has not at this time been finalized and in any event is limited to has not at this time been finalized and in any event is limited to
unicast sessions, and that RSVP has been standardized and has the unicast sessions, and that RSVP has been standardized and has the
relevant services. We therefore recommend the use of RSVP at the relevant services. We therefore recommend the use of RSVP at the
UNI. Procedures at the NNI are business matters to be discussed UNI. Procedures at the NNI are business matters to be discussed
between the relevant networks, and are recommended but not required. between the relevant networks, and are recommended but not required.
4. IANA Considerations 4. IANA Considerations
This note requests that IANA assign a DSCP value to a second EF This note requests that IANA assign a DSCP value to a second EF
traffic class consistent with [RFC3246] and [RFC3247]. It implements traffic class consistent with [RFC3246] and [RFC3247] in the
"Differentiated Services Field Codepoints" registry. It implements
the Telephony Service Class described in [RFC4594] at lower speeds the Telephony Service Class described in [RFC4594] at lower speeds
and is included in the Real Time Treatment Aggregate and is included in the Real Time Treatment Aggregate [RFC5127] at
[I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The higher speeds. The recommended value for the code point 101100,
recommended value for the code point 101101, paralleling the EF code paralleling the EF code point, which is 101110. The code point
point, which is 101110, and is allocated from the pool set aside for should be referred to as VOICE-ADMIT.
experimental use but potentially available for standards use as well
in [RFC2474]. The code point should be referred to as VOICE-ADMIT.
This traffic class requires the use of capacity admission such as This traffic class requires the use of capacity admission such as
RSVP services together with AAA services at the User/Network RSVP services together with AAA services at the User/Network
Interface (UNI); the use of such services at the NNI is at the option Interface (UNI); the use of such services at the NNI is at the option
of the interconnected networks. of the interconnected networks.
5. Security Considerations 5. Security Considerations
A major requirement of this service is effective use of a signaling A major requirement of this service is effective use of a signaling
protocol such as RSVP, with the capabilities to identify its user protocol such as RSVP, with the capabilities to identify its user
skipping to change at page 15, line 42 skipping to change at page 15, line 13
and others if the proof of identity is not adequately strong or if and others if the proof of identity is not adequately strong or if
policies are written or implemented improperly by the carriers. This policies are written or implemented improperly by the carriers. This
goes without saying, but this section is here for it to be said... goes without saying, but this section is here for it to be said...
6. Acknowledgements 6. Acknowledgements
Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3. Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3.
Georgios Karagiannis offered additional comments on the same section. Georgios Karagiannis offered additional comments on the same section.
The impetus for including Video in the discussion, which initially The impetus for including Video in the discussion, which initially
only targeted voice, is from Dave McDysan, and text he suggested was only targeted voice, is from Dave McDysan, and text he suggested was
included. included. Dan Voce also commented.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
skipping to change at page 16, line 44 skipping to change at page 16, line 11
Chan, K., "Pre-Congestion Notification Problem Statement", Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress), draft-chan-pcn-problem-statement-01 (work in progress),
October 2006. October 2006.
[I-D.charny-pcn-single-marking] [I-D.charny-pcn-single-marking]
Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre- Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
Congestion Notification Using Single Marking for Admission Congestion Notification Using Single Marking for Admission
and Termination", draft-charny-pcn-single-marking-03 and Termination", draft-charny-pcn-single-marking-03
(work in progress), November 2007. (work in progress), November 2007.
[I-D.ietf-tsvwg-diffserv-class-aggr]
Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-class-aggr-07 (work in
progress), November 2007.
[I-D.morita-tsvwg-pps] [I-D.morita-tsvwg-pps]
Morita, N. and G. Karlsson, "Framework of Priority Morita, N. and G. Karlsson, "Framework of Priority
Promotion Scheme", draft-morita-tsvwg-pps-01 (work in Promotion Scheme", draft-morita-tsvwg-pps-01 (work in
progress), October 2003. progress), October 2003.
[ITU.MLPP.1990]
International Telecommunications Union, "Multilevel
Precedence and Preemption Service", ITU-T Recommendation
I.255.3, 1990.
[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.
[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
skipping to change at page 17, line 47 skipping to change at page 17, line 13
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.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time Services in Telecommunications Service (ETS) for Real-Time Services in
the Internet Protocol Suite", RFC 4542, May 2006. the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
August 2006. August 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Email: fred@cisco.com Email: fred@cisco.com
James Polk James Polk
Cisco Systems Cisco Systems
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
Martin Dolly Martin Dolly
AT&T Labs AT&T Labs
skipping to change at page 19, line 7 skipping to change at page 19, line 7
Martin Dolly Martin Dolly
AT&T Labs AT&T Labs
Middletown Township, New Jersey 07748 Middletown Township, New Jersey 07748
USA USA
Phone: +1-732-420-4574 Phone: +1-732-420-4574
Email: mdolly@att.com Email: mdolly@att.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 44 change blocks. 
148 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/