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


            BGP Extended Community Attribute for QoS Marking
                    draft-knoll-idr-qos-attribute-01

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 7, 2009.

Abstract

   This document specifies a simple signalling mechanism for inter-
   domain QoS marking using several instances of a new BGP Extended
   Community Attribute.  Class based packet marking and forwarding is
   currently performed independently within ASes.  The new QoS marking
   attribute makes the QoS class marking within the IP prefix
   advertising AS known to all access and transit ASes.  This enables
   individual (re-)marking and possibly forwarding treatment adaptation
   to the original QoS class setup of the respective originating AS.
   The attribute provides the means to signal QoS markings on different
   layers, which are linked together in QoS Class Sets.  It provides
   inter-domain and cross-layer insight into the QoS class mapping of
   the source AS with minimal signalling traffic.



Knoll                    Expires January 7, 2009                [Page 1]


Internet-Draft          BGP QoS Marking Attribute              July 2008


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.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Definition of the QoS Marking Attribute  . . . . . . . . . . .  6
     4.1.  Extended Community Type  . . . . . . . . . . . . . . . . .  7
     4.2.  Structure of the QoS Marking Attribute . . . . . . . . . .  7
     4.3.  Technology Type Enumeration  . . . . . . . . . . . . . . . 10
   5.  Attribute Usage  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  QoS Marking Attribute Example  . . . . . . . . . . . . . . 11
     5.2.  AS Border Packet Forwarding  . . . . . . . . . . . . . . . 11
     5.3.  IP Prefix Aggregation  . . . . . . . . . . . . . . . . . . 12
   6.  Confidentiality Considerations . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  QoS Marking Attribute Example . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17






















Knoll                    Expires January 7, 2009                [Page 2]


Internet-Draft          BGP QoS Marking Attribute              July 2008


1.  Introduction

   A new BGP Extended Community Attribute is defined in this document,
   which carries QoS marking information for different network layer
   technologies across ASes.  This attribute is called "QoS Marking
   Attribute".  This new attribute provides a mechanism within BGP-4
   [RFC4271] for associating all advertised prefixes of the AS with its
   differentiated QoS Class Marking information.  It allows for the
   consistent exchange of class encoding values between BGP peers for
   physical, data link and network QoS mechanisms.  These labels can be
   used to control the distribution of this information, for the
   encoding and for treatment adjustments within the AS or for other
   applications.  One globally seen QoS Class Set per AS is required for
   scalability reasons.  It is the AS provider's responsibility to
   enforce the globally signalled Set throughout the AS.

   Several QoS Marking Attributes MAY be included in a single BGP UPDATE
   message.  They are virtually linked together by means of an identical
   "QoS Set Number" field.  Each QoS Marking Attribute is encoded as
   8-octet tuple, as defined in Section 4.  Signalled QoS Class Sets are
   assumed to be valid for traffic crossing this AS.  If different QoS
   strategies are used with an AS, its provider is responsible for
   consistent transport of transit traffic across this inhomogeneous
   domain.  In all transit forwarding cases, QoS based tunnelling
   mechanisms are the means of choice for transparent traffic transport.

   The availability of the "Best Effort" forwarding class is implied and
   defaults to a zero encoding on all signalled layers.  It is therefore
   not necessary to include QoS Marking Attributes for the Best Effort
   Class as long as the default encoding is in place.


2.  Problem Statement

   Current inter-domain peering is "best effort" peering only.  That is,
   traffic forwarding between ASes is without traffic class
   differentiation and without any forwarding guarantee.  It is common
   for network providers to reset any IP packet class markings to zero,
   the best effort DSCP marking, at the AS ingress router, which
   eliminates any traffic differentiation.  Some providers perform
   higher layer classification at the ingress in order to guess the
   forwarding requirements and to match on their AS internal QoS
   forwarding policy.  There is no standardized set of classes, no
   standardized marking (class encoding) 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.




