Network Working Group                                            S. Shah
Internet-Draft                                                  K. Patel
Intended status: Standards Track                           Cisco Systems
Expires: October 28, 2015 May 4, 2016                                            S. Bajaj
                                                        Juniper Networks
                                                             L. Tomotaki
                                                            M. Boucadair
                                                          France Telecom
                                                            Apr 26,
                                                       November 01, 2015

                       Inter-domain SLA Exchange


   Network administrators typically enforce Quality of Service (QoS)
   policies according to Service Level Agreement (SLA) with their
   providers.  The enforcement of such policies often relies upon
   vendor-specific configuration language.  Both learning of SLA, either
   thru SLA documents or via some other out-of-band method, and
   translating them to vendor specific configuration language is a
   complex, many times manual, process and prone to errors.  This
   document proposes an in-band method of SLA signaling signaling, which can help
   to simplify some of the complexities. complexities, where BGP is available as the
   routing protocol.

   This document defines an optional transitive attribute to signal SLA
   parameters in-band, across administrative boundaries (considered as
   Autonomous Systems (AS)), thus simplifying and facilitating some of
   the complex provisioning tasks.

   Though the use case with the proposed BGP attribute is explicitly
   defined in this document, purpose of this attribute is not limited to
   this use case only.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on October 28, 2015. May 4, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5   4
   3.  QoS Attribute Definition  . . . . . . . . . . . . . . . . . . .  5   4
     3.1.  SLA, QoS attribute sub-type, Definition . . . . . . . . .  6   5
   4.  Originating SLA Notification  . . . . . . . . . . . . . . . . . 16  15
     4.1.  SLA Contexts  . . . . . . . . . . . . . . . . . . . . . . . 16  15
       4.1.1.  SLA Advertisement for Point-to-Point Connection . . .  16
       4.1.2.  SLA Advertisement for Destination AS Multiple Hops
               Away  . . . . . . . . . . . . . . . . . . . . . . . . . 17  16
   5.  SLA Attribute Handling at Forwarding Nodes  . . . . . . . . . . 17  16
     5.1.  BGP Node Capable of Processing QoS Attribute  . . . . . . . 17  16
     5.2.  BGP Node not Capable of Processing QoS  SLA Attribute . . . . . 18
     5.3.  Aggregator . . . . Handling at Receiver  . . . . . . . . . . .  17
   6.  Error Handling  . . . . . . . . . 18
   6.  SLA Attribute Handling at Receiver . . . . . . . . . . . . . .  18
   7.  Traffic Class Mapping . . . . . . . . . . . . . . . . . . 19
   7. . .  18
   8.  Deployment Considerations . . . . . . . . . . . . . . . . . . 20
   8.  18
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
   10.  20
   11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
   11.  21
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     11.1.  21
     12.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2.  21
     12.2.  Informative References . . . . . . . . . . . . . . . . . . 23  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   Typically there is a contractual Service Level Agreement (SLA) for
   QoS established between Customer a customer and Provider a provider or between providers,
   possibly using one or the other form of the template [CPP].
   providers.  This
   contractual agreement usually QoS SLA defines the nature of the various traffic
   classes (i.e., traffic match conditions) and services needed
   for within each traffic class.  The contract
   may exist at different levels
   of traffic granularity.  The contract could be for the include full line-rate or sub line-rate without granular additional
   traffic distinction classes, or it could be may contain additional traffic classes and
   service definitions for finer granular those traffic classes, with services defined. classes.  Finer granular
   traffic classes can may be based on some standard code-points code points (like DSCP)
   or for a specific set of prefixes or for a set of well-known
   application types. prefixes.

   Once the SLA is established, QoS SLA parameters are enforced in some
   or all participating devices by deriving SLA those parameters into
   configuration information on respective devices.  SLA parameters may
   have to be exchanged through organizational boundaries, thru SLA
   documents or via some other off-band method to an administrator
   provisioning actual devices.  In a subsequent step, administrator
   requires to translate SLA to QoS policies using router (vendor)
   specific provisioning language.  In a multi-vendor network,
   translating SLAs into technology-specific and vendor-specific
   configuration requires to consider specificities of each vendor.
   There does not exist any standard protocol to translate SLA
   agreements into technical clauses and configurations and thus both
   the steps of out of band learning of negotiated SLA and provisioning
   them in a vendor specific language can be complex and error-prone.
   As an example for voice service, the Provider may negotiate QoS
   parameters (like min/max rates) for such traffic based upon the EF
   code-point in Diffserv-enabled [RFC2475] networks.  The Administrator
   at the CE side not only will have to know that Provider's service for
   voice traffic is EF-based, so that traffic exiting CE is marked
   properly, EF-based but will also have to know how to implement
   DSCP EF classification rule along with Low Latency Service, and
   possibly min/
   max min/max rate enforcement for the optimal use of bandwidth,
   as per vendor specific provisioning language.

   An in-band signaling method of propagating SLA parameters from the
   provider, PE in an example above, to contractual devices, CE in an
   example above, can help eliminate manual administrative process
   described above.  Provider  The provider may have SLA negotiated with the
   Customer via some defined off-band method (based on the specifics
   defined by the Provider or using protocols like [CPNP]. [CPNP]).  The Inter-domain Inter-
   domain SLA exchange proposal described in this document does not pre-requisite pre-
   requisite any specific method of establishing SLAs).  The Provider
   provisions established SLA on the Provider device.  This SLA instance
   then can be signaled to the Customer via in-band signaling protocol.
   In reaction to this signal, receiver router may translate that to
   relevant QoS policy definition on the device.

   For an in-band signaling, we propose to use BGP as a transport.  The
   details of SLA parameters are specific to the granularity of traffic
   classes and their respective treatment, which is independent of the
   BGP protocol itself.  Though we find BGP as a suitable transport for
   inter-domain SLA exchange for the following reasons:

        - The need to exchange SLA parameters between domains (Automated domains(Autonomous
          Systems (AS)), where in use-cases described in this document,
          BGP is a suitable protocol for inter-domain exchange [RFC4271]
        - There is no specifically defined protocol available today for
          SLA exchange exchange.
        - BGP updates already advertise specific set of prefixes (flow
          or flow-group). Other QoS-related attributes, apart from the
          the use of SLA advertisement, can be added to these updates
          in the future future.

   The proposal is to define a new BGP attribute to advertise/learn SLA
   details in-band.  The proposed attribute is intended to advertise SLA
   from one AS to a list of destined ASes.  The advertised QoS
   information could be for the incoming traffic to the advertiser, that
   is advertising SLA or could be for the outgoing traffic from the
   advertiser or could be for both directions.  Reception of and
   reaction to advertised SLAs are optional for the receiver.

   We propose QoS as an optional transitive attribute, keeping SLA
   advertisement and discovery (request) as one of the sub-types of QoS attribute.  This is to
   keep the QoS attribute open for extensions.  For example, SLA
   Negotiation and Assurance is out of scope of this document but can be
   envisioned as another sub-type.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  QoS Attribute Definition

   The QoS Attribute proposed here is an optional transitive attribute
   (attribute type code to be assigned by IANA).  SLA is defined as one
   of the sub-types in the QoS attribute.  The QoS attribute is only
   applicable to the NLRI advertised in the BGP update message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |   Attr flag   | Attr type QoS |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       ~                                                               ~
       |                     QoS Attr length/Value                     |

    Attribute flags
        highest order bit (bit 0) -
            MUST be set to 1, since this is an optional attribute

        2nd higher order bit (bit 1) -
            MUST be set to 1, since this is a transitive attribute

3.1.  SLA, QoS attribute sub-type, Definition

   The value field of the QoS Attribute contains TLVs, followed to QoS
   Attribute flags described in the previous section.  One of the TLVs
   that we define is a tuple of (SLA sub-type, Length, Value) Value).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       | QoS Attr flags|      subType  |         sub type         subtype Length        |
       ~                                                               ~
       |                               Value                           |

    QoS Attr flags
        8-bit = 0000-0000, All the bits are currently un-used. The first octet in space
                is made available for the Value field purpose of the QoS attribute is QoS
    attribute specific flags

        highest order bit (bit 0) -
            It defines if update message future use. For now
                they all MUST be dropped (if set to 1)
            without updating routing information base, 0 when this is the
            last BGP receiver from the list of destination ASes this QoS attribute is announced to, or MUST announce (if set to 0)
            further to BGP peers

            The purpose of this bit is discussed further added in subsequent

        Remaining bits are currently unused
                the BGP update message and MUST be set to 0 ignored when received

    subType - 8 bits
        0x00        = reserved
        0x01        = SLA
        0x02 - 0x0f = for future use

    subType Length
        Length of the content to follow pertaining to specified

    Value for the SLA sub-type specific value field details. is as described below. These details
    contain information about 1) sender and receiver(s) and 2) SLA
    parameters. SLA Parameters include SLA event type (such as Advertise, Request)
    Advertise) and contents associated to that event type.

    The format of SLA message is,

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |                    32-bit source Source AS (Advertiser)              |
       |Optional advertiserid total len|      Advertiser id TLVs       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
       |                                                               |
       ~                                                               ~
       |                                                               |
       |                  32-bit destination Destination AS count                  |
       |                variable list of destination AS                |
       ~                            ....                               ~
       |                            ....                               |
       | Event |             SLA id            |      SLA length       |
       |                    Content as per SLA Event                   |
       ~                                                               ~
       |                                                               |

    Source AS
        32-bit source AS number. This is the AS that is advertising SLA
        0 = ignore Source and Destination AS list from this Value field.
            Instead refer to Source and Destination field

            Note that AS as defined by BGP

    Optional advertiser id total len
        16-bit Source address identifier (optional).
        0 = No optional identifier

        In general any additional qualifier for an advertiser is not
        required. The SLA definition is 0, used in the context message outside of prefix
        advertised in the NLRI definition. The exception QoS attribute,
            is where a BGP
        speaker, illegal in the middle of an update path to the destination AS,
        aggregates prefixes. We will refer this middle normal BGP speaker, that
        aggregates routes, operations. AS = 0 inside the QoS
            attribute may be used simply as an Aggregator. Aggregator is then required a flag to insert original NLRI details in the optional advertiser field

    Optional Advertiser id TLV
        4-bit type
        0x0  = reserved
        0x1  = ORIGIN_NLRI, variable length
        0x2 tell receiver to 0xf = for future use,
            ignore Source and Destination AS list from inside the QoS

    Destination AS count
        32-bit destination AS count to take variable length AS list.
        This count has no functional value when Source AS is 0 0.

        0 = QoS attribute is relevant to every receiver of the message

    Destination AS list
        32-bit destination AS number
        .... [as many as AS count]

    SLA Event Type
        0x0 = reserved
        0x1 = ADVERTISE
        0x2 = REQUEST
        0x3 to 0xf, for future use

    SLA Id
        16-bit identifier unique within the scope of source AS

        The significance of an SLA identifier is in the context of the
        source that is advertising SLA parameters. The SLA identifier
        is not globally unique but it MUST be unique within the source
        AS (advertiser).

        If advertised SLA id is different from earlier advertised one,
        for the same prefix, previous SLA content MUST be replaced
        with the new advertised one.

        SLA is aggregate for all the traffic to prefixes for a given
        AFI/SAFI that share same source AS and SLA id.

    SLA Length
        12-bits - Total length of the SLA content to follow

    Content as per SLA event

        The SLA content is optional for an advertised SLA id. The
        value of the SLA length field in such case would be 0. If SLA
        content does not exist in BGP update messages with advertised
        QoS attribute, that contains the SLA sub-type, then receiver
        MUST inherit prior advertised SLA content for the same SLA id
        from the same Source AS. If advertised there does not exist any prior SLA id is different from earlier
        to relate to the advertised one,
        for SLA id, then receiver can ignore
        the same prefix, previous SLA content MUST be replaced advertisement and continue with the new advertised one.

        SLA is aggregate for all rest of the traffic to prefixes that share
        same source AS BGP
        message processing and SLA id.

    SLA Length
        12-bits forwarding rules. Note that such
        condition MUST not discard the attribute. All defined
        forwarding rules for this attribute still MUST apply.

      The only event prescribed in this document is ADVERTISE.
      The format of SLA ADVERTISE event message is,
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |dir|       Traffic Class count     | Class Desc Len|           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           ~
       |                                                               |
       ~                  Traffic Class Description                    ~
       |                                                               |
       | Elements Count|                                               |
       +-+-+-+-+-+-+-+-+                                               ~
       |                                                               |
       ~              Traffic Class Elements count/values TLVs                      ~
       |                                                               |
       | Service  Count|      service type/value pair                                               |
       +-+-+-+-+-+-+-+-+                                               ~
       |               Traffic Class Service TLVs                      |
       ~                                                               ~
       |                                                               |
       |                                                               |
       ~  Repeat from Traffic Class Description for next Traffic Class ~
       |                                                               |
       |                                                               |
       ~    Repeat from direction for SLA in the other direction       ~
       |                                                               |


    dir (Direction)
        02-bit for incoming traffic to source AS or outgoing traffic, traffic
                   from source AS,
        0x0 = reserved
        0x1 = incoming, to source AS from destination AS towards source AS
        0x2 = outgoing, from source AS towards destination AS
        0x3 = for future use

    Traffic Class count (Classifier Groups count)
        16-bit, count of number of classifier groups
        00 = Advertisement to invalidate previous advertised SLA if any

    Traffic Class Descr Length
        08-bit, size length of the length description

        0 = No description

    Traffic Class Description
        Description of the Traffic Class in UTF-8 encoding

    Traffic Class Elements Count in a Traffic Class,

        08-bit count of classifier elements in a specific Traffic Class

        00 = this has relative definition. It means classify rest all
             traffic that is not classified via earlier described
             Traffic Classes.
             It is RECOMMENDED that Traffic Class, Class that has 0 elements, elements
             is present last in the advertised list of Traffic Classes.
             If Advertised message has it positioned some-where somewhere else,
             then receiver MUST re-order it, for the forwarding purpose,
             to the last position in the advertised list of Traffic
             Classes from a given source AS. QoS attribute advertised
             from a specific source MUST NOT have more than one such
             Traffic Classes (Traffic Class with 0 element elements count). If
             there are more than one such Traffic Classes present then
             advertised SLA parameters MUST be ignored. It
             it is okay
             though to have none Traffic Class with element count 0. an error condition which should follow handling of
             such BGP message as described in Error handling section.

    Classifier Element values in a Traffic Class (optional),

        08-bit                = IPFIX Element Identifier
        08-bit                = based on type size, in octets, of the Element value field
        variable-length field = contains actual value

        Given IPFIX [RFC5102] has well defined identifier set for a
        large number of packet attributes, IPFIX IANA registry is
        ("") chosen to specify
        packet classification attributes. However, since not all
        identifiers from IPFIX would be applicable to this proposal,
        only a limited set identified here can be supported by BGP
        SLA exchange. Any new element identifier, in future, the future added
        to the IPFIX IANA registry does registry, is not automatically mean supported
        for this proposal. Only the IPFIX elements indicated in this
        document below remain supported.

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |
       |  8 | sourceIPv4Address          |
       | 27 | sourceIPv6Address          |
       |  9 | sourceIPv4PrefixLength     |
       | 29 | sourceIPv6PrefixLength     |
       | 44 | sourceIPv4Prefix           |
       |170 | sourceIPv6Prefix           |
       | 12 | destinationIPv4Address     |
       | 28 | destinationIPv6Address     |
       | 13 | destinationIPv4PrefixLength|
       | 30 | destinationIPv6PrefixLength|
       | 45 | destinationIPv4Prefix      |
       |169 | destinationIPv6Prefix      |
       |  4 | protocolIdentifier         |
       |  7 | sourceTransportPort        |
       | 11 | destinationTransportPort   |

       Any traffic classifier element advertised in the QoS attribute
       is only applicable to the NLRI advertised for a given AFI/SAFI
       within the BGP update message. If a receiver receives a BGP
       update message with QoS/SLA attribute for an NLRI that is not
       supported by a receiver then receiver MUST not install an
       advertised SLA and continue to forward this attribute further
       if it is not the last receiver of an attribute.

    Traffic Class Service count (for a Traffic Class under definition)
        08-bit count of service attributes fields to follow with
               type/value pair
        List of service types and relevant values are discussed below

        00 = no bounded service (also means Best Effort)

    Traffic Class Service (optional),
        16-bit                = type Traffic Class Service Type
        08-bit                = size, in octets, of the value field
        variable-length field = based on type of the service contains actual value

    - 0x00 = reserved

      160-bits TSpec Parameter
      The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p),
      (m) and (M) parameters as described in Invocation Information
      section of [RFC2212]. Note that inheriting the definition of
      TSpec here does not enable RFC2212 functionality. It purely is Only the
      values of the Traffic Specification that is inherited here for the purpose of
      SLA exchange. are used in this

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |  Minimum Rate (r) (32-bit IEEE floating point number)         |
       |  Burst Size (b) (32-bit IEEE floating point number)           |
       |  Maximum Rate (p) (32-bit IEEE floating point number)         |
       |  Minimum Policed Unit (m) (32-bit integer)                    |
       |  Maximum Packet Size (M)  (32-bit integer)                    |

      Parameter (r) indicates min-rate of the traffic class. This rate
      indicates the minimum rate, measured in bytes octets of Layer 2 (L2)
      datagrams per second, that the service advertiser is providing
      for a given class of traffic on advertiser's hop. Note that it
      does not necessarily translate to a minimum rate service to the
      receiver of an SLA unless the traffic class definition clearly
      represents a sole receiver of an SLA. If there is no SLA for
      min-rate, the value of (r) MUST be set to 0.

      Parameter (b) indicates maximum burst size, measured in bytes octets of
      L2 datagram size. Since queuing delay can be considered a
      function of burst size (b) and min-rate (r), in presence of non-
      zero parameter (r), parameter (b) represents bounded delay for
      the Traffic Class. This delay is a single hop queuing delay when
      SLA is to be implemented at the resource constrained bottleneck.
      In other words this burst size can be considered as a buffer
      size. Value of 0 for parameter (b) means the advertiser does not
      mandate specific bounded delay.

      Parameter (p) indicates max-rate of the traffic class. Just like
      min-rate, max-rate, measured in bytes octets of L2 packets per second,
      field here also indicates service provided by advertiser. If
      advertiser does not have any specific value to set for a given
      class of traffic, it MAY be set to physical interface line rate
      or any other indirect limit that may affect this class' maximum
      rate. In absence of any such known value, it MUST be set to
      positive infinity. Value 0 is considered an error.

      Parameters (r), (b) and (p) are each set as 32-bit IEEE floating
      point numbers. Positive infinity is represented as an IEEE single
      precision floating-point number with an exponent of all ones and
      a sign mantissa of all zeros.  The format of IEEE floating-point
      numbers is further summarized in [RFC4506].

      The minimum policed unit (m) and maximum packet size (M)
      parameters have no relevance for the purpose of SLA exchange.
      Thus they MUST be ignored.

    - 0x02, L2_OVERHEAD
      08-bit, value

      By default specification of rate and other packet size related
      parameters, advertised in an SLA, includes L2 overhead. For the
      receiver next hop, this hop,this overhead is the L2 overhead of the local
      link where advertised SLA is received. However, in cases where
      advertised SLA is for a receiver multiple hops away, L2 overhead
      consideration from the source perspective may be different from
      the local L2 overhead at the receiver. Explicit notification of
      size of L2 overhead from a sender, in such cases, is useful for
      a receiver to distinguish local L2 overhead from the sender
      advertised one. When receiver choose to react to an advertised
      SLA and if this service type is present in advertised SLA,
      receiver MUST use advertised L2 overhead over local L2 overhead.

      If SLA is required to consider only IP packet size, sender may
      advertise this service with a value of 0.

      08-bit                = IPFIX Element Identifier
      08-bit                = based on type size, in octets, of the Element value field
      variable-length field = contains actual value

      00 Identifier = drop, variable-length for this id is 0.

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |

      08-bit                = IPFIX Element Identifier
      08-bit                = based on type size, in octets, of the Element value field
      variable-length field = contains actual value

      00 Identifier = drop, variable-length for this id is 0.

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |

      08-bit                = IPFIX Element Identifier
      08-bit                = based on type size, in octets, of the Element value field
      variable-length field = contains actual value

      00 Identifier = drop, variable-length for this id is 0.

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |

      08-bit                = IPFIX Element Identifier
      08-bit                = based on type size, in octets, of the Element value field
      variable-length field = contains actual value

      00 Identifier = drop, variable-length for this id is 0.

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |

      In the case when MINRATE_IN_PROFILE_MARKING,
      MAXRATE_OUT_PROFILE_MARKING all of them are all advertised,
          - MINRATE_IN_PROFILE_MARKING takes highest precedence
            (that is over MAXRATE_IN_PROFILE_MARKING)

          - MAXRATE_IN_PROFILE_MARKING takes precedence over

          - and MAXRATE_OUT_PROFILE_MARKING takes precedence over

    - 0x07  = DROP_THRESHOLD
      03-bit count of drop-priority fields to follow with
               (type, type-value, burst size) tuple

      04-bit, drop priority type
        08-bit                = IPFIX Element Identifier
        08-bit                = based on type size, in octets, of the Element
        32-bit, value field
        variable-length field = contains actual value
        32-bit                = Burst Size
                                (32-bit IEEE floating point number)

       | ID | Name                       |
       |195 | ipDiffServCodePoint        |
       |203 | mplsTopLabelExp            |
       |244 | dot1qPriority              |

      This finer granular drop threshold does not require separate
      buffer space from the aggregate buffer space. It is just an
      indicator beyond which code-point specific traffic to be
      discarded when occupancy of aggregate buffers reached to that

      04-bit, priority value
              lower the value, higher the priority

      Relative priority indicates scheduling priority. For example
      voice traffic, which requires lowest latency compare compared to any
      other traffic, may have lowest value advertised in relative
      priority. For two different traffic classification groups
      where one application group may be considered more important
      than the other but from a scheduling perspective does not
      require to be distinguished with a different priority, relative
      priority for those classification groups may be advertised with
      the same value.

      variable-length, repeats all content described above from Traffic
                       Class count onwards.

      For SLAs where a specific Traffic Class may further have
      different sub-services for a sub-group of Classifier Elements,
      this service type SHOULD be used to further divide Traffic Class
      in multiple sub-classes. Each sub-class is then defined with
      their own classifier elements and service types.

