One document matched: draft-ietf-tsvwg-admitted-realtime-dscp-03.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="bcp" docName="draft-ietf-tsvwg-admitted-realtime-dscp-03"
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="2007" />
<area>Transport Area</area>
<workgroup>Transport Working Group</workgroup>
<abstract>
<t>This document requests one DSCP from the IANA for real-time traffic
classes similar to voice conforming to the Expedited Forwarding Per Hop
Behavior, and admitted using a CAC procedure involving authentication,
authorization, and capacity admission, as compared to a class of
real-time traffic 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 traffic described in
RFC 4594 and which have similar requirements be require admission using
a CAC procedure involving authentication, authorization, and capacity
admission.</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 DoD's Assured Service (which
is similar to MLPP), or e-911. Capacity-admitted traffic classes need
separation from traffic not subject to admission control, from which
they can deterministically obtain their service requirements, including
SLA matters.</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 DSCP from the IANA for a class of
real-time traffic conforming to the <xref target="RFC3246"> Expedited
Forwarding </xref> <xref target="RFC3247"></xref> Per Hop Behavior and
admitted using a CAC procedure involving authentication, authorization,
and capacity admission, as compared to a class of real-time traffic
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 DoD's Assured Service (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 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 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="I-D.ietf-tsvwg-diffserv-class-aggr"></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 DS-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 Codepoint (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, which includes concepts
of authorization (an identified and authenticated user is
determined to also be authorized to use the service) and capacity
admission (at the present time, under some stated policy, capacity
exists to support the call). 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) which 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. However, NNI performance may
differ by ISP, and the performance guarantee interval may also
range from a month to a much shorter period of time. Furthermore,
a peering point NNI may not have contractual performance
guarantees or may become overloaded during certain conditions.
They are also policy-controlled interfaces, especially in BGP. As
a result, they may require policy to be applied in traffic
prioritization.</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 routine 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="I-D.ietf-tsvwg-diffserv-class-aggr"></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>
<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. There is an authorization step in the sense that the
service ensures that the user pays his bills, but 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 maybe 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>
<t>Current simulation work have shown the pre-congestion
notification mechanism works well with large number of audio and
video flows on high speed lines. This work is ongoing.</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, and obtaining that information from the
network via SNMP GET or other network management action can impose a
severe network overhead, and is obviously not in 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 NSIS 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 DoD'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 either 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 in view, 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>. It implements the Telephony Service Class
described in <xref target="RFC4594"></xref> at lower speeds and is
included in the <xref target="I-D.ietf-tsvwg-diffserv-class-aggr">Real
Time Treatment Aggregate</xref> 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 <xref
target="RFC2474"></xref>. 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.</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.I-D.ietf-tsvwg-diffserv-class-aggr'?>
<?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.4190'?>
<?rfc include='reference.RFC.4504'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:05:25 |