Knoll                    Expires January 7, 2009                [Page 3]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   This general statement does not cover the existing individual
   agreements, which do offer quality based peering with strict QoS
   guarantees.  However, such SLA based agreements are of bilateral or
   multilateral nature and do not offer a means for a general "better
   than best effort" peering.  This draft does not aim for making such
   SLA based agreements become void.  On the contrary, those agreements
   are expected to exist for special traffic forwarding paths with
   strictly guaranteed QoS.

   There are many approaches, which propose proper inter-domain QoS
   strategies including inter-domain parameter signalling, metering,
   monitoring and misbehaviour detection.  Such complex strategies get
   close to guaranteed QoS based forwarding at the expense of dynamic
   measurements and adjustments, of state keeping on resource usage vs.
   traffic load and in particular of possibly frequent inter-domain
   signalling.

   The proposed QoS Class marking approach dissociates from the complex
   latter solutions and targets the general "better than best effort"
   peering in coexistence with SLA based agreements.  It enables ASes to
   make their supported Class Sets and their encoding globally known.
   In other words, this support information constitutes a simple map of
   QoS enabled roads in transit and destination ASes.

   Signalling the coarse information about the supported class set and
   its cross-layer encoding within the involved forwarding domains of
   the selected AS path removes the lack of knowledge about the over-all
   available traffic differentiation.  AS providers are enabled to make
   an informed decision about supported class encodings and might adopt
   to them.  No guarantees are offered by this "better than best effort"
   approach, but as much as easily possible traffic differentiation
   without the need for frequent inter-domain signalling and for costly
   ingress re-classification will be achieved.

   Remarking the class encoding of customer traffic in order to match
   neighbouring class set encodings is reasonable at AS peering points.
   For AS internal forwarding, the encapsulation within any kind of QoS
   supporting tunnelling technology is highly recommended.  The cross-
   layer signalling of QoS encoding will further ease the setup of QoS
   based inter-domain tunnelling.

   The general confidentiality concern of disclosing AS internal policy
   information is addressed in Section 6.  In short, AS providers can
   signal a different class set in the QoS Marking Attributes to the one
   actually used internally.  The different class sets (externally
   signalled vs. internally applied one) require an undisclosed strictly
   defined mapping at the AS borders between the two.  This way, a
   distinction between internal and external QoS Class Sets can be



Knoll                    Expires January 7, 2009                [Page 4]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   achieved.

   The general need for class based accounting is not addressed by this
   draft.  MIB extensions are also required, which separate traffic
   variables by traffic marking.  It is expected for both that existing
   procedures can be reused in a class based manner.


3.  Related Work

   A number of QoS improvement approaches have been proposed before and
   a selection will be briefly mentioned in this section.

   Most of the approaches perform parameter signalling.
   [I-D.jacquenet-bgp-qos] defines the QOS_NLRI attribute, which is used
   for propagating QoS-related information associated to the NLRI
   (Network Layer Reachability Information) information conveyed in a
   BGP UPDATE message.  Single so called "QoS routes" are signalled,
   which fulfil certain QoS requirements.  Several information types are
   defined for the attribute, which concentrate on rate and delay type
   parameters.

   [I-D.boucadair-qos-bgp-spec] is based on the specified QOS_NLRI
   attribute and introduces some modifications to it.  The notion of AS-
   local and extended QoS classes is used, which effectively describes
   the local set of QoS performance parameters or their cross-domain
   combined result.  Two groups of QoS delivery services are
   distinguished, where the second group concentrates on ID associated
   QoS parameter propagation between adjacent peers.  The first group is
   of more interest for this draft since it concentrates on the
   "identifier propagation" such as the DSCP value for example.
   However, this signalling is specified for the information exchange
   between adjacent peers only and assumes the existence of extended QoS
   classes and offline traffic engineering functions.

   Another approach is described in [I-D.liang-bgp-qos].  It associates
   a list of QoS metrics with each prefix by extending the existing
   AS_PATH attribute format.  Hop-by-hop metric accumulation is
   performed as the AS_PATH gets extended in relaying ASes.  Metrics are
   generically specified as a list of TLV-style attribute elements.  The
   metrics such as bandwidth and delay are exemplary mentioned in the
   draft.

   One contribution specialized in the signalling of Type Of Service
   (TOS) values which are in turn directly mapped to DSCP values in
   section 3.2 of the draft [I-D.zhang-idr-bgp-extcommunity-qos].  The
   TOS value is signalled within an Extended Community Attribute and, if
   it is understood correctly, will be applied to a certain route.  An