4.  Originating SLA Notification

   The QoS attribute to advertise SLA sub-type MUST only be added by the originator of a and MUST NOT
   be added during BGP UPDATE message. propagation.

   SLA messages SHOULD NOT be sent periodically just for the purpose of
   keep alive.  Some sort of SLA policy change may be considered as a
   trigger for the advertisement.

   For any modified SLA parameters, the originator MUST re-advertise the
   entire set of SLA parameters.  There is no provision to advertise
   partial set of parameters.  To invalidate previously advertised SLA
   parameters, a message MUST be sent with the same SLA id for the same
   source with the Traffic Class count set to 0.

4.1.  SLA Contexts

   In certain cases, the advertisement may relate to an SLA for
   aggregate traffic over a point-to-point connection between a specific
   destination and a specific source.  A point-to-point connection may
   be the physical link, that connects two BGP peers, or may be a
   virtual link (e.g. a tunnel).  A BGP update message, in such cases,
   with source AS number and NLRI prefix of source end-point can
   uniquely identify physical/virtual link and so establishes advertised
   SLA's context for that point to point link.

   In the simplest case where Provider (e.g.  PE) and Customer (e.g.
   CE) devices are directly connected via a physical link and have only
   a single link between them, CE can uniquely identify the forwarding
   link to PE with AS number of the PE and NLRI prefix being an IP
   address of PE, to CE (that is the next hop address from CE to PE).
   SLA advertised thru BGP update message from PE to CE, with PE's AS
   number and IP address, establishes SLA context for the aggregate
   traffic through link CE to PE.  SLA advertised thru BGP update
   message from PE to CE, with PE's AS number and any other prefix
   establishes SLA for that specific prefix, subset of traffic under CE
   to PE link.

   Even though this example is in the context of IP prefixes, SLA
   exchange does not have to be limited to the IP address family only. (IPv4
   and IPv6).  SLA advertisement is generic to all forms of NLRI types
   that are supported by the BGP protocol specification (like IPv4,
   IPv6, VPN-
   IPv4, VPN-IPv4, VPN-IPv6).

