PCE Controlled ID SpaceHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinachengli13@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095ChinaMach.chen@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comThe 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.
The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. Furthermore, PCEP can be used for computing paths in
SR networks.Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a
model where the PCC delegates control over one or more locally
configured LSPs to the PCE. Further, stateful PCE could also create and
delete PCE-initiated LSPs itself. A PCE-based central controller (PCECC)
simplify the processing of a distributed control plane by blending it
with elements of Software-Defined Networking (SDN) and without
necessarily completely replacing it.In some use cases, such as PCECC, Binding Segment Identifier (SID),
SR Path Identification, there is a requirement for a stateful PCE to
make allocation of labels, SID, Path-ID respectively. These use cases
require for the PCE to be aware of the various identifier space from
which to make allocations on behalf of PCC. This documents specify a
mechanism for a PCC to inform the PCE of the identifier space under its
control via PCEP. The identifier could be MPLS label, SID, Path ID or
another future identifier to be allocated by a PCE.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. defines the stateless Path Computation
Element communication Protocol (PCEP) for Path Computation Elements
(PCEs) to perform path computations in response to Path Computation
Clients (PCCs) requests. For supporting stateful operations, specifies a set of extensions to PCEP to enable
stateful control of LSPs within and across PCEP sessions in compliance
with . Furthermore,
describes the setup, maintenance, and teardown of PCE-initiated LSPs
under the stateful PCE model, without the need for local configuration
on the PCC, thus allowing for a dynamic network that is centrally
controlled and deployed. introduces the architecture for PCE as a
central controller, it examines the motivations and applicability for
PCEP as a control protocol in this environment, and introduces the
implications for the protocol. Also, specifies the
procedures and PCEP protocol extensions for using the PCE as the central
controller, where LSPs are calculated/setup/initiated and label
forwarding entries are downloaded through extending PCEP. However, the
document assumes that label range to be used by a PCE is known and set
on both PCEP peers. This extension adds the capability to advertise the
range via a PCEP extension.Similarly, specifies the
procedures and PCEP protocol extensions when a PCE-based controller is
also responsible for configuring the forwarding actions on the routers
(SR SID distribution in this case), in addition to computing the paths
for packet flows in a segment routing network and telling the edge
routers what instructions to attach to packets as they enter the
network. However, the document assumes that label range to be used by a
PCE is known and set on both PCEP peers. This extension adds the
capability to advertise the range (from SRGB or SRLB of the node) via a
PCEP extension.[I-D.li-pce-sr-path-segment] defines a procedure for path ID in PCEP
for SR by defining the PATH-ID TLV. The path ID can be a path segment in
SR-MPLS , or a path
ID in SRv6 , or
other IDs that can identify an SR path. This document specify the
extension to support advertisement of the various ID space to the PCE to
control.The usecase are described in . The ID space range
information can be advertised via the TLVs in the Open message. The
detailed procedures will be described in , and the
objects' format will be introduced in .This memo makes use of the terms defined in ,
, and .A PCE-based central controller (PCECC) can simplify the processing
of a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the LSP can be
calculated/setup/initiated and the label forwarding entries can also
be downloaded through a centralized PCE server to each network devices
along the path while leveraging the existing PCE technologies as much
as possible.
describe a mode where LSPs are provisioned as explicit label
instructions at each hop on the end-to-end path. Each router along the
path must be told what label forwarding instructions to program and
what resources to reserve. The controller uses PCEP to communicate
with each router along the path of the end-to-end LSP. For this to
work, the PCE-based controller will take responsibility for managing
some part of the MPLS label space for each of the routers that it
controls as described in section 3.1.2. of . A
mechanism for a PCC to inform the PCE of such a label space to control
is needed within PCEP. specifies extensions
to PCEP that allow a stateful PCE to compute, update or initiate SR-TE
paths.
describes the mechanism for PCECC to allocate and provision the
node/prefix/adjacency label (SID) via PCEP. To make such allocation
PCE needs to be aware of the label space from Segment Routing Global
Block (SRGB) or Segment Routing Local Block (SRLB) of the node that it
controls. A mechanism for a PCC to inform the PCE of such a label
space to control is needed within PCEP. The full SRGB/SRLB of a node
could be learned via existing IGP or BGP-LS mechanism.The headend of an SR Policy binds a binding SID to its policy . The instantiation of which
may involve a list of SIDs. Currently binding SID are allocated by the
node, but there is an inherent advantage in the binding SID to be
allocated by a PCE to allow SR policies to be dynamically created,
updated according to the network status and operations. Therefore, a
PCE needs to obtain the authority and control to allocate binding SID
actively from the PCC's label space as described in above use
case.Path identification is needed for several use cases such as
performance measurement in Segment Routing (SR) network. For
identifying an SR path, introduces a new segment
that is referred to as Path Segment, and introduces the path ID
in SRv6.[I-D.li-pce-sr-path-segment] defines a procedure for path ID in
PCEP for SR. It describes a mode in which PCE could allocate path ID
and inform the ingress and egress PCC. To make such an allocation a
PCE needs to be aware of the path ID space under its control. A
mechanism for a PCC to inform the PCE of such a path ID space is
needed within PCEP.During PCEP Initialization Phase, Open messages are exchanged between
PCCs and PCEs. The OPEN object may also contain a set of TLVs used to
convey capabilities in the Open message. The ID could be a MPLS label,
SRv6 path ID or any other future ID space for PCE to allocate. A PCC can
include a corresponding ID-CONTROL-SPACE TLVs, in the OPEN Object to
inform the corresponding ID space information that it wants the PCE to
control. This TLV MUST NOT be included by the PCE and MUST be ignored on
receipt by a PCC. This is an optional TLV, the PCE could be aware of the
ID space from some other means outside of PCEP.For delegating multiple types of ID space, multiple TLVs
corresponding to each ID type MUST be included in a Open message. Each
TLV (corresponding to each ID type) SHOULD be included only once in a
Open Message. On receipt, only the first instance is processed and
others MUST be ignored. The ID type can be MPLS label, SRv6 path ID
or other ID. The
following ID-CONTROL-SPACE TLVs are defined in this document - LABEL-CONTROL-SPACE - for MPLS Labels (including for SR-MPLS)SRv6-PATH-ID-CONTROL-SPACE - for SRv6 Path IDThe procedure of ID space control to PCE is shown below:If the ID space control procedure is successful, the PCE will return
a KeepAlive message to the PCC. If there is any error in processing the
corresponding TLV, an Error (PCErr) message will be sent to the PCC with
Error-Type=1 (PCEP session establishment failure) and Error-value=TBD
(ID space control failure).After this process, a stateful PCE can learn the PCE controlled ID
spaces of a node (PCC) under its control. A PCE can then allocate IDs
within the control ID space. For example, a PCE can actively allocate
labels and download forwarding instructions for the PCECC LSP as
described in . A PCE can
also allocate labels from SRGB/SRLB for PCECC-SR , binding
segments, and path segments . The full SRGB/SRLB of a
node could be learned via existing IGP or BGP-LS mechanism. Similarly a
PCE can allocate SRv6 Path ID according to the SRv6
Path ID space under its control.For advertising the PCE controlled ID space to a PCE, this document
defines several TLVs within the Open object.For a PCC to inform the label space under the PCE control, this
document defines a new LABEL-CONTROL-SPACE TLV.The LABEL-CONTROL-SPACE TLV is an optional TLV for use in the
OPEN object, and its format is shown in the following figure:The type (16 bits) of the TLV is TBA. The length field (16 bits)
and has a variable value.Flags (32 bits): Following flags are currently definedA-flag: All space flag, set when all the label space is
delegated to a PCE. When A-flag is set, the pair of Start and
End SHOULD NOT appear unless the PCC needs to notify the entire
ID space to a PCE.The unassigned bits of Flags field MUST be set to 0 on
transmission and MUST be ignored on receipt.Start(i) (24 bits): indicates the beginning of the label block
i.Range(i) (24 bits): indicates the range of the label block i.Reserved: SHOULD be set to 0 on transmission and MUST be ignored
on reception.The number of label blocks can be calculated according to value
of the length field in the TLV.A stateful PCE can actively allocate labels and download
forwarding instructions for the PCECC LSP as described in . A PCE can
also allocate labels from SRGB/SRLB for PCECC-SR and binding
segments can be selected for the PCE controlled space. Also, Path
segment can be
allocated by a stateful PCE in a similar same way as described in
[I-D.li-pce-sr-path-segment].For a PCC to inform the SRv6 path ID space under the PCE control,
this document defines a new SRv6-PATH-ID-CONTROL-SPACE TLV.The SRv6-PATH-ID-CONTROL-SPACE TLV is an optional TLV for use in
the OPEN object, and its format is shown in the following
figure:The type (16 bits) of the TLV is TBA. The length field (16 bits)
and has a variable value.Flags (32 bits): is of same format as LABEL-CONTROL-SPACE TLV.
Any bits assigned in the LABEL-CONTROL-SPACE TLV are also applicable
for this.Start(i) (32 bits): indicates the beginning of the SRv6 Path ID
block i.Range(i) (32 bits): indicates the range of the SRv6 Path ID block
i.The number of Path ID blocks can be calculated according to the
length field in the TLV. Given the controlled ID spaces, a stateful
PCE can actively allocate path IDs to SRv6 paths from the controlled
ID spaces as described in [I-D.li-pce-sr-path-segment].In case of multiple PCEs, a PCC MAY decide to give control over
different ID space to each instance of the PCE. In case a PCC includes
the same ID space to multiple PCEs, the PCE SHOULD use synchronization
mechanism (such as ) to
avoid allocating the same ID.TBA.TBA.TBA.