Extension for Stateful PCE to allow Optional Processing of PCEP Objects.Huawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comOrangestephane.litkowski@orange.com
Routing
PCE Working Group
This document introduces a mechanism to mark some Path Computation
Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints. describes the Path Computation Element
communication Protocol (PCEP) which enables the communication between
a Path Computation Client (PCC) and a Path Control Element (PCE),
or between two PCEs based on the PCE architecture
. PCEP Extensions
for Stateful PCE Model
describes a set of extensions to PCEP to
enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) tunnels.
describes the setup and teardown of
PCE-initiated LSPs under the active stateful PCE model, without the
need for local configuration on the PCC, thus allowing for a dynamic
network. defined P flag (Processing-Rule) as part of Common Object Header
to allow a PCC to specify
in a PCReq message sent to a PCE whether the object must be taken
into account by the PCE during path computation or is just
optional. The I flag (Ignore) is used by a PCE in a PCRep
message to indicate to a PCC whether or not an optional object was
processed. Stateful PCE
specified that P and I flags of the PCEP
objects defined in is to be set to 0 on
transmission and ignored on receipt since they are
exclusively related to path computation requests. The behavior for P and I flag in
other objects defined in and other extension was not specified.
This document clarifies how the P and I flag could be used in the stateful PCE model to identify
optional objects in the Path Computation State Report (PCRpt), the Path Computation Update Request (PCUpd)
and the LSP Initiate Request (PCInitiate) message.This document updates with respect to usage of P and I flag as well as
handling of unknown objects in stateful PCEP message exchanges.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only when, they appear in all
capitals, as shown here. describes the handling on unknown objects as per the setting of the P flag for the PCReq message.
Further defined the usage of LSP Error Code TLV in PCRpt message in response to failed LSP Update Request
via PCUpd message (for example, due to an unsupported object or a TLV).This document clarifies the procedure for marking some objects as optional to be processed by the PCEP peer in the stateful PCEP messages. Further
this document updates the procedure for handling unknown objects in the stateful PCEP messages based on the P flag.The PCRpt message is used to report the current state of an LSP. As part of the message both the <intended-attribute-list> and <actual-attribute-list> is encoded.
The <intended-attribute-list> could include the METRIC object to indicate a limiting constraint (B flag set) for the Path Delay Variation metric . In some scenarios it would be useful to state that this limiting constraint can be relaxed by the PCE, in case it cannot find a path. Similarly in case of an association groups such as Disjoint Association , the PCE may need to completely relax the
disjointness constraint in order to provide a path to all the LSPs that are part of the association. In these case it would be useful mark the objects as optional and could be ignored by the PCEP peer. Also it would be used for the PCEP speaker to learn if the PCEP peer has relaxed the constraint and ignored the processing of the PCEP object.Thus, this document simply clarifies how the already existing P and I flag in PCEP common object header could be used during stateful PCEP exchanges.A PCEP speaker indicates its ability to support for handling P and I flag during the stateful PCEP message exchanges during the PCEP initialization phase, as follows.
When the PCEP session is created, it sends an Open message with an OPEN object that
contains the STATEFUL-PCE-CAPABILITY TLV, as defined in . A
new flag, the R (RELAX) flag, is introduced to
this TLV to indicate support for relaxing the processing of some objects via the use of P and I flag in PCEP common object header.R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to send and receive PCEP objects with handling of P and I flags in the PCEP common object header. In case the bit is unset, it indicates that the PCEP Speaker would not handle P and I flags in the PCEP common object header.The R flag must be set by both a PCC and a PCE for handling of P and I flag in the PCEP common object header to allow relaxing some constraints by marking objects as optional to process. If the PCEP speaker that did not set R flag but receives PCEP objects with P or I bit set, would behave as per the processing rule in .The P flag in the PCRpt message allows a PCC to specify
to a PCE whether the object must be taken
into account by the PCE (during path computation or re-optimization) or is just
optional. When the P flag is set, the object MUST be taken into
account by the PCE. Conversely, when the P flag is cleared, the
object is optional and the PCE is free to ignore it. The P flag for the
mandatory objects LSP and ERO (intended path) MUST be set in the
PCRpt message. If the mandatory object is
received with the P flag set incorrectly according to the rules
stated above, the receiving peer MUST send a PCErr message with
Error-Type=10 (Reception of an invalid object) and Error-value=1
(reception of an object with P flag not set). By default, the PCC
SHOULD set the P flag, unless a local configuration or local policy
indicates that some constraints (corresponding PCEP objects) can be
marked as optional and could be ignored by the PCE.The P flag in the PCUpd message and the PCInitiate message allows a PCE to specify
to a PCC whether the object must be taken
into account by the PCC (during path setup) or is just
optional. When the P flag is set, the object MUST be taken into
account by the PCC. Conversely, when the P flag is cleared, the
object is optional and the PCC is free to ignore it. The P flag for the
mandatory objects SRP, LSP and ERO (intended path) MUST be set in the
PCUpd message. If the mandatory object is
received with the P flag set incorrectly according to the rules
stated above, the receiving peer MUST send a PCErr message with
Error-Type=10 (Reception of an invalid object) and Error-value=1
(reception of an object with P flag not set). By default, the PCE
SHOULD set the P flag, unless a local configuration or local policy
indicates that some constraints (corresponding PCEP objects) can be
marked as optional and could be ignored by the PCC.The I flag in the PCUpd message allows a PCE to
indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its
update request and set the I flag to indicate that the optional object was
ignored. When the I flag is cleared, the
PCE indicates that the optional object was processed. Note that
for the delegated LSPs, the PCE can update and mark some object as
ignored even when the PCC had set the P flag during delegation.The I flag in the PCRpt message allows a PCC to
indicate to a PCE whether or not an optional object was
processed in response to an LSP Update Request. The PCC MAY include the ignored optional object in its
report and set the I flag to indicate that the optional object was
ignored at PCC. When the I flag is cleared, the
PCC indicates that the optional object was processed.
The I flag has no meaning if the PCRpt message is not in response to a
PCUpd or PCInitiate message.
The I flag has no meaning in the PCinitiate message .This document updates the handling of unknown objects in stateful PCEP messages as per the setting of P flag in the common object header in a similar way as , i.e. if a PCEP speaker does not understand an object with the P flag set or
understands the object but decides to ignore the object, the entire
stateful PCEP message MUST be rejected and the PCE MUST send a PCErr message
with Error-Type="Unknown Object" or "Not supported Object" . In case the P flag is not set, the PCEP speaker is free to ignore the object and continue with the message processing as defined. defined LSP Error Code TLV to be carried in PCRpt message in the LSP object
to convey error information. This document does not change that impact that procedure. This documents clarifies how the already existing P and I flag in PCEP common object header could be used during stateful PCEP exchanges. It updates the
unknown object error handling in stateful PCEP message exchange. These changes on its own do not add any new security concerns. The security considerations identified in , , and . As stated in , PCEP implementations SHOULD support the
TCP-AO and not use TCP MD5 because of TCP MD5's known
vulnerabilities and weakness. PCEP also support Transport Layer Security (TLS)
as per the recommendations and best current practices
in . defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA
created a registry to manage the value of the STATEFUL-PCE-CAPABILITY
TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE-
CAPABILITY TLV Flag Field registry, as follows:
An operator MUST be allowed to configure the capability to support relaxation of constraints in the stateful PCEP message exchange. They SHOULD also allow configuration of related LSP constraints (or parameters) that are optional to process. An implementation SHOULD allow the operator to view the capability defined in this document. To serve this purpose, the PCEP YANG module could be extended. Mechanisms defined in this document do not imply any new liveness detection
and monitoring requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
.Mechanisms defined in this document do not imply any new requirements
on other protocols.Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in
.