idnits 2.17.1 draft-geib-tsvwg-diffserv-intercon-06.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: ---------------------------------------------------------------------------- No issues found here. 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 (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC3260' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Q' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-12 Summary: 0 errors (**), 0 flaws (~~), 8 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 July 4, 2014 4 Expires: January 5, 2015 6 DiffServ interconnection classes and practice 7 draft-geib-tsvwg-diffserv-intercon-06 9 Abstract 11 This document proposes a limited and well defined set of QoS PHBs and 12 PHB groups to be applied at (inter)connections of two separately 13 administered and operated networks. Many network providers operate 14 Treatment Aggregate of different DiffServ classes. This draft offers 15 a simple and constrained interconnection concept which may simplify 16 operation and negotiation of DiffServ at interconnection points. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 5, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. An Interconnection class and codepoint scheme . . . . . . . . 5 56 3.1. Limitations arising from the MPLS Short Pipe model . . . . 9 57 3.2. Treatment of Network Control traffic at carrier 58 interconnection interfaces . . . . . . . . . . . . . . . . 9 59 4. DiffServ Intercon relation to other QoS standards 60 (revision may be required) . . . . . . . . . . . . . . . . . . 10 61 4.1. MPLS, Ethernet and DSCP Precedence Prefixes for 62 aggregated classes . . . . . . . . . . . . . . . . . . . . 11 63 4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11 64 4.3. Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12 65 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 Many providers operate MPLS based backbones. RFC 5127 assumes 84 backbone engineering to ensure that a major link, switch, or router 85 can fail, and the result will be a routed network that still meets 86 ambient Service Level Agreements classes(SLAs) [RFC5127]. Based on 87 it, RFC5127 introduces the concept of Treatment Aggregates, which 88 allow to forward multiple DSCPs by a single MPLS Traffic Class. This 89 draft shares the assumption of RFC 5127 on backbone engineering. 90 RFC3270 adds the Short Pipe Models to the Pipe and Uniform Model 91 already defined for Differentiated Services and Tunnels [RFC2983] , 92 [RFC3270]. It was required due to the presence of Pen-ultimate hop 93 popping (PHP) of MPLS Labels. RFC3270 expects the Short Pipe model 94 only to be deployed for IP tunnels and VPNs. If it used to transport 95 non tunneled IP traffic, some restrictions may apply for DSCP 96 transparency. The Short Pipe model is popular with many network 97 providers operating MPLS. 99 RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. 100 Differentiated treatment is based on the specific DSCP. Once set, it 101 may change, but any DSCP rewrite is always a one by one mapping. 102 What is not allowed is remarking n received DSCPs to a single 103 transmitted DSCP. If unknown DSCPs are received, RFC2474 recommends 104 transmitting them unchanged by default forwarding. An MPLS network 105 supporting the Short Pipe model for not tunneled IPv4 traffic may 106 need to be able to correctly classify or rewrite the IP DSCP on 107 interfaces between the last Label Switch Router and a Label Edge 108 Router. In that case, it may not be possible to transmit 64 DSCPs 109 through this domain. 111 RFC5127 proposes to transmit DSCPs as they are received in general. 112 This is not possible, if the receiving and the transmitting domain 113 use different DSCPs for the PHBs to which traffic is mapped if both 114 interconnect. 116 This draft adresses IP interconnection supporting DiffServ to or 117 between providers operating MPLS in their backbone. It proposes 118 operational simplifications and methods to match IP DiffServ 119 requirements with MPLS limitations (especially regarding the Short 120 Pipe Model if applied for non tunnel IPv4 traffic). The scope of 121 this draft is limited to 4 specified interconnection Treatment 122 Aggregates. To ease operation and to ensure traffic to leave a 123 domain with the DSCPs received, small sets of specific DSCPs and a 124 definition of their Treatment Aggregate PHB are suggested. The 125 mechanism proposed here may be extended. This is relevant only if it 126 sees some deployment, and it is preferred to start with a limited and 127 simple approach to clarify the concept. 129 At first glance, the interconnection codepoint scheme may look like 130 an additional effort. But there are some obvious benefits: each 131 party sending or receiving traffic has to specify the mapping from or 132 to the interconnection class and code point scheme only once. 133 Without it, this is to be negotiated per interconnection party 134 individually. Further, end-to-end QoS in terms of traffic being 135 classified for say, for a sufficiently similar PHB in all passed 136 domains is more likely to result if an interconnection code point 137 scheme is used. This draft supports a remarking of one DSCP only to 138 one other DSCPs (no n DSCP to one DSCP remarking). 140 The example given in RFC 5127 on aggregation of DiffServ service 141 classes picks 4 Treatment Aggregates. This draft also favours 4 142 Treatment Aggregates. Reasons to favour working with 4 DiffServ 143 Treatment Aggregates: 145 o There should be a coding reserve for interconnection classes. 146 This leaves space for future standards, for private bilateral 147 agreements and for provider internal classes. 149 o The fields available for carrying QoS information (e.g., DiffServ 150 PHB) in MPLS and Ethernet are only 3 bits in size, and are 151 intended for more than just QoS purposes (see e.g. [RFC5129]). 153 o Migrations from one code point scheme to another may require spare 154 QoS code points. 156 RFC5127 provides recommendations on aggregation of IP DSCPs into MPLS 157 Treatment Aggregates and offers a deployment example [RFC5127]. 158 RFC5127 seems to be based on an assumption the the MPLS Short Pipe 159 model is only deployed for tunneled IP products or VPNs. This draft 160 assumes presence of non tunneled IPv4 traffic and deployment of the 161 MPLS Short Pipe model. That requires deviating from the RFC5127 162 example as follows: 164 o DSCP remarking is to be expected at provider edges, if the domain 165 is terminating this traffic. 167 o This draft follows RFC4594 in the proposed marking of provider 168 Network Control traffic and expands RFC4594 on treatment of CS6 169 marked traffic at interconnection points (see section 5.2). 171 The proposed Interconnection class and code point scheme tries to 172 reflect and consolidate related DiffServ and QoS standardisation 173 efforts outside of the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and 174 ITU [Y.1566]. GSMAs IR.34 specifies an inter provider VPN, but it is 175 nevertheless specifying a kind of DiffServ aware IP based carrier 176 interconnection. 178 1.1. Related work 180 In addition to the standardisation activities which triggered this 181 work, other authors published RFCs or drafts which may benefit from 182 an interconnection class- and codepoint scheme. RFC 5160 suggests 183 Meta-QoS- Classes to enable deployment of standardised end to end QoS 184 classes [RFC5160]. The authors agree that the proposed 185 interconnection class- and codepoint scheme as well as the idea of 186 standardised end to end classes would complement their own work. 187 Work on signaling Class of Service at interconnection interfaces by 188 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the 189 scope of this draft. Should the basic transport and class properties 190 be standardised as proposed here, signaled access to QoS classes may 191 be of interest. The current BGP drafts focus on exchanging SLA and 192 traffic conditioning parameters. They seem to assume that common 193 interpretation of the PHB properties identified by DSCPs has been 194 established prior to exchanging further details by BGP signaling. 196 2. Terminology 198 This draft reuses existing terminology of RFCs 2474 and 5127. 200 3. An Interconnection class and codepoint scheme 202 Interconnecting parties face the problem of matching classes to be 203 interconnected and then to agree on code point mapping. As stated by 204 the DiffServ Architecture [RFC2475], remarking is a standard 205 behaviour at interconnection interfaces. If the MPLS Short Pipe 206 model is deployed by the receiving domain, the Label Switch Router 207 prior to and the destination Label Edge Router may have to correctly 208 classify traffic by its DSCP. To avoid DSCPs being misused, only 209 domain internal DSCPs may be tolerated there. This means, that 210 traffic terminating within this domain will be delivered with the 211 DSCP matching the properties of the PHB at interconnection, but with 212 the DSCP assigned by the terminating domain. This draft proposes a 213 standard interconnection set of 4 Treatment Aggregates with well 214 defined DSCPs to be aggregated by them. A sending party remarks 215 DSCPs from internal schemes to the Interconnection code points. The 216 receiving party remarks DSCPs to her internal scheme. The 217 interconnection code point scheme fully complies with the DiffServ 218 architecture. DiffServ compliance does not allow for a rewrite of 219 several received DSCPs with a single DSCP to be transmitted. The set 220 of DSCPs and PHBs supported accross the two interconnected domains 221 and the treatment of PHBs and DSCPs not recognised by any of both 222 domains should be part of an SLA. DiffServ transit to a third party 223 network is excluded for initial versions of this draft (but may be 224 added if there's interest). 226 This draft picks up the DiffServ interconnection class defintions 227 proposed by ITU-T Y.1566 [Y.1566]. The classes defined there, are 228 used as MPLS Treatment Aggregates here. This draft proposes a set of 229 Treatment Aggregate PHBs and DSCPs to be aggregated. Their 230 properties differ slightly from those of the RFC5127 example: 232 Class Priority: PHB EF, DSCP 101 110. The figures of merit 233 describing the PHB to be in the range of low single digit 234 milliseconds. See [RFC3246]. This class corresponds to RFC 235 5127's real time class, but it is limited to traffic for 236 which node configuration "ensures that the service rate of EF 237 packets on a given output interface exceeds their arrival 238 rate at that interface over long and short time intervals" 239 (see RFC 3246). 241 Bulk inelastic: The Treatment Aggregate is initially designed only 242 to transport PHB AF41, DSCP 100 010 (the other AF4 PHB group 243 PHB's and DSCPs should be reserved for future extension of 244 the set of DSCPs carried by this Treatment Aggregate). 245 Optimised for low loss, low delay, low jitter at high 246 bandwidth. Traffic load in this class must be controlled, 247 e.g. by application servers. One example could be flow 248 admission control. There may be infrequent retransmissions 249 requested by the application layer to mitigate low levels of 250 packet losses. Discard of packets through active queue 251 management should be avoided in this class. Congestion in 252 this class may result in bursty packet loss. If used to 253 carry multimedia traffic, it is recommended to carry audio 254 and video traffic in a single PHB (note that video 255 conferencing may require separate PHBs for audio and video 256 traffic, which could also be realised by utilising two AF 4 257 PHBs). All of these properties influence the buffer design. 258 This class is designed to transport those parts of RFC 5127's 259 Real Time class, which consume considerable QoS bandwidth at 260 the interconnection interface. 262 Assured: The complete PHB group AF3, DSCPs 011 010, 011 100 and 011 263 110 is transmitted by this Treatment Aggregate. It may be 264 optimised to transport traffic without bandwidth 265 requirements. It aims on very low loss at high bandwidths. 266 Retransmissions after losses characterise the class and 267 influence the buffer design. Active queue management with 268 probabilistic dropping may be deployed. The RFC 5127 example 269 calls this class Assured Elastic. 271 Default: The Treatment Aggregate for the default PHB, CS0 with DSCP 272 000 000. This class may be optimised to transport traffic 273 without bandwidth requirements. Retransmissions after losses 274 characterise the class and influence the buffer design. 275 Active queue management with probabilistic dropping may be 276 deployed. The RFC 5127 example calls this class Elastic. 278 RFC2474 recommends leaving DSCPs unknown to a receiving domain 279 unchanged while default PHB transport is provided. If there's 280 community interest in this draft, current carrier deployments should 281 be checked for support of this RFC2474 recommendation. 283 The idea is illustrated by an example. Provider O and provider W are 284 peer with provider T. They have agreed upon a QoS interconnection. 285 Traffic of provider O terminates within provider Ts network, while 286 the GSMA IR.34 traffic transits through the netwirk of provider T to 287 provider F. Assume all providers to run their own internal codepoint 288 schemes for a class with properties of the DiffServ Intercon Assured 289 Treatment Aggregate. See below for a description of GSMA IR.34. 291 Provider-O Provider-W 292 RFC5127 GSMA 34.1 293 | | 294 +----------+ +----------+ 295 |AF21, AF22| |AF31, AF21| 296 +----------+ +----------+ 297 | | 298 V V 299 +++++++++ +++++++++ 300 |Rtr PrO| |Rtr PrW| 301 +++++++++ +++++++++ 302 | DiffServ | 303 +----------+ +----------+ 304 |AF31, AF32| |AF31, AF32| 305 +----------+ +----------+ 306 | Intercon | 307 V V 308 +++++++++ | 309 |RtrPrTI|------------------+ 310 +++++++++ 311 | Provider-T domain 312 +-----------+ 313 | MPLS TC 2 | 314 | DSCP rew. | 315 | AF21, AF22| 316 +-----------+ 317 | | Local DSCPs Provider-T 318 | | +----------+ +++++++++ 319 V +->|AF21, AF22|->-|RtrDstH| 320 | +----------+ +++++++++ 321 +----------+ 322 |AF21, AF22| 323 +----------+ 324 | 325 +++++++++ 326 |RtrPrTE| 327 +++++++++ 328 | DiffServ 329 +----------+ 330 |AF31, AF32| 331 +----------+ 332 | Intercon 333 +++++++++ 334 |RtrPrHF| 335 +++++++++ 336 | 337 +----------+ 338 |AF31, AF21| 339 +----------+ 340 | 341 Provider-F 342 GSM IR.34 344 DiffServ Intercon example 346 Figure 1 348 It is easily visible that all providers only need to deploy internal 349 DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the 350 desired classes. 352 RFC5127 specifies a separate Treatment Aggregate for network control 353 traffic. It may be present at interconnection interfaces too, but 354 depending on the agreement between providers, Network Control traffic 355 may also be classified for another interconnection class. See below 356 for a detailed discussion on the treatment of Network Control 357 traffic. 359 The proposed class and code point scheme is designed for point to 360 point IP layer interconnections. Other types of interconnections are 361 out of scope of this document. The basic class and code point scheme 362 is applicable on Ethernet layer too. 364 3.1. Limitations arising from the MPLS Short Pipe model 366 If non tunneled IPv4 traffic is transmitted by deploying the MPLS 367 Short Pipe model as specified by RFC3270, then IP DSCPs may be used 368 for classification or they may be remarked at interfaces between the 369 destination Label Edge Router and the Label Switch Router. Domain 370 internal Treatment Aggregates may be applicable, e.g. for domain 371 internal network control traffic. This Treatment Aggregate and the 372 DSCPs which are aggregated by it, may not be available for customer 373 traffic. A domain supporting such an internal Treatment Aggregate 374 can't support a set of 64 DSCPs in that case. As mentioned below, 375 the number of PHBs and their DSCPs supported end-to-end should be as 376 well defined as the treatment of not recognised DSCPs when 377 negotiating interconnection. 379 The situation is more relaxed for tunneled IPv4 traffic, IPv6 traffic 380 in general (for the time being) and for VPN traffic. If there's 381 community interest, a later version of this discuss this in more 382 detail. 384 3.2. Treatment of Network Control traffic at carrier interconnection 385 interfaces 387 As specified by RFC4594, section 3.2, Network Control (NC) traffic 388 marked by CS6 is to be expected at interconnection interfaces. This 389 document does not change NC specifications of RFC4594. The latter 390 specification is detailed on domain internal NC traffic and on 391 traffic exchanged between peering points. Further, it recommends not 392 to forward CS6 marked traffic originating from user-controlled end 393 points by the NC class of a provider domain. 395 As a minor clarification to RFC4594, "peering" shouldn't be 396 interpreted in a commercial sense. The NC PHB is applicable also in 397 the case of a purchased network service based on a transit agreement 398 with an upstream provider. RFC4594 recommendations on NC traffic are 399 applicable for IP carrier interconnections in general. 401 Some CS6 traffic exchanged accross carrier interconnections will 402 terminate at the domain ingress node (e.g., if BGP is running between 403 the two routers on opposite ends of the interconnection link). 405 If the MPLS Short Pipe model is deployed for non tunneled IPv4 406 traffic, an IP carrier may limit access to the NC PHB for traffic 407 which is recognised as network control traffic relevant to the own 408 domain. Interconnecting carriers should specify treatment of CS6 409 marked traffic received at a carrier interconnection which is to be 410 forwarded beyond the ingress node. An SLA covering the following 411 cases is recommended, if a carrier wishes to send CS6 marked traffic 412 accross an interconnection link which isn't terminating at the 413 interconnected ingress node: 415 o classification of traffic which is network control traffic for 416 both domains. This traffic should be classified and marked for 417 the NC PHB. 419 o classification of traffic which is network control traffic for the 420 sending domain only. This traffic should be classified for a PHB 421 offering similar properties as the NC class (e.g. AF31 as 422 specified by this document). As an example GSMA IR.34 proposes an 423 Interactive class / AF31 to carry SIP and DIAMETER traffic. While 424 this is service control traffic of high importance to the 425 interconnected Mobile Network Operators, it is certainly no 426 Network Control traffic for a fixed network providing transit. 427 The example may not be perfect. It was picked nevertheless 428 because it refers to an existing standard. 430 o any other CS6 marked traffic should be remarked or dropped. 432 4. DiffServ Intercon relation to other QoS standards (revision may be 433 required) 435 This sections provides suggestions how to aggregate traffic by DSCP 436 Precedence Prefexies to Ethernet and MPLS. Other Standardisation 437 Organsiations deal with QoS aware provider interconnection. As IP is 438 the state of the art realisation of provider interconnections, these 439 standards bodies specify DiffServ aware interconnections. Some of 440 these bodies are industry alliances chartered also to promote 441 interconnection of wireless or Ethernet technology including the 442 exchange of IP datagrams at interconnection points. Examples are the 443 Metro Ethernet Forum (MEF) or the GSM Alliance (GSMA). The ITU was 444 mentioned earlier. ITU works across and between responsibilities of 445 different Standardisation Organisations and liaising with them, if 446 their responsibilities are touched, is traditional part of that 447 process. 449 4.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes 451 The interconnection class and code point scheme respects properties 452 and limits of a 3 bit PHB coding space in different ways: 454 o it allows to classify four interconnection classes based on the 455 DSCP Precedence Prefix. 457 o it supports a single PHB group (AF3), whose DSCPs may be 458 aggregated into a sinle MPLS TC (or Ethernet priority) based on 459 their joint DSCP Precedence Prefix. This kind of aggregation will 460 work for the AF4 PHB group, if the PHBs AF42 and AF43 need to be 461 supported in addition to AF41. 463 o Applying only 4 aggregated classes at interconnection allows for 464 bilateral extensions, if desired. Should two carriers agree to 465 map AF32 and AF33 to an additional individual MPLS TC and offer an 466 Ordered Aggregate across the interconnecting domain, this proposal 467 at leaves some MPLS TC coding space for such an extension 468 (although this draft doesn't recommend interconnections of that 469 type). 471 The above statement is no requirement to depricate any DSCP to MPLS 472 TC or Ethernet P-Bit mapping functionality. In the opposite, by 473 limiting the interconnection scheme to 6 PHBs, each PHB may be mapped 474 to an individual Traffic Class or Priority also within MPLS or 475 Ethernet (if desired). 477 4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping 479 GSMA IR.34 provides guidelines on how to set up and interconnect 480 Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. An 481 IPX network is an inter-Service Provider IP backbone which comprises 482 the interconnected networks of IPX Providers. IPX is a 483 telecommunications interconnection model for the exchange of IP based 484 traffic between customers of separate mobile and fixed operators as 485 well as other types of service provider (such as ISP), via IP based 486 network-to-network interface. Note that IPX is not a public 487 interconnection model however, it is designed as a private IP 488 Backbone of the interconnected parties. Two IPX partners may 489 interconnect using transit offered by an Inter-Service Provider IP 490 Backbone. This requires an IP QoS aware interconnection as described 491 by this draft between IPX provider and Inter-Service Provider IP 492 Backbone. 494 GSMA IR.34 specifies 4 aggregated classes and 7 PHBs. Mapping to 495 DiffServ Intercon is smooth apart from the GSMA aggregated class 496 Interactive, which consistfs of 4 PHBs. The table below lists a 497 suggested mapping to DiffServ Intercon. 499 | GSMA IR.34 | DiffServ-Intercon | 500 | | | 501 | Agg. Class | PHB | Agg. Class | PHB | 502 +---------------+-------+--------------+--------+ 503 |Conversational | EF | Priority | EF | 504 +---------------+-------+--------------+--------+ 505 | Streaming | AF41 |Bulk inelastic| AF41 | 506 +---------------+-------+--------------+--------+ 507 | Interactive | AF31 | Assured | AF31 | 508 + +-------+ +--------+ 509 | (ordered by | AF32 | | | 510 + priority, +-------+ + AF32 + 511 | AF3 highest) | AF21 | | | 512 + +-------+ +--------+ 513 | | AF11 | | AF33 | 514 +---------------+-------+--------------+--------+ 515 | Background | CS0 | Default | CS0 | 516 +---------------+-------+--------------+--------+ 518 Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon 520 Figure 2 522 The motivation resulting in the design of the IR.34 Intercative class 523 are unknown to the author of this draft. It is out of scope of this 524 draft to decide how 4 PHBs can be mapped to a to single aggregated 525 class. The suggested mapping is pragmatic and tries to come as close 526 as possible to other design criteria pursued by GSMA IR.34. 528 4.3. Proposed MEF 23.1 to DiffServ Intercon mapping 530 MEF 23.1 is an implemenation agreement facilitating Ethernet service 531 interoperability and consistency between Operators and the use of a 532 common CoS Label set for Subscribers [MEF23.1]. It pursues the same 533 aims and method on Ethernet layer as this draft does on IP layer 534 (i.e. providing an interconnection class and codepoint scheme). MEF 535 23.1 addresses external network to network interfaces typically 536 interconnecting metro ethernet providers. This may typically involve 537 Ethernet Network Sections associated with typical Operator domains 538 that interconnect at external network to network interfaces. MEF 539 23.1 specifies three aggregated CoS classes. In addition, the usage 540 of a subset of Ethernet PCP and IP DSCP values is specifiedthus 541 facilitating synergies between Ethernet and IP services and networks. 543 The main purpose is specifying operator virtual (Ethernet) 544 connections. As an IP QoS model is added, this draft proposes an IP 545 class and codepoint mapping. 547 MEF 23.1 QoS mapping requires some thought as 3 classes are supported 548 of which two are Ordered Aggregates. MEF 23.1s section 8.5.1 example 549 on IP DSCP mapping may suggest supporting classification based on the 550 DSCP Precedence Prefix. MEF 23.1 section 8.5.2.1 allows the 551 conclusion that MEF class M is best mapped to this drafts Bulk 552 inelastic class. The suggested mapping MEF to DiffServ Intercon is 553 limited to the the MEF color blind mode (3 classes, no sub-classes): 555 | MEF 23.1 | DiffServ-Intercon | 556 | | | 557 | Agg. Class | PHB | Agg. Class | PHB | 558 +---------------+-------+--------------+--------+ 559 | High | EF | Priority | EF | 560 +---------------+-------+--------------+--------+ 561 | Medium | AF3 |Bulk inelastic| AF41 | 562 +---------------+-------+--------------+--------+ 563 | Low | CS1 | Default | CS0 | 564 +---------------+-------+--------------+--------+ 566 Suggested mapping of MEF 23.1 color blind mode classes and PHBs to 567 DiffServ Intercon 569 Figure 3 571 The MEF color aware mode supports Ordered Aggregates in the MEF 572 classes M and L. The MEF L specification classifies AF1 and Best 573 Effort for the same Ordered Aggregate. A Better than Best Effort 574 service produced in the same queue as best effort traffic can be 575 realized, but hasn't been standardized by IETF. This document 576 doesn't suggest any mapping. Diffserv Intercon also doesn't suggest 577 an Ordered Aggregate in the Bulk Inelastic class. Later versions of 578 this document may do so and specify a solution. Both issues are left 579 for bilateral negotiation. 581 5. Contributors 583 David Black provided many helpful comments and inputs to this work. 585 6. Acknowledgements 587 Al Morton and Sebastien Jobert provided feedback on many aspects 588 during private discussions. Mohamed Boucadair and Thomas Knoll 589 helped adding awareness of related work. David Black, Fred Baker and 590 Brian Carpenter provided intensive feedback and discussion. 592 7. IANA Considerations 594 This memo includes no request to IANA. 596 8. Security Considerations 598 This document does not introduce new features, it describes how to 599 use existing ones. The security section of RFC 2475 [RFC2475] and 600 RFC 4594 [RFC4594] apply. 602 9. References 604 9.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 610 "Definition of the Differentiated Services Field (DS 611 Field) in the IPv4 and IPv6 Headers", RFC 2474, 612 December 1998. 614 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 615 and W. Weiss, "An Architecture for Differentiated 616 Services", RFC 2475, December 1998. 618 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 619 "Assured Forwarding PHB Group", RFC 2597, June 1999. 621 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 622 J., Courtney, W., Davari, S., Firoiu, V., and D. 623 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 624 Behavior)", RFC 3246, March 2002. 626 [RFC3260] Grossman, D., "New Terminology and Clarifications for 627 Diffserv", RFC 3260, April 2002. 629 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 630 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 631 Protocol Label Switching (MPLS) Support of Differentiated 632 Services", RFC 3270, May 2002. 634 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 635 Marking in MPLS", RFC 5129, January 2008. 637 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 638 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 639 Class" Field", RFC 5462, February 2009. 641 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 643 9.2. Informative References 645 [I-D.knoll-idr-cos-interconnect] 646 Knoll, T., "BGP Class of Service Interconnection", 647 draft-knoll-idr-cos-interconnect-12 (work in progress), 648 May 2014. 650 [ID.idr-sla] 651 IETF, "Inter-domain SLA Exchange", IETF, http:// 652 datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, 653 2013. 655 [IEEE802.1Q] 656 IEEE, "IEEE Standard for Local and Metropolitan Area 657 Networks - Virtual Bridged Local Area Networks", 2005. 659 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 660 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ 661 /www.gsma.com/newsroom/wp-content/uploads/2012/03/ 662 ir.34.pdf, 2012. 664 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 665 Class of Service Phase 2", MEF, MEF23.1 http:// 666 metroethernetforum.org/PDF_Documents/ 667 technical-specifications/MEF_23.1.pdf, 2012. 669 [RFC2983] Black, D., "Differentiated Services and Tunnels", 670 RFC 2983, October 2000. 672 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 673 Guidelines for DiffServ Service Classes", RFC 4594, 674 August 2006. 676 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 677 Diffserv Service Classes", RFC 5127, February 2008. 679 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 680 to-Provider Agreements for Internet-Scale Quality of 681 Service (QoS)", RFC 5160, March 2008. 683 [Y.1566] ITU-T, "Quality of service mapping and interconnection 684 between Ethernet, IP and multiprotocol label switching 685 networks", ITU, 686 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 688 Appendix A. Change log 690 00 to 01 Added terminology and references. Added details and 691 information to interconnection class and codepoint scheme. 692 Editorial changes. 694 01 to 02 Added some references regarding related work. Clarified 695 class definitions. Further editorial improvements. 697 02 to 03 Consistent terminology. Discussion of Network Management 698 PHB at interconnection interfaces. Editorial review. 700 03 to 04 Again improved terminology. Better wording of Network 701 Control PHB at interconnection interfaces. 703 04 to 05 Large rewrite and re-ordering of contents. 705 05 to 06 Description of IP and MPLS related requirements and 706 constraints on DSCP rewrites. 708 Author's Address 710 Ruediger Geib (editor) 711 Deutsche Telekom 712 Heinrich Hertz Str. 3-7 713 Darmstadt, 64295 714 Germany 716 Phone: +49 6151 5812747 717 Email: Ruediger.Geib@telekom.de