PCE Controlled ID SpaceHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095ChinaMach.chen@huawei.comChina TelecomBeiqijia Town,BeijingChangping District102209Chinawangaj3@chinatelecom.cnChina Mobilechengweiqiang@chinamobile.comHPEchaozhou_us@yahoo.comThe Path Computation Element Communication Protocol (PCEP) provides a
mechanisms for the 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, PCE can be used for computing paths in
the 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
remove PCE-initiated LSPs by itself. A PCE-based Central Controller
(PCECC) simplify the processing of a distributed control plane by
integrating with elements of Software-Defined Networking (SDN).In some use cases, such as PCECC or Binding Segment Identifier (SID)
for Segment Routing (SR), there are requirements for a stateful PCE to
make allocation of labels, SIDs, etc. These use cases require PCE aware
of various identifier spaces from where to make allocations on behalf of
a PCC. This document describes a mechanism for a PCC to inform the PCE
of the identifier space set aside for the PCE control via PCEP. The
identifier could be an MPLS label, a SID or any other to-be-defined
identifier that can be allocated by a PCE. defines the stateless Path Computation
Element Communication Protocol (PCEP) for the Path Computation Elements
(PCEs) to perform path computation 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 extensions for using the PCE as a Central
Controller (PCECC), where LSPs are calculated/set up/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
label range via a PCEP extension.Similarly, specifies the procedures and PCEP
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.In addition, specifies
the procedures and PCEP extensions of PCECC for SRv6. An SRv6 SID is
represented as LOC:FUNCT () where LOC is the L
most significant bits and FUNCT is the 128-L least significant bits. The
FUNCT part of the SID is an opaque identification of a local function
bound to the SID. This extension adds the capability to advertise the
range of Function ID (FUNCT part) via a PCEP extension.Once the PCC/node has given control over an ID space (for example
labels), the PCC/node MUST NOT allocate the ID from this ID space. For
example, a PCC/node MUST NOT use this labels from the PCE controlled
label space to make allocation for VPN Prefix distributed via BGP or
labels used for LDP/RSVP-TE signalling. This is done to make sure that
the PCE control over ID space does not conflict with the existing node
allocation.The use case are described in . The ID space
range information can be advertised via the TLVs in the Open message.
The detailed procedures are described in , and the
TLV format is specified in .This memo makes use of the terms defined in ,
, and .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.A PCE-based Central Controller (PCECC) can simplify the processing
of a distributed control plane by integrating with elements of SDN.
Thus, the LSP/SR path can be calculated/set up/initiated and the
label/SID 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. describes 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 router 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
distribute 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 can control. A
mechanism for a PCC to inform the PCE of such 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.
describes the mechanism for PCECC to allocate and provision the SRv6
SID via PCEP. An SRv6 SID is represented as LOC:FUNCT () where LOC is the L most significant bits and
FUNCT is the 128-L least significant bits. The FUNCT part of the SID
is an opaque identification of a local function bound to the SID. To
make such allocation, PCE needs to be aware of the Function ID space
(FUNCT part) of the node that it controls. A mechanism for a PCC to
inform the PCE of such a Function ID space to control is needed
within PCEP.The headend of an SR Policy binds a Binding SID (BSID) to its policy . The instantiation
of which may involve a list of SIDs. The Binding SID can be allocated
by the node as described in , 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. This is described in .
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.This is applicable for both SR-MPLS and SRv6 BSID.During PCEP Initialization Phase, Open messages are exchanged between
the PCCs and the PCEs. The OPEN object may also contain a set of TLVs
used to convey the capabilities in the Open message. The term 'ID' in
this document, could be a MPLS label, SRv6 Function ID or any other
future ID space for PCE to control and allocate from. 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 an Open message. The
ID type can be MPLS label or other type of ID. The following
ID-CONTROL-SPACE TLV is defined in this document - LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for
SR-MPLS)FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function 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 controlled-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 the PCE controlled portion of the SRGB/SRLB for PCECC-SR . The full SRGB/SRLB of a node could be learned via
existing IGP or BGP-LS mechanism.The procedure for handling the FUNCTION-ID-CONTROL-SPACE TLV is same
as above.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 in the OPEN
object, and its format is shown in the following figure:The type (16 bits) of the TLV is TBD1. The length field (16 bits)
and has a variable value.Block(8 bits): the number of ID blocks. The range of a block is
described by a start field and a range field.Flags (24 bits): No flag is currently defined. 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: MUST be set to 0 on transmission and MUST be ignored on
reception.LABEL-CONTROL-SPACE TLV SHOULD be included only once in a Open
Message. On receipt, only the first instance is processed and others
MUST be ignored.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 . The
Binding Segments can also be selected for the PCE controlled space
.For a PCC to inform the SRv6 SID Function ID space under the PCE
control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV.The FUNCT-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 TBD2. The length field
(16 bits) and has a variable value.Block(8 bits): the number of ID blocks. The range of a block is
described by a start field and a range field.Flags (24 bits): Following flags are currently definedL-flag: Locator flag, set when the locator information is
included in this TLV. If L-flag is unset, Loc Size and variable
Locator field MUST NOT be included in this TLV, and the ID
spaces are applicable to all Locators.The unassigned bits of Flags field MUST be set to 0 on
transmission and MUST be ignored on receipt.SID Structure: 64-bit field formatted as per "SID Structure" in
.Start(i) (128 bits): indicates the beginning of the Function ID
block i.Range(i) (128 bits): indicates the range of the Function ID block
i.Loc size(8 bits): indicates the bit length of a Locator. Appears
only when the L-flag is set.Locator (variable length): the value of a Locator. The Function
ID spaces specified in this TLV are associated with this
locator.As per , the value portion of the PCEP
TLV needs to be 4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is
padded with trailing zeros to a 4-byte boundary.Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in a OPEN
object to specify Function ID space specefic to each locator.A stateful PCE can actively allocate SRv6 SID and download SIDs
for the PCECC-SRv6 as described in .Note that SRv6 SID allocation involves LOC:FUNCT; the LOC is
assumed to be known at PCE and FUNCT is allocated from the PCE
controlled Function ID block.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 MUST use synchronization
mechanism (such as ) to avoid
allocating the same ID.The PCE would allocate ID from the PCE controlled ID space. The PCC
would not allocate ID by itself from this space as long as it has an
active PCEP session to a PCE to which it has given control over the ID
space.Note that if there is any change in the ID space, the PCC MUST bring
the session down and re-establish the session with new TLVs. During
state synchronization the PCE would need to consider the new ID space
into consideration and SHOULD re-establish the LSP/SR-paths if
needed.The PCC can regain control of the ID space by closing the PCEP
session and require new session without ID space TLVs specified in this
document.IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry. This document requests IANA actions to allocate code points
for the protocol elements defined in this document.IANA maintains a subregistry called "PCEP TLV Type Indicators".
IANA is requested to make an assignment from this subregistry as
follows:This document defines the LABEL-CONTROL-SPACE TLV and requests that
IANA to create a new sub-registry to manage the value of the
LABEL-CONTROL-SPACE TLV's 24-bits Flag field. New values are to be
assigned by Standards Action . Each bit should
be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCCurrently, there is no allocation in this registry.This document defines the FUNCT-ID-CONTROL-SPACE TLV and requests
that IANA to create a new sub-registry to manage the value of the
FUNCT-ID-CONTROL-SPACE TLV's 24-bits Flag field. New values are to be
assigned by Standards Action . Each bit should
be tracked with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCCurrently, there is no allocation in this registry.The security considerations described in ,
, and
and
apply to the extensions described in this document.As per , it is RECOMMENDED that these PCEP
extensions only be activated on authenticated and encrypted sessions
across PCEs and PCCs belonging to the same administrative authority,
using Transport Layer Security (TLS) as per the
recommendations and best current practices in
(unless explicitly set aside in ).TBD.