draft-ietf-idr-sla-exchange-06.txt   draft-ietf-idr-sla-exchange-07.txt 
Network Working Group S. Shah IDR S. Shah
Internet-Draft K. Patel Internet-Draft K. Patel
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: May 4, 2016 S. Bajaj Expires: August 7, 2016 S. Bajaj
Juniper Networks Juniper Network
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
France Telecom Orange
November 01, 2015 February 4, 2016
Inter-domain SLA Exchange Inter-domain SLA Exchange Attribute
draft-ietf-idr-sla-exchange-06 draft-ietf-idr-sla-exchange-07.txt
Abstract Abstract
Network administrators typically enforce Quality of Service (QoS) Network administrators typically enforce Quality of Service (QoS)
policies according to Service Level Agreement (SLA) with their policies according to Service Level Agreement (SLA) with their
providers. The enforcement of such policies often relies upon providers. The enforcement of such policies often relies upon
vendor-specific configuration language. Both learning of SLA, either vendor-specific configuration language. Both learning of SLA, either
thru SLA documents or via some other out-of-band method, and thru SLA documents or via some other out-of-band method, and
translating them to vendor specific configuration language is a translating them to vendor specific configuration language is a
complex, many times manual, process and prone to errors. This complex, often manual, process and prone to errors.
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 This document specifies an optional transitive attribute to signal
parameters in-band, across administrative boundaries (considered as SLA parameters in-band, across administrative boundaries (considered
Autonomous Systems (AS)), thus simplifying and facilitating some of as Autonomous Systems (AS)), thus simplifying and facilitating some
the complex provisioning tasks. of the complex provisioning tasks in situations where BGP is
available as a routing protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2016.
This Internet-Draft will expire on August 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4
3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5
4. Originating SLA Notification . . . . . . . . . . . . . . . . 15 3.2. SLA SubType Value Field . . . . . . . . . . . . . . . . . 6
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 15 3.3. SLA-Content per Event Field . . . . . . . . . . . . . . . 8
4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16 3.3.1. Supported IPFIX values for Classifier Elements . . . 12
3.3.2. Traffic Class Service TLVs . . . . . . . . . . . . . 13
4. Originating SLA Notification . . . . . . . . . . . . . . . . 20
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21
4.1.2. SLA Advertisement for Destination AS Multiple Hops 4.1.2. SLA Advertisement for Destination AS Multiple Hops
Away . . . . . . . . . . . . . . . . . . . . . . . . 16 Away . . . . . . . . . . . . . . . . . . . . . . . . 21
5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 16 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 22
5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 16 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 22
5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 17 5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 22
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23
7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 18 7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 23
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Typically there is a contractual Service Level Agreement (SLA) for Typically there is a contractual Service Level Agreement (SLA) for
QoS established between a customer and a provider or between QoS established between a customer and a provider or between
providers. This QoS SLA defines the nature of the various traffic providers [RFC7297]. This QoS SLA defines the nature of the various
classes and services needed within each traffic class. The contract traffic classes and services needed within each traffic class. The
may include full line-rate or sub line-rate without additional contract may include full line-rate or sub line-rate without
traffic classes, or it may contain additional traffic classes and additional traffic classes, or it may contain additional traffic
service definitions for those traffic classes. Finer granular classes and service definitions for those traffic classes. Finer
traffic classes may be based on some standard code points (like DSCP) granular traffic classes may be based on some standard code points
or specific set of prefixes. (e.g., based on DSCP (Differentiated Services Code Point)) or
specific set of prefixes.
Once the SLA is established, QoS SLA parameters are enforced in some Once the contractual QoS SLA is established, QoS SLA parameters are
or all participating devices by deriving those parameters into enforced in some or all participating devices by deriving those
configuration information on respective devices. SLA parameters may parameters into configuration information on respective devices. The
have to be exchanged through organizational boundaries, thru SLA network administrator translates the QoS SLA to QoS policies using
documents or via some other off-band method to an administrator router (vendor) specific provisioning language. In a multi-vendor
provisioning actual devices. In a subsequent step, administrator network, translating SLAs into technology-specific and vendor-
requires to translate SLA to QoS policies using router (vendor) specific configuration requires the network administrator to consider
specific provisioning language. In a multi-vendor network, specific configuration of each vendor. There does not exist any
translating SLAs into technology-specific and vendor-specific standard protocol to translate SLA agreements into technical clauses
configuration requires to consider specificities of each vendor. and configurations and thus both the steps of out of band learning of
There does not exist any standard protocol to translate SLA negotiated SLA and provisioning them in a vendor specific language
agreements into technical clauses and configurations and thus both can be complex and error-prone.
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 SLA parameters may have to be exchanged through organizational
provider, PE in an example above, to contractual devices, CE in an boundaries, thru SLA documents or via some other off-band method, to
example above, can help eliminate manual administrative process an administrator provisioning actual devices.
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 For example, to provide voice services, the provider may negotiate
details of SLA parameters are specific to the granularity of traffic QoS parameters (like min/max rates) for such traffic classified under
classes and their respective treatment, which is independent of the the EF (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475]
BGP protocol itself. Though we find BGP as a suitable transport for networks. The Administrator at the CE (Customer Edge) not only will
inter-domain SLA exchange for the following reasons: 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.
- The need to exchange SLA parameters between domains(Autonomous The Inter-domain exchange of QoS SLA exchange policy described in
Systems (AS)), where in use-cases described in this document, this document does not require any specific method for the provider
BGP is a suitable protocol for inter-domain exchange [RFC4271] in establishing SLAs. It only requires that the provider wishes to
[RFC4364]. send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the
- There is no specifically defined protocol available today for provider to a set of receivers (BGP peers) who will enact the policy.
SLA exchange. In reaction to, a receiving router may translate that to relevant QoS
- BGP updates already advertise specific set of prefixes (flow policy definition on the device.
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 This document defines a new optional transitive BGP QoS attribute
details in-band. The proposed attribute is intended to advertise SLA which has as one of its sub-types the SLA policy. The BGP speakers
from one AS to a list of destined ASes. The advertised QoS of the originating AS send the BGP Attribute for prefixes this QoS
information could be for the incoming traffic to the advertiser, that SLA Policy applies to in a BGP UPDATE message that will be
is advertising SLA or could be for the outgoing traffic from the distributed to a list of destination ASes. The QoS SLA policy can be
advertiser or could be for both directions. Reception of and for inbound traffic to the advertising AS or outbound traffic from
reaction to advertised SLAs are optional for the receiver. the advertising AS, or both.
We propose QoS as an optional transitive attribute, keeping SLA The SLA negotiation and assurance is outside the scope of this
advertisement as one of the sub-types of QoS attribute. This is to document. In the future, other sub-types of the QoS Attribute may
keep the QoS attribute open for extensions. For example, SLA deal with QoS other than SLA Policy for traffic.
Negotiation and Assurance is out of scope of this document but can be
envisioned as another sub-type. Protocols and data models are being created to standardize setting
routing configuration parameters within networks. YANG data models
[RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf
([I-D.ietf-netconf-restconf]) can set these standardized in
configuration mechanisms. For ephemeral state, the I2RS protocol is
being developed to set ephemeral state. While these protocol provide
valid configuration within a domain or across domains, some providers
desire to exchange QoS parameters in-band utilizing BGP peering
relationships. This is similar to the distribution of Flow
Specification information via BGP peering relationships (see
[RFC5575] and [RFC7674]).
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. QoS Attribute Definition 3. QoS Attribute Definition
The QoS Attribute proposed here is an optional transitive attribute The QoS Attribute is an optional transitive attribute (TBD -
(attribute type code to be assigned by IANA). SLA is defined as one attribute code to be assigned by IANA). SLA is defined as one of the
of the sub-types in the QoS attribute. The QoS attribute is only sub-types in the QoS attribute. The QoS attribute is only applicable
applicable to the NLRI advertised in the BGP update message. to the NLRIs advertised in the BGP UPDATE message this attribute is
included in.
0 1 2 3 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 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 | | | Attr flag | Attr type QoS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| QoS Attr length/Value | | QoS Attr length/Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Attribute flags Attribute flags
highest order bit (bit 0) - highest order bit (bit 0) -
MUST be set to 1, since this is an optional attribute MUST be set to 1, since this is an optional attribute
2nd higher order bit (bit 1) - 2nd higher order bit (bit 1) -
MUST be set to 1, since this is a transitive attribute MUST be set to 1, since this is a transitive attribute
Figure 1 - QoS BGP attribute
3.1. SLA, QoS attribute sub-type, Definition 3.1. SLA, QoS attribute sub-type, Definition
The value field of the QoS Attribute contains TLVs, followed to QoS The value field of the QoS Attribute contains the following:
Attribute flags described in the previous section. One of the TLVs
that we define is a tuple of (SLA sub-type, Length, Value). QoS Attribute flags, and
Tuple of (SLA sub-type, length, value).
0 1 2 3 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 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 | | QoS Attr flags| subType | subtype Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Value | | SubType-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+
QoS Attr flags Figure 2 - Format of BGP QoS Attribute
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 QoS Attr flags 1 octet. All the bits are currently un-used. The
8-bit space is provided for future use. All bits MUST be set to zero
0x00 = reserved when sent. The values (0x01-0xFF) are reserved, and MUST be
0x01 = SLA ignored when received.
0x02 - 0x0f = for future use
subType Length SubType 1 octet field with the following values:
16-bit
Length of the content to follow pertaining to specified
subType.
Value for the SLA sub-type is as described below. These details 0x00 = reserved
contain information about 1) sender and receiver(s) and 2) SLA 0x01 = SLA
parameters. SLA Parameters include SLA event type (such as
Advertise) and contents associated to that event type.
The format of SLA message is, 0x02 - 0x0f = reserved for future use (Standards Action)
SubType length - 2 octet field with length of sub-type value.
SubType Value variable length field containing information about:
sender and receiver(s), and SLA parameters described in
Section 3.2.
3.2. SLA SubType Value Field
The format of SubType Value field is shown in Figure 3.
0 1 2 3 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 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 Source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Destination AS count | | 32-bit Destination AS count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable list of destination AS | | variable list of destination AS |
~ .... ~ ~ .... ~
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | SLA id | SLA length | | Event | SLA id | SLA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content as per SLA Event | | SLA-Content per SLA Event |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source AS Figure 3 - The format of SLA SubType of the BGP QoS attribute
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, Source AS: 32-bit source AS number. This is the AS that is
is illegal in normal BGP operations. AS = 0 inside the QoS advertising SLA
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 0 = ignore Source and Destination AS list from this value field
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 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 indicate to the
receiver to ignore Source and Destination AS list from inside
the QoS attribute.
Destination AS list Destination AS count: 32-bit destination AS count to take variable
32-bit destination AS number length AS list. This count has no functional value when Source AS
.... is 0.
.... [as many as AS count]
SLA Event 0 = QoS attribute is relevant to every receiver of the message
4-bits
0x0 = reserved
0x1 = ADVERTISE
0x2 to 0xf, for future use
SLA Id Destination AS list:
16-bit identifier unique within the scope of source AS
The significance of an SLA identifier is in the context of the 32-bit destination AS number
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 .... [as many as AS count]
AFI/SAFI that share same source AS and SLA id.
SLA Length SLA Event:
12-bits - Total length of the SLA content to follow
Content as per SLA event 4-bits with values
The SLA content is optional for an advertised SLA id. The 0x0 = reserved
value of the SLA length field in such case would be 0. If SLA
content does not exist in BGP update messages with advertised 0x1 = ADVERTISE
QoS attribute, that contains the SLA sub-type, then receiver
MUST inherit prior advertised SLA content for the same SLA id 0x2 to 0xf - Reserved for future use
from the same Source AS. If there does not exist any prior SLA
to relate to the advertised SLA id, then receiver can ignore SLA Id: A 16-bit field containing identifier which is unique in
the SLA advertisement and continue with the rest of the BGP scope of source AS
message processing and forwarding rules. Note that such
condition MUST not discard the attribute. All defined The significance of an SLA identifier is in the context of the
forwarding rules for this attribute still MUST apply. source that is advertising SLA parameters. The SLA identifier
is not globally unique but it MUST be unique within the source
AS (advertiser).
If the advertised SLA id is different from earlier advertised
one, for the same prefix, previous SLA content MUST be replaced
with the new advertised one.
The SLA ID applies aggregate for all the traffic to prefixes
for a given AFI/SAFI that share same source AS and SLA id.
SLA Length: A 12-bit field indicating the length of SLA-Content.
The SLA-content is optional for each advertised SLA id. If the
SLA-content field does not exist, the SLA length field value is
zero.
SLA-Content per SLA Event: A variable length field (optional field).
If SLA field exists, it follows the format described in
Section 3.3.
If the SLA-Content field does not exist in a BGP UPDATE message
that contains the QoS attribute with an SLA Sub-type, then
receiver MUST inherit the previously 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 process the rest of the BGP message.
The lack of a valid prior SLA-Content field does not make this
attribute invalid, so the attribute MUST be forwarded as a
valid BGP optional transitive attribute.
3.3. SLA-Content per Event Field
The only event described below is ADVERTISE. The format of SLA-
Content for the ADVERTISE event is shown in Figure 4.
The only event prescribed in this document is ADVERTISE.
The format of SLA ADVERTISE event message is,
0 1 2 3 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 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| | |dir| Traffic Class count | Class Desc Len| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Description ~ ~ Traffic Class Description ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elements Count| | | Elements Count| |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Elements TLVs ~ ~ Traffic Class Elements (TLVs) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Count| | | Service Count| |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
| Traffic Class Service TLVs | | Traffic Class Service TLVs |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Repeat from Traffic Class Description for next Traffic Class ~ ~ Repeat from Traffic Class Description for next Traffic Class ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Repeat from direction for SLA in the other direction ~ ~ Repeat from direction for SLA in the other direction ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
dir (Direction) Figure 4 - SLA-Content for event ADVERTISE
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) SLA-content contains set of Traffic Class Elements (Classifiers) and
16-bit, count of number of classifier groups Service TLVs for a list of Traffic Classes. This list of Traffic
00 = Advertisement to invalidate previous advertised SLA if any Classes MUST be specified for one direction first and then optionally
followed by for the opposite direction.
Traffic Class Descr Length dir (Direction): 2 bit field that indicates Direction of the SLA.
08-bit, length of the description The following values are defined:
0 = No description 0x0 = reserved
Traffic Class Description 0x1 = incoming, to source AS from destination AS
Description of the Traffic Class in UTF-8 encoding
Traffic Class Elements Count in a Traffic Class, 0x2 = outgoing, from source AS towards destination AS
08-bit count of classifier elements in a specific Traffic Class 0x3 = for future use
00 = this has relative definition. It means classify rest all Traffic Class (Classifier Group) count: 16 bit field with the count
traffic that is not classified via earlier described of number of classifier groups. The value of zero (0x00)in this
Traffic Classes. field is a special value which invalidates previous advertised SLA
It is RECOMMENDED that Traffic Class that has 0 elements (if any exist).
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), Class Descr Len: 8 bit field that contains the length of the Traffic
Class Description field. The value of zero in this field
indicates that no Traffic Class Description field follows.
08-bit = IPFIX Element Identifier Traffic Class Description: The description field MUST carry UTF-8
08-bit = size, in octets, of the value field encoded description.
variable-length field = contains actual value
Given IPFIX [RFC5102] has well defined identifier set for a Elements (Classifier) Count: 8 bit field containing the count of
large number of packet attributes, IPFIX IANA registry is traffic elements. The value zero (0x00) means there are no
("https://www.ietf.org/assignments/ipfix") chosen to specify elements in the traffic class, and thus the traffic class is to
packet classification attributes. However, since not all classify rest of the traffic not captured otherwise by other
identifiers from IPFIX would be applicable to this proposal, traffic classes in the set for a given direction.
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.
+----+----------------------------+ It is RECOMMENDED that Traffic Class that has 0 elements is
| ID | Name | present last in the advertised list of Traffic Classes.
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|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 If an advertised message has it positioned somewhere else, then
is only applicable to the NLRI advertised for a given AFI/SAFI the receiver MUST re-order it, for the forwarding purpose, to
within the BGP update message. If a receiver receives a BGP the last position in the advertised list of Traffic Classes
update message with QoS/SLA attribute for an NLRI that is not from a given source AS.
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) The QoS attribute advertised from a specific source MUST NOT
08-bit count of service attributes fields to follow with have more than one such Traffic Classes (Traffic Class with 0
type/value pair elements count). If there are more than one such Traffic
List of service types and relevant values are discussed below Classes present then it is an error condition which should
follow handling of such BGP message as described in the Error
handling section.
00 = no bounded service (also means Best Effort) Classifier Element TLVs: (optional) variable length field containing
as many TLVs specified by the Elements count field. Each TLV has
the following format:
Traffic Class Service (optional), IPFIX Element Identifier: (8 bit type field) IPFIX Identifiers
16-bit = Traffic Class Service Type listed in Table 1.
08-bit = size, in octets, of the value field
variable-length field = contains actual value
- 0x00 = reserved Size of Value field: (8 bit field) - Indicates the length of
the value field.
- 0x01 = TRAFFIC_CLASS_TSPEC Value: A variable field containing a value appropriate for the
160-bits TSpec Parameter IPFIX element. It is an error if the IPFix field does not
The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p), contain the appropriate format (see BGP error handling in
(m) and (M) parameters as described in Invocation Information section 6). Only the IPFIX elements shown in Table 1 are
section of [RFC2212]. Note that inheriting the definition of supported.
TSpec here does not enable RFC2212 functionality. Only the
values of the Traffic Specification are used in this Any Traffic Class element advertised in the QoS attribute only
applies to the NLRI advertised (AFI/SAFIs) within the BGP UPDATE
message the QoS attribute is contained in. If a receiver receives
a BGP UPDATE message with QoS/SLA attribute for an NLRI that it
does not support then the receiver MUST NOT install that
advertised SLA and continue to forward this attribute as an
optional transitive attribute.
Service Count: 8 bit count of Traffic Class Service TLVs following
this count. A value of zero is a special value indicating "no
bounded service" (a.k.a., Best Effort (BE)).
Traffic Class Service TLVs: (optional) variable length field with
the following format for the TLVs
Traffic Class Service type: 16-bit field which specifies a
service type. Each service type is detailed in Section 3.3.2.
The list of available service types are,
0x00 = reserved
0x01 = TRAFFIC_CLASS_TSPEC
0x02 = L2_OVERHEAD
0x03 = MINRATE_IN_PROFILE_MARKING
0x04 = MINRATE_OUT_PROFILE_MARKING
0x05 = MAXRATE_IN_PROFILE_MARKING
0x06 = MAXRATE_OUT_PROFILE_MARKING
0x07 = DROP_THRESHOLD
0x08 = RELATIVE_PRIORITY
0x09 = SUB_TRAFFIC_CLASSES
Length of value field: 08-bit field that specifies the size of
a value field to follow.
TRAFFIC_CLASS_TSPEC type has a fixed size length of a value.
It is 96 bits specifying Tspec described in Section 3.3.2.1.
L2_OVERHEAD type has a fixed size length of a value. It is
8 bits as described in Section 3.3.2.2.
MINRATE_IN_PROFILE_MARKING type has a variable length value
(see Section 3.3.2.3).
MINRATE_OUT_PROFILE_MARKING type has a variable length value
(see Section 3.3.2.4).
MAXRATE_IN_PROFILE_MARKING type has a variable length value
(see Section 3.3.2.5).
MAXRATE_OUT_PROFILE_MARKING type has a variable length value
(see Section 3.3.2.6).
DROP_THRESHOLD type has a variable length value (see
Section 3.3.2.8).
RELATIVE_PRIORITY has a fixed size length of 4 bits
specifying the priority value. (see Section 3.3.2.9).
0x09 = SUB_TRAFFIC_CLASSES is a variable length field which
allows sub-classes to be specified under traffic classes
(see Section 3.3.2.10).
Value field: field containing value appropriate for one of the
Service Types. It is an error if this field does not contain
the appropriate format (see BGP error handling section for
details).
3.3.1. Supported IPFIX values for Classifier Elements
IPFIX [RFC7012] has well defined identifier set for a large number of
packet attributes; an IPFIX IANA registry maintains values for packet
classifier attributes (https://www.ietf.org/assignments/ipfix").
Only the IPFIX attributes listed in Table 1 are supported by BGP SLA
exchange. Any new attribute to be supported by SLA QOS MUST be added
by a Standards Action.
+----+----------------------------+
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|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 |
+----+----------------------------+
Table 1
3.3.2. Traffic Class Service TLVs
3.3.2.1. Traffic Class TSPEC TLV
The TRAFFIC_CLASS_TSPEC TLV consists of:
type = 0x01
length = 96 bits (12 octets) TSpec field
value = 96 bits, TRAFFIC_CLASS_TSPEC value consists of the (r),
(b), (p) parameters as described in Invocation Information section
of [RFC2212] and shown in Figure 5. 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. specification.
0 1 2 3 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 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) | | Minimum Rate (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Size (b) (32-bit IEEE floating point number) | | Burst Size (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Rate (p) (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 Figure 5 - Traffic Class TSPEC
Format of Parameters (r), (b) and (p): are 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].
Parameter (r): indicates min-rate of the traffic class. This rate
indicates the minimum rate, measured in octets of Layer 2 (L2) indicates the minimum rate, measured in octets of Layer 2 (L2)
datagrams per second, that the service advertiser is providing datagrams per second, that the service advertiser is providing for
for a given class of traffic on advertiser's hop. Note that it a given class of traffic on advertiser's hop. Note that it does
does not necessarily translate to a minimum rate service to the not necessarily translate to a minimum rate service to the
receiver of an SLA unless the traffic class definition clearly receiver of an SLA unless the traffic class definition clearly
represents a sole receiver of an SLA. If there is no SLA for represents a sole receiver of an SLA. If there is no SLA for min-
min-rate, the value of (r) MUST be set to 0. rate, the value of (r) MUST be set to 0.
Parameter (b) indicates maximum burst size, measured in octets of Parameter (b): indicates maximum burst size, measured in octets of
L2 datagram size. Since queuing delay can be considered a L2 datagram size. Since queuing delay can be considered a
function of burst size (b) and min-rate (r), in presence of non- function of burst size (b) and min-rate (r), in presence of non-
zero parameter (r), parameter (b) represents bounded delay for zero parameter (r), parameter (b) represents bounded delay for the
the Traffic Class. This delay is a single hop queuing delay when Traffic Class. This delay is a single hop queuing delay when SLA
SLA is to be implemented at the resource constrained bottleneck. is to be implemented at the resource constrained bottleneck. In
In other words this burst size can be considered as a buffer other words this burst size can be considered as a buffer size.
size. Value of 0 for parameter (b) means the advertiser does not Value of 0 for parameter (b) means the advertiser does not mandate
mandate specific bounded delay. specific bounded delay.
Parameter (p) indicates max-rate of the traffic class. Just like Parameter (p): indicates max-rate of the traffic class. Just like
min-rate, max-rate, measured in octets of L2 packets per second, min-rate, max-rate, measured in octets of L2 packets per second,
field here also indicates service provided by advertiser. If field here also indicates service provided by advertiser. If
advertiser does not have any specific value to set for a given advertiser does not have any specific value to set for a given
class of traffic, it MAY be set to physical interface line rate class of traffic, it MAY be set to physical interface line rate or
or any other indirect limit that may affect this class' maximum any other indirect limit that may affect this class' maximum rate.
rate. In absence of any such known value, it MUST be set to In absence of any such known value, it MUST be set to positive
positive infinity. Value 0 is considered an error. infinity. Value 0 is considered an error.
Parameters (r), (b) and (p) are each set as 32-bit IEEE floating 3.3.2.2. Traffic Class L2 Overhead
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) The L2_OVERHEAD traffic class consists of:
parameters have no relevance for the purpose of SLA exchange.
Thus they MUST be ignored.
- 0x02, L2_OVERHEAD Type = 0x02 (L2_OVERHEAD)
08-bit, value
By default specification of rate and other packet size related Length = 1 octet
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 value = 8 bits, count of L2 overhead from sender in bytes
advertise this service with a value of 0.
- 0x03 = MINRATE_IN_PROFILE_MARKING By default the packet rate and other packet size related parameters
08-bit = IPFIX Element Identifier advertised in an SLA include the L2 packet overhead. For the
08-bit = size, in octets, of the value field receiver (of the SLA at next hop),this overhead is the L2 overhead of
variable-length field = contains actual value the local link where advertised SLA is received.
00 Identifier = drop, variable-length for this id is 0. However, in cases where advertised SLA is for a receiver multiple
hops away, L2 overhead from the source perspective may be different
from the local L2 overhead at the receiver. In such cases, the
explicit notification of size of L2 overhead from a sender is
necessary for the a receiver to be able to know the L2 overhead
required by the sender. When the receiver chooses to react to an
advertised SLA and if the L2 Overhead service type is present in
advertised SLA, the receiver MUST use the explicit advertised L2
overhead rather than the local L2 overhead.
+----+----------------------------+ If SLA is required to consider only IP packet size, the sender MAY
| ID | Name | advertise this service with a value of 0.
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
- 0x04 = MINRATE_OUT_PROFILE_MARKING 3.3.2.3. Traffic Class for 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. The MINRATE_IN_PROFILE_MARKING traffic class consists of:
+----+----------------------------+ Type = 0x03 = MINRATE_IN_PROFILE_MARKING
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
- 0x05 = MAXRATE_IN_PROFILE_MARKING Length = 2 octets
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. Value:
+----+----------------------------+ Marking code-point type = 8 bits (1 octet) IPFIX Element
| ID | Name | Identifier.
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
- 0x06 = MAXRATE_OUT_PROFILE_MARKING Marking code-point value = 8 bits (1 octet) code-point number.
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. The marking code-point type of 0x00 is a drop identifier; the length
in this case is zero.
+----+----------------------------+ The following table lists the supported IPFIX Identifiers:
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
In the case when MINRATE_IN_PROFILE_MARKING, +----+----------------------------+
MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and | ID | Name |
MAXRATE_OUT_PROFILE_MARKING are all advertised, +----+----------------------------+
- MINRATE_IN_PROFILE_MARKING takes highest precedence |195 | ipDiffServCodePoint |
(that is over MAXRATE_IN_PROFILE_MARKING) |203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
- MAXRATE_IN_PROFILE_MARKING takes precedence over Table 2
MINRATE_OUT_PROFILE_MARKING
- and MAXRATE_OUT_PROFILE_MARKING takes precedence over 3.3.2.4. Traffic Class for MINRATE_OUT_PROFILE_MARKING
MINRATE_OUT_PROFILE_MARKING
- 0x07 = DROP_THRESHOLD The MINRATE_OUT_PROFILE_MARKING traffic class consists of:
03-bit count of drop-priority fields to follow with
(type, type-value, burst size) tuple
04-bit, drop priority type Type = 0x04 = MINRATE_OUT_PROFILE_MARKING
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)
+----+----------------------------+ Length = 2 octets
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
This finer granular drop threshold does not require separate Value:
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 Marking code-point type = 8 bits (1 octet) IPFIX Element
04-bit, priority value Identifier.
lower the value, higher the priority
Relative priority indicates scheduling priority. For example Marking code-point value = 8 bits (1 octet) code-point number.
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
priority for those classification groups may be advertised with
the same value.
- 0x09 = SUB_TRAFFIC_CLASSES The marking code-point type of 0x00 is a drop identifier; the length
variable-length, repeats all content described above from Traffic in this case is zero.
Class count onwards.
For SLAs where a specific Traffic Class may further have The following table lists the supported IPFIX Identifiers:
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 | ID | Name |
their own classifier elements and service types. +----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 3
3.3.2.5. Traffic Class for MAXRATE_IN_PROFILE_MARKING
The MAXRATE_IN_PROFILE_MARKING traffic class consists of:
Type = 0x05 = MAXRATE_IN_PROFILE_MARKING
Length = 2 octets
Value:
Marking code-point type = 8 bits (1 octet) IPFIX Element
Identifier.
Marking code-point value = 8 bits (1 octet) code-point number.
The marking code-point type of 0x00 is a drop identifier; the length
in this case is zero.
The following table lists the supported IPFIX Identifiers:
+----+----------------------------+
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 4
3.3.2.6. Traffic Class for MAXRATE_OUT_PROFILE_MARKING
The MAXRATE_OUT_PROFILE_MARKING traffic class consists of:
Type = 0x06 = MAXRATE_OUT_PROFILE_MARKING
Length = 2 octets
Value:
Marking code-point type = 8 bits (1 octet) IPFIX Element
Identifier.
Marking code-point value = 8 bits (1 octet) code-point number.
The marking code-point type of 0x00 is a drop identifier; the length
in this case is zero.
The following table lists the supported IPFIX Identifiers:
+----+----------------------------+
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 5
3.3.2.7. Precedence between MINRATE and MAXRATE
The precedence between MINRATE_IN_PROFILE_MARKING,
MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and
MAXRATE_OUT_PROFILE_MARKING when all four are advertised is:
o MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over
MAXRATE_IN_PROFILE_MARKING),
o MAXRATE_IN_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING, and
o MAXRATE_OUT_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING
3.3.2.8. Traffic Class for DROP_THRESHOLD
The DROP_THRESHOLD traffic class consists of:
Type = 0x07 - DROP_THRESHOLD
Length = 1 octet that specifies total length of all set of drop
thresholds.
A set of drop threshold contains list of code-points of a specific
type sharing a threshold in unit of bytes. There MAY be more than
one set of such threshold for this Service Type per Traffic Class.
Value: number of set of thresholds and values in form of a sub-TLV
for each set.
Number of set of thresholds = 1 octet
sub-TLV for each set: Each sub-TLV specifies a code-point type/
values that the burst size is applicable to. The sub-TLV is in
the form of a (code-point type, value length, value) where
value = list of code-points + burst size in unit of bytes
applicable to that code-points.
sub-TLV code point type = 8 bits (1 octet) IPFIX Element
Identifier from the list shown in Table 6.
sub-TLV Length = 1 octet that specifies total length for set
of code-points and burst size.
sub-TLV Value: variable length field with
sequence of code points - one code-point value specified
in 1 octet.
4 octets burst size - 32 bit (4 octets) IEEE Floating
point number.
+----+----------------------------+
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 6
3.3.2.9. Traffic Class for Relative Priority
The RELATIVE_PRIORITY traffic class consists of:
Type = 0x08 - RELATIVE_PRIORITY
Length = 4 bits
Value:
A value from range of 0 - 15. Lower the value means higher the
priority.
Relative priority indicates scheduling priority of this traffic
class. Voice traffic, for example, 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 priority for those
classification groups may be advertised with the same value.
3.3.2.10. Traffic Class for Sub-Traffic Classes
The SUB_TRAFFIC_CLASSES traffic class consists of:
Type = 0x09 - SUB_TRAFFIC_CLASSSES
length = the combined length of a set of traffic Class TLVs
included in a Sub-Traffic Classes grouping
value = sequence of traffic class TLVs
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 4. Originating SLA Notification
The QoS attribute MUST only be added by the originator and MUST NOT The QoS attribute MUST only be added by the originator and MUST NOT
be added during BGP propagation. be added during BGP propagation.
SLA messages SHOULD NOT be sent periodically just for the purpose of BGP UPDATE message with the QoS Attribute carrying SLA parameters
keep alive. Some sort of SLA policy change may be considered as a SHOULD NOT be sent periodically just for the purpose of KEEPALIVE
trigger for the advertisement. between two points. 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 For any modified SLA parameters, the originator MUST re-advertise the
entire set of SLA parameters. There is no provision to advertise entire set of SLA parameters. There is no provision to advertise
partial set of parameters. To invalidate previously advertised SLA partial set of parameters. To invalidate previously advertised SLA
parameters, a message MUST be sent with the same SLA id for the same parameters, a message MUST be sent with the same SLA id for the same
source with the Traffic Class count set to 0. source with the Traffic Class count set to 0.
4.1. SLA Contexts 4.1. SLA Contexts
In certain cases, the advertisement may relate to an SLA for In certain cases, the advertisement of a QoS Attribute in a BGP
aggregate traffic over a point-to-point connection between a specific UPDATE message may relate to an SLA for aggregate traffic over a
destination and a specific source. A point-to-point connection may point-to-point connection between a specific destination and a
be the physical link, that connects two BGP peers, or may be a specific source. A point-to-point connection may be the physical
virtual link (e.g. a tunnel). A BGP update message, in such cases, link, that connects two BGP peers, or may be a virtual link (e.g. a
with source AS number and NLRI prefix of source end-point can tunnel). In such cases, a BGP update message with source AS number
uniquely identify physical/virtual link and so establishes advertised and NLRI prefix of source end-point can uniquely identify physical/
SLA's context for that point to point link. virtual link in order to establish the context for the advertised
SLA's for that point to point link.
In the simplest case where Provider (e.g. PE) and Customer (e.g. 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 CE) devices are directly connected via a physical link and have only
a single link between them, CE can uniquely identify the forwarding a single link between them, the CE can uniquely identify the
link to PE with AS number of the PE and NLRI prefix being an IP forwarding link to PE with the following:
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
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 o AS number of the PE,
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 o NLRI prefix being an IP address of PE,
that are supported by the BGP protocol specification (like IPv4,
IPv6, VPN-IPv4, VPN-IPv6). o next hop to CE (that is the next hop address from CE to PE).
The SLA advertised in the QoS attribute in the BGP UPDATE message
sent from the PE to a CE, along with the PE's AS number and IP
address, establishes SLA context for the aggregate traffic through
CE-to-PE link.
The SLA advertised in the QoS attribute in the BGP UPDATE message
from PE to CE, with PE's AS number and any other prefix establishes
SLA for that specific prefix's traffic as a subset of traffic under
CE-to-PE link.
Even though this example is in the context of IP prefixes, QoS
attribute's 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 specification (like
IPv4, IPv6, VPN-IPv4, VPN-IPv6).
4.1.1. SLA Advertisement for Point-to-Point Connection 4.1.1. SLA Advertisement for Point-to-Point Connection
When SLA messages are intended to be advertised for the point-to- When BGP UPDATE message with the QoS Attribute with SLA is used to
point connection (physical or logical), the message is destined for advertise the QoS SLA for a point-to-point connection (physical or
the next hop and advertised message is in the context of the prefix logical), the next hop in the BGP message is used with the prefix of
of the source end-point of the point to point connection. the source end-point of the point to point connection.
The destination AS number set to, within QoS SLA attribute, typically The destination AS number in the QoS SLA attribute is typically set
is of the neighbor BGP speaker's. Alternatively, source AS and to the AS of the BGP peer's IP-Address.
destination AS count MAY be set to 0.
If the source AS number in the QoS SLA Attribute is set to zero, the
source AS and Destination AS fields in the QoS SLA attribute are
ignored. This occurs if the BGP peer is sending an UPDATE message
with the QOS SLA directly to a BGP peer (next-hop BGP peer).
4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away
When SLA messages are to be advertised beyond next hop, value of When a BGP UPDATE message with a QoS SLA attribute is to be sent by a
source AS, in the QoS attribute, MUST be set by the originator of the BGP peer beyond next hop peer, the value of source AS in the QoS
update message. If such an update is meant to be for a specific list attribute MUST be set by the originator of the UPDATE message. If
of AS(es) as receivers, then the list of destination AS MUST be such an update is meant to be for a specific list of AS(es) as
explicitly described in the QoS attribute message to avoid flooding receivers, then the list of destination AS(es) MUST be explicitly
of the QoS attribute data in the network beyond those destinations. 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 If a new prefix is added in an AS for which SLA parameters have
have already been advertised before for other existing prefixes, and already been advertised before for other existing prefixes, and if
if traffic to this new prefix is subject to the same SLA advertised traffic to this new prefix is subject to the same SLA advertised
earlier then BGP update for this new prefix may include QoS attribute earlier, then the BGP UPDATE for this new prefix may include QoS
containing just an SLA id, an id that was advertised earlier. The attribute containing just an SLA id for an SLA id that was advertised
corresponding Update message does not require to have the whole SLA earlier. This BGP UPDATE message does not require to have the whole
content. SLA id is sufficient to relate SLA parameters to new SLA content. The SLA id is sufficient to relate SLA parameters to
advertised prefix. new advertised prefixes.
5. SLA Attribute Handling at Forwarding Nodes 5. SLA Attribute Handling at Forwarding Nodes
The propagation of the QoS Attribute in the BGP UPDATE depends on the
rules detailed in the following sub-sections for forwarding the QoS
Attribute.
5.1. BGP Node Capable of Processing QoS Attribute 5.1. BGP Node Capable of Processing QoS Attribute
If a BGP node is capable of processing QoS attribute, it optionally If a BGP peer is capable of processing a QoS attribute in a BGP
MAY process the QoS attribute. If advertised SLA has a list of UPDATE message, it MAY process the QoS attribute. If UPDATE has a
destination ASes, it MAY trim the list and so count of destination AS QoS Attribute with a list of destination ASes, it MAY trim the list
to exclude ones that are not required in further announcement of BGP and adjust the count of the destination AS to exclude ones that are
updates. not required in further announcement of BGP UPDATE messages.
BGP node MUST drop SLA related sub-type from the QoS attribute, if BGP peer MUST drop SLA related sub-type from the QoS attribute, if
there is no more AS from the destination list in the forwarding path. there are no more ASes from the QoS Attribute's destination list in
The rest of the QoS attribute contents MAY be forwarded if there the forwarding path. The rest of the QoS attribute contents MAY be
exist other sub-types of QoS attribute and forwarding rules meets forwarded if there exist other sub-types of QoS attribute and
other sub-types requirements. If there is no other sub-types in the forwarding rules meets other sub-types requirements. If there is no
QoS attribute content then the node MUST drop the entire QoS other sub-types in the QoS attribute content then the node MUST drop
attribute all together. The other attributes and NLRI information the entire QoS attribute all together. The other attributes and NLRI
may be announced further if they meet rules defined by other information MAY be announced further if they meet rules defined by
attributes and BGP protocol. other attributes and BGP specification.
Except extracting the entire SLA sub-type of the QoS attribute and Except extracting the entire SLA sub-type of the QoS attribute and
trimming the list of destination AS list, all other content MUST NOT trimming the list of destination AS list, all other content MUST NOT
be modified by any intermediate receivers of the message. be modified by any intermediate receivers of the message.
5.2. SLA Attribute Handling at Receiver 5.2. SLA Attribute Handling at Receiver
Reception of and processing of advertised QoS SLA content are Reception of and processing of advertised QoS SLA content are
optional for the receiver. optional for the receiver. While reacting to SLA advertisement in a
QoS attribute,
While reacting to SLA advertisement o the receiving BGP peer SHOULD invalidate previous advertised SLA
- receiver SHOULD invalidate previous advertised SLA parameters if parameters if one exists for the same SLA id and source AS. If
one exists for the same SLA id and source AS. If the new the new advertised SLA has a non-zero traffic count, then the new
advertised SLA has a non-zero traffic count, then the new advertised SLA SHOULD be installed. If new advertised SLA update
advertised SLA SHOULD be installed. If new advertised SLA update is with Traffic Class count 0, then no further action is required.
is with Traffic Class count 0, then no action is required.
- When BGP update messages are triggered only as a result of SLA o When BGP UPDATE messages are triggered only as a result of SLA
policy change, BGP update message forwarding beyond intended policy change, BGP UPDATE message forwarding beyond intended BGP
receivers are not necessary. If receiver device implementation peer receivers is not necessary. If the receiver device
supports policy based filtering then receiver MAY implement a implementation supports policy based filtering, then the receiver
policy to filter such messages based on prefix and attribute. MAY implement a policy to filter such messages based on the prefix
and attribute.
If SLA advertised to the next hop neighbor, the receiver may If QoS attribute with the SLA is advertised to the next hop BGP peer
implement advertised SLA for the whole link, where the link could be who is a neighbor, the receiver MAY implement advertised SLA for the
physical or virtual link, connected to the neighbor. If SLA whole link; the link could be a physical or virtual connected to the
advertised to is not the next hop neighbor then receiver may neighbor. If the QoS Attribute with the SLA is advertised to a BGP
establish advertised SLA for that specific prefix list under the peer which is not the next hop neighbor, then receiver may establish
relevant link. It is completely up to the receiver to decide for advertised SLA for that specific prefix list under the relevant link.
which prefixes it should accept advertised SLA and for which ones it It is completely up to the receiver to decide for which prefixes it
won't. should accept advertised SLA and for which ones it will not accept.
6. Error Handling 6. Error Handling
Error conditions, while processing of the QoS attribute, SHALL be Error conditions, while processing of the QoS attribute, MUST be
handled with the approach of attribute-discard as described in [IDR- handled with the approach of attribute-discard as described in
ERR]. In such condition, receiver SHOULD also cleanup any previously [RFC7606]. In such condition, the receiver SHOULD also cleanup any
installed SLA state for the same prefix. previously installed SLA state for the same prefix.
7. Traffic Class Mapping 7. Traffic Class Mapping
It is possible that switching/routing methods used in 2 different It is possible that forwarding methods used in two different ASes
ASes could be different. For example, Provider may tunnel Customer's could be different. For example, provider may tunnel a customer's IP
IP traffic thru MPLS cloud. In such cases traffic class definition traffic thru an MPLS infrastructure. In such cases, the traffic
for QoS services may differ in both ASes. For the meaningful use of class definition for QoS services may differ between the ASes. For
advertised SLA in such cases, receiver is required to map traffic the meaningful use of advertised SLA in such cases, the receiver is
class from one type to the other. required to map the remote traffic class to the local traffic class.
In the example given, traffic classification in Customer AS could be In the example given, traffic classification in Customer AS could be
IP Diffserv-based whereas traffic classification in Provider AS could IP Diffserv-based whereas traffic classification in Provider AS could
be MPLS TC-based. Thus for advertised MPLS TC-based SLA would 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 require to map traffic class from IP Diffserv-based to MPLS TC type
[RFC3270]. [RFC3270].
There are well-defined recommendations that exist for traffic class There are well-defined recommendations that exist for traffic class
mapping between two technologies, eg. RFC3270 for mapping between mapping between two technologies (e.g. [RFC3270] maps between DSCP
DSCP and MPLS TC. Receiver MAY use those defined recommendations for and MPLS TC). Receiver MAY use those defined recommendations for
traffic class mapping or MAY define its own as per its network traffic class mapping or MAY define its own as per its network
Traffic Class service definition to map to advertised Traffic Traffic Class service definition to map to advertised Traffic
Classes. It is completely up to the receiver how to define such Classes. It is completely up to the receiver how to define such
traffic class mapping. traffic class mapping.
8. Deployment Considerations 8. Deployment Considerations
One of the use cases is for a Provider to advertise contracted SLA One of the use cases is for a provider to advertise contracted SLA
parameters to Customer Edge (CE) in cases where eBGP is deployed parameters to a Customer Edge (CE) in cases where eBGP is deployed
between PE and CE. The SLA parameters may already be provisioned by between PE and CE. The SLA parameters may already be provisioned by
the provider on the PE device (facing CE). This provisioned SLA the provider on the PE device (facing CE). This provisioned SLA
parameters are then advertised thru proposed BGP QoS attribute to the parameters are then advertised thru proposed BGP QoS attribute to the
CE device. CE device may read the attribute and SLA sub-type content CE device. The CE device may read the attribute and SLA sub-type
to implement the QoS policy on the device. content to implement the QoS policy on the device.
Contracted SLA from PE to CE may be full line-rate or sub line-rate 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 or finer granular controlled services. The advertised SLA can be
when contracted service is sub-rate of a link and/or when for finer useful when contracted service is sub-rate of a link and/or when for
granular traffic classes that are controlled (e.g. voice, video finer granular traffic classes that are controlled (e.g. voice, video
services may be capped to certain rate) services may be capped to certain rate).
_______________
__________ / \
/ \ / \
/ \ / \
|CustomerSite|-----| Provider |
\ C/E P\E /
\__________/ \ /
\_______________/
AS 3 AS 2
SLA_ADVERTISE: AS2 to AS3 _______________
NLRI = PE ip address __________ / \
/ \ / \
/ \ / \
|CustomerSite|-----| Provider |
\ C/E P\E /
\__________/ \ /
\_______________/
AS 3 AS 2
SLA_ADVERTISE: AS2 to AS3
NLRI = PE ip address
Figure 6 - Example 1
Another use case can be to advertise SLAs among different network Another use case can be to advertise SLAs among different network
sites within one Enterprise network. In Hub and Spoke deployments, sites within one Enterprise network. In Hub and Spoke deployments,
Administrator may define SLAs at spoke and advertise QoS SLA Administrator may define SLAs at spoke and advertise QoS SLA
parameters to the Hub thru BGP updates. In the figure below, each parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1
spoke (AS1 and AS2) are connected to Hub (AS3) via a VPN tunnel. As and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in
shown, AS2 can advertise SLA to AS3 in the context of that tunnel ip Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel
address. ip address.
AS 2 AS 2
_______________ ________ _______________ ________
/ \ / \ / \ / \
__________ / \-----| Spoke2 | _____ / \-----| Spoke2 |
/ \ / \ \________/ / \ / \ \________/
| Hub |-----| Provider | ________ | Hub |-----| Provider | ________
\__________/ \ / / \ \______/ \ / / \
\ /-----| Spoke1 | \ /-----| Spoke1 |
AS 3 \_______________/ \________/ AS 3 \_______________/ \________/
AS 1
AS 1 SLA_ADVERTISE: AS2 to AS3
NLRI = AS2 tunnel address
SLA_ADVERTISE: AS2 to AS3 SLA_ADVERTISE: AS1 to AS3
NLRI = AS2 tunnel address NLRI = AS1 tunnel address
SLA_ADVERTISE: AS1 to AS3 Figure 7 - Example 2
NLRI = AS1 tunnel address
Deployment options are not limited to involving CEs, PE-to-CE or CE- Deployment options are not limited to involving CEs, PE-to-CE or CE-
to-CE, only. For any contract between two providers, SLA parameters to-CE, only. For any contract between two providers, SLA parameters
may be advertised from one to the other. may be advertised from one to the other.
9. Acknowledgements 9. Acknowledgements
Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for
their suggestions and to Christian Jacquenet, Ken Briley, Rahul their suggestions and to Christian Jacquenet, Ken Briley, Rahul
Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier, Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier,
skipping to change at page 20, line 22 skipping to change at page 25, line 45
10. IANA Considerations 10. IANA Considerations
This document defines a new BGP optional transitive path attribute, This document defines a new BGP optional transitive path attribute,
called QoS Attribute. IANA action is required to allocate a new called QoS Attribute. IANA action is required to allocate a new
code-point in the BGP path Attributes registry. code-point in the BGP path Attributes registry.
IANA is requested to create a registry for QoS Attribute subTypes. 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 This is a registry of 1 octet value, to be assigned on a standards
action/early allocation basis. The initial assignments are: action/early allocation basis. The initial assignments are:
QoS Attribute subTypes QoS Attribute subTypes
- - - - - - - - - - - - ============= ========
Reserved 0x00 Reserved 0x00
SLA 0x01 SLA 0x01
Reserved 0x02-0xff (Standards Action)
IANA is requested to create a registry for SLA Event Types. This is 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/ a registry of 4-bits value, to be assigned on a standards action or
early allocation basis. The initial assignments are: early allocation basis. The initial assignments are:
QoS Attribute SLA Event Types QoS Attribute SLA Event Types
- - - - - - - - - - - - - - - ============= ===============
Reserved 0x00 Reserved 0x00
ADVERTISE 0x01 ADVERTISE 0x01
IANA is requested to create a registry to define QoS SLA Direction. IANA is requested to create a registry to define QoS SLA Direction.
This is the direction in forwarding path, advertised QoS SLA is This is the direction in forwarding path, advertised QoS SLA is
applicable to. applicable to. The values for QoS SLA direction are:
QoS SLA Direction QoS SLA Direction Value
- - - - - - - - - ================= =====
Reserved 0x00 Reserved 0x00
to Source AS from destination AS 0x01 To source AS from destination AS 0x01
from source AS to destination AS 0x02 From source AS to destination AS 0x02
QoS SLA Traffic Class Element Types will be referring to existing QoS SLA Traffic Class Element Types will be referring to existing
IPFIX IANA types as described in section 3.1. IPFIX IANA types as listed in Table 1.
IANA is requested to create a registry for QoS SLA Traffic Class 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 Service Types. This is a registry of 2 octet values, to be assigned
on a standards action/early allocation basis. The initial on a standards action/early allocation basis. The initial
assignments are: assignments are:
Traffic Class Service Type Traffic Class Service Type Value
- - - - - - - - - - - - - - ============================ ======
Reserved 0x00 Reserved 0x00
TRAFFIC_CLASS_TSPEC 0x01 TRAFFIC_CLASS_TSPEC 0x01
L2_OVERHEAD 0x02 L2_OVERHEAD 0x02
MINRATE_IN_PROFILE_MARKING 0x03 MINRATE_IN_PROFILE_MARKING 0x03
MINRATE_OUT_PROFILE_MARKING 0x04 MINRATE_OUT_PROFILE_MARKING 0x04
MAXRATE_IN_PROFILE_MARKING 0x05 MAXRATE_IN_PROFILE_MARKING 0x05
MAXRATE_OUT_PROFILE_MARKING 0x06 MAXRATE_OUT_PROFILE_MARKING 0x06
DROP_THRESHOLD 0x07 DROP_THRESHOLD 0x07
RELATIVE_PRIORITY 0x08 RELATIVE_PRIORITY 0x08
SUB_TRAFFIC_CLASSES 0x09 SUB_TRAFFIC_CLASSES 0x09
11. Security Considerations 11. Security Considerations
The QOS attribute defined in this document SHOULD be used by the The QOS attribute defined in this document SHOULD be used by the
managed networks for enforcing Quality of Service Policies and so managed networks for enforcing Quality of Service policies and so
there should not be any risks for identity thefts. To strengthen the there should not be any risks for identity thefts. To strengthen the
security for the QOS attribute, RPKI based origin validation security for the QoS attribute, RPKI based origin validation
[RFC7115] MAY be used. In addition to the RPKI based origin [RFC7115] MAY be used. In addition to the RPKI based origin
validation, BGP Path Validation [I-D.ietf-sidr-bgpsec-protocol] validation, BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec-
procedures could be used over BGP QOS attribute and its associated protocol]) procedures could be used over BGP QoS attribute and its
prefix in producing the digital signature that can be carried within associated prefix in producing the digital signature that can be
the signature SLA for the messages. This would help prevent any man- carried within the signature SLA for the messages. This would help
in-the-middle attracks. prevent any man- in-the-middle attacks.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 22, line 16 skipping to change at page 27, line 43
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>. <http://www.rfc-editor.org/info/rfc3270>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <http://www.rfc-editor.org/info/rfc4506>. 2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
Meyer, "Information Model for IP Flow Information Export", for IP Flow Information Export (IPFIX)", RFC 7012,
RFC 5102, DOI 10.17487/RFC5102, January 2008, DOI 10.17487/RFC7012, September 2013,
<http://www.rfc-editor.org/info/rfc5102>. <http://www.rfc-editor.org/info/rfc7012>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the [RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185, Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014, RFC 7115, DOI 10.17487/RFC7115, January 2014,
<http://www.rfc-editor.org/info/rfc7115>. <http://www.rfc-editor.org/info/rfc7115>.
[IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
"Revised Error Handling for BGP UPDATE Message, I-D.draft- Patel, "Revised Error Handling for BGP UPDATE Messages",
ietf-idr-error-handling", June 2012. RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in
progress), December 2015.
[I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPsec Protocol Specification", draft-ietf-
sidr-bgpsec-protocol-14 (work in progress), December 2015.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
<http://www.rfc-editor.org/info/rfc7297>. <http://www.rfc-editor.org/info/rfc7297>.
[BGP-SEC] Lepinski, M., "BGPsec Protocol Specification, I-D.draft- [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
ietf-sidr-bgpsec-protocol", June 2015. Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <http://www.rfc-editor.org/info/rfc7674>.
[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 Authors' Addresses
Shitanshu Shah Shitanshu Shah
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: svshah@cisco.com Email: svshah@cisco.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: keyupate@cisco.com Email: keyupate@cisco.com
Sandeep Bajaj Sandeep Bajaj
Juniper Networks Juniper Network
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: sbajaj@juniper.net Email: sbajaj@juniper.net
Luis Tomotaki Luis Tomotaki
Verizon Verizon
400 International 400 International
Richardson, TX 75081 Richardson, TX 75081
US US
Email: luis.tomotaki@verizon.com Email: luis.tomotaki@verizon.com
Mohamed Boucadair Mohamed Boucadair
France Telecom Orange
Rennes 35000 Rennes
35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 145 change blocks. 
609 lines changed or deleted 855 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/