One document matched: draft-ietf-tsvwg-admitted-realtime-dscp-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations)
and others prefer numbers. The RFC Editor always uses
symbolic tags. The tags used are the anchor attributes
of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-ietf-tsvwg-admitted-realtime-dscp-05"
ipr="full3978" updates="4542,4594">
<front>
<title abbrev="">DSCP for Capacity-Admitted Traffic</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<phone>+1-408-526-4257</phone>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="James Polk" initials="J.M." surname="Polk">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Richardson</city>
<code>75082</code>
<region>Texas</region>
<country>USA</country>
</postal>
<phone>+1-817-271-3552</phone>
<email>jmpolk@cisco.com</email>
</address>
</author>
<author fullname="Martin Dolly" initials="M." surname="Dolly">
<organization>AT&T Labs</organization>
<address>
<postal>
<street></street>
<city>Middletown Township</city>
<code>07748</code>
<region>New Jersey</region>
<country>USA</country>
</postal>
<phone>+1-732-420-4574</phone>
<email>mdolly@att.com</email>
</address>
</author>
<date year="2008" />
<area>Transport Area</area>
<workgroup>Transport Working Group</workgroup>
<abstract>
<t>This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for real-time
traffic classes similar to voice conforming to the Expedited Forwarding
Per Hop Behavior, and admitted using a call admission procedure
involving authentication, authorization, and capacity admission.</t>
<t>This document also recommends that certain classes of video traffic
described in RFC 4594 and which have similar requirements be changed to
require admission using a Call Admission Control (CAC) procedure
involving authentication, authorization, and capacity admission.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements Language">
<t>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 <xref target="RFC2119">
RFC 2119 </xref>.</t>
</note>
<!--
<?rfc needLines="10" ?>
<texttable anchor='table_example' title="A Very Simple Table">
<preamble> Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content. </preamble>
<ttcol align='center'> ttcol #1 </ttcol>
<ttcol align='center'> ttcol #2 </ttcol>
<c> c #1 </c> <c> c #2 </c>
<c> c #3 </c> <c> c #4 </c>
<c> c #5 </c> <c> c #6 </c>
<postamble> which is a very simple example. </postamble>
</texttable>
-->
</front>
<middle>
<!--
<t> There are multiple list styles: 'symbols', 'letters', 'numbers',
'hanging', 'format', etc. </t>
<t>
<list style="symbols">
<t> First bullet </t>
<t> Second bullet </t>
</list>
</t>
-->
<!--
<figure anchor="xml_happy" title="Figure N">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for a class of
real-time traffic. This class conforms to the <xref target="RFC3246">
Expedited Forwarding </xref> <xref target="RFC3247"></xref> Per Hop
Behavior. It is also admitted using a CAC procedure involving
authentication, authorization, and capacity admission. This differs from
a real-time traffic class conforming to the Expedited Forwarding Per Hop
Behavior but not subject to capacity admission or subject to very coarse
capacity admission.</t>
<t>It also recommends that certain classes of video described in <xref
target="RFC4594"></xref> be treated as requiring capacity admission as
well.</t>
<t>These applications have one or more potential congestion points
between the endpoints. Reserving capacity for them is important to
application performance. All of these applications have low tolerance to
jitter (aka delay variation) and loss, as summarized in <xref
target="implementation"></xref>, and most (except for multimedia
conferencing) have inelastic flow behavior from Figure 1 of <xref
target="RFC4594"></xref>. Inelastic flow behavior and low jitter/loss
tolerance are the service characteristics that define the need for
admission control behavior.</t>
<t>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 Department of Defense's
Assured Service (which is similar to <xref target="ITU.MLPP.1990">
Multi-Level Precedence and Preemption</xref> procedure), or e-911, in
addition to normal routine calls that use call admission. It is possible
to use control plane protocols to generally restrict session admission
such that admitted traffic should receive the desired service, and the
policy (e.g. Routine, National Security or Emergency 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 VoIP services that
perform no capacity admission or only very coarse capacity admission and
can exceed their allocated resources.</t>
<t>The requested DSCP applies to the Telephony Service Class described
in <xref target="RFC4594"></xref>.</t>
<t>Since video classes have not had the history of mixing admitted and
non-admitted traffic in the same Per-Hop Behavior (PHB) as has occurred
for EF, an additional DSCP code point is not recommended. Instead, the
recommended "best practice" is to perform admission control for all
traffic in three of <xref target="RFC4594"></xref>'s video classes: the
<list style="symbols">
<t>Interactive Real-Time Traffic (CS4, used for Video conferencing
and Interactive gaming),</t>
<t>Broadcast TV (CS3) for use in a video on demand context, and</t>
<t>AF4 Multimedia Conferencing (video conferencing).</t>
</list></t>
<t>Other video classes are believed to not have the current problem of
confusion with unadmitted traffic and therefore would not benefit from
the notion of a separate DSCP for admitted 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 <xref
target="RFC5127"></xref>.</t>
<section title="Definitions">
<t>The following terms and acronyms are used in this document.</t>
<t><list style="hanging">
<t hangText="PHB:">A Per-Hop-Behavior (PHB) is the externally
observable forwarding behavior applied at a Differentiated
Services compliant node to a DS behavior aggregate <xref
target="RFC2475"></xref>. It may be thought of as a program
configured on the interface of an Internet host or router,
specified drop probabilities, queuing priorities or rates, and
other handling characteristics for the traffic class.</t>
<t hangText="DSCP:">The Differentiated Services Code Point (DSCP),
as defined in <xref target="RFC2474"></xref>, 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 by each packet it forwards
<xref target="RFC3260"></xref>. It is a 6-bit number embedded into
the 8-bit TOS field of an IPv4 datagram or the Traffic Class field
of an IPv6 datagram.</t>
<t hangText="CAC:">Call Admission Control includes concepts of
authorization and capacity admission. "Authorization" refers to
any procedure that identifies a user, verifies the authenticity of
the identification, and determines whether the user is authorized
to use the service under the relevant policy. "Capacity Admission"
refers to any procedure that determines whether capacity exists
supporting a session's requirements under some policy. <vspace
blankLines="1" /> In the Internet, these are separate functions,
while in the PSTN they and call routing are carried out
together.</t>
<t hangText="UNI:">A User/Network Interface (UNI) is the interface
(often a physical link or its virtual equivalent) that connects
two entities that do not trust each other, and in which one (the
user) purchases connectivity services from the other (the
network). <xref target="UNI-NNI"></xref> shows two user networks
connected by what appears to each of them to be a single network
("The Internet", access to which is provided by their service
provider) that provides connectivity services to other users.
<vspace blankLines="1" /> UNIs tend to be the bottlenecks in the
Internet, where users purchase relatively low amounts of bandwidth
for cost or service reasons, and as a result are most subject to
congestion issues and therefore issues requiring traffic
conditioning and service prioritization.</t>
<t hangText="NNI:">A Network/Network Interface (NNI) is the
interface (often a physical link or its virtual equivalent) that
connects two entities that trust each other within limits, and in
which the two are seen as trading services for value. <xref
target="UNI-NNI"></xref> shows three service networks that
together provide the connectivity services that we call "the
Internet". They are different administrations and are very
probably in competition, but exchange contracts for connectivity
and capacity that enable them to offer specific services to their
customers. <vspace blankLines="1" /> NNIs may not be bottlenecks
in the Internet if service providers contractually agree to
provision excess capacity at them, as they commonly do. However,
NNI performance may differ by ISP, and the performance guarantee
interval may range from a month to a much shorter period.
Furthermore, a peering point NNI may not have contractual
performance guarantees or may become overloaded under certain
conditions. They are also policy-controlled interfaces, especially
in BGP. As a result, they may require traffic prioritization
policy.</t>
<t hangText="Queue:">There are multiple ways to build a
multi-queue scheduler. Weighted Round Robin (WRR) literally builds
multiple lists and visits them in a specified order, while a
calendar queue (often 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 such list for transmission during
that time interval. While these differ dramatically in
implementation, the external difference in behavior is generally
negligible when they are properly configured. Consistent with the
definitions used in the <xref target="RFC2475"> Differentiated
Services Architecture </xref>, these are treated as equivalent in
this document, and the lists of WRR and the classes of a calendar
queue will be referred to uniformly as "queues".</t>
</list></t>
<figure anchor="UNI-NNI" title="UNI and NNI interfaces">
<artwork align="center"><![CDATA[
_.--------.
,-'' `--.
,-' `-.
,-------. ,',-------. `.
,' `. ,',' `. `.
/ User \ UNI / / Service \ \
( Network +-----+ Network ) `.
\ / ; \ / :
`. ,' ; `. .+ :
'-------' / '-------' \ NNI \
; \ :
; "The Internet" \ ,-------. :
; +' `. :
UNI: User/Network Interface / Service \ |
| ( Network ) |
NNI: Network/Network Interface \ / |
: +. ,' ;
: / '-------' ;
: / ;
,-------. \ ,-------. / NNI /
,' `. : ,' `+ ;
/ User \ UNI / Service \ ;
( Network +-----+ Network ) ,'
\ / \ \ / /
`. ,' `.`. ,' ,'
'-------' `.'-------' ,'
`-. ,-'
`--. _.-'
`--------''
]]></artwork>
</figure>
</section>
<section title="Problem">
<t>In short, the Telephony Service Class described in <xref
target="RFC4594"></xref> permits the use of capacity admission in
implementing the service, but present implementations either provide
no capacity admission services or do so in a manner that depends on
specific traffic engineering. In the context of the Internet backbone,
the two are essentially equivalent; the edge network depends on
specific engineering by the service provider that may not be present,
especially in a mobile environment.</t>
<t>However, services are being requested of the network that would
specifically make use of capacity admission, and would distinguish
among users or the uses of available Voice-over-IP or Video-over-IP
capacity in various ways. Various agencies would like to provide
services as described in section 2.6 of <xref target="RFC4504"></xref>
or in <xref target="RFC4190"></xref>. This requires the use of
capacity admission to differentiate among users (which might be 911
call centers, other offices with preferential service contracts, or
individual users gaining access with special credentials) to provide
services to them that are not afforded to non-capacity admitted
customer-to-customer IP telephony sessions.</t>
</section>
</section>
<section anchor="implementation"
title="Candidate Implementations of the Admitted Telephony Service Class">
<section anchor="data-plane"
title="Potential implementations of EF in this model">
<t>There are at least two possible ways to implement isolation between
the Capacity Admitted PHB and the Expedited Forwarding PHB in this
model. They are to implement separate classes as a set of <list
style="symbols">
<t>Multiple data plane traffic classes, each consisting of a
policer and a queue, and the queues enjoying different priorities,
or</t>
<t>Multiple data plane traffic classes, each consisting of a
policer but feeding into a common queue or multiple queues at the
same priority.</t>
</list> We will explain the difference, and describe in what way
they differ in operation. The reason this is necessary is that there
is current confusion in the industry.</t>
<t>The multi-priority model is shown in <xref
target="priority-schematic"></xref>. In this model, traffic from each
service class is placed into a separate priority queue. If data is
present in both queues, traffic from one of them will always be
selected for transmission. This has the effect of transferring jitter
from the higher priority queue to the lower priority queue, and
reordering traffic in a way that gives the higher priority traffic a
smaller average queuing delay. Each queue must have its own policer,
however, to protect the network from errors and attacks; if a traffic
class thinks it is carrying a certain data rate but an abuse sends
significantly more, the effect of simple prioritization would not
preserve the lower priorities of traffic, which could cause routing to
fail or otherwise impact an SLA.</t>
<figure anchor="priority-schematic"
title="Implementation as a data plane priority">
<artwork align="center"><![CDATA[
.
policers priorities |`.
Unadmitted EF <=> ----------||----+ `.
high| `.
Admitted EF <=> ----------||----+ .'-----------
. medium .'
rate queues |`. +-----+ .' Priority
AF1------>||----+ `. / low |' Scheduler
| `. /
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc)
]]></artwork>
</figure>
<t>The multi-policer model is shown in <xref
target="policer-schematic"></xref>. In this model, traffic from each
service class is policed according to its SLA requirements, and then
placed into a common priority queue. Unlike the multi-priority model,
the jitter experienced by the traffic classes in this case is the
same, as there is only one queue, but the sum of the traffic in this
higher priority queue experiences less average jitter than the elastic
traffic in the lower priority.</t>
<figure anchor="policer-schematic"
title="Implementation as a data plane policer">
<artwork align="center"><![CDATA[
policers priorities .
Unadmitted EF <=> -------\ |`.
--||----+ `.
Admitted EF <=> -------/ high| `.
. | .'--------
rate queues |`. +-----+ .'
AF1------>||----+ `. / low | .' Priority
| `. / |' Scheduler
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc)
]]></artwork>
</figure>
<t>The difference between the two operationally is, as stated, the
issues of loss due to policing and distribution of jitter.</t>
<t>If the two traffic classes are, for example, voice and video,
datagrams conaining video data can be relatively large (often of
variable sizes up to the path MTU) while datagrams containing voice
are relatively 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 video to voice can be disruptive, while at higher speeds
the jitter is nominal compared to the jitter requirements of voice. At
access network speeds, therefore, <xref target="RFC4594"></xref>
recommends separation of video and voice into separate queues, while
at optical speeds <xref target="RFC5127"></xref> recommends that they
use a common queue.</t>
<t>If, on the other hand, the two traffic classes are carrying the
same type of application with the same jitter requirements, then
giving one preference in this sense does not benefit the higher
priority traffic and may harm the lower priority traffic. In such a
case, using separate policers and a common queue is a superior
approach.</t>
</section>
<section anchor="CAC" title="Capacity admission control">
<t>There are at least six major ways that capacity admission is done
or has been proposed to be done for real-time applications. Each will
be described below, then Section 3 will judge which ones are likely to
meet the requirements of the Admitted Telephony service class. These
include: <list style="symbols">
<t>Drop Precedence used to force sessions to voluntarily exit,</t>
<t>Capacity admission control by assumption or engineering,</t>
<t>Capacity admission control by call counting,</t>
<t>End-point capacity admission performed by probing the
network,</t>
<t>Centralized capacity admission control via bandwidth broker,
and</t>
<t>Distributed capacity admission control using protocols such as
RSVP or NSIS.</t>
</list></t>
<t>The problem with capacity admission by assumption, which is widely
reployed in today's VoIP environment, is that it depends on the
assumptions made. One can do careful traffic engineering to ensure
needed bandwidth, but this can also be painful, and has to be
revisited when the network is changed or network usage changes.</t>
<t>The problem with dropping traffic to force users to hang up is that
it affects a broad class of users - if there is capacity for N calls
and the N+1 calls are active, data is dropped randomly from all
sessions to ensure that offered load doesn't exceed capacity. On very
fast links, that is acceptable, but on lower speed links it can
seriously affect call quality.</t>
<t>There are two fundamental problems with depending on the endpoint
to perform capacity admission; it may not be able to accurately
measure the impact of the traffic it generates on the network, and it
tends to be greedy (eg., it doesn't care). If the network operator is
providing a service, he must be able to guarantee the service, which
means that he can't trust systems that are not controlled by his
network.</t>
<t>The problem with mechanisms that don't enable the association of a
policy with the request is that they don't allow for multi-policy
services, which are becoming important.</t>
<t>The operator's choice of admission procedure must, for this DSCP,
ensure the following:<list style="symbols">
<t>The actual links that a session uses have enough bandwidth to
support it.</t>
<t>New sessions are refused admission if there is inadequate
bandwidth under the relevant policy.</t>
<t>If multiple policies are in use in a network, that the user is
identified and the correct policy applied.</t>
<t>Under periods of network stress, the process of admission of
new sessions does not disrupt existing sessions, unless the
service explicitly allows for disruption of calls.</t>
</list></t>
</section>
<section title="Recommendations on implementation of an Admitted Telephony Service Class">
<t>It is the belief of the authors that either PHB implementation
described in <xref target="data-plane"></xref>, if coupled with
adequate AAA and capacity admission procedures as described in <xref
target="CAC"></xref>, are sufficient to provide the services required
for an Admitted Telephony service class. If preemption is required, as
described in section 2.3.5.2 of <xref target="RFC4542"></xref>, this
provides the tools for carrying out the preemption. If preemption is
not in view, or if used in addition to preemptive services, the
application of different thresholds depending on call precedence has
the effect of improving the probability of call completion by
admitting preferred calls at a time that other calls are being
refused. Routine and priority traffic can be admitted using the same
DSCP value, as the choice of which calls are admitted is handled in
the admission procedure executed in the control plane, not the
policing of the data plane.</t>
<t>On the point of what protocols and procedures are required for
authentication, authorization, and capacity admission, we note that
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
unicast sessions, and that RSVP has been standardized and has the
relevant services. We therefore recommend the use of RSVP at the UNI.
Procedures at the NNI are business matters to be discussed between the
relevant networks, and are recommended but not required.</t>
</section>
</section>
<section title="Summary: changes from RFC 4594">
<t>To summarize, there are two changes to <xref target="RFC4594"></xref>
discussed in this document:<list style="hanging">
<t hangText="Telephony class:">The Telephony Service Class in RFC
4594 does not involve capacity admission, but depends on application
layer admission that only estimates capacity, and that through
static engineering. In addition to that class, a separate Admitted
Telephony Class is added which performs capacity admission
dynamically.</t>
<t hangText="Video classes">Capacity admission is added to three
video classes. These are the Interactive Real-Time Traffic class,
Broadcast TV class when used for video on demand, and the Multimedia
Conferencing class.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This note requests that IANA assign a DSCP value to a second EF
traffic class consistent with <xref target="RFC3246"></xref> and <xref
target="RFC3247"></xref> in the "Differentiated Services Field
Codepoints" registry. It implements the Telephony Service Class
described in <xref target="RFC4594"></xref> at lower speeds and is
included in the <xref target="RFC5127">Real Time Treatment
Aggregate</xref> at higher speeds. The recommended value for the code
point is 101100, paralleling the EF code point, which is 101110. The
code point should be referred to as VOICE-ADMIT.</t>
<t>This traffic class requires the use of capacity admission such as
RSVP services together with AAA services at the User/Network Interface
(UNI); the use of such services at the NNI is at the option of the
interconnected networks.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>A major requirement of this service is effective use of a signaling
protocol such as RSVP, with the capabilities to identify its user either
as an individual or as a member of some corporate entity, and assert a
policy such as "routine" or "priority".</t>
<t>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
policies are written or implemented improperly by the carriers. This
goes without saying, but this section is here for it to be said...</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Kwok Ho Chan,
Georgios Karagiannis,
Dan Voce, and Bob Briscoe commented and offered text.
The impetus for including Video in the
discussion, which initially only targeted voice, is from Dave McDysan,
</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.3246'?>
<?rfc include='reference.RFC.4594'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.RFC.3247'?>
<?rfc include='reference.RFC.3260'?>
<?rfc include='reference.RFC.4190'?>
<?rfc include='reference.RFC.4504'?>
<?rfc include='reference.RFC.4542'?>
<?rfc include='reference.RFC.5127'?>
<reference anchor="ITU.MLPP.1990">
<front>
<title abbrev="MLPP">Multilevel Precedence and Preemption
Service</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date year="1990" />
</front>
<seriesInfo name="ITU-T" value="Recommendation I.255.3" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:40:58 |