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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   PHB id Code                 |     Flags     | Reserved = '0'|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ASN of sending AS                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Token Bucket Rate [r] (32-bit IEEE floating point number)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Token Bucket Size [b] (32-bit IEEE floating point number)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Peak Data Rate [p] (32-bit IEEE floating point number)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Minimum Policed Unit [m] (32-bit integer)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Maximum Packet Size [M] (32-bit integer)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4

PHB ID:

This field specifies the targeted Per Hop Behaviour limitations and follows the defined encoding of [RFC3140] as listed in Figure 3.

Flags:

 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
|G |DR|0 |0 |0 |0 |0 |0 |
+--+--+--+--+--+--+--+--+

Only two flags are defined. The remaining 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' flag 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.

ASN of sending AS:

Depending on the 2-octet or 4-octet AS peering type, the sending AS of the attribute MUST encode its AS number as right-aligned 32bit number.

Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed Unit and Maximum Packet Size:

The rates and sizes are given in 4 octet IEEE floating point format [IEEE] or 4 octet integer format, respectively. They are parameters to a token bucket ingress filter, which is applied to the packets belonging to the stated PHB id. The parameters follow the definition given in [RFC2210] and [RFC2215].

3.2. Usage of the CoS Parameter Attribute

The signalled parameters are used for 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.

To withdraw a previously signalled limitation, a CoS Parameter Attribute for the respective PHB id Code MUST be sent with a rate value [r] of zero. Using the 'G' flag, this can be withdrawn globally for all traffic of the given PHB id Code or withdrawn only for traffic destined to the prefixes given in the NLRI of the UPDATE. Previously signalled non-global (i.e. NLRI specific) limitations are also waived, if the same prefix is advertised without a CoS Parameter Attribute later on. In this case, the missing attribute is considered as the above described 'rate zero update' for those prefixes. Waived prefix specific limitations do not supersede global limitations for the respective PHB id Code. In turn, a withdrawal of a global limitation does also withdraw any possibly existing prefix specific ones for the respective PHB id Code.

All limitations have AS local scope for the advertising AS and the neighbouring AS might or might not adopt its sending behaviour to those advertised limitations.

Despite the transitive nature of the new attribute, its usage for ingress limitation is confined to neighbouring ASes. Processing of the conveyed parameters is only valid for peers, who are peering with the AS specified in the ASN field of the attribute.

The attribute SHOULD NOT be transitively relayed to non-adjacent interconnection partners.

4. Confidentiality Considerations

The disclosure of confidential AS intrinsic information by means of the signalled Basic CoS support is of low key security concern. The disclosure of information through CoS Parameter signalling is more detailed. However, all included parameters are exchanged with direct interconnection partners and are the free choice of each AS provider.

5. IANA Considerations

This document defines a new BGP Extended Community, which needs to be assigned a number by IANA within the Extended Community list. The new CoS Capability is a BGP Extended Community of regular type. It is IANA-assignable (FCFS procedure) and is transitive across ASes. A number assignment application within the numbering range of 0x00-0x3f is made to IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

This document defines a new BGP attribute. This attribute is optional and transitive.

6. Security Considerations

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

The signalled attributes are transitive with limited relay operation in the CoS Parameter Attribute case. 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.

7. References

7.1. Normative References

[IEEE]	, , "IEEE Standard for Binary Floating-Point Arithmetic", ISBN 1-5593-7653-8, 1985.
[RFC1997]	Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2210]	Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997.
[RFC2215]	Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, DOI 10.17487/RFC2215, September 1997.
[RFC2597]	Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999.
[RFC3140]	Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, DOI 10.17487/RFC3140, June 2001.
[RFC3246]	Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002.
[RFC4271]	Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006.
[RFC4360]	Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006.

7.2. Informative References

[I-D.knoll-idr-qos-attribute]	Knoll, T., "BGP Extended Community for QoS Marking", Internet-Draft draft-knoll-idr-qos-attribute-18, July 2016.
[RFC2475]	Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998.
[RFC3662]	Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003.

Author's Address