Network Working Group S. Shah Internet-Draft K. Patel Intended status: Standards Track Cisco Systems Expires: May 4, 2016 S. Bajaj Juniper Networks L. Tomotaki Verizon M. Boucadair France Telecom November 01, 2015 Inter-domain SLA Exchange draft-ietf-idr-sla-exchange-06 Abstract Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling, which can help to simplify some of the complexities, where BGP is available as the routing protocol. This document defines an optional transitive attribute to signal SLA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Shah, et al. Expires May 4, 2016 [Page 1] Internet-Draft Inter-domain SLA Exchange attribute November 2015 This Internet-Draft will expire on May 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5 4. Originating SLA Notification . . . . . . . . . . . . . . . . 15 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away . . . . . . . . . . . . . . . . . . . . . . . . 16 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 16 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 16 5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 17 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18 7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 18 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Typically there is a contractual Service Level Agreement (SLA) for QoS established between a customer and a provider or between providers. This QoS SLA defines the nature of the various traffic classes and services needed within each traffic class. The contract Shah, et al. Expires May 4, 2016 [Page 2] Internet-Draft Inter-domain SLA Exchange attribute November 2015 may include full line-rate or sub line-rate without additional traffic classes, or it may contain additional traffic classes and service definitions for those traffic classes. Finer granular traffic classes may be based on some standard code points (like DSCP) or specific set of prefixes. Once the SLA is established, QoS SLA parameters are enforced in some or all participating devices by deriving those parameters into configuration information on respective devices. SLA parameters may have to be exchanged through organizational boundaries, thru SLA documents or via some other off-band method to an administrator provisioning actual devices. In a subsequent step, administrator requires to translate SLA to QoS policies using router (vendor) specific provisioning language. In a multi-vendor network, translating SLAs into technology-specific and vendor-specific configuration requires to consider specificities of each vendor. There does not exist any standard protocol to translate SLA agreements into technical clauses and configurations and thus both the steps of out of band learning of negotiated SLA and provisioning them in a vendor specific language can be complex and error-prone. As an example for voice service, the Provider may negotiate QoS parameters (like min/max rates) for such traffic based upon the EF code-point in Diffserv-enabled [RFC2475] networks. The Administrator at the CE side not only will have to know that Provider's service for voice traffic is EF-based but will also have to know how to implement DSCP EF classification rule along with Low Latency Service, and possibly min/max rate enforcement for the optimal use of bandwidth, as per vendor specific provisioning language. An in-band signaling method of propagating SLA parameters from the provider, PE in an example above, to contractual devices, CE in an example above, can help eliminate manual administrative process described above. The provider may have SLA negotiated with the Customer via some defined off-band method (based on the specifics defined by the Provider or using protocols like [CPNP]). The Inter- domain SLA exchange proposal described in this document does not pre- requisite any specific method of establishing SLAs). The Provider provisions established SLA on the Provider device. This SLA instance then can be signaled to the Customer via in-band signaling protocol. In reaction to this signal, receiver router may translate that to relevant QoS policy definition on the device. For an in-band signaling, we propose to use BGP as a transport. The details of SLA parameters are specific to the granularity of traffic classes and their respective treatment, which is independent of the BGP protocol itself. Though we find BGP as a suitable transport for inter-domain SLA exchange for the following reasons: Shah, et al. Expires May 4, 2016 [Page 3] Internet-Draft Inter-domain SLA Exchange attribute November 2015 - The need to exchange SLA parameters between domains(Autonomous Systems (AS)), where in use-cases described in this document, BGP is a suitable protocol for inter-domain exchange [RFC4271] [RFC4364]. - There is no specifically defined protocol available today for SLA exchange. - BGP updates already advertise specific set of prefixes (flow or flow-group). Other QoS-related attributes, apart from the the use of SLA advertisement, can be added to these updates in the future. The proposal is to define a new BGP attribute to advertise/learn SLA details in-band. The proposed attribute is intended to advertise SLA from one AS to a list of destined ASes. The advertised QoS information could be for the incoming traffic to the advertiser, that is advertising SLA or could be for the outgoing traffic from the advertiser or could be for both directions. Reception of and reaction to advertised SLAs are optional for the receiver. We propose QoS as an optional transitive attribute, keeping SLA advertisement as one of the sub-types of QoS attribute. This is to keep the QoS attribute open for extensions. For example, SLA Negotiation and Assurance is out of scope of this document but can be envisioned as another sub-type. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. QoS Attribute Definition The QoS Attribute proposed here is an optional transitive attribute (attribute type code to be assigned by IANA). SLA is defined as one of the sub-types in the QoS attribute. The QoS attribute is only applicable to the NLRI advertised in the BGP update message. Shah, et al. Expires May 4, 2016 [Page 4] Internet-Draft Inter-domain SLA Exchange attribute November 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr flag | Attr type QoS | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | QoS Attr length/Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... Attribute flags highest order bit (bit 0) - MUST be set to 1, since this is an optional attribute 2nd higher order bit (bit 1) - MUST be set to 1, since this is a transitive attribute 3.1. SLA, QoS attribute sub-type, Definition The value field of the QoS Attribute contains TLVs, followed to QoS Attribute flags described in the previous section. One of the TLVs that we define is a tuple of (SLA sub-type, Length, Value). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS Attr flags| subType | subtype Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... QoS Attr flags 8-bit = 0000-0000, All the bits are currently un-used. The space is made available for the purpose of future use. For now they all MUST be set to 0 when QoS attribute is added in the BGP update message and MUST be ignored when received subType 8-bit 0x00 = reserved 0x01 = SLA 0x02 - 0x0f = for future use Shah, et al. Expires May 4, 2016 [Page 5] Internet-Draft Inter-domain SLA Exchange attribute November 2015 subType Length 16-bit Length of the content to follow pertaining to specified subType. Value for the SLA sub-type is as described below. These details contain information about 1) sender and receiver(s) and 2) SLA parameters. SLA Parameters include SLA event type (such as Advertise) and contents associated to that event type. The format of SLA message is, 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source AS (Advertiser) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination AS count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | variable list of destination AS | ~ .... ~ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event | SLA id | SLA length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content as per SLA Event | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source AS 32-bit source AS number. This is the AS that is advertising SLA 0 = ignore Source and Destination AS list from this Value field Note that AS = 0, used in message outside of QoS attribute, is illegal in normal BGP operations. AS = 0 inside the QoS attribute may be used simply as a flag to tell receiver to ignore Source and Destination AS list from inside the QoS attribute. Destination AS count 32-bit destination AS count to take variable length AS list. This count has no functional value when Source AS is 0. 0 = QoS attribute is relevant to every receiver of the message Destination AS list Shah, et al. Expires May 4, 2016 [Page 6] Internet-Draft Inter-domain SLA Exchange attribute November 2015 32-bit destination AS number .... .... [as many as AS count] SLA Event 4-bits 0x0 = reserved 0x1 = ADVERTISE 0x2 to 0xf, for future use SLA Id 16-bit identifier unique within the scope of source AS The significance of an SLA identifier is in the context of the source that is advertising SLA parameters. The SLA identifier is not globally unique but it MUST be unique within the source AS (advertiser). If advertised SLA id is different from earlier advertised one, for the same prefix, previous SLA content MUST be replaced with the new advertised one. SLA is aggregate for all the traffic to prefixes for a given AFI/SAFI that share same source AS and SLA id. SLA Length 12-bits - Total length of the SLA content to follow Content as per SLA event The SLA content is optional for an advertised SLA id. The value of the SLA length field in such case would be 0. If SLA content does not exist in BGP update messages with advertised QoS attribute, that contains the SLA sub-type, then receiver MUST inherit prior advertised SLA content for the same SLA id from the same Source AS. If there does not exist any prior SLA to relate to the advertised SLA id, then receiver can ignore the SLA advertisement and continue with the rest of the BGP message processing and forwarding rules. Note that such condition MUST not discard the attribute. All defined forwarding rules for this attribute still MUST apply. The only event prescribed in this document is ADVERTISE. The format of SLA ADVERTISE event message is, Shah, et al. Expires May 4, 2016 [Page 7] Internet-Draft Inter-domain SLA Exchange attribute November 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dir| Traffic Class count | Class Desc Len| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | | ~ Traffic Class Description ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elements Count| | +-+-+-+-+-+-+-+-+ ~ | | ~ Traffic Class Elements TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Count| | +-+-+-+-+-+-+-+-+ ~ | Traffic Class Service TLVs | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Repeat from Traffic Class Description for next Traffic Class ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Repeat from direction for SLA in the other direction ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ dir (Direction) 02-bit for incoming traffic to source AS or outgoing traffic from source AS, 0x0 = reserved 0x1 = incoming, to source AS from destination AS 0x2 = outgoing, from source AS towards destination AS 0x3 = for future use Traffic Class count (Classifier Groups count) 16-bit, count of number of classifier groups 00 = Advertisement to invalidate previous advertised SLA if any Traffic Class Descr Length 08-bit, length of the description 0 = No description Shah, et al. Expires May 4, 2016 [Page 8] Internet-Draft Inter-domain SLA Exchange attribute November 2015 Traffic Class Description Description of the Traffic Class in UTF-8 encoding Traffic Class Elements Count in a Traffic Class, 08-bit count of classifier elements in a specific Traffic Class 00 = this has relative definition. It means classify rest all traffic that is not classified via earlier described Traffic Classes. It is RECOMMENDED that Traffic Class that has 0 elements is present last in the advertised list of Traffic Classes. If Advertised message has it positioned somewhere else, then receiver MUST re-order it, for the forwarding purpose, to the last position in the advertised list of Traffic Classes from a given source AS. QoS attribute advertised from a specific source MUST NOT have more than one such Traffic Classes (Traffic Class with 0 elements count). If there are more than one such Traffic Classes present then it is an error condition which should follow handling of such BGP message as described in Error handling section. Classifier Element values (optional), 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value Given IPFIX [RFC5102] has well defined identifier set for a large number of packet attributes, IPFIX IANA registry is ("https://www.ietf.org/assignments/ipfix") chosen to specify packet classification attributes. However, since not all identifiers from IPFIX would be applicable to this proposal, only a limited set identified here can be supported by BGP SLA exchange. Any new element identifier, in the future added to the IPFIX IANA registry, is not automatically supported for this proposal. Only the IPFIX elements indicated in this document below remain supported. +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | Shah, et al. Expires May 4, 2016 [Page 9] Internet-Draft Inter-domain SLA Exchange attribute November 2015 |244 | dot1qPriority | | 8 | sourceIPv4Address | | 27 | sourceIPv6Address | | 9 | sourceIPv4PrefixLength | | 29 | sourceIPv6PrefixLength | | 44 | sourceIPv4Prefix | |170 | sourceIPv6Prefix | | 12 | destinationIPv4Address | | 28 | destinationIPv6Address | | 13 | destinationIPv4PrefixLength| | 30 | destinationIPv6PrefixLength| | 45 | destinationIPv4Prefix | |169 | destinationIPv6Prefix | | 4 | protocolIdentifier | | 7 | sourceTransportPort | | 11 | destinationTransportPort | +----+----------------------------+ Any traffic classifier element advertised in the QoS attribute is only applicable to the NLRI advertised for a given AFI/SAFI within the BGP update message. If a receiver receives a BGP update message with QoS/SLA attribute for an NLRI that is not supported by a receiver then receiver MUST not install an advertised SLA and continue to forward this attribute further if it is not the last receiver of an attribute. Traffic Class Service count (for a Traffic Class under definition) 08-bit count of service attributes fields to follow with type/value pair List of service types and relevant values are discussed below 00 = no bounded service (also means Best Effort) Traffic Class Service (optional), 16-bit = Traffic Class Service Type 08-bit = size, in octets, of the value field variable-length field = contains actual value - 0x00 = reserved - 0x01 = TRAFFIC_CLASS_TSPEC 160-bits TSpec Parameter Shah, et al. Expires May 4, 2016 [Page 10] Internet-Draft Inter-domain SLA Exchange attribute November 2015 The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p), (m) and (M) parameters as described in Invocation Information section of [RFC2212]. Note that inheriting the definition of TSpec here does not enable RFC2212 functionality. Only the values of the Traffic Specification are used in this specification. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Rate (r) (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Size (b) (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Rate (p) (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit (m) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size (M) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter (r) indicates min-rate of the traffic class. This rate indicates the minimum rate, measured in octets of Layer 2 (L2) datagrams per second, that the service advertiser is providing for a given class of traffic on advertiser's hop. Note that it does not necessarily translate to a minimum rate service to the receiver of an SLA unless the traffic class definition clearly represents a sole receiver of an SLA. If there is no SLA for min-rate, the value of (r) MUST be set to 0. Parameter (b) indicates maximum burst size, measured in octets of L2 datagram size. Since queuing delay can be considered a function of burst size (b) and min-rate (r), in presence of non- zero parameter (r), parameter (b) represents bounded delay for the Traffic Class. This delay is a single hop queuing delay when SLA is to be implemented at the resource constrained bottleneck. In other words this burst size can be considered as a buffer size. Value of 0 for parameter (b) means the advertiser does not mandate specific bounded delay. Parameter (p) indicates max-rate of the traffic class. Just like min-rate, max-rate, measured in octets of L2 packets per second, field here also indicates service provided by advertiser. If advertiser does not have any specific value to set for a given class of traffic, it MAY be set to physical interface line rate or any other indirect limit that may affect this class' maximum rate. In absence of any such known value, it MUST be set to positive infinity. Value 0 is considered an error. Shah, et al. Expires May 4, 2016 [Page 11] Internet-Draft Inter-domain SLA Exchange attribute November 2015 Parameters (r), (b) and (p) are each set as 32-bit IEEE floating point numbers. Positive infinity is represented as an IEEE single precision floating-point number with an exponent of all ones and a sign mantissa of all zeros. The format of IEEE floating-point numbers is further summarized in [RFC4506]. The minimum policed unit (m) and maximum packet size (M) parameters have no relevance for the purpose of SLA exchange. Thus they MUST be ignored. - 0x02, L2_OVERHEAD 08-bit, value By default specification of rate and other packet size related parameters, advertised in an SLA, includes L2 overhead. For the receiver next hop,this overhead is the L2 overhead of the local link where advertised SLA is received. However, in cases where advertised SLA is for a receiver multiple hops away, L2 overhead consideration from the source perspective may be different from the local L2 overhead at the receiver. Explicit notification of size of L2 overhead from a sender, in such cases, is useful for a receiver to distinguish local L2 overhead from the sender advertised one. When receiver choose to react to an advertised SLA and if this service type is present in advertised SLA, receiver MUST use advertised L2 overhead over local L2 overhead. If SLA is required to consider only IP packet size, sender may advertise this service with a value of 0. - 0x03 = MINRATE_IN_PROFILE_MARKING 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value 00 Identifier = drop, variable-length for this id is 0. +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | |244 | dot1qPriority | +----+----------------------------+ - 0x04 = MINRATE_OUT_PROFILE_MARKING Shah, et al. Expires May 4, 2016 [Page 12] Internet-Draft Inter-domain SLA Exchange attribute November 2015 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value 00 Identifier = drop, variable-length for this id is 0. +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | |244 | dot1qPriority | +----+----------------------------+ - 0x05 = MAXRATE_IN_PROFILE_MARKING 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value 00 Identifier = drop, variable-length for this id is 0. +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | |244 | dot1qPriority | +----+----------------------------+ - 0x06 = MAXRATE_OUT_PROFILE_MARKING 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value 00 Identifier = drop, variable-length for this id is 0. +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | |244 | dot1qPriority | +----+----------------------------+ In the case when MINRATE_IN_PROFILE_MARKING, Shah, et al. Expires May 4, 2016 [Page 13] Internet-Draft Inter-domain SLA Exchange attribute November 2015 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and MAXRATE_OUT_PROFILE_MARKING are all advertised, - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over MAXRATE_IN_PROFILE_MARKING) - MAXRATE_IN_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING - and MAXRATE_OUT_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING - 0x07 = DROP_THRESHOLD 03-bit count of drop-priority fields to follow with (type, type-value, burst size) tuple 04-bit, drop priority type 08-bit = IPFIX Element Identifier 08-bit = size, in octets, of the value field variable-length field = contains actual value 32-bit = Burst Size (32-bit IEEE floating point number) +----+----------------------------+ | ID | Name | +----+----------------------------+ |195 | ipDiffServCodePoint | |203 | mplsTopLabelExp | |244 | dot1qPriority | +----+----------------------------+ This finer granular drop threshold does not require separate buffer space from the aggregate buffer space. It is just an indicator beyond which code-point specific traffic to be discarded when occupancy of aggregate buffers reached to that threshold. - 0x08 = RELATIVE_PRIORITY 04-bit, priority value lower the value, higher the priority Relative priority indicates scheduling priority. For example voice traffic, which requires lowest latency compared to any other traffic, may have lowest value advertised in relative priority. For two different traffic classification groups where one application group may be considered more important than the other but from a scheduling perspective does not require to be distinguished with a different priority, relative Shah, et al. Expires May 4, 2016 [Page 14] Internet-Draft Inter-domain SLA Exchange attribute November 2015 priority for those classification groups may be advertised with the same value. - 0x09 = SUB_TRAFFIC_CLASSES variable-length, repeats all content described above from Traffic Class count onwards. For SLAs where a specific Traffic Class may further have different sub-services for a sub-group of Classifier Elements, this service type SHOULD be used to further divide Traffic Class in multiple sub-classes. Each sub-class is then defined with their own classifier elements and service types. 4. Originating SLA Notification The QoS attribute MUST only be added by the originator and MUST NOT be added during BGP propagation. SLA messages SHOULD NOT be sent periodically just for the purpose of keep alive. Some sort of SLA policy change may be considered as a trigger for the advertisement. For any modified SLA parameters, the originator MUST re-advertise the entire set of SLA parameters. There is no provision to advertise partial set of parameters. To invalidate previously advertised SLA parameters, a message MUST be sent with the same SLA id for the same source with the Traffic Class count set to 0. 4.1. SLA Contexts In certain cases, the advertisement may relate to an SLA for aggregate traffic over a point-to-point connection between a specific destination and a specific source. A point-to-point connection may be the physical link, that connects two BGP peers, or may be a virtual link (e.g. a tunnel). A BGP update message, in such cases, with source AS number and NLRI prefix of source end-point can uniquely identify physical/virtual link and so establishes advertised SLA's context for that point to point link. In the simplest case where Provider (e.g. PE) and Customer (e.g. CE) devices are directly connected via a physical link and have only a single link between them, CE can uniquely identify the forwarding link to PE with AS number of the PE and NLRI prefix being an IP address of PE, to CE (that is the next hop address from CE to PE). SLA advertised thru BGP update message from PE to CE, with PE's AS Shah, et al. Expires May 4, 2016 [Page 15] Internet-Draft Inter-domain SLA Exchange attribute November 2015 number and IP address, establishes SLA context for the aggregate traffic through link CE to PE. SLA advertised thru BGP update message from PE to CE, with PE's AS number and any other prefix establishes SLA for that specific prefix, subset of traffic under CE to PE link. Even though this example is in the context of IP prefixes, SLA exchange does not have to be limited to the IP address family (IPv4 and IPv6). SLA advertisement is generic to all forms of NLRI types that are supported by the BGP protocol specification (like IPv4, IPv6, VPN-IPv4, VPN-IPv6). 4.1.1. SLA Advertisement for Point-to-Point Connection When SLA messages are intended to be advertised for the point-to- point connection (physical or logical), the message is destined for the next hop and advertised message is in the context of the prefix of the source end-point of the point to point connection. The destination AS number set to, within QoS SLA attribute, typically is of the neighbor BGP speaker's. Alternatively, source AS and destination AS count MAY be set to 0. 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away When SLA messages are to be advertised beyond next hop, value of source AS, in the QoS attribute, MUST be set by the originator of the update message. If such an update is meant to be for a specific list of AS(es) as receivers, then the list of destination AS MUST be explicitly described in the QoS attribute message to avoid flooding of the QoS attribute data in the network beyond those destinations. When a new prefix is added in the AS, AS for which SLA parameters have already been advertised before for other existing prefixes, and if traffic to this new prefix is subject to the same SLA advertised earlier then BGP update for this new prefix may include QoS attribute containing just an SLA id, an id that was advertised earlier. The corresponding Update message does not require to have the whole SLA content. SLA id is sufficient to relate SLA parameters to new advertised prefix. 5. SLA Attribute Handling at Forwarding Nodes 5.1. BGP Node Capable of Processing QoS Attribute If a BGP node is capable of processing QoS attribute, it optionally MAY process the QoS attribute. If advertised SLA has a list of destination ASes, it MAY trim the list and so count of destination AS Shah, et al. Expires May 4, 2016 [Page 16] Internet-Draft Inter-domain SLA Exchange attribute November 2015 to exclude ones that are not required in further announcement of BGP updates. BGP node MUST drop SLA related sub-type from the QoS attribute, if there is no more AS from the destination list in the forwarding path. The rest of the QoS attribute contents MAY be forwarded if there exist other sub-types of QoS attribute and forwarding rules meets other sub-types requirements. If there is no other sub-types in the QoS attribute content then the node MUST drop the entire QoS attribute all together. The other attributes and NLRI information may be announced further if they meet rules defined by other attributes and BGP protocol. Except extracting the entire SLA sub-type of the QoS attribute and trimming the list of destination AS list, all other content MUST NOT be modified by any intermediate receivers of the message. 5.2. SLA Attribute Handling at Receiver Reception of and processing of advertised QoS SLA content are optional for the receiver. While reacting to SLA advertisement - receiver SHOULD invalidate previous advertised SLA parameters if one exists for the same SLA id and source AS. If the new advertised SLA has a non-zero traffic count, then the new advertised SLA SHOULD be installed. If new advertised SLA update is with Traffic Class count 0, then no action is required. - When BGP update messages are triggered only as a result of SLA policy change, BGP update message forwarding beyond intended receivers are not necessary. If receiver device implementation supports policy based filtering then receiver MAY implement a policy to filter such messages based on prefix and attribute. If SLA advertised to the next hop neighbor, the receiver may implement advertised SLA for the whole link, where the link could be physical or virtual link, connected to the neighbor. If SLA advertised to is not the next hop neighbor then receiver may establish advertised SLA for that specific prefix list under the relevant link. It is completely up to the receiver to decide for which prefixes it should accept advertised SLA and for which ones it won't. Shah, et al. Expires May 4, 2016 [Page 17] Internet-Draft Inter-domain SLA Exchange attribute November 2015 6. Error Handling Error conditions, while processing of the QoS attribute, SHALL be handled with the approach of attribute-discard as described in [IDR- ERR]. In such condition, receiver SHOULD also cleanup any previously installed SLA state for the same prefix. 7. Traffic Class Mapping It is possible that switching/routing methods used in 2 different ASes could be different. For example, Provider may tunnel Customer's IP traffic thru MPLS cloud. In such cases traffic class definition for QoS services may differ in both ASes. For the meaningful use of advertised SLA in such cases, receiver is required to map traffic class from one type to the other. In the example given, traffic classification in Customer AS could be IP Diffserv-based whereas traffic classification in Provider AS could be MPLS TC-based. Thus for advertised MPLS TC-based SLA would require to map traffic class from IP Diffserv-based to MPLS TC type [RFC3270]. There are well-defined recommendations that exist for traffic class mapping between two technologies, eg. RFC3270 for mapping between DSCP and MPLS TC. Receiver MAY use those defined recommendations for traffic class mapping or MAY define its own as per its network Traffic Class service definition to map to advertised Traffic Classes. It is completely up to the receiver how to define such traffic class mapping. 8. Deployment Considerations One of the use cases is for a Provider to advertise contracted SLA parameters to Customer Edge (CE) in cases where eBGP is deployed between PE and CE. The SLA parameters may already be provisioned by the provider on the PE device (facing CE). This provisioned SLA parameters are then advertised thru proposed BGP QoS attribute to the CE device. CE device may read the attribute and SLA sub-type content to implement the QoS policy on the device. Contracted SLA from PE to CE may be full line-rate or sub line-rate or finer granular controlled services. SLA advertise can be useful when contracted service is sub-rate of a link and/or when for finer granular traffic classes that are controlled (e.g. voice, video services may be capped to certain rate) Shah, et al. Expires May 4, 2016 [Page 18] Internet-Draft Inter-domain SLA Exchange attribute November 2015 _______________ __________ / \ / \ / \ / \ / \ |CustomerSite|-----| Provider | \ C/E P\E / \__________/ \ / \_______________/ AS 3 AS 2 SLA_ADVERTISE: AS2 to AS3 NLRI = PE ip address Another use case can be to advertise SLAs among different network sites within one Enterprise network. In Hub and Spoke deployments, Administrator may define SLAs at spoke and advertise QoS SLA parameters to the Hub thru BGP updates. In the figure below, each spoke (AS1 and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown, AS2 can advertise SLA to AS3 in the context of that tunnel ip address. AS 2 _______________ ________ / \ / \ __________ / \-----| Spoke2 | / \ / \ \________/ | Hub |-----| Provider | ________ \__________/ \ / / \ \ /-----| Spoke1 | AS 3 \_______________/ \________/ AS 1 SLA_ADVERTISE: AS2 to AS3 NLRI = AS2 tunnel address SLA_ADVERTISE: AS1 to AS3 NLRI = AS1 tunnel address Deployment options are not limited to involving CEs, PE-to-CE or CE- to-CE, only. For any contract between two providers, SLA parameters may be advertised from one to the other. Shah, et al. Expires May 4, 2016 [Page 19] Internet-Draft Inter-domain SLA Exchange attribute November 2015 9. Acknowledgements Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for their suggestions and to Christian Jacquenet, Ken Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier, Bruno Decraene for the review. 10. IANA Considerations This document defines a new BGP optional transitive path attribute, called QoS Attribute. IANA action is required to allocate a new code-point in the BGP path Attributes registry. IANA is requested to create a registry for QoS Attribute subTypes. This is a registry of 1 octet value, to be assigned on a standards action/early allocation basis. The initial assignments are: QoS Attribute subTypes - - - - - - - - - - - - Reserved 0x00 SLA 0x01 IANA is requested to create a registry for SLA Event Types. This is a registry of 4-bits value, to be assigned on a standards action/ early allocation basis. The initial assignments are: QoS Attribute SLA Event Types - - - - - - - - - - - - - - - Reserved 0x00 ADVERTISE 0x01 IANA is requested to create a registry to define QoS SLA Direction. This is the direction in forwarding path, advertised QoS SLA is applicable to. QoS SLA Direction - - - - - - - - - Reserved 0x00 to Source AS from destination AS 0x01 from source AS to destination AS 0x02 QoS SLA Traffic Class Element Types will be referring to existing IPFIX IANA types as described in section 3.1. Shah, et al. Expires May 4, 2016 [Page 20] Internet-Draft Inter-domain SLA Exchange attribute November 2015 IANA is requested to create a registry for QoS SLA Traffic Class Service Types. This is a registry of 2 octet values, to be assigned on a standards action/early allocation basis. The initial assignments are: Traffic Class Service Type - - - - - - - - - - - - - - Reserved 0x00 TRAFFIC_CLASS_TSPEC 0x01 L2_OVERHEAD 0x02 MINRATE_IN_PROFILE_MARKING 0x03 MINRATE_OUT_PROFILE_MARKING 0x04 MAXRATE_IN_PROFILE_MARKING 0x05 MAXRATE_OUT_PROFILE_MARKING 0x06 DROP_THRESHOLD 0x07 RELATIVE_PRIORITY 0x08 SUB_TRAFFIC_CLASSES 0x09 11. Security Considerations The QOS attribute defined in this document SHOULD be used by the managed networks for enforcing Quality of Service Policies and so there should not be any risks for identity thefts. To strengthen the security for the QOS attribute, RPKI based origin validation [RFC7115] MAY be used. In addition to the RPKI based origin validation, BGP Path Validation [I-D.ietf-sidr-bgpsec-protocol] procedures could be used over BGP QOS attribute and its associated prefix in producing the digital signature that can be carried within the signature SLA for the messages. This would help prevent any man- in-the-middle attracks. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, DOI 10.17487/RFC2212, September 1997, . Shah, et al. Expires May 4, 2016 [Page 21] Internet-Draft Inter-domain SLA Exchange attribute November 2015 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, . [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, January 2008, . [RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, . [IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Message, I-D.draft- ietf-idr-error-handling", June 2012. 12.2. Informative References [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [BGP-SEC] Lepinski, M., "BGPsec Protocol Specification, I-D.draft- ietf-sidr-bgpsec-protocol", June 2015. Shah, et al. Expires May 4, 2016 [Page 22] Internet-Draft Inter-domain SLA Exchange attribute November 2015 [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP), I-D.boucadair-connectivity- provisioning-protocol", Sep 2014. [BGPSLA-IMPL] Shah, S. and K. Patel, "Inter-domain SLA Exchange Implementation Report, I-D.draft-svshah-idr-sla-exchange- impl", Feb 2015. Authors' Addresses Shitanshu Shah Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: svshah@cisco.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: keyupate@cisco.com Sandeep Bajaj Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Email: sbajaj@juniper.net Luis Tomotaki Verizon 400 International Richardson, TX 75081 US Email: luis.tomotaki@verizon.com Shah, et al. Expires May 4, 2016 [Page 23] Internet-Draft Inter-domain SLA Exchange attribute November 2015 Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Shah, et al. Expires May 4, 2016 [Page 24]