4.1.1.  SLA Advertisement for Point-to-Point Connection

   When SLA messages are intended to be advertised for the point-to-
   point connection (physical or logical), the message is destined for
   the next hop and advertised message is in the context of the prefix
   of the source end-point of the point to point connection.

   The destination AS number set to, within QoS SLA attribute, typically
   is of the neighbor BGP speaker's.  Alternatively, the originator MAY
   not encode source/destination AS numbers (that is the source AS is
   set to 0 and
   destination AS count is set to 0), in the QoS attribute.
   The most significant bit of the QoS attribute flag MAY be set to 1,
   specifically it MUST be set to 1 when intention is to not install
   route update, at the receiver, for the advertised message. 0.

4.1.2.  SLA Advertisement for Destination AS Multiple Hops Away

   When SLA messages are to be advertised beyond next hop, value of
   source AS, in the QoS attribute, MUST be set by the originator of the
   update message.  If such an update is meant to be for a specific list
   of AS(es) as receivers, then the list of destination AS MUST be
   explicitly described in the QoS attribute message to avoid flooding
   of the QoS attribute data in the network beyond those destinations.

   When a new prefix is added in the AS, AS for which SLA parameters
   have already been advertised before for other existing prefixes, and
   if traffic to this new prefix is subject to the same SLA advertised
   earlier then BGP update for this new prefix may include QoS attribute
   containing just an SLA id, an id that was advertised earlier.  The
   corresponding Update message does not require to have the whole SLA
   content.  SLA id is sufficient to relate SLA parameters to new
   advertised prefix.

   When BGP update messages are triggered as a result of SLA policy
   change and thus only for the purpose of SLA exchange, forwarding BGP
   update messages beyond intended receivers are not necessary.  Highest
   order bit in the QoS Attribute flag MUST be set to suggest receiver
   to drop entire BGP update message [Note that it is an indication to
   drop entire update message, not only QoS attribute], after all
   intended receivers have processed it.  If update message contains a
   list of destination ASes, then the message MUST be dropped only after
   all intended receivers (destinations)  The
   corresponding Update message does not require to have received it. the whole SLA
   content.  SLA id is sufficient to relate SLA parameters to new
   advertised prefix.

