idnits 2.17.1 draft-ietf-tsvwg-diffserv-intercon-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2016) is 2934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-15 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Geib, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational D. Black 5 Expires: October 2, 2016 EMC Corporation 6 April 2016 8 Diffserv-Interconnection classes and practice 9 draft-ietf-tsvwg-diffserv-intercon-05 11 Abstract 13 This document proposes a limited common set of Diffserv PHBs and 14 codepoints (DSCPs) to be applied at (inter)connections of two 15 separately administered and operated networks, and explains how this 16 approach can simplify network configuration and operation. Many 17 network providers operate MPLS using Treatment Aggregates for traffic 18 marked with different Diffserv PHBs, and use MPLS for interconnection 19 with other networks. This document offers a simple interconnection 20 approach that may simplify operation of Diffserv for network 21 interconnection among providers that use MPLS and apply the Short- 22 Pipe tunnel mode. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 2, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 61 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 62 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5 63 3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 6 64 3.1. RFC 5127 Background . . . . . . . . . . . . . . . . . . . 6 65 3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7 66 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8 67 4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 9 68 4.2. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 12 69 4.3. Treatment of Network Control traffic at carrier 70 interconnection interfaces . . . . . . . . . . . . . . . 13 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 8.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 16 78 Appendix B. Change log (to be removed by the RFC editor) . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 81 1. Introduction 83 Diffserv has been deployed in many networks; it provides 84 differentiated traffic forwarding based on the Diffserv Codepoint 85 (DSCP) field [RFC2474]. This draft proposes a set of common Diffserv 86 QoS classes (Per Hop Behaviors, PHBs)and code points at 87 interconnection points to which and from which locally used classes 88 and code points should be mapped. 90 As described by section 2.3.4.2 of RFC 2475, remarking of packets at 91 domain boundaries is a Diffserv feature [RFC2475]. If traffic marked 92 with unknown or unexpected DSCPs is received, RFC2474 recommends 93 forwarding that traffic with default (best effort) treatment without 94 changing the DSCP markings to better support incremental Diffserv 95 deployment in existing networks as well as with routers that do not 96 support Diffserv or are not configured to support it. Many networks 97 do not follow this recommendation, and instead remark unknown or 98 unexpected DSCPs to zero upon receipt for default (best effort) 99 forwarding in accordance with the guidance in RFC 2475 [RFC2475] to 100 ensure that appropriate DSCPs are used within a Diffserv domain. 101 This draft assumes that latter approach by defining additional DSCPs 102 that are known and expected at network interconnection interfaces. 104 This document is motivated by requirements for IP network 105 interconnection with Diffserv support among providers that operate 106 MPLS in their backbones, but is applicable to other technologies. 107 The operational simplifications and methods in this document help 108 align IP Diffserv functionality with MPLS limitations resulting from 109 the widely deployed Short Pipe tunnel model for operation [RFC3270]. 110 Further, limiting Diffserv to a small number of Treatment Aggregates 111 can enable network traffic to leave a network with the same DSCPs 112 that it was received with, even if a different DSCP is used within 113 the network, thus providing an opportunity to extend consistent QoS 114 treatment across network boundaries. 116 In isolation, use of standard interconnection PHBs and DSCPs may 117 appear to be additional effort for a network operator. The primary 118 offsetting benefit is that mapping from or to the interconnection 119 PHBs and DSCPs is specified once for all of the interconnections to 120 other networks that can use this approach. Absent this approach, the 121 PHBs and DSCPs have to be negotiated and configured independently for 122 each network interconnection, which has poor administrative and 123 operational scaling properties. Further, consistent end-to-end QoS 124 treatment is more likely to result when an interconnection code point 125 scheme is used because traffic is remarked to the same PHBs at all 126 network interconnections. 128 The interconnection approach described in this document (referred to 129 as Diffserv-Intercon) uses a set of PHBs and MPLS treatment 130 aggregates along with a set of interconnection DSCPs allowing 131 straightforward rewriting to domain-internal DSCPs and defined DSCP 132 markings for traffic forwarded to interconnected domains. Diffserv- 133 Intercon supports the Short Pipe model. The solution described here 134 can be used in other contexts benefitting from a defined 135 interconnection QoS interface. 137 The basic idea is that traffic sent with a Diffserv-Interconnect PHB 138 and DSCP is restored to that PHB and DSCP at each network 139 interconnection, even though a different PHB and DSCP may be used by 140 each network involved. The key requirement is that the network 141 ingress interconnect DSCP be restored at network egress, and a key 142 observation is that this is only feasible in general for a small 143 number of DSCPs. Traffic sent with other DSCPs can be remarked to an 144 interconnect DSCP or dealt with via additional agreement(s) among the 145 operators of the interconnected networks; remarking in the absence of 146 additional agreement(s) when the MPLS Short Pipe model is used for 147 reasons explained in this document. Diffserv-Intercon may be also be 148 applied to the Pipe tunneling model [RFC2983], [RFC3270], but is not 149 applicable to the. Uniform tunneling model [RFC2983], [RFC3270]. 151 In addition to the common interconnecting PHBs and DSCPs, 152 interconnecting operators need to further agree on the tunneling 153 technology used for interconnection (e.g., MPLS, if used) and control 154 or mitigate the impacts of tunneling on reliability and MTU. 156 1.1. Related work 158 In addition to the activities that triggered this work, there are 159 additional RFCs and Internet-drafts that may benefit from an 160 interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS- 161 Classes to enable deployment of standardized end to end QoS classes 162 [RFC5160]. The Diffserv-Intercon class- and codepoint scheme is 163 intended to complement that work (e.g. by enabling standard end-to- 164 end QoS service classes). 166 BGP signaling Class of Service at interconnection interfaces by BGP 167 [I-D.knoll-idr-cos-interconnect], [ID.ietf-idr-sla] is complementary 168 to Diffserv-Intercon. These two BGP documents focus on exchanging 169 SLA and traffic conditioning parameters and assume that common PHBs 170 identified by the signaled DSCPs have been established (e.g., via use 171 of the Diffserv-Intercon DSCPs) prior to BGP signaling of QoS. 173 1.2. Applicability Statement 175 This document is applicable to use of Differentiated Services for 176 interconnection traffic between networks, and in particular to 177 interconnection of MPLS-based networks. This document is not 178 intended for use within an individual network, where the approach 179 specified in RFC 5127 [RFC5127] is among the possible alternatives; 180 see Section 3 for further discussion. 182 The Diffserv-Intercon approach described in this document simplifies 183 IP based interconnection to domains operating the MPLS Short Pipe 184 model for IP traffic, both terminating within the domain and 185 transiting onward to another domain. Transiting traffic is received 186 and sent with the same PHB and DSCP. Terminating traffic maintains 187 the PHB with which it was received, however the DSCP may change. 189 1.3. Document Organization 191 This document is organized as follows: section 2 reviews the MPLS 192 Short Pipe tunnel model for Diffserv Tunnels [RFC3270], as effective 193 support for that model is a crucial goal of Diffserv-Intercon. 194 Section 3 provides background on RFC 5127's approach to traffic class 195 aggregation within a Diffserv network domain and contrasts it with 196 the Diffserv-Intercon approach. Section 4 introduces Diffserv- 197 Interconnection Treatment Aggregates, along with the PHBs and DSCPs 198 that they use, and explains how other PHBs (and associated DSCPs) may 199 be mapped to these Treatment Aggregates. Section 4 also discusses 200 treatment of non-tunneled and tunneled IP traffic and MPLS VPN QoS 201 considerations and handling of high-priority Network Management 202 traffic is described. Appendix A describes how the MPLS Short Pipe 203 model (penultimate hop popping) impacts QoS and DSCP marking for IP 204 interconnections. 206 2. MPLS and the Short Pipe tunnel model 208 The Pipe and Uniform models for Differentiated Services and Tunnels 209 are defined in [RFC2983]. RFC3270 adds the Short Pipe model in order 210 to support MPLS penultimate hop popping (PHP) of Labels, primarily 211 for MPLS-based IP tunnels and VPNs. The Short Pipe model and PHP 212 have subsequently become popular with network providers that operate 213 MPLS networks and are now widely used to transport non-tunneled IP 214 traffic, not just traffic encapsulated in IP tunnels and VPNs. This 215 has important implications for Diffserv functionality in MPLS 216 networks. 218 RFC 2474's recommendation to forward traffic with unrecognized DSCPs 219 with Default (best effort) service without rewriting the DSCP has 220 proven to be a poor operational practice. Network operation and 221 management are simplified when there is a 1-1 match between the DSCP 222 marked on the packet and the forwarding treatment (PHB) applied by 223 network nodes. When this is done, CS0 (the all-zero DSCP) is the 224 only DSCP used for Default forwarding of best effort traffic, and a 225 common practice is to remark to CS0 any traffic received with 226 unrecognized or unsupported DSCPs at network edges. 228 MPLS networks are more subtle in this regard, as it is possible to 229 encode the provider's DSCP in the MPLS Traffic Class (TC) field and 230 allow that to differ from the PHB indicated by the DSCP in the MPLS- 231 encapsulated IP packet. If the MPLS label with the provider's TC 232 field is present at all hops within the provider's network, this 233 approach would allow an unrecognized DSCP to be carried edge-to-edge 234 over an MPLS network, because the effective DSCP used by the 235 provider's MPLS network would be encoded in the MPLS label TC field 236 (and also carried edge-to-edge). Unfortunately this is only true for 237 the Pipe tunnel model. 239 The Short Pipe tunnel model and PHP behave differently because PHP 240 removes and discards the MPLS provider label carrying the provider's 241 TC field before the traffic exits the provider's network. That 242 discard occurs one hop upstream of the MPLS tunnel endpoint (which is 243 usually at the network edge), resulting in no provider TC info being 244 available at tunnel egress. To ensure consistent handling of traffic 245 at the tunnel egress, the DSCP field in the MPLS-encapsulated IP 246 header has to contain a DSCP that is valid for the provider's 247 network, so that IP header cannot be used to carry a different DSCP 248 edge-to-edge . See Appendix A for a more detailed discussion. 250 3. Relationship to RFC 5127 252 This document draws heavily upon RFC 5127's approach to aggregation 253 of Diffserv traffic classes for use within a network, but there are 254 important differences caused by characteristics of network 255 interconnects that differ from links within a network. 257 3.1. RFC 5127 Background 259 Many providers operate MPLS-based backbones that employ backbone 260 traffic engineering to ensure that if a major link, switch, or router 261 fails, the result will be a routed network that continues to 262 function. Based on that foundation, [RFC5127] introduced the concept 263 of Diffserv Treatment Aggregates, which enable traffic marked with 264 multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC) 265 based on robust provider backbone traffic engineering. This enables 266 differentiated forwarding behaviors within a domain in a fashion that 267 does not consume a large number of MPLS Traffic Classes. 269 RFC 5127 provides an example aggregation of Diffserv service classes 270 into 4 Treatment Aggregates. A small number of aggregates are used 271 because: 273 o The available coding space for carrying QoS information (e.g., 274 Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and 275 is intended for more than just QoS purposes (see e.g. [RFC5129]). 277 o The common interconnection DSCPs ought not to use all 8 possible 278 values. This leaves space for future standards, for private 279 bilateral agreements and for local use PHBs and DSCPs. 281 o Migrations from one Diffserv code point scheme to a different one 282 is another possible application of otherwise unused QoS code 283 points. 285 3.2. Differences from RFC 5127 287 Like RFC 5127, this document also uses four traffic aggregates, but 288 differs from RFC 5127 in some important ways: 290 o It follows RFC 2475 in allowing the DSCPs used within a network to 291 differ from those to exchange traffic with other networks (at 292 network edges), but provides support to restore ingress DSCP 293 values if one of the recommended interconnect DSCPs in this draft 294 is used. This results in DSCP remarking at both network ingress 295 and network egress, and this draft assumes that such remarking at 296 network edges is possible for all interface types. 298 o Diffserv-Intercon suggests limiting the number of interconnection 299 PHBs per Treatment Aggregate to the minimum required. As further 300 discussed below, the number of PHBs per Treatment Aggreagate is no 301 more than two. When two PHBs are specified for a Diffserv- 302 Intercon treatment aggregate, the expectation is that the provider 303 network supports DSCPs for both PHBs, but uses a single MPLS TC 304 for the Treatment Aggregate that contains the two PHBs. 306 o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the 307 interconnection Treatment Aggregates as further discussed below. 309 o Diffserv-Intercon treats network control traffic as a special 310 case. Within a provider's network, the CS6 DSCP is used for local 311 network control traffic (routing protocols and OAM traffic that is 312 essential to network operation administration, control and 313 management) that may be destined for any node within the network. 314 In contrast, network control traffic exchanged between networks 315 (e.g., BGP) usually terminates at or close to a network edge, and 316 is not forwarded through the network because it is not part of 317 internal routing or OAM for the receiving network. In addition, 318 such traffic is unlikely to be covered by standard interconnection 319 agreements; rather, it is more likely to be specifically 320 configured (e.g., most networks impose restrictions on use of BGP 321 with other networks for obvious reasons). See Section 4.2 for 322 further discussion. 324 o Because RFC 5127 used a Treatment Aggregate for network control 325 traffic, Diffserv-Intercon can instead define a fourth traffic 326 aggregate to be defined for use at network interconnections 327 instead of the Network Control aggregate in RFC 5127. Network 328 Control traffic may still be exchanged across network 329 interconnections as further discussed in Section 4.2. Diffserv- 330 Intercon uses this fourth traffic aggregate for VoIP traffic, 331 where network-provided QoS is crucial, as even minor glitches are 332 immediately apparent to the humans involved in the conversation. 334 4. The Diffserv-Intercon Interconnection Classes 336 At an interconnection, the networks involved need to agree on the 337 PHBs used for interconnection and the specific DSCP for each PHB. 338 This draft proposes a standard interconnection set of 4 Treatment 339 Aggregates with well-defined DSCPs to be aggregated by them. A 340 sending party remarks DSCPs from internal schemes to the 341 interconnection code points. The receiving party remarks DSCPs to 342 her internal scheme. The set of DSCPs and PHBs supported across the 343 two interconnected domains and the treatment of PHBs and DSCPs not 344 recognized by the receiving domain should be part of the interconnect 345 SLA. 347 Similar approaches to use of a small number of traffic aggregates 348 (including recognition of the importance of VoIP traffic) have been 349 taken in related standards and recommendations from outside the IETF, 350 e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1]. 352 The list of the four Diffserv-Interconnect traffic aggregates 353 follows, highlighting differences from RFC 5127 and suggesting 354 mappings for all RFC 4594 traffic classes to Diffserv-Intercon 355 Treatment Aggregates: 357 Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and PHB 358 VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865]. 359 This Treatment Aggregate corresponds to RFC 5127s real time 360 Treatment Aggregate definition regarding the queuing (both 361 delay and jitter should be minimized), but this aggregate is 362 restricted to transport Telephony Service Class traffic in 363 the sense of RFC 4594. [RFC4594] 365 Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is 366 designed to transport PHB AF41, DSCP 100 010 (the other AF4 367 PHB group PHBs and DSCPs may be used for future extension of 368 the set of DSCPs carried by this Treatment Aggregate). This 369 Treatment Aggregate is intended for Diffserv-Intercon network 370 interconnection of the portions of RFC 5127's Real Time 371 Treatment Aggregate, that consume significant bandwidth, 372 namely Broadcast Video, Real-Time Interactive and Multimedia 373 Conferencing. This treatment aggregate should be configured 374 with a rate queue (consistent with RFC 4594's recommendation 375 for the transported traffic classes). By comparison to RFC 376 5127, the number of DSCPs has been reduced to one 377 (initially). If need for three-color marked Multimedia 378 Conferencing traffic arises, AF42 and AF43 PHBs may be added. 380 Assured Elastic Treatment Aggregate This Treatment Aggregate 381 consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011 382 100). By comparison to RFC 5127, the number of DSCPs has 383 been reduced to two. This document suggests to transport 384 signaling marked by AF31 (e.g. as recommended by GSMA IR.34 385 [IR.34]). AF33 is reserved for extension of PHBs to be 386 aggregated by this TA. For Diffserv-Intercon network 387 interconnection, the following RFC 4594 service classes 388 should be mapped to the Assured Elastic Treatment Aggregate: 389 the Signaling Service Class (being marked for lowest loss 390 probability), Multimedia Streaming Service Class, the Low- 391 Latency Data Service Class and the High-Throughput Data 392 Service Class. 394 Default / Elastic Treatment Aggregate: transports the default PHB, 395 CS0 with DSCP 000 000. RFC 5127 example refers to this 396 Treatment Aggregate as Aggregate Elastic. An important 397 difference from RFC 5127 is that any traffic with 398 unrecognized or unsupported DSCPs may be remarked to this 399 DSCP. For Diffserv-Intercon network interconnection, the RFC 400 4594 standard service class and Low-priority Data service 401 class should be mapped to this Treatment Aggregate. RFC 4594 402 Low-priority data may be forwarded by a Lower Effort PHB in 403 one domain (like the PHB proposed by Informational 404 [RFC3662]), but is remarked with DSCP CS0 at a Diffserv- 405 Intercon network interconnection. 407 RFC2575 states that Ingress nodes must condition all inbound traffic 408 to ensure that the DS codepoints are acceptable; packets found to 409 have unacceptable codepoints must either be discarded or must have 410 their DS codepoints modified to acceptable values before being 411 forwarded. For example, an ingress node receiving traffic from a 412 domain with which no enhanced service agreement exists may reset the 413 DS codepoint to CS0. As a consequence, an interconnect SLA needs to 414 specify not only the treatment of traffic that arrives with a 415 supported interconnect DSCP, but also the treatment of traffic that 416 arrives with unsupported or unexpected DSCPs; remarking to CS0 is a 417 widely deployed behavior. 419 4.1. Diffserv-Intercon Example 421 The overall approach to DSCP marking at network interconnections is 422 illustrated by the following example. Provider O and provider W are 423 peered with provider T. They have agreed upon a QoS interconnection 424 SLA. 426 Traffic of provider O terminates within provider T's network, while 427 provider W's traffic transits through the network of provider T to 428 provider F. This example assumes taht all providers use their own 429 internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in 430 the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and 431 CS2 are used in the example). 433 Provider O Provider W 434 | | 435 +----------+ +----------+ 436 | AF21 | | CS2 | 437 +----------+ +----------+ 438 V V 439 +~~~~~~~+ +~~~~~~~+ 440 |Rtr PrO| |Rtr PrW| 441 +~~~~~~~+ +~~~~~~~+ 442 | DiffServ | 443 +----------+ +----------+ 444 | AF31 | | AF31 | 445 +----------+ +----------+ 446 V Intercon V 447 +~~~~~~~+ | 448 |RtrPrTI|------------------+ 449 +~~~~~~~+ 450 | Provider T domain 451 +------------------+ 452 | MPLS TC 2, AF21 | 453 +-----------------+ 454 | | +----------+ +~~~~~~~+ 455 V `--->| AF21 |->-|RtrDstH| 456 +----------+ +----------+ +~~~~~~~+ 457 | AF21 | Local DSCPs Provider T 458 +----------+ 459 | 460 +~~~~~~~+ 461 |RtrPrTE| 462 +~~~~~~~+ 463 | DiffServ 464 +----------+ 465 | AF31 | 466 +----------+ 467 | Intercon 468 +~~~~~~~+ 469 |RtrPrHF| 470 +~~~~~~~+ 471 | 472 +----------+ 473 | AF11 | Provider F 474 +----------+ 476 Diffserv-Intercon example 478 Figure 1 480 Providers only need to deploy mappings of internal DSCPs to/from 481 Diffserv-Intercon DSCPs in order to exchange traffic using the 482 desired PHBs. In the example, provider O has decided that the 483 properties of his internal class AF21 and are best met by the 484 Diffserv-Intercon Assured Elastic Treatment Aggregate, PHB AF31. At 485 the outgoing peering interface connecting provider O with provider T 486 the former's peering router remarks AF21 traffic to AF31. The domain 487 internal PHB of provider T meeting the requirement of Diffserv- 488 Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group. 489 Hence AF31 traffic received at the interconnection with provider T is 490 remarked to AF21 by the peering router of domain T, and domain T has 491 chosen to use MPLS Traffic Class value 2 for this aggregate. At the 492 penultimate MPLS node, the top MPLS label is removed and exposes the 493 IP header marked by the DSCP which has been set at the network 494 ingress. The peering router connecting domain T with domain F 495 classifies the packet by its domain-T-internal DSCP AF21. As the 496 packet leaves domain T on the interface to domain F, this causes the 497 packet's DSCP to be remarked to AF31. The peering router of domain F 498 classifies the packet for domain-F-internal PHB AF11, as this is the 499 PHB with properties matching Diffserv-Intercon's Assured Elastic 500 Treatment Aggregate. 502 This example can be extended. The figure shows Provider-W using CS2 503 for traffic that corresponds to Diffserv-Intercon Assured Elastic 504 Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the 505 Diffserv-Intercon interconnection to Provider-T. In addition, 506 suppose that Provider-O supports a PHB marked by AF22 and this PHB is 507 supposed to be transported by QoS within Provider-T domain. Then 508 Provider-O will remark it with DSCP AF32 for interconnection to 509 Provider-T. 511 Finally suppose that Provider-W supports CS3 for internal use only. 512 Then no Diffserv- Intercon DSCP mapping needs to be configured at the 513 peering router. Traffic, sent by Provider-W to Provider-T marked by 514 CS3 due to a misconfiguration may be remarked to CS0 by Provider-T. 516 4.2. End-to-end QoS: PHB and DS CodePoint Transparency 518 This section briefly discusses end-to-end QoS approaches related to 519 the Uniform, Pipe and Short Pipe tunnel models ([RFC2983], 520 [RFC3270]), when used edge-to-edge in a network. 522 o With the Uniform model, neither the DCSP nor the PHB change. This 523 implies that a network management packet received with a CS6 DSCP 524 would be forwarded with an MPLS Traffic Class corresponding to 525 CS6. The uniform model is outside the scope of this document. 527 o With the Pipe model, the inner tunnel DCSP remains unchanged, but 528 an outer tunnel DSCP and the PHB could changed. For example a 529 packet received with a (network specific) CS1 DSCP would be 530 transported by default PHB and if MPLS is applicable, forwarded 531 with an MPLS Traffic Class corresponding to Default PHB. The CS1 532 DSCP is not rewritten. Transport of a large variety (much greater 533 than 4) DSCPs may be required across an interconnected network 534 operating MPLS Short pipe transport for IP traffic. In that case, 535 a tunnel based on the Pipe model is among the possible approaches. 536 The Pipe model is outside the scope of this document. 538 o With the Short Pipe model, the DCSP likely changes and the PHB 539 might change. This document describes a method to simplify QoS 540 for network interconnection when a DSCP rewrite can't be avoided. 542 4.3. Treatment of Network Control traffic at carrier interconnection 543 interfaces 545 As specified by RFC4594, section 3.2, Network Control (NC) traffic 546 marked by CS6 is expected at some interconnection interfaces. This 547 document does not change RFC4594, but observes that network control 548 traffic received at network ingress is generally different from 549 network control traffic within a network that is the primary use of 550 CS6 envisioned by RFC 4594. A specific example is that some CS6 551 traffic exchanged across carrier interconnections is terminated at 552 the network ingress node, e.g. when BGP is used between the two 553 routers on opposite ends of an interconnection link; in this case the 554 operators would enter into a bilateral agreement to use CS6 for that 555 BGP traffic. 557 The end-to-end QoS discussion in the previous section (4.2) is 558 generally inapplicable to network control traffic - network control 559 traffic is generally intended to control a network, not be 560 transported across it. One exception is that network control traffic 561 makes sense for a purchased transit agreement, and preservation of 562 the CS6 DSCP marking for network control traffic that is transited is 563 reasonable in some cases, although it is generally inappropriate to 564 use CS6 for forwarding that traffic within the network that provides 565 transit. Use of an IP tunnel is suggested in order to conceal the 566 CS6 markings on transiting network control traffic from the network 567 that provides the transit. In this case, Pipe model for Diffserv 568 tunneling is used. 570 If the MPLS Short Pipe model is deployed for non-tunneled IPv4 571 traffic, an IP network provider should limit access to the CS6 and 572 CS7 DSCPs so that they are only used for network control traffic for 573 the provider's own network. 575 Interconnecting carriers should specify treatment of CS6 marked 576 traffic received at a carrier interconnection which is to be 577 forwarded beyond the ingress node. An SLA covering the following 578 cases is recommended when a provider wishes to send CS6 marked 579 traffic across an interconnection link and that traffic's destination 580 is beyond the interconnected ingress node: 582 o classification of traffic that is network control traffic for both 583 domains. This traffic should be classified and marked for the CS6 584 DSCP. 586 o classification of traffic that is network control traffic for the 587 sending domain only. This traffic should be forwarded with a PHB 588 that is appropriate for the NC service class [RFC4594], e.g. AF31 589 as specified by this document. As an example GSMA IR.34 590 recommends an Interactive class / AF31 to carry SIP and DIAMETER 591 traffic. While this is service control traffic of high importance 592 to interconnected Mobile Network Operators, it is certainly not 593 Network Control traffic for a fixed network providing transit 594 among such operators, and hence should not receive CS6 treatment 595 in such a transit network. 597 o any other CS6 marked traffic should be remarked or dropped. 599 5. Acknowledgements 601 Bob Briscoe reviewed the draft and provided rich feedback. Fred 602 Baker and Brian Carpenter provided intensive feedback and discussion. 603 Al Morton and Sebastien Jobert provided feedback on many aspects 604 during private discussions. Mohamed Boucadair and Thomas Knoll 605 helped adding awareness of related work. James Polk's discussion 606 during IETF 89 helped to improve the relation of this draft to RFC 607 4594 and RFC 5127. 609 6. IANA Considerations 611 This memo includes no request to IANA. 613 7. Security Considerations 615 This document does not introduce new features; it describes how to 616 use existing ones. The Diffserv security considerations in RFC 2475 617 [RFC2475] and RFC 4594 [RFC4594] apply. 619 8. References 621 8.1. Normative References 623 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 624 "Definition of the Differentiated Services Field (DS 625 Field) in the IPv4 and IPv6 Headers", RFC 2474, 626 DOI 10.17487/RFC2474, December 1998, 627 . 629 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 630 J., Courtney, W., Davari, S., Firoiu, V., and D. 631 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 632 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 633 . 635 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 636 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 637 Protocol Label Switching (MPLS) Support of Differentiated 638 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 639 . 641 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 642 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 643 2008, . 645 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 646 Services Code Point (DSCP) for Capacity-Admitted Traffic", 647 RFC 5865, DOI 10.17487/RFC5865, May 2010, 648 . 650 8.2. Informative References 652 [I-D.knoll-idr-cos-interconnect] 653 Knoll, T., "BGP Class of Service Interconnection", draft- 654 knoll-idr-cos-interconnect-15 (work in progress), November 655 2015. 657 [ID.ietf-idr-sla] 658 IETF, "Inter-domain SLA Exchange", IETF, 659 http://datatracker.ietf.org/doc/ 660 draft-ietf-idr-sla-exchange/, 2013. 662 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 663 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 664 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ 665 ir.34.pdf, 2012. 667 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 668 Class of Service Phase 2", MEF, MEF23.1 669 http://metroethernetforum.org/PDF_Documents/technical- 670 specifications/MEF_23.1.pdf, 2012. 672 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 673 and W. Weiss, "An Architecture for Differentiated 674 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 675 . 677 [RFC2983] Black, D., "Differentiated Services and Tunnels", 678 RFC 2983, DOI 10.17487/RFC2983, October 2000, 679 . 681 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 682 Per-Domain Behavior (PDB) for Differentiated Services", 683 RFC 3662, DOI 10.17487/RFC3662, December 2003, 684 . 686 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 687 Guidelines for DiffServ Service Classes", RFC 4594, 688 DOI 10.17487/RFC4594, August 2006, 689 . 691 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 692 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 693 February 2008, . 695 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 696 to-Provider Agreements for Internet-Scale Quality of 697 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 698 2008, . 700 [Y.1566] ITU-T, "Quality of service mapping and interconnection 701 between Ethernet, IP and multiprotocol label switching 702 networks", ITU, 703 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 705 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 707 The MPLS Short Pipe Model (or penultimate Hop Label Popping) is 708 widely deployed in carrier networks. If non-tunneled IPv4 traffic is 709 transported using MPLS Short Pipe, IP headers appear inside the last 710 section of the MPLS domain. This impacts the number of PHBs and 711 DSCPs that a network provider can reasonably support . See Figure 2 712 (below) for an example. 714 For tunneled IPv4 traffic, only the outer tunnel header is relevant 715 for forwarding. If the tunnel does not terminate within the MPLS 716 network section, only the outer tunnel DSCP is involved, as the inner 717 DSCP does not affect forwarding behavior; in this case all DSCPs 718 could be used in the inner IP header without affecting network 719 behavior based on the outer MPLS header. Here the Pipe model 720 applies. 722 Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic 723 all use an additional MPLS label; in this case, the MPLS tunnel 724 follows the Pipe model. Classification and queuing within an MPLS 725 network is always based on an MPLS label, as opposed to the outer IP 726 header. 728 Carriers often select QoS PHBs and DSCP without regard to 729 interconnection. As a result PHBs and DSCPs typically differ between 730 network carriers. With the exception of best effort traffic, a DSCP 731 change should be expected at an interconnection at least for plain IP 732 traffic, even if the PHB is suitably mapped by the carriers involved. 734 Although RFC3270 suggests that the Short Pipe Model is only 735 applicable to VPNs, current networks also use it to transport non- 736 tunneled IPv4 traffic. This is shown in figure 2 where Diffserv- 737 Intercon is not used, resulting in exposure of the internal DSCPs of 738 the upstream network to the downstream network across the 739 interconnection. 741 | 742 \|/ IPv4, DSCP_send 743 V 744 | 745 Peering Router 746 | 747 \|/ IPv4, DSCP_send 748 V 749 | 750 MPLS Edge Router 751 | Mark MPLS Label, TC_internal 752 \|/ Remark DSCP to 753 V (Inner: IPv4, DSCP_d) 754 | 755 MPLS Core Router (penultimate hop label popping) 756 | \ 757 | IPv4, DSCP_d | The DSCP needs to be in network- 758 | ^^^^^^^^| internal QoS context. The Core 759 \|/ > Router may require or enforce 760 V | that. The Edge Router may wrongly 761 | | classify, if the DSCP is not in 762 | / network-internal Diffserv context. 763 MPLS Edge Router 764 | \ Traffic leaves the network marked 765 \|/ IPv4, DSCP_d | with the network-internal 766 V > DSCP_d that must be dealt with 767 | | by the next network (downstream). 768 | / 769 Peer Router 770 | Remark DSCP to 771 \|/ IPv4, DSCP_send 772 V 773 | 775 Short-Pipe / penultimate hop popping example 777 Figure 2 779 The packets IP DSCP must be in a well understood Diffserv context for 780 schedulers and classifiers on the interfaces of the ultimate MPLS 781 link (last link traversed before leaving the network). The necessary 782 Diffserv context is network-internal and a network operating in this 783 mode enforces DSCP usage in order to obtain robust QoS behavior. 785 Without Diffserv-Intercon treatment, the traffic is likely to leave 786 each network marked with network-internal DSCP. DSCP_send in the 787 figure above has to be remarked into the first network's Diffserv 788 scheme at the ingress MPLS Edge Router, to DSCP_d in the example. 789 For that reason, the traffic leaves this domain marked by the 790 network-internal DSCP_d. This structure requires that every carrier 791 deploys per-peer PHB and DSCP mapping schemes. 793 If Diffserv-Intercon is applied DSCPs for traffic transiting the 794 domain can be mapped from and remapped to an original DSCP. This is 795 shown in figure 3. Internal traffic may continue to use internal 796 DSCPs (e.g, DSCP_d) and they may also be used between a carrier and 797 its direct customers. 799 Internal Router 800 | 801 | Outer Header 802 \|/ IPv4, DSCP_send 803 V 804 | 805 Peering Router 806 | Remark DSCP to 807 \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB 808 V 809 | 810 MPLS Edge Router 811 | 812 | Mark MPLS Label, TC_internal 813 \|/ Remark DSCP to 814 V (Inner: IPv4, DSCP_d) domain internal DSCP for 815 | the PHB 816 MPLS Core Router (penultimate hop label popping) 817 | 818 | IPv4, DSCP_d 819 | ^^^^^^ 820 \|/ 821 V 822 | 823 | 824 MPLS Edge Router--------------------+ 825 | | 826 \|/ Remark DSCP to \|/ IPv4, DSCP_d 827 V IPv4, DSCP_ds-int V 828 | | 829 | | 830 Peer Router Domain internal Broadband 831 | Access Router 832 \|/ Remark DSCP to \|/ 833 V IPv4, DSCP_send V IPv4, DSCP_d 834 | | 836 Short-Pipe example with Diffserv-Intercon 838 Figure 3 840 Appendix B. Change log (to be removed by the RFC editor) 842 00 to 01 Added an Applicability Statement. Put the main part of the 843 RFC5127 related discussion into a separate chapter. 845 01 to 02 More emphasis on the Short-Pipe tunel model as compared to 846 Pipe and Uniform tunnel models. Further editorial 847 improvements. 849 02 to 03 Suggestions how to remark all RFC4594 classes to Diffserv- 850 Intercon classes at interconnection. 852 03 to 04 Minor clarifications and editorial review, preparation for 853 WGLC. 855 Authors' Addresses 857 Ruediger Geib (editor) 858 Deutsche Telekom 859 Heinrich Hertz Str. 3-7 860 Darmstadt 64295 861 Germany 863 Phone: +49 6151 5812747 864 Email: Ruediger.Geib@telekom.de 866 David L. Black 867 EMC Corporation 868 176 South Street 869 Hopkinton, MA 870 USA 872 Phone: +1 (508) 293-7953 873 Email: david.black@emc.com