One document matched: draft-ietf-pce-pcep-service-aware-07.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 ipr="trust200902" category="std" docName="draft-ietf-pce-pcep-service-aware-07" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="SERVICE-AWARE">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 abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<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>bill.wu@huawei.com</email>
</address>
</author>
<author initials="V" surname="Manral" fullname="Vishwas Manral">
<organization>Ionos Network</organization>
<address>
<postal>
<street>4100 Moorpark Av</street>
<city>San Jose</city>
<region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>vishwas.ietf@gmail.com</email>
</address>
</author>
<author initials="Z" surname="Ali" fullname="Zafar Ali">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>zali@cisco.com</email>
</address>
</author>
<author initials="K" surname="Kumaki" fullname="Kenji Kumaki">
<organization>KDDI Corporation</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>ke-kumaki@kddi.com</email>
</address>
</author>
<date month="February" year="2015" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<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 are becoming key requirements for path computation
along with other constraints and metrics. These metrics are associated with the
Service Level Agreement (SLA) between customers and service
providers. The Link Bandwidth Utilization (the total bandwidth of
a link in current use for the forwarding) is another important
factor to consider during path computation.</t>
<t>IGP Traffic Engineering (TE) Metric extensions describes mechanisms with
which network performance information is distributed via
OSPF and IS-IS 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, Packet Loss, and Link Bandwidth Utilization
as constraints for end to end path computation.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>Real time network performance is becoming critical in the
path computation in some networks. Mechanisms to measure Latency,
Latency-Variation, and Packet Loss in an MPLS network are
described in <xref target="RFC6374"/>. Further, there exist
mechanisms to measure these network performance metrics after
the LSP has been established, which is inefficient.
It is important that Latency, Latency Variation, and Packet
Loss are considered during path selection process, even before
the LSP is set up.</t>
<t>Link bandwidth utilization based on real time traffic along
the path is also becoming critical during path
computation in some networks. Thus it is important that the Link
bandwidth
utilization is factored in during path computation itself.</t>
<t>Traffic Engineering Database (TED) is populated with network
performance information like link latency, latency variation, and
packet loss through <xref target="OSPF-TE-METRIC-EXT"/> or
<xref target="ISIS-TE-METRIC-EXT"/>. Path Computation Client (PCC)
can request Path Computation Element (PCE) to provide a path
meeting end to end network performance criteria. This document
extends Path Computation Element Communication Protocol (PCEP)
<xref target="RFC5440"/> to handle network performance constraint. </t>
<t><xref target="OSPF-TE-METRIC-EXT"/> and
<xref target="ISIS-TE-METRIC-EXT"/> include parameters related
to bandwidth (Residual bandwidth, Available bandwidth and Utilized
bandwidth); this document also 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"/>.</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="IS-IS:">Intermediate System to Intermediate System.</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="MPLP:">Minimum Packet Loss Path.
(See <xref target="SEC_OF"></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="OSPF:">Open Shortest Path First.</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="RSVP:">Resource Reservation Protocol</t>
<t hangText="TE:">Traffic Engineering.</t>
</list>
</t>
</section>
<section title="PCEP Requirements" toc="default" anchor="SEC_R">
<t>End-to-end service optimization based on latency, latency variation,
packet loss, and link bandwidth utilization is a key requirement
for service provider. Following key
requirements associated are
identified for PCEP: </t>
<t>
<list style="numbers">
<t>PCE supporting this draft MUST have the capability to compute
end-to-end (E2E) path with latency, latency variation, packet loss,
and bandwidth utilization
constraints. It MUST also support the combination of network
performance constraint (latency, latency variation, loss...)
with existing constraints (cost, hop-limit...).</t>
<t>PCC MUST be able to request for E2E network performance
constraint(s) in PCReq message as the key constraint to be
optimized or to suggest boundary condition that should not be
crossed. </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 these constraint
in PCReq message as an Objective function (OF) <xref
target="RFC5541"></xref> to be optimized.</t>
<t>PCEs are not required to support service aware path computation.
Therefore, it MUST be possible for a PCE to reject a PCReq message
with a reason code that indicates no support for service-aware path
computation.</t>
<t>PCEP SHOULD provide a means to return end to end network performance
information of the computed path in a PCRep message.</t>
<t>PCEP SHOULD provide mechanism to compute multi-domain (e.g., Inter-AS,
Inter-Area or Multi-Layer) service aware paths. </t>
</list>
</t>
<t>It is assumed that such constraints are only meaningful if used
consistently: for instance, if the delay of a computed path segment is
exchanged between two PCEs residing in different domains, consistent
ways of defining the delay must be used.</t>
</section>
<section title="PCEP Extensions" toc="default">
<t>This section defines PCEP extensions (see <xref target="RFC5440"/>)
for requirements outlined in <xref target="SEC_R"/>. The proposed
solution is used to support network performance and service aware
path computation. </t>
<section title="Extensions to METRIC Object" toc="default">
<t>The METRIC object is defined in section 7.8 of <xref target="RFC5440"/>,
comprising of metric-value, metric-type (T field) and flags. This document
defines the following optional types for the
METRIC object.</t>
<!--PM-DIR <t> This document defines the following optional types for the
METRIC object defined in section 7.8 of <xref target="RFC5440"/>. </t>-->
<t>For explanation of these metrics, the following terminology
is used and expanded along the way.</t>
<t>- A network comprises of a set of N links {Li, (i=1...N)}.</t>
<t>- A path P of a P2P LSP is a list of K links {Lpi,(i=1...K)}.</t>
<section title="Latency (Delay) Metric" toc="default">
<t>Link delay metric is defined in <xref target="OSPF-TE-METRIC-EXT"/> and
<xref target="ISIS-TE-METRIC-EXT"/> as "Unidirectional Link Delay".
P2P latency metric type of METRIC object
in PCEP encodes the sum of the link delay metric of all links along a P2P
Path. Specifically, extending on the above mentioned terminology: </t>
<t>- A Link delay metric of link L is denoted D(L).</t>
<t>- A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. </t>
<t>This is as per sum of means composition function (section 4.2.5 of
<xref target="RFC6049"/>).</t>
<t>* Metric Type T=TBD1: Latency metric </t>
<t>PCC MAY use this latency metric in PCReq message to request a path
meeting the end to end latency requirement. In this case B bit MUST be
set to suggest a bound (a maximum) for the path latency metric that must
not be exceeded for the PCC to consider the computed path as acceptable.
The path metric must be less than or equal to the value specified in the
metric-value field. </t>
<t>PCC MAY also use this metric to ask PCE to optimize latency during
path computation, in this case B flag will be cleared. </t>
<t>PCE MAY use this latency metric in PCRep message along with NO-PATH
object in case PCE cannot compute a path meeting this constraint. PCE
MAY also use this metric to reply the computed end to end latency metric
to PCC. </t>
<section title="Latency (Delay) Metric Value" toc="default">
<t><xref target="OSPF-TE-METRIC-EXT"/> and <xref target="ISIS-TE-METRIC-EXT"/>
defines "Unidirectional Link Delay Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with 32-bit
metric value. Consequently, encoding for Latency (Delay) Metric
Value is defined as follows: </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
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 | Latency (Delay) Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Reserved (8 bits):">Reserved field. This field
MUST be set to zero on transmission and MUST be ignored on receipt.</t>
<t hangText="Latency (Delay) Metric (24 bits):">Represents the end
to end Latency (delay) quantified in units of microseconds and
MUST be encoded as integer value. With the maximum value 16,777,215
representing 16.777215 sec.</t>
</list>
</t>
</section>
</section>
<section title="Latency Variation (Jitter) Metric" toc="default">
<t>Link delay variation metric is defined in <xref target="OSPF-TE-METRIC-EXT"/>
and <xref target="ISIS-TE-METRIC-EXT"/> as "Unidirectional Delay Variation".
P2P latency variation metric type of
METRIC object in PCEP encodes the sum of the link delay variation metric
of all links along a P2P Path. Specifically, extending on the above mentioned
terminology: </t>
<t>- A Latency variation of link L is denoted DV(L) (average delay variation
for link L).</t>
<t>- A P2P latency variation metric for the Path P = Sum {DV(Lpi), (i=1...K)}. </t>
<!--PM-DIR <t>Specification of the "Function" used to derive latency variation
metric of a
path from latency variation metrics of individual links along the path is
beyond the scope of this document.</t>-->
<!--ZAFAR <t>Since we have an average delay variation for the links, sum is an acceptable
composition function for the path for simplicity. This document
allows use of an enhanced composition function for latency variation in future.</t>-->
<t>Note that the IGP advertisement for link attributes includes average latency
variation over a period of time. An implementation, therefore, MAY use sum of
the average latency variation of links along a path to derive the average
latency variation of the Path. An implementation MAY also use some enhanced
composition function for computing average latency variation of a Path.</t>
<t>* Metric Type T=TBD2: Latency Variation metric </t>
<t>PCC MAY use this latency variation metric in PCReq message to request a
path meeting the end to end latency variation requirement. In this case B bit
MUST be set to suggest a bound (a maximum) for the path latency variation
metric that must not be exceeded for the PCC to consider the computed path
as acceptable. The path metric must be less than or equal to the value
specified in the metric-value field. </t>
<t>PCC MAY also use this metric to ask PCE to optimize latency variation
during path computation, in this case B flag will be cleared. </t>
<t>PCE MAY use this latency variation metric in PCRep message along with
NO-PATH object in case PCE cannot compute a path meeting this constraint.
PCE MAY also use this metric to reply the computed end to end latency
variation metric to PCC. </t>
<section title="Latency Variation (Jitter) Metric Value" toc="default">
<t><xref target="OSPF-TE-METRIC-EXT"/> and <xref target="ISIS-TE-METRIC-EXT"/>
defines "Unidirectional Delay Variation Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with 32-bit metric
value. Consequently, encoding for Latency Variation (Jitter) Metric
Value is defined as follows:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
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 | Latency variation (jitter) Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Reserved (8 bits):">Reserved field. This
field MUST be set to zero on transmission and MUST be
ignored on receipt.</t>
<t hangText="Latency variation (jitter) Metric (24 bits):">
Represents the end to end Latency variation (jitter)
quantified in units of microseconds and MUST be encoded
as integer value. With the maximum value 16,777,215
representing 16.777215 sec.</t>
</list>
</t>
</section>
</section>
<section title="Packet Loss Metric" toc="default">
<t><xref target="OSPF-TE-METRIC-EXT"/> and <xref target="ISIS-TE-METRIC-EXT"/>
defines "Unidirectional Link Loss". Packet Loss metric type of
METRIC object in PCEP encodes a function of the link's unidirectional loss
metric of all links along a P2P Path. Specifically, extending on the above
mentioned terminology:</t>
<t>The end to end Packet Loss for the path is represented by this metric. </t>
<t>- A Packet loss of link L is denoted PL(L) in percentage.</t>
<t>- A Packet loss in fraction of link L is denoted FPL(L) = PL(L)/100.</t>
<t>- A P2P packet loss metric in percentage for the Path P = (1 - ((1-FPL(Lp1)) *
(1-FPL(Lp2)) * .. * (1-FPL(LpK))) * 100 for a path P with link 1 to K. </t>
<t>This is as per the composition function (section 5.1.5 of <xref target="RFC6049"/>).</t>
<!--PM-DIR <t>Specification of the "Function" used to drive end to end packet loss metric
of a path from packet loss metrics of individual links along the path is beyond
the scope of this document.</t>-->
<t>* Metric Type T=TBD3: Packet Loss metric </t>
<t>PCC MAY use this packet loss metric in PCReq message to request a path
meeting the end to end packet loss requirement. In this case B bit MUST
be set to suggest a bound (a maximum) for the path packet loss metric
that must not be exceeded for the PCC to consider the computed path as
acceptable. The path metric must be less than or equal to the value
specified in the metric-value field. </t>
<t>PCC MAY also use this metric to ask PCE to optimize packet loss
during path computation, in this case B flag will be cleared. </t>
<t>PCE MAY use this packet loss metric in PCRep message along with
NO-PATH object in case PCE cannot compute a path meeting this
constraint. PCE MAY also use this metric to reply the computed
end to end packet loss metric to PCC. </t>
<section title="Packet Loss Metric Value" toc="default">
<t><xref target="OSPF-TE-METRIC-EXT"/> and <xref target="ISIS-TE-METRIC-EXT"/>
defines "Unidirectional Link Loss Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with 32-bit
metric value. Consequently, encoding for Packet Loss Metric Value
is defined as follows: </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
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 | Packet loss Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Reserved (8 bits):">Reserved field.
This field MUST be set to zero on transmission and
MUST be ignored on receipt.</t>
<t hangText="Packet loss Metric (24 bits):">
Represents the end to end packet loss quantified
as a percentage of packets lost and MUST be encoded
as integer. The basic unit is 0.000003%, with the
maximum value 16,777,215 representing 50.331645%
(16,777,215 * 0.000003%). This value is the highest
packet loss percentage that can be expressed.</t>
</list>
</t>
</section>
</section>
<section title="Non-Understanding / Non-Support of Service Aware Path Computation" toc="default" >
<t>If the P bit is clear in the object header and PCE does not
understand or does not support service aware path computation
it SHOULD simply ignore this METRIC object.</t>
<t>If the P Bit is set in the object header and PCE receives
new METRIC type in path request and it understands the METRIC
type, but the PCE is not capable of service aware path computation,
the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 4
(Not supported object) <xref target="RFC5440"/>. The path computation
request MUST then be cancelled. </t>
<t>If the PCE does not understand the new METRIC type, then the PCE
MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 3
(Unknown object) <xref target="RFC5440"/>.</t>
</section>
<section title="Mode of Operation" toc="default" >
<t>As explained in <xref target="RFC5440"/>, the METRIC object is
optional and can be used for several purposes. In a PCReq message,
a PCC MAY insert one or more METRIC objects:</t>
<t>
<list style="symbols">
<t>To indicate the metric that MUST be optimized by the path
computation algorithm (Latency, Latency Variation or Loss)</t>
<t>To indicate a bound on the path METRIC (Latency,
Latency Variation or Loss) that MUST NOT be exceeded for
the path to be considered as acceptable by the PCC.</t>
</list>
</t>
<t>In a PCRep message, the METRIC object MAY be inserted so as
to provide the METRIC (Latency, Latency Variation or Loss) for
the computed path. It MAY also be inserted within a PCRep with
the NO-PATH object to indicate that the metric constraint could
not be satisfied.</t>
<t>The path computation algorithmic aspects used by the PCE to
optimize a path with respect to a specific metric are outside
the scope of this document.</t>
<t>All the rules of processing METRIC object as explained in
<xref target="RFC5440"/> are applicable to the new metric types
as well. </t>
<t>In a PCReq message, a PCC MAY insert more than one METRIC
object to be optimized, in such a case PCE SHOULD find the
path that is optimal when both the metrics are considered
together.</t>
<section title="Examples" toc="default">
<t>Example 1: If a PCC sends a path computation request to
a PCE where two metric to optimize are the latency and the
packet loss, two METRIC objects are inserted in the PCReq
message:</t>
<t>
<list style="symbols">
<t>First METRIC object with B=0, T=TBD1, C=1, metric-value=0x0000</t>
<t>Second METRIC object with B=0, T=TBD3, C=1, metric-value=0x0000</t>
</list>
</t>
<t>PCE in such a case SHOULD try to optimize both the metrics
and find a path with the minimum latency and packet loss, if a
path can be found by the PCE and there is no policy that prevents
the return of the computed metric, the PCE inserts first METRIC
object with B=0, T=TBD1, metric-value= computed end to
end latency and second METRIC object with B=1, T=TBD3,
metric-value= computed end to end packet loss.</t>
<t>Example 2: If a PCC sends a path computation request to a PCE
where the metric to optimize is the latency and the packet loss
must not exceed the value of M, two METRIC objects are inserted
in the PCReq message:</t>
<t>
<list style="symbols">
<t>First METRIC object with B=0, T=TBD1, C=1, metric-value=0x0000</t>
<t>Second METRIC object with B=1, T=TBD3, metric-value=M</t>
</list>
</t>
<t>If a path satisfying the set of constraints can be found by the
PCE and there is no policy that prevents the return of the
computed metric, the PCE inserts one METRIC object with B=0,
T=TBD1, metric-value= computed end to end latency.
Additionally, the PCE may insert a second METRIC object with
B=1, T=TBD3, metric-value=computed end to end packet
loss.</t>
</section>
</section>
</section>
<section title="Bandwidth Utilization" toc="default">
<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-METRIC-EXT"></xref> and <xref
target="ISIS-TE-METRIC-EXT"></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 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 TBD4.</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 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>
<section title="Objective Functions" toc="default" anchor="SEC_OF">
<t><xref target="RFC5541"/> defines mechanism to specify an optimization
criteria, referred to as objective functions. The new metric types specified
in this document MAY continue to use the existing objective functions like
Minimum Cost Path (MCP). Latency (Delay) and Latency Variation (Jitter) are
well suited to use MCP as an optimization criteria. For Packet Loss following
new OF is defined - </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>Packet loss of link L is denoted PL(L) in percentage.</t>
<t>Packet loss in fraction of link L is denoted FPL(L) = PL(L) / 100.</t>
<t>The Packet loss of a path P (in percentage) is denoted PL(P), where PL(P) = (1 -
((1-FPL(Lp1)) * (1-FPL(Lp2)) * .. * (1-FPL(LpK))) * 100. </t>
</list>
</t>
<t><list style="hanging">
<t hangText="Objective Function Code:">TBD5</t>
<t><list>
<t>Name: Minimum Packet Loss Path (MPLP)</t>
<t>Description: Find a path P such that PL(P) is
minimized.</t>
</list></t>
</list></t>
<!-- <t>The new metric types for example latency (delay) can continue
to use the above objective function to find the minimum cost
path where cost is latency (delay). At the same time new objective
functions can be defined in future to optimize these new metric types. </t>
-->
<t>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
additional terminology:</t>
<t><list style="symbols">
<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:">TBD6</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:">TBD7</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>
<section title="PCEP Message Extension" toc="default">
<section title="The PCReq message" toc="default" anchor="SEC_REQ">
<t>The extension to PCReq message are -
<list style="symbols">
<t>new metric types using existing METRIC object</t>
<t>a new optional BU object</t>
<t>new objective functions using existing OF object (<xref target="RFC5541"></xref>)</t>
</list>
</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 extension to PCRep message are -
<list style="symbols">
<t>new metric types using existing METRIC object</t>
<t>a new optional BU object (during unsuccessful path
computation, to indicate the bandwidth utilization as
a reason for failure)</t>
<t>new objective functions using existing OF object (<xref target="RFC5541"></xref>)</t>
</list>
</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 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 service aware parameters.</t>
<t>The additional objective functions defined in this document can also
be used with stateful PCE.</t>
<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 title="Other Considerations" toc="default">
<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 metric
types
defined in this document can be applied to end to end path
computation, in similar manner as existing IGP or TE metric.
The new BU object
defined in this document can be applied to end to end path
computation, in similar manner as the METRIC object.</t>
<t>All domains should have the same understanding of the METRIC
(Latency Variation etc) and BU object for end-to-end inter-domain path computation
to make sense. Otherwise some form of Metric Normalization as
described in <xref target="RFC5441"/> MAY need to be applied.</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 network performance
link properties are described in <xref target="OSPF-TE-METRIC-EXT"/> and
<xref target="ISIS-TE-METRIC-EXT"/>, the same properties must be advertised
using the mechanism described in <xref target="RFC5392"/> (OSPF) and
<xref target="RFC5316"/> (ISIS).</t>
</section>
<section title="Inter-Layer Consideration" toc="default">
<t><xref target="RFC5623"/> provides a framework for PCE-Based inter-layer
MPLS and GMPLS Traffic Engineering. Lower-layer LSPs that are advertised
as TE links into the higher-layer network form a Virtual Network Topology
(VNT). The advertisement in higher-layer should include the network performance
link properties based on the end to end metric of lower-layer LSP. Note that
the new metric defined in this document are applied to end to end path computation,
even though the path may cross multiple layers. </t>
</section>
</section>
<section title="Reoptimization Consideration" toc="default">
<t>PCC can monitor the setup LSPs and in case of degradation of
network performance constraints, it MAY ask PCE for reoptimization
as per <xref target="RFC5440"/>. Based on the changes in performance
parameters in TED, a PCC MAY also issue a reoptimization request.</t>
<t>Further, PCC can also monitor the link bandwidth utilization along the
path 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="Point-to-Multipoint (P2MP)" toc="default">
<t>This document defines the following optional types for the METRIC
object defined in <xref target="RFC5440"/> for P2MP TE LSPs. The
usage of BU object for P2MP LSP is out of scope of this document.</t>
<section title="P2MP Latency Metric" toc="default">
<t>P2MP latency metric type of METRIC object in PCEP encodes the path
latency metric for destination that observes the worst latency metric
among all destinations of the P2MP tree. Specifically, extending on the
above mentioned terminology: </t>
<t> - A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)} </t>
<t> - P2P latency metric of the Path to destination Dest_j is denoted by LM(Dest_j). </t>
<t> - P2MP latency metric for the P2MP tree T = Maximum {LM(Dest_j), (j=1...M)}. </t>
<t> Value for P2MP latency metric type (T) = TBD8 is to be assigned by IANA. </t>
</section>
<section title="P2MP Latency Variation Metric" toc="default">
<t>P2MP latency variation metric type of METRIC object in PCEP encodes the
path latency variation metric for destination that observes the worst latency
variation metric among all destinations of the P2MP tree. Specifically,
extending on the above mentioned terminology: </t>
<t> - A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)} </t>
<t> - P2P latency variation metric of the Path to destination Dest_j is denoted by LVM(Dest_j). </t>
<t> - P2MP latency variation metric for the P2MP tree T = Maximum {LVM(Dest_j), (j=1...M)}. </t>
<t> Value for P2MP latency variation metric type (T) = TBD9 is to be assigned by IANA. </t>
</section>
<section title="P2MP Packet Loss Metric" toc="default">
<t>P2MP packet loss metric type of METRIC object in PCEP encodes the path packet
loss metric for destination that observes the worst packet loss metric among all
destinations of the P2MP tree. Specifically, extending on the above mentioned terminology: </t>
<t> - A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)} </t>
<t> - P2P packet loss metric of the Path to destination Dest_j is denoted by PLM(Dest_j). </t>
<t> - P2MP packet loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}. </t>
<t> Value for P2MP packet loss metric type (T) = = TBD10 is to be assigned by IANA. </t>
</section>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="METRIC types" toc="default">
<t>Six new metric types are defined in this document for the METRIC
object (specified in <xref target="RFC5440"/>). IANA maintains a registry of metric
types in the "METRIC Object T Field" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>IANA is requested to make the following allocations:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value Description Reference
TBD1 Latency (delay) metric [This I.D.]
TBD2 Latency Variation (jitter) metric [This I.D.]
TBD3 Packet Loss metric [This I.D.]
TBD8 P2MP latency metric [This I.D.]
TBD9 P2MP latency variation metric [This I.D.]
TBD10 P2MP packet loss metric [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<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
--------------------------------------------------
TBD4 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="OF Codes" toc="default">
<t>One new Objective Functions have been
defined in this document for the OF code (described in <xref target="RFC5541"/>).
IANA maintains this registry at
"Objective Function" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>IANA is requested to make the following allocations:</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
--------------------------------------------------
TBD5 Minimum Packet Loss Path [This I.D.]
(MPLP)
TBD6 Maximum Under-Utilized [This I.D.]
Path (MUP)
TBD7 Maximum Reserved [This I.D.]
Under-Utilized Path (MRUP)
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines new METRIC types, a new BU object, and OF codes which does not add any new
security concerns beyond those discussed in <xref target="RFC5440"/>
and <xref target="RFC5541"/> in itself. Some deployments may find the
service aware information like delay and packet loss as extra sensitive
and thus should employ suitable PCEP security mechanisms like TCP-AO
or <xref target="PCEPS"/>.</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 on individual basis. If the new
constraint is not supported/allowed on a PCE, it MUST send a PCErr
message accordingly.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="RFC7420"/> 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"/>.</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"/>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>PCE requires the TED to be populated with network performance
information like link latency, latency variation, packet loss,
and utilized bandwidth.
This mechanism is described in <xref target="OSPF-TE-METRIC-EXT"/>
and <xref target="ISIS-TE-METRIC-EXT"/>.</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"/>.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Alia Atlas, John E Drake, David Ward,
Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina,
Suresh Babu, Quintin Zhao, Chen Huaimo and Avantika for their
useful comments and
suggestions.</t>
<t>Also the authors gratefully acknowledge reviews and feedback
provided by Qin Wu,
Alfred Morton and Paul Aitken during performance directorate
review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.5316.xml" ?>
<?rfc include="reference.RFC.5392.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<?rfc include="reference.RFC.5623.xml" ?>
<?rfc include="reference.RFC.6049.xml" ?>
<?rfc include="reference.RFC.6374.xml" ?>
<?rfc include="reference.RFC.7420.xml" ?>
<!--OSPF-TE-METRIC-EXT-->
<reference anchor="OSPF-TE-METRIC-EXT">
<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="January" day="9" year="2015"/>
<abstract>
<t>
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed 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 by which network performance information is distributed. The mechanisms for measuring network performance information or using 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-11"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-metric-extensions-11.txt"/>
</reference>
<!--ISIS-TE-METRIC-EXT-->
<reference anchor="ISIS-TE-METRIC-EXT">
<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="October" day="22" 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-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-isis-te-metric-extensions-04.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="I" surname="Minei" fullname="Ina Minei">
<organization/>
</author>
<author initials="J" surname="Medved" fullname="Jan Medved">
<organization/>
</author>
<author initials="R" surname="Varga" fullname="Robert Varga">
<organization/>
</author>
<date month="October" day="26" 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-10"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-stateful-pce-10.txt"/>
</reference>
<reference anchor="PCEPS">
<front>
<title>Secure Transport for PCEP</title>
<author initials="D" surname="Lopez" fullname="Diego Lopez">
<organization/>
</author>
<author initials="O" surname="Dios" fullname="Oscar de Dios">
<organization/>
</author>
<author initials="W" surname="Wu" fullname="Wenson Wu">
<organization/>
</author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<date month="October" day="2" year="2014"/>
<abstract>
<t>
The Path Computation Element Communication Protocol (PCEP) defines the
mechanisms for the communication between a Path Computation Client (PCC)
and a Path Computation Element (PCE), or among PCEs. This document
describe the usage of Transport Layer Security (TLS) to enhance PCEP
security, hence the PCEPS acronym proposed for it. The additional
security mechanisms are provided by the transport protocol supporting
PCEP, and therefore they do not affect its flexibility and
extensibility.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pceps-02.txt"/>
</reference>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
George Swallow
Cisco Systems
Email: swallow@cisco.com
Stefano Previdi
Cisco Systems, Inc
Via Del Serafico 200
Rome 00191
Italy
Email: sprevidi@cisco.com
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: udayasree.palle@huawei.com
Avantika
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: avantika.sushilkumar@huawei.com
Xian Zhang
Huawei Technologies
F3-1-B R&D Center, Huawei Base Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhang.xian@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 11:00:27 |