5.  SLA Attribute Handling at Forwarding Nodes

5.1.  BGP Node Capable of Processing QoS Attribute

   If a BGP node is capable of processing QoS attribute, it optionally
   MAY process the message. QoS attribute.  If advertised SLA has a list of
   destination ASes, it MAY trim the list and so count of destination AS
   to exclude ones that are not required in further announcement of BGP

   BGP node MUST drop SLA related sub-type from the QoS attribute, if
   none of the
   there is no more AS from the destination list is in the forwarding path.
   The rest of the QoS attribute contents MAY be forwarded if there
   exist other sub-types of QoS attribute and forwarding rules meets
   other sub-types requirements.  If there is no other sub-types in the
   QoS attribute content then the node MUST drop the entire QoS
   attribute all together.  The other attributes and NLRI information
   may be announced further if they meet rules defined by other
   attributes and BGP protocol.

   If the most significant bit in the QoS attribute flag is set to 1
   then the entire BGP update message MUST be dropped if there are no
   destinations left in the list to advertise to.

   Except extracting the entire SLA sub-type of the QoS attribute and
   trimming the list of destination AS list and inserting NLRI at the
   Aggregator node, list, all other content MUST NOT
   be modified by any intermediate receivers of the message.

5.2.  BGP Node not Capable of Processing QoS Attribute

   If the BGP node is not capable of processing QoS attribute, it MUST
   forward the QoS attribute message unaltered.

