draft-ietf-tsvwg-diffserv-intercon-06.txt   draft-ietf-tsvwg-diffserv-intercon-07.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: December 22, 2016 EMC Corporation Expires: February 26, 2017 EMC Corporation
June 20, 2016 August 25, 2016
Diffserv-Interconnection classes and practice Diffserv-Interconnection classes and practice
draft-ietf-tsvwg-diffserv-intercon-06 draft-ietf-tsvwg-diffserv-intercon-07
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 PHBs, and use MPLS for interconnection
with other networks. This document offers a simple interconnection with other networks. This document offers a simple interconnection
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 22, 2016. This Internet-Draft will expire on February 26, 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 11, line 8 skipping to change at page 11, line 8
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
| | | |
+----------+ +----------+ +----------+ +----------+
| AF21 | | CS2 | | AF21 | | CS2 |
+----------+ +----------+ +----------+ +----------+
V V V V
+~~~~~~~+ +~~~~~~~+ +~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| |Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ +~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| DiffServ | | DiffServ |
+----------+ +----------+ +----------+ +----------+
| AF31 | | AF31 | | AF31 | | AF31 |
+----------+ +----------+ +----------+ +----------+
V Intercon V V Intercon V
+~~~~~~~+ | +~~~~~~~+ |
|RtrPrTI|------------------+ |RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+ +~~~~~~~+
| Provider T domain | Provider T domain
+------------------+ +------------------+
| MPLS TC 2, AF21 | | MPLS TC 2, AF21 |
+-----------------+ +------------------+
| | +----------+ +~~~~~~~+ | | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+ +----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T | AF21 | Local DSCPs Provider T
+----------+ +----------+
| |
+~~~~~~~+ +~~~~~~~+
|RtrPrTE| |RtrPrTE| Router Provider T Egress
+~~~~~~~+ +~~~~~~~+
| DiffServ | DiffServ
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
| Intercon | Intercon
+~~~~~~~+ +~~~~~~~+
|RtrPrHF| |RtrPrF | Router Provider F
+~~~~~~~+ +~~~~~~~+
| |
+----------+ +----------+
| AF11 | Provider F | AF11 | Provider F
+----------+ +----------+
Diffserv-Intercon example Diffserv-Intercon example
Figure 1 Figure 1
Providers only need to deploy mappings of internal DSCPs to/from Providers only need to deploy mappings of internal DSCPs to/from
Diffserv-Intercon DSCPs in order to exchange traffic using the Diffserv-Intercon DSCPs in order to exchange traffic using the
desired PHBs. In the example, provider O has decided that the desired PHBs. In the example, provider O has decided that the
properties of his internal class AF21 and are best met by the properties of his internal class AF21 are best met by the Diffserv-
Diffserv-Intercon Assured Elastic Treatment Aggregate, PHB AF31. At Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the
the outgoing peering interface connecting provider O with provider T outgoing peering interface connecting provider O with provider T the
the former's peering router remarks AF21 traffic to AF31. The domain former's peering router remarks AF21 traffic to AF31. The domain
internal PHB of provider T meeting the requirement of Diffserv- internal PHB of provider T meeting the requirement of Diffserv-
Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group. Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group.
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 Traffic Class value 2 for this aggregate. At the chosen to use MPLS Traffic Class value 2 for this aggregate. At the
penultimate MPLS node, the top MPLS label is removed and exposes the penultimate MPLS node, the top MPLS label is removed and exposes the
IP header marked by the DSCP which has been set at the network IP header marked by the DSCP which has been set at the network
ingress. The peering router connecting domain T with domain F ingress. The peering router connecting domain T with domain F
classifies the packet by its domain-T-internal DSCP AF21. As the classifies the packet by its domain-T-internal DSCP AF21. As the
packet leaves domain T on the interface to domain F, this causes the packet leaves domain T on the interface to domain F, this causes the
skipping to change at page 13, line 38 skipping to change at page 13, line 38
CS6 envisioned by RFC 4594. A specific example is that some CS6 CS6 envisioned by RFC 4594. 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 QoS discussion in the previous section (4.2) is
generally inapplicable to network control traffic - network control generally inapplicable to network control traffic - network control
traffic is generally intended to control a network, not be traffic is generally intended to control a network, not be
transported across it. One exception is that network control traffic transported between networks. One exception is that network control
makes sense for a purchased transit agreement, and preservation of traffic makes sense for a purchased transit agreement, and
the CS6 DSCP marking for network control traffic that is transited is preservation of the CS6 DSCP marking for network control traffic that
reasonable in some cases, although it is generally inappropriate to is transited is reasonable in some cases, although it is generally
use CS6 for forwarding that traffic within the network that provides inappropriate to use CS6 for forwarding that traffic within the
transit. Use of an IP tunnel is suggested in order to conceal the network that provides transit. Use of an IP tunnel is suggested in
CS6 markings on transiting network control traffic from the network order to conceal the CS6 markings on transiting network control
that provides the transit. In this case, Pipe model for Diffserv traffic from the network that provides the transit. In this case,
tunneling is used. Pipe model for Diffserv tunneling is used.
If the MPLS Short Pipe model is deployed for non-tunneled IPv4 If the MPLS Short Pipe model is deployed for non-tunneled 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
skipping to change at page 17, line 22 skipping to change at page 17, line 22
Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic
all use an additional MPLS label; in this case, the MPLS tunnel all use an additional MPLS label; in this case, the MPLS tunnel
follows the Pipe model. Classification and queuing within an MPLS follows the Pipe model. Classification and queuing within an MPLS
network is always based on an MPLS label, as opposed to the outer IP network is always based on an MPLS label, as opposed to the outer IP
header. header.
Carriers often select QoS PHBs and DSCP without regard to Carriers often select QoS 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 plain IP change should be expected at an interconnection an interconnection at
traffic, even if the PHB is suitably mapped by the carriers involved. least for non-tunneled IP traffic, even if the PHB is suitably mapped
by the carriers involved.
Although RFC3270 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
| |
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
 End of changes. 14 change blocks. 
29 lines changed or deleted 30 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/