idnits 2.17.1 draft-ietf-tsvwg-diffserv-intercon-00.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 : ---------------------------------------------------------------------------- == 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 (December 4, 2014) is 3428 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC3260' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q' is defined on line 657, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-13 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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 7, 2015 EMC Corporation 6 December 4, 2014 8 DiffServ interconnection classes and practice 9 draft-ietf-tsvwg-diffserv-intercon-00 11 Abstract 13 This document proposes a limited and well defined set of DiffServ 14 PHBs and codepoints to be applied at (inter)connections of two 15 separately administered and operated networks. Many network 16 providers operate MPLS using Treatment Aggregates for traffic marked 17 with different DiffServ PHBs, and use MPLS for interconnection with 18 other networks. This document offers a simple interconnection 19 approach that may simplify operation of DiffServ for network 20 interconnection among providers. 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 June 7, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 4 58 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5 59 3. An Interconnection class and codepoint scheme . . . . . . . . 6 60 3.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 11 61 3.2. Treatment of Network Control traffic at carrier 62 interconnection interfaces . . . . . . . . . . . . . . . 12 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 7.2. Informative References . . . . . . . . . . . . . . . . . 14 69 Appendix A. Annex A Carrier interconnection related DiffServ 70 aspects . . . . . . . . . . . . . . . . . . . . . . 15 71 Appendix B. Annex 2 The MPLS Short Pipe Model and IP traffic . . 17 72 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 21 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 DiffServ has been deployed in many networks. As described by section 78 2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a 79 DiffServ feature [RFC2475]. This draft proposes a set of standard 80 QoS classes and code points at interconnection points to which and 81 from which locally used classes and code points should be mapped. 83 RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. 84 Differentiated treatment is based on the specific DSCP. Once set, it 85 may change. If traffic marked with unknown or unexpected DSCPs is 86 received, RFC2474 recommends forwarding that traffic with default 87 (best effort) treatment without changing the DSCP markings. Many 88 networks do not follow this recommendation, and instead remark 89 unknown or unexpected DSCPs to the zero DSCP for consistency with 90 default (best effort) forwarding. 92 Many providers operate MPLS-based backbones that employ backbone 93 traffic engineering to ensure that if a major link, switch, or router 94 fails, the result will be a routed network that continues to meet its 95 Service Level Agreements (SLAs). Based on that foundation, 96 foundation, [RFC5127] introduces the concept of DiffServ Treatment 97 Aggregates, which enable traffic marked with multiple DSCPs to be 98 forwarded in a single MPLS Traffic Class (TC). Like RFC 5127, this 99 document assumes robust provider backbone traffic engineering. 101 RFC5127 recommends transmission of DSCPs as they are received. This 102 is not possible, if the receiving and the transmitting domains at a 103 network interconnection use different DSCPs for the PHBs involved. 105 This document is motivated by requirements for IP network 106 interconnection with DiffServ support among providers that operate 107 MPLS in their backbones, but is applicable to other technologies. 108 The operational simplifications and methods in this document help 109 align IP DiffServ functionality with MPLS limitations, particularly 110 when MPLS penultimate hop popping is used. That is an important 111 reason why this document specifies 4 interconnection Treatment 112 Aggregates. Limiting DiffServ to a small number Treatment Aggregates 113 can help ensure that network traffic leaves a network with the same 114 DSCPs that it was received with. The approach proposed here may be 115 extended by operators or future specifications. 117 In isolation, use of standard interconnection PHBs and DSCPs may 118 appear to be additional effort for a network operator. The primary 119 offsetting benefit is that the mapping from or to the interconnection 120 PHBs and DSCPs is specified once for all of the interconnections to 121 other networks that can use this approach. Otherwise, the PHBs and 122 DSCPs have to be negotiated and configured independently for each 123 network interconnection, which has poor scaling properties. Further, 124 end-to-end QoS treatment is more likely to result when an 125 interconnection code point scheme is used because traffic is remarked 126 to the same PHBs at all network interconnections. This document 127 supports one-to-one DSCP remarking at network interconnections (not n 128 DSCP to one DSCP remarking). 130 The example given in RFC 5127 on aggregation of DiffServ service 131 classes uses 4 Treatment Aggregates, and this document does likewise 132 because: 134 o The available coding space for carrying QoS information (e.g., 135 DiffServ PHB) in MPLS and Ethernet is only 3 bits in size, and is 136 intended for more than just QoS purposes (see e.g. [RFC5129]). 138 o There should be unused codes for interconnection purposes. This 139 leaves space for future standards, for private bilateral 140 agreements and for local use PHBs and DSCPs. 142 o Migrations from one code point scheme to another may require spare 143 QoS code points. 145 RFC5127 provides recommendations on aggregation of DSCP-marked 146 traffic into MPLS Treatment Aggregates and offers a deployment 147 example [RFC5127] that does not work for the MPLS Short Pipe model 148 when that model is used for ordinary network traffic. This document 149 supports the MPLS Short Pipe model for ordinary network traffic and 150 hence differs from the RFC5127 approach as follows: 152 o remarking of received DSCPs to domain internal DSCPs is to be 153 expected for ordinary IP traffic at provider edges (and for outer 154 headers of tunneled IP traffic). 156 o document follows RFC4594 in the proposed marking of provider 157 Network Control traffic and expands RFC4594 on treatment of CS6 158 marked traffic at interconnection points (see section 3.2). 160 This document is organized as follows: section 2 reviews the MPLS 161 Short Pipe tunnel model for DiffServ Tunnels [RFC3270]; effective 162 support for that model is a crucial goal of this document. Section 3 163 introduces DiffServ interconnection Treatment Aggregates, plus the 164 PHBs and DSCPs that are mapped to these Treatment Aggregates. 165 Further, section 3 discusses treatment of non-tunneled and tunneled 166 IP traffic and MPLS VPN QoS aspects. Finally Network Management PHB 167 treatment is described. Annex A discusses how domain internal IP 168 layer QoS schemes impact interconnection. Annex B describes the 169 impact of the MPLS Short Pipe model (pen ultimate hop popping) on QoS 170 related IP interconnections. 172 1.1. Related work 174 In addition to the activities that triggered this work, there are 175 additional RFCs and Internet-drafts that may benefit from an 176 interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS- 177 Classes to enable deployment of standardized end to end QoS classes 178 [RFC5160]. In private discussion, the authors of that RFC agree that 179 the proposed interconnection class- and codepoint scheme and its 180 enablement of standardised end to end classes would complement their 181 own work. 183 Work on signaling Class of Service at interconnection interfaces by 184 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the 185 scope of this draft. When the basic DiffServ elements for network 186 interconnection are used as described in this document, signaled 187 access to QoS classes may be of interest. These two BGP documents 188 focus on exchanging SLA and traffic conditioning parameters and 189 assume that common PHBs identified by the signaled DSCPs have been 190 established prior to BGP signaling of QoS. 192 2. MPLS and the Short Pipe tunnel model 194 The Pipe and Uniform models for Differentiated Services and Tunnels 195 are defined in [RFC2983]. RFC3270 adds the MPLS Short Pipe model in 196 order to support penultimate hop popping (PHP) of MPLS Labels, 197 primarily for IP tunnels and VPNs. The Short Pipe model and PHP have 198 become popular with many network providers that operate MPLS networks 199 and are now widely used for ordinary network traffic, not just 200 traffic encapsulated in IP tunnels and VPNs. This has important 201 implications for DiffServ functionality in MPLS networks. 203 RFC 2474's recommendation to forward traffic with unrecognized DSCPs 204 with Default (best effort) service without rewriting the DSCP has 205 proven to be a poor operational practice. Network operation and 206 management are simplified when there is a 1-1 match between the DSCP 207 marked on the packet and the forwarding treatment (PHB) applied by 208 network nodes. When this is done, CS0 (the all-zero DSCP) is the 209 only DSCP used for Default forwarding of best effort traffic, so a 210 common practice is to use CS0 to remark traffic received with 211 unrecognized or unsupported DSCPs at network edges. 213 MPLS networks are more subtle in this regard, as it is possible to 214 encode the provider's DSCP in the MPLS TC field and allow that to 215 differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP 216 packet. That would allow an unrecognized DSCP to be carried edge-to- 217 edge over an MPLS network, because the effective DSCP used by the 218 MPLS network would be encoded in the MPLS label TC field (and also 219 carried edge-to-edge); this approach assumes that a provider MPLS 220 label with the provider's TC field being present at all hops within 221 the provider's network. 223 The Short Pipe tunnel model and PHP violate that assumption because 224 PHP pops and discards the MPLS provider label carrying the provider's 225 TC field. That discard occurs one hop upstream of the MPLS tunnel 226 endpoint, resulting in no provider TC info being available at tunnel 227 egress. Therefore the DSCP field in the MPLS-encapsulated IP header 228 has to contain a DSCP that is valid for the provider's network; 229 propagating another DSCP edge-to-edge requires an IP tunnel of some 230 form. In the absence of IP tunneling (a common case for MPLS 231 networks), it is not possible to pass all 64 possible DSCP values 232 edge-to-edge across an MPLS network. See Annex B for a more detailed 233 discussion. 235 If transport of a large number (much greater than 4) DSCPs is 236 required across a network that supports this DiffServ interconnection 237 scheme, a tunnel or VPN can be provisioned for this purpose, so that 238 the inner IP header carries the DSCP that is to be preserved not to 239 be changed. From a network operations perspective, the customer 240 equipment (CE) is the preferred location for tunnel termination, 241 although a receiving domains Provider Edge router is another viable 242 option. 244 3. An Interconnection class and codepoint scheme 246 At an interconnection, the networks involved need to agree on the 247 PHBs used for interconnection and the specific DSCP for each PHB. 248 This may involve remarking for the interconnection; such remarking is 249 part of the DiffServ Architecture [RFC2475], at least for the network 250 edge nodes involved in interconnection. See Annex A for a more 251 detailed discussion. This draft proposes a standard interconnection 252 set of 4 Treatment Aggregates with well-defined DSCPs to be 253 aggregated by them. A sending party remarks DSCPs from internal 254 schemes to the interconnection code points. The receiving party 255 remarks DSCPs to her internal scheme. The set of DSCPs and PHBs 256 supported across the two interconnected domains and the treatment of 257 PHBs and DSCPs not recognized by the receiving domain should be part 258 of the interconnect SLA. 260 RFC 5127's four treatment aggregates include a Network Control 261 aggregate for routing protocols and OAM traffic that is essential for 262 network operation administration, control and management. Using this 263 aggregate as one of the four in RFC 5127 implicitly assumes that 264 network control traffic is forwarded in potential competition with 265 all other network traffic, and hence DiffServ must favor such traffic 266 (e.g., via use of the CS6 codepoint) for network stability. That is 267 a reasonable assumption for IP-based networks where routing and OAM 268 protocols are mixed with all other types of network traffic; 269 corporate networks are an example. 271 In contrast, mixing of all traffic is not a reasonable assumption for 272 MPLS-based provider or carrier networks, where customer traffic is 273 usually segregated from network control (routing and OAM) traffic via 274 other means, e.g., network control traffic use of separate LSPs that 275 can be prioritized over customer LSPs (e.g., for VPN service) via 276 other means. This sort of of network control traffic from customer 277 traffic is also used for MPLS-based network interconnections. In 278 addition, many customers of a network provider do not exchange 279 Network Control traffic (e.g., routing) with the network provider. 280 For these reasons, a separate Network Control traffic aggregate is 281 not important for MPLS-based carrier or provider networks; when such 282 traffic is not segregated from other traffic, it may reasonably share 283 the Assured Elastic treatment aggregate (as RFC 5127 suggests for a 284 situation in which only three treatment aggregates are supported). 286 In contrast, VoIP is emerging as a valuable and important class of 287 network traffic for which network-provided QoS is crucial, as even 288 minor glitches are immediately apparent to the humans involved in the 289 conversation. 291 For these reasons, the Diffserv Interconnect scheme in this document 292 departs from the approach in RFC 5127 by not providing a Network 293 Control traffic aggregate, and instead dedicating the fourth traffic 294 aggregate for VoIP traffic. Network Control traffic may still be 295 exchanged across network interconnections, see Section 3.2 for 296 further discussion. 298 Similar approaches to use of a small number of traffic aggregates 299 (including recognition of the importance of VoIP traffic) have been 300 taken in related standards and recommendations from outside the IETF, 301 e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34] andMEF23.1 [MEF23.1]. 303 The list of the four DiffServ Interconnect traffic aggregates 304 follows, highlighting differences from RFC 5127 and the specific 305 traffic classes from RFC 4594 that each class aggregates. 307 Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and 308 VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865]. 309 This Treatment Aggregate corresponds to RFC 5127s real time 310 Treatment Aggregate definition regarding the queuing, but it 311 is restricted to transport Telephony Service Class traffic in 312 the sense of RFC 4594. 314 Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is 315 designed to transport PHB AF41, DSCP 100 010 (the other AF4 316 PHB group PHBs and DSCPs may be used for future extension of 317 the set of DSCPs carried by this Treatment Aggregate). This 318 Treatment Aggregate is designed to transport the portions of 319 RFC 5127's Real Time Treatment Aggregate, which consume large 320 amounts of bandwidth, namely Broadcast Video, Real-Time 321 Interactive and Multimedia Conferencing. The treatment 322 aggregate should be configured with a rate queue (which is in 323 line with RFC 4594 for the mentioned traffic classes). As 324 compared to RFC 5127, the number of DSCPs has been reduced to 325 one (initially) and the proposed queuing mechanism. The 326 latter is however in line with RFC4594. 328 Assured Elastic Treatment Aggregate This Treatment Aggregate 329 consists of the entire AF3 PHB group AF3, i.e., DSCPs 011 330 010, 011 100 and 011 110. As compared to RFC5127, just the 331 number of DSCPs, which has been reduced. This document 332 suggests to transport signaling marked by AF31. RFC5127 333 suggests to map Network Management traffic into this 334 Treatment Aggregate, if no separate Network Control Treatment 335 Aggregate is supported (for a more detailed discussion of 336 Network Control PHB treatment see section 3.2). GSMA IR.34 337 proposes to transport signaling traffic by AF31 too. 339 Default / Elastic Treatment Aggregate: transports the default PHB, 340 CS0 with DSCP 000 000. RFC 5127 example refers to this 341 Treatment Aggregate as Aggregate Elastic. An important 342 difference as compared to RFC5127 is that any traffic with 343 unrecognized or unsupported DSCPs may be remarked to this 344 DSCP. 346 RFC 4594's Multimedia Streaming class has not been mapped to the 347 above scheme. By the time of writing, the most popular streaming 348 applications use TCP transport and adapt picture quality in the case 349 of congestion. These applications are proprietary and still change 350 behaviour frequently. At this state, the Bulk Real-Time Treatment 351 Aggregate or the Bulk Real-Time Treatment Aggregate may be a 352 reasonable match. 354 The overall approach to DSCP marking at network interconnections is 355 illustrated by the following example. Provider O and provider W are 356 peered with provider T. They have agreed upon a QoS interconnection 357 SLA. 359 Traffic of provider O terminates within provider Ts network, while 360 provider W's traffic transits through the network of provider T to 361 provider F. Assume all providers to run their own internal codepoint 362 schemes for a PHB groupwith properties of the DiffServ Intercon 363 Assured Treatment Aggregate. 365 Provider-O Provider-W 366 RFC5127 GSMA 34.1 367 | | 368 +----------+ +----------+ 369 |AF21, AF22| | CS3, CS2 | 370 +----------+ +----------+ 371 | | 372 V V 373 +++++++++ +++++++++ 374 |Rtr PrO| |Rtr PrW| Rtr Pr: 375 +++++++++ +++++++++ Router Peering 376 | DiffServ | 377 +----------+ +----------+ 378 |AF31, AF32| |AF31, AF32| 379 +----------+ +----------+ 380 | Intercon | 381 V V 383 +++++++++ | 384 |RtrPrTI|------------------+ 385 +++++++++ 386 | Provider-T domain 387 +-----------+ 388 | MPLS TC 2 | 389 | DSCP rew. | 390 | AF21, AF22| 391 +-----------+ 392 | | Local DSCPs Provider-T 393 | | +----------+ +++++++++ 394 V +->|AF21, AF22|->-|RtrDstH| 395 | +----------+ +++++++++ 396 +----------+ RtrDst: 397 |AF21, AF22| Router Destination 398 +----------+ 399 | 400 +++++++++ 401 |RtrPrTE| 402 +++++++++ 403 | DiffServ 404 +----------+ 405 |AF31, AF32| 406 +----------+ 407 | Intercon 408 +++++++++ 409 |RtrPrF| 410 +++++++++ 411 | 412 +----------+ 413 | CS4, CS3 | 414 +----------+ 415 | 416 Provider-F 417 GSM IR.34 419 DiffServ Intercon example 421 Figure 1 423 It is easily visible that all providers only need to deploy internal 424 DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the 425 desired classes. Provider W has decided that the properties of his 426 internal classes CS3 and CS2 are best met by the Diffserv Intercon 427 Assured Elastic Treatment Aggregate, PHBs AF31 and AF32 respectively. 428 At the outgoing peering interface connecting provider W with provider 429 T remarks CS3 traffic to AF31 and CS 2 traffic to CS32. The domain 430 internal PHBs of provider T meeting the Diffserv Intercon Assured 431 Elastic Treatment Aggregate requirements is AF2. Hence AF31 traffic 432 received at the interconnection with provider T is remarked to AF21 433 by the peering router of domain T. As domain T deploys MPLS, further 434 the MPLS TC ist set to 2. Traffic received with AF32 is remarked to 435 AF22. The MPLS TC of the Treatment Aggregate is the same, TC 2. At 436 the pen-ultimate MPLS node, the top MPLS label is removed. The 437 packet should be forwarded as determined by the incoming MPLS TC. 438 The peering router connecting domain T with domain F classifies the 439 packet by it's domain T internal DSCP AF21 for the Diffserv Intercon 440 Assured Elastic Treatment Aggregate. As it leaves domain T on the 441 interface to domain F, it is remarked to AF31. The peering router of 442 domain F classifies the packet for domain F internal PHB CS4, as this 443 is the PHB with properties matching DiffServ Intercon's Assured 444 Elastic Treatment Aggregate. Likewise, AF21 traffic is remarked to 445 AF32 by the peering router od domain T when leaving it and from AF32 446 to CS3 by domain F's peering router when receiving it. 448 This example can be extended. Suppose Provider-O also supports a PHB 449 marked by CS2 and this PHB is supposed to be transported by QoS 450 within Provider-T domain. Then Provider-O will remark it with a DSCP 451 other than AF31 DSCP in order to preserve the differentiation from 452 CS2; AF11 is one possibility that might be private to the 453 interconnection between Provider-O and Provider-T; there's no 454 assumption that Provider-W can also use AF11, as it may not be in the 455 SLA with Provider-W. 457 Now suppose Provider-W supports CS2 for internal use only. Then no 458 DiffServ intercon DSCP mapping may be configured at the peering 459 router. Traffic, sent by Provider-W to Provider-T marked by CS2 due 460 to a misconfiguration may be remarked to CS0 by Provider-T. 462 See section 3.1 for further discussion of this and DSCP transparency 463 in general. 465 RFC5127 specifies a separate Treatment Aggregate for network control 466 traffic. It may be present at interconnection interfaces too, but 467 depending on the agreement between providers, Network Control traffic 468 may also be classified into a different interconnection class. See 469 section 3.2 for a detailed discussion on the treatment of Network 470 Control traffic. 472 RFC2575 states that Ingress nodes must condition all other inbound 473 traffic to ensure that the DS codepoints are acceptable; packets 474 found to have unacceptable codepoints must either be discarded or 475 must have their DS codepoints modified to acceptable values before 476 being forwarded. For example, an ingress node receiving traffic from 477 a domain with which no enhanced service agreement exists may reset 478 the DS codepoint to the Default PHB codepoint. As a consequence, an 479 interconnect SLA needs to specify not only the treatment of traffic 480 that arrives with a supported interconnect DSCP, but also the 481 treatment of traffic that arrives with unsupported or unexpected 482 DSCPs. 484 The proposed interconnect class and code point scheme is designed for 485 point to point IP layer interconnections among MPLS networks. Other 486 types of interconnections are out of scope of this document. The 487 basic class and code point scheme is applicable on Ethernet layer 488 too, if a provider e.g. supports Ethernet pririties like specified by 489 IEEE 802.1p. 491 3.1. End-to-end QoS: PHB and DS CodePoint Transparency 493 This section describes how the use of a common PHB and DSCP scheme 494 for interconnection can lead to end-to-end DiffServ-based QoS across 495 networks that do not have common policies or practices for PHB and 496 DSCP usage. This will initially be possible for PHBs and DSCPs 497 corresponding to at most 3 or 4 Treatment Aggregates due to the MPLS 498 considerations discussed previously. 500 Networks can be expected to differ in the number of PHBs available at 501 interconnections (for terminating or transit service) and the DSCP 502 values used within their domain. At an interconnection, Treatment 503 Aggregate and PHB properties are best described by SLAs and related 504 explanatory material. See annex A for a more detailed discussion 505 about why PHB and g DSCP usage is likely to differ among networks. 506 For the above reasons and the desire to support interconnection among 507 networks with different DiffServ schemes, the DiffServ 508 interconnection scheme supports a small number of PHBs and DSCPs; 509 this scheme is expandable. 511 The basic idea is that traffic sent with a DiffServ interconnect PHB 512 and DSCP is restored to that PHB and DSCP (or a PHB and DSCP within 513 the AF3 PHB group for the Assured Treatment Aggregate) at each 514 network interconnection, even though a different PHB and DSCP may be 515 used by each network involved. So, Bulk Inelastic traffic could be 516 sent with AF41, remarked to CS3 by the first network and back to AF41 517 at the interconnection with the second network, which could mark it 518 to CS5 and back to AF41 at the next interconnection, etc. The result 519 is end-to-end QoS treatment consistent with the Bulk Inelastic 520 Traffic Aggregate, and that is signaled or requested by the AF41 DSCP 521 at each network interconnection in a fashion that allows each network 522 operator to use their own internal PHB and DSCP scheme. 524 The key requirement is that the network ingress interconnect DSCP be 525 restored at network egress, and a key observation is that this is 526 only feasible in general for a small number of DSCPs. 528 3.2. Treatment of Network Control traffic at carrier interconnection 529 interfaces 531 As specified by RFC4594, section 3.2, Network Control (NC) traffic 532 marked by CS6 is to be expected at interconnection interfaces. This 533 document does not change NC specifications of RFC4594, but observes 534 that network control traffic received at network ingress is generally 535 different from network control traffic within a network that is the 536 primary use of CS6 envisioned by RFC 4594. A specific example is 537 that some CS6 traffic exchanged across carrier interconnections is 538 terminated at the network ingress node (e.g., if BGP is running 539 between two routers on opposite ends of an interconnection link), 540 which is consistent with RFC 4594's recommendation to not use CS6 541 when forwarding CS6-marked traffic originating from user-controlled 542 end points. 544 The end-to-end QoS discussion in the previous section (3.1) is 545 generally inapplicable to network control traffic - network control 546 traffic is generally intended to control a network, not be 547 transported across it. One exception is that network control traffic 548 makes sense for a purchased transit agreement, and preservation of 549 CS6 for network control traffic that is transited is reasonable in 550 some cases. Use of an IP tunnel is suggested in order to reduce the 551 risk of CS6 markings on transiting network control traffic being 552 interpreted by the network providing the transit. 554 If the MPLS Short Pipe model is deployed for non tunneled IPv4 555 traffic, an IP network provider should limit access to the CS6 and 556 CS7 DSCPs so that they are only used for network control traffic for 557 the provider's own network. 559 Interconnecting carriers should specify treatment of CS6 marked 560 traffic received at a carrier interconnection which is to be 561 forwarded beyond the ingress node. An SLA covering the following 562 cases is recommended when a provider wishes to send CS6 marked 563 traffic across an interconnection link which isn't terminating at the 564 interconnected ingress node: 566 o classification of traffic which is network control traffic for 567 both domains. This traffic should be classified and marked for 568 the NC PHB. 570 o classification of traffic which is network control traffic for the 571 sending domain only. This traffic should be classified for a PHB 572 offering similar properties as the NC class (e.g. AF31 as 573 specified by this document). As an example GSMA IR.34 proposes an 574 Interactive class / AF31 to carry SIP and DIAMETER traffic. While 575 this is service control traffic of high importance to the 576 interconnected Mobile Network Operators, it is certainly no 577 Network Control traffic for a fixed network providing transit. 578 The example may not be perfect. It was picked nevertheless 579 because it refers to an existing standard. 581 o any other CS6 marked traffic should be remarked or dropped. 583 4. Acknowledgements 585 Al Morton and Sebastien Jobert provided feedback on many aspects 586 during private discussions. Mohamed Boucadair and Thomas Knoll 587 helped adding awareness of related work. Fred Baker and Brian 588 Carpenter provided intensive feedback and discussion. 590 5. IANA Considerations 592 This memo includes no request to IANA. 594 6. Security Considerations 596 This document does not introduce new features, it describes how to 597 use existing ones. The security section of RFC 2475 [RFC2475] and 598 RFC 4594 [RFC4594] apply. 600 7. References 602 7.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 608 "Definition of the Differentiated Services Field (DS 609 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 610 1998. 612 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 613 and W. Weiss, "An Architecture for Differentiated 614 Services", RFC 2475, December 1998. 616 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 617 "Assured Forwarding PHB Group", RFC 2597, June 1999. 619 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 620 J., Courtney, W., Davari, S., Firoiu, V., and D. 621 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 622 Behavior)", RFC 3246, March 2002. 624 [RFC3260] Grossman, D., "New Terminology and Clarifications for 625 Diffserv", RFC 3260, April 2002. 627 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 628 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 629 Protocol Label Switching (MPLS) Support of Differentiated 630 Services", RFC 3270, May 2002. 632 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 633 Marking in MPLS", RFC 5129, January 2008. 635 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 636 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 637 Class" Field", RFC 5462, February 2009. 639 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 640 Services Code Point (DSCP) for Capacity-Admitted Traffic", 641 RFC 5865, May 2010. 643 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 645 7.2. Informative References 647 [I-D.knoll-idr-cos-interconnect] 648 Knoll, T., "BGP Class of Service Interconnection", draft- 649 knoll-idr-cos-interconnect-13 (work in progress), November 650 2014. 652 [ID.idr-sla] 653 IETF, "Inter-domain SLA Exchange", IETF, 654 http://datatracker.ietf.org/doc/ 655 draft-ietf-idr-sla-exchange/, 2013. 657 [IEEE802.1Q] 658 IEEE, "IEEE Standard for Local and Metropolitan Area 659 Networks - Virtual Bridged Local Area Networks", 2005. 661 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 662 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 663 http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ 664 ir.34.pdf, 2012. 666 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 667 Class of Service Phase 2", MEF, MEF23.1 668 http://metroethernetforum.org/PDF_Documents/technical- 669 specifications/MEF_23.1.pdf, 2012. 671 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 672 2983, October 2000. 674 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 675 Guidelines for DiffServ Service Classes", RFC 4594, August 676 2006. 678 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 679 Diffserv Service Classes", RFC 5127, February 2008. 681 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 682 to-Provider Agreements for Internet-Scale Quality of 683 Service (QoS)", RFC 5160, March 2008. 685 [Y.1566] ITU-T, "Quality of service mapping and interconnection 686 between Ethernet, IP and multiprotocol label switching 687 networks", ITU, 688 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 690 Appendix A. Annex A Carrier interconnection related DiffServ aspects 692 This annex provides a general discussion of PHB and DSCP mapping at 693 IP interconnection interfaces. It also informs about limitations and 694 likely DSCP changes. 696 The following scenarios start from a domain sending non-tunneled IP 697 traffic using a PHB and a corresponding DSCP to an interconnected 698 domain. The receiving domain may 700 o Support the PHB and offer the same corresponding DSCP. 702 o Not support the PHB and use the DSCP for a different PHB. 704 o Not support the PHB and not use the DSCP. 706 o Support the PHB with a differing DSCP, and the DSCP of the sending 707 domain is not used for another PHB 709 o Support the PHB with a differing DSCP, and the DSCP of the sending 710 domain is used for another PHB. 712 RFC2475 allows for local use PHB groups which are only available 713 within a domain. If such a local use PHB is present, non-tunneled IP 714 traffic possibly cannot utilize 64 DSCPs end-to-end. 716 If a domain receives traffic for a PHB, which it does not support, 717 there are two general scenarios: 719 o The received DSCP is not available for usage within the domain. 721 o The received DSCP is available for usage within the domain. 723 RFC2474 suggests to transport packets received with unrecognized 724 DSCPs by the default PHB and leave the DSCP as received. Also if a 725 particular DSCP is spare within a domain, it may later change its QoS 726 design and assign a PHB to a formerly unused DSCP (which a customer 727 used to transit through this unrecognized DSCP will note, as his DSCP 728 will the be remarked). A transparent transport of the same DSCP as 729 unknown with the default PHB may no longer be possible. Remarking to 730 another DSCP apart from the Default PHBs DSCP does not seem to be a 731 good option in the latter case. Which other DSCP is making sense? 732 If a domain interconnects with many other domains, the questions 733 asked here may have to be answered multiple times. 735 The scenarios above indicate, that reliably delivering a non-tunneled 736 IP packet by the same PHB and DSCP unchanged end-to-end is only 737 likely, if both domains support this DSCP and use the same 738 corresponding DSCP. 740 Limitations in the number of supported PHBs are to be expected if 741 DiffServ is applied across different domains. Unchanged end-to-end 742 DSCPs should only be expected for non-tunneled IP traffic, if the PHB 743 and DSCP are well specified and generally deployed. This is true for 744 Default Forwarding. EF PHB is a candidate. The Network Control PHB 745 is a local use only example, hence end-to-end support of CS6 for non- 746 tunneled IP traffic at interconnection points should only be 747 expected, if the receiving domain regards this traffic as Network 748 Control traffic relevant for the own domain too. 750 DiffServ Intercon proposes a well defined set of PHBs and 751 corresponding DSCPs at interconnection points. A PHB to DSCPs 752 correspondence is specified at least for interconnection interfaces. 753 Supported PHBs should be available end-to-end, but domain internal 754 DSCPs may change end-to-end. 756 Appendix B. Annex 2 The MPLS Short Pipe Model and IP traffic 758 The MPLS Short Pipe Model (or Pen-ultimate Hop Label Popping) is 759 widely deployed by IP carriers. If non-tunneled IPv4 traffic is 760 transported using MPLS Short Pipe, IP headers appear inside the last 761 section of the MPLS domain. This likely impacts the number of PHBs 762 and DSCPs a network provider supports for this kind of traffic. 763 Figure 2 provides an example for the treatment of this kind of 764 traffic. 766 In the case of tunneled IPv4 traffic, only the outer tunnel header is 767 exposed. Assuming the tunnel not to terminate within the MPLS 768 network section, only the outer tunnel DSCP is impacted. 770 Non-tunneled IPv6 traffic and Layer 2 and Layer 3 VPN traffic all use 771 an additional label. Hence no IP header is exposed within an MPLS 772 domain. 774 Carriers may first design their own QoS PHB and codepoint scheme 775 before they worry about interconnection. PHB and corresponding 776 codepoint schemes usually differ between different carriers. PHBs 777 may be mapped. A DSCP rewrite should be expected at an 778 interconnection interface at least for plain IP traffic. 780 RFC3270 suggests deployment of the Short Pipe Model only in the case 781 of VPNs. State of the art deployments also support transport of non 782 tunneled IPv4 traffic. This is shown in figure 2. 784 | 785 \|/ IPv4, DSCP_send 786 V 787 | 788 Peering Router 789 | 790 \|/ IPv4, DSCP_send 791 V 792 | 793 MPLS Edge Router 794 | Mark MPLS Label, TC_internal 795 \|/ Remark DSCP to 796 V (Inner: IPv4, DSCP_d) 797 | 798 MPLS Core Router (pen-ultimate hop label popping) 799 | \ 800 | IPv4, DSCP_d | The DSCP needs to be in domain 801 | ^^^^^^^^| internal QoS context. The Core 802 \|/ > Router might require or enforce 803 V | it. The Edge Router may wrongly 804 | | classify, if the DSCP is not in 805 | / domain internal DiffServ context. 806 MPLS Edge Router 807 | \ With well defined PHBs and 808 \|/ IPv4, DSCP_d | corresponding DSCPs at interdomain 809 V > links, more than one DSCP per 810 | | treatment aggregate may pass a 811 | / domain and carry a well defined 812 Peer Router DSCP when leaving it. 813 | Remark DSCP to 814 \|/ IPv4, DSCP_send 815 V 816 | 818 Short-Pipe / Pen-ultimate hop popping example 820 Figure 2 822 The packets IP DSCP must be in a well understood Diffserv context for 823 schedulers and classifiers on the interfaces of the ultimate MPLS 824 link. These are domain internal and a domain operating in this mode 825 enforces DSCPs resulting in reliable domain internal QoS operation. 827 Without DiffServ-Intercon treatment, the traffic always leaves the 828 domain having internal DS codepoints. DSCP_send of the figure above 829 is remarked to the receiving domains DiffServ scheme. It leaves the 830 domain marked by the domains DSCP_d. Every carrier must deploy per 831 peer PHB and DSCP mapping schemes. 833 If DiffServ-Intercon is applied, only traffic terminating within a 834 domain must be aligned with the domain internal DiffServ Codepoint 835 scheme. Traffic transiting through the domain can be easily mapped 836 and remapped to an original DSCP. This is shown in figure 3. Of 837 course the domain internal limitations caused by the Short Pipe model 838 still apply. 840 Internal Router 841 | 842 | Outer Header 843 \|/ IPv4, DSCP_send 844 V 845 | 846 Peering Router 847 | Remark DSCP to 848 \|/ IPv4, DSCP_ds-int DiffServ Intercon DSCP and PHB 849 V 850 | 851 MPLS Edge Router 852 | 853 | Mark MPLS Label, TC_internal 854 \|/ Remark DSCP to 855 V (Inner: IPv4, DSCP_d) domain internal DSCP for 856 | the PHB 857 MPLS Core Router (pen-ultimate hop label popping) 858 | 859 | IPv4, DSCP_d 860 | ^^^^^^ 861 \|/ 862 V 863 | 864 | 865 MPLS Edge Router--------------------+ 866 | | 867 \|/ Remark DSCP to \|/ IPv4, DSCP_d 868 V IPv4, DSCP_ds-int V 869 | | 870 | | 871 Peer Router Domain internal Broadband 872 | Access Router 873 \|/ Remark DSCP to \|/ 874 V IPv4, DSCP_send V IPv4, DSCP_d 875 | | 877 Short-Pipe example with Diffserv-Intercon 879 Figure 3 881 Picking up terminology of RFC2983 and RFC3270, DiffServ intercon 882 emulates the long pipe model for the PHBs it supports, if traffic is 883 terminating in the receiving domain. 885 Looking at the peering interfaces only, for transiting QoS traffic 886 DiffServ-Intercon emulates the uniform model for the PHBs and DSCPs 887 supported. Packets are expected to leave a domain with the DSCP/PHB 888 as received (and per flow within each PHB in the same order as 889 received). MPLS Treatment Aggregates should not experience 890 congestion under standard operational conditions. The peering links 891 need to engineered to be congestion free too for QoS PHBs, if also 892 the IP transit transport is to be congestion free. 894 Appendix C. Change log 896 00 to 01 Added terminology and references. Added details and 897 information to interconnection class and codepoint scheme. 898 Editorial changes. 900 01 to 02 Added some references regarding related work. Clarified 901 class definitions. Further editorial improvements. 903 02 to 03 Consistent terminology. Discussion of Network Management 904 PHB at interconnection interfaces. Editorial review. 906 03 to 04 Again improved terminology. Better wording of Network 907 Control PHB at interconnection interfaces. 909 04 to 05 Large rewrite and re-ordering of contents. 911 05 to 06 Description of IP and MPLS related requirements and 912 constraints on DSCP rewrites. 914 06 to 07 Largely rewrite, improved match and comparison with RFCs 915 4594 and 5127. 917 07 to 08 Added Annex A and B which where forgotten when putting 918 together -07 920 Authors' Addresses 922 Ruediger Geib (editor) 923 Deutsche Telekom 924 Heinrich Hertz Str. 3-7 925 Darmstadt 64295 926 Germany 928 Phone: +49 6151 5812747 929 Email: Ruediger.Geib@telekom.de 930 David L. Black 931 EMC Corporation 932 176 South Street 933 Hopkinton, MA 934 USA 936 Phone: +1 (508) 293-7953 937 Email: david.black@emc.com