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