Inter-Domain Routing Working Group                             Th. Knoll
Internet-Draft                         Chemnitz University of Technology
Intended status: Standards Track                            July 7, 2008
Expires: January 8, 2009


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 8, 2009.

Abstract

   This document focuses on Class of Service Interconnection at inter-
   domain peering points.  It specifies two new non-transitive
   attributes, which enable adjacent peers to signal Class of Service
   Capabilities and certain Class of Service admission control
   Parameters.  The new "CoS Capability Attribute" is deliberately kept
   simple and denotes the general EF, AF Group and BE 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.  The



Knoll                    Expires January 8, 2009                [Page 1]


Internet-Draft            BGP CoS Interconnect                 July 2008


   denoted Class of Service forwarding support is meant as the AS
   externally available (transit) Class of Service support.

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].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition and Usage of the CoS Capability Attribute . . . . .  4
     2.1.  Extended Community Type  . . . . . . . . . . . . . . . . .  4
     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 . . . . . . . . . . .  7
   4.  Confidentiality Considerations . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10























Knoll                    Expires January 8, 2009                [Page 2]


Internet-Draft            BGP CoS Interconnect                 July 2008


1.  Introduction

   AS interconnection is currently based on best effort peering only.
   BGP-4 [RFC4271] is the de-facto peering 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) possible.  Some PHBs
   have been defined in separate RFCs, which will be focused on in this
   document.

   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] and the "Assured Forwarding
   (AF)" PHB Group [RFC2597].  AS providers, which can support this
   Basic CoS are asked to signal this capability to their peering
   partners by means of the new CoS Capability Attribute 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 non-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 peering 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].





Knoll                    Expires January 8, 2009                [Page 3]


Internet-Draft            BGP CoS Interconnect                 July 2008


2.  Definition and Usage of the CoS Capability Attribute

2.1.  Extended Community Type

   The new CoS Capability Attribute is encoded as a BGP Extended
   Community Attribute [RFC4360].  Extended Community Attributes are
   transitive optional BGP attribute 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.

   The CoS Capability Attribute is non-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 non-transitive across ASes.
   The type number has been assigned by IANA to 0xYY (0x40-0x7f).
    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 x x x x x x|                                               |
   +-+-+-+-+-+-+-+-+   7 octet CoS Capability Attribute structure  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 1

   Note to RFC Editor: The actual type number needs to replace the '0xYY
   (0x40-0x7f)' after the IANA assignment has occurred.

2.2.  Structure of the CoS Capability Attribute

   The CoS Capability Attributes 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1| Currently Unused - default to '0'                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Currently Unused - default to '0'|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

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

   Leading "111" encoding.



Knoll                    Expires January 8, 2009                [Page 4]


Internet-Draft            BGP CoS Interconnect                 July 2008


      This encoding signals the BE, EF and AF Group support of the
      respective AS.  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 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 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


                                 Figure 3







Knoll                    Expires January 8, 2009                [Page 5]


Internet-Draft            BGP CoS Interconnect                 July 2008


2.3.  Usage of the CoS Capability Attribute

   The CoS Capability Attribute is used as primitive means to signal the
   general availability of the set of "Basic CoS" PHBs in the
   advertising AS.  The attribute 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 Attribute if they were received together with
   such an Attribute by neighbouring peers.

   NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS
   Capability Attribute, 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 non-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'|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Peak Rate                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Token Bucket Rate                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Token Bucket Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   PHB ID:

      This field specifies the targeted Per Hop Behaviour limitations
      and follows the defined encoding of [RFC3140]

   Flags:




Knoll                    Expires January 8, 2009                [Page 6]


Internet-Draft            BGP CoS Interconnect                 July 2008


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

      Only two flags are defines.  The resulting 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' flags 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.

   Peak Rate, Token Bucket Rate and Token Bucket Size:

      The rates and sizes are given in 4 octet IEEE floating point
      format [IEEE] .

3.2.  Usage of the CoS Parameter Attribute

   The signalled Parameter as used of 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.

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


4.  Confidentiality Considerations

   The disclosure of confidential AS intrinsic information by means of
   the signalled Basic CoS support is certainly of low key security
   concern.  The disclosure of information through CoS Parameter



Knoll                    Expires January 8, 2009                [Page 7]


Internet-Draft            BGP CoS Interconnect                 July 2008


   signalling is more detailed.  However, the attribute is non-
   transitive and all included parameters are the free choice of each AS
   provider.


5.  IANA Considerations

   This document defines a new BGP Extended Community Attribute, which
   needs to be assigned a number by IANA within the Extended Community
   Attribute list.

   The new CoS Capability Attribute is a BGP Extended Community
   Attribute of regular type.  It is IANA-assignable (FCFS procedure)
   and is non-transitive across ASes.

   An number assignment application within the numbering range of 0x40-
   0x7f is made to IANA.

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

   This document defines a second BGP attribute.  This attribute is
   optional and non-transitive and need to be assigned an appropriate
   number as well.


6.  Security Considerations

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

   The signalled attributes are non-transitive, which limits the reach
   of possibly applied malicious attribute modifications.  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]  Chandrasekeran, R., Traina, P., and T. Li, "BGP
              Communities Attribute", RFC 1997, August 1996.




Knoll                    Expires January 8, 2009                [Page 8]


Internet-Draft            BGP CoS Interconnect                 July 2008


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

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140,
              June 2001.

   [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, March 2002.

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

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

7.2.  Informative References

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

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


Author's Address

   Thomas Martin Knoll
   Chemnitz University of Technology
   Reichenhainer Str. 70 /331
   Chemnitz,   09126
   GERMANY

   Phone: +49-371-531-33246
   Fax:   +49-371-531-833246
   Email: knoll@etit.tu-chemnitz.de







Knoll                    Expires January 8, 2009                [Page 9]


Internet-Draft            BGP CoS Interconnect                 July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Knoll                    Expires January 8, 2009               [Page 10]