idnits 2.17.00 (12 Aug 2021) /tmp/idnits26330/draft-ietf-tsvwg-diffserv-intercon-03.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2015) is 2408 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC3260' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q' is defined on line 732, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-14 -- 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: April 18, 2016 EMC Corporation 6 October 16, 2015 8 Diffserv interconnection classes and practice 9 draft-ietf-tsvwg-diffserv-intercon-03 11 Abstract 13 This document proposes a limited set of Diffserv PHBs and codepoints 14 to be applied at (inter)connections of two separately administered 15 and operated networks. Many network providers operate MPLS using 16 Treatment Aggregates for traffic marked with different Diffserv PHBs, 17 and use MPLS for interconnection with other networks. This document 18 offers a simple interconnection approach that may simplify operation 19 of Diffserv for network interconnection among providers that use MPLS 20 and apply the Short-Pipe tunnel mode. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 18, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 59 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 60 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 4 61 3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 6 62 3.1. RFC 5127 Background . . . . . . . . . . . . . . . . . . . 6 63 3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 6 64 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 7 65 4.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 12 66 4.2. Treatment of Network Control traffic at carrier 67 interconnection interfaces . . . . . . . . . . . . . . . 13 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 8.2. Informative References . . . . . . . . . . . . . . . . . 16 74 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 17 75 Appendix B. Change log (to be removed by the RFC editor) . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 78 1. Introduction 80 Diffserv has been deployed in many networks. As described by section 81 2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a 82 Diffserv feature [RFC2475]. This draft proposes a set of standard 83 QoS classes and code points at interconnection points to which and 84 from which locally used classes and code points should be mapped. 86 RFC2474 specifies the Diffserv Codepoint Field [RFC2474]. 87 Differentiated treatment is based on the specific DSCP. Once set, it 88 may change. If traffic marked with unknown or unexpected DSCPs is 89 received, RFC2474 recommends forwarding that traffic with default 90 (best effort) treatment without changing the DSCP markings. Many 91 networks do not follow this recommendation, and instead remark 92 unknown or unexpected DSCPs to the zero DSCP upon receipt for 93 consistency with default (best effort) forwarding in accordance with 94 the guidance in RFC 2475 [RFC2474] to ensure that appropriate DSCPs 95 are used within a Diffserv domain. Network providers applying the 96 MPLS Short Pipe model are likely to remark unexpected DSCPs. 98 This document is motivated by requirements for IP network 99 interconnection with Diffserv support among providers that operate 100 MPLS in their backbones, but is applicable to other technologies. 101 The operational simplifications and methods in this document help 102 align IP Diffserv functionality with MPLS limitations resulting 103 especially from the Short Pipe model of operation [RFC3270]. The 104 latter is widely deployed. Further, limiting Diffserv to a small 105 number of Treatment Aggregates can enable network traffic to leave a 106 network with the same DSCPs that it was received with, even if a 107 different DSCP is used within the network, thus providing an 108 opportunity to extend consistent QoS treatment across network 109 boundaries. 111 In isolation, use of standard interconnection PHBs and DSCPs may 112 appear to be additional effort for a network operator. The primary 113 offsetting benefit is that the mapping from or to the interconnection 114 PHBs and DSCPs is specified once for all of the interconnections to 115 other networks that can use this approach. Otherwise, the PHBs and 116 DSCPs have to be negotiated and configured independently for each 117 network interconnection, which has poor scaling properties. Further, 118 consistent end-to-end QoS treatment is more likely to result when an 119 interconnection code point scheme is used because traffic is remarked 120 to the same PHBs at all network interconnections. This document 121 envisions one-to-one DSCP remarking at network interconnections (not 122 n DSCP to one DSCP remarking). 124 In addition to the standard interconnecting PHBs and DSCPs, 125 interconnecting operators need to further agree on the tunneling 126 technology used for interconnection (e.g., MPLS, if used) and control 127 or mitigate the impacts of tunneling on reliability and MTU. 129 The MPLS Short Pipe tunneling model motivated this work and is its 130 main scope. The approach proposed here may be also be applied for 131 the Pipe tunneling model [RFC2983], [RFC3270]. The uniform model is 132 out of scope of this document. 134 1.1. Related work 136 In addition to the activities that triggered this work, there are 137 additional RFCs and Internet-drafts that may benefit from an 138 interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS- 139 Classes to enable deployment of standardized end to end QoS classes 140 [RFC5160]. The authors of that RFC agree that the proposed 141 interconnection class- and codepoint scheme and its enablement of 142 standardised end to end classes would complement their own work. 144 Work on signaling Class of Service at interconnection interfaces by 145 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the 146 scope of this draft. When the scheme in this document is used, 147 signaled access to QoS classes may be of interest. These two BGP 148 documents focus on exchanging SLA and traffic conditioning parameters 149 and assume that common PHBs identified by the signaled DSCPs have 150 been established prior to BGP signaling of QoS. 152 1.2. Applicability Statement 154 This document is primarily applicable to use of Differentiated 155 Services for interconnection traffic between networks, and in 156 particular to interconnection of MPLS-based networks. The approach 157 described in this document is not intended for use within the 158 interconnected (or other) networks, where the approach specified in 159 RFC 5127 [RFC5127] is among the possible alternatives; see Section 3 160 for further discussion. 162 The Diffserv-Intercon approach described in this document simplifies 163 IP based interconnection to domains operating the MPLS Short Pipe 164 model to transport plain IP traffic terminating within or transiting 165 through the receiving domain. Transit traffic is received and sent 166 with the same PHB and DSCP. Terminating traffic maintains the PHB 167 with which it was received, however the DSCP may change. 169 1.3. Document Organization 171 This document is organized as follows: section 2 reviews the MPLS 172 Short Pipe tunnel model for Diffserv Tunnels [RFC3270]; effective 173 support for that model is a crucial goal of this document. Section 3 174 provides background on RFC 5127's approach to traffic class 175 aggregation within a Diffserv network domain and explains why this 176 document uses a somewhat different approach. Section 4 introduces 177 Diffserv interconnection Treatment Aggregates, plus the PHBs and 178 DSCPs that are mapped to these Treatment Aggregates. Further, 179 section 4 discusses treatment of non-tunneled and tunneled IP traffic 180 and MPLS VPN QoS aspects. Finally Network Management PHB treatment 181 is described. Appendix A describes the impact of the MPLS Short Pipe 182 model (penultimate hop popping) on QoS for related IP 183 interconnections. 185 2. MPLS and the Short Pipe tunnel model 187 The Pipe and Uniform models for Differentiated Services and Tunnels 188 are defined in [RFC2983]. RFC3270 adds the MPLS Short Pipe model in 189 order to support penultimate hop popping (PHP) of MPLS Labels, 190 primarily for IP tunnels and VPNs. The Short Pipe model and PHP have 191 become popular with many network providers that operate MPLS networks 192 and are now widely used to transport non-tunneled IP traffic, not 193 just traffic encapsulated in IP tunnels and VPNs. This has important 194 implications for Diffserv functionality in MPLS networks. 196 RFC 2474's recommendation to forward traffic with unrecognized DSCPs 197 with Default (best effort) service without rewriting the DSCP has 198 proven to be a poor operational practice. Network operation and 199 management are simplified when there is a 1-1 match between the DSCP 200 marked on the packet and the forwarding treatment (PHB) applied by 201 network nodes. When this is done, CS0 (the all-zero DSCP) is the 202 only DSCP used for Default forwarding of best effort traffic, so a 203 common practice is to use CS0 to remark traffic received with 204 unrecognized or unsupported DSCPs at network edges. 206 MPLS networks are more subtle in this regard, as it is possible to 207 encode the provider's DSCP in the MPLS Traffic Class (TC) field and 208 allow that to differ from the PHB indicated by the DSCP in the MPLS- 209 encapsulated IP packet. That would allow an unrecognized DSCP to be 210 carried edge-to-edge over an MPLS network, because the effective DSCP 211 used by the MPLS network would be encoded in the MPLS label TC field 212 (and also carried edge-to-edge); this approach assumes that a 213 provider MPLS label with the provider's TC field is present at all 214 hops within the provider's network. But this is only true for the 215 Pipe tunnel model. 217 The Short Pipe tunnel model and PHP violate that assumption because 218 PHP pops and discards the MPLS provider label carrying the provider's 219 TC field. That discard occurs one hop upstream of the MPLS tunnel 220 endpoint (which is usually at the network edge), resulting in no 221 provider TC info being available at tunnel egress. To ensure 222 consistent handling of traffic at the tunnel egress, the DSCP field 223 in the MPLS-encapsulated IP header has to contain a DSCP that is 224 valid for the provider's network; propagating another DSCP edge-to- 225 edge requires an IP or MPLS tunnel of some form. See Appendix A for 226 a more detailed discussion. 228 If transport of a large number (much greater than 4) DSCPs is 229 required across a network that supports this Diffserv interconnection 230 scheme, a tunnel or VPN can be provisioned for this purpose, so that 231 the inner IP header carries the DSCP that is to be preserved not to 232 be changed. From a network operations perspective, the customer 233 equipment (CE) is the preferred location for tunnel termination, 234 although a receiving domains Provider Edge router is another viable 235 option. 237 3. Relationship to RFC 5127 239 This document draws heavily upon RFC 5127's approach to aggregation 240 of Diffserv traffic classes for use within a network, but there are 241 some important differences caused by the characteristics of network 242 interconnects. 244 3.1. RFC 5127 Background 246 Many providers operate MPLS-based backbones that employ backbone 247 traffic engineering to ensure that if a major link, switch, or router 248 fails, the result will be a routed network that continues to meet its 249 Service Level Agreements (SLAs). Based on that foundation, [RFC5127] 250 introduced the concept of Diffserv Treatment Aggregates, which enable 251 traffic marked with multiple DSCPs to be forwarded in a single MPLS 252 Traffic Class (TC) based on robust provider backbone traffic 253 engineering. This enables differentiated forwarding behaviors within 254 a domain in a fashion that does not consume a large number of MPLS 255 Traffic Classes. 257 RFC 5127 provides an example aggregation of Diffserv service classes 258 into 4 Treatment Aggregates. A small number of aggregates are used 259 because: 261 o The available coding space for carrying QoS information (e.g., 262 Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and 263 is intended for more than just QoS purposes (see e.g. [RFC5129]). 265 o There should be unused codes for interconnection purposes. This 266 leaves space for future standards, for private bilateral 267 agreements and for local use PHBs and DSCPs. 269 o Migrations from one code point scheme to another may require spare 270 QoS code points. 272 RFC 5127 also follows RFC 2474 in recommending transmission of DSCPs 273 through a network as they are received at the network edge. 275 3.2. Differences from RFC 5127 277 Like RFC 5127, this document also uses four traffic aggregates, but 278 differs from RFC 5127 in three important ways: 280 o It follows RFC 2475 in allowing the DSCPs used within a network to 281 differ from those to exchange traffic with other networks (at 282 network edges), but provides support to restore ingress DSCP 283 values if one of the recommended interconnect DSCPs in this draft 284 is used. This results in DSCP remarking at both network ingress 285 and network egress, and this draft assumes that such remarking at 286 network edges is possible for all interface types. 288 o It treats network control traffic as a special case. Within a 289 network, the CS6 DSCP is used for local network control traffic 290 (routing protocols and OAM traffic that is essential for network 291 operation administration, control and management) that may be 292 destined for any node within the network. In contrast, network 293 control traffic exchanged between networks (e.g., BGP traffic) 294 usually terminates at or close to a network edge, and is not 295 forwarded through the network because it is not part of internal 296 routing or OAM for the receiving network. In addition, such 297 traffic is unlikely to be covered by standard interconnection 298 agreements; it is more likely to be specifically configured (e.g., 299 most networks impose on exchange of BGP for obvious reasons). See 300 Section 4.2 for further discussion. 302 o Because network control traffic is treated as a special case, a 303 fourth traffic aggregate is defined for use at network 304 interconnections to replace the Network Control aggregate in RFC 305 5127. Network Control traffic may still be exchanged across 306 network interconnections as further discussed in Section 4.2 308 4. The Diffserv-Intercon Interconnection Classes 310 At an interconnection, the networks involved need to agree on the 311 PHBs used for interconnection and the specific DSCP for each PHB. 312 This may involve remarking for the interconnection; such remarking is 313 part of the Diffserv Architecture [RFC2475], at least for the network 314 edge nodes involved in interconnection. This draft proposes a 315 standard interconnection set of 4 Treatment Aggregates with well- 316 defined DSCPs to be aggregated by them. A sending party remarks 317 DSCPs from internal schemes to the interconnection code points. The 318 receiving party remarks DSCPs to her internal scheme. The set of 319 DSCPs and PHBs supported across the two interconnected domains and 320 the treatment of PHBs and DSCPs not recognized by the receiving 321 domain should be part of the interconnect SLA. 323 RFC 5127's four treatment aggregates include a Network Control 324 aggregate for routing protocols and OAM traffic that is essential for 325 network operation administration, control and management. Using this 326 aggregate as one of the four in RFC 5127 implicitly assumes that 327 network control traffic is forwarded in potential competition with 328 all other network traffic, and hence Diffserv must favor such traffic 329 (e.g., via use of the CS6 codepoint) for network stability. That is 330 a reasonable assumption for IP-based networks where routing and OAM 331 protocols are mixed with all other types of network traffic; 332 corporate networks are an example. 334 In contrast, mixing of all traffic is not a reasonable assumption for 335 MPLS-based provider or carrier networks, where customer traffic is 336 usually segregated from network control (routing and OAM) traffic via 337 other means, e.g., network control traffic use of separate LSPs that 338 can be prioritized over customer LSPs (e.g., for VPN service) via 339 other means. This segregation of network control traffic from 340 customer traffic is also used for MPLS-based network 341 interconnections. In addition, many customers of a network provider 342 do not exchange Network Control traffic (e.g., routing) with the 343 network provider. For these reasons, a separate Network Control 344 traffic aggregate is not important for MPLS-based carrier or provider 345 networks; when such traffic is not segregated from other traffic, it 346 may reasonably share the Assured Elastic treatment aggregate (as RFC 347 5127 suggests for a situation in which only three treatment 348 aggregates are supported). 350 In contrast, VoIP is emerging as a valuable and important class of 351 network traffic for which network-provided QoS is crucial, as even 352 minor glitches are immediately apparent to the humans involved in the 353 conversation. 355 Similar approaches to use of a small number of traffic aggregates 356 (including recognition of the importance of VoIP traffic) have been 357 taken in related standards and recommendations from outside the IETF, 358 e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1]. 360 The list of the four Diffserv Interconnect traffic aggregates 361 follows, highlighting differences from RFC 5127 and suggesting 362 mappings for all RFC 4594 traffic classes to Diffserv-Intercon 363 Treatment Aggregates: 365 Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and 366 VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865]. 367 This Treatment Aggregate corresponds to RFC 5127s real time 368 Treatment Aggregate definition regarding the queuing, but it 369 is restricted to transport Telephony Service Class traffic in 370 the sense of RFC 4594. 372 Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is 373 designed to transport PHB AF41, DSCP 100 010 (the other AF4 374 PHB group PHBs and DSCPs may be used for future extension of 375 the set of DSCPs carried by this Treatment Aggregate). This 376 Treatment Aggregate is designed to transport the portions of 377 RFC 5127's Real Time Treatment Aggregate, which consume large 378 amounts of bandwidth, namely Broadcast Video, Real-Time 379 Interactive and Multimedia Conferencing. The treatment 380 aggregate should be configured with a rate queue (which is in 381 line with RFC 4594 for the mentioned traffic classes). As 382 compared to RFC 5127, the number of DSCPs has been reduced to 383 one (initially). The proposed queuing mechanism is in line 384 with RFC4594 definitions for Broadcast Video and Real-Time 385 Interactive. If need for three-color marked Multimedia 386 Conferencing traffic arises, AF42 and AF43 PHBs may be added. 388 Assured Elastic Treatment Aggregate This Treatment Aggregate 389 consists of the entire AF3 PHB group AF3, i.e., DSCPs 011 390 010, 011 100 and 011 110. As compared to RFC5127, just the 391 number of DSCPs, which has been reduced. This document 392 suggests to transport signaling marked by AF31. RFC5127 393 suggests to map Network Management traffic into this 394 Treatment Aggregate, if no separate Network Control Treatment 395 Aggregate is supported (for a more detailed discussion of 396 Network Control PHB treatment see section 3.2). GSMA IR.34 397 proposes to transport signaling traffic by AF31 too. The 398 following RFC 4594 classes should also be mapped to the 399 Assured Elastic Treatment Aggregate: the Signalling Service 400 Class (being marked for lowest loss probability), Multimedia 401 Streaming Service Class, the Low-Latency Data Service Class 402 and the High-Throughput Data Service Class. 404 Default / Elastic Treatment Aggregate: transports the default PHB, 405 CS0 with DSCP 000 000. RFC 5127 example refers to this 406 Treatment Aggregate as Aggregate Elastic. An important 407 difference as compared to RFC5127 is that any traffic with 408 unrecognized or unsupported DSCPs may be remarked to this 409 DSCP. The RFC 4594 Standard Service Class and Low-priority 410 data should be mapped to this Treatment Aggregate. RFC 4594 411 Low-priority data may be forwarded by a Lower Effort PHB in 412 one domain (like the PHB proposed by Informational 413 [RFC3662]). If such traffic is sent to a domain not 414 supporting a Lower Effort PHB, the lowest effort PHB there 415 may be expected to be the Default PHB. Marking such traffic 416 with DSCP CS0 at an interconnection interface is a reasonable 417 choice then. 419 The overall approach to DSCP marking at network interconnections is 420 illustrated by the following example. Provider O and provider W are 421 peered with provider T. They have agreed upon a QoS interconnection 422 SLA. 424 Traffic of provider O terminates within provider Ts network, while 425 provider W's traffic transits through the network of provider T to 426 provider F. Assume all providers run their own internal codepoint 427 schemes for a PHB group with properties of the Diffserv-Intercon 428 Assured Treatment Aggregate. 430 Provider-O Provider-W 431 RFC5127 GSMA 34.1 432 | | 433 +----------+ +----------+ 434 |AF21, AF22| | CS3, CS2 | 435 +----------+ +----------+ 436 | | 437 V V 438 +++++++++ +++++++++ 439 |Rtr PrO| |Rtr PrW| Rtr Pr: 440 +++++++++ +++++++++ Router Peering 441 | Diffserv | 442 +----------+ +----------+ 443 |AF31, AF32| |AF31, AF32| 444 +----------+ +----------+ 445 | Intercon | 446 V V 447 +++++++++ | 448 |RtrPrTI|------------------+ 449 +++++++++ 450 | Provider-T domain 451 +-----------+ 452 | MPLS TC 2 | 453 | DSCP rew. | rew. -> rewrite 454 | AF21, AF22| 455 +-----------+ 456 | | Local DSCPs Provider-T 457 | | +----------+ +++++++++ 458 V +->|AF21, AF22|->-|RtrDstH| 459 | +----------+ +++++++++ 460 +----------+ RtrDst: 461 |AF21, AF22| Router Destination 462 +----------+ 463 | 464 +++++++++ 465 |RtrPrTE| 466 +++++++++ 467 | Diffserv 468 +----------+ 469 |AF31, AF32| 470 +----------+ 471 | Intercon 472 +++++++++ 473 |RtrPrF| 474 +++++++++ 475 | 476 +----------+ 477 | CS4, CS3 | 478 +----------+ 479 | 480 Provider-F 481 GSM IR.34 483 Diffserv-Intercon example 485 Figure 1 487 Providers only need to deploy internal DSCP to Diffserv-Intercon DSCP 488 mappings to exchange traffic in the desired classes. Provider W has 489 decided that the properties of his internal classes CS3 and CS2 are 490 best met by the Diffserv-Intercon Assured Elastic Treatment 491 Aggregate, PHBs AF31 and AF32 respectively. At the outgoing peering 492 interface connecting provider W with provider T the former's peering 493 router remarks CS3 traffic to AF31 and CS2 traffic to AF32. The 494 domain internal PHBs of provider T that meet the requirements of 495 Diffserv-Intercon Assured Elastic Treatment Aggregate are AF2x. 496 Hence AF31 traffic received at the interconnection with provider T is 497 remarked to AF21 by the peering router of domain T, and domain T has 498 chosen to use MPLS TC value 2 for this aggregate. Traffic received 499 with AF32 is similarly remarked to AF22, but uses the same MPLS TC 500 for the Treatment Aggregate, i.e. TC 2. At the penultimate MPLS 501 node, the top MPLS label is removed. The packet should be forwarded 502 as determined by the incoming MPLS TC. The peering router connecting 503 domain T with domain F classifies the packet by it's domain T 504 internal DSCP AF21 for the Diffserv-Intercon Assured Elastic 505 Treatment Aggregate. As it leaves domain T on the interface to 506 domain F, this causes the packet to be remarked to AF31. The peering 507 router of domain F classifies the packet for domain F internal PHB 508 CS4, as this is the PHB with properties matching Diffserv-Intercon's 509 Assured Elastic Treatment Aggregate. Likewise, AF21 traffic is 510 remarked to AF32 by the peering router od domain T when leaving it 511 and from AF32 to CS3 by domain F's peering router when receiving it. 513 This example can be extended. Suppose Provider-O also supports a PHB 514 marked by CS2 and this PHB is supposed to be transported by QoS 515 within Provider-T domain. Then Provider-O will remark it with a DSCP 516 other than the AF31 DSCP in order to preserve the distinction from 517 CS2; AF11 is one possibility that might be private to the 518 interconnection between Provider-O and Provider-T; there's no 519 assumption that Provider-W can also use AF11, as it may not be in the 520 SLA with Provider-W. 522 Now suppose Provider-W supports CS2 for internal use only. Then no 523 Diffserv- Intercon DSCP mapping may be configured at the peering 524 router. Traffic, sent by Provider-W to Provider-T marked by CS2 due 525 to a misconfiguration may be remarked to CS0 by Provider-T. 527 See section 4.1 for further discussion of this and DSCP transparency 528 in general. 530 RFC2575 states that Ingress nodes must condition all other inbound 531 traffic to ensure that the DS codepoints are acceptable; packets 532 found to have unacceptable codepoints must either be discarded or 533 must have their DS codepoints modified to acceptable values before 534 being forwarded. For example, an ingress node receiving traffic from 535 a domain with which no enhanced service agreement exists may reset 536 the DS codepoint to the Default PHB codepoint. As a consequence, an 537 interconnect SLA needs to specify not only the treatment of traffic 538 that arrives with a supported interconnect DSCP, but also the 539 treatment of traffic that arrives with unsupported or unexpected 540 DSCPs. 542 The proposed interconnect class and code point scheme is designed for 543 point to point IP layer interconnections among MPLS networks. Other 544 types of interconnections are out of scope of this document. The 545 basic class and code point scheme is applicable on Ethernet layer 546 too, if a provider e.g. supports Ethernet priorities like specified 547 by IEEE 802.1p. 549 4.1. End-to-end QoS: PHB and DS CodePoint Transparency 551 This section briefly discusses end-to-end QoS approaches related to 552 the Uniform, Pipe and Short Pipe tunnel model. 554 o With the Uniform model, neither DCSP nor PHB change when an 555 interconnected network is passed. This would mean that a packet 556 received with syntax network management, marked by CS6 is, if MPLS 557 is applicable, forwarded with an MPLS label marked TC6. The 558 uniform model is not within scope of this document. 560 o With the Pipe model, the inner tunnel DCSP remains unchanged, but 561 an outer tunnel DSCP and the PHB may change when an interconnected 562 network is passed. This would mean that a packet received with 563 (private) syntax scavenger marked by DSCP CS1, is transported by 564 default PHB and if MPLS is applicable, forwarded with an MPLS 565 label marked TC0. CS1 is not rewritten. The Pipe model is not 566 within scope of this document. 568 o With the Short Pipe model, the DCSP likely changes and the might 569 PHB change when an interconnected network is passed. This draft 570 describes a method to speed up and simplify QoS interconnection if 571 a DSCP rewrite can't be avoided. It offers a set of PHBs and 572 treatment aggregates as well as a set of interconnection DSCPs 573 allowing straightforward rewriting to domain-internal DSCPs as 574 well as defined forwarding and markings to the next domain. 575 Diffserv-Intercon supports the Short Pipe model. The solution 576 described here can be used in other contexts benefitting from a 577 defined interconnection QoS interface. 579 The basic idea is that traffic sent with a Diffserv interconnect PHB 580 and DSCP is restored to that PHB and DSCP at each network 581 interconnection, even though a different PHB and DSCP may be used by 582 each network involved. The key requirement is that the network 583 ingress interconnect DSCP be restored at network egress, and a key 584 observation is that this is only feasible in general for a small 585 number of DSCPs. 587 4.2. 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 to be expected at some interconnection interfaces. 592 This document does not change RFC4594, but observes that network 593 control traffic received at network ingress is generally different 594 from network control traffic within a network that is the primary use 595 of CS6 envisioned by RFC 4594. A specific example is that some CS6 596 traffic exchanged across carrier interconnections is terminated at 597 the network ingress node, e.g. if BGP is running between two routers 598 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 QoS discussion in the previous section (4.1) is 603 generally inapplicable to network control traffic - network control 604 traffic is generally intended to control a network, not be 605 transported across it. One exception is that network control traffic 606 makes sense for a purchased transit agreement, and preservation of 607 the CS6 DSCP marking for network control traffic that is transited is 608 reasonable in some cases, although it is generally inappropriate to 609 use CS6 for transiting traffic, including transiting network control 610 traffic. Use of an IP tunnel is suggested in order to reduce the 611 risk of CS6 markings on transiting network control traffic being 612 interpreted by the network providing the transit. In this case, the 613 CS6 marked traffic is forwarded based on the Uniform or Pipe model, 614 Short Pipe doesn't apply. 616 If the MPLS Short Pipe model is deployed for non-tunneled IPv4 617 traffic, an IP network provider should limit access to the CS6 and 618 CS7 DSCPs so that they are only used for network control traffic for 619 the provider's own network. 621 Interconnecting carriers should specify treatment of CS6 marked 622 traffic received at a carrier interconnection which is to be 623 forwarded beyond the ingress node. An SLA covering the following 624 cases is recommended when a provider wishes to send CS6 marked 625 traffic across an interconnection link which isn't terminating at the 626 interconnected ingress node: 628 o classification of traffic which is network control traffic for 629 both domains. This traffic should be classified and marked for 630 the NC PHB. 632 o classification of traffic which is network control traffic for the 633 sending domain only. This traffic should be classified for a PHB 634 offering similar properties as the NC class (e.g. AF31 as 635 specified by this document). As an example GSMA IR.34 proposes an 636 Interactive class / AF31 to carry SIP and DIAMETER traffic. While 637 this is service control traffic of high importance to the 638 interconnected Mobile Network Operators, it is certainly not 639 Network Control traffic for a fixed network providing transit 640 between such operators, and hence should not receive CS6 treatment 641 in such a network. 643 o any other CS6 marked traffic should be remarked or dropped. 645 5. Acknowledgements 647 Bob Briscoe reviewed the draft and provided rich feedback. Fred 648 Baker and Brian Carpenter provided intensive feedback and discussion. 649 Al Morton and Sebastien Jobert provided feedback on many aspects 650 during private discussions. Mohamed Boucadair and Thomas Knoll 651 helped adding awareness of related work. James Polks discussion 652 during IETF 89 helped to improve the relation of this draft to RFC 653 4594 and RFC 5127. 655 6. IANA Considerations 657 This memo includes no request to IANA. 659 7. Security Considerations 661 This document does not introduce new features, it describes how to 662 use existing ones. The security considerations of RFC 2475 [RFC2475] 663 and RFC 4594 [RFC4594] apply. 665 8. References 667 8.1. Normative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, 671 DOI 10.17487/RFC2119, March 1997, 672 . 674 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 675 "Definition of the Differentiated Services Field (DS 676 Field) in the IPv4 and IPv6 Headers", RFC 2474, 677 DOI 10.17487/RFC2474, December 1998, 678 . 680 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 681 and W. Weiss, "An Architecture for Differentiated 682 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 683 . 685 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 686 "Assured Forwarding PHB Group", RFC 2597, 687 DOI 10.17487/RFC2597, June 1999, 688 . 690 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 691 J., Courtney, W., Davari, S., Firoiu, V., and D. 692 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 693 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 694 . 696 [RFC3260] Grossman, D., "New Terminology and Clarifications for 697 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 698 . 700 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 701 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 702 Protocol Label Switching (MPLS) Support of Differentiated 703 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 704 . 706 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 707 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 708 2008, . 710 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 711 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 712 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 713 2009, . 715 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 716 Services Code Point (DSCP) for Capacity-Admitted Traffic", 717 RFC 5865, DOI 10.17487/RFC5865, May 2010, 718 . 720 8.2. Informative References 722 [I-D.knoll-idr-cos-interconnect] 723 Knoll, T., "BGP Class of Service Interconnection", draft- 724 knoll-idr-cos-interconnect-14 (work in progress), May 725 2015. 727 [ID.idr-sla] 728 IETF, "Inter-domain SLA Exchange", IETF, 729 http://datatracker.ietf.org/doc/ 730 draft-ietf-idr-sla-exchange/, 2013. 732 [IEEE802.1Q] 733 IEEE, "IEEE Standard for Local and Metropolitan Area 734 Networks - Virtual Bridged Local Area Networks", 2005. 736 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 737 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 738 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ 739 ir.34.pdf, 2012. 741 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 742 Class of Service Phase 2", MEF, MEF23.1 743 http://metroethernetforum.org/PDF_Documents/technical- 744 specifications/MEF_23.1.pdf, 2012. 746 [RFC2983] Black, D., "Differentiated Services and Tunnels", 747 RFC 2983, DOI 10.17487/RFC2983, October 2000, 748 . 750 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 751 Per-Domain Behavior (PDB) for Differentiated Services", 752 RFC 3662, DOI 10.17487/RFC3662, December 2003, 753 . 755 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 756 Guidelines for DiffServ Service Classes", RFC 4594, 757 DOI 10.17487/RFC4594, August 2006, 758 . 760 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 761 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 762 February 2008, . 764 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 765 to-Provider Agreements for Internet-Scale Quality of 766 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 767 2008, . 769 [Y.1566] ITU-T, "Quality of service mapping and interconnection 770 between Ethernet, IP and multiprotocol label switching 771 networks", ITU, 772 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 774 Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 776 The MPLS Short Pipe Model (or penultimate Hop Label Popping) is 777 widely deployed in carrier networks. If non-tunneled IPv4 traffic is 778 transported using MPLS Short Pipe, IP headers appear inside the last 779 section of the MPLS domain. This impacts the number of PHBs and 780 DSCPs that a network provider can reasonably support . See Figure 2 781 (below) for an example. 783 For tunneled IPv4 traffic, only the outer tunnel header is relevant 784 for forwarding. If the tunnel does not terminate within the MPLS 785 network section, only the outer tunnel DSCP is involved, as the inner 786 DSCP does not affect forwarding behavior. In this case, the Pipe 787 model applies. 789 Non-tunneled IPv6 traffic as well as Layer 2 and Layer 3 VPN traffic 790 all use an additional MPLS label; in this case, the MPLS tunnel 791 follows the Pipe model. Classification and queuing within an MPLS 792 network is always based on an MPLS label, as opposed to the outer IP 793 header. 795 Carriers often select QoS PHBs and DSCP without regard to 796 interconnection. As a result PHBs and DSCPs typically differ between 797 network carriers. PHBs may be mapped. With the exception of best 798 effort traffic, a DSCP change should be expected at an 799 interconnection at least for plain IP traffic, even if the PHB is 800 suitably mapped by the carriers involved. 802 Beyond RFC3270's suggestions that the Short Pipe Model is only 803 applicable to VPNs, current network structures also use it to 804 transport non tunneled IPv4 traffic. This is shown in figure 2. 806 | 807 \|/ IPv4, DSCP_send 808 V 809 | 810 Peering Router 811 | 812 \|/ IPv4, DSCP_send 813 V 814 | 815 MPLS Edge Router 816 | Mark MPLS Label, TC_internal 817 \|/ Remark DSCP to 818 V (Inner: IPv4, DSCP_d) 819 | 820 MPLS Core Router (penultimate hop label popping) 821 | \ 822 | IPv4, DSCP_d | The DSCP needs to be in network- 823 | ^^^^^^^^| internal QoS context. The Core 824 \|/ > Router might require or enforce 825 V | it. The Edge Router may wrongly 826 | | classify, if the DSCP is not in 827 | / network-internal Diffserv context. 828 MPLS Edge Router 829 | \ Traffic leaves the network marked 830 \|/ IPv4, DSCP_d | with the network-internal 831 V > DSCP_d that must be dealt with 832 | | by the next network (downstream). 833 | / 834 Peer Router 835 | Remark DSCP to 836 \|/ IPv4, DSCP_send 837 V 838 | 840 Short-Pipe / penultimate hop popping example 842 Figure 2 844 The packets IP DSCP must be in a well understood Diffserv context for 845 schedulers and classifiers on the interfaces of the ultimate MPLS 846 link (last link traversed before leaving the network). The necessary 847 Diffserv context is network-internal and a network operating in this 848 mode enforces DSCP usage in order to obtain robust QoS behavior. 850 Without Diffserv-Intercon treatment, the traffic is likely to leave 851 each network marked with network-internal DSCP. DSCP_send of the 852 figure above is remarked to the receiving network's Diffserv scheme. 853 It leaves the domain marked by the domains DSCP_d. This structure 854 requires that every carrier deploys per-peer PHB and DSCP mapping 855 schemes. 857 If Diffserv-Intercon is applied DSCPs for traffic transiting the 858 domain can be mapped from and remapped to an original DSCP. This is 859 shown in figure 3. Internal traffic may continue to use internal 860 DSCPs (e.g, DSCP_d) and those may also be used between a carrier and 861 its direct customers. 863 Internal Router 864 | 865 | Outer Header 866 \|/ IPv4, DSCP_send 867 V 868 | 869 Peering Router 870 | Remark DSCP to 871 \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB 872 V 873 | 874 MPLS Edge Router 875 | 876 | Mark MPLS Label, TC_internal 877 \|/ Remark DSCP to 878 V (Inner: IPv4, DSCP_d) domain internal DSCP for 879 | the PHB 880 MPLS Core Router (penultimate hop label popping) 881 | 882 | IPv4, DSCP_d 883 | ^^^^^^ 884 \|/ 885 V 886 | 887 | 888 MPLS Edge Router--------------------+ 889 | | 890 \|/ Remark DSCP to \|/ IPv4, DSCP_d 891 V IPv4, DSCP_ds-int V 892 | | 893 | | 894 Peer Router Domain internal Broadband 895 | Access Router 896 \|/ Remark DSCP to \|/ 897 V IPv4, DSCP_send V IPv4, DSCP_d 898 | | 900 Short-Pipe example with Diffserv-Intercon 902 Figure 3 904 Appendix B. Change log (to be removed by the RFC editor) 906 00 to 01 Added an Applicability Statement. Put the main part of the 907 RFC5127 related discussion into a separate chapter. 909 01 to 02 More emphasis on the Short-Pipe tunel model as compared to 910 Pipe and Uniform tunnel models. Further editorial 911 improvements. 913 02 to 03 Suggestions how to remark all RFC4594 classes to Diffserv- 914 Intercon classes at interconnection. 916 Authors' Addresses 918 Ruediger Geib (editor) 919 Deutsche Telekom 920 Heinrich Hertz Str. 3-7 921 Darmstadt 64295 922 Germany 924 Phone: +49 6151 5812747 925 Email: Ruediger.Geib@telekom.de 927 David L. Black 928 EMC Corporation 929 176 South Street 930 Hopkinton, MA 931 USA 933 Phone: +1 (508) 293-7953 934 Email: david.black@emc.com