One document matched: draft-knoll-idr-qos-attribute-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-knoll-idr-qos-attribute-03" ipr="trust200811"
submissionType="IETF">
<front>
<title abbrev="BGP QoS Marking Attribute">BGP Extended Community Attribute
for QoS Marking</title>
<author fullname="Thomas Martin Knoll" initials="Th. M." surname="Knoll">
<organization>Chemnitz University of Technology</organization>
<address>
<email>knoll@etit.tu-chemnitz.de</email>
</address>
</author>
<date day="7" month="January" year="2009" />
<area>Routing Area</area>
<workgroup>Inter-Domain Routing Working Group</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>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 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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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 <xref
target="RFC4271"></xref> 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.</t>
<t>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 <xref target="Attribute_Definition"></xref>.
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.</t>
<t>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.</t>
</section>
<section title="Problem Statement">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The general confidentiality concern of disclosing AS internal policy
information is addressed in <xref target="Confidentiality"></xref>. 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
achieved.</t>
<t>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.</t>
<t></t>
</section>
<section title="Related Work">
<t>A number of QoS improvement approaches have been proposed before and
a selection will be briefly mentioned in this section.</t>
<t>Most of the approaches perform parameter signalling. <xref
target="I-D.jacquenet-bgp-qos"></xref> 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.</t>
<t><xref target="I-D.boucadair-qos-bgp-spec"> </xref> 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.</t>
<t>Another approach is described in <xref
target="I-D.liang-bgp-qos"></xref>. 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.</t>
<t>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 <xref
target="I-D.zhang-idr-bgp-extcommunity-qos"></xref>. The TOS value is
signalled within an Extended Community Attribute and, if it is
understood correctly, will be applied to a certain route. An 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.</t>
<t>The most comprehensive analysis (although not an IETF draft) is given
in <xref target="MIT_CFP"></xref>. 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.</t>
<t>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.</t>
<t>One example is the usage of the "Traffic Engineering Attribute" as
defined in <xref target="I-D.ietf-softwire-bgp-te-attribute"></xref>.
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.</t>
<t>The second example is the current "Dissemination of flow
specification rules" draft <xref
target="I-D.ietf-idr-flow-spec"></xref>. 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.</t>
</section>
<section anchor="Attribute_Definition"
title="Definition of the QoS Marking Attribute" toc="default">
<t></t>
<section title="Extended Community Type">
<t>The new QoS Marking attribute is encoded as a BGP Extended
Community Attribute <xref target="RFC4360"></xref>. It is therefore a
transitive optional BGP attribute with Type Code 16. An adoption to
the simple BGP Community Attribute encoding <xref
target="RFC1997"></xref> is not defined in this document. The actual
encoding within the BGP Extended Community Attribute is as
follows.</t>
<t>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 <xref
target="IANA_EC"></xref>.</t>
<t>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.</t>
<figure anchor="Figure_1">
<artwork><![CDATA[ 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Structure of the QoS Marking Attribute">
<t>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.</t>
<figure anchor="Figure_2">
<artwork><![CDATA[ 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Flags:</t>
<figure anchor="Figure_3">
<artwork><![CDATA[ 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|0 0 0 |R |I |A |0 |0 |
+--+--+--+--+--+--+--+--+
]]></artwork>
</figure>
<t><list style="hanging">
<t>All used and unused flags default to a value of
‘0’. The following table shows the bit encoding of the
Flags field.</t>
</list></t>
<texttable align="left" anchor="Table_1">
<ttcol>Bit</ttcol>
<ttcol>Flag</ttcol>
<ttcol>Encoding</ttcol>
<c>0-2</c>
<c>unused</c>
<c>Default to ‘0’</c>
<c>3</c>
<c>R</c>
<c>‘1’ … remarking occurred</c>
<c>4</c>
<c>I</c>
<c>‘1’ … QoS marking ignored</c>
<c>5</c>
<c>A</c>
<c>‘1’ … QoS class aggregation occurred</c>
<c>6,7</c>
<c>unused</c>
<c>Default to ‘0’</c>
</texttable>
<t></t>
<t><list style="hanging">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>QoS Set Number:</t>
<t><list style="hanging">
<t>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 <xref target="RFC3140"></xref>. 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.</t>
</list></t>
<t>Technology Type:</t>
<t>The technology type encoding uses the enumeration list <xref
target="tech_type">in</xref>. Future version of this draft will need
an extended enumeration list administered by IANA.</t>
<t>QoS Marking / Enumeration O & A:</t>
<t>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.</t>
<t>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.</t>
<t>QoS Marking O (Original QoS Marking):<list style="hanging">
<t>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 <xref target="RFC3140"></xref>. The
field MUST remain unchanged in BGP UPDATE messages of relaying
nodes.</t>
</list></t>
<t>QoS Marking A (Active QoS Marking):<list style="hanging">
<t>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.</t>
<t>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.</t>
</list></t>
<t></t>
</section>
<section anchor="tech_type" title="Technology Type Enumeration">
<t>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.</t>
<texttable align="left" anchor="Table_3">
<ttcol>Value</ttcol>
<ttcol>Technology Type</ttcol>
<c>0x00</c>
<c>DiffServ enabled IP (DSCP encoding)</c>
<c>0x01</c>
<c>Ethernet using 802.1q priority tag</c>
<c>0x02</c>
<c>MPLS using E-LSP</c>
<c>0x03</c>
<c>Virtual Channel (VC) encoding using separate channels for QoS
forwarding / one channel per class (e.g. ATM VCs, FR VCs, MPLS
L-LSPs)</c>
<c>0x04</c>
<c>GMPLS – time slot encoding</c>
<c>0x05</c>
<c>GMPLS – lambda encoding</c>
<c>0x06</c>
<c>GMPLS – fibre encoding</c>
</texttable>
</section>
</section>
<section title="Attribute Usage">
<t>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.</t>
<t>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.</t>
<t><xref target="Figure_4"></xref> 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.</t>
<figure anchor="Figure_4">
<artwork><![CDATA[ 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]]></artwork>
</figure>
<section title="QoS Marking Attribute Example">
<t>See <xref target="appendix_a"></xref> for an example QoS Marking
attribute Set.</t>
</section>
<section title="AS Border Packet Forwarding">
<t>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.</t>
<t>Identical QoS class sets and encodings between neighbouring ASes do
not require any remarking. Different encodings will be matched on the
outgoing traffic.</t>
<t>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.</t>
<t>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.</t>
<t>There is no outgoing remarking, if the targeted class is not
supported by the neighbouring AS.</t>
</section>
<section title="IP Prefix Aggregation">
<t>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.</t>
<t>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'.</t>
</section>
</section>
<section anchor="Confidentiality" title="Confidentiality Considerations">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines a new BGP Extended Community Attribute, which
includes a "Technology Type" field. <xref target="tech_type"></xref>
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.</t>
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This extension to BGP does not change the underlying security issues
inherent in the existing BGP.</t>
<t>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.</t>
<t>The IP prefix originating AS MAY place a copy of its marking
information into the Internet Routing Registry (IRR) for global
reference.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IANA_EC"
target="http://www.iana.org/assignments/bgp-extended-communities">
<front>
<title>Border Gateway Protocol (BGP) Data Collection Standard
Communities</title>
<author fullname="IANA" initials="" surname="IANA">
<organization></organization>
</author>
<date day="10" month="June" year="2008" />
</front>
</reference>
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3140"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.4360"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.boucadair-qos-bgp-spec.xml"?>
<?rfc include="reference.I-D.jacquenet-bgp-qos.xml"?>
<?rfc include="reference.I-D.liang-bgp-qos.xml"?>
<?rfc include="reference.I-D.zhang-idr-bgp-extcommunity-qos.xml"?>
<?rfc include="reference.I-D.ietf-softwire-bgp-te-attribute.xml"?>
<?rfc include="reference.I-D.ietf-idr-flow-spec.xml"?>
<reference anchor="MIT_CFP"
target="http://cfp.mit.edu/docs/interprovider-qos-nov2006.pdf">
<front>
<title>Inter-provider Quality of Service - White paper draft
1.1</title>
<author fullname="Amante, Shane" initials="S." surname="Amante">
<organization></organization>
</author>
<author fullname="Bitar, Nabil" initials="N." surname="Bitar">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Bjorkman, Nils" initials="N." surname="Bjorkman">
<organization>N.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author>
<organization>others</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="17" month="November" year="2006" />
</front>
</reference>
</references>
<section anchor="appendix_a" title="QoS Marking Attribute Example">
<t>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.</t>
<figure anchor="Figure_5">
<artwork><![CDATA[ 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.
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-26 04:02:30 |