Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).

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 . It is important that latency, delay variation, and packet loss are considered during the 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 the path computation. 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 or IS-IS or via a management system. describes how a Path Computation Element (PCE) , can use that information for path selection for explicitly routed LSPs. 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) to handle network performance constraints which include any combination of latency, delay variation, packet loss and bandwidth utilization constraints.

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 .

The following terminology is used in this document. Interior Gateway Protocol; Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). Intermediate System to Intermediate System Link Bandwidth Utilization (See .) Link Reserved Bandwidth Utilization (See .) Minimum Packet Loss Path (See .) Maximum Reserved Under-Utilized Path (See .) Maximum Under-Utilized Path (See .) 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 .) Open Shortest Path First Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element. 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. Resource Reservation Protocol Traffic Engineering Traffic Engineering Database

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: 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...). 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. A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria. 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. A PCE SHOULD be able to return end to end network performance information of the computed path in a Path Computation Reply (PCRep) message. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) service aware paths. 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.

This section defines PCEP extensions (see ) for requirements outlined in . The proposed solution is used to support network performance and service aware path computation.

The METRIC object is defined in section 7.8 of , comprising metric-value, metric-type (T field) and flags. This document defines the following types for the METRIC object. T=TBD1: Path Delay metric () T=TBD2: Path Delay Variation metric () T=TBD3: Path Loss metric () T=TBD8: P2MP Path Delay metric () T=TBD9: P2MP Path Delay Variation metric () T=TBD10: P2MP Path Loss metric () 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 point to point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.

The link delay metric is defined in and 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: - A link delay metric of link L is denoted D(L). - A path delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}. This is as per the sum of means composition function (section 4.2.5 of ). * Metric Type T=TBD1: Path Delay metric 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. 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. 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.

and define the "Unidirectional Link Delay Sub-TLV" in a 24-bit field. defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see ). Consequently, the encoding for the path delay metric value is quantified in units of microseconds and encoded in IEEE floating point format.

The link delay variation metric is defined in and 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: - A delay variation of link L is denoted DV(L) (average delay variation for link L). - A path delay variation metric for the P2P path P = Sum {DV(Lpi), (i=1...K)}. 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. * Metric Type T=TBD2: Path Delay Variation metric 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. 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. 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.

and define "Unidirectional Delay Variation Sub-TLV" in a 24-bit field. defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see ). Consequently, the encoding for the path delay variation metric value is quantified in units of microseconds and encoded in IEEE floating point format.

and 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: The end to end path loss for the path is represented by this metric. - The percentage link loss of link L is denoted PL(L). - The fractional link loss of link L is denoted FL(L) = PL(L)/100. - 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. This is as per the composition function described in section 5.1.5 of . * Metric Type T=TBD3: Path Loss metric 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. 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. 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.

and define "Unidirectional Link Loss Sub-TLV" in a 24-bit field. defines the METRIC object with 32-bit metric value encoded in IEEE floating point format (see ). Consequently, the encoding for the path loss metric value is quantified as a percentage and encoded in IEEE floating point format.

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 . 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) . 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. 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.

As explained in , 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: To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation or path loss). 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. 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. 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 the METRIC object as explained in are applicable to the new metric types as well.

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: First METRIC object with B=0, T=TBD1, C=1, metric-value=0x0000 Second METRIC object with B=1, T=TBD3, metric-value=M 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.

This section defines the following optional types for the METRIC object for P2MP TE LSPs.

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: - A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)} - The P2P path delay metric of the path to destination Dest_j is denoted by LM(Dest_j). - The P2MP path delay metric for the P2MP tree T = Maximum {LM(Dest_j), (j=1...M)}. The value for the P2MP path delay metric type (T) = TBD8 is to be assigned by IANA.

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: - A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)} - The P2P path delay variation metric of the path to the destination Dest_j is denoted by LVM(Dest_j). - The P2MP path delay variation metric for the P2MP tree T = Maximum {LVM(Dest_j), (j=1...M)}. The value for the P2MP path delay variation metric type (T) = TBD9 is to be assigned by IANA.

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: - A P2MP tree T comprises of a set of M destinations {Dest_j, (j=1...M)} - The P2P path loss metric of the path to destination Dest_j is denoted by PLM(Dest_j). - The P2MP path loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}. The value for the P2MP path loss metric type (T) = TBD10 is to be assigned by IANA.

