idnits 2.17.1 draft-jacquenet-qos-nlri-01.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 209 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 255 has weird spacing: '... common sub...' -- 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 (November 2000) is 8562 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 327 looks like a reference -- Missing reference section? '2' on line 330 looks like a reference -- Missing reference section? '3' on line 333 looks like a reference -- Missing reference section? '4' on line 372 looks like a reference -- Missing reference section? '5' on line 342 looks like a reference -- Missing reference section? '6' on line 346 looks like a reference -- Missing reference section? '7' on line 349 looks like a reference -- Missing reference section? '8' on line 353 looks like a reference -- Missing reference section? '9' on line 356 looks like a reference -- Missing reference section? '10' on line 359 looks like a reference -- Missing reference section? '11' on line 362 looks like a reference -- Missing reference section? '12' on line 365 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jacquenet 3 Internet Draft France Telecom R&D 4 Document: draft-jacquenet-qos-nlri-01.txt November 2000 5 Category: Experimental 6 Expires: May 2001 8 Providing Quality of Service Indication by the BGP-4 Protocol: the 9 QOS_NLRI attribute 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft specifies an additional BGP4 (Border Gateway Protocol, 34 version 4, [2]) attribute, named the "QOS_NLRI" attribute, which aims 35 at providing QoS (Quality of Service)-related information associated 36 to the NLRI information conveyed in a BGP UPDATE message. 38 1. Introduction 40 Providing end-to-end quality of service is probably one of the most 41 important challenges of the Internet, not only because of the massive 42 development of value-added IP service offerings, but also because of 43 the various QoS policies that are currently deployed and enforced 44 within an autonomous system, and which may well differ from one AS 45 (Autonomous System) to another. 47 For almost the last decade, value-added IP service offerings have 48 been deployed over the Internet, thus yielding a dramatic development 49 of the specification effort, as far as quality of service in IP 50 networks is concerned. Nevertheless, providing end-to-end quality of 51 service by crossing administrative domains still remains an issue, 52 mainly because: 54 - QoS policies may dramatically differ from one service provider to 55 another, 56 - The enforcement of a specific QoS policy may also differ from one 57 domain to another, although the definition of a set of basic and 58 common quality of service indicators may be shared between the 59 service providers. 61 Activate the BGP4 protocol for exchanging reachability information 62 between autonomous systems has been a must for many years, and, from 63 this standpoint, the BGP4 protocol is one of the key components for 64 the enforcement of end-to-end QoS policies. 66 Therefore, exchanging QoS-related information as well as reachability 67 information in a given BGP UPDATE message appears to be helpful in 68 enforcing an end-to-end QoS policy. 70 This draft aims at specifying a new BGP4 attribute, the QOS_NLRI 71 attribute, that will convey QoS-related information associated to 72 the routes described in the corresponding NLRI (Network Layer 73 Reachability Information) field of a BGP UPDATE message. 75 This document is organized into the following sections: 77 - Section 3 identifies the changes that have been made in the 78 document since the last version, 79 - Section 4 describes the attribute and its mode of operation, 80 - Section 5 elaborates on the use of the capabilities advertisement 81 feature of the BGP4 protocol, 82 - Finally, sections 6 and 7 introduce IANA and some security 83 considerations, respectively. 85 2. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [3]. 91 3. Changes since the last version of this draft 93 The current version of this draft reflects the following changes: 95 - Re-wording of the Abstract section (summarized), 97 - Re-wording of the Introduction section (section 1), 99 - Insertion of the information in the QOS_NLRI attribute 100 (section 4), 102 - Insertion of an acknowledgements section (section , 104 - Revision of the 106 - Correction of remaining typos. 108 4. The QOS_NLRI attribute (Type Code XY*) 110 (*): "XY" is subject to the IANA considerations section of this 111 draft. 113 This is an optional transitive attribute that can be used for the 114 following purposes: 116 (a) To advertise a QoS route to a peer. A QoS route is a route that 117 meets one or a set of QoS requirement(s) to reach a given (set 118 of) destination prefixes (see [4], for example). Such QoS 119 requirements can be expressed in terms of minimum transit delay 120 to reach a destination, maximum available bandwidth along the 121 path to reach a destination, and/or the identification of the 122 traffic that is expected to use this specific route 123 (identification means for such traffic include DSCP (DiffServ 124 Code Point, [5]) marking). These QoS requirements can be used as 125 an input for the route calculation process embedded in the BGP 126 peers, e.g. thanks to the activation of a signaling protocol, 127 such as RSVP (Resource ReSerVation Protocol, [6]), 129 (b) To provide QoS information along with the NLRI information in a 130 single BGP UPDATE message. It is assumed that this QoS 131 information will be related to the route (or set of routes) 132 described in the NLRI field of the BGP UPDATE message. 134 This draft makes no specific assumption about the means to actually 135 value this attribute, since this is mostly a matter of 136 implementation, but the reader is kindly suggested to have a look on 137 the [7], as an example of a means to feed the BGP peer with the 138 appropriate information. 140 The QOS_NLRI attribute is encoded as follows: 142 +---------------------------------------------------------+ 143 | QoS Information Code (1 octet) | 144 +---------------------------------------------------------+ 145 | QoS Information Sub-code (1 octet) | 146 +---------------------------------------------------------+ 147 | QoS Information Value (2 octets) | 148 +---------------------------------------------------------+ 149 | QoS Information Origin (1 octet) | 150 +---------------------------------------------------------+ 151 | Address Family Identifier (2 octets) | 152 +---------------------------------------------------------+ 153 | Subsequent Address Family Identifier (1 octet) | 154 +---------------------------------------------------------+ 155 | Network Address of Next Hop (1 octet) | 156 +---------------------------------------------------------+ 157 | Network Layer Reachability Information (variable) | 158 +---------------------------------------------------------+ 160 The use and meaning of the fields of the QOS_NLRI attribute are 161 defined as follows: 163 - QoS Information Code: 165 This field carries the type of the QOS information. The following 166 types have been identified so far: 168 (0) Reserved 169 (1) Bandwidth 170 (2) Delay 171 (3) Jitter 172 (4) DSCP 174 - QoS Information Sub-code: 176 This field carries the sub-type of the QOS information. The 177 following sub-types have been identified so far: 179 (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub- 180 type) 181 (1) Reserved bandwidth 182 (2) Available bandwidth 183 (3) Minimum transit delay 184 (4) Maximum transit delay 185 (5) Average transit delay 186 (6) AF (Assured Forwarding, [8]) type 188 The instantiation of this sub-code field MUST be compatible with the 189 value conveyed in the QoS Information code field, as stated in the 190 following table (the rows represent the QoS Information Code possible 191 values, the columns represent the QOS Information Sub-code values 192 identified so far, while the "X" sign indicates incompatibility). 194 +---------------------------------------+ 195 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 196 +---------------------------------------+ 197 | 0 | | | | | | | | 198 +---------------------------------------+ 199 | 1 | | | | X | X | X | X | 200 +---------------------------------------+ 201 | 2 | | X | X | | | | X | 202 +---------------------------------------+ 203 | 3 | | X | X | X | X | X | X | 204 +---------------------------------------+ 205 | 4 | | X | X | X | X | X | | 206 +---------------------------------------+ 208 - QoS Information value: 210 This field indicates the value of the QoS information. The 211 corresponding units obviously depend on the instantiation of the 212 QoS Information Code. Namely, if: 214 (a) QoS Information Code field is "0", no unit specified, 215 (b) QoS Information Code field is "1", unit is bits per second (bps), 216 (c) QoS Information Code field is "2", unit is milliseconds, 217 (d) QoS Information Code field is "3", unit is milliseconds, 218 (e) QoS Information Code field is "4", no unit specified. 220 - Address Family Identifier (AFI): 222 This field carries the identity of the Network Layer protocol 223 associated with the Network Address that follows. Presently defined 224 values for this field are specified in [9] (see the Address Family 225 Numbers section of this reference document). 227 - Subsequent Address Family Identifier (SAFI): 229 This field provides additional information about the type of the 230 Network Layer Reachability Information carried in the QOS_NLRI 231 attribute. 233 - Network Address of Next Hop: 235 A variable length field that contains the Network Address of the 236 next router on the path to the destination prefix. 238 - Network Layer Reachability Information: 240 A variable length field that lists NLRI for the feasible routes 241 that are being advertised in this attribute. The next hop 242 information carried in the QOS_NLRI path attribute defines the 243 Network Layer address of the border router that should be used as 244 the next hop to the destinations listed in the QOS_NLRI attribute 245 in the UPDATE message. 247 When advertising a QOS_NLRI attribute to an external peer, a router 248 may use one of its own interface addresses in the next hop component 249 of the attribute, given the external peer to which the route is being 250 advertised shares a common subnet with the next hop address. This is 251 known as a "first party" next hop. 253 A BGP speaker can advertise to an external peer an interface of any 254 internal peer router in the next hop component, provided the external 255 peer to which the route is being advertised shares a common subnet 256 with the next hop address. This is known as a "third party" next hop 257 information. 259 A BGP speaker can advertise any external peer router in the next hop 260 component, provided that the Network Layer address of this border 261 router was learned from an external peer, and the external peer to 262 which the route is being advertised shares a common subnet with the 263 next hop address. This is a second form of "third party" next hop 264 information. 266 Normally the next hop information is chosen such that the shortest 267 available path will be taken. A BGP speaker must be able to support 268 disabling advertisement of third party next hop information to handle 269 imperfectly bridged media or for reasons of policy. 271 A BGP speaker must never advertise an address of a peer to that peer 272 as a next hop, for a route that the speaker is originating. A BGP 273 speaker must never install a route with itself as the next hop. 275 When a BGP speaker advertises the route to an internal peer, the 276 advertising speaker should not modify the next hop information 277 associated with the route. When a BGP speaker receives the route via 278 an internal link, it may forward packets to the next hop address if 279 the address contained in the attribute is on a common subnet with the 280 local and remote BGP speakers. 282 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 283 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 284 exchanges). Moreover, in IBGP exchanges such a message MUST also 285 carry the LOCAL_PREF attribute. If such a message is received from an 286 external peer, the local system shall check whether the leftmost AS 287 in the AS_PATH attribute is equal to the autonomous system number of 288 the peer than sent the message. If that is not the case, the local 289 system shall send the NOTIFICATION message with Error Code UPDATE 290 Message Error, and the Error Subcode set to Malformed AS_PATH. 292 An UPDATE message that carries no NLRI, other than the one encoded in 293 the QOS_NLRI attribute, should not carry the NEXT_HOP attribute. If 294 such a message contains the NEXT_HOP attribute, the BGP speaker that 295 receives the message should ignore this attribute. 297 5. Use of Capabilities Advertisement with BGP-4 299 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 300 Capabilities Advertisement procedures, as defined in [10], so that it 301 might be able to determine if it can use such an attribute with a 302 particular peer. 304 The fields in the Capabilities Optional Parameter are defined as 305 follows: 307 - The Capability Code field is set to N (127 < N < 256, when 308 considering the "Private Use" range, as specified in [11]), while 309 the Capability Length field is set to "1". 311 - The Capability Value field is a one-octet field, encoded the same 312 way as the QOS Information Code field of the QOS_NLRI attribute. 314 6. IANA Considerations 316 Section 5 of this draft documents an optional transitive BGP-4 317 attribute named "QOS_NLRI" whose type value will be assigned by IANA. 319 7. Security Considerations 321 This additional BGP-4 attribute specification does not change the 322 underlying security issues inherent in the existing BGP-4 protocol 323 specification [12]. 325 8. References 327 [1] Bradner, S.,"The Internet Standards Process -- Revision 3", BCP 328 9, RFC 2026, October 1996. 330 [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 331 1771, March 1995. 333 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 334 Levels", BCP 14, RFC 2119, March 1997. 336 [4] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., 337 Egan R., Griffin D., Georgatsos P., Georgiadis L., 338 "Specification of a Service Level Specification (SLS) Template", 339 draft-tequila-sls-00.txt, Work in Progress, November 2000. Check 340 http://www.ist-tequila.org for additional information. 342 [5] Nichols K., Blake S., Baker F., Black D., "Definition of the 343 Differentiated Services Field (DS Field) in the IPv4 and IPv6 344 Headers", RFC 2474, December 1998. 346 [6] Braden R. et al., "Resource ReSerVation Protocol (RSVP)- Version 347 1 Functional Specification", RFC 2205, September 1997. 349 [7] Jacquenet C., "A COPS client-type for IP traffic engineering", 350 draft-jacquenet-ip-te-cops-00.txt, Work in Progress, November 351 2000. 353 [8] Heinanen J. et al., " Assured Forwarding PHB Group", RFC 2597, 354 June 1999. 356 [9] Reynolds J., Postel J., "ASSIGNED NUMBERS", RFC 1700, October 357 1994. 359 [10] R. Chandra, J. Scudder, "Capabilities Advertisement with 360 BGP-4", RFC 2842, May 2000. 362 [11] Narten T., Alvestrand H., "Guidelines for Writing an IANA 363 Considerations Section in RFCs", RFC 2434, October 1998. 365 [12] Heffernan A., "Protection of BGP sessions via the TCP MD5 366 Signature Option", RFC 2385, August 1998. 368 9. Acknowledgments 370 Part of this work is funded by the European Commission, within the 371 context of the TEQUILA (Traffic Engineering for Quality of Service in 372 the Internet At Large Scale, [4]) project, which is itself part of 373 the IST (Information Society Technologies) research program. 375 The author would also like to thank all the partners of the TEQUILA 376 project for the fruitful discussions that have been conducted within 377 the context of the traffic engineering specification effort of the 378 project. 380 10. Author's Addresses 382 Christian Jacquenet 383 France Telecom R & D 384 DMI/SIR 385 42, rue des Coutures 386 BP 6243 387 14066 CAEN Cedex 04 388 France 389 Phone: +33 2 31 75 94 28 390 Email: christian.jacquenet@francetelecom.fr 392 11. Full Copyright Statement 394 Copyright(C) The Internet Society (2000). All Rights Reserved. 396 This document and translations of it may be copied and furnished to 397 others, and derivative works that comment on or otherwise explain it 398 or assist its implementation may be prepared, copied, published and 399 distributed, in whole or in part, without restriction of any kind, 400 provided that the above copyright notice and this paragraph are 401 included on all such copies and derivative works. However, this 402 document itself may not be modified in any way, such as by removing 403 the copyright notice or references to the Internet Society or other 404 Internet organizations, except as needed for the purpose of 405 developing Internet standards in which case the procedures for 406 copyrights defined in the Internet Standards process must be 407 followed, or as required to translate it into languages other than 408 English. 410 The limited permissions granted above are perpetual and will not be 411 revoked by the Internet Society or its successors or assigns. 413 This document and the information contained herein is provided on an 414 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 415 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 416 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 417 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 418 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.