5.3.  Aggregator

   It is RECOMMENDED to not aggregate prefixes from 2 or more BGP update
   messages into one BGP update, when original messages contain the QoS
   attribute with SLA sub-type contents.  If Aggregator MUST aggregate
   them then it MUST copy entire parameter set of an SLA sub-type from
   the QoS attribute in the new aggregated BGP update message.  At the
   same time, it MUST also insert NLRI information, from the original
   update message, as an optional advertiser id to go along with source
   AS inside the QoS attribute.

   To support SLA exchange multiple hops away in the path that has one
   of the forwarding node acting as an Aggregator, it is required that
   the Aggregator node is capable of processing the QoS attribute.

6.  SLA Attribute Handling at Receiver

   Reception of and processing of advertised QoS SLA content are
   optional for the receiver.

      While reacting to SLA advertisement
      - receiver SHOULD invalidate previous advertised SLA parameters if
        one exists for the same SLA id and source AS. If the new
        advertised SLA update is with has a non-zero Traffic Class traffic count, then the new
        advertised SLA SHOULD be installed. If new advertised SLA update
        is with Traffic Class count 0, then no action is required.

      - If advertised QoS Attribute, inside an When BGP update message, is with messages are triggered only as a result of SLA
        policy change, BGP update message forwarding beyond intended
        receivers are not necessary. If receiver device implementation
        supports policy based filtering then receiver MAY implement a
        flag set indicating
        policy to drop that message, a receiver MUST drop
        message if it is the last receiver, in update path, that message
        is advertised to. filter such messages based on prefix and attribute.

   If the advertised SLA is from advertised to the next hop, in the reverse path, hop neighbor, the receiver may
   implement advertised SLA for the whole link, where the link could be
   physical or virtual link, associated with connected to the next hop. neighbor.  If
   advertised in update message to is not of the next hop, hop neighbor then receiver may
   establish advertised SLA for that specific prefix list under the
   relevant link.  It is completely up to the receiver to decide for
   which prefixes it should accept advertised SLA and for which ones it

   For cases where if earlier messages have not reached the intended
   receiver yet, a re-signaling is required.  A receiver may intend to
   request an SLA message from the originator in such case.  Since BGP
   messages are considered reliable, it is assumed that advertised
   messages always reach intended receivers.  Thus discussion of REQUEST
   message, for this purpose or any other purpose, is considered out of
   the scope of this document.

   To handle error

