draft-geib-tsvwg-diffserv-intercon-05.txt   draft-geib-tsvwg-diffserv-intercon-06.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational February 14, 2014 Intended status: Informational July 4, 2014
Expires: August 18, 2014 Expires: January 5, 2015
DiffServ interconnection classes and practice DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-05 draft-geib-tsvwg-diffserv-intercon-06
Abstract Abstract
This document proposes a limited and well defined set of QoS PHBs and This document proposes a limited and well defined set of QoS PHBs and
PHB groups to be applied at (inter)connections of two separately PHB groups to be applied at (inter)connections of two separately
administered and operated networks. Many network providers operate administered and operated networks. Many network providers operate
Aggregated DiffServ classes. This draft contains DiffServ Treatment Aggregate of different DiffServ classes. This draft offers
aggregation friendly interconnection concepts. a simple and constrained interconnection concept which may simplify
operation and negotiation of DiffServ at interconnection points.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 11
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Aggregating PHBs of a class by a DSCP Precedence Prefix . . . 6 3. An Interconnection class and codepoint scheme . . . . . . . . 5
4. An Interconnection class and codepoint scheme . . . . . . . . 6 3.1. Limitations arising from the MPLS Short Pipe model . . . . 9
4.1. Treatment of Network Control traffic at carrier 3.2. Treatment of Network Control traffic at carrier
interconnection interfaces . . . . . . . . . . . . . . . . 9 interconnection interfaces . . . . . . . . . . . . . . . . 9
5. DiffServ Intercon relation to other QoS standards . . . . . . 10 4. DiffServ Intercon relation to other QoS standards
5.1. MPLS, Ethernet and DSCP Precedence Prefixes for (revision may be required) . . . . . . . . . . . . . . . . . . 10
4.1. MPLS, Ethernet and DSCP Precedence Prefixes for
aggregated classes . . . . . . . . . . . . . . . . . . . . 11 aggregated classes . . . . . . . . . . . . . . . . . . . . 11
5.2. Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11 4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11
5.3. Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12 4.3. Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
DiffServ has been deployed in many networks. As described by section 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 2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a
DiffServ feature [RFC2475]. This draft proposes a set of standard DiffServ feature [RFC2475]. This draft proposes a set of standard
QoS classes and code points at interconnection points to which and QoS classes and code points at interconnection points to which and
from which locally used classes and code points should be mapped. from which locally used classes and code points should be mapped.
IP precedence has been deprecated. MPLS and Ethernet support 3 bit Many providers operate MPLS based backbones. RFC 5127 assumes
code point fields to differentiate service quality (see MPLS TC / backbone engineering to ensure that a major link, switch, or router
Traffic Class [RFC5462] and PCP, Priority Code Point [IEEE802.1Q]). can fail, and the result will be a routed network that still meets
The concept of classifying DiffServ traffic classes by the bits 0-2 ambient Service Level Agreements classes(SLAs) [RFC5127]. Based on
of a DSCP has been part of Diffserv from start on. This is also it, RFC5127 introduces the concept of Treatment Aggregates, which
reflected by the DiffServ codepoint definitions of AF and EF. It is allow to forward multiple DSCPs by a single MPLS Traffic Class. This
common practice today also to copy these three DSCP bits into MPLS TC draft shares the assumption of RFC 5127 on backbone engineering.
or Ethernet P-Bits. PHBs based on DSCP bit 0-2 classification may be RFC3270 adds the Short Pipe Models to the Pipe and Uniform Model
applied in core network sections rather than then DSCP based PHBs. already defined for Differentiated Services and Tunnels [RFC2983] ,
Network providers make use of this feature for their own IP QoS [RFC3270]. It was required due to the presence of Pen-ultimate hop
concepts. This draft suggests to expand it to interconnections popping (PHP) of MPLS Labels. RFC3270 expects the Short Pipe model
between operators of different domains in a simple manner while each only to be deployed for IP tunnels and VPNs. If it used to transport
operator may maintain the own class and codepoint scheme within the non tunneled IP traffic, some restrictions may apply for DSCP
own domain. transparency. The Short Pipe model is popular with many network
providers operating MPLS.
The scope of this draft is limited to 4 specified interconnection RFC2474 specifies the DiffServ Codepoint Field [RFC2474].
classes having four different 3 bit code points in DSCP bits 0-2. Differentiated treatment is based on the specific DSCP. Once set, it
Using more than the 4 proposed IP precedences at interconnection may change, but any DSCP rewrite is always a one by one mapping.
could result in non-revertible IP Precedence or DSCP rewrites and What is not allowed is remarking n received DSCPs to a single
avoid sustaining end-to-end QoS classes, if a receiving provider transmitted DSCP. If unknown DSCPs are received, RFC2474 recommends
operates more than 4 MPLS TCs. Assume a provider operating 4 QoS transmitting them unchanged by default forwarding. An MPLS network
classes available at interconnection and MPLS within his backbone. supporting the Short Pipe model for not tunneled IPv4 traffic may
Further assume this carrier to support MPLS based ECN marking and need to be able to correctly classify or rewrite the IP DSCP on
assume this carrier to operate a newtork control class with an own interfaces between the last Label Switch Router and a Label Edge
MPLS TC. Two codepoints are left for future use. If 5 or more PHBs Router. In that case, it may not be possible to transmit 64 DSCPs
each with different DSCP bits 0-2 are offerd at an interconnection through this domain.
point and no more than a single MPLS label needs to be pushed, two
(or more) PHBs will carry the same DSCP bits 0-2 after re-marking to
the provider internal QoS scheme. Due to MPLS pen ultimate hop
popping, DSCPs must be re-written in this case. That may work if
bits 3-5 of the DSCP can be varied without introducing ambiguities.
Should this traffic later pass another QoS interconnection point
further downstream, the orginal sending domain may not be able to
ensure proper class mapping for the PHBs merged into a single class
by the receiving domain.
At first glance, the interconnection codepoint scheme looks like an RFC5127 proposes to transmit DSCPs as they are received in general.
additional effort. But there are some obvious benefits: each party This is not possible, if the receiving and the transmitting domain
sending or receiving traffic has to specify the mapping from or to use different DSCPs for the PHBs to which traffic is mapped if both
the interconnection class and code point scheme only once. Without interconnect.
it, this is to be negotiated per interconnection party individually.
Further, end-to-end QoS in terms of traffic being classified for the This draft adresses IP interconnection supporting DiffServ to or
same class in all passed domains is more likely to result if an between providers operating MPLS in their backbone. It proposes
interconnection code point scheme is used. It is not necessarily operational simplifications and methods to match IP DiffServ
resulting from individual per provider mapping negotiations, as can requirements with MPLS limitations (especially regarding the Short
be seen from the example given above. 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.
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).
The standards and deployments known to the author of this draft are
limited to 4 DiffServ classes at interconnection points (or less).
The example given in RFC 5127 on aggregation of DiffServ service The example given in RFC 5127 on aggregation of DiffServ service
classes picks 4 Treatment aggregates (note that this document prefers classes picks 4 Treatment Aggregates. This draft also favours 4
class instead of treatment aggregate). Reasons to favour working Treatment Aggregates. Reasons to favour working with 4 DiffServ
with 4 DiffServ interconnection classes: Treatment Aggregates:
o There should be a coding reserve for interconnection classes. o There should be a coding reserve for interconnection classes.
This leaves space for future standards, for private bilateral This leaves space for future standards, for private bilateral
agreements and for provider internal classes. agreements and for provider internal classes.
o The fields available for carrying QoS information (e.g., DiffServ o The fields available for carrying QoS information (e.g., DiffServ
PHB) in MPLS and Ethernet are only 3 bits in size, and are PHB) in MPLS and Ethernet are only 3 bits in size, and are
intended for more than just QoS purposes (see e.g. [RFC5129]). intended for more than just QoS purposes (see e.g. [RFC5129]).
o Migrations from one code point scheme to another may require spare o Migrations from one code point scheme to another may require spare
QoS code points. QoS code points.
IP Precedence has been deprecated when DiffServ was standardised. It RFC5127 provides recommendations on aggregation of IP DSCPs into MPLS
is common practice today however to copy the DSCPs Bits 0-2 (called Treatment Aggregates and offers a deployment example [RFC5127].
DSCP Precedence Prefix in the following) into MPLS TC or Ethernet RFC5127 seems to be based on an assumption the the MPLS Short Pipe
P-Bits. This is also reflected by the DiffServ codepoint definitions model is only deployed for tunneled IP products or VPNs. This draft
of AF and EF. Class based PHBs may be applied in core network assumes presence of non tunneled IPv4 traffic and deployment of the
sections rather than then DSCP based PHBs. MPLS Short Pipe model. That requires deviating from the RFC5127
example as follows:
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 (e.g., whether the traffic in a class is congestion
controlled or not) than to application requirements.
RFC5127 provides recommendations on domain internal aggregation of
DiffServ traffic and offers a deployment example [RFC5127]. This
draft differs from the RFC5127 aggregation deployment example in the
following points:
o the basic concept of this draft is to maintain classes, while o DSCP remarking is to be expected at provider edges, if the domain
expecting DSCP remarking at provider edges. is terminating this traffic.
o This draft follows RFC4594 in the proposed marking of provider o This draft follows RFC4594 in the proposed marking of provider
Network Control traffic and expands RFC4594 on treatment of CS6 Network Control traffic and expands RFC4594 on treatment of CS6
marked traffic at interconnection points (see section 5.2). marked traffic at interconnection points (see section 5.2).
The proposed Interconnection class and code point scheme tries to The proposed Interconnection class and code point scheme tries to
reflect and consolidate related DiffServ and QoS standardisation reflect and consolidate related DiffServ and QoS standardisation
efforts outside of the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and 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 ITU [Y.1566]. GSMAs IR.34 specifies an inter provider VPN, but it is
nevertheless specifying a kind of DiffServ aware IP based carrier nevertheless specifying a kind of DiffServ aware IP based carrier
skipping to change at page 5, line 33 skipping to change at page 5, line 32
BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the
scope of this draft. Should the basic transport and class properties scope of this draft. Should the basic transport and class properties
be standardised as proposed here, signaled access to QoS classes may be standardised as proposed here, signaled access to QoS classes may
be of interest. The current BGP drafts focus on exchanging SLA and be of interest. The current BGP drafts focus on exchanging SLA and
traffic conditioning parameters. They seem to assume that common traffic conditioning parameters. They seem to assume that common
interpretation of the PHB properties identified by DSCPs has been interpretation of the PHB properties identified by DSCPs has been
established prior to exchanging further details by BGP signaling. established prior to exchanging further details by BGP signaling.
2. Terminology 2. Terminology
This draft re-uses existing terminology. This draft reuses existing terminology of RFCs 2474 and 5127.
DSCP Precedence Prefix Bits 0-2 of the DSCP ("x" in this generic
DSCP: xxxddd) are called the DSCP Precedence Prefix. Section
4.2 of [RFC2474] discusses the role of these bits in enabling
use of DiffServ with network equipment that is not fully
DiffServ- compliant; this term provides a formal for these
bits that is preferable to referring to them as "the former
IP Precedence field".
DSCP Precedence Class This is a set of one or more PHBs that utilize
the same DSCP Precedence Prefix on an interconnection between
two networks.
3. Aggregating PHBs of a class by a DSCP Precedence Prefix
Configuration and operation of MPLS networks is simplified, if a DSCP
Precedence Class can be aggregated into a single PSC by classifying
them on their DSCP Precedence Prefix. The DSCP Precedence Prefix of
an interconnection DSCP Precedence Class may be rewritten at the
ingress edge router and then simply be copied into the MPLS TC field
of one or more labels to be pushed.
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 code point scheme specified below, if they interconnect
to a carrier applying DSCP Precedence Prefix based traffic
aggregation. An example where this may be applicable is the
Interactive Class of GSMA IR.34 [IR.34]). Another option is to
negotiate a customised interconnection agreement of course.
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.
RFC 2474 specifies the Class Selector Codepoints [RFC2474]. These
offer a similar concept, but they are strictly limited to xxx000
DSCPs. The Class Selector Code points 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 Code points.
4. An Interconnection class and codepoint scheme 3. An Interconnection class and codepoint scheme
Interconnecting parties face the problem of matching classes to be Interconnecting parties face the problem of matching classes to be
interconnected and then to agree on code point mapping. As stated by interconnected and then to agree on code point mapping. As stated by
the DiffServ Architecture [RFC2475], remarking is a standard the DiffServ Architecture [RFC2475], remarking is a standard
behaviour at interconnection interfaces. This draft proposes a behaviour at interconnection interfaces. If the MPLS Short Pipe
standard interconnection set of 4 DSCP precedence classes with well model is deployed by the receiving domain, the Label Switch Router
defined DSCP and DSCP Precedence Prefix values. A sending party prior to and the destination Label Edge Router may have to correctly
remarks DSCPs from internal schemes to the Interconnection code classify traffic by its DSCP. To avoid DSCPs being misused, only
points. The receiving party remarks DSCP Precedence Prefixes and / domain internal DSCPs may be tolerated there. This means, that
or DSCPs to her internal scheme. Thus the interconnection code point traffic terminating within this domain will be delivered with the
scheme fully complies with the DiffServ architecture. 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).
This draft picks up the DiffServ interconnection class defintions This draft picks up the DiffServ interconnection class defintions
proposed by ITU-T Y.1566 [Y.1566]. In addition to the classes proposed by ITU-T Y.1566 [Y.1566]. The classes defined there, are
defined there, this draft proposes a complete set of PHBs and DSCPs. used as MPLS Treatment Aggregates here. This draft proposes a set of
Like in the example given by RFC 5127 for domain internal class Treatment Aggregate PHBs and DSCPs to be aggregated. Their
aggregation, Y.1566 specifies four PHB scheduling classes (for properties differ slightly from those of the RFC5127 example:
provider interconnection however). Their properties slightly from
those of the RFC5127 example:
Class Priority: PHB EF, DSCP 101 110. The figures of merit Class Priority: PHB EF, DSCP 101 110. The figures of merit
describing the PHB to be in the range of low single digit describing the PHB to be in the range of low single digit
milliseconds. See [RFC3246]. This class corresponds to RFC milliseconds. See [RFC3246]. This class corresponds to RFC
5127's real time class, but it is limited to traffic for 5127's real time class, but it is limited to traffic for
which node configuration "ensures that the service rate of EF which node configuration "ensures that the service rate of EF
packets on a given output interface exceeds their arrival packets on a given output interface exceeds their arrival
rate at that interface over long and short time intervals" rate at that interface over long and short time intervals"
(see RFC 3246). (see RFC 3246).
Bulk inelastic: PHB AF41, DSCP 100 010 (the other AF4 PHB group 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 PHB's and DSCPs should be reserved for future extension of
this DSCP scheduling class). Optimised for low loss, low the set of DSCPs carried by this Treatment Aggregate).
delay, low jitter at high bandwidth. Traffic load in this Optimised for low loss, low delay, low jitter at high
class must be controlled, e.g. by application servers. One bandwidth. Traffic load in this class must be controlled,
example could be flow admission control. There may be e.g. by application servers. One example could be flow
infrequent retransmissions requested by the application layer admission control. There may be infrequent retransmissions
to mitigate low levels of packet losses. Discard of packets requested by the application layer to mitigate low levels of
through active queue management should be avoided in this packet losses. Discard of packets through active queue
class. Congestion in this class may result in bursty packet management should be avoided in this class. Congestion in
loss. If used to carry multimedia traffic, it is recommended this class may result in bursty packet loss. If used to
to carry audio and video traffic in a single PHB (note that carry multimedia traffic, it is recommended to carry audio
video conferencing may require separate PHBs for audio and and video traffic in a single PHB (note that video
video traffic, which could also be realised by utlising two conferencing may require separate PHBs for audio and video
AF 4 PHBs). All of these properties influence the buffer traffic, which could also be realised by utilising two AF 4
design. This class is designed to transport those parts of PHBs). All of these properties influence the buffer design.
RFC 5127's Real Time class, which consume considerable QoS This class is designed to transport those parts of RFC 5127's
bandwidth at the interconnection interface. Real Time class, which consume considerable QoS bandwidth at
the interconnection interface.
Assured: The complete PHB group AF3, DSCPs 011 010, 011 100 and 011 Assured: The complete PHB group AF3, DSCPs 011 010, 011 100 and 011
110. This class may be optimised to transport traffic 110 is transmitted by this Treatment Aggregate. It may be
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.
Default: Default PHB, CS0 with DSCP 000 000. This class may be
optimised to transport traffic without bandwidth optimised to transport traffic without bandwidth
requirements. Retransmissions after losses characterise the requirements. It aims on very low loss at high bandwidths.
class and influence the buffer design. Active queue Retransmissions after losses characterise the class and
management with probabilistic dropping may be deployed. The influence the buffer design. Active queue management with
RFC 5127 example calls this class Elastic. probabilistic dropping may be deployed. The RFC 5127 example
calls this class Assured Elastic.
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.
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.
The idea is illustrated by an example. Provider O and provider W are The idea is illustrated by an example. Provider O and provider W are
peer with provider T. They have agreed upon a QoS interconnection. peer with provider T. They have agreed upon a QoS interconnection.
Traffic of provider O terminates within provider Ts network, while Traffic of provider O terminates within provider Ts network, while
the GSMA IR.34 traffic transits through the netwirk of provider T to the GSMA IR.34 traffic transits through the netwirk of provider T to
provider F. Assume all providers to run their own internal codepoint provider F. Assume all providers to run their own internal codepoint
schemes for a class with properties of the DiffServ Intercon Assured schemes for a class with properties of the DiffServ Intercon Assured
class. See section for a description of GSMA IR.34. Treatment Aggregate. See below for a description of GSMA IR.34.
Provider-O Provider-W Provider-O Provider-W
RFC5127 GSMA 34.1 RFC5127 GSMA 34.1
| | | |
+----------+ +----------+ +----------+ +----------+
|AF21, AF22| |AF31, AF21| |AF21, AF22| |AF31, AF21|
+----------+ +----------+ +----------+ +----------+
| | | |
V V V V
+++++++++ +++++++++ +++++++++ +++++++++
skipping to change at page 8, line 36 skipping to change at page 8, line 11
|AF31, AF32| |AF31, AF32| |AF31, AF32| |AF31, AF32|
+----------+ +----------+ +----------+ +----------+
| Intercon | | Intercon |
V V V V
+++++++++ | +++++++++ |
|RtrPrTI|------------------+ |RtrPrTI|------------------+
+++++++++ +++++++++
| Provider-T domain | Provider-T domain
+-----------+ +-----------+
| MPLS TC 2 | | MPLS TC 2 |
|and rewr. | | DSCP rew. |
|DSCP pref 2| | AF21, AF22|
+-----------+ +-----------+
| | Local DSCPs Provider-T | | Local DSCPs Provider-T
| | +----------+ +++++++++ | | +----------+ +++++++++
V +->|AF21, AF22|->-|RtrDstH| V +->|AF21, AF22|->-|RtrDstH|
| +----------+ +++++++++ | +----------+ +++++++++
+----------+ +----------+
|AF21, AF22| |AF21, AF22|
+----------+ +----------+
| |
+++++++++ +++++++++
skipping to change at page 9, line 28 skipping to change at page 8, line 49
GSM IR.34 GSM IR.34
DiffServ Intercon example DiffServ Intercon example
Figure 1 Figure 1
It is easily visible that all providers only need to deploy internal It is easily visible that all providers only need to deploy internal
DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the
desired classes. desired classes.
RFC5127 specifies a separate PHB scheduling class for network control RFC5127 specifies a separate Treatment Aggregate for network control
traffic. This class may be present at interconnection interfaces traffic. It may be present at interconnection interfaces too, but
too, but depending on the agreement between providers, it may also be depending on the agreement between providers, Network Control traffic
classified for another interconnection class. See section 4.2 for a may also be classified for another interconnection class. See below
detailed discussion. for a detailed discussion on the treatment of Network Control
traffic.
The proposed class and code point scheme is designed for point to The proposed class and code point scheme is designed for point to
point IP layer interconnections. Other types of interconnections are point IP layer interconnections. Other types of interconnections are
out of scope of this document. The basic class and code point scheme out of scope of this document. The basic class and code point scheme
is applicable on Ethernet layer too. is applicable on Ethernet layer too.
4.1. Treatment of Network Control traffic at carrier interconnection 3.1. Limitations arising from the MPLS Short Pipe model
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.
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.
3.2. Treatment of Network Control traffic at carrier interconnection
interfaces interfaces
As specified by RFC4594, section 3.2, Network Control (NC) traffic As specified by RFC4594, section 3.2, Network Control (NC) traffic
marked by CS6 is to be expected at interconnection interfaces. This marked by CS6 is to be expected at interconnection interfaces. This
document does not change NC specifications of RFC4594. The latter document does not change NC specifications of RFC4594. The latter
specification is detailed on domain internal NC traffic and on specification is detailed on domain internal NC traffic and on
traffic exchanged between peering points. Further, it recommends not traffic exchanged between peering points. Further, it recommends not
to forward CS6 marked traffic originating from user-controlled end to forward CS6 marked traffic originating from user-controlled end
points by the NC class of a provider domain. points by the NC class of a provider domain.
As a minor clarification to RFC4594, "peering" shouldn't be As a minor clarification to RFC4594, "peering" shouldn't be
interpreted in a commercial sense. The NC PHB is applicable also in interpreted in a commercial sense. The NC PHB is applicable also in
the case of a purchased network service based on a transit agreement the case of a purchased network service based on a transit agreement
with an upstream provider. RFC4594 recommendations on NC traffic are with an upstream provider. RFC4594 recommendations on NC traffic are
applicable for IP carrier interconnections in general. applicable for IP carrier interconnections in general.
Some CS6 traffic exchanged accross carrier interconnections will Some CS6 traffic exchanged accross carrier interconnections will
terminate at the domain ingress node (e.g., if BGP is running between terminate at the domain ingress node (e.g., if BGP is running between
the two routers on opposite ends of the interconnection link). the two routers on opposite ends of the interconnection link).
An IP carrier may limit access to the NC PHB for traffic which is If the MPLS Short Pipe model is deployed for non tunneled IPv4
recognised as network control traffic relevant to the own domain. traffic, an IP carrier may limit access to the NC PHB for traffic
Interconnecting carriers should specify treatment of CS6 marked which is recognised as network control traffic relevant to the own
traffic received at a carrier interconnection which is to be 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 forwarded beyond the ingress node. An SLA covering the following
cases is recommended, if a carrier wishes to send CS6 marked traffic cases is recommended, if a carrier wishes to send CS6 marked traffic
accross an interconnection link which isn't terminating at the accross an interconnection link which isn't terminating at the
interconnected ingress node: interconnected ingress node:
o classification of traffic which is network control traffic for o classification of traffic which is network control traffic for
both domains. This traffic should be classified and marked for both domains. This traffic should be classified and marked for
the NC PHB. the NC PHB.
o classification of traffic which is network control traffic for the o classification of traffic which is network control traffic for the
skipping to change at page 10, line 41 skipping to change at page 10, line 36
specified by this document). As an example GSMA IR.34 proposes an specified by this document). As an example GSMA IR.34 proposes an
Interactive class / AF31 to carry SIP and DIAMETER traffic. While Interactive class / AF31 to carry SIP and DIAMETER traffic. While
this is service control traffic of high importance to the this is service control traffic of high importance to the
interconnected Mobile Network Operators, it is certainly no interconnected Mobile Network Operators, it is certainly no
Network Control traffic for a fixed network providing transit. Network Control traffic for a fixed network providing transit.
The example may not be perfect. It was picked nevertheless The example may not be perfect. It was picked nevertheless
because it refers to an existing standard. because it refers to an existing standard.
o any other CS6 marked traffic should be remarked or dropped. o any other CS6 marked traffic should be remarked or dropped.
5. DiffServ Intercon relation to other QoS standards 4. DiffServ Intercon relation to other QoS standards (revision may be
required)
This sections provides suggestions how to aggregate traffic by DSCP This sections provides suggestions how to aggregate traffic by DSCP
Precedence Prefexies to Ethernet and MPLS. Other Standardisation Precedence Prefexies to Ethernet and MPLS. Other Standardisation
Organsiations deal with QoS aware provider interconnection. As IP is Organsiations deal with QoS aware provider interconnection. As IP is
the state of the art realisation of provider interconnections, these the state of the art realisation of provider interconnections, these
standards bodies specify DiffServ aware interconnections. Some of standards bodies specify DiffServ aware interconnections. Some of
these bodies are industry alliances chartered also to promote these bodies are industry alliances chartered also to promote
interconnection of wireless or Ethernet technology including the interconnection of wireless or Ethernet technology including the
exchange of IP datagrams at interconnection points. Examples are the exchange of IP datagrams at interconnection points. Examples are the
Metro Ethernet Forum (MEF) or the GSM Alliance (GSMA). The ITU was Metro Ethernet Forum (MEF) or the GSM Alliance (GSMA). The ITU was
mentioned earlier. ITU works across and between responsibilities of mentioned earlier. ITU works across and between responsibilities of
different Standardisation Organisations and liaising with them, if different Standardisation Organisations and liaising with them, if
their responsibilities are touched, is traditional part of that their responsibilities are touched, is traditional part of that
process. process.
5.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes 4.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes
The interconnection class and code point scheme respects properties The interconnection class and code point scheme respects properties
and limits of a 3 bit PHB coding space in different ways: and limits of a 3 bit PHB coding space in different ways:
o it allows to classify four interconnection classes based on the o it allows to classify four interconnection classes based on the
DSCP Precedence Prefix. DSCP Precedence Prefix.
o it supports a single PHB group (AF3), whose DSCPs may be o it supports a single PHB group (AF3), whose DSCPs may be
aggregated into a sinle MPLS TC (or Ethernet priority) based on aggregated into a sinle MPLS TC (or Ethernet priority) based on
their joint DSCP Precedence Prefix. This kind of aggregation will their joint DSCP Precedence Prefix. This kind of aggregation will
skipping to change at page 11, line 37 skipping to change at page 11, line 33
at leaves some MPLS TC coding space for such an extension at leaves some MPLS TC coding space for such an extension
(although this draft doesn't recommend interconnections of that (although this draft doesn't recommend interconnections of that
type). type).
The above statement is no requirement to depricate any DSCP to MPLS The above statement is no requirement to depricate any DSCP to MPLS
TC or Ethernet P-Bit mapping functionality. In the opposite, by TC or Ethernet P-Bit mapping functionality. In the opposite, by
limiting the interconnection scheme to 6 PHBs, each PHB may be mapped limiting the interconnection scheme to 6 PHBs, each PHB may be mapped
to an individual Traffic Class or Priority also within MPLS or to an individual Traffic Class or Priority also within MPLS or
Ethernet (if desired). Ethernet (if desired).
5.2. Proposed GSMA IR.34 to DiffServ Intercon mapping 4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping
GSMA IR.34 provides guidelines on how to set up and interconnect GSMA IR.34 provides guidelines on how to set up and interconnect
Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. An Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. An
IPX network is an inter-Service Provider IP backbone which comprises IPX network is an inter-Service Provider IP backbone which comprises
the interconnected networks of IPX Providers. IPX is a the interconnected networks of IPX Providers. IPX is a
telecommunications interconnection model for the exchange of IP based telecommunications interconnection model for the exchange of IP based
traffic between customers of separate mobile and fixed operators as traffic between customers of separate mobile and fixed operators as
well as other types of service provider (such as ISP), via IP based well as other types of service provider (such as ISP), via IP based
network-to-network interface. Note that IPX is not a public network-to-network interface. Note that IPX is not a public
interconnection model however, it is designed as a private IP interconnection model however, it is designed as a private IP
skipping to change at page 12, line 40 skipping to change at page 12, line 35
Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon
Figure 2 Figure 2
The motivation resulting in the design of the IR.34 Intercative class 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 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 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 class. The suggested mapping is pragmatic and tries to come as close
as possible to other design criteria pursued by GSMA IR.34. as possible to other design criteria pursued by GSMA IR.34.
5.3. Proposed MEF 23.1 to DiffServ Intercon mapping 4.3. Proposed MEF 23.1 to DiffServ Intercon mapping
MEF 23.1 is an implemenation agreement facilitating Ethernet service MEF 23.1 is an implemenation agreement facilitating Ethernet service
interoperability and consistency between Operators and the use of a interoperability and consistency between Operators and the use of a
common CoS Label set for Subscribers [MEF23.1]. It pursues the same common CoS Label set for Subscribers [MEF23.1]. It pursues the same
aims and method on Ethernet layer as this draft does on IP layer aims and method on Ethernet layer as this draft does on IP layer
(i.e. providing an interconnection class and codepoint scheme). MEF (i.e. providing an interconnection class and codepoint scheme). MEF
23.1 addresses external network to network interfaces typically 23.1 addresses external network to network interfaces typically
interconnecting metro ethernet providers. This may typically involve interconnecting metro ethernet providers. This may typically involve
Ethernet Network Sections associated with typical Operator domains Ethernet Network Sections associated with typical Operator domains
that interconnect at external network to network interfaces. MEF that interconnect at external network to network interfaces. MEF
skipping to change at page 14, line 5 skipping to change at page 13, line 43
The MEF color aware mode supports Ordered Aggregates in the MEF The MEF color aware mode supports Ordered Aggregates in the MEF
classes M and L. The MEF L specification classifies AF1 and Best classes M and L. The MEF L specification classifies AF1 and Best
Effort for the same Ordered Aggregate. A Better than Best Effort Effort for the same Ordered Aggregate. A Better than Best Effort
service produced in the same queue as best effort traffic can be service produced in the same queue as best effort traffic can be
realized, but hasn't been standardized by IETF. This document realized, but hasn't been standardized by IETF. This document
doesn't suggest any mapping. Diffserv Intercon also doesn't suggest doesn't suggest any mapping. Diffserv Intercon also doesn't suggest
an Ordered Aggregate in the Bulk Inelastic class. Later versions of an Ordered Aggregate in the Bulk Inelastic class. Later versions of
this document may do so and specify a solution. Both issues are left this document may do so and specify a solution. Both issues are left
for bilateral negotiation. for bilateral negotiation.
6. Contributors 5. Contributors
David Black provided many helpful comments and inputs to this work. David Black provided many helpful comments and inputs to this work.
7. Acknowledgements 6. Acknowledgements
Al Morton and Sebastien Jobert provided feedback on many aspects Al Morton and Sebastien Jobert provided feedback on many aspects
during private discussions. Brian Carpenter, Mohamed Boucadair and during private discussions. Mohamed Boucadair and Thomas Knoll
Thomas Knoll helped adding awareness of related work. helped adding awareness of related work. David Black, Fred Baker and
Brian Carpenter provided intensive feedback and discussion.
8. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
This document does not introduce new features, it describes how to This document does not introduce new features, it describes how to
use existing ones. The security section of RFC 2475 [RFC2475] and use existing ones. The security section of RFC 2475 [RFC2475] and
RFC 4594 [RFC4594] apply. RFC 4594 [RFC4594] apply.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
skipping to change at page 15, line 22 skipping to change at page 15, line 17
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. Marking in MPLS", RFC 5129, January 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006. [min_ref] authSurName, authInitials., "Minimal Reference", 2006.
10.2. Informative References 9.2. Informative References
[I-D.knoll-idr-cos-interconnect] [I-D.knoll-idr-cos-interconnect]
Knoll, T., "BGP Class of Service Interconnection", Knoll, T., "BGP Class of Service Interconnection",
draft-knoll-idr-cos-interconnect-11 (work in progress), draft-knoll-idr-cos-interconnect-12 (work in progress),
November 2013. May 2014.
[ID.idr-sla] [ID.idr-sla]
IETF, "Inter-domain SLA Exchange", IETF, http:// IETF, "Inter-domain SLA Exchange", IETF, http://
datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/,
2013. 2013.
[IEEE802.1Q] [IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks", 2005. Networks - Virtual Bridged Local Area Networks", 2005.
[IR.34] GSMA Association, "IR.34 Inter-Service Provider IP [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP
Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/
/www.gsma.com/newsroom/wp-content/uploads/2012/03/ /www.gsma.com/newsroom/wp-content/uploads/2012/03/
ir.34.pdf, 2012. ir.34.pdf, 2012.
[MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
Class of Service Phase 2", MEF, MEF23.1 http:// Class of Service Phase 2", MEF, MEF23.1 http://
metroethernetforum.org/PDF_Documents/ metroethernetforum.org/PDF_Documents/
technical-specifications/MEF_23.1.pdf, 2012. technical-specifications/MEF_23.1.pdf, 2012.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
August 2006. August 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, February 2008. Diffserv Service Classes", RFC 5127, February 2008.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, March 2008. Service (QoS)", RFC 5160, March 2008.
skipping to change at page 16, line 30 skipping to change at page 16, line 29
01 to 02 Added some references regarding related work. Clarified 01 to 02 Added some references regarding related work. Clarified
class definitions. Further editorial improvements. class definitions. Further editorial improvements.
02 to 03 Consistent terminology. Discussion of Network Management 02 to 03 Consistent terminology. Discussion of Network Management
PHB at interconnection interfaces. Editorial review. PHB at interconnection interfaces. Editorial review.
03 to 04 Again improved terminology. Better wording of Network 03 to 04 Again improved terminology. Better wording of Network
Control PHB at interconnection interfaces. Control PHB at interconnection interfaces.
04 to 05 Large rewrite and re-ordering of contents.
05 to 06 Description of IP and MPLS related requirements and
constraints on DSCP rewrites.
Author's Address Author's Address
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt, 64295 Darmstadt, 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
 End of changes. 42 change blocks. 
204 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/