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