draft-ietf-idr-sla-exchange-08.txt   draft-ietf-idr-sla-exchange-09.txt 
IDR 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: August 8, 2016 S. Bajaj Expires: February 2, 2017 S. Bajaj
Juniper Network Juniper Network
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
Orange Orange
February 5, 2016 August 1, 2016
Inter-domain SLA Exchange Attribute Inter-domain SLA Exchange Attribute
draft-ietf-idr-sla-exchange-08.txt draft-ietf-idr-sla-exchange-09.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, often manual, process and prone to errors. complex, often manual, process and prone to errors.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 8, 2016. This Internet-Draft will expire on February 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 5
3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5 3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6
3.2. SLA SubType Value Field . . . . . . . . . . . . . . . . . 6 3.2. SLA SubType . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. SLA-Content per Event Field . . . . . . . . . . . . . . . 8 3.3. SLA Content for ADVERTISE SLA Event . . . . . . . . . . . 9
3.3.1. Supported IPFIX values for Classifier Elements . . . 12 3.3.1. Supported IPFIX identifiers for Traffic Class
3.3.2. Traffic Class Service TLVs . . . . . . . . . . . . . 13 Elements . . . . . . . . . . . . . . . . . . . . . . 13
4. Originating SLA Notification . . . . . . . . . . . . . . . . 20 3.3.2. Traffic Class Service types and respective TLVs . . . 14
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 20 4. Originating SLA Notification . . . . . . . . . . . . . . . . 21
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 Away . . . . . . . . . . . . . . . . . . . . . . . . 22
5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 22 5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 22
5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 22 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 23
5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 22 5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 23
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23
7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 23 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 [RFC7297]. This QoS SLA defines the nature of the various providers [RFC7297]. This QoS SLA defines the nature of the various
traffic classes and services needed within each traffic class. The traffic classes and services needed within each traffic class. The
contract may include full line-rate or sub line-rate without contract may include full line-rate or sub line-rate without
additional traffic classes, or it may contain additional traffic additional traffic classes, or it may contain additional traffic
classes and service definitions for those traffic classes. Finer classes and service definitions for those traffic classes. Finer
skipping to change at page 3, line 33 skipping to change at page 3, line 33
network, translating SLAs into technology-specific and vendor- network, translating SLAs into technology-specific and vendor-
specific configuration requires the network administrator to consider specific configuration requires the network administrator to consider
specific configuration of each vendor. There does not exist any specific configuration of each vendor. There does not exist any
standard protocol to translate SLA agreements into technical clauses standard protocol to translate SLA agreements into technical clauses
and configurations and thus both the steps of out of band learning of and configurations and thus both the steps of out of band learning of
negotiated SLA and provisioning them in a vendor specific language negotiated SLA and provisioning them in a vendor specific language
can be complex and error-prone. can be complex and error-prone.
SLA parameters may have to be exchanged through organizational SLA parameters may have to be exchanged through organizational
boundaries, thru SLA documents or via some other off-band method, to boundaries, thru SLA documents or via some other off-band method, to
an administrator provisioning actual devices. an administrator provisioning actual devices. For example, to
provide voice services, the provider may negotiate QoS parameters
For example, to provide voice services, the provider may negotiate (like min/max rates) for such traffic classified under the EF
QoS parameters (like min/max rates) for such traffic classified under (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475]
the EF (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475]
networks. The Administrator at the CE (Customer Edge) not only will networks. The Administrator at the CE (Customer Edge) not only will
have to know that provider's service for voice traffic is EF-based 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 but will also have to know how to implement DSCP EF classification
rule along with Low Latency Service, and possibly min/max rate rule along with Low Latency Service, and possibly min/max rate
enforcement for the optimal use of bandwidth, as per vendor specific enforcement for the optimal use of bandwidth, as per vendor specific
provisioning language. provisioning language.
The Inter-domain exchange of QoS SLA exchange policy described in The Inter-domain exchange of QoS SLA policy described in this
this document does not require any specific method for the provider document does not require any specific method for the provider in
in establishing SLAs. It only requires that the provider wishes to establishing SLAs. It only requires that the provider wishes to send
send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the the QoS SLA policy via BGP UPDATE [RFC4271] messages from the
provider to a set of receivers (BGP peers) who will enact the policy. provider to a set of receivers (BGP peers). In reaction to, a
In reaction to, a receiving router may translate that to relevant QoS receiving router may translate that to relevant QoS policy definition
policy definition on the device. on the device. The SLA negotiation and assurance is outside the
scope of this document.
This document defines a new optional transitive BGP QoS attribute
which has as one of its sub-types the SLA policy. The BGP speakers
of the originating AS send the BGP Attribute for prefixes this QoS
SLA Policy applies to in a BGP UPDATE message that will be
distributed to a list of destination ASes. The QoS SLA policy can be
for inbound traffic to the advertising AS or outbound traffic from
the advertising AS, or both.
The SLA negotiation and assurance is outside the scope of this This document defines a new optional BGP transitive attribute,
document. In the future, other sub-types of the QoS Attribute may referred as QoS Attribute, which has as one of its sub-types the SLA
deal with QoS other than SLA Policy for traffic. policy. The BGP node of the originating AS sends this QoS Attribute,
for prefixes this QoS SLA Policy applies to, in a BGP UPDATE message
that will be distributed to a list of destination ASes. The QoS SLA
policy can be for inbound traffic to the advertising AS or outbound
traffic from the advertising AS, or both.
Protocols and data models are being created to standardize setting Protocols and data models are being created to standardize setting
routing configuration parameters within networks. YANG data models routing configuration parameters within networks. YANG data models
[RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf [RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf
([I-D.ietf-netconf-restconf]) can set these standardized in ([I-D.ietf-netconf-restconf]) can set these standardize in
configuration mechanisms. For ephemeral state, the I2RS protocol is configuration mechanisms. For ephemeral state, the I2RS protocol is
being developed to set ephemeral state. While these protocol provide being developed to set ephemeral state. While these protocols
valid configuration within a domain or across domains, some providers provide valid configuration within a domain or across domains, some
desire to exchange QoS parameters in-band utilizing BGP peering providers desire to exchange QoS parameters in-band utilizing BGP
relationships. This is similar to the distribution of Flow peering relationships. This is similar to the distribution of Flow
Specification information via BGP peering relationships (see Specification information via BGP peering relationships (see
[RFC5575] and [RFC7674]). [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].
BGP Speaker: A functional component on a BGP capable device that
functions as per BGP specification.
BGP Peers: BGP Speakers adjacent to each other.
QoS Attribute Speaker: A functional component on a BGP capable device
that produces and/or processes content of the QoS Attribute. A
device that is QoS Attribute Speaker is also always a BGP Speaker.
However, a BGP Speaker not necessarily always a QoS Attribute
Speaker.
QoS Attribute content is produced and processed outside the function
of the BGP Speaker and thus content of the QoS Attribute is
completely opaque to the BGP Speaker. At BGP capable device where
QoS Attribute content is produced, length and value of the QoS
Attribute is passed from QoS Attribute Speaker to the BGP Speaker
where BGP Speaker inserts the attribute into the BGP UPDATE message
with appropriate attribute flags, attribute type, and length and
value passed from the QoS Attribute Speaker. Similarly, a BGP
capable device when receives QoS Attribute in the BGP UPDATE message,
BGP Speaker extracts QoS Attribute value from the message and passes
it to the QoS Attribute Speaker where QoS Attribute Speaker processes
the content from that passed down value. How the content of the QoS
Attribute is passed from the QoS Attribute Speaker to the BGP Speaker
and vice versa is implementation specific.
In the context of use of QoS Attribute for SLA parameters exchange,
following roles are defined further within the scope of the QoS
Attribute Speaker.
SLA Producer: This is a QoS Attribute Speaker that produces QoS
Attribute for the SLA SubType.
SLA Consumer: This is a QoS Attribute Speaker that is intended
receiver of QoS Attribute with the SLA SubType.
3. QoS Attribute Definition 3. QoS Attribute Definition
The QoS Attribute is an optional transitive attribute (TBD - The QoS Attribute is an optional transitive attribute (TBD -
attribute code to be assigned by IANA). SLA is defined as one of the attribute code to be assigned by IANA) which is applicable to the
sub-types in the QoS attribute. The QoS attribute is only applicable Source AS and NLRIs advertised in the BGP UPDATE message this
to the NLRIs advertised in the BGP UPDATE message this attribute is attribute is included in. The format of the QoS Attribute is shown
included in. in Figure 1.
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 Figure 1
highest order bit (bit 0) -
MUST be set to 1, since this is an optional attribute
2nd higher order bit (bit 1) - Attribute flags - 8-bits field
MUST be set to 1, since this is a transitive attribute
Figure 1 - QoS BGP attribute highest order bit (bit 0) - MUST be set to 1, since this is an
optional attribute
3.1. SLA, QoS attribute sub-type, Definition 2nd higher order bit (bit 1) - MUST be set to 1, since this is a
transitive attribute
The value field of the QoS Attribute contains the following: The content of the QoS Attribute is further specified with flags,
applicable to QoS Attribute content, and a SubType in a TLV form.
QoS Attribute flags, and 3.1. QoS Attribute SubType
Tuple of (SLA sub-type, length, value). The Value field of the QoS Attribute contains the following:
QoS Attribute flags
Tuple (SubType of the QoS Attribute, SubType length, SubType
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| SubType-Value | | SubType value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+
Figure 2 - Format of BGP QoS Attribute Figure 2 - Format of QoS Attribute
QoS Attr flags 1 octet. All the bits are currently un-used. The QoS Attr flags - 8-bits field
space is provided for future use. All bits MUST be set to zero
when sent. The values (0x01-0xFF) are reserved, and MUST be
ignored when received.
SubType 1 octet field with the following values: All bits of this field are currently un-used. The space is
provided for future use. All bits MUST be set to zero when sent.
The values (0x01-0xFF) are reserved, and MUST be ignored when
received.
SubType - 8-bits field with following values:
0x00 = reserved 0x00 = reserved
0x01 = SLA 0x01 = SLA
0x02 - 0x0f = reserved for future use (Standards Action) 0x02 - 0xf0 = reserved for future use (Standards Action)
SubType length - 2 octet field with length of sub-type value. 0xf1 - 0xff = Private use
SubType Value variable length field containing information about: The only SubType of the QoS Attribute defined in this
sender and receiver(s), and SLA parameters described in specification is the SLA SubType.
Section 3.2.
3.2. SLA SubType Value Field SubType length - 16-bits field that specifies length of the SubType
value in number of octets.
The format of SubType Value field is shown in Figure 3. SubType value - variable length field, as expressed in SubType
length, that contains information about a specified SubType. For
the SLA SubType the information is about sender and receiver(s),
and SLA parameters as described in Section 3.2.
3.2. SLA SubType
Format of the SLA 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) | | SLA SubType flags | Destination AS count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Destination AS count | | Source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable list of destination AS | | variable list of Destination AS |
~ .... ~ ~ .... ~
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | SLA id | SLA length | |SLAEvnt| SLA ID | SLA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA-Content per SLA Event | | SLA Content for SLA Event |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - The format of SLA SubType of the BGP QoS attribute Figure 3 - Format of the SLA SubType of the QoS attribute
Source AS: 32-bit source AS number. This is the AS that is SLA SubType flags - 16-bits field
advertising SLA
0 = ignore Source and Destination AS list from this value field highest order bit (bit 0) -
Note that AS = 0, used in message outside of QoS attribute, is If set to 1 indicates that SLA ID and SLA Content, specified in
illegal in normal BGP operations. AS = 0 inside the QoS this SLA SubType, is from the source AS to the list of
attribute may be used simply as a flag to indicate to the Destination AS specified in the same SLA SubType.
receiver to ignore Source and Destination AS list from inside
the QoS attribute.
Destination AS count: 32-bit destination AS count to take variable If set to 0 indicates to ignore Source AS and list of
length AS list. This count has no functional value when Source AS Destination AS specified in this SLA SubType field. SLA ID and
is 0. SLA Content, specified in this SLA SubType, are intended for
the peer receiver of the BGP UPDATE message. In such a case,
on reception of such a message, QoS Attribute Speaker SHOULD
drop the QoS Attribute from the BGP UPDATE message and rest of
the BGP UPDATE message should be processed by BGP Speaker as
per BGP specification.
0 = QoS attribute is relevant to every receiver of the message Rest all other bits are currently un-used.
Destination AS list: Destination AS count - 16-bits field that specifies count of
destination ASNs present in the Destination AS list.
32-bit destination AS number This count has no functional value when highest order bit in the
SLA SubType flags field is set to 0. When highest order bit is
set to 1 and if this count is 0 then that is an error condition
which should be handled as described in Section 6.
.... Source AS - 32-bits field (AS number space as defined in RFC6793)
.... [as many as AS count] This is the AS where SLA Content is originated from. The Source
AS MUST be of the same AS that is originating SLA ID and SLA
Content.
SLA Event: When highest order bit in the SLA SubType flags field is set to 0,
this Source AS value MUST be ignored. In such a case SLA ID and
SLA Content of this SLA SubType is intended for the peer receiver
of the BGP UPDATE message.
4-bits with values When highest order bit in the SLA SubType flags field is set to 1,
the Source AS value of 0 is illegal and thus should be considered
an error which should be handled as described in Section 6.
Destination AS list - variable length field that holds as many ASN
identifiers, each is 32-bits (AS number space is defined in
RFC6793), as specified in the Destination AS count field.
List of ASNs for which the SLA is relevant to, each of which is a
32-bit number. If Destination AS count is set to 0 then this
field MUST NOT be included.
SLA Event - 4-bits field with following values:
0x0 = reserved 0x0 = reserved
0x1 = ADVERTISE 0x1 = ADVERTISE
0x2 to 0xf - Reserved for future use 0x2 to 0xf = Reserved for future use
SLA Id: A 16-bit field containing identifier which is unique in The only SLA Event defined in this specification is ADVERTISE.
scope of source AS
The significance of an SLA identifier is in the context of the SLA ID - 16-bits field that specifies identifier which is unique in
source that is advertising SLA parameters. The SLA identifier the scope of Source AS.
is not globally unique but it MUST be unique within the source
AS (advertiser).
If the advertised SLA id is different from earlier advertised The significance of an SLA ID is in the context of the source that
one, for the same prefix, previous SLA content MUST be replaced is advertising SLA Content. The SLA ID is not globally unique but
with the new advertised one. it MUST be unique within the source AS.
The SLA ID applies aggregate for all the traffic to prefixes The SLA ID applies to aggregate traffic to prefixes for a given
for a given AFI/SAFI that share same source AS and SLA id. AFI/SAFI that share the same Source AS and SLA ID.
SLA Length: A 12-bit field indicating the length of SLA-Content. If an advertised SLA ID is different from earlier advertised one,
The SLA-content is optional for each advertised SLA id. If the for the same prefix and from the same Source AS, indicates Source
SLA-content field does not exist, the SLA length field value is AS is advertising new SLA Content to replace the previous one
zero. advertised with the same SLA ID.
SLA-Content per SLA Event: A variable length field (optional field). SLA Length - 12-bits field that specifies the length of the SLA
Content. The length is expressed in octets. The SLA Content is
optional for an advertised SLA ID. If the SLA Content need not be
there, the SLA length field MUST be set to zero in such a case.
If SLA field exists, it follows the format described in SLA Content - A variable length field (optional field)
Section 3.3.
If the SLA-Content field does not exist in a BGP UPDATE message The SLA Content field contains SLA parameters relevant to
that contains the QoS attribute with an SLA Sub-type, then specified SLA SubType. Since the only defined SLA SubType is
receiver MUST inherit the previously advertised SLA content for ADVERTISE, this specification describes SLA Content only for the
the same SLA id from the same Source AS. ADVERTISE SLA Event.
If there does not exist any prior SLA to relate to the If SLA Content field exists in a BGP UPDATE message that contains
advertised SLA id, then receiver can ignore the SLA the QoS Attribute with an SLA SubType for SLA Event ADVERTISE,
advertisement and process the rest of the BGP message. format of the SLA Content is as described in Section 3.3.
The lack of a valid prior SLA-Content field does not make this If the SLA Content field does not exist, then the advertised
attribute invalid, so the attribute MUST be forwarded as a message refers to SLA Content advertised in the previous message
valid BGP optional transitive attribute. for the same SLA ID. If there does not exist any prior SLA
Content to relate to the advertised SLA ID, then receiver, SLA
Consumer, can ignore the SLA advertisement and it may simply
update Destination AS count and Destination AS list.
3.3. SLA-Content per Event Field The lack of a valid prior SLA Content field does not make this
attribute invalid, so the QoS Attribute MUST be forwarded as a
valid BGP optional transitive attribute.
The only event described below is ADVERTISE. The format of SLA- 3.3. SLA Content for ADVERTISE SLA Event
Content for the ADVERTISE event is shown in Figure 4.
The only SLA Event described in this specification is ADVERTISE. The
format of SLA Content for the ADVERTISE Event is shown in Figure 4.
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| | | Element Count | |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Elements (TLVs) ~ ~ Traffic Class Element 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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - SLA-Content for event ADVERTISE Figure 4 - SLA-Content for ADVERTISE SLA Event
SLA-content contains set of Traffic Class Elements (Classifiers) and SLA Content contains set of Traffic Class Elements (Classifiers) and
Service TLVs for a list of Traffic Classes. This list of Traffic Traffic Class Service TLVs for a list of Traffic Classes. This list
Classes MUST be specified for one direction first and then optionally of Traffic Classes MUST be specified for one direction first and then
followed by for the opposite direction. optionally followed by the specification for the other direction.
dir (Direction): 2 bit field that indicates Direction of the SLA. dir (Direction) - 2-bits field that specifies Direction of the
The following values are defined: traffic SLA is applicable to. The following values are defined:
0x0 = reserved 0x0 = reserved
0x1 = incoming, to source AS from destination AS 0x1 = incoming, traffic to source AS from destination AS
0x2 = outgoing, from source AS towards destination AS 0x2 = outgoing, traffic from source AS towards destination AS
0x3 = for future use 0x3 = for future use
Traffic Class (Classifier Group) count: 16 bit field with the count Traffic Class (Classifier Group) count - 16 bits field that
of number of classifier groups. The value of zero (0x00)in this specifies number of Traffic Classes.
field is a special value which invalidates previous advertised SLA
(if any exist).
Class Descr Len: 8 bit field that contains the length of the Traffic The value of zero (0x00) in this field is a special value which
Class Description field. The value of zero in this field means no SLA for the traffic in a specified direction. When
indicates that no Traffic Class Description field follows. Traffic Class count is 0, for a specific direction, the rest of
the SLA Content fields MUST NOT be encoded, for that specific
direction.
Traffic Class Description: The description field MUST carry UTF-8 Traffic Class Description Len - 8-bits field that specifies the
encoded description. length of the Traffic Class Description field. The length is
expressed in octets.
Elements (Classifier) Count: 8 bit field containing the count of The value of zero in this field indicates that no Traffic Class
traffic elements. The value zero (0x00) means there are no Description field follows.
elements in the traffic class, and thus the traffic class is to
classify rest of the traffic not captured otherwise by other
traffic classes in the set for a given direction.
It is RECOMMENDED that Traffic Class that has 0 elements is Traffic Class Description - variable length field, as expressed in
present last in the advertised list of Traffic Classes. The Traffic Class Description Len field, MUST carry UTF-8 encoded
[RFC3629] description.
If an advertised message has it positioned somewhere else, then Traffic Class Elements (Classifier) Count - 8-bits field that
the receiver MUST re-order it, for the forwarding purpose, to specifies the count of Traffic Class Elements.
the last position in the advertised list of Traffic Classes
from a given source AS.
The QoS attribute advertised from a specific source MUST NOT The value zero (0x00) means there are no Traffic Class Elements in
the traffic class, and thus the Traffic Class is to classify rest
of the traffic not captured otherwise by other Traffic Classes in
the set for a specified direction.
Traffic Class that has 0 elements MUST be presented last in the
advertised list of Traffic Classes for a specific Direction.
Otherwise it is considered an error condition which should be
handled as described in Section 6.
The QoS Attribute advertised from a specific source MUST NOT
have more than one such Traffic Classes (Traffic Class with 0 have more than one such Traffic Classes (Traffic Class with 0
elements count). If there are more than one such Traffic elements count). If there are more than one such Traffic
Classes present then it is an error condition which should Classes present then it is an error condition which should be
follow handling of such BGP message as described in the Error handled as described in Section 6.
handling section.
Classifier Element TLVs: (optional) variable length field containing Traffic Class Element TLVs - (optional) variable length field
as many TLVs specified by the Elements count field. Each TLV has holding as many TLVs specified by the Traffic Class Elements Count
the following format: field. Each TLV has the following format:
IPFIX Element Identifier: (8 bit type field) IPFIX Identifiers IPFIX Element Identifier - 8-bits field that specifies IPFIX
listed in Table 1. Identifiers listed in Table 1.
Size of Value field: (8 bit field) - Indicates the length of Length of Value field - 8-bits field that specifies the length,
the value field. expressed in octets, of the value field.
Value: A variable field containing a value appropriate for the Value - A variable field that specifies a value appropriate for
IPFIX element. It is an error if the IPFix field does not the IPFIX Element Identifier. It is an error, if the value
contain the appropriate format (see BGP error handling in field does not contain the appropriate format, which should be
section 6). Only the IPFIX elements shown in Table 1 are handled as described in Section 6. Only the IPFIX elements
supported. shown in Table 1 are supported.
Any Traffic Class element advertised in the QoS attribute only Any Traffic Class Element advertised in the QoS Attribute only
applies to the NLRI advertised (AFI/SAFIs) within the BGP UPDATE applies to the advertised AFI/SAFI NLRI within the BGP UPDATE
message the QoS attribute is contained in. If a receiver receives message the QoS Attribute is contained in. If a receiver, SLA
a BGP UPDATE message with QoS/SLA attribute for an NLRI that it Consumer, receives a BGP UPDATE message with QoS Attribute for an
does not support then the receiver MUST NOT install that unsupported AFI/SAFI then SLA Consumer MAY ignore advertised SLA.
advertised SLA and continue to forward this attribute as an SLA Consumer MAY update only Destination AS count and Destination
optional transitive attribute. AS list, and then QoS Attribute and rest of the BGP UPDATE message
MUST be forwarded as per QoS Attribute and BGP protocol
specification.
Service Count: 8 bit count of Traffic Class Service TLVs following Traffic Class Service Count - 8-bits field that specifies count of
this count. A value of zero is a special value indicating "no Traffic Class Service TLVs.
bounded service" (a.k.a., Best Effort (BE)).
Traffic Class Service TLVs: (optional) variable length field with 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 the following format for the TLVs
Traffic Class Service type: 16-bit field which specifies a Traffic Class Service type - 16-bits field that specifies a
service type. Each service type is detailed in Section 3.3.2. service type. Each service type is detailed in Section 3.3.2.
The list of available service types are, The list of available service types are,
0x00 = reserved 0x00 = reserved
0x01 = TRAFFIC_CLASS_TSPEC 0x01 = TRAFFIC_CLASS_TSPEC
0x02 = L2_OVERHEAD 0x02 = L2_OVERHEAD
0x03 = MINRATE_IN_PROFILE_MARKING 0x03 = MINRATE_IN_PROFILE_MARKING
skipping to change at page 11, line 44 skipping to change at page 13, line 5
0x05 = MAXRATE_IN_PROFILE_MARKING 0x05 = MAXRATE_IN_PROFILE_MARKING
0x06 = MAXRATE_OUT_PROFILE_MARKING 0x06 = MAXRATE_OUT_PROFILE_MARKING
0x07 = DROP_THRESHOLD 0x07 = DROP_THRESHOLD
0x08 = RELATIVE_PRIORITY 0x08 = RELATIVE_PRIORITY
0x09 = SUB_TRAFFIC_CLASSES 0x09 = SUB_TRAFFIC_CLASSES
Length of value field: 08-bit field that specifies the size of Length of Value field - 08-bits field that specifies the length
a value field to follow. of the value field. The length of the value is expressed in
octets.
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 Value - a variable length field that specifies the value
Service Types. It is an error if this field does not contain appropriate for each of the Service Types. It is an error, if
the appropriate format (see BGP error handling section for this field does not contain the appropriate format, which
details). should be handled as described in Section 6. The format of the
value for each of the service types is described in
Section 3.3.2
3.3.1. Supported IPFIX values for Classifier Elements 3.3.1. Supported IPFIX identifiers for Traffic Class Elements
IPFIX [RFC7012] has well defined identifier set for a large number of IPFIX [RFC7012] has well defined identifier set for a large number of
packet attributes; an IPFIX IANA registry maintains values for packet packet attributes; an IPFIX IANA registry maintains values for packet
classifier attributes (https://www.ietf.org/assignments/ipfix"). classifier attributes (https://www.ietf.org/assignments/ipfix/
Only the IPFIX attributes listed in Table 1 are supported by BGP SLA ipfix.xml#ipfix-information-elements). Only the IPFIX attributes
exchange. Any new attribute to be supported by SLA QOS MUST be added listed in Table 1 are supported. Any new attribute to be supported
by a Standards Action. by SLA SubType MUST be a Standards Action as described in IANA
section.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
| 8 | sourceIPv4Address | | 8 | sourceIPv4Address |
| 27 | sourceIPv6Address | | 27 | sourceIPv6Address |
| 9 | sourceIPv4PrefixLength | | 9 | sourceIPv4PrefixLength |
skipping to change at page 13, line 30 skipping to change at page 14, line 5
| 30 | destinationIPv6PrefixLength| | 30 | destinationIPv6PrefixLength|
| 45 | destinationIPv4Prefix | | 45 | destinationIPv4Prefix |
|169 | destinationIPv6Prefix | |169 | destinationIPv6Prefix |
| 4 | protocolIdentifier | | 4 | protocolIdentifier |
| 7 | sourceTransportPort | | 7 | sourceTransportPort |
| 11 | destinationTransportPort | | 11 | destinationTransportPort |
+----+----------------------------+ +----+----------------------------+
Table 1 Table 1
3.3.2. Traffic Class Service TLVs 3.3.2. Traffic Class Service types and respective TLVs
3.3.2.1. Traffic Class TSPEC TLV 3.3.2.1. TRAFFIC_CLASS_TSPEC
The TRAFFIC_CLASS_TSPEC TLV consists of: The TRAFFIC_CLASS_TSPEC TLV definition:
type = 0x01 Type - 0x01
length = 96 bits (12 octets) TSpec field Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be
specified to be 12 octets to hold the value defined as per format
below.
value = 96 bits, TRAFFIC_CLASS_TSPEC value consists of the (r), Value - TRAFFIC_CLASS_TSPEC value consists of the (r), (b), (p)
(b), (p) parameters as described in Invocation Information section parameters as described in Invocation Information section of
of [RFC2212] and shown in Figure 5. Note that inheriting the [RFC2212] and shown in Figure 5. Note that inheriting the
definition of TSpec here does not enable RFC2212 functionality. definition of TSPEC (Traffic SPECification) here does not enable
Only the values of the Traffic Specification are used in this RFC2212 functionality. Only the format of the Traffic
specification. Specification is used in this 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Traffic Class TSPEC Figure 5 - Traffic Class TSPEC
Format of Parameters (r), (b) and (p): are 32-bit IEEE floating Format of Parameters (r), (b) and (p): are 32-bit IEEE floating
point numbers. Positive infinity is represented as an IEEE single point numbers. Positive infinity is represented as an IEEE single
precision floating-point number with an exponent of all ones and a precision floating-point number with an exponent of all ones and a
sign mantissa of all zeros. The format of IEEE floating-point sign mantissa of all zeros. The format of IEEE floating-point
numbers is further summarized in [RFC4506]. numbers is further summarized in [RFC4506].
Parameter (r): indicates min-rate of the traffic class. This rate 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 for datagrams per second (a.k.a, bytes per second), that the service
a given class of traffic on advertiser's hop. Note that it does advertiser is providing for a given class of traffic on
not necessarily translate to a minimum rate service to the advertiser's hop. Note that it does not necessarily translate to
receiver of an SLA unless the traffic class definition clearly a minimum rate service to the receiver of an SLA unless the
represents a sole receiver of an SLA. If there is no SLA for min- traffic class definition clearly represents a sole receiver of an
rate, the value of (r) MUST be set to 0. 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 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 the zero parameter (r), parameter (b) represents bounded delay for the
Traffic Class. This delay is a single hop queuing delay when SLA Traffic Class. This delay is a single hop queuing delay when SLA
is to be implemented at the resource constrained bottleneck. In is to be implemented at the resource constrained bottleneck. In
other words this burst size can be considered as a buffer size. other words this burst size can be considered as a buffer size.
Value of 0 for parameter (b) means the advertiser does not mandate Value of 0 for parameter (b) means the advertiser does not 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 datagrams per second
field here also indicates service provided by advertiser. If (a.k.a., bytes per second), field here also indicates service
advertiser does not have any specific value to set for a given provided by advertiser. If advertiser does not have any specific
class of traffic, it MAY be set to physical interface line rate or value to set for a given class of traffic, it MAY be set to
any other indirect limit that may affect this class' maximum rate. physical interface line rate or any other indirect limit that may
In absence of any such known value, it MUST be set to positive affect this class' maximum rate. In absence of any such known
infinity. Value 0 is considered an error. value, it MUST be set to positive infinity. Value 0 is considered
an error which should be handled as described in Section 6.
3.3.2.2. Traffic Class L2 Overhead 3.3.2.2. L2_OVERHEAD
The L2_OVERHEAD traffic class consists of: The L2_OVERHEAD TLV definition:
Type = 0x02 (L2_OVERHEAD) Type - 0x02
Length = 1 octet Length - 8-bits field that specifies length, expressed in octets,
of the value field.
value = 8 bits, count of L2 overhead from sender in bytes Value - Layer 2 overhead in octets
By default the packet rate and other packet size related parameters L2_OVERHEAD defines Layer 2 (L2) specific data in octets, on top of
advertised in an SLA include the L2 packet overhead. For the IP datagram size, in a layer 2 frame. By default the rate and burst
receiver (of the SLA at next hop),this overhead is the L2 overhead of advertised in the TRAFFIC_CLASS_TSPEC TLV are applicable to the
the local link where advertised SLA is received. packet size including L2 packet overhead. For the SLA Consumer
directly connected to the SLA Producer, 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 However, in cases where advertised SLA is for a SLA Consumer multiple
hops away, L2 overhead from the source perspective may be different hops away, L2 overhead from the source, SLA Producer, perspective may
from the local L2 overhead at the receiver. In such cases, the be different from the local link L2 overhead at the receiver, SLA
explicit notification of size of L2 overhead from a sender is Consumer. In such cases, explicit notification of size of L2
necessary for the a receiver to be able to know the L2 overhead overhead from the SLA Producer suggests what per packet L2 overhead
required by the sender. When the receiver chooses to react to an is applicable to the rate and burst advertised in the
advertised SLA and if the L2 Overhead service type is present in TRAFFIC_CLASS_TSPEC TLV. L2_OVERHEAD TLV SHOULD BE ignored by the
advertised SLA, the receiver MUST use the explicit advertised L2 SLA Consumer if there does not exist TRAFFIC_CLASS_TSPEC TLV for the
overhead rather than the local L2 overhead. specified direction.
If SLA is required to consider only IP packet size, the sender MAY Advertised L2 value of 0 means SLA advertised is for IP packet size.
advertise this service with a value of 0.
3.3.2.3. Traffic Class for MINRATE_IN_PROFILE_MARKING 3.3.2.3. MINRATE_IN_PROFILE_MARKING
The MINRATE_IN_PROFILE_MARKING traffic class consists of: This Traffic Class Service Type defines action performed, by the SLA
Producer, on packets that are compliant to the min-rate specified in
the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the
TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service
Type SHOULD NOT be advertised. MINRATE_IN_PROFILE_MARKING TLV SHOULD
BE ignored by the SLA Consumer if there does not exist
TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate
specified in the TRAFFIC_CLASS_TSPEC TLV is 0.
Type = 0x03 = MINRATE_IN_PROFILE_MARKING The MINRATE_IN_PROFILE_MARKING TLV definition:
Length = 2 octets Type - 0x03
Value: Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be
specified to be 2 octets to hold the value defined as per format
below.
Marking code-point type = 8 bits (1 octet) IPFIX Element Value - contains the Marking code-point type and value
Identifier.
Marking code-point value = 8 bits (1 octet) code-point number. Marking code-point type - 8-bits IPFIX Element Identifier.
The marking code-point type of 0x00 is a drop identifier; the length Marking code-point value - 8-bits code-point number.
in this case is zero.
The following table lists the supported IPFIX Identifiers: The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking
code-point value in this case has no meaning and thus the value in
this field should be ignored.
The following table lists the supported IPFIX Identifiers. Any value
other than 0 or identifier from the following table is an error
condition which should be handled as described in Section 6.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
Table 2 Table 2
3.3.2.4. Traffic Class for MINRATE_OUT_PROFILE_MARKING
The MINRATE_OUT_PROFILE_MARKING traffic class consists of:
Type = 0x04 = MINRATE_OUT_PROFILE_MARKING
Length = 2 octets 3.3.2.4. MINRATE_OUT_PROFILE_MARKING
Value: This Traffic Class Service Type defines action performed, at the SLA
Producer, on packets that are not compliant to the min-rate specified
in the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the
TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service
Type SHOULD NOT be advertised. MINRATE_OUT_PROFILE_MARKING TLV
SHOULD BE ignored by the SLA Consumer if there does not exist
TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate
specified in the TRAFFIC_CLASS_TSPEC TLV is 0.
Marking code-point type = 8 bits (1 octet) IPFIX Element The MINRATE_OUT_PROFILE_MARKING TLV definition:
Identifier.
Marking code-point value = 8 bits (1 octet) code-point number. Type - 0x04
The marking code-point type of 0x00 is a drop identifier; the length Length - 8-bits field that specifies length, expressed in octets,
in this case is zero. of the value field. The length of the value field MUST be
specified to be 2 octets to hold the value defined as per format
below.
The following table lists the supported IPFIX Identifiers: Value - contains the Marking code-point type and value
+----+----------------------------+ Marking code-point type - 8-bits IPFIX Element Identifier
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 3 Marking code-point value - 8-bits code-point number
3.3.2.5. Traffic Class for MAXRATE_IN_PROFILE_MARKING The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking
code-point value in this case has no meaning and thus the value in
this field should be ignored.
The MAXRATE_IN_PROFILE_MARKING traffic class consists of: Table 2 lists the supported IPFIX Identifiers. Any value other than
0 or identifier from the Table 2 is an error condition which should
be handled as described in Section 6.
Type = 0x05 = MAXRATE_IN_PROFILE_MARKING 3.3.2.5. MAXRATE_IN_PROFILE_MARKING
Length = 2 octets This Traffic Class Service Type defines action performed, at the SLA
Value: Producer, on packets that are compliant to the max-rate specified in
the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_IN_PROFILE_MARKING TLV SHOULD
BE ignored by the SLA Consumer if there does not exist
TRAFFIC_CLASS_TSPEC TLV for the specified direction.
Marking code-point type = 8 bits (1 octet) IPFIX Element The MAXRATE_IN_PROFILE_MARKING TLV definition:
Identifier.
Marking code-point value = 8 bits (1 octet) code-point number. Type - 0x05
Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be
specified to be 2 octets to hold the value defined as per format
below.
The marking code-point type of 0x00 is a drop identifier; the length Value - contains the Marking code-point type and value
in this case is zero.
The following table lists the supported IPFIX Identifiers: Marking code-point type - 8-bits IPFIX Element Identifier
+----+----------------------------+ Marking code-point value - 8-bits code-point number
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 4 The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking
code-point value in this case has no meaning and thus the value in
this field should be ignored.
3.3.2.6. Traffic Class for MAXRATE_OUT_PROFILE_MARKING Table 2 lists the supported IPFIX Identifiers. Any value other than
0 or identifier from the Table 2 is an error condition which should
be handled as described in Section 6.
The MAXRATE_OUT_PROFILE_MARKING traffic class consists of: 3.3.2.6. MAXRATE_OUT_PROFILE_MARKING
Type = 0x06 = MAXRATE_OUT_PROFILE_MARKING This Traffic Class Service Type defines action performed, at the SLA
Producer, on packets that are not compliant to the max-rate specified
in the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_OUT_PROFILE_MARKING TLV
SHOULD BE ignored by the SLA Consumer if there does not exist
TRAFFIC_CLASS_TSPEC TLV for the specified direction.
Length = 2 octets The MAXRATE_OUT_PROFILE_MARKING TLV definition:
Value: Type - 0x06
Marking code-point type = 8 bits (1 octet) IPFIX Element Length - 8-bits field that specifies length, expressed in octets,
Identifier. of the value field. The length of the value field MUST be
specified to be 2 octets to hold the value defined as per format
below.
Marking code-point value = 8 bits (1 octet) code-point number. Value - contains the Marking code-point type and value
The marking code-point type of 0x00 is a drop identifier; the length Marking code-point type - 8-bits IPFIX Element Identifier
in this case is zero.
The following table lists the supported IPFIX Identifiers: Marking code-point value - 8-bits code-point number
+----+----------------------------+ The marking code-point type of 0x00 is a drop identifier. When
| ID | Name | marking code-point type value is 0x00 (that is drop), the marking
+----+----------------------------+ code-point value in this case has no meaning and thus the value in
|195 | ipDiffServCodePoint | this field should be ignored.
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
Table 5 Table 2 lists the supported IPFIX Identifiers. Any value other than
0 or identifier from the Table 2 is an error condition which should
be handled as described in Section 6.
3.3.2.7. Precedence between MINRATE and MAXRATE 3.3.2.7. Precedence between MINRATE and MAXRATE
The precedence between MINRATE_IN_PROFILE_MARKING, The precedence between MINRATE_IN_PROFILE_MARKING,
MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and
MAXRATE_OUT_PROFILE_MARKING when all four are advertised is: MAXRATE_OUT_PROFILE_MARKING when all four are advertised is:
o MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is
MAXRATE_IN_PROFILE_MARKING), over MAXRATE_IN_PROFILE_MARKING),
o MAXRATE_IN_PROFILE_MARKING takes precedence over - MAXRATE_IN_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING, and MINRATE_OUT_PROFILE_MARKING, and
o MAXRATE_OUT_PROFILE_MARKING takes precedence over - MAXRATE_OUT_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING MINRATE_OUT_PROFILE_MARKING
3.3.2.8. Traffic Class for DROP_THRESHOLD 3.3.2.8. 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 The DROP_THRESHOLD TLV definition:
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 Type - 0x07
for each set.
Number of set of thresholds = 1 octet Length - 8-bits field that specifies length, expressed in octets,
of the value field.
sub-TLV for each set: Each sub-TLV specifies a code-point type/ Value - Count of drop thresholds, followed by content for each
values that the burst size is applicable to. The sub-TLV is in drop threshold in the form of (code-point type, count of code-
the form of a (code-point type, value length, value) where points, list of code-points, threshold value).
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 Count of drop thresholds - 8-bits field that specifies number
Identifier from the list shown in Table 6. of drop thresholds specified in this TLV. Content of each drop
threshold is to follow following format
sub-TLV Length = 1 octet that specifies total length for set Code-point type - 8-bits IPFIX Element Identifier from the list
of code-points and burst size. shown in Table 6.
sub-TLV Value: variable length field with Count of code-points - 8-bits field that specifies number of
code-point values to follow for a specified code-point type.
sequence of code points - one code-point value specified List of code-points - each code-point value is specified in
in 1 octet. size of 8 bits and thus total size for this field is 8 bits
multiplied by as many number of code-points specified.
4 octets burst size - 32 bit (4 octets) IEEE Floating Burst value - This is a fixed size 32-bits IEEE floating point
point number. number that specifies burst value in unit of bytes.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
Table 6 Table 3
3.3.2.9. Traffic Class for Relative Priority
The RELATIVE_PRIORITY traffic class consists of: 3.3.2.9. RELATIVE_PRIORITY
Type = 0x08 - RELATIVE_PRIORITY The RELATIVE_PRIORITY TLV definition:
Length = 4 bits Type - 0x08
Value: Length - 8-bits field that specifies length, expressed in octets,
of the value field. Given supported range of priority values in
this specification, the length of the value field MUST be limited
to and thus MUST be specified exactly as 1 octet.
A value from range of 0 - 15. Lower the value means higher the Value - A value from range of 0 - 255. Lower the value means
priority. higher the priority
Relative priority indicates scheduling priority of this traffic Relative priority indicates scheduling priority of this traffic
class. Voice traffic, for example, which requires lowest latency class. Voice traffic, for example, which requires lowest latency
compared to any other traffic, may have lowest value advertised in compared to any other traffic, may have lowest value advertised in
relative priority. For two different traffic classification groups relative priority. For two different traffic classification groups
where one application group may be considered more important than the where one application group may be considered more important than the
other but from a scheduling perspective does not require to be other but from a scheduling perspective does not require to be
distinguished with a different priority, relative priority for those distinguished with a different priority, relative priority for those
classification groups may be advertised with the same value. classification groups may be advertised with the same value.
3.3.2.10. Traffic Class for Sub-Traffic Classes 3.3.2.10. SUB_TRAFFIC_CLASSES
The SUB_TRAFFIC_CLASSES traffic class consists of: The SUB_TRAFFIC_CLASSES TLV definition:
Type = 0x09 - SUB_TRAFFIC_CLASSSES Type - 0x09
length = the combined length of a set of traffic Class TLVs Length - 16-bits field that specifies total length, expressed in
included in a Sub-Traffic Classes grouping octets, of a subset of Traffic Class TLVs encoded in the value
field
value = sequence of traffic class TLVs Value - A subset of Traffic Class TLVs
For SLAs where a specific Traffic Class may further have different For SLAs where a specific Traffic Class may further be defined by a
sub-services for a sub-group of Classifier Elements, this service subset of more granular Traffic Classes, each with its own set of
type SHOULD be used to further divide Traffic Class in multiple sub- Traffic Class Elements and Service types definitions,
classes. Each sub-class is then defined with their own classifier SUB_TRAFFIC_CLASSES service type SHOULD be used to specify them.
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 for the SLA SubType MUST only be added to the BGP
be added during BGP propagation. UPDATE message at the node that is SLA Producer. Any QoS Attribute
Speaker, in the path to the SLA Consumer MUST NOT modify content of
that attribute except modification of the Destination AS list.
BGP UPDATE message with the QoS Attribute carrying SLA parameters QoS Attribute with the SLA SubType SHOULD NOT be advertised
SHOULD NOT be sent periodically just for the purpose of KEEPALIVE periodically just for the purpose of KEEPALIVE between SLA Producer
between two points. Some sort of SLA policy change may be considered and SLA Consumer. Some sort of SLA policy change, at the SLA
as a trigger for the advertisement. Producer, may be considered as a trigger for the advertisement.
For any modified SLA parameters, the originator MUST re-advertise the For any modified SLA policy at the SLA Producer, SLA Producer MUST
entire set of SLA parameters. There is no provision to advertise re-advertise the entire set of SLA parameters. There is no provision
partial set of parameters. To invalidate previously advertised SLA to advertise partial set of SLA parameters. If modified SLA policy
parameters, a message MUST be sent with the same SLA id for the same is to mean no SLA between SLA Producer and SLA Consumer, then SLA
source with the Traffic Class count set to 0. Content MUST be sent with the same SLA ID with the same AS Source and
NLRI prefix, as were used to advertise earlier SLA parameters, and
the Traffic Class count set to 0.
4.1. SLA Contexts 4.1. SLA Contexts
In certain cases, the advertisement of a QoS Attribute in a BGP 4.1.1. SLA Advertisement for Point-to-Point Connection
UPDATE message 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). In such cases, a BGP update message with source AS number
and NLRI prefix of source end-point can uniquely identify physical/
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 certain cases, the advertisement of an SLA is intended to relate
to aggregate traffic over a point-to-point connection between a
specific destination and a specific source. A point-to-point
connection may be a physical link or a virtual link (e.g. a tunnel).
In such cases, a BGP UPDATE message with source AS number and NLRI
prefix as an IP address of an SLA Producer can uniquely identify
physical/virtual link in order to establish the context for the
advertised SLA 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 CE) devices are directly connected via a physical link and have only
a single link between them, the CE can uniquely identify the a single link between them, the CE can uniquely identify the
forwarding link to PE with the following: forwarding link to the PE with the following:
o AS number of the PE, o AS number of the PE,
o NLRI prefix being an IP address of PE, o NLRI prefix being an IP address of the PE, that is the next hop
address from CE to PE.
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 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 sent from the PE to a CE, along with the PE's AS number and PE's IP
address, establishes SLA context for the aggregate traffic through address, establishes SLA context for the aggregate traffic through
CE-to-PE link. CE-to-PE link.
The SLA advertised in the QoS attribute in the BGP UPDATE message 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 from PE to CE, with PE's AS number and any other prefix, means SLA
SLA for that specific prefix's traffic as a subset of traffic under for that specific prefix based traffic, a subset of traffic through
CE-to-PE link. CE-to-PE link.
Even though this example is in the context of IP prefixes, QoS 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 Attribute's SLA exchange does not have to be limited to the IP
address family (IPv4 and IPv6). SLA advertisement is generic to all address family (IPv4 and IPv6). SLA advertisement is generic to all
forms of NLRI types that are supported by the BGP specification (like forms of NLRI types that are supported by the BGP specification (like
IPv4, IPv6, VPN-IPv4, VPN-IPv6). IPv4, IPv6, VPN-IPv4, VPN-IPv6).
4.1.1. SLA Advertisement for Point-to-Point Connection When BGP UPDATE message with the QoS Attribute, containing SLA
SubType, is triggered for a point-to-point connection (physical or
When BGP UPDATE message with the QoS Attribute with SLA is used to logical), the Source AS number in the SLA SubType SHOULD BE set to
advertise the QoS SLA for a point-to-point connection (physical or SLA Producer's AS number and destination AS number SHOULD BE set to
logical), the next hop in the BGP message is used with the prefix of AS number of BGP peer's that is targeted SLA Consumer.
the source end-point of the point to point connection. Alternatively, highest order bit in the SLA SubType flags MAY BE set
to ignore Source AS and destination AS values from the SLA SubType
The destination AS number in the QoS SLA attribute is typically set content since SLA advertised is meant specifically for the BGP peer.
to the AS of the BGP peer's IP-Address.
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 a BGP UPDATE message with a QoS SLA attribute is to be sent by a When advertised SLA is not for the BGP peer of an SLA Producer, the
BGP peer beyond next hop peer, the value of source AS in the QoS Source AS field, in the SLA SubType, MUST be set. The list of
attribute MUST be set by the originator of the UPDATE message. If destination AS(es) also MUST be set, in the SLA SubType, to avoid
such an update is meant to be for a specific list of AS(es) as flooding of the QoS Attribute data in the network beyond those
receivers, then the list of destination AS(es) MUST be explicitly destinations. Destination AS(es) is a list of SLA Consumers the
described in the QoS attribute message to avoid flooding of the QoS advertised SLA is intended for.
attribute data in the network beyond those destinations.
If a new prefix is added in an AS for which SLA parameters have If a new prefix is learned and traffic with this new prefix is
already been advertised before for other existing prefixes, and if subject to SLA parameters that have already been advertised before
traffic to this new prefix is subject to the same SLA advertised for other existing prefixes, then the BGP UPDATE for this new prefix
earlier, then the BGP UPDATE for this new prefix may include QoS MAY include QoS Attribute containing just an SLA ID that was
attribute containing just an SLA id for an SLA id that was advertised advertised earlier. This BGP UPDATE message does not require to have
earlier. This BGP UPDATE message does not require to have the whole the whole SLA Content. The SLA ID is sufficient to relate SLA
SLA content. The SLA id is sufficient to relate SLA parameters to parameters to new advertised prefixes.
new advertised prefixes.
5. SLA Attribute Handling at Forwarding Nodes 5. QoS Attribute Handling at Forwarding Nodes
The propagation of the QoS Attribute in the BGP UPDATE depends on the The propagation of the QoS Attribute in the BGP UPDATE messages
rules detailed in the following sub-sections for forwarding the QoS depends on the rules detailed in the following sub-sections.
Attribute.
5.1. BGP Node Capable of Processing QoS Attribute 5.1. BGP Node Capable of Processing QoS Attribute
If a BGP peer is capable of processing a QoS attribute in a BGP If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS
UPDATE message, it MAY process the QoS attribute. If UPDATE has a Attribute. If BGP UPDATE message has a QoS Attribute with a list of
QoS Attribute with a list of destination ASes, it MAY trim the list destination ASes, QoS Attribute Speaker MAY trim the list and adjust
and adjust the count of the destination AS to exclude ones that are the count of the destination AS to exclude ones that are not required
not required in further announcement of BGP UPDATE messages. in further announcement of BGP UPDATE messages.
BGP peer MUST drop SLA related sub-type from the QoS attribute, if
there are no more ASes from the QoS Attribute's 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 specification.
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 A QoS Attribute Speaker MUST drop SLA SubType from the QoS Attribute,
if there are no more ASes left in the QoS Attribute's destination
list. The rest of the QoS Attribute contents may be forwarded if
there exist other SubTypes of QoS Attribute and forwarding rules meet
other SubTypes requirements. If there is no other SubTypes in that
QoS Attribute content then QoS Attribute Speaker MUST drop the entire
QoS Attribute all together. BGP Speaker MAY announce further other
attributes and NLRI information, if they meet rules defined by other
attributes and BGP specification.
Reception of and processing of advertised QoS SLA content are Except extracting the entire SLA SubType of the QoS Attribute and
optional for the receiver. While reacting to SLA advertisement in a trimming the list of Destination AS list, all other content MUST NOT
QoS attribute, be modified by any QoS Attribute Speaker or BGP Speaker in the path
of a BGP UPDATE message.
o the receiving BGP peer SHOULD invalidate previous advertised SLA 5.2. QoS Attribute Handling at Receiver
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 further action is required.
o When BGP UPDATE messages are triggered only as a result of SLA Once QoS Attribute with the SLA SubType is received at intended
policy change, BGP UPDATE message forwarding beyond intended BGP receiver (SLA Consumer) , processing of advertised SLA Content is
peer receivers is not necessary. If the receiver device optional for the SLA Consumer. SLA Consumer MAY just trim the
implementation supports policy based filtering, then the receiver Destination AS list as per rules described in this specification,
MAY implement a policy to filter such messages based on the prefix without processing any other content of the Attribute. If intended
and attribute. receiver is not a QoS Attribute Speaker than BGP Speaker MUST forward
this attribute without any change if rest of the BGP UPDATE message
also meets forwarding rules as per BGP specification.
If QoS attribute with the SLA is advertised to the next hop BGP peer When BGP UPDATE messages are triggered only as a result of SLA policy
who is a neighbor, the receiver MAY implement advertised SLA for the change, propagating BGP UPDATE message beyond intended SLA Consumers
whole link; the link could be a physical or virtual connected to the is not necessary. If the SLA Consumer device implementations are
neighbor. If the QoS Attribute with the SLA is advertised to a BGP capable of policy based filtering, it may implement a policy to
peer which is not the next hop neighbor, then receiver may establish filter such BGP UPDATE messages based on prefixes and QoS Attribute
advertised SLA for that specific prefix list under the relevant link. containing SLA SubType.
It is completely up to the receiver to decide for which prefixes it
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, MUST be Error conditions, while processing of the QoS Attribute content, MUST
handled with the approach of attribute-discard as described in be handled with the approach of attribute discard as described in
[RFC7606]. In such condition, the receiver SHOULD also cleanup any [RFC7606]. Processing of QoS Attribute content is done by QoS
previously installed SLA state for the same prefix. Attribute Speaker and thus in case of errors, resulting in attribute
discard, QoS Attribute Speaker SHOULD convey such indication to the
7. Traffic Class Mapping BGP Speaker and rest of the BGP message SHOULD BE processed by the
BGP Speaker as per BGP specification.
It is possible that forwarding methods used in two different ASes
could be different. For example, provider may tunnel a customer's IP
traffic thru an MPLS infrastructure. In such cases, the traffic
class definition for QoS services may differ between the ASes. For
the meaningful use of advertised SLA in such cases, the receiver is
required to map the remote traffic class to the local traffic class.
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 (e.g. [RFC3270] maps 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 7. 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 a 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 QoS Attribute to the CE
CE device. The CE device may read the attribute and SLA sub-type device. The CE device may read the QoS Attribute and SLA SubType
content 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. The advertised SLA can be or finer granular controlled services. The advertised SLA can be
useful when contracted service is sub-rate of a link and/or when for 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 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).
_______________ _______________
__________ / \ __________ / \
skipping to change at page 24, line 36 skipping to change at page 24, line 36
/ \ / \ / \ / \
|CustomerSite|-----| Provider | |CustomerSite|-----| Provider |
\ C/E P\E / \ C/E P\E /
\__________/ \ / \__________/ \ /
\_______________/ \_______________/
AS 3 AS 2 AS 3 AS 2
SLA_ADVERTISE: AS2 to AS3 SLA_ADVERTISE: AS2 to AS3
NLRI = PE ip address NLRI = PE ip address
Figure 6 - Example 1 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 Figure 7, each spoke (AS1 parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1
and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in
Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel
ip address. ip address.
AS 2 AS 2
skipping to change at page 25, line 22 skipping to change at page 25, line 22
\ /-----| Spoke1 | \ /-----| Spoke1 |
AS 3 \_______________/ \________/ AS 3 \_______________/ \________/
AS 1 AS 1
SLA_ADVERTISE: AS2 to AS3 SLA_ADVERTISE: AS2 to AS3
NLRI = AS2 tunnel address NLRI = AS2 tunnel address
SLA_ADVERTISE: AS1 to AS3 SLA_ADVERTISE: AS1 to AS3
NLRI = AS1 tunnel address NLRI = AS1 tunnel address
Figure 7 - Example 2 Figure 7 - Example 2
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 8. Acknowledgements
Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and
their suggestions and to Christian Jacquenet, Ken Briley, Rahul Alvaro Retana for their suggestions and to Christian Jacquenet, Ken
Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier, Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand
Bruno Decraene for the review. Duvivier, Bruno Decraene for the review.
10. IANA Considerations 9. 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, divided into two pools.One pool
action/early allocation basis. The initial assignments are: of numbers to be assigned on a standards action/early allocation
basis. The initial assignments are as shown below. The other pool
is for the private use,available range for which is as shown below.
QoS Attribute subTypes QoS Attribute SubTypes
============= ======== ======================
Reserved 0x00 Reserved 0x00
SLA 0x01 SLA 0x01
Reserved 0x02-0xff (Standards Action) Reserved 0x02-0xf0 (Standards Action)
Private use 0xf1-0xff
IANA is requested to create a registry for SLA Event Types. This is IANA is requested to create a registry for QoS Attribute SLA SubType
a registry of 4-bits value, to be assigned on a standards action or flags. This is registry for 8-bits. The initial assignments are as
early allocation basis. The initial assignments are: shown below.
QoS Attribute SLA SubType Flags
===============================
Highest order bit (bit 0) - to indicate source and destination AS context
Reserved - bits 1 to 15 (Standards Action)
IANA is requested to create a registry for QoS Attribute SLA Event
Types. This is a registry of 4-bits value, divided into two pools.
One pool of numbers to be assigned on a standards action/early
allocation basis. One pool of numbers to be assigned on a standards
action/early allocation basis. The initial assignments are as shown
below. The other pool is for the private use, available range for
which is as shown below.
QoS Attribute SLA Event Types QoS Attribute SLA Event Types
============= =============== =============================
Reserved 0x0 Reserved 0x0
ADVERTISE 0x1 ADVERTISE 0x1
Reserved 0x2 - 0xf (Standards Action) Reserved 0x2 - 0xc (Standards Action)
Private use 0xd - 0xf
IANA is requested to create a registry to define QoS SLA Direction. IANA is requested to create a registry to define QoS Attribute SLA
This is the direction in forwarding path, advertised QoS SLA is Direction. This is the direction in forwarding path, advertised QoS
applicable to. This is a 2-bit registry. Values for QoS SLA SLA is applicable to. This is a 2-bit registry. Values for QoS
direction are: Attribute SLA direction are:
QoS SLA Direction Value QoS Attribute SLA Direction
================= ===== ===========================
Reserved 0x0 Reserved 0x0
To source AS from destination AS 0x1 To source AS from destination AS 0x1
From source AS to destination AS 0x2 From source AS to destination AS 0x2
Reserved (Standards Action) 0x3 Reserved (Standards Action) 0x3
QoS SLA Traffic Class Element Types will be referring to existing QoS Attribute SLA Traffic Class Element Types will be referring to
IPFIX IANA types as listed in Table 1. existing IPFIX IANA types as listed in Table 1. While IPFIX registry
is maintained by IANA out of scope of this specification, the use of
IPFIX identifiers for this specification are limited to what is
described in Table 1. Any new addition of IPFIX identifiers to this
table should be a Standards Action.
IANA is requested to create a registry for QoS SLA Traffic Class IANA is requested to create a registry for QoS Attribute SLA Traffic
Service Types. This is a registry of 2 octet values, to be assigned Class Service Types. This is a registry of 2 octet values, to be
on a standards action/early allocation basis. The initial assigned on a standards action/early allocation basis. The initial
assignments are: assignments are:
Traffic Class Service Type Value 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
Standards Action 0x0A - 0x3FFF Standards Action 0x0A - 0x3FFF
FCFS 0x4000 - 0x4FF0 FCFS 0x4000 - 0x4FF0
11. Security Considerations 10. Security Considerations
The QOS attribute defined in this document SHOULD be used by the BGP security vulnerabilities analysis is documented in [RFC4272]
managed networks for enforcing Quality of Service policies and so while BGP-related security considerations are discussed in [RFC4271].
there should not be any risks for identity thefts. To strengthen the Also, the reader may refer to [RFC7132] for more details about BGP
security for the QoS attribute, RPKI based origin validation path threat model. Rest of the content in this section discusses
[RFC7115] MAY be used. In addition to the RPKI based origin additional privacy and security considerations that are applicable to
validation, BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec- the attribute defined in this document.
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 attacks.
12. References The information conveyed in the QoS Attribute SLA SubType reveals
sensitive data that should not be exposed publicly to non-authorized
parties. Deployment considerations mainly target use of QoS
Attribute and SLA SubType in managed networks and those where a trust
relationship is in place (Customer to Provider, or Provider to
Provider). It is NOT RECOMMENDED to enable this attribute at the
scale of the Internet unless if means to prevent leaking sensitive
information are enforced.
12.1. Normative References The attribute may be advertised by a misbehaving node to communicate
SLA parameters that are not aligned with the SLA agreements. Though
the enforcement of SLA parameters is outside the scope of this
document, it is RECOMMENDED that the SLA Consumer to enforce a set of
validation checks before translating the SLA parameters conveyed in
the QoS attributes into provisioning actions. Such validations MAY
rely on SLA parameters lime the origin AS or SLA ID, like generating
SLA ID using pseudo-random schemes [RFC4086].
Means to prevent route hijacking SHOULD BE considered. Such means
include RPKI based origin validation [RFC7115] and BGP Path
validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]).
11. References
11.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>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, of Guaranteed Quality of Service", RFC 2212,
DOI 10.17487/RFC2212, September 1997, DOI 10.17487/RFC2212, September 1997,
<http://www.rfc-editor.org/info/rfc2212>. <http://www.rfc-editor.org/info/rfc2212>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- IANA Considerations Section in RFCs", RFC 2434,
Protocol Label Switching (MPLS) Support of Differentiated DOI 10.17487/RFC2434, October 1998,
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <http://www.rfc-editor.org/info/rfc2434>.
<http://www.rfc-editor.org/info/rfc3270>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[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>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.
[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>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012, for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013, DOI 10.17487/RFC7012, September 2013,
<http://www.rfc-editor.org/info/rfc7012>. <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>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://www.rfc-editor.org/info/rfc7132>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
12.2. Informative References 11.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in Protocol", draft-ietf-netconf-restconf-15 (work in
progress), December 2015. progress), July 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPsec Protocol Specification", draft-ietf- Lepinski, M. and K. Sriram, "BGPsec Protocol
sidr-bgpsec-protocol-14 (work in progress), December 2015. Specification", draft-ietf-sidr-bgpsec-protocol-17 (work
in progress), June 2016.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>. <http://www.rfc-editor.org/info/rfc5575>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
 End of changes. 224 change blocks. 
598 lines changed or deleted 711 lines changed or added

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