| TOC |
|
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 15, 2009.
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 peering 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.
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
2.
Problem Statement
3.
Related Work
4.
Definition of the QoS Marking Attribute
4.1.
Extended Community Type
4.2.
Structure of the QoS Marking Attribute
4.3.
Technology Type Enumeration
5.
Attribute Usage
5.1.
QoS Marking Attribute Example
5.2.
AS Border Packet Forwarding
5.3.
IP Prefix Aggregation
6.
Confidentiality Considerations
7.
IANA Considerations
8.
Security Considerations
9.
References
9.1.
Normative References
9.2.
Informative References
Appendix A.
QoS Marking Attribute Example
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) 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 (Definition of the QoS Marking Attribute). 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.
| TOC |
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.
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 (Confidentiality Considerations). 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.
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.
| TOC |
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] (Cristallo, G., “The BGP QOS_NLRI Attribute,” February 2004.) 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] (Boucadair, M., “QoS-Enhanced Border Gateway Protocol,” July 2005.) 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] (Benmohamed, L., “QoS Enhancements to BGP in Support of Multiple Classes of Service,” June 2006.). 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] (Zhang, Z., “ExtCommunity map and carry TOS value of IP header,” November 2005.). 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.
The most comprehensive analysis (although not an IETF draft) is given in [MIT_CFP] (Amante, S., Bitar, N., Bjorkman, N., and others, “Inter-provider Quality of Service - White paper draft 1.1,” November 2006.). 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] (Fedyk, D., Rekhter, Y., and H. Ould-Brahim, “BGP Traffic Engineering Attribute,” December 2008.). 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] (Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, “Dissemination of flow specification rules,” May 2009.). 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.
| TOC |
| TOC |
The new QoS Marking Attribute is encoded as a BGP Extended Community Attribute [RFC4360] (Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” February 2006.). It is therefore a transitive optional BGP attribute with Type Code 16. An adoption to the simple BGP Community Attribute encoding [RFC1997] (Chandrasekeran, R., Traina, P., and T. Li, “BGP Communities Attribute,” August 1996.) 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] (IANA, “Border Gateway Protocol (BGP) Data Collection Standard Communities,” June 2008.).
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 |
| TOC |
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 Oh| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS Marking Ol| QoS Marking A | P. Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2 |
Flags:
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 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 cross-layer linking between the QoS class encodings. It can also be used for the specification of behaviour sets are given in the [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.). 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 (Technology Type Enumeration). 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] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.). 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, 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 peering 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.
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'.
| TOC |
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 |
| TOC |
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.
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, 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.
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,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 |
| TOC |
See Appendix A (QoS Marking Attribute Example) for an example QoS Marking Attribute Set.
| TOC |
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.
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.
There is no outgoing remarking, if the targeted class is not supported by the neighbouring AS.
| TOC |
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'.
| TOC |
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.
| TOC |
This document defines a new BGP Extended Community Attribute, which includes a "Technology Type" field. Section 4.3 (Technology Type Enumeration) 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.
| TOC |
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.
| TOC |
| TOC |
| [IANA_EC] | IANA, “Border Gateway Protocol (BGP) Data Collection Standard Communities,” June 2008. |
| [RFC1997] | Chandrasekeran, R., Traina, P., and T. Li, “BGP Communities Attribute,” RFC 1997, August 1996 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3140] | Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” RFC 3140, June 2001 (TXT). |
| [RFC4271] | Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” RFC 4271, January 2006 (TXT). |
| [RFC4360] | Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute,” RFC 4360, February 2006 (TXT). |
| TOC |
| [I-D.boucadair-qos-bgp-spec] | Boucadair, M., “QoS-Enhanced Border Gateway Protocol,” draft-boucadair-qos-bgp-spec-01 (work in progress), July 2005 (TXT). |
| [I-D.ietf-idr-flow-spec] | Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, “Dissemination of flow specification rules,” draft-ietf-idr-flow-spec-09 (work in progress), May 2009 (TXT). |
| [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 (TXT). |
| [I-D.jacquenet-bgp-qos] | Cristallo, G., “The BGP QOS_NLRI Attribute,” draft-jacquenet-bgp-qos-00 (work in progress), February 2004 (TXT). |
| [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 (TXT). |
| [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 (TXT). |
| [MIT_CFP] | Amante, S., Bitar, N., Bjorkman, N., and others, “Inter-provider Quality of Service - White paper draft 1.1,” November 2006. |
| TOC |
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 |
| TOC |
| 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 |
| TOC |
Copyright © 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.
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.