6.  Error Handling

   Error conditions, the approach while processing of "attribute-discard" as
   mentioned in [IDR-ERR] MAY the QoS attribute, SHALL be used in
   handled with the event QOS attribute parsing
   results in any attribute errors.  Alternatively, an approach of
   "treat-as-withdraw" MAY be used attribute-discard as mentioned described in [IDR-ERR] if an
   implementation [IDR-
   ERR].  In such condition, receiver SHOULD also wishes to withdraw cleanup any previously
   installed SLA state for the associated same prefix.


7.  Traffic Class Mapping

   It is possible that switching/routing methods used in 2 different
   ASes could be different.  For example, Provider may tunnel Customer's
   IP traffic thru MPLS cloud.  In such cases traffic class definition
   for QoS services may differ in both ASes.  For the meaningful use of
   advertised SLA in such cases, receiver is required to map traffic
   class from one type to the other.

   In the example given, traffic classification in Customer AS could be
   IP Diffserv-based whereas traffic classification in Provider AS could
   be MPLS TC-based.  Thus for advertised MPLS TC-based SLA would
   require to map traffic class from IP Diffserv-based to MPLS TC type. type

   There are well-defined recommendations that exist for traffic class
   mapping between two technologies. technologies, eg.  RFC3270 for mapping between
   DSCP and MPLS TC.  Receiver MAY use those defined recommendations for
   traffic class mapping or MAY define its own as per its network
   Traffic Class service definition to map to advertised Traffic
   Classes.  It is completely up to the receiver how to define such
   traffic class mapping.


