]> PCE Redundancy Extensions in Path Computation Element Communication Protocol (PCEP) Ribbon Communication
Yagia Kapaim 24 Petah Tikva Israel marina.fizgeer@rbbn.com
PCE Working Group The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). A PCE redundance case is very important and has no real solution for many cases, like as active-standby, active-active or not concurrent sessions of PCC with different PCEs. This document proposes extensions to PCEP to allow a PCC and PCEs to support PCE fast and smooth redundancy in case of PCEP session and PCE failure.
Introduction PCE redundancy case is very important and complicate scenario, as PCEP protocol doesn't support exchange of session information between PCEs.
Requirements Language 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.
Terminology This document uses the following terms defined in : PCC, PCE, PCEP Peer, and PCEP speaker. The base PCEP specification originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types, such as SRv6, has been introduced . The term "LSP" is used extensively in PCEP specifications and, in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP Object as specified in .
PCEP Extensions
Let's consider simple configuration:
PCE redundancy
| | | Terminated Session| | | | | | | Start del and state | | | timers | | | | | | Del timer expired | | | | | | Put LSPs (PCE1) as orphan | | |<----------------------------| | | Take delegation LSPs (PCE1) | | |---------------------------->| | | State timer expired | | | (internal) | | | Delete LSPs (PCE1) | ]]>
  • Note:
    PCE2 session can be created/exist in different states after or in parallel with PCE1 session and others.
    Only in the timeslot between expiration of the deletion timer and
    the state timer, PCE2 can take delegation.
Figure 2: PCE redundancy and take delegation timeslot
A PCE1 can instantiate LSPs on a PCC. When session between PCE1 and PCC is terminated, PCC starts delegation and state timers. Once delegation timer is expired, all LSPs are changed to orphan. Once state timer is expired, all LSPs in orphan state are deleted by PCC. PCE2 can take delegation of orphan LSPs only, but doesn't aware about timers of PCE1-PCC session. This document specifies PCEP extensions to handle this situation in different scenarios: Multiple parallel sessions in mode active-standby Multiple parallel sessions in mode active-active Sequential sessions (one session is terminated, then another session is established)
OPEN Object This document defines one new flag for use in the STATEFUL-PCE-CAPABILITY TLV.
STATEFUL-PCE-CAPABILITY TLV A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in Section 5.4 of . * D (DELEGATION-INFO-CAPABILITY): If set, indicates that the PCEP peer supports LSP delegation info.
LSP object New TLV with address of PCE to which LSP is delegated SHALL be added:
    • 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Delegated PCE IPv4 address
Delegated PCE IPv6 address
DELEGATION-TIMER-EXPIRATION TLV PCE address (was owner) for session with its delegation timer expired. PCC SHALL send this message to all PCEs with active session.
Operation
Optional extension for take delegation action New flag in PCInit: D take delegation, PLSP ID = 0, New sub-TLV: Address of the last delegation PCE PCC SHALL send list of above LSPs with new delegation address and delegation flag Note: : if there are more than 2 parallel session, the first PCE sent get delegation all, will get it ownership, P CC is responsible to lock other PCEs for it
Manageability Considerations All manageability requirements and considerations listed in , , and apply to the PCEP extensions defined in this document.
Security Considerations The security considerations described in , , and are applicable to this document. No additional security measures are required.
IANA Considerations
STATEFUL-PCE-CAPABILITY TLV Flag
Bit Description Reference
TBD1 D (DELEGATION-INFO-CAPABILITY) This document
LSP object IANA maintains a registry, named "TE-PATH-BINDING TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignments:
PCNtf message DELEGATION-TIMER-EXPIRATION TLV
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Path Computation Element (PCE) Communication Protocol (PCEP) This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. Carrying Binding Label/SID in PCE-Based Networks Informative References A Path Computation Element (PCE)-Based Architecture Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. 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. An SR 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.
Acknowledgements