idnits 2.17.1 draft-ietf-idr-sla-exchange-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The SLA content is optional for an advertised SLA id. The value of the SLA length field in such case would be 0. If SLA content does not exist in BGP update messages with advertised QoS attribute, that contains the SLA sub-type, then receiver MUST inherit prior advertised SLA content for the same SLA id from the same Source AS. If there does not exist any prior SLA to relate to the advertised SLA id, then receiver can ignore the SLA advertisement and continue with the rest of the BGP message processing and forwarding rules. Note that such condition MUST not discard the attribute. All defined forwarding rules for this attribute still MUST apply. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any traffic classifier element advertised in the QoS attribute is only applicable to the NLRI advertised for a given AFI/SAFI within the BGP update message. If a receiver receives a BGP update message with QoS/SLA attribute for an NLRI that is not supported by a receiver then receiver MUST not install an advertised SLA and continue to forward this attribute further if it is not the last receiver of an attribute. -- The document date (November 01, 2015) is 3100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-sidr-bgpsec-protocol' is mentioned on line 929, but not defined == Unused Reference: 'RFC7297' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'BGP-SEC' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'BGPSLA-IMPL' is defined on line 1001, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shah 3 Internet-Draft K. Patel 4 Intended status: Standards Track Cisco Systems 5 Expires: May 4, 2016 S. Bajaj 6 Juniper Networks 7 L. Tomotaki 8 Verizon 9 M. Boucadair 10 France Telecom 11 November 01, 2015 13 Inter-domain SLA Exchange 14 draft-ietf-idr-sla-exchange-06 16 Abstract 18 Network administrators typically enforce Quality of Service (QoS) 19 policies according to Service Level Agreement (SLA) with their 20 providers. The enforcement of such policies often relies upon 21 vendor-specific configuration language. Both learning of SLA, either 22 thru SLA documents or via some other out-of-band method, and 23 translating them to vendor specific configuration language is a 24 complex, many times manual, process and prone to errors. This 25 document proposes an in-band method of SLA signaling, which can help 26 to simplify some of the complexities, where BGP is available as the 27 routing protocol. 29 This document defines an optional transitive attribute to signal SLA 30 parameters in-band, across administrative boundaries (considered as 31 Autonomous Systems (AS)), thus simplifying and facilitating some of 32 the complex provisioning tasks. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 4, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4 70 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5 71 4. Originating SLA Notification . . . . . . . . . . . . . . . . 15 72 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16 74 4.1.2. SLA Advertisement for Destination AS Multiple Hops 75 Away . . . . . . . . . . . . . . . . . . . . . . . . 16 76 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 16 77 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 16 78 5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 17 79 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 18 81 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 87 12.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Typically there is a contractual Service Level Agreement (SLA) for 93 QoS established between a customer and a provider or between 94 providers. This QoS SLA defines the nature of the various traffic 95 classes and services needed within each traffic class. The contract 96 may include full line-rate or sub line-rate without additional 97 traffic classes, or it may contain additional traffic classes and 98 service definitions for those traffic classes. Finer granular 99 traffic classes may be based on some standard code points (like DSCP) 100 or specific set of prefixes. 102 Once the SLA is established, QoS SLA parameters are enforced in some 103 or all participating devices by deriving those parameters into 104 configuration information on respective devices. SLA parameters may 105 have to be exchanged through organizational boundaries, thru SLA 106 documents or via some other off-band method to an administrator 107 provisioning actual devices. In a subsequent step, administrator 108 requires to translate SLA to QoS policies using router (vendor) 109 specific provisioning language. In a multi-vendor network, 110 translating SLAs into technology-specific and vendor-specific 111 configuration requires to consider specificities of each vendor. 112 There does not exist any standard protocol to translate SLA 113 agreements into technical clauses and configurations and thus both 114 the steps of out of band learning of negotiated SLA and provisioning 115 them in a vendor specific language can be complex and error-prone. 116 As an example for voice service, the Provider may negotiate QoS 117 parameters (like min/max rates) for such traffic based upon the EF 118 code-point in Diffserv-enabled [RFC2475] networks. The Administrator 119 at the CE side not only will have to know that Provider's service for 120 voice traffic is EF-based but will also have to know how to implement 121 DSCP EF classification rule along with Low Latency Service, and 122 possibly min/max rate enforcement for the optimal use of bandwidth, 123 as per vendor specific provisioning language. 125 An in-band signaling method of propagating SLA parameters from the 126 provider, PE in an example above, to contractual devices, CE in an 127 example above, can help eliminate manual administrative process 128 described above. The provider may have SLA negotiated with the 129 Customer via some defined off-band method (based on the specifics 130 defined by the Provider or using protocols like [CPNP]). The Inter- 131 domain SLA exchange proposal described in this document does not pre- 132 requisite any specific method of establishing SLAs). The Provider 133 provisions established SLA on the Provider device. This SLA instance 134 then can be signaled to the Customer via in-band signaling protocol. 135 In reaction to this signal, receiver router may translate that to 136 relevant QoS policy definition on the device. 138 For an in-band signaling, we propose to use BGP as a transport. The 139 details of SLA parameters are specific to the granularity of traffic 140 classes and their respective treatment, which is independent of the 141 BGP protocol itself. Though we find BGP as a suitable transport for 142 inter-domain SLA exchange for the following reasons: 144 - The need to exchange SLA parameters between domains(Autonomous 145 Systems (AS)), where in use-cases described in this document, 146 BGP is a suitable protocol for inter-domain exchange [RFC4271] 147 [RFC4364]. 148 - There is no specifically defined protocol available today for 149 SLA exchange. 150 - BGP updates already advertise specific set of prefixes (flow 151 or flow-group). Other QoS-related attributes, apart from the 152 the use of SLA advertisement, can be added to these updates 153 in the future. 155 The proposal is to define a new BGP attribute to advertise/learn SLA 156 details in-band. The proposed attribute is intended to advertise SLA 157 from one AS to a list of destined ASes. The advertised QoS 158 information could be for the incoming traffic to the advertiser, that 159 is advertising SLA or could be for the outgoing traffic from the 160 advertiser or could be for both directions. Reception of and 161 reaction to advertised SLAs are optional for the receiver. 163 We propose QoS as an optional transitive attribute, keeping SLA 164 advertisement as one of the sub-types of QoS attribute. This is to 165 keep the QoS attribute open for extensions. For example, SLA 166 Negotiation and Assurance is out of scope of this document but can be 167 envisioned as another sub-type. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 3. QoS Attribute Definition 177 The QoS Attribute proposed here is an optional transitive attribute 178 (attribute type code to be assigned by IANA). SLA is defined as one 179 of the sub-types in the QoS attribute. The QoS attribute is only 180 applicable to the NLRI advertised in the BGP update message. 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Attr flag | Attr type QoS | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 187 ~ ~ 188 | QoS Attr length/Value | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 191 Attribute flags 192 highest order bit (bit 0) - 193 MUST be set to 1, since this is an optional attribute 195 2nd higher order bit (bit 1) - 196 MUST be set to 1, since this is a transitive attribute 198 3.1. SLA, QoS attribute sub-type, Definition 200 The value field of the QoS Attribute contains TLVs, followed to QoS 201 Attribute flags described in the previous section. One of the TLVs 202 that we define is a tuple of (SLA sub-type, Length, Value). 204 0 1 2 3 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | QoS Attr flags| subType | subtype Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ~ ~ 210 | Value | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 213 QoS Attr flags 214 8-bit = 0000-0000, All the bits are currently un-used. The space 215 is made available for the purpose of future use. For now 216 they all MUST be set to 0 when QoS attribute is added in 217 the BGP update message and MUST be ignored when received 219 subType 220 8-bit 221 0x00 = reserved 222 0x01 = SLA 223 0x02 - 0x0f = for future use 225 subType Length 226 16-bit 227 Length of the content to follow pertaining to specified 228 subType. 230 Value for the SLA sub-type is as described below. These details 231 contain information about 1) sender and receiver(s) and 2) SLA 232 parameters. SLA Parameters include SLA event type (such as 233 Advertise) and contents associated to that event type. 235 The format of SLA message is, 237 0 1 2 3 238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | 32-bit Source AS (Advertiser) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | 32-bit Destination AS count | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | variable list of destination AS | 245 ~ .... ~ 246 | .... | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Event | SLA id | SLA length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Content as per SLA Event | 251 ~ ~ 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Source AS 256 32-bit source AS number. This is the AS that is advertising SLA 257 0 = ignore Source and Destination AS list from this Value field 259 Note that AS = 0, used in message outside of QoS attribute, 260 is illegal in normal BGP operations. AS = 0 inside the QoS 261 attribute may be used simply as a flag to tell receiver to 262 ignore Source and Destination AS list from inside the QoS 263 attribute. 265 Destination AS count 266 32-bit destination AS count to take variable length AS list. 267 This count has no functional value when Source AS is 0. 269 0 = QoS attribute is relevant to every receiver of the message 271 Destination AS list 272 32-bit destination AS number 273 .... 274 .... [as many as AS count] 276 SLA Event 277 4-bits 278 0x0 = reserved 279 0x1 = ADVERTISE 280 0x2 to 0xf, for future use 282 SLA Id 283 16-bit identifier unique within the scope of source AS 285 The significance of an SLA identifier is in the context of the 286 source that is advertising SLA parameters. The SLA identifier 287 is not globally unique but it MUST be unique within the source 288 AS (advertiser). 290 If advertised SLA id is different from earlier advertised one, 291 for the same prefix, previous SLA content MUST be replaced 292 with the new advertised one. 294 SLA is aggregate for all the traffic to prefixes for a given 295 AFI/SAFI that share same source AS and SLA id. 297 SLA Length 298 12-bits - Total length of the SLA content to follow 300 Content as per SLA event 302 The SLA content is optional for an advertised SLA id. The 303 value of the SLA length field in such case would be 0. If SLA 304 content does not exist in BGP update messages with advertised 305 QoS attribute, that contains the SLA sub-type, then receiver 306 MUST inherit prior advertised SLA content for the same SLA id 307 from the same Source AS. If there does not exist any prior SLA 308 to relate to the advertised SLA id, then receiver can ignore 309 the SLA advertisement and continue with the rest of the BGP 310 message processing and forwarding rules. Note that such 311 condition MUST not discard the attribute. All defined 312 forwarding rules for this attribute still MUST apply. 314 The only event prescribed in this document is ADVERTISE. 315 The format of SLA ADVERTISE event message is, 316 0 1 2 3 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |dir| Traffic Class count | Class Desc Len| | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 321 | | 322 ~ Traffic Class Description ~ 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Elements Count| | 326 +-+-+-+-+-+-+-+-+ ~ 327 | | 328 ~ Traffic Class Elements TLVs ~ 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Service Count| | 332 +-+-+-+-+-+-+-+-+ ~ 333 | Traffic Class Service TLVs | 334 ~ ~ 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 ~ Repeat from Traffic Class Description for next Traffic Class ~ 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 ~ Repeat from direction for SLA in the other direction ~ 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 dir (Direction) 347 02-bit for incoming traffic to source AS or outgoing traffic 348 from source AS, 349 0x0 = reserved 350 0x1 = incoming, to source AS from destination AS 351 0x2 = outgoing, from source AS towards destination AS 352 0x3 = for future use 354 Traffic Class count (Classifier Groups count) 355 16-bit, count of number of classifier groups 356 00 = Advertisement to invalidate previous advertised SLA if any 358 Traffic Class Descr Length 359 08-bit, length of the description 361 0 = No description 363 Traffic Class Description 364 Description of the Traffic Class in UTF-8 encoding 366 Traffic Class Elements Count in a Traffic Class, 368 08-bit count of classifier elements in a specific Traffic Class 370 00 = this has relative definition. It means classify rest all 371 traffic that is not classified via earlier described 372 Traffic Classes. 373 It is RECOMMENDED that Traffic Class that has 0 elements 374 is present last in the advertised list of Traffic Classes. 375 If Advertised message has it positioned somewhere else, 376 then receiver MUST re-order it, for the forwarding purpose, 377 to the last position in the advertised list of Traffic 378 Classes from a given source AS. QoS attribute advertised 379 from a specific source MUST NOT have more than one such 380 Traffic Classes (Traffic Class with 0 elements count). If 381 there are more than one such Traffic Classes present then 382 it is an error condition which should follow handling of 383 such BGP message as described in Error handling section. 385 Classifier Element values (optional), 387 08-bit = IPFIX Element Identifier 388 08-bit = size, in octets, of the value field 389 variable-length field = contains actual value 391 Given IPFIX [RFC5102] has well defined identifier set for a 392 large number of packet attributes, IPFIX IANA registry is 393 ("https://www.ietf.org/assignments/ipfix") chosen to specify 394 packet classification attributes. However, since not all 395 identifiers from IPFIX would be applicable to this proposal, 396 only a limited set identified here can be supported by BGP 397 SLA exchange. Any new element identifier, in the future added 398 to the IPFIX IANA registry, is not automatically supported 399 for this proposal. Only the IPFIX elements indicated in this 400 document below remain supported. 402 +----+----------------------------+ 403 | ID | Name | 404 +----+----------------------------+ 405 |195 | ipDiffServCodePoint | 406 |203 | mplsTopLabelExp | 407 |244 | dot1qPriority | 408 | 8 | sourceIPv4Address | 409 | 27 | sourceIPv6Address | 410 | 9 | sourceIPv4PrefixLength | 411 | 29 | sourceIPv6PrefixLength | 412 | 44 | sourceIPv4Prefix | 413 |170 | sourceIPv6Prefix | 414 | 12 | destinationIPv4Address | 415 | 28 | destinationIPv6Address | 416 | 13 | destinationIPv4PrefixLength| 417 | 30 | destinationIPv6PrefixLength| 418 | 45 | destinationIPv4Prefix | 419 |169 | destinationIPv6Prefix | 420 | 4 | protocolIdentifier | 421 | 7 | sourceTransportPort | 422 | 11 | destinationTransportPort | 423 +----+----------------------------+ 425 Any traffic classifier element advertised in the QoS attribute 426 is only applicable to the NLRI advertised for a given AFI/SAFI 427 within the BGP update message. If a receiver receives a BGP 428 update message with QoS/SLA attribute for an NLRI that is not 429 supported by a receiver then receiver MUST not install an 430 advertised SLA and continue to forward this attribute further 431 if it is not the last receiver of an attribute. 433 Traffic Class Service count (for a Traffic Class under definition) 434 08-bit count of service attributes fields to follow with 435 type/value pair 436 List of service types and relevant values are discussed below 438 00 = no bounded service (also means Best Effort) 440 Traffic Class Service (optional), 441 16-bit = Traffic Class Service Type 442 08-bit = size, in octets, of the value field 443 variable-length field = contains actual value 445 - 0x00 = reserved 447 - 0x01 = TRAFFIC_CLASS_TSPEC 448 160-bits TSpec Parameter 449 The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p), 450 (m) and (M) parameters as described in Invocation Information 451 section of [RFC2212]. Note that inheriting the definition of 452 TSpec here does not enable RFC2212 functionality. Only the 453 values of the Traffic Specification are used in this 454 specification. 456 0 1 2 3 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Minimum Rate (r) (32-bit IEEE floating point number) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Burst Size (b) (32-bit IEEE floating point number) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Maximum Rate (p) (32-bit IEEE floating point number) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Minimum Policed Unit (m) (32-bit integer) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Maximum Packet Size (M) (32-bit integer) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Parameter (r) indicates min-rate of the traffic class. This rate 471 indicates the minimum rate, measured in octets of Layer 2 (L2) 472 datagrams per second, that the service advertiser is providing 473 for a given class of traffic on advertiser's hop. Note that it 474 does not necessarily translate to a minimum rate service to the 475 receiver of an SLA unless the traffic class definition clearly 476 represents a sole receiver of an SLA. If there is no SLA for 477 min-rate, the value of (r) MUST be set to 0. 479 Parameter (b) indicates maximum burst size, measured in octets of 480 L2 datagram size. Since queuing delay can be considered a 481 function of burst size (b) and min-rate (r), in presence of non- 482 zero parameter (r), parameter (b) represents bounded delay for 483 the Traffic Class. This delay is a single hop queuing delay when 484 SLA is to be implemented at the resource constrained bottleneck. 485 In other words this burst size can be considered as a buffer 486 size. Value of 0 for parameter (b) means the advertiser does not 487 mandate specific bounded delay. 489 Parameter (p) indicates max-rate of the traffic class. Just like 490 min-rate, max-rate, measured in octets of L2 packets per second, 491 field here also indicates service provided by advertiser. If 492 advertiser does not have any specific value to set for a given 493 class of traffic, it MAY be set to physical interface line rate 494 or any other indirect limit that may affect this class' maximum 495 rate. In absence of any such known value, it MUST be set to 496 positive infinity. Value 0 is considered an error. 498 Parameters (r), (b) and (p) are each set as 32-bit IEEE floating 499 point numbers. Positive infinity is represented as an IEEE single 500 precision floating-point number with an exponent of all ones and 501 a sign mantissa of all zeros. The format of IEEE floating-point 502 numbers is further summarized in [RFC4506]. 504 The minimum policed unit (m) and maximum packet size (M) 505 parameters have no relevance for the purpose of SLA exchange. 506 Thus they MUST be ignored. 508 - 0x02, L2_OVERHEAD 509 08-bit, value 511 By default specification of rate and other packet size related 512 parameters, advertised in an SLA, includes L2 overhead. For the 513 receiver next hop,this overhead is the L2 overhead of the local 514 link where advertised SLA is received. However, in cases where 515 advertised SLA is for a receiver multiple hops away, L2 overhead 516 consideration from the source perspective may be different from 517 the local L2 overhead at the receiver. Explicit notification of 518 size of L2 overhead from a sender, in such cases, is useful for 519 a receiver to distinguish local L2 overhead from the sender 520 advertised one. When receiver choose to react to an advertised 521 SLA and if this service type is present in advertised SLA, 522 receiver MUST use advertised L2 overhead over local L2 overhead. 524 If SLA is required to consider only IP packet size, sender may 525 advertise this service with a value of 0. 527 - 0x03 = MINRATE_IN_PROFILE_MARKING 528 08-bit = IPFIX Element Identifier 529 08-bit = size, in octets, of the value field 530 variable-length field = contains actual value 532 00 Identifier = drop, variable-length for this id is 0. 534 +----+----------------------------+ 535 | ID | Name | 536 +----+----------------------------+ 537 |195 | ipDiffServCodePoint | 538 |203 | mplsTopLabelExp | 539 |244 | dot1qPriority | 540 +----+----------------------------+ 542 - 0x04 = MINRATE_OUT_PROFILE_MARKING 543 08-bit = IPFIX Element Identifier 544 08-bit = size, in octets, of the value field 545 variable-length field = contains actual value 547 00 Identifier = drop, variable-length for this id is 0. 549 +----+----------------------------+ 550 | ID | Name | 551 +----+----------------------------+ 552 |195 | ipDiffServCodePoint | 553 |203 | mplsTopLabelExp | 554 |244 | dot1qPriority | 555 +----+----------------------------+ 557 - 0x05 = MAXRATE_IN_PROFILE_MARKING 558 08-bit = IPFIX Element Identifier 559 08-bit = size, in octets, of the value field 560 variable-length field = contains actual value 562 00 Identifier = drop, variable-length for this id is 0. 564 +----+----------------------------+ 565 | ID | Name | 566 +----+----------------------------+ 567 |195 | ipDiffServCodePoint | 568 |203 | mplsTopLabelExp | 569 |244 | dot1qPriority | 570 +----+----------------------------+ 572 - 0x06 = MAXRATE_OUT_PROFILE_MARKING 573 08-bit = IPFIX Element Identifier 574 08-bit = size, in octets, of the value field 575 variable-length field = contains actual value 577 00 Identifier = drop, variable-length for this id is 0. 579 +----+----------------------------+ 580 | ID | Name | 581 +----+----------------------------+ 582 |195 | ipDiffServCodePoint | 583 |203 | mplsTopLabelExp | 584 |244 | dot1qPriority | 585 +----+----------------------------+ 587 In the case when MINRATE_IN_PROFILE_MARKING, 588 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and 589 MAXRATE_OUT_PROFILE_MARKING are all advertised, 590 - MINRATE_IN_PROFILE_MARKING takes highest precedence 591 (that is over MAXRATE_IN_PROFILE_MARKING) 593 - MAXRATE_IN_PROFILE_MARKING takes precedence over 594 MINRATE_OUT_PROFILE_MARKING 596 - and MAXRATE_OUT_PROFILE_MARKING takes precedence over 597 MINRATE_OUT_PROFILE_MARKING 599 - 0x07 = DROP_THRESHOLD 600 03-bit count of drop-priority fields to follow with 601 (type, type-value, burst size) tuple 603 04-bit, drop priority type 604 08-bit = IPFIX Element Identifier 605 08-bit = size, in octets, of the value field 606 variable-length field = contains actual value 607 32-bit = Burst Size 608 (32-bit IEEE floating point number) 610 +----+----------------------------+ 611 | ID | Name | 612 +----+----------------------------+ 613 |195 | ipDiffServCodePoint | 614 |203 | mplsTopLabelExp | 615 |244 | dot1qPriority | 616 +----+----------------------------+ 618 This finer granular drop threshold does not require separate 619 buffer space from the aggregate buffer space. It is just an 620 indicator beyond which code-point specific traffic to be 621 discarded when occupancy of aggregate buffers reached to that 622 threshold. 624 - 0x08 = RELATIVE_PRIORITY 625 04-bit, priority value 626 lower the value, higher the priority 628 Relative priority indicates scheduling priority. For example 629 voice traffic, which requires lowest latency compared to any 630 other traffic, may have lowest value advertised in relative 631 priority. For two different traffic classification groups 632 where one application group may be considered more important 633 than the other but from a scheduling perspective does not 634 require to be distinguished with a different priority, relative 635 priority for those classification groups may be advertised with 636 the same value. 638 - 0x09 = SUB_TRAFFIC_CLASSES 639 variable-length, repeats all content described above from Traffic 640 Class count onwards. 642 For SLAs where a specific Traffic Class may further have 643 different sub-services for a sub-group of Classifier Elements, 644 this service type SHOULD be used to further divide Traffic Class 645 in multiple sub-classes. Each sub-class is then defined with 646 their own classifier elements and service types. 648 4. Originating SLA Notification 650 The QoS attribute MUST only be added by the originator and MUST NOT 651 be added during BGP propagation. 653 SLA messages SHOULD NOT be sent periodically just for the purpose of 654 keep alive. Some sort of SLA policy change may be considered as a 655 trigger for the advertisement. 657 For any modified SLA parameters, the originator MUST re-advertise the 658 entire set of SLA parameters. There is no provision to advertise 659 partial set of parameters. To invalidate previously advertised SLA 660 parameters, a message MUST be sent with the same SLA id for the same 661 source with the Traffic Class count set to 0. 663 4.1. SLA Contexts 665 In certain cases, the advertisement may relate to an SLA for 666 aggregate traffic over a point-to-point connection between a specific 667 destination and a specific source. A point-to-point connection may 668 be the physical link, that connects two BGP peers, or may be a 669 virtual link (e.g. a tunnel). A BGP update message, in such cases, 670 with source AS number and NLRI prefix of source end-point can 671 uniquely identify physical/virtual link and so establishes advertised 672 SLA's context for that point to point link. 674 In the simplest case where Provider (e.g. PE) and Customer (e.g. 675 CE) devices are directly connected via a physical link and have only 676 a single link between them, CE can uniquely identify the forwarding 677 link to PE with AS number of the PE and NLRI prefix being an IP 678 address of PE, to CE (that is the next hop address from CE to PE). 679 SLA advertised thru BGP update message from PE to CE, with PE's AS 680 number and IP address, establishes SLA context for the aggregate 681 traffic through link CE to PE. SLA advertised thru BGP update 682 message from PE to CE, with PE's AS number and any other prefix 683 establishes SLA for that specific prefix, subset of traffic under CE 684 to PE link. 686 Even though this example is in the context of IP prefixes, SLA 687 exchange does not have to be limited to the IP address family (IPv4 688 and IPv6). SLA advertisement is generic to all forms of NLRI types 689 that are supported by the BGP protocol specification (like IPv4, 690 IPv6, VPN-IPv4, VPN-IPv6). 692 4.1.1. SLA Advertisement for Point-to-Point Connection 694 When SLA messages are intended to be advertised for the point-to- 695 point connection (physical or logical), the message is destined for 696 the next hop and advertised message is in the context of the prefix 697 of the source end-point of the point to point connection. 699 The destination AS number set to, within QoS SLA attribute, typically 700 is of the neighbor BGP speaker's. Alternatively, source AS and 701 destination AS count MAY be set to 0. 703 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 705 When SLA messages are to be advertised beyond next hop, value of 706 source AS, in the QoS attribute, MUST be set by the originator of the 707 update message. If such an update is meant to be for a specific list 708 of AS(es) as receivers, then the list of destination AS MUST be 709 explicitly described in the QoS attribute message to avoid flooding 710 of the QoS attribute data in the network beyond those destinations. 712 When a new prefix is added in the AS, AS for which SLA parameters 713 have already been advertised before for other existing prefixes, and 714 if traffic to this new prefix is subject to the same SLA advertised 715 earlier then BGP update for this new prefix may include QoS attribute 716 containing just an SLA id, an id that was advertised earlier. The 717 corresponding Update message does not require to have the whole SLA 718 content. SLA id is sufficient to relate SLA parameters to new 719 advertised prefix. 721 5. SLA Attribute Handling at Forwarding Nodes 723 5.1. BGP Node Capable of Processing QoS Attribute 725 If a BGP node is capable of processing QoS attribute, it optionally 726 MAY process the QoS attribute. If advertised SLA has a list of 727 destination ASes, it MAY trim the list and so count of destination AS 728 to exclude ones that are not required in further announcement of BGP 729 updates. 731 BGP node MUST drop SLA related sub-type from the QoS attribute, if 732 there is no more AS from the destination list in the forwarding path. 733 The rest of the QoS attribute contents MAY be forwarded if there 734 exist other sub-types of QoS attribute and forwarding rules meets 735 other sub-types requirements. If there is no other sub-types in the 736 QoS attribute content then the node MUST drop the entire QoS 737 attribute all together. The other attributes and NLRI information 738 may be announced further if they meet rules defined by other 739 attributes and BGP protocol. 741 Except extracting the entire SLA sub-type of the QoS attribute and 742 trimming the list of destination AS list, all other content MUST NOT 743 be modified by any intermediate receivers of the message. 745 5.2. SLA Attribute Handling at Receiver 747 Reception of and processing of advertised QoS SLA content are 748 optional for the receiver. 750 While reacting to SLA advertisement 751 - receiver SHOULD invalidate previous advertised SLA parameters if 752 one exists for the same SLA id and source AS. If the new 753 advertised SLA has a non-zero traffic count, then the new 754 advertised SLA SHOULD be installed. If new advertised SLA update 755 is with Traffic Class count 0, then no action is required. 757 - When BGP update messages are triggered only as a result of SLA 758 policy change, BGP update message forwarding beyond intended 759 receivers are not necessary. If receiver device implementation 760 supports policy based filtering then receiver MAY implement a 761 policy to filter such messages based on prefix and attribute. 763 If SLA advertised to the next hop neighbor, the receiver may 764 implement advertised SLA for the whole link, where the link could be 765 physical or virtual link, connected to the neighbor. If SLA 766 advertised to is not the next hop neighbor then receiver may 767 establish advertised SLA for that specific prefix list under the 768 relevant link. It is completely up to the receiver to decide for 769 which prefixes it should accept advertised SLA and for which ones it 770 won't. 772 6. Error Handling 774 Error conditions, while processing of the QoS attribute, SHALL be 775 handled with the approach of attribute-discard as described in [IDR- 776 ERR]. In such condition, receiver SHOULD also cleanup any previously 777 installed SLA state for the same prefix. 779 7. Traffic Class Mapping 781 It is possible that switching/routing methods used in 2 different 782 ASes could be different. For example, Provider may tunnel Customer's 783 IP traffic thru MPLS cloud. In such cases traffic class definition 784 for QoS services may differ in both ASes. For the meaningful use of 785 advertised SLA in such cases, receiver is required to map traffic 786 class from one type to the other. 788 In the example given, traffic classification in Customer AS could be 789 IP Diffserv-based whereas traffic classification in Provider AS could 790 be MPLS TC-based. Thus for advertised MPLS TC-based SLA would 791 require to map traffic class from IP Diffserv-based to MPLS TC type 792 [RFC3270]. 794 There are well-defined recommendations that exist for traffic class 795 mapping between two technologies, eg. RFC3270 for mapping between 796 DSCP and MPLS TC. Receiver MAY use those defined recommendations for 797 traffic class mapping or MAY define its own as per its network 798 Traffic Class service definition to map to advertised Traffic 799 Classes. It is completely up to the receiver how to define such 800 traffic class mapping. 802 8. Deployment Considerations 804 One of the use cases is for a Provider to advertise contracted SLA 805 parameters to Customer Edge (CE) in cases where eBGP is deployed 806 between PE and CE. The SLA parameters may already be provisioned by 807 the provider on the PE device (facing CE). This provisioned SLA 808 parameters are then advertised thru proposed BGP QoS attribute to the 809 CE device. CE device may read the attribute and SLA sub-type content 810 to implement the QoS policy on the device. 812 Contracted SLA from PE to CE may be full line-rate or sub line-rate 813 or finer granular controlled services. SLA advertise can be useful 814 when contracted service is sub-rate of a link and/or when for finer 815 granular traffic classes that are controlled (e.g. voice, video 816 services may be capped to certain rate) 817 _______________ 818 __________ / \ 819 / \ / \ 820 / \ / \ 821 |CustomerSite|-----| Provider | 822 \ C/E P\E / 823 \__________/ \ / 824 \_______________/ 825 AS 3 AS 2 827 SLA_ADVERTISE: AS2 to AS3 828 NLRI = PE ip address 830 Another use case can be to advertise SLAs among different network 831 sites within one Enterprise network. In Hub and Spoke deployments, 832 Administrator may define SLAs at spoke and advertise QoS SLA 833 parameters to the Hub thru BGP updates. In the figure below, each 834 spoke (AS1 and AS2) are connected to Hub (AS3) via a VPN tunnel. As 835 shown, AS2 can advertise SLA to AS3 in the context of that tunnel ip 836 address. 838 AS 2 839 _______________ ________ 840 / \ / \ 841 __________ / \-----| Spoke2 | 842 / \ / \ \________/ 843 | Hub |-----| Provider | ________ 844 \__________/ \ / / \ 845 \ /-----| Spoke1 | 846 AS 3 \_______________/ \________/ 848 AS 1 850 SLA_ADVERTISE: AS2 to AS3 851 NLRI = AS2 tunnel address 853 SLA_ADVERTISE: AS1 to AS3 854 NLRI = AS1 tunnel address 856 Deployment options are not limited to involving CEs, PE-to-CE or CE- 857 to-CE, only. For any contract between two providers, SLA parameters 858 may be advertised from one to the other. 860 9. Acknowledgements 862 Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for 863 their suggestions and to Christian Jacquenet, Ken Briley, Rahul 864 Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier, 865 Bruno Decraene for the review. 867 10. IANA Considerations 869 This document defines a new BGP optional transitive path attribute, 870 called QoS Attribute. IANA action is required to allocate a new 871 code-point in the BGP path Attributes registry. 873 IANA is requested to create a registry for QoS Attribute subTypes. 874 This is a registry of 1 octet value, to be assigned on a standards 875 action/early allocation basis. The initial assignments are: 877 QoS Attribute subTypes 878 - - - - - - - - - - - - 879 Reserved 0x00 880 SLA 0x01 882 IANA is requested to create a registry for SLA Event Types. This is 883 a registry of 4-bits value, to be assigned on a standards action/ 884 early allocation basis. The initial assignments are: 886 QoS Attribute SLA Event Types 887 - - - - - - - - - - - - - - - 888 Reserved 0x00 889 ADVERTISE 0x01 891 IANA is requested to create a registry to define QoS SLA Direction. 892 This is the direction in forwarding path, advertised QoS SLA is 893 applicable to. 895 QoS SLA Direction 896 - - - - - - - - - 897 Reserved 0x00 898 to Source AS from destination AS 0x01 899 from source AS to destination AS 0x02 901 QoS SLA Traffic Class Element Types will be referring to existing 902 IPFIX IANA types as described in section 3.1. 904 IANA is requested to create a registry for QoS SLA Traffic Class 905 Service Types. This is a registry of 2 octet values, to be assigned 906 on a standards action/early allocation basis. The initial 907 assignments are: 909 Traffic Class Service Type 910 - - - - - - - - - - - - - - 911 Reserved 0x00 912 TRAFFIC_CLASS_TSPEC 0x01 913 L2_OVERHEAD 0x02 914 MINRATE_IN_PROFILE_MARKING 0x03 915 MINRATE_OUT_PROFILE_MARKING 0x04 916 MAXRATE_IN_PROFILE_MARKING 0x05 917 MAXRATE_OUT_PROFILE_MARKING 0x06 918 DROP_THRESHOLD 0x07 919 RELATIVE_PRIORITY 0x08 920 SUB_TRAFFIC_CLASSES 0x09 922 11. Security Considerations 924 The QOS attribute defined in this document SHOULD be used by the 925 managed networks for enforcing Quality of Service Policies and so 926 there should not be any risks for identity thefts. To strengthen the 927 security for the QOS attribute, RPKI based origin validation 928 [RFC7115] MAY be used. In addition to the RPKI based origin 929 validation, BGP Path Validation [I-D.ietf-sidr-bgpsec-protocol] 930 procedures could be used over BGP QOS attribute and its associated 931 prefix in producing the digital signature that can be carried within 932 the signature SLA for the messages. This would help prevent any man- 933 in-the-middle attracks. 935 12. References 937 12.1. Normative References 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, 941 DOI 10.17487/RFC2119, March 1997, 942 . 944 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 945 of Guaranteed Quality of Service", RFC 2212, 946 DOI 10.17487/RFC2212, September 1997, 947 . 949 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 950 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 951 Protocol Label Switching (MPLS) Support of Differentiated 952 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 953 . 955 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 956 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 957 DOI 10.17487/RFC4271, January 2006, 958 . 960 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 961 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 962 2006, . 964 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 965 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 966 2006, . 968 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 969 Meyer, "Information Model for IP Flow Information Export", 970 RFC 5102, DOI 10.17487/RFC5102, January 2008, 971 . 973 [RFC7115] Bush, R., "Origin Validation Operation Based on the 974 Resource Public Key Infrastructure (RPKI)", BCP 185, 975 RFC 7115, DOI 10.17487/RFC7115, January 2014, 976 . 978 [IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 979 "Revised Error Handling for BGP UPDATE Message, I-D.draft- 980 ietf-idr-error-handling", June 2012. 982 12.2. Informative References 984 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 985 and W. Weiss, "An Architecture for Differentiated 986 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 987 . 989 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 990 Connectivity Provisioning Profile (CPP)", RFC 7297, 991 DOI 10.17487/RFC7297, July 2014, 992 . 994 [BGP-SEC] Lepinski, M., "BGPsec Protocol Specification, I-D.draft- 995 ietf-sidr-bgpsec-protocol", June 2015. 997 [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 998 Negotiation Protocol (CPNP), I-D.boucadair-connectivity- 999 provisioning-protocol", Sep 2014. 1001 [BGPSLA-IMPL] 1002 Shah, S. and K. Patel, "Inter-domain SLA Exchange 1003 Implementation Report, I-D.draft-svshah-idr-sla-exchange- 1004 impl", Feb 2015. 1006 Authors' Addresses 1008 Shitanshu Shah 1009 Cisco Systems 1010 170 W. Tasman Drive 1011 San Jose, CA 95134 1012 US 1014 Email: svshah@cisco.com 1016 Keyur Patel 1017 Cisco Systems 1018 170 W. Tasman Drive 1019 San Jose, CA 95134 1020 US 1022 Email: keyupate@cisco.com 1024 Sandeep Bajaj 1025 Juniper Networks 1026 1194 N. Mathilda Avenue 1027 Sunnyvale, CA 94089 1028 US 1030 Email: sbajaj@juniper.net 1032 Luis Tomotaki 1033 Verizon 1034 400 International 1035 Richardson, TX 75081 1036 US 1038 Email: luis.tomotaki@verizon.com 1039 Mohamed Boucadair 1040 France Telecom 1041 Rennes 35000 1042 France 1044 Email: mohamed.boucadair@orange.com