| TSVWG | R. Geib, Ed. |
| Internet-Draft | Deutsche Telekom |
| Intended status: Informational | July 4, 2014 |
| Expires: January 5, 2015 |
DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-06
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 feature [RFC2475]. 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.
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 classes(SLAs) [RFC5127]. 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 Differentiated Services and Tunnels [RFC2983] , [RFC3270]. 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.
RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. 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.
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.
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.
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 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:
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:
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.
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 classes [RFC5160]. 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 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] 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.
This draft reuses existing terminology of RFCs 2474 and 5127.
Interconnecting parties face the problem of matching classes to be interconnected and then to agree on code point mapping. As stated by the DiffServ Architecture [RFC2475], 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).
This draft picks up the DiffServ interconnection class defintions proposed by ITU-T Y.1566 [Y.1566]. 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:
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 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.
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
DiffServ Intercon example
Figure 1
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.
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.
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.
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.
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.
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.
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).
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:
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.
The interconnection class and code point scheme respects properties and limits of a 3 bit PHB coding space in different ways:
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).
GSMA IR.34 provides guidelines on how to set up and interconnect Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. 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.
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.
| 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 | +---------------+-------+--------------+--------+
Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon
Figure 2
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.
MEF 23.1 is an implemenation agreement facilitating Ethernet service interoperability and consistency between Operators and the use of a 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 (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.
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):
| MEF 23.1 | DiffServ-Intercon | | | | | Agg. Class | PHB | Agg. Class | PHB | +---------------+-------+--------------+--------+ | High | EF | Priority | EF | +---------------+-------+--------------+--------+ | Medium | AF3 |Bulk inelastic| AF41 | +---------------+-------+--------------+--------+ | Low | CS1 | Default | CS0 | +---------------+-------+--------------+--------+
Suggested mapping of MEF 23.1 color blind mode classes and PHBs to DiffServ Intercon
Figure 3
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.
David Black provided many helpful comments and inputs to this work.
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.
This memo includes no request to IANA.
This document does not introduce new features, it describes how to use existing ones. The security section of RFC 2475 [RFC2475] and RFC 4594 [RFC4594] apply.