draft-ietf-idr-sla-exchange-10.txt   draft-ietf-idr-sla-exchange-11.txt 
IDR S. Shah IDR S. Shah
Internet-Draft Internet-Draft
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: August 1, 2017 Arrcus, Inc Expires: February 2, 2018 Arrcus, Inc
S. Bajaj S. Bajaj
Viptela Viptela
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
Orange Orange
January 28, 2017 August 1, 2017
Inter-domain SLA Exchange Attribute Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute
draft-ietf-idr-sla-exchange-10.txt draft-ietf-idr-sla-exchange-11.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 Traffic Conditioning Agreement (TCA) 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 TCA, either
thru SLA documents or via some other out-of-band method, and thru TCA 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.
This document specifies an optional transitive attribute to signal This document specifies an optional transitive attribute to signal
SLA parameters in-band, across administrative boundaries (considered TCA parameters in-band, across administrative boundaries (considered
as Autonomous Systems (AS)), thus simplifying and facilitating some as Autonomous Systems (AS)), thus simplifying and facilitating some
of the complex provisioning tasks in situations where BGP is of the complex provisioning tasks in situations where BGP is
available as a routing protocol. available as a routing protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2017. This Internet-Draft will expire on February 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . 5 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 5
3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6 3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6
3.2. SLA SubType . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. TCA SubType . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. SLA Content for ADVERTISE SLA Event . . . . . . . . . . . 9 3.3. TCA Content for ADVERTISE TCA Event . . . . . . . . . . . 9
3.3.1. Supported IPFIX identifiers for Traffic Class 3.3.1. Supported IPFIX identifiers for Traffic Class
Elements . . . . . . . . . . . . . . . . . . . . . . 13 Elements . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Traffic Class Service types and respective TLVs . . . 14 3.3.2. Traffic Class Service types and respective TLVs . . . 15
4. Originating SLA Notification . . . . . . . . . . . . . . . . 21 4. Originating TCA Notification . . . . . . . . . . . . . . . . 22
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 21 4.1. TCA Contexts . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21 4.1.1. TCA Advertisement for Point-to-Point Connection . . . 23
4.1.2. SLA Advertisement for Destination AS Multiple Hops 4.1.2. TCA Advertisement for Destination AS Multiple Hops
Away . . . . . . . . . . . . . . . . . . . . . . . . 22 Away . . . . . . . . . . . . . . . . . . . . . . . . 24
5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 22 5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 24
5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 23 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 24
5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 23 5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 25
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Typically there is a contractual Service Level Agreement (SLA) for Typically there is a contractual Traffic Conditioning Agreement (TCA)
QoS established between a customer and a provider or between for Quality of Service (QoS) established between a customer and a
providers [RFC7297]. This QoS SLA defines the nature of the various provider or between providers [RFC7297]. This QoS TCA defines the
traffic classes and services needed within each traffic class. The nature of the various traffic classes and services needed within each
contract may include full line-rate or sub line-rate without traffic class. The contract may include full line-rate or sub line-
additional traffic classes, or it may contain additional traffic rate without additional traffic classes, or it may contain additional
classes and service definitions for those traffic classes. Finer traffic classes and service definitions for those traffic classes.
granular traffic classes may be based on some standard code points Finer granular traffic classes may be based on some standard code
(e.g., based on DSCP (Differentiated Services Code Point)) or points (e.g., based on DSCP (Differentiated Services Code Point)) or
specific set of prefixes. specific set of prefixes.
Once the contractual QoS SLA is established, QoS SLA parameters are Once the contractual QoS TCA is established, QoS TCA parameters are
enforced in some or all participating devices by deriving those enforced in some or all participating devices by deriving those
parameters into configuration information on respective devices. The parameters into configuration information on respective devices. The
network administrator translates the QoS SLA to QoS policies using network administrator translates the QoS TCA to QoS policies using
router (vendor) specific provisioning language. In a multi-vendor router (vendor) specific provisioning language. In a multi-vendor
network, translating SLAs into technology-specific and vendor- network, translating TCAs 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 TCA 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 TCA 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 TCA parameters may have to be exchanged through organizational
boundaries, thru SLA documents or via some other off-band method, to boundaries, thru TCA documents or via some other off-band method, to
an administrator provisioning actual devices. For example, to an administrator provisioning actual devices. For example, to
provide voice services, the provider may negotiate QoS parameters provide voice services, the provider may negotiate QoS parameters
(like min/max rates) for such traffic classified under the EF (like min/max rates) for such traffic classified under the EF
(Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475] (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 policy described in this The Inter-domain exchange of QoS TCA policy described in this
document does not require any specific method for the provider in document does not require any specific method for the provider in
establishing SLAs. It only requires that the provider wishes to send establishing TCAs. It only requires that the provider wishes to send
the QoS SLA policy via BGP UPDATE [RFC4271] messages from the the QoS TCA policy via BGP UPDATE [RFC4271] messages from the
provider to a set of receivers (BGP peers). In reaction to, a provider to a set of receivers (BGP peers). In reaction to, a
receiving router may translate that to relevant QoS policy definition receiving router may translate that to relevant QoS policy definition
on the device. The SLA negotiation and assurance is outside the on the device. The TCA negotiation and assurance is outside the
scope of this document. scope of this document.
This document defines a new optional BGP transitive attribute, This document defines a new optional BGP transitive attribute,
referred as QoS Attribute, which has as one of its sub-types the SLA referred as QoS Attribute, which has as one of its sub-types the TCA
policy. The BGP node of the originating AS sends this QoS Attribute, 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 for prefixes this QoS TCA Policy applies to, in a BGP UPDATE message
that will be distributed to a list of destination ASes. The QoS SLA that will be distributed to a list of destination ASes. The QoS TCA
policy can be for inbound traffic to the advertising AS or outbound policy can be for inbound traffic to the advertising AS or outbound
traffic from the advertising AS, or both. 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 standardize in [RFC8040] can set these standardize in configuration mechanisms. For
configuration mechanisms. For ephemeral state, the I2RS protocol is ephemeral state, the I2RS protocol is being developed to set
being developed to set ephemeral state. While these protocols ephemeral state. While these protocols provide valid configuration
provide valid configuration within a domain or across domains, some within a domain or across domains, some providers desire to exchange
providers desire to exchange QoS parameters in-band utilizing BGP QoS parameters in- band utilizing BGP peering relationships. This is
peering relationships. This is similar to the distribution of Flow similar to the distribution of Flow Specification information via BGP
Specification information via BGP peering relationships (see 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
BGP Speaker: A functional component on a BGP capable device that This document makes use of the following terms:
functions as per BGP specification.
BGP Peers: BGP Speakers adjacent to each other. o BGP Speaker: A functional component on a BGP capable device that
functions as per BGP specification.
QoS Attribute Speaker: A functional component on a BGP capable device o BGP peers: BGP Speakers adjacent to each other.
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 o QoS Attribute Speaker: A functional component on a BGP capable
of the BGP Speaker and thus content of the QoS Attribute is device that produces and/or processes content of the QoS
completely opaque to the BGP Speaker. At BGP capable device where Attribute. A device that is QoS Attribute Speaker is also always
QoS Attribute content is produced, length and value of the QoS a BGP Speaker. However, a BGP Speaker not necessarily always a
Attribute is passed from QoS Attribute Speaker to the BGP Speaker QoS Attribute 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, o QoS Attribute content is produced and processed outside the
following roles are defined further within the scope of the QoS function of the BGP Speaker and thus content of the QoS Attribute
Attribute Speaker. 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.
SLA Producer: This is a QoS Attribute Speaker that produces QoS In the context of use of QoS Attribute for TCA parameters
Attribute for the SLA SubType. exchange, following roles are defined further within the scope of
the QoS Attribute Speaker.
SLA Consumer: This is a QoS Attribute Speaker that is intended o TCA Producer: This is a QoS Attribute Speaker that produces QoS
receiver of QoS Attribute with the SLA SubType. Attribute for the TCA SubType.
o TCA Consumer: This is a QoS Attribute Speaker that is intended
receiver of QoS Attribute with the TCA 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) which is applicable to the attribute code to be assigned by IANA) which is applicable to the
Source AS and NLRIs advertised in the BGP UPDATE message this Source AS and NLRIs advertised in the BGP UPDATE message this
attribute is included in. The format of the QoS Attribute is shown attribute is included in. The format of the QoS Attribute is shown
in Figure 1. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 1 Figure 1: QoS attribute
Attribute flags - 8-bits field Attribute flags - 8-bits field
highest order bit (bit 0) - MUST be set to 1, since this is an highest order bit (bit 0) - MUST be set to 1, since this is an
optional attribute optional attribute
2nd higher order bit (bit 1) - MUST be set to 1, since this is a 2nd higher order bit (bit 1) - MUST be set to 1, since this is a
transitive attribute transitive attribute
The content of the QoS Attribute is further specified with flags, The content of the QoS Attribute is further specified with flags,
skipping to change at page 6, line 23 skipping to change at page 6, line 23
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 QoS Attribute Figure 2: Format of QoS Attribute
QoS Attr flags - 8-bits field QoS Attr flags - 8-bits field
All bits of this field are currently un-used. The space is 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. provided for future use. All bits MUST be set to zero when sent.
The values (0x01-0xFF) are reserved, and MUST be ignored when The values (0x01-0xFF) are reserved, and MUST be ignored when
received. received.
SubType - 8-bits field with following values: SubType - 8-bits field with following values:
0x00 = reserved 0x00 = reserved
0x01 = SLA 0x01 = TCA
0x02 - 0xf0 = reserved for future use (Standards Action) 0x02 - 0xf0 = reserved for future use (Standards Action)
0xf1 - 0xff = Private use 0xf1 - 0xff = Private use
The only SubType of the QoS Attribute defined in this The only SubType of the QoS Attribute defined in this
specification is the SLA SubType. specification is the TCA SubType.
SubType length - 16-bits field that specifies length of the SubType SubType length - 16-bits field that specifies length of the SubType
value in number of octets. value in number of octets.
SubType value - variable length field, as expressed in SubType SubType value - variable length field, as expressed in SubType
length, that contains information about a specified SubType. For length, that contains information about a specified SubType. For
the SLA SubType the information is about sender and receiver(s), the TCA SubType the information is about sender and receiver(s),
and SLA parameters as described in Section 3.2. and TCA parameters as described in Section 3.2.
3.2. SLA SubType 3.2. TCA SubType
Format of the SLA SubType Value field is shown in Figure 3. Format of the TCA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA SubType flags | Destination AS count | | TCA SubType flags | Destination AS count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS (Advertiser) | | Source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable list of Destination AS | | variable list of Destination AS |
~ .... ~ ~ .... ~
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SLAEvnt| SLA ID | SLA length | |TCAEvnt| TCA ID | TCA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA Content for SLA Event | | TCA Content for TCA Event |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Format of the SLA SubType of the QoS attribute Figure 3: Format of the TCA SubType of the QoS attribute
SLA SubType flags - 16-bits field
highest order bit (bit 0) -
If set to 1 indicates that SLA ID and SLA Content, specified in
this SLA SubType, is from the source AS to the list of
Destination AS specified in the same SLA SubType.
If set to 0 indicates to ignore Source AS and list of TCA SubType flags - 16-bits field
Destination AS specified in this SLA SubType field. SLA ID and
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.
Rest all other bits are currently un-used. Currently un-used. All bits in this field MUST be set to 0. The
field is defined for the future use.
Destination AS count - 16-bits field that specifies count of Destination AS count - 16-bits field that specifies count of
destination ASNs present in the Destination AS list. destination ASNs present in the Destination AS list.
This count has no functional value when highest order bit in the If this count is 0 then that is an error condition which should be
SLA SubType flags field is set to 0. When highest order bit is handled as described in Section 6.
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) Source AS - 32-bits field AS number space as defined in [RFC6793]
This is the AS where SLA Content is originated from. The Source This is the AS where TCA Content is originated from. The Source
AS MUST be of the same AS that is originating SLA ID and SLA AS MUST be of the same AS that is originating TCA ID and TCA
Content. Content.
When highest order bit in the SLA SubType flags field is set to 0, The Source AS value of 0 is illegal and thus should be considered
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.
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. an error which should be handled as described in Section 6.
Destination AS list - variable length field that holds as many ASN Destination AS list - variable length field that holds as many ASN.
identifiers, each is 32-bits (AS number space is defined in identifiers, each is 32-bits AS number space is defined in
RFC6793), as specified in the Destination AS count field. [RFC6793], as specified in the Destination AS count field.
List of ASNs for which the SLA is relevant to, each of which is a List of ASNs for which the TCA is relevant to, each of which is a
32-bit number. If Destination AS count is set to 0 then this 32-bit number.
field MUST NOT be included.
SLA Event - 4-bits field with following values: TCA 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
The only SLA Event defined in this specification is ADVERTISE. The only TCA Event defined in this specification is ADVERTISE.
SLA ID - 16-bits field that specifies identifier which is unique in TCA ID - 16-bits field that specifies identifier which is unique in
the scope of Source AS. the scope of Source AS.
The significance of an SLA ID is in the context of the source that The significance of a TCA ID is in the context of the source that
is advertising SLA Content. The SLA ID is not globally unique but is advertising TCA Content. The TCA ID is not globally unique but
it MUST be unique within the source AS. it MUST be unique within the source AS.
The SLA ID applies to aggregate traffic to prefixes for a given The TCA ID applies to aggregate traffic to prefixes for a given
AFI/SAFI that share the same Source AS and SLA ID. AFI/SAFI that share the same Source AS and TCA ID.
If an advertised SLA ID is different from earlier advertised one,
for the same prefix and from the same Source AS, indicates Source
AS is advertising new SLA Content to replace the previous one
advertised with the same SLA ID.
SLA Length - 12-bits field that specifies the length of the SLA TCA Length - 12-bits field that specifies the length of the TCA
Content. The length is expressed in octets. The SLA Content is Content. The length is expressed in octets. The TCA Content is
optional for an advertised SLA ID. If the SLA Content need not be optional for an advertised TCA ID. If the TCA Content need not be
there, the SLA length field MUST be set to zero in such a case. there, the TCA length field MUST be set to zero in such a case.
SLA Content - A variable length field (optional field) TCA Content - A variable length field (optional field)
The SLA Content field contains SLA parameters relevant to The TCA Content field contains TCA parameters relevant to
specified SLA SubType. Since the only defined SLA SubType is specified TCA SubType. Since the only defined TCA SubType is
ADVERTISE, this specification describes SLA Content only for the ADVERTISE, this specification describes TCA Content only for the
ADVERTISE SLA Event. ADVERTISE TCA Event.
If SLA Content field exists in a BGP UPDATE message that contains If TCA Content field exists in a BGP UPDATE message that contains
the QoS Attribute with an SLA SubType for SLA Event ADVERTISE, the QoS Attribute with a TCA SubType for TCA Event ADVERTISE,
format of the SLA Content is as described in Section 3.3. format of the TCA Content is as described in Section 3.3.
If the SLA Content field does not exist, then the advertised If the TCA Content field does not exist, then the advertised
message refers to SLA Content advertised in the previous message message refers to TCA Content advertised in the previous message
for the same SLA ID. If there does not exist any prior SLA for the same TCA ID. If there does not exist any prior TCA
Content to relate to the advertised SLA ID, then receiver, SLA Content to relate to the advertised TCA ID, then receiver, TCA
Consumer, can ignore the SLA advertisement and it may simply Consumer, can ignore the TCA advertisement and it may simply
update Destination AS count and Destination AS list. update Destination AS count and Destination AS list.
The lack of a valid prior SLA Content field does not make this The lack of a valid prior TCA Content field does not make this
attribute invalid, so the QoS Attribute MUST be forwarded as a attribute invalid, so the QoS Attribute MUST be forwarded as a
valid BGP optional transitive attribute. valid BGP optional transitive attribute.
3.3. SLA Content for ADVERTISE SLA Event 3.3. TCA Content for ADVERTISE TCA Event
The only SLA Event described in this specification is ADVERTISE. The The only TCA Event described in this specification is ADVERTISE. The
format of SLA Content for the ADVERTISE Event is shown in Figure 4. format of TCA 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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 31 skipping to change at page 9, line 47
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
| 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 TCA in the other direction ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - SLA-Content for ADVERTISE SLA Event Figure 4: TCA-Content for ADVERTISE TCA Event
SLA Content contains set of Traffic Class Elements (Classifiers) and TCA Content contains Traffic Class TLVs that is a set of Traffic
Traffic Class Service TLVs for a list of Traffic Classes. This list Class Elements (Classifiers) and Traffic Class Service TLVs for a
of Traffic Classes MUST be specified for one direction first and then list of Traffic Classes specified by Traffic Class count. This
Traffic Class TLVs MUST be specified for one direction first and then
optionally followed by the specification for the other direction. optionally followed by the specification for the other direction.
dir (Direction) - 2-bits field that specifies Direction of the dir (Direction) - 2-bits field that specifies Direction of the
traffic SLA is applicable to. The following values are defined: traffic TCA is applicable to. The following values are defined:
0x0 = reserved 0x0 = reserved
0x1 = incoming, traffic to source AS from destination AS 0x1 = incoming, traffic to source AS from destination AS
0x2 = outgoing, traffic 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 bits field that Traffic Class (Classifier Group) count - 16 bits field that
specifies number of Traffic Classes. specifies number of Traffic Classes.
The value of zero (0x00) in this field is a special value which The value of zero (0x00) in this field is a special value which
means no SLA for the traffic in a specified direction. When means no TCA for the traffic in a specified direction. When
Traffic Class count is 0, for a specific direction, the rest of Traffic Class count is 0, for a specific direction, the rest of
the SLA Content fields MUST NOT be encoded, for that specific the TCA Content fields MUST NOT be encoded, for that specific
direction. direction.
Traffic Class Description Len - 8-bits field that specifies the Traffic Class Description Len - 8-bits field that specifies the
length of the Traffic Class Description field. The length is length of the Traffic Class Description field. The length is
expressed in octets. expressed in octets.
The value of zero in this field indicates that no Traffic Class The value of zero in this field indicates that no Traffic Class
Description field follows. Description field follows.
Traffic Class Description - variable length field, as expressed in Traffic Class Description - variable length field, as expressed in
The Traffic Class Description Len field, MUST carry UTF-8 encoded The Traffic Class Description Len field, MUST carry UTF-8 encoded
[RFC3629] description. ([RFC3629]) description.
Traffic Class Elements (Classifier) Count - 8-bits field that Traffic Class Elements (Classifier) Count - 8-bits field that
specifies the count of Traffic Class Elements. specifies the count of Traffic Class Elements.
The value zero (0x00) means there are no Traffic Class Elements in The value zero (0x00) means there are no Traffic Class Elements in
the traffic class, and thus the Traffic Class is to classify rest the traffic class, and thus the Traffic Class is to classify rest
of the traffic not captured otherwise by other Traffic Classes in of the traffic not captured otherwise by other Traffic Classes in
the set for a specified direction. the set for a specified direction.
Traffic Class that has 0 elements MUST be presented last in the Traffic Class that has 0 elements MUST be presented last in the
advertised list of Traffic Classes for a specific Direction. 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 Otherwise it is considered an error condition which should be
have more than one such Traffic Classes (Traffic Class with 0 handled as described in Section 6.
elements count). If there are more than one such Traffic
Classes present then it is an error condition which should be The QoS Attribute advertised from a specific source MUST NOT have
handled as described in Section 6. more than one such Traffic Classes (Traffic Class with 0 elements
count). If there are more than one such Traffic Classes present
then it is an error condition which should be handled as described
in Section 6.
Traffic Class Element TLVs - (optional) variable length field Traffic Class Element TLVs - (optional) variable length field
holding as many TLVs specified by the Traffic Class Elements Count holding as many TLVs specified by the Traffic Class Elements Count
field. Each TLV has the following format: field. Each TLV has the following format:
IPFIX Element Identifier - 8-bits field that specifies IPFIX IPFIX Element Identifier - 8-bits field that specifies IPFIX
Identifiers listed in Table 1. Identifiers listed in Table 1.
Length of Value field - 8-bits field that specifies the length, Length of Value field - 8-bits field that specifies the length,
expressed in octets, of the value field. expressed in octets, of the value field.
Value - A variable field that specifies a value appropriate for Value - A variable field that specifies a value appropriate for
the IPFIX Element Identifier. It is an error, if the value the IPFIX Element Identifier. It is an error, if the value field
field does not contain the appropriate format, which should be does not contain the appropriate format, which should be handled
handled as described in Section 6. Only the IPFIX elements as described in Section 6. Only the IPFIX elements shown in
shown in Table 1 are supported. 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 advertised AFI/SAFI NLRI 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, SLA message the QoS Attribute is contained in. If a receiver, TCA
Consumer, receives a BGP UPDATE message with QoS Attribute for an Consumer, receives a BGP UPDATE message with QoS Attribute for an
unsupported AFI/SAFI then SLA Consumer MAY ignore advertised SLA. unsupported AFI/SAFI then TCA Consumer MAY ignore advertised TCA.
SLA Consumer MAY update only Destination AS count and Destination TCA Consumer MAY update only Destination AS count and Destination
AS list, and then QoS Attribute and rest of the BGP UPDATE message AS list, and then QoS Attribute and rest of the BGP UPDATE message
MUST be forwarded as per QoS Attribute and BGP protocol MUST be forwarded as per QoS Attribute and BGP protocol
specification. specification.
Traffic Class Service Count - 8-bits field that specifies count of Traffic Class Service Count - 8-bits field that specifies count of
Traffic Class Service TLVs. Traffic Class Service TLVs.
A value of zero is a special value indicating "no bounded service" A value of zero is a special value indicating "no bounded service"
(a.k.a., Best Effort (BE)). (a.k.a., Best Effort (BE)).
Traffic Class Service TLVs - (optional) variable length field with 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-bits field that 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 = COMMITTED_TSPEC
0x02 = L2_OVERHEAD 0x02 = PEAK_TSPEC
0x03 = MINRATE_IN_PROFILE_MARKING 0x03 = COMMITTED_IN_PROFILE_MARKING
0x04 = MINRATE_OUT_PROFILE_MARKING 0x04 = COMMITTED_OUT_PROFILE_MARKING
0x05 = MAXRATE_IN_PROFILE_MARKING 0x05 = PEAK_OUT_PROFILE_MARKING
0x06 = MAXRATE_OUT_PROFILE_MARKING 0x06 = DROP_THRESHOLD
0x07 = DROP_THRESHOLD 0x07 = RELATIVE_PRIORITY
0x08 = RELATIVE_PRIORITY 0x08 = EFFECTIVE_MAX_RATE
0x09 = SUB_TRAFFIC_CLASSES 0x09 = SUB_TRAFFIC_CLASSES
Length of Value field - 08-bits field that specifies the length Length of Value field - 08-bits field that specifies the length of
of the value field. The length of the value is expressed in the value field. The length of the value is expressed in octets.
octets.
Value - a variable length field that specifies the value Value - a variable length field that specifies the value
appropriate for each of the Service Types. It is an error, if appropriate for each of the Service Types. It is an error, if
this field does not contain the appropriate format, which this field does not contain the appropriate format, which should
should be handled as described in Section 6. The format of the be handled as described in Section 6. The format of the value for
value for each of the service types is described in each of the service types is described in Section 3.3.2
Section 3.3.2
3.3.1. Supported IPFIX identifiers for Traffic Class 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/
ipfix.xml#ipfix-information-elements). Only the IPFIX attributes ipfix.xml#ipfix-information-elements> ipfix.xml#ipfix-information-
listed in Table 1 are supported. Any new attribute to be supported elements). Only the IPFIX attributes listed in Table 1 are
by SLA SubType MUST be a Standards Action as described in IANA supported. Any new attribute to be supported by TCA SubType MUST be
section. a Standards Action as described in IANA section.
+----+----------------------------+ +-----+-----------------------------+-------------------------------+
| ID | Name | | ID | Name | Context |
+----+----------------------------+ +-----+-----------------------------+-------------------------------+
|195 | ipDiffServCodePoint | | 195 | ipDiffServCodePoint | Indicates the value of the |
|203 | mplsTopLabelExp | | | | marking used in the link(s) |
|244 | dot1qPriority | | | | between the TCA Consumer and |
| 8 | sourceIPv4Address | | | | TCA Producer domains. |
| 27 | sourceIPv6Address | +-----+-----------------------------+-------------------------------+
| 9 | sourceIPv4PrefixLength | | 203 | mplsTopLabelExp | Indicates the value of the |
| 29 | sourceIPv6PrefixLength | | | | marking used in the link(s) |
| 44 | sourceIPv4Prefix | | | | between the TCA Consumer and |
|170 | sourceIPv6Prefix | | | | TCA Producer domains. |
| 12 | destinationIPv4Address | +-----+-----------------------------+-------------------------------+
| 28 | destinationIPv6Address | | 244 | dot1qPriority | Indicates the value of the |
| 13 | destinationIPv4PrefixLength| | | | marking used in the link(s) |
| 30 | destinationIPv6PrefixLength| | | | between the TCA Consumer and |
| 45 | destinationIPv4Prefix | | | | TCA Producer domains. |
|169 | destinationIPv6Prefix | +-----+-----------------------------+-------------------------------+
| 4 | protocolIdentifier | | 8 | sourceIPv4Address | Indicates the source IPv4 |
| 7 | sourceTransportPort | | | | address of an aggregate |
| 11 | destinationTransportPort | | | | traffic over a connection |
+----+----------------------------+ | | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 27 | sourceIPv6Address | Indicates the source IPv6 |
| | | address of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 9 | sourceIPv4PrefixLength | Indicates the length of the |
| | | source IPv4 prefix. |
+-----+-----------------------------+-------------------------------+
| 29 | sourceIPv6PrefixLength | Indicates the length of the |
| | | source IPv6 prefix. |
+-----+-----------------------------+-------------------------------+
| 44 | sourceIPv4Prefix | Indicates the source IPv4 |
| | | prefix of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 170 | sourceIPv6Prefix | Indicates the source IPv6 |
| | | prefix of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 12 | destinationIPv4Address | Indicates the destination |
| | | IPv4 address of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 28 | destinationIPv6Address | Indicates the destination |
| | | IPv6 address of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 13 | destinationIPv4PrefixLength | Indicates the length of the |
| | | destination IPv4 prefix. |
+-----+-----------------------------+-------------------------------+
| 30 | destinationIPv6PrefixLength | Indicates the length of the |
| | | destination IPv6 prefix. |
+-----+-----------------------------+-------------------------------+
| 45 | destinationIPv4Prefix | Indicates the destination |
| | | IPv4 prefix of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 169 | destinationIPv6Prefix | Indicates the destination |
| | | IPv6 prefix of an aggregate |
| | | traffic over a connection |
| | | subject to a TCA; the |
| | | direction is being explicitly |
| | | indicated in the ADVERTISE |
| | | Event message. |
+-----+-----------------------------+-------------------------------+
| 4 | protocolIdentifier | Indicates whether any or a |
| | | specific protocol for the |
| | | traffic class. |
+-----+-----------------------------+-------------------------------+
| 7 | sourceTransportPort | This parameter is used only |
| | | for protocols with port |
| | | identifiers. It indicates the |
| | | source port number for the |
| | | transport protocol identified |
| | | by "protocolIdentifier". |
+-----+-----------------------------+-------------------------------+
| 11 | destinationTransportPort | This parameter is used only |
| | | for protocols with port |
| | | identifiers. It indicates the |
| | | destination port number for |
| | | the transport protocol |
| | | identified by |
| | | "protocolIdentifier". |
+-----+-----------------------------+-------------------------------+
Table 1 Table 1
3.3.2. Traffic Class Service types and respective TLVs 3.3.2. Traffic Class Service types and respective TLVs
3.3.2.1. TRAFFIC_CLASS_TSPEC 3.3.2.1. COMMITTED_TSPEC
The TRAFFIC_CLASS_TSPEC TLV definition: The COMMITTED_TSPEC TLV definition:
Type - 0x01 Type - 0x01
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be 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 specified to be 8 octets to hold the value defined as per format
below. below.
Value - TRAFFIC_CLASS_TSPEC value consists of the (r), (b), (p) Value - COMMITTED_TSPEC value consists of the (r), (b) parameters
parameters as described in Invocation Information section of as described in Invocation Information section of [RFC2212] and
[RFC2212] and shown in Figure 5. Note that inheriting the shown in Figure 5. Note that inheriting the definition of TSPEC
definition of TSPEC (Traffic SPECification) here does not enable (Traffic SPECification) here does not enable RFC2212
RFC2212 functionality. Only the format of the Traffic functionality. Only the format of the Traffic Specification is
Specification is used in this specification. 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) | | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Traffic Class TSPEC Figure 5: Traffic Class COMMITTED_TSPEC
Format of Parameters (r), (b) and (p): are 32-bit IEEE floating Format of Parameters (r) and (b): are 32-bit IEEE floating point
point numbers. Positive infinity is represented as an IEEE single 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 committed-rate of the traffic class. This
indicates the minimum rate, measured in octets of Layer 2 (L2) rate indicates the minimum rate, measured in octets of IP
datagrams per second (a.k.a, bytes per second), that the service datagrams per second (a.k.a, bytes per second), that the service
advertiser is providing for a given class of traffic on advertiser is providing for a given class of traffic on
advertiser's hop. Note that it does not necessarily translate to advertiser's hop. Note that it does not necessarily translate to
a minimum rate service to the receiver of an SLA unless the a minimum rate service to the receiver of a TCA unless the traffic
traffic class definition clearly represents a sole receiver of an class definition clearly represents a sole receiver of a TCA.
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 IP 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 committed-rate (r), in presence of
zero parameter (r), parameter (b) represents bounded delay for the non-zero parameter (r), parameter (b) represents bounded delay for
Traffic Class. This delay is a single hop queuing delay when SLA the Traffic Class. This delay is a single hop queuing delay when
is to be implemented at the resource constrained bottleneck. In TCA is to be implemented at the resource constrained bottleneck.
other words this burst size can be considered as a buffer size. In other words this burst size can be considered as a buffer size.
Value of 0 for parameter (b) means the advertiser does not mandate 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 3.3.2.2. PEAK_TSPEC
min-rate, max-rate, measured in octets of L2 datagrams per second
(a.k.a., bytes per second), field here also indicates service
provided by advertiser. If advertiser does not have any specific
value to set for a given class of traffic, it MAY be set to
physical interface line rate or any other indirect limit that may
affect this class' maximum rate. In absence of any such known
value, it MUST be set to positive infinity. Value 0 is considered
an error which should be handled as described in Section 6.
3.3.2.2. L2_OVERHEAD
The L2_OVERHEAD TLV definition: The PEAK_TSPEC TLV definition:
Type - 0x02 Type - 0x01
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. of the value field. The length of the value field MUST be
specified to be 8 octets to hold the value defined as per format
below.
Value - Layer 2 overhead in octets Value - PEAK_TSPEC value consists of the (r), (b) parameters as
described in Invocation Information section of [RFC2212] and shown
in Figure 5. Note that inheriting the definition of TSPEC
(Traffic SPECification) here does not enable RFC2212
functionality. Only the format of the Traffic Specification is
used in this specification.
L2_OVERHEAD defines Layer 2 (L2) specific data in octets, on top of 0 1 2 3
IP datagram size, in a layer 2 frame. By default the rate and burst 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
advertised in the TRAFFIC_CLASS_TSPEC TLV are applicable to the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
packet size including L2 packet overhead. For the SLA Consumer | Rate (r) (32-bit IEEE floating point number) |
directly connected to the SLA Producer, this overhead is the L2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
overhead of the local link where advertised SLA is received. | Burst Size (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
However, in cases where advertised SLA is for a SLA Consumer multiple Figure 6: Traffic Class PEAK_TSPEC
hops away, L2 overhead from the source, SLA Producer, perspective may
be different from the local link L2 overhead at the receiver, SLA
Consumer. In such cases, explicit notification of size of L2
overhead from the SLA Producer suggests what per packet L2 overhead
is applicable to the rate and burst advertised in the
TRAFFIC_CLASS_TSPEC TLV. L2_OVERHEAD TLV SHOULD BE ignored by the
SLA Consumer if there does not exist TRAFFIC_CLASS_TSPEC TLV for the
specified direction.
Advertised L2 value of 0 means SLA advertised is for IP packet size. Format of Parameters (r) and (b): are 32-bit IEEE floating point
numbers. Positive infinity is represented as an IEEE single
precision floating-point number with an exponent of all ones and a
sign mantissa of all zeros. The format of IEEE floating-point
numbers is further summarized in [RFC4506].
3.3.2.3. MINRATE_IN_PROFILE_MARKING Parameter (r): indicates peak-rate of the traffic class. This rate
indicates the maximum rate, measured in octets of IP datagrams per
second (a.k.a, bytes per second), that the service advertiser is
providing for a given class of traffic on advertiser's hop.
This Traffic Class Service Type defines action performed, by the SLA Parameter (b): indicates maximum burst size, measured in octets of
Producer, on packets that are compliant to the min-rate specified in IP datagram size.
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.
The MINRATE_IN_PROFILE_MARKING TLV definition: When PEAK_TSPEC TLV is advertised, COMMITTED_TSPEC TLV MUST be
present in the advertisement. Advertisement of PEAK_TSPEC TLV
without COMMITTED_TSPEC TLV MUST be considered an error condition
which should be handled as described in Section 6. If committed-rate
of the TCA is 0 then rate advertised in the COMMITTED_TSPEC shall be
0. Note that existence of COMMITTED_TSPEC in TCA advertisement is
not mandatory nor is it a mandate that COMMITTED_TSPEC and PEAK_TSPEC
must always go together. COMMITTED_TSPEC TLV is optional but only
when there is no PEAK_TSPEC TLV present in the advertised TCA.
PEAK_TSPEC TLV with rate value of 0 MUST be considered an error
condition which should be handled as described in Section 6.
3.3.2.3. COMMITTED_IN_PROFILE_MARKING
This Traffic Class Service Type defines action performed, by the TCA
Producer, on packets that are compliant to the committed-rate
specified in the COMMITTED_TSPEC TLV. If committed-rate specified in
the COMMITTED_TSPEC TLV is 0 then TLV for this Traffic Class Service
Type SHOULD NOT be advertised. COMMITTED_IN_PROFILE_MARKING TLV
SHOULD be ignored by the TCA Consumer if there does not exist
COMMITTED_TSPEC TLV for the specified direction, or committed-rate
specified in the COMMITTED_TSPEC TLV is 0.
The COMMITTED_IN_PROFILE_MARKING TLV definition:
Type - 0x03 Type - 0x03
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be 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 specified to be 2 octets to hold the value defined as per format
below. below.
Value - contains the Marking code-point type and value Value - contains the Marking code-point type and value
Marking code-point type - 8-bits IPFIX Element Identifier. Marking code-point type - 8-bits IPFIX Element Identifier.
Marking code-point value - 8-bits code-point number. Marking code-point value - 8-bits code-point number.
The marking code-point type of 0x00 is a drop identifier. When The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking 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 code-point value in this case has no meaning and thus the value in
this field should be ignored. this field should be ignored.
The following table lists the supported IPFIX Identifiers. Any value The following table lists the supported IPFIX Identifiers. Any value
skipping to change at page 16, line 42 skipping to change at page 18, line 17
The marking code-point type of 0x00 is a drop identifier. When The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking 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 code-point value in this case has no meaning and thus the value in
this field should be ignored. this field should be ignored.
The following table lists the supported IPFIX Identifiers. Any value The following table lists the supported IPFIX Identifiers. Any value
other than 0 or identifier from the following table is an error other than 0 or identifier from the following table is an error
condition which should be handled as described in Section 6. 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. MINRATE_OUT_PROFILE_MARKING 3.3.2.4. COMMITTED_OUT_PROFILE_MARKING
This Traffic Class Service Type defines action performed, at the SLA This Traffic Class Service Type defines action performed, at the TCA
Producer, on packets that are not compliant to the min-rate specified Producer, on packets that are not compliant to the committed-rate
in the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the specified in the COMMITTED_TSPEC TLV, and compliant to rate specified
TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service in the PEAK_TSPEC TLV if PEAK_TSPEC TLV exists.
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.
The MINRATE_OUT_PROFILE_MARKING TLV definition: The COMMITTED_OUT_PROFILE_MARKING TLV definition:
Type - 0x04 Type - 0x04
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be 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 specified to be 2 octets to hold the value defined as per format
below. below.
Value - contains the Marking code-point type and value Value - contains the Marking code-point type and value
skipping to change at page 17, line 40 skipping to change at page 19, line 14
The marking code-point type of 0x00 is a drop identifier. When The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking 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 code-point value in this case has no meaning and thus the value in
this field should be ignored. this field should be ignored.
Table 2 lists the supported IPFIX Identifiers. Any value other than Table 2 lists the supported IPFIX Identifiers. Any value other than
0 or identifier from the Table 2 is an error condition which should 0 or identifier from the Table 2 is an error condition which should
be handled as described in Section 6. be handled as described in Section 6.
3.3.2.5. MAXRATE_IN_PROFILE_MARKING 3.3.2.5. PEAK_OUT_PROFILE_MARKING
This Traffic Class Service Type defines action performed, at the SLA
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.
The MAXRATE_IN_PROFILE_MARKING TLV definition:
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.
Value - contains the Marking code-point type and value
Marking code-point type - 8-bits IPFIX Element Identifier
Marking code-point value - 8-bits code-point number
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.
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.6. MAXRATE_OUT_PROFILE_MARKING
This Traffic Class Service Type defines action performed, at the SLA This Traffic Class Service Type defines action performed, at the TCA
Producer, on packets that are not compliant to the max-rate specified Producer, on packets that are not compliant to the max-rate specified
in the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_OUT_PROFILE_MARKING TLV in the PEAK_TSPEC TLV. PEAK_OUT_PROFILE_MARKING TLV SHOULD be
SHOULD BE ignored by the SLA Consumer if there does not exist ignored by the TCA Consumer if there does not exist PEAK_TSPEC TLV
TRAFFIC_CLASS_TSPEC TLV for the specified direction. for the specified direction.
The MAXRATE_OUT_PROFILE_MARKING TLV definition: The PEAK_OUT_PROFILE_MARKING TLV definition:
Type - 0x06 Type - 0x06
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be 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 specified to be 2 octets to hold the value defined as per format
below. below.
Value - contains the Marking code-point type and value Value - contains the Marking code-point type and value
skipping to change at page 19, line 9 skipping to change at page 19, line 46
The marking code-point type of 0x00 is a drop identifier. When The marking code-point type of 0x00 is a drop identifier. When
marking code-point type value is 0x00 (that is drop), the marking 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 code-point value in this case has no meaning and thus the value in
this field should be ignored. this field should be ignored.
Table 2 lists the supported IPFIX Identifiers. Any value other than Table 2 lists the supported IPFIX Identifiers. Any value other than
0 or identifier from the Table 2 is an error condition which should 0 or identifier from the Table 2 is an error condition which should
be handled as described in Section 6. be handled as described in Section 6.
3.3.2.7. Precedence between MINRATE and MAXRATE 3.3.2.6. DROP_THRESHOLD
The precedence between MINRATE_IN_PROFILE_MARKING,
MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and
MAXRATE_OUT_PROFILE_MARKING when all four are advertised is:
- MINRATE_IN_PROFILE_MARKING takes highest precedence (that is
over MAXRATE_IN_PROFILE_MARKING),
- MAXRATE_IN_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING, and
- MAXRATE_OUT_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING
3.3.2.8. DROP_THRESHOLD
The DROP_THRESHOLD TLV definition: The DROP_THRESHOLD TLV definition:
Type - 0x07 Type - 0x07
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. of the value field.
Value - Count of drop thresholds, followed by content for each Value - Count of drop thresholds, followed by content for each
drop threshold in the form of (code-point type, count of code- drop threshold in the form of (code-point type, count of code-
points, list of code-points, threshold value). points, list of code-points, threshold value).
Count of drop thresholds - 8-bits field that specifies number Count of drop thresholds - 8-bits field that specifies number of
of drop thresholds specified in this TLV. Content of each drop drop thresholds specified in this TLV. Content of each drop
threshold is to follow following format threshold is to follow following format
Code-point type - 8-bits IPFIX Element Identifier from the list Code-point type - 8-bits IPFIX Element Identifier from the list
shown in Table 6. shown in Table 6.
Count of code-points - 8-bits field that specifies number of Count of code-points - 8-bits field that specifies number of code-
code-point values to follow for a specified code-point type. point values to follow for a specified code-point type.
List of code-points - each code-point value is specified in List of code-points - each code-point value is specified in size
size of 8 bits and thus total size for this field is 8 bits of 8 bits and thus total size for this field is 8 bits multiplied
multiplied by as many number of code-points specified. by as many number of code-points specified.
Burst value - This is a fixed size 32-bits IEEE floating point Burst value - This is a fixed size 32-bits IEEE floating point
number that specifies burst value in unit of bytes. number that specifies burst value in unit of bytes.
+----+----------------------------+ All advertised drop thresholds, for a specific traffic class, are
| ID | Name | applicable to a single queue associated with that traffic class. A
+----+----------------------------+ threshold for a set of code-points is a logical marker where an
|195 | ipDiffServCodePoint | arrived packet is to be tail dropped if overall depth of a queue is
|203 | mplsTopLabelExp | beyond a threshold of a code-point set, a packet is classified into.
|244 | dot1qPriority | If a packet can not be classified into any of the advertised code-
+----+----------------------------+ point set then that means the TCA Producer is not defining any
specific tail drop behavior and thus dropping behavior is subject to
implementation specific of the TCA Consumer.
Table 3 +-----+---------------------+
| ID | Name |
+-----+---------------------+
| 195 | ipDiffServCodePoint |
| 203 | mplsTopLabelExp |
| 244 | dot1qPriority |
+-----+---------------------+
3.3.2.9. RELATIVE_PRIORITY Table 3
3.3.2.7. RELATIVE_PRIORITY
The RELATIVE_PRIORITY TLV definition: The RELATIVE_PRIORITY TLV definition:
Type - 0x08 Type - 0x08
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. Given supported range of priority values in of the value field. Given supported range of priority values in
this specification, the length of the value field MUST be limited this specification, the length of the value field MUST be limited
to and thus MUST be specified exactly as 1 octet. to and thus MUST be specified exactly as 1 octet.
skipping to change at page 20, line 38 skipping to change at page 21, line 28
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. SUB_TRAFFIC_CLASSES A higher priority class of traffic to be served without pre-empted by
lower priority class of traffic for more than a packet time at the
configured rate.
In the system that implements WRR only (no priority queuing), it is
possible to use a single queue from a group of queues serviced by WRR
scheduler, where the share of the output bandwidth assigned to that
queue is equal to advertised rate for that priority.
3.3.2.8. EFFECTIVE_MAX_RATE
The EFFECTIVE_MAX_RATE TLV definition:
Type - 0x02
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 5 octets to hold the value defined as per format
below.
Value - Contains value of rate and per packet overhead
Aggregate max rate - 32-bits IEEE floating point number
Per packet overhead - 8-bits specifying value of overhead
octets
Aggregate max rate indicates rate measured based on combined octets
of packet's IP datagram size and advertised per packet overhead.
A packet traversing from the TCA Producer to the TCA Consumer or
vice-versa may see packet overhead, additional octets on top of IP
datagram size, difference between the Producer and the Consumer sent
or received over a physical link. In cases, where advertised TCA is
for a Consumer where total traffic between Consumer and Producer is
to be capped to a specific sub-rate of a physical link, due to packet
overhead differences between Producer and Consumer, sum of traffic
from each TRAFFIC CLASS may overrun that total cap causing undesired
behavior. In such cases, Producer can explicitly notify this TLV in
advertised TCA.
3.3.2.9. SUB_TRAFFIC_CLASSES
The SUB_TRAFFIC_CLASSES TLV definition: The SUB_TRAFFIC_CLASSES TLV definition:
Type - 0x09 Type - 0x09
Length - 16-bits field that specifies total length, expressed in Length - 16-bits field that specifies total length, expressed in
octets, of a subset of Traffic Class TLVs encoded in the value octets, of a Traffic Class TLVs encoded in the value field
field
Value - A subset of Traffic Class TLVs Value - A subset of Traffic Class TLVs
For SLAs where a specific Traffic Class may further be defined by a For TCAs where a specific Traffic Class may further be defined by a
subset of more granular Traffic Classes, each with its own set of subset of more granular Traffic Classes, with its own set of Traffic
Traffic Class Elements and Service types definitions, Class TLVs, SUB_TRAFFIC_CLASSES service type SHOULD be used to
SUB_TRAFFIC_CLASSES service type SHOULD be used to specify them. specify them.
4. Originating SLA Notification 4. Originating TCA Notification
The QoS Attribute for the SLA SubType MUST only be added to the BGP The QoS Attribute for the TCA SubType MUST only be added to the BGP
UPDATE message at the node that is SLA Producer. Any QoS Attribute UPDATE message at the node that is TCA Producer. Any QoS Attribute
Speaker, in the path to the SLA Consumer MUST NOT modify content of Speaker, in the path to the TCA Consumer MUST NOT modify content of
that attribute except modification of the Destination AS list. that attribute except modification of the Destination AS list.
QoS Attribute with the SLA SubType SHOULD NOT be advertised QoS Attribute with the TCA SubType SHOULD NOT be advertised
periodically just for the purpose of KEEPALIVE between SLA Producer periodically just for the purpose of KEEPALIVE between TCA Producer
and SLA Consumer. Some sort of SLA policy change, at the SLA and TCA Consumer. Some sort of TCA policy change, at the TCA
Producer, may be considered as a trigger for the advertisement. Producer, may be considered as a trigger for the advertisement.
For any modified SLA policy at the SLA Producer, SLA Producer MUST For any modified TCA policy at the TCA Producer, the TCA Producer
re-advertise the entire set of SLA parameters. There is no provision MUST re-advertise the entire set of TCA parameters. There is no
to advertise partial set of SLA parameters. If modified SLA policy provision to advertise partial set of TCA parameters. Announcing a
is to mean no SLA between SLA Producer and SLA Consumer, then SLA TCA ID different from an earlier advertised one, for the same prefix
Content MUST be sent with the same SLA ID with the same AS Source and and from the same Source AS, indicates Source AS is advertising new
NLRI prefix, as were used to advertise earlier SLA parameters, and TCA Content to replace the previous one advertised with the same TCA
the Traffic Class count set to 0. ID.
4.1. SLA Contexts In order to withdraw a given TCA between TCA Producer and TCA
Consumer, the TCA Produced MUST sent TCA Content with the same TCA
ID, AS Source, and NLRI prefix, as were used to advertise earlier TCA
parameters, and the Traffic Class count MUST be set to 0.
4.1.1. SLA Advertisement for Point-to-Point Connection 4.1. TCA Contexts
In certain cases, the advertisement of an SLA is intended to relate 4.1.1. TCA Advertisement for Point-to-Point Connection
to aggregate traffic over a point-to-point connection between a
specific destination and a specific source. A point-to-point In certain cases, the advertisement of a TCA is intended to relate to
connection may be a physical link or a virtual link (e.g. a tunnel). aggregate traffic over a point-to-point connection between a specific
In such cases, a BGP UPDATE message with source AS number and NLRI destination and a specific source. A point-to-point connection may
prefix as an IP address of an SLA Producer can uniquely identify be a physical link or a virtual link (e.g. a tunnel). In such cases,
physical/virtual link in order to establish the context for the a BGP UPDATE message with source AS number and NLRI prefix as an IP
advertised SLA for that point to point link. address of a TCA Producer can uniquely identify physical/virtual link
in order to establish the context for the advertised TCA for that
point to point link.
In the simplest case where Provider (e.g., PE) and Customer (e.g., In the simplest case where Provider (e.g., PE) and Customer (e.g.,
CE) devices are directly connected via a physical link and have only CE) devices are directly connected via a physical link and have only
a single link between them, the CE can uniquely identify the a single link between them, the CE can uniquely identify the
forwarding link to the 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 the PE, that is the next hop o NLRI prefix being an IP address of the PE, that is the next hop
address from CE to PE. address from CE to PE.
The SLA advertised in the QoS Attribute in the BGP UPDATE message The TCA 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 PE's 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 TCA 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 TCA advertised in the QoS Attribute in the BGP UPDATE message
from PE to CE, with PE's AS number and any other prefix, means SLA from PE to CE, with PE's AS number and any other prefix, means TCA
for that specific prefix based traffic, a subset of traffic through 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 TCA 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). TCA 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).
When BGP UPDATE message with the QoS Attribute, containing SLA When BGP UPDATE message with the QoS Attribute, containing TCA
SubType, is triggered for a point-to-point connection (physical or SubType, is triggered for a point-to-point connection (physical or
logical), the Source AS number in the SLA SubType SHOULD BE set to logical), the Source AS number in the TCA SubType SHOULD be set to
SLA Producer's AS number and destination AS number SHOULD BE set to TCA Producer's AS number and destination AS number SHOULD be set to
AS number of BGP peer's that is targeted SLA Consumer. AS number of BGP peer's that is targeted TCA Consumer.
Alternatively, highest order bit in the SLA SubType flags MAY BE set
to ignore Source AS and destination AS values from the SLA SubType
content since SLA advertised is meant specifically for the BGP peer.
4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 4.1.2. TCA Advertisement for Destination AS Multiple Hops Away
When advertised SLA is not for the BGP peer of an SLA Producer, the When advertised TCA is not for the BGP peer of a TCA Producer, the
Source AS field, in the SLA SubType, MUST be set. The list of Source AS field, in the TCA SubType, MUST be set. The list of
destination AS(es) also MUST be set, in the SLA SubType, to avoid destination AS(es) also MUST be set, in the TCA SubType, to avoid
flooding of the QoS Attribute data in the network beyond those flooding of the QoS Attribute data in the network beyond those
destinations. Destination AS(es) is a list of SLA Consumers the destinations. Destination AS(es) is a list of TCA Consumers the
advertised SLA is intended for. advertised TCA is intended for.
If a new prefix is learned and traffic with this new prefix is If a new prefix is learned and traffic with this new prefix is
subject to SLA parameters that have already been advertised before subject to TCA parameters that have already been advertised before
for other existing prefixes, then the BGP UPDATE for this new prefix for other existing prefixes, then the BGP UPDATE for this new prefix
MAY include QoS Attribute containing just an SLA ID that was MAY include QoS Attribute containing just a TCA ID that was
advertised earlier. This BGP UPDATE message does not require to have advertised earlier. This BGP UPDATE message does not require to have
the whole SLA Content. The SLA ID is sufficient to relate SLA the whole TCA Content. The TCA ID is sufficient to relate TCA
parameters to new advertised prefixes. parameters to new advertised prefixes.
5. QoS Attribute Handling at Forwarding Nodes 5. QoS Attribute Handling at Forwarding Nodes
The propagation of the QoS Attribute in the BGP UPDATE messages The propagation of the QoS Attribute in the BGP UPDATE messages
depends on the rules detailed in the following sub-sections. depends on the rules detailed in the following sub-sections.
5.1. BGP Node Capable of Processing QoS Attribute 5.1. BGP Node Capable of Processing QoS Attribute
If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS
Attribute. If BGP UPDATE message has a QoS Attribute with a list of Attribute. If BGP UPDATE message has a QoS Attribute with a list of
destination ASes, QoS Attribute Speaker MAY trim the list and adjust destination ASes, QoS Attribute Speaker MAY trim the list and adjust
the count of the destination AS to exclude ones that are not required the count of the destination AS to exclude ones that are not required
in further announcement of BGP UPDATE messages. in further announcement of BGP UPDATE messages.
A QoS Attribute Speaker MUST drop SLA SubType from the QoS Attribute, A QoS Attribute Speaker MUST drop TCA SubType from the QoS Attribute,
if there are no more ASes left in the QoS Attribute's destination 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 list. The rest of the QoS Attribute contents may be forwarded if
there exist other SubTypes of QoS Attribute and forwarding rules meet there exist other SubTypes of QoS Attribute and forwarding rules meet
other SubTypes requirements. If there is no other SubTypes in that other SubTypes requirements. If there is no other SubTypes in that
QoS Attribute content then QoS Attribute Speaker MUST drop the entire QoS Attribute content then QoS Attribute Speaker MUST drop the entire
QoS Attribute all together. BGP Speaker MAY announce further other QoS Attribute all together. BGP Speaker MAY announce further other
attributes and NLRI information, if they meet rules defined by other attributes and NLRI information, if they meet rules defined by other
attributes and BGP specification. attributes and BGP specification.
Except extracting the entire SLA SubType of the QoS Attribute and Except extracting the entire TCA SubType of the QoS Attribute and
trimming the list of Destination AS list, all other content MUST NOT trimming the list of Destination AS list, all other content MUST NOT
be modified by any QoS Attribute Speaker or BGP Speaker in the path be modified by any QoS Attribute Speaker or BGP Speaker in the path
of a BGP UPDATE message. of a BGP UPDATE message.
5.2. QoS Attribute Handling at Receiver 5.2. QoS Attribute Handling at Receiver
Once QoS Attribute with the SLA SubType is received at intended Once QoS Attribute with the TCA SubType is received at intended
receiver (SLA Consumer) , processing of advertised SLA Content is receiver (TCA Consumer) , processing of advertised TCA Content is
optional for the SLA Consumer. SLA Consumer MAY just trim the optional for the TCA Consumer. TCA Consumer MAY just trim the
Destination AS list as per rules described in this specification, Destination AS list as per rules described in this specification,
without processing any other content of the Attribute. If intended without processing any other content of the Attribute. If Receiver
receiver is not a QoS Attribute Speaker than BGP Speaker MUST forward chooses to process advertised TCA content, it may encounter errors
this attribute without any change if rest of the BGP UPDATE message beyond the ones described in this document, errors like
also meets forwarding rules as per BGP specification. unavailability of resources if Receiver chooses to implement policies
for advertised TCA. In such a case Receiver MAY simply log a
message. QoS attribute still MUST be forwarded as per rules defined
in this document and rest of the BGP UPDATE message MUST be processed
as per BGP specification. If intended 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.
When BGP UPDATE messages are triggered only as a result of SLA policy When BGP UPDATE messages are triggered only as a result of TCA policy
change, propagating BGP UPDATE message beyond intended SLA Consumers change, propagating BGP UPDATE message beyond intended TCA Consumers
is not necessary. If the SLA Consumer device implementations are is not necessary. If the TCA Consumer device implementations are
capable of policy based filtering, it may implement a policy to capable of policy based filtering, it may implement a policy to
filter such BGP UPDATE messages based on prefixes and QoS Attribute filter such BGP UPDATE messages based on prefixes and QoS Attribute
containing SLA SubType. containing TCA SubType.
6. Error Handling 6. Error Handling
Error conditions, while processing of the QoS Attribute content, MUST Error conditions, while processing of the QoS Attribute content, MUST
be handled with the approach of attribute discard as described in be handled with the approach of attribute discard as described in
[RFC7606]. Processing of QoS Attribute content is done by QoS [RFC7606]. Processing of QoS Attribute content is done by QoS
Attribute Speaker and thus in case of errors, resulting in attribute Attribute Speaker and thus in case of errors, resulting in attribute
discard, QoS Attribute Speaker SHOULD convey such indication to the discard, QoS Attribute Speaker SHOULD convey such indication to the
BGP Speaker and rest of the BGP message SHOULD BE processed by the BGP Speaker and rest of the BGP message SHOULD be processed by the
BGP Speaker as per BGP specification. BGP Speaker as per BGP specification.
7. 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 TCA
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 TCA 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 TCA
parameters are then advertised thru proposed QoS Attribute to the CE parameters are then advertised thru proposed QoS Attribute to the CE
device. The CE device may read the QoS Attribute and SLA SubType device. The CE device may read the QoS Attribute and TCA 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 TCA 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 TCA 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).
_______________ _______________
__________ / \ __________ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
|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 TCA_ADVERTISE: AS2 to AS3
NLRI = PE ip address NLRI = PE ip address
Figure 6 - Example 1 Figure 7: - Example 1
Another use case can be to advertise SLAs among different network Another use case can be to advertise TCAs 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 TCAs at spoke and advertise QoS TCA
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 TCA to AS3 in the context of that tunnel
ip address. ip address.
AS 2 AS 2
_______________ ________ _______________ ________
/ \ / \ / \ / \
_____ / \-----| Spoke2 | _____ / \-----| Spoke2 |
/ \ / \ \________/ / \ / \ \________/
| Hub |-----| Provider | ________ | Hub |-----| Provider | ________
\______/ \ / / \ \______/ \ / / \
\ /-----| Spoke1 | \ /-----| Spoke1 |
AS 3 \_______________/ \________/ AS 3 \_______________/ \________/
AS 1 AS 1
SLA_ADVERTISE: AS2 to AS3 TCA_ADVERTISE: AS2 to AS3
NLRI = AS2 tunnel address NLRI = AS2 tunnel address
SLA_ADVERTISE: AS1 to AS3 TCA_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, TCA parameters
may be advertised from one to the other. may be advertised from one to the other.
8. Acknowledgements 8. IANA Considerations
Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and
Alvaro Retana for their suggestions and to Christian Jacquenet, Ken
Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand
Duvivier, Bruno Decraene for the review.
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, divided into two pools.One pool This is a registry of 1 octet value, divided into two pools.One pool
of numbers to be assigned on a standards action/early allocation of numbers to be assigned on a standards action/early allocation
basis. The initial assignments are as shown below. The other pool basis. The initial assignments are as shown below. The other pool
is for the private use,available range for which is as shown below. 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 TCA 0x01
Reserved 0x02-0xf0 (Standards Action) Reserved 0x02-0xf0 (Standards Action)
Private use 0xf1-0xff Private use 0xf1-0xff
IANA is requested to create a registry for QoS Attribute SLA SubType IANA is requested to create a registry for QoS Attribute TCA Event
flags. This is registry for 8-bits. The initial assignments are as
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. 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 One pool of numbers to be assigned on a standards action/early
allocation basis. One pool of numbers to be assigned on a standards allocation basis. One pool of numbers to be assigned on a standards
action/early allocation basis. The initial assignments are as shown action/early allocation basis. The initial assignments are as shown
below. The other pool is for the private use, available range for below. The other pool is for the private use, available range for
which is as shown below. which is as shown below.
QoS Attribute SLA Event Types QoS Attribute TCA Event Types
============================= =============================
Reserved 0x0 Reserved 0x0
ADVERTISE 0x1 ADVERTISE 0x1
Reserved 0x2 - 0xc (Standards Action) Reserved 0x2 - 0xc (Standards Action)
Private use 0xd - 0xf Private use 0xd - 0xf
IANA is requested to create a registry to define QoS Attribute SLA IANA is requested to create a registry to define QoS Attribute TCA
Direction. This is the direction in forwarding path, advertised QoS Direction. This is the direction in forwarding path, advertised QoS
SLA is applicable to. This is a 2-bit registry. Values for QoS TCA is applicable to. This is a 2-bit registry. Values for QoS
Attribute SLA direction are: Attribute TCA direction are:
QoS Attribute SLA Direction QoS Attribute TCA 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 Attribute SLA Traffic Class Element Types will be referring to QoS Attribute TCA Traffic Class Element Types will be referring to
existing IPFIX IANA types as listed in Table 1. While IPFIX registry 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 is maintained by IANA out of scope of this specification, the use of
IPFIX identifiers for this specification are limited to what is IPFIX identifiers for this specification are limited to what is
described in Table 1. Any new addition of IPFIX identifiers to this described in Table 1. Any new addition of IPFIX identifiers to this
table should be a Standards Action. table should be a Standards Action.
IANA is requested to create a registry for QoS Attribute SLA Traffic IANA is requested to create a registry for QoS Attribute TCA Traffic
Class Service Types. This is a registry of 2 octet values, to be Class Service Types. This is a registry of 2 octet values, to be
assigned 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 COMMITTED_TSPEC 0x01
L2_OVERHEAD 0x02 PEAK_TSPEC 0x02
MINRATE_IN_PROFILE_MARKING 0x03 COMMITTED_IN_PROFILE_MARKING 0x03
MINRATE_OUT_PROFILE_MARKING 0x04 COMMITTED_OUT_PROFILE_MARKING 0x04
MAXRATE_IN_PROFILE_MARKING 0x05 PEAK_OUT_PROFILE_MARKING 0x05
MAXRATE_OUT_PROFILE_MARKING 0x06 DROP_THRESHOLD 0x06
DROP_THRESHOLD 0x07 RELATIVE_PRIORITY 0x07
RELATIVE_PRIORITY 0x08 EFFECTIVE_MAX_RATE 0x08
SUB_TRAFFIC_CLASSES 0x09 SUB_TRAFFIC_CLASSES 0x09
Standards Action 0x0A - 0x3FFF Standards Action 0x0A - 0x3FFF
FCFS 0x4000 - 0x4FF0 FCFS 0x4000 - 0x4FF0
10. Security Considerations 9. Security Considerations
BGP security vulnerabilities analysis is documented in [RFC4272] BGP security vulnerabilities analysis is documented in [RFC4272],
while BGP-related security considerations are discussed in [RFC4271]. while BGP-related security considerations are discussed in [RFC4271].
Also, the reader may refer to [RFC7132] for more details about BGP Also, the reader may refer to [RFC7132] for more details about BGP
path threat model. Rest of the content in this section discusses path threat model. Means to prevent route hijacking SHOULD be
additional privacy and security considerations that are applicable to enabled. Such means include RPKI based origin validation [RFC7115]
the attribute defined in this document. and BGP Path validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]).
Rest of the content in this section discusses additional privacy and
security considerations that are applicable to the attribute defined
in this document.
The information conveyed in the QoS Attribute SLA SubType reveals The information conveyed in the QoS Attribute TCA SubType reveals
sensitive data that should not be exposed publicly to non-authorized sensitive data that should not be exposed publicly to non-authorized
parties. Deployment considerations mainly target use of QoS parties. Deployment considerations mainly target use of QoS
Attribute and SLA SubType in managed networks and those where a trust Attribute and TCA SubType in managed networks and those where a trust
relationship is in place (Customer to Provider, or Provider to relationship is in place (Customer to Provider, or Provider to
Provider). It is NOT RECOMMENDED to enable this attribute at the Provider). Administrators MUST disable this attribute to be sent to
scale of the Internet unless if means to prevent leaking sensitive a remote peer which whom no trust relationship is in place. Both TCA
information are enforced. Producer and Consumer SHOULD NOT publish valid TCA IDs to non-
authorized nodes.
The attribute may be advertised by a misbehaving node to communicate The attribute may be advertised by a misbehaving node to communicate
SLA parameters that are not aligned with the SLA agreements. Though TCA parameters that are not aligned with the TCA agreements. The
the enforcement of SLA parameters is outside the scope of this enforcement of TCA parameters is outside the scope of this document.
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 like 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 The attribute defined in this document may be used by a misbehaving
include RPKI based origin validation [RFC7115] and BGP Path node for denial-of-service (e.g., inadequately rate-limit or drop
validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). some critical traffic). As a mitigation, a BGP peer MUST accept this
attribute only from trusted BGP peers. For example, ACLs may be
configured to identify the trusted ASes that are allowed to send the
attribute. Further, administrators of a TCA Consumer's domain are
RECOMMENDED to generate TCA ID using pseudo-random schemes [RFC4086].
Using robust TCA IDs make it hard to guess a valid TCA.
10. Acknowledgements
Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and
Alvaro Retana for their suggestions and to Christian Jacquenet, Ken
Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand
Duvivier, Bruno Decraene, David Black, and Ron Bonica for the review.
11. References 11. References
11.1. Normative 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>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
DOI 10.17487/RFC2434, October 1998,
<http://www.rfc-editor.org/info/rfc2434>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-22 (work Specification", draft-ietf-sidr-bgpsec-protocol-22 (work
in progress), January 2017. in progress), January 2017.
[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, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[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>.
[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>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
<http://www.rfc-editor.org/info/rfc7297>. <http://www.rfc-editor.org/info/rfc7297>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
Extended Community", RFC 7674, DOI 10.17487/RFC7674, Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <http://www.rfc-editor.org/info/rfc7674>. October 2015, <http://www.rfc-editor.org/info/rfc7674>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
Authors' Addresses Authors' Addresses
Shitanshu Shah Shitanshu Shah
Email: shitanshu_shah@hotmail.com Email: shitanshu_shah@hotmail.com
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
Email: keyur@arrcus.com Email: keyur@arrcus.com
skipping to change at page 30, line 29 skipping to change at page 32, line 4
Authors' Addresses Authors' Addresses
Shitanshu Shah Shitanshu Shah
Email: shitanshu_shah@hotmail.com Email: shitanshu_shah@hotmail.com
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
Email: keyur@arrcus.com Email: keyur@arrcus.com
Sandeep Bajaj Sandeep Bajaj
Viptela Viptela
Luis Tomotaki Luis Tomotaki
Verizon Verizon
400 International 400 International
Richardson, TX 75081 Richardson, TX 75081
US US
Email: luis.tomotaki@verizon.com Email: luis.tomotaki@verizon.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes Rennes
35000 35000
France France
 End of changes. 211 change blocks. 
589 lines changed or deleted 659 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/