One document matched: draft-wu-pce-pcep-link-bw-utilization-03.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-03"
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 the 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="June" year="2014" />
<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>The Link bandwidth utilization (the total bandwidth of a link
in current use for the forwarding) is an important factor to consider
during path computation. <xref target="OSPF-TE-EXPRESS"></xref> and
<xref target="ISIS-TE-EXPRESS"></xref> define mechanisms that
distribute this information via OSPF and
ISIS respectively. This document describes extensions to PCEP to
use them as new constraints during path computation.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The link bandwidth utilization based on real time traffic along
the path is becoming critical during path
computation in some networks. Thus it is important that the link bandwidth
utilization is factored in during path computation. A 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>The Traffic Engineering Database (TED) as populated by the Interior Gateway
Protocol (IGP) contains the Maximum bandwidth, the Maximum reservable bandwidth
and the 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 the Residual
bandwidth, the Available bandwidth and the Utilized bandwidth.</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>
<t><xref target="OSPF-TE-EXPRESS"></xref> and
<xref target="ISIS-TE-EXPRESS"></xref> also include parameters related
to link latency, latency variation and packet loss.
<xref target="PCE-SERVICE-AWARE"></xref> describes extensions to
PCEP to consider them.</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="LBU:">Link Bandwidth Utilization. (See <xref
target="SEC_LBU"></xref>.)</t>
<t hangText="LRBU:">Link Reserved Bandwidth Utilization. (See <xref
target="SEC_LRBU"></xref>.)</t>
<t hangText="MRUP:">Maximum Reserved Under-Utilized Path.
(See <xref target="SEC_OF"></xref>.)</t>
<t hangText="MUP:">Maximum Under-Utilized Path.
(See <xref target="SEC_OF"></xref>.)</t>
<t hangText="OF:">Objective Function. A set of one or more optimization
criteria used for the computation of a single path (e.g.,
path cost minimization) or for the synchronized computation
of a set of paths (e.g., aggregate bandwidth consumption
minimization, etc). (See <xref target="RFC5541"></xref>.)</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 the network node) that is capable of computing a network
path or the route based on a network graph and applying computational
constraints.</t>
<t hangText="PCEP:">Path Computation Element Communication 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 (Utilized Bandwidth in
<xref target="OSPF-TE-EXPRESS"></xref> and <xref
target="ISIS-TE-EXPRESS"></xref>). For a link or forwarding adjacency,
the bandwidth utilization represents the actual utilization of the link
(i.e., as measured in the router). For a bundled link, the 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, the Available
bandwidth and LBU. The actual bandwidth by non-RSVP TE traffic can be
calculated by subtracting the Available Bandwidth from the 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 / (Maximum reservable
bandwidth)) * 100.</t>
</section>
<section anchor="SEC_R" title="PCEP Requirements" toc="default">
<t>The following requirements associated with the bandwidth utilization are
identified for PCEP:</t>
<t><list style="numbers">
<t>The PCE supporting this document MUST have the capability to compute
end-to-end path with the bandwidth utilization constraints. It MUST also
support the combination of the bandwidth utilization constraint with
the existing constraints (cost, hop-limit...).</t>
<t>The PCC MUST be able to request for the bandwidth utilization constraint
in PCReq message as the upper limit that should not be
crossed for each link in the path.</t>
<t>The PCC MUST be able to request for the 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 the 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
the bandwidth utilization constraint.</t>
<t>PCEP SHOULD provide a mechanism to handle the 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> to meet requirements outlined in <xref
target="SEC_R"></xref>. The proposed solution is used to consider
the bandwidth utilization during path computation.</t>
<section title="BU Object" toc="default">
<t>The BU (the 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>BU Object-Type is 1.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Reserved (24 bits):">This field MUST be set to zero
on transmission and MUST be ignored on receipt.</t>
<t hangText="Type (8 bits):">Represents the bandwidth utilization
type. Link Bandwidth Utilization (LBU) Type is 1 and
Link Reserved Bandwidth Utilization (LRBU) Type is
2.</t>
<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 8 bytes.</t>
<section anchor="SEC_N" title="Elements of Procedure" toc="default">
<t>A 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 type. If, for a given request, two or more
instances of a BU object with the same 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 the 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 the 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" anchor="SEC_OF">
<t>This document defines two additional objective functions -- namely,
MUP (the Maximum Under-Utilized Path) and MRUP (the 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>The Bandwidth Utilization on link L is denoted u(L).</t>
<t>The Reserved Bandwidth Utilization on link L is denoted ru(L).</t>
<t>The Maximum bandwidth on link L is denoted M(L).</t>
<t>The Maximum Reserved bandwidth on link L is denoted R(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 {(R(Lpi)-
ru(Lpi)) / R(Lpi), i=1...K } ) is maximized.</t>
</list></t>
</list></t>
<t>These new objective functions are used to optimize paths based on
the 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 Extension" toc="default">
<section title="The PCReq message" toc="default" anchor="SEC_REQ">
<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>
</section>
<section title="The PCRep message" toc="default" anchor="SEC_REP">
<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>
<section title="Other Considerations" toc="default">
<section title="Reoptimization Consideration" toc="default">
<t>PCC can monitor the link bandwidth utilization of an LSP
by monitoring changes in the bandwidth utilization parameters of
one or more links on the path in the TED. 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">
<t><xref target="RFC5441"/> describes the Backward-Recursive
PCE-Based Computation (BRPC) procedure to compute end to end
optimized inter-domain path by cooperating PCEs. The new BU object
defined in this document can be applied to end to end path
computation, in similar manner as existing METRIC object. </t>
<t>All domains should have the same understanding of the BU object
for end-to-end inter-domain path computation
to make sense.</t>
<section title="Inter-AS Link" toc="default">
<t>The IGP in each neighbor domain can advertise its inter-domain
TE link capabilities, this has been described in <xref target="RFC5316"/>
(ISIS) and <xref target="RFC5392"/> (OSPF). The bandwidth related network
performance link properties are described in <xref target="OSPF-TE-EXPRESS"/> and
<xref target="ISIS-TE-EXPRESS"/>, the same properties must be advertised
using the mechanism described in <xref target="RFC5392"/> (OSPF) and
<xref target="RFC5316"/> (ISIS).</t>
</section>
</section>
<section title="P2MP Consideration" toc="default">
<t>They are currently out of scope of this document.</t>
</section>
<section title="Stateful PCE" toc="default">
<t><xref target="STATEFUL-PCE"></xref> specifies a set of
extensions to PCEP to enable
stateful control of MPLS-TE and GMPLS LSPs via PCEP and maintaining
of these LSPs at the stateful PCE. It further distinguishes between
an active and a passive stateful PCE. A passive stateful PCE uses LSP state
information learned from PCCs to optimize path computations but does
not actively update LSP state. In contrast, an active stateful PCE
utilizes the LSP delegation mechanism to let PCCs relinquish control
over some LSPs to the PCE. </t>
<t>The passive stateful PCE implementation MAY use the extension of
PCReq and PCRep messages as defined in <xref target="SEC_REQ"/> and
<xref target="SEC_REP"/> to enable the use of BU object.</t>
<t>The additional objective functions defined in this document can also
be used with stateful PCE.</t>
<section title="PCEP Message Extension" toc="default">
<section title="The PCRpt message" toc="default">
<t>A Path Computation LSP State
Report message (also referred to as PCRpt message) is a PCEP message
sent by a PCC to a PCE to report the current state or delegate control
of an LSP. The PCRpt message is extended to support BU object. This
optional BU object can specify the upper limit that should not be crossed.</t>
<t>As per <xref target="STATEFUL-PCE"></xref>, the format of the PCRpt
message is as follows:</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
<PCRpt Message> ::= <Common Header>
<state-report-list>
where:
<state-report-list> ::= <state-report> [<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
<path> ::= <ERO><attribute-list>[<RRO>]
</artwork>
</figure>
<t>Where <attribute-list> is extended as per <xref target="SEC_REP"/> for BU object.</t>
<t>Thus a BU object can be used to specify the upper limit set at the PCC at the
time of LSP delegation to an active stateful PCE.</t>
</section>
</section>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>IANA assigns values to PCEP parameters in registries defined in
<xref target="RFC5440"/>. IANA has made the following additional assignments.</t>
<section title="New PCEP Object" toc="default">
<t>IANA assigned a new object class in the registry of PCEP Objects as
follows.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Object Object Name Reference
Class Type
--------------------------------------------------
TBD 1 BU [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="BU Object" toc="default">
<t>IANA created a registry to manage the codespace of the Type field
of the METRIC Object.</t>
<t>Codespace of the T field (Metric Object)</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Type Name Reference
--------------------------------------------------
1 LBU (Link Bandwidth [This I.D.]
Utilization
2 LRBU (Link Residual [This I.D.]
Bandwidth Utilization
]]></artwork>
</figure>
</t>
</section>
<section title="Objective Functions" toc="default">
<t>Two new Objective Functions have been
defined. IANA has made the following allocations from the PCEP
"Objective Function" sub-registry:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Code Name Reference
Point
--------------------------------------------------
TBA Maximum Under-Utilized [This I.D.]
Path (MUP)
TBA Maximum Reserved [This I.D.]
Under-Utilized Path (MRUP)
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines a new BU object and OF codes which do 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 and 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.5316.xml" ?>
<?rfc include="reference.RFC.5392.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<!--OSPF-TE-EXPRESS-->
<reference anchor="OSPF-TE-EXPRESS">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions</title>
<author initials="S" surname="Giacalone" fullname="Spencer Giacalone">
<organization/>
</author>
<author initials="D" surname="Ward" fullname="David Ward">
<organization/>
</author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization/>
</author>
<author initials="A" surname="Atlas" fullname="Alia Atlas">
<organization/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization/>
</author>
<date month="December" day="5" year="2013"/>
<abstract>
<t>
In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to OSPF TE [RFC3630] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ospf-te-metric-extensions-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-metric-extensions-05.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-metric-extensions-05.pdf"/>
</reference>
<!--ISIS-TE-EXPRESS-->
<reference anchor="ISIS-TE-EXPRESS">
<front>
<title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization/>
</author>
<author initials="S" surname="Giacalone" fullname="Spencer Giacalone">
<organization/>
</author>
<author initials="D" surname="Ward" fullname="David Ward">
<organization/>
</author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization/>
</author>
<author initials="A" surname="Atlas" fullname="Alia Atlas">
<organization/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
<organization/>
</author>
<author initials="W" surname="Wu" fullname="Wenson Wu">
<organization/>
</author>
<date month="April" day="26" year="2014"/>
<abstract>
<t>
In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC5305) such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-isis-te-metric-extensions-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-isis-te-metric-extensions-03.txt"/>
</reference>
<!--PCEP-MIB-->
<reference anchor="PCEP-MIB">
<front>
<title>
Path Computation Element Protocol (PCEP) Management Information Base
</title>
<author initials="K" surname="Koushik" fullname="Kiran Koushik">
<organization/>
</author>
<author initials="S" surname="Emile" fullname="Stephan Emile">
<organization/>
</author>
<author initials="Q" surname="Zhao" fullname="Quintin Zhao">
<organization/>
</author>
<author initials="D" surname="King" fullname="Daniel King">
<organization/>
</author>
<author initials="J" surname="Hardwick" fullname="Jonathan Hardwick">
<organization/>
</author>
<date month="April" day="2" year="2014"/>
<abstract>
<t>
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-mib-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-mib-08.txt"/>
</reference>
<!--STATEFUL-PCE-->
<reference anchor="STATEFUL-PCE">
<front>
<title>PCEP Extensions for Stateful PCE</title>
<author initials="E" surname="Crabbe" fullname="Edward Crabbe">
<organization/>
</author>
<author initials="J" surname="Medved" fullname="Jan Medved">
<organization/>
</author>
<author initials="I" surname="Minei" fullname="Ina Minei">
<organization/>
</author>
<author initials="R" surname="Varga" fullname="Robert Varga">
<organization/>
</author>
<date month="February" day="14" year="2014"/>
<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. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-stateful-pce-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-stateful-pce-08.txt"/>
</reference>
<!--PCE-SERVICE-AWARE-->
<reference anchor="PCE-SERVICE-AWARE">
<front>
<title>
Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).
</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<author initials="V" surname="Manral" fullname="Vishwas Manral">
<organization/>
</author>
<author initials="Z" surname="Ali" fullname="Zafar Ali">
<organization/>
</author>
<author initials="G" surname="Swallow" fullname="George Swallow">
<organization/>
</author>
<author initials="K" surname="Kumaki" fullname="Kenji Kumaki">
<organization/>
</author>
<date month="March" day="2" year="2014"/>
<abstract>
<t>
In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet Loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectively. 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. This document describes the extension to PCEP to carry Latency, Latency-Variation and Packet Loss as constraints for end to end path computation.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-service-aware-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-service-aware-04.txt"/>
</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
Avantika
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: avantika.sushilkumar@huawei.com
Zafar Ali
Cisco Systems
EMail: zali@cisco.com
</artwork>
</figure></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:36:19 |