< draft-ietf-tsvwg-diffserv-intercon-02.txt   draft-ietf-tsvwg-diffserv-intercon-03.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: January 2, 2016 EMC Corporation Expires: April 18, 2016 EMC Corporation
July 1, 2015 October 16, 2015
Diffserv interconnection classes and practice Diffserv interconnection classes and practice
draft-ietf-tsvwg-diffserv-intercon-02 draft-ietf-tsvwg-diffserv-intercon-03
Abstract Abstract
This document proposes a limited set of DiffServ PHBs and codepoints This document proposes a limited set of Diffserv PHBs and codepoints
to be applied at (inter)connections of two separately administered to be applied at (inter)connections of two separately administered
and operated networks. Many network providers operate MPLS using and operated networks. Many network providers operate MPLS using
Treatment Aggregates for traffic marked with different DiffServ PHBs, Treatment Aggregates for traffic marked with different Diffserv PHBs,
and use MPLS for interconnection with other networks. This document and use MPLS for interconnection with other networks. This document
offers a simple interconnection approach that may simplify operation offers a simple interconnection approach that may simplify operation
of DiffServ for network interconnection among providers that use MPLS of Diffserv for network interconnection among providers that use MPLS
and apply the Short-Pipe tunnel mode. and apply the Short-Pipe tunnel mode.
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 January 2, 2016. This Internet-Draft will expire on April 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4
2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 4 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 4
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 6 3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 6
3.1. RFC 5127 Background . . . . . . . . . . . . . . . . . . . 6 3.1. RFC 5127 Background . . . . . . . . . . . . . . . . . . . 6
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 6 3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 6
4. The DiffServ-Intercon Interconnection Classes . . . . . . . . 7 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 7
4.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 12 4.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 12
4.2. Treatment of Network Control traffic at carrier 4.2. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 17 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 17
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 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. 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.
RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. RFC2474 specifies the Diffserv Codepoint Field [RFC2474].
Differentiated treatment is based on the specific DSCP. Once set, it Differentiated treatment is based on the specific DSCP. Once set, it
may change. If traffic marked with unknown or unexpected DSCPs is may change. If traffic marked with unknown or unexpected DSCPs is
received, RFC2474 recommends forwarding that traffic with default received, RFC2474 recommends forwarding that traffic with default
(best effort) treatment without changing the DSCP markings. Many (best effort) treatment without changing the DSCP markings. Many
networks do not follow this recommendation, and instead remark networks do not follow this recommendation, and instead remark
unknown or unexpected DSCPs to the zero DSCP upon receipt for unknown or unexpected DSCPs to the zero DSCP upon receipt for
consistency with default (best effort) forwarding in accordance with consistency with default (best effort) forwarding in accordance with
the guidance in RFC 2475 [RFC2474] to ensure that appropriate DSCPs the guidance in RFC 2475 [RFC2474] to ensure that appropriate DSCPs
are used within a DiffServ domain. Network providers applying the are used within a Diffserv domain. Network providers applying the
MPLS Short Pipe model are likely to remark unexpected DSCPs. MPLS Short Pipe model are likely to remark unexpected DSCPs.
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 applicable to other technologies.
The operational simplifications and methods in this document help The operational simplifications and methods in this document help
align IP DiffServ functionality with MPLS limitations resulting align IP Diffserv functionality with MPLS limitations resulting
especially from the Short Pipe model of operation [RFC3270]. The especially from the Short Pipe model of operation [RFC3270]. The
latter is widely deployed. Further, limiting DiffServ to a small latter is widely deployed. Further, limiting Diffserv to a small
number of Treatment Aggregates can enable network traffic to leave a number of Treatment Aggregates can enable network traffic to leave a
network with the same DSCPs that it was received with, even if a network with the same DSCPs that it was received with, even if a
different DSCP is used within the network, thus providing an different DSCP is used within the network, thus providing an
opportunity to extend consistent QoS treatment across network opportunity to extend consistent QoS treatment across network
boundaries. boundaries.
In isolation, use of standard interconnection PHBs and DSCPs may In isolation, use of standard interconnection PHBs and DSCPs may
appear to be additional effort for a network operator. The primary appear to be additional effort for a network operator. The primary
offsetting benefit is that the mapping from or to the interconnection offsetting benefit is that the mapping from or to the interconnection
PHBs and DSCPs is specified once for all of the interconnections to PHBs and DSCPs is specified once for all of the interconnections to
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 to transport plain IP traffic terminating within or transiting model to transport plain IP traffic terminating within or transiting
through the receiving domain. Transit traffic is received and sent through the receiving domain. Transit traffic is received and sent
with the same PHB and DSCP. Terminating traffic maintains the PHB with the same PHB and DSCP. Terminating traffic maintains the PHB
with which it was received, however the DSCP may change. with which it was received, however the DSCP may change.
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]; effective Short Pipe tunnel model for Diffserv Tunnels [RFC3270]; effective
support for that model is a crucial goal of this document. Section 3 support for that model is a crucial goal of this document. Section 3
provides background on RFC 5127's approach to traffic class provides background on RFC 5127's approach to traffic class
aggregation within a DiffServ network domain and explains why this aggregation within a Diffserv network domain and explains why this
document uses a somewhat different approach. Section 4 introduces document uses a somewhat different approach. Section 4 introduces
DiffServ interconnection Treatment Aggregates, plus the PHBs and Diffserv interconnection Treatment Aggregates, plus the PHBs and
DSCPs that are mapped to these Treatment Aggregates. Further, DSCPs that are mapped to these Treatment Aggregates. Further,
section 4 discusses treatment of non-tunneled and tunneled IP traffic section 4 discusses treatment of non-tunneled and tunneled IP traffic
and MPLS VPN QoS aspects. Finally Network Management PHB treatment and MPLS VPN QoS aspects. Finally Network Management PHB treatment
is described. Appendix A describes the impact of the MPLS Short Pipe is described. Appendix A describes the impact of the MPLS Short Pipe
model (penultimate hop popping) on QoS for related IP model (penultimate hop popping) on QoS for related 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 The Pipe and Uniform models for Differentiated Services and Tunnels
are defined in [RFC2983]. RFC3270 adds the MPLS Short Pipe model in are defined in [RFC2983]. RFC3270 adds the MPLS Short Pipe model in
order to support penultimate hop popping (PHP) of MPLS Labels, order to support penultimate hop popping (PHP) of MPLS Labels,
primarily for IP tunnels and VPNs. The Short Pipe model and PHP have primarily for IP tunnels and VPNs. The Short Pipe model and PHP have
become popular with many network providers that operate MPLS networks become popular with many network providers that operate MPLS networks
and are now widely used to transport non-tunneled IP traffic, not and are now widely used to transport non-tunneled IP traffic, not
just traffic encapsulated in IP tunnels and VPNs. This has important just traffic encapsulated in IP tunnels and VPNs. This has important
implications for DiffServ functionality in MPLS networks. implications for Diffserv functionality in MPLS networks.
RFC 2474's recommendation to forward traffic with unrecognized DSCPs RFC 2474'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, so a only DSCP used for Default forwarding of best effort traffic, so a
common practice is to use CS0 to remark traffic received with common practice is to use CS0 to remark traffic received with
unrecognized or unsupported DSCPs at network edges. unrecognized or unsupported DSCPs at network edges.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
TC field. That discard occurs one hop upstream of the MPLS tunnel TC field. That discard occurs one hop upstream of the MPLS tunnel
endpoint (which is usually at the network edge), resulting in no endpoint (which is usually at the network edge), resulting in no
provider TC info being available at tunnel egress. To ensure provider TC info being available at tunnel egress. To ensure
consistent handling of traffic at the tunnel egress, the DSCP field consistent handling of traffic at the tunnel egress, the DSCP field
in the MPLS-encapsulated IP header has to contain a DSCP that is in the MPLS-encapsulated IP header has to contain a DSCP that is
valid for the provider's network; propagating another DSCP edge-to- valid for the provider's network; propagating another DSCP edge-to-
edge requires an IP or MPLS tunnel of some form. See Appendix A for edge requires an IP or MPLS tunnel of some form. See Appendix A for
a more detailed discussion. a more detailed discussion.
If transport of a large number (much greater than 4) DSCPs is If transport of a large number (much greater than 4) DSCPs is
required across a network that supports this DiffServ interconnection required across a network that supports this Diffserv interconnection
scheme, a tunnel or VPN can be provisioned for this purpose, so that scheme, a tunnel or VPN can be provisioned for this purpose, so that
the inner IP header carries the DSCP that is to be preserved not to the inner IP header carries the DSCP that is to be preserved not to
be changed. From a network operations perspective, the customer be changed. From a network operations perspective, the customer
equipment (CE) is the preferred location for tunnel termination, equipment (CE) is the preferred location for tunnel termination,
although a receiving domains Provider Edge router is another viable although a receiving domains Provider Edge router is another viable
option. option.
3. Relationship to RFC 5127 3. Relationship to RFC 5127
This document draws heavily upon RFC 5127's approach to aggregation This document draws heavily upon RFC 5127's approach to aggregation
of DiffServ traffic classes for use within a network, but there are of Diffserv traffic classes for use within a network, but there are
some important differences caused by the characteristics of network some important differences caused by the characteristics of network
interconnects. interconnects.
3.1. RFC 5127 Background 3.1. RFC 5127 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 meet its fails, the result will be a routed network that continues to meet its
Service Level Agreements (SLAs). Based on that foundation, [RFC5127] Service Level Agreements (SLAs). Based on that foundation, [RFC5127]
introduced the concept of DiffServ Treatment Aggregates, which enable introduced the concept of Diffserv Treatment Aggregates, which enable
traffic marked with multiple DSCPs to be forwarded in a single MPLS traffic marked with multiple DSCPs to be forwarded in a single MPLS
Traffic Class (TC) based on robust provider backbone traffic Traffic Class (TC) based on robust provider backbone traffic
engineering. This enables differentiated forwarding behaviors within engineering. This enables differentiated forwarding behaviors within
a domain in a fashion that does not consume a large number of MPLS a domain in a fashion that does not consume a large number of MPLS
Traffic Classes. Traffic Classes.
RFC 5127 provides an example aggregation of DiffServ service classes RFC 5127 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 QoS information (e.g.,
DiffServ PHB) in MPLS (and Ethernet) is only 3 bits in size, and Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and
is intended for more than just QoS purposes (see e.g. [RFC5129]). is intended for more than just QoS purposes (see e.g. [RFC5129]).
o There should be unused codes for interconnection purposes. This o There should be unused codes for interconnection purposes. This
leaves space for future standards, for private bilateral leaves space for future standards, for private bilateral
agreements and for local use PHBs and DSCPs. agreements and for local use PHBs and DSCPs.
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.
RFC 5127 also follows RFC 2474 in recommending transmission of DSCPs RFC 5127 also follows RFC 2474 in recommending transmission of DSCPs
skipping to change at page 7, line 27 skipping to change at page 7, line 27
agreements; it is more likely to be specifically configured (e.g., agreements; it is more likely to be specifically configured (e.g.,
most networks impose on exchange of BGP for obvious reasons). See most networks impose on exchange of BGP for obvious reasons). See
Section 4.2 for further discussion. Section 4.2 for further discussion.
o Because network control traffic is treated as a special case, a o Because network control traffic is treated as a special case, a
fourth traffic aggregate is defined for use at network fourth traffic aggregate is defined for use at network
interconnections to replace the Network Control aggregate in RFC interconnections to replace the Network Control aggregate in RFC
5127. Network Control traffic may still be exchanged across 5127. Network Control traffic may still be exchanged across
network interconnections as further discussed in Section 4.2 network interconnections as further discussed in Section 4.2
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 may involve remarking for the interconnection; such remarking is This may involve remarking for the interconnection; such remarking is
part of the DiffServ Architecture [RFC2475], at least for the network part of the Diffserv Architecture [RFC2475], at least for the network
edge nodes involved in interconnection. This draft proposes a edge nodes involved in interconnection. This draft proposes a
standard interconnection set of 4 Treatment Aggregates with well- standard interconnection set of 4 Treatment Aggregates with well-
defined DSCPs to be aggregated by them. A sending party remarks defined DSCPs to be aggregated by them. A sending party remarks
DSCPs from internal schemes to the interconnection code points. The DSCPs from internal schemes to the interconnection code points. The
receiving party remarks DSCPs to her internal scheme. The set of receiving party remarks DSCPs to her internal scheme. The set of
DSCPs and PHBs supported across the two interconnected domains and DSCPs and PHBs supported across the two interconnected domains and
the treatment of PHBs and DSCPs not recognized by the receiving the treatment of PHBs and DSCPs not recognized by the receiving
domain should be part of the interconnect SLA. domain should be part of the interconnect SLA.
RFC 5127's four treatment aggregates include a Network Control RFC 5127's four treatment aggregates include a Network Control
aggregate for routing protocols and OAM traffic that is essential for aggregate for routing protocols and OAM traffic that is essential for
network operation administration, control and management. Using this network operation administration, control and management. Using this
aggregate as one of the four in RFC 5127 implicitly assumes that aggregate as one of the four in RFC 5127 implicitly assumes that
network control traffic is forwarded in potential competition with network control traffic is forwarded in potential competition with
all other network traffic, and hence DiffServ must favor such traffic all other network traffic, and hence Diffserv must favor such traffic
(e.g., via use of the CS6 codepoint) for network stability. That is (e.g., via use of the CS6 codepoint) for network stability. That is
a reasonable assumption for IP-based networks where routing and OAM a reasonable assumption for IP-based networks where routing and OAM
protocols are mixed with all other types of network traffic; protocols are mixed with all other types of network traffic;
corporate networks are an example. corporate networks are an example.
In contrast, mixing of all traffic is not a reasonable assumption for In contrast, mixing of all traffic is not a reasonable assumption for
MPLS-based provider or carrier networks, where customer traffic is MPLS-based provider or carrier networks, where customer traffic is
usually segregated from network control (routing and OAM) traffic via usually segregated from network control (routing and OAM) traffic via
other means, e.g., network control traffic use of separate LSPs that other means, e.g., network control traffic use of separate LSPs that
can be prioritized over customer LSPs (e.g., for VPN service) via can be prioritized over customer LSPs (e.g., for VPN service) via
skipping to change at page 8, line 31 skipping to change at page 8, line 31
In contrast, VoIP is emerging as a valuable and important class of In contrast, VoIP is emerging as a valuable and important class of
network traffic for which network-provided QoS is crucial, as even network traffic for which network-provided QoS is crucial, as even
minor glitches are immediately apparent to the humans involved in the minor glitches are immediately apparent to the humans involved in the
conversation. conversation.
Similar approaches to use of a small number of traffic aggregates Similar approaches to 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 the specific follows, highlighting differences from RFC 5127 and suggesting
traffic classes from RFC 4594 that each class aggregates. mappings for all RFC 4594 traffic classes to Diffserv-Intercon
Treatment Aggregates:
Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and
VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865]. VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865].
This Treatment Aggregate corresponds to RFC 5127s real time This Treatment Aggregate corresponds to RFC 5127s real time
Treatment Aggregate definition regarding the queuing, but it Treatment Aggregate definition regarding the queuing, but it
is restricted to transport Telephony Service Class traffic in is restricted to transport Telephony Service Class traffic in
the sense of RFC 4594. the sense of RFC 4594.
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
skipping to change at page 9, line 18 skipping to change at page 9, line 19
Assured Elastic Treatment Aggregate This Treatment Aggregate Assured Elastic Treatment Aggregate This Treatment Aggregate
consists of the entire AF3 PHB group AF3, i.e., DSCPs 011 consists of the entire AF3 PHB group AF3, i.e., DSCPs 011
010, 011 100 and 011 110. As compared to RFC5127, just the 010, 011 100 and 011 110. As compared to RFC5127, just the
number of DSCPs, which has been reduced. This document number of DSCPs, which has been reduced. This document
suggests to transport signaling marked by AF31. RFC5127 suggests to transport signaling marked by AF31. RFC5127
suggests to map Network Management traffic into this suggests to map Network Management traffic into this
Treatment Aggregate, if no separate Network Control Treatment Treatment Aggregate, if no separate Network Control Treatment
Aggregate is supported (for a more detailed discussion of Aggregate is supported (for a more detailed discussion of
Network Control PHB treatment see section 3.2). GSMA IR.34 Network Control PHB treatment see section 3.2). GSMA IR.34
proposes to transport signaling traffic by AF31 too. proposes to transport signaling traffic by AF31 too. The
following RFC 4594 classes should also be mapped to the
Assured Elastic Treatment Aggregate: the Signalling Service
Class (being marked for lowest loss probability), Multimedia
Streaming Service Class, the Low-Latency Data Service Class
and the High-Throughput Data 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. RFC 5127 example refers to this
Treatment Aggregate as Aggregate Elastic. An important Treatment Aggregate as Aggregate Elastic. An important
difference as compared to RFC5127 is that any traffic with difference as compared to RFC5127 is that any traffic with
unrecognized or unsupported DSCPs may be remarked to this unrecognized or unsupported DSCPs may be remarked to this
DSCP. If a Lower Effort PHB, as proposed by e.g. [RFC3662], DSCP. The RFC 4594 Standard Service Class and Low-priority
is standardised, Diffserv-Intercon support is suggested by data should be mapped to this Treatment Aggregate. RFC 4594
marking this traffic with a DSCP 000 xx0 at interconnection Low-priority data may be forwarded by a Lower Effort PHB in
interfaces. Note that this requires standardisation (this one domain (like the PHB proposed by Informational
document is informational only). [RFC3662]). If such traffic is sent to a domain not
supporting a Lower Effort PHB, the lowest effort PHB there
RFC 4594's Multimedia Streaming class has not been mapped to the may be expected to be the Default PHB. Marking such traffic
above scheme. By the time of writing, the most popular streaming with DSCP CS0 at an interconnection interface is a reasonable
applications use TCP transport and adapt picture quality in the case choice then.
of congestion. A possible deployment of Diffserv-Intercon may be to
move all quality content to the Bulk Real Time Treatment Aggregate.
The Assured Elastic Treatment Aggregate may be used to carry
signaling traffic. Another option is to carry Multimedia Streaming
as part of the Assured Elastic Treatment aggregate, as its properties
are suitable for protocols applying automated retransmit requests.
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 QoS interconnection
SLA. SLA.
Traffic of provider O terminates within provider Ts network, while Traffic of provider O terminates within provider Ts 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. Assume all providers run their own internal codepoint provider F. Assume all providers run their own internal codepoint
schemes for a PHB group with properties of the DiffServ-Intercon schemes for a PHB group with properties of the Diffserv-Intercon
Assured Treatment Aggregate. Assured Treatment Aggregate.
Provider-O Provider-W Provider-O Provider-W
RFC5127 GSMA 34.1 RFC5127 GSMA 34.1
| | | |
+----------+ +----------+ +----------+ +----------+
|AF21, AF22| | CS3, CS2 | |AF21, AF22| | CS3, CS2 |
+----------+ +----------+ +----------+ +----------+
| | | |
V V V V
+++++++++ +++++++++ +++++++++ +++++++++
|Rtr PrO| |Rtr PrW| Rtr Pr: |Rtr PrO| |Rtr PrW| Rtr Pr:
+++++++++ +++++++++ Router Peering +++++++++ +++++++++ Router Peering
| DiffServ | | Diffserv |
+----------+ +----------+ +----------+ +----------+
|AF31, AF32| |AF31, AF32| |AF31, AF32| |AF31, AF32|
+----------+ +----------+ +----------+ +----------+
| Intercon | | Intercon |
V V V V
+++++++++ | +++++++++ |
|RtrPrTI|------------------+ |RtrPrTI|------------------+
+++++++++ +++++++++
| Provider-T domain | Provider-T domain
+-----------+ +-----------+
skipping to change at page 10, line 42 skipping to change at page 10, line 42
| | +----------+ +++++++++ | | +----------+ +++++++++
V +->|AF21, AF22|->-|RtrDstH| V +->|AF21, AF22|->-|RtrDstH|
| +----------+ +++++++++ | +----------+ +++++++++
+----------+ RtrDst: +----------+ RtrDst:
|AF21, AF22| Router Destination |AF21, AF22| Router Destination
+----------+ +----------+
| |
+++++++++ +++++++++
|RtrPrTE| |RtrPrTE|
+++++++++ +++++++++
| DiffServ | Diffserv
+----------+ +----------+
|AF31, AF32| |AF31, AF32|
+----------+ +----------+
| Intercon | Intercon
+++++++++ +++++++++
|RtrPrF| |RtrPrF|
+++++++++ +++++++++
| |
+----------+ +----------+
| CS4, CS3 | | CS4, CS3 |
+----------+ +----------+
| |
Provider-F Provider-F
GSM IR.34 GSM IR.34
DiffServ-Intercon example Diffserv-Intercon example
Figure 1 Figure 1
Providers only need to deploy internal DSCP to DiffServ-Intercon DSCP Providers only need to deploy internal DSCP to Diffserv-Intercon DSCP
mappings to exchange traffic in the desired classes. Provider W has mappings to exchange traffic in the desired classes. Provider W has
decided that the properties of his internal classes CS3 and CS2 are decided that the properties of his internal classes CS3 and CS2 are
best met by the Diffserv-Intercon Assured Elastic Treatment best met by the Diffserv-Intercon Assured Elastic Treatment
Aggregate, PHBs AF31 and AF32 respectively. At the outgoing peering Aggregate, PHBs AF31 and AF32 respectively. At the outgoing peering
interface connecting provider W with provider T the former's peering interface connecting provider W with provider T the former's peering
router remarks CS3 traffic to AF31 and CS2 traffic to AF32. The router remarks CS3 traffic to AF31 and CS2 traffic to AF32. The
domain internal PHBs of provider T that meet the requirements of domain internal PHBs of provider T that meet the requirements of
Diffserv-Intercon Assured Elastic Treatment Aggregate are AF2x. Diffserv-Intercon Assured Elastic Treatment Aggregate are AF2x.
Hence AF31 traffic received at the interconnection with provider T is Hence AF31 traffic received at the interconnection with provider T is
remarked to AF21 by the peering router of domain T, and domain T has remarked to AF21 by the peering router of domain T, and domain T has
chosen to use MPLS TC value 2 for this aggregate. Traffic received chosen to use MPLS TC value 2 for this aggregate. Traffic received
with AF32 is similarly remarked to AF22, but uses the same MPLS TC with AF32 is similarly remarked to AF22, but uses the same MPLS TC
for the Treatment Aggregate, i.e. TC 2. At the penultimate MPLS for the Treatment Aggregate, i.e. TC 2. At the penultimate MPLS
node, the top MPLS label is removed. The packet should be forwarded node, the top MPLS label is removed. The packet should be forwarded
as determined by the incoming MPLS TC. The peering router connecting as determined by the incoming MPLS TC. The peering router connecting
domain T with domain F classifies the packet by it's domain T domain T with domain F classifies the packet by it's domain T
internal DSCP AF21 for the Diffserv-Intercon Assured Elastic internal DSCP AF21 for the Diffserv-Intercon Assured Elastic
Treatment Aggregate. As it leaves domain T on the interface to Treatment Aggregate. As it leaves domain T on the interface to
domain F, this causes the packet to be remarked to AF31. The peering domain F, this causes the packet to be remarked to AF31. The peering
router of domain F classifies the packet for domain F internal PHB router of domain F classifies the packet for domain F internal PHB
CS4, as this is the PHB with properties matching DiffServ-Intercon's CS4, as this is the PHB with properties matching Diffserv-Intercon's
Assured Elastic Treatment Aggregate. Likewise, AF21 traffic is Assured Elastic Treatment Aggregate. Likewise, AF21 traffic is
remarked to AF32 by the peering router od domain T when leaving it remarked to AF32 by the peering router od domain T when leaving it
and from AF32 to CS3 by domain F's peering router when receiving it. and from AF32 to CS3 by domain F's peering router when receiving it.
This example can be extended. Suppose Provider-O also supports a PHB This example can be extended. Suppose Provider-O also supports a PHB
marked by CS2 and this PHB is supposed to be transported by QoS marked by CS2 and this PHB is supposed to be transported by QoS
within Provider-T domain. Then Provider-O will remark it with a DSCP within Provider-T domain. Then Provider-O will remark it with a DSCP
other than the AF31 DSCP in order to preserve the distinction from other than the AF31 DSCP in order to preserve the distinction from
CS2; AF11 is one possibility that might be private to the CS2; AF11 is one possibility that might be private to the
interconnection between Provider-O and Provider-T; there's no interconnection between Provider-O and Provider-T; there's no
assumption that Provider-W can also use AF11, as it may not be in the assumption that Provider-W can also use AF11, as it may not be in the
SLA with Provider-W. SLA with Provider-W.
Now suppose Provider-W supports CS2 for internal use only. Then no Now suppose Provider-W supports CS2 for internal use only. Then no
DiffServ- Intercon DSCP mapping may be configured at the peering Diffserv- Intercon DSCP mapping may be configured at the peering
router. Traffic, sent by Provider-W to Provider-T marked by CS2 due router. Traffic, sent by Provider-W to Provider-T marked by CS2 due
to a misconfiguration may be remarked to CS0 by Provider-T. to a misconfiguration may be remarked to CS0 by Provider-T.
See section 4.1 for further discussion of this and DSCP transparency See section 4.1 for further discussion of this and DSCP transparency
in general. in general.
RFC2575 states that Ingress nodes must condition all other inbound RFC2575 states that Ingress nodes must condition all other inbound
traffic to ensure that the DS codepoints are acceptable; packets traffic to ensure that the DS codepoints are acceptable; packets
found to have unacceptable codepoints must either be discarded or found to have unacceptable codepoints must either be discarded or
must have their DS codepoints modified to acceptable values before must have their DS codepoints modified to acceptable values before
skipping to change at page 13, line 7 skipping to change at page 13, line 7
label marked TC0. CS1 is not rewritten. The Pipe model is not label marked TC0. CS1 is not rewritten. The Pipe model is not
within scope of this document. within scope of this document.
o With the Short Pipe model, the DCSP likely changes and the might o With the Short Pipe model, the DCSP likely changes and the might
PHB change when an interconnected network is passed. This draft PHB change when an interconnected network is passed. This draft
describes a method to speed up and simplify QoS interconnection if describes a method to speed up and simplify QoS interconnection if
a DSCP rewrite can't be avoided. It offers a set of PHBs and a DSCP rewrite can't be avoided. It offers a set of PHBs and
treatment aggregates as well as a set of interconnection DSCPs treatment aggregates as well as a set of interconnection DSCPs
allowing straightforward rewriting to domain-internal DSCPs as allowing straightforward rewriting to domain-internal DSCPs as
well as defined forwarding and markings to the next domain. well as defined forwarding and markings to the next domain.
DiffServ-Intercon supports the Short Pipe model. The solution Diffserv-Intercon supports the Short Pipe model. The solution
described here can be used in other contexts benefitting from a described here can be used in other contexts benefitting from a
defined interconnection QoS interface. defined interconnection QoS 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. number of DSCPs.
4.2. Treatment of Network Control traffic at carrier interconnection 4.2. Treatment of Network Control traffic at carrier interconnection
interfaces interfaces
skipping to change at page 14, line 31 skipping to change at page 14, line 31
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 not interconnected Mobile Network Operators, it is certainly not
Network Control traffic for a fixed network providing transit Network Control traffic for a fixed network providing transit
between such operators, and hence should not receive CS6 treatment between such operators, and hence should not receive CS6 treatment
in such a network. in such a network.
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 Brisoe reviewed the draft and provided rich feedback. Fred Baker Bob Briscoe reviewed the draft and provided rich feedback. Fred
and Brian Carpenter provided intensive feedback and discussion. Al Baker and Brian Carpenter provided intensive feedback and discussion.
Morton and Sebastien Jobert provided feedback on many aspects during Al Morton and Sebastien Jobert provided feedback on many aspects
private discussions. Mohamed Boucadair and Thomas Knoll helped during private discussions. Mohamed Boucadair and Thomas Knoll
adding awareness of related work. James Polks discussion during IETF helped adding awareness of related work. James Polks discussion
89 helped to improve the relation of this draft to RFC 4594 and RFC during IETF 89 helped to improve the relation of this draft to RFC
5127. 4594 and RFC 5127.
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
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 considerations of RFC 2475 [RFC2475] use existing ones. The security considerations of RFC 2475 [RFC2475]
and RFC 4594 [RFC4594] apply. and RFC 4594 [RFC4594] apply.
8. References 8. References
8.1. Normative References 8.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>.
[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.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<http://www.rfc-editor.org/info/rfc3260>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[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, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>.
[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, DOI 10.17487/RFC5462, February
2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010. RFC 5865, DOI 10.17487/RFC5865, May 2010,
<http://www.rfc-editor.org/info/rfc5865>.
8.2. Informative References 8.2. Informative References
[I-D.knoll-idr-cos-interconnect] [I-D.knoll-idr-cos-interconnect]
Knoll, T., "BGP Class of Service Interconnection", draft- Knoll, T., "BGP Class of Service Interconnection", draft-
knoll-idr-cos-interconnect-14 (work in progress), May knoll-idr-cos-interconnect-14 (work in progress), May
2015. 2015.
[ID.idr-sla] [ID.idr-sla]
IETF, "Inter-domain SLA Exchange", IETF, IETF, "Inter-domain SLA Exchange", IETF,
http://datatracker.ietf.org/doc/ http://datatracker.ietf.org/doc/
draft-ietf-idr-sla-exchange/, 2013. draft-ietf-idr-sla-exchange/, 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 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34
http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ http://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 Class of Service Phase 2", MEF, MEF23.1
http://metroethernetforum.org/PDF_Documents/technical- http://metroethernetforum.org/PDF_Documents/technical-
specifications/MEF_23.1.pdf, 2012. specifications/MEF_23.1.pdf, 2012.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC [RFC2983] Black, D., "Differentiated Services and Tunnels",
2983, October 2000. RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003. RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>.
[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, August Guidelines for DiffServ Service Classes", RFC 4594,
2006. DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
[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, DOI 10.17487/RFC5127,
February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[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, DOI 10.17487/RFC5160, March
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 non-tunneled IPv4 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.
skipping to change at page 18, line 5 skipping to change at page 18, line 9
interconnection. As a result PHBs and DSCPs typically differ between interconnection. As a result PHBs and DSCPs typically differ between
network carriers. PHBs may be mapped. With the exception of best network carriers. PHBs may be mapped. With the exception of best
effort traffic, a DSCP change should be expected at an effort traffic, a DSCP change should be expected at an
interconnection at least for plain IP traffic, even if the PHB is interconnection at least for plain IP traffic, even if the PHB is
suitably mapped by the carriers involved. suitably mapped by the carriers involved.
Beyond RFC3270's suggestions that the Short Pipe Model is only Beyond RFC3270's suggestions that the Short Pipe Model is only
applicable to VPNs, current network structures also use it to applicable to VPNs, current network structures also use it to
transport non tunneled IPv4 traffic. This is shown in figure 2. transport non tunneled IPv4 traffic. This is shown in figure 2.
| |
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
Peering Router Peering Router
| |
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
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 QoS context. The Core
\|/ > Router might require or enforce \|/ > Router might require or enforce
V | it. The Edge Router may wrongly V | it. 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).
| / | /
Peer Router Peer Router
| Remark DSCP to | Remark DSCP to
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
skipping to change at page 18, line 49 skipping to change at page 19, line 5
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 QoS 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 of the each network marked with network-internal DSCP. DSCP_send of the
figure above is remarked to the receiving network's DiffServ scheme. figure above is remarked to the receiving network's Diffserv scheme.
It leaves the domain marked by the domains DSCP_d. This structure It leaves the domain marked by the domains DSCP_d. This structure
requires that every carrier deploys per-peer PHB and DSCP mapping requires that every carrier deploys per-peer PHB and DSCP mapping
schemes. schemes.
If Diffserv-Intercon is applied DSCPs for traffic transiting the If Diffserv-Intercon is applied DSCPs for traffic transiting the
domain can be mapped from and remapped to an original DSCP. This is domain can be mapped from and remapped to an original DSCP. This is
shown in figure 3. Internal traffic may continue to use internal shown in figure 3. Internal traffic may continue to use internal
DSCPs (e.g, DSCP_d) and those may also be used between a carrier and DSCPs (e.g, DSCP_d) and those may also be used between a carrier and
its direct customers. its direct customers.
Internal Router Internal Router
| |
| Outer Header | Outer Header
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
Peering Router Peering Router
| Remark DSCP to | Remark DSCP to
\|/ IPv4, DSCP_ds-int DiffServ-Intercon DSCP and PHB \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
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) domain internal DSCP for V (Inner: IPv4, DSCP_d) domain internal DSCP for
| the PHB | the PHB
MPLS Core Router (penultimate hop label popping) MPLS Core Router (penultimate hop label popping)
| |
skipping to change at page 20, line 46 skipping to change at page 20, line 46
Peer Router Domain internal Broadband Peer Router Domain internal Broadband
| Access Router | Access Router
\|/ Remark DSCP to \|/ \|/ Remark DSCP to \|/
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 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
RFC5127 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 RFC4594 classes to Diffserv-
Intercon classes at interconnection.
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
 End of changes. 66 change blocks. 
92 lines changed or deleted 111 lines changed or added

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