One document matched: draft-knoll-idr-cos-interconnect-04.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-cos-interconnect-04"
ipr="trust200902" submissionType="IETF">
<front>
<title abbrev="BGP CoS Interconnect">BGP Class of Service
Interconnection</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="10" month="May" year="2010" />
<area>Routing Area</area>
<workgroup>Inter-Domain Routing Working Group</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>This document focuses on Class of Service Interconnection at
inter-domain interconnection points. It specifies two new transitive
attributes, which enable adjacent peers to signal Class of Service
Capabilities and certain Class of Service admission control Parameters.
The new "CoS Capability" is deliberately kept simple and denotes the
general EF, AF Group BE and LE forwarding support across the advertising
AS. The second "CoS Parameter Attribute" is of variable length and
contains a more detailed description of available forwarding behaviours
using the PHB id Code encoding. Each PHB id Code is associated with rate
and size based traffic parameters, which will be applied in the ingress
AS Border Router for admission control purposes to a given forwarding
behaviour.</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>AS interconnection is currently based on best effort interconnection
only. BGP-4 <xref target="RFC4271"></xref> is the de-facto
interconnection 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
<xref target="RFC2475"></xref> as AS internal QoS mechanism. Within this
architecture, there are 64 codepoints and an unlimited number of Per Hop
Behaviours (PHBs) available. Some PHBs have been defined in separate
RFCs, which will be focused on in this document.</t>
<t>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 <xref target="RFC3246"></xref>, the
"Assured Forwarding (AF)" PHB Group <xref target="RFC2597"></xref> and
the "Lower Effort" Per-Domain Behavior (PDB) <xref
target="RFC3662"></xref>. AS providers, which can support this Basic CoS
are asked to signal this capability to their interconnection partners by
means of the new CoS Capability Extended Community defined in <xref
target="CoS_Capability_Attribute"></xref> of this draft.</t>
<t>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.</t>
<t>A second transitive attribute is defined in <xref
target="CoS_Parameter_Attribute"></xref>, 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 interconnection 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.</t>
<t>Both attributes are likely to be used together, if ingress class
limitation is used for the respective AS.</t>
<t>More detailed signalling of forwarding behaviour distinction and
associated cross-layer marking can be achieved using the QoS Marking
Attribute approach <xref
target="I-D.knoll-idr-qos-attribute"></xref>.</t>
</section>
<section anchor="CoS_Capability_Attribute"
title="Definition and Usage of the CoS Capability">
<t></t>
<section title="Extended Community Type">
<t>The new CoS Capability is encoded as a BGP Extended Community <xref
target="RFC4360"></xref>. Extended Community Attributes are transitive
optional BGP attributes 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 CoS Capability is 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 transitive across ASes. The type number has been assigned
by IANA to 0xYY (0x00-0x3f).</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 x x x x x x| |
+-+-+-+-+-+-+-+-+ 7 octet CoS Capability structure |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
</section>
<section title="Structure of the CoS Capability Attribute">
<t>The CoS Capability structure is deliberately kept very simple and
is defined as follows.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B E A L| Currently Unused - default to '0' |
|E F F E| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Currently Unused - default to '0' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Currently Unused bits default to '0' and MUST be ignored on
reception.</t>
<t></t>
<t>Leading "BE, EF, AF and LE" encoding.</t>
<t><list style="hanging">
<t>This encoding signals the BE, EF, AF Group and LE support of
the respective AS.</t>
<texttable align="left" anchor="Table_1"
title="CoS support encoding">
<ttcol>Bit</ttcol>
<ttcol>Encoding</ttcol>
<c>BE</c>
<c>Default to ‘1’ to signal general “Best
Effort” PHB support</c>
<c>EF</c>
<c>‘1’ … “Expedited Forwarding”
PHB support <xref target="RFC3246" /></c>
<c>AF</c>
<c>‘1’ … “Assured Forwarding” PHB
group support <xref target="RFC2597" /></c>
<c>LE</c>
<c>‘1’ … “Lower Effort” PDB
support <xref target="RFC3662" /></c>
</texttable>
<t>The implied Per-Hop-Behaviour Identification Codes follow the
definition as standardized in <xref target="RFC3140" />. The AF
Group needs to consist of at least one of the currently available
AF1x, AF2x, AF3x and AF4x.</t>
</list></t>
<figure anchor="Figure_3">
<artwork><![CDATA[BE:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EF:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 0 1 1 1 0 | 0 0 0 0 0 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
AF1x:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
AF2x:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 1 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
AF3x:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
AF4x:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LE:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 0 1 0 0 0 | 0 0 0 0 0 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t></t>
</section>
<section title="Usage of the CoS Capability Attribute">
<t>The CoS Capability is used as primitive means to signal the general
availability of the set of "Basic CoS" PHBs in the advertising AS.
This Extended Community 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.</t>
<t>All other reachability information MUST be signalled together with
this CoS Capability if they were received together with such an
Extended Community by neighbouring peers.</t>
<t>NLRI MUST NOT be marked as supporting "Basic CoS" by means of the
CoS Capability, if it were not received together with such an
attribute.</t>
</section>
</section>
<section anchor="CoS_Parameter_Attribute"
title="Definition and Usage of the CoS Parameter Attribute">
<section title="Definition of the CoS Parameter Attribute">
<t>The CoS Parameter Attribute is an optional transitive BGP
attribute.</t>
<t>The attribute contains one or more of the following:</t>
<figure anchor="Figure_4">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>PHB ID:</t>
<t><list style="hanging">
<t>This field specifies the targeted Per Hop Behaviour limitations
and follows the defined encoding of <xref target="RFC3140"></xref>
as listed in <xref target="Figure_3"></xref>.</t>
</list></t>
<t>Flags:</t>
<figure>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|G |DR|0 |0 |0 |0 |0 |0 |
+--+--+--+--+--+--+--+--+]]></artwork>
</figure>
<t><list style="hanging">
<t>Only two flags are defined. The remaining bits default to '0'
and MUST be ignored on reception.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>ASN of sending AS:</t>
<t><list style="hanging">
<t>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.</t>
</list></t>
<t>Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum
Policed Unit and Maximum Packet Size:</t>
<t><list style="hanging">
<t>The rates and sizes are given in 4 octet IEEE floating point
format <xref target="IEEE"></xref> 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 <xref
target="RFC2210"></xref> and <xref target="RFC2215"></xref>.</t>
</list></t>
<t></t>
</section>
<section title="Usage of the CoS Parameter Attribute">
<t>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.</t>
<t>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.</t>
<t>The resulting treatment for non-confirming traffic is signalled
through the 'DR' flag.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The attribute SHOULD NOT be transitively relayed to non-adjacent
interconnection partners.</t>
</section>
</section>
<section anchor="Confidentiality" title="Confidentiality Considerations">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>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.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
<t>This document defines a new BGP attribute. This attribute is optional
and transitive.</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 version.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2210"?>
<?rfc include="reference.RFC.2215"?>
<?rfc include="reference.RFC.2597"?>
<?rfc include="reference.RFC.3140"?>
<?rfc include="reference.RFC.3246"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.4360"?>
<reference anchor="IEEE">
<front>
<title>IEEE Standard for Binary Floating-Point Arithmetic</title>
<author fullname="" initials="" surname="">
<organization>IEEE</organization>
</author>
<date day="" month="" year="1985" />
</front>
<seriesInfo name="ISBN" value="1-5593-7653-8" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3662"?>
<?rfc include="reference.RFC.2475"?>
<?rfc include="reference.I-D.knoll-idr-qos-attribute.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-25 12:28:51 |