One document matched: draft-wu-pce-pcep-link-bw-utilization-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-wu-pce-pcep-link-bw-utilization-00"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="TE Link BW Utilization">Extensions to Path Computation
Element Communication Protocol (PCEP) for handling Link Bandwidth
Utilization</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies</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="Dhruv Dhody" initials="D" surname="Dhody">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc</organization>
<address>
<postal>
<street>Via Del Serafico 200 </street>
<city>Rome</city>
<code>00191 </code>
<country>IT</country>
</postal>
<email>sprevidi@cisco.com </email>
</address>
</author>
<date month="October" year="2013" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs)
requests.</t>
<t>Link bandwidth utilization considering the total bandwidth of a link
in current use for the forwarding is an important factor to consider
during path computation. This document describes extensions to PCEP to
consider them as new constraints during path computation.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>Real time link bandwidth utilization is becoming critical in the path
computation in some networks. It is important that link bandwidth
utilization is factored in during path computation. PCC can request a
PCE to provide a path such that it selects under-utilized links. This
document extends PCEP <xref target="RFC5440"></xref> for this
purpose.</t>
<t>Traffic Engineering Database (TED) as populated by Interior Gateway
Protocol (IGP) contains Maximum bandwidth, Maximum reservable bandwidth
and Unreserved bandwidth (<xref target="RFC3630"></xref> and <xref
target="RFC3784"></xref>). <xref target="OSPF-TE-EXPRESS"></xref> and
<xref target="ISIS-TE-EXPRESS"></xref> further populate Residual
bandwidth and Available bandwidth. Further <xref
target="ISIS-TE-EXPRESS"></xref> also define Bandwidth Utilization.</t>
<t>[Editors Note: <xref target="OSPF-TE-EXPRESS"></xref> should also be
extended in future version for real time link bandwidth utilization]</t>
<t>The links in the path MAY be monitored for changes in the link
bandwidth utilization, re-optimization of such path MAY be further
requested.</t>
<section title="Requirements Language" toc="default">
<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"></xref>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t><list style="hanging">
<t hangText="IGP:">Interior Gateway Protocol. Either of the two
routing protocols, Open Shortest Path First (OSPF) or Intermediate
System to Intermediate System (IS-IS).</t>
<t hangText="PCC:">Path Computation Client: any client application
requesting a path computation to be performed by a Path Computation
Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component,
application, or network node) that is capable of computing a network
path or route based on a network graph and applying computational
constraints.</t>
<t hangText="PCEP:">Path Computation Element Protocol.</t>
<t hangText="RSVP:">Resource Reservation Protocol</t>
<t hangText="TE LSP:">Traffic Engineering Label Switched Path.</t>
</list></t>
</section>
<section anchor="SEC_LBU" title="Link Bandwidth Utilization (LBU)"
toc="default">
<t>The bandwidth utilization on a link, forwarding adjacency, or bundled
link is populated in the TED (Bandwidth Utilization in <xref
target="ISIS-TE-EXPRESS"></xref>). For a link or forwarding adjacency,
bandwidth utilization represent the actual utilization of the link
(i.e.: as measured in the router). For a bundled link, bandwidth
utilization is defined to be the sum of the component link bandwidth
utilization. This includes traffic for both RSVP and non-RSVP.</t>
<t>LBU Percentage is described as the (LBU / Maximum bandwidth) *
100.</t>
</section>
<section anchor="SEC_LRBU"
title="Link Reserved Bandwidth Utilization (LRBU)" toc="default">
<t>The reserved bandwidth utilization on a link, forwarding adjacency,
or bundled link can be calculated from the TED. This includes traffic
for only RSVP-TE LSPs.</t>
<t>LRBU can be calculated by using the Residual bandwidth, available
bandwidth and LBU. The actual bandwidth by non-RSVP TE traffic can be
calculated by subtracting Available Bandwidth from Residual Bandwidth.
Once we have the actual bandwidth for non-RSVP TE traffic, subtracting
this from LBU would result in LRBU.</t>
<t>LRBU Percentage is described as the (LRBU / (current reserved
bandwidth)) * 100; where the current reserved bandwidth can be
calculated by subtracting Residual bandwidth from Maximum bandwidth.</t>
</section>
<section anchor="SEC_R" title="PCEP Requirements" toc="default">
<t>Following requirements associated with bandwidth utilization are
identified for PCEP:</t>
<t><list style="numbers">
<t>PCE supporting this draft MUST have the capability to compute
end-to-end path with bandwidth utilization constraints. It MUST also
support the combination of bandwidth utilization constraint with
existing constraints (cost, hop-limit...).</t>
<t>PCC MUST be able to request for bandwidth utilization constraint
in PCReq message as the boundary condition that should not be
crossed for each link in the path.</t>
<t>PCC MUST be able to request for bandwidth utilization constraint
in PCReq message as an Objective function (OF) <xref
target="RFC5541"></xref> to be optimized.</t>
<t>PCEs are not required to support bandwidth utilization
constraint. Therefore, it MUST be possible for a PCE to reject a
PCReq message with a reason code that indicates no support for
bandwidth utilization constraint.</t>
<t>PCEP SHOULD provide mechanism to handle bandwidth utilization
constraint in multi-domain (e.g., Inter-AS, Inter-Area or
Multi-Layer) environment.</t>
</list></t>
</section>
<section title="PCEP Extensions" toc="default">
<t>This section defines extensions to PCEP <xref
target="RFC5440"></xref> for requirements outlined in <xref
target="SEC_R"></xref>. The proposed solution is used to consider
bandwidth utilization during path computation.</t>
<section title="BU Object" toc="default">
<t>The BU (Bandwidth Utilization) is used to indicate the upper limit
of the acceptable link bandwidth utilization percentage.</t>
<t>The BU object may be carried within the PCReq message and PCRep
messages.</t>
<t>BU Object-Class is TBD.</t>
<t>Two Object-Type values are defined for the BU object:</t>
<t><list style="symbols">
<t>Link Bandwidth Utilization (LBU): BU Object-Type is 1.</t>
<t>Link Reserved Bandwidth Utilization (LRBU): BU Object-Type is
2.</t>
</list></t>
<t>The format of the BU object body is as follows:</t>
<figure align="left" alt="" height="" suppress-title="false"
title="BU Object Body Format" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Bandwidth utilization (32 bits):">Represents the
bandwidth utilization quantified as a percentage (as described in
<xref target="SEC_LBU"></xref> and <xref
target="SEC_LRBU"></xref>). The basic unit is 0.000000023%, with
the maximum value 4,294,967,295 representing 98.784247785%
(4,294,967,295 * 0.000000023%). This value is the maximum
Bandwidth utilization percentage that can be expressed.</t>
</list></t>
<t>The BU object body has a fixed length of 4 bytes.</t>
<section anchor="SEC_N" title="Elements of Procedure" toc="default">
<t>PCC SHOULD request the PCE to factor in the bandwidth utilization
during path computation by including a BU object in the PCReq
message.</t>
<t>Multiple BU objects MAY be inserted in a PCReq or a PCRep message
for a given request but there MUST be at most one instance of the BU
object for each object type. If, for a given request, two or more
instances of a BU object with the same object type are present, only
the first instance MUST be considered and other instances MUST be
ignored.</t>
<t>BU object MAY be carried in a PCRep message in case of
unsuccessful path computation along with a NO-PATH object to
indicate the constraints that could not be satisfied.</t>
<t>If the P bit is clear in the object header and PCE does not
understand or does not support bandwidth utilization during path
computation it SHOULD simply ignore BU object.</t>
<t>If the P Bit is set in the object header and PCE receives BU
object in path request and it understands the BU object, but the PCE
is not capable of bandwidth utilization check during path
computation, the PCE MUST send a PCErr message with a PCEP-ERROR
Object Error-Type = 4 (Not supported object) <xref
target="RFC5440"></xref>. The path computation request MUST then be
cancelled.</t>
<t>If the PCE does not understand the BU object, then the PCE MUST
send a PCErr message with a PCEP-ERROR Object Error-Type = 3
(Unknown object) <xref target="RFC5440"></xref>.</t>
</section>
</section>
<section title="New Objective Functions" toc="default">
<t>This document defines two additional objective functions -- namely,
MUP (Maximum Under-Utilized Path) and MRUP (Maximum Reserved
Under-Utilized Path. Hence two new objective function codes have to be
defined.</t>
<t>Objective functions are formulated using the following
terminology:</t>
<t><list style="symbols">
<t>A network comprises a set of N links {Li, (i=1...N)}.</t>
<t>A path P is a list of K links {Lpi,(i=1...K)}.</t>
<t>Bandwidth Utilization on link L is denoted u(L).</t>
<t>Reserved Bandwidth Utilization on link L is denoted ru(L).</t>
<t>Maximum bandwidth on link L is denoted M(L).</t>
<t>Current Reserved bandwidth on link L is denoted c(L).</t>
</list></t>
<t>The description of the two new objective functions is as
follows.</t>
<t><list style="hanging">
<t hangText="Objective Function Code:">TBD</t>
<t><list>
<t>Name: Maximum Under-Utilized Path (MUP)</t>
<t>Description: Find a path P such that (Min {(M(Lpi)- u(Lpi))
/ M(Lpi), i=1...K } ) is maximized.</t>
</list></t>
</list></t>
<t><list style="hanging">
<t hangText="Objective Function Code:">TBD</t>
<t><list>
<t>Name: Maximum Reserved Under-Utilized Path (MRUP)</t>
<t>Description: Find a path P such that (Min {(c(Lpi)-
ru(Lpi)) / c(Lpi), i=1...K } ) is maximized.</t>
</list></t>
</list></t>
<t>These new objective function are used to optimize paths based on
bandwidth utilization as the optimization criteria.</t>
<t>If the objective function defined in this document are
unknown/unsupported, the procedure as defined in <xref
target="RFC5541"></xref> is followed.</t>
</section>
<section title="PCEP Message" toc="default">
<t>The new optional BU objects MAY be specified in the PCReq message.
As per <xref target="RFC5541"></xref>, an OF object specifying a new
objective function MAY also be specified.</t>
<t>The format of the PCReq message (with <xref
target="RFC5541"></xref> as a base) is updated as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC>[<metric-list>]
</artwork>
</figure>
<t>The BU objects MAY be specified in the PCRep message, in case of an
unsuccessful path computation to indicate the bandwidth utilization as
a reason for failure. The OF object MAY be carried within a PCRep
message to indicate the objective function used by the PCE during path
computation.</t>
<t>The format of the PCRep message (with <xref
target="RFC5541"></xref> as a base) is updated as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<IRO>]
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC> [<metric-list>]
</artwork>
</figure>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="Reoptimization Consideration" toc="default">
<t>PCC can monitor the link bandwidth utilization of the setup LSPs
and in case of drastic change, it MAY ask PCE for reoptimization as
per <xref target="RFC5440"></xref>.</t>
</section>
<section title="Inter-domain Consideration" toc="default"></section>
<section title="P2MP Consideration" toc="default"></section>
<section title="Stateful PCE" toc="default"></section>
</section>
<section title="IANA Considerations" toc="default">
<t>TBD</t>
</section>
<section title="Security Considerations" toc="default">
<t>TBD</t>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines a new BU object and OF codes which does not add
any new security concerns beyond those discussed in <xref
target="RFC5440"></xref>.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>The only configurable item is the support of the new constraints on
a PCE which MAY be controlled by a policy module. If the new
constraints are not supported/allowed on a PCE, it MUST send a PCErr
message as specified in <xref target="SEC_N"></xref>.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="PCEP-MIB"></xref> describes the PCEP MIB, there are
no new MIB Objects for this document.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in <xref target="RFC5440"></xref>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in <xref
target="RFC5440"></xref>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>PCE requires the TED to be populated with the bandwidth
utilization. This mechanism is described in <xref
target="OSPF-TE-EXPRESS"></xref> or <xref
target="ISIS-TE-EXPRESS"></xref>.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in <xref
target="RFC5440"></xref>.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Alia Atlas, John E Drake, David Ward for their
useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3630.xml" ?>
<?rfc include="reference.RFC.3784.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<!--OSPF-TE-EXPRESS-->
<reference anchor="OSPF-TE-EXPRESS">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions
[draft-ietf-ospf-te-metric-extensions]</title>
<author fullname="Spencer Giacalone" initials="S"
surname="Giacalone">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D" surname="Ward">
<organization></organization>
</author>
<author fullname="John Drake" initials="J" surname="Drake">
<organization></organization>
</author>
<author fullname="Alia Atlas" initials="A" surname="Atlas">
<organization></organization>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
</reference>
<!--ISIS-TE-EXPRESS-->
<reference anchor="ISIS-TE-EXPRESS">
<front>
<title>IS-IS Traffic Engineering (TE) Metric Extensions
[draft-ietf-isis-te-metric-extensions-01]</title>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization></organization>
</author>
<author fullname="Spencer Giacalone" initials="S"
surname="Giacalone">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D" surname="Ward">
<organization></organization>
</author>
<author fullname="John Drake" initials="J" surname="Drake">
<organization></organization>
</author>
<author fullname="Alia Atlas" initials="A" surname="Atlas">
<organization></organization>
</author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<organization></organization>
</author>
<author fullname="Qin Wu" initials="W" surname="Qin">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<!--PCEP-MIB-->
<reference anchor="PCEP-MIB">
<front>
<title>PCE communication protocol(PCEP) Management Information Base
[draft-ietf-pce-pcep-mib]</title>
<author fullname="Kiran Koushik A S" initials="A S"
surname="Kiran Koushik">
<organization></organization>
</author>
<author fullname="Stephan E" initials="E" surname="Stephan">
<organization></organization>
</author>
<author fullname="Quintin Zhao" initials="Q" surname="Zhao">
<organization></organization>
</author>
<author fullname="Daniel King" initials="D" surname="King">
<organization></organization>
</author>
<author fullname="John Hardwick" initials="J" surname="Hardwick">
<organization></organization>
</author>
<date month="Feb" year="2013" />
</front>
</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">
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
</artwork>
</figure></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:40:08 |