Knoll                    Expires January 7, 2009                [Page 5]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   additional value field is used to identify, which routes belong to
   which signalled TOS community.  Who advertises such attributes and
   whether they are of transitive or non-transitive type remains
   unspecified.

   The most comprehensive analysis (although not an IETF draft) is given
   in [MIT_CFP].  This "Inter- provider Quality of Service" white paper
   examines the inter-domain QoS requirements and derives a
   comprehensive approach for the introduction of at least one QoS class
   with guaranteed delay parameters.  The implementation aspects of
   metering, monitoring, parameter feedback and impairment allocations
   are all considered in the white paper.  However, QoS guarantees and
   parameter signalling is beyond the intention of this QoS Marking
   Attribute draft.

   Other drafts may also be considered as related work as long as they
   convey QoS marking information and might be "misused" for QoS class
   signalling.

   One example is the usage of the "Traffic Engineering Attribute" as
   defined in [I-D.ietf-softwire-bgp-te-attribute].  However, the
   attribute is non-transitive and the LSP encoding types are not
   generally applicable to inter-domain peering types.  Its usage of the
   targeted QoS Marking signalling is not possible.  The included
   maximum bandwidth of each of eight priority classes, could however be
   used in future draft extensions.

   The second example is the current "Dissemination of flow
   specification rules" draft [I-D.ietf-idr-flow-spec].  It defines a
   new BGP NLRI encoding format, which can be used to distribute traffic
   flow specifications.  Such flow specification can also include DSCP
   values as type 11 in the NLRI.  Furthermore, one could signal
   configuration actions together with the DSCP encoding, which could be
   used for filtering purposes or even trigger remarking and route
   selection with it.  Such usage is not defined in the draft and can
   hardly be achieved because of the following reasons.  The flow
   specification is focused on single flows, which might even be part of
   an aggregate.  Such fine grained specification is counterproductive
   for the coarse grained general QoS Marking approach of this draft.
   The novel approach of cross-layer QoS Marking could also not be
   incorporated, which might be essential for future tunnelled inter-
   domain peering.


4.  Definition of the QoS Marking Attribute






Knoll                    Expires January 7, 2009                [Page 6]


Internet-Draft          BGP QoS Marking Attribute              July 2008


4.1.  Extended Community Type

   The new QoS Marking Attribute is encoded as a BGP Extended Community
   Attribute [RFC4360].  It is therefore a 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 QoS Marking Attribute is of regular type which results in a 1
   octet Type field followed by 7 octets for the QoS marking structure.
   The Type is IANA-assignable and marks the community as transitive
   across ASes.  The type number has been assigned by IANA to 0x00
   [IANA_EC].
    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 0 0 0 0 0 0|                                               |
   +-+-+-+-+-+-+-+-+   7 octet QoS Marking Attribute structure     |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

4.2.  Structure of the QoS Marking Attribute

   The QoS Marking Attributes provides a flexible encoding structure for
   various QoS Markings on different layers.  This flexibility is
   achieved by a Flags, a QoS Set Number and a Technology Type field
   within the 7 octet structure as defined below.
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags      | QoS Set Number|Technology Type| QoS Marking O |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | QoS Marking A |   P. Count    | C. Unused ='0'|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   Flags:
    0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |0  0  0 |R |I |A |0 |0 |
   +--+--+--+--+--+--+--+--+

                                 Figure 3




Knoll                    Expires January 7, 2009                [Page 7]


Internet-Draft          BGP QoS Marking Attribute              July 2008


      All used and unused flags default to a value of '0'.  The
      following table shows the bit encoding of the Flags field.

   +-----+--------+-----------------------------------------+
   | Bit | Flag   | Encoding                                |
   +-----+--------+-----------------------------------------+
   | 0-2 | unused | Default to '0'                          |
   | 3   | R      | '1' ... remarking occurred              |
   | 4   | I      | '1' ... QoS marking ignored             |
   | 5   | A      | '1' ... QoS class aggregation occurred  |
   | 6,7 | unused | Default to '0'                          |
   +-----+--------+-----------------------------------------+

                                  Table 1

      The Flags "R, I and A" are set to '0' in the advertisement by the
      IP prefix originating AS.  Transit ASes MUST change the flag value
      to '1' once the respective event occurred.  If the QoS marking
      actively used in the transit AS internal forwarding is different
      from the advertised original one, the 'Remarking (R)' flag is set
      to '1'.  This MUST be done separately for each technology type
      attribute within the attribute set.  The same applies to the
      'Ignore (I)' flag, if the respective advertised QoS marking is
      ignored in the transit AS internal forwarding.

      The 'Aggregation (A)' flag MUST be set to '1' by the UPDATE
      message relaying transit AS, if the respective IP prefixes will be
      advertised inside an IP prefix aggregate constituted from
      differing Class Sets.

      If the defined Flags are cleared - and by means of the zero 'I'
      flag and the later on explained Processing Count it is shown that
      no "QoS Class ignorant" is involved in the forwarding path - a
      consistent class based overall forwarding is available along this
      path.

   QoS Set Number:

      Several single QoS Marking Attributes can be logically grouped
      into a QoS Marking Attribute Set characterized by a identical QoS
      Set Number.  This grouping of the single QoS Marking Attributes
      into a set provides a cross-layer linking between the QoS class
      encodings.  The number of signalled QoS Marking Attributes as well
      as QoS Marking Attribute Sets is at the operator's choice of the
      originating AS.  The enumerated QoS set numbers have BGP UPDATE
      message local significance starting with set number 0x00.

   Technology Type:



