One document matched: draft-geib-tsvwg-diffserv-intercon-00.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-00" ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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 -->
<city>Darmstdadt</city>
<region></region>
<code>64297</code>
<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="November" year="2012" />
<!-- 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 deals proposes a DiffServ interconnection class and
codepoint scheme. At least one party of an interconnection often is a
network provider. Aggregated DiffServ classes are often deployed
within provider networks. To respect this, this draft also 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 may be mapped. Such a scheme
simplifies interconnection negotiations and ensures that class properties
remain roughly the same, even if codepoints 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 depricated when DiffServ was standardised. It
is common practice today however to copy the DSCPs "IP Precedence Bits"
into MPLS TC or Ethernet P-Bits, whenever possible. This is reflected
by the DiffServ codepoint definitions of AF and EF. This practice and
it's limits deserve to be documented and disussed briefly.</t>
<t>The draft further adds proposals by which philosophy to add or
pick aggregated DiffServ classes. The set of available router and traffic
management tools to configure and operate DiffServ classes is limited.
This should be reflected by class definitions, which may in the end more
strongly be related transport properties than application requirements.
Please read that "congestion aware" and "not congestion aware" rather
then TCP or UDP.</t>
<t>Finally, this draft proposes to leave some MPLS TC codepoint space to
allow for future DiffServ extensions like ECN/PCN and domain internal
classes (network management traffic is a good example) </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>A later version of this draft needs to be clearer on that. The author
prefers to talk of QoS classes. PHB or PHB groups are not commonly used,
although they are better defined. An issue is, that PHB groups, which
e.g. allow to offer two or more different drop levels (PHB's) within
one PHB group , hardly saw commercial deployment. This may change
with more Ethernet services being offered.</t>
<t>Some rather concept than terminology related real world issues are
additional motivations of this activity:</t>
<t><list style="symbols">
<t>Abstract class names like "EF" are preferrential 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 and often decide,
based on a name and some numbers on a paper, that their application
needs separate QoS class.</t>
<t>Worse than that, but very present in real life, is the class
abstraction level which is preferred by those dealing with QoS
(as experts or non experts): the DSCPs or the IP precedence. So
DSCPs or IP Precedence values are the commodity real life
abstractions applied for QoS classes. Most of these persons
hav fixed class to codepoint mappings in their
minds, which they can't easily adapt on a per customer and
interconnection partner basis. </t>
</list> 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 QoS interconnection scheme also
is helpful in this area. Those dealing with QoS on any level need
to understand the interconnection classes and their codepoints, and
they are able to deal with the mappings of those to their own networks
class and codepoint scheme. Simplicity is important, however.</t>
</section>
<section title="An Interconnection class and codepoint scheme">
<t>DiffServ deployments mostly follow loose class specification schemes
(often one or two AF PHBs or PHB groups, EF and Best Effort). Especially
DSCP assignment for the AF classes varies between deployment, while
basic class defeinitions are often similar. This is in line with the
DiffServ architecture. This document doesn't propose to change that.</t>
<t>Interconnecting parties usually 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 prolebm statement</xref>, remarking is a standard
behaviour at interconnection interfaces. This draft propses a set of
4 QoS classes with a set of well defined DSCPs as interconnection
codepoint scheme. As the idea is that a sending party remarks DSCPs
from internal schemes to the Interconnection codepoints and the
receiving party remarks to their internal scheme, the interconnection
codepoint scheme fully complies with the DiffServ architecture.</t>
<t>While this may look like an additional step at first, 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 once per
interconnection party. 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, while it
is not necessarily resulting from individual per network
interconnection negotiations.</t>
<t>The Interconnection scheme is supporting aggregated DiffServ
classes, as proposed by <xref target="RFC5127">RFC 5127</xref>. Note that <xref target="I-D.polk-tsvwg-rfc4594-update">
draft RFC 4597 update</xref>
doesn't expect any network to deploy all possible QoS classes (and
proposes to standardise DSCPs for all while maintaining deployment
of classes a network specific issue). RFC2597 does not allow to
aggregate separate <xref target="RFC2597">AF classes</xref>. Hence a low number of interconnection
classes on aggregated level makes sense, as some codepoint space for
carrier internal services and future features like ECN should be
left also for aggregatd classes. MPLS and Ethernet only support up
to 8 QoS classes. IP over Ethernet and / or MPLS is acommodity in
todays operational environments, and inter layer QoS likely will
be a commodity 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>. MEF 23.1 specifies 3 aggregated classes,
consuming up to 5 bit codepoints (EF, two AF classes and Best Effort)
and <xref target="MEF23.1">
8 DSCPs</xref>. GSMA IR.34 proposes four aggregated DiffServ classes,
EF, 2 AF and Best Effort with <xref target="IR.34">
7 DSCPs (PHBs) in sum</xref>. Consolidation may be
reached for EF, one AF class and Best Effort, meaning three aggregated
or 5 DSCPs. Consolidation here aims on similar class definitions
and DiffServ codepoints in all standards, MEF23.1, GSMA IR.34 and
Y.1566. This will again simplify product design and interconnection
negotiations for customers and parties following these standards.</t>
</section>
<section title="MPLS, Ethernet and IP Precedence for aggregated classes">
<t>IP Precedence has been depricated when DiffServ was standardised.
Ethernet and MPLS support 3 bit codepoint fields to differntiate service
quality. Mapping of the IP precedence to these 3 Bit fields has been
a configuration restriction in the early days of DiffServ. The concept
of paying attention to the three most significant bits of a DSCP has
however been part of Diffserv from start on (EF's IP Precedence is 5,
that of AF4 is 4 and so on). The interconnection class and codepoint
scheme respects this in different ways:</t>
<t><list style="symbols">
<t>it allows to classify four aggregated classes based on IP
precedence.</t>
<t>It supports a single PHB group (AF3), which may be mapped to up to
three different MPLS TC's or Ethernet P-Bits. Note that the
author 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>This is of course no requirement to depricate any DSCP to MPLS TC
or Ethernet P-Bit mapping functionality. This functionalities are very
important as well.</t>
</section>
<section title="QoS class name selection">
<t>This is more of an informational discussion, proposed best practice, and
mainly relates to human behviour (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 to avoid application related QoS class names. Focus
should be put on class properties. But these can be irritating again, as
just looking at a few SLA numbers doesn't tell the reader, which
engineering assumptions resulted in the scheduler configurations of
a class. 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 presendt (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 with this set of tools.</t>
<t>There's no perfect solution to the problem, as scheduler 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 schedulers. But they closer
relate to layer 3 or layer 4 level properties than to specific
applications. In general, 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 enginieering ensures that the
packet arrival rate never exceeds the transmision 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 a second class
with EF like properties (but a different engineering) may be present.</t>
<t>Active queue management may be deployed for QoS classes,
which are designed to transport traffic responding to congestion by
traffic reduction.</t>
<t>The author couldn't yet find conceivable class names. TCP_optimised
and especially UDP_optimised are inappropriate, as some UDP based
application are or may be expected to become TCP friendly.</t>
</section>
<section title="Allow for DiffServ extendability 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 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.2597'?>
<?rfc include='reference.RFC.3246'?>
<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.2119'?>
<?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'?>
<!-- A reference written by by an organization not a person. -->
<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="draft Y.QoSmap (now Y.61566) https://datatracker.ietf.org/documents/LIAISON/liaison-2012-07-03-itu-t-sg-12-tsvwg-development-of-informative-codepoint-mapping-in-itu-t-study-group-12-attachment-1.zip"/>
</reference>
</references>
<!-- Change Log
v01 2012-10-26 RG Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:33:59 |