One document matched: draft-geib-tsvwg-diffserv-intercon-06.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-06' 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="July" year="2014" />
<!-- 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 -->
<keyword>DiffServ, Interconnection, QoS, QoS class</keyword>
<!-- 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 and well defined set of QoS PHBs
and PHB groups to be applied at (inter)connections of two separately
administered and operated networks. Many network providers operate
Treatment Aggregate of different DiffServ classes. This draft
offers a simple and constrained interconnection concept which
may simplify operation and negotiation of DiffServ at
interconnection points.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> DiffServ has been deployed in many networks. As described by section 2.3.4.2
of RFC 2475, remarking of packets at domain boundaries is a DiffServ <xref
target="RFC2475">feature</xref>. This draft proposes a set of standard QoS
classes and code points at interconnection points to which and from which
locally used classes and code points should be mapped. </t>
<t>Many providers operate MPLS based backbones. RFC 5127 assumes backbone engineering
to ensure that a major link, switch, or router can fail, and the result will be a
routed network that still meets ambient Service Level Agreements <xref target="RFC5127">classes(SLAs) </xref>.
Based on it, RFC5127 introduces the concept of Treatment Aggregates, which allow
to forward multiple DSCPs by a single MPLS Traffic Class. This draft shares the
assumption of RFC 5127 on backbone engineering. RFC3270 adds the Short Pipe Models
to the Pipe and Uniform Model already defined for <xref target="RFC2983">Differentiated Services and Tunnels</xref>
<xref target="RFC3270">, </xref>. It was required due to the presence of Pen-ultimate
hop popping (PHP) of MPLS Labels. RFC3270 expects the Short Pipe model only to be
deployed for IP tunnels and VPNs. If it used to transport non tunneled IP traffic,
some restrictions may apply for DSCP transparency. The Short Pipe model is
popular with many network providers operating MPLS.</t>
<t>RFC2474 specifies the <xref target="RFC2474">DiffServ Codepoint Field</xref>.
Differentiated treatment is based on the specific DSCP. Once set, it may change,
but any DSCP rewrite is always a one by one mapping. What is not allowed is
remarking n received DSCPs to a single transmitted DSCP. If unknown DSCPs
are received, RFC2474 recommends transmitting them unchanged by default forwarding.
An MPLS network supporting the Short Pipe model for not tunneled IPv4 traffic may
need to be able to correctly classify or rewrite the IP DSCP on interfaces
between the last Label Switch Router and a Label Edge Router. In that case, it
may not be possible to transmit 64 DSCPs through this domain.</t>
<t>RFC5127 proposes to transmit DSCPs as they are received in general. This is
not possible, if the receiving and the transmitting domain use different DSCPs
for the PHBs to which traffic is mapped if both interconnect.</t>
<t>This draft adresses IP interconnection supporting DiffServ to or between
providers operating MPLS in their backbone. It proposes operational simplifications
and methods to match IP DiffServ requirements with MPLS limitations (especially
regarding the Short Pipe Model if applied for non tunnel IPv4 traffic).
The scope of this draft is limited to 4 specified interconnection Treatment Aggregates.
To ease operation and to ensure traffic to leave a domain with the DSCPs received,
small sets of specific DSCPs and a definition of their Treatment Aggregate PHB
are suggested. The mechanism proposed here may be extended. This is relevant
only if it sees some deployment, and it is preferred to start with a limited
and simple approach to clarify the concept.</t>
<t>At first glance, the interconnection codepoint scheme may look like an
additional effort. But there are some obvious benefits: each party sending or
receiving traffic has to specify the mapping from or to the interconnection
class and code point 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 say, for a sufficiently similar PHB in all passed
domains is more likely to result if an interconnection code point scheme is used.
This draft supports a remarking of one DSCP only to one other DSCPs (no n DSCP
to one DSCP remarking).</t>
<t>The example given in RFC 5127 on aggregation of DiffServ service
classes picks 4 Treatment Aggregates. This draft also favours 4
Treatment Aggregates. Reasons to favour working with 4 DiffServ Treatment
Aggregates: </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>The fields available for carrying QoS information (e.g., DiffServ
PHB) in MPLS and Ethernet are only 3 bits in size, and are intended for
more than just QoS purposes (<xref target="RFC5129">see e.g.</xref>).</t>
<t>Migrations from one code point scheme to another may require spare
QoS code points.</t>
</list> </t>
<t>RFC5127 provides recommendations on aggregation of IP DSCPs into MPLS
Treatment Aggregates and offers a deployment example [RFC5127]. RFC5127
seems to be based on an assumption the the MPLS Short Pipe model is only
deployed for tunneled IP products or VPNs. This draft assumes presence of
non tunneled IPv4 traffic and deployment of the MPLS Short Pipe model.
That requires deviating from the RFC5127 example as follows:</t>
<t> <list style="symbols">
<t>DSCP remarking is to be expected at provider edges, if the domain is
terminating this traffic.</t>
<t>This draft follows RFC4594 in the proposed marking of provider Network
Control traffic and expands RFC4594 on treatment of CS6 marked traffic at
interconnection points (see section 5.2).</t>
</list> </t>
<t>The proposed Interconnection class and code point scheme tries to
reflect and consolidate related DiffServ and QoS standardisation
efforts outside of the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and ITU
[Y.1566]. GSMAs IR.34 specifies an inter provider VPN, but it is
nevertheless specifying a kind of DiffServ aware IP based carrier
interconnection.</t>
<section title="Related work">
<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>
</section>
<section title="Terminology">
<t>This draft reuses existing terminology of RFCs 2474 and 5127.</t>
</section>
<section title="An Interconnection class and codepoint scheme">
<t>Interconnecting parties face the problem of matching classes to be
interconnected and then to agree on code point mapping. As stated by
the <xref target="RFC2475">DiffServ Architecture</xref>, remarking is a
standard behaviour at interconnection interfaces. If the MPLS Short
Pipe model is deployed by the receiving domain, the Label Switch Router
prior to and the destination Label Edge Router may have to correctly
classify traffic by its DSCP. To avoid DSCPs being misused, only domain
internal DSCPs may be tolerated there. This means, that traffic
terminating within this domain will be delivered with the DSCP matching
the properties of the PHB at interconnection, but with the DSCP assigned
by the terminating domain. This draft
proposes a standard interconnection set of 4 Treatment Aggregates with
well defined DSCPs to be aggregated by them. A sending party
remarks DSCPs from internal schemes to the Interconnection
code points. The receiving party remarks DSCPs to her internal scheme.
The interconnection code point scheme fully complies with the DiffServ
architecture. DiffServ compliance does not allow for a rewrite of several
received DSCPs with a single DSCP to be transmitted. The set of DSCPs and
PHBs supported accross the two interconnected domains and the treatment
of PHBs and DSCPs not recognised by any of both domains should be part
of an SLA. DiffServ transit to a third party network is excluded for
initial versions of this draft (but may be added if there's interest).</t>
<t>This draft picks up the DiffServ interconnection class defintions proposed
by ITU-T <xref target="Y.1566"> Y.1566 </xref>. The classes defined there,
are used as MPLS Treatment Aggregates here. This draft proposes a set of
Treatment Aggregate PHBs and DSCPs to be aggregated.
Their properties differ slightly from those of the RFC5127 example:</t>
<t><list hangIndent="8" style="hanging">
<t hangText="Class Priority:">PHB EF, DSCP 101 110. The figures of merit
describing the PHB to be in the range of low single digit milliseconds.
<xref target="RFC3246">See</xref>. This class corresponds to RFC 5127's
real time class, but it is limited to traffic for which node configuration
"ensures that the service rate of EF packets on a given output interface
exceeds their arrival rate at that interface over long and short time
intervals" (see RFC 3246). </t>
<t hangText="Bulk inelastic:">The Treatment Aggregate is initially designed
only to transport PHB AF41, DSCP 100 010 (the other AF4 PHB
group PHB's and DSCPs should be reserved for future extension of the set
of DSCPs carried by this Treatment Aggregate). 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 (note that
video conferencing may require separate PHBs for audio and video traffic,
which could also be realised by utilising two AF 4 PHBs). All of these
properties influence the buffer design. This class is designed to transport
those parts of RFC 5127's Real Time class, which consume considerable
QoS bandwidth at the interconnection interface.</t>
<t hangText="Assured:">The complete PHB group AF3, DSCPs 011 010, 011 100
and 011 110 is transmitted by this Treatment Aggregate.
It 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. The RFC 5127
example calls this class Assured Elastic. </t>
<t hangText="Default:">The Treatment Aggregate for the default PHB, CS0
with DSCP 000 000. 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. The RFC 5127 example calls this class Elastic.</t>
</list> </t>
<t> RFC2474 recommends leaving DSCPs unknown to a receiving domain unchanged while
default PHB transport is provided. If there's community interest in this draft,
current carrier deployments should be checked for support of this RFC2474
recommendation.</t>
<t> The idea is illustrated by an example. Provider O and provider W are peer
with provider T. They have agreed upon a QoS interconnection. Traffic of
provider O terminates within provider Ts network, while the GSMA IR.34
traffic transits through the netwirk of provider T to provider F. Assume
all providers to run their own internal codepoint schemes for a class with
properties of the DiffServ Intercon Assured Treatment Aggregate. See below for a
description of GSMA IR.34. </t>
<figure anchor="Intercon-example">
<preamble></preamble>
<artwork>
Provider-O Provider-W
RFC5127 GSMA 34.1
| |
+----------+ +----------+
|AF21, AF22| |AF31, AF21|
+----------+ +----------+
| |
V V
+++++++++ +++++++++
|Rtr PrO| |Rtr PrW|
+++++++++ +++++++++
| DiffServ |
+----------+ +----------+
|AF31, AF32| |AF31, AF32|
+----------+ +----------+
| Intercon |
V V
+++++++++ |
|RtrPrTI|------------------+
+++++++++
| Provider-T domain
+-----------+
| MPLS TC 2 |
| DSCP rew. |
| AF21, AF22|
+-----------+
| | Local DSCPs Provider-T
| | +----------+ +++++++++
V +->|AF21, AF22|->-|RtrDstH|
| +----------+ +++++++++
+----------+
|AF21, AF22|
+----------+
|
+++++++++
|RtrPrTE|
+++++++++
| DiffServ
+----------+
|AF31, AF32|
+----------+
| Intercon
+++++++++
|RtrPrHF|
+++++++++
|
+----------+
|AF31, AF21|
+----------+
|
Provider-F
GSM IR.34
</artwork>
<postamble>DiffServ Intercon example</postamble>
</figure>
<t>It is easily visible that all providers only need to deploy internal DSCP to
DiffServ Intercon DSCP mappings to exchange traffic in the desired classes.
</t>
<t>RFC5127 specifies a separate Treatment Aggregate for network control
traffic. It may be present at interconnection interfaces too, but
depending on the agreement between providers, Network Control traffic may
also be classified for another interconnection class. See below
for a detailed discussion on the treatment of Network Control traffic.
</t>
<t>The proposed class and code point 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 code point scheme
is applicable on Ethernet layer too. </t>
<section title="Limitations arising from the MPLS Short Pipe model">
<t>If non tunneled IPv4 traffic is transmitted by deploying the MPLS Short
Pipe model as specified by RFC3270, then IP DSCPs may be used for classification
or they may be remarked at interfaces between the destination Label Edge Router
and the Label Switch Router. Domain internal Treatment Aggregates may be
applicable, e.g. for domain internal network control traffic. This Treatment Aggregate and
the DSCPs which are aggregated by it, may not be available for customer traffic.
A domain supporting such an internal Treatment Aggregate can't support a set of 64
DSCPs in that case. As mentioned below, the number of PHBs and their DSCPs supported
end-to-end should be as well defined as the treatment of not recognised DSCPs when
negotiating interconnection.</t>
<t>The situation is more relaxed for tunneled IPv4 traffic, IPv6 traffic in general
(for the time being) and for VPN traffic. If there's community interest, a later
version of this discuss this in more detail.</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>If the MPLS Short Pipe model is deployed for non tunneled IPv4 traffic,
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 and marked 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). As an example GSMA IR.34 proposes an Interactive
class / AF31 to carry SIP and DIAMETER traffic. While this is service control
traffic of high importance to the interconnected Mobile Network Operators, it is
certainly no Network Control traffic for a fixed network providing transit. The
example may not be perfect. It was picked nevertheless because it refers to an
existing standard.</t>
<t>any other CS6 marked traffic should be remarked or dropped.</t>
</list></t>
</section>
</section>
<section title="DiffServ Intercon relation to other QoS standards (revision may be required)">
<t> This sections provides suggestions how to aggregate traffic by DSCP
Precedence Prefexies to Ethernet and MPLS. Other Standardisation Organsiations
deal with QoS aware provider interconnection. As IP is the state of the art
realisation of provider interconnections, these standards bodies specify
DiffServ aware interconnections. Some of these bodies are industry alliances
chartered also to promote interconnection of wireless or Ethernet technology
including the exchange of IP datagrams at interconnection points. Examples are
the Metro Ethernet Forum (MEF) or the GSM Alliance (GSMA). The ITU was mentioned
earlier. ITU works across and between responsibilities of different
Standardisation Organisations and liaising with them, if their responsibilities
are touched, is traditional part of that process. </t>
<section title="MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes">
<t> The interconnection class and code point 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 the DSCP
Precedence Prefix. </t>
<t>it supports a single PHB group (AF3), whose DSCPs may be aggregated into
a sinle MPLS TC (or Ethernet priority) based on their joint DSCP Precedence
Prefix. This kind of aggregation will work for the AF4 PHB group, if the
PHBs AF42 and AF43 need to be supported in addition to AF41. </t>
<t>Applying only 4 aggregated classes at interconnection allows for
bilateral extensions, if desired. Should two carriers agree to map AF32
and AF33 to an additional individual MPLS TC and offer an Ordered
Aggregate across the interconnecting domain, this proposal at leaves
some MPLS TC coding space for such an extension (although this draft
doesn't recommend interconnections of that type).</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 6 PHBs, each PHB may be mapped
to an individual Traffic Class or Priority also within MPLS or Ethernet
(if desired). </t>
</section>
<section title="Proposed GSMA IR.34 to DiffServ Intercon mapping">
<t>GSMA IR.34 provides guidelines on how to set up and interconnect <xref target="IR.34">
Internet Protocol (IP) Packet eXchange (IPX) Networks</xref>. An IPX network is an
inter-Service Provider IP backbone which comprises the interconnected networks of IPX
Providers. IPX is a telecommunications interconnection model for the exchange of IP based
traffic between customers of separate mobile and fixed operators as well as other types
of service provider (such as ISP), via IP based network-to-network interface. Note that IPX
is not a public interconnection model however, it is designed as a private IP Backbone
of the interconnected parties. Two IPX partners may interconnect using transit offered by an
Inter-Service Provider IP Backbone. This requires an IP QoS aware interconnection as described
by this draft between IPX provider and Inter-Service Provider IP Backbone.</t>
<t> GSMA IR.34 specifies 4 aggregated classes and 7 PHBs. Mapping to DiffServ Intercon is smooth
apart from the GSMA aggregated class Interactive, which consistfs of 4 PHBs. The table below
lists a suggested mapping to DiffServ Intercon.</t>
<figure anchor="IR.34_mapping">
<preamble></preamble>
<artwork>
| GSMA IR.34 | DiffServ-Intercon |
| | |
| Agg. Class | PHB | Agg. Class | PHB |
+---------------+-------+--------------+--------+
|Conversational | EF | Priority | EF |
+---------------+-------+--------------+--------+
| Streaming | AF41 |Bulk inelastic| AF41 |
+---------------+-------+--------------+--------+
| Interactive | AF31 | Assured | AF31 |
+ +-------+ +--------+
| (ordered by | AF32 | | |
+ priority, +-------+ + AF32 +
| AF3 highest) | AF21 | | |
+ +-------+ +--------+
| | AF11 | | AF33 |
+---------------+-------+--------------+--------+
| Background | CS0 | Default | CS0 |
+---------------+-------+--------------+--------+
</artwork>
<postamble>Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon</postamble>
</figure>
<t> The motivation resulting in the design of the IR.34 Intercative class are unknown to the author of this draft. It is out of scope of this draft to decide how 4 PHBs can be mapped to a to single aggregated class. The suggested mapping is pragmatic and tries to come as close as possible to other design criteria pursued by GSMA IR.34. </t>
</section>
<section title="Proposed MEF 23.1 to DiffServ Intercon mapping">
<t> MEF 23.1 is an implemenation agreement facilitating Ethernet service
interoperability and consistency between Operators and the use of a <xref target="MEF23.1"> common CoS Label set for Subscribers </xref>. It pursues the same aims and method on Ethernet layer as this draft does on IP layer (i.e. providing an interconnection class and codepoint scheme). MEF 23.1 addresses external network to network interfaces typically interconnecting metro ethernet providers. This may typically involve Ethernet Network Sections associated with typical Operator domains that interconnect at external network to network interfaces. MEF 23.1 specifies three aggregated CoS classes. In addition, the usage of a subset of Ethernet PCP and IP DSCP values is specifiedthus facilitating synergies between Ethernet and IP services and networks. The main purpose is specifying operator virtual (Ethernet) connections. As an IP QoS model is added, this draft proposes an IP class and codepoint mapping. </t>
<t> MEF 23.1 QoS mapping requires some thought as 3 classes are supported of which two are Ordered Aggregates. MEF 23.1s section 8.5.1 example on IP DSCP mapping may suggest supporting classification based on the DSCP Precedence Prefix. MEF 23.1 section 8.5.2.1 allows the conclusion that MEF class M is best mapped to this drafts Bulk inelastic class. The suggested mapping MEF to DiffServ Intercon is limited to the the MEF color blind mode (3 classes, no sub-classes): </t>
<figure anchor="MEF_23.1_mapping">
<preamble></preamble>
<artwork>
| MEF 23.1 | DiffServ-Intercon |
| | |
| Agg. Class | PHB | Agg. Class | PHB |
+---------------+-------+--------------+--------+
| High | EF | Priority | EF |
+---------------+-------+--------------+--------+
| Medium | AF3 |Bulk inelastic| AF41 |
+---------------+-------+--------------+--------+
| Low | CS1 | Default | CS0 |
+---------------+-------+--------------+--------+
</artwork>
<postamble>Suggested mapping of MEF 23.1 color blind mode classes and PHBs to DiffServ Intercon</postamble>
</figure>
<t> The MEF color aware mode supports Ordered Aggregates in the MEF classes M and L. The MEF L specification classifies AF1 and Best Effort for the same Ordered Aggregate. A Better than Best Effort service produced in the same queue as best effort traffic can be realized, but hasn't been standardized by IETF. This document doesn't suggest any mapping. Diffserv Intercon also doesn't suggest an Ordered Aggregate in the Bulk Inelastic class. Later versions of this document may do so and specify a solution. Both issues are left for bilateral negotiation. </t>
</section>
</section>
<section title="Contributors">
<t>David Black provided many helpful comments and inputs to this work.</t>
</section>
<section title="Acknowledgements">
<t> Al Morton and Sebastien Jobert provided feedback on many aspects during
private discussions. Mohamed Boucadair and Thomas Knoll helped
adding awareness of related work. David Black, Fred Baker and Brian Carpenter
provided intensive feedback and discussion.</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="RFC2475">RFC 2475</xref> and
<xref target="RFC4594">RFC 4594</xref> apply. </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.2475'?>
<?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.5129'?>
<?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.2983'?>
<?rfc include='reference.RFC.5160'?>
<?rfc include='reference.RFC.5127'?>
<?rfc include='reference.RFC.4594'?>
<?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="IEEE802.1Q">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks
</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2005" />
</front>
</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>
<t hangText="04 to 05">Large rewrite and re-ordering of contents.</t>
<t hangText="04 to 05">Description of IP and MPLS related requirements and
constraints on DSCP rewrites.</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.
v05 2014-02-01 RG Rewrite and Reordering of contents.
v04 2014-07-03 RG Description of IP and MPLS related requirements and constraints on DSCP rewrites.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:29:55 |