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