draft-ietf-tsvwg-diffserv-intercon-09.txt   draft-ietf-tsvwg-diffserv-intercon-10.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational D. Black Intended status: Informational D. Black
Expires: March 1, 2017 EMC Corporation Expires: April 13, 2017 Dell EMC
August 28, 2016 October 10, 2016
Diffserv-Interconnection classes and practice Diffserv-Interconnection classes and practice
draft-ietf-tsvwg-diffserv-intercon-09 draft-ietf-tsvwg-diffserv-intercon-10
Abstract Abstract
This document defines a limited common set of Diffserv PHBs and This document defines a limited common set of Diffserv PHBs and
codepoints (DSCPs) to be applied at (inter)connections of two codepoints (DSCPs) to be applied at (inter)connections of two
separately administered and operated networks, and explains how this separately administered and operated networks, and explains how this
approach can simplify network configuration and operation. Many approach can simplify network configuration and operation. Many
network providers operate MPLS using Treatment Aggregates for traffic network providers operate MPLS using Treatment Aggregates for traffic
marked with different Diffserv PHBs, and use MPLS for interconnection marked with different Diffserv Per Hop Behaviors, and use MPLS for
with other networks. This document offers a simple interconnection interconnection with other networks. This document offers a simple
approach that may simplify operation of Diffserv for network interconnection approach that may simplify operation of Diffserv for
interconnection among providers that use MPLS and apply the Short- network interconnection among providers that use MPLS and apply the
Pipe tunnel mode. Short-Pipe tunnel mode. While motivated by the requirements of MPLS
network operators that use Short-Pipe tunnels, this document is
applicable to other networks, both MPLS and non-MPLS.
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 March 1, 2017. This Internet-Draft will expire on April 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 18 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 6 3. Relationship to RFC5127 . . . . . . . . . . . . . . . . . . . 6
3.1. RFC 5127 Background . . . . . . . . . . . . . . . . . . . 6 3.1. RFC5127 Background . . . . . . . . . . . . . . . . . . . 6
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7 3.2. Differences from RFC5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 9 4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 10
4.2. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 12 4.2. End-to-end PHB and DSCP Transparency . . . . . . . . . . 12
4.3. Treatment of Network Control traffic at carrier 4.3. Treatment of Network Control traffic at carrier
interconnection interfaces . . . . . . . . . . . . . . . 13 interconnection interfaces . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 16 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 16
Appendix B. Change log (to be removed by the RFC editor) . . . . 20 Appendix B. Change log (to be removed by the RFC editor) . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Diffserv has been deployed in many networks; it provides Diffserv has been deployed in many networks; it provides
differentiated traffic forwarding based on the Diffserv Codepoint differentiated traffic forwarding based on the Diffserv Codepoint
(DSCP) field [RFC2474]. This document defines a set of common (DSCP) field [RFC2474]. This document defines a set of common
Diffserv QoS classes (Per Hop Behaviors, PHBs)and code points at Diffserv classes (Per Hop Behaviors, PHBs) and code points for use at
interconnection points to which and from which locally used classes interconnection points to which and from which locally used classes
and code points should be mapped. and code points should be mapped.
As described by section 2.3.4.2 of RFC 2475, remarking of packets at As described by section 2.3.4.2 of RFC2475, remarking of packets at
domain boundaries is a Diffserv feature [RFC2475]. If traffic marked domain boundaries is a Diffserv feature [RFC2475]. If traffic marked
with unknown or unexpected DSCPs is received, RFC 2474 recommends with unknown or unexpected DSCPs is received, RFC2474 recommends
forwarding that traffic with default (best effort) treatment without forwarding that traffic with default (best effort) treatment without
changing the DSCP markings to better support incremental Diffserv changing the DSCP markings to better support incremental Diffserv
deployment in existing networks as well as with routers that do not deployment in existing networks as well as with routers that do not
support Diffserv or are not configured to support it. Many networks support Diffserv or are not configured to support it. Many networks
do not follow this recommendation, and instead remark unknown or do not follow this recommendation, and instead remark unknown or
unexpected DSCPs to zero upon receipt for default (best effort) unexpected DSCPs to zero upon receipt for default (best effort)
forwarding in accordance with the guidance in RFC 2475 [RFC2475] to forwarding in accordance with the guidance in RFC2475 [RFC2475] to
ensure that appropriate DSCPs are used within a Diffserv domain. ensure that appropriate DSCPs are used within a Diffserv domain.
This draft assumes that latter approach by defining additional DSCPs This draft is based on the latter approach, and defines additional
that are known and expected at network interconnection interfaces. DSCPs that are known and expected at network interconnection
interfaces in order to reduce the amount of traffic whose DSCPs are
remarked to zero.
This document is motivated by requirements for IP network This document is motivated by requirements for IP network
interconnection with Diffserv support among providers that operate interconnection with Diffserv support among providers that operate
MPLS in their backbones, but is applicable to other technologies. MPLS in their backbones, but is also applicable to other
The operational simplifications and methods in this document help technologies. The operational simplifications and methods in this
align IP Diffserv functionality with MPLS limitations resulting from document help align IP Diffserv functionality with MPLS limitations
the widely deployed Short Pipe tunnel model for operation [RFC3270]. resulting from the widely deployed Short Pipe tunnel model for
Further, limiting Diffserv to a small number of Treatment Aggregates operation [RFC3270]. Further, limiting Diffserv to a small number of
can enable network traffic to leave a network with the DSCP value Treatment Aggregates can enable network traffic to leave a network
with which it was received, even if a different DSCP is used within with the DSCP value with which it was received, even if a different
the network, thus providing an opportunity to extend consistent QoS DSCP is used within the network, thus providing an opportunity to
treatment across network boundaries. extend consistent Diffserv treatment across network boundaries.
In isolation, use of a defined set of interconnection PHBs and DSCPs In isolation, use of a defined set of interconnection PHBs and DSCPs
may appear to be additional effort for a network operator. The may appear to be additional effort for a network operator. The
primary offsetting benefit is that mapping from or to the primary offsetting benefit is that mapping from or to the
interconnection PHBs and DSCPs is specified once for all of the interconnection PHBs and DSCPs is specified once for all of the
interconnections to other networks that can use this approach. interconnections to other networks that can use this approach.
Absent this approach, the PHBs and DSCPs have to be negotiated and Absent this approach, the PHBs and DSCPs have to be negotiated and
configured independently for each network interconnection, which has configured independently for each network interconnection, which has
poor administrative and operational scaling properties. Further, poor administrative and operational scaling properties. Further,
consistent end-to-end QoS treatment is more likely to result when an consistent end-to-end Diffserv treatment is more likely to result
interconnection code point scheme is used because traffic is remarked when an interconnection code point scheme is used because traffic is
to the same PHBs at all network interconnections. remarked to the same PHBs at all network interconnections.
The interconnection approach described in this document (referred to The interconnection approach described in this document (referred to
as Diffserv-Intercon) uses a set of PHBs and MPLS treatment as Diffserv-Intercon) uses a set of PHBs (mapped to four
aggregates along with a set of interconnection DSCPs allowing corresponding MPLS treatment aggregates) along with a set of
straightforward rewriting to domain-internal DSCPs and defined DSCP interconnection DSCPs allowing straightforward rewriting to domain-
markings for traffic forwarded to interconnected domains. The internal DSCPs and defined DSCP markings for traffic forwarded to
solution described here can be used in other contexts benefitting interconnected domains. The solution described here can be used in
from a defined interconnection QoS interface. other contexts benefitting from a defined Diffserv interconnection
interface.
The basic idea is that traffic sent with a Diffserv-Interconnect PHB The basic idea is that traffic sent with a Diffserv-Interconnect PHB
and DSCP is restored to that PHB and DSCP at each network and DSCP is restored to that PHB and DSCP at each network
interconnection, even though a different PHB and DSCP may be used by interconnection, even though a different PHB and DSCP may be used by
each network involved. The key requirement is that the network each network involved. The key requirement is that the network
ingress interconnect DSCP be restored at network egress, and a key ingress interconnect DSCP be restored at network egress, and a key
observation is that this is only feasible in general for a small observation is that this is only feasible in general for a small
number of DSCPs. Traffic sent with other DSCPs can be remarked to an number of DSCPs. Traffic sent with other DSCPs can be remarked to an
interconnect DSCP or dealt with via additional agreement(s) among the interconnect DSCP or dealt with via additional agreement(s) among the
operators of the interconnected networks; remarking in the absence of operators of the interconnected networks; use of the MPLS Short Pipe
additional agreement(s) when the MPLS Short Pipe model is used for model favors remarking unexpected DSCPs to zero in the absence of
reasons explained in this document. additional agreement(s), as explained further in this document.
In addition to the common interconnecting PHBs and DSCPs, In addition to the common interconnecting PHBs and DSCPs,
interconnecting operators need to further agree on the tunneling interconnecting operators need to further agree on the tunneling
technology used for interconnection (e.g., MPLS, if used) and control technology used for interconnection (e.g., MPLS, if used) and control
or mitigate the impacts of tunneling on reliability and MTU. or mitigate the impacts of tunneling on reliability and MTU.
1.1. Related work 1.1. Related work
In addition to the activities that triggered this work, there are In addition to the activities that triggered this work, there are
additional RFCs and Internet-drafts that may benefit from an additional RFCs and Internet-drafts that may benefit from an
interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS- interconnection PHB and DSCP scheme. RFC5160 suggests Meta-QoS-
Classes to enable deployment of standardized end to end QoS classes Classes to help enabling deployment of standardized end to end QoS
[RFC5160]. The Diffserv-Intercon class- and codepoint scheme is classes [RFC5160]. The Diffserv-Intercon class- and codepoint scheme
intended to complement that work (e.g. by enabling a defined set of is intended to complement that work (e.g. by enabling a defined set
end-to-end QoS service classes). of interconnection DSCPs and PHBs).
BGP signaling Class of Service at interconnection interfaces by BGP BGP signaling Class of Service at interconnection interfaces by BGP
[I-D.knoll-idr-cos-interconnect], [ID.ietf-idr-sla] is complementary [I-D.knoll-idr-cos-interconnect], [ID.ietf-idr-sla] is complementary
to Diffserv-Intercon. These two BGP documents focus on exchanging to Diffserv-Intercon. These two BGP documents focus on exchanging
SLA and traffic conditioning parameters and assume that common PHBs SLA and traffic conditioning parameters and assume that common PHBs
identified by the signaled DSCPs have been established (e.g., via use identified by the signaled DSCPs have been established (e.g., via use
of the Diffserv-Intercon DSCPs) prior to BGP signaling of QoS. of the Diffserv-Intercon DSCPs) prior to BGP signaling of PHB id
codes.
1.2. Applicability Statement 1.2. Applicability Statement
This document is applicable to use of Differentiated Services for This document is applicable to use of Differentiated Services for
interconnection traffic between networks, and in particular to interconnection traffic between networks, and is particularly suited
interconnection of MPLS-based networks. This document is not to interconnection of MPLS-based networks that use MPLS Short-pipe
intended for use within an individual network, where the approach tunnels. This document is also applicable to other network
specified in RFC 5127 [RFC5127] is among the possible alternatives; technologies, but it isnot intended for use within an individual
see Section 3 for further discussion. network, where the approach specified in RFC5127 [RFC5127] is among
the possible alternatives; see Section 3 for further discussion.
The Diffserv-Intercon approach described in this document simplifies The Diffserv-Intercon approach described in this document simplifies
IP based interconnection to domains operating the MPLS Short Pipe IP based interconnection to domains operating the MPLS Short Pipe
model for IP traffic, both terminating within the domain and model for IP traffic, both terminating within the domain and
transiting onward to another domain. Transiting traffic is received transiting onward to another domain. Transiting traffic is received
and sent with the same PHB and DSCP. Terminating traffic maintains and sent with the same PHB and DSCP. Terminating traffic maintains
the PHB with which it was received, however the DSCP may change. the PHB with which it was received, however the DSCP may change.
Diffserv-Intercon may also be applied to the Pipe tunneling model Diffserv-Intercon is also applicable to the Pipe tunneling model
[RFC2983], [RFC3270], but is not applicable to the Uniform tunneling [RFC2983], [RFC3270], but it is not applicable to the Uniform
model [RFC2983], [RFC3270]. tunneling model [RFC2983], [RFC3270].
The Diffserv-Intercon approach defines a set of four PHBs for support
at interconnections (or network boundaries in general).
Corresponding DSCPs for use at an interconnection interface are
added. Diffserv-intercon allows for a simple mapping of PHBs and
DSCPs to MPLS Treatment Aggregates. It is extensible and allows to
add a few more PHBs and DSCPs to the Diffserv-intercon scheme.
Coding space for private interconnection agreements or provider
internal services is left too.
1.3. Document Organization 1.3. Document Organization
This document is organized as follows: section 2 reviews the MPLS This document is organized as follows: section 2 reviews the MPLS
Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because
effective support for that model is a crucial goal of Diffserv- effective support for that model is a crucial goal of Diffserv-
Intercon. Section 3 provides background on RFC 5127's approach to Intercon. Section 3 provides background on RFC5127's approach to
traffic class aggregation within a Diffserv network domain and traffic class aggregation within a Diffserv network domain and
contrasts it with the Diffserv-Intercon approach. Section 4 contrasts it with the Diffserv-Intercon approach. Section 4
introduces Diffserv-Interconnection Treatment Aggregates, along with introduces Diffserv-Interconnection Treatment Aggregates, along with
the PHBs and DSCPs that they use, and explains how other PHBs (and the PHBs and DSCPs that they use, and explains how other PHBs (and
associated DSCPs) may be mapped to these Treatment Aggregates. associated DSCPs) may be mapped to these Treatment Aggregates.
Section 4 also discusses treatment of non-tunneled and tunneled IP Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv
traffic and MPLS VPN QoS considerations and handling of high-priority considerations and handling of high-priority Network Management
Network Management traffic is described. Appendix A describes how traffic. Appendix A describes how the MPLS Short Pipe model
the MPLS Short Pipe model (penultimate hop popping) impacts QoS and (penultimate hop popping) impacts DSCP marking for IP
DSCP marking for IP interconnections. interconnections.
2. MPLS and the Short Pipe tunnel model 2. MPLS and the Short Pipe tunnel model
The Pipe and Uniform models for Differentiated Services and Tunnels This section provides a summary of the implications of the MPLS Short
are defined in [RFC2983]. RFC 3270 adds the Short Pipe model in Pipe tunnels, and in particular their use of use of PHP (Penultimate
order to support MPLS penultimate hop popping (PHP) of Labels, Hop Popping, see RFC3270) on the Diffserv tunnel framework described
primarily for MPLS-based IP tunnels and VPNs. The Short Pipe model in RFC2983. The Pipe and Uniform models for Differentiated Services
and PHP have subsequently become popular with network providers that and Tunnels are defined in [RFC2983]. RFC3270 adds the Short Pipe
operate MPLS networks and are now widely used to transport non- model in order to support MPLS penultimate hop popping (PHP) of
tunneled IP traffic, not just traffic encapsulated in IP tunnels and Labels, primarily for MPLS-based IP tunnels and VPNs. The Short Pipe
VPNs. This has important implications for Diffserv functionality in model and PHP have subsequently become popular with network providers
MPLS networks. that operate MPLS networks and are now widely used to transport
unencapsulated IP traffic. This has important implications for
Diffserv functionality in MPLS networks.
RFC 2474's recommendation to forward traffic with unrecognized DSCPs RFC2474's recommendation to forward traffic with unrecognized DSCPs
with Default (best effort) service without rewriting the DSCP has with Default (best effort) service without rewriting the DSCP has
proven to be a poor operational practice. Network operation and proven to be a poor operational practice. Network operation and
management are simplified when there is a 1-1 match between the DSCP management are simplified when there is a 1-1 match between the DSCP
marked on the packet and the forwarding treatment (PHB) applied by marked on the packet and the forwarding treatment (PHB) applied by
network nodes. When this is done, CS0 (the all-zero DSCP) is the network nodes. When this is done, CS0 (the all-zero DSCP) is the
only DSCP used for Default forwarding of best effort traffic, and a only DSCP used for Default forwarding of best effort traffic, and a
common practice is to remark to CS0 any traffic received with common practice is to remark to CS0 any traffic received with
unrecognized or unsupported DSCPs at network edges. unrecognized or unsupported DSCPs at network edges.
MPLS networks are more subtle in this regard, as it is possible to MPLS networks are more subtle in this regard, as it is possible to
skipping to change at page 6, line 18 skipping to change at page 6, line 32
removes and discards the MPLS provider label carrying the provider's removes and discards the MPLS provider label carrying the provider's
TC field before the traffic exits the provider's network. That TC field before the traffic exits the provider's network. That
discard occurs one hop upstream of the MPLS tunnel endpoint (which is discard occurs one hop upstream of the MPLS tunnel endpoint (which is
usually at the network edge), resulting in no provider TC info being usually at the network edge), resulting in no provider TC info being
available at tunnel egress. To ensure consistent handling of traffic available at tunnel egress. To ensure consistent handling of traffic
at the tunnel egress, the DSCP field in the MPLS-encapsulated IP at the tunnel egress, the DSCP field in the MPLS-encapsulated IP
header has to contain a DSCP that is valid for the provider's header has to contain a DSCP that is valid for the provider's
network, so that IP header cannot be used to carry a different DSCP network, so that IP header cannot be used to carry a different DSCP
edge-to-edge. See Appendix A for a more detailed discussion. edge-to-edge. See Appendix A for a more detailed discussion.
3. Relationship to RFC 5127 3. Relationship to RFC5127
This document draws heavily upon RFC 5127's approach to aggregation This document draws heavily upon RFC5127's approach to aggregation of
of Diffserv traffic classes for use within a network, but there are Diffserv traffic classes for use within a network, but there are
important differences caused by characteristics of network important differences caused by characteristics of network
interconnects that differ from links within a network. interconnects that differ from links within a network.
3.1. RFC 5127 Background 3.1. RFC5127 Background
Many providers operate MPLS-based backbones that employ backbone Many providers operate MPLS-based backbones that employ backbone
traffic engineering to ensure that if a major link, switch, or router traffic engineering to ensure that if a major link, switch, or router
fails, the result will be a routed network that continues to fails, the result will be a routed network that continues to
function. Based on that foundation, [RFC5127] introduced the concept function. Based on that foundation, [RFC5127] introduced the concept
of Diffserv Treatment Aggregates, which enable traffic marked with of Diffserv Treatment Aggregates, which enable traffic marked with
multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC) multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC)
based on robust provider backbone traffic engineering. This enables based on robust provider backbone traffic engineering. This enables
differentiated forwarding behaviors within a domain in a fashion that differentiated forwarding behaviors within a domain in a fashion that
does not consume a large number of MPLS Traffic Classes. does not consume a large number of MPLS Traffic Classes.
RFC 5127 provides an example aggregation of Diffserv service classes RFC5127 provides an example aggregation of Diffserv service classes
into 4 Treatment Aggregates. A small number of aggregates are used into 4 Treatment Aggregates. A small number of aggregates are used
because: because:
o The available coding space for carrying QoS information (e.g., o The available coding space for carrying Traffic Class information
Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and (e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in
is intended for more than just QoS purposes (see e.g. [RFC5129]). size, and is intended for more than just Diffserv purposes (see
e.g. [RFC5129]).
o The common interconnection DSCPs ought not to use all 8 possible o The common interconnection DSCPs ought not to use all 8 possible
values. This leaves space for future standards, for private values. This leaves space for future standards, for private
bilateral agreements and for local use PHBs and DSCPs. bilateral agreements and for local use PHBs and DSCPs.
o Migrations from one Diffserv code point scheme to a different one o Migrations from one Diffserv code point scheme to a different one
is another possible application of otherwise unused QoS code is another possible application of otherwise unused DSCPs.
points.
3.2. Differences from RFC 5127 3.2. Differences from RFC5127
Like RFC 5127, this document also uses four traffic aggregates, but Like RFC5127, this document also uses four traffic aggregates, but
differs from RFC 5127 in some important ways: differs from RFC5127 in some important ways:
o It follows RFC 2475 in allowing the DSCPs used within a network to o It follows RFC2475 in allowing the DSCPs used within a network to
differ from those to exchange traffic with other networks (at differ from those to exchange traffic with other networks (at
network edges), but provides support to restore ingress DSCP network edges), but provides support to restore ingress DSCP
values if one of the recommended interconnect DSCPs in this draft values if one of the recommended interconnect DSCPs in this draft
is used. This results in DSCP remarking at both network ingress is used. This results in DSCP remarking at both network ingress
and network egress, and this draft assumes that such remarking at and network egress, and this draft assumes that such remarking at
network edges is possible for all interface types. network edges is possible for all interface types.
o Diffserv-Intercon suggests limiting the number of interconnection o Diffserv-Intercon suggests limiting the number of interconnection
PHBs per Treatment Aggregate to the minimum required. As further PHBs per Treatment Aggregate to the minimum required. As further
discussed below, the number of PHBs per Treatment Aggreagate is no discussed below, the number of PHBs per Treatment Aggreagate is no
skipping to change at page 7, line 44 skipping to change at page 8, line 11
In contrast, network control traffic exchanged between networks In contrast, network control traffic exchanged between networks
(e.g., BGP) usually terminates at or close to a network edge, and (e.g., BGP) usually terminates at or close to a network edge, and
is not forwarded through the network because it is not part of is not forwarded through the network because it is not part of
internal routing or OAM for the receiving network. In addition, internal routing or OAM for the receiving network. In addition,
such traffic is unlikely to be covered by standard interconnection such traffic is unlikely to be covered by standard interconnection
agreements; rather, it is more likely to be specifically agreements; rather, it is more likely to be specifically
configured (e.g., most networks impose restrictions on use of BGP configured (e.g., most networks impose restrictions on use of BGP
with other networks for obvious reasons). See Section 4.2 for with other networks for obvious reasons). See Section 4.2 for
further discussion. further discussion.
o Because RFC 5127 used a Treatment Aggregate for network control o Because RFC5127 used a Treatment Aggregate for network control
traffic, Diffserv-Intercon can instead define a fourth traffic traffic, Diffserv-Intercon can instead define a fourth traffic
aggregate to be defined for use at network interconnections aggregate to be defined for use at network interconnections
instead of the Network Control aggregate in RFC 5127. Network instead of the Network Control aggregate in RFC5127. Network
Control traffic may still be exchanged across network Control traffic may still be exchanged across network
interconnections as further discussed in Section 4.2. Diffserv- interconnections as further discussed in Section 4.2. Diffserv-
Intercon uses this fourth traffic aggregate for VoIP traffic, Intercon uses this fourth traffic aggregate for VoIP traffic,
where network-provided QoS is crucial, as even minor glitches are where network-provided service differentiation is crucial, as even
immediately apparent to the humans involved in the conversation. minor glitches are immediately apparent to the humans involved in
the conversation.
4. The Diffserv-Intercon Interconnection Classes 4. The Diffserv-Intercon Interconnection Classes
At an interconnection, the networks involved need to agree on the At an interconnection, the networks involved need to agree on the
PHBs used for interconnection and the specific DSCP for each PHB. PHBs used for interconnection and the specific DSCP for each PHB.
This document defines a set of 4 interconnection Treatment Aggregates This document defines a set of 4 interconnection Treatment Aggregates
with well-defined DSCPs to be aggregated by them. A sending party with well-defined DSCPs to be aggregated by them. A sending party
remarks DSCPs from internal schemes to the interconnection code remarks DSCPs from internal schemes to the interconnection code
points. The receiving party remarks DSCPs to their internal scheme. points. The receiving party remarks DSCPs to their internal scheme.
The interconnect SLA defines the set of DSCPs and PHBs supported The interconnect SLA defines the set of DSCPs and PHBs supported
across the two interconnected domains and the treatment of PHBs and across the two interconnected domains and the treatment of PHBs and
DSCPs that are not recognized by the receiving domain. DSCPs that are not recognized by the receiving domain.
Similar approaches that use of a small number of traffic aggregates Similar approaches that use of a small number of traffic aggregates
(including recognition of the importance of VoIP traffic) have been (including recognition of the importance of VoIP traffic) have been
taken in related standards and recommendations from outside the IETF, taken in related standards and recommendations from outside the IETF,
e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1]. e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1].
The list of the four Diffserv-Interconnect traffic aggregates The list of the four Diffserv-Interconnect traffic aggregates
follows, highlighting differences from RFC 5127 and suggesting follows, highlighting differences from RFC5127 and suggesting
mappings for all RFC 4594 traffic classes to Diffserv-Intercon mappings for all RFC4594 traffic classes to Diffserv-Intercon
Treatment Aggregates: Treatment Aggregates:
Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and PHB Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and PHB
VOICE-ADMIT, DSCP 101100, see [RFC3246],[RFC4594]and VOICE-ADMIT, DSCP 101 100, see [RFC3246],[RFC4594]and
[RFC5865]. This Treatment Aggregate corresponds to RFC 5127s [RFC5865]. This Treatment Aggregate corresponds to RFC5127s
real time Treatment Aggregate definition regarding the real time Treatment Aggregate definition regarding the
queuing (both delay and jitter should be minimized), but this queuing (both delay and jitter should be minimized), but this
aggregate is restricted to transport Telephony Service Class aggregate is restricted to transport Telephony Service Class
traffic in the sense of RFC 4594 [RFC4594]. traffic in the sense of RFC4594 [RFC4594].
Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is
designed to transport PHB AF41, DSCP 100 010 (the other AF4 designed to transport PHB AF41, DSCP 100 010 (the other AF4
PHB group PHBs and DSCPs may be used for future extension of PHB group PHBs and DSCPs may be used for future extension of
the set of DSCPs carried by this Treatment Aggregate). This the set of DSCPs carried by this Treatment Aggregate). This
Treatment Aggregate is intended for Diffserv-Intercon network Treatment Aggregate is intended for Diffserv-Intercon network
interconnection of the portions of RFC 5127's Real Time interconnection of the portions of RFC5127's Real Time
Treatment Aggregate, that consume significant bandwidth. Treatment Aggregate, that consume significant bandwidth.
This traffic is expected to consist of the RFC 4594 classes This traffic is expected to consist of the RFC4594 classes
Broadcast Video, Real-Time Interactive and Multimedia Broadcast Video, Real-Time Interactive and Multimedia
Conferencing. This treatment aggregate should be configured Conferencing. This treatment aggregate should be configured
with a rate queue (consistent with RFC 4594's recommendation with a rate queue (consistent with RFC4594's recommendation
for the transported traffic classes). By comparison to RFC for the transported traffic classes). By comparison to
5127, the number of DSCPs has been reduced to one RFC5127, the number of DSCPs has been reduced to one
(initially). The AF42 and AF43 PHBs could be added if there (initially). The AF42 and AF43 PHBs could be added if there
is a need for three-color marked Multimedia. is a need for three-color marked Multimedia.
Assured Elastic Treatment Aggregate This Treatment Aggregate Assured Elastic Treatment Aggregate This Treatment Aggregate
consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011 consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011
100). By comparison to RFC 5127, the number of DSCPs has 100). By comparison to RFC5127, the number of DSCPs has been
been reduced to two. This document suggests to transport reduced to two. This document suggests to transport
signaling marked by AF31 (e.g. as recommended by GSMA IR.34 signaling marked by AF31 (e.g. as recommended by GSMA IR.34
[IR.34]). AF33 is reserved for extension of PHBs to be [IR.34]). AF33 is reserved for extension of PHBs to be
aggregated by this TA. For Diffserv-Intercon network aggregated by this TA. For Diffserv-Intercon network
interconnection, the following RFC 4594 service classes interconnection, the following RFC4594 service classes should
should be mapped to the Assured Elastic Treatment Aggregate: be mapped to the Assured Elastic Treatment Aggregate: the
the Signaling Service Class (being marked for lowest loss Signaling Service Class (being marked for lowest loss
probability), Multimedia Streaming Service Class, the Low- probability), Multimedia Streaming Service Class, the Low-
Latency Data Service Class and the High-Throughput Data Latency Data Service Class and the High-Throughput Data
Service Class. Service Class.
Default / Elastic Treatment Aggregate: transports the default PHB, Default / Elastic Treatment Aggregate: transports the default PHB,
CS0 with DSCP 000 000. RFC 5127 example refers to this CS0 with DSCP 000 000. RFC5127 example refers to this
Treatment Aggregate as Aggregate Elastic. An important Treatment Aggregate as Aggregate Elastic. An important
difference from RFC 5127 is that any traffic with difference from RFC5127 is that any traffic with unrecognized
unrecognized or unsupported DSCPs may be remarked to this or unsupported DSCPs may be remarked to this DSCP. For
DSCP. For Diffserv-Intercon network interconnection, the RFC Diffserv-Intercon network interconnection, the RFC4594
4594 standard service class and Low-priority Data service standard service class and Low-priority Data service class
class should be mapped to this Treatment Aggregate. This should be mapped to this Treatment Aggregate. This document
document does not specify an interconnection class for RFC does not specify an interconnection class for RFC4594 Low-
4594 Low-priority data. This data may be forwarded by a priority data. This data may be forwarded by a Lower Effort
Lower Effort PHB in one domain (like the PHB proposed by PHB in one domain (like the PHB proposed by Informational
Informational [RFC3662]), but using the methods specified in [RFC3662]), but using the methods specified in this document
this document will be remarked with DSCP CS0 at a Diffserv- will be remarked with DSCP CS0 at a Diffserv-Intercon network
Intercon network interconnection. This has the effect that interconnection. This has the effect that Low-priority data
Low-priority data is treated the same as data sent using the is treated the same as data sent using the default class.
default class. (Note: In a network that implements RFC 2474, (Note: In a network that implements RFC2474, Low-priority
Low-priority traffic marked as CS1 would otherwise receive traffic marked as CS1 would otherwise receive better
better treatment than traffic using the default class.) treatment than traffic using the default class.)
RFC 2475 states that Ingress nodes must condition all inbound traffic RFC2475 states that Ingress nodes must condition all inbound traffic
to ensure that the DS codepoints are acceptable; packets found to to ensure that the DS codepoints are acceptable; packets found to
have unacceptable codepoints must either be discarded or must have have unacceptable codepoints must either be discarded or must have
their DS codepoints modified to acceptable values before being their DS codepoints modified to acceptable values before being
forwarded. For example, an ingress node receiving traffic from a forwarded. For example, an ingress node receiving traffic from a
domain with which no enhanced service agreement exists may reset the domain with which no enhanced service agreement exists may reset the
DS codepoint to CS0. As a consequence, an interconnect SLA needs to DS codepoint to CS0. As a consequence, an interconnect SLA needs to
specify not only the treatment of traffic that arrives with a specify not only the treatment of traffic that arrives with a
supported interconnect DSCP, but also the treatment of traffic that supported interconnect DSCP, but also the treatment of traffic that
arrives with unsupported or unexpected DSCPs; remarking to CS0 is a arrives with unsupported or unexpected DSCPs; remarking to CS0 is a
widely deployed behavior. widely deployed behavior.
4.1. Diffserv-Intercon Example 4.1. Diffserv-Intercon Example
The overall approach to DSCP marking at network interconnections is The overall approach to DSCP marking at network interconnections is
illustrated by the following example. Provider O and provider W are illustrated by the following example. Provider O and provider W are
peered with provider T. They have agreed upon a QoS interconnection peered with provider T. They have agreed upon a Diffserv
SLA. interconnection SLA.
Traffic of provider O terminates within provider T's network, while Traffic of provider O terminates within provider T's network, while
provider W's traffic transits through the network of provider T to provider W's traffic transits through the network of provider T to
provider F. This example assumes that all providers use their own provider F. This example assumes that all providers use their own
internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in
the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and
CS2 are used in the example). CS2 are used in the example).
Provider O Provider W Provider O Provider W
| | | |
skipping to change at page 12, line 32 skipping to change at page 12, line 32
packet's DSCP to be remarked to AF31. The peering router of domain F packet's DSCP to be remarked to AF31. The peering router of domain F
classifies the packet for domain-F-internal PHB AF11, as this is the classifies the packet for domain-F-internal PHB AF11, as this is the
PHB with properties matching Diffserv-Intercon's Assured Elastic PHB with properties matching Diffserv-Intercon's Assured Elastic
Treatment Aggregate. Treatment Aggregate.
This example can be extended. The figure shows Provider-W using CS2 This example can be extended. The figure shows Provider-W using CS2
for traffic that corresponds to Diffserv-Intercon Assured Elastic for traffic that corresponds to Diffserv-Intercon Assured Elastic
Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the
Diffserv-Intercon interconnection to Provider-T. In addition, Diffserv-Intercon interconnection to Provider-T. In addition,
suppose that Provider-O supports a PHB marked by AF22 and this PHB is suppose that Provider-O supports a PHB marked by AF22 and this PHB is
supposed to be transported by QoS within Provider-T domain. Then supposed to obtain Diffserv transport within Provider-T domain. Then
Provider-O will remark it with DSCP AF32 for interconnection to Provider-O will remark it with DSCP AF32 for interconnection to
Provider-T. Provider-T.
Finally suppose that Provider-W supports CS3 for internal use only. Finally suppose that Provider-W supports CS3 for internal use only.
Then no Diffserv- Intercon DSCP mapping needs to be configured at the Then no Diffserv- Intercon DSCP mapping needs to be configured at the
peering router. Traffic, sent by Provider-W to Provider-T marked by peering router. Traffic, sent by Provider-W to Provider-T marked by
CS3 due to a misconfiguration may be remarked to CS0 by Provider-T. CS3 due to a misconfiguration may be remarked to CS0 by Provider-T.
4.2. End-to-end QoS: PHB and DS CodePoint Transparency 4.2. End-to-end PHB and DSCP Transparency
This section briefly discusses end-to-end QoS approaches related to This section briefly discusses end-to-end Diffserv approaches related
the Uniform, Pipe and Short Pipe tunnel models ([RFC2983], to the Uniform, Pipe and Short Pipe tunnel models ([RFC2983],
[RFC3270]), when used edge-to-edge in a network. [RFC3270]), when used edge-to-edge in a network.
o With the Uniform model, neither the DCSP nor the PHB change. This o With the Uniform model, neither the DCSP nor the PHB change. This
implies that a network management packet received with a CS6 DSCP implies that a network management packet received with a CS6 DSCP
would be forwarded with an MPLS Traffic Class corresponding to would be forwarded with an MPLS Traffic Class corresponding to
CS6. The uniform model is outside the scope of this document. CS6. The uniform model is outside the scope of this document.
o With the Pipe model, the inner tunnel DCSP remains unchanged, but o With the Pipe model, the inner tunnel DCSP remains unchanged, but
an outer tunnel DSCP and the PHB could changed. For example a an outer tunnel DSCP and the PHB could changed. For example a
packet received with a (network specific) CS1 DSCP would be packet received with a (network specific) CS1 DSCP would be
transported by default PHB and if MPLS is applicable, forwarded transported by default PHB and if MPLS is applicable, forwarded
with an MPLS Traffic Class corresponding to Default PHB. The CS1 with an MPLS Traffic Class corresponding to Default PHB. The CS1
DSCP is not rewritten. Transport of a large variety (much greater DSCP is not rewritten. Transport of a large variety (much greater
than 4) DSCPs may be required across an interconnected network than 4) DSCPs may be required across an interconnected network
operating MPLS Short pipe transport for IP traffic. In that case, operating MPLS Short pipe transport for IP traffic. In that case,
a tunnel based on the Pipe model is among the possible approaches. a tunnel based on the Pipe model is among the possible approaches.
The Pipe model is outside the scope of this document. The Pipe model is outside the scope of this document.
o With the Short Pipe model, the DCSP likely changes and the PHB o With the Short Pipe model, the DCSP likely changes and the PHB
might change. This document describes a method to simplify QoS might change. This document describes a method to simplify
for network interconnection when a DSCP rewrite can't be avoided. Diffserv network interconnection when a DSCP rewrite can't be
avoided.
4.3. Treatment of Network Control traffic at carrier interconnection 4.3. Treatment of Network Control traffic at carrier interconnection
interfaces interfaces
As specified by RFC 4594, section 3.2, Network Control (NC) traffic As specified by RFC4594, section 3.2, Network Control (NC) traffic
marked by CS6 is expected at some interconnection interfaces. This marked by CS6 is expected at some interconnection interfaces. This
document does not change RFC 4594, but observes that network control document does not change RFC4594, but observes that network control
traffic received at network ingress is generally different from traffic received at network ingress is generally different from
network control traffic within a network that is the primary use of network control traffic within a network that is the primary use of
CS6 envisioned by RFC 4594. A specific example is that some CS6 CS6 envisioned by RFC4594. A specific example is that some CS6
traffic exchanged across carrier interconnections is terminated at traffic exchanged across carrier interconnections is terminated at
the network ingress node, e.g. when BGP is used between the two the network ingress node, e.g. when BGP is used between the two
routers on opposite ends of an interconnection link; in this case the routers on opposite ends of an interconnection link; in this case the
operators would enter into a bilateral agreement to use CS6 for that operators would enter into a bilateral agreement to use CS6 for that
BGP traffic. BGP traffic.
The end-to-end QoS discussion in the previous section (4.2) is The end-to-end discussion in the previous section (4.2) is generally
generally inapplicable to network control traffic - network control inapplicable to network control traffic - network control traffic is
traffic is generally intended to control a network, not be generally intended to control a network, not be transported between
transported between networks. One exception is that network control networks. One exception is that network control traffic makes sense
traffic makes sense for a purchased transit agreement, and for a purchased transit agreement, and preservation of the CS6 DSCP
preservation of the CS6 DSCP marking for network control traffic that marking for network control traffic that is transited is reasonable
is transited is reasonable in some cases, although it is generally in some cases, although it is generally inappropriate to use CS6 for
inappropriate to use CS6 for forwarding that traffic within the forwarding that traffic within the network that provides transit.
network that provides transit. Use of an IP tunnel is suggested in Use of an IP tunnel is suggested in order to conceal the CS6 markings
order to conceal the CS6 markings on transiting network control on transiting network control traffic from the network that provides
traffic from the network that provides the transit. In this case, the transit. In this case, Pipe model for Diffserv tunneling is
Pipe model for Diffserv tunneling is used. used.
If the MPLS Short Pipe model is deployed for non-tunneled IPv4 If the MPLS Short Pipe model is deployed for unencapsulated IPv4
traffic, an IP network provider should limit access to the CS6 and traffic, an IP network provider should limit access to the CS6 and
CS7 DSCPs so that they are only used for network control traffic for CS7 DSCPs so that they are only used for network control traffic for
the provider's own network. the provider's own network.
Interconnecting carriers should specify treatment of CS6 marked Interconnecting carriers should specify treatment of CS6 marked
traffic received at a carrier interconnection which is to be 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 when a provider wishes to send CS6 marked cases is recommended when a provider wishes to send CS6 marked
traffic across an interconnection link and that traffic's destination traffic across an interconnection link and that traffic's destination
is beyond the interconnected ingress node: is beyond the interconnected ingress node:
skipping to change at page 14, line 36 skipping to change at page 14, line 36
o any other CS6 marked traffic should be remarked or dropped. o any other CS6 marked traffic should be remarked or dropped.
5. Acknowledgements 5. Acknowledgements
Bob Briscoe and Gorry Fairhurst reviewed the draft and provided rich Bob Briscoe and Gorry Fairhurst reviewed the draft and provided rich
feedback. Fred Baker, Brian Carpenter, Al Morton and Sebastien feedback. Fred Baker, Brian Carpenter, Al Morton and Sebastien
Jobert discussed the draft and helped improving it. Mohamed Jobert discussed the draft and helped improving it. Mohamed
Boucadair and Thomas Knoll helped adding awareness of related work. Boucadair and Thomas Knoll helped adding awareness of related work.
James Polk's discussion during IETF 89 helped to improve the text on James Polk's discussion during IETF 89 helped to improve the text on
the relation of this draft to RFC 4594 and RFC 5127. the relation of this draft to RFC4594 and RFC5127.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
DSCP marks expose additional traffic classification information is at
network interconnections by comparison to DSCP remarking to zero - if
that traffic classification info is sensitive, remarking DSCPs to
zero to hide the classification is the countermeasure, at the cost of
loss of Diffserv info and differentiated traffic handling on the
interconnect.
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 Diffserv security considerations in RFC 2475 use existing ones. The Diffserv security considerations in RFC2475
[RFC2475] and RFC 4594 [RFC4594] apply. [RFC2475] and RFC4594 [RFC4594] apply.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
skipping to change at page 16, line 46 skipping to change at page 16, line 51
2008, <http://www.rfc-editor.org/info/rfc5160>. 2008, <http://www.rfc-editor.org/info/rfc5160>.
[Y.1566] ITU-T, "Quality of service mapping and interconnection [Y.1566] ITU-T, "Quality of service mapping and interconnection
between Ethernet, IP and multiprotocol label switching between Ethernet, IP and multiprotocol label switching
networks", ITU, networks", ITU,
http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012.
Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic
The MPLS Short Pipe Model (or penultimate Hop Label Popping) is The MPLS Short Pipe Model (or penultimate Hop Label Popping) is
widely deployed in carrier networks. If non-tunneled IPv4 traffic is widely deployed in carrier networks. If unencapsulated IP traffic is
transported using MPLS Short Pipe, IP headers appear inside the last transported using MPLS Short Pipe, IP headers appear inside the last
section of the MPLS domain. This impacts the number of PHBs and section of the MPLS domain. This impacts the number of PHBs and
DSCPs that a network provider can reasonably support. See Figure 2 DSCPs that a network provider can reasonably support. See Figure 2
(below) for an example. (below) for an example.
For tunneled IPv4 traffic, only the outer tunnel header is relevant For encapsulated IP traffic, only the outer tunnel header is relevant
for forwarding. If the tunnel does not terminate within the MPLS for forwarding. If the tunnel does not terminate within the MPLS
network section, only the outer tunnel DSCP is involved, as the inner network section, only the outer tunnel DSCP is involved, as the inner
DSCP does not affect forwarding behavior; in this case all DSCPs DSCP does not affect forwarding behavior; in this case all DSCPs
could be used in the inner IP header without affecting network could be used in the inner IP header without affecting network
behavior based on the outer MPLS header. Here the Pipe model behavior based on the outer MPLS header. Here the Pipe model
applies. applies.
Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in
all use an additional MPLS label; in this case, the MPLS tunnel this case, the MPLS tunnel follows the Pipe model. Classification
follows the Pipe model. Classification and queuing within an MPLS and queuing within an MPLS network is always based on an MPLS label,
network is always based on an MPLS label, as opposed to the outer IP as opposed to the outer IP header.
header.
Carriers often select QoS PHBs and DSCP without regard to Carriers often select PHBs and DSCP without regard to
interconnection. As a result PHBs and DSCPs typically differ between interconnection. As a result PHBs and DSCPs typically differ between
network carriers. With the exception of best effort traffic, a DSCP network carriers. With the exception of best effort traffic, a DSCP
change should be expected at an interconnection at least for non- change should be expected at an interconnection at least for
tunneled IP traffic, even if the PHB is suitably mapped by the unencapsulated IP traffic, even if the PHB is suitably mapped by the
carriers involved. carriers involved.
Although RFC 3270 suggests that the Short Pipe Model is only Although RFC3270 suggests that the Short Pipe Model is only
applicable to VPNs, current networks also use it to transport non- applicable to VPNs, current networks also use it to transport non-
tunneled IPv4 traffic. This is shown in figure 2 where Diffserv- tunneled IPv4 traffic. This is shown in figure 2 where Diffserv-
Intercon is not used, resulting in exposure of the internal DSCPs of Intercon is not used, resulting in exposure of the internal DSCPs of
the upstream network to the downstream network across the the upstream network to the downstream network across the
interconnection. interconnection.
| |
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
skipping to change at page 18, line 22 skipping to change at page 18, line 22
V V
| |
MPLS Edge Router MPLS Edge Router
| Mark MPLS Label, TC_internal | Mark MPLS Label, TC_internal
\|/ Remark DSCP to \|/ Remark DSCP to
V (Inner: IPv4, DSCP_d) V (Inner: IPv4, DSCP_d)
| |
MPLS Core Router (penultimate hop label popping) MPLS Core Router (penultimate hop label popping)
| \ | \
| IPv4, DSCP_d | The DSCP needs to be in network- | IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal QoS context. The Core | ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce \|/ > Router may require or enforce
V | that. The Edge Router may wrongly V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in | | classify, if the DSCP is not in
| / network-internal Diffserv context. | / network-internal Diffserv context.
MPLS Edge Router MPLS Edge Router
| \ Traffic leaves the network marked | \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal \|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with V > DSCP_d that must be dealt with
| | by the next network (downstream). | | by the next network (downstream).
| / | /
skipping to change at page 18, line 47 skipping to change at page 18, line 47
| |
Short-Pipe / penultimate hop popping example Short-Pipe / penultimate hop popping example
Figure 2 Figure 2
The packets IP DSCP must be in a well understood Diffserv context for The packets IP DSCP must be in a well understood Diffserv context for
schedulers and classifiers on the interfaces of the ultimate MPLS schedulers and classifiers on the interfaces of the ultimate MPLS
link (last link traversed before leaving the network). The necessary link (last link traversed before leaving the network). The necessary
Diffserv context is network-internal and a network operating in this Diffserv context is network-internal and a network operating in this
mode enforces DSCP usage in order to obtain robust QoS behavior. mode enforces DSCP usage in order to obtain robust differentiated
forwarding behavior.
Without Diffserv-Intercon treatment, the traffic is likely to leave Without Diffserv-Intercon treatment, the traffic is likely to leave
each network marked with network-internal DSCP. DSCP_send in the each network marked with network-internal DSCP. DSCP_send in the
figure above has to be remarked into the first network's Diffserv figure above has to be remarked into the first network's Diffserv
scheme at the ingress MPLS Edge Router, to DSCP_d in the example. scheme at the ingress MPLS Edge Router, to DSCP_d in the example.
For that reason, the traffic leaves this domain marked by the For that reason, the traffic leaves this domain marked by the
network-internal DSCP_d. This structure requires that every carrier network-internal DSCP_d. This structure requires that every carrier
deploys per-peer PHB and DSCP mapping schemes. deploys per-peer PHB and DSCP mapping schemes.
If Diffserv-Intercon is applied DSCPs for traffic transiting the If Diffserv-Intercon is applied DSCPs for traffic transiting the
skipping to change at page 20, line 49 skipping to change at page 20, line 49
V IPv4, DSCP_send V IPv4, DSCP_d V IPv4, DSCP_send V IPv4, DSCP_d
| | | |
Short-Pipe example with Diffserv-Intercon Short-Pipe example with Diffserv-Intercon
Figure 3 Figure 3
Appendix B. Change log (to be removed by the RFC editor) Appendix B. Change log (to be removed by the RFC editor)
00 to 01 Added an Applicability Statement. Put the main part of the 00 to 01 Added an Applicability Statement. Put the main part of the
RFC 5127 related discussion into a separate chapter. RFC5127 related discussion into a separate chapter.
01 to 02 More emphasis on the Short-Pipe tunel model as compared to 01 to 02 More emphasis on the Short-Pipe tunel model as compared to
Pipe and Uniform tunnel models. Further editorial Pipe and Uniform tunnel models. Further editorial
improvements. improvements.
02 to 03 Suggestions how to remark all RFC 4594 classes to Diffserv- 02 to 03 Suggestions how to remark all RFC4594 classes to Diffserv-
Intercon classes at interconnection. Intercon classes at interconnection.
03 to 04 Minor clarifications and editorial review, preparation for 03 to 04 Minor clarifications and editorial review, preparation for
WGLC. WGLC.
Authors' Addresses Authors' Addresses
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
David L. Black David L. Black
EMC Corporation Dell EMC
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
USA USA
Phone: +1 (508) 293-7953 Phone: +1 (508) 293-7953
Email: david.black@emc.com Email: david.black@dell.com
 End of changes. 73 change blocks. 
165 lines changed or deleted 193 lines changed or added

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