Inter-Domain Routing Working Group Th. Knoll
Internet-Draft Chemnitz University of Technology
Intended status: Standards Track January 7, 2009
Expires: July 11, 2009
BGP Extended Community Attribute for QoS Marking
draft-knoll-idr-qos-attribute-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 11, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract
This document specifies a simple signalling mechanism for inter-
domain QoS marking using several instances of a new BGP Extended
Knoll Expires July 11, 2009 [Page 1]
Internet-Draft BGP QoS Marking Attribute January 2009
Community Attribute. Class based packet marking and forwarding is
currently performed independently within ASes. The new QoS marking
attribute makes the targeted Per Hop Behaviour within the IP prefix
advertising AS and the currently applied marking at the
interconnection point 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.
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].
Knoll Expires July 11, 2009 [Page 2]
Internet-Draft BGP QoS Marking Attribute January 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definition of the QoS Marking Attribute . . . . . . . . . . . 7
4.1. Extended Community Type . . . . . . . . . . . . . . . . . 8
4.2. Structure of the QoS Marking Attribute . . . . . . . . . . 8
4.3. Technology Type Enumeration . . . . . . . . . . . . . . . 11
5. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. QoS Marking Attribute Example . . . . . . . . . . . . . . 13
5.2. AS Border Packet Forwarding . . . . . . . . . . . . . . . 13
5.3. IP Prefix Aggregation . . . . . . . . . . . . . . . . . . 14
6. Confidentiality Considerations . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. QoS Marking Attribute Example . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Knoll Expires July 11, 2009 [Page 3]
Internet-Draft BGP QoS Marking Attribute January 2009
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".
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 interconnection is "best effort" interconnection
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 July 11, 2009 [Page 4]
Internet-Draft BGP QoS Marking Attribute January 2009
This general statement does not cover the existing individual
agreements, which do offer quality based interconnection 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" interconnection. 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"
interconnection 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 interconnection
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 July 11, 2009 [Page 5]
Internet-Draft BGP QoS Marking Attribute January 2009
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 July 11, 2009 [Page 6]
Internet-Draft BGP QoS Marking Attribute January 2009
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 interconnection 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 interconnection.
4. Definition of the QoS Marking Attribute
Knoll Expires July 11, 2009 [Page 7]
Internet-Draft BGP QoS Marking Attribute January 2009
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 0x04
[IANA_EC].
Optionally, a non-transitive Type value assignment of 0x44 is
provided, which allows for the interconnection local marking
information exchange. The attributes format remains untouched for
the non-transitive version.
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 attribute 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 Oh|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Marking Ol| QoS Marking A |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Flags:
Knoll Expires July 11, 2009 [Page 8]
Internet-Draft BGP QoS Marking Attribute January 2009
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|0 0 0 |R |I |A |0 |0 |
+--+--+--+--+--+--+--+--+
Figure 3
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 cleared
'Partial' flag of the BGP attribute it is shown, that no "QoS
Class ignorant" AS is involved in the forwarding path - a
consistent class based overall traffic separated forwarding is
available along this path.
QoS Set Number:
Knoll Expires July 11, 2009 [Page 9]
Internet-Draft BGP QoS Marking Attribute January 2009
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 cross-layer linking between the QoS class
encodings. It can also be used for the specification of behaviour
sets as given in the [RFC3140]. 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:
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 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 behaviour (e.g. IP DSCP, Ethernet User Priority, MPLS EXP
etc.) MUST use a copy of the encoding in the "QoS Marking A"
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. Higher order
bits of those fields, which are not used for the respective behaviour
encoding, default to zero.
QoS Marking O (Original QoS Marking):
This field is a 16 bit QoS Marking field, which consists of of a
high ("Oh") and a low ("Ol") octet. The IP prefix originating AS
copies the internally associated QoS encoding of the given
Technology Type into this one octet field. The field value is
right-aligned depending on the number of encoded bits. For the IP
technology, the encoding of Per Hop Behaviour Codes has to follow
the definitions stated in [RFC3140]. The field MUST remain
unchanged in BGP UPDATE messages of relaying nodes.
Knoll Expires July 11, 2009 [Page 10]
Internet-Draft BGP QoS Marking Attribute January 2009
QoS Marking A (Active QoS Marking):
QoS Marking A and O MUST be identically encoded by the prefix
originating AS, except for the case, where IP technology Per Hop
Behaviours are addressed. "QoS Marking A" will always contain the
locally applied encoding for the targeted PHB.
All other ASes use this Active QoS Marking field to advertise
their locally applied internal QoS encoding of the given class and
technology at the interconnection point. The field value is
right-aligned depending on the number of encoded bits. A cleared
Marking field (all zero) signals that this traffic class
experiences default traffic treatment within the transit AS
forwarding technology.
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 behaviour 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.
Knoll Expires July 11, 2009 [Page 11]
Internet-Draft BGP QoS Marking Attribute January 2009
Only the IP prefix originating AS is allowed to signal the QoS
Marking attributes and Sets. 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
and the respective "R, I, A" flags. Prefixes with associated
identical QoS Marking attribute Sets are to be advertised together in
common UPDATE messages in relaying nodes.
Figure 4 shows an AS interconnection 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.
Knoll Expires July 11, 2009 [Page 12]
Internet-Draft BGP QoS Marking Attribute January 2009
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,AF1,BE)+
+ [] + 3 classes +[] +
+------------+ L3 (EF,AF1,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.
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.
Knoll Expires July 11, 2009 [Page 13]
Internet-Draft BGP QoS Marking Attribute January 2009
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.
There is no 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.
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 will require an extended "Technology Type"
enumeration list administered by IANA.
Knoll Expires July 11, 2009 [Page 14]
Internet-Draft BGP QoS Marking Attribute January 2009
A new extended community QoS Marking attribute is defined, which has
been assigned a Type value of 0x04 for a transitive and 0x44 for a
non-transitive usage.
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 interconnection, which is no
stringent security concern.
The IP prefix originating AS MAY place a copy of its marking
information into the Internet Routing Registry (IRR) for global
reference.
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.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
Knoll Expires July 11, 2009 [Page 15]
Internet-Draft BGP QoS Marking Attribute January 2009
[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.
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-03 (work in progress),
November 2008.
[I-D.ietf-softwire-bgp-te-attribute]
Fedyk, D., Rekhter, Y., and H. Ould-Brahim, "BGP Traffic
Engineering Attribute",
draft-ietf-softwire-bgp-te-attribute-04 (work in
progress), December 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>.
Knoll Expires July 11, 2009 [Page 16]
Internet-Draft BGP QoS Marking Attribute January 2009
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
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|1 0 1 1 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 1 0 1 1 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 0 0 0 0 0 1 0|0 0 0 0 0 0 0 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 1 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 1 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 1|0 0 0 0 0 0 1 0|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 1 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 1 0 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 1 0|0 0 0 0 0 0 1 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 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class set as well as the example encodings are arbitrarily chosen.
Figure 5
Knoll Expires July 11, 2009 [Page 17]
Internet-Draft BGP QoS Marking Attribute January 2009
Author's Address
Thomas Martin Knoll
Chemnitz University of Technology
Email: knoll@etit.tu-chemnitz.de
Knoll Expires July 11, 2009 [Page 18]