idnits 2.17.1 draft-ietf-idr-sla-exchange-10.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 28, 2017) is 2646 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) == Unused Reference: 'RFC2434' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'RFC6793' is defined on line 1301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Downref: Normative reference to an Informational RFC: RFC 7132 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-22 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7674 (Obsoleted by RFC 8955) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Shah 3 Internet-Draft 4 Intended status: Standards Track K. Patel 5 Expires: August 1, 2017 Arrcus, Inc 6 S. Bajaj 7 Viptela 8 L. Tomotaki 9 Verizon 10 M. Boucadair 11 Orange 12 January 28, 2017 14 Inter-domain SLA Exchange Attribute 15 draft-ietf-idr-sla-exchange-10.txt 17 Abstract 19 Network administrators typically enforce Quality of Service (QoS) 20 policies according to Service Level Agreement (SLA) with their 21 providers. The enforcement of such policies often relies upon 22 vendor-specific configuration language. Both learning of SLA, either 23 thru SLA documents or via some other out-of-band method, and 24 translating them to vendor specific configuration language is a 25 complex, often manual, process and prone to errors. 27 This document specifies an optional transitive attribute to signal 28 SLA parameters in-band, across administrative boundaries (considered 29 as Autonomous Systems (AS)), thus simplifying and facilitating some 30 of the complex provisioning tasks in situations where BGP is 31 available as a routing protocol. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 1, 2017. 50 Copyright Notice 52 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 5 70 3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6 71 3.2. SLA SubType . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. SLA Content for ADVERTISE SLA Event . . . . . . . . . . . 9 73 3.3.1. Supported IPFIX identifiers for Traffic Class 74 Elements . . . . . . . . . . . . . . . . . . . . . . 13 75 3.3.2. Traffic Class Service types and respective TLVs . . . 14 76 4. Originating SLA Notification . . . . . . . . . . . . . . . . 21 77 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 21 78 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21 79 4.1.2. SLA Advertisement for Destination AS Multiple Hops 80 Away . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 22 82 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 23 83 5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 23 84 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 85 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 91 11.2. Informative References . . . . . . . . . . . . . . . . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 94 1. Introduction 96 Typically there is a contractual Service Level Agreement (SLA) for 97 QoS established between a customer and a provider or between 98 providers [RFC7297]. This QoS SLA defines the nature of the various 99 traffic classes and services needed within each traffic class. The 100 contract may include full line-rate or sub line-rate without 101 additional traffic classes, or it may contain additional traffic 102 classes and service definitions for those traffic classes. Finer 103 granular traffic classes may be based on some standard code points 104 (e.g., based on DSCP (Differentiated Services Code Point)) or 105 specific set of prefixes. 107 Once the contractual QoS SLA is established, QoS SLA parameters are 108 enforced in some or all participating devices by deriving those 109 parameters into configuration information on respective devices. The 110 network administrator translates the QoS SLA to QoS policies using 111 router (vendor) specific provisioning language. In a multi-vendor 112 network, translating SLAs into technology-specific and vendor- 113 specific configuration requires the network administrator to consider 114 specific configuration of each vendor. There does not exist any 115 standard protocol to translate SLA agreements into technical clauses 116 and configurations and thus both the steps of out of band learning of 117 negotiated SLA and provisioning them in a vendor specific language 118 can be complex and error-prone. 120 SLA parameters may have to be exchanged through organizational 121 boundaries, thru SLA documents or via some other off-band method, to 122 an administrator provisioning actual devices. For example, to 123 provide voice services, the provider may negotiate QoS parameters 124 (like min/max rates) for such traffic classified under the EF 125 (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475] 126 networks. The Administrator at the CE (Customer Edge) not only will 127 have to know that provider's service for voice traffic is EF-based 128 but will also have to know how to implement DSCP EF classification 129 rule along with Low Latency Service, and possibly min/max rate 130 enforcement for the optimal use of bandwidth, as per vendor specific 131 provisioning language. 133 The Inter-domain exchange of QoS SLA policy described in this 134 document does not require any specific method for the provider in 135 establishing SLAs. It only requires that the provider wishes to send 136 the QoS SLA policy via BGP UPDATE [RFC4271] messages from the 137 provider to a set of receivers (BGP peers). In reaction to, a 138 receiving router may translate that to relevant QoS policy definition 139 on the device. The SLA negotiation and assurance is outside the 140 scope of this document. 142 This document defines a new optional BGP transitive attribute, 143 referred as QoS Attribute, which has as one of its sub-types the SLA 144 policy. The BGP node of the originating AS sends this QoS Attribute, 145 for prefixes this QoS SLA Policy applies to, in a BGP UPDATE message 146 that will be distributed to a list of destination ASes. The QoS SLA 147 policy can be for inbound traffic to the advertising AS or outbound 148 traffic from the advertising AS, or both. 150 Protocols and data models are being created to standardize setting 151 routing configuration parameters within networks. YANG data models 152 [RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf 153 ([I-D.ietf-netconf-restconf]) can set these standardize in 154 configuration mechanisms. For ephemeral state, the I2RS protocol is 155 being developed to set ephemeral state. While these protocols 156 provide valid configuration within a domain or across domains, some 157 providers desire to exchange QoS parameters in-band utilizing BGP 158 peering relationships. This is similar to the distribution of Flow 159 Specification information via BGP peering relationships (see 160 [RFC5575] and [RFC7674]). 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 BGP Speaker: A functional component on a BGP capable device that 169 functions as per BGP specification. 171 BGP Peers: BGP Speakers adjacent to each other. 173 QoS Attribute Speaker: A functional component on a BGP capable device 174 that produces and/or processes content of the QoS Attribute. A 175 device that is QoS Attribute Speaker is also always a BGP Speaker. 176 However, a BGP Speaker not necessarily always a QoS Attribute 177 Speaker. 179 QoS Attribute content is produced and processed outside the function 180 of the BGP Speaker and thus content of the QoS Attribute is 181 completely opaque to the BGP Speaker. At BGP capable device where 182 QoS Attribute content is produced, length and value of the QoS 183 Attribute is passed from QoS Attribute Speaker to the BGP Speaker 184 where BGP Speaker inserts the attribute into the BGP UPDATE message 185 with appropriate attribute flags, attribute type, and length and 186 value passed from the QoS Attribute Speaker. Similarly, a BGP 187 capable device when receives QoS Attribute in the BGP UPDATE message, 188 BGP Speaker extracts QoS Attribute value from the message and passes 189 it to the QoS Attribute Speaker where QoS Attribute Speaker processes 190 the content from that passed down value. How the content of the QoS 191 Attribute is passed from the QoS Attribute Speaker to the BGP Speaker 192 and vice versa is implementation specific. 194 In the context of use of QoS Attribute for SLA parameters exchange, 195 following roles are defined further within the scope of the QoS 196 Attribute Speaker. 198 SLA Producer: This is a QoS Attribute Speaker that produces QoS 199 Attribute for the SLA SubType. 201 SLA Consumer: This is a QoS Attribute Speaker that is intended 202 receiver of QoS Attribute with the SLA SubType. 204 3. QoS Attribute Definition 206 The QoS Attribute is an optional transitive attribute (TBD - 207 attribute code to be assigned by IANA) which is applicable to the 208 Source AS and NLRIs advertised in the BGP UPDATE message this 209 attribute is included in. The format of the QoS Attribute is shown 210 in Figure 1. 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 | Attr flag | Attr type QoS | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 217 ~ ~ 218 | QoS Attr length/value | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 221 Figure 1 223 Attribute flags - 8-bits field 225 highest order bit (bit 0) - MUST be set to 1, since this is an 226 optional attribute 228 2nd higher order bit (bit 1) - MUST be set to 1, since this is a 229 transitive attribute 231 The content of the QoS Attribute is further specified with flags, 232 applicable to QoS Attribute content, and a SubType in a TLV form. 234 3.1. QoS Attribute SubType 236 The Value field of the QoS Attribute contains the following: 238 QoS Attribute flags 240 Tuple (SubType of the QoS Attribute, SubType length, SubType 241 value) 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | QoS Attr flags| SubType | SubType length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 ~ ~ 249 | SubType value | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+ 252 Figure 2 - Format of QoS Attribute 254 QoS Attr flags - 8-bits field 256 All bits of this field are currently un-used. The space is 257 provided for future use. All bits MUST be set to zero when sent. 258 The values (0x01-0xFF) are reserved, and MUST be ignored when 259 received. 261 SubType - 8-bits field with following values: 263 0x00 = reserved 265 0x01 = SLA 267 0x02 - 0xf0 = reserved for future use (Standards Action) 269 0xf1 - 0xff = Private use 271 The only SubType of the QoS Attribute defined in this 272 specification is the SLA SubType. 274 SubType length - 16-bits field that specifies length of the SubType 275 value in number of octets. 277 SubType value - variable length field, as expressed in SubType 278 length, that contains information about a specified SubType. For 279 the SLA SubType the information is about sender and receiver(s), 280 and SLA parameters as described in Section 3.2. 282 3.2. SLA SubType 284 Format of the SLA SubType Value field is shown in Figure 3. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | SLA SubType flags | Destination AS count | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Source AS (Advertiser) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | variable list of Destination AS | 294 ~ .... ~ 295 | .... | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |SLAEvnt| SLA ID | SLA length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | SLA Content for SLA Event | 300 ~ ~ 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3 - Format of the SLA SubType of the QoS attribute 306 SLA SubType flags - 16-bits field 308 highest order bit (bit 0) - 310 If set to 1 indicates that SLA ID and SLA Content, specified in 311 this SLA SubType, is from the source AS to the list of 312 Destination AS specified in the same SLA SubType. 314 If set to 0 indicates to ignore Source AS and list of 315 Destination AS specified in this SLA SubType field. SLA ID and 316 SLA Content, specified in this SLA SubType, are intended for 317 the peer receiver of the BGP UPDATE message. In such a case, 318 on reception of such a message, QoS Attribute Speaker SHOULD 319 drop the QoS Attribute from the BGP UPDATE message and rest of 320 the BGP UPDATE message should be processed by BGP Speaker as 321 per BGP specification. 323 Rest all other bits are currently un-used. 325 Destination AS count - 16-bits field that specifies count of 326 destination ASNs present in the Destination AS list. 328 This count has no functional value when highest order bit in the 329 SLA SubType flags field is set to 0. When highest order bit is 330 set to 1 and if this count is 0 then that is an error condition 331 which should be handled as described in Section 6. 333 Source AS - 32-bits field (AS number space as defined in RFC6793) 335 This is the AS where SLA Content is originated from. The Source 336 AS MUST be of the same AS that is originating SLA ID and SLA 337 Content. 339 When highest order bit in the SLA SubType flags field is set to 0, 340 this Source AS value MUST be ignored. In such a case SLA ID and 341 SLA Content of this SLA SubType is intended for the peer receiver 342 of the BGP UPDATE message. 344 When highest order bit in the SLA SubType flags field is set to 1, 345 the Source AS value of 0 is illegal and thus should be considered 346 an error which should be handled as described in Section 6. 348 Destination AS list - variable length field that holds as many ASN 349 identifiers, each is 32-bits (AS number space is defined in 350 RFC6793), as specified in the Destination AS count field. 352 List of ASNs for which the SLA is relevant to, each of which is a 353 32-bit number. If Destination AS count is set to 0 then this 354 field MUST NOT be included. 356 SLA Event - 4-bits field with following values: 358 0x0 = reserved 360 0x1 = ADVERTISE 362 0x2 to 0xf = Reserved for future use 364 The only SLA Event defined in this specification is ADVERTISE. 366 SLA ID - 16-bits field that specifies identifier which is unique in 367 the scope of Source AS. 369 The significance of an SLA ID is in the context of the source that 370 is advertising SLA Content. The SLA ID is not globally unique but 371 it MUST be unique within the source AS. 373 The SLA ID applies to aggregate traffic to prefixes for a given 374 AFI/SAFI that share the same Source AS and SLA ID. 376 If an advertised SLA ID is different from earlier advertised one, 377 for the same prefix and from the same Source AS, indicates Source 378 AS is advertising new SLA Content to replace the previous one 379 advertised with the same SLA ID. 381 SLA Length - 12-bits field that specifies the length of the SLA 382 Content. The length is expressed in octets. The SLA Content is 383 optional for an advertised SLA ID. If the SLA Content need not be 384 there, the SLA length field MUST be set to zero in such a case. 386 SLA Content - A variable length field (optional field) 388 The SLA Content field contains SLA parameters relevant to 389 specified SLA SubType. Since the only defined SLA SubType is 390 ADVERTISE, this specification describes SLA Content only for the 391 ADVERTISE SLA Event. 393 If SLA Content field exists in a BGP UPDATE message that contains 394 the QoS Attribute with an SLA SubType for SLA Event ADVERTISE, 395 format of the SLA Content is as described in Section 3.3. 397 If the SLA Content field does not exist, then the advertised 398 message refers to SLA Content advertised in the previous message 399 for the same SLA ID. If there does not exist any prior SLA 400 Content to relate to the advertised SLA ID, then receiver, SLA 401 Consumer, can ignore the SLA advertisement and it may simply 402 update Destination AS count and Destination AS list. 404 The lack of a valid prior SLA Content field does not make this 405 attribute invalid, so the QoS Attribute MUST be forwarded as a 406 valid BGP optional transitive attribute. 408 3.3. SLA Content for ADVERTISE SLA Event 410 The only SLA Event described in this specification is ADVERTISE. The 411 format of SLA Content for the ADVERTISE Event is shown in Figure 4. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |dir| Traffic Class count | Class Desc Len| | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 418 | | 419 ~ Traffic Class Description ~ 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Element Count | | 423 +-+-+-+-+-+-+-+-+ ~ 424 | | 425 ~ Traffic Class Element TLVs ~ 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Service Count| | 429 +-+-+-+-+-+-+-+-+ ~ 430 | Traffic Class Service TLVs | 431 ~ ~ 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 ~ Repeat from Traffic Class Description for next Traffic Class ~ 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 ~ Repeat from direction for SLA in the other direction ~ 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4 - SLA-Content for ADVERTISE SLA Event 445 SLA Content contains set of Traffic Class Elements (Classifiers) and 446 Traffic Class Service TLVs for a list of Traffic Classes. This list 447 of Traffic Classes MUST be specified for one direction first and then 448 optionally followed by the specification for the other direction. 450 dir (Direction) - 2-bits field that specifies Direction of the 451 traffic SLA is applicable to. The following values are defined: 453 0x0 = reserved 455 0x1 = incoming, traffic to source AS from destination AS 457 0x2 = outgoing, traffic from source AS towards destination AS 459 0x3 = for future use 461 Traffic Class (Classifier Group) count - 16 bits field that 462 specifies number of Traffic Classes. 464 The value of zero (0x00) in this field is a special value which 465 means no SLA for the traffic in a specified direction. When 466 Traffic Class count is 0, for a specific direction, the rest of 467 the SLA Content fields MUST NOT be encoded, for that specific 468 direction. 470 Traffic Class Description Len - 8-bits field that specifies the 471 length of the Traffic Class Description field. The length is 472 expressed in octets. 474 The value of zero in this field indicates that no Traffic Class 475 Description field follows. 477 Traffic Class Description - variable length field, as expressed in 478 The Traffic Class Description Len field, MUST carry UTF-8 encoded 479 [RFC3629] description. 481 Traffic Class Elements (Classifier) Count - 8-bits field that 482 specifies the count of Traffic Class Elements. 484 The value zero (0x00) means there are no Traffic Class Elements in 485 the traffic class, and thus the Traffic Class is to classify rest 486 of the traffic not captured otherwise by other Traffic Classes in 487 the set for a specified direction. 489 Traffic Class that has 0 elements MUST be presented last in the 490 advertised list of Traffic Classes for a specific Direction. 491 Otherwise it is considered an error condition which should be 492 handled as described in Section 6. 494 The QoS Attribute advertised from a specific source MUST NOT 495 have more than one such Traffic Classes (Traffic Class with 0 496 elements count). If there are more than one such Traffic 497 Classes present then it is an error condition which should be 498 handled as described in Section 6. 500 Traffic Class Element TLVs - (optional) variable length field 501 holding as many TLVs specified by the Traffic Class Elements Count 502 field. Each TLV has the following format: 504 IPFIX Element Identifier - 8-bits field that specifies IPFIX 505 Identifiers listed in Table 1. 507 Length of Value field - 8-bits field that specifies the length, 508 expressed in octets, of the value field. 510 Value - A variable field that specifies a value appropriate for 511 the IPFIX Element Identifier. It is an error, if the value 512 field does not contain the appropriate format, which should be 513 handled as described in Section 6. Only the IPFIX elements 514 shown in Table 1 are supported. 516 Any Traffic Class Element advertised in the QoS Attribute only 517 applies to the advertised AFI/SAFI NLRI within the BGP UPDATE 518 message the QoS Attribute is contained in. If a receiver, SLA 519 Consumer, receives a BGP UPDATE message with QoS Attribute for an 520 unsupported AFI/SAFI then SLA Consumer MAY ignore advertised SLA. 521 SLA Consumer MAY update only Destination AS count and Destination 522 AS list, and then QoS Attribute and rest of the BGP UPDATE message 523 MUST be forwarded as per QoS Attribute and BGP protocol 524 specification. 526 Traffic Class Service Count - 8-bits field that specifies count of 527 Traffic Class Service TLVs. 529 A value of zero is a special value indicating "no bounded service" 530 (a.k.a., Best Effort (BE)). 532 Traffic Class Service TLVs - (optional) variable length field with 533 the following format for the TLVs 535 Traffic Class Service type - 16-bits field that specifies a 536 service type. Each service type is detailed in Section 3.3.2. 537 The list of available service types are, 539 0x00 = reserved 541 0x01 = TRAFFIC_CLASS_TSPEC 543 0x02 = L2_OVERHEAD 545 0x03 = MINRATE_IN_PROFILE_MARKING 547 0x04 = MINRATE_OUT_PROFILE_MARKING 549 0x05 = MAXRATE_IN_PROFILE_MARKING 551 0x06 = MAXRATE_OUT_PROFILE_MARKING 553 0x07 = DROP_THRESHOLD 555 0x08 = RELATIVE_PRIORITY 557 0x09 = SUB_TRAFFIC_CLASSES 559 Length of Value field - 08-bits field that specifies the length 560 of the value field. The length of the value is expressed in 561 octets. 563 Value - a variable length field that specifies the value 564 appropriate for each of the Service Types. It is an error, if 565 this field does not contain the appropriate format, which 566 should be handled as described in Section 6. The format of the 567 value for each of the service types is described in 568 Section 3.3.2 570 3.3.1. Supported IPFIX identifiers for Traffic Class Elements 572 IPFIX [RFC7012] has well defined identifier set for a large number of 573 packet attributes; an IPFIX IANA registry maintains values for packet 574 classifier attributes (https://www.ietf.org/assignments/ipfix/ 575 ipfix.xml#ipfix-information-elements). Only the IPFIX attributes 576 listed in Table 1 are supported. Any new attribute to be supported 577 by SLA SubType MUST be a Standards Action as described in IANA 578 section. 580 +----+----------------------------+ 581 | ID | Name | 582 +----+----------------------------+ 583 |195 | ipDiffServCodePoint | 584 |203 | mplsTopLabelExp | 585 |244 | dot1qPriority | 586 | 8 | sourceIPv4Address | 587 | 27 | sourceIPv6Address | 588 | 9 | sourceIPv4PrefixLength | 589 | 29 | sourceIPv6PrefixLength | 590 | 44 | sourceIPv4Prefix | 591 |170 | sourceIPv6Prefix | 592 | 12 | destinationIPv4Address | 593 | 28 | destinationIPv6Address | 594 | 13 | destinationIPv4PrefixLength| 595 | 30 | destinationIPv6PrefixLength| 596 | 45 | destinationIPv4Prefix | 597 |169 | destinationIPv6Prefix | 598 | 4 | protocolIdentifier | 599 | 7 | sourceTransportPort | 600 | 11 | destinationTransportPort | 601 +----+----------------------------+ 603 Table 1 605 3.3.2. Traffic Class Service types and respective TLVs 607 3.3.2.1. TRAFFIC_CLASS_TSPEC 609 The TRAFFIC_CLASS_TSPEC TLV definition: 611 Type - 0x01 613 Length - 8-bits field that specifies length, expressed in octets, 614 of the value field. The length of the value field MUST be 615 specified to be 12 octets to hold the value defined as per format 616 below. 618 Value - TRAFFIC_CLASS_TSPEC value consists of the (r), (b), (p) 619 parameters as described in Invocation Information section of 620 [RFC2212] and shown in Figure 5. Note that inheriting the 621 definition of TSPEC (Traffic SPECification) here does not enable 622 RFC2212 functionality. Only the format of the Traffic 623 Specification is used in this specification. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Minimum Rate (r) (32-bit IEEE floating point number) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Burst Size (b) (32-bit IEEE floating point number) | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Maximum Rate (p) (32-bit IEEE floating point number) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Figure 5 - Traffic Class TSPEC 637 Format of Parameters (r), (b) and (p): are 32-bit IEEE floating 638 point numbers. Positive infinity is represented as an IEEE single 639 precision floating-point number with an exponent of all ones and a 640 sign mantissa of all zeros. The format of IEEE floating-point 641 numbers is further summarized in [RFC4506]. 643 Parameter (r): indicates min-rate of the traffic class. This rate 644 indicates the minimum rate, measured in octets of Layer 2 (L2) 645 datagrams per second (a.k.a, bytes per second), that the service 646 advertiser is providing for a given class of traffic on 647 advertiser's hop. Note that it does not necessarily translate to 648 a minimum rate service to the receiver of an SLA unless the 649 traffic class definition clearly represents a sole receiver of an 650 SLA. If there is no SLA for min-rate, the value of (r) MUST be 651 set to 0. 653 Parameter (b): indicates maximum burst size, measured in octets of 654 L2 datagram size. Since queuing delay can be considered a 655 function of burst size (b) and min-rate (r), in presence of non- 656 zero parameter (r), parameter (b) represents bounded delay for the 657 Traffic Class. This delay is a single hop queuing delay when SLA 658 is to be implemented at the resource constrained bottleneck. In 659 other words this burst size can be considered as a buffer size. 660 Value of 0 for parameter (b) means the advertiser does not mandate 661 specific bounded delay. 663 Parameter (p): indicates max-rate of the traffic class. Just like 664 min-rate, max-rate, measured in octets of L2 datagrams per second 665 (a.k.a., bytes per second), field here also indicates service 666 provided by advertiser. If advertiser does not have any specific 667 value to set for a given class of traffic, it MAY be set to 668 physical interface line rate or any other indirect limit that may 669 affect this class' maximum rate. In absence of any such known 670 value, it MUST be set to positive infinity. Value 0 is considered 671 an error which should be handled as described in Section 6. 673 3.3.2.2. L2_OVERHEAD 675 The L2_OVERHEAD TLV definition: 677 Type - 0x02 679 Length - 8-bits field that specifies length, expressed in octets, 680 of the value field. 682 Value - Layer 2 overhead in octets 684 L2_OVERHEAD defines Layer 2 (L2) specific data in octets, on top of 685 IP datagram size, in a layer 2 frame. By default the rate and burst 686 advertised in the TRAFFIC_CLASS_TSPEC TLV are applicable to the 687 packet size including L2 packet overhead. For the SLA Consumer 688 directly connected to the SLA Producer, this overhead is the L2 689 overhead of the local link where advertised SLA is received. 691 However, in cases where advertised SLA is for a SLA Consumer multiple 692 hops away, L2 overhead from the source, SLA Producer, perspective may 693 be different from the local link L2 overhead at the receiver, SLA 694 Consumer. In such cases, explicit notification of size of L2 695 overhead from the SLA Producer suggests what per packet L2 overhead 696 is applicable to the rate and burst advertised in the 697 TRAFFIC_CLASS_TSPEC TLV. L2_OVERHEAD TLV SHOULD BE ignored by the 698 SLA Consumer if there does not exist TRAFFIC_CLASS_TSPEC TLV for the 699 specified direction. 701 Advertised L2 value of 0 means SLA advertised is for IP packet size. 703 3.3.2.3. MINRATE_IN_PROFILE_MARKING 705 This Traffic Class Service Type defines action performed, by the SLA 706 Producer, on packets that are compliant to the min-rate specified in 707 the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the 708 TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service 709 Type SHOULD NOT be advertised. MINRATE_IN_PROFILE_MARKING TLV SHOULD 710 BE ignored by the SLA Consumer if there does not exist 711 TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate 712 specified in the TRAFFIC_CLASS_TSPEC TLV is 0. 714 The MINRATE_IN_PROFILE_MARKING TLV definition: 716 Type - 0x03 718 Length - 8-bits field that specifies length, expressed in octets, 719 of the value field. The length of the value field MUST be 720 specified to be 2 octets to hold the value defined as per format 721 below. 723 Value - contains the Marking code-point type and value 725 Marking code-point type - 8-bits IPFIX Element Identifier. 727 Marking code-point value - 8-bits code-point number. 729 The marking code-point type of 0x00 is a drop identifier. When 730 marking code-point type value is 0x00 (that is drop), the marking 731 code-point value in this case has no meaning and thus the value in 732 this field should be ignored. 734 The following table lists the supported IPFIX Identifiers. Any value 735 other than 0 or identifier from the following table is an error 736 condition which should be handled as described in Section 6. 738 +----+----------------------------+ 739 | ID | Name | 740 +----+----------------------------+ 741 |195 | ipDiffServCodePoint | 742 |203 | mplsTopLabelExp | 743 |244 | dot1qPriority | 744 +----+----------------------------+ 746 Table 2 748 3.3.2.4. MINRATE_OUT_PROFILE_MARKING 750 This Traffic Class Service Type defines action performed, at the SLA 751 Producer, on packets that are not compliant to the min-rate specified 752 in the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the 753 TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service 754 Type SHOULD NOT be advertised. MINRATE_OUT_PROFILE_MARKING TLV 755 SHOULD BE ignored by the SLA Consumer if there does not exist 756 TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate 757 specified in the TRAFFIC_CLASS_TSPEC TLV is 0. 759 The MINRATE_OUT_PROFILE_MARKING TLV definition: 761 Type - 0x04 763 Length - 8-bits field that specifies length, expressed in octets, 764 of the value field. The length of the value field MUST be 765 specified to be 2 octets to hold the value defined as per format 766 below. 768 Value - contains the Marking code-point type and value 770 Marking code-point type - 8-bits IPFIX Element Identifier 772 Marking code-point value - 8-bits code-point number 774 The marking code-point type of 0x00 is a drop identifier. When 775 marking code-point type value is 0x00 (that is drop), the marking 776 code-point value in this case has no meaning and thus the value in 777 this field should be ignored. 779 Table 2 lists the supported IPFIX Identifiers. Any value other than 780 0 or identifier from the Table 2 is an error condition which should 781 be handled as described in Section 6. 783 3.3.2.5. MAXRATE_IN_PROFILE_MARKING 785 This Traffic Class Service Type defines action performed, at the SLA 786 Producer, on packets that are compliant to the max-rate specified in 787 the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_IN_PROFILE_MARKING TLV SHOULD 788 BE ignored by the SLA Consumer if there does not exist 789 TRAFFIC_CLASS_TSPEC TLV for the specified direction. 791 The MAXRATE_IN_PROFILE_MARKING TLV definition: 793 Type - 0x05 794 Length - 8-bits field that specifies length, expressed in octets, 795 of the value field. The length of the value field MUST be 796 specified to be 2 octets to hold the value defined as per format 797 below. 799 Value - contains the Marking code-point type and value 801 Marking code-point type - 8-bits IPFIX Element Identifier 803 Marking code-point value - 8-bits code-point number 805 The marking code-point type of 0x00 is a drop identifier. When 806 marking code-point type value is 0x00 (that is drop), the marking 807 code-point value in this case has no meaning and thus the value in 808 this field should be ignored. 810 Table 2 lists the supported IPFIX Identifiers. Any value other than 811 0 or identifier from the Table 2 is an error condition which should 812 be handled as described in Section 6. 814 3.3.2.6. MAXRATE_OUT_PROFILE_MARKING 816 This Traffic Class Service Type defines action performed, at the SLA 817 Producer, on packets that are not compliant to the max-rate specified 818 in the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_OUT_PROFILE_MARKING TLV 819 SHOULD BE ignored by the SLA Consumer if there does not exist 820 TRAFFIC_CLASS_TSPEC TLV for the specified direction. 822 The MAXRATE_OUT_PROFILE_MARKING TLV definition: 824 Type - 0x06 826 Length - 8-bits field that specifies length, expressed in octets, 827 of the value field. The length of the value field MUST be 828 specified to be 2 octets to hold the value defined as per format 829 below. 831 Value - contains the Marking code-point type and value 833 Marking code-point type - 8-bits IPFIX Element Identifier 835 Marking code-point value - 8-bits code-point number 837 The marking code-point type of 0x00 is a drop identifier. When 838 marking code-point type value is 0x00 (that is drop), the marking 839 code-point value in this case has no meaning and thus the value in 840 this field should be ignored. 842 Table 2 lists the supported IPFIX Identifiers. Any value other than 843 0 or identifier from the Table 2 is an error condition which should 844 be handled as described in Section 6. 846 3.3.2.7. Precedence between MINRATE and MAXRATE 848 The precedence between MINRATE_IN_PROFILE_MARKING, 849 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and 850 MAXRATE_OUT_PROFILE_MARKING when all four are advertised is: 852 - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is 853 over MAXRATE_IN_PROFILE_MARKING), 855 - MAXRATE_IN_PROFILE_MARKING takes precedence over 856 MINRATE_OUT_PROFILE_MARKING, and 858 - MAXRATE_OUT_PROFILE_MARKING takes precedence over 859 MINRATE_OUT_PROFILE_MARKING 861 3.3.2.8. DROP_THRESHOLD 863 The DROP_THRESHOLD TLV definition: 865 Type - 0x07 867 Length - 8-bits field that specifies length, expressed in octets, 868 of the value field. 870 Value - Count of drop thresholds, followed by content for each 871 drop threshold in the form of (code-point type, count of code- 872 points, list of code-points, threshold value). 874 Count of drop thresholds - 8-bits field that specifies number 875 of drop thresholds specified in this TLV. Content of each drop 876 threshold is to follow following format 878 Code-point type - 8-bits IPFIX Element Identifier from the list 879 shown in Table 6. 881 Count of code-points - 8-bits field that specifies number of 882 code-point values to follow for a specified code-point type. 884 List of code-points - each code-point value is specified in 885 size of 8 bits and thus total size for this field is 8 bits 886 multiplied by as many number of code-points specified. 888 Burst value - This is a fixed size 32-bits IEEE floating point 889 number that specifies burst value in unit of bytes. 891 +----+----------------------------+ 892 | ID | Name | 893 +----+----------------------------+ 894 |195 | ipDiffServCodePoint | 895 |203 | mplsTopLabelExp | 896 |244 | dot1qPriority | 897 +----+----------------------------+ 899 Table 3 901 3.3.2.9. RELATIVE_PRIORITY 903 The RELATIVE_PRIORITY TLV definition: 905 Type - 0x08 907 Length - 8-bits field that specifies length, expressed in octets, 908 of the value field. Given supported range of priority values in 909 this specification, the length of the value field MUST be limited 910 to and thus MUST be specified exactly as 1 octet. 912 Value - A value from range of 0 - 255. Lower the value means 913 higher the priority 915 Relative priority indicates scheduling priority of this traffic 916 class. Voice traffic, for example, which requires lowest latency 917 compared to any other traffic, may have lowest value advertised in 918 relative priority. For two different traffic classification groups 919 where one application group may be considered more important than the 920 other but from a scheduling perspective does not require to be 921 distinguished with a different priority, relative priority for those 922 classification groups may be advertised with the same value. 924 3.3.2.10. SUB_TRAFFIC_CLASSES 926 The SUB_TRAFFIC_CLASSES TLV definition: 928 Type - 0x09 930 Length - 16-bits field that specifies total length, expressed in 931 octets, of a subset of Traffic Class TLVs encoded in the value 932 field 934 Value - A subset of Traffic Class TLVs 936 For SLAs where a specific Traffic Class may further be defined by a 937 subset of more granular Traffic Classes, each with its own set of 938 Traffic Class Elements and Service types definitions, 939 SUB_TRAFFIC_CLASSES service type SHOULD be used to specify them. 941 4. Originating SLA Notification 943 The QoS Attribute for the SLA SubType MUST only be added to the BGP 944 UPDATE message at the node that is SLA Producer. Any QoS Attribute 945 Speaker, in the path to the SLA Consumer MUST NOT modify content of 946 that attribute except modification of the Destination AS list. 948 QoS Attribute with the SLA SubType SHOULD NOT be advertised 949 periodically just for the purpose of KEEPALIVE between SLA Producer 950 and SLA Consumer. Some sort of SLA policy change, at the SLA 951 Producer, may be considered as a trigger for the advertisement. 953 For any modified SLA policy at the SLA Producer, SLA Producer MUST 954 re-advertise the entire set of SLA parameters. There is no provision 955 to advertise partial set of SLA parameters. If modified SLA policy 956 is to mean no SLA between SLA Producer and SLA Consumer, then SLA 957 Content MUST be sent with the same SLA ID with the same AS Source and 958 NLRI prefix, as were used to advertise earlier SLA parameters, and 959 the Traffic Class count set to 0. 961 4.1. SLA Contexts 963 4.1.1. SLA Advertisement for Point-to-Point Connection 965 In certain cases, the advertisement of an SLA is intended to relate 966 to aggregate traffic over a point-to-point connection between a 967 specific destination and a specific source. A point-to-point 968 connection may be a physical link or a virtual link (e.g. a tunnel). 969 In such cases, a BGP UPDATE message with source AS number and NLRI 970 prefix as an IP address of an SLA Producer can uniquely identify 971 physical/virtual link in order to establish the context for the 972 advertised SLA for that point to point link. 974 In the simplest case where Provider (e.g., PE) and Customer (e.g., 975 CE) devices are directly connected via a physical link and have only 976 a single link between them, the CE can uniquely identify the 977 forwarding link to the PE with the following: 979 o AS number of the PE, 981 o NLRI prefix being an IP address of the PE, that is the next hop 982 address from CE to PE. 984 The SLA advertised in the QoS Attribute in the BGP UPDATE message 985 sent from the PE to a CE, along with the PE's AS number and PE's IP 986 address, establishes SLA context for the aggregate traffic through 987 CE-to-PE link. 989 The SLA advertised in the QoS Attribute in the BGP UPDATE message 990 from PE to CE, with PE's AS number and any other prefix, means SLA 991 for that specific prefix based traffic, a subset of traffic through 992 CE-to-PE link. 994 Even though this example is in the context of IP prefixes, QoS 995 Attribute's SLA exchange does not have to be limited to the IP 996 address family (IPv4 and IPv6). SLA advertisement is generic to all 997 forms of NLRI types that are supported by the BGP specification (like 998 IPv4, IPv6, VPN-IPv4, VPN-IPv6). 1000 When BGP UPDATE message with the QoS Attribute, containing SLA 1001 SubType, is triggered for a point-to-point connection (physical or 1002 logical), the Source AS number in the SLA SubType SHOULD BE set to 1003 SLA Producer's AS number and destination AS number SHOULD BE set to 1004 AS number of BGP peer's that is targeted SLA Consumer. 1005 Alternatively, highest order bit in the SLA SubType flags MAY BE set 1006 to ignore Source AS and destination AS values from the SLA SubType 1007 content since SLA advertised is meant specifically for the BGP peer. 1009 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 1011 When advertised SLA is not for the BGP peer of an SLA Producer, the 1012 Source AS field, in the SLA SubType, MUST be set. The list of 1013 destination AS(es) also MUST be set, in the SLA SubType, to avoid 1014 flooding of the QoS Attribute data in the network beyond those 1015 destinations. Destination AS(es) is a list of SLA Consumers the 1016 advertised SLA is intended for. 1018 If a new prefix is learned and traffic with this new prefix is 1019 subject to SLA parameters that have already been advertised before 1020 for other existing prefixes, then the BGP UPDATE for this new prefix 1021 MAY include QoS Attribute containing just an SLA ID that was 1022 advertised earlier. This BGP UPDATE message does not require to have 1023 the whole SLA Content. The SLA ID is sufficient to relate SLA 1024 parameters to new advertised prefixes. 1026 5. QoS Attribute Handling at Forwarding Nodes 1028 The propagation of the QoS Attribute in the BGP UPDATE messages 1029 depends on the rules detailed in the following sub-sections. 1031 5.1. BGP Node Capable of Processing QoS Attribute 1033 If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS 1034 Attribute. If BGP UPDATE message has a QoS Attribute with a list of 1035 destination ASes, QoS Attribute Speaker MAY trim the list and adjust 1036 the count of the destination AS to exclude ones that are not required 1037 in further announcement of BGP UPDATE messages. 1039 A QoS Attribute Speaker MUST drop SLA SubType from the QoS Attribute, 1040 if there are no more ASes left in the QoS Attribute's destination 1041 list. The rest of the QoS Attribute contents may be forwarded if 1042 there exist other SubTypes of QoS Attribute and forwarding rules meet 1043 other SubTypes requirements. If there is no other SubTypes in that 1044 QoS Attribute content then QoS Attribute Speaker MUST drop the entire 1045 QoS Attribute all together. BGP Speaker MAY announce further other 1046 attributes and NLRI information, if they meet rules defined by other 1047 attributes and BGP specification. 1049 Except extracting the entire SLA SubType of the QoS Attribute and 1050 trimming the list of Destination AS list, all other content MUST NOT 1051 be modified by any QoS Attribute Speaker or BGP Speaker in the path 1052 of a BGP UPDATE message. 1054 5.2. QoS Attribute Handling at Receiver 1056 Once QoS Attribute with the SLA SubType is received at intended 1057 receiver (SLA Consumer) , processing of advertised SLA Content is 1058 optional for the SLA Consumer. SLA Consumer MAY just trim the 1059 Destination AS list as per rules described in this specification, 1060 without processing any other content of the Attribute. If intended 1061 receiver is not a QoS Attribute Speaker than BGP Speaker MUST forward 1062 this attribute without any change if rest of the BGP UPDATE message 1063 also meets forwarding rules as per BGP specification. 1065 When BGP UPDATE messages are triggered only as a result of SLA policy 1066 change, propagating BGP UPDATE message beyond intended SLA Consumers 1067 is not necessary. If the SLA Consumer device implementations are 1068 capable of policy based filtering, it may implement a policy to 1069 filter such BGP UPDATE messages based on prefixes and QoS Attribute 1070 containing SLA SubType. 1072 6. Error Handling 1074 Error conditions, while processing of the QoS Attribute content, MUST 1075 be handled with the approach of attribute discard as described in 1076 [RFC7606]. Processing of QoS Attribute content is done by QoS 1077 Attribute Speaker and thus in case of errors, resulting in attribute 1078 discard, QoS Attribute Speaker SHOULD convey such indication to the 1079 BGP Speaker and rest of the BGP message SHOULD BE processed by the 1080 BGP Speaker as per BGP specification. 1082 7. Deployment Considerations 1084 One of the use cases is for a provider to advertise contracted SLA 1085 parameters to a Customer Edge (CE) in cases where eBGP is deployed 1086 between PE and CE. The SLA parameters may already be provisioned by 1087 the provider on the PE device (facing CE). This provisioned SLA 1088 parameters are then advertised thru proposed QoS Attribute to the CE 1089 device. The CE device may read the QoS Attribute and SLA SubType 1090 content to implement the QoS policy on the device. 1092 Contracted SLA from PE to CE may be full line-rate or sub line-rate 1093 or finer granular controlled services. The advertised SLA can be 1094 useful when contracted service is sub-rate of a link and/or when for 1095 finer granular traffic classes that are controlled (e.g. voice, video 1096 services may be capped to certain rate). 1098 _______________ 1099 __________ / \ 1100 / \ / \ 1101 / \ / \ 1102 |CustomerSite|-----| Provider | 1103 \ C/E P\E / 1104 \__________/ \ / 1105 \_______________/ 1106 AS 3 AS 2 1108 SLA_ADVERTISE: AS2 to AS3 1109 NLRI = PE ip address 1111 Figure 6 - Example 1 1113 Another use case can be to advertise SLAs among different network 1114 sites within one Enterprise network. In Hub and Spoke deployments, 1115 Administrator may define SLAs at spoke and advertise QoS SLA 1116 parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1 1117 and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in 1118 Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel 1119 ip address. 1121 AS 2 1122 _______________ ________ 1123 / \ / \ 1124 _____ / \-----| Spoke2 | 1125 / \ / \ \________/ 1126 | Hub |-----| Provider | ________ 1127 \______/ \ / / \ 1128 \ /-----| Spoke1 | 1129 AS 3 \_______________/ \________/ 1130 AS 1 1132 SLA_ADVERTISE: AS2 to AS3 1133 NLRI = AS2 tunnel address 1135 SLA_ADVERTISE: AS1 to AS3 1136 NLRI = AS1 tunnel address 1138 Figure 7 - Example 2 1140 Deployment options are not limited to involving CEs, PE-to-CE or CE- 1141 to-CE, only. For any contract between two providers, SLA parameters 1142 may be advertised from one to the other. 1144 8. Acknowledgements 1146 Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and 1147 Alvaro Retana for their suggestions and to Christian Jacquenet, Ken 1148 Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand 1149 Duvivier, Bruno Decraene for the review. 1151 9. IANA Considerations 1153 This document defines a new BGP optional transitive path attribute, 1154 called QoS Attribute. IANA action is required to allocate a new 1155 code-point in the BGP path Attributes registry. 1157 IANA is requested to create a registry for QoS Attribute SubTypes. 1158 This is a registry of 1 octet value, divided into two pools.One pool 1159 of numbers to be assigned on a standards action/early allocation 1160 basis. The initial assignments are as shown below. The other pool 1161 is for the private use,available range for which is as shown below. 1163 QoS Attribute SubTypes 1164 ====================== 1165 Reserved 0x00 1166 SLA 0x01 1167 Reserved 0x02-0xf0 (Standards Action) 1168 Private use 0xf1-0xff 1170 IANA is requested to create a registry for QoS Attribute SLA SubType 1171 flags. This is registry for 8-bits. The initial assignments are as 1172 shown below. 1174 QoS Attribute SLA SubType Flags 1175 =============================== 1176 Highest order bit (bit 0) - to indicate source and destination 1177 AS context 1178 Reserved - bits 1 to 15 (Standards Action) 1180 IANA is requested to create a registry for QoS Attribute SLA Event 1181 Types. This is a registry of 4-bits value, divided into two pools. 1182 One pool of numbers to be assigned on a standards action/early 1183 allocation basis. One pool of numbers to be assigned on a standards 1184 action/early allocation basis. The initial assignments are as shown 1185 below. The other pool is for the private use, available range for 1186 which is as shown below. 1188 QoS Attribute SLA Event Types 1189 ============================= 1190 Reserved 0x0 1191 ADVERTISE 0x1 1192 Reserved 0x2 - 0xc (Standards Action) 1193 Private use 0xd - 0xf 1195 IANA is requested to create a registry to define QoS Attribute SLA 1196 Direction. This is the direction in forwarding path, advertised QoS 1197 SLA is applicable to. This is a 2-bit registry. Values for QoS 1198 Attribute SLA direction are: 1200 QoS Attribute SLA Direction 1201 =========================== 1202 Reserved 0x0 1203 To source AS from destination AS 0x1 1204 From source AS to destination AS 0x2 1205 Reserved (Standards Action) 0x3 1207 QoS Attribute SLA Traffic Class Element Types will be referring to 1208 existing IPFIX IANA types as listed in Table 1. While IPFIX registry 1209 is maintained by IANA out of scope of this specification, the use of 1210 IPFIX identifiers for this specification are limited to what is 1211 described in Table 1. Any new addition of IPFIX identifiers to this 1212 table should be a Standards Action. 1214 IANA is requested to create a registry for QoS Attribute SLA Traffic 1215 Class Service Types. This is a registry of 2 octet values, to be 1216 assigned on a standards action/early allocation basis. The initial 1217 assignments are: 1219 Traffic Class Service Type Value 1220 ============================ ====== 1221 Reserved 0x00 1222 TRAFFIC_CLASS_TSPEC 0x01 1223 L2_OVERHEAD 0x02 1224 MINRATE_IN_PROFILE_MARKING 0x03 1225 MINRATE_OUT_PROFILE_MARKING 0x04 1226 MAXRATE_IN_PROFILE_MARKING 0x05 1227 MAXRATE_OUT_PROFILE_MARKING 0x06 1228 DROP_THRESHOLD 0x07 1229 RELATIVE_PRIORITY 0x08 1230 SUB_TRAFFIC_CLASSES 0x09 1231 Standards Action 0x0A - 0x3FFF 1232 FCFS 0x4000 - 0x4FF0 1234 10. Security Considerations 1236 BGP security vulnerabilities analysis is documented in [RFC4272] 1237 while BGP-related security considerations are discussed in [RFC4271]. 1238 Also, the reader may refer to [RFC7132] for more details about BGP 1239 path threat model. Rest of the content in this section discusses 1240 additional privacy and security considerations that are applicable to 1241 the attribute defined in this document. 1243 The information conveyed in the QoS Attribute SLA SubType reveals 1244 sensitive data that should not be exposed publicly to non-authorized 1245 parties. Deployment considerations mainly target use of QoS 1246 Attribute and SLA SubType in managed networks and those where a trust 1247 relationship is in place (Customer to Provider, or Provider to 1248 Provider). It is NOT RECOMMENDED to enable this attribute at the 1249 scale of the Internet unless if means to prevent leaking sensitive 1250 information are enforced. 1252 The attribute may be advertised by a misbehaving node to communicate 1253 SLA parameters that are not aligned with the SLA agreements. Though 1254 the enforcement of SLA parameters is outside the scope of this 1255 document, it is RECOMMENDED that the SLA Consumer to enforce a set of 1256 validation checks before translating the SLA parameters conveyed in 1257 the QoS attributes into provisioning actions. Such validations MAY 1258 rely on SLA parameters like the origin AS or SLA ID, like generating 1259 SLA ID using pseudo-random schemes [RFC4086]. 1261 Means to prevent route hijacking SHOULD BE considered. Such means 1262 include RPKI based origin validation [RFC7115] and BGP Path 1263 validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). 1265 11. References 1267 11.1. Normative References 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, 1271 DOI 10.17487/RFC2119, March 1997, 1272 . 1274 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1275 of Guaranteed Quality of Service", RFC 2212, 1276 DOI 10.17487/RFC2212, September 1997, 1277 . 1279 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1280 IANA Considerations Section in RFCs", RFC 2434, 1281 DOI 10.17487/RFC2434, October 1998, 1282 . 1284 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1285 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1286 2003, . 1288 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1289 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1290 DOI 10.17487/RFC4271, January 2006, 1291 . 1293 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1294 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1295 . 1297 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 1298 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 1299 2006, . 1301 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1302 Autonomous System (AS) Number Space", RFC 6793, 1303 DOI 10.17487/RFC6793, December 2012, 1304 . 1306 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1307 for IP Flow Information Export (IPFIX)", RFC 7012, 1308 DOI 10.17487/RFC7012, September 2013, 1309 . 1311 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1312 Resource Public Key Infrastructure (RPKI)", BCP 185, 1313 RFC 7115, DOI 10.17487/RFC7115, January 2014, 1314 . 1316 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1317 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1318 . 1320 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1321 Patel, "Revised Error Handling for BGP UPDATE Messages", 1322 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1323 . 1325 11.2. Informative References 1327 [I-D.ietf-netconf-restconf] 1328 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1329 Protocol", draft-ietf-netconf-restconf-18 (work in 1330 progress), October 2016. 1332 [I-D.ietf-sidr-bgpsec-protocol] 1333 Lepinski, M. and K. Sriram, "BGPsec Protocol 1334 Specification", draft-ietf-sidr-bgpsec-protocol-22 (work 1335 in progress), January 2017. 1337 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1338 and W. Weiss, "An Architecture for Differentiated 1339 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1340 . 1342 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1343 "Randomness Requirements for Security", BCP 106, RFC 4086, 1344 DOI 10.17487/RFC4086, June 2005, 1345 . 1347 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1348 and D. McPherson, "Dissemination of Flow Specification 1349 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1350 . 1352 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1353 the Network Configuration Protocol (NETCONF)", RFC 6020, 1354 DOI 10.17487/RFC6020, October 2010, 1355 . 1357 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1358 and A. Bierman, Ed., "Network Configuration Protocol 1359 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1360 . 1362 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1363 Connectivity Provisioning Profile (CPP)", RFC 7297, 1364 DOI 10.17487/RFC7297, July 2014, 1365 . 1367 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1368 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1369 October 2015, . 1371 Authors' Addresses 1373 Shitanshu Shah 1375 Email: shitanshu_shah@hotmail.com 1377 Keyur Patel 1378 Arrcus, Inc 1380 Email: keyur@arrcus.com 1382 Sandeep Bajaj 1383 Viptela 1385 Luis Tomotaki 1386 Verizon 1387 400 International 1388 Richardson, TX 75081 1389 US 1391 Email: luis.tomotaki@verizon.com 1393 Mohamed Boucadair 1394 Orange 1395 Rennes 1396 35000 1397 France 1399 Email: mohamed.boucadair@orange.com