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