RFC 5440
Path Computation Element (PCE) Communication Protocol (PCEP)
7.11. LSPA Object
The LSPA (LSP Attributes) object is optional and specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA object can be carried within a PCReq message, or a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the LSPA object is used to indicate the set of constraints that could not be satisfied). Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. See Section 4.7.4 of [RFC3209] for a detailed description of the use of resource affinities. LSPA Object-Class is 9. LSPA Object-Types is 1.
The format of the LSPA object body is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: LSPA Object Body Format Setup Prio (Setup Priority - 8 bits): The priority of the TE LSP with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session. Holding Prio (Holding Priority - 8 bits): The priority of the TE LSP with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. Flags (8 bits) L flag: Corresponds to the "Local Protection Desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Note that optional TLVs may be defined in the future to carry additional TE LSP attributes such as those defined in [RFC5420].
7.12. Include Route Object
The IRO (Include Route Object) is optional and can be used to specify that the computed path MUST traverse a set of specified network elements. The IRO MAY be carried within PCReq and PCRep messages. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of elements that cause the PCE to fail to find a path. IRO Object-Class is 10. IRO Object-Type is 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Sub-objects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: IRO Body Format Sub-objects: The IRO is made of sub-objects identical to the ones defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub- object type is identical to the sub-object type defined in the related documents. The following sub-object types are supported. Type Sub-object 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number The L bit of such sub-object has no meaning within an IRO.7.13. SVEC Object
7.13.1. Notion of Dependent and Synchronized Path Computation Requests
Independent versus dependent path computation requests: path computation requests are said to be independent if they are not related to each other. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other (a typical example of dependent requests is the computation of a set of diverse paths).
Synchronized versus non-synchronized path computation requests: a set of path computation requests is said to be non-synchronized if their respective treatment (path computations) can be performed by a PCE in a serialized and independent fashion. There are various circumstances where the synchronization of a set of path computations may be beneficial or required. Consider the case of a set of N TE LSPs for which a PCC needs to send path computation requests to a PCE. The first solution consists of sending N separate PCReq messages to the selected PCE. In this case, the path computation requests are non-synchronized. Note that the PCC may chose to distribute the set of N requests across K PCEs for load balancing purposes. Considering that M (with M<N) requests are sent to a particular PCEi, as described above, such M requests can be sent in the form of successive PCReq messages destined to PCEi or bundled within a single PCReq message (since PCEP allows for the bundling of multiple path computation requests within a single PCReq message). That said, even in the case of independent requests, it can be desirable to request from the PCE the computation of their paths in a synchronized fashion that is likely to lead to more optimal path computations and/or reduced blocking probability if the PCE is a stateless PCE. In other words, the PCE should not compute the corresponding paths in a serialized and independent manner, but it should rather "simultaneously" compute their paths. For example, trying to "simultaneously" compute the paths of M TE LSPs may allow the PCE to improve the likelihood to meet multiple constraints. Consider the case of two TE LSPs requesting N1 Mbit/s and N2 Mbit/s, respectively, and a maximum tolerable end-to-end delay for each TE LSP of X ms. There may be circumstances where the computation of the first TE LSP, irrespectively of the second TE LSP, may lead to the impossibility to meet the delay constraint for the second TE LSP. A second example is related to the bandwidth constraint. It is quite straightforward to provide examples where a serialized independent path computation approach would lead to the impossibility to satisfy both requests (due to bandwidth fragmentation), while a synchronized path computation would successfully satisfy both requests. A last example relates to the ability to avoid the allocation of the same resource to multiple requests, thus helping to reduce the call setup failure probability compared to the serialized computation of independent requests. Dependent path computations are usually synchronized. For example, in the case of the computation of M diverse paths, if such paths are computed in a non-synchronized fashion, this seriously increases the
probability of not being able to satisfy all requests (sometimes also
referred to as the well-known "trapping problem").
Furthermore, this would not allow a PCE to implement objective
functions such as trying to minimize the sum of the TE LSP costs. In
such a case, the path computation requests must be synchronized: they
cannot be computed independently of each other.
Conversely, a set of independent path computation requests may or may
not be synchronized.
The synchronization of a set of path computation requests is achieved
by using the SVEC object that specifies the list of synchronized
requests that can either be dependent or independent.
PCEP supports the following three modes:
o Bundle of a set of independent and non-synchronized path
computation requests,
o Bundle of a set of independent and synchronized path computation
requests (requires the SVEC object defined below),
o Bundle of a set of dependent and synchronized path computation
requests (requires the SVEC object defined below).
7.13.2. SVEC Object
Section 7.13.1 details the circumstances under which it may be
desirable and/or required to synchronize a set of path computation
requests. The SVEC (Synchronization VECtor) object allows a PCC to
request the synchronization of a set of dependent or independent path
computation requests. The SVEC object is optional and may be carried
within a PCReq message.
The aim of the SVEC object carried within a PCReq message is to
request the synchronization of M path computation requests. The SVEC
object is a variable-length object that lists the set of M path
computation requests that must be synchronized. Each path
computation request is uniquely identified by the Request-ID-number
carried within the respective RP object. The SVEC object also
contains a set of flags that specify the synchronization type.
SVEC Object-Class is 11.
SVEC Object-Type is 1.
The format of the SVEC 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 | Flags |S|N|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number #1 | // // | Request-ID-number #M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SVEC Body Object Format Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags (24 bits): Defines the potential dependency between the set of path computation requests. * L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any link in common. * N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any node in common. * S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT share any SRLG (Shared Risk Link Group). In case of a set of M synchronized independent path computation requests, the bits L, N, and S are cleared. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. The flags defined above are not exclusive.7.13.3. Handling of the SVEC Object
The SVEC object allows a PCC to specify a list of M path computation requests that MUST be synchronized along with a potential dependency. The set of M path computation requests may be sent within a single PCReq message or multiple PCReq messages. In the latter case, it is RECOMMENDED for the PCE to implement a local timer (called the
SyncTimer) activated upon the receipt of the first PCReq message that contains the SVEC object after the expiration of which, if all the M path computation requests have not been received, a protocol error is triggered. When a PCE receives a path computation request that cannot be satisfied (for example, because the PCReq message contains an object with the P bit set that is not supported), the PCE sends a PCErr message for this request (see Section 7.2), the PCE MUST cancel the whole set of related path computation requests and MUST send a PCErr message with Error-Type="Synchronized path computation request missing". Note that such PCReq messages may also contain non-synchronized path computation requests. For example, the PCReq message may comprise N synchronized path computation requests that are related to RP 1, ..., RP N and are listed in the SVEC object along with any other path computation requests that are processed as normal.7.14. NOTIFICATION Object
The NOTIFICATION object is exclusively carried within a PCNtf message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC so as to notify of an event. NOTIFICATION Object-Class is 12. NOTIFICATION Object-Type is 1. The format of the NOTIFICATION body object 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 | Flags | NT | NV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: NOTIFICATION Body Object Format Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags (8 bits): No flags are currently defined. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
NT (Notification Type - 8 bits): The Notification-type specifies the
class of notification.
NV (Notification Value - 8 bits): The Notification-value provides
addition information related to the nature of the notification.
Both the Notification-type and Notification-value are managed by
IANA.
The following Notification-type and Notification-value values are
currently defined:
o Notification-type=1: Pending Request cancelled
* Notification-value=1: PCC cancels a set of pending requests. A
Notification-type=1, Notification-value=1 indicates that the
PCC wants to inform a PCE of the cancellation of a set of
pending requests. Such an event could be triggered because of
external conditions such as the receipt of a positive reply
from another PCE (should the PCC have sent multiple requests to
a set of PCEs for the same path computation request), a network
event such as a network failure rendering the request obsolete,
or any other events local to the PCC. A NOTIFICATION object
with Notification-type=1, Notification-value=1 is carried
within a PCNtf message sent by the PCC to the PCE. The RP
object corresponding to the cancelled request MUST also be
present in the PCNtf message. Multiple RP objects may be
carried within the PCNtf message; in which case, the
notification applies to all of them. If such a notification is
received by a PCC from a PCE, the PCC MUST silently ignore the
notification and no errors should be generated.
* Notification-value=2: PCE cancels a set of pending requests. A
Notification-type=1, Notification-value=2 indicates that the
PCE wants to inform a PCC of the cancellation of a set of
pending requests. A NOTIFICATION object with Notification-
type=1, Notification-value=2 is carried within a PCNtf message
sent by a PCE to a PCC. The RP object corresponding to the
cancelled request MUST also be present in the PCNtf message.
Multiple RP objects may be carried within the PCNtf message; in
which case, the notification applies to all of them. If such
notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be
generated.
o Notification-type=2: Overloaded PCE
* Notification-value=1: A Notification-type=2, Notification-
value=1 indicates to the PCC that the PCE is currently in an
overloaded state. If no RP objects are included in the PCNtf
message, this indicates that no other requests SHOULD be sent
to that PCE until the overloaded state is cleared: the pending
requests are not affected and will be served. If some pending
requests cannot be served due to the overloaded state, the PCE
MUST also include a set of RP objects that identifies the set
of pending requests that are cancelled by the PCE and will not
be honored. In this case, the PCE does not have to send an
additional PCNtf message with Notification-type=1 and
Notification-value=2 since the list of cancelled requests is
specified by including the corresponding set of RP objects. If
such notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be
generated.
* A PCE implementation SHOULD use a dual-threshold mechanism used
to determine whether it is in a congestion state with regards
to specific resource monitoring (e.g. CPU, memory). The use
of such thresholds is to avoid oscillations between overloaded/
non-overloaded state that may result in oscillations of request
targets by the PCCs.
* Optionally, a TLV named OVERLOADED-DURATION may be included in
the NOTIFICATION object that specifies the period of time
during which no further request should be sent to the PCE.
Once this period of time has elapsed, the PCE should no longer
be considered in a congested state.
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
format defined in Section 7.1 and is comprised of 2 bytes for
the type, 2 bytes specifying the TLV length (length of the
value portion in bytes), followed by a fixed-length value field
of a 32-bit flags field.
Type: 2
Length: 4 bytes
Value: 32-bit flags field indicates the estimated PCE
congestion duration in seconds.
* Notification-value=2: A Notification-type=2, Notification-
value=2 indicates that the PCE is no longer in an overloaded
state and is available to process new path computation
requests. An implementation SHOULD make sure that a PCE sends
such notification to every PCC to which a Notification message
(with Notification-type=2, Notification-value=1) has been sent
unless an OVERLOADED-DURATION TLV has been included in the
corresponding message and the PCE wishes to wait for the
expiration of that period of time before receiving new
requests. If such notification is received by a PCE from a
PCC, the PCE MUST silently ignore the notification and no
errors should be generated. It is RECOMMENDED to support some
dampening notification procedure on the PCE so as to avoid too
frequent congestion state and congestion state release
notifications. For example, an implementation could make use
of an hysteresis approach using a dual-threshold mechanism that
triggers the sending of congestion state notifications.
Furthermore, in case of high instabilities of the PCE
resources, an additional dampening mechanism SHOULD be used
(linear or exponential) to pace the notification frequency and
avoid oscillation of path computation requests.
When a PCC receives an overload indication from a PCE, it should
consider the impact on the entire network. It must be remembered
that other PCCs may also receive the notification, and so many path
computation requests could be redirected to other PCEs. This may, in
turn, cause further overloading at PCEs in the network. Therefore,
an application at a PCC receiving an overload notification should
consider applying some form of back-off (e.g., exponential) to the
rate at which it generates path computation requests into the
network. This is especially the case as the number of PCEs reporting
overload grows.
7.15. PCEP-ERROR Object
The PCEP-ERROR object is exclusively carried within a PCErr message
to notify of a PCEP error.
PCEP-ERROR Object-Class is 13.
PCEP-ERROR Object-Type is 1.
The format of the PCEP-ERROR 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 | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: PCEP-ERROR Object Body Format
A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-value are managed by IANA
(see the IANA section).
Reserved (8 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Flags (8 bits): no flag is currently defined. This flag MUST be set
to zero on transmission and MUST be ignored on receipt.
Error-Type (8 bits): defines the class of error.
Error-value (8 bits): provides additional details about the error.
Optionally, the PCEP-ERROR object may contain additional TLVs so as
to provide further information about the encountered error.
A single PCErr message may contain multiple PCEP-ERROR objects.
For each PCEP error, an Error-Type and an Error-value are defined.
Error-Type Meaning
1 PCEP session establishment failure
Error-value=1: reception of an invalid Open message or
a non Open message.
Error-value=2: no Open message received before the
expiration of the OpenWait timer
Error-value=3: unacceptable and non-negotiable session
characteristics
Error-value=4: unacceptable but negotiable session
characteristics
Error-value=5: reception of a second Open message with
still unacceptable session
characteristics
Error-value=6: reception of a PCErr message proposing
unacceptable session characteristics
Error-value=7: No Keepalive or PCErr message received
before the expiration of the KeepWait
timer
2 Capability not supported
3 Unknown Object
Error-value=1: Unrecognized object class
Error-value=2: Unrecognized object Type
4 Not supported object
Error-value=1: Not supported object class
Error-value=2: Not supported object Type
5 Policy violation
Error-value=1: C bit of the METRIC object set
(request rejected)
Error-value=2: O bit of the RP object set
(request rejected)
6 Mandatory Object missing
Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set)
when bandwidth is not equal to 0.
Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing
8 Unknown request reference
9 Attempt to establish a second PCEP session
10 Reception of an invalid object
Error-value=1: reception of an object with P flag not
set although the P flag must be set according to this
specification.
The error types listed above are described below.
Error-Type=1: PCEP session establishment failure.
If a malformed message is received, the receiving PCEP peer MUST
send a PCErr message with Error-Type=1, Error-value=1.
If no Open message is received before the expiration of the
OpenWait timer, the receiving PCEP peer MUST send a PCErr message
with Error-Type=1, Error-value=2 (see Appendix A for details).
If one or more PCEP session characteristics are unacceptable by
the receiving peer and are not negotiable, it MUST send a PCErr
message with Error-Type=1, Error-value=3.
If an Open message is received with unacceptable session
characteristics but these characteristics are negotiable, the
receiving PCEP peer MUST send a PCErr message with Error-Type-1,
Error-value=4 (see Section 6.2 for details).
If a second Open message is received during the PCEP session
establishment phase and the session characteristics are still
unacceptable, the receiving PCEP peer MUST send a PCErr message
with Error-Type-1, Error-value=5 (see Section 6.2 for details).
If a PCErr message is received during the PCEP session
establishment phase that contains an Open message proposing
unacceptable session characteristics, the receiving PCEP peer MUST
send a PCErr message with Error-Type=1, Error-value=6.
If neither a Keepalive message nor a PCErr message is received
before the expiration of the KeepWait timer during the PCEP
session establishment phase, the receiving PCEP peer MUST send a
PCErr message with Error-Type=1, Error-value=7.
Error-Type=2: the PCE indicates that the path computation request
cannot be honored because it does not support one or more required
capability. The corresponding path computation request MUST be
cancelled.
Error-Type=3 or Error-Type=4: if a PCEP message is received that
carries a PCEP object (with the P flag set) not recognized by the
PCE or recognized but not supported, then the PCE MUST send a
PCErr message with a PCEP-ERROR object (Error-Type=3 and 4,
respectively). In addition, the PCE MAY include in the PCErr
message the unknown or not supported object. The corresponding
path computation request MUST be cancelled by the PCE without
further notification.
Error-Type=5: if a path computation request is received that is not
compliant with an agreed policy between the PCC and the PCE, the
PCE MUST send a PCErr message with a PCEP-ERROR object (Error-
Type=5). The corresponding path computation MUST be cancelled.
Policy-specific TLVs carried within the PCEP-ERROR object may be
defined in other documents to specify the nature of the policy
violation.
Error-Type=6: if a path computation request is received that does
not contain a mandatory object, the PCE MUST send a PCErr message
with a PCEP-ERROR object (Error-Type=6). If there are multiple
mandatory objects missing, the PCErr message MUST contain one
PCEP-ERROR object per missing object. The corresponding path
computation MUST be cancelled.
Error-Type=7: if a PCC sends a synchronized path computation request
to a PCE and the PCE does not receive all the synchronized path
computation requests listed within the corresponding SVEC object
after the expiration of the timer SyncTimer defined in
Section 7.13.3, the PCE MUST send a PCErr message with a PCEP-
ERROR object (Error-Type=7). The corresponding synchronized path
computation MUST be cancelled. It is RECOMMENDED for the PCE to
include the REQ-MISSING TLVs (defined below) that identify the
missing requests.
The REQ-MISSING TLV is compliant with the PCEP TLV format defined
in section 7.1 and is comprised of 2 bytes for the type, 2 bytes
specifying the TLV length (length of the value portion in bytes),
followed by a fixed-length value field of 4 bytes.
Type: 3
Length: 4 bytes
Value: 4 bytes that indicate the Request-ID-number that
corresponds to the missing request.
Error-Type=8: if a PCC receives a PCRep message related to an
unknown path computation request, the PCC MUST send a PCErr
message with a PCEP-ERROR object (Error-Type=8). In addition, the
PCC MUST include in the PCErr message the unknown RP object.
Error-Type=9: if a PCEP peer detects an attempt from another PCEP
peer to establish a second PCEP session, it MUST send a PCErr
message with Error-Type=9, Error-value=1. The existing PCEP
session MUST be preserved and all subsequent messages related to
the tentative establishment of the second PCEP session MUST be
silently ignored.
Error-Type=10: if a PCEP peers receives an object with the P flag
not set although the P flag must be set according to this
specification, it MUST send a PCErr message with Error-Type=10,
Error-value=1.
7.16. LOAD-BALANCING Object
There are situations where no TE LSP with a bandwidth of X could be
found by a PCE although such a bandwidth requirement could be
satisfied by a set of TE LSPs such that the sum of their bandwidths
is equal to X. Thus, it might be useful for a PCC to request a set
of TE LSPs so that the sum of their bandwidth is equal to X Mbit/s,
with potentially some constraints on the number of TE LSPs and the
minimum bandwidth of each of these TE LSPs. Such a request is made
by inserting a LOAD-BALANCING object in a PCReq message sent to a
PCE.
The LOAD-BALANCING object is optional.
LOAD-BALANCING Object-Class is 14.
LOAD-BALANCING Object-Type is 1.
The format of the LOAD-BALANCING 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 | Flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LOAD-BALANCING Object Body Format
Reserved (16 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Flags (8 bits): No flag is currently defined. The Flags field MUST
be set to zero on transmission and MUST be ignored on receipt.
Max-LSP (8 bits): maximum number of TE LSPs in the set.
Min-Bandwidth (32 bits): Specifies the minimum bandwidth of each
element of the set of TE LSPs. The bandwidth is encoded in 32
bits in IEEE floating point format (see [IEEE.754.1985]),
expressed in bytes per second.
The LOAD-BALANCING object body has a fixed length of 8 bytes. If a PCC requests the computation of a set of TE LSPs so that the sum of their bandwidth is X, the maximum number of TE LSPs is N, and each TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALANCING object with the Max-LSP and Min-Bandwidth fields set to N and B, respectively.7.17. CLOSE Object
The CLOSE object MUST be present in each Close message. There MUST be only one CLOSE object per Close message. If a Close message is received that contains more than one CLOSE object, the first CLOSE object is the one that must be processed. Other CLOSE objects MUST be silently ignored. CLOSE Object-Class is 15. CLOSE Object-Type is 1. The format of the CLOSE 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 | Flags | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: CLOSE Object Format Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags (8 bits): No flags are currently defined. The Flag field MUST be set to zero on transmission and MUST be ignored on receipt. Reason (8 bits): specifies the reason for closing the PCEP session. The setting of this field is optional. IANA manages the codespace of the Reason field. The following values are currently defined:
Reasons
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of unknown
requests/replies
5 Reception of an unacceptable number of unrecognized
PCEP messages
Optional TLVs may be included within the CLOSE object body. The
specification of such TLVs is outside the scope of this document.
8. Manageability Considerations
This section follows the guidance of [PCE-MANAGE].
8.1. Control of Function and Policy
A PCEP implementation SHOULD allow configuring the following PCEP
session parameters on the implementation:
o The local Keepalive and DeadTimer (i.e., parameters sent by the
PCEP peer in an Open message),
o The maximum acceptable remote Keepalive and DeadTimer (i.e.,
parameters received from a peer in an Open message),
o Whether negotiation is enabled or disabled,
o If negotiation is allowed, the minimum acceptable Keepalive and
DeadTimer timers received from a PCEP peer,
o The SyncTimer,
o The maximum number of sessions that can be set up,
o The request timer, the amount of time a PCC waits for a reply
before resending its path computation requests (potentially to an
alternate PCE),
o The MAX-UNKNOWN-REQUESTS,
o The MAX-UNKNOWN-MESSAGES.
These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific
session with a given PCEP peer or to a specific group of sessions
with a specific group of PCEP peers. A PCEP implementation SHOULD
allow configuring the initiation of a PCEP session with a selected
subset of discovered PCEs. Note that PCE selection is a local
implementation issue. A PCEP implementation SHOULD allow configuring
a specific PCEP session with a given PCEP peer. This includes the
configuration of the following parameters:
o The IP address of the PCEP peer,
o The PCEP speaker role: PCC, PCE, or both,
o Whether the PCEP speaker should initiate the PCEP session or wait
for initiation by the peer,
o The PCEP session parameters, as listed above, if they differ from
the default parameters,
o A set of PCEP policies including the type of operations allowed
for the PCEP peer (e.g., diverse path computation,
synchronization, etc.).
A PCEP implementation MUST allow restricting the set of PCEP peers
that can initiate a PCEP session with the PCEP speaker (e.g., list of
authorized PCEP peers, all PCEP peers in the area, all PCEP peers in
the AS).
8.2. Information and Data Models
A PCEP MIB module is defined in [PCEP-MIB] that describes managed
objects for modeling of PCEP communication including:
o PCEP client configuration and status,
o PCEP peer configuration and information,
o PCEP session configuration and information,
o Notifications to indicate PCEP session changes.
8.3. Liveness Detection and Monitoring
PCEP includes a keepalive mechanism to check the liveliness of a PCEP
peer and a notification procedure allowing a PCE to advertise its
overloaded state to a PCC. Also, procedures in order to monitor the
liveliness and performances of a given PCE chain (in case of
multiple-PCE path computation) are defined in [PCE-MONITOR].
8.4. Verifying Correct Operation
Verifying the correct operation of a PCEP communication can be performed by monitoring various parameters. A PCEP implementation SHOULD provide the following parameters: o Response time (minimum, average, and maximum), on a per-PCE-peer basis, o PCEP session failures, o Amount of time the session has been in active state, o Number of corrupted messages, o Number of failed computations, o Number of requests for which no reply has been received after the expiration of a configurable timer and by verifying that at least one path exists that satisfies the set of constraints. A PCEP implementation SHOULD log error events (e.g., corrupted messages, unrecognized objects).8.5. Requirements on Other Protocols and Functional Components
PCEP does not put any new requirements on other protocols. As PCEP relies on the TCP transport protocol, PCEP management can make use of TCP management mechanisms (such as the TCP MIB defined in [RFC4022]). The PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an impact on PCEP. To avoid that a high frequency of PCE Discoveries/ Disappearances triggers a high frequency of PCEP session setups/ deletions, it is RECOMMENDED to introduce some dampening for establishment of PCEP sessions.8.6. Impact on Network Operation
In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker, and MAY allow a limit to be placed on the rate of messages sent by a PCEP speaker and received from a peer. It MAY also allow sending a notification when a rate threshold is reached.
(next page on part 4)
