One document matched: draft-wu-idr-te-pm-bgp-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-idr-te-pm-bgp-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="BGP for TE performance">BGP attribute for North-Bound
Distribution of Traffic Engineering (TE) performance Metric</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Danhua Wang" initials="D." surname="Wang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>wangdanhua@huawei.com</email>
</address>
</author>
<date year="2013" />
<area>Routing Area</area>
<workgroup>IDR Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Inter-Domain Routing</keyword>
<abstract>
<t>In order to populate network performance information like link
latency, latency variation and packet loss into Traffic Engineering
Database(TED) and ALTO server, this document describes extensions to BGP
protocol, that can be used to distribute network performance information
(such as link delay, delay variation, packet loss, residual bandwidth,
and available bandwidth, link utilization, channel throughput). </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>As specified in [RFC4655],a Path Computation Element (PCE) is an
entity that is capable of computing a network path or route based on a
network graph, and of applying computational constraints during the
computation In order to compute an end to end path, the PCE needs to
have a unified view of the overall
topology[I-D.ietf-pce-pcep-service-aware]. [I.D-ietf-idr-ls-
distribution] describes a mechanism by which links state and traffic
engineering information can be collected from networks and shared with
external components using the BGP routing protocol. This mechanism can
be used by both PCE and ALTO server to gather information about the
topologies and capabilities of the network. </t>
<t>With the growth of network virtualization technology, the needs for
inter-connection between various overlay technologies (e.g. Enterprise
BGP/MPLS IP VPNs) in the Wide Area Network (WAN) become important. The
Network performance or QoS requirements such as latency, limited
bandwidth, packet loss, and jitter, are all critical factors that must
be taken into account in the end to end path computation
([I-D.ietf-pce-pcep-service-aware])and selection to establish segment
overlay tunnel between overlay nodes and stitch them together to compute
end to end path. </t>
<t>In order to populate network performance information like link
latency, latency variation and packet loss into TED and ALTO server,
this document describes extensions to BGP protocol, that can be used to
distribute network performance information (such as link delay, delay
variation, packet loss, residual bandwidth, and available bandwidth,link
utilization, channel throughput).</t>
</section>
<section title="Conventions used in this document">
<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">RFC2119</xref>.</t>
</section>
<section title="Use Cases">
<section title="MPLS-TE with PCE">
<t>The following figure shows how a PCE can get its TE performance
information beyond that contained in the LINK_STATE attributes
[I.D-ietf-idr-ls-distribution] using the mechanism described in this
document.</t>
<figure>
<artwork>
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with TE performance
| v | NLRI
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
Figure 1: External PCE node using a TED synchronization mechanism
</artwork>
</figure>
</section>
<section title="ALTO Server Network API">
<t>The following figure shows how an ALTO Server can get TE
performance information from the underlying network beyond that
contained in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution]
using the mechanism described in this document.</t>
<figure>
<artwork>
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | TE Performance | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | NLR | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
Figure 2: ALTO Server using network performance information
</artwork>
</figure>
</section>
</section>
<section title="Carrying TE Performance information in BGP">
<t>This document proposes new BGP TE performance TLVs that can be
announced as attribute in the BGP-LS attribute (defined in
[I.D-ietf-idr- ls-distribution]) to distribute network performance
information. The extensions in this document build on the ones provided
in BGP-LS [I.D -ietf-idr-ls-distribution] and BGP-4 [RFC4271]. </t>
<t>BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested
TLVs which allow the BGP-LS attribute to be readily extended. This
document proposes seven additional TLVs as its attributes: </t>
<figure>
<artwork>
Type Value
TBD1 Unidirectional Link Delay
TBD2 Unidirectional Delay Variation
TBD3 Unidirectional Packet Loss
TBD4 Unidirectional Residual Bandwidth
TBD5 Unidirectional Available Bandwidth
TBD6 Link Utilization
TBD7 Channel Throughput
</artwork>
</figure>
<t>As can be seen in the list above, the TLVs described in this document
carry different types of network performance information. Many (but not
all) of the TLVs include a bit called the Anomalous (or "A") bit. When
the A bit is clear (or when the TLV does not include an A bit), the TLV
describes steady state link performance. This information could
conceivably be used to construct a steady state performance topology for
initial tunnel path computation, or to verify alternative failover
paths.</t>
<t>When network performance downgrades and falls below configurable
link-local thresholds a TLV with the A bit set is advertised. These TLVs
could be used by the receiving node to determine whether to redirect
failing traffic to a backup path, or whether to calculate an entirely
new path. If link performance improves later and exceeds a configurable
minimum value (i.e.,threshold), that TLV can be re-advertised with the
Anomalous bit cleared. In this case, a receiving node can conceivably do
whatever re-optimization (or failback) it wishes to do (including
nothing).</t>
<t>Note that when a TLV does not include the A bit, that sub-TLV cannot
be used for failover purposes. The A bit was intentionally omitted from
some TLVs to help mitigate oscillations.</t>
<t>Consistent with existing ISIS TE specifications
[RFC5305][ISIS-TE-METRIC], the bandwidth advertisements defined in this
document MUST be encoded as IEEE floating point values. The delay and
delay variation advertisements defined in this draft MUST be encoded as
integer values. Delay values MUST be quantified in units of
microseconds, packet loss MUST be quantified as a percentage of packets
sent, and bandwidth MUST be sent as bytes per second. All values (except
residual bandwidth) MUST be calculated as rolling averages where the
averaging period MUST be a configurable period of time.</t>
</section>
<section title="Attribute TLV Details">
<t>Link attribute TLVs defined in section 3.2.2 of [I-D.
ietf-idr-ls-distribution]are TLVs that may be encoded in the BGP-LS
attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/
Value (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-
idr-ls-distribution]. The format and semantics of the 'value' fields in
some 'Link Attribute' TLVs correspond to the format and semantics of
value fields in IS-IS Extended IS Reachability sub-TLVs, defined in
[RFC5305]. Although the encodings for 'Link Attribute' TLVs were
originally defined for IS-IS, the TLVs can carry data sourced either by
IS-IS or OSPF. </t>
<t>The following 'Link Attribute' TLVs are valid in the LINK_STATE
attribute: <figure>
<artwork>
+------------+---------------------+--------------+-----------------+
| TLV Code | Description | IS-IS | Defined in: |
| Point | | TLV/Sub-TLV | |
+------------+---------------------+--------------+-----------------+
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.1 |
| | Link Delay | | |
| | | | |
| xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE]/4.2 |
| | Link Delay | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.3 |
| | Delay Variation | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.4 |
| | Link Loss | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.5 |
| |Residual Bandwidth | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.6 |
| |Available Bandwidth | | |
| | | | |
| xxxx | Link Utilization | ---- | section 5.1 |
| | | | |
| xxxx | Channel Throughput | ---- | section 5.2 |
+------------+---------------------+--------------+-----------------+
Table 1: Link Attribute TLVs</artwork>
</figure></t>
<section title="Link Utilization TLV">
<t>This TLV advertises the average link utilization between two
directly connected IS-IS neighbors. The link utilization advertised by
this sub-TLV MUST be the utilization percentage per interval from the
local neighbor to the remote one. The format of this sub-TLV is shown
in the following diagram:</t>
<figure>
<artwork> 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBA
Length: 4
Link Utilization. This 24-bit field carries the average
link untilization over a configurable interval. A commonly
used time interval is 5 minutes, and this interval has been
sufficient to support network operations and design for some
time. link utilization can be calculated by counting the
IP-layer (or other layer) octets received over a time interval
and dividing by the theoretical maximum number of octets that
could have been delivered in the same interval(see section6.4
of [RFC6703]). If there is no value to send (unmeasured and
not statically specified), then the sub-TLV should not be sent
or be withdrawn.
</artwork>
</figure>
</section>
<section title="Channel Throughput TLV">
<t>This TLV advertises the average Channel Throughput between two
directly connected IS-IS neighbors. The channel throughput advertised
by this sub-TLV MUST be the throughput between the local neighbor and
the remote one. The format of this sub-TLV is shown in the following
diagram:</t>
<figure>
<artwork> 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput Offered |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput Delivered |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBA
Length: 8
Throughput offered: This 24-bit field carries the average
throughput offered over a configurable interval. Throughput
offered can be calculated by counting the number of
units successfully transmitted in the interval
(See section 2.3 of [RFC6374)). If there is no value to
send (unmeasured and not statically specified), then
the sub-TLV should not be sent or be withdrawn.
Throughput delivered: This 24-bit field carries the average
throughput delivered over a configurable interval.
Throughput delivered can be calculated by counting the
number of units successfully received in the interval
(See section 2.3 of [RFC6374)). If there is no value
to send (unmeasured and not statically specified),
then the sub-TLV should not be sent or be withdrawn.
</artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce security issues beyond those
discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271].</t>
</section>
<section title="IANA Considerations">
<t>IANA maintains the registry for the TLVs. BGP TE Performance TLV will
require one new type code per TLV defined in this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-idr-ls-distribution">
<front>
<title>North-Bound Distribution of Link-State and TE Information
using BGP</title>
<author fullname="H.Gredler" initials="H." surname="Gredler">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03" />
</reference>
<reference anchor="I-D.ietf-pce-pcep-service-aware">
<front>
<title>Extensions to the Path Computation Element Communication
Protocol (PCEP) to compute service aware Label Switched Path (LSP)
</title>
<author fullname="D.Dhruv" initials="D." surname="Dhruv">
<organization></organization>
</author>
<date month="July" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-pce-pcep-service-aware-01" />
</reference>
<reference anchor="ISIS-TE-METRIC">
<front>
<title abbrev="RFC Key Words">ISIS Traffic Engineering (TE) Metric
Extensions</title>
<author fullname="S.Giacalone" initials="S." surname="Giacalone">
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-isis-te-metric-extensions-00" />
</reference>
<reference anchor="RFC5305">
<front>
<title>IS-IS Extensions for Traffic Engineering</title>
<author fullname="T.Li" initials="T." surname="Li">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5305" />
<format target="http://www.rfc-editor.org/rfc/rfc5305.txt" type="TXT" />
</reference>
<reference anchor="RFC4271">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization></organization>
</author>
<date month="January" year="2006" />
</front>
<seriesInfo name="RFC" value="4271" />
<format target="http://www.rfc-editor.org/rfc/rfc4271.txt" type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author fullname="A.Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4655" />
</reference>
<reference anchor="ALTO">
<front>
<title>ALTO Protocol</title>
<author fullname="Y.Yang" initials="Y." surname="Yang">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID"
value="http://tools.ietf.org/html/draft-ietf-alto-protocol-16" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:26 |