One document matched: draft-geib-tsvwg-diffserv-intercon-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category='info' docName='draft-geib-tsvwg-diffserv-intercon-04' ipr='trust200902'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">DiffServ interconnection classes and practice</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ruediger Geib" initials="R." role="editor"
surname="Geib">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich Hertz Str. 3-7</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code>
<city>Darmstadt</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 6151 5812747</phone>
<email>Ruediger.Geib@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>TSVWG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>RFC5127, DiffServ, Interconnection</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document proposes a limited set of interconnection QoS PHBs and
PHB groups. It further introduces some DiffServ deployment aspects. The proposals
made here should be integrated into a revised version of RFC5127.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This draft proposes a DiffServ interconnection class and
codepoint scheme. At least one party of an interconnection often is a
network provider. Many network providers operate Aggregated DiffServ
classes. This draft contains concepts and current
practice relevant for a revised version of <xref target="RFC5127">RFC5127</xref>.
Its main purpose is to be considered as an input for the latter task.</t>
<t>DiffServ sees deployment in many networks for the time being. As
described in the introduction of the <xref target="I-D.polk-tsvwg-diffserv-stds-problem-statement">
draft DiffServ problem statement</xref>, remarking of packets at domain
boundaries is a DiffServ feature. This draft proposes a set of standard
QoS classes and codepoints at interconnection points to which and from
which locally used classes and codepoints should be mapped. Such a scheme
simplifies interconnection negotiations and ensures that end to end class
properties remain roughly the same while codepoints may change.</t>
<t>The proposed Interconnection class and codepoint scheme tries to
reflect and consolidate related DiffServ and QoS standardisation efforts
outside of the IETF, namely MEF, GSMA and ITU.</t>
<t>IP Precedence has been deprecated when DiffServ was standardised. It
is common practice today however to copy the DSCPs Bits 0-2 (called
DSCP Precedence Prefix in the following) into MPLS TC or Ethernet P-Bits.
This is also reflected by the DiffServ codepoint
definitions of AF and EF. Class based PHBs may be applied
in core network sections rather than then DSCP based PHBs.</t>
<t>The set of available router and traffic
management tools to configure and operate DiffServ classes is limited.
This should be reflected by class definitions. These may in the end be
more related to transport properties than to application requirements.
Please interpret transport properties as "congestion aware" and "not
congestion aware" rather then TCP or UDP.</t>
<t>Finally, this draft proposes to leave some lass Selector Codepoint and
by that MPLS TC codepoint space to allow for future DiffServ extensions like ECN/PCN
and domain internal classes. An example for an internal PHB may be CS6.
Some operators protect their network internal routing and / or management
traffic by CS6. This PHB is possibly not available to transport customer
or interconnection partner signaling and management traffic.</t>
<t>In addition to the standardisation activities which triggered this work,
other authors published RFCs or drafts which may benefit from an interconnection
class- and codepoint scheme. RFC 5160 suggests Meta-QoS-Classes to enable
deployment of standardised end to end QoS <xref target="RFC5160">classes</xref>. The authors agree that the
proposed interconnection class- and codepoint scheme as well as the idea of
standardised end to end classes would complement their own work.
Work on signaling Class of Service at interconnection interfaces by <xref target="I-D.knoll-idr-cos-interconnect">BGP</xref>, <xref target="ID.idr-sla"> </xref>
is beyond the scope of this draft. Should the basic transport
and class properties be standardised as proposed here, signaled
access to QoS classes may be of interest. The current BGP drafts focus on
exchanging SLA and traffic conditioning parameters. They seem to assume that
common interpretation of the PHB properties identified by DSCPs has been
established prior to exchanging further details by BGP signaling.</t>
<section 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>
</section>
</section>
<section title="Terminology">
<t>This draft re-uses existing terminology.</t>
<t><list hangIndent="8" style="hanging">
<t hangText="DSCP Precedence Prefix">The bits 0-2 of the DSCP (marked "x" in this
generic DSCP field: xxxddd) are called the <xref target="RFC2474">DSCP Precedence Prefix</xref> in the following.
By ignoring the value of bits 3-6 ( d stands for don' care), a simple
aggregation of PHBs differed by DSCP is possible in IP and MPLS backbones,
but also if Ethernet transport is applied. This is discussed in more detail below.</t>
<t hangText="Class"> A class is a set of one or more PHBs utilising the same
PHB if classified by a single identical DSCP Precedence Prefix (<xref target="RFC2597">e.g. an AF class</xref>).
It is <xref target="RFC3260"> a PHB Scheduling Class</xref> or an Ordered Aggregate.
A class is a <xref target="RFC2575">PHB group</xref>. Different classes must
not be aggregated.</t>
<t hangText="PHB">On IP layer, a single DSCP identifies a single PHB. In
addition, this document proposes an MPLS like classification of traffic for
a single PHB based on the DSCP Precedence Prefix (<xref target="RFC3270">see</xref>).</t>
</list></t>
<t>The above references may be incomplete and mostly refer to the early
DiffServ RFCs only.</t>
<t>To gain clarity, "DSCP based PHB selection" is only meant if expressed exactly that
way in the remaining document. "PHB" here relates to DSCP Precedence Prefix based PHB
selection.</t>
<t>The following current practice issues relate to the concept of the DiffServ
interconnection class proposal rather than to terminology. They serve as
additional motivation of this activity:</t>
<t><list style="symbols">
<t>Abstract class names like "EF" are preferential over those
being close to an application, like "Voice". Unfortunately,
non QoS experts can't handle abstract class names. Hence and usually
sooner than later, classes are named for applications or groups
of them. One consequence however is, that people tend to combine
application group class names and SLA parameters. Based on an application
specific name and some worst case performance numbers on a paper,
they often decide that their application needs a separate new
QoS class.</t>
<t>Worse than that, but very present in practice, is the class
abstraction level which is preferred by those dealing with QoS
(as experts or non experts): the DSCPs or the DSCP Precedence Prefix values.
These are the commodity abstractions applied for QoS classes. Most
of these persons have fixed class to codepoint mappings in their
minds, which they can't easily adapt on per customer or per
interconnection partner basis. </t>
</list></t>
<t>While these issues aren't to be solved by IETF (QoS experts
could and should of course teach staff to use proper Diffserv
terminology and concepts), a simple and comprehensible QoS interconnection
class scheme also is helpful in this area.</t>
</section>
<section title="Aggregating PHBs of a class by a DSCP Precedence Prefix">
<t>Operation of IP and MPLS networks and router configuration is simplified,
if DSCP based PHBs can be aggregated into a single class by simply
classifying them by their DSCP Precedence Prefix. As specified above,
the DSCP Precedence Prefix are the bits 0-2 od the DSCP. If classification
based on DSCP Precedence Prefix is applied in an MPLS domain, the DSCP
Precedence Prefix my simply be copied into the MPLS TC field. This is
very useful in domains operating Pen-ultimate hop popping. Also in this
case, operation and configuration of routers can be simplified
significantly as compared to aggregation schemes based on configuring
individual DSCPs.</t>
<t>A network provider applying DSCP Precedence Prefix based aggregation MAY
remark incoming DSCPs so that they can be aggregated by their DSCP Precedence
Prefix. To allow for simple carrier interconnection agreements, carriers
sending traffic belonging to the same class but marked by DSCPs with differing
DSCP Precedence Prefixes SHOULD apply the interconnection marking and codepoint
scheme specified below, if they interconnect to a carrier applying DSCP
Precedence Prefix based traffic aggregation. An example where this may be
required is the <xref target="IR.34">Interactive Class of GSMA IR.34</xref> (note that
the author of this draft believes that the GSMA specification is breaking RFC 2597).
Another option is to negotiate a customised interconnection agreement of course.</t>
<t>A node forwarding traffic based the DSCP Precedence Prefix MUST classify this traffic
by the DSCP bits 0-2 and it MUST ignore the bits 4-6 of DSCP for classification.
Classification by DSCP Precedence Prefix is useful for links aggregating DiffServ
traffic. DSCP Precedence Prefix based classification is not recommended as a general
mode of operation. Edge systems, QoS policy enforcement nodes, service areas and hosts
benefit from fine grained DSCP based classification and should continue to do so.</t>
<t>RFC 2474 specifies the <xref target="RFC2474">Class Selector Codepoints</xref>. These
offer a similar concept, but they are strictly limited to xxx000 DSCPs. The Class
Selector Codepoints don't offer aggregation, they just simplify classification. This draft
intents to aggregate several PHBs of a single class by a DSCP Precedence Prefix, which
a different concept than that of the Class Selector Codepoints.</t>
</section>
<section title="An Interconnection class and codepoint scheme">
<t>DiffServ deployments mostly follow loose class specification schemes
(often one or two AF classes, EF and Best Effort). Especially
DSCP assignment for the AF classes varies between deployments.
Basic AF class property definitions are often similar however. Applying
provider specific DSCPs is in line with the DiffServ architecture. This
document doesn't propose to change that.</t>
<t>Interconnecting parties face the problem of matching classes
to be interconnected and then to agree on codepoint mapping. As stated
by <xref target="I-D.polk-tsvwg-diffserv-stds-problem-statement">
draft DiffServ problem statement</xref>, remarking is a standard
behaviour at interconnection interfaces. This draft proposes a
standard interconnection set of 4 QoS classes with well defined
DSCP and DSCP Precedence Prefix values. A sending party remarks DSCPs
from internal schemes to the Interconnection codepoints. The
receiving party remarks DSCP Precedence Prefixes and / or DSCPs to her internal
scheme. Thus the interconnection codepoint scheme fully complies with
the DiffServ architecture. An interconnection class and codepoint
scheme was introduced by <xref target="Y.1566">ITU-T</xref> (there also
includíng Ethernet). It is specified to a higher level of detail in
this document.</t>
<t>At first glance, this looks like an additional effort. But there are
obvious benefits: each party sending or receiving traffic has to
specify the mapping from or to the interconnection class and codepoint
scheme only once. Without it, this is to be negotiated per
interconnection party individually. Further, end-to-end QoS in terms
of traffic being classified for the same class in all passed domains
is likely to result if an interconnection codepoint scheme is used. It
is not necessarily resulting from individual per network mapping
negotiations.</t>
<t>The standards and deployments known to the author of this
draft are limited to 4 DiffServ classes at interconnection points (or
less).<xref target="I-D.polk-tsvwg-rfc4594-update">
Draft RFC 4597 update </xref>doesn't seem to generally contradict
to this, as it proposes to standardise "many services classes, not all
will be used in each network at any period of time." Some reasons favour
working with 4 DiffServ interconnection classes:</t>
<t><list style="symbols">
<t>There should be a coding reserve for interconnection classes. This leaves
space for future standards, for private bilateral agreements and for provider
internal classes.</t>
<t>MPLS and Ethernet support only 8 PHBs, classes or ECN indications.
Assignment of 3 bit codepoints for whatever purpose must be well thought through.
Limiting interconnection QoS to four classes is MPLS and Ethernet friendly
in that sense.</t>
<t>Migrations from one codepoint scheme to another may require spare
QoS codepoints.</t>
</list></t>
<t>The proposed class and codepoint scheme is designed for point to point IP
layer interconnections. Other types of interconnections are out of scope of
this document. The basic class and codepoint scheme is applicable on Ethernet
layer too.</t>
</section>
<section title="Consolidation of QoS standards by the interconnection codepoint scheme">
<t>The interconnection class and codepoint scheme proposed by Y.1566 also
tries to consolidate related DiffServ and QoS standardisation efforts
outside of <xref target="Y.1566"> the IETF</xref>. The interconnection class and
codepoint scheme may be a suitable approach to consolidate these standards.
MEF 23.1 specifies 3 aggregated classes, consuming up to 5 codepoints on
Ethernet layer (EF, AF3, AF1 and Best Effort)
and <xref target="MEF23.1"> 5 PHBs </xref>. MEF aggregates AF1 and Default
PHB in a single class. This is not recommended for interconnection,
as it is not in line with RFC 2597 (which requires separate forwarding
resources for each AF class and doesn't foresee aggregation of Default PHB
and an AF class).</t>
<t>GSMA IR.34 proposes four classes, EF, AF4, another AF class and
Best Effort with <xref target="IR.34"> 7 PHBs in sum</xref>. IR.34 specifies
an "Interactive" class consisting of 3 PHBs with different priorities.
IR.34 assigns the PHBS AF31, AF21 and AF11 to this Interactive class.
This breaks RFC 2597. The proposed interconnection class and codepoint scheme
supports an GSMA Interactive like class but assigns AF3 with PHBs AF31, AF32 and
AF33.</t>
<t>If IETF picks up this draft, it may be a good idea to inform MEF and GSMA about
conflicts of their standards with DiffServ and suggest joint activities to improve
the situation. Information on interworking with MEF 23 and GSMA IR.34 with the
interconnection QoS scheme could be given by a later version of this draft.</t>
<t>The classes to be supported at interconnection interfaces are specified by
Y.1566 as:</t>
<t><list hangIndent="8" style="hanging">
<t hangText="Class Priority:">EF, expecting the figures of merit describing
the PHB to be in the range of low single digit milliseconds. <xref target="RFC3246">See</xref>.</t>
<t hangText="Bulk inelastic:">Optimised for low loss, low delay, low jitter at high bandwidth.
Traffic load in this class must be controlled, e.g. by application servers.
One example could be flow admission control. There may be infrequent
retransmissions requested by the application layer to mitigate low levels
of packet losses. Discard of packets through active queue management should
be avoided in this class. Congestion in this class may result in bursty packet
loss. If used to carry multimedia traffic, it is recommended to carry audio
and video traffic in a single PHB. All of these properties influence the
buffer design.</t>
<t hangText="Assured:">This class may be optimised to transport traffic without bandwidth requirements.
It aims on Very low loss at high bandwidths. Retransmissions after losses characterise
the class and influence the buffer design. Active queue management with probabilistic
dropping may be deployed.</t>
<t hangText="Default:">Default. This class may be optimised to transport traffic without bandwidth requirements.
Retransmissions after losses characterise the class and influence the buffer design.
Active queue management with probabilistic dropping may be deployed.</t>
</list></t>
<t>Note that other DiffServ related standards trim down class requirements to SLA parameters.
To quote e.g. RFC 4594-update, "A "service class" represents a similar set of traffic
characteristics for delay, loss, and jitter as packets traverse routers in a network." This
draft adds traffic PHB properties corresponding to expected transport layer
characteristics as a key factor to a class definition: the desired class performance like
delay, jitter and worst case loss are met only if PHB and transport properties
meet the ones described by the class definition.
This is not to say, the other standards ignore PHB properties. They are e.g. a core part
of RFC 4594-update. They do not directly refer to transport protocol properties, as most
existing QoS standards prefer the approach of assigning QoS classes to applications or
application sets. This may result in undesirable class mappings, if an e.g. IP TV application
demanding low loss is matched to a class whose low loss guarantees depend on AQM mechanisms.</t>
<t>Y.1566 does not define a complete set of DSCP based PHBs to be supported at an interconnection
interface. This information is added by this draft. At interconnection points,
the following DSCP based PHBs should be accepted between interconnected parties:</t>
<t><list hangIndent="8" style="hanging">
<t hangText="Class:">PHB (one or more)</t>
<t hangText="Class Priority:">EF</t>
<t hangText="Bulk inelastic:">AF41 (AF42 and AF43 are reserved for extension)</t>
<t hangText="Assured:">AF31, AF32 and AF33</t>
<t hangText="Default:">Default (i.e. Best Effort)</t>
</list></t>
<t>Class names (and property specification) have been picked from Y.1566 above.</t>
</section>
<section title="Treatment of Network Control traffic at carrier interconnection interfaces">
<t>As specified by RFC4594, section 3.2, Network Control (NC) traffic
marked by CS6 is to be expected at interconnection interfaces. This
document does not change NC specifications of RFC4594. The latter
specification is detailed on domain internal NC traffic and on traffic
exchanged between peering points. Further, it recommends not to
forward CS6 marked traffic originating from user-controlled end points
by the NC class of a provider domain.</t>
<t>As a minor clarification to RFC4594, "peering" shouldn't be interpreted
in a commercial sense. The NC PHB is applicable also in the case of a
purchased network service based on a transit agreement with an upstream
provider. RFC4594 recommendations on NC traffic are applicable for
IP carrier interconnections in general.</t>
<t>Some CS6 traffic exchanged accross carrier interconnections will
terminate at the domain ingress node (e.g., if BGP is running between
the two routers on opposite ends of the interconnection link).</t>
<t>An IP carrier MAY limit access to the NC PHB for traffic which is
recognised as network control traffic relevant to the own domain.
Interconnecting carriers SHOULD specify treatment of CS6 marked
traffic received at a carrier interconnection which is to be
forwarded beyond the ingress node. An SLA covering the following
cases is recommended, if a carrier wishes to send CS6 marked
traffic accross an interconnection link which isn't terminating
at the interconnected ingress node:</t>
<t><list style="symbols">
<t>classification of traffic which is network control traffic for
both domains. This traffic SHOULD be classified for the NC PHB.</t>
<t>classification of traffic which is network control traffic for
the sending domain only. This traffic SHOULD be classified for
a PHB offering similar properties as the NC class (e.g. AF31
as specified by this document).</t>
<t>any other CS6 marked traffic SHOULD be remarked or dropped.</t>
</list></t>
</section>
<section title="MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes">
<t> Ethernet and MPLS support 3 bit codepoint fields to differentiate service
quality. Mapping of the DSCP Precedence Prefix to these 3 Bit fields has been
a configuration restriction in the early days of DiffServ. The concept
of classifying DiffServ traffic classes by the bits 0-2 of a DSCP has
however been part of Diffserv from start on. EF's DSCP Precedence Prefix is 5,
that of AF4 is 4 and so on. The interconnection class and codepoint
scheme respects properties and limits of a 3 bit PHB coding space in different
ways:</t>
<t><list style="symbols">
<t>it allows to classify four interconnection classes based on Class
Selector Codepoints.</t>
<t>it supports a single PHB group (AF3), whose DSCP based PHBs may
be mapped to up to three different MPLS TC's or Ethernet P-Bits.
Note that this draft doesn's favour or recommend doing that, but
it is possible.
The author isn't aware of deployed service offers with 3 different
drop levels in a single class.</t>
</list> </t>
<t>The above statement is no requirement to depricate any DSCP to MPLS TC
or Ethernet P-Bit mapping functionality. In the opposite, by limiting the
interconnection scheme to 7 DSCP based PHBs, each PHB may be mapped to a
3 Bit based PHB scheme.</t>
</section>
<section title="QoS class name selection">
<t>This is more of an informational discussion, proposed best practice, and
mainly relates to human behaviour (including QoS experts) rather than
technical issues. Above the human preference for conceivable class names
has been mentioned. Network engineers (including the former Diffserv WG
authors) recommend avoiding application related QoS class names. Focus
should be put on class properties. These can be irritating again.
Just looking at SLA parameters like Delay, Jitter and packet loss doesn't
tell the reader, which transport properties guided
the related scheduler engineering of a PHB. A router produces QoS with a
scheduling mechanism, a settable queue depth and optional active queue
management (including ECN), and may be a policer. Some kind of resource
management may be present (also in Diffserv domains). It's beyond the
imagination of the author how one would engineer more than half a dozen
classes with distinguishable properties using this set of tools.</t>
<t>There's no perfect solution to the problem, as PHB configurations
are not comprehensible to most readers, even if they were communicated
(they are operational secrets of course). There are (or should be)
engineering assumptions, when designing QoS PHBs. They closer
relate to layer 3 or layer 4 level properties than to specific
applications. In most cases, an application responds to congestion by
reducing traffic, or it ignores congestion. Active queue management
doesn't help to avoid congestion in the latter case, only resource
management does. EF may be a special case. If the EF traffic is not
responsive to congestion, and packets are assumed to be short, rather
small jitter values can be reached if engineering ensures that the
packet arrival rate never exceeds the transmission rate of that queue
(see <xref target="RFC3246">RFC 3246</xref>). There's other non congestion-responsive traffic, for
which the EF engineering assumptions may not fit. So support of a PHB
like bulk inelastic is reasonable.</t>
<t>Active queue management may be deployed for QoS classes
designed to transport traffic responding to congestion by
traffic reduction.</t>
<t>The class names of this document follow Y.1566. TCP_optimised
and especially UDP_optimised are inappropriate class names, as some
UDP based applications are or may be expected to become TCP friendly.</t>
</section>
<section title="Allow for DiffServ extendibility on MPLS and Ethernet level">
<t>Any aggregated Diffserv deployment faces codepoint depletion issues
rather soon, if deployed on MPLS or Ethernet. Coding space should be
left for new features, like ECN, PCN or Conex. In addition to carrying
customer traffic, internal routing and network management
traffic may be protected by using a separate class. Offering
interconnection with up to four classes and 4 - 6 MPLS TC's (or
Ethernet P-bits) to that respect is probably at least a
fair compromise. </t>
</section>
<section title="Acknowledgements">
<t>David Black gave many helpful comments to this work. Al Morton and
Sebastien Jobert provided feedback on many aspects during private discussions.
Brian Carpenter, Mohamed Boucadair and Thomas Knoll helped adding awareness
of further potentially related work.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce new features, it
describes how to use existing ones. The security section of
<xref target="RFC4597">RFC 4597</xref> applies.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.2575'?>
<?rfc include='reference.RFC.2597'?>
<?rfc include='reference.RFC.3246'?>
<?rfc include='reference.RFC.3260'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5462'?>
<reference anchor="min_ref">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.RFC.5160'?>
<?rfc include='reference.RFC.5127'?>
<?rfc include='reference.RFC.4597'?>
<?rfc include='reference.I-D.polk-tsvwg-diffserv-stds-problem-statement'?>
<?rfc include='reference.I-D.polk-tsvwg-rfc4594-update'?>
<?rfc include='reference.I-D.knoll-idr-cos-interconnect'?>
<!-- A reference written by by an organization not a person. -->
<reference anchor="ID.idr-sla">
<front>
<title>Inter-domain SLA Exchange
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/"/>
</reference>
<reference anchor="IR.34">
<front>
<title>IR.34 Inter-Service Provider IP Backbone Guidelines Version 7.0
</title>
<author>
<organization>GSMA Association</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="GSMA, " value="GSMA IR.34 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ir.34.pdf"/>
</reference>
<reference anchor="MEF23.1">
<front>
<title>Implementation Agreement MEF 23.1 Carrier Ethernet Class of Service Phase 2
</title>
<author>
<organization>MEF</organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="MEF, " value="MEF23.1 http://metroethernetforum.org/PDF_Documents/technical-specifications/MEF_23.1.pdf"/>
</reference>
<reference anchor="Y.1566">
<front>
<title>Quality of service mapping and interconnection between Ethernet, IP and multiprotocol label switching networks
</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="ITU, " value="http://www.itu.int/rec/T-REC-Y.1566-201207-I/en"/>
</reference>
</references>
<section anchor="app-additional" title="Change log">
<t><list hangIndent="8" style="hanging">
<t hangText="00 to 01">Added terminology and references. Added details and
information to interconnection class and codepoint scheme. Editorial changes.</t>
<t hangText="01 to 02">Added some references regarding related work.
Clarified class definitions. Further editorial improvements.</t>
<t hangText="02 to 03">Consistent terminology. Discussion of Network Management
PHB at interconnection interfaces. Editorial review.</t>
<t hangText="03 to 04">Again improved terminology. Better wording of Network Control
PHB at interconnection interfaces.</t>
</list></t>
</section>
<!-- Change Log
v00 2012-10-26 RG Initial version
v01 2013-02-20 RG Added material see change log and editorial changes
v02 2013-02-25 RG Added some references promised for -01 but forgotten there
v03 2013-06-14 RG Clarified Traffic Class definition and Network Management treatment and some other issues.
v04 2013-10-18 RG Clarified DSCP Precedence Prefix specification and Network Control treatment.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:34:01 |