draft-ietf-tsvwg-admitted-realtime-dscp-00.txt   draft-ietf-tsvwg-admitted-realtime-dscp-01.txt 
Please post the attached as a working group document in tsvwg
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Updates: 4542,4594 (if approved) Cisco Systems Updates: 4542,4594 Cisco Systems
Intended status: Informational M. Dolly (if approved) M. Dolly
Expires: June 14, 2007 AT&T Labs Intended status: Best Current AT&T Labs
December 13, 2006 Practice March 22, 2007
Expires: September 23, 2007
An EF DSCP for Capacity-Admitted Traffic DSCPs for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-00 draft-ietf-tsvwg-admitted-realtime-dscp-01
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 37
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 14, 2007. This Internet-Draft will expire on September 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document requests a DSCP from the IANA for a class of real-time This document requests two DSCPs from the IANA for real-time traffic
traffic conforming to the Expedited Forwarding Per Hop Behavior and classes similar to voice and video, conforming to the Expedited
admitted using a CAC procedure involving authentication, Forwarding Per Hop Behavior, and admitted using a CAC procedure
authorization, and capacity admission, as compared to a class of involving authentication, authorization, and capacity admission, as
real-time traffic conforming to the Expedited Forwarding Per Hop compared to a class of real-time traffic conforming to the Expedited
Behavior but not subject to capacity admission or subject to very Forwarding Per Hop Behavior but not subject to capacity admission or
coarse capacity admission. subject to very coarse capacity admission.
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 DoD's Assured Service
(which is similar to MLPP), or e-911. These do not need separate (which is similar to MLPP), or e-911. These do not need separate
DSCPs or separate PHBs that are separate from each other, but they DSCPs or separate PHBs that separate them from each other, but they
need a traffic class from which they can deterministically obtain need a traffic class that separates them from the traffic not subject
their service requirements from including SLA matters. to admission control, from which they can deterministically obtain
their service requirements, including SLA matters.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7
2. Implementation of the Admitted Telephony Service Class . . . . 6 2. Implementation of the Admitted Service Classes . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 6 2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . . 8 2.2. Capacity admission control . . . . . . . . . . . . . . . . 9
2.2.1. Capacity admission control by assumption . . . . . . . 8 2.2.1. Capacity admission control by assumption . . . . . . . 9
2.2.2. Capacity admission control by call counting . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 9 the network . . . . . . . . . . . . . . . . . . . . . 10
2.2.4. Centralized capacity admission control . . . . . . . . 10 2.2.4. Centralized capacity admission control . . . . . . . . 11
2.2.5. Distributed capacity admission control . . . . . . . . 11 2.2.5. Distributed capacity admission control . . . . . . . . 11
2.3. Prioritized capacity admission control . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 Service Class . . . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This document requests a DSCP from the IANA for a class of real-time This document requests two DSCPs from the IANA for two classes of
traffic conforming to the Expedited Forwarding [RFC3246][RFC3247] Per real-time traffic conforming to the Expedited Forwarding [RFC3246]
Hop Behavior and admitted using a CAC procedure involving [RFC3247] Per Hop Behavior and admitted using a CAC procedure
authentication, authorization, and capacity admission, as compared to involving authentication, authorization, and capacity admission, as
a class of real-time traffic conforming to the Expedited Forwarding compared to a class of real-time traffic conforming to the Expedited
Per Hop Behavior but not subject to capacity admission or subject to Forwarding Per Hop Behavior but not subject to capacity admission or
very coarse capacity admission. subject to very coarse capacity admission.
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 DoD's Assured Service
(which is similar to MLPP and uses preemption), or e-911, in addition (which is similar to MLPP and uses preemption), or e-911, in addition
to normal routine calls that use call admission. It is possible to to normal routine calls that use call admission. It is possible to
use control plane protocols to generally restrict session admission use control plane protocols to generally restrict session admission
such that admitted traffic should receive the desired service, and such that admitted traffic should receive the desired service, and
the policy (e.g., routine, NS/EP, e-911, etc) need not be signaled in the policy (e.g., routine, National Security or Emergency
a DSCP. However, service providers need to distinguish between Preparedness [NS/EP] communications, e-911, etc) need not be signaled
in a DSCP. However, service providers need to distinguish between
special-policy traffic and other classes, particularly the existing special-policy traffic and other classes, particularly the existing
VoIP services that perform no capacity admission or only very coarse VoIP services that perform no capacity admission or only very coarse
capacity admission and can exceed their allocated resources. capacity admission and can exceed their allocated resources.
This DSCP applies to the Telephony Service Class described in One of these DSCPs applies to the Telephony Service Class described
[RFC4594]. WIthin an ISP and on inter-ISP links (i.e., within in [RFC4594]. The other applies to the Multimedia Conferencing
networks whose internal paths are uniform at hundreds of megabits or Service Class described in the same docuemnt. Other video classes
faster), one would expect this traffic to be carried in the Real Time are not belieevd to be required by the targetted services and to not
have the current problem of confusion with unadmitted traffic.
WIthin an ISP and on inter-ISP links (i.e., within networks whose
internal paths are uniform at hundreds of megabits or faster), one
would expect all of this traffic to be carried in the Real Time
Traffic Class described in [I-D.ietf-tsvwg-diffserv-class-aggr]. Traffic Class described in [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 DS-compliant node to a DS
behavior aggregate [RFC2475]. It may be thought of as a program behavior aggregate [RFC2475]. It may be thought of as a program
configured on the interface of an Internet host or router, configured on the interface of an Internet host or router,
skipping to change at page 5, line 49 skipping to change at page 6, line 49
In short, the Telephony Service Class described in [RFC4594] permits In short, the Telephony Service Class described in [RFC4594] permits
the use of capacity admission in implementing the service, but the use of capacity admission in implementing the service, but
present implementations either provide no capacity admission services present implementations either provide no capacity admission services
or do so in a manner that depends on specific traffic engineering. or do so in a manner that depends on specific traffic engineering.
In the context of the Internet backbone, the two are essentially In the context of the Internet backbone, the two are essentially
equivalent; the edge network is depending on specific engineering by equivalent; the edge network is depending on specific engineering by
the service provider that may not be present. the service provider that may not be present.
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 capacity in various among users or the uses of available Voice-on-IP or Video-on-IP
ways. Various agencies would like to provide services as described capacity in various ways. Various agencies would like to provide
in section 2.6 of [RFC4504] or in [RFC4190]. This requires the use services as described in section 2.6 of [RFC4504] or in [RFC4190].
of capacity admission to differentiate among users (which might be This requires the use of capacity admission to differentiate among
911 call centers, other offices with preferential service contracts, users (which might be 911 call centers, other offices with
or individual users gaining access with special credentials) to preferential service contracts, or individual users gaining access
provide services to them that are not afforded to routine customer- with special credentials) to provide services to them that are not
to-customer IP telephony sessions. afforded to routine 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
cooperate with network control, and may be given different levels of cooperate with network control, and may be given different levels of
preference depending on the policies that the network applies. In preference depending on the policies that the network applies. In
order to provide this differentiation, the IETF requests that the order to provide this differentiation, the IETF requests that the
IANA assign a separate DSCP value to admitted sessions using the IANA assign a separate DSCP value to admitted sessions using the
Telephony service (see Section 4). Telephony service (see Section 4).
2. Implementation of the Admitted Telephony Service Class 2. Implementation of the Admitted Service Classes
2.1. Potential implementations of EF in this model 2.1. Potential implementations of EF in this model
There are at least two possible ways to implement the Expedited There are at least two possible ways to implement the Expedited
Forwarding PHB in this model. They are to implement separate classes Forwarding PHB in this model. They are to implement separate classes
as a set of as a set of
o Multiple data plane traffic classes, each consisting of a policer o Multiple data plane traffic classes, each consisting of a policer
and a queue, and the queues enjoying different priorities, or and a queue, and the queues enjoying different priorities, or
skipping to change at page 8, line 28 skipping to change at page 9, line 28
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 Internet Voice 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
skipping to change at page 9, line 4 skipping to change at page 10, line 4
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. There is an authorization step in the sense that the
service ensures that the user pays his bills, but no capacity service ensures that the user pays his bills, but no capacity
admission is considered because there is a clear separation from the admission is considered because there is a clear separation from the
voice application service provider admitting the calls and the access application service provider admitting the calls and the access
network provider admitting the traffic. The two have no way of network provider admitting the traffic. The two have no way of
knowing about each other, except maybe 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,
and limits how far away a Gatekeeper can influence calls. This is and limits how far away a Gatekeeper can influence calls. This is
because call counting doesn't scale when more than one server is because call counting doesn't scale when more than one server is
admitting flows across the same limited speed links. This approach admitting flows across the same limited speed links. This approach
is consistent with the original design of H.323, which in 1996 was a is consistent with the original design of H.323, which in 1996 was a
mechanism for connecting H.320 media gateways across a LAN. VoIP has mechanism for connecting H.320 media gateways across a LAN. VoIP has
come a long way since then, however, and the engineering trade-offs come a long way since then, however, and the engineering trade-offs
this approach requires in complex networks are unsatisfactory. this approach requires in complex networks are unsatisfactory.
skipping to change at page 9, line 42 skipping to change at page 10, line 42
or do not configure the use of [RFC3312], or other call management or do not configure the use of [RFC3312], or other call management
systems, the amount of traffic between the two must be contained systems, the amount of traffic between the two must be contained
below that bottleneck even if the normal path is of much higher below that bottleneck even if the normal path is of much higher
bandwidth. In addition, the multiplexing of traffic streams between bandwidth. In addition, the multiplexing of traffic streams between
different pairs of gatekeepers over a common LAN infrastructure is different pairs of gatekeepers over a common LAN infrastructure is
not handled by the application, and so must be managed in the not handled by the application, and so must be managed in the
engineering of the network. engineering of the network.
2.2.3. End-point capacity admission performed by probing the network 2.2.3. End-point capacity admission performed by probing the network
[I-D.briscoe-tsvwg-cl-architecture] is one of many proposals that The IETF started looking into the use of Pre-Congestion Notification
have looked at probing of the network by the end system to determine mechanism to full fill the need of admission control for real-time
its capacity to accept a new session. Such proposals have been made traffic. The main contribution of this work for admission control is
a number of times by the likes of NTT Labs, UIUC researchers, Cisco to allow the network to provide the network's pre-congestion
Systems (which used its Service Assurance Architecture to probe information using encoding of a field in the IP header. This network
capacity using pings and report when network delay variability pre-congestion information is then used for making admission control
increased), and others. Many of the proposals tested in research decisions. With the decision influenced by this network pre-
have fared reasonably well in high bandwidth environments where congestion notification information and any applicable policy
actual network congestion is unusual, but have not scaled down to information with possible user credentials and situational
slower access links. information. The pre-congestion notification mechanism does not
limit the placement of the admission control decision point or the
signaling protocol used.
The problem has been, in essence, that variable rate codecs can be on The overview of one of the current proposals is provided by
the quiet side of the average for lengthy periods of time and then [I-D.chan-pcn-problem-statement]. With the pre-congestion
become noisier. New sessions can be disrupted or disrupt existing notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An
sessions if they perform their capacity admission procedures at a initial deployment model provided by
quiet time and find themselves overrunning the allocated capacity [I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in
during a noisy time. In addition, for a service in which the network [I-D.charny-pcn-single-marking]. Similar approaches have been
must exercise control and differentiate among users, the users cannot proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars
be depended on to differentiate among themselves in the network's and Karlsson in their PBAC work, and many others.
favor. The network must manage that service.
For this reason, [I-D.briscoe-tsvwg-cl-architecture] is only proposed Current simulation work have shown the pre-congestion notification
as a solution within backbone networks, leaving access networks to mechanism works well with large number of audio and video flows on
provide other forms of capacity admission, and more generally such high speed lines. This work is ongoing.
techniques are only recommended in high bandwidth contexts. What is
not addressed, is when these quite times become not-at-all quite due
to some event occurring, leading to great amounts of traffic. A
means of maintaining existing critical calls is essential to retain a
given service. Times of disaster can be such times of extreme bursts
of the number of call attempts. Once a call is established, that
call needs to be retained.
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 them including applying AAA services (as in [RFC2904] )and authorizing
to use specified capacity at specified times. Its strength is that them to use specified capacity at specified times. Its strength is
it is relatively simple, at least in concept, and can keep track of that it is relatively simple, at least in concept, and can keep track
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, and obtaining that
information from the network via SNMP GET or other network management information from the network via SNMP GET or other network management
action can impose a severe network overhead, and is obviously not in action can impose a severe network overhead, and is obviously not in
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 worked to describe a next [RFC2998]. Since then, the IETF has been working on a next
generation capacity admission protocol, which is calls NSIS, and generation signaling protocol called NSIS that can be used for
which is limited in scope to considering unicast sessions. [RFC4542] capacity admission protocol, and which is limited in scope to
looked at the issue of providing preferential services in the considering unicast sessions. [RFC4542] looked at the issue of
Internet, and determined that RSVP with its defined extensions could providing preferential services in the Internet, and determined that
provide those services to unicast and multicast sessions. RSVP with its defined extensions could provide those services to
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
skipping to change at page 12, line 39 skipping to change at page 13, line 34
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. If the services required for an Admitted Telephony service class and an
preemption is in view, as described in section 2.3.5.2 or [RFC4542], Admitted Multimedia Conferencing Service Class. If preemption is in
this provides the tools for carrying out the preemption. If view, as described in section 2.3.5.2 of [RFC4542], this provides the
preemption is not in view, or in addition to preemptive services, the tools for carrying out the preemption. If preemption is not in view,
application of different thresholds depending on call precedence has or in addition to preemptive services, the application of different
the effect of improving the probability of call completion by thresholds depending on call precedence has the effect of improving
admitting preferred calls at a time that other calls are being the probability of call completion by admitting preferred calls at a
refused. Routine and priority traffic can be admitted using the same time that other calls are being refused. Routine and priority
DSCP value, as the choice of which calls are admitted is handled in traffic can be admitted using the same DSCP value, as the choice of
the admission procedure executed in the control plane, not the which calls are admitted is handled in the admission procedure
policing of the data plane. 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, fundamentally, requests IANA the assign a DSCP value to a This note requests that IANA assign a DSCP value to a second EF
second EF traffic class consistent with [RFC3246] and [RFC3247] and traffic class consistent with [RFC3246] and [RFC3247]. It implements
implementing the Telephony Service Class described in [RFC4594] at the Telephony Service Class described in [RFC4594] at lower speeds
lower speeds and [I-D.ietf-tsvwg-diffserv-class-aggr] at higher and is included in the Real Time Treatment Aggregate
speeds. This new traffic class requires the use of capacity [I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The
recommended value for the code point 101101, paralleling the EF code
point, which is 101110, and is allocated from the pool set aside for
experimental use but potentially available for standards use as well
in [RFC2474]. The code point should be referred to as VOICE-ADMIT.
Additionally, it requests that IANA assign a DSCP value to a traffic
class consistent with [RFC2597]. It implements the Multimedia
Conferencing Service Class described in [RFC4594] at lower speeds and
is included in the Real Time Treatment Aggregate
[I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The
recommended value for the code point 100101, paralleling the AF42
code point, which is 100100, and is allocated from the pool set aside
for experimental use but potentially available for standards use as
well in [RFC2474]. The code point should be referred to as VIDEO-
ADMIT.
Both of these new traffic classes require the use of capacity
admission such as RSVP services together with AAA services at the admission such as RSVP services together with AAA services at the
User/Network Interface (UNI); the use of such services at the NNI is User/Network Interface (UNI); the use of such services at the NNI is
at the option of the interconnected networks. The recommended value at the option of the interconnected networks.
for the code point 101100, paralleling the EF code point, which is
101110, and both of which are allocated from Pool 1 as described in
[RFC2474].
The code point should be referred to as EF-ADMIT.
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
either as an individual or as a member of some corporate entity, and either as an individual or as a member of some corporate entity, and
assert a policy such as "routine" or "priority". assert a policy such as "routine" or "priority".
This capability, one has to believe, will be abused by script kiddies This capability, one has to believe, will be abused by script kiddies
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.
Georgios Karagiannis offered additional comments on the same section.
The impetus for including Video in the discussion, which initially
only targetted voice, is from Dave McDysan.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tsvwg-diffserv-class-aggr] [I-D.ietf-tsvwg-diffserv-class-aggr]
Chan, K., "Aggregation of DiffServ Service Classes", Chan, K., "Aggregation of DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-class-aggr-00 (work in draft-ietf-tsvwg-diffserv-class-aggr-01 (work in
progress), June 2006. progress), October 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC 2998, November 2000. over Diffserv Networks", RFC 2998, November 2000.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Ramakrishnan, "Supplemental Information for the New
Definition of the EF PHB (Expedited Forwarding Per-Hop Definition of the EF PHB (Expedited Forwarding Per-Hop
Behavior)", RFC 3247, March 2002. Behavior)", RFC 3247, March 2002.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, June 14002. Diffserv", RFC 3260, April 2002.
[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
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
7.2. Informative References 7.2. Informative References
[I-D.briscoe-tsvwg-cl-architecture] [I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre- Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-03 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), June 2006. (work in progress), October 2006.
[I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006.
[I-D.chan-pcn-problem-statement]
Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress),
October 2006.
[I-D.charny-pcn-single-marking]
Charny, A., "Pre-Congestion Notification Using Single
Marking for Admission and Pre-emption",
draft-charny-pcn-single-marking-00 (work in progress),
October 2006.
[I-D.morita-tsvwg-pps]
Morita, N. and G. Karlsson, "Framework of Priority
Promotion Scheme", draft-morita-tsvwg-pps-01 (work in
progress), October 2003.
[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
ReSerVation Protocol (RSVP) Version 1 Applicability ReSerVation Protocol (RSVP) Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208, Statement Some Guidelines on Deployment", RFC 2208,
September 1997. September 1997.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
skipping to change at page 15, line 31 skipping to change at page 17, line 28
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[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.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
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
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
skipping to change at page 17, 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 Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 39 change blocks. 
142 lines changed or deleted 192 lines changed or added

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