Knoll                    Expires January 7, 2009                [Page 8]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   The technology type encoding uses the enumeration list in
   (Section 4.3).  Future version of this draft will need an extended
   enumeration list administered by IANA.

   QoS Marking / Enumeration O & A:

   The interpretation of these identically approached fields depends on
   the selected layer and technology.  ASes, which process the Attribute
   and support the given QoS Class by means of a QoS mechanism using bit
   encodings for the targeted priority (e.g.  IP DSCP, Ethernet User
   Priority, MPLS EXP etc.)  MUST use a copy of the encoding in this
   attribute field.  Unused higher order bits default to '0'.  Other
   technologies, which use separate forwarding channels for different
   classes (such as L-LSPs, VPI/VCI inferred ATM classes, lambda
   inferred priority, etc.)  SHALL use class enumerations as encoding in
   this attribute field.  The enumeration count starts with zero for the
   best effort traffic class and rises by one with each available higher
   priority class.

   There are two QoS Marking fields within the QoS Marking Attribute for
   the "original (O)" and the "active (A)" QoS marking.

   QoS Marking O (Original QoS Marking):

      The IP prefix originating AS copies the internally associated QoS
      encoding of the given Technology Type into this one octet field.
      The field MUST remain unchanged in BGP UPDATE messages of relaying
      nodes.

   QoS Marking A (Active QoS Marking):

      QoS Marking A and O MUST be identically encoded by the prefix
      originating AS.

      All other ASes use this Active QoS Marking field to advertise
      their internal QoS encoding of the given class and technology.  A
      cleared Marking field (all zero) signals that this traffic class
      experiences default traffic treatment within the transit AS
      forwarding technology.

   Processing Count (P. Count):

      Each BGP instance, which processes the attribute and appends a
      different AS number to the AS_PATH, MUST increase this counter by
      one.  The attribute originating instance initializes the counter
      value to '0x00'.

   Currently Unused (C. Unused):



Knoll                    Expires January 7, 2009                [Page 9]


Internet-Draft          BGP QoS Marking Attribute              July 2008


      This one octet field is currently unused and MUST be set to
      '0x00'.

4.3.  Technology Type Enumeration

   A small list of technologies is provided in the table below for the
   direct encoding of common technology types.  The mapping of all
   virtual channel technologies into a single technology type value is
   for limiting the number of different attributes in an UPDATE message.
   It is therefore a contribution to scalability.

   +-------+-----------------------------------------------------------+
   | Value | Technology Type                                           |
   +-------+-----------------------------------------------------------+
   | 0x00  | DiffServ enabled IP (DSCP encoding)                       |
   | 0x01  | Ethernet using 802.1q priority tag                        |
   | 0x02  | MPLS using E-LSP                                          |
   | 0x03  | Virtual Channel (VC) encoding using separate channels for |
   |       | QoS forwarding / one channel per class (e.g. ATM VCs, FR  |
   |       | VCs, MPLS L-LSPs)                                         |
   | 0x04  | GMPLS - time slot encoding                                |
   | 0x05  | GMPLS - lambda encoding                                   |
   | 0x06  | GMPLS - fibre encoding                                    |
   +-------+-----------------------------------------------------------+

                                  Table 2


5.  Attribute Usage

   Providers MAY choose to process the QoS Marking Attributes and adopt
   the priority encoding and tunnel selection according to their local
   policy.  Whether this MAY also lead to different IGP routing
   decisions or even effect BGP update filters is out of scope for the
   attribute definition.

   Only the IP prefix originating AS is allowed to signal the QoS
   Marking Attributes and Set. AS providers, which make use of this
   signalling mechanism MUST make sure that only one external Class Set
   will be advertised for the AS.  All advertised prefixes, which
   originate from that AS will be sent with the same QoS Marking
   Attribute Set in the respective UPDATE message.  Transit ASes MUST
   NOT modify or extend the QoS Marking Attribute Set except for the
   update of each 'QoS Marking A' field contained in the Attribute Set,
   the respective "R, I, A" flags and the Processing Counter.  Prefixes
   with associated identical QoS Marking Attribute Sets are to be
   advertised together in common UPDATE messages in relaying nodes.




