| PCE Working Group | D. Dhody |
| Internet-Draft | Q. Wu |
| Intended status: Standards Track | Huawei |
| Expires: April 8, 2016 | V. Manral |
| Ionos Network | |
| Z. Ali | |
| Cisco Systems | |
| K. Kumaki | |
| KDDI Corporation | |
| October 6, 2015 |
Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).
draft-ietf-pce-pcep-service-aware-08
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.
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 8, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC6374]. Further, there exist mechanisms to measure these network performance metrics after the Label Switched Path (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.
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.
Traffic Engineering Database (TED) is populated with network performance information like link latency, latency variation, and packet loss through [RFC7471] or [ISIS-TE-METRIC-EXT]. [TE-EXPRESS-PATH] describes how a Path Computation Element (PCE) [RFC4655], can use that information for path selection for explicitly routed LSPs.
Path Computation Client (PCC) can request PCE to provide a path meeting end to end network performance criteria. This document extends Path Computation Element Communication Protocol (PCEP) [RFC5440] to handle network performance constraints.
[RFC7471] and [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 during path computation.
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 [RFC2119].
The following terminology is used in this document.
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:
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.
This section defines PCEP extensions (see [RFC5440]) for requirements outlined in Section 3. The proposed solution is used to support network performance and service aware path computation.
The METRIC object is defined in section 7.8 of [RFC5440], comprising of metric-value, metric-type (T field) and flags. This document defines the following optional types for the METRIC object.
For explanation of these metrics, the following terminology is used and expanded along the way.
- A network comprises of a set of N links {Li, (i=1...N)}.
- A path P of a P2P LSP is a list of K links {Lpi,(i=1...K)}.
Link delay metric is defined in [RFC7471] and [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:
- A Link delay metric of link L is denoted D(L).
- A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}.
This is as per sum of means composition function (section 4.2.5 of [RFC6049]).
* Metric Type T=TBD1: Latency metric
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.
PCC MAY also use this metric to ask PCE to optimize latency during path computation, in this case B flag will be cleared.
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.
[RFC7471] and [ISIS-TE-METRIC-EXT] defines "Unidirectional Link Delay Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC object with 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, encoding for Latency (Delay) Metric Value is quantified in units of microseconds and encoded in IEEE floating point format.
Link delay variation metric is defined in [RFC7471] and [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:
- A Latency variation of link L is denoted DV(L) (average delay variation for link L).
- A P2P latency variation metric for the Path P = Sum {DV(Lpi), (i=1...K)}.
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.
* Metric Type T=TBD2: Latency Variation metric
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.
PCC MAY also use this metric to ask PCE to optimize latency variation during path computation, in this case B flag will be cleared.
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.
[RFC7471] and [ISIS-TE-METRIC-EXT] defines "Unidirectional Delay Variation Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC object with 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, encoding for Latency Variation (Jitter) Metric Value is quantified in units of microseconds and encoded in IEEE floating point format.
[RFC7471] and [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:
The end to end Packet Loss for the path is represented by this metric.
- A Packet loss of link L is denoted PL(L) in percentage.
- A Packet loss in fraction of link L is denoted FPL(L) = PL(L)/100.
- 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.
This is as per the composition function (section 5.1.5 of [RFC6049]).
* Metric Type T=TBD3: Packet Loss metric
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.
PCC MAY also use this metric to ask PCE to optimize packet loss during path computation, in this case B flag will be cleared.
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.
[RFC7471] and [ISIS-TE-METRIC-EXT] defines "Unidirectional Link Loss Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC object with 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]). Consequently, encoding for Packet Loss Metric Value is quantified as a percentage and encoded in IEEE floating point format.
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.
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) [RFC5440]. The path computation request MUST then be cancelled.
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) [RFC5440].
As explained in [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:
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.
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.
All the rules of processing METRIC object as explained in [RFC5440] are applicable to the new metric types as well.
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.
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:
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.
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:
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.
The bandwidth utilization on a link, forwarding adjacency, or bundled link is populated in the TED (Utilized Bandwidth in [RFC7471] and [ISIS-TE-METRIC-EXT]). 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.
LBU Percentage is described as the (LBU / Maximum bandwidth) * 100.
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.
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.
LRBU Percentage is described as the (LRBU / (Maximum reservable bandwidth)) * 100.
The BU (the Bandwidth Utilization) is used to indicate the upper limit of the acceptable link bandwidth utilization percentage.
The BU object may be carried within the PCReq message and PCRep messages.
BU Object-Class is TBD4.
BU Object-Type is 1.
The format of the BU object body is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BU Object Body Format
The BU object body has a fixed length of 8 bytes.
A PCC SHOULD request the PCE to factor in the bandwidth utilization during path computation by including a BU object in the PCReq message.
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.
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.
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.
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) [RFC5440]. The path computation request MUST then be cancelled.
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) [RFC5440].
[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 -
Two additional objective functions -- namely, MUP (the Maximum Under-Utilized Path) and MRUP (the Maximum Reserved Under-Utilized Path) are need to optimize bandwidth utilization. Hence two new objective function codes have to be defined.
Objective functions are formulated using the following additional terminology:
The description of the two new objective functions is as follows.
These new objective functions are used to optimize paths based on the bandwidth utilization as the optimization criteria.
If the objective function defined in this document are unknown/unsupported, the procedure as defined in [RFC5541] is followed.
The extension to PCReq message are -
The format of the PCReq message (with [RFC5541] as a base) is updated as follows:
<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>]
The extension to PCRep message are -
The format of the PCRep message (with [RFC5541] as a base) is updated as follows:
<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>]
[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. 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.
The passive stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5.1 and Section 5.2 to enable the use of service aware parameters.
The additional objective functions defined in this document can also be used with 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 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.
As per [STATEFUL-PCE], the format of the PCRpt message is as follows:
<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>]
Where <attribute-list> is extended as per Section 5.2 for BU object.
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.
[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.
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 [RFC5441] MAY need to be applied.
The IGP in each neighbour domain can advertise its inter-domain TE link capabilities, this has been described in [RFC5316] (ISIS) and [RFC5392] (OSPF). The network performance link properties are described in [RFC7471] and [ISIS-TE-METRIC-EXT], the same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (ISIS).
[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.
PCC can monitor the setup LSPs and in case of degradation of network performance constraints, it MAY ask PCE for reoptimization as per [RFC5440]. Based on the changes in performance parameters in TED, a PCC MAY also issue a reoptimization request.
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 [RFC5440].
This document defines the following optional types for the METRIC object defined in [RFC5440] for P2MP TE LSPs. The usage of BU object for P2MP LSP is out of scope of this document.
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:
- A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)}
- P2P latency metric of the Path to destination Dest_j is denoted by LM(Dest_j).
- P2MP latency metric for the P2MP tree T = Maximum {LM(Dest_j), (j=1...M)}.
Value for P2MP latency metric type (T) = TBD8 is to be assigned by IANA.
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:
- A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)}
- P2P latency variation metric of the Path to destination Dest_j is denoted by LVM(Dest_j).
- P2MP latency variation metric for the P2MP tree T = Maximum {LVM(Dest_j), (j=1...M)}.
Value for P2MP latency variation metric type (T) = TBD9 is to be assigned by IANA.
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:
- A P2MP Tree T comprises of a set of M destinations {Dest_j, (j=1...M)}
- P2P packet loss metric of the Path to destination Dest_j is denoted by PLM(Dest_j).
- P2MP packet loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}.
Value for P2MP packet loss metric type (T) = = TBD10 is to be assigned by IANA.
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this registry IANA maintains one sub-registrie for "METRIC object T field" at http://www.iana.org/assignments/pcep/pcep.xhtml#metric-object-ni-field. Six new metric types are defined in this document for the METRIC object (specified in [RFC5440]).
IANA is requested to make the following allocations:
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.]
IANA maintains object class in the registry of PCEP Objects at the sub-registry http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects. One new allocation is requested as follows.
Object Object Name Reference
Class Type
---------------------------------------------------
TBD4 1 BU [This I.D.]
IANA is requested to create a new sub-registry to manage the codespace of the Type field of the BU Object.
Codespace of the T field (BU Object)
Type Name Reference
--------------------------------------------------
1 LBU (Link Bandwidth [This I.D.]
Utilization
2 LRBU (Link Residual [This I.D.]
Bandwidth Utilization
IANA maintains registry of Objective Function (described in [RFC5541]) at the sub-registry http://www.iana.org/assignments/pcep/pcep.xhtml#of. Three new Objective Functions have been defined in this document.
IANA is requested to make the following allocations:
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)
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 [RFC5440] and [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 [PCEPS].
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.
[RFC7420] describes the PCEP MIB, there are no new MIB Objects for this document.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
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 [RFC7471] and [ISIS-TE-METRIC-EXT].
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
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.
Also the authors gratefully acknowledge reviews and feedback provided by Qin Wu, Alfred Morton and Paul Aitken during performance directorate review.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009. |
| [RFC5541] | Le Roux, JL., Vasseur, JP. and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009. |
| [STATEFUL-PCE] | Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-11, April 2015. |
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