idnits 2.17.00 (12 Aug 2021) /tmp/idnits52412/draft-boucadair-qos-bgp-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 945. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 are 15 instances 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 38 has weird spacing: '... This memo ...' == Line 82 has weird spacing: '... and manage...' == Line 83 has weird spacing: '...ability persp...' == Line 85 has weird spacing: '...rmation in a...' == Line 86 has weird spacing: '...ability infor...' == (19 more instances...) -- 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 2005) is 6147 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IAB' is mentioned on line 80, but not defined == Missing Reference: 'BGP' is mentioned on line 98, but not defined == Missing Reference: 'CAP' is mentioned on line 273, but not defined == Missing Reference: 'WALTON' is mentioned on line 516, but not defined == Outdated reference: A later version (-06) exists of draft-walton-bgp-add-paths-01 ** Obsolete normative reference: RFC 2385 (ref. 'BGPSEC') (Obsoleted by RFC 5925) Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 (Editor) 4 Internet Draft France Telecom R&D 5 Document: draft-boucadair-qos-bgp-spec-01.txt July 2005 6 Category: Experimental 8 QoS-Enhanced Border Gateway Protocol 9 < draft-boucadair-qos-bgp-spec-01.txt > 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress" 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2006. 36 Abstract 38 This memo describes a proposal for exchanging QoS-enabled 39 reachability information between service providers. It defines new 40 BGP attributes to be used in order to convey QoS performance 41 characteristics between service providers and it describes how to use 42 these QoS values in order to select the best path. An example of 43 route selection process that takes into account the QoS performance 44 values enclosed in BGP messages is also detailed. 46 Table of Contents 48 1. Introduction................................................2 49 2. Conventions used in this document...........................3 50 3. Terminology.................................................3 51 4. Inter domain QoS delivery services taxonomy.................3 52 5. q-BGP requirements and behaviors............................4 53 5.1. Requirements................................................4 54 5.2. q-BGP behaviors.............................................5 55 5.3. How to set QoS-related information carried in q-BGP 56 messages?.................................................5 57 6. q-BGP specifications........................................5 58 6.1. Attributes..................................................6 59 6.1.1. QoS Service Capability......................................6 60 6.1.2. QoS_NLRI attribute..........................................7 61 6.1.3. QoS_NLRI attribute for Group-1..............................7 62 6.1.4. QoS_NLRI attribute for Group-2..............................9 63 6.1.5. Multiple paths.............................................11 64 6.2. Processing q-BGP attributes................................11 65 6.3. q-BGP Route Selection Process..............................12 66 6.3.1. Group-1 Route Selection Process............................12 67 6.3.2. Group-2 Route Selection Process............................13 68 6.3.2.1. QoS comparison logic.....................................14 69 6.3.2.2. Priority-based route selection process...................14 70 o Processing of route with QoS holes..........................16 71 7. Security Considerations....................................18 72 8. References.................................................18 73 9. Acknowledgments............................................19 74 10. Contributors...............................................19 75 11. Author's Address...........................................19 77 1. Introduction 79 QoS delivery services are seen as critical future Internet services 80 [IAB]. The introduction of such services requires updating network 81 infrastructures, including network devices capabilities, protocols, 82 and management tools, with appropriate technologies. From a 83 reachability perspective, modifications need to be brought to 84 existing signaling and routing protocols in order to convey richer 85 information in addition to best effort one. In other words, 86 reachability information should provide routers with pertinent 87 information to help the route selection decision-making process. Such 88 information could be for instance the QoS that will be experienced 89 along a given path. Therefore, Network Providers have to evolve and 90 update the protocols deployed in their domains in order to meet the 91 new requirements and then to be able to offer new sophisticated added 92 value services. As far as inter-domain is concerned, the issue is 93 crucial since all providers should deploy means to convey QoS-related 94 information between their domains so that QoS-based services could 95 have a world-wide scope and then be accessible for a large set of 96 customers. 98 The Border Gateway Protocol (BGP) protocol [BGP] is the de facto 99 protocol deployed by network providers in order to interconnect their 100 autonomous systems with the ones of their peers. This memo describes 101 how BGP could be used as a means to convey QoS-related information 102 between adjacent autonomous systems and then allow deployment of new 103 inter-domain QoS delivery services. The proposed solution is generic 104 and could be applied to any kind of inter-domain QoS delivery 105 solution that is based on the exchange of QoS-related information. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 113 3. Terminology 115 This memo makes use of the following terms: 117 o Local QoS Class: A QoS transfer capability within a single SP 118 domain, characterized by a set of QoS performance parameters. 120 o Extended QC: A QoS transfer capability provided using both the 121 local domain and neighbor domains. An extended QC is provided by 122 combining the local QC of local domain with the ones of adjacent 123 domains. The topological scope of an extended QC extends the 124 boundaries of local domain. 126 o Domain: within this document it denotes an Autonomous System 128 o q-BGP (QoS-enhanced BGP): an enhanced BGP that takes into 129 account QoS information it carries in its messages as an input 130 to its route selection process. 132 4. Inter domain QoS delivery services taxonomy 134 Internet is a collection of domains interconnected together and that 135 exchange reachability information between them. In order to introduce 136 inter domain QoS delivery services, providers should exchange QoS 137 information in addition to best effort one. This information will be 138 used as an input for the route selection process and will guide the 139 selection of optimal paths that will be used to carry traffic 140 belonging to inter-domain QoS services. The QoS-related information 141 exchange occurs either at the service level or at the routing level. 143 Two groups of QoS delivery services have been identified and are 144 detailed hereafter: 146 o The first group of services requires propagating only an 147 identifier that has been agreed between adjacent peers. This 148 identifier could be the DSCP value used to signal an extended 149 QoS class. Additional QoS performance characteristics could be 150 negotiated but not exchanged in the routing level. In the rest 151 of this document, we will refer to this group as "group-1". 153 o The second group requires the propagation of a set of QoS 154 performance characteristics associated with an identifier. The 155 nature of the QoS-related information to be exchanged has to be 156 agreed between adjacent peers. We will refer to this group in 157 the rest of this document as "group-2". 159 5. q-BGP requirements and behaviors 161 5.1. Requirements 163 As stated in the introduction, BGP is the inter domain routing 164 protocol used to interconnect domains. This protocol is widely 165 deployed and activated in a big range of network nodes. One of the 166 risks to be taken into account when introducing new services like 167 inter domain QoS ones is to preserve backward compatibility. 168 Therefore, in order to ease introduction of these value added 169 services, it is recommended to reuse existing protocols and systems. 170 Nevertheless, these protocols should be evolved and enhanced with 171 additional features in order to achieve these new service objectives. 173 As far as inter domain routing is concerned, we will reuse BGP and 174 define new features in order to convey QoS-related information. This 175 information could only be reduced to a DS code point or be a set of 176 QoS performance characteristics. In the rest of this document we will 177 refer to this enhanced BGP as q-BGP (QoS-Enhanced BGP) protocol. When 178 designing extensions to be added to classical BGP, the following 179 requirements are to be taken into account: 181 o The q-BGP protocol should, as far as possible, be able to 182 operate independently of the inter-domain QoS delivery service 183 it serves. Nevertheless, q-BGP should be able to detect the 184 group it serves. 186 o q-BGP should be able to propagate topology changes without any 187 significant impact on the existing best-effort based network 188 infrastructure; 190 o q-BGP should be able to support all kind of services based on an 191 exchange of QoS-related information especially to serve the two 192 groups described above. 194 5.2. q-BGP behaviors 196 q-BGP could have several behaviors depending on the nature of the 197 QoS-related information carried by its messages. If q-BGP messages 198 carry only a QC identifier (this identifier could be a DS code-point 199 or a proprietary identifier), offline traffic engineering functions 200 are certainly complex but the q-BGP route selection process 201 complexity is reduced. This complexity increases when a set of QoS 202 characteristics are associated with each QC identifier. The route 203 selection process can use either the QC-identifier for all services 204 that take part of group-1 or the QC-identifier and QoS performance 205 characteristics for solutions belonging to group-2. 207 5.3. How to set QoS-related information carried in q-BGP messages? 209 q-BGP can carry QoS performance characteristics that could be 210 advantageously taken into account by the q-BGP route selection 211 process to select an optimal path. This would enable to tune the 212 route selection process in order to select routes according to more 213 sophisticated routing policies (e.g route with highest available rate 214 and lower delay). The QoS information inserted in q-BGP messages 215 could be of different nature. It could be (1) administratively 216 enforced. In that case it would not change too frequently. Or, it 217 could (2) be much more dynamic (result of an active measurement for 218 instance). In that case the frequency of changes could be much 219 higher. 221 Administrative setting of QoS values could be achieved either 222 statically or periodically. If these values are set statically, the 223 behavior of q-BGP will be static and the route selection process will 224 choose the same route. The QoS-related information doesnÆt bring 225 major added-value to the final behavior of the route decision making 226 process and freezes the state of the inter-domain routing. 227 Nevertheless, in the case of QoS performance characteristics values 228 are set periodically or dynamically, providers will deploy mechanisms 229 that monitor the network and then guide the setting of these values. 230 q-BGP will be provided by accurate information in order to select the 231 optimal path. The frequency between two q-BGP router configuration 232 operations in an administrative scheme should not be too small and 233 could be very small in the dynamic scheme. In case of dynamic setting 234 scheme, the risk is to impact routing table stability and probably 235 introduce oscillation phenomena. 237 6. q-BGP specifications 239 In this section we detail the specification of q-BGP. This 240 specification encloses new attributes introduced in order to convey 241 QoS performance characteristics between distinct domains. Also, we 242 detail the processing of QoS_NLRI attribute and the use of QoS 243 related information enclosed in BGP update message in order to select 244 an optimal path towards a given prefix. A new capability attribute 245 that allows negotiation of QoS service capability is also defined. 247 6.1. Attributes 249 6.1.1. QoS Service Capability 251 In order to prevent from BGP session closure due to reception of a 252 non supported optional parameter, IDR WG has adopted a mechanism 253 called capability negotiation [CAP]. Capability exchange is achieved 254 thanks to the specification of a new optional parameter. 256 As far as q-BGP is concerned, it is useful for a q-BGP peer to know 257 the capabilities of a q-BGP neighbor with respect to the BGP protocol 258 extensions. Thus, a new parameter is included in the optional 259 parameters of the OPEN message of a q-BGP session to indicate that 260 this peer supports q-BGP related attributes. 262 In order to indicate that a given inter-domain QoS delivery solution 263 belongs to a given group (either group-1 or group-2) a new parameter 264 called QoS Service Capability is introduced. A q-BGP speaker SHOULD 265 use this capability advertisement in order to indicate the group to 266 which an offered inter-domain QoS delivery solution belongs to, so 267 that q-BGP peers can deduce if they can use the 'QoS service'-related 268 attributes with a q-BGP speaker. 270 The fields of this optional parameter are set as follows: 272 o The capability code field is set to a value between 128 and 255 273 as described in [CAP]; 275 o The capability length is set to 2; 277 o The capability value field is encoded as shown in Figure below: 279 +--------------------+--------------------+ 280 | G1QS | G2QS | 281 | | | 282 +--------------------+--------------------+ 284 Figure 1. QoS service capability attribute. 286 o The first octet (G1QS, Group-1 QoS Service) is set to 0xFF if an 287 offered inter-domain QoS delivery solution that belongs to 288 group-1 is supported; 290 o The second octet (G2SQ, Group-2 QoS Service) is set to 0xFF if 291 an offered inter-domain QoS delivery solution that belongs to 292 group-2 is supported. 294 6.1.2. QoS_NLRI attribute 296 In order to convey QoS-related information, we adopt the [QOSNLRI] 297 proposal that consists at introducing a new optional attribute called 298 QOS_NLRI attribute as the starting point. This attribute is modified 299 in order to support the requirements of two groups defined above. The 300 format of the QoS_NLRI is different depending on the group (group-1 301 or group-2) it serves. 303 The modifications are twofold: 305 o Information carried by this attribute: 307 o The [QOSNLRI] proposal allows to send only one QoS 308 performance characteristic per announcement. This 309 limitation has been relaxed within this specification since 310 it might be necessary to carry a list of QoS performance 311 characteristics in a single q-BGP UPDATE message; 313 o Unlike the [QOSNLRI] proposal, this specification allows to 314 propagate information about extended QCs that are pre- 315 negotiated between service peers; 317 o The [QOSNLRI] proposal adopts the multiple paths [Walton]. 318 The basic q-BGP specification focuses on single path; 320 o The PHB identifier has been removed from the list of 321 possible "QoS Information Code" because of the existence of 322 "QoS Class identifier". 324 o The format of the QoS_NLRI attribute: 325 o Add a new field called "QoS Information length": the 326 purpose of this field is to indicate the number of QoS 327 performance characteristics that are enclosed in a q-BGP 328 UPDATE message. 330 o The lengths of "QoS Information code" and "QoS Information 331 Sub-code" have been reduced to 4 bits in order to reduce 332 the total length of the QOS_NLRI attribute. This is also 333 motivated by the fact that 2^4 values are sufficient to 334 indicate this information. 336 6.1.3. QoS_NLRI attribute for Group-1 337 As described above, both group-1 and group-2 solutions need to 338 exchange a QC identifier. This identifier is used to differentiate 339 between the extended QCs. Especially this is the unique additional 340 information that must be carried by q-BGP messages. Therefore, we 341 define a new QoS_NLRI attribute for group-1 solutions. The format of 342 this QoS_NLRI attribute is as follows: 344 0 7 15 345 +------------------------------+ 346 |QoS Class Identifier | 347 +------------------------------+------------------------------+ 348 |Address Family Identifier | 349 +------------------------------+------------------------------+ 350 |SAFI | 351 +------------------------------+ 352 |Next Hop Address Length | 353 +------------------------------+----------------------+ 354 |Network Address of next hop (variable) | 355 +-----------------------------------------------------+ 356 |NLRI (variable) | 357 +-----------------------------------------------------+ 359 Figure 2. QoS NLRI attribute for Group-1. 361 The meaning of the fields of the group-1 QOS_NLRI attribute is as 362 follows: 364 o QoS class identifier (1 octet): this field indicates the QC 365 identifier as described in [DS]; 367 o Address Family Identifier (AFI) (2 octet): this field carries 368 the identity of the Network Layer protocol associated with the 369 Network Address that follows; 371 o Subsequent Address Family Identifier (SAFI) (1 octet): this 372 field provides additional information about the type of the 373 prefix carried in the QOS_NLRI attribute; 375 o Next Hop Network address length (1 octet): the length of next 376 hop network address; 378 o Network address of Next Hop: this field contains the network 379 address of the next router on the path to the destination 380 prefix; 382 o Network Layer Reachability Information: This variable length 383 field lists the NLRI information for the feasible routes that 384 are being advertised by this attribute. The next hop information 385 carried in the QOS_NLRI path attribute defines the Network Layer 386 address of the border router that should be used as the next hop 387 to the destinations listed in the QOS_NLRI attribute in the 388 UPDATE message. 390 6.1.4. QoS_NLRI attribute for Group-2 392 As described above, group-2 solutions need to exchange both QC 393 identifier and a set of QoS performance characteristics. Therefore, 394 we define a new QoS NLRI attribute that carry several QoS values for 395 a given extended QC. The format of this new attribute is as follows: 397 0 3 7 399 +------------------------------+------------------------------+ 400 |QoS Information length | 401 +------------------------------+------------------------------+ 402 |QoS Information Code |QoS Information Sub-Code | 403 +------------------------------+------------------------------+ 404 |QoS Information value | 405 + + 406 | | 407 +------------------------------+------------------------------+ 408 |QoS Information length | 409 +------------------------------+------------------------------+ 410 |QoS Information Code |QoS Information Sub-Code | 411 +------------------------------+------------------------------+ 412 |QoS Information value | 413 + + 414 | | 415 +------------------------------+------------------------------+ 416 . 417 +------------------------------+------------------------------+ 418 |QoS Information length | 419 +------------------------------+------------------------------+ 420 |QoS Information Code |QoS Information Sub-Code | 421 +------------------------------+------------------------------+ 422 |QoS Information value | 423 + + 424 | | 425 +------------------------------+------------------------------+ 426 |QoS Class Identifier | 427 +------------------------------+------------------------------+ 428 |Address Family Identifier | 429 + + 430 | | 431 +------------------------------+------------------------------+ 432 |SAFI | 433 +------------------------------+------------------------------+ 434 |Next Hop Address Length | 435 +-------------------------------------------------------------+ 436 |Network Address of next hop (variable) | 437 +-------------------------------------------------------------+ 438 |NLRI (variable) | 439 +-------------------------------------------------------------+ 441 Figure 3. QoS NLRI attribute for Group-1. 443 The meaning of the fields of the group-2 QOS_NLRI attribute is 444 defined below: 446 o QoS information length: this field carries the number of the QoS 447 information Code that will be sent by the q-BGP speaker in a 448 single q-BGP UPDATE message. 450 o QoS information Code: this field identifies the type of QoS 451 information: 453 o (0) Reserved 455 o (1) Packet rate 457 o (2) One-way delay metric 459 o (3) Inter-packet delay variation 461 o QoS information Sub-code: this field carries the sub-type of the 462 QoS information. The following sub-types have been identified: 464 o (0) None 466 o (1) Reserved rate 468 o (2) Available rate 470 o (3) Loss rate 472 o (4) Minimum one-way delay 474 o (5) Maximum one-way delay 476 o (6) Average one-way delay 478 o QoS information value: this field indicates the value of the QoS 479 information. The corresponding units depend on the instantiation 480 of the QoS information code. 482 o QoS class identifier: this field indicates the QC identifier as 483 described in [DS]. 485 o Address Family Identifier (AFI): this field carries the identity 486 of the Network Layer protocol associated with the Network 487 Address that follows. 489 o Subsequent Address Family Identifier (SAFI): this field provides 490 additional information about the type of the prefix carried in 491 the QOS_NLRI attribute. 493 o Length of Next HopÆ Network address: this field carries the 494 length of next hopÆs network address; 496 o Network address of Next Hop: this field contains the network 497 address of the next router on the path to the destination 498 prefix. 500 o Network Layer Reachability Information: This variable length 501 field lists the NLRI information for the feasible routes that 502 are being advertised by this attribute. The next hop information 503 carried in the QOS_NLRI path attribute defines the Network Layer 504 address of the border router that should be used as the next hop 505 to the destinations listed in the QOS_NLRI attribute in the 506 UPDATE message. 508 6.1.5. Multiple paths 510 [Walton] proposes a mechanism that allows the advertisement of 511 multiple paths for the same prefix without the new path implicitly 512 replacing any previous ones. This is achieved thanks to the use of an 513 arbitrary identifier that will identify (in addition to the prefix) a 514 given path. The QoS_NLRI attributes could support this mechanism by 515 adding: Flags, Identifier, Length, and Prefix in the QoS NLRI 516 attribute. The meaning of these fields is described in [WALTON]. 518 6.2. Processing q-BGP attributes 520 As described above, q-BGP peers could exchange their respective 521 capabilities through capability negotiation procedure. As a 522 consequence, q-BGP peers will indicate if they both support QoS_NLRI 523 attribute or not. If a q-BGP speaker does not support capability 524 negotiation feature, it will be hard to know in advance its behavior 525 when receiving QoS_NLRI attribute. Therefore, three scenarios should 526 be examined in order to describe the processing of QoS_NLRI attribute 527 by a q-BGP speaker: 529 o Scenario 1: If a q-BGP speaker does not support capability 530 feature, QoS_NLRI could be sent to this peer; 532 o Scenario 2: If a q-BGP speaker does not support QoS Service 533 Capability, no QoS_NLRI should be sent to this peer; 535 o Scenario 3: Both q-BGP peers support QoS Service Capability. In 536 this case, q-BGP peers could use QoS_NLRI attribute. The variant 537 of QoS_NLRI attribute that will be used depends on the nature of 538 the deployed inter-domain QoS delivery solution, either it is a 539 group-1 or group-2. 541 o When sending a QoS_NLRI attribute, the local q-BGP speaker 542 should set the QC identifier field to the identifier of 543 extended QC on the corresponding inter-domain link. In 544 addition, if it is a group-2 solution and if the q-BGP peer 545 supports group-2 QoS delivery solution, the local q-BGP 546 speaker should set the value(s) of ôQoS Information valueö 547 field(s). 549 o When receiving a QoS_NLRI attribute, q-BGP speaker applies 550 its inbound policies to grant the received announcement 551 depending on QC binding list. The local q-BGP speaker gets 552 the value of the ôQoS Class Identifierö enclosed in the 553 QoS_NLRI of the received announcement and checks if there 554 is a binding entry. 556 o If there is no entry in the binding list: the local 557 q-BGP speaker drops the received announcement. 559 o If there is an entry in the binding list: the local 560 q-BGP speaker updates the values of ôQoS 561 Information valueö fields enclosed in the QoS_NLRI 562 with the ones of bound QC. 564 6.3. q-BGP Route Selection Process 566 As far as QoS-related information is conveyed in BGP UPDATE messages, 567 the route selection process should take into account this information 568 in order to make a choice and make a tie-break between equal paths 569 and determine the one(s) to be stored in the local FIB. This process 570 could differ between solutions that belong to group-1 or group-2. 572 6.3.1. Group-1 Route Selection Process 574 For inter-domain QoS-delivery solution that belongs to group-1 only 575 the identifier of the extended QC is to be taken into account in 576 order to choose a path that will be stored in the local RIB. The 577 unique modification to be added to the classical route selection 578 process is to identify routes that serve the same destination with 579 similar extended QCs. Local policies could be configured by each INP 580 in their ASBRs. 582 From this perspective, the pseudo code of the modified route 583 selection process will be as follows: 585 ===================================================================== 587 1. Identify the received routes that serve the same destination 589 2. Consider the routes with similar extended QCs 591 3. Apply local policies (e.g. prefer a given origin AS, cost,à). 593 4. If only one route has been returned 594 Store this route in the RIB 596 5. If more than one route has been returned 597 Apply the classical BGP route selection process. 599 ===================================================================== 601 6.3.2. Group-2 Route Selection Process 603 For inter-domain QoS-delivery solutions that belong to group-2, q-BGP 604 UPDATE messages carry QoS performance characteristics together with a 605 QC identifier. q-BGP route selection process should exploit enclosed 606 QoS performance characteristics in order to determine the path that 607 will be stored in the local RIB. Modifications that should be added 608 to the classical route selection process are at least as follows: 610 o Identify routes that serve the same destination in the same QC 611 plane; 613 o Select a route that optimises QoS performance characteristics. 615 Therefore, the pseudo code of the new route selection process 616 becomes: 618 ===================================================================== 620 1. Identify routes that serve the same destination 622 2. Consider routes that have the same QoS class identifier 624 3. Compare the QoS performance characteristics associated with 625 resulting routes with respect to a given comparison logic 627 4. Return the route that optimises the QoS performance characteristic 629 5. if more than one route has been returned, apply the classical BGP 630 route selection process 632 ===================================================================== 634 6.3.2.1. QoS comparison logic 636 In this section, we discuss several approaches for comparing sets of 637 QoS values enclosed in q-BGP messages. Consider two QoS tuples X and 638 Y. These tuples consist of both the attributes (e.g. delay, jitter, 639 loss rate) and their values. Let the tuples consist of QoS attributes 640 A, B and C, and let the QoS tuple X have the values (Ax, Bx, Cx) and 641 let QoS tuple Y have the values (Ay, By, Cy). 643 Then to compare the two QoS tuples X and Y, a number of mechanisms 644 can be adopted. To generalise the discussion, here we assume that 645 ôP>Qö means that P is better than Q, irrespective of whether we are 646 comparing bandwidth values (where a higher numerical value represents 647 a better level of QoS) or delay values (where a lower numerical value 648 represents a better level of QoS). The proposed mechanisms are as 649 follows: 651 o Lexicographical ordering method: the QoS attributes are compared 652 in strict order. Thus if Ax > Ay then X is better than Y, 653 irrespective of the relative values of Bx, By, Cx or Cy. If Ax 654 = Ay then the second QoS attributes are compared: if Bx > By 655 then X is said to be better than Y. We refer to the route 656 selection process that uses this QoS comparison logic as 657 priority-based route selection process. 659 o Simultaneous comparison method: X is better than Y if Ax > Ay 660 and Bx > By and Cx > Cy. Similarly, Y is better than X if Ay > 661 Ax and By > Bx and Cy > Cx. This approach does not define a 662 result if some of the QoS attributes A, B, C of one tuple are 663 better than the second tuple but some of the QoS attributes are 664 worse. For example, if Ax > Ay while By > Bx then the result of 665 the comparison of X with Y is undefined. This approach is not 666 recommended to be used as QoS comparison logic in route 667 selection process implementations. 669 o Weighted ordering method: the QoS attributes are normalised to 670 create dimensionless values, and summed. This results in a 671 single value for each QoS tuple, which can be compared to 672 determine which tuple is better. The dimensionless values could 673 additionally be weighted so as to prefer one attribute over 674 others. The advantage of this approach is that it potentially 675 allows a wider range of QoS metrics to be fairly compared, for 676 example ôa low delay route with reasonable bandwidthö. 678 6.3.2.2. Priority-based route selection process 680 When a route selection process implements lexicographical comparison 681 logic, priority values must be assigned to QoS performance 682 characteristics. Then, the comparison of available routes should be 683 based on the use of the priority value that has been affected to each 684 QoS performance characteristic. The priority ordering of the QoS 685 performance characteristics could be commonly understood by service 686 providers or only configured by each provider. The philosophy of this 687 method is: ôfind the route that optimises the highest priority QoS- 688 related informationö. 690 Therefore, the pseudo code of the priority-based route selection 691 process algorithm is as follows: 693 ===================================================================== 695 1. Identify routes that serve the same destination 697 2. Consider routes that have the same QoS class identifier 699 3. Consider the QoS performance characteristic that has the highest 700 priority, and return the routes that optimise that QoS 701 performance characteristic 703 i. If only one route is returned store this route in the local 704 RIB 706 ii. If more than one route are returned 708 1. Exclude the QoS performance characteristic that has 709 been used in the step 3 from the list of QoS 710 performance characteristics. 712 a. If there is no remaining QoS performance 713 characteristics, go to step 4 715 b. Else, go to step 3 717 4. if more than one route has been returned, apply the classical 718 BGP route selection process 720 ===================================================================== 722 Example: Suppose that a q-BGP listener has received the following 723 routes for reaching the same destination. Each of these routes is 724 associated with a set of QoS performance values as follows: 726 o R1: minimum one way delay=150ms, Loss rate=5% 728 o R2: minimum one way delay=90ms, Loss rate=2% 730 o R3: minimum one way delay=100ms, Loss rate=3% 732 o R4: minimum one way delay=200ms, Loss rate=1% 734 If the q-BGP router is configured to prioritize minimum one way 735 delay, the selected route is R2. But if the q-BGP router is 736 configured to prioritize loss rate, the selected route is R4. 738 o Processing of route with QoS holes 740 Let suppose now that a q-BGP router has received from its peers, the 741 following routes for reaching the same destination D1. The received 742 routes enclose the following QoS performance values as detailed 743 below: 745 o Route R1: QoS1=90ms, QoS3=150ms, QoS4=5% 747 o Route R2: QoS2=30ms, QoS3=153ms, QoS4=1% 749 o Route R3: QoS1= 120ms, QoS2=100ms, QoS3= 60ms, QoS4=3% 751 o Route R4: QoS2=90ms, QoS3= 50ms, QoS4=8% 753 The aforementioned routes enclosed different QoS performance 754 characteristics. The issue is how to compare these routes? 756 This problem could be caused by a mis-configuration or because 757 provider does not support some QoS parameters. This risk in both 758 cases is that providers will not advertise QoS-related information 759 since if only one AS in the chain does not implement a QoS parameter 760 it will introduce a "QoS hole" in all routes that it will advertise 761 and then impact the announcement of this route for downstream ASes. 763 In order to solve this issue, two solutions could be considered: 765 o Solution 1: Add a new control level in the definition of l-QC. 766 This consists in defining mandatory and optional attributes. A 767 ôMandatory QoS informationö is a parameter that must be present 768 in the QoS_NLRI. In the case it is missing the announcement will 769 be dropped by q-BGP receiver. The announcement is not dropped if 770 an ôOptional QoS Informationö is missing. Nevertheless, the 771 problem of ensuring route selection consistency when optional 772 parameters are missing is unsolved. For solving this case, one 773 of options details under Solution 2 bullet could be implemented. 774 It is clear that all providers should have the same 775 understanding of the mandatory and the optional parameters in 776 order to preserve a consistent and coherent treatment in crossed 777 ASes. 779 o Solution 2: No additional control level is introduced in the 780 local QoS Class definition (all parameters are optional). In 781 this second solution, the risk is that service providers wonÆt 782 advertise routes with required QoS information that should be 783 used as guidance to meet service needs. As a consequence, group- 784 2 solutions become as group-1 ones because there is no control 785 regarding the enclosed QoS information. When a QoS parameter is 786 missing, two options could be considered. 788 o Option 1: Discard unvalued routes but keep them all if they 789 are all unvalued. In this case, the priority criterion is 790 respected and the comparison between routes is consistent. 791 But, the risk is that some destinations could be unreachable 792 if received routes do not enclose higher priority QoS 793 performance characteristics. 795 o Option 2: Always keep routes with unvalued parameter, but 796 perform selection for the remaining routes. The route 797 selection process compares between routes that have valued 798 the QoS parameter used as criterion in a given step. If there 799 still have equal routes, all routes are considered and the 800 route selection process checks for the route that encloses 801 the next QoS parameter to be used as criterion of its 802 selection even if these routes were not present in the 803 previous step. The inconvenient of this option is that the 804 priority criterion is not satisfied. 806 As a consequence, the updated pseudo code of the route selection 807 process is as follows: 809 ===================================================================== 811 1. Identify routes that serve the same destination 813 2. Group routes having the same QoS class identifier 815 3. For each route group, 817 i. If the number of remaining routes is not null, check for 818 each route, if all mandatory QoS performance 819 characteristics are valued 821 i. If yes, add this route to remaining routes 823 ii. If no, drop this route 825 4. Consider the remaining routes 827 i. If the number of remaining routes is not null, 829 1. Consider the QoS performance characteristic that has 830 the highest priority, and return the routes that 831 optimise that QoS performance characteristic 832 a. If only one route is returned store this route in 833 the local RIB 835 b. If more than one route is returned 837 o Exclude the QoS performance characteristic that 838 has been used in the step 4.i.1 from the list of 839 QoS performance characteristics. 841 1. If there is no remaining QoS performance 842 characteristics, go to step 5 844 2. Else, go to step 4.i.1 846 ii. If the number of remaining routes is null, go to 847 step 5 849 6. if more than one route has been returned, apply the classical 850 BGP route selection process 852 ===================================================================== 854 7. Security Considerations 856 This document does not change the underlying security issues in the 857 BGP protocols specifications. The security recommendations related to 858 BGP should be considered [BGPSEC]. 860 8. References 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997 865 [Walton] Walton, D., et al., "Advertisement of Multiple Paths in 866 BGP", draft-walton-bgp-add-paths-01.txt, Work in Progress, 867 November 2002 869 [QOSNLRI] Cristallo, G., Jacquenet, C, " Providing Quality of Service 870 Indication by the BGP-4 Protocol: the QOS_NLRI attribute", , work in progress 873 [DS] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of 874 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 875 Headers", RFC 2474, December 1998 877 [BGP]Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 878 1771, March 1995 880 [BGPSEC] Heffernan, A., "Protection of BGP sessions via the TCP MD5 881 Signature Option", RFC 2385, August 1998. 883 [CAP]Chandra, R., Scudder, J., Capabilities Advertisement with BGP-4, 884 RFC 3392 November 2002 886 [IAB]Atkinson, R., Floyd, S., "IAB Concerns & Recommendations 887 Regarding Internet Research & Evolution", RFC 3869, August 2004 889 9. Acknowledgments 891 The authors would also like to thank all the partners of the MESCAL 892 (Management of End-to-End Quality of Service Across the Internet At 893 Large, http://www.mescal.org) project for the fruitful discussions. 895 10. Contributors 897 o Pierrick Morand (France Telecom) 899 o Pierre Levis (France Telecom) 901 o Thibaut Coadic (France Telecom) 903 o Hamid Asgari (Thales Research and Technology) 905 o Panagiotis Georgatsos (Algonet) 907 o David Griffin (University College London) 909 o Jason Spencer (University College London) 911 o Micheal Howarth (University of Surrey) 913 11. Author's Address 915 Mohamed Boucadair 916 France Telecom R & D 917 42, rue des Coutures 918 BP 6243 919 14066 Caen Cedex 4 920 France 922 Email: mohamed.boucadair@francetelecom.com 924 Intellectual Property Statement 925 The IETF takes no position regarding the validity or scope of any 926 Intellectual Property Rights or other rights that might be claimed to 927 pertain to the implementation or use of the technology described in 928 this document or the extent to which any license under such rights 929 might or might not be available; nor does it represent that it has 930 made any independent effort to identify any such rights. Information 931 on the procedures with respect to rights in RFC documents can be 932 found in BCP 78 and BCP 79. 934 Copies of IPR disclosures made to the IETF Secretariat and any 935 assurances of licenses to be made available, or the result of an 936 attempt made to obtain a general license or permission for the use of 937 such proprietary rights by implementers or users of this 938 specification can be obtained from the IETF on-line IPR repository at 939 http://www.ietf.org/ipr. 941 The IETF invites any interested party to bring to its attention any 942 copyrights, patents or patent applications, or other proprietary 943 rights that may cover technology that may be required to implement 944 this standard. Please address the information to the IETF at 945 ietf-ipr@ietf.org. 947 Disclaimer of Validity 949 This document and the information contained herein are provided on an 950 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 951 REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 952 INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 953 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 954 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 955 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 957 Copyright Statement 959 Copyright (C) The Internet Society (2005). This document is subject 960 to the rights, licenses and restrictions contained in BCP 78, and 961 except as set forth therein, the authors retain all their rights.