Knoll                    Expires January 7, 2009               [Page 10]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   Figure 4 shows an AS peering example with different Class Sets.  It
   shows the case in AS 5 where different Class Sets are used internally
   and externally.  The proposed QoS Class Set signalling will always
   use the external definitions within the UPDATE message QoS Marking
   Attributes.  The example also shows, that IP prefixes, which
   originate in AS 5 and AS 3 can be advertised together with the same
   QoS Marking Attribute Set as long as their Layer 2 encoding is
   identical.
                      AS 5 = Transit AS
   +------------+     =================     +------------+
   +   AS 1     +      AS internal:         +   AS 3     +
   + 4 classes  +         5 classes         + 3 classes  +
   +   L2/L3    +         L2/L3             +   L2/L3    +
   +(EF,2xAF,BE)+      AS external:         +(EF,AF11,BE)+
   +         [] +         3 classes         +[]          +
   +------------+         L3 (EF,AF11,BE)   +------------+
                 \    +---------------+    /
                  \   |       []      |   /
                   \  |      /  \     |  /
                    \ |  --()---()--  | /
                     \| /   |    |  \ |/
                      |[]   |    |  []|
                     /| \   |    |  / |\
                    / |  --()---()--  | \
                   /  |      \  /     |  \
                  /   |       []      |   \
                 /    +---------------+    \
   +------------+                           +------------+
   +         [] +                           +[]          +
   +   AS 2     +                           +   AS 4     +
   + 2 classes  +                           + 6 classes  +
   +   L2/L3    +                           +  L1/L2/L3  +
   +  (EF,BE)   +                           +(EF,4xAF,BE)+
   +------------+                           +------------+
   [] ... AS Border Router
   () ... AS internal Router

                                 Figure 4

5.1.  QoS Marking Attribute Example

   See Appendix A for an example QoS Marking Attribute Set.

5.2.  AS Border Packet Forwarding

   IP packet forwarding based on packet header QoS encoding might
   require remarking of packets in order to match AS internal policies
   and encodings of neighbouring ASes.



Knoll                    Expires January 7, 2009               [Page 11]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   Identical QoS class sets and encodings between neighbouring ASes do
   not require any remarking.  Different encodings will be matched on
   the outgoing traffic.

   Outgoing traffic for a given IP prefix uses the 'QoS Marking A'
   information of the respective BGP UPDATE message QoS Marking
   Attribute for adopted remarking of the forwarded packet.

   If the Process Count is smaller than the number of different AS
   numbers in the AS PATH or if the 'I' flag is set for a given
   encoding, the outgoing traffic remarking can not be applied due to
   this signalled lack of QoS Class forwarding support.

   'QoS Marking O' information is used for outgoing remarking, if the
   targeted class is not supported by the neighbouring AS.

5.3.  IP Prefix Aggregation

   Several IP prefixes of different IP prefix originating ASes MAY be
   aggregated to a shorter IP prefix in transit ASes.  If the original
   Class Sets of the aggregated prefixes are identical, the aggregate
   will use the same Set. In all other cases, the resulting IP prefix
   aggregate is handled the same as if the transit AS were the
   originating AS for this aggregated prefix.  The transit AS provider
   MAY care for AS internal mechanisms, which map the signalled
   aggregate QoS Class Set to the different original Class Sets in the
   internal forwarding path.

   In case of IP prefix aggregation with different QoS Class Sets, the
   'Aggregation (A)' flag of each QoS Marking Attribute within the Set
   MUST be set to '1'.


6.  Confidentiality Considerations

   The disclosure of confidential AS intrinsic information is of no
   concern since the signalled marking for QoS class encodings can be
   adopted prior to the UPDATE advertisement of the IP prefix
   originating AS.  This way, a distinction between internal and
   external QoS Class Sets can be achieved.  AS internal cross-layer
   marking adaptation and policy based update filtering allows for
   consistent QoS class support despite made up QoS Class Set and
   encoding information within UPDATE advertisements.  In case of such
   policy hiding strategy, the required AS internal ingress and egress
   adaptation SHALL be done transparently without explicit "Active
   Marking" and 'R' flag signalling.





Knoll                    Expires January 7, 2009               [Page 12]


Internet-Draft          BGP QoS Marking Attribute              July 2008


