idnits 2.17.1 draft-jacquenet-qos-nlri-04.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 511 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 (March 2002) is 8070 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-01 ** Obsolete normative reference: RFC 2679 (ref. '5') (Obsoleted by RFC 7679) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-ipdv-08 == Outdated reference: A later version (-04) exists of draft-jacquenet-ip-te-cops-02 ** 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 (==), 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-04.txt C. Jacquenet 5 Category: Experimental France Telecom R&D 6 Expires September 2002 March 2002 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 (that includes the figures 32 mentioned in section 7) can be accessed at http://www.ist- 33 tequila.org. 35 Abstract 37 This draft specifies an additional BGP4 (Border Gateway Protocol, 38 version 4, [2]) attribute, named the "QOS_NLRI" attribute, which aims 39 at providing QoS (Quality of Service)-related information associated 40 to the NLRI (Network Layer Reachability Information) information 41 conveyed in a BGP UPDATE message. 43 1. Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [3]. 49 2. Introduction 51 Providing end-to-end quality of service is probably one of the most 52 important challenges of the Internet, not only because of the massive 53 development of value-added IP service offerings, but also because of 54 the various QoS policies that are currently deployed and enforced 55 within an autonomous system, and which may well differ from one AS 56 (Autonomous System) to another. 58 For almost the last decade, value-added IP service offerings have 59 been deployed over the Internet, thus yielding a dramatic development 60 of the specification effort, as far as quality of service in IP 61 networks is concerned. Nevertheless, providing end-to-end quality of 62 service by crossing administrative domains still remains an issue, 63 mainly because: 65 - QoS policies may dramatically differ from one service provider to 66 another, 67 - The enforcement of a specific QoS policy may also differ from one 68 domain to another, although the definition of a set of basic and 69 common quality of service indicators may be shared between the 70 service providers. 72 Activate the BGP4 protocol for exchanging reachability information 73 between autonomous systems has been a must for many years, and, from 74 this standpoint, the BGP4 protocol is one of the key components for 75 the enforcement of end-to-end QoS policies. 77 Therefore, exchanging QoS-related information as well as reachability 78 information in a given BGP UPDATE message appears to be helpful in 79 enforcing an end-to-end QoS policy. 81 This draft aims at specifying a new BGP4 attribute, the QOS_NLRI 82 attribute, which will convey QoS-related information associated to 83 the routes described in the corresponding NLRI field of the 84 attribute. 86 This document is organized into the following sections: 88 - Section 3 identifies the changes that have been made in the 89 document since the last version, 91 - Section 4 describes the basic requirements that motivate the 92 approach, based upon the use of an additional BGP4 attribute, 94 - Section 5 describes the attribute and its mode of operation, 96 - Section 6 elaborates on the use of the capabilities advertisement 97 feature of the BGP4 protocol, 99 - Section 7 depicts the preliminary results of an ongoing simulation 100 work, 102 - Finally, sections 8 and 9 introduce IANA and some security 103 considerations, respectively. 105 3. Changes since the last version of this draft 107 The current version of this draft reflects the following changes: 109 - Slight re-ordering of the beginning of the document, 111 - Introduction of a Requirements section (section 4), 113 - Developed the simulation results section (section 7), 115 - The References section has been updated, 117 - Correction of remaining typos. 119 4. Basic requirements 121 The choice of using the BGP4 protocol for exchanging QoS information 122 between domains is not only motivated by the fact this is currently 123 the only inter-domain (routing) protocol activated in the Internet, 124 but also because the manipulation of attributes is a powerful means 125 for service providers to announce QoS information with the desired 126 level of precision. 128 The approach presented in this draft has identified the following 129 requirements: 131 - Keep the approach scalable. The scalability of the approach can be 132 defined in many ways that include the convergence time to reach a 133 consistent view of the network connectivity, the number of route 134 entries that will have to be maintained by a BGP peer, the 135 dynamics of the route announcement mechanism (e.g., how frequently 136 and under which conditions should an UPDATE message containing QoS 137 information be sent?), etc. 139 - Keep the BGP4 protocol operation unchanged. The introduction of a 140 new attribute should not affect the way the protocol operates, but 141 the information contained in this attribute may very well 142 influence the BGP route selection process. 144 - Allow for a smooth migration. The use of a specific BGP attribute 145 to convey QoS information should not constrain network operators 146 to migrate the whole installed base at once, but rather help them 147 in gradually deploying the QoS information processing capability. 149 5. The QOS_NLRI attribute (Type Code XY*) 151 (*): "XY" is subject to the IANA considerations section of this 152 draft. 154 The QOS_NLRI attribute is an optional transitive attribute that can 155 be used for the following purposes: 157 (a) To advertise a QoS route to a peer. A QoS route is a route that 158 meets one or a set of QoS requirement(s) to reach a given (set 159 of) destination prefixes (see [4], for example). Such QoS 160 requirements can be expressed in terms of minimum one-way delay 161 ([5]) to reach a destination, the experienced delay variation 162 for IP datagrams that are destined to a given destination prefix 163 ([6]), the loss rate experienced along the path to reach a 164 destination, and/or the identification of the traffic that is 165 expected to use this specific route (identification means for 166 such traffic include DSCP (DiffServ Code Point, [7]) marking). 167 These QoS requirements can be used as an input for the route 168 calculation process embedded in the BGP peers, e.g. thanks to 169 the activation of a signaling protocol, such as RSVP (Resource 170 ReSerVation Protocol, [8]), 172 (b) To provide QoS information along with the NLRI information in a 173 single BGP UPDATE message. It is assumed that this QoS 174 information will be related to the route (or set of routes) 175 described in the NLRI field of the attribute. 177 From a service provider's perspective, the choice of defining the 178 QOS_NLRI attribute as an optional transitive attribute is basically 179 motivated by the fact that this kind of attribute allows for gradual 180 deployment of QoS extensions to BGP4: not all the BGP peers are 181 supposed to be updated accordingly, while partial deployment of such 182 QoS extensions can already provide an added value. 184 This draft makes no specific assumption about the means to actually 185 value this attribute, since this is mostly a matter of 186 implementation, but the reader is kindly suggested to have a look on 187 document [9], as an example of a means to feed the BGP peer with the 188 appropriate information. The QOS_NLRI attribute is encoded as 189 follows: 191 +---------------------------------------------------------+ 192 | QoS Information Code (1 octet) | 193 +---------------------------------------------------------+ 194 | QoS Information Sub-code (1 octet) | 195 +---------------------------------------------------------+ 196 | QoS Information Value (2 octets) | 197 +---------------------------------------------------------+ 198 | QoS Information Origin (1 octet) | 199 +---------------------------------------------------------+ 200 | Address Family Identifier (2 octets) | 201 +---------------------------------------------------------+ 202 | Subsequent Address Family Identifier (1 octet) | 203 +---------------------------------------------------------+ 204 | Network Address of Next Hop (4 octets) | 205 +---------------------------------------------------------+ 206 | Network Layer Reachability Information (variable) | 207 +---------------------------------------------------------+ 209 The use and meaning of the fields of the QOS_NLRI attribute are 210 defined as follows: 212 - QoS Information Code: 214 This field carries the type of the QOS information. The 215 following types have been identified so far: 217 (0) Reserved 218 (1) Packet rate, i.e. the number of IP datagrams that can be 219 transmitted (or have been lost) per unit of time, this number 220 being characterized by the elaboration provided in the QoS 221 Information Sub-code (see below) 222 (2) One-way delay, as defined in [5] 223 (3) Inter-packet delay variation, as defined in [6] 224 (4) PHB Identifier, as defined in [10] 226 - QoS Information Sub-code: 228 This field carries the sub-type of the QoS information. The 229 following sub-types have been identified so far: 231 (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub- 232 type) 233 (1) Reserved rate 234 (2) Available rate 235 (3) Loss rate 236 (4) Minimum one-way delay 237 (5) Maximum one-way delay 238 (6) Average one-way delay 240 The instantiation of this sub-code field MUST be compatible with the 241 value conveyed in the QoS Information code field, as stated in the 242 following table (the rows represent the QoS Information Code possible 243 values, the columns represent the QoS Information Sub-code values 244 identified so far, while the "X" sign indicates incompatibility). 246 +---------------------------------------+ 247 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 248 +---------------------------------------+ 249 | 0 | | | | | | | | 250 +---------------------------------------+ 251 | 1 | | | | | X | X | X | 252 +---------------------------------------+ 253 | 2 | | X | X | X | | | | 254 +---------------------------------------+ 255 | 3 | | X | X | X | X | X | X | 256 +---------------------------------------+ 257 | 4 | | X | X | X | X | X | X | 258 +---------------------------------------+ 260 - QoS Information Value: 262 This field indicates the value of the QoS information. The 263 corresponding units obviously depend on the instantiation of the 264 QoS Information Code. Namely, if: 266 (a) QoS Information Code field is "0", no unit specified, 267 (b) QoS Information Code field is "1", unit is kilobits per second 268 (kbps), and the rate encoding rule is composed of a 3-bit 269 exponent (with an assumed base of 8) followed by a 13-bit 270 mantissa, as depicted in the figure below: 272 0 8 16 273 | | | 274 ----------------- 275 |Exp| Mantissa | 276 ----------------- 278 This encoding scheme advertises a numeric value that is (2^16 -1 279 - exponential encoding of the considered rate), as depicted in 280 [11]. 281 (c) QoS Information Code field is "2", unit is milliseconds, 282 (d) QoS Information Code field is "3", unit is milliseconds, 283 (e) QoS Information Code field is "4", no unit specified. 285 - QoS Information Origin: 287 This field provides indication on the origin of the path 288 information, as defined in section 4.3.of [2]. 290 - Address Family Identifier (AFI): 292 This field carries the identity of the Network Layer protocol 293 associated with the Network Address that follows. Presently 294 defined values for this field are specified in [12] (see the 295 Address Family Numbers section of this reference document). 297 - Subsequent Address Family Identifier (SAFI): 299 This field provides additional information about the type of the 300 NLRI carried in the QOS_NLRI attribute. 302 - Network Address of Next Hop: 304 This field contains the IPv4 Network Address of the next router 305 on the path to the destination prefix, (reasonably) assuming 306 that such routers can at least be addressed according to the 307 IPv4 formalism. 309 - Network Layer Reachability Information: 311 This variable length field lists the NLRI information for the 312 feasible routes that are being advertised by this attribute. The 313 next hop information carried in the QOS_NLRI path attribute 314 defines the Network Layer address of the border router that 315 should be used as the next hop to the destinations listed in the 316 QOS_NLRI attribute in the UPDATE message. 318 When advertising a QOS_NLRI attribute to an external peer, a router 319 may use one of its own interface addresses in the next hop component 320 of the attribute, given the external peer to which the route is being 321 advertised shares a common subnet with the next hop address. This is 322 known as a "first party" next hop information. 324 A BGP speaker can advertise to an external peer an interface of any 325 internal peer router in the next hop component, provided the external 326 peer to which the route is being advertised shares a common subnet 327 with the next hop address. This is known as a "third party" next hop 328 information. 330 A BGP speaker can advertise any external peer router in the next hop 331 component, provided that the Network Layer address of this border 332 router was learned from an external peer, and the external peer to 333 which the route is being advertised shares a common subnet with the 334 next hop address. This is a second form of "third party" next hop 335 information. 337 Normally the next hop information is chosen so that the shortest 338 available path will be taken. A BGP speaker must be able to support 339 disabling advertisement of third party next hop information to handle 340 imperfectly bridged media or for reasons of policy. 342 A BGP speaker must never advertise an address of a peer to that peer 343 as a next hop, for a route that the speaker is originating. A BGP 344 speaker must never install a route with itself as the next hop. 346 When a BGP speaker advertises the route to an internal peer, the 347 advertising speaker should not modify the next hop information 348 associated with the route. When a BGP speaker receives the route via 349 an internal link, it may forward packets to the next hop address if 350 the address contained in the attribute is on a common subnet with the 351 local and remote BGP speakers. 353 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 354 ORIGIN and the AS_PATH attributes (both in eBGP and in iBGP 355 exchanges). Moreover, in IBGP exchanges such a message MUST also 356 carry the LOCAL_PREF attribute. If such a message is received from an 357 external peer, the local system shall check whether the leftmost AS 358 in the AS_PATH attribute is equal to the autonomous system number of 359 the peer than sent the message. If that is not the case, the local 360 system shall send the NOTIFICATION message with Error Code UPDATE 361 Message Error, and the Error Sub-code set to Malformed AS_PATH. 363 An UPDATE message that carries no NLRI, other than the one encoded in 364 the QOS_NLRI attribute, should not carry the NEXT_HOP attribute. If 365 such a message contains the NEXT_HOP attribute, the BGP speaker that 366 receives the message should ignore this attribute. 368 6. Use of Capabilities Advertisement with BGP-4 370 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 371 Capabilities Advertisement procedures, as defined in [13], so that it 372 might be able to determine if it can use such an attribute with a 373 particular peer. 375 The fields in the Capabilities Optional Parameter are defined as 376 follows: 378 - The Capability Code field is set to N (127 < N < 256, when 379 considering the "Private Use" range, as specified in [14]), while 380 the Capability Length field is set to "1". 382 - The Capability Value field is a one-octet field, which contains 383 the Type Code of the QOS_NLRI attribute, as defined in the 384 introduction of section 4 of the present draft. 386 7. Preliminary simulation results 388 7.1. A phased approach 390 The simulation work that has begun within the context of the TEQUILA 391 project (see [4]) basically aims at qualifying the scalability of the 392 usage of the QOS_NLRI attribute for propagating QoS-related 393 information between domains. This work also aims at quantifying the 394 added value provided by the QoS extensions to BGP4, as a function of 395 the percentage of the accordingly updated BGP peers. 397 This effort has also been launched to focus on the impact on the 398 stability of the BGP routes, by defining a set of basic engineering 399 rules for the introduction of new QoS information, as well as design 400 considerations for the calculation of "QoS routes". 402 This ongoing development effort is organized into a step-by-step 403 approach, which consists in the following phases: 405 1. Model an IP network composed of several autonomous systems. 406 Since this simulation effort is primarily focused on the 407 qualification of the scalability related to the use of the 408 QOS_NLRI attribute for exchanging QoS-related information 409 between domains, it has been decided that the internal 410 architecture of such domains be kept very simple, i.e. without 411 any specific IGP interaction, 413 2. Within this IP network, there are BGP peers that are QOS_NLRI 414 aware, i.e. they have the ability to process the information 415 conveyed in the attribute, while the other routers do not: these 416 routers do not recognize the QOS_NLRI attribute by definition, 417 and they will forward the information to other peers, by setting 418 the Partial bit in the attribute, meaning that the information 419 conveyed in the message is incomplete. This approach allows to 420 elaborate on the added value introduced by a gradual deployment 421 of the QoS extensions to BGP4, 423 3. As far as QOS_NLRI aware BGP peers are concerned, they will 424 process the information contained in the QOS_NLRI attribute to 425 possibly influence the route decision process, thus yielding the 426 selection (and the installation) of distinct routes towards a 427 same destination prefix, depending on the QoS-related 428 information conveyed in the QOS_NLRI attribute. From this 429 implementation perspective, the BGP routing tables have been 430 modeled so that they contain a "sub-section" where QOS_NLRI- 431 capable peers will store the information conveyed in the 432 attribute, 434 4. Modify the BGP route decision process: at this stage of the 435 simulation, the modified decision process relies upon the one- 436 way delay information (which corresponds to the QoS Information 437 Code field of the attribute valued at "2"), and it also takes 438 into account the value of the Partial bit of the attribute. 440 Once the creation of these components of the IP network has been 441 completed (together with the modification of the BGP route selection 442 process), the behavior of a QOS_NLRI-capable BGP peer is as follows: 444 Upon receipt of a BGP UPDATE message that contains the QOS_NLRI 445 attribute, the router will first check if the corresponding route is 446 already stored in its local RIB, according to the value of the one- 447 way delay information contained in both QoS Information Code and Sub- 448 code fields of the attribute. 450 If not, the BGP peer will install the route in its local RIB. 451 Otherwise (i.e. an equivalent route already exists in its database), 452 the BGP peer will select the best of both routes according to the 453 following criteria: 455 - If both routes are said to be either incomplete (Partial bit has 456 been set) or complete (Partial bit is unset), the route with the 457 lowest delay will be selected, 459 - Otherwise, a route with the Partial bit unset is always 460 preferred over any other route, even if this (complete) route 461 reflects a higher transit delay. 463 If ever both Partial bit and transit delay information are not 464 sufficient to make a decision, the standard BGP decision process 465 (according to the breaking ties mechanism depicted in [2]) is 466 performed. 468 7.2. A case study 470 As stated in the previous section 7.1, the current status of the 471 simulation work basically relies upon the one-way transit delay 472 information only, as well as the complete/incomplete indication of 473 the Partial bit conveyed in the QOS_NLRI attribute. 475 The following figures depict the actual processing of the QoS-related 476 information conveyed in the QOS_NLRI attribute, depending on whether 477 the peer is QOS_NRLI-aware or not. 479 [- Figure 1: a case study. -] 481 Figure 1 depicts the IP network that has been modelled, while figure 482 2 depicts the propagation of a BGP UPDATE message that contains the 483 QOS_NLRI attribute, in the case where the contents of the attribute 484 are changed, because of complete/incomplete conditions depicted by 485 the Partial bit of the QOS_NLRI attribute. 487 [- Figure 2: propagation of one-way delay information via BGP4. -] 489 Router S in figure 2 is a QOS_NRLI-capable speaker. It takes 20 490 milliseconds to node S to reach network 192.0.20.0: this information 491 will be conveyed in a QOS_NLRI attribute that will be sent by node S 492 in a BGP UPDATE message with the Partial bit of the QOS_NLRI 493 attribute unset. 495 Router A is another QOS_NLRI BGP peer, and it takes 3 milliseconds 496 for A to reach router S. Node A will update the QoS-related 497 information of a QOS_NLRI attribute, indicating that, to reach 498 network 192.0.20.0, it takes 23 milliseconds. Router A will install 499 this new route in its database, and will propagate the corresponding 500 UPDATE message to its peers. 502 On the other hand, router B is not capable of processing the 503 information conveyed in the QOS_NLRI attribute, and it will therefore 504 set the Partial bit of the QOS_NLRI attribute in the corresponding 505 UPDATE message, leaving the one-way delay information detailed in 506 both QoS Information Code and Sub-code unchanged. 508 Upon receipt of the UPDATE message sent by router A, router E will 509 update the one-way delay information since it is a QOS_NRLI-capable 510 peer. Finally, router D receives the UPDATE message, and selects a 511 route with a 40 milliseconds one-way delay to reach network 512 192.0.20.0, as depicted in figure 3. 514 [- Figure 3: selecting QoS routes across domains. -] 516 This simulation result shows that the selection of a delay-based 517 route over a BGP route (as depicted in [2]) may not yield an optimal 518 decision. In the above example, the 40 ms-route goes through routers 519 D-E-A-S, while a "truly optimal" BGP route would be through routers 520 D-E-F-A-S, hence a 38 ms-route. This is because of a BGP4 rule that 521 does not allow router F to send an UPDATE message towards router E, 522 because router F received the UPDATE message from router A thanks to 523 the iBGP connection it has established with A. 525 These basic observations confirm that the enforcement of a QoS policy 526 between domains by using the BGP4 protocol is obviously conditioned 527 by the BGP4 routing policies that are enforced within each domain. 529 7.3. Preliminary results 531 The following table reflects the first results obtained from a 532 simulation network composed of 9 autonomous systems and 20 BGP peers. 533 The numbers contained in the columns reflect the percentage of 534 serviced requirements, where the requirements are expressed in terms 535 of delay. 537 Three parameters have been taken into account: 539 - The percentage of BGP peers that have the ability to process the 540 information conveyed in the QOS_NLRI attribute (denoted as "x% Q- 541 BGP" in the following table), 543 - The transit delays "observed" (and artificially simulated) on 544 each transmission link: the higher the delays, the lower the 545 percentage of serviced QoS requirements, 547 - The QoS requirements themselves, expressed in terms of delay: as 548 such, the strongest requirements (i.e. the lowest delays) have 549 less chance to be satisfied. 551 +-------------------------------------------+ 552 | Delay | 0% Q-BGP | 50% Q-BGP | 100% Q-BGP | 553 +-------------------------------------------+ 554 | 3 | 11 | 8,3 | 11 | 555 +-------------------------------------------+ 556 | 5 | 30,5 | 30,5 | 36,1 | 557 +-------------------------------------------+ 558 | 6 | 40 | 47,2 | 55,5 | 559 +-------------------------------------------+ 560 | 7 | 47 | 59,7 | 72,2 | 561 +-------------------------------------------+ 562 | 8 | 62,5 | 79 | 91,6 | 563 +-------------------------------------------+ 564 | 9 | 63 | 84,7 | 97,2 | 565 +-------------------------------------------+ 566 | 10 | 70,8 | 90,2 | 98,6 | 567 +-------------------------------------------+ 568 | 11 | 76,3 | 93 | 98,6 | 569 +-------------------------------------------+ 570 | 12 | 86,1 | 97,2 | 100 | 571 +-------------------------------------------+ 572 | 13 | 88,8 | 98,6 | 100 | 573 +-------------------------------------------+ 574 | 14 | 94,4 | 100 | 100 | 575 +-------------------------------------------+ 576 | 15 | 94,4 | 100 | 100 | 577 +-------------------------------------------+ 578 | 16 | 94,4 | 100 | 100 | 579 +-------------------------------------------+ 580 | 17 | 97,2 | 100 | 100 | 581 +-------------------------------------------+ 582 | 18 | 98,6 | 100 | 100 | 583 +-------------------------------------------+ 584 | 19 | 98,6 | 100 | 100 | 585 +-------------------------------------------+ 586 | 20 | 98,6 | 100 | 100 | 587 +-------------------------------------------+ 588 | 21 | 98,6 | 100 | 100 | 589 +-------------------------------------------+ 590 | 22 | 100 | 100 | 100 | 591 +-------------------------------------------+ 593 While this table demonstrates the technical feasibility of the 594 approach (and how the use of the QOS_NLRI attribute can improve the 595 percentage of serviced QoS requirements), the results presented here 596 remain obviously preliminary, as discussed in the next section. 598 7.4. Next steps 600 The above-mentioned simulation effort will be pursued in order to 601 better qualify the interest of using the BGP4 protocol to convey QoS- 602 related information between domains, from a scalability perspective, 603 i.e. the increase of BGP traffic vs. the stability of the network. 605 The stability of the IP network is probably one of the most important 606 aspects, since QoS-related information is subject to very dynamic 607 changes, thus yielding non-negligible risks of flapping. 609 It is therefore expected that the upcoming versions of this draft 610 will reflect the progress of this simulation work, which will take 611 into account other types of QoS information, among other tracks of 612 evolution. 614 8. IANA Considerations 616 Section 5 of this draft documents an optional transitive BGP-4 617 attribute named "QOS_NLRI" whose type value will be assigned by IANA. 619 Section 6 of this draft also documents a Capability Code whose value 620 should be assigned by IANA. 622 9. Security Considerations 624 This additional BGP-4 attribute specification does not change the 625 underlying security issues inherent in the existing BGP-4 protocol 626 specification [15]. 628 10. References 630 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 631 9, RFC 2026, October 1996. 633 [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 634 1771, March 1995. 636 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 637 Levels", BCP 14, RFC 2119, March 1997. 639 [4] Goderis, D., T'Joens, Y., Jacquenet, C., Memenios, G., Pavlou, 640 G., Egan, R., Griffin, D., Georgatsos, P., Georgiadis, L., 641 "Specification of a Service Level Specification (SLS) Template", 642 draft-tequila-sls-01.txt, Work in Progress, June 2001. Check 643 http://www.ist-tequila.org for additional information. 645 [5] Almes, G., Kalidindi, S., "A One-Way-Delay Metric for IPPM", RFC 646 2679, September 1999. 648 [6] Demichelis, C., Chimento, P., "IP Packet Delay Variation Metric 649 for IPPM", draft-ietf-ippm-ipdv-08.txt, Work in Progress, November 650 2001. 652 [7] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the 653 Differentiated Services Field (DS Field) in the IPv4 and IPv6 654 Headers", RFC 2474, December 1998. 656 [8] Braden, R., et al., "Resource ReSerVation Protocol (RSVP)- 657 Version 1 Functional Specification", RFC 2205, September 1997. 659 [9] Jacquenet, C., "A COPS client-type for IP traffic engineering", 660 draft-jacquenet-ip-te-cops-02.txt, Work in Progress, June 2001. 662 [10] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop 663 Behavior Identification Codes", RFC 3140, June 2001. 665 [11] Apostolopoulos, G. et al, "QoS Routing Mechanisms and OSPF 666 Extensions", RFC 2676, August 1999. 668 [12] Reynolds, J., Postel, J., "ASSIGNED NUMBERS", RFC 1700, October 669 1994. 671 [13] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 672 4", RFC 2842, May 2000. 674 [14] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 675 Considerations Section in RFCs", RFC 2434, October 1998. 677 [15] Heffernan, A., "Protection of BGP sessions via the TCP MD5 678 Signature Option", RFC 2385, August 1998. 680 11. Acknowledgments 682 Part of this work is funded by the European Commission, within the 683 context of the TEQUILA (Traffic Engineering for Quality of Service in 684 the Internet At Large Scale, [4]) project, which is itself part of 685 the IST (Information Society Technologies) research program. 687 The author would also like to thank all the partners of the TEQUILA 688 project for the fruitful discussions that have been conducted within 689 the context of the traffic engineering specification effort of the 690 project, as well as O. Bonaventure and B. Carpenter for their 691 valuable input. 693 12. Authors' Addresses 695 Geoffrey Cristallo 696 Alcatel 697 Francis Wellesplein, 1 698 2018 Antwerp 699 Belgium 700 Phone: +32 (0)3 240 7890 701 E-Mail: geoffrey.cristallo@alcatel.be 703 Christian Jacquenet 704 France Telecom R & D 705 DMI/SIR 706 42, rue des Coutures 707 BP 6243 708 14066 Caen Cedex 4 709 France 710 Phone: +33 2 31 75 94 28 711 Email: christian.jacquenet@rd.francetelecom.com 713 13. Full Copyright Statement 715 Copyright(C) The Internet Society (2002). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist its implementation may be prepared, copied, published and 720 distributed, in whole or in part, without restriction of any kind, 721 provided that the above copyright notice and this paragraph are 722 included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into languages other than 729 English. 731 The limited permissions granted above are perpetual and will not be 732 revoked by the Internet Society or its successors or assigns. 734 This document and the information contained herein is provided on an 735 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 736 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 737 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 738 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 739 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.