PCEP Procedures and Protocol Extensions for
Using PCE as a Central Controller (PCECC) for SRv6Huawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing 100095Chinalizhenbin@huawei.comHuawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinapengshuping@huawei.comHuawei TechnologiesChinagengxuesong@huawei.comRtBrick IncN-17L, 18th Cross Rd, HSR LayoutBangaloreKarnataka560102Indiamahend.ietf@gmail.com
Routing
PCE Working GroupThe Path Computation Element (PCE) is a core component of Software-
Defined Networking (SDN) systems. It can compute optimal paths for
traffic across a network and can also update the paths to reflect
changes in the network or traffic demands.PCE was developed to derive paths for MPLS Label Switched Paths
(LSPs), which are supplied to the head end of the LSP using the Path
Computation Element Communication Protocol (PCEP). But SDN has a
broader applicability than signaled (G)MPLS traffic-engineered (TE)
networks, and the PCE may be used to determine paths in a range of
use cases. PCEP has been proposed as a control protocol for use in
these environments to allow the PCE to be fully enabled as a central
controller.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. This document specifies the procedures and PCEP protocol extensions
when a PCE-based controller is also responsible for configuring the
forwarding actions on the routers for Segment Routing (SR) in IPv6 (SRv6), in addition to computing the SRv6 paths
for packet flows and telling the edge
routers what instructions to attach to packets as they enter the
network. The Path Computation Element (PCE) was developed to offload
the path computation function from routers in an MPLS traffic-engineered
network. Since then, the role and function of the PCE has grown to
cover a number of other uses (such as GMPLS ) and to allow
delegated control and PCE-initiated use of network
resources .According to , Software-Defined Networking (SDN) refers to a
separation between the control elements and the forwarding components
so that software running in a centralized system, called a
controller, can act to program the devices in the network to behave
in specific ways. A required element in an SDN architecture is a
component that plans how the network resources will be used and how
the devices will be programmed. It is possible to view this
component as performing specific computations to place traffic flows
within the network given knowledge of the availability of network
resources, how other forwarding devices are programmed, and the way
that other flows are routed. This is the function and purpose of a
PCE, and the way that a PCE integrates into a wider network control
system (including an SDN system) is presented in .In early PCE implementations, where the PCE was used to derive paths
for MPLS Label Switched Paths (LSPs), paths were requested by network
elements (known as Path Computation Clients (PCCs)), and the results
of the path computations were supplied to network elements using the
Path Computation Element Communication Protocol (PCEP) .
This protocol was later extended to allow a PCE to send unsolicited
requests to the network for LSP establishment . introduces the architecture for PCE as a central
controller as an extension of the architecture described in
and assumes the continued use of PCEP as the protocol used between
PCE and PCC. further examines the motivations and applicability
for PCEP as a Southbound Interface (SBI), and introduces the implications for the
protocol. describes the use cases for
the PCE-based Central Controller (PCECC) architecture. specify the procedures and PCEP extensions for
using the PCE as the central controller for static LSPs, where
LSPs can be provisioned as explicit label instructions at each
hop on the end-to-end path.Segment Routing (SR) technology leverages the source routing and tunneling paradigms.
A source node can choose a path without relying on hop-by-hop
signaling protocols such as LDP or RSVP-TE. Each path is specified
as a set of "segments" advertised by link-state routing protocols
(IS-IS or OSPF). provides an
introduction to SR architecture. The corresponding IS-IS and OSPF extensions are
specified in and
, respectively.
It relies on a series of
forwarding instructions being placed in the header of a packet.
The list of segments forming the path is called the
Segment List and is encoded in the packet header. Segment Routing
can be applied to the IPv6 architecture with the Segment Routing
Header (SRH) . A segment is
encoded as an IPv6 address. An ordered list of segments is encoded
as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address of the packet.
Upon completion of a segment, a pointer in the new routing header is
incremented and indicates the next segment.
The segment routing architecture supports operations that can be used
to steer packet flows in a network, thus providing a form of traffic
engineering. and specify the SR specific PCEP
extensions.
PCECC may further use PCEP for SR SID (Segment Identifier) distribution on the SR nodes
with some benefits. The SR
nodes continue to rely on IGP for distributed computation (nexthop
selection, protection etc) where PCE (and PCEP) does only the
allocation and distribution of SRv6 SIDs in the network. Note that the
topology at PCE is still learned via existing mechanisms. specifies the procedures and PCEP extensions when
a PCE-based controller is also responsible for configuring
the forwarding actions on the routers (SR-MPLS SID distribution), 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. This document extends this to include SRv6 SID distribution as well.
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.Terminologies used in this document is the same as described in the draft
and . specifies extensions to
PCEP that allow a stateful PCE to
compute, update, or initiate SR-TE paths for MPLS dataplane. An ingress node of an SR-TE path appends
all outgoing packets with a list of MPLS labels (SIDs). This is encoded in
SR-ERO subobject, capable of carrying a label (SID) as well as the identity of the
node/adjacency label (SID). extends the procedure
to include support for SRv6 paths.As per , an SRv6 Segment is a
128-bit value. "SRv6 SID" or simply "SID" are often used as a
shorter reference for "SRv6 Segment". Further details are in an
illustration provided in
.
The SR is applied to IPV6 data
plane using SRH. An SR path can be derived from an IGP Shortest Path
Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may
be chosen by a suitable network planning tool, or a PCE and
provisioned on the ingress node. specify
the SRv6-ERO subobject capable of carrying an SRv6 SID as well as the identity
of the node/adjacency represented by the SID. examines the motivations and applicability for
PCECC and use of PCEP as an SBI. Section 3.1.5. of
highlights the use of PCECC for configuring the forwarding actions on the routers and
assume responsibility for managing the identifier space. It simplifies the processing of a distributed
control plane by blending it with elements of SDN and without
necessarily completely replacing it. This allows the operator to introduce
the advantages of SDN (such as programmability) into the network. Further Section 3.3. of describes some of the scenarios where the PCECC technique could be useful. Section 4 of
also describe the implications on the protocol when used as an SDN SBI. The operator needs to evaluate the advantages offered by PCECC against the operational and scalability needs of the PCECC. As per ,
PCECC can allocate and provision the node/prefix/adjacency label (SID) via PCEP.
As per this is also applicable to SRv6 SIDs. The rest of the
processing is similar to existing stateful PCE for SRv6 .Following key requirements for PCECC-SRv6 should be considered when
designing the PCECC-based solution:A PCEP speaker supporting this draft needs to have the capability to
advertise its PCECC-SRv6 capability to its peers.PCEP procedures need to allow for PCC-based SRv6 SID allocations.PCEP procedures need means to update (or clean up) the SRv6 SID to the PCC.PCEP procedures need to provide a mean to synchronize the SRv6 SID allocations between
the PCE to the PCC in the PCEP messages.Active stateful PCE is described in . PCE
as a Central Controller (PCECC) reuses the existing active stateful PCE
mechanism as much as possible to control the LSPs.This document uses the same PCEP messages and its extensions which
are described in and for
PCECC-SRv6 as well.The PCEP messages PCRpt, PCInitiate, PCUpd are used to send
LSP Reports, LSP setup, and LSP update respectively. The extended PCInitiate message described in
is used to download
or clean up central controller's instructions (CCIs) (a new CCI Object-Type=TBD3 for SRv6 SID). The extended PCRpt message described in
is also used to report
the CCIs (SRv6 SIDs) from PCC to PCE. specify an object called CCI for the encoding of the central controller's instructions. defined a CCI object-type for SR-MPLS. This document further defines a new CCI object-type=TBD3 for SRv6.
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of PCECC extensions. A PCEP Speaker includes
the "PCECC Capability" sub-TLV, described in
.A new S-bit is added in the PCECC-CAPABILITY sub-TLV to indicate support for
PCECC-SR-MPLS in . This document adds another I-bit to indicate support for SR in IPv6. A PCC MUST set the I-bit in the PCECC-CAPABILITY sub-TLV and include
the SRv6-PCE-CAPABILITY sub-TLV () in the OPEN Object
(inside the PATH-SETUP-TYPE-CAPABILITY TLV)
to support the PCECC SRv6 extensions defined in this document. If
I-bit is set in PCECC-CAPABILITY sub-TLV and the SRv6-PCE-CAPABILITY sub-TLV is not
advertised in the OPEN Object, PCE SHOULD send a PCErr message with
Error-Type=19 (Invalid Operation) and Error-value=TBD4 (SRv6 capability
was not advertised) and terminate the session.The rest of the processing is as per
and .As described in , it is important to link the session IP address with the
Router ID in TED for successful PCECC-SRv6 operations. specify the PCEP extension to allow a stateful PCE
to compute and initiate SR-TE paths, as well as a PCC to request a
path subject to certain constraint(s) and optimization criteria in SR
networks. extends it to support SRv6.The Path Setup Type for SRv6 (PST=TBD) is used on the PCEP session with the Ingress as per
.Segment Routing (SR) as described in
depends on "segments" that are
advertised by Interior Gateway Protocols (IGPs). The SR-node
allocates and advertises the SID (node, adj, etc) and floods them via the
IGP. This document proposes a new mechanism where PCE allocates the
SRv6 SID centrally and uses PCEP to distribute them to all nodes. In some
deployments, PCE (and PCEP) are better suited than IGP because of
the centralized nature of PCE and direct TCP based PCEP sessions to the
node. Note that only
the SRv6 SID allocation and distribution is done by the PCEP, all other SRv6
operations (nexthop selection, protection, etc) are still done by the
node (and the IGPs).Each node (PCC) is allocated a node SRv6 SID by the PCECC. The
PCECC sends the PCInitiate message to update the SRv6 SID table of each node.
The TE router ID is determined from the
TED or from "IPv4/IPv6 Router-ID" Sub-TLV
, in the OPEN Object.On receiving the SRv6 node SID allocation, each node (PCC) uses the local
routing information to determine the next-hop and download the
forwarding instructions accordingly. The PCInitiate message uses the FEC object .On receiving the SRv6 node SID allocation:For the local SID, the node (PCC) needs to update SID with associated
function (END function in this case) in "My Local SID Table" ().For the non-local SID, the node (PCC) uses the local routing information
to determine the next-hop and download the forwarding instructions accordingly. The forwarding behavior and the end result is similar to IGP based
"Node-SID" in SRv6. Thus, from anywhere in the domain, it enforces the
ECMP-aware shortest-path forwarding of the packet towards the related
node as per .PCE relies on the Node/Prefix SRv6 SID clean up using the same PCInitiate
message as per .For PCECC-SRv6, apart from node-SID, Adj-SID is used where each adjacency
is allocated an Adj-SID by the PCECC. The PCECC sends
PCInitiate message to update the SRv6 SID entry for each adjacency to all
nodes in the domain. Each node (PCC) download the SRv6 SID
instructions accordingly. Similar to SRv6 Node/Prefix Label allocation, the
PCInitiate message in this case uses
the FEC object. The forwarding behavior and the end result is similar to IGP based
"Adj-SID" in SRv6 as per .The handling of adjacencies on the LAN subnetworks is specified in . PCECC MUST assign Adj-SID for every pair of routers in the LAN. The rest of the protocol mechanism remains the same.PCE relies on the Adj label clean up using the same PCInitiate
message as per . describes the synchronization
mechanism between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST also be
synchronized among PCEs for PCECC-SRv6 state synchronization. Note that the SRv6 SIDs
are independent of the SRv6 paths, and remains intact till any topology
change. The redundant PCEs MUST have a common view of all SRv6 SIDs allocated in the
domain.
describes the action
needed for CCIs for the static LSPs on a terminated
session. Same holds true for the CCI for SRv6 SID as well. describes the synchronization of Central Controller's Instructions (CCI) via the LSP state synchronization
as described in and
.
Same procedures are applied for the CCI for the SRv6 SIDs as well.The PCEP messages are as per . defined
the PCECC-CAPABILITY sub-TLV.A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6:[Editor's Note - The above figure is included for ease of the reader but should be removed before publication.]I (PCECC-SRv6-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP speaker, it
indicates that the PCEP speaker is capable of PCECC-SRv6 capability
and the PCE allocates the Node and Adj SRv6 SID on this session.The PATH-SETUP-TYPE TLV is defined in . A PST value of TBD is used
when Path is setup via SRv6 mode as per . The procedure for SRv6 path setup as specified in remains unchanged.The Central Control Instructions (CCI) Object is used by the PCE to specify the controller instructions is defined in .
This document defines another object-type for SRv6 purpose. CCI Object-Type is TBD3 for SRv6 as below -
The field CC-ID is as described in . The field MT-ID, Algorithm, Flags are defined in
.Reserved: MUST be set to 0 while sending and ignored on receipt.SRv6 Endpoint Function: 16-bit field representing supported
functions associated with SRv6 SIDs.SRv6 Identifier: 128-bit IPv6 addresses representing SRv6
segment.SID Structure: 64-bit field formatted as per "SID Structure" in .The FEC Object is used to specify the FEC information and MAY be
carried within PCInitiate or PCRpt message.FEC Object (and various Object-Types) are described in . SRv6 Node SID MUST includes the FEC Object-Type 2 for IPv6 Node.
SRv6 Adjacency SID MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC object types could be added in future extensions.As per , the security considerations for a PCE-based controller is a little
different from those for any other PCE system. That is, the
operation relies heavily on the use and security of PCEP, so
consideration should be given to the security features discussed in
and the additional mechanisms described in . It further lists the vulnerability of a central controller architecture, such as a central
point of failure, denial-of-service, and a focus for
interception and modification of messages sent to individual NEs.The PCECC extension builds on the existing PCEP messages and thus the security considerations described in , ,
, , and continue to apply.As per , it is RECOMMENDED that these PCEP extensions only be activated on mutually-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 ). A PCE or PCC implementation SHOULD allow to configure to
enable/disable PCECC SRv6 capability as a global configuration. describes the PCEP MIB, this MIB can be extended to get the
PCECC SRv6 capability status.The PCEP YANG module could be extended
to enable/disable PCECC SRv6 capability.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
and .PCEP extensions defined in this document do not put new requirements
on other protocols.PCEP implementation SHOULD allow a limit to be placed on the rate
of PCInitiate/PCUpd messages (as per ) sent by PCE and processed by PCC.
It SHOULD also allow sending a notification when a rate threshold is
reached. defines the
PCECC-CAPABILITY sub-TLV and requests that IANA creates a registry to
manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. IANA
is requested to allocate a new bit in the PCECC-CAPABILITY sub-TLV Flag
Field registry, as follows:BitDescriptionReferenceTBD1SRv6This documentIANA is requested to allocate a new code-point for the new CCI object-type in "PCEP Objects" sub-registry as follows:Object-Class ValueNameObject-TypeReferenceTBDCCITBD3: SRv6This documentIANA is requested to allocate new error types and error values within
the "PCEP-ERROR Object Error Types and Values" sub-registry of the
PCEP Numbers registry for the following errors:
MeaningInvalid operation.
SRv6 capability was not advertisedThe Reference is marked as "This document".