|
|
| |
| A YANG Data Model for Path Computation Element Communications Protocol (PCEP) |
|
| draft-ietf-pce-pcep-yang-23.txt |
| Date: |
18/03/2024 |
| Authors: |
Dhruv Dhody, Vishnu Beeram, Jonathan Hardwick, Jeff Tantsura |
| Working Group: |
Path Computation Element (pce) |
|
This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data. |
| Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks |
|
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based applications in Native IP networks. It describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End-to-End (E2E) traffic assurance in the Native IP network under PCE as a central controller (PCECC). |
| Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing |
|
|
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element(PCE). Since SR can be applied to both MPLS and IPv6 data-planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data- planes. The Path Computation Element communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data-plane within PCEP. |
| Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. |
|
|
In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (SID) (called BSID) as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering Label Switched Path or an SR Traffic Engineering path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or Segment Identifier. It further specifies an extension to Path Computation Element (PCE) communication Protocol(PCEP) for reporting the binding value by a Path Computation Client (PCC) to the PCE to support PCE-based Traffic Engineering policies. |
| Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) |
|
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. |
| Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
|
|
The 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. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. |
| Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths |
|
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies Path Computation Element Communication Protocol (PCEP) extension to associate candidate paths of the SR Policy. Additionally, this document updates [RFC8231] to allow stateful bringup of an SR LSP, without using PCReq/PCRep messages. This document is applicable to both Segment Routing over MPLS and to Segment Routing over IPv6 (SRv6). |
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. |
|
|
The PCE is a core component of Software-Defined Networking (SDN) systems. 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 Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. |
| PCEP Extension for Stateful Inter-Domain Tunnels |
|
|
This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the MPLS toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. |
| PCEP Extensions for Signaling Multipath Information |
|
| draft-ietf-pce-multipath-11.txt |
| Date: |
08/04/2024 |
| Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra |
| Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new PCEP mechanisms are meant to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. |
| Inter Stateful Path Computation Element (PCE) Communication Procedures. |
|
| draft-ietf-pce-state-sync-07.txt |
| Date: |
17/03/2024 |
| Authors: |
Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng |
| Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. |
| Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects |
|
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. |
| PCEP extensions for p2mp sr policy |
|
| draft-ietf-pce-sr-p2mp-policy-05.txt |
| Date: |
03/03/2024 |
| Authors: |
Hooman Bidgoli, Dan Voyer, Saranya Rajarathinam, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| Working Group: |
Path Computation Element (pce) |
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. |
| PCEP Extension for Layer 2 (L2) Flow Specification |
|
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| Carrying SR-Algorithm information in PCE-based Networks. |
|
| draft-ietf-pce-sid-algo-08.txt |
| Date: |
01/02/2024 |
| Authors: |
Samuel Sidor, Alex Tokar, Shaofu Peng, Shuping Peng, Andrew Stone |
| Working Group: |
Path Computation Element (pce) |
|
The SR-Algorithm associated with a Prefix Segment-ID (SID) defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the SR- Algorithm associated with each Prefix SID used in PCE-computed paths, as well as signalling a specific SR-Algorithm as a constraint to the PCE. |
| Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
|
| draft-ietf-pce-pcep-pmtu-05.txt |
| Date: |
28/01/2024 |
| Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor |
| Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available at the headend. This document specify the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR and other scenarios. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT |
|
| draft-ietf-pce-pcep-ifit-04.txt |
| Date: |
08/01/2024 |
| Authors: |
Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola |
| Working Group: |
Path Computation Element (pce) |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. |
| A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) |
|
| draft-ietf-pce-pcep-srv6-yang-05.txt |
| Date: |
18/03/2024 |
| Authors: |
Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor |
| Working Group: |
Path Computation Element (pce) |
|
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). |
| Path Computation Element Protocol(PCEP) Extension for Color |
|
| draft-ietf-pce-pcep-color-03.txt |
| Date: |
29/03/2024 |
| Authors: |
Balaji Rajagopalan, Vishnu Beeram, Shaofu Peng, Mike Koldychev, Gyan Mishra |
| Working Group: |
Path Computation Element (pce) |
|
Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g. low latency). This document specifies an extension to Path Computation Element Protocol (PCEP) to carry the color attribute. |
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. |
|
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. Each path is specified as a set of "segments" encoded in the header of each packet as a list of Segment Identifiers (SIDs). This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in the SRv6 (SR in IPv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID allocation and distribution. |
| Updates for PCEPS: TLS Connection Establishment Restrictions |
|
|
Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data. |
| Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. |
|
|
A Stateful Path Computation Element (PCE) maintains information on the current network state, including computed Label Switched Path (LSPs), reserved resources within the network, and the pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for the associated and the dependent LSPs, received from a Path Computation Client (PCC). RFC 7470 defines a facility to carry vendor-specific information in stateless Path Computation Element Communication Protocol (PCEP). This document extends this capability for the Stateful PCEP messages. |
| PCEP Extensions for BIER-TE |
|
| draft-ietf-pce-bier-te-00.txt |
| Date: |
04/11/2023 |
| Authors: |
Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang |
| Working Group: |
Path Computation Element (pce) |
|
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [RFC9262]. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE. |
| PCEP extensions for Circuit Style Policies |
|
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. |
| Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions |
|
|
Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. |