One document matched: draft-ietf-pce-pcep-service-aware-11.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-11" 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>560066</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="June" year="2016" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<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 and constraints. 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 describe 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,
delay 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 information is becoming critical in the
path computation in some networks. Mechanisms to measure latency,
delay variation, and packet loss in an MPLS network are
described in <xref target="RFC6374"/>.
It is important that latency, delay variation, and packet
loss are considered during the 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 the path computation.</t>
<t>The Traffic Engineering Database (TED) is populated with network
performance information like link latency, delay variation,
packet loss, as well as parameters related
to bandwidth (residual bandwidth, available bandwidth and utilized
bandwidth) via TE Metric Extensions in OSPF <xref target="RFC7471"/> or
IS-IS <xref target="RFC7810"/> or via a management system. <xref target="RFC7823"/>
describes how a Path Computation Element (PCE) <xref target="RFC4655"/>,
can use that information for path selection for explicitly routed
LSPs.</t>
<t>A Path Computation Client (PCC)
can request a 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 constraints
which include any combination of latency, delay variation,
packet loss and bandwidth utilization constraints.</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>
<t hangText="TED:">Traffic Engineering Database</t>
</list>
</t>
</section>
<section title="PCEP Requirements" toc="default" anchor="SEC_R">
<t>End-to-end service optimization based on latency, delay variation,
packet loss, and link bandwidth utilization are key requirements
for service providers. The following associated key requirements are
identified for PCEP: </t>
<t>
<list style="numbers">
<t>A PCE supporting this draft MUST have the capability to compute
end-to-end (E2E) paths with latency, delay variation, packet loss,
and bandwidth utilization
constraints. It MUST also support the combination of network
performance constraints (latency, delay variation, loss...)
with existing constraints (cost, hop-limit...).</t>
<t>A PCC MUST be able to specify any network performance constraint
in a Path Computation Request (PCReq) message to be applied during the path computation.</t>
<t>A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria.</t>
<!-- text provided by Jon - <t>
A PCC must be able to specify any network performance
constraint as a constraint in a PCReq message, and must be
able to indicate whether it is providing a metric that must be
optimised on the computed path or is providing a bound
constraint that must not be exceeded by the computed path.
</t> -->
<!-- removed
<t>A 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>A PCC MUST be able to request for network performance
constraint
in PCReq message as an Objective function (OF) <xref
target="RFC5541"></xref> to be optimized.</t>
-->
<t>A PCE is 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 service-aware path
computation is not supported.</t>
<t>A PCE SHOULD be able to return end to end network performance
information of the computed path in a Path Computation Reply (PCRep) message.</t>
<t>A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS,
Inter-Area or Multi-Layer) service aware paths. </t>
</list>
</t>
<t>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, a consistent
way 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 metric-value, metric-type (T field) and flags. This document
defines the following types for the
METRIC object.
<list style="symbols">
<t>T=TBD1: Path Delay metric (<xref target="sec_pd"/>)</t>
<t>T=TBD2: Path Delay Variation metric (<xref target="sec_pdv"/>)</t>
<t>T=TBD3: Path Loss metric (<xref target="sec_pl"/>)</t>
<t>T=TBD8: P2MP Path Delay metric (<xref target="sec_pd_p2mp"/>)</t>
<t>T=TBD9: P2MP Path Delay Variation metric (<xref target="sec_pdv_p2mp"/>)</t>
<t>T=TBD10: P2MP Path Loss metric (<xref target="sec_pl_p2mp"/>)</t>
</list>
</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>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 point to point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.</t>
<section title="Path Delay Metric" toc="default" anchor="sec_pd">
<t>The link delay metric is defined in <xref target="RFC7471"/> and
<xref target="RFC7810"/> as "Unidirectional Link Delay".
The path delay metric type of the METRIC object
in PCEP represents 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 path delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}. </t>
<t>This is as per the sum of means composition function (section 4.2.5 of
<xref target="RFC6049"/>).</t>
<t>* Metric Type T=TBD1: Path Delay metric </t>
<t>A PCC MAY use the path delay metric in a PCReq message to request a path
meeting the end to end latency requirement. In this case, the B bit MUST be
set to suggest a bound (a maximum) for the path delay metric that must
not be exceeded for the PCC to consider the computed path as acceptable.
The path delay metric must be less than or equal to the value specified in the
metric-value field. </t>
<t>A PCC MAY also use this metric to ask PCE to optimize the path delay during
path computation. In this case, the B bit MUST be cleared. </t>
<t>A PCE MAY use the path delay metric in a PCRep message along with a NO-PATH
object in the case where the PCE cannot compute a path meeting this constraint. A PCE
MAY also use this metric to send the computed path delay metric
to the PCC. </t>
<section title="Path Delay Metric Value" toc="default">
<t><xref target="RFC7471"/> and <xref target="RFC7810"/>
define the "Unidirectional Link Delay Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with a 32-bit
metric value encoded in IEEE floating point format
(see <xref target="IEEE.754.1985"/>). Consequently, the encoding for the path delay metric
value is quantified in units of microseconds and encoded in IEEE floating
point format.</t>
</section>
</section>
<section title="Path Delay Variation Metric" toc="default" anchor="sec_pdv">
<t>The link delay variation metric is defined in <xref target="RFC7471"/>
and <xref target="RFC7810"/> as "Unidirectional Delay Variation".
The path delay variation metric type of the
METRIC object in PCEP encodes the sum of the link delay variation metric
of all links along the path. Specifically, extending on the above mentioned
terminology: </t>
<t>- A delay variation of link L is denoted DV(L) (average delay variation
for link L).</t>
<t>- A path delay variation metric for the P2P 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 the average delay
variation over a period of time. An implementation, therefore, MAY use the sum of
the average delay variation of links along a path to derive the average
delay variation of the Path. An implementation MAY also use some enhanced
composition function for computing the average delay variation of a path.</t>
<t>* Metric Type T=TBD2: Path Delay Variation metric </t>
<t>A PCC MAY use the path delay variation metric in a PCReq message to request a
path meeting the path delay variation requirement. In this case, the B bit
MUST be set to suggest a bound (a maximum) for the path delay variation
metric that must not be exceeded for the PCC to consider the computed path
as acceptable. The path delay variation must be less than or equal to the value
specified in the metric-value field. </t>
<t>A PCC MAY also use this metric to ask the PCE to optimize the path delay variation
during path computation. In this case, the B flag MUST be cleared. </t>
<t>A PCE MAY use the path delay variation metric in PCRep message along with a
NO-PATH object in the case where the PCE cannot compute a path meeting this constraint.
A PCE MAY also use this metric to send the computed end to end path delay
variation metric to the PCC. </t>
<section title="Path Delay Variation Metric Value" toc="default">
<t><xref target="RFC7471"/> and <xref target="RFC7810"/>
define "Unidirectional Delay Variation Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with a 32-bit metric
value encoded in IEEE floating point format
(see <xref target="IEEE.754.1985"/>). Consequently, the encoding for the path delay variation metric
value is quantified in units of microseconds and encoded in IEEE floating
point format.</t>
</section>
</section>
<section title="Path Loss Metric" toc="default" anchor="sec_pl">
<t><xref target="RFC7471"/> and <xref target="RFC7810"/>
define "Unidirectional Link Loss". The path loss metric type of the
METRIC object in PCEP encodes a function of the unidirectional loss
metrics of all links along a P2P path. Specifically, extending on the above
mentioned terminology:</t>
<t>The end to end path loss for the path is represented by this metric. </t>
<t>- The percentage link loss of link L is denoted PL(L).</t>
<t>- The fractional link loss of link L is denoted FL(L) = PL(L)/100.</t>
<t>- The percentage path loss metric for the P2P path P = (1 - ((1-FL(Lp1)) *
(1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P with links Lp1 to LpK. </t>
<t>This is as per the composition function described in 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: Path Loss metric </t>
<t>A PCC MAY use the path loss metric in a PCReq message to request a path
meeting the end to end packet loss requirement. In this case, the B bit MUST
be set to suggest a bound (a maximum) for the path loss metric
that must not be exceeded for the PCC to consider the computed path as
acceptable. The path loss metric must be less than or equal to the value
specified in the metric-value field. </t>
<t>A PCC MAY also use this metric to ask the PCE to optimize the path loss
during path computation. In this case, the B flag MUST be cleared. </t>
<t>A PCE MAY use the path loss metric in a PCRep message along with a
NO-PATH object in the case where the PCE cannot compute a path meeting this
constraint. A PCE MAY also use this metric to send the computed
end to end path loss metric to the PCC. </t>
<section title="Path Loss Metric Value" toc="default">
<t><xref target="RFC7471"/> and <xref target="RFC7810"/>
define "Unidirectional Link Loss Sub-TLV" in a 24-bit field.
<xref target="RFC5440"/> defines the METRIC object with 32-bit
metric value encoded in IEEE floating point format
(see <xref target="IEEE.754.1985"/>). Consequently, the encoding for the path loss metric value
is quantified as a percentage and encoded in IEEE floating point format. </t>
</section>
</section>
<section title="Non-Understanding / Non-Support of Service Aware Path Computation" toc="default" >
<!--JEH <t>I've reworded this section a bit for clarity.</t>-->
<t>If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and
the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header
then the PCE SHOULD simply ignore the METRIC object as per the processing specified in <xref target="RFC5440"/>.</t>
<t>If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST
send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4
(Not supported object) and Error-value = 4 (Unsupported parameter) <xref target="RFC5440"/><xref target="RFC5441"/>.</t>
<t>If the PCE understands but does not support the new METRIC type, and the P bit is set in the METRIC object header,
then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4
(Not supported object) with Error-value = TBD11 (Unsupported network performance constraint). The path computation
request MUST then be cancelled. </t>
<t>If the PCE understands the new METRIC type, but the local policy has been configured on the PCE to not
allow network performance constraint, and the P bit is set in the METRIC object header,
then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 5
(Policy violation) with Error-value = TBD12 (Not allowed network performance constraint). The path computation
request MUST then be cancelled. </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 (path delay, path delay variation or path loss).</t>
<t>To indicate a bound on the METRIC (path delay,
path delay variation or path 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 PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as
to provide the METRIC (path delay, path delay variation or path loss) for
the computed path. The PCE MAY also insert the METRIC object with
a 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 the METRIC object as explained in
<xref target="RFC5440"/> are applicable to the new metric types
as well. </t>
<!-- remove as we have not defined the OF to handle multi-
optimization OF
<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 path delay and the
path 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 path delay and path 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 path delay and second METRIC object with B=1, T=TBD3,
metric-value= computed path loss.</t>-->
<t>If a PCC sends a path computation request to a PCE
where the metric to optimize is the path delay and the path loss
must not exceed the value of M, then 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, then the PCE inserts one METRIC object with B=0,
T=TBD1, metric-value= computed path delay.
Additionally, the PCE may insert a second METRIC object with
B=1, T=TBD3, metric-value=computed path
loss.</t>
</section>
</section>
<section title="Point-to-Multipoint (P2MP)" toc="default">
<t>This section defines the following optional types for the METRIC
object for P2MP TE LSPs.</t>
<section title="P2MP Path Delay Metric" toc="default" anchor="sec_pd_p2mp">
<t>The P2MP path delay metric type of the METRIC object in PCEP encodes the path
delay metric for the destination that observes the worst delay metric
among all destinations of the P2MP tree. Specifically, extending on the
above mentioned terminology: </t>
<t> - A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)} </t>
<t> - The P2P path delay metric of the path to destination Dest_j is denoted by LM(Dest_j). </t>
<t> - The P2MP path delay metric for the P2MP tree T = Maximum {LM(Dest_j), (j=1...M)}. </t>
<t> The value for the P2MP path delay metric type (T) = TBD8 is to be assigned by IANA. </t>
</section>
<section title="P2MP Path Delay Variation Metric" toc="default" anchor="sec_pdv_p2mp">
<t>The P2MP path delay variation metric type of the METRIC object in PCEP encodes the
path delay variation metric for the destination that observes the worst delay
variation metric among all destinations of the P2MP tree. Specifically,
extending on the above mentioned terminology: </t>
<t> - A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)} </t>
<t> - The P2P path delay variation metric of the path to the destination Dest_j is denoted by LVM(Dest_j). </t>
<t> - The P2MP path delay variation metric for the P2MP tree T = Maximum {LVM(Dest_j), (j=1...M)}. </t>
<t> The value for the P2MP path delay variation metric type (T) = TBD9 is to be assigned by IANA. </t>
</section>
<section title="P2MP Path Loss Metric" toc="default" anchor="sec_pl_p2mp">
<t>The P2MP path loss metric type of the METRIC object in PCEP encodes the path packet
loss metric for the 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> - The P2P path loss metric of the path to destination Dest_j is denoted by PLM(Dest_j). </t>
<t> - The P2MP path loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}. </t>
<t> The value for the P2MP path loss metric type (T) = TBD10 is to be assigned by IANA. </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="RFC7471"></xref> and <xref
target="RFC7810"></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-TE and non-RSVP-TE
label switched path packets.</t>
<t>The LBU percentage is described as the (LBU / maximum bandwidth) *
100.</t>
<t>Where "maximum bandwidth" is defined in <xref target="RFC3630"/> and
<xref target="RFC5305"/>.</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>The 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 (<xref target="RFC7471"></xref> and <xref
target="RFC7810"></xref>).
Once we have the actual bandwidth for non-RSVP TE traffic, subtracting
this from LBU would result in LRBU.</t>
<t>LRBU = LBU - (residual bandwidth - available bandwidth)</t>
<t>LRBU percentage is described as the (LRBU / (maximum reservable
bandwidth)) * 100.</t>
<t>Where the "maximum reservable bandwidth" is defined in <xref target="RFC3630"/> and
<xref target="RFC5305"/>.</t>
</section>
<section title="Bandwidth Utilization (BU) Object" toc="default">
<t>The BU object 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. Two values are currently defined.
<list style="symbols">
<t>Type 1 is Link Bandwidth Utilization (LBU)</t>
<t>Type 2 is Link Reserved Bandwidth Utilization (LRBU)</t>
</list>
</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>) and encoded in IEEE floating point format
(see <xref target="IEEE.754.1985"/>).</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. A PCE that supports this object MUST ensure that no
link on the computed path has bandwidth utilization (LBU or LRBU percentage)
exceeding the given value.</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>
<!--JEH <t>I've reworded this section a bit for clarity.</t>-->
<t>If a PCE receives a PCReq message containing a BU object, and
the PCE does not understand or support the BU object, and the P bit is clear in the BU object header
then the PCE SHOULD simply ignore the BU object.</t>
<t>If the PCE does not understand the BU object, and the P bit is set in the BU object header, then the PCE MUST
send a PCErr message containing a PCEP-ERROR Object with Error-Type = 3
(Unknown object) and Error-value = 1 (Unrecognized object class)
as per <xref target="RFC5440"></xref>.</t>
<t>If the PCE understands but does not support path computation requests using the BU object, and the P bit is set in the BU object header,
then the PCE MUST send a PCErr message with a PCEP-ERROR
Object Error-Type = 4 (Not supported object) with Error-value = TBD11
(Unsupported network performance constraint). The path computation request MUST then be
cancelled.</t>
<t>If the PCE understands the BU object but the local policy has been configured on the PCE to not
allow network performance constraint, and the P bit is set in the BU object header,
then the PCE MUST send a PCErr message with a PCEP-ERROR
Object Error-Type = 5 (Policy Violation) with Error-value = TBD12
(Not allowed network performance constraint). The path computation request MUST then be
cancelled.</t>
<t>If path computation is unsuccessful, then a PCE MAY insert a BU object (along with a NO-PATH object) into a PCRep
message to indicate the constraints that could not be satisfied.</t>
<t>
Usage of the BU object for P2MP LSPs is outside the scope of this document.</t>
</section>
</section>
</section>
<section title="Objective Functions" toc="default" anchor="SEC_OF">
<t><xref target="RFC5541"/> defines a mechanism to specify an objective function
that is used by a PCE when it computes a path.
<!--Reword this-> The new metric types specified
in this document MAY continue to use the existing objective functions like
Minimum Cost Path (MCP). Path Delay and Path Delay Variation are
well suited to use MCP as an objective function. -->
The new metric types for path delay and path delay variation
can continue to use the existing objective function - Minimum Cost Path (MCP) <xref target="RFC5541"/>.
For path loss, the 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>The percentage link loss of link L is denoted PL(L).</t>
<t>The fractional link loss of link L is denoted FL(L) = PL(L) / 100.</t>
<t>The percentage path loss of a path P is denoted PL(P), where PL(P) = (1 -
((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(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) are needed to optimize bandwidth utilization.
These two new objective function codes are defined below.</t>
<t>These 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 reservable 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 functions defined in this document are
unknown/unsupported by a PCE, then the procedure as defined in <xref
target="RFC5541"></xref> is followed.</t>
</section>
</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 update LSP parameters in those PCCs that
delegated control over their LSPs to the PCE. </t>
<t>The 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>
<t>The PCRpt message is extended to support the BU object (see <xref target="sec_rep"/>).
The BU object in a PCRpt message specifies the upper limit set at the PCC
at the time of LSP delegation to an active stateful PCE.</t>
</section>
<section title="PCEP Message Extension" toc="default">
<section title="The PCReq message" toc="default" anchor="SEC_REQ">
<t>The extensions 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> and <xref target="STATEFUL-PCE"></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>
[<LSP>]
[<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 extensions 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> and <xref target="STATEFUL-PCE"></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>
[<LSP>]
[<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="The PCRpt message" toc="default" anchor="sec_rep">
<!--JEH <t>I've deleted a couple of redundant sentences.</t>-->
<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 the BU object.</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> ::= <intended_path><attribute-list>[<actual_path>]
</artwork>
</figure>
<t>Where <attribute-list> is extended as per <xref target="SEC_REP"/> for the BU object,
and <intended_path> and <actual_path> are defined in <xref target="STATEFUL-PCE"></xref>.</t>
</section>
</section>
<section title="Other Considerations" toc="default">
<section title="Inter-domain Path Computation" 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 a similar manner to the existing IGP or TE metrics.
The new BU object
defined in this document can be applied to end to end path
computation, in a similar manner to a METRIC object with its B bit set to 1.</t>
<t>All domains should have the same understanding of the METRIC
(path delay variation etc.) and the 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"/> MUST be applied.</t>
<section title="Inter-AS Links" toc="default">
<t>The IGP in each neighbour domain can advertise its inter-domain
TE link capabilities. This has been described in <xref target="RFC5316"/>
(IS-IS) and <xref target="RFC5392"/> (OSPF). The network performance
link properties are described in <xref target="RFC7471"/> and
<xref target="RFC7810"/>. The same properties must be advertised
using the mechanism described in <xref target="RFC5392"/> (OSPF) and
<xref target="RFC5316"/> (IS-IS).</t>
</section>
<section title="Inter-Layer Path Computation" 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 into the higher-layer network should include network performance
link properties based on the end to end metric of the lower-layer LSP. Note that
the new metrics 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="Reoptimizing Paths" toc="default">
<t><xref target="RFC6374"/> defines the measurement of loss, delay,
and related metrics over LSPs. A PCC can
utilize these measurement techniques. In case it detects a degradation
of network performance parameters relative to the value of the constraint it gave when the
path was set up, or relative to an implementation-specific
threshold, it MAY ask the PCE to reoptimize the path by sending a PCReq with the R bit set in the RP
object, as per <xref target="RFC5440"/>.</t>
<t>A PCC may also detect the degradation of an LSP without making any direct measurements,
by monitoring the TED (as populated by the IGP) for changes in the network performance
parameters of the links that carry its LSPs. The PCC MAY issue a reoptimization request
for any impacted LSPs.
For example, a PCC can 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. If the bandwidth utilization
percentage of any of the links in the path changes to a value less
than that required when the path was set up, or otherwise less
than an implementation-specific threshold, then the PCC MAY issue an reoptimization
request to a PCE.</t>
<t>A stateful PCE can also determine which LSPs should be re-optimized
based on network events or triggers from external monitoring systems.
For example, when a particular link deteriorates and its loss
increases, this can trigger the stateful PCE to automatically determine
which LSP are impacted and should be reoptimized.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="METRIC types" toc="default">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
at <http://www.iana.org/assignments/pcep>. Within this
registry IANA maintains one sub-registry for "METRIC object T field".
Six new metric types are defined in this document for the METRIC
object (specified in <xref target="RFC5440"/>). </t>
<t>IANA is requested to make the following allocations:</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Value Description Reference
----------------------------------------------------------
TBD1 Path Delay metric [This I.D.]
TBD2 Path Delay Variation metric [This I.D.]
TBD3 Path Loss metric [This I.D.]
TBD8 P2MP Path Delay metric [This I.D.]
TBD9 P2MP Path Delay variation metric [This I.D.]
TBD10 P2MP Path Loss metric [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="New PCEP Object" toc="default">
<t>IANA maintains object class in the registry of PCEP Objects
at the sub-registry "PCEP Objects". One
new allocation is requested as follows.</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" 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>This document requests that a new sub-registry, named "BU Object
Type Field", is created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Type field of the BU
object. New values are to be assigned by Standards Action <xref target="RFC5226"/>.
Each value should be tracked with the following qualities:
<list style="symbols">
<t>Type</t>
<t>Name</t>
<t>Defining RFC</t>
</list></t>
<t>The following values are defined in this document:</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" 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>IANA maintains registry of Objective Function (described in <xref target="RFC5541"/>) at the
sub-registry "Objective Function".
Three new Objective Functions have been
defined in this document.</t>
<t>IANA is requested to make the following allocations:</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" 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 title="New Error-Values" toc="default">
<t>IANA maintains a registry of Error-Types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.</t>
<t>IANA is requested to make the following allocations - </t>
<t>Two new Error-values are defined for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5).</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Error-Type Meaning and error values Reference
4 Not supported object
Error-value=TBD11 Unsupported [This I.D.]
network performance constraint
5 Policy violation
Error-value=TBD12 Not allowed [This I.D.]
network performance constraint
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document defines new METRIC types, a new BU object, and new 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 to be 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>The 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>The 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>The PCE requires the TED to be populated with network performance
information like link latency, delay variation, packet loss,
and utilized bandwidth.
This mechanism is described in <xref target="RFC7471"/>
and <xref target="RFC7810"/>.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>The 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>
<t>Thanks to Jonathan Hardwick for shepherding this document and
providing valuable comments. His help in fixing the editorial
and grammatical issues is also appreciated.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.3630.xml" ?>
<?rfc include="reference.RFC.5305.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<?rfc include="reference.RFC.7471.xml" ?>
<?rfc include="reference.RFC.7810.xml" ?>
<!--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="March" day="20" year="2016"/>
<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-14"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-stateful-pce-14.txt"/>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5226.xml" ?>
<?rfc include="reference.RFC.5316.xml" ?>
<?rfc include="reference.RFC.5392.xml" ?>
<?rfc include="reference.RFC.5441.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" ?>
<?rfc include="reference.RFC.7823.xml" ?>
<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 Gonzalez 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="March" day="8" year="2016"/>
<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 the flexibility and extensibility of PCEP.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pceps-09.txt"/>
</reference>
<!--IEEE.754.1985-->
<reference anchor="IEEE.754.1985">
<front>
<title>
Standard for Binary Floating-Point Arithmetic
</title>
<author fullname="IEEE Standard 754">
<organization >IEEE</organization>
</author>
<date month="August" year="1985"/>
</front>
<seriesInfo name="IEEE" value="754"/>
</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 560066
India
Email: udayasree.palle@huawei.com
Avantika
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
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:02:07 |