idnits 2.17.00 (12 Aug 2021) /tmp/idnits51194/draft-levis-meta-qos-class-00.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 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 607. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 30, 2005) is 6162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 6 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 Expires: January 1, 2006 France Telecom 5 June 30, 2005 7 The Meta-QoS-Class concept 8 draft-levis-meta-qos-class-00.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 January 1, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a framework for inter-domain Quality of 42 Service (QoS). It makes use of a new concept denoted by Meta-QoS- 43 Class. This new concept guides and simplifies QoS agreements between 44 providers and opens up new perspectives for a global QoS-enabled 45 Internet. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Binding l-QCs as a fundamental inter-domain QoS process . . 5 57 5. Provider to provider agreements analysis . . . . . . . . . . 5 58 5.1 About traps and glaciation . . . . . . . . . . . . . . . . 5 59 5.2 Recommendations for provider agreements . . . . . . . . . 6 60 5.3 Edge to edge guarantees . . . . . . . . . . . . . . . . . 7 61 5.4 The need for MQC . . . . . . . . . . . . . . . . . . . . . 7 63 6. The Meta QoS Class concept . . . . . . . . . . . . . . . . . 8 64 6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2 Template . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.3 Binding process . . . . . . . . . . . . . . . . . . . . . 8 67 6.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.5 Common understanding . . . . . . . . . . . . . . . . . . . 10 70 7. New perspectives for a gobal QoS-enabled Internet . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 11.1 Normative References . . . . . . . . . . . . . . . . . . 12 80 11.2 Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 84 Intellectual Property and Copyright Statements . . . . . . . 14 86 1. Introduction 88 Inter-domain Quality of Service (QoS) is seen as one of the future 89 challenges for the Internet community [RFC3869]. At a first stage, 90 most of the effort has been put into intra-domain specific problems. 91 A number of issues still appear to need further elaboration 92 [RFC2990], before it is conceivable to have an operational deployment 93 of QoS services including inter-domain aspects. 95 As pointed in [WIP], concepts should always be created in relation to 96 specific problems. This memo focuses on inter-domain QoS and 97 proposes some mechanisms to ease extending intra-domain QoS 98 capabilities. It introduces a new concept denoted by Meta-QoS-Class 99 (MQC). This concept is based on a very simple assumption: for two 100 adjacent domains, each specifically engineered to convey traffic for 101 a given application, the quality of the transportation across the two 102 networks as a whole is likely to be satisfactory for the application, 103 even if the two networks are managed by two different entities. 104 Basically this is how the Plain Old Telephone Service (POTS) works. 105 Finally, this memo explains how MQC could be used to promote a global 106 QoS-enabled Internet. Note that this document doesn't specify any 107 protocols or systems. 109 2. Terminology 111 Service Provider 113 An entity that provides Internet connectivity. Sometimes simply 114 referred to as provider or SP. This document assumes that a 115 provider owns and administers an IP network called a domain. 117 Domain 119 A network infrastructure composed of one or several Autonomous 120 Systems. 122 Local-QoS-Class (l-QC) 124 A QoS transfer capability across a single domain, characterized by 125 a set of QoS performance parameters denoted by (D, J, L). From a 126 Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per 127 Domain Behavior (PDB) [RFC3086]. It is then signalized by one or 128 several Differentiated Services Code Point (DSCP)[RFC2474]. 130 (D, J, L) 132 D: one-way transit delay [RFC2679], J: one-way transit delay 133 variation or jitter [RFC3393], and L: packet loss rate [RFC2680]. 135 Inter-domain QoS 137 Refers to the level of network QoS guarantees for communications 138 that span several domains. 140 Service scope 142 Network boundaries demarcating the guarantees of a service. 144 3. Assumptions 146 This memo considers the Internet subset composed of all domains with 147 Diffserv-like capabilities. These capabilities can differ from one 148 provider to another by the number of deployed l-QCs, by their 149 respective QoS characteristics, and also by the way they have been 150 implemented and engineered. This memo does not put any specific 151 requirements on the intra-domain traffic engineering policies and the 152 way they are enforced. 154 When crossing a domain, a traffic requesting a particular QoS 155 treatment experiences conditions constrained by the values of the (D, 156 J, L) tuple corresponding to the l-QC applied by the provider. 158 A provider negotiates QoS agreements only with its BGP peers 159 [RFC1771]. Potentially, all SPs that are directly accessible without 160 the need to cross a third party domain (immediate neighbors). This 161 is referenced as the cascaded model, see (Figure 1). The opposite 162 approach is the centralized model, see (Figure 2), where agreements 163 can be reached directly with any remote providers. 165 /-Agreement-\/-Agreement-\/-Agreement-\ 166 | || || | 167 +--v-+ +-vv-+ +-vv-+ +-v--+ 168 |SP +-------+SP +-------+SP |-------+SP | 169 |4 | |3 | |2 | |1 | 170 +--- + +----+ +----+ +----+ 172 Figure 1: Cascaded model 174 There is a great deal of complexity and scalability issues related to 175 the centralized approach, which represents a radical shift from 176 current Internet business model. Therefore, the only realistic way 177 forward seems to be the cascaded approach. This is the approach 178 adopted in the remainder of this document. 180 /---------------------------Agreement-\ 181 /--------------Agreement-\ | 182 /-Agreement-\ | | 183 | | | | 184 +--v-+ +-v--+ +-v--+ +-v--+ 185 |SP +-------+SP +-------+SP |-------+SP | 186 |4 | |3 | |2 | |1 | 187 +--- + +----+ +----+ +----+ 189 Figure 2: Centralized model 191 4. Binding l-QCs as a fundamental inter-domain QoS process 193 Inter-domain QoS can be approached from many points of view. For 194 providers it is a matter of extending their service scopes, beyond 195 the boundaries of their own domains. They want to benefit from the 196 Internet QoS infrastructure formed by all QoS-enabled domains. On a 197 low level (with regard to protocol layering) extending the service 198 scopes means extending the l-QCs. Packets leaving a domain that 199 applied a given l-QC (signaled by a given DSCP if Diffserv is used), 200 should experience similar treatment when crossing external domains up 201 to their final destination. 203 By definition, two l-QCs from two neighboring domains are bound 204 together once the two providers have agreed to transfer traffic from 205 one l-QC to the other. Binding l-QC appears as a fundamental 206 process, it should ensure the consistency of inter-domain QoS 207 treatments. 209 A provider needs to find the best match between its deployed l-QCs 210 and the neighbor's l-QCs. One potential difficulty is that providers 211 are, in general, very reluctant to communicate on how their networks 212 are engineered. They consider this kind of information as private 213 and confidential. L-Qc binding should operate with minimal exchange 214 of information. 216 5. Provider to provider agreements analysis 218 5.1 About traps and glaciation 220 In order to identify relevant criteria to bind adjacent l-QCs, this 221 section analyzes provider to provider agreements based on chains of 222 domains. 224 Provider SPn offers IP connectivity services to its customers that 225 are part of its BGP neighbors. An IP connectivity service is a set 226 of (Destination, D, J, L) where Destination is a group of IP 227 addresses reachable via SPn, and (D, J, L) is the QoS performance to 228 get from SPn to Destination. SPn guarantees the level of QoS for the 229 crossing of the whole chain of providers (SPn, SPn-1, SPn-2, ..., 230 SP1) from its own domain to the domain where Destination is located, 231 see (Figure 3). That means SPn implicitly guarantees the level of 232 QoS for the crossing of distant domains like SPn-2. In the same way, 233 SPn-2 is likely to be part of numerous SP chains and to see its level 234 of QoS guaranteed by many providers it has maybe even never heard of. 236 /-Agreement-\ 237 SP SP Destination 238 Customer Provider / 239 +----+ +----+ +----+ +----+ +----+ 240 |SP +-------+SP +----+SP +----+SP +- ... -+SP | 241 |n+1 | |n | |n-1 | |n-2 | |1 | 242 +----+ +----+ +----+ +----+ +----+ 243 -----> packet flow 245 <----------- Guarantee Scope -----------> 247 Figure 3: Provider to provider agreement 249 Any modification in a given agreement is likely to have an impact on 250 numerous external agreements that make use of it. A provider sees 251 the degree of freedom to renegotiate, or terminate, one of its own 252 agreements, being restricted by the number of external (to its 253 domain) agreements that depend on it. This is referenced as the SP 254 chain trap issue. Within the scope of global Internet services, each 255 provider would find itself being part of a large number of SP chains. 256 This solution is not appropriate for a worldwide QoS coverage as it 257 would lead to glaciation phenomena, ending up with a completely 258 petrified QoS infrastructure, where nobody could renegotiate any 259 agreement. 261 If a QoS-enabled Internet is deemed desirable, with QoS services 262 available potentially to and from any destination, as we are used to 263 with the current Internet, any solution must resolve this problem and 264 find alternate schemes for provider to provider agreements. 266 5.2 Recommendations for provider agreements 268 These recommendations are based on two assumptions. First, to avoid 269 forming SP chain traps, provider to provider agreements should not 270 cover several domains. Second, since it is very hard to know about 271 agreements more than one domain hop, and that these agreements can 272 change, it is almost impossible to have an accurate visibility of 273 their evolution. 275 Therefore, a provider should take the decision to bind one of its 276 l-QCs to one of its neighbor l-QCs based exclusively on: 278 - What it knows about its own l-QCs; 280 - What it knows about its neighbor l-QCs. 282 Agreements are then based on guarantees covering a single domain. 283 For any n, SPn should guarantee SPn+1 only the crossing performance 284 of SPn. 286 5.3 Edge to edge guarantees 288 It is very important to note that the proposition to limit guarantees 289 to only one domain hop applies exclusively to provider to provider 290 agreements. It does not in any way preclude edge to edge guarantees 291 for a user communication. 293 <-------------Edge to Edge-------------> 294 +----+ +----+ +----+ +----+ 295 |SP +----+SP +----+SP |----+SP | 296 (User A)--|4 | |3 | |2 | |1 |--(User B) 297 +----+ +----+ +----+ +----+ 298 <--PtoP--><--PtoP--><--PtoP--><--PtoP--> 300 <-- -->: guarantee scope 302 Figure 4: User communication guarantees 304 Any QoS inter-domain solution, either based on MQC or on a completely 305 different approach, is valid as long as each provider claiming to 306 offer some QoS performance actually delivers the expected level of 307 guarantee. In Figure 4, edge to edge guarantee between users A et B 308 is ensured by concatenation of local provider to provider (PtoP) 309 agreements. 311 5.4 The need for MQC 313 For its binding process, a provider will not use any information 314 related to what is happening more than one domain away. It will try 315 to find the best match between its l-QCs and its neighbor l-QCs. 316 That is to say, it will bind its l-QC with the neighbor l-QC that has 317 the closest performance. However, at the scale of a communication, 318 if there is systematically a slight difference between each upstream 319 and downstream l-QC, there can be a significant difference between 320 the first and the last l-QC. There must be a means to ensure the 321 consistency and the coherency of a QoS treatment when traversing a 322 given path. 324 A solution is to have a classification tool that defines two l-QCs as 325 being able to be bound together if, and only if, they are classified 326 in the same category. Each category is called a Meta-QoS-Class 327 (MQC). Two l-QCs can be bound together if, and only if, they belong 328 to the same MQC. 330 6. The Meta QoS Class concept 332 6.1 Definition 334 An MQC can be loosely defined as a label associated with a set of 335 applications that bear similar network QoS requirements. It can be 336 put on any l-QC suited to convey packets from this type of 337 applications. It is a means to certify that this l-QC is suitable 338 for the traffic of this application. 340 6.2 Template 342 The following attributes should be documented in any specification of 343 an MQC. 345 o A list of services (e.g. VoIP) the MQC is particularly suited 346 for. 348 o Boundaries for each QoS performance attribute (D, J, L), whenever 349 required. Several levels can be specified depending on the size 350 of the network provider (regional, national, etc.). 352 o Constraints on traffic (e.g. only TCP-friendly). 354 o Constraints on the ratio: network resources for the class to 355 overall traffic using this class (e.g. less resource than peak 356 traffic). 358 6.3 Binding process 360 A provider goes through several steps to extend its internal l-QCs. 361 First, it classifies its own l-QCs based on MQCs. Second, it learns 362 about available MQCs advertised by its neighbors. To advertise an 363 MQC, a provider must have at least one compliant l-QC and should be 364 ready to reach agreements to let neighbor traffic benefits from it. 365 Third, it contracts an agreement with its neighbor to send some 366 traffic that will be handled accordingly to the agreed MQCs. The 367 latter stage is the binding process. 369 Note that when a provider contracts an agreement with a neighbor, it 370 may well not know to what downstream l-QCs its own l-QCs are going to 371 be bound. It only knows that when it sends a packet requesting a 372 given MQC treatment (for example, owing to an agreed DSCP marking) 373 the packet will be handled in the downstream domain by an l-QC 374 compliant with the treatment associated with this MQC. 376 6.4 Properties 378 An MQC typically bears properties relevant to the crossing of one and 379 only one domain. However this notion can be extended, in a 380 straightforward manner, to the crossing of several domains, as long 381 as the set of consecutive domains is considered as a single virtual 382 domain. 384 MQC should not be confused with PDB concept defined in Diffserv 385 architecture. The two notions share the common characteristic of 386 specifying some QoS performance values. But the two concepts differ 387 in their purposes. The objective for the definition of a PDB is to 388 help implementation of l-QCs within a single administrative network. 389 The objective for an MQC is to help agreement negotiation between 390 providers, and therefore the process of binding two adjacent l-QCs. 392 The MQC concept is very flexible with regard to new unanticipated 393 applications. According to the end-to-end principle [E2E], a new 394 unanticipated application should have little impact on existing 395 l-QCs, because the l-QCs should have been designed and engineered, to 396 the extent possible, to gracefully allow any new application to 397 benefit from the existing QoS infrastructure. However, this issue 398 does not concern the MQCs as such, because an MQC is an abstract 399 concept that has no physical existence. It is only the problem of 400 l-QCs design and engineering. Therefore, a new unanticipated 401 application could simply drive a new MQC and a new classification 402 process for the l-QCs. 404 A hierarchy of MQCs can be defined for a given type of service (e.g. 405 VoIP with different qualities: VoIP for residential and VoIP for 406 enterprise). A given l-QC can be suitable for several MQCs (even 407 outside the same hierarchy). Several l-QCs in a given domain can be 408 classified as belonging to the same MQC. 410 MQC is a concept. MQC does not prohibit the use of any particular 411 mechanism or protocol at the data, control, or management plane. For 412 example, Diffserv, Intserv, traffic shaping, traffic engineering, 413 admission control, and so forth, are completely legitimate. MQC 414 simply drives and federates the way QoS inter-domain relationships 415 are built. 417 6.5 Common understanding 419 The need for standardization is strong as far as inter-domain QoS is 420 concerned [RFC2990]. Each provider must have the same understanding 421 of what a given MQC is about. A global agreement on a set of MQC 422 standards is needed. The number of classes to be defined must remain 423 very small to avoid an overwhelming complexity. There must be also a 424 means to certify that the l-QC classification made by a provider 425 conforms to the MQC standards. So the standardization effort should 426 go along with some investigations on conformance testing 427 requirements. 429 7. New perspectives for a gobal QoS-enabled Internet 431 The MQC concept opens up new perspectives for a QoS enabled Internet 432 that keeps, as much as possible, the openness characteristics of the 433 existing best-effort Internet. This is certainly not the only domain 434 of application to explore, but it is sufficiently important to 435 deserve some special considerations. 437 The resulting QoS Internet can be viewed as a set of parallel 438 Internets or MQC planes. Each plane consists of all the l-QCs bound 439 accordingly to the same MQC. When an l-QC maps to several MQCs, it 440 potentially belongs to several planes. Users can select the MQC 441 plane that is the closest to their needs, as long as there is a path 442 available for the destination. 444 The best effort service can be considered as relevant to the so- 445 called best-effort MQC. It is of primary importance to maintain a 446 best-effort route available when no QoS route is known. Best-effort 447 delivery must survive QoS and must remain the main Internet transport 448 service. 450 When a provider contracts with another provider based on the use of 451 MQCs, it simply adds a logical link to the corresponding MQC plane, 452 basically like what current traditional inter-domain agreement means 453 for the existing Internet. As soon as a new domain joins an MQC 454 plane, it can reach all domains and networks within this plane. 456 Figure 5 a) depicts the physical layout of a fraction of the 457 Internet, comprising four domains with full-mesh connectivity. 459 +----+ +----+ +----+ +----+ 460 |SP +----+SP | |SP +----+SP | 461 |1 | |2 | |1 | |2 | 462 +-+--+ +--+-+ +-+--+ +----+ 463 | \ / | | / 464 | \/ | | / 465 | /\ | | / 466 | / \ | | / 467 +-+--+ +--+-+ +-+--+ +----+ 468 |SP +----+SP | |SP | |SP | 469 |4 | |3 | |4 | |3 | 470 +----+ +----+ +----+ +----+ 471 a) physical configuration b) an MQC plane 473 Figure 5: MQC planes 475 Figure 5 b) depicts how these four domains are involved in a given 476 MQC plane. SP1, SP2 and SP4 have at least one compliant l-QC (SP3 477 maybe has or not) for this MQC. A bi-directional agreement exists 478 between SP1 and SP2, SP1 and SP4, SP2 and SP4. 480 Route path selection within a selected MQC plane can be envisaged as 481 the traditional routing system used by the Internet routers: do your 482 best to find one path, which is as good as possible. Thus, we can 483 rely on a BGP-like protocol, for instance the proposal detailed in 484 [q-BGP], for the inter-domain routing process. The resilience 485 feature of the IP routing system is preserved: if a QoS path breaks 486 somewhere, the routing protocol will make it possible to dynamically 487 compute another QoS path if available, in the proper MQC plane. 489 8. IANA Considerations 491 There are no IANA considerations. 493 Note to RFC Editor: this section may be removed on publication as an 494 RFC. 496 9. Security Considerations 498 This document describes a framework and not protocols or systems. 499 Potential risks and attacks will directly depend on the 500 implementation technology. Solutions to implement this proposal must 501 detail security issues in the relevant protocol documentation. 503 Particular attention should be paid on giving access to MQC resources 504 only to authorized traffic. Unauthorized access can lead to denial 505 of service when the network resources get overused. 507 10. Acknowledgements 509 Part of this work is funded by the European Commission, within the 510 context of the MESCAL (Management of End-to-End Quality of Service 511 Across the Internet At Large) project (http://www.mescal.org). The 512 authors would like to thank all the other partners for the fruitful 513 discussions. 515 11. References 517 11.1 Normative References 519 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 520 (BGP-4)", RFC 1771, March 1995. 522 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 523 Delay Metric for IPPM", RFC 2679, September 1999. 525 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 526 Packet Loss Metric for IPPM", RFC 2680, September 1999. 528 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 529 Metric for IP Performance Metrics (IPPM)", RFC 3393, 530 November 2002. 532 11.2 Informative References 534 [E2E] Saltzer, J H., Reed, D P., and D D. Clark, "End-To-End 535 Arguments in System Design", ACM Transactions in Computer 536 Systems, Vol 2, Number 4, pp 277-288, November 1984. 538 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 539 "Definition of the Differentiated Services Field (DS 540 Field) in the IPv4 and IPv6 Headers", RFC 2474, 541 December 1998. 543 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 544 and W. Weiss, "An Architecture for Differentiated 545 Services", RFC 2475, December 1998. 547 [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", 548 RFC 2990, November 2000. 550 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 551 Differentiated Services Per Domain Behaviors and Rules for 552 their Specification", RFC 3086, April 2001. 554 [RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, 555 "IAB Concerns and Recommendations Regarding Internet 556 Research and Evolution", RFC 3869, August 2004. 558 [WIP] Deleuze, G. and F. Guattari, "What Is Philosophy?", 559 Columbia University Press ISBN: 0231079893, April 1996. 561 [q-BGP] Boucadair, M., "QoS-Enhanced Border Gateway Protocol", 562 draft-boucadair-qos-bgp-spec-00.txt, Work in Progress, 563 June 2005. 565 Authors' Addresses 567 Pierre Levis 568 France Telecom 569 42 rue des Coutures 570 BP 6243 571 Caen Cedex 4 14066 572 France 574 Email: pierre.levis@francetelecom.com 576 Mohamed Boucadair 577 France Telecom 578 42 rue des Coutures 579 BP 6243 580 Caen Cedex 4 14066 581 France 583 Email: mohamed.boucadair@francetelecom.com 585 Intellectual Property Statement 587 The IETF takes no position regarding the validity or scope of any 588 Intellectual Property Rights or other rights that might be claimed to 589 pertain to the implementation or use of the technology described in 590 this document or the extent to which any license under such rights 591 might or might not be available; nor does it represent that it has 592 made any independent effort to identify any such rights. Information 593 on the procedures with respect to rights in RFC documents can be 594 found in BCP 78 and BCP 79. 596 Copies of IPR disclosures made to the IETF Secretariat and any 597 assurances of licenses to be made available, or the result of an 598 attempt made to obtain a general license or permission for the use of 599 such proprietary rights by implementers or users of this 600 specification can be obtained from the IETF on-line IPR repository at 601 http://www.ietf.org/ipr. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights that may cover technology that may be required to implement 606 this standard. Please address the information to the IETF at 607 ietf-ipr@ietf.org. 609 Disclaimer of Validity 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 614 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 615 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 616 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Copyright Statement 621 Copyright (C) The Internet Society (2005). This document is subject 622 to the rights, licenses and restrictions contained in BCP 78, and 623 except as set forth therein, the authors retain all their rights. 625 Acknowledgment 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.