7.  IANA Considerations

   This document defines a new BGP Extended Community Attribute, which
   includes a "Technology Type" field.  Section 4.3 enumerates a number
   of popular technologies.  This list is expected to suffice for first
   implementations.  However, future or currently uncovered technologies
   may arise, which require an extended "Technology Type" enumeration
   list administered by IANA.


8.  Security Considerations

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

   Malicious signalling behaviour of QoS marking Attribute advertising
   ASes can result in misguided neighbours about non existing or
   maliciously encoded Class Sets.  Removal of QoS Marking Attribute
   Sets leads to the current best effort peering, which is no stringent
   security concern.

   The strongest thread is the advertisement of numerous very fine
   grained Class Sets, which could limit the scalability of this
   approach.  However, neighbouring ASes are free to set the ignore flag
   of single attributes or to stop processing the QoS Marking Attributes
   of a certain routing advertisement, once a self-set threshold has
   been crossed.  By means of this self defence mechanism it should not
   be possible to crash neighbouring peers due to the excessive use of
   the new attribute.


9.  References

9.1.  Normative References

   [IANA_EC]  IANA, "Border Gateway Protocol (BGP) Data Collection
              Standard Communities", June 2008,
              <http://www.iana.org/assignments/
              bgp-extended-communities>.

   [RFC1997]  Chandrasekeran, R., Traina, P., and T. Li, "BGP
              Communities Attribute", RFC 1997, August 1996.

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

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



Knoll                    Expires January 7, 2009               [Page 13]


Internet-Draft          BGP QoS Marking Attribute              July 2008


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

9.2.  Informative References

   [I-D.boucadair-qos-bgp-spec]
              Boucadair, M., "QoS-Enhanced Border Gateway Protocol",
              draft-boucadair-qos-bgp-spec-01 (work in progress),
              July 2005.

   [I-D.ietf-idr-flow-spec]
              Marques, P., Sheth, N., Raszuk, R., Greene, B., and D.
              McPherson, "Dissemination of flow specification rules",
              draft-ietf-idr-flow-spec-01 (work in progress),
              April 2008.

   [I-D.ietf-softwire-bgp-te-attribute]
              Ould-Brahim, H., "Traffic Engineering Attribute",
              draft-ietf-softwire-bgp-te-attribute-00 (work in
              progress), January 2008.

   [I-D.jacquenet-bgp-qos]
              Cristallo, G., "The BGP QOS_NLRI Attribute",
              draft-jacquenet-bgp-qos-00 (work in progress),
              February 2004.

   [I-D.liang-bgp-qos]
              Benmohamed, L., "QoS Enhancements to BGP in Support of
              Multiple Classes of Service", draft-liang-bgp-qos-00 (work
              in progress), June 2006.

   [I-D.zhang-idr-bgp-extcommunity-qos]
              Zhang, Z., "ExtCommunity map and carry TOS value of IP
              header", draft-zhang-idr-bgp-extcommunity-qos-00 (work in
              progress), November 2005.

   [MIT_CFP]  Amante, S., Bitar, N., Bjorkman, N., and others, "Inter-
              provider Quality of Service - White paper draft 1.1",
              November 2006,
              <http://cfp.mit.edu/docs/interprovider-qos-nov2006.pdf>.


Appendix A.  QoS Marking Attribute Example

   The example AS is advertising several IP prefixes, which experience
   equal QoS treatment from AS internal networks.  The IP packet
   forwarding policy within this originating AS defines e.g. 3 traffic
   classes for IP traffic (DSCP1, DSCP2 and DSCP3).  These three classes



Knoll                    Expires January 7, 2009               [Page 14]


Internet-Draft          BGP QoS Marking Attribute              July 2008


   are also consistently taken care of within an EXP bit supporting MPLS
   tunnel forwarding.  The BGP UPDATE message for the announced IP
   prefixes will contain the following QoS Marking Attribute Set
   together with the IP prefix NLRI.
   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 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 1 0 1 1 1 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 1 0 1 1 1 0|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|0 0 0 1 1 0 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 1 1 0 0 0|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0|0 0 0 0 1 0 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| C. Unused ='0'|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  The class set as well as the example encodings are arbitrarily chosen.

                                 Figure 5















Knoll                    Expires January 7, 2009               [Page 15]


Internet-Draft          BGP QoS Marking Attribute              July 2008


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 7, 2009               [Page 16]


Internet-Draft          BGP QoS Marking Attribute              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 7, 2009               [Page 17]