idnits 2.17.1 draft-jacquenet-qos-nlri-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 483 has weird spacing: '... route with ...' -- 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 (July 2001) is 8321 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1771 (ref. '2') (Obsoleted by RFC 4271) == Outdated reference: A later version (-03) exists of draft-tequila-sls-00 ** Obsolete normative reference: RFC 2679 (ref. '5') (Obsoleted by RFC 7679) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-ipdv-07 == Outdated reference: A later version (-04) exists of draft-jacquenet-ip-te-cops-02 -- No information found for draft-ietf-diffserv-2839bis - is the name correct? ** Obsolete normative reference: RFC 1700 (ref. '12') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2842 (ref. '13') (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2434 (ref. '14') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2385 (ref. '15') (Obsoleted by RFC 5925) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Cristallo 3 Internet Draft Alcatel 4 Document: draft-jacquenet-qos-nlri-03.txt C. Jacquenet 5 Category: Experimental France Telecom R&D 6 Expires January 2002 July 2001 8 Providing Quality of Service Indication by the BGP-4 Protocol: the 9 QOS_NLRI attribute 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft specifies an additional BGP4 (Border Gateway Protocol, 34 version 4, [2]) attribute, named the "QOS_NLRI" attribute, which aims 35 at providing QoS (Quality of Service)-related information associated 36 to the NLRI (Network Layer Reachability Information) information 37 conveyed in a BGP UPDATE message. 39 1. Introduction 41 Providing end-to-end quality of service is probably one of the most 42 important challenges of the Internet, not only because of the massive 43 development of value-added IP service offerings, but also because of 44 the various QoS policies that are currently deployed and enforced 45 within an autonomous system, and which may well differ from one AS 46 (Autonomous System) to another. 48 For almost the last decade, value-added IP service offerings have 49 been deployed over the Internet, thus yielding a dramatic development 50 of the specification effort, as far as quality of service in IP 51 networks is concerned. Nevertheless, providing end-to-end quality of 52 service by crossing administrative domains still remains an issue, 53 mainly because: 55 - QoS policies may dramatically differ from one service provider to 56 another, 57 - The enforcement of a specific QoS policy may also differ from one 58 domain to another, although the definition of a set of basic and 59 common quality of service indicators may be shared between the 60 service providers. 62 Activate the BGP4 protocol for exchanging reachability information 63 between autonomous systems has been a must for many years, and, from 64 this standpoint, the BGP4 protocol is one of the key components for 65 the enforcement of end-to-end QoS policies. 67 Therefore, exchanging QoS-related information as well as reachability 68 information in a given BGP UPDATE message appears to be helpful in 69 enforcing an end-to-end QoS policy. 71 This draft aims at specifying a new BGP4 attribute, the QOS_NLRI 72 attribute, which will convey QoS-related information associated to 73 the routes described in the corresponding NLRI field of the 74 attribute. 76 This document is organized into the following sections: 78 - Section 3 identifies the changes that have been made in the 79 document since the last version, 81 - Section 4 describes the attribute and its mode of operation, 83 - Section 5 elaborates on the use of the capabilities advertisement 84 feature of the BGP4 protocol, 86 - Section 6 introduces the first results of an ongoing simulation 87 work, 89 - Finally, sections 7 and 8 introduce IANA and some security 90 considerations, respectively. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [3]. 98 3. Changes since the last version of this draft 100 The current version of this draft reflects the following changes: 102 - Slight re-wording of the Introduction section (section 1), 104 - Added a section on the first simulation results (section 6), 106 - Authors' list has been updated, 108 - Correction of remaining typos. 110 4. The QOS_NLRI attribute (Type Code XY*) 112 (*): "XY" is subject to the IANA considerations section of this 113 draft. 115 The QOS_NLRI attribute is an optional transitive attribute that can 116 be used for the following purposes: 118 (a) To advertise a QoS route to a peer. A QoS route is a route that 119 meets one or a set of QoS requirement(s) to reach a given (set 120 of) destination prefixes (see [4], for example). Such QoS 121 requirements can be expressed in terms of minimum one-way delay 122 ([5]) to reach a destination, the experienced delay variation 123 for IP datagrams that are destined to a given destination prefix 124 ([6]), the loss rate experienced along the path to reach a 125 destination, and/or the identification of the traffic that is 126 expected to use this specific route (identification means for 127 such traffic include DSCP (DiffServ Code Point, [7]) marking). 128 These QoS requirements can be used as an input for the route 129 calculation process embedded in the BGP peers, e.g. thanks to 130 the activation of a signaling protocol, such as RSVP (Resource 131 ReSerVation Protocol, [8]), 133 (b) To provide QoS information along with the NLRI information in a 134 single BGP UPDATE message. It is assumed that this QoS 135 information will be related to the route (or set of routes) 136 described in the NLRI field of the attribute. 138 From a service provider's perspective, the choice of defining the 139 QOS_NLRI attribute as an optional transitive attribute is basically 140 motivated by the fact that this kind of attribute allows for gradual 141 deployment of QoS extensions to BGP4: not all the BGP peers are 142 supposed to be updated accordingly, while partial deployment of such 143 QoS extensions can already provide an added value. 145 This draft makes no specific assumption about the means to actually 146 value this attribute, since this is mostly a matter of 147 implementation, but the reader is kindly suggested to have a look on 148 document [9], as an example of a means to feed the BGP peer with the 149 appropriate information. 151 The QOS_NLRI attribute is encoded as follows: 153 +---------------------------------------------------------+ 154 | QoS Information Code (1 octet) | 155 +---------------------------------------------------------+ 156 | QoS Information Sub-code (1 octet) | 157 +---------------------------------------------------------+ 158 | QoS Information Value (2 octets) | 159 +---------------------------------------------------------+ 160 | QoS Information Origin (1 octet) | 161 +---------------------------------------------------------+ 162 | Address Family Identifier (2 octets) | 163 +---------------------------------------------------------+ 164 | Subsequent Address Family Identifier (1 octet) | 165 +---------------------------------------------------------+ 166 | Network Address of Next Hop (4 octets) | 167 +---------------------------------------------------------+ 168 | Network Layer Reachability Information (variable) | 169 +---------------------------------------------------------+ 171 The use and meaning of the fields of the QOS_NLRI attribute are 172 defined as follows: 174 - QoS Information Code: 176 This field carries the type of the QOS information. The 177 following types have been identified so far: 179 (0) Reserved 180 (1) Packet rate, i.e. the number of IP datagrams that can be 181 transmitted (or have been lost) per unit of time, this number 182 being characterized by the elaboration provided in the QoS 183 Information Sub-code (see below) 184 (2) One-way delay, as defined in [5] 185 (3) Inter-packet delay variation, as defined in [6] 186 (4) PHB Identifier, as defined in [10] 188 - QoS Information Sub-code: 190 This field carries the sub-type of the QoS information. The 191 following sub-types have been identified so far: 193 (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub- 194 type) 195 (1) Reserved rate 196 (2) Available rate 197 (3) Loss rate 198 (4) Minimum one-way delay 199 (5) Maximum one-way delay 200 (6) Average one-way delay 201 The instantiation of this sub-code field MUST be compatible with the 202 value conveyed in the QoS Information code field, as stated in the 203 following table (the rows represent the QoS Information Code possible 204 values, the columns represent the QoS Information Sub-code values 205 identified so far, while the "X" sign indicates incompatibility). 207 +---------------------------------------+ 208 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 209 +---------------------------------------+ 210 | 0 | | | | | | | | 211 +---------------------------------------+ 212 | 1 | | | | | X | X | X | 213 +---------------------------------------+ 214 | 2 | | X | X | X | | | | 215 +---------------------------------------+ 216 | 3 | | X | X | X | X | X | X | 217 +---------------------------------------+ 218 | 4 | | X | X | X | X | X | X | 219 +---------------------------------------+ 221 - QoS Information Value: 223 This field indicates the value of the QoS information. The 224 corresponding units obviously depend on the instantiation of the 225 QoS Information Code. Namely, if: 227 (a) QoS Information Code field is "0", no unit specified, 228 (b) QoS Information Code field is "1", unit is kbits per second 229 (kbps), and the rate encoding rule is composed of a 3-bit 230 exponent (with an assumed base of 8) followed by a 13-bit 231 mantissa, as depicted in the figure below: 233 0 8 16 234 | | | 235 ----------------- 236 |Exp| Mantissa | 237 ----------------- 239 This encoding scheme advertises a numeric value that is (2^16 -1 240 - exponential encoding of the considered rate), as depicted in 241 [11]. 242 (c) QoS Information Code field is "2", unit is milliseconds, 243 (d) QoS Information Code field is "3", unit is milliseconds, 244 (e) QoS Information Code field is "4", no unit specified. 246 - QoS Information Origin: 248 This field provides indication on the origin of the path 249 information, as defined in section 4.3.of [2]. 251 - Address Family Identifier (AFI): 253 This field carries the identity of the Network Layer protocol 254 associated with the Network Address that follows. Presently 255 defined values for this field are specified in [12] (see the 256 Address Family Numbers section of this reference document). 258 - Subsequent Address Family Identifier (SAFI): 260 This field provides additional information about the type of the 261 NLRI carried in the QOS_NLRI attribute. 263 - Network Address of Next Hop: 265 This field contains the IPv4 Network Address of the next router 266 on the path to the destination prefix, (reasonably) assuming 267 that such routers can at least be addressed according to the 268 IPv4 formalism. 270 - Network Layer Reachability Information: 272 This variable length field lists the NLRI information for the 273 feasible routes that are being advertised by this attribute. The 274 next hop information carried in the QOS_NLRI path attribute 275 defines the Network Layer address of the border router that 276 should be used as the next hop to the destinations listed in the 277 QOS_NLRI attribute in the UPDATE message. 279 When advertising a QOS_NLRI attribute to an external peer, a router 280 may use one of its own interface addresses in the next hop component 281 of the attribute, given the external peer to which the route is being 282 advertised shares a common subnet with the next hop address. This is 283 known as a "first party" next hop information. 285 A BGP speaker can advertise to an external peer an interface of any 286 internal peer router in the next hop component, provided the external 287 peer to which the route is being advertised shares a common subnet 288 with the next hop address. This is known as a "third party" next hop 289 information. 291 A BGP speaker can advertise any external peer router in the next hop 292 component, provided that the Network Layer address of this border 293 router was learned from an external peer, and the external peer to 294 which the route is being advertised shares a common subnet with the 295 next hop address. This is a second form of "third party" next hop 296 information. 298 Normally the next hop information is chosen so that the shortest 299 available path will be taken. A BGP speaker must be able to support 300 disabling advertisement of third party next hop information to handle 301 imperfectly bridged media or for reasons of policy. 303 A BGP speaker must never advertise an address of a peer to that peer 304 as a next hop, for a route that the speaker is originating. A BGP 305 speaker must never install a route with itself as the next hop. 307 When a BGP speaker advertises the route to an internal peer, the 308 advertising speaker should not modify the next hop information 309 associated with the route. When a BGP speaker receives the route via 310 an internal link, it may forward packets to the next hop address if 311 the address contained in the attribute is on a common subnet with the 312 local and remote BGP speakers. 314 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 315 ORIGIN and the AS_PATH attributes (both in eBGP and in iBGP 316 exchanges). Moreover, in IBGP exchanges such a message MUST also 317 carry the LOCAL_PREF attribute. If such a message is received from an 318 external peer, the local system shall check whether the leftmost AS 319 in the AS_PATH attribute is equal to the autonomous system number of 320 the peer than sent the message. If that is not the case, the local 321 system shall send the NOTIFICATION message with Error Code UPDATE 322 Message Error, and the Error Sub-code set to Malformed AS_PATH. 324 An UPDATE message that carries no NLRI, other than the one encoded in 325 the QOS_NLRI attribute, should not carry the NEXT_HOP attribute. If 326 such a message contains the NEXT_HOP attribute, the BGP speaker that 327 receives the message should ignore this attribute. 329 5. Use of Capabilities Advertisement with BGP-4 331 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 332 Capabilities Advertisement procedures, as defined in [13], so that it 333 might be able to determine if it can use such an attribute with a 334 particular peer. 336 The fields in the Capabilities Optional Parameter are defined as 337 follows: 339 - The Capability Code field is set to N (127 < N < 256, when 340 considering the "Private Use" range, as specified in [14]), while 341 the Capability Length field is set to "1". 343 - The Capability Value field is a one-octet field, which contains 344 the Type Code of the QOS_NLRI attribute, as defined in the 345 introduction of section 4 of the present draft. 347 6. First simulation results 349 6.1. A step-by-step approach 351 The simulation work that has begun within the context of the TEQUILA 352 project (see [4]) basically aims at qualifying the scalability of the 353 usage of the QOS_NLRI attribute for propagating QoS-related 354 information between domains. This work also aims at quantifying the 355 added value provided by the QoS extensions to BGP4, as a function of 356 the percentage of the accordingly updated BGP peers. 358 This effort has also been launched to focus on the impact on the 359 stability of the BGP routes, by defining a set of basic engineering 360 rules for the introduction of new QoS information, as well as design 361 considerations for the calculation of "QoS routes". 363 This ongoing development effort is organized into a step-by-step 364 approach, which consists in the following phases: 366 1. Model an IP network composed of several autonomous systems. Each 367 of the autonomous systems is composed of BGP peers that have 368 established iBGP connections between each other. Since this 369 simulation effort is primarily focused on the qualification of 370 the scalability related to the use of the QOS_NLRI attribute for 371 exchanging QoS-related information between domains, it has been 372 decided that the internal architecture of such domains be kept 373 very simple, i.e. without any specific IGP interaction, 375 2. Within this IP network, there are BGP peers that are QOS_NLRI 376 aware, i.e. they have the ability to process the information 377 conveyed in the attribute, while the other routers are not: 378 these routers do not recognize the QOS_NLRI attribute by 379 definition, and they will forward the information to other 380 peers, by setting the Partial bit in the corresponding UPDATE 381 messages, meaning that the information conveyed in the message 382 is incomplete. This is the typical behavior that is expected 383 when a BGP peer has to deal with an optional transitive 384 attribute. This approach allows to elaborate on the added value 385 introduced by a gradual deployment of the QoS extensions to 386 BGP4, 388 3. As far as QOS_NLRI aware BGP peers are concerned, they will 389 process the information contained in the QOS_NLRI attribute to 390 possibly influence the route decision process, thus yielding the 391 selection (and the installation) of distinct routes towards a 392 same destination prefix, depending on the QoS-related 393 information conveyed in the QOS_NLRI attribute. From this 394 implementation perspective, the BGP routing tables have been 395 modeled so that they contain a "sub-section" where QOS_NLRI- 396 capable peers will store the information conveyed in the 397 attribute, 399 4. Modify the BGP route decision process: at this stage of the 400 simulation, the modified decision process relies upon the one- 401 way delay information (which corresponds to the QoS Information 402 Code field of the attribute valued at "2"), and it will also 403 take into account the value of the partial bit in the UPDATE 404 message, in the case where the QoS-related information contained 405 in the QOS_NLRI attribute happens to be incomplete, because it's 406 been relayed by a non-QOS_NLRI aware BGP peer. 408 Once the creation of these components of the IP network has been 409 completed (together with the modification of the BGP route selection 410 process), the behavior of a QOS_NLRI-capable BGP peer is as follows: 411 upon receipt of a BGP UPDATE message that contains the QOS_NLRI 412 attribute, the router will first check if the corresponding route is 413 already stored in its local RIB, according to the value of the one- 414 way delay information contained in both QoS Information Code and Sub- 415 code fields of the attribute. 417 If not, the BGP peer will install the route in its local RIB. 418 Otherwise (i.e. an equivalent route already exists in its database), 419 the BGP peer will select the best of both routes according to the 420 following criteria: 422 - If both routes are said to be incomplete (partial bit valued to 423 "1" in the UPDATE message), or if both routes are said to be 424 complete, the best route is the route with the lowest value of the 425 QoS Information Sub-code field of the QOS_NLRI attribute, 427 - Otherwise, a complete QoS-related information is always preferred 428 over an incomplete one, even if the complete route has a QoS 429 Information Sub-code field with a better value. 431 If the BGP route selection process cannot make a decision based upon 432 the QoS Information Code and Sub-code fields (and possibly the 433 complete/incomplete indication of the Partial bit), then the BGP 434 route selection process is basically based upon the recommendations 435 stated in [2]. 437 6.2. Current status of the simulation work 439 As stated in the previous section 6.1, the current status of the 440 simulation work basically relies upon the one-way transit delay 441 information only, as well as the complete/incomplete indication of 442 the partial bit conveyed in the corresponding BGP UPDATE messages. 444 The IP network has been modeled so that it is composed of 6 445 autonomous systems and 11 BGP peers. Future scenarios will be 446 composed of more ASs. The following figures depict the actual 447 processing of the QoS-related information conveyed in the QOS_NLRI 448 attribute, depending on whether the peer is QOS_NRLI-aware or not. 450 NOTE: the text version of this draft does not contain the above- 451 mentioned figures, but a PDF version of this document can be accessed 452 at the following link: http://www.ietf.org/ietf/1id-abstracts.txt. 454 [- Figure 1: the modeled IP network. -] 456 Figure 1 depicts the IP network that has been modeled, while figure 2 457 depicts the propagation of a BGP UPDATE message that contains the 458 QOS_NLRI attribute, in the case where the contents of the attribute 459 are changed, because of complete/incomplete conditions of the UPDATE 460 message propagation. 462 [- Figure 2: propagation of a one-way delay information via BGP4. -] 464 Router S in figure 2 is a QOS_NRLI-capable speaker. It takes 20 465 milliseconds to node S to reach network 192.0.20.0: this information 466 will be conveyed in a QOS_NLRI attribute that will be sent by node S 467 in a BGP UPDATE message with a partial bit unset. Router A is another 468 QOS_NLRI BGP peer, and it takes 3 milliseconds for A to reach router 469 S. Node A will update the QoS-related information of a QOS_NLRI 470 attribute, indicating that, to reach network 192.0.20.0, it takes 23 471 milliseconds. Router A will install this new route in its database, 472 and will propagate the corresponding UPDATE message to its peers. 474 On the other hand, router B is not capable of processing the 475 information conveyed in the QOS_NLRI attribute, and it will therefore 476 set the Partial bit in the corresponding UPDATE message, leaving the 477 one-way delay information detailed in both QoS Information Code and 478 Sub-code unchanged. 480 Upon receipt of the UPDATE message sent by router A, router E will 481 update the one-way delay information since it is a QOS_NRLI-capable 482 peer. Finally, router D receives the UPDATE message, and selects a 483 route with a 40 milliseconds one-way delay to reach network 484 192.0.20.0, as depicted in figure 3. 486 [- Figure 3: installing QoS routes between domains. -] 488 This simulation result shows that the selection of a delay-based 489 route over a BGP route (as depicted in [2]) may not yield an optimum 490 decision. In the above example, the 40 ms-route goes through routers 491 D-E-A-S, while a "truly optimal" BGP route would be through routers 492 D-E-F-A-S, hence a 38 ms-route. This is because of a BGP4 rule that 493 does not allow router F to send an UPDATE message towards router E, 494 because router F received the UPDATE message from router A thanks to 495 the iBGP connection it has established with A. 497 These basic observations confirm that the enforcement of a QoS policy 498 between domains by using the BGP4 protocol is obviously conditioned 499 by the BGP4 routing policies that are enforced within each domain. 501 6.3. Next steps 503 The above-mentioned simulation effort will be pursued in order to 504 qualify the interest of using the BGP4 protocol to convey QoS-related 505 information between domains, from a scalability perspective, i.e. the 506 increase of BGP traffic vs. the stability of the network. The 507 stability of the IP network is probably one of the most important 508 aspects, since QoS-related information is subject to very dynamic 509 changes, thus yielding non-negligible risks of flapping. 511 It is therefore expected that the upcoming versions of this draft 512 will reflect the progress of this simulation work, which will take 513 into account additional autonomous systems, among other tracks of 514 evolution. 516 7. IANA Considerations 518 Section 4 of this draft documents an optional transitive BGP-4 519 attribute named "QOS_NLRI" whose type value will be assigned by IANA. 520 Section 5 of this draft also documents a Capability Code whose value 521 should be assigned by IANA. 523 8. Security Considerations 525 This additional BGP-4 attribute specification does not change the 526 underlying security issues inherent in the existing BGP-4 protocol 527 specification [15]. 529 9. References 531 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 532 BCP 9, RFC 2026, October 1996. 534 [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 535 1771, March 1995. 537 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 538 Levels", BCP 14, RFC 2119, March 1997. 540 [4] Goderis, D., T'Joens, Y., Jacquenet, C., Memenios, G., Pavlou, 541 G., Egan, R., Griffin, D., Georgatsos, P., Georgiadis, L., 542 "Specification of a Service Level Specification (SLS) 543 Template", draft-tequila-sls-00.txt, Work in Progress, November 544 2000. Check http://www.ist-tequila.org for additional 545 information. 547 [5] Almes, G., Kalidindi, S., "A One-Way-Delay Metric for IPPM", 548 RFC 2679, September 1999. 550 [6] Demichelis, C., Chimento, P., "IP Packet Delay Variation Metric 551 for IPPM", draft-ietf-ippm-ipdv-07.txt, Work in Progress, 552 February 2001. 554 [7] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of 555 the Differentiated Services Field (DS Field) in the IPv4 and 556 IPv6 Headers", RFC 2474, December 1998. 558 [8] Braden, R., et al., "Resource ReSerVation Protocol (RSVP)- 559 Version 1 Functional Specification", RFC 2205, September 1997. 561 [9] Jacquenet, C., "A COPS client-type for IP traffic engineering", 562 draft-jacquenet-ip-te-cops-02.txt, Work in Progress, June 2001. 564 [10] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop 565 Behavior Identification Codes", draft-ietf-diffserv-2839bis- 566 02.txt, Work in Progress, May 2001. 568 [11] Apostolopoulos, G. et al, "QoS Routing Mechanisms and OSPF 569 Extensions", RFC 2676, August 1999. 571 [12] Reynolds, J., Postel, J., "ASSIGNED NUMBERS", RFC 1700, October 572 1994. 574 [13] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 575 4", RFC 2842, May 2000. 577 [14] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 578 Considerations Section in RFCs", RFC 2434, October 1998. 580 [15] Heffernan, A., "Protection of BGP sessions via the TCP MD5 581 Signature Option", RFC 2385, August 1998. 583 10. Acknowledgments 585 Part of this work is funded by the European Commission, within the 586 context of the TEQUILA (Traffic Engineering for Quality of Service in 587 the Internet At Large Scale, [4]) project, which is itself part of 588 the IST (Information Society Technologies) research program. 590 The author would also like to thank all the partners of the TEQUILA 591 project for the fruitful discussions that have been conducted within 592 the context of the traffic engineering specification effort of the 593 project, as well as O. Bonaventure and B. Carpenter for their 594 valuable input. 596 11. Authors' Addresses 598 Geoffrey Cristallo 599 Alcatel 600 Francis Wellesplein, 1 601 2018 Antwerp 602 Belgium 603 Phone: +32 (0)3 240 7890 604 E-Mail: geoffrey.cristallo@alcatel.be 606 Christian Jacquenet 607 France Telecom R & D 608 DMI/SIR 609 42, rue des Coutures 610 BP 6243 611 14066 Caen Cedex 4 612 France 613 Phone: +33 2 31 75 94 28 614 Email: christian.jacquenet@francetelecom.com 616 12. Full Copyright Statement 618 Copyright(C) The Internet Society (2001). All Rights Reserved. 620 This document and translations of it may be copied and furnished to 621 others, and derivative works that comment on or otherwise explain it 622 or assist its implementation may be prepared, copied, published and 623 distributed, in whole or in part, without restriction of any kind, 624 provided that the above copyright notice and this paragraph are 625 included on all such copies and derivative works. However, this 626 document itself may not be modified in any way, such as by removing 627 the copyright notice or references to the Internet Society or other 628 Internet organizations, except as needed for the purpose of 629 developing Internet standards in which case the procedures for 630 copyrights defined in the Internet Standards process must be 631 followed, or as required to translate it into languages other than 632 English. 634 The limited permissions granted above are perpetual and will not be 635 revoked by the Internet Society or its successors or assigns. 637 This document and the information contained herein is provided on an 638 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 639 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 640 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 641 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 642 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.