| Internet-Draft | PCEP Extension for INTERACTING-CAPBILITY | March 2022 |
| Wang, et al. | Expires 26 September 2022 | [Page] |
The PCE communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs), Path Computation Elements (PCEs) and cooperating PCEs, support of traffic engineering in Multiprotocol Label Switching (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks. In PCEP, due to the different implementing of PCC tunnel capability, especially bidirectional SR tunnels, the PCE can only provides path computation functions between the PCCs which adopt identical mechanisms.¶
With the introduction and evolvement of 5G and other network scenarios, the scale of bearing and transport network has developed to a high level. On the other hand, with the improvement of network slicing ability, network equipments can provide network slicing service, such as enhanced VPNs (VPN+). Transport network employing time slot isolation technology, such as FlexE,MTN,can provide advanced timeslot slicing for the high quality customer services. The high quality customer services, for example industry production service, demand for superior SLA and end-to-end timeslot service slicing, regardless of whether it is across of different network equipment providers or across of different regions. Therefore, there is an urgent need of a method to support PCE to provide end-to-end path computation and establishment of SR tunnels regardless of PCC enables different protocol selections.¶
This document specifies the extensions to PCE communication Protocol (PCEP) to carry bidirectional SR tunnel capability advertisement information in PCEP message to enhance PCE ability to perceive the protocol mechanism supported by PCC.¶
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.¶
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 26 September 2022.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC5440]describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.¶
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The model of operation where LSPs are initiated from the PCE is described in [RFC8281].¶
[I-D.ietf-pce-segment-routing] specifies extensions to the Path Computation Element Protocol (PCEP)for SR networks, that allow a stateful PCE to compute and initiate SR-TE paths, as well as a PCC to request, report or delegate SR paths.¶
[I-D.li-pce-sr-path-segment] specifies a mechanism to carry the SR path identification information in PCEP messages.¶
[I-D.ietf-pce-binding-label-sid] specifies the binding value as an MPLS label or Segment Identifier. It further specifies an approach for reporting binding label/Segment Identifier (SID) by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based Traffic Engineering policies.¶
Two different implementation mechanisms of PCEP are defined in the standard protocol: Passive Stateful PCE and Active Stateful PCE. For Passive Stateful PCE, the PCC sends a path computation request to the PCE, the PCE triggers a path computation and returns either a positive or a negative reply to the PCC. For Active Stateful PCE, to create or update LSP, PCE MUST send LSP Update Request to PCC using PCUpd message or using PCInt message.¶
[I-D.li-pce-sr-path-segment] specifies various modes of operations for SR-path segment. Path Segment can be either allocated by Egress PCC or PCE. This leads to different implementation methods for the extension of Path Segment. Meanwhile PCEP procedure is divided into PCC-initiated and PCE-initiated LSPs[RFC9059].For example, Association ID is used for bidirectional SR tunnel binding. The difference of Association ID allocation between PCC-initiated and PCE-initiated is as follows: In PCC-initiated, the PCE needs to control whether the PCC reports the Association ID or not. If the PCE receives the Association ID reported by the PCC through PCRpt, it will be issued according to the Association ID reported by the PCC; if the PCE has not received the Association ID through the PCC, the PCE will directly assign an ID to the PCC. In PCE-initiated,the PCE directly assigns the AssociationID.¶
This document specifies a new OPTIONAL TLV for multiple PCC interworking scenarios. PCC can employ this TLV to report PCC abilities of supporting different mechanisms of bidirectional SR tunnels. PCE can perceive the specific implementation mode of PCC by parsing this TLV,in order to achieve the compatibility of multiple sets of PCEP standard processes in the management and control system. Particularly, Vendor TLV[RFC7470] can be used as a special implementation mechanism when various capability distinctions have been reconciled in advance.¶
This memo makes use of the terms defined in [RFC4655], [RFC5440],[I-D.li-pce-sr-path-segment], [I-D.ietf-pce-binding-label-sid] and [RFC8042].¶
SR-PCE-INTERACTING-CAPBILITY TLV clarifies various capability distinctions of PCC. Through this TLV,the PCC sends its own capability information to the PCE,which is used to determine the bidirectional segment routing tunnel capability supported by the PCC, whether the tunnel creation is initiated by the PCC or the PCE, and whether the distribution is supported by the label allocation to the PCC or the PCE,etc.¶
The PCE determines the bidirectional SR tunnel capability supported by the PCC through the acquired capability information of the PCC, and performs corresponding management on the PCC that supports different capabilities according to the capability. The PCE parses this TLV. Through the analysis results of different fields in this tlv, it can preceive which mode of the PCEP standard process is currently supported by PCC,in order to achieve PCEP interoperability. This solution can realize the PCEP implementation to compatible with different PCCs.¶
The SR-PCE-INTERACTING-CAPBILITY is an optional TLV associated with the OPEN Object to exchange SR Tunnel Capability Notification of PCEP speakers. When the PCEP session is created, PCC sends an Open message with an OPEN object containing the SR-PCE-INTERACTING-CAPBILITY TLV.¶
When the PCE receives the Open message with a SR-PCE-INTERACTING-CAPBILITY TLV, the PCE can parse the TLV. According to the results of the analysis of each capability field of the TLV, it can realize how the PCC implements the SR tunnel as a basis to send the corresponding PCEP message. In an Open message, a PCC MAY insert one SR-PCE-INTERACTING-CAPBILITY-TLV, PCC can assign different values to the corresponding fields to announce its own PCEP capability.¶
The format of SR-PCE-INTERACTING-CAPBILITY TLV is defined as follows:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TDB | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | N |FLAGS|S|C|P|B|T|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Figure 1 SR-PCE-INTERACTING-CAPBILITY TLV format¶
The code point for the TLV type is to be defined by IANA. The TLV length is 4 octets.¶
The 32-bit value is formatted as follows. The "Reserved" is unused.¶
The" Flags "(2 bits) field is unused, and MUST be set to zero on transmission and ignored on reception. This document defines the following flag:¶
o N(Number of PCInt messages sent when creating a tunnel-8 bits): This field indicates the number of times that PCInt messages need to be sent to create a tunnel. If set to 1 by a PCC means sending it once, If set to 2 by a PCC means sending it twice, and supports expansion.¶
o S (SR tunnel initiator-1 bit): This field is used to distinguish the tunnel initiator. If set to 1 by a PCC means that the PCC initiates the tunnel request. If set to 0 by a PCC means that the PCE sends the tunnel information.¶
o C (Configuration tunnel-1bit): This field is used to indicate whether the PCE is configured with a tunnel. If set to 1 by a PCC, the PCE configures the tunnel. If set to 0 by a PCC, the PCE does not configure the tunnel.¶
o P (Path Segment label assignment-1 bit): This field is used to indicate Path Segment label allocation. If set to 1 by a PCC, the Path Segment label is allocated by PCC, If set to 0 by a PCC, the Path Segment label is allocated by PCE.¶
o B (Binding label-1bit): This field is used to indicate the allocation of the adhesive label. If set to 1 by a PCC, the Binding label is allocated by the PCC, If set to 1 by a PCC, the Binding label is allocated by the PCE.¶
o T (Time sequence dependency-1bit): This field indicates whether there is a timing dependency in the protocol interaction. If set to 1 by a PCC, it means that there is a strong dependence between PCEP message interaction and time sequence. If set to 0 by a PCC, it means that there is no timing dependency.¶
o A (Association ID 1bit): This field indicates the assignment of the Association ID. If set to 1 by a PCC, it means that the Association ID is allocated by PCC. If set to 0 by a PCC, it means that the association id is allocated by PCE.¶
IANA is requested to make allocations from the registry, as follows:¶
+======+==============================+=================+
| Type | TLV | Reference |
+======+==============================+=================+
| TBD1 | SR-PCE-INTERACTING-CAPBILITY | [this document] |
+------+------------------------------+-----------------+¶
TBD¶