idnits 2.17.1 draft-jacquenet-qos-nlri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1771 (ref. '2') (Obsoleted by RFC 4271) == Outdated reference: A later version (-03) exists of draft-tequila-sls-00 ** Obsolete normative reference: RFC 2679 (ref. '5') (Obsoleted by RFC 7679) == Outdated reference: A later version (-09) exists of draft-ietf-ippm-ipdv-06 == Outdated reference: A later version (-04) exists of draft-jacquenet-ip-te-cops-00 -- No information found for draft-ietf-diffserv-2839bis - is the name correct? ** Obsolete normative reference: RFC 1700 (ref. '12') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2842 (ref. '13') (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2434 (ref. '14') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2385 (ref. '15') (Obsoleted by RFC 5925) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 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-02.txt February 2001 5 Category: Experimental 6 Expires: August 2001 8 Providing Quality of Service Indication by the BGP-4 Protocol: the 9 QOS_NLRI attribute 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This draft specifies an additional BGP4 (Border Gateway Protocol, 34 version 4, [2]) attribute, named the "QOS_NLRI" attribute, which aims 35 at providing QoS (Quality of Service)-related information associated 36 to the NLRI (Network Layer Reachability Information) information 37 conveyed in a BGP UPDATE message. 39 1. Introduction 41 Providing end-to-end quality of service is probably one of the most 42 important challenges of the Internet, not only because of the massive 43 development of value-added IP service offerings, but also because of 44 the various QoS policies that are currently deployed and enforced 45 within an autonomous system, and which may well differ from one AS 46 (Autonomous System) to another. 48 For almost the last decade, value-added IP service offerings have 49 been deployed over the Internet, thus yielding a dramatic development 50 of the specification effort, as far as quality of service in IP 51 networks is concerned. Nevertheless, providing end-to-end quality of 52 service by crossing administrative domains still remains an issue, 53 mainly because: 55 - QoS policies may dramatically differ from one service provider to 56 another, 57 - The enforcement of a specific QoS policy may also differ from one 58 domain to another, although the definition of a set of basic and 59 common quality of service indicators may be shared between the 60 service providers. 62 Activate the BGP4 protocol for exchanging reachability information 63 between autonomous systems has been a must for many years, and, from 64 this standpoint, the BGP4 protocol is one of the key components for 65 the enforcement of end-to-end QoS policies. 67 Therefore, exchanging QoS-related information as well as reachability 68 information in a given BGP UPDATE message appears to be helpful in 69 enforcing an end-to-end QoS policy. 71 This draft aims at specifying a new BGP4 attribute, the QOS_NLRI 72 attribute, that will convey QoS-related information associated to 73 the routes described in the corresponding NLRI field of the 74 attribute. 76 This document is organized into the following sections: 78 - Section 3 identifies the changes that have been made in the 79 document since the last version, 80 - Section 4 describes the attribute and its mode of operation, 81 - Section 5 elaborates on the use of the capabilities advertisement 82 feature of the BGP4 protocol, 83 - Finally, sections 6 and 7 introduce IANA and some security 84 considerations, respectively. 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC-2119 [3]. 92 3. Changes since the last version of this draft 94 The current version of this draft reflects the following changes: 96 - Slight re-wording of the Introduction section (section 1), 98 - Development of Section 4 (introduction of new QoS metrics, as well 99 as elaboration on the rate encoding scheme), 101 - Correction of remaining typos. 103 4. The QOS_NLRI attribute (Type Code XY*) 105 (*): "XY" is subject to the IANA considerations section of this 106 draft. 108 The QOS_NLRI attribute is an optional transitive attribute that can 109 be used for the following purposes: 111 (a) To advertise a QoS route to a peer. A QoS route is a route that 112 meets one or a set of QoS requirement(s) to reach a given (set 113 of) destination prefixes (see [4], for example). Such QoS 114 requirements can be expressed in terms of minimum one-way delay 115 ([5]) to reach a destination, the experienced delay variation for 116 IP datagrams that are destined to a given destination prefix 117 ([6]), the loss rate experienced along the path to reach a 118 destination, and/or the identification of the traffic that is 119 expected to use this specific route (identification means for 120 such traffic include DSCP (DiffServ Code Point, [7]) marking). 121 These QoS requirements can be used as an input for the route 122 calculation process embedded in the BGP peers, e.g. thanks to the 123 activation of a signaling protocol, such as RSVP (Resource 124 ReSerVation Protocol, [8]), 126 (b) To provide QoS information along with the NLRI information in a 127 single BGP UPDATE message. It is assumed that this QoS 128 information will be related to the route (or set of routes) 129 described in the NLRI field of the attribute. 131 This draft makes no specific assumption about the means to actually 132 value this attribute, since this is mostly a matter of 133 implementation, but the reader is kindly suggested to have a look on 134 document [9], as an example of a means to feed the BGP peer with the 135 appropriate information. 137 The QOS_NLRI attribute is encoded as follows: 139 +---------------------------------------------------------+ 140 | QoS Information Code (1 octet) | 141 +---------------------------------------------------------+ 142 | QoS Information Sub-code (1 octet) | 143 +---------------------------------------------------------+ 144 | QoS Information Value (2 octets) | 145 +---------------------------------------------------------+ 146 | QoS Information Origin (1 octet) | 147 +---------------------------------------------------------+ 148 | Address Family Identifier (2 octets) | 149 +---------------------------------------------------------+ 150 | Subsequent Address Family Identifier (1 octet) | 151 +---------------------------------------------------------+ 152 | Network Address of Next Hop (4 octets) | 153 +---------------------------------------------------------+ 154 | Network Layer Reachability Information (variable) | 155 +---------------------------------------------------------+ 157 The use and meaning of the fields of the QOS_NLRI attribute are 158 defined as follows: 160 - QoS Information Code: 162 This field carries the type of the QOS information. The following 163 types have been identified so far: 165 (0) Reserved 166 (1) Packet rate, i.e. the number of IP datagrams that can be 167 transmitted (or have been lost) per unit of time, this number 168 being characterized by the elaboration provided in the QoS 169 Information Sub-code (see below), 170 (2) One-way delay, as defined in [5] 171 (3) Inter-packet delay variation, as defined in [6] 172 (4) PHB Identifier, as defined in [10] 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 rate 182 (2) Available rate 183 (3) Loss rate 184 (4) Minimum one-way delay 185 (5) Maximum one-way delay 186 (6) Average one-way delay 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). 193 +---------------------------------------+ 194 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 195 +---------------------------------------+ 196 | 0 | | | | | | | | 197 +---------------------------------------+ 198 | 1 | | | | | X | X | X | 199 +---------------------------------------+ 200 | 2 | | X | X | X | | | | 201 +---------------------------------------+ 202 | 3 | | X | X | X | X | X | X | 203 +---------------------------------------+ 204 | 4 | | X | X | X | X | X | X | 205 +---------------------------------------+ 207 - QoS Information Value: 209 This field indicates the value of the QoS information. The 210 corresponding units obviously depend on the instantiation of the 211 QoS Information Code. Namely, if: 213 (a) QoS Information Code field is "0", no unit specified, 214 (b) QoS Information Code field is "1", unit is kbits per second 215 (kbps), and the rate encoding rule is composed of a 3-bit 216 exponent (with an assumed base of 8) followed by a 13-bit 217 mantissa, as depicted in the figure below: 219 0 8 16 220 | | | 221 ----------------- 222 |Exp| Mantissa | 223 ----------------- 225 This encoding scheme advertises a numeric value that is 2^16 -1 - 226 (exponential encoding of the considered rate), as depicted in 227 [11]. 228 (c) QoS Information Code field is "2", unit is milliseconds, 229 (d) QoS Information Code field is "3", unit is milliseconds, 230 (e) QoS Information Code field is "4", no unit specified. 232 - QoS Information Origin: 234 This field provides indication on the origin of the path 235 information, as defined in section 4.3. of [2]. 237 - Address Family Identifier (AFI): 239 This field carries the identity of the Network Layer protocol 240 associated with the Network Address that follows. Presently defined 241 values for this field are specified in [12] (see the Address Family 242 Numbers section of this reference document). 244 - Subsequent Address Family Identifier (SAFI): 246 This field provides additional information about the type of the 247 Network Layer Reachability Information carried in the QOS_NLRI 248 attribute. 250 - Network Address of Next Hop: 252 This field contains the IPv4 Network Address of the next router on 253 the path to the destination prefix, (reasonably) assuming that such 254 routers can at least be addressed according to the IPv4 formalism. 256 - Network Layer Reachability Information: 258 This variable length field lists the NLRI information for the 259 feasible routes that are being advertised by this attribute. The 260 next hop information carried in the QOS_NLRI path attribute defines 261 the Network Layer address of the border router that should be used 262 as the next hop to the destinations listed in the QOS_NLRI 263 attribute in the UPDATE message. 265 When advertising a QOS_NLRI attribute to an external peer, a router 266 may use one of its own interface addresses in the next hop component 267 of the attribute, given the external peer to which the route is being 268 advertised shares a common subnet with the next hop address. This is 269 known as a "first party" next hop. 271 A BGP speaker can advertise to an external peer an interface of any 272 internal peer router in the next hop component, provided the external 273 peer to which the route is being advertised shares a common subnet 274 with the next hop address. This is known as a "third party" next hop 275 information. 277 A BGP speaker can advertise any external peer router in the next hop 278 component, provided that the Network Layer address of this border 279 router was learned from an external peer, and the external peer to 280 which the route is being advertised shares a common subnet with the 281 next hop address. This is a second form of "third party" next hop 282 information. 284 Normally the next hop information is chosen so that the shortest 285 available path will be taken. A BGP speaker must be able to support 286 disabling advertisement of third party next hop information to handle 287 imperfectly bridged media or for reasons of policy. 289 A BGP speaker must never advertise an address of a peer to that peer 290 as a next hop, for a route that the speaker is originating. A BGP 291 speaker must never install a route with itself as the next hop. 293 When a BGP speaker advertises the route to an internal peer, the 294 advertising speaker should not modify the next hop information 295 associated with the route. When a BGP speaker receives the route via 296 an internal link, it may forward packets to the next hop address if 297 the address contained in the attribute is on a common subnet with the 298 local and remote BGP speakers. 300 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 301 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 302 exchanges). Moreover, in IBGP exchanges such a message MUST also 303 carry the LOCAL_PREF attribute. If such a message is received from an 304 external peer, the local system shall check whether the leftmost AS 305 in the AS_PATH attribute is equal to the autonomous system number of 306 the peer than sent the message. If that is not the case, the local 307 system shall send the NOTIFICATION message with Error Code UPDATE 308 Message Error, and the Error Subcode set to Malformed AS_PATH. 310 An UPDATE message that carries no NLRI, other than the one encoded in 311 the QOS_NLRI attribute, should not carry the NEXT_HOP attribute. If 312 such a message contains the NEXT_HOP attribute, the BGP speaker that 313 receives the message should ignore this attribute. 315 5. Use of Capabilities Advertisement with BGP-4 317 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 318 Capabilities Advertisement procedures, as defined in [13], so that it 319 might be able to determine if it can use such an attribute with a 320 particular peer. 322 The fields in the Capabilities Optional Parameter are defined as 323 follows: 325 - The Capability Code field is set to N (127 < N < 256, when 326 considering the "Private Use" range, as specified in [14]), while 327 the Capability Length field is set to "1". 329 - The Capability Value field is a one-octet field, that contains the 330 Type Code of the QOS_NLRI attribute, as defined in the introduction 331 of section 4 of the present draft. 333 6. IANA Considerations 335 Section 4 of this draft documents an optional transitive BGP-4 336 attribute named "QOS_NLRI" whose type value will be assigned by IANA. 337 Section 5 of this draft also documents a Capability Code whose value 338 should be assigned by IANA. 340 7. Security Considerations 342 This additional BGP-4 attribute specification does not change the 343 underlying security issues inherent in the existing BGP-4 protocol 344 specification [15]. 346 8. References 348 [1] Bradner, S.,"The Internet Standards Process -- Revision 3", BCP 349 9, RFC 2026, October 1996. 351 [2] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 352 1771, March 1995. 354 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 355 Levels", BCP 14, RFC 2119, March 1997. 357 [4] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., 358 Egan R., Griffin D., Georgatsos P., Georgiadis L., 359 "Specification of a Service Level Specification (SLS) Template", 360 draft-tequila-sls-00.txt, Work in Progress, November 2000. Check 361 http://www.ist-tequila.org for additional information. 363 [5] Almes G., Kalidindi S., "A One-Way-Delay Metric for IPPM", RFC 364 2679, September 1999. 366 [6] Demichelis C., Chimento P., "IP Packet Delay Variation Metric 367 for IPPM", draft-ietf-ippm-ipdv-06.txt, Work in Progress, 368 February 2001. 370 [7] Nichols K., Blake S., Baker F., Black D., "Definition of the 371 Differentiated Services Field (DS Field) in the IPv4 and IPv6 372 Headers", RFC 2474, December 1998. 374 [8] Braden R. et al., "Resource ReSerVation Protocol (RSVP)- Version 375 1 Functional Specification", RFC 2205, September 1997. 377 [9] Jacquenet C., "A COPS client-type for IP traffic engineering", 378 draft-jacquenet-ip-te-cops-00.txt, Work in Progress, November 379 2000. 381 [10] Black D., Brim S., Carpenter B., Le Faucheur F., "Per Hop 382 Behavior Identification Codes", draft-ietf-diffserv-2839bis- 383 01.txt, Work in Progress, February 2001. 385 [11] Apostolopoulos G. et al, "QoS Routing Mechanisms and OSPF 386 Extensions", RFC 2676, August 1999. 388 [12] Reynolds J., Postel J., "ASSIGNED NUMBERS", RFC 1700, October 389 1994. 391 [13] R. Chandra, J. Scudder, "Capabilities Advertisement with BGP-4", 392 RFC 2842, May 2000. 394 [14] Narten T., Alvestrand H., "Guidelines for Writing an IANA 395 Considerations Section in RFCs", RFC 2434, October 1998. 397 [15] Heffernan A., "Protection of BGP sessions via the TCP MD5 398 Signature Option", RFC 2385, August 1998. 400 9. Acknowledgments 402 Part of this work is funded by the European Commission, within the 403 context of the TEQUILA (Traffic Engineering for Quality of Service in 404 the Internet At Large Scale, [4]) project, which is itself part of 405 the IST (Information Society Technologies) research program. 407 The author would also like to thank all the partners of the TEQUILA 408 project for the fruitful discussions that have been conducted within 409 the context of the traffic engineering specification effort of the 410 project, as well as O. Bonaventure and B. Carpenter for their 411 valuable input. 413 10. Author's Addresses 415 Christian Jacquenet 416 France Telecom R & D 417 DMI/SIR 418 42, rue des Coutures 419 BP 6243 420 14066 CAEN Cedex 04 421 France 422 Phone: +33 2 31 75 94 28 423 Email: christian.jacquenet@francetelecom.fr 425 11. Full Copyright Statement 427 Copyright(C) The Internet Society (2001). All Rights Reserved. 429 This document and translations of it may be copied and furnished to 430 others, and derivative works that comment on or otherwise explain it 431 or assist its implementation may be prepared, copied, published and 432 distributed, in whole or in part, without restriction of any kind, 433 provided that the above copyright notice and this paragraph are 434 included on all such copies and derivative works. However, this 435 document itself may not be modified in any way, such as by removing 436 the copyright notice or references to the Internet Society or other 437 Internet organizations, except as needed for the purpose of 438 developing Internet standards in which case the procedures for 439 copyrights defined in the Internet Standards process must be 440 followed, or as required to translate it into languages other than 441 English. 443 The limited permissions granted above are perpetual and will not be 444 revoked by the Internet Society or its successors or assigns. 446 This document and the information contained herein is provided on an 447 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 448 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 449 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 450 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 451 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.