idnits 2.17.1 draft-ietf-idr-sla-exchange-02.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 -- The document date (Nov 04, 2013) is 3820 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) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 8, 2014 S. Bajaj 6 Juniper Networks 7 L. Tomotaki 8 Verizon 9 M. Boucadair 10 France Telecom 11 Nov 04, 2013 13 Inter-domain SLA Exchange 14 draft-ietf-idr-sla-exchange-02 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. 28 This document defines an optional transitive attribute to signal SLA 29 details in-band, across administrative boundaries (considered as 30 Autonomous Systems (AS)), thus simplifying and facilitating some of 31 the complex provisioning tasks. 33 Though the use case with the proposed BGP attribute is explicitly 34 defined in this document, purpose of this attribute is not limited to 35 this use case only. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 8, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 5 74 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 6 75 4. Originating SLA Notification . . . . . . . . . . . . . . . . . 16 76 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16 78 4.1.2. SLA Advertisement for Destination AS Multiple Hops 79 Away . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . . 17 81 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . . 17 82 5.2. BGP Node not Capable of Processing QoS Attribute . . . . . 18 83 5.3. Aggregator . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6. SLA Attribute Handling at Receiver . . . . . . . . . . . . . . 18 85 6.1. Traffic Class Mapping . . . . . . . . . . . . . . . . . . 19 86 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 20 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 Typically there is a contractual Service Level Agreement (SLA) 98 established between Customer and Provider or between providers, 99 possibly using one or the other form of the template [CPP]. This 100 contractual agreement usually defines the nature of the various 101 traffic classes (i.e., traffic match conditions) and services needed 102 for each traffic class. The contract may exist at different levels 103 of traffic granularity. The contract could be for the full line-rate 104 or sub line-rate without granular traffic distinction or it could be 105 for finer granular traffic classes, with services defined. Finer 106 granular classes can be based on some standard code-points (like 107 DSCP) or for a specific set of prefixes or for a set of well-known 108 application types. 110 Once the SLA is established, SLA parameters are enforced in some or 111 all participating devices by deriving SLA parameters into 112 configuration information on respective devices. SLA parameters may 113 have to be exchanged through organizational boundaries, thru SLA 114 documents or via some other off-band method to an administrator 115 provisioning actual devices. In a subsequent step, administrator 116 requires to translate SLA to QoS policies using router (vendor) 117 specific provisioning language. In a multi-vendor network, 118 translating SLAs into technology-specific and vendor-specific 119 configuration requires to consider specificities of each vendor. 120 There does not exist any standard protocol to translate SLA 121 agreements into technical clauses and configurations and thus both 122 the steps of out of band learning of negotiated SLA and provisioning 123 them in a vendor specific language can be complex and error-prone. 124 As an example for voice service, the Provider may negotiate QoS 125 parameters (like min/max rates) for such traffic based upon the EF 126 code-point in Diffserv-enabled [RFC2475] networks. Administrator at 127 the CE side not only will have to know that Provider's service for 128 voice traffic is EF-based, so that traffic exiting CE is marked 129 properly, but will also have to know how to implement DSCP EF 130 classification rule along with Low Latency Service, and possibly min/ 131 max rate enforcement for the optimal use of bandwidth, as per vendor 132 specific provisioning language. 134 An in-band signaling method of propagating SLA parameters from 135 provider, PE in an example above, to contractual devices, CE in an 136 example above, can help eliminate manual administrative process 137 described above. Provider may have SLA negotiated with the Customer 138 via some defined off-band method (based on the specifics defined by 139 the Provider or using protocols like [CPNP]. The Inter-domain SLA 140 exchange proposal described in this document does not pre-requisite 141 any specific method of establishing SLAs). The Provider provisions 142 established SLA on the Provider device. This SLA instance then can 143 be signaled to the Customer via in-band signaling protocol. In 144 reaction to this signal, receiver router may translate that to 145 relevant QoS policy definition on the device. 147 For an in-band signaling, we propose to use BGP as a transport. The 148 details of SLA parameters are specific to the granularity of traffic 149 classes and their respective treatment, which is independent of the 150 BGP protocol itself. Though we find BGP as a suitable transport for 151 inter-domain SLA exchange for the following reasons: 153 - The need to exchange SLA parameters between domains (Automated 154 Systems (AS)), where in use-cases described in this document, 155 BGP is a suitable protocol for inter-domain exchange [RFC4271] 156 [RFC4364] 157 - There is no specifically defined protocol available today for 158 SLA exchange 159 - BGP updates already advertise specific set of prefixes (flow 160 or flow-group). Other QoS-related attributes, apart from the 161 the use of SLA advertisement, can be added to these updates 162 in the future 164 The proposal is to define a new BGP attribute to advertise/learn SLA 165 details in-band. The proposed attribute is intended to advertise SLA 166 from one AS to a list of destined ASes. The advertised QoS 167 information could be for the incoming traffic to the advertiser, that 168 is advertising SLA or could be for the outgoing traffic from the 169 advertiser or could be for both directions. Reception of and 170 reaction to advertised SLAs are optional for the receiver. 172 We propose QoS as an optional transitive attribute, keeping SLA 173 advertisement and discovery (request) as one of the sub-types of QoS 174 attribute. This is to keep the QoS attribute open for extensions. 175 For example, SLA Negotiation and Assurance is out of scope of this 176 document but can be envisioned as another sub-type. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 3. QoS Attribute Definition 186 The QoS Attribute proposed here is an optional transitive attribute 187 (attribute type code to be assigned by IANA). SLA is defined as one 188 of the sub-types in the QoS attribute. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Attr flag | Attr type QoS | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 195 ~ ~ 196 | QoS Attr length/Value | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 199 Attribute flags 200 highest order bit (bit 0) - 201 MUST be set to 1, since this is an optional attribute 203 2nd higher order bit (bit 1) - 204 MUST be set to 1, since this is a transitive attribute 206 3.1. SLA, QoS attribute sub-type, Definition 208 The value field of the QoS Attribute contains TLVs, followed to QoS 209 Attribute flags described in the previous section. One of the TLVs 210 that we define is a tuple of (SLA sub-type, Length, Value) 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | QoS Attr flags| subType | sub type Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ ~ 218 | Value | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 221 The first octet in the Value field of the QoS attribute is QoS 222 attribute specific flags 224 highest order bit (bit 0) - 225 It defines if update message MUST be dropped (if set to 1) 226 without updating routing information base, when this is the 227 last BGP receiver from the list of destination ASes this 228 attribute is announced to, or MUST announce (if set to 0) 229 further to BGP peers 231 The purpose of this bit is discussed further in subsequent 232 sections. 234 Remaining bits are currently unused and MUST be set to 0 236 subType - 8 bits 237 0x00 = reserved 238 0x01 = SLA 239 0x02 - 0x0f = for future use 241 SLA sub-type specific value field details. These details contain 242 information about 1) sender and receiver(s) and 2) SLA parameters. 243 SLA Parameters include SLA event type (such as Advertise, Request) 244 and contents associated to that event type. 246 The format of SLA message is, 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | 32-bit source AS (Advertiser) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |Optional advertiserid total len| Advertiser id TLVs | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 252 | | 253 ~ ~ 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | 32-bit destination AS count | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | variable list of destination AS | 259 ~ .... ~ 260 | .... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Event | SLA id | SLA length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Content as per SLA Event | 265 ~ ~ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Source AS 270 32-bit source AS number. This is the AS that is advertising SLA 271 0 = ignore Source and Destination AS list from this Value field. 272 Instead refer to Source and Destination AS as defined by BGP 273 message. 275 Optional advertiser id total len 276 16-bit Source address identifier (optional). 277 0 = No optional identifier 279 In general any additional qualifier for an advertiser is not 280 required. The SLA definition is in the context of prefix 281 advertised in the NLRI definition. The exception is where a BGP 282 speaker, in the middle of an update path to the destination AS, 283 aggregates prefixes. We will refer this middle BGP speaker, that 284 aggregates routes, as an Aggregator. Aggregator is then required 285 to insert original NLRI details in the optional advertiser field 287 Optional Advertiser id TLV 288 4-bit type 289 0x0 = reserved 290 0x1 = ORIGIN_NLRI, variable length 291 0x2 to 0xf = for future use, 293 Destination AS count 294 32-bit destination AS count to take variable length AS list. 295 This count has no functional value when Source AS is 0 297 0 = QoS attribute is relevant to every receiver of the message 299 Destination AS list 300 32-bit destination AS number 301 .... 302 .... [as many as AS count] 304 SLA Event Type 305 4-bits 306 0x0 = reserved 307 0x1 = ADVERTISE 308 0x2 = REQUEST 309 0x3 to 0xf, for future use 311 SLA Id 312 16-bit identifier unique within the scope of source AS 314 The significance of an SLA identifier is in the context of the 315 source that is advertising SLA parameters. The SLA identifier 316 is not globally unique but it MUST be unique within the source 317 AS (advertiser). 319 The SLA content is optional for an advertised SLA id. If SLA 320 content does not exist in BGP update messages with advertised 321 QoS attribute, that contains the SLA sub-type, then receiver 322 MUST inherit prior advertised SLA content for the same SLA id 323 from the same Source AS. 325 If advertised SLA id is different from earlier advertised one, 326 for the same prefix, previous SLA content MUST be replaced 327 with the new advertised one. 329 SLA is aggregate for all the traffic to prefixes that share 330 same source AS and SLA id. 332 SLA Length 333 12-bits 335 The format of SLA ADVERTISE event message is, 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |dir| Traffic Class count | Class Desc Len| | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 340 | | 341 ~ Traffic Class Description ~ 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 ~ Traffic Class Elements count/values ~ 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Service Count| service type/value pair | 349 +-+-+-+-+-+-+-+-+ ~ 350 | | 351 ~ ~ 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 ~ Repeat from Traffic Class Description for next Traffic Class ~ 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 ~ Repeat from direction for SLA in the other direction ~ 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Direction 364 02-bit for incoming or outgoing traffic, 365 0x0 = reserved 366 0x1 = incoming, from destination AS towards source AS 367 0x2 = outgoing, from source AS towards destination AS 368 0x3 = for future use 370 Traffic Class count (Classifier Groups count) 371 16-bit, count of number of classifier groups 372 00 = Advertisement to invalidate previous advertised SLA if any 374 Traffic Class Descr Length 375 08-bit, size of the length 376 0 = No description 378 Traffic Class Description 379 Ascii Description of the Traffic Class 381 Traffic Class Elements Count in a Traffic Class, 383 08-bit count of classifier elements in a specific Traffic Class 385 00 = this has relative definition. It means classify rest all 386 traffic that is not classified via earlier described 387 Traffic Classes. 388 It is RECOMMENDED that Traffic Class, that has 0 elements, 389 is present last in the advertised list of Traffic Classes. 390 If Advertised message has it positioned some-where else, 391 then receiver MUST re-order it, for the forwarding purpose, 392 to the last position in the advertised list of Traffic 393 Classes from a given source AS. QoS attribute advertised 394 from a specific source MUST NOT have more than one such 395 Traffic Classes (Traffic Class with 0 element count). If 396 there are more than one such Traffic Classes present then 397 advertised SLA parameters MUST be ignored. It is okay 398 though to have none Traffic Class with element count 0. 400 Classifier Element values in a Traffic Class (optional), 402 08-bit = IPFIX Element Identifier 403 variable-length = based on type of the Element 405 Given IPFIX [RFC5102] has well defined identifier set for a 406 large number of packet attributes, IPFIX IANA registry is 407 "https://www.ietf.org/assignments/ipfix" chosen to specify 408 packet classification attributes. However, since not all 409 identifiers from IPFIX would be applicable to this proposal, 410 only a limited set identified here can be supported by BGP 411 SLA exchange. Any new element identifier, in future, added 412 to the IPFIX IANA registry does not automatically mean 413 supported for this proposal. 415 +----+----------------------------+ 416 | ID | Name | 417 +----+----------------------------+ 418 |195 | ipDiffServCodePoint | 419 |203 | mplsTopLabelExp | 420 |244 | dot1qPriority | 421 | 8 | sourceIPv4Address | 422 | 27 | sourceIPv6Address | 423 | 9 | sourceIPv4PrefixLength | 424 | 29 | sourceIPv6PrefixLength | 425 | 44 | sourceIPv4Prefix | 426 |170 | sourceIPv6Prefix | 427 | 12 | destinationIPv4Address | 428 | 28 | destinationIPv6Address | 429 | 13 | destinationIPv4PrefixLength| 430 | 30 | destinationIPv6PrefixLength| 431 | 45 | destinationIPv4Prefix | 432 |169 | destinationIPv6Prefix | 433 | 4 | protocolIdentifier | 434 | 7 | sourceTransportPort | 435 | 11 | destinationTransportPort | 436 +----+----------------------------+ 438 Traffic Class Service count (for a Traffic Class under definition) 439 08-bit count of service attributes fields to follow with 440 type/value pair 441 List of service types and relevant values are discussed below 443 00 = no bounded service (also means Best Effort) 445 Traffic Class Service (optional), 446 16-bit = type of the field 447 variable-length = based on type of the service 449 - 0x00 = reserved 451 - 0x01 = TRAFFIC_CLASS_TSPEC 452 160-bits TSpec Parameter 454 The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p), 455 (m) and (M) parameters as described in Invocation Information 456 section of [RFC2212]. Note that inheriting definition of TSpec 457 here does not enable RFC2212 functionality. It purely is the 458 Traffic Specification that is inherited here for the purpose of 459 SLA exchange. 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Minimum Rate (r) (32-bit IEEE floating point number) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Burst Size (b) (32-bit IEEE floating point number) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Maximum Rate (p) (32-bit IEEE floating point number) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Minimum Policed Unit (m) (32-bit integer) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Maximum Packet Size (M) (32-bit integer) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Parameter (r) indicates min-rate of the traffic class. This rate 474 indicates the minimum rate, measured in bytes of Layer 2 (L2) 475 datagrams per second, service advertiser is providing for a given 476 class of traffic on advertiser's hop. Note that it does not 477 necessarily translate to a minimum rate service to receiver of an 478 SLA unless the traffic class definition clearly represents a sole 479 receiver of an SLA. If there is no SLA for min-rate, the value of 480 (r) MUST be set to 0. 482 Parameter (b) indicates maximum burst size, measured in bytes of 483 L2 datagram size. Since queuing delay can be considered a 484 function of burst size (b) and min-rate (r), in presence of non- 485 zero parameter (r), parameter (b) represents bounded delay for 486 the Traffic Class. This delay is a single hop queuing delay when 487 SLA is to be implemented at the resource constrained bottleneck. 488 In other words this burst size can be considered as a buffer 489 size. Value of 0 for parameter (b) means the advertiser does not 490 mandate specific bounded delay. 492 Parameter (p) indicates max-rate of the traffic class. Just like 493 min-rate, max-rate, measured in bytes of L2 packets per second, 494 field here also indicates service provided by advertiser. If 495 advertiser does not have any specific value to set for a given 496 class of traffic, it MAY be set to physical interface line rate 497 or any other indirect limit that may affect this class' maximum 498 rate. In absence of any such known value, it MUST be set to 499 positive infinity. Value 0 is considered an error. 501 Parameters (r), (b) and (p) are each set as 32-bit IEEE floating 502 point numbers. Positive infinity is represented as an IEEE single 503 precision floating-point number with an exponent of all ones and 504 a sign mantissa of all zeros. The format of IEEE floating-point 505 numbers is further summarized in [RFC4506]. 507 The minimum policed unit (m) and maximum packet size (M) 508 parameters have no relevance for the purpose of SLA exchange. 509 Thus they MUST be ignored. 511 - 0x02, L2_OVERHEAD 512 08-bit, value 514 By default specification of rate and other packet size related 515 parameters, advertised in an SLA, includes L2 overhead. For the 516 receiver next hop, this overhead is the L2 overhead of the local 517 link where advertised SLA is received. However, in cases where 518 advertised SLA is for a receiver multiple hops away, L2 overhead 519 consideration from the source perspective may be different from 520 the local L2 overhead at the receiver. Explicit notification of 521 size of L2 overhead from a sender, in such cases, is useful for 522 a receiver to distinguish local L2 overhead from the sender 523 advertised one. When receiver choose to react to an advertised 524 SLA and if this service type is present in advertised SLA, 525 receiver MUST use advertised L2 overhead over local L2 overhead. 527 If SLA is required to consider only IP packet size, sender may 528 advertise this service with a value of 0. 530 - 0x03 = MINRATE_IN_PROFILE_MARKING 531 08-bit = IPFIX Element Identifier 532 variable-length = based on type of the Element 534 00 Identifier = drop, variable-length for this id is 0. 536 +----+----------------------------+ 537 | ID | Name | 538 +----+----------------------------+ 539 |195 | ipDiffServCodePoint | 540 |203 | mplsTopLabelExp | 541 |244 | dot1qPriority | 542 +----+----------------------------+ 544 - 0x04 = MINRATE_OUT_PROFILE_MARKING 545 08-bit = IPFIX Element Identifier 546 variable-length = based on type of the Element 548 00 Identifier = drop, variable-length for this id is 0. 550 +----+----------------------------+ 551 | ID | Name | 552 +----+----------------------------+ 553 |195 | ipDiffServCodePoint | 554 |203 | mplsTopLabelExp | 555 |244 | dot1qPriority | 556 +----+----------------------------+ 558 - 0x05 = MAXRATE_IN_PROFILE_MARKING 559 08-bit = IPFIX Element Identifier 560 variable-length = based on type of the Element 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 variable-length = based on type of the Element 576 00 Identifier = drop, variable-length for this id is 0. 578 +----+----------------------------+ 579 | ID | Name | 580 +----+----------------------------+ 581 |195 | ipDiffServCodePoint | 582 |203 | mplsTopLabelExp | 583 |244 | dot1qPriority | 584 +----+----------------------------+ 586 In the case when MINRATE_IN_PROFILE_MARKING, 587 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and 588 MAXRATE_OUT_PROFILE_MARKING all of them are advertised, 589 - MINRATE_IN_PROFILE_MARKING takes highest precedence 590 (that is over MAXRATE_IN_PROFILE_MARKING) 592 - MAXRATE_IN_PROFILE_MARKING takes precedence over 593 MINRATE_OUT_PROFILE_MARKING 595 - and MAXRATE_OUT_PROFILE_MARKING takes precedence over 596 MINRATE_OUT_PROFILE_MARKING 598 - 0x07 = DROP_THRESHOLD 599 03-bit count of drop-priority fields to follow with 600 (type, type-value, burst size) tuple 602 04-bit, drop priority type 603 08-bit = IPFIX Element Identifier 604 variable-length = based on type of the Element 605 32-bit, Burst Size (32-bit IEEE floating point number) 607 +----+----------------------------+ 608 | ID | Name | 609 +----+----------------------------+ 610 |195 | ipDiffServCodePoint | 611 |203 | mplsTopLabelExp | 612 |244 | dot1qPriority | 613 +----+----------------------------+ 615 This finer granular drop threshold does not require separate 616 buffer space from the aggregate buffer space. It is just an 617 indicator beyond which code-point specific traffic to be 618 discarded when occupancy of aggregate buffers reached to that 619 threshold. 621 - 0x08 = RELATIVE_PRIORITY 622 04-bit, priority value 623 lower the value, higher the priority 625 Relative priority indicates scheduling priority. For example 626 voice traffic, which requires lowest latency compare to any 627 other traffic, may have lowest value advertised in relative 628 priority. For two different traffic classification groups 629 where one application group may be considered more important 630 than the other but from a scheduling perspective does not 631 require to be distinguished with a different priority, relative 632 priority for those classification groups may be advertised with 633 the same value. 635 - 0x09 = SUB_TRAFFIC_CLASSES 636 variable-length, repeats all content described above from Traffic 637 Class count onwards. 639 For SLAs where a specific Traffic Class may further have 640 different sub-services for sub-group of Classifier Elements, 641 this service type SHOULD be used to further divide Traffic Class 642 in multiple sub-classes. Each sub-class then defined with their 643 own classifier elements and service types. 645 4. Originating SLA Notification 647 The QoS attribute to advertise SLA sub-type MUST be added by the 648 originator of a BGP UPDATE message. 650 SLA messages SHOULD NOT be sent periodically just for the purpose of 651 keep alive. Some sort of SLA policy change may be considered as a 652 trigger for the advertisement. 654 For any modified SLA parameters, the originator MUST re-advertise the 655 entire set of SLA parameters. There is no provision to advertise 656 partial set of parameters. To invalidate previously advertised SLA 657 parameters, a message MUST be sent with the same SLA id for the same 658 source with the Traffic Class count set to 0. 660 4.1. SLA Contexts 662 In certain cases, the advertisement may relate to an SLA for 663 aggregate traffic over a point-to-point connection between a specific 664 destination and a specific source. A point-to-point connection may 665 be the physical link, that connects two BGP peers, or may be a 666 virtual link (e.g. a tunnel). A BGP update message, in such cases, 667 with source AS number and NLRI prefix of source end-point can 668 uniquely identify physical/virtual link and so establishes advertised 669 SLA's context for that point to point link. 671 In the simplest case where Provider (e.g. PE) and Customer (e.g. 672 CE) devices are directly connected via a physical link and have only 673 single link between them, CE can uniquely identify the forwarding 674 link to PE with AS number of the PE and NLRI prefix being an IP 675 address of PE, to CE (that is the next hop address from CE to PE). 676 SLA advertised thru BGP update message from PE to CE, with PE's AS 677 number and IP address, establishes SLA context for the aggregate 678 traffic through link CE to PE. SLA advertised thru BGP update 679 message from PE to CE, with PE's AS number and any other prefix 680 establishes SLA for that specific prefix, subset of traffic under CE 681 to PE link. 683 Even though this example is in the context of IP prefixes, SLA 684 exchange does not have to be limited to the IP address family only. 685 SLA advertisement is generic to all forms of NLRI types that are 686 supported by the BGP protocol specification (like IPv4, IPv6, VPN- 687 IPv4, VPN-IPv6). 689 4.1.1. SLA Advertisement for Point-to-Point Connection 691 When SLA messages are intended to be advertised for the point-to- 692 point connection (physical or logical), the message is destined for 693 the next hop and advertised message is in the context of the prefix 694 of the source end-point of the point to point connection. 696 The destination AS number set to, within QoS SLA attribute, typically 697 is of the neighbor BGP speaker's. Alternatively, the originator MAY 698 not encode source/destination AS numbers (that is the source AS is 699 set to 0 and destination AS count is set to 0), in the QoS attribute. 700 The most significant bit of the QoS attribute flag MAY be set to 1, 701 specifically it MUST be set to 1 when intention is to not install 702 route update, at the receiver, for the advertised message. 704 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 706 When SLA messages are to be advertised beyond next hop, value of 707 source AS, in the QoS attribute, MUST be set by the originator of the 708 update message. If such update is meant to be for a specific list of 709 AS(es) as receivers, then the list of destination AS MUST be 710 explicitly described in the QoS attribute message to avoid flooding 711 of the QoS attribute data in the network beyond those destinations. 713 When a new prefix is added in the AS, AS for which SLA parameters 714 have already been advertised before for other existing prefixes, and 715 if traffic to this new prefix is subject to the same SLA advertised 716 earlier then BGP update for this new prefix may include QoS attribute 717 containing just an SLA id, an id that was advertised earlier. The 718 corresponding Update message does not require to have the whole SLA 719 content. SLA id is sufficient to relate SLA parameters to new 720 advertised prefix. 722 When BGP update messages are triggered as a result of SLA policy 723 change and thus only for the purpose of SLA exchange, forwarding BGP 724 update messages beyond intended receivers are not necessary. Highest 725 order bit in the QoS Attribute flag MUST be set to suggest receiver 726 to drop entire BGP update message [Note that it is an indication to 727 drop entire update message, not only QoS attribute], after all 728 intended receivers have processed it. If update message contains a 729 list of destination ASes, then the message MUST be dropped only after 730 all intended receivers (destinations) have received it. 732 5. SLA Attribute Handling at Forwarding Nodes 734 5.1. BGP Node Capable of Processing QoS Attribute 736 If a BGP node is capable of processing QoS attribute, it optionally 737 MAY process the message. If advertised SLA has a list of destination 738 ASes, it MAY trim list and so count of destination AS to exclude ones 739 that are not required in further announcement of BGP updates. 741 BGP node MUST drop SLA related sub-type from the QoS attribute, if 742 none of the AS from the destination list is in the forwarding path. 743 The rest of the QoS attribute contents MAY be forwarded if there 744 exist other sub-types of QoS attribute and forwarding rules meets 745 other sub-types requirements. If there is no other sub-types in the 746 QoS attribute content then the node MUST drop the QoS attribute all 747 together. The other attributes and NLRI information may be announced 748 further if they meet rules defined by other attributes and BGP 749 protocol. 751 If the most significant bit in the QoS attribute flag is set to 1 752 then the entire BGP update message MUST be dropped if there are no 753 destinations left in the list to advertise to. 755 Except extracting the entire SLA sub-type of the QoS attribute and 756 trimming the list of destination AS list and inserting NLRI at the 757 Aggregator node, all other content MUST NOT be modified by any 758 intermediate receivers of the message. 760 5.2. BGP Node not Capable of Processing QoS Attribute 762 If the BGP node is not capable of processing QoS attribute, it MUST 763 forward the QoS attribute message unaltered. 765 5.3. Aggregator 767 It is RECOMMENDED to not aggregate prefixes from 2 or more BGP update 768 messages into one BGP update, when original messages contain the QoS 769 attribute with SLA sub-type contents. If Aggregator MUST aggregate 770 them then it MUST copy entire parameter set of an SLA sub-type from 771 the QoS attribute in the new aggregated BGP update message. At the 772 same time, it MUST also insert NLRI information, from the original 773 update message, as an optional advertiser id to go along with source 774 AS inside the QoS attribute. 776 To support SLA exchange multiple hops away in the path that has one 777 of the forwarding node acting as an Aggregator, it is required that 778 the Aggregator node is capable of processing the QoS attribute. 780 6. SLA Attribute Handling at Receiver 782 Reception of and processing of advertised QoS SLA content are 783 optional for the receiver. 785 While reacting to SLA advertisement 786 - receiver SHOULD invalidate previous advertised SLA parameters if 787 one exists for the same SLA id and source AS. If new advertised 788 SLA update is with non-zero Traffic Class count, new advertised 789 SLA SHOULD be installed. If new advertised SLA update is with 790 Traffic Class count 0, no action is required. 792 - If advertised QoS Attribute, inside an update message, is with a 793 flag set indicating to drop that message, a receiver MUST drop 794 message if it is the last receiver, in update path, that message 795 is advertised to. 797 If the advertised SLA is from the next hop, in the reverse path, the 798 receiver may implement advertised SLA for the whole link, the link 799 could be physical or virtual link, associated with the next hop. If 800 NLRI advertised in update message is not of the next hop, receiver 801 may establish advertised SLA for that specific prefix list under the 802 relevant link. It is completely up to the receiver to decide for 803 which prefixes it should accept advertised SLA and for which ones it 804 won't. 806 For cases where if earlier messages have not reached the intended 807 receiver yet, a re-signaling is required. A receiver may intend to 808 request an SLA message from the originator in such case. Since BGP 809 messages are considered reliable, it is assumed that advertised 810 messages always reach intended receivers. Thus discussion of REQUEST 811 message, for this purpose or any other purpose, is considered out of 812 the scope of this document. 814 To handle error conditions, the approach of "attribute-discard" as 815 mentioned in [IDR-ERR] MAY be used in the event QOS attribute parsing 816 results in any attribute errors. Alternatively, an approach of 817 "treat-as-withdraw" MAY be used as mentioned in [IDR-ERR] if an 818 implementation also wishes to withdraw the associated prefix. 820 6.1. Traffic Class Mapping 822 It is possible that switching/routing methods used in 2 different 823 ASes could be different. For example, Provider may tunnel Customer's 824 IP traffic thru MPLS cloud. In such cases traffic class definition 825 for QoS services may differ in both ASes. For the meaningful use of 826 advertised SLA in such cases, receiver is required to map traffic 827 class from one type to the other. 829 In the example given, traffic classification in Customer AS could be 830 IP Diffserv-based whereas traffic classification in Provider AS could 831 be MPLS TC-based. Thus for advertised MPLS TC-based SLA would 832 require to map traffic class from IP Diffserv-based to MPLS TC type. 834 There are well-defined recommendations that exist for traffic class 835 mapping between two technologies. Receiver MAY use those defined 836 recommendations for traffic class mapping or MAY define its own as 837 per its network Traffic Class service definition to map to advertised 838 Traffic Classes. It is completely up to the receiver how to define 839 such traffic class mapping. 841 7. Deployment Considerations 843 One of the use cases is for a Provider to advertise contracted SLA 844 parameters to Customer Edge (CE). The SLA parameters are provisioned 845 by the provider on the PE device (facing CE). This provisioned SLA 846 parameters are then advertised thru proposed BGP QoS attribute to the 847 CE device. CE device may read the attribute and SLA sub-type content 848 to implement the QoS policy on the device. 850 Contracted SLA from PE to CE may be full line-rate or sub line-rate 851 or finer granular controlled services. SLA advertise can be useful 852 when contracted service is sub-rate of a link and/or when for finer 853 granular traffic classes that are controlled (e.g. voice, video 854 services may be capped to certain rate) 856 _______________ 857 __________ / \ 858 / \ / \ 859 / \ / \ 860 |CustomerSite|-----| Provider | 861 \ C/E P\E / 862 \__________/ \ / 863 \_______________/ 864 AS 3 AS 2 866 SLA_ADVERTISE: AS2 to AS3 867 NLRI = PE ip address 869 Another use case can be to advertise SLAs among different network 870 sites within one Enterprise network. In Hub and Spoke deployments, 871 Administrator, being aware of each Spoke's SLA, may define SLAs for 872 each of them at the Hub and advertise them thru BGP updates, where at 873 each Spoke, advertised SLA may translate to a forwarding policy. In 874 a scale network, managing a large number of Spokes can be complex. 875 The proposal in such cases would be to provision SLA parameters at 876 the Hub only and distribute them to each Spoke with SLA exchange 877 protocol described here. 879 Alternatively, in a network that supports SLA parameters signaling 880 capabilities with the Provider, manual administration can be avoided 881 or minimized even at the Hub. As shown in the figure below, AS2 may 882 first learn its SLA with the Provider from the Provider Edge it is 883 connected to. AS2 can advertise the same or a subset of that SLA to 884 AS3 in the context of tunnel's ip address. 886 AS 2 887 _______________ ________ 888 / \ / \ 889 __________ / \-----| Spoke2 | 890 / \ / \ \________/ 891 | Hub |-----| Provider | ________ 892 \__________/ \ / / \ 893 \ /-----| Spoke1 | 894 AS 3 \_______________/ \________/ 896 AS 1 898 SLA_ADVERTISE: AS2 to AS3 899 NLRI = AS2 tunnel address 901 SLA_ADVERTISE: AS1 to AS3 902 NLRI = AS1 tunnel address 904 Deployment options are not limited to involving CEs, PE-to-CE or CE- 905 to-CE, only. For any contract between two providers, SLA parameters 906 may be advertised from one to the other. 908 8. Acknowledgements 910 Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for 911 their suggestions and to Christian Jacquenet, Ken Briley, Rahul 912 Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier for 913 the review. 915 9. IANA Considerations 917 The proposal in this document defines a new BGP attribute. IANA 918 maintains the list of existing BGP attribute types. A new type to be 919 added in the list for the QoS attribute. 921 The proposal also defines a list for Service types associated to 922 Traffic Class. IANA will be required to maintain this list for 923 Traffic Class Service type as a new registry. Where-as Traffic Class 924 Element types, defined in the proposal, refer to existing IPFIX IANA 925 types. 927 Proposed definition of Traffic Class Service Types 928 0x00 = reserved 929 0x01 = TRAFFIC_CLASS_TSPEC 930 0x02 = L2_OVERHEAD 931 0x03 = MINRATE_IN_PROFILE_MARKING 932 0x04 = MINRATE_OUT_PROFILE_MARKING 933 0x05 = MAXRATE_IN_PROFILE_MARKING 934 0x06 = MAXRATE_OUT_PROFILE_MARKING 935 0x07 = DROP_THRESHOLD 936 0x08 = RELATIVE_PRIORITY 937 0x09 = SUB_TRAFFIC_CLASSES 939 10. Security Considerations 941 There is a potential for mis-behaved AS to advertise wrong SLA, 942 stealing identity of another AS. This resembles to problems already 943 identified and resolved, in the routing world, thru reverse path 944 forwarding check. One proposal, inline to RPF, to resolve such 945 threats is to have each BGP speaker node, in the forwarding path, 946 perform reverse path check on source AS. Since we expect these 947 messages to originate and distributed in the managed network, there 948 should not be any risks for identity theft. Thus reverse path check 949 is not considered in this proposal nor have we considered any 950 alternates. Such solutions can be explored later if any such need. 952 11. References 954 11.1. Normative References 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 960 of Guaranteed Quality of Service", RFC 2212, 961 September 1997. 963 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 964 Protocol 4 (BGP-4)", RFC 4271, January 2006. 966 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 967 Networks (VPNs)", RFC 4364, February 2006. 969 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 970 STD 67, RFC 4506, May 2006. 972 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 973 Meyer, "Information Model for IP Flow Information Export", 974 RFC 5102, January 2008. 976 11.2. Informative References 978 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 979 and W. Weiss, "An Architecture for Differentiated 980 Services", RFC 2475, December 1998. 982 [IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 983 "Revised Error Handling for BGP UPDATE Message, 984 I-D.draft-ietf-idr-error-handling", June 2012. 986 [CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS 987 Connectivity Provisioning Profile, I-D.boucadair- 988 connectivity-provisioning-profile", Sep 2012. 990 [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 991 Negotiation Protocol (CPNP), I-D.boucadair-connectivity- 992 provisioning-protocol", May 2013. 994 Authors' Addresses 996 Shitanshu Shah 997 Cisco Systems 998 170 W. Tasman Drive 999 San Jose, CA 95134 1000 US 1002 Email: svshah@cisco.com 1004 Keyur Patel 1005 Cisco Systems 1006 170 W. Tasman Drive 1007 San Jose, CA 95134 1008 US 1010 Email: keyupate@cisco.com 1011 Sandeep Bajaj 1012 Juniper Networks 1013 1194 N. Mathilda Avenue 1014 Sunnyvale, CA 94089 1015 US 1017 Email: sbajaj@juniper.net 1019 Luis Tomotaki 1020 Verizon 1021 400 International 1022 Richardson, TX 75081 1023 US 1025 Email: luis.tomotaki@verizon.com 1027 Mohamed Boucadair 1028 France Telecom 1029 Rennes 35000 1030 France 1032 Email: mohamed.boucadair@orange.com