One document matched: draft-ietf-pce-pcep-service-aware-02.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-02" 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>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 initials="V" surname="Manral" fullname="Vishwas Manral">
<organization>Hewlett-Packard Corp.</organization>
<address>
<postal>
<street>191111 Pruneridge Ave.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country>
</postal>
<email>vishwas.manral@hp.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="G" surname="Swallow" fullname="George Swallow">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>swallow@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="January" year="2014" />
<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 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. </t>
<t><xref target="OSPF-TE-EXPRESS"/> and
<xref target="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>
<middle>
<section title="Introduction" toc="default">
<t>Real time network performance is becoming a 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>Traffic Engineering Database (TED) is populated with network
performance information like link latency, latency variation and
packet loss through <xref target="OSPF-TE-EXPRESS"/> or
<xref target="ISIS-TE-EXPRESS"/>. 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>PCE MAY use mechanism described in
<xref target="MPLS-TE-EXPRESS-PATH"/> on how to use the
link latency, latency variation and packet loss information for
end to end path selection. </t>
<t><xref target="OSPF-TE-EXPRESS"/> and
<xref target="ISIS-TE-EXPRESS"/> include parameters related
to bandwidth (Residual bandwidth, Available bandwidth and Utilized
bandwidth); <xref target="PCEP-BW-UTIL"/> 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="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="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
and packet loss is a key requirement for service provider. Following key
requirements associated with latency, latency-variation and loss 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 latency, latency-variation and packet loss
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 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>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>
<t> This document defines the following optional types for the
METRIC object defined in <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-EXPRESS"/> and
<xref target="ISIS-TE-EXPRESS"/>. 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>* T=13(TBA - IANA): 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-EXPRESS"/> and <xref target="ISIS-TE-EXPRESS"/>
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-EXPRESS"/>
and <xref target="ISIS-TE-EXPRESS"/>. P2P latency variation metric type of
METRIC object in PCEP encodes a function 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).</t>
<t>- A P2P latency variation metric for the Path P = function {DV(Lpi), (i=1...K)}. </t>
<t>Specification of the "Function" used to drive latency variation metric of a
path from latency variation metrics of individual links along the path is
beyond the scope of this document.</t>
<t>* T=14(TBA - IANA): 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-EXPRESS"/> and <xref target="ISIS-TE-EXPRESS"/>
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-EXPRESS"/> and <xref target="ISIS-TE-EXPRESS"/>
defines "Unidirectional Link Loss". Packet Loss Metric 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).</t>
<t>- A P2P packet loss metric for the Path P = function {PL(Lpi), (i=1...K)}. </t>
<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>* T=15(TBA - IANA): 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-EXPRESS"/> and <xref target="ISIS-TE-EXPRESS"/>
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" anchor="SEC_N">
<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=13 (TBA - IANA), C=1, metric-value=0x0000</t>
<t>Second METRIC object with B=0, T=15 (TBA - IANA), 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=13 (TBA - IANA), metric-value= computed end to end latency and second METRIC object with B=1, T=15 (TBA - IANA), 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=13 (TBA - IANA), C=1, metric-value=0x0000</t>
<t>Second METRIC object with B=1, T=15 (TBA - IANA), 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=13 (TBA - IANA), metric-value= computed end to end latency.
Additionally, the PCE may insert a second METRIC object with
B=1, T=15 (TBA - IANA), metric-value= computed end to end packet
loss.</t>
</section>
</section>
</section>
<section title="Relationship with Objective Functions" toc="default">
<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.</t>
<t>Minimum Cost Path (MCP) is one such objective function.</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>Metric of link L is denoted M(L). This can be any metric, including the ones defined in this document.</t>
<t>The cost of a path P is denoted C(P), where C(P) = sum {M(Lpi),(i=1...K)}.</t>
</list>
</t>
<t>Name: Minimum Cost Path (MCP)</t>
<t>Description: Find a path P such that C(P) is minimized.</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>
</section>
<section title="Protocol Consideration" toc="default">
<t>There is no change in the message format of PCReq and PCRep Messages.</t>
<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
defined in this document can be applied to end to end path
computation, in similar manner as existing IGP or TE metric. </t>
<t>All domains should have the same understanding of the METRIC
(Latency-Variation etc) 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-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 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>
</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.</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 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 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 is to be assigned by IANA </t>
</section>
</section>
<section title="Stateful PCE" toc="default">
<t><xref target="STATEFUL-PCE"/> 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. 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 of an LSP. This message contains the metric-list as part
of attributes, the new metric types defined in this document for network performance
parameter MAY be carried to report them to stateful PCEs.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>New metric object T fields have been defined in this document.
IANA has made the following allocations from the PCEP "METRIC Object T Field"
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[
Value Description Reference
13(TBD) Latency (delay) metric [This I.D.]
14(TBD) Latency Variation (jitter) metric [This I.D.]
15(TBD) Packet Loss metric [This I.D.]
16(TBD) P2MP latency metric [This I.D.]
17(TBD) P2MP latency variation metric [This I.D.]
18(TBD) P2MP packet loss metric [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines new METRIC types which does not add any new
security concerns beyond those discussed in <xref target="RFC5440"/>.</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 service-aware METRICS
on a PCE which MAY be controlled by a policy module. If the new METRIC is not
supported/allowed on a PCE, it MUST send a PCErr message as specified in
<xref target="SEC_N"/>.</t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="PCEP-MIB"/> 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 and packet loss.
This mechanism is described in <xref target="OSPF-TE-EXPRESS"/>
and <xref target="ISIS-TE-EXPRESS"/>.</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 Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina,
Suresh Babu, Quintin Zhao, Chen Huaimo and Avantika for their useful comments and
suggestions.</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.6374.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 initials="S" surname="Giacalone" fullname="Spencer Giacalone">
<organization />
</author>
<author initials="D" surname="Ward" fullname="Dave 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" 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-00]</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="Dave 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="Q" surname="Wu" fullname="Qin Wu">
<organization />
</author>
<date month="October" year="2013" />
</front>
</reference>
<!--MPLS-TE-EXPRESS-PATH-->
<reference anchor="MPLS-TE-EXPRESS-PATH">
<front>
<title>Performance-based Path Selection for Explicitly Routed LSPs [draft-atlas-mpls-te-express-path]</title>
<author initials="A" surname="Atlas" fullname="Alia Atlas">
<organization />
</author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization />
</author>
<author initials="D" surname="Ward" fullname="Dave Ward">
<organization />
</author>
<author initials="S" surname="Giacalone" fullname="Spencer Giacalone">
<organization />
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization />
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
<organization />
</author>
<date month="September" 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 initials="A S" surname="Kiran Koushik" fullname="Kiran Koushik A S">
<organization />
</author>
<author initials="E" surname="Stephan" fullname="Stephan E">
<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="John Hardwick">
<organization />
</author>
<date month="July" year="2013" />
</front>
</reference>
<!--STATEFUL-PCE-->
<reference anchor="STATEFUL-PCE">
<front>
<title>PCEP Extensions for Stateful PCE (draft-ietf-pce-stateful-pce)</title>
<author initials="E" surname="Crabbe" fullname="Crabbe E">
<organization />
</author>
<author initials="J" surname="Medved" fullname="Medved J">
<organization />
</author>
<author initials="I" surname="Minei" fullname="Minei I">
<organization />
</author>
<author initials="R" surname="Varga," fullname="Varga R">
<organization />
</author>
<date month="October" year="2013" />
</front>
</reference>
<!--PCEP-BW-UTIL-->
<reference anchor="PCEP-BW-UTIL">
<front>
<title>Extensions to Path Computation Element Communication
Protocol (PCEP) for handling Link Bandwidth
Utilization (draft-wu-pce-pcep-link-bw-utilization)</title>
<author initials="Q" surname="Wu" fullname="Qin Wu">
<organization />
</author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization />
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization />
</author>
<date month="January" year="2014" />
</front>
</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
Stefano Previdi
Cisco Systems
EMail: sprevidi@cisco.com
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@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:04:03 |