8.  Deployment Considerations

   One of the use cases is for a Provider to advertise contracted SLA
   parameters to Customer Edge (CE). (CE) in cases where eBGP is deployed
   between PE and CE.  The SLA parameters are may already be provisioned by
   the provider on the PE device (facing CE).  This provisioned SLA
   parameters are then advertised thru proposed BGP QoS attribute to the
   CE device.  CE device may read the attribute and SLA sub-type content
   to implement the QoS policy on the device.

   Contracted SLA from PE to CE may be full line-rate or sub line-rate
   or finer granular controlled services.  SLA advertise can be useful
   when contracted service is sub-rate of a link and/or when for finer
   granular traffic classes that are controlled (e.g. voice, video
   services may be capped to certain rate)
                __________         /               \
               /          \       /                 \
              /            \     /                   \
              |CustomerSite|-----|      Provider     |
              \           C/E   P\E                  /
               \__________/       \                 /
                   AS 3                   AS 2

                                  SLA_ADVERTISE: AS2 to AS3
                                                 NLRI = PE ip address

   Another use case can be to advertise SLAs among different network
   sites within one Enterprise network.  In Hub and Spoke deployments,
   Administrator, being aware of each Spoke's SLA, may define SLAs for
   each of them at the Hub and advertise them thru BGP updates, where at
   each Spoke, advertised SLA
   Administrator may translate to a forwarding policy.  In
   a scale network, managing a large number of Spokes can be complex.
   The proposal in such cases would be to provision SLA parameters at
   the Hub only and distribute them to each Spoke with SLA exchange
   protocol described here.

   Alternatively, in a network that supports define SLAs at spoke and advertise QoS SLA
   parameters signaling
   capabilities with the Provider, manual administration can be avoided
   or minimized even at to the Hub. As shown in Hub thru BGP updates.  In the figure below, AS2 may
   first learn its SLA with the Provider from the Provider Edge it is each
   spoke (AS1 and AS2) are connected to. to Hub (AS3) via a VPN tunnel.  As
   shown, AS2 can advertise the same or a subset of that SLA to AS3 in the context of tunnel's that tunnel ip

                                                       AS 2
                              _______________        ________
                             /               \      /        \
           __________       /                 \-----| Spoke2 |
          /          \     /                   \    \________/
          |    Hub   |-----|      Provider     |     ________
          \__________/     \                   /    /        \
                            \                 /-----| Spoke1 |
              AS 3           \_______________/      \________/

                                                       AS 1

                                SLA_ADVERTISE: AS2 to AS3
                                               NLRI = AS2 tunnel address

                                SLA_ADVERTISE: AS1 to AS3
                                               NLRI = AS1 tunnel address

   Deployment options are not limited to involving CEs, PE-to-CE or CE-
   to-CE, only.  For any contract between two providers, SLA parameters
   may be advertised from one to the other.


9.  Acknowledgements

   Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for
   their suggestions and to Christian Jacquenet, Ken Briley, Rahul
   Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier Duvivier,
   Bruno Decraene for the review.