The bandwidth utilization on a link, forwarding adjacency, or bundled link is populated in the TED ("Utilized Bandwidth" in and ). 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. The LBU percentage is described as the (LBU / maximum bandwidth) * 100. Where "maximum bandwidth" is defined in and .

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. 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 ( and ). Once we have the actual bandwidth for non-RSVP TE traffic, subtracting this from LBU would result in LRBU. LRBU = LBU - (residual bandwidth - available bandwidth) LRBU percentage is described as the (LRBU / (maximum reservable bandwidth)) * 100. Where the "maximum reservable bandwidth" is defined in and .

The BU object 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This field MUST be set to zero on transmission and MUST be ignored on receipt. Represents the bandwidth utilization type. Two values are currently defined. Type 1 is Link Bandwidth Utilization (LBU) Type 2 is Link Reserved Bandwidth Utilization (LRBU) Represents the bandwidth utilization quantified as a percentage (as described in and ) and encoded in IEEE floating point format (see ). 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. 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. 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. 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. 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 . 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. 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. 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. Usage of the BU object for P2MP LSPs is outside the scope of this document.

defines a mechanism to specify an objective function that is used by a PCE when it computes a path. The new metric types for path delay and path delay variation can continue to use the existing objective function - Minimum Cost Path (MCP) . For path loss, the following new OF is defined. A network comprises a set of N links {Li, (i=1...N)}. A path P is a list of K links {Lpi,(i=1...K)}. The percentage link loss of link L is denoted PL(L). The fractional link loss of link L is denoted FL(L) = PL(L) / 100. 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. TBD5 Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized. 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. These objective functions are formulated using the following additional terminology: The bandwidth utilization on link L is denoted u(L). The reserved bandwidth utilization on link L is denoted ru(L). The maximum bandwidth on link L is denoted M(L). The maximum reservable bandwidth on link L is denoted R(L). The description of the two new objective functions is as follows. TBD6 Name: Maximum Under-Utilized Path (MUP) Description: Find a path P such that (Min {(M(Lpi)- u(Lpi)) / M(Lpi), i=1...K } ) is maximized. TBD7 Name: Maximum Reserved Under-Utilized Path (MRUP) Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / R(Lpi), i=1...K } ) is maximized. These new objective functions are used to optimize paths based on the bandwidth utilization as the optimization criteria. If the objective functions defined in this document are unknown/unsupported by a PCE, then the procedure as defined in is followed.

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. The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in and to enable the use of service aware parameters. The additional objective functions defined in this document can also be used with stateful PCE. The PCRpt message is extended to support the BU object (see ). 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.

The extensions to PCReq message are - new metric types using existing METRIC object a new optional BU object new objective functions using existing OF object () The format of the PCReq message (with and 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> [<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>]

The extensions to PCRep message are - new metric types using existing METRIC object a new optional BU object (during unsuccessful path computation, to indicate the bandwidth utilization as a reason for failure) new objective functions using existing OF object () The format of the PCRep message (with and 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> [<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>]

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. As per , 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> ::= <intended_path><attribute-list>[<actual_path>] Where <attribute-list> is extended as per for the BU object, and <intended_path> and <actual_path> are defined in .

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. 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 MUST be applied.

The IGP in each neighbour domain can advertise its inter-domain TE link capabilities. This has been described in (IS-IS) and (OSPF). The network performance link properties are described in and . The same properties must be advertised using the mechanism described in (OSPF) and (IS-IS).

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.

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 . 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. 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.

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 ). IANA is requested to make the following allocations:

IANA maintains object class in the registry of PCEP Objects at the sub-registry "PCEP Objects". One new allocation is requested as follows.

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 . Each value should be tracked with the following qualities: Type Name Defining RFC The following values are defined in this document:

IANA maintains registry of Objective Function (described in ) at the sub-registry "Objective Function". Three new Objective Functions have been defined in this document. IANA is requested to make the following allocations:

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. IANA is requested to make the following allocations - Two new Error-values are defined for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5).

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 and 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 .

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.

describes the PCEP MIB. There are no new MIB Objects for this document.

The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in .

The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in .

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 and .

The mechanisms defined in this document do not have any impact on network operations in addition to those already listed in .

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. Thanks to Jonathan Hardwick for shepherding this document and providing valuable comments. His help in fixing the editorial and grammatical issues is also appreciated.