BGP Class of Service Interconnection

AS interconnection is currently based on best effort peering only. BGP-4 is the de-facto peering protocol used to exchange reachability information. There is no standardized set of supported traffic classes, no standardized packet marking and no standardized forwarding behaviour, which cross-domain traffic could rely on. QoS policy decisions are taken by AS providers independently and in an uncoordinated fashion. However, many AS providers make use of the Differentiated Services Architecture as AS internal QoS mechanism. Within this architecture, there are 64 codepoints and an unlimited number of Per Hop Behaviours (PHBs) possible. Some PHBs have been defined in separate RFCs, which will be focused on in this document. A Basic Set of supported Classes, called "Basic CoS" is defined inhere, which consists of the primitive "Best Effort (BE)" PHB, the "Expedited Forwarding (EF)" PHB and the "Assured Forwarding (AF)" PHB Group . AS providers, which can support this Basic CoS are asked to signal this capability to their peering partners by means of the new CoS Capability Attribute defined in of this draft. 4 AF PHB classes have been defined so far, which will be grouped into the generally signalled "AF Group". That is, as long as the AS provider can support at least one out of the 4 AF classes in his externally supported CoS Set, this AS is regarded as AF capable. A second non-transitive attribute is defined in , which is used for parameter signalling about the applied access control within the ingress AS Border Router. The reason for this traffic limitation is the fact, that certain high quality forwarding behaviours can only be achieved, if the percentage of high priority traffic within the traffic mix lies below a certain threshold. This attribute informs the peering partner about the applied limitation, which can in turn be used to perform traffic shaping at the neighbouring AS egress. The attribute allows this limitation signalling either associated to the NLRI within the same UPDATE message or with "global" scope to describe the generally applied ingress limitation. Both attributes are likely to be used together, if ingress class limitation is used for the respective AS. More detailed signalling of forwarding behaviour distinction and associated cross-layer marking can be achieved using the QoS Marking Attribute approach .

The new CoS Capability Attribute is encoded as a BGP Extended Community Attribute . Extended Community Attributes are transitive optional BGP attribute with Type Code 16. An adoption to the simple BGP Community Attribute encoding is not defined in this document. The actual encoding within the BGP Extended Community Attribute is as follows. The CoS Capability Attribute is non-transitive and of regular type which results in a 1 octet Type field followed by 7 octets for the CoS Capability structure. The Type is IANA-assignable (FCFS procedure) and marks the community as non-transitive across ASes. The type number has been assigned by IANA to 0xYY (0x40-0x7f).

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

The CoS Capability Attributes structure is deliberately kept very simple and is defined as follows.

The Currently Unused bits default to '0' and must be ignored on reception. Leading "111" encoding. This encoding signals the BE, EF and AF Group support of the respective AS. The implied Per-Hop-Behaviour Identification Codes follow the definition as standardized in . The AF Group needs to consist of at least one of the available AF1x, AF2x, AF3x and AF4x.

The CoS Capability Attribute is used as primitive means to signal the general availability of the set of "Basic CoS" PHBs in the advertising AS. The attribute is included within the attribute section of an BGP UPDATE message and is therefore associated to the NLRI information of the same message. Whether the Basic CoS is available and is therefore advertised can easily being judged on for all prefixes, which originate from the advertising AS. All other reachability information MUST be signalled together with this CoS Capability Attribute if they were received together with such an Attribute by neighbouring peers. NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS Capability Attribute, if it were not received together with such an Attribute.

The CoS Parameter Attribute is an optional non-transitive BGP attribute. The attribute contains one or more of the following:

PHB ID: This field specifies the targeted Per Hop Behaviour limitations and follows the defined encoding of Flags:

Only two flags are defines. The resulting bits default to '0' and must be ignored on reception. The 'G' flag signals, whether the limitations have global scope on all incoming traffic ('1') or are associated to traffic that is destined to destinations within the NLRI of the UPDATE message ('0'). NLRI specific limitation will supersede globally signalled ones for traffic destined to those NLRI destinations. The 'DR' flags signals the applied handling of non-confirming traffic. DR='0' signals strict dropping of excess traffic. DR='1' signals the performed remarking of excess traffic packets to Best Effort traffic marking. Peak Rate, Token Bucket Rate and Token Bucket Size: The rates and sizes are given in 4 octet IEEE floating point format .

The signalled Parameter as used of PHB id Code based ingress limitation. Depending on which PHB id Codes a BGP peer signals in this attribute to its neighbour, it is said, that the respective PHB id Code is supported and will experience the defined limitations. Those limitations can be applied to all incoming traffic of a specific PHB id Code (marked as 'G') or only for incoming traffic, that is destined for the NLRI of the given UPDATE message. The resulting treatment for non-confirming traffic is signalled through the 'DR' flag. All limitations have AS local scope for the advertising AS and the peering AS might or might not adopt its sending behaviour to those advertised limitations.

The disclosure of confidential AS intrinsic information by means of the signalled Basic CoS support is certainly of low key security concern. The disclosure of information through CoS Parameter signalling is more detailed. However, the attribute is non-transitive and all included parameters are the free choice of each AS provider.

This document defines a new BGP Extended Community Attribute, which needs to be assigned a number by IANA within the Extended Community Attribute list. The new CoS Capability Attribute is a BGP Extended Community Attribute of regular type. It is IANA-assignable (FCFS procedure) and is non-transitive across ASes. An number assignment application within the numbering range of 0x40-0x7f is made to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. This document defines a second BGP attribute. This attribute is optional and non-transitive and need to be assigned an appropriate number as well.

This extension to BGP does not change the underlying security issues inherent in the existing BGP. The signalled attributes are non-transitive, which limits the reach of possibly applied malicious attribute modifications. AS peers, which use egress traffic shaper on the signalled limitations should exhaust all available BGP security features to make sure, that the signalled limitation is actually sent by the adjacent peer.