Table of Contents
Advertisement
MPLS Guide
The behavior and limitations of the implementation of the TLVs, objects, and
messages in
3HE 18686 AAAB TQZZA
Table 33
are as follows.
• The PCC and PCE support all PCEP capability TLVs defined in this document
and will always advertise them. If the OPEN object received from a PCEP
speaker does not contain one or more of the capabilities, the PCE or PCC will
not use them during that specific PCEP session.
• The PCC always includes the LSP object in the PCReq message to make sure
that the PCE can correlate the PLSP-ID for this LSP when a subsequent PCRpt
message arrives with the delegation bit set. The PCE will, however, still honor a
PCReq message without the LSP Object.
• PCE path computation will only consider the bandwidth used by LSPs in its
LSP-DB. As a result, there are two situations where PCE path computation will
not accurately take into account the bandwidth used in the network:
- when there are LSPs that are signaled by the routers but are not
synchronized with the PCE. The user can enable the reporting of the LSP
to the PCE LSP database for each LSP.
- when the stateful PCE is peering with a third-party stateless PCC,
implementing only the original RFC 5440. While the PCE will be able to
bring the PCEP session up, the LSP database will not be updated, because
stateless PCC does not support the PCRpt message. Therefore, PCE path
computation will not accurately take into account the bandwidth used by
these LSPs in the network.
• The PCE ignores the R-flag (reoptimize flag) in the PCReq message when
acting in passive stateful mode for an LSP and will always return the newly
computed path, regardless whether it is link-by-link identical or has the same
metric as the current path. The decision whether to initiate the new path in the
network belongs to the PCC.
• The synchronization vector (SVEC) object is not supported on the 7705 SAR
and the NSP. If the PCE receives a PCReq message with the SVEC object, it
will ignore the SVEC object and treat each path computation request in the
PCReq message as independent, regardless of the setting of the P-flag in the
SVEC object common header.
• When an LSP is delegated to the PCE, there may be no prior state in the
NRC-P LSP database for the LSP. This could be due to the PCE not having
received a PCReq message for the same PLSP-ID. In order for the PCE to
become aware of the original constraints of such an LSP, the following additional
procedures are performed. These procedures are proprietary to Nokia.
- The PCC appends a duplicate of each of the LSPA, metric, and bandwidth
objects in the PCRpt message. The only difference between the two objects
of the same type is that the P-flag is set in the common header of the
duplicate object to indicate a mandatory object for processing by the PCE.
Use subject to Terms available at: www.nokia.com
© 2022 Nokia.
PCEP
317
Advertisement
Table of Contents
