[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

Inter-Domain Routing Working Group                             Th. Knoll
Internet-Draft                                               TU Chemnitz
Intended status: Standards Track                       November 18, 2016
Expires: May 22, 2017


                  BGP Class of Service Interconnection
                  draft-knoll-idr-cos-interconnect-17

Abstract

   This document focuses on Class of Service Interconnection at inter-
   domain interconnection points.  It specifies two new transitive
   attributes, which enable adjacent peers to signal Class of Service
   Capabilities and certain Class of Service admission control
   Parameters.  The new "CoS Capability" is deliberately kept simple and
   denotes the general EF, AF Group BE and LE forwarding support across
   the advertising AS.  The second "CoS Parameter Attribute" is of
   variable length and contains a more detailed description of available
   forwarding behaviours using the PHB id Code encoding.  Each PHB id
   Code is associated with rate and size based traffic parameters, which
   will be applied in the ingress AS Border Router for admission control
   purposes to a given forwarding behaviour.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 22, 2017.





Knoll                     Expires May 22, 2017                  [Page 1]


Internet-Draft            BGP CoS Interconnect             November 2016


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition and Usage of the CoS Capability  . . . . . . . . .   3
     2.1.  Extended Community Type . . . . . . . . . . . . . . . . .   3
     2.2.  Structure of the CoS Capability Attribute . . . . . . . .   4
     2.3.  Usage of the CoS Capability Attribute . . . . . . . . . .   6
   3.  Definition and Usage of the CoS Parameter Attribute . . . . .   6
     3.1.  Definition of the CoS Parameter Attribute . . . . . . . .   6
     3.2.  Usage of the CoS Parameter Attribute  . . . . . . . . . .   8
   4.  Confidentiality Considerations  . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   AS interconnection is currently based on best effort interconnection
   only.  BGP-4 [RFC4271] is the de-facto interconnection protocol used
   to exchange reachability information.  There is no standardized set
   of supported traffic classes, no standardized packet marking and no
   standardized forwarding behaviour, which cross-domain traffic could
   rely on.  QoS policy decisions are taken by AS providers
   independently and in an uncoordinated fashion.  However, many AS
   providers make use of the Differentiated Services Architecture
   [RFC2475] as AS internal QoS mechanism.  Within this architecture,
   there are 64 codepoints and an unlimited number of Per Hop Behaviours
   (PHBs) available.  Some PHBs have been defined in separate RFCs,
   which will be focused on in this document.




Knoll                     Expires May 22, 2017                  [Page 2]


Internet-Draft            BGP CoS Interconnect             November 2016


   A Basic Set of supported Classes, called "Basic CoS" is defined
   inhere, which consists of the primitive "Best Effort (BE)" PHB, the
   "Expedited Forwarding (EF)" PHB [RFC3246], the "Assured Forwarding
   (AF)" PHB Group [RFC2597] and the "Lower Effort" Per-Domain Behavior
   (PDB) [RFC3662].  AS providers, which can support this Basic CoS are
   asked to signal this capability to their interconnection partners by
   means of the new CoS Capability Extended Community defined in
   Section 2 of this draft.

   4 AF PHB classes have been defined so far, which will be grouped into
   the generally signalled "AF Group".  That is, as long as the AS
   provider can support at least one out of the 4 AF classes in his
   externally supported CoS Set, this AS is regarded as AF capable.

   A second transitive attribute is defined in Section 3, which is used
   for parameter signalling about the applied access control within the
   ingress AS border router.  The reason for this traffic limitation is
   the fact, that certain high quality forwarding behaviours can only be
   achieved, if the percentage of high priority traffic within the
   traffic mix lies below a certain threshold.  This attribute informs
   the interconnection partner about the applied limitation, which can
   in turn be used to perform traffic shaping at the neighbouring AS'
   egress.  The attribute allows this limitation signalling either
   associated to the NLRI within the same UPDATE message or with
   "global" scope to describe the generally applied ingress limitation.

   Both attributes are likely to be used together, if ingress class
   limitation is used for the respective AS.

   More detailed signalling of forwarding behaviour distinction and
   associated cross-layer marking can be achieved using the QoS Marking
   Attribute approach [I-D.knoll-idr-qos-attribute].

2.  Definition and Usage of the CoS Capability

2.1.  Extended Community Type

   The new CoS Capability is encoded as a BGP Extended Community
   [RFC4360].  Extended Community Attributes are transitive optional BGP
   attributes with Type Code 16.  An adoption to the simple BGP
   Community Attribute encoding [RFC1997] is not defined in this
   document.  The actual encoding within the BGP Extended Community
   Attribute is as follows.








Knoll                     Expires May 22, 2017                  [Page 3]


Internet-Draft            BGP CoS Interconnect             November 2016


   The CoS Capability is transitive and of regular type which results in
   a 1 octet Type field followed by 7 octets for the CoS Capability
   structure.  The Type is IANA-assignable (FCFS procedure) and marks
   the community as transitive across ASes.  The type number has been
   assigned by IANA to 0xYY (0x00-0x3f).

    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 0 x x x x x x|                                               |
   +-+-+-+-+-+-+-+-+   7 octet CoS Capability structure            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 1

2.2.  Structure of the CoS Capability Attribute

   The CoS Capability structure is deliberately kept very simple and is
   defined as follows.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B E A L| Currently Unused - default to '0'                     |
   |E F F E|                                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Currently Unused - default to '0'     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   The Currently Unused bits default to '0' and MUST be ignored on
   reception.

   Leading "BE, EF, AF and LE" encoding.

   This encoding signals the BE, EF, AF Group and LE support of the
   respective AS.

   +-----+------------------------------------------------------------+
   | Bit | Encoding                                                   |
   +-----+------------------------------------------------------------+
   | BE  | Default to '1' to signal general "Best Effort" PHB support |
   +-----+------------------------------------------------------------+
   | EF  | '1' ... "Expedited Forwarding" PHB support [RFC3246]       |
   +-----+------------------------------------------------------------+



Knoll                     Expires May 22, 2017                  [Page 4]


Internet-Draft            BGP CoS Interconnect             November 2016


   | AF  | '1' ... "Assured Forwarding" PHB group support [RFC2597]   |
   +-----+------------------------------------------------------------+
   | LE  | '1' ... "Lower Effort" PDB support [RFC3662]               |
   +-----+------------------------------------------------------------+

                       Table 1: CoS support encoding

   The implied Per-Hop-Behaviour Identification Codes follow the
   definition as standardized in [RFC3140].  The AF Group needs to
   consist of at least one of the currently available AF1x, AF2x, AF3x
   and AF4x.

   BE:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0   0   0   0   0   0 | 0   0   0   0   0   0   0   0   0   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   EF:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 1   0   1   1   1   0 | 0   0   0   0   0   0   0   0   0   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   AF1x:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0   0   1   0   1   0 | 0   0   0   0   0   0   0   0   1   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   AF2x:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0   1   0   0   1   0 | 0   0   0   0   0   0   0   0   1   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   AF3x:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0   1   1   0   1   0 | 0   0   0   0   0   0   0   0   1   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   AF4x:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 1   0   0   0   1   0 | 0   0   0   0   0   0   0   0   1   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+




Knoll                     Expires May 22, 2017                  [Page 5]


Internet-Draft            BGP CoS Interconnect             November 2016


   LE:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0   0   1   0   0   0 | 0   0   0   0   0   0   0   0   0   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


                                 Figure 3

2.3.  Usage of the CoS Capability Attribute

   The CoS Capability is used as primitive means to signal the general
   availability of the set of "Basic CoS" PHBs in the advertising AS.
   This Extended Community is included within the attribute section of
   an BGP UPDATE message and is therefore associated to the NLRI
   information of the same message.  Whether the Basic CoS is available
   and is therefore advertised can easily being judged on for all
   prefixes, which originate from the advertising AS.

   All other reachability information MUST be signalled together with
   this CoS Capability if they were received together with such an
   Extended Community by neighbouring peers.

   NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS
   Capability, if it were not received together with such an attribute.

3.  Definition and Usage of the CoS Parameter Attribute

3.1.  Definition of the CoS Parameter Attribute

   The CoS Parameter Attribute is an optional transitive BGP attribute.

   The attribute contains one or more of the following:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PHB id Code                 |     Flags     | Reserved = '0'|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ASN of sending AS                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token Bucket Rate [r] (32-bit IEEE floating point number)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token Bucket Size [b] (32-bit IEEE floating point number)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Peak Data Rate [p] (32-bit IEEE floating point number)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Minimum Policed Unit [m] (32-bit integer)                   |



Knoll                     Expires May 22, 2017                  [Page 6]


Internet-Draft            BGP CoS Interconnect             November 2016


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Maximum Packet Size [M] (32-bit integer)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   PHB ID:

      This field specifies the targeted Per Hop Behaviour limitations
      and follows the defined encoding of [RFC3140] as listed in Figure
      3.

   Flags:

    0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |G |DR|0 |0 |0 |0 |0 |0 |
   +--+--+--+--+--+--+--+--+

      Only two flags are defined.  The remaining bits default to '0' and
      MUST be ignored on reception.

      The 'G' flag signals, whether the limitations have global scope on
      all incoming traffic ('1') or are associated to traffic that is
      destined to destinations within the NLRI of the UPDATE message
      ('0').  NLRI specific limitation will supersede globally signalled
      ones for traffic destined to those NLRI destinations.

      The 'DR' flag signals the applied handling of non-confirming
      traffic.  DR='0' signals strict dropping of excess traffic.
      DR='1' signals the performed remarking of excess traffic packets
      to Best Effort traffic marking.

   ASN of sending AS:

      Depending on the 2-octet or 4-octet AS peering type, the sending
      AS of the attribute MUST encode its AS number as right-aligned
      32bit number.

   Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed
   Unit and Maximum Packet Size:

      The rates and sizes are given in 4 octet IEEE floating point
      format [IEEE] or 4 octet integer format, respectively.  They are
      parameters to a token bucket ingress filter, which is applied to
      the packets belonging to the stated PHB id.  The parameters follow
      the definition given in [RFC2210] and [RFC2215].




Knoll                     Expires May 22, 2017                  [Page 7]


Internet-Draft            BGP CoS Interconnect             November 2016


3.2.  Usage of the CoS Parameter Attribute

   The signalled parameters are used for PHB id Code based ingress
   limitation.  Depending on which PHB id Codes a BGP peer signals in
   this attribute to its neighbour, it is said, that the respective PHB
   id Code is supported and will experience the defined limitations.

   Those limitations can be applied to all incoming traffic of a
   specific PHB id Code (marked as 'G') or only for incoming traffic,
   that is destined for the NLRI of the given UPDATE message.

   The resulting treatment for non-confirming traffic is signalled
   through the 'DR' flag.

   To withdraw a previously signalled limitation, a CoS Parameter
   Attribute for the respective PHB id Code MUST be sent with a rate
   value [r] of zero.  Using the 'G' flag, this can be withdrawn
   globally for all traffic of the given PHB id Code or withdrawn only
   for traffic destined to the prefixes given in the NLRI of the UPDATE.
   Previously signalled non-global (i.e. NLRI specific) limitations are
   also waived, if the same prefix is advertised without a CoS Parameter
   Attribute later on.  In this case, the missing attribute is
   considered as the above described 'rate zero update' for those
   prefixes.  Waived prefix specific limitations do not supersede global
   limitations for the respective PHB id Code.  In turn, a withdrawal of
   a global limitation does also withdraw any possibly existing prefix
   specific ones for the respective PHB id Code.

   All limitations have AS local scope for the advertising AS and the
   neighbouring AS might or might not adopt its sending behaviour to
   those advertised limitations.

   Despite the transitive nature of the new attribute, its usage for
   ingress limitation is confined to neighbouring ASes.  Processing of
   the conveyed parameters is only valid for peers, who are peering with
   the AS specified in the ASN field of the attribute.

   The attribute SHOULD NOT be transitively relayed to non-adjacent
   interconnection partners.

4.  Confidentiality Considerations

   The disclosure of confidential AS intrinsic information by means of
   the signalled Basic CoS support is of low key security concern.  The
   disclosure of information through CoS Parameter signalling is more
   detailed.  However, all included parameters are exchanged with direct
   interconnection partners and are the free choice of each AS provider.




Knoll                     Expires May 22, 2017                  [Page 8]


Internet-Draft            BGP CoS Interconnect             November 2016


5.  IANA Considerations

   This document defines a new BGP Extended Community, which needs to be
   assigned a number by IANA within the Extended Community list.  The
   new CoS Capability is a BGP Extended Community of regular type.  It
   is IANA-assignable (FCFS procedure) and is transitive across ASes.  A
   number assignment application within the numbering range of 0x00-0x3f
   is made to IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

   This document defines a new BGP attribute.  This attribute is
   optional and transitive.

6.  Security Considerations

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP version.

   The signalled attributes are transitive with limited relay operation
   in the CoS Parameter Attribute case.  AS peers, which use egress
   traffic shaper on the signalled limitations SHOULD exhaust all
   available BGP security features to make sure, that the signalled
   limitation is actually sent by the adjacent peer.

7.  References

7.1.  Normative References

   [IEEE]     IEEE, "IEEE Standard for Binary Floating-Point
              Arithmetic", ISBN 1-5593-7653-8, 1985.

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <http://www.rfc-editor.org/info/rfc1997>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, DOI 10.17487/RFC2210, September 1997,
              <http://www.rfc-editor.org/info/rfc2210>.

   [RFC2215]  Shenker, S. and J. Wroclawski, "General Characterization
              Parameters for Integrated Service Network Elements", RFC



Knoll                     Expires May 22, 2017                  [Page 9]


Internet-Draft            BGP CoS Interconnect             November 2016


              2215, DOI 10.17487/RFC2215, September 1997,
              <http://www.rfc-editor.org/info/rfc2215>.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/
              RFC2597, June 1999,
              <http://www.rfc-editor.org/info/rfc2597>.

   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140, DOI
              10.17487/RFC3140, June 2001,
              <http://www.rfc-editor.org/info/rfc3140>.

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
              <http://www.rfc-editor.org/info/rfc3246>.

   [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,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.

7.2.  Informative References

   [I-D.knoll-idr-qos-attribute]
              Knoll, T., "BGP Extended Community for QoS Marking",
              draft-knoll-idr-qos-attribute-18 (work in progress), July
              2016.

   [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,
              <http://www.rfc-editor.org/info/rfc2475>.

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",
              RFC 3662, DOI 10.17487/RFC3662, December 2003,
              <http://www.rfc-editor.org/info/rfc3662>.

Author's Address





Knoll                     Expires May 22, 2017                 [Page 10]


Internet-Draft            BGP CoS Interconnect             November 2016


   Thomas Martin Knoll
   TU Chemnitz

   Email: thomas.m.knoll@gmail.com















































Knoll                     Expires May 22, 2017                 [Page 11]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/