idnits 2.17.1 draft-levis-provider-qos-agreement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 866. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2007) is 5986 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MESCAL' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Levis 3 Internet-Draft M. Boucadair 4 Intended status: Informational France Telecom 5 Expires: June 7, 2008 December 5, 2007 7 Considerations of provider-to-provider agreements for Internet-scale QoS 8 draft-levis-provider-qos-agreement-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo analyzes provider-to-provider QoS agreements suitable for a 42 global QoS-enabled Internet. It defines terminology relevant to 43 inter-domain QoS models. It proposes a new concept denoted by Meta- 44 QoS-Class (MQC). This concept could potentially drive and federate 45 the way QoS inter-domain relationships are built between providers. 46 It opens up new perspectives for a QoS-enabled Internet that retains, 47 as much as possible, the openness of the existing best-effort 48 Internet. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Assumptions and requirements . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Weaknesses of provider-to-provider QoS agreements based on 59 SP chains . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. IP connectivity services . . . . . . . . . . . . . . . . . 6 61 4.2. Similarity between provider and customer agreements . . . 7 62 4.3. Liability for service disruption . . . . . . . . . . . . . 7 63 4.4. SP chain trap leading to glaciation . . . . . . . . . . . 7 65 5. Provider-to-provider agreements based on Meta-QoS-Class . . . 8 66 5.1. Single domain covering . . . . . . . . . . . . . . . . . . 8 67 5.2. Binding l-QCs . . . . . . . . . . . . . . . . . . . . . . 9 68 5.3. MQC-based Binding process . . . . . . . . . . . . . . . . 10 70 6. The Internet as MQC planes . . . . . . . . . . . . . . . . . . 12 72 7. Towards end-to-end QoS services . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 Intellectual Property and Copyright Statements . . . . . . . . . . 19 87 1. Introduction 89 Three different areas can be distinguished in IP QoS service 90 offerings. The first area is the single domain where a provider 91 delivers QoS services inside the boundaries of its own network. The 92 second area is multi domains where a small set of providers, with 93 mutual business interests, cooperate to deliver QoS services inside 94 the boundaries of their network aggregate. The third area, which has 95 very seldom been put forward, is the Internet where QoS services can 96 be delivered from almost any source to any destination. Both multi 97 domains and Internet areas deal with inter-domain aspects. However 98 they differ significantly in many ways, such as the number of domains 99 and QoS paths involved, which are much higher and dynamic for the 100 Internet area. Multi domains and Internet areas are therefore likely 101 to differ in their respective solutions. This memo is an attempt to 102 investigate the Internet area from the point of view of provider-to- 103 provider agreements. It provides a framework for inter-domain QoS- 104 enabled Internet. 106 [MESCAL]provides a set of requirements to be met by any solution 107 aiming to solve inter-domain QoS issues. These requirements are not 108 reproduced within this memo. Readers are invited to refer to this 109 document for more elaborated description on the requirements. 111 This memo shows that for the sake of scalability, providers need not 112 be concerned what occurs more than one hop away (from their 113 Autonomous System) when they negotiate inter-domain QoS agreements. 114 They should base their agreements on nothing but their local QoS 115 capabilities and those of their direct neighbours. This analysis 116 leads us to define terminology relevant to inter-domain QoS models. 117 We also introduce a new concept denoted by Meta-QoS-Class(MQC) that 118 drives and federates the way QoS inter-domain relationships are built 119 between providers. The rationale for the MQC concept relies on a 120 universal and common understanding of QoS-sensitive application 121 needs. Wherever end-users are connected, they experience the same 122 QoS difficulties and are likely to express very similar QoS 123 requirements to their respective providers. Globally confronted with 124 the same customer requirements, providers are likely to design and 125 operate similar network capabilities. 127 MQC brings a simplified view of the Internet QoS capabilities as a 128 set of MQC planes. This memo looks at whether the idea of MQC planes 129 can be helpful in certain well-known concrete inter-domain QoS 130 issues. The focus, however, is on the provider-to-provider QoS 131 agreement framework, and the intention is not to specify individual 132 solutions and protocols for a full inter-domain QoS system. For 133 discussion of a complete architecture based on the notion of parallel 134 Internets that extends and generalizes the notion of MQC planes see 136 [AGAVE]. 138 Note that this document does not specify any protocols or systems. 140 2. Assumptions and requirements 142 To avoid a great deal of complexity and scalability issues we assume 143 that provider-to-provider QoS agreements are negotiated only for two 144 adjacent domains that are directly accessible to each other 145 (immediate neighbors). We also assume, because they exchange 146 traffic, that these neighbors are BGP [RFC4271] peers. This pairwise 147 peering is logical, therefore it can be supported not only on 148 physical point-to-point connections but also on Internet exchange 149 points (IXPs), where many operators connect to each other using a 150 layer 2 switch. 152 The QoS solutions envisaged in this document are exclusively 153 solutions suitable for the global Internet. As far as Internet-wide 154 solutions are concerned, this document assumes that: 156 o Any solutions should apply locally in order to be usable as soon 157 as deployed in a small set of domains. 159 o Any solutions should be scalable in order to allow a global 160 deployment to almost all Internet domains, with the ability to 161 establish QoS communications between any two end-users. 163 o Any solutions should also maintain a best-effort service that 164 should remain the pre-eminent service as a consequence of the end- 165 to-end argument [E2E]. 167 o If there is no path available within the requested QoS to reach a 168 destination, this destination must remain reachable through the 169 best-effort service. 171 This memo does not place any specific requirements on the intra- 172 domain traffic engineering policies and the way they are enforced. A 173 provider may deploy any technique to ensure QoS inside its own 174 network. This memo assumes only that QoS capabilities inside a 175 provider's network can be represented as local-QoS-Classes (l-QCs). 176 When crossing a domain, traffic experiences conditions characterized 177 by the values of delay, jitter, and packet loss rate that correspond 178 to the l-QC selected for that traffic within that domain. 179 Capabilities can differ from one provider to another by the number of 180 deployed l-QCs, by their respective QoS characteristics, and also by 181 the way they have been implemented and engineered. 183 3. Terminology 185 (D, J, L) 187 D: one-way transit delay [RFC2679], J: one-way transit delay 188 variation or jitter [RFC3393], and L: packet loss rate [RFC2680]. 190 Domain 192 A network infrastructure composed of one or several Autonomous 193 Systems (AS) managed by a single administrative entity. 195 IP connectivity service 197 IP transfer capability characterized by a (Destination, D, J, L) 198 tuple where Destination is a group of IP addresses and (D, J, L) 199 is the QoS performance to get to Destination. 201 Local-QoS-Class (l-QC) 203 A QoS transfer capability across a single domain, characterized by 204 a set of QoS performance parameters denoted by (D, J, L). From a 205 Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per 206 Domain Behavior (PDB) [RFC3086]. 208 L-QC binding 210 Two l-QCs from two neighboring domains are bound together once the 211 two providers have agreed to transfer traffic from one l-QC to the 212 other. 214 L-QC thread 216 Chain of neighboring bound l-QCs. 218 Meta-QoS-Class (MQC) 220 An MQC provides the limits of the QoS parameter values that two 221 l-QCs must respect in order to be bound together. An MQC is used 222 as a label that certifies the support of a set of applications 223 that bear similar network QoS requirements. 225 Service Provider (SP) 227 An entity that provides Internet connectivity. This document 228 assumes that an SP owns and administers an IP network called a 229 domain. Sometimes simply referred to as provider. 231 SP chain 233 The chain of Service Providers whose domains are used to convey 234 packets for a given IP connectivity service. 236 4. Weaknesses of provider-to-provider QoS agreements based on SP chains 238 The objective of this section is to show, by a sort of reductio ad 239 absurdum proof, that within the scope of Internet services, provider- 240 to-provider QoS agreements should be based on guarantees that span a 241 single domain. 243 We therefore analyze provider-to-provider QoS agreements based on 244 guarantees that span several domains and emphasis their 245 vulnerabilities. In this case, the basic service element that a 246 provider offers to its neighboring providers is called an IP 247 connectivity service. It uses the notion of SP chains. We first 248 define what an IP connectivity service is, and then we point out 249 several weaknesses of such an approach, especially the SP chain trap 250 problem that leads to the so-called Internet glaciation era. 252 4.1. IP connectivity services 254 An IP connectivity service is a (Destination, D, J, L) tuple where 255 Destination is a group of IP addresses reachable from the domain of 256 the provider offering the service, and (D, J, L) is the QoS 257 performance to get from this domain to Destination. Destination is 258 typically located in a remote domain. 260 Provider- /--------------SP chain---------------\ 261 oriented 262 view /--Agreement--\ 263 +----+ +----+ +----+ +----+ +----+ 264 |SP +-------+SP +----+SP +----+SP +- ... -+SP | 265 |n+1 | |n | |n-1 | |n-2 | |1 | 266 +----+ +----+ +----+ +----+ +----+ 267 Domain- -----> packet flow / 268 oriented Destination 269 view <----------- Guarantee Scope ---------> 271 Figure 1: IP connectivity service 273 In Figure 1 Provider SPn guarantees provider SPn+1 the level of QoS 274 for crossing the whole chain of providers' domains (SPn, SPn-1, 275 SPn-2, ...,SP1). SPi denotes a provider as well as its domain. The 276 top of the figure is the provider-oriented view, the ordered set of 277 providers (SPn, SPn-1, SPn-2, ...,SP1) is called an SP chain. The 278 bottom of the figure is the domain-oriented view. 280 4.2. Similarity between provider and customer agreements 282 This approach maps end-users' needs directly to provider-to-provider 283 agreements. Providers negotiate agreements to a destination because 284 they know customers are ready to pay for QoS guaranteed transfer to 285 this destination. As far as service scope is concerned, the 286 agreements between providers will resemble the agreements between 287 customers and providers. For instance, in Figure 1, SPn can sell to 288 its own customers the same IP connectivity service it sells to SPn+1. 289 There is no clear distinction between provider-to-provider agreements 290 and customer-to-provider agreements. 292 In order to guarantee a stable service, redundant SP chains should be 293 formed to reach the same destination. When one SP chain becomes 294 unavailable, an alternative SP chain should be selected. In the 295 context of a global QoS Internet that would lead to an enormous 296 number of SP chains along with the associated agreements. 298 4.3. Liability for service disruption 300 In Figure 1, if SPn+1 sees a disruption in the IP connectivity 301 service, it can turn only against SPn, its legal partner in the 302 agreement. If SPn is not responsible, in the same way, it can only 303 complain to SPn-1, and so on, until the faulty provider is found and 304 eventually requested to pay for the service impairment. The claim is 305 then supposed to move back along the chain until SPn pays SPn+1. The 306 SP chain becomes a liability chain. 308 Unfortunately this process is prone to failure in many cases. In the 309 context of QoS solutions suited for the Internet, SP chains are 310 likely to be dynamic and involve a significant number of providers. 311 Providers (that do not all know each other) involved in a same SP 312 chain can be competitors in many fields; therefore, trust 313 relationships are very difficult to build. Many complex and critical 314 issues need to be resolved: How will SPn+1 prove to SPn that QoS 315 level is not the level expected for a scope that can expand well 316 beyond SPn? How long will it take to find the guilty domain? Is SPn 317 ready to pay SPn+1 for something it does not control and is not 318 responsible for? 320 4.4. SP chain trap leading to glaciation 322 In Figure 1, SPn implicitly guarantees SPn+1 the level of QoS for the 323 crossing of distant domains like SPn-2. As we saw in Section 4.2, SP 324 chains will proliferate. A provider is, in this context, likely to 325 be part of numerous SP chains. It will see the level of QoS it 326 provides guaranteed by many providers it has maybe even never heard 327 of. 329 Any change in a given agreement is likely to have an impact on 330 numerous external agreements that make use of it. A provider sees 331 the degree of freedom to renegotiate, or terminate, one of its own 332 agreements being restricted by the large number of external (to its 333 domain) agreements that depend on it. This is what is referred to as 334 the "SP chain trap" issue. This solution is not appropriate for 335 worldwide QoS coverage as it would lead to glaciation phenomena, 336 causing a completely petrified QoS infrastructure, where nobody could 337 renegotiate any agreement. 339 5. Provider-to-provider agreements based on Meta-QoS-Class 341 If a QoS-enabled Internet is deemed desirable, with QoS services 342 available potentially to and from any destination, any solution must 343 resolve the above weaknesses and scalability problems, and find 344 alternate schemes for provider-to-provider agreements. 346 5.1. Single domain covering 348 Due to the vulnerabilities of the SP chain approach we assume 349 provider-to-provider QoS agreements should be based on guarantees 350 covering a single domain. A provider guarantees its neighbors only 351 the crossing performance of its own domain. In Figure 2, the 352 provider SPn guarantees the provider SPn+1 only the QoS performance 353 of the SPn domain. The remainder of this document will show that 354 this approach, bringing clarity and simplicity into inter-domain 355 relationships, is better suited for a global QoS Internet than that 356 based on SP chains. 358 Provider- 359 oriented 360 view /--Agreement--\ 361 +----+ +----+ 362 |SP +-------+SP + 363 |n+1 | |n | 364 +----+ +----+ 365 Domain- -----> packet flow 366 oriented <----> 367 view Guarantee Scope 369 Figure 2: provider-to-provider QoS agreement 371 It is very important to note that the proposition to limit guarantees 372 to only one domain hop applies exclusively to provider-to-provider 373 agreements. It does not in any way preclude end-to-end guarantees 374 for communications. 376 The simple fact that SP chains do not exist makes the AS chain trap 377 problem and the associated glaciation threat vanish. 379 The liability issue is restricted to a one hop distance. A provider 380 is responsible for its own domain only, and is controlled only by all 381 the neighbors with whom it has a direct contract. 383 5.2. Binding l-QCs 385 When a provider wants to contract with another provider, the main 386 concern is to decide which l-QC(s) in its own domain it will bind to 387 which l-QC(s) in the neighboring downstream domain. The l-QC Binding 388 process becomes the basic inter-domain process. 390 Upstream Downstream 391 domain domain 393 l-QC21 -----> l-QC11 395 l-QC22 -----> l-QC12 397 l-QC23 -----> 398 l-QC13 399 l-QC24 -----> 401 Figure 3: l-QC Binding 403 If one l-QC were to be bound to two (or more) l-QCs it would be very 404 difficult to know which l-QC the packets should select. This could 405 imply a flow classification at the border of the domains based on 406 granularity as fine as the application flows. For the sake of 407 scalability we assume one l-QC should not be bound to several l-QCs 408 [Lev]. On the contrary, several l-QCs can be bound to the same l-QC, 409 in the way that l-QC23 and l-QC24 are bound to l-QC13 in Figure 3. 411 A provider decides the best match between l-QCs based exclusively on: 413 - What it knows about its own l-QCs; 415 - What it knows about its neighboring l-QCs. 417 It does not use any information related to what is happening more 418 than one domain away. 420 Despite this one hop, short-sighted approach, the consistency and the 421 coherency of the QoS treatment must be ensured on an l-QC thread 422 formed by neighboring bound l-QCs. Packets leaving a domain that 423 applies a given l-QC, should experience similar treatment when 424 crossing external domains up to their final destination. A provider 425 should bind its l-QC with the neighboring l-QC that has the closest 426 performance. The criteria for l-QC binding should be stable along 427 any l-QC thread. For example, two providers should not bind two 428 l-QCs for minimizing the delay whereas further on, on the same 429 thread, two other providers have bound two l-QCs for minimizing 430 errors. Constraints should be put on l-QC QoS performance parameters 431 to confine their values to an acceptable and expected level on an 432 l-QC thread scale. These constraints should depend on domain size, 433 for example restrictions on delay should authorize a bigger value for 434 a national domain than for a regional one. Some rules must therefore 435 be defined to establish in which conditions two l-QCs can be bound 436 together. These rules are provided by the notion of Meta-QoS-Class 437 (MQC). 439 5.3. MQC-based Binding process 441 An MQC provides the limits of the QoS parameters two l-QCs must 442 respect in order to be bound together. A provider goes through 443 several steps to extend its internal l-QCs through the binding 444 process. Firstly, it classifies its own l-QCs based on MQCs. An MQC 445 is used as a label that certifies the support of a set of 446 applications that bear similar network QoS requirements. It is a 447 means to make sure that an l-QC has the appropriate QoS 448 characteristics to convey the traffic of this set of applications. 449 Secondly, it learns about available MQCs advertised by its neighbors. 450 To advertise an MQC, a provider must have at least one compliant l-QC 451 and should be ready to reach agreements to let neighbor traffic 452 benefit from it. Thirdly, it contracts an agreement with its 453 neighbor to send some traffic that will be handled according to the 454 agreed MQCs. 456 The following attributes should be documented in any specification of 457 an MQC. This is not a closed list, other points can be added if 458 needed. 460 o A set of applications (e.g. VoIP) the MQC is particularly suited 461 for. 463 o Boundaries or intervals of a set of QoS performance attributes 464 whenever required. For illustration purposes, we propose to use 465 in this document attribute (D, J, L) 3-uple. An MQC could be 466 focused on a single parameter (e.g. suitable to convey low delay 467 sensible traffic). Several levels could also be specified 468 depending on the size of the network provider, for instance a 469 small domain (e.g. regional) needs lower delay than a large domain 470 (e.g. national) to match a given MQC. 472 o Constraints on traffic (e.g. only TCP-friendly). 474 o Constraints on the ratio: network resources for the class / 475 overall traffic using this class (e.g. less resources than peak 476 traffic). 478 Two l-QCs can be bound together if, and only if, they conform to the 479 same MQC. 481 Provider-to-provider agreements, as defined here, are uni- 482 directional. They are established for transporting traffic in a 483 given direction. However, from a business perspective, it is likely 484 that reverse agreements will also be negotiated for transporting 485 traffic in the opposite direction. Note that uni-directional 486 provider-to-provider agreements do not preclude having end-to-end 487 services with bi-directional guarantees, when you consider the two 488 directions of the traffic separately. 490 Two providers negotiating an agreement based on MQC will have to 491 agree on several other parameters that are outside the definition of 492 MQC. One such obvious parameter is bandwidth. The two providers 493 agree to exchange up to a given level of QoS traffic. This bandwidth 494 level can then be further re-negotiated, inside the same MQC 495 agreement, to reflect an increase in the end-user QoS requests. 496 Other clauses of inter-domain agreements could cover availability of 497 the service, time of repair, etc. 499 A hierarchy of MQCs can be defined for a given type of service (e.g. 500 VoIP with different qualities: VoIP for residential and VoIP for 501 business). A given l-QC can be suitable for several MQCs (even 502 outside the same hierarchy). Several l-QCs in the same domain can be 503 classified as belonging to the same MQC. There is an MQC with no 504 specific constraints called the best-effort MQC. 506 There is a need for some form of standardization to control QoS 507 agreements between providers [RFC3387]. Each provider must have the 508 same understanding of what a given MQC is about. We need a global 509 agreement on a set of MQC standards. The number of classes to be 510 defined must remain very small to avoid overwhelming complexity. We 511 also need a means to certify that the l-QC classification made by a 512 provider conforms to the MQC standards. So the standardization 513 effort should be accompanied by investigations on conformance testing 514 requirements. 516 The three notions of PDB, Service Class [RFC4594], and MQC are 517 related; what MQC brings is the inter-domain aspect: 519 - PDB is how to engineer a network; 521 - Service Class is a set of traffic with specific QoS requests; 523 - MQC is a way to classify the QoS capabilities (l-QCs, through 524 Diffserv or any other protocols or mechanisms) in order to reach 525 agreements with neighbors. MQCs are only involved when a provider 526 wants to negotiate an agreement with a neighboring provider. MQC is 527 completely indifferent to the way networks are engineered as long as 528 the MQC QoS attributes (e.g. (D, J, L)) values are reached. 530 6. The Internet as MQC planes 532 The resulting QoS Internet can be viewed as a set of parallel 533 Internets or MQC planes. Each plane consists of all the l-QCs bound 534 according to the same MQC. An MQC plane can have holes and isolated 535 domains because QoS capabilities do not cover all Internet domains. 536 When an l-QC maps to several MQCs, it belongs potentially to several 537 planes. 539 When a provider contracts with another provider based on the use of 540 MQCs, it simply adds a logical link to the corresponding MQC plane. 541 This is basically what current traditional inter-domain agreements 542 mean for the existing Internet. Figure 4a) depicts the physical 543 layout of a fraction of the Internet, comprising four domains with 544 full-mesh connectivity. 546 +----+ +----+ +----+ +----+ 547 |SP +----+SP | |SP +----+SP | 548 |1 | |2 | |1 | |2 | 549 +-+--+ +--+-+ +-+--+ +----+ 550 | \ / | | / 551 | \/ | | / 552 | /\ | | / 553 | / \ | | / 554 +-+--+ +--+-+ +-+--+ +----+ 555 |SP +----+SP | |SP | |SP | 556 |4 | |3 | |4 | |3 | 557 +----+ +----+ +----+ +----+ 558 a) physical configuration b) an MQC plane 560 Figure 4: MQC planes 562 Figure 4 b) depicts how these four domains are involved in a given 563 MQC plane. SP1, SP2 and SP4 have at least one compliant l-QC (SP3 564 maybe has or not) for this MQC. A bi-directional agreement exists 565 between SP1 and SP2, SP1 and SP4, SP2 and SP4. 567 MQC brings a clear distinction between provider-to-provider and 568 customer-to-provider QoS agreements. We expect a great deal of 569 difference in dynamicity between the two. Most provider-to-provider 570 agreements should have been negotiated, and should remain stable, 571 before end-users can dynamically request end-to-end guarantees. 572 Provider agreements do not directly map end users' needs, therefore 573 the number of provider agreements is largely independent of the 574 number of end-user requests and does not increase as dramatically as 575 with SP chains. 577 For a global QoS-based Internet, this solution will work only if MQC- 578 based binding is largely accepted and becomes a current practice. 579 This limitation is due to the nature of the service itself, and not 580 to the use of MQCs. Insofar as we target global services we are 581 bound to provide QoS in as many SP domains as possible. However, any 582 MQC-enabled part of the Internet that forms a connected graph can be 583 used for QoS communications, and be extended. Therefore, incremental 584 deployment is possible, and leads to incremental benefits. For 585 example, in Figure 4 right-hand plane, as soon as SP3 connects to the 586 MQC plane it will be able to benefit from the SP1, SP2 and SP4 QoS 587 capabilities. 589 The Internet as a split of different MQC planes offers an ordered and 590 simplified view of the Internet QoS capabilities. End-users can 591 select the MQC plane that is the closest to their needs, as long as 592 there is a path available for the destination. One of the main 593 outcomes of applying the MQC concept is that it alleviates the 594 complexity and the management burden of inter-domain relationships. 596 7. Towards end-to-end QoS services 598 Building end-to-end QoS paths, for the purpose of QoS-guaranteed 599 communications between end-users, is going a step further in the QoS 600 process. The full description of customer-to-provider QoS 601 agreements, and the way they are enforced, is outside the scope of 602 this memo. However, in this section, we will list some important 603 issues and state whether MQC can help to find solutions. 605 Route path selection within a selected MQC plane can be envisaged in 606 the same way as the traditional routing system used by Internet 607 routers. Thus, we can rely on the BGP protocol, basically one BGP 608 occurrence per MQC plane, for the inter-domain routing process. The 609 resilience of the IP routing system is preserved. If a QoS path 610 breaks somewhere, the routing protocol enables dynamic computation of 611 another QoS path, if available, in the proper MQC plane. This 612 provides a first level of QoS infrastructure that could be 613 conveniently named "best-effort QoS", even if this is an oxymoron. 615 On this basis, features can be added in order to select and control 616 the QoS paths better. For example, BGP can be used to convey QoS- 617 related information, and to implement a process where Autonomous 618 Systems add their own QoS values (D, J, L) when they propagate an AS 619 path. Then, the AS path information is coupled with the information 620 on Delay, Jitter and Loss, and the decision whether or not to use the 621 path selected by BGP can be taken, based on numerical values. For 622 example, for destination N, an AS path (X, Y) is advertised to AS Z. 623 During the propagation of this AS path by BGP, X adds the information 624 concerning its own delay, say 30ms, and Y adds the information 625 concerning its own delay, say 20ms. Z receives the BGP advertisement 626 (X, Y, N, 50ms). One of Z's customers requests a delay of 100ms to 627 reach N. Z knows its own delay for this customer, say 20ms. Z 628 computes the expected maximum delay from its customer to N: 70ms, and 629 concludes that it can use the AS path (X, Y). The QoS value of an AS 630 path could also be disconnected from BGP and computed via an off-line 631 process. 633 If we use QoS routing, we can incorporate the (D, J, L) information 634 in the BGP decision process, but that raises the issue of composing 635 performance metrics in order to select appropriate paths [Chau]. 636 When confronted by multiple incompatible objectives, the local 637 decisions taken to optimize the targeted parameters could give rise 638 to a set of incomparable paths, where no path is strictly superior to 639 the others. The existence of provider-to-provider agreements based 640 on MQC offers a homogenous view of the QoS parameters, and should 641 therefore bring coherency, and restrict the risk of such non optimal 642 choices. 644 A lot of end-to-end services are bi-directional, so one must measure 645 the composite performance in both directions. Many inter-domain 646 paths are asymmetric, and usually, some providers involved in the 647 forward path are not in the reverse path, and vice versa. That means 648 that no assumptions can be made about the reverse path. Although 649 MQC-based provider-to-provider agreements are likely to be negotiated 650 bi-directionally, they allow the inter-domain routing protocol to 651 compute the forward and the reverse paths separately, as usual. The 652 only constraint MQC puts on routing is that the selected paths must 653 use the chosen MQCs throughout the selected domains. There might be 654 a different MQC requirement in the reverse direction than in the 655 forward direction. To address this problem, we can use application 656 level communication between the two parties (customers) involved in 657 order to specify the QoS requirements in both directions. 659 We can go a step further in the control of the path to ensure the 660 stability of QoS parameters such as, for example, enforcing an 661 explicit routing scheme, making use of RSVP-TE/MPLS-TE requests 662 [RFC3209], before injecting the traffic into an l-QC thread. 663 However, currently, several problems must be resolved before ready 664 and operational solutions for inter-domain route pinning, inter- 665 domain TE, fast failover, and so forth, are available. See for 666 example the BGP slow convergence problem in [Kushman]. 668 Multicast supports many applications such as audio and video 669 distribution (e.g. IPTV, streaming applications) with QoS 670 requirements. Along with solutions at the IP or Application level, 671 such as Forward Error Correction (FEC), the inter-domain multicast 672 routing protocol with Multiprotocol Extensions for BGP-4 [RFC4760], 673 could be used to advertise MQC capabilities for multicast source 674 reachability. If an inter-domain tree that spans several domains 675 remains in the same MQC plane, it would be possible to benefit from 676 the consistency and the coherency conferred by MQC. 678 Note that the use of some QoS parameters to drive the route selection 679 process within an MQC plane may induce QoS deterioration since the 680 best QoS-inferred path will be selected by all ASBR involved in the 681 inter-domain path computation (i.e. no other available routes in the 682 same MQC plane will have a chance to be selected). This problem was 683 called the QoS Attribute-rush (QA-rush) in [Grif]. This drawback may 684 be avoided if all involved ASes in the QoS chain implement some out- 685 band means to control the inter-domain QoS path consistency (MQC 686 compliance). 688 To conclude this section, whatever the protocols we want to use, and 689 however tightly we want to control QoS paths, MQC is a concept that 690 can help to resolve problems [WIP], without prohibiting the use of 691 any particular mechanism or protocol at the data, control, or 692 management planes. 694 8. IANA Considerations 696 There are no IANA considerations. 698 Note to RFC Editor: this section may be removed on publication as an 699 RFC. 701 9. Security Considerations 703 This document describes a framework and not protocols or systems. 704 Potential risks and attacks will depend directly on the 705 implementation technology. Solutions to implement this proposal must 706 detail security issues in the relevant protocol documentation. 708 Particular attention should be paid to giving access to MQC resources 709 only to authorized traffic. Unauthorized access can lead to denial 710 of service when the network resources get overused [RFC3869]. 712 10. Acknowledgements 714 This work is funded by the European Commission, within the context of 715 the MESCAL (Management of End-to-End Quality of Service Across the 716 Internet At Large) and AGAVE (A liGhtweight Approach for Viable End- 717 to-end IP-based QoS Services) projects. The authors would like to 718 thank all the other partners for the fruitful discussions. 720 We are grateful to Brian Carpenter, Jon Crowcroft and Juergen Quittek 721 for their helpful comments and suggestions for improving this 722 document. 724 11. References 726 11.1. Normative References 728 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 729 Delay Metric for IPPM", RFC 2679, September 1999. 731 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 732 Packet Loss Metric for IPPM", RFC 2680, September 1999. 734 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 735 Metric for IP Performance Metrics (IPPM)", RFC 3393, 736 November 2002. 738 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 739 Protocol 4 (BGP-4)", RFC 4271, January 2006. 741 11.2. Informative References 743 [AGAVE] Boucadair, et al., "Parallel Internets Framework", IST 744 AGAVE project public deliverable D1.1, September 2006. 746 [Chau] Chau, C., "Policy-based routing with non-strict 747 preferences", Proceedings of the ACM SIGCOMM 2006 748 Conference on Applications, Technologies, Architectures, 749 and Protocols for Computer Communications, Pisa, Italy, pp 750 387-398, September 2006. 752 [E2E] Saltzer, J H., Reed, D P., and D D. Clark, "End-To-End 753 Arguments in System Design", ACM Transactions in Computer 754 Systems, Vol 2, Number 4, pp 277-288, November 1984. 756 [Grif] Griffin, D., Spencer, J., Griem, J., Boucadair, M., 757 Morand, P., Howarth, M., Wang, N., Pavlou, G., Asgari, A., 758 and P. Georgatsos, "Interdomain routing through QoS-class 759 planes [Quality-of-Service-Based Routing Algorithms for 760 Heterogeneous Networks]", IEEE Communications 761 Magazine, Vol 45, Issue 2, pp 88-95, February 2007. 763 [Kushman] Kushman, N., Kandula, S., and D. Katabi, "Can You Hear Me 764 Now?! It Must Be BGP", ACM Journal of Computer and 765 Communication Review CCR, November 2007. 767 [Lev] Levis, P., Asgari, H., and P. Trimintzios, "Consideration 768 on Inter-domain QoS and Traffic Engineering issues Through 769 a Utopian Approach", SAPIR-2004 workshop of ICT-2004, (C) 770 Springer-Verlag, August 2004. 772 [MESCAL] Flegkas, et al., "Specification of Business Models and a 773 Functional Architecture for Inter-domain QoS Delivery", 774 IST MESCAL project public deliverable D1.1, May 2003. 776 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 777 and W. Weiss, "An Architecture for Differentiated 778 Services", RFC 2475, December 1998. 780 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 781 Differentiated Services Per Domain Behaviors and Rules for 782 their Specification", RFC 3086, April 2001. 784 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 785 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 786 Tunnels", RFC 3209, December 2001. 788 [RFC3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from 789 the Service Management Research Group (SMRG) on Quality of 790 Service (QoS) in the IP Network", RFC 3387, 791 September 2002. 793 [RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, 794 "IAB Concerns and Recommendations Regarding Internet 795 Research and Evolution", RFC 3869, August 2004. 797 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 798 Guidelines for DiffServ Service Classes", RFC 4594, 799 August 2006. 801 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 802 "Multiprotocol Extensions for BGP-4", RFC 4760, 803 January 2007. 805 [WIP] Deleuze, G. and F. Guattari, "What Is Philosophy?", 806 Columbia University Press ISBN: 0231079893, April 1996. 808 Authors' Addresses 810 Pierre Levis 811 France Telecom 812 42 rue des Coutures 813 BP 6243 814 Caen Cedex 4 14066 815 France 817 Email: pierre.levis@orange-ftgroup.com 819 Mohamed Boucadair 820 France Telecom 821 42 rue des Coutures 822 BP 6243 823 Caen Cedex 4 14066 824 France 826 Email: mohamed.boucadair@orange-ftgroup.com 828 Full Copyright Statement 830 Copyright (C) The IETF Trust (2007). 832 This document is subject to the rights, licenses and restrictions 833 contained in BCP 78, and except as set forth therein, the authors 834 retain all their rights. 836 This document and the information contained herein are provided on an 837 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 838 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 839 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 840 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 841 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 842 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 844 Intellectual Property 846 The IETF takes no position regarding the validity or scope of any 847 Intellectual Property Rights or other rights that might be claimed to 848 pertain to the implementation or use of the technology described in 849 this document or the extent to which any license under such rights 850 might or might not be available; nor does it represent that it has 851 made any independent effort to identify any such rights. Information 852 on the procedures with respect to rights in RFC documents can be 853 found in BCP 78 and BCP 79. 855 Copies of IPR disclosures made to the IETF Secretariat and any 856 assurances of licenses to be made available, or the result of an 857 attempt made to obtain a general license or permission for the use of 858 such proprietary rights by implementers or users of this 859 specification can be obtained from the IETF on-line IPR repository at 860 http://www.ietf.org/ipr. 862 The IETF invites any interested party to bring to its attention any 863 copyrights, patents or patent applications, or other proprietary 864 rights that may cover technology that may be required to implement 865 this standard. Please address the information to the IETF at 866 ietf-ipr@ietf.org. 868 Acknowledgment 870 Funding for the RFC Editor function is provided by the IETF 871 Administrative Support Activity (IASA).