idnits 2.17.1 draft-jacquenet-qos-nlri-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. 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. ** There are 287 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 527 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 (June 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) == Outdated reference: A later version (-06) exists of draft-walton-bgp-add-paths-01 ** Obsolete normative reference: RFC 2679 (ref. '5') (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 3065 (ref. '8') (Obsoleted by RFC 5065) ** Obsolete normative reference: RFC 1700 (ref. '11') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 3392 (ref. '12') (Obsoleted by RFC 5492) ** Obsolete normative reference: RFC 2434 (ref. '13') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2385 (ref. '14') (Obsoleted by RFC 5925) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-05.txt C. Jacquenet 5 Category: Experimental France Telecom 6 Expires December 2003 June 2003 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 NOTE: a PDF version of this document (which includes the figures 32 mentioned in section 8) can be accessed at http://www.mescal.org. 34 Abstract 36 This draft specifies an additional BGP4 (Border Gateway Protocol, 37 version 4) attribute, named the "QOS_NLRI" attribute, which aims at 38 propagating QoS (Quality of Service)-related information associated 39 to the NLRI (Network Layer Reachability Information) information 40 conveyed in a BGP UPDATE message. 42 Table of Contents 44 1. Conventions Used in this Document..........................2 45 2. Introduction...............................................2 46 3. Changes since the Previous Version.........................3 47 4. Basic Requirements.........................................3 48 5. The QOS_NLRI Attribute (Type Code tbd*)....................4 49 6. Operation..................................................7 50 7. Use of Capabilities Advertisement with BGP-4...............8 51 8. Simulation Results.........................................9 52 8.1. A Phased Approach..........................................9 53 8.2. A Case Study..............................................10 54 8.3. Additional Results........................................11 55 8.4. Next Steps................................................12 56 9. IANA Considerations.......................................13 57 10. Security Considerations...................................13 58 11. References................................................13 59 12. Acknowledgments...........................................14 60 13. Authors' Addresses........................................14 61 14. Full Copyright Statement..................................14 63 1. Conventions Used in this Document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [2]. 69 2. Introduction 71 Providing end-to-end quality of service is one of the most important 72 challenges of the Internet, not only because of the massive 73 development of value-added IP service offerings, but also because of 74 the various QoS policies that are currently enforced within an 75 autonomous system, and which may well differ from one AS (Autonomous 76 System) to another. 78 For the last decade, value-added IP service offerings have been 79 deployed over the Internet, thus yielding a dramatic development of 80 the specification effort, as far as quality of service in IP networks 81 is concerned. Nevertheless, providing end-to-end quality of service 82 across administrative domains still remains an issue, mainly because: 84 - QoS policies may dramatically differ from one service provider to 85 another, 87 - The enforcement of a specific QoS policy may also differ from one 88 domain to another, although the definition of a set of common 89 quality of service indicators may be shared between the service 90 providers. 92 Activate the BGP4 protocol ([3]) for exchanging reachability 93 information between autonomous systems has been a must for many 94 years. Therefore, disseminating QoS information coupled with 95 reachability information in a given BGP UPDATE message appears to be 96 helpful in enforcing an end-to-end QoS policy. 98 This draft aims at specifying a new BGP4 attribute, the QOS_NLRI 99 attribute, which will convey QoS-related information associated to 100 the routes described in the corresponding NLRI field of the 101 attribute. 103 This document is organized according to the following sections: 105 - Section 3 identifies the changes that have been made in the 106 document since the previous version, 108 - Section 4 describes the basic requirements that motivate the 109 approach, 111 - Section 5 describes the attribute, 113 - Section 6 elaborates on the mode of operation, 115 - Section 7 elaborates on the use of the capabilities advertisement 116 feature of the BGP4 protocol, 118 - Section 8 depicts the results of an ongoing simulation work, 120 - Finally, sections 9 and 10 introduce IANA and some security 121 considerations, respectively. 123 3. Changes since the Previous Version 125 The current version of this draft reflects the following changes: 127 - The format of the attribute has been modified, to include the 128 multiple path advertisement capability, as described in [4], and 129 section 5 has been updated accordingly, 131 - Section 6 has been introduced to better depict the mode of 132 operation that now takes into account the multiple path 133 advertisement capability, as described in [4]. From this 134 perspective, this draft can be viewed as an application of this 135 extension, 137 - A table of contents has been added, 139 - The References section has been updated, 141 - Correction of remaining typos. 143 4. Basic Requirements 145 The choice of using the BGP4 protocol for exchanging QoS information 146 between domains is not only motivated by the fact BGP is currently 147 the only inter-domain (routing) protocol activated in the Internet, 148 but also because the manipulation of attributes is a powerful means 149 for service providers to disseminate QoS information with the desired 150 level of precision. 152 The approach presented in this draft has identified the following 153 requirements: 155 - Keep the approach scalable. The scalability of the approach can be 156 defined in many ways that include the convergence time taken by the 157 BGP peers to reach a consistent view of the network connectivity, 158 the number of route entries that will have to be maintained by a 159 BGP peer, the dynamics of the route announcement mechanism (e.g., 160 how frequently and under which conditions should an UPDATE message 161 containing QoS information be sent?), etc. 163 - Keep the BGP4 protocol operation unchanged. The introduction of a 164 new attribute should not affect the way the protocol operates, but 165 the information contained in this attribute may very well influence 166 the BGP route selection process. 168 - Allow for a smooth migration. The use of a specific BGP attribute 169 to convey QoS information should not constrain network operators to 170 migrate the whole installed base at once, but rather help them in 171 gradually deploying the QoS information processing capability. 173 5. The QOS_NLRI Attribute (Type Code tbd*) 175 (*): "tbd" is subject to the IANA considerations section of this 176 draft. 178 The QOS_NLRI attribute is an optional transitive attribute that can 179 be used for the following purposes: 181 1. To advertise a QoS route to a peer. A QoS route is a route that 182 meets one or a set of QoS requirement(s) to reach a given (set of) 183 destination prefixes. Such QoS requirements can be expressed in 184 terms of minimum one-way delay ([5]) to reach a destination, the 185 experienced delay variation for IP datagrams that are destined to 186 a given destination prefix ([6]), the loss rate experienced along 187 the path to reach a destination, and/or the identification of the 188 traffic that is expected to use this specific route 189 (identification means for such traffic include DSCP (DiffServ Code 190 Point, [7]) marking). These QoS requirements can be used as an 191 input for the BGP route calculation process, 193 2. To provide QoS-related information along with the NLRI information 194 in a single BGP UPDATE message. It is assumed that this 195 information will be related to the route (or set of routes) 196 described in the NLRI field of the attribute. 198 From a service provider's perspective, the choice of defining the 199 QOS_NLRI attribute as an optional transitive attribute is motivated 200 by the fact that this kind of attribute allows for gradual deployment 201 of the dissemination of QoS-related information by BGP4: not all the 202 BGP peers are supposed to be updated accordingly, while partial 203 deployment of such QoS extensions can already provide an added value, 204 e.g. in the case where a service provider manages multiple domains, 205 and/or has deployed a BGP confederation ([8]). 207 This draft makes no specific assumption about the means to actually 208 value this attribute, since this is mostly a matter of 209 implementation, but the reader is suggested to have a look on 210 document [9], as an example of a means to feed the BGP peer with the 211 appropriate information. The QOS_NLRI attribute is encoded as 212 follows: 214 +---------------------------------------------------------+ 215 | QoS Information Code (1 octet) | 216 +---------------------------------------------------------+ 217 | QoS Information Sub-code (1 octet) | 218 +---------------------------------------------------------+ 219 | QoS Information Value (2 octets) | 220 +---------------------------------------------------------+ 221 | QoS Information Origin (1 octet) | 222 +---------------------------------------------------------+ 223 | Address Family Identifier (2 octets) | 224 +---------------------------------------------------------+ 225 | Subsequent Address Family Identifier (1 octet) | 226 +---------------------------------------------------------+ 227 | Network Address of Next Hop (4 octets) | 228 +---------------------------------------------------------+ 229 | Flags (1 octet) | 230 +---------------------------------------------------------+ 231 | Identifier (2 octets) | 232 +---------------------------------------------------------+ 233 | Length (1 octet) | 234 +---------------------------------------------------------+ 235 | Prefix (variable) | 236 +---------------------------------------------------------+ 238 The use and meaning of the fields of the QOS_NLRI attribute are 239 defined as follows: 241 - QoS Information Code: 243 This field carries the type of the QOS information. The following 244 types have been identified so far: 246 (0) Reserved 247 (1) Packet rate, i.e. the number of IP datagrams that can be 248 transmitted (or have been lost) per unit of time, this number 249 being characterized by the elaboration provided in the QoS 250 Information Sub-code (see below) 251 (2) One-way delay metric 252 (3) Inter-packet delay variation 253 (4) PHB Identifier 254 - QoS Information Sub-Code: 256 This field carries the sub-type of the QoS information. The 257 following sub-types have been identified so far: 259 (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub- 260 type) 261 (1) Reserved rate 262 (2) Available rate 263 (3) Loss rate 264 (4) Minimum one-way delay 265 (5) Maximum one-way delay 266 (6) Average one-way delay 268 The instantiation of this sub-code field MUST be compatible with the 269 value conveyed in the QoS Information code field, as stated in the 270 following table (the rows represent the QoS Information Code possible 271 values, the columns represent the QoS Information Sub-code values 272 identified so far, while the "X" sign indicates incompatibility). 274 +---------------------------------------+ 275 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 276 +---------------------------------------+ 277 | 0 | | | | | | | | 278 +---------------------------------------+ 279 | 1 | | | | | X | X | X | 280 +---------------------------------------+ 281 | 2 | | X | X | X | | | | 282 +---------------------------------------+ 283 | 3 | | X | X | X | X | X | X | 284 +---------------------------------------+ 285 | 4 | | X | X | X | X | X | X | 286 +---------------------------------------+ 288 - QoS Information Value: 290 This field indicates the value of the QoS information. The 291 corresponding units obviously depend on the instantiation of the 292 QoS Information Code. Namely, if: 294 (a) QoS Information Code field is "0", no unit specified, 295 (b) QoS Information Code field is "1", unit is kilobits per second 296 (kbps), and the rate encoding rule is composed of a 3-bit 297 exponent (with an assumed base of 8) followed by a 13-bit 298 mantissa, as depicted in the figure below: 299 0 8 16 300 | | | 301 ----------------- 302 |Exp| Mantissa | 303 ----------------- 305 This encoding scheme advertises a numeric value that is (2^16 -1 306 - exponential encoding of the considered rate), as depicted in 307 [10]. 308 (c) QoS Information Code field is "2", unit is milliseconds, 309 (d) QoS Information Code field is "3", unit is milliseconds, 310 (e) QoS Information Code field is "4", no unit specified. 312 - QoS Information Origin: 314 This field provides indication on the origin of the path 315 information, as defined in section 4.3.of [3]. 317 - Address Family Identifier (AFI): 319 This field carries the identity of the Network Layer protocol 320 associated with the Network Address that follows. Currently 321 defined values for this field are specified in [11] (see the 322 Address Family Numbers section of this reference document). 324 - Subsequent Address Family Identifier (SAFI): 326 This field provides additional information about the type of the 327 prefix carried in the QOS_NLRI attribute. 329 - Network Address of Next Hop: 331 This field contains the IPv4 Network Address of the next router 332 on the path to the destination prefix, (reasonably) assuming that 333 such routers can at least be addressed according to the IPv4 334 formalism. 336 - Flags, Identifier, Length and Prefix fields: 338 These four fields actually compose the NLRI field of the QOS_NLRI 339 attribute, and their respective meanings are as defined in 340 section 2.2.2 of [4]. 342 6. Operation 344 When advertising a QOS_NLRI attribute to an external peer, a router 345 may use one of its own interface addresses in the next hop component 346 of the attribute, given the external peer to which one or several 347 route(s) is (are) being advertised shares a common subnet with the 348 next hop address. This is known as a "first party" next hop 349 information. 351 A BGP speaker can advertise to an external peer an interface of any 352 internal peer router in the next hop component, provided the external 353 peer to which the route is being advertised shares a common subnet 354 with the next hop address. This is known as a "third party" next hop 355 information. 357 A BGP speaker that sends an UPDATE message with the QOS_NLRI 358 attribute has the ability to advertise multiple QoS routes, since the 359 Identifier field of the attribute is part of the NLRI description. In 360 particular, the same prefix can be advertised more than once without 361 subsequent advertisements that would replace previous announcements. 363 Since the resolution of the NEXT_HOP address that is always conveyed 364 in a BGP UPDATE message is left to the responsibility of the IGP that 365 has been activated within the domain, the best path according to the 366 BGP route selection process depicted in [3] SHOULD also be 367 advertised. As long as the routers on the path towards the address 368 depicted in the NEXT_HOP attribute of the message have the additional 369 paths depicted in the QOS_NLRI attribute, the propagation of QoS 370 routes within a domain where all the routers are QOS_NLRI aware 371 should not yield inconsistent routing. 373 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 374 ORIGIN and the AS_PATH attributes (both in eBGP and in iBGP 375 exchanges). Moreover, in iBGP exchanges such a message MUST also 376 carry the LOCAL_PREF attribute. If such a message is received from an 377 external peer, the local system shall check whether the leftmost AS 378 in the AS_PATH attribute is equal to the autonomous system number of 379 the peer than sent the message. If that is not the case, the local 380 system shall send the NOTIFICATION message with Error Code UPDATE 381 Message Error, and the Error Sub-code set to Malformed AS_PATH. 383 Finally, an UPDATE message that carries no NLRI, other than the one 384 encoded in the QOS_NLRI attribute, should not carry the NEXT_HOP 385 attribute. If such a message contains the NEXT_HOP attribute, the BGP 386 speaker that receives the message should ignore this attribute. 388 7. Use of Capabilities Advertisement with BGP-4 390 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 391 Capabilities Advertisement procedures, as defined in [12], so that it 392 might be able to determine if it can use such an attribute with a 393 particular peer. 395 The fields in the Capabilities Optional Parameter are defined as 396 follows: 398 - The Capability Code field is set to N (127 < N < 256, when 399 considering the "Private Use" range, as specified in [13]), while 400 the Capability Length field is set to "1". 402 - The Capability Value field is a one-octet field, which contains 403 the Type Code of the QOS_NLRI attribute, as defined in the 404 introduction of section 5 of the present draft. 406 In addition, the multiple path advertisement capability MUST be 407 supported, as defined in section 2.1 of [4]. 409 8. Simulation Results 411 8.1. A Phased Approach 413 The simulation work basically aims at qualifying the scalability of 414 the usage of the QOS_NLRI attribute for propagating QoS-related 415 information across domains. 417 This effort also focused on the impact on the stability of the BGP 418 routes, by defining a set of basic engineering rules for the 419 introduction of additional QoS information, as well as design 420 considerations for the computation and the selection of "QoS routes". 422 This ongoing development effort is organized into a step-by-step 423 approach, which consists in the following phases: 425 1. Model an IP network composed of several autonomous systems. 426 Since this simulation effort is primarily focused on the 427 qualification of the scalability related to the use of the 428 QOS_NLRI attribute for exchanging QoS-related information 429 between domains, it has been decided that the internal 430 architecture of such domains should be kept very simple, i.e. 431 without any specific IGP interaction, 433 2. Within this IP network, there are BGP peers that are QOS_NLRI 434 aware, i.e. they have the ability to process the information 435 conveyed in the attribute, while the other routers are not: the 436 latter do not recognize the QOS_NLRI attribute by definition, 437 and they will forward the information to other peers, by setting 438 the Partial bit in the attribute, meaning that the information 439 conveyed in the message is incomplete. This approach contributes 440 to the qualification of a progressive deployment of QOS_NLRI- 441 aware BGP peers, 443 3. As far as QOS_NLRI aware BGP peers are concerned, they will 444 process the information contained in the QOS_NLRI attribute to 445 possibly influence the route decision process, thus yielding the 446 selection (and the announcement) of distinct routes towards a 447 same destination prefix, depending on the QoS-related 448 information conveyed in the QOS_NLRI attribute, 450 4. Modify the BGP route decision process: at this stage of the 451 simulation, the modified decision process relies upon the one- 452 way delay information (which corresponds to the QoS Information 453 Code field of the attribute valued at "2"), and it also takes 454 into account the value of the Partial bit of the attribute. 456 Once the creation of these components of the IP network has been 457 completed (together with the modification of the BGP route selection 458 process), the behavior of a QOS_NLRI-capable BGP peer is as follows. 460 Upon receipt of a BGP UPDATE message that contains the QOS_NLRI 461 attribute, the router will first check if the corresponding route is 462 already stored in its local RIB, according to the value of the one- 463 way delay information contained in both QoS Information Code and Sub- 464 code fields of the attribute. 466 If not, the BGP peer will install the route in its local RIB. 467 Otherwise (i.e. an equivalent route already exists in its database), 468 the BGP peer will select the best of both routes according to the 469 following criteria: 471 - If both routes are said to be either incomplete (Partial bit has 472 been set) or complete (Partial bit is unset), the route with the 473 lowest delay will be selected, 475 - Otherwise, a route with the Partial bit unset is always preferred 476 over any other route, even if this route reflects a higher transit 477 delay. 479 If ever both Partial bit and transit delay information are not 480 sufficient to make a decision, the standard BGP decision process 481 (according to the breaking ties mechanism depicted in [3]) is 482 performed. 484 8.2. A Case Study 486 As stated in the previous section 8.1, the current status of the 487 simulation work basically relies upon the one-way transit delay 488 information only, as well as the complete/incomplete indication of 489 the Partial bit conveyed in the QOS_NLRI attribute. 491 The following figures depict the actual processing of the QoS-related 492 information conveyed in the QOS_NLRI attribute, depending on whether 493 the peer is QOS_NRLI-aware or not. 495 [Fig. 1: A Case Study.] 497 Figure 1 depicts the IP network that has been modelled, while figure 498 2 depicts the propagation of a BGP UPDATE message that contains the 499 QOS_NLRI attribute, in the case where the contents of the attribute 500 are changed, because of complete/incomplete conditions depicted by 501 the Partial bit of the QOS_NLRI attribute. 503 [Fig. 2: Propagation of One-way Delay Information via BGP4.] 505 Router S in figure 2 is a QOS_NRLI-capable speaker. It takes 20 506 milliseconds for node S to reach network 192.0.20.0: this information 507 will be conveyed in a QOS_NLRI attribute that will be sent by node S 508 in a BGP UPDATE message with the Partial bit of the QOS_NLRI 509 attribute unset. 511 Router A is another QOS_NLRI BGP peer, and it takes 3 milliseconds 512 for A to reach router S. Node A will update the QoS-related 513 information of a QOS_NLRI attribute, indicating that, to reach 514 network 192.0.20.0, it takes 23 milliseconds. Router A will install 515 this new route in its database, and will propagate the corresponding 516 UPDATE message to its peers. 518 On the other hand, router B is not capable of processing the 519 information conveyed in the QOS_NLRI attribute, and it will therefore 520 set the Partial bit of the QOS_NLRI attribute in the corresponding 521 UPDATE message, leaving the one-way delay information detailed in 522 both QoS Information Code and Sub-code unchanged. 524 Upon receipt of the UPDATE message sent by router A, router E will 525 update the one-way delay information since it is a QOS_NRLI-capable 526 peer. Finally, router D receives the UPDATE message, and selects a 527 route with a 40 milliseconds one-way delay to reach network 528 192.0.20.0, as depicted in figure 3. 530 [Fig. 3: Selecting QoS Routes Across Domains.] 532 This simulation result shows that the selection of a delay-inferred 533 route over a BGP route may not yield an optimal decision. In the 534 above example, the 40 ms-route goes through routers D-E-A-S, while a 535 "truly optimal" BGP route would be through routers D-E-F-A-S, hence a 536 38 ms-route. This is because of a BGP4 rule that does not allow 537 router F to send an UPDATE message towards router E, because router F 538 received the UPDATE message from router A thanks to the iBGP 539 connection it has established with A. 541 8.3. Additional Results 543 The following table reflects the results obtained from a simulation 544 network composed of 9 autonomous systems and 20 BGP peers. The 545 numbers contained in the columns reflect the percentage of serviced 546 requirements, where the requirements are expressed in terms of delay. 548 Three parameters have been taken into account: 550 - The percentage of BGP peers that have the ability to process the 551 information conveyed in the QOS_NLRI attribute (denoted as "x% Q- 552 BGP" in the following table), 554 - The transit delays "observed" (and artificially simulated) on each 555 transmission link: the higher the delays, the lower the percentage 556 of serviced QoS requirements, 558 - The QoS requirements themselves, expressed in terms of delay: as 559 such, the strongest requirements (i.e. the lowest delays) have less 560 chance to be satisfied. 562 +-------------------------------------------+ 563 | Delay | 0% Q-BGP | 50% Q-BGP | 100% Q-BGP | 564 +-------------------------------------------+ 565 | 3 | 11 | 8,3 | 11 | 566 +-------------------------------------------+ 567 | 5 | 30,5 | 30,5 | 36,1 | 568 +-------------------------------------------+ 569 | 6 | 40 | 47,2 | 55,5 | 570 +-------------------------------------------+ 571 | 7 | 47 | 59,7 | 72,2 | 572 +-------------------------------------------+ 573 | 8 | 62,5 | 79 | 91,6 | 574 +-------------------------------------------+ 575 | 9 | 63 | 84,7 | 97,2 | 576 +-------------------------------------------+ 577 | 10 | 70,8 | 90,2 | 98,6 | 578 +-------------------------------------------+ 579 | 11 | 76,3 | 93 | 98,6 | 580 +-------------------------------------------+ 581 | 12 | 86,1 | 97,2 | 100 | 582 +-------------------------------------------+ 583 | 13 | 88,8 | 98,6 | 100 | 584 +-------------------------------------------+ 585 | 14 | 94,4 | 100 | 100 | 586 +-------------------------------------------+ 587 | 15 | 94,4 | 100 | 100 | 588 +-------------------------------------------+ 589 | 16 | 94,4 | 100 | 100 | 590 +-------------------------------------------+ 591 | 17 | 97,2 | 100 | 100 | 592 +-------------------------------------------+ 593 | 18 | 98,6 | 100 | 100 | 594 +-------------------------------------------+ 595 | 19 | 98,6 | 100 | 100 | 596 +-------------------------------------------+ 597 | 20 | 98,6 | 100 | 100 | 598 +-------------------------------------------+ 599 | 21 | 98,6 | 100 | 100 | 600 +-------------------------------------------+ 601 | 22 | 100 | 100 | 100 | 602 +-------------------------------------------+ 604 This table clearly demonstrates the technical feasibility of the 605 approach, and how the use of the QOS_NLRI attribute can improve the 606 percentage of serviced QoS requirements. 608 8.4. Next Steps 610 The above-mentioned simulation effort is currently pursued in order 611 to better qualify the interest of using the BGP4 protocol to convey 612 QoS-related information between domains, from a scalability 613 perspective, i.e. the growth of BGP traffic vs. the stability of the 614 network. 616 The stability of the IP network is probably one of the most important 617 aspects, since QoS-related information is subject to very dynamic 618 changes, thus yielding non-negligible risks of flapping. 620 9. IANA Considerations 622 Section 5 of this draft documents an optional transitive BGP-4 623 attribute named "QOS_NLRI" whose type value will be assigned by IANA. 624 Section 6 of this draft also documents a Capability Code whose value 625 should be assigned by IANA as well. 627 10. Security Considerations 629 This additional BGP-4 attribute specification does not change the 630 underlying security issues inherent in the existing BGP-4 protocol 631 specification [14]. 633 11. References 635 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 636 BCP 9, RFC 2026, October 1996. 637 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 638 Levels", BCP 14, RFC 2119, March 1997. 639 [3] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 640 1771, March 1995. 641 [4] Walton, D., et al., "Advertisement of Multiple Paths in BGP", 642 draft-walton-bgp-add-paths-01.txt, Work in Progress, November 643 2002. 644 [5] Almes, G., Kalidindi, S., "A One-Way-Delay Metric for IPPM", 645 RFC 2679, September 1999. 646 [6] Demichelis, C., Chimento, P., "IP Packet Delay Variation Metric 647 for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 648 [7] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of 649 the Differentiated Services Field (DS Field) in the IPv4 and 650 IPv6 Headers", RFC 2474, December 1998. 651 [8] Traina, P., McPherson, D., Scudder, J., " Autonomous System 652 Confederations for BGP", RFC 3065, February 2001. 653 [9] Jacquenet, C., "A COPS client-type for IP traffic engineering", 654 draft-jacquenet-ip-te-cops-04.txt, Work in Progress, January 655 2003. 656 [10] Apostolopoulos, G. et al, "QoS Routing Mechanisms and OSPF 657 Extensions", RFC 2676, August 1999. 658 [11] Reynolds, J., Postel, J., "ASSIGNED NUMBERS", RFC 1700, October 659 1994. 660 [12] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 661 4", RFC 3392, November 2002. 663 [13] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 664 Considerations Section in RFCs", RFC 2434, October 1998. 665 [14] Heffernan, A., "Protection of BGP sessions via the TCP MD5 666 Signature Option", RFC 2385, August 1998. 668 12. Acknowledgments 670 Part of this work is funded by the European Commission, within the 671 context of the MESCAL (Management of End-to-End Quality of Service 672 Across the Internet At Large, http://www.mescal.org) project, which 673 is itself part of the IST (Information Society Technologies) research 674 program. 676 The author would also like to thank all the partners of the MESCAL 677 project for the fruitful discussions that have been conducted within 678 the context of the traffic engineering specification effort of the 679 project, as well as O. Bonaventure and B. Carpenter for their 680 valuable input. 682 13. Authors' Addresses 684 Geoffrey Cristallo 685 Alcatel 686 Francis Wellesplein, 1 687 2018 Antwerp 688 Belgium 689 Phone: +32 (0)3 240 7890 690 E-Mail: geoffrey.cristallo@alcatel.be 692 Christian Jacquenet 693 France Telecom 694 3, avenue Fran�ois Ch�teau 695 CS 36901 696 35069 Rennes Cedex 697 France 698 Phone: +33 2 99 87 63 31 699 Email: christian.jacquenet@francetelecom.com 701 14. Full Copyright Statement 703 Copyright(C) The Internet Society (2003). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it 707 or assist its implementation may be prepared, copied, published and 708 distributed, in whole or in part, without restriction of any kind, 709 provided that the above copyright notice and this paragraph are 710 included on all such copies and derivative works. However, this 711 document itself may not be modified in any way, such as by removing 712 the copyright notice or references to the Internet Society or other 713 Internet organizations, except as needed for the purpose of 714 developing Internet standards in which case the procedures for 715 copyrights defined in the Internet Standards process must be 716 followed, or as required to translate it into languages other than 717 English. 719 The limited permissions granted above are perpetual and will not be 720 revoked by the Internet Society or its successors or assigns. 722 This document and the information contained herein is provided on an 723 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 724 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 725 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 726 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 727 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.