One document matched: draft-ietf-idr-te-pm-bgp-00.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-ietf-idr-te-pm-bgp-00" 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 Metrics</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>bill.wu@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>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>00191</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization abbrev="Juniper">Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Saikat Ray" initials="S." surname="Ray">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170, West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>sairay@cisco.com</email>
</address>
</author>
<date year="2014" />
<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, packet loss and bandwidth 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, available bandwidth and utilized bandwidth
).</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 which enable
establishing segment overlay tunnel between overlay nodes and stitching
them together to compute end to end path.</t>
<t>In order to populate network performance information like link
latency, latency variation, packet loss and bandwidth 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, available bandwidth,
and utilized bandwidth). The network performance information can be
distributed in the same way as link state information distribution,i.e.,
either directly or via a peer BGP speaker (see figure 1 of
[I.D-ietf-idr-ls-distribution]).</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 H-PCE">
<t>For inter-AS path computation the Hierarchical PCE (H-PCE)
[RFC6805] may be used to compute the optimal sequence of domains.
Within the H-PCE architecture, the child PCE communicates domain
connectivity information to the parent PCE, and the parent PCE will
use this information to compute a multi-domain path based on the
optimal TE links between domains [I.D-ietf-pce-hierarchy-extensions]
for the end-to-end path.</t>
<t>The following figure demonstrates how a parent PCE may obtain 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 ALTO Server can aggregate information from multiple systems to
provide an abstract and unified view that can be more useful to
applications.</t>
<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:<figure>
<artwork>
Type Value
TBD1 Unidirectional Link Delay
TBD2 Min/Max Unidirectional Link Delay
TBD3 Unidirectional Delay Variation
TBD4 Unidirectional Packet Loss
TBD5 Unidirectional Residual Bandwidth
TBD6 Unidirectional Available Bandwidth
TBD7 Unidirectional Utilized Bandwidth
</artwork>
</figure><vspace blankLines="1" /><!--< - - !
When this draft(v-01) was presented in the IDR WG session of Berlin meeting,John Scudder suggested to define new attributes(i.e.,link utilization attribute, channel throughput attribute) added in the previous version of this draft in the draft-ietf-isis-te-metric-extensions. After Berlin meeting, Hannes Gredler help initiate discussion with authors of IGP drafts(i.e., draft-ietf-isis-te-metric-extensions and draft-ietf-ospf-te-metric-extensions) on why two additional attributes should be added into IGPdraft. After a few offline discussion with authors of IGP drafts, specially with John Drake, David Ward, Alia Atlas,Stefano Previdi,it was roughly agreed that
a.drop channel throughput attribute since it is node attribute rather than link attribute.
b.and add link utilization attribute into IGP drafts.
However the open issue is whether defining total Link Utilization as Currently Utilized Bandwidth or as Currently Utilized Bandwidth / Maximum Bandwidth. Until this openissue is resolved, the link utilization attribute will the added into the update of this draft as seventh additional TLV.
- - >--></t>
<t>As can be seen in the list above, the TLVs described in this document
carry different types of network performance information. These TLVs
include a bit called the Anomalous (or "A") bit at the left-most bit
after length field of each TLV defined in figure 4 of
[[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets
after length field of each TLV is reserved for future use. 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 exceeds configurable maximum
thresholds, a TLV with the A bit set is advertised. These TLVs could be
used by the receiving BGP peer 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 falls below a configurable value,
that TLV can be re- advertised with the Anomalous bit cleared. In this
case, a receiving BGP peer 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 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 [ISIS-TE-METRIC], the
bandwidth advertisements, the delay and delay variation advertisements,
packet loss defined in this document MUST be encoded in the same unit as
one defined in IS-IS Extended IS Reachability sub-TLVs [ISIS-TE-METRIC].
All values (except residual bandwidth) MUST be obtained by a filter that
is reasonably representative of an average or calculated as rolling
averages where the averaging period MUST be a configurable period of
time. The measurement interval, any filter coefficients, and any
advertisement intervals MUST be configurable per sub-TLV in the same way
as ones defined in section 5 of [ISIS-TE-METRIC].</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 '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- |
| | Link Delay | | METRIC]/4.1 |
| | | | |
| xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE- |
| | Link Delay | | METRIC]/4.2 |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
| | Delay Variation | | METRIC]/4.3 |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
| | Link Loss | | METRIC]/4.4 |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
| |Residual Bandwidth | | METRIC]/4.5 |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
| |Available Bandwidth | | METRIC]/4.6 |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
| |Utilized Bandwidth | | METRIC]/4.7 |
+------------+---------------------+--------------+-----------------+
Table 1: Link Attribute TLVs</artwork>
</figure><vspace blankLines="1" /><!--< - - !
The open issue is whether defining total Link Utilization as Currently Utilized Bandwidth or as Currently Utilized Bandwidth / Maximum Bandwidth? We will add link utilization attribute as seventh additional attribute(e.g.,Currently Utilized Bandwidth) when the open issue is resolved.
- - >--></t>
</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>
<reference anchor="I.D-ietf-pce-hierarchy-extensions">
<front>
<title>Extensions to Path Computation Element Communication Protocol
(PCEP) for Hierarchical Path Computation Elements (PCE)</title>
<author fullname="F.Zhang" initials="F." surname="Zhang">
<organization></organization>
</author>
<author fullname="Q.Zhao" initials="Q." surname="Zhao">
<organization></organization>
</author>
<author fullname="O.Gonzalez de Dios" initials="O."
surname="Gonzalez de Dios">
<organization></organization>
</author>
<author fullname="R.Casellas" initials="R." surname="Casellas">
<organization></organization>
</author>
<author fullname="D.King" initials="D." surname="King">
<organization></organization>
</author>
<date day="" month="August" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-pce-hierarchy-extensions-00" />
</reference>
</references>
<section title="Contributor Addresses" toc="default">
<t><figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
US
Email: Jeff.Tantsura@ericsson.com
</artwork>
</figure></t>
</section>
<section title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section title="draft-ietf-idr-te-pm-bgp-00">
<t>The following are the major changes compared to previous version
draft-wu-idr-te-pm-bgp-03:<vspace blankLines="1" /><list
style="symbols">
<t>Update PCE case in section 3.1.</t>
<t>Add some texts in section 1 and section 4 to clarify from where
to distribute pm info and measurement interval and method.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:12 |