idnits 2.17.1 draft-jacquenet-qos-nlri-00.txt: ** The Abstract section seems to be numbered 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 an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. 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: ' an IANA Considerations Section in RFCs", RFC 2434,' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC-2205], [RFC-1771], [RFC-2385], [RFC-2475], [RFC-2597], [RFC-2026], [RFC-2842], [RFC-2119], [RFC-2434]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC-2026' on line 288 looks like a reference -- Missing reference section? 'RFC-2119' on line 290 looks like a reference -- Missing reference section? 'RFC-2475' on line 300 looks like a reference -- Missing reference section? 'RFC-2205' on line 292 looks like a reference -- Missing reference section? 'RFC-2597' on line 302 looks like a reference -- Missing reference section? 'RFC-2842' on line 304 looks like a reference -- Missing reference section? 'RFC-2434' on line 297 looks like a reference -- Missing reference section? 'RFC-2385' on line 295 looks like a reference -- Missing reference section? 'RFC-1771' on line 286 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Jacquenet 2 INTERNET-DRAFT France Telecom R & D 3 Document: draft-jacquenet-qos-nlri-00.txt 4 Category: informational 5 Expires: January 2001 7 Providing Quality of Service Indication by the BGP-4 Protocol: the 8 QOS_NLRI attribute 9 11 1. Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 For almost the last decade, value-added IP service offerings have 35 been massively deployed over the Internet, thus yielding a dramatic 36 development of the specification effort, as far as quality of 37 service (QOS) in IP networks is concerned. Nevertheless, providing 38 end-to-end quality of service by crossing administrative domains 39 still remains an issue, mainly because: 41 - quality of service policies may dramatically differ from one 42 service provider to another; 43 - the enforcement of a specific quality of service policy may also 44 differ from one domain to another, although the definition of a set 45 of basic and common quality of service indicators may be shared 46 between the service providers. 48 As far as IP routing is concerned, the BGP-4 protocol (Border 49 Gateway Protocol, version 4,[RFC-1771]) has been systematically 50 activated between autonomous systems for the purpose of exchanging 51 routing information related to the reachability of IP destination 52 prefixes. From this standpoint, the BGP-4 protocol appears to be one 53 of the key components for the enforcement of a global quality of 54 service policy, by allowing BGP peers to indicate each other if (1) 55 they have the ability to announce QOS-related information when 56 transmitting UPDATE messages and (2) they have the ability to 57 process such a QOS-related information when conveyed in an UPDATE 58 message. 59 The purpose of this draft consists in proposing an additional BGP4 60 attribute, named the QOS_NLRI attribute, which aims at providing 61 QOS-related information related to the NLRI information conveyed in 62 a BGP UPDATE message. 64 3. Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 68 this document are to be interpreted as described in RFC 2119 ([RFC- 69 2119]). 71 4. Introduction 73 Providing end-to-end quality of service is probably one of the most 74 important challenges of the Internet, not only because of the 75 massive development of value-added IP service offerings, but also 76 because of the various QOS policies that are currently deployed and 77 enforced within an autonomous system, and which may well differ from 78 one AS to another. 80 Activate the BGP-4 protocol for exchanging reachability information 81 between autonomous systems has been a must for many years, and, from 82 this standpoint, the BGP-4 protocol appears to be a key component in 83 the deployment of end-to-end QOS policies. 85 Exchanging QOS-related information as well as reachability 86 information in a given BGP UPDATE message might be helpful in 87 enforcing an end-to-end QOS policy. 89 This draft aims at specifying a new BGP-4 attribute, the QOS_NLRI 90 attribute which will convey QOS-related information associated to 91 the (possibly withdrawn) routes described in the NLRI (Network Layer 92 Reachability Information) field of a BGP UPDATE message. 94 5. The QOS_NLRI attribute (Type Code XY*) 96 *: "XY" is subject to the IANA considerations section of this draft. 98 This is an optional transitive attribute which can be used for the 99 following purposes: 101 (a) to advertise a QOS route to a peer. A QOS route is a route which 102 meets one or a set of QOS requirements to reach a given (set of) 103 destination prefixes. Such QOS requirements can be expressed in 104 terms of minimum transit delay to reach a destination, maximum 105 available bandwidth along the path to reach a destination, the 106 identification of the traffic which is expected to use this specific 107 route (identification means for such traffic include DSCP (DiffServ 108 Code Point, [RFC-2475]) marking), etc., and they can be provided as 109 an input for the route calculation process embedded in the BGP peers 110 thanks to the activation of a signaling protocol, such as RSVP 111 (Resource ReSerVation Protocol, [RFC-2205]); 113 (b) to provide QOS information along with the NLRI information in a 114 single BGP UPDATE message. It is assumed that this QOS information 115 will be related to the route (or set of routes) described in the 116 NLRI field of the BGP UPDATE message. 117 The QOS_NLRI attribute is encoded as follows: 119 +---------------------------------------------------------+ 120 | QOS Information Code (1 octet) | 121 +---------------------------------------------------------+ 122 | QOS Information Sub-code (1 octet) | 123 +---------------------------------------------------------+ 124 | QOS Information Value (2 octets) | 125 +---------------------------------------------------------+ 126 | QOS Information Origin (1 octet) | 127 +---------------------------------------------------------+ 128 | Network Address of Next Hop (1 octet) | 129 +---------------------------------------------------------+ 130 | Network Layer Reachability Information (variable) | 131 +---------------------------------------------------------+ 133 The use and meaning of these fields are as follows: 135 - QOS Information Code: 137 This field carries the type of the QOS information. The following 138 types have been identified so far: 140 (0) Reserved 141 (1) Bandwidth 142 (2) Delay 143 (3) Jitter 144 (4) DSCP 146 - QOS Information Sub-code: 148 This field carries the sub-type of the QOS information. The 149 following sub-types have been identified so far: 151 (0) None (i.e. no sub-type, or sub-type unavailable, or unknown sub- 152 type) 153 (1) Reserved bandwidth 154 (2) Available bandwidth 155 (3) Minimum transit delay 156 (4) Maximum transit delay 157 (5) Average transit delay 158 (6) AF (Assured Forwarding, [RFC-2597]) type 160 The instantiation of this sub-code field MUST be compatible with the 161 value conveyed in the QOS Information code field, as stated in the 162 following table (the rows represent the QOS Information Code 163 possible values, the columns represent the QOS Information Sub-code 164 values identified so far, while the "X" sign indicates 165 incompatibility). 166 +----------------------------------------+ 167 | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 168 +---------------------------------------+ 169 | 0 | | | | | | | | 170 +---------------------------------------+ 171 | 1 | | | | X | X | X | X | 172 +---------------------------------------+ 173 | 2 | | X | X | | | | X | 174 +---------------------------------------+ 175 | 3 | | X | X | X | X | X | X | 176 +---------------------------------------+ 177 | 4 | | X | X | X | X | X | | 178 +---------------------------------------+ 180 - QOS Information value: 182 This field indicates the value of the QOS information. The 183 corresponding units obviously depend on the instantiation of the QOS 184 Information Code. Namely, if: 186 (a) QOS Information Code field is "0", no unit specified, 187 (b) QOS Information Code field is "1", unit is bits per second 188 (bps), 189 (c) QOS Information Code field is "2", unit is milliseconds, 190 (d) QOS Information Code field is "3", unit is milliseconds, 191 (e) QOS Information Code field is "4", no unit specified. 193 - Network Address of Next Hop: 195 A variable length field that contains the Network Address of the 196 next router on the path to the destination prefix. 198 - Network Layer Reachability Information: 200 A variable length field that lists NLRI for the feasible routes that 201 are being advertised in this attribute. 203 The next hop information carried in the QOS_NLRI path attribute 204 defines the Network Layer address of the border router that should 205 be used as the next hop to the destinations listed in the QOS_NLRI 206 attribute in the UPDATE message. When advertising a QOS_NLRI 207 attribute to an external peer, a router may use one of its own 208 interface addresses in the next hop component of the attribute, 209 provided the external peer to which the route is being advertised 210 shares a common subnet with the next hop address. This is known as 211 a "first party" next hop. 213 A BGP speaker can advertise to an external peer an interface of any 214 internal peer router in the next hop component, provided the 215 external peer to which the route is being advertised shares a common 216 subnet with the next hop address. This is known as a "third party" 217 next hop information. 219 A BGP speaker can advertise any external peer router in the next hop 220 component, provided that the Network Layer address of this border 221 router was learned from an external peer, and the external peer to 222 which the route is being advertised shares a common subnet with the 223 next hop address. This is a second form of "third party" next hop 224 information. 225 Normally the next hop information is chosen such that the shortest 226 available path will be taken. A BGP speaker must be able to support 227 disabling advertisement of third party next hop information to 228 handle imperfectly bridged media or for reasons of policy. 230 A BGP speaker must never advertise an address of a peer to that peer 231 as a next hop, for a route that the speaker is originating. A BGP 232 speaker must never install a route with itself as the next hop. 233 When a BGP speaker advertises the route to an internal peer, the 234 advertising speaker should not modify the next hop information 235 associated with the route. When a BGP speaker receives the route 236 via an internal link, it may forward packets to the next hop address 237 if the address contained in the attribute is on a common subnet with 238 the local and remote BGP speakers. 240 A BGP UPDATE message that carries the QOS_NLRI MUST also carry the 241 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 242 exchanges). Moreover, in IBGP exchanges such a message MUST also 243 carry the LOCAL_PREF attribute. If such a message is received from 244 an external peer, the local system shall check whether the leftmost 245 AS in the AS_PATH attribute is equal to the autonomous system number 246 of the peer than sent the message. If that is not the case, the 247 local system shall send the NOTIFICATION message with Error Code 248 UPDATE Message Error, and the Error Subcode set to Malformed 249 AS_PATH. 251 An UPDATE message that carries no NLRI, other than the one encoded 252 in the QOS_NLRI attribute, should not carry the NEXT_HOP attribute. 253 If such a message contains the NEXT_HOP attribute, the BGP speaker 254 that receives the message should ignore this attribute. 256 6. Use of Capabilities Advertisement with BGP-4 258 A BGP speaker that uses the QOS_NLRI attribute SHOULD use the 259 Capabilities Advertisement procedures, as defined in [RFC-2842], so 260 that it might be able to determine if it can use such an attribute 261 with a particular peer. 263 The fields in the Capabilities Optional Parameter are defined as 264 follows: 266 - The Capability Code field is set to N (127 < N < 256, when 267 considering the "Private Use" range, as specified in [RFC-2434]), 268 while the Capability Length field is set to "1". 270 - The Capability Value field is a one-octet field, encoded the same 271 way as the QOS Information Code field of the QOS_NLRI attribute. 273 7. IANA Considerations 275 Section 5 of this draft documents an optional transitive BGP-4 276 attribute named "QOS_NLRI" whose type value will be assigned by 277 IANA. To be completed. 279 8. Security considerations 281 This additional BGP-4 attribute specification does not change the 282 underlying security issues inherent in the existing BGP-4 protocol 283 specification [RFC-2385]. 284 9. References 286 [RFC-1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 287 (BGP-4)", RFC 1771, March 1995. 288 [RFC-2026] Bradner, S., "The Internet Standards Process -- 289 Revision 3", BCP 9, RFC 2026, October 1996. 290 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997 292 [RFC-2205] R. braden et al., "Resource ReSerVation Protocol 293 (RSVP) - Version 1 Functional Specification", RFC 294 2205, September 1997. 295 [RFC-2385] A. Heffernan, "Protection of BGP sessions via the 296 TCP MD5 Signature Option", RFC 2385, August 1998. 297 [RFC-2434] T. Narten, H. Alvestrand, "Guidelines for Writing 298 an IANA Considerations Section in RFCs", RFC 2434, 299 October 1998. 300 [RFC-2475] S. Blake et al., "An Architecture for 301 Differentiated Services", RFC 2475, December 1998. 302 [RFC-2597] J. Heinanen et al., " Assured Forwarding PHB 303 Group", RFC 2597, June 1999. 304 [RFC-2842] R. Chandra, J. Scudder, "Capabilities Advertisement 305 with BGP-4", RFC 2842, May 2000. 307 10. Author's address 309 Christian Jacquenet 310 France Telecom R & D 311 42, rue des Coutures 312 BP 6243 313 14066 Caen cedex 04 314 France 315 Phone : + 33 2 31 75 94 28 316 Fax : + 33 2 31 73 56 26 317 Email : christian.jacquenet@francetelecom.fr 319 11. Full copyright statement 321 Copyright (C) The Internet Society (2000). All Rights Reserved. 323 This document and translations of it may be copied and furnished to 324 others, and derivative works that comment on or otherwise explain it 325 or assist its implementation may be prepared, copied, published and 326 distributed, in whole or in part, without restriction of any kind, 327 provided that the above copyright notice and this paragraph are 328 included on all such copies and derivative works. However, this 329 document itself may not be modified in any way, such as by removing 330 the copyright notice or references to the Internet Society or other 331 Internet organizations, except as needed for the purpose of 332 developing Internet standards in which case the procedures for 333 copyrights defined in the Internet Standards process must be 334 followed, or as required to translate it into languages other than 335 English. 337 The limited permissions granted above are perpetual and will not be 338 revoked by the Internet Society or its successors or assigns. 340 This document and the information contained herein is provided on an 341 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 342 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 343 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 344 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 345 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.