10.  IANA Considerations

   The proposal in this

   This document defines a new BGP attribute. optional transitive path attribute,
   called QoS Attribute.  IANA
   maintains the list of existing BGP attribute types.  A new type action is required to be
   added allocate a new
   code-point in the list BGP path Attributes registry.

   IANA is requested to create a registry for the QoS attribute. Attribute subTypes.
   This is a registry of 1 octet value, to be assigned on a standards
   action/early allocation basis.  The proposal also defines initial assignments are:

             QoS Attribute subTypes
             - - - - - - - - - - - -
             Reserved                        0x00
             SLA                             0x01

   IANA is requested to create a list registry for Service types associated SLA Event Types.  This is
   a registry of 4-bits value, to
   Traffic Class.  IANA will be required assigned on a standards action/
   early allocation basis.  The initial assignments are:

             QoS Attribute SLA Event Types
             - - - - - - - - - - - - - - -
             Reserved                        0x00
             ADVERTISE                       0x01

   IANA is requested to maintain this list for create a registry to define QoS SLA Direction.
   This is the direction in forwarding path, advertised QoS SLA is
   applicable to.

             QoS SLA Direction
             - - - - - - - - -
             Reserved                          0x00
             to Source AS from destination AS  0x01
             from source AS to destination AS  0x02

   QoS SLA Traffic Class Service type Element Types will be referring to existing
   IPFIX IANA types as described in section 3.1.

   IANA is requested to create a new registry.  Where-as registry for QoS SLA Traffic Class
   Element types, defined in the proposal, refer to existing IPFIX IANA

         Proposed definition
   Service Types.  This is a registry of 2 octet values, to be assigned
   on a standards action/early allocation basis.  The initial
   assignments are:

             Traffic Class Service Types Type
             - - - - - - - - - - - - - -
             Reserved                        0x00 = reserved
             0x01 =
             0x02 =             0x01
             0x03 =                     0x02
             0x04 =      0x03
             0x05 =     0x04
             0x06 =      0x05
             0x07 =     0x06
             0x08 =                  0x07
             0x09 =               0x08

10.             0x09

11.  Security Considerations

   There is a potential for mis-behaved AS to advertise wrong SLA,
   stealing identity of another AS.  This resembles to problems already
   identified and resolved, in the routing world, thru reverse path
   forwarding check.  One proposal, inline to RPF, to resolve such
   threats is to have each BGP speaker node, in the forwarding path,
   perform reverse path check on source AS.  Since we expect these
   messages to originate and distributed

   The QOS attribute defined in this document SHOULD be used by the
   managed network, networks for enforcing Quality of Service Policies and so
   there should not be any risks for identity theft.  Thus reverse path check
   is not considered thefts.  To strengthen the
   security for the QOS attribute, RPKI based origin validation
   [RFC7115] MAY be used.  In addition to the RPKI based origin
   validation, BGP Path Validation [I-D.ietf-sidr-bgpsec-protocol]
   procedures could be used over BGP QOS attribute and its associated
   prefix in this proposal nor have we considered any
   alternates.  Such solutions producing the digital signature that can be explored later if carried within
   the signature SLA for the messages.  This would help prevent any such need.

11. man-
   in-the-middle attracks.

12.  References


12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,

   [RFC2212]  Shenker, S., Partridge, C., and R. Guerin, "Specification
              of Guaranteed Quality of Service", RFC 2212,
              DOI 10.17487/RFC2212, September 1997. 1997,

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Differentiated
              Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006. 2006,

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006.
              2006, <>.

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006.
              2006, <>.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, DOI 10.17487/RFC5102, January 2008,

   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
              Resource Public Key Infrastructure (RPKI)", BCP 185,
              RFC 7115, DOI 10.17487/RFC7115, January 2008.

11.2. 2014,

   [IDR-ERR]  Scudder, J., Chen, E., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Message, I-D.draft-
              ietf-idr-error-handling", June 2012.

12.2.  Informative References

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998.

   [IDR-ERR]  Scudder, J., Chen, E., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Message,
              I-D.draft-ietf-idr-error-handling", June 2012.

   [CPP] 1998,

   [RFC7297]  Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS "IP
              Connectivity Provisioning Profile, I-D.boucadair-
              connectivity-provisioning-profile", Sep 2012. Profile (CPP)", RFC 7297,
              DOI 10.17487/RFC7297, July 2014,

   [BGP-SEC]  Lepinski, M., "BGPsec Protocol Specification, I-D.draft-
              ietf-sidr-bgpsec-protocol", June 2015.

   [CPNP]     Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
              Negotiation Protocol (CPNP), I-D.boucadair-connectivity-
              provisioning-protocol", May 2013. Sep 2014.

              Shah, S. and K. Patel, "Inter-domain SLA Exchange
              Implementation Report, I-D.draft-svshah-idr-sla-exchange-
              impl", Feb 2015.

Authors' Addresses

   Shitanshu Shah
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134


   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134


   Sandeep Bajaj
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA  94089


   Luis Tomotaki
   400 International
   Richardson, TX  75081

   Mohamed Boucadair
   France Telecom
   Rennes 35000