idnits 2.17.1 draft-ietf-tsvwg-diffserv-intercon-09.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 (August 28, 2016) is 2795 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'L' is mentioned on line 448, but not defined == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-16 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 0 errors (**), 0 flaws (~~), 4 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: March 1, 2017 EMC Corporation 6 August 28, 2016 8 Diffserv-Interconnection classes and practice 9 draft-ietf-tsvwg-diffserv-intercon-09 11 Abstract 13 This document defines 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 March 1, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 document defines a set of common 86 Diffserv 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, RFC 2474 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 DSCP value 112 with which it was received, 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 a defined set of interconnection PHBs and DSCPs 117 may appear to be additional effort for a network operator. The 118 primary offsetting benefit is that mapping from or to the 119 interconnection PHBs and DSCPs is specified once for all of the 120 interconnections to other networks that can use this approach. 121 Absent this approach, the PHBs and DSCPs have to be negotiated and 122 configured independently for each network interconnection, which has 123 poor administrative and operational scaling properties. Further, 124 consistent end-to-end QoS treatment is more likely to result when an 125 interconnection code point scheme is used because traffic is remarked 126 to the same PHBs at all 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. The 133 solution described here can be used in other contexts benefitting 134 from a defined interconnection QoS interface. 136 The basic idea is that traffic sent with a Diffserv-Interconnect PHB 137 and DSCP is restored to that PHB and DSCP at each network 138 interconnection, even though a different PHB and DSCP may be used by 139 each network involved. The key requirement is that the network 140 ingress interconnect DSCP be restored at network egress, and a key 141 observation is that this is only feasible in general for a small 142 number of DSCPs. Traffic sent with other DSCPs can be remarked to an 143 interconnect DSCP or dealt with via additional agreement(s) among the 144 operators of the interconnected networks; remarking in the absence of 145 additional agreement(s) when the MPLS Short Pipe model is used for 146 reasons explained in this document. 148 In addition to the common interconnecting PHBs and DSCPs, 149 interconnecting operators need to further agree on the tunneling 150 technology used for interconnection (e.g., MPLS, if used) and control 151 or mitigate the impacts of tunneling on reliability and MTU. 153 1.1. Related work 155 In addition to the activities that triggered this work, there are 156 additional RFCs and Internet-drafts that may benefit from an 157 interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS- 158 Classes to enable deployment of standardized end to end QoS classes 159 [RFC5160]. The Diffserv-Intercon class- and codepoint scheme is 160 intended to complement that work (e.g. by enabling a defined set of 161 end-to-end QoS service classes). 163 BGP signaling Class of Service at interconnection interfaces by BGP 164 [I-D.knoll-idr-cos-interconnect], [ID.ietf-idr-sla] is complementary 165 to Diffserv-Intercon. These two BGP documents focus on exchanging 166 SLA and traffic conditioning parameters and assume that common PHBs 167 identified by the signaled DSCPs have been established (e.g., via use 168 of the Diffserv-Intercon DSCPs) prior to BGP signaling of QoS. 170 1.2. Applicability Statement 172 This document is applicable to use of Differentiated Services for 173 interconnection traffic between networks, and in particular to 174 interconnection of MPLS-based networks. This document is not 175 intended for use within an individual network, where the approach 176 specified in RFC 5127 [RFC5127] is among the possible alternatives; 177 see Section 3 for further discussion. 179 The Diffserv-Intercon approach described in this document simplifies 180 IP based interconnection to domains operating the MPLS Short Pipe 181 model for IP traffic, both terminating within the domain and 182 transiting onward to another domain. Transiting traffic is received 183 and sent with the same PHB and DSCP. Terminating traffic maintains 184 the PHB with which it was received, however the DSCP may change. 186 Diffserv-Intercon may also be applied to the Pipe tunneling model 187 [RFC2983], [RFC3270], but is not applicable to the Uniform tunneling 188 model [RFC2983], [RFC3270]. 190 1.3. Document Organization 192 This document is organized as follows: section 2 reviews the MPLS 193 Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because 194 effective support for that model is a crucial goal of Diffserv- 195 Intercon. Section 3 provides background on RFC 5127's approach to 196 traffic class aggregation within a Diffserv network domain and 197 contrasts it with the Diffserv-Intercon approach. Section 4 198 introduces Diffserv-Interconnection Treatment Aggregates, along with 199 the PHBs and DSCPs that they use, and explains how other PHBs (and 200 associated DSCPs) may be mapped to these Treatment Aggregates. 201 Section 4 also discusses treatment of non-tunneled and tunneled IP 202 traffic and MPLS VPN QoS considerations and handling of high-priority 203 Network Management traffic is described. Appendix A describes how 204 the MPLS Short Pipe model (penultimate hop popping) impacts QoS and 205 DSCP marking for IP interconnections. 207 2. MPLS and the Short Pipe tunnel model 209 The Pipe and Uniform models for Differentiated Services and Tunnels 210 are defined in [RFC2983]. RFC 3270 adds the Short Pipe model in 211 order to support MPLS penultimate hop popping (PHP) of Labels, 212 primarily for MPLS-based IP tunnels and VPNs. The Short Pipe model 213 and PHP have subsequently become popular with network providers that 214 operate MPLS networks and are now widely used to transport non- 215 tunneled IP traffic, not just traffic encapsulated in IP tunnels and 216 VPNs. This has important implications for Diffserv functionality in 217 MPLS networks. 219 RFC 2474's recommendation to forward traffic with unrecognized DSCPs 220 with Default (best effort) service without rewriting the DSCP has 221 proven to be a poor operational practice. Network operation and 222 management are simplified when there is a 1-1 match between the DSCP 223 marked on the packet and the forwarding treatment (PHB) applied by 224 network nodes. When this is done, CS0 (the all-zero DSCP) is the 225 only DSCP used for Default forwarding of best effort traffic, and a 226 common practice is to remark to CS0 any traffic received with 227 unrecognized or unsupported DSCPs at network edges. 229 MPLS networks are more subtle in this regard, as it is possible to 230 encode the provider's DSCP in the MPLS Traffic Class (TC) field and 231 allow that to differ from the PHB indicated by the DSCP in the MPLS- 232 encapsulated IP packet. If the MPLS label with the provider's TC 233 field is present at all hops within the provider network, this 234 approach would allow an unrecognized DSCP to be carried edge-to-edge 235 over an MPLS network, because the effective DSCP used by the 236 provider's MPLS network would be encoded in the MPLS label TC field 237 (and also carried edge-to-edge). Unfortunately this is only true for 238 the Pipe tunnel model. 240 The Short Pipe tunnel model and PHP behave differently because PHP 241 removes and discards the MPLS provider label carrying the provider's 242 TC field before the traffic exits the provider's network. That 243 discard occurs one hop upstream of the MPLS tunnel endpoint (which is 244 usually at the network edge), resulting in no provider TC info being 245 available at tunnel egress. To ensure consistent handling of traffic 246 at the tunnel egress, the DSCP field in the MPLS-encapsulated IP 247 header has to contain a DSCP that is valid for the provider's 248 network, so that IP header cannot be used to carry a different DSCP 249 edge-to-edge. See Appendix A for a more detailed discussion. 251 3. Relationship to RFC 5127 253 This document draws heavily upon RFC 5127's approach to aggregation 254 of Diffserv traffic classes for use within a network, but there are 255 important differences caused by characteristics of network 256 interconnects that differ from links within a network. 258 3.1. RFC 5127 Background 260 Many providers operate MPLS-based backbones that employ backbone 261 traffic engineering to ensure that if a major link, switch, or router 262 fails, the result will be a routed network that continues to 263 function. Based on that foundation, [RFC5127] introduced the concept 264 of Diffserv Treatment Aggregates, which enable traffic marked with 265 multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC) 266 based on robust provider backbone traffic engineering. This enables 267 differentiated forwarding behaviors within a domain in a fashion that 268 does not consume a large number of MPLS Traffic Classes. 270 RFC 5127 provides an example aggregation of Diffserv service classes 271 into 4 Treatment Aggregates. A small number of aggregates are used 272 because: 274 o The available coding space for carrying QoS information (e.g., 275 Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and 276 is intended for more than just QoS purposes (see e.g. [RFC5129]). 278 o The common interconnection DSCPs ought not to use all 8 possible 279 values. This leaves space for future standards, for private 280 bilateral agreements and for local use PHBs and DSCPs. 282 o Migrations from one Diffserv code point scheme to a different one 283 is another possible application of otherwise unused QoS code 284 points. 286 3.2. Differences from RFC 5127 288 Like RFC 5127, this document also uses four traffic aggregates, but 289 differs from RFC 5127 in some important ways: 291 o It follows RFC 2475 in allowing the DSCPs used within a network to 292 differ from those to exchange traffic with other networks (at 293 network edges), but provides support to restore ingress DSCP 294 values if one of the recommended interconnect DSCPs in this draft 295 is used. This results in DSCP remarking at both network ingress 296 and network egress, and this draft assumes that such remarking at 297 network edges is possible for all interface types. 299 o Diffserv-Intercon suggests limiting the number of interconnection 300 PHBs per Treatment Aggregate to the minimum required. As further 301 discussed below, the number of PHBs per Treatment Aggreagate is no 302 more than two. When two PHBs are specified for a Diffserv- 303 Intercon treatment aggregate, the expectation is that the provider 304 network supports DSCPs for both PHBs, but uses a single MPLS TC 305 for the Treatment Aggregate that contains the two PHBs. 307 o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the 308 interconnection Treatment Aggregates as further discussed below. 310 o Diffserv-Intercon treats network control traffic as a special 311 case. Within a provider's network, the CS6 DSCP is used for local 312 network control traffic (routing protocols and OAM traffic that is 313 essential to network operation administration, control and 314 management) that may be destined for any node within the network. 315 In contrast, network control traffic exchanged between networks 316 (e.g., BGP) usually terminates at or close to a network edge, and 317 is not forwarded through the network because it is not part of 318 internal routing or OAM for the receiving network. In addition, 319 such traffic is unlikely to be covered by standard interconnection 320 agreements; rather, it is more likely to be specifically 321 configured (e.g., most networks impose restrictions on use of BGP 322 with other networks for obvious reasons). See Section 4.2 for 323 further discussion. 325 o Because RFC 5127 used a Treatment Aggregate for network control 326 traffic, Diffserv-Intercon can instead define a fourth traffic 327 aggregate to be defined for use at network interconnections 328 instead of the Network Control aggregate in RFC 5127. Network 329 Control traffic may still be exchanged across network 330 interconnections as further discussed in Section 4.2. Diffserv- 331 Intercon uses this fourth traffic aggregate for VoIP traffic, 332 where network-provided QoS is crucial, as even minor glitches are 333 immediately apparent to the humans involved in the conversation. 335 4. The Diffserv-Intercon Interconnection Classes 337 At an interconnection, the networks involved need to agree on the 338 PHBs used for interconnection and the specific DSCP for each PHB. 339 This document defines a set of 4 interconnection Treatment Aggregates 340 with well-defined DSCPs to be aggregated by them. A sending party 341 remarks DSCPs from internal schemes to the interconnection code 342 points. The receiving party remarks DSCPs to their internal scheme. 343 The interconnect SLA defines the set of DSCPs and PHBs supported 344 across the two interconnected domains and the treatment of PHBs and 345 DSCPs that are not recognized by the receiving domain. 347 Similar approaches that 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]and 359 [RFC5865]. This Treatment Aggregate corresponds to RFC 5127s 360 real time Treatment Aggregate definition regarding the 361 queuing (both delay and jitter should be minimized), but this 362 aggregate is restricted to transport Telephony Service Class 363 traffic in 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 This traffic is expected to consist of the RFC 4594 classes 373 Broadcast Video, Real-Time Interactive and Multimedia 374 Conferencing. This treatment aggregate should be configured 375 with a rate queue (consistent with RFC 4594's recommendation 376 for the transported traffic classes). By comparison to RFC 377 5127, the number of DSCPs has been reduced to one 378 (initially). The AF42 and AF43 PHBs could be added if there 379 is a need for three-color marked Multimedia. 381 Assured Elastic Treatment Aggregate This Treatment Aggregate 382 consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011 383 100). By comparison to RFC 5127, the number of DSCPs has 384 been reduced to two. This document suggests to transport 385 signaling marked by AF31 (e.g. as recommended by GSMA IR.34 386 [IR.34]). AF33 is reserved for extension of PHBs to be 387 aggregated by this TA. For Diffserv-Intercon network 388 interconnection, the following RFC 4594 service classes 389 should be mapped to the Assured Elastic Treatment Aggregate: 390 the Signaling Service Class (being marked for lowest loss 391 probability), Multimedia Streaming Service Class, the Low- 392 Latency Data Service Class and the High-Throughput Data 393 Service Class. 395 Default / Elastic Treatment Aggregate: transports the default PHB, 396 CS0 with DSCP 000 000. RFC 5127 example refers to this 397 Treatment Aggregate as Aggregate Elastic. An important 398 difference from RFC 5127 is that any traffic with 399 unrecognized or unsupported DSCPs may be remarked to this 400 DSCP. For Diffserv-Intercon network interconnection, the RFC 401 4594 standard service class and Low-priority Data service 402 class should be mapped to this Treatment Aggregate. This 403 document does not specify an interconnection class for RFC 404 4594 Low-priority data. This data may be forwarded by a 405 Lower Effort PHB in one domain (like the PHB proposed by 406 Informational [RFC3662]), but using the methods specified in 407 this document will be remarked with DSCP CS0 at a Diffserv- 408 Intercon network interconnection. This has the effect that 409 Low-priority data is treated the same as data sent using the 410 default class. (Note: In a network that implements RFC 2474, 411 Low-priority traffic marked as CS1 would otherwise receive 412 better treatment than traffic using the default class.) 414 RFC 2475 states that Ingress nodes must condition all inbound traffic 415 to ensure that the DS codepoints are acceptable; packets found to 416 have unacceptable codepoints must either be discarded or must have 417 their DS codepoints modified to acceptable values before being 418 forwarded. For example, an ingress node receiving traffic from a 419 domain with which no enhanced service agreement exists may reset the 420 DS codepoint to CS0. As a consequence, an interconnect SLA needs to 421 specify not only the treatment of traffic that arrives with a 422 supported interconnect DSCP, but also the treatment of traffic that 423 arrives with unsupported or unexpected DSCPs; remarking to CS0 is a 424 widely deployed behavior. 426 4.1. Diffserv-Intercon Example 428 The overall approach to DSCP marking at network interconnections is 429 illustrated by the following example. Provider O and provider W are 430 peered with provider T. They have agreed upon a QoS interconnection 431 SLA. 433 Traffic of provider O terminates within provider T's network, while 434 provider W's traffic transits through the network of provider T to 435 provider F. This example assumes that all providers use their own 436 internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in 437 the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and 438 CS2 are used in the example). 440 Provider O Provider W 441 | | 442 +----------+ +----------+ 443 | AF21 | | CS2 | 444 +----------+ +----------+ 445 V V 446 +~~~~~~~+ +~~~~~~~+ 447 |Rtr PrO| |Rtr PrW| Rtr: Router 448 +~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L] 449 | DiffServ | 450 +----------+ +----------+ 451 | AF31 | | AF31 | 452 +----------+ +----------+ 453 V Intercon V 454 +~~~~~~~+ | 455 |RtrPrTI|------------------+ Router Provider T Ingress 456 +~~~~~~~+ 457 | Provider T domain 458 +------------------+ 459 | MPLS TC 2, AF21 | 460 +------------------+ 461 | | +----------+ +~~~~~~~+ 462 V `--->| AF21 |->-|RtrDstH| Router Destination Host 463 +----------+ +----------+ +~~~~~~~+ 464 | AF21 | Local DSCPs Provider T 465 +----------+ 466 | 467 +~~~~~~~+ 468 |RtrPrTE| Router Provider T Egress 469 +~~~~~~~+ 470 | DiffServ 471 +----------+ 472 | AF31 | 473 +----------+ 474 | Intercon 475 +~~~~~~~+ 476 |RtrPrF | Router Provider F 477 +~~~~~~~+ 478 | 479 +----------+ 480 | AF11 | Provider F 481 +----------+ 483 Diffserv-Intercon example 485 Figure 1 487 Providers only need to deploy mappings of internal DSCPs to/from 488 Diffserv-Intercon DSCPs in order to exchange traffic using the 489 desired PHBs. In the example, provider O has decided that the 490 properties of his internal class AF21 are best met by the Diffserv- 491 Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the 492 outgoing peering interface connecting provider O with provider T the 493 former's peering router remarks AF21 traffic to AF31. The domain 494 internal PHB of provider T meeting the requirement of Diffserv- 495 Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group. 496 Hence AF31 traffic received at the interconnection with provider T is 497 remarked to AF21 by the peering router of domain T, and domain T has 498 chosen to use MPLS Traffic Class value 2 for this aggregate. At the 499 penultimate MPLS node, the top MPLS label is removed and exposes the 500 IP header marked by the DSCP which has been set at the network 501 ingress. The peering router connecting domain T with domain F 502 classifies the packet by its domain-T-internal DSCP AF21. As the 503 packet leaves domain T on the interface to domain F, this causes the 504 packet's DSCP to be remarked to AF31. The peering router of domain F 505 classifies the packet for domain-F-internal PHB AF11, as this is the 506 PHB with properties matching Diffserv-Intercon's Assured Elastic 507 Treatment Aggregate. 509 This example can be extended. The figure shows Provider-W using CS2 510 for traffic that corresponds to Diffserv-Intercon Assured Elastic 511 Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the 512 Diffserv-Intercon interconnection to Provider-T. In addition, 513 suppose that Provider-O supports a PHB marked by AF22 and this PHB is 514 supposed to be transported by QoS within Provider-T domain. Then 515 Provider-O will remark it with DSCP AF32 for interconnection to 516 Provider-T. 518 Finally suppose that Provider-W supports CS3 for internal use only. 519 Then no Diffserv- Intercon DSCP mapping needs to be configured at the 520 peering router. Traffic, sent by Provider-W to Provider-T marked by 521 CS3 due to a misconfiguration may be remarked to CS0 by Provider-T. 523 4.2. End-to-end QoS: PHB and DS CodePoint Transparency 525 This section briefly discusses end-to-end QoS approaches related to 526 the Uniform, Pipe and Short Pipe tunnel models ([RFC2983], 527 [RFC3270]), when used edge-to-edge in a network. 529 o With the Uniform model, neither the DCSP nor the PHB change. This 530 implies that a network management packet received with a CS6 DSCP 531 would be forwarded with an MPLS Traffic Class corresponding to 532 CS6. The uniform model is outside the scope of this document. 534 o With the Pipe model, the inner tunnel DCSP remains unchanged, but 535 an outer tunnel DSCP and the PHB could changed. For example a 536 packet received with a (network specific) CS1 DSCP would be 537 transported by default PHB and if MPLS is applicable, forwarded 538 with an MPLS Traffic Class corresponding to Default PHB. The CS1 539 DSCP is not rewritten. Transport of a large variety (much greater 540 than 4) DSCPs may be required across an interconnected network 541 operating MPLS Short pipe transport for IP traffic. In that case, 542 a tunnel based on the Pipe model is among the possible approaches. 543 The Pipe model is outside the scope of this document. 545 o With the Short Pipe model, the DCSP likely changes and the PHB 546 might change. This document describes a method to simplify QoS 547 for network interconnection when a DSCP rewrite can't be avoided. 549 4.3. Treatment of Network Control traffic at carrier interconnection 550 interfaces 552 As specified by RFC 4594, section 3.2, Network Control (NC) traffic 553 marked by CS6 is expected at some interconnection interfaces. This 554 document does not change RFC 4594, but observes that network control 555 traffic received at network ingress is generally different from 556 network control traffic within a network that is the primary use of 557 CS6 envisioned by RFC 4594. A specific example is that some CS6 558 traffic exchanged across carrier interconnections is terminated at 559 the network ingress node, e.g. when BGP is used between the two 560 routers on opposite ends of an interconnection link; in this case the 561 operators would enter into a bilateral agreement to use CS6 for that 562 BGP traffic. 564 The end-to-end QoS discussion in the previous section (4.2) is 565 generally inapplicable to network control traffic - network control 566 traffic is generally intended to control a network, not be 567 transported between networks. One exception is that network control 568 traffic makes sense for a purchased transit agreement, and 569 preservation of the CS6 DSCP marking for network control traffic that 570 is transited is reasonable in some cases, although it is generally 571 inappropriate to use CS6 for forwarding that traffic within the 572 network that provides transit. Use of an IP tunnel is suggested in 573 order to conceal the CS6 markings on transiting network control 574 traffic from the network that provides the transit. In this case, 575 Pipe model for Diffserv tunneling is used. 577 If the MPLS Short Pipe model is deployed for non-tunneled IPv4 578 traffic, an IP network provider should limit access to the CS6 and 579 CS7 DSCPs so that they are only used for network control traffic for 580 the provider's own network. 582 Interconnecting carriers should specify treatment of CS6 marked 583 traffic received at a carrier interconnection which is to be 584 forwarded beyond the ingress node. An SLA covering the following 585 cases is recommended when a provider wishes to send CS6 marked 586 traffic across an interconnection link and that traffic's destination 587 is beyond the interconnected ingress node: 589 o classification of traffic that is network control traffic for both 590 domains. This traffic should be classified and marked for the CS6 591 DSCP. 593 o classification of traffic that is network control traffic for the 594 sending domain only. This traffic should be forwarded with a PHB 595 that is appropriate for the NC service class [RFC4594], e.g. AF31 596 as specified by this document. As an example GSMA IR.34 597 recommends an Interactive class / AF31 to carry SIP and DIAMETER 598 traffic. While this is service control traffic of high importance 599 to interconnected Mobile Network Operators, it is certainly not 600 Network Control traffic for a fixed network providing transit 601 among such operators, and hence should not receive CS6 treatment 602 in such a transit network. 604 o any other CS6 marked traffic should be remarked or dropped. 606 5. Acknowledgements 608 Bob Briscoe and Gorry Fairhurst reviewed the draft and provided rich 609 feedback. Fred Baker, Brian Carpenter, Al Morton and Sebastien 610 Jobert discussed the draft and helped improving it. Mohamed 611 Boucadair and Thomas Knoll helped adding awareness of related work. 612 James Polk's discussion during IETF 89 helped to improve the text on 613 the relation of this draft to RFC 4594 and RFC 5127. 615 6. IANA Considerations 617 This memo includes no request to IANA. 619 7. Security Considerations 621 This document does not introduce new features; it describes how to 622 use existing ones. The Diffserv security considerations in RFC 2475 623 [RFC2475] and RFC 4594 [RFC4594] apply. 625 8. References 626 8.1. Normative References 628 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 629 "Definition of the Differentiated Services Field (DS 630 Field) in the IPv4 and IPv6 Headers", RFC 2474, 631 DOI 10.17487/RFC2474, December 1998, 632 . 634 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 635 J., Courtney, W., Davari, S., Firoiu, V., and D. 636 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 637 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 638 . 640 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 641 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 642 Protocol Label Switching (MPLS) Support of Differentiated 643 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 644 . 646 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 647 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 648 2008, . 650 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 651 Services Code Point (DSCP) for Capacity-Admitted Traffic", 652 RFC 5865, DOI 10.17487/RFC5865, May 2010, 653 . 655 8.2. Informative References 657 [I-D.knoll-idr-cos-interconnect] 658 Knoll, T., "BGP Class of Service Interconnection", draft- 659 knoll-idr-cos-interconnect-16 (work in progress), May 660 2016. 662 [ID.ietf-idr-sla] 663 IETF, "Inter-domain SLA Exchange", IETF, 664 http://datatracker.ietf.org/doc/ 665 draft-ietf-idr-sla-exchange/, 2013. 667 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 668 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 669 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ 670 ir.34.pdf, 2012. 672 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 673 Class of Service Phase 2", MEF, MEF23.1 674 http://metroethernetforum.org/PDF_Documents/technical- 675 specifications/MEF_23.1.pdf, 2012. 677 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 678 and W. Weiss, "An Architecture for Differentiated 679 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 680 . 682 [RFC2983] Black, D., "Differentiated Services and Tunnels", 683 RFC 2983, DOI 10.17487/RFC2983, October 2000, 684 . 686 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 687 Per-Domain Behavior (PDB) for Differentiated Services", 688 RFC 3662, DOI 10.17487/RFC3662, December 2003, 689 . 691 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 692 Guidelines for DiffServ Service Classes", RFC 4594, 693 DOI 10.17487/RFC4594, August 2006, 694 . 696 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 697 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 698 February 2008, . 700 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 701 to-Provider Agreements for Internet-Scale Quality of 702 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 703 2008, . 705 [Y.1566] ITU-T, "Quality of service mapping and interconnection 706 between Ethernet, IP and multiprotocol label switching 707 networks", ITU, 708 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 710 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 712 The MPLS Short Pipe Model (or penultimate Hop Label Popping) is 713 widely deployed in carrier networks. If non-tunneled IPv4 traffic is 714 transported using MPLS Short Pipe, IP headers appear inside the last 715 section of the MPLS domain. This impacts the number of PHBs and 716 DSCPs that a network provider can reasonably support. See Figure 2 717 (below) for an example. 719 For tunneled IPv4 traffic, only the outer tunnel header is relevant 720 for forwarding. If the tunnel does not terminate within the MPLS 721 network section, only the outer tunnel DSCP is involved, as the inner 722 DSCP does not affect forwarding behavior; in this case all DSCPs 723 could be used in the inner IP header without affecting network 724 behavior based on the outer MPLS header. Here the Pipe model 725 applies. 727 Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic 728 all use an additional MPLS label; in this case, the MPLS tunnel 729 follows the Pipe model. Classification and queuing within an MPLS 730 network is always based on an MPLS label, as opposed to the outer IP 731 header. 733 Carriers often select QoS PHBs and DSCP without regard to 734 interconnection. As a result PHBs and DSCPs typically differ between 735 network carriers. With the exception of best effort traffic, a DSCP 736 change should be expected at an interconnection at least for non- 737 tunneled IP traffic, even if the PHB is suitably mapped by the 738 carriers involved. 740 Although RFC 3270 suggests that the Short Pipe Model is only 741 applicable to VPNs, current networks also use it to transport non- 742 tunneled IPv4 traffic. This is shown in figure 2 where Diffserv- 743 Intercon is not used, resulting in exposure of the internal DSCPs of 744 the upstream network to the downstream network across the 745 interconnection. 747 | 748 \|/ IPv4, DSCP_send 749 V 750 | 751 Peering Router 752 | 753 \|/ IPv4, DSCP_send 754 V 755 | 756 MPLS Edge Router 757 | Mark MPLS Label, TC_internal 758 \|/ Remark DSCP to 759 V (Inner: IPv4, DSCP_d) 760 | 761 MPLS Core Router (penultimate hop label popping) 762 | \ 763 | IPv4, DSCP_d | The DSCP needs to be in network- 764 | ^^^^^^^^| internal QoS context. The Core 765 \|/ > Router may require or enforce 766 V | that. The Edge Router may wrongly 767 | | classify, if the DSCP is not in 768 | / network-internal Diffserv context. 769 MPLS Edge Router 770 | \ Traffic leaves the network marked 771 \|/ IPv4, DSCP_d | with the network-internal 772 V > DSCP_d that must be dealt with 773 | | by the next network (downstream). 774 | / 775 Peer Router 776 | Remark DSCP to 777 \|/ IPv4, DSCP_send 778 V 779 | 781 Short-Pipe / penultimate hop popping example 783 Figure 2 785 The packets IP DSCP must be in a well understood Diffserv context for 786 schedulers and classifiers on the interfaces of the ultimate MPLS 787 link (last link traversed before leaving the network). The necessary 788 Diffserv context is network-internal and a network operating in this 789 mode enforces DSCP usage in order to obtain robust QoS behavior. 791 Without Diffserv-Intercon treatment, the traffic is likely to leave 792 each network marked with network-internal DSCP. DSCP_send in the 793 figure above has to be remarked into the first network's Diffserv 794 scheme at the ingress MPLS Edge Router, to DSCP_d in the example. 795 For that reason, the traffic leaves this domain marked by the 796 network-internal DSCP_d. This structure requires that every carrier 797 deploys per-peer PHB and DSCP mapping schemes. 799 If Diffserv-Intercon is applied DSCPs for traffic transiting the 800 domain can be mapped from and remapped to an original DSCP. This is 801 shown in figure 3. Internal traffic may continue to use internal 802 DSCPs (e.g, DSCP_d) and they may also be used between a carrier and 803 its direct customers. 805 Internal Router 806 | 807 | Outer Header 808 \|/ IPv4, DSCP_send 809 V 810 | 811 Peering Router 812 | Remark DSCP to 813 \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB 814 V 815 | 816 MPLS Edge Router 817 | 818 | Mark MPLS Label, TC_internal 819 \|/ Remark DSCP to 820 V (Inner: IPv4, DSCP_d) domain internal DSCP for 821 | the PHB 822 MPLS Core Router (penultimate hop label popping) 823 | 824 | IPv4, DSCP_d 825 | ^^^^^^ 826 \|/ 827 V 828 | 829 | 830 MPLS Edge Router--------------------+ 831 | | 832 \|/ Remark DSCP to \|/ IPv4, DSCP_d 833 V IPv4, DSCP_ds-int V 834 | | 835 | | 836 Peer Router Domain internal Broadband 837 | Access Router 838 \|/ Remark DSCP to \|/ 839 V IPv4, DSCP_send V IPv4, DSCP_d 840 | | 842 Short-Pipe example with Diffserv-Intercon 844 Figure 3 846 Appendix B. Change log (to be removed by the RFC editor) 848 00 to 01 Added an Applicability Statement. Put the main part of the 849 RFC 5127 related discussion into a separate chapter. 851 01 to 02 More emphasis on the Short-Pipe tunel model as compared to 852 Pipe and Uniform tunnel models. Further editorial 853 improvements. 855 02 to 03 Suggestions how to remark all RFC 4594 classes to Diffserv- 856 Intercon classes at interconnection. 858 03 to 04 Minor clarifications and editorial review, preparation for 859 WGLC. 861 Authors' Addresses 863 Ruediger Geib (editor) 864 Deutsche Telekom 865 Heinrich Hertz Str. 3-7 866 Darmstadt 64295 867 Germany 869 Phone: +49 6151 5812747 870 Email: Ruediger.Geib@telekom.de 872 David L. Black 873 EMC Corporation 874 176 South Street 875 Hopkinton, MA 876 USA 878 Phone: +1 (508) 293-7953 879 Email: david.black@emc.com