| PCE Working Group | M. Negi |
| Internet-Draft | Z. Li |
| Intended status: Standards Track | X. Geng |
| Expires: February 23, 2020 | Huawei Technologies |
| August 22, 2019 |
PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs
draft-dhody-pce-pcep-extension-pce-controller-p2mp-02
The 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.
The PCE has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs).
PCE was developed to derive paths for MPLS P2MP LSPs, which are supplied to the head end (root) of the LSP using PCEP. PCEP has been proposed as a control protocol 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. Thus, the P2MP 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 P2MP path while leveraging the existing PCE technologies as much as possible.
This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for P2MP TE LSP.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 23, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Path Computation Element (PCE) [RFC4655] was developed to offload 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 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated use of network resources [RFC8281].
According to [RFC7399], 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 [RFC7491].
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) [RFC5440]. This protocol was later extended to allow a PCE to send unsolicited requests to the network for LSP establishment [RFC8281].
[RFC8283] introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. [RFC8283] further examines the motivations and applicability for PCEP as a Southbound Interface (SBI), and introduces the implications for the protocol.
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.
[I-D.ietf-pce-pcep-extension-for-pce-controller] specify the procedures and PCEP protocol extensions for using the PCE as the central controller for static P2P LSPs, where LSPs can be 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 PCE-based controller keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP.
[RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC8306]. Further [RFC8623] specify the extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs as well as the setup, maintenance and teardown of PCE-initiated P2MP LSPs under the stateful PCE model.
This document extends [I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the procedures and PCEP protocol extensions for using the PCE as the central controller for static P2MP LSPs, where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path with an added functionality of a P2MP branch node. As per [RFC4875], a branch node is an LSR that replicates the incoming data on to one or more outgoing interfaces. [I-D.ietf-teas-pcecc-use-cases] describes the use cases for P2MP in PCECC architecture.
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terminologies used in this document is same as described in the draft [RFC8283] and [I-D.ietf-teas-pcecc-use-cases].
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in this mode 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. Note that the PCE-based controller will take responsibility for managing some part of the MPLS label space for each of the routers that it controls, and may taker wider responsibility for partitioning the label space for each router and allocating different parts for different uses. This is also described in section 3.1.2. of [RFC8283]. For the purpose of this document, it is assumed that label range to be used by a PCE is known and set on both PCEP peers. A future extension could add this capability to advertise the range via possible PCEP extensions as well.
This document extends the functionality to include support for central control instruction for replication at the branch nodes.
The rest of processing is similar to the existing stateful PCE mechanism for P2MP.
Active stateful PCE is described in [RFC8231] and extended for P2MP [RFC8623]. PCE as a central controller (PCECC) reuses existing Active stateful PCE mechanism as much as possible to control the LSP.
[I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP messages - PCRpt, PCInitiate, PCUpd message for the Central Controller's Instructions (CCI) (label forwarding instructions in the context of this document). This documents specify the procedure for additional instruction for branch node needed for P2MP.
As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of PCECC extensions by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this PST=PCECC included in the PST list.
[I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the PCECC Capability sub-TLV. A new M-bit is added in PCECC-CAPABILITY TLV to indicate support for PCECC-P2MP. A PCC MUST set M-bit in PCECC-CAPABILITY TLV and include STATEFUL-PCE-CAPABILITY TLV with P2MP bits set ([RFC8623]) in OPEN Object to support the PCECC P2MP extensions defined in this document. If M-bit is set in PCECC-CAPABILITY TLV and N-bit in STATEFUL-PCE-CAPABILITY TLV is not set in OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=TBD (P2MP capability was not advertised) and terminate the session.
The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE TLV [RFC8408] with PST=PCECC [I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to clearly identify the PCECC LSP is intended.
In order to setup a P2MP LSP based on PCECC mechanism, a PCC MUST delegate the P2MP LSP by sending a PCRpt message with PST set for PCECC and D (Delegate) flag (see [RFC8623]) set in the LSP object.
P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for PCECC LSP, the tuple uniquely identifies the P2MP LSP in the network. As per [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object is included in central controller's instructions (label download) to identify the PCECC LSP for this instruction.
When a PCE receives PCRpt message with D flags and PST Type set, it calculates the P2MP tree and assigns labels along the path; and set up the path by sending PCInitiate message to each node along the path of the LSP, similar to [I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension required is the instructions on the branch nodes for replications to more than one outgoing interfaces with respective labels. The rest of the operations remains same as [I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623].
The new central controller's instructions (CCI) for the label operations in PCEP is done via the PCInitiate message, by defining a new PCEP Objects for CCI operations. Local label range of each PCC is assumed to be known at both the PCC and the PCE.
In order to setup an LSP based on PCECC, the PCE sends a PCInitiate message to each node along the path to download the Label instruction as described in Section 4.3.1.
The CCI object MUST be included, along with the LSP object in the PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object.
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if a node (PCC) receives a PCInitiate message which includes a Label to download as part of CCI, that is out of the range set aside for the PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and Error-value=TBD (Label out of range). If a PCC receives a PCInitiate message but failed to download the Label entry, it sends a PCErr message with Error-type=TBD (PCECC failure) and Error-value=TBD (instruction failed).
Consider the example in the [I-D.ietf-teas-pcecc-use-cases] -
+----------+
| R1 | Root node of the P2MP TE LSP
+----------+
|6000
+----------+
Transit Node | R2 |
branch +----------+
* | * *
9001* | * *9002
* | * *
+-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes
+-----------+ | * +-----------+
* | * * +
9003* | * * +9004
* | * * +
+-----------+ +-----------+
| R3 | | R6 | Leaf Node
+-----------+ +-----------+
9005|
+-----------+
| R8 | Leaf Node
+-----------+
PCECC would provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The branch node (R2) needs to be instructed to replicate two copies of the incoming packet, and sent towards R4 and R5 with 9001 and 9002 labels respectively). This done via including 3 instances of CCI objects in the PCEP messages, one for each label in the example, 6000 for incoming and 9001/9002 for outgoing (along with remote nexthop). The message and procedure remains exactly as [I-D.ietf-pce-pcep-extension-for-pce-controller] with only distinction that more than one outgoing CCI MAY be present for the P2MP LSP.
In order to delete an P2MP LSP based on PCECC, the PCE sends a central controller instructions via a PCInitiate message to each node along the path of the LSP to cleanup the Label forwarding instruction as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. In case of branch nodes all instances of CCIs needs to be present in the PCEP message.
The LSP Instantiation operation is same as defined in [RFC8281] and [RFC8623].
In order to setup a P2MP PCE Initiated LSP based on the PCECC mechanism, a PCE sends PCInitiate message with Path Setup Type set for PCECC (see Section 5.2) to the Ingress PCC (root).
The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The PCC responds with first PCRpt message with the status as "GOING-UP" and assigned PLSP-ID.
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the label forwarding instructions from PCECC are send after the initial PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and other LSP identifiers can be obtained from the ingress and can be included in the label forwarding instruction in the next PCInitiate message. The rest of the PCECC LSP setup operations are same as those described in Section 4.3.1.
In case of a modification of PCECC P2MP LSP with a new path, the procedure and instructions as described in [I-D.ietf-pce-pcep-extension-for-pce-controller] apply.
In case of a redelgation and cleanup of PCECC P2MP LSP, the procedure and instructions as described in [I-D.ietf-pce-pcep-extension-for-pce-controller] apply.
The procedure and instructions are as per [I-D.ietf-pce-pcep-extension-for-pce-controller].
An Ingress PCC MAY choose to apply any OAM mechanism to check the status of LSP in the Data plane and MAY further send its status in PCRpt message (as per [RFC8623]) to the PCE.
The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN Object for PCECC capability advertisement in PATH-SETUP-TYPE-CAPABILITY TLV as specified in [I-D.ietf-pce-pcep-extension-for-pce-controller].
This document adds a new flag (M-bit) in PCECC-CAPABILITY sub-TLV to indicate the support for P2MP in PCECC. A PCC MUST set M-bit in PCECC-CAPABILITY sub-TLV and set the N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) (as per [RFC8623]) in STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support the PCECC P2MP extensions defined in this document. If M-bit is set in PCECC-CAPABILITY sub-TLV and the P2MP bits in STATEFUL-PCE-CAPABILITY TLV are not set in OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=TBD(P2MP capability was not advertised) and terminate the session.
The PATH-SETUP-TYPE TLV is defined in [RFC8408]; [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value for PCECC, which is also used for P2MP.
The Central Control Instructions (CCI) Object [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE to specify the forwarding instructions (Label information in the context of this document) to the PCC, and MAY be carried within PCInitiate or PCRpt message for label download which defined Object Type 1 for MPLS Label, which is also used for P2MP. The address TLVs [I-D.ietf-pce-pcep-extension-for-pce-controller] associates the next-hop information in case of an outgoing label.
If a node (PCC) receives a PCInitiate/PCUpd message with more than one CCI with O-bit set for outgoiing label and the node does not support the P2MP branch/replication capability, it MUST respond with PCErr message with Error-Type=2(Capability not supported).
The security considerations described in [RFC8231], [RFC8281], [RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the extensions described in this document.
A PCE or PCC implementation SHOULD allow to configure to enable/disable PCECC P2MP capability as a global configuration.
[RFC7420] describes the PCEP MIB, this MIB can be extended to get the PCECC capability status.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to enable/disable PCECC P2MP capability.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231].
PCEP extensions defined in this document do not put new requirements on other protocols.
PCEP extensions defined in this document do not put new requirements on network operations.
[I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC-CAPABILITY TLV and requests that IANA creates a registry to manage the value of the PCECC-CAPABILITY TLV's Flag field. IANA is requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag Field registry, as follows:
| Bit | Description | Reference |
|---|---|---|
| TBD | M((PCECC-P2MP-CAPABILITY)) | This document |
IANA 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:
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Udayasree Palle
EMail: udayasreereddy@gmail.com