One document matched: draft-ietf-tsvwg-admitted-realtime-dscp-04.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-04"
ipr="full3978" updates="4542,4594">
<front>
<title abbrev="">DSCPs 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>It 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 video distribution/conferencing bridge or gaming server and
the user(s), and 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>. The video classes addressed include
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>Since the admitted 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 the above video classes.</t>
<t>Other video classes are not believed to be required by the targeted
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 <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" includes and
procedure identifies a user, verifies the authenticity of the
identification, and determines whether the user is authorized to
use the service. "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 is depending on
specific engineering by the service provider that may not be
present.</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-on-IP or Video-on-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 title="Proposed Solution">
<t>The IETF is asked to differentiate, in the Telephony Service,
between sessions that are originated without capacity admission or
using traffic engineering and sessions that are originated using more
robust capacity admission procedures. Sessions of the first type use a
traffic class in which they compete without network-originated control
as described in <xref target="CAC-LAN"></xref> or <xref
target="CAC-H323"></xref>, and in the worst case lose traffic due to
policing. Sessions of the second type cooperate with network control,
and may be given different levels of preference depending on the
policies that the network applies. In order to provide this
differentiation, the IETF requests that the IANA assign a separate
DSCP value to admitted sessions using the Telephony service (see <xref
target="IANA"></xref> ).</t>
</section>
</section>
<section anchor="implementation"
title="Implementation of the Admitted Service Classes">
<section anchor="data-plane"
title="Potential implementations of EF in this model">
<t>There are at least two possible ways to implement 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, including a widely reported test
for NS/EP services that implemented the policing model and described
it as an implementation of the multi-priority model, and discussion in
other environments of the intermixing of voice and video traffic at
relatively low bandwidths in the policing model.</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 |`.
EF ---------> <=> ----------||----+ `.
high| `.
EF2---------> <=> ----------||----+ .'-----------
. 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 .
EF ---------> <=> -------\ |`.
--||----+ `.
EF2---------> <=> -------/ 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 containing video data are relatively large (generally the
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.
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 five major ways that capacity admission is done or has
been proposed to be done in real-time applications: <list
style="symbols">
<t>Capacity admission control by assumption,</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, and</t>
<t>Distributed capacity admission control.</t>
</list></t>
<t>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.</t>
<section anchor="CAC-LAN"
title="Capacity admission control by assumption">
<t>The first approach is to ignore the matter entirely. If one
assumes that the capacity available to the application is uniformly
far in excess of its requirements, it is perhaps overhead that can
be ignored. This assumption is currently made in Internet VoIP
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
high speed broadband connection and use capable ISPs to deliver the
service. The only "authorization" verified is that the user pays his
bills; no capacity admission is considered because there is a clear
separation from the application service provider admitting the calls
and the access network provider admitting the traffic. The two have
no way of knowing about each other, except in the abstract
sense.</t>
</section>
<section anchor="CAC-H323"
title="Capacity admission control by call counting">
<t>The H.323 gatekeeper, originally specified in 1996, operates on
the model that the considerations of <xref target="CAC-LAN"></xref>
generally apply, and that it is therefore sufficient to count calls
in order to ensure that any bottlenecks in the network are never
overloaded. Which phone is calling which phone is configured
information into the 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, and limits how far away a Gatekeeper can influence
calls. This is because call counting doesn't scale when more than
one server is admitting flows across the same limited speed links.
This approach 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 come a long way since then, however, and the
engineering trade-offs this approach requires in complex networks
are unsatisfactory.</t>
<t>SIP provides the option to go down another path, to admit its
servers at layer 7, have no awareness of lower layer connectivity,
resulting in a divorce from infrastructure knowledge - save for
<xref target="RFC3312"></xref>, which binds the two, but only at the
endpoints.</t>
<t>In short, if there is a bottleneck anywhere in the network that
might be used to connect two gatekeepers, SIP proxies that do not
implement or do not configure the use of <xref
target="RFC3312"></xref>, or other call management systems, the
amount of traffic between the two must be contained below that
bottleneck even if the normal path is of much higher bandwidth. In
addition, the multiplexing of traffic streams between different
pairs of gatekeepers over a common LAN infrastructure is not handled
by the application, and so must be managed in the engineering of the
network.</t>
</section>
<section anchor="CAC-probing"
title="End-point capacity admission performed by probing the network">
<t>The IETF started looking into the use of Pre-Congestion
Notification mechanism to full fill the need of admission control
for real-time traffic. The main contribution of this work for
admission control is to allow the network to provide the network's
pre-congestion information using encoding of a field in the IP
header. This network pre-congestion information is then used for
making admission control decisions. With the decision influenced by
this network pre-congestion notification information and any
applicable policy information with possible user credentials and
situational information. The pre-congestion notification mechanism
does not limit the placement of the admission control decision point
or the signaling protocol used.</t>
<t>The overview of one of the current proposals is provided by <xref
target="I-D.chan-pcn-problem-statement"></xref>. With the
pre-congestion notification encoding described in <xref
target="I-D.briscoe-tsvwg-cl-phb"></xref>. An initial deployment
model provided by <xref
target="I-D.briscoe-tsvwg-cl-architecture"></xref>. Another proposal
is embodied in <xref target="I-D.charny-pcn-single-marking"></xref>.
Similar approaches have been proposed in <xref
target="I-D.morita-tsvwg-pps"></xref> and its related drafts, by
Ivars and Karlsson in their PBAC work, and many others.</t>
</section>
<section anchor="CAC-BB"
title="Centralized capacity admission control">
<t>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 been discussed in the literature pertaining to the <xref
target="RFC2475"> Differentiated Services Architecture </xref>. It
is, in short, a central system that performs a variety of services
on behalf of clients of a network including applying AAA services
(as in <xref target="RFC2904"></xref> ) and authorizing them to use
specified capacity at specified times. Its strength is that it is
relatively simple, at least in concept, and can keep track of simple
book-keeping functions apart from network elements such as routers.
Its weakness is that it has no idea what the specific routing of any
stated data flow is, or its capacity apart from services such as
MPLS Traffic Engineering or engineering assumptions specified by the
designers of a network. Obtaining that information from the network
via SNMP GET or other network management action can impose a severe
network overhead, and is obviously not real-time.</t>
<t>For scaling reasons, operational Bandwidth Brokers generally take
on a semi-distributed or fully distributed nature. They are
implemented on a per-point-of-presence basis, and in satellite
networks might be implemented in each terminal. At this point, they
become difficult to operationally distinguish from distributed
capacity admission services such as described in <xref
target="CAC-RSVP"></xref>.</t>
</section>
<section anchor="CAC-RSVP"
title="Distributed capacity admission control">
<t>The IETF developed the <xref target="RFC1633"> Integrated
Services Model </xref> and the <xref target="RFC2205"> RSVP capacity
admission protocol </xref> in the early 1990's, and then integrated
it with the Differentiated Services Architecture in <xref
target="RFC2998"></xref>. Since then, the IETF has been working on a
next generation signaling protocol called <xref
target="RFC4080">NSIS</xref> that can be used for capacity admission
protocol, and which is limited in scope to considering unicast
sessions. <xref target="RFC4542"></xref> looked at the issue of
providing preferential services in the Internet, and determined that
RSVP with its defined extensions could provide those services to
unicast and multicast sessions.</t>
<t>As with the Bandwidth Broker model, there are concerns regarding
scaling, mentioned in <xref target="RFC2208"></xref>. Present
implementations that have been measured have been found to not
display the scaling concerns, however, and in any event the use of
RSVP Aggregation enables the backbone to handle such sessions in a
manner similar to an ATM Virtual Path, bundling sessions together
for capacity management purposes.</t>
</section>
</section>
<section anchor="CAC-priority"
title="Prioritized capacity admission control">
<t>Emergency Telecommunication Service, the US Department of Defense's
Assured Service, and e-911 each call for some form of prioritization
of some calls over others. Prioritization of the use of bandwidth is
fundamentally a matter of choices - at a point where one has multiple
choices, applying a policy that selects among them. In the PSTN, GETS
operates in favor of an authorized caller either by routing a call
that would otherwise be refused by a path unavailable to the general
public or by queuing the call until some existing call completes and
bandwidth becomes available. e-911 is similar, but the policy is based
on the called party, the emergency call center. MLPP operates by
preempting an existing call to make way for the new one.</t>
<t>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.
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
in the Internet some bandwidth is always reserved for elastic
applications - at least, it must be available for routing, and there
is generally significant consideration of the web, instant messaging,
and other applications. In essence, any capacity admission policy that
differentiates between calls has the option of temporarily borrowing
bandwidth from the capacity reserved for elastic traffic by accepting
new sessions under some prioritized policy while refusing sessions of
lower priority because the threshold at that priority has been
reached.</t>
<t>For example, regardless of the type of capacity admission that is
used (apart from "no admission process"), one might admit prioritized
sessions using a higher bandwidth threshold than one admits lower
priority sessions.</t>
<t>If capacity admission as described in <xref
target="CAC-H323"></xref> is in use, the thresholds must be set low
enough that bandwidth would be available anywhere in the network. This
greatly limits the utility of such a service due to the level of
bandwidth waste that results.</t>
<t>If capacity admission as described in <xref
target="CAC-probing"></xref> is in use, then multiple thresholds must
be applied in marking the traffic, multiple traffic marks must be
applied, or there must be multiple ways to interpret the result. In
any event, this is only applicable in domains in which the law of
large numbers applies.</t>
<t>If capacity admission as described in <xref target="CAC-BB"></xref>
is in use, thresholds can be applied related to a general policy or
SLA, or related to the network ingress and egress in use. It requires
them to maintain state regarding network traffic routing separate from
the network; to the extent that is variable, it requires direct
monitoring in the OSS.</t>
<t>If capacity admission as described in <xref
target="CAC-RSVP"></xref> is in use, thresholds can be applied to the
critical points of the path that the traffic in question actually
takes because one is asking the equipment that the path traverses.</t>
</section>
</section>
<section title="Recommendations on implementation of an Admitted Telephony Service Class">
<t>It is the belief of the authors that either data plane PHB described
in <xref target="data-plane"></xref>, if coupled with adequate AAA and
capacity admission procedures as described in <xref
target="CAC-RSVP"></xref>, are sufficient to provide the services
required for an Admitted Telephony service class and an Admitted
Multimedia Conferencing 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 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 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 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 offered some textual comments and rewrote <xref
target="CAC-probing"></xref>. Georgios Karagiannis offered additional
comments on the same section. The impetus for including Video in the
discussion, which initially only targeted voice, is from Dave McDysan,
and text he suggested was included. Dan Voce also commented.</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'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.briscoe-tsvwg-cl-architecture'?>
<?rfc include='reference.RFC.3247'?>
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.RFC.4542'?>
<?rfc include='reference.RFC.5127'?>
<?rfc include='reference.RFC.4594'?>
<?rfc include='reference.I-D.briscoe-tsvwg-cl-phb'?>
<?rfc include='reference.RFC.3260'?>
<?rfc include='reference.I-D.chan-pcn-problem-statement'?>
<?rfc include='reference.RFC.2998'?>
<?rfc include='reference.I-D.charny-pcn-single-marking'?>
<?rfc include='reference.I-D.morita-tsvwg-pps'?>
<?rfc include='reference.RFC.1633'?>
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.2208'?>
<?rfc include='reference.RFC.2904'?>
<?rfc include='reference.RFC.3312'?>
<?rfc include='reference.RFC.4080'?>
<?rfc include='reference.RFC.4190'?>
<?rfc include='reference.RFC.4504'?>
<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 05:24:50 |