PCE Working Group J. Dong Internet-Draft S. Fang Intended status: Standards Track Huawei Technologies Expires: April 26, 2022 L. Han M. Wang China Mobile October 23, 2021 Support for Virtual Transport Network (VTN) in the Path Computation Element Communication Protocol (PCEP) draft-dong-pce-pcep-vtn-00 Abstract With the introduction and evolvement of 5G and other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional Virtual Private Networks (VPNs). Such kind of network service is called enhanced VPNs (VPN+). The typical application of VPN+ is to provide network slice services. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. Then traffic flows of the VPN+ service can be steered onto the TE paths within the VTN. The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks. This document specifies the extensions to PCE communication Protocol (PCEP) to carry VTN information in the PCEP messages. The extensions in this document can be used in the basic PCE computation, the stateful PCE and the PCE-initiated LSP mechanisms to indicate path computation, path status report and path initialization within a specific VTN. 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 Dong, et al. Expires April 26, 2022 [Page 1] Internet-Draft PCEP Extensions for VTN October 2021 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo 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 April 26, 2022. Copyright Notice Copyright (c) 2021 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. New TLV in LSPA Object . . . . . . . . . . . . . . . . . 4 2.2. Capability Advertisement . . . . . . . . . . . . . . . . 5 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 Dong, et al. Expires April 26, 2022 [Page 2] Internet-Draft PCEP Extensions for VTN October 2021 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalized MPLS (GMPLS) 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]. [RFC8664] specifies PCEP extensions to allow a stateful PCE to compute and initiate TE paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. With the introduction and evolvement of 5G and other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional Virtual Private Networks (VPNs). Such kind of network service is called enhanced VPNs (VPN+). The typical application of VPN+ is to provide network slice services. The concept and general framework of IETF network slice are described in [I-D.ietf-teas-ietf-network-slices]. [I-D.ietf-teas-enhanced-vpn] describes a framework and the candidate component technologies for providing VPN+ services. It also introduces the concept of Virtual Transport Network (VTN). A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the underlay, so as to provide the network characteristics required by the customers. Then the traffic flows of the VPN+ service can be steered onto the TE paths within the VTN. In MPLS or SR based network, the set of network resources allocated to a VTN can be identified using resource-aware SR SIDs as defined in [I-D.ietf-spring-resource-aware-segments] Dong, et al. Expires April 26, 2022 [Page 3] Internet-Draft PCEP Extensions for VTN October 2021 [I-D.ietf-spring-sr-for-enhanced-vpn], or the VTN Resource ID as defined in [I-D.dong-6man-enhanced-vpn-vtn-id]. The logical topology associated with a VTN could be specified using mechanisms such as Multi-Topology [RFC4915], [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo], etc. To meet specific service requirement, traffic flows of a VPN+ service need be steered onto TE paths of the corresponding VTN. A PCC may request the PCE for computing a TE path within a VTN, so that the path computation would take the resource attribute and the associated topology of the VTN into consideration. Correspondingly, a PCE may reply or initiate a TE path with VTN-specific control and data plane information to a PCC. This document extends PCEP to allow VTN information to be encoded in the PCEP messages. The extensions in this document can be used in the basic PCE computation, the stateful PCE and the PCE-initiated LSP mechanisms to indicate path computation, path status report and path initialization within the context of a specific VTN. 2. PCEP Extensions 2.1. New TLV in LSPA Object A new VTN TLV for use in the LSPA Object is defined to indicate the VTN ID and the related information as constraints. The format of the VTN TLV is 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=TBD1 | Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional sub-TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: VTN TLV Format Where: o VTN ID: A global significant 32-bit identifier which is used to identify a VTN. Dong, et al. Expires April 26, 2022 [Page 4] Internet-Draft PCEP Extensions for VTN October 2021 o Flags: 16-bit flags. Currently all the flags are reserved for future use. They SHOULD be set to zero on transmission and MUST be ignored on receipt. o Reserved: 16-bit reserved field for future use. All the bits SHOULD be set to zero on transmission and MUST be ignored on receipt. o Optional sub-TLVs: Additional information which can be used in as VTN-specific constraints. Currently no sub-TLV is defined in this document. 2.2. Capability Advertisement A PCEP speaker indicates whether it supports VTN specific path computation using a new PCEP capability called "VTN-CAPABILITY". When the PCEP session is created, it sends an Open message with an OPEN Object containing the VTN-CAPABILITY TLV. The format of this TLV is 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=TBD2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: VTN CAPABILITY TLV The type (16 bits) of the TLV is TBA. The length field is 16 bits long and has a fixed value of 4. The value comprises a single field -- Flags (32 bits): o D (Data Plane VTN-ID CAPABILITY - 1 bit): if set to 1 by a PCC, the D flag indicates that the PCC supports the encapsulation of data plane VTN-ID in data packet; if set to 1 by a PCE, the D flag indicates that the PCE supports to provide path computation result with the data plane VTN-ID. o Unassigned bits in the Flags field MUST be set to zero and ignored on receipt. Dong, et al. Expires April 26, 2022 [Page 5] Internet-Draft PCEP Extensions for VTN October 2021 3. Operations The new VTN TLV defined in this document can be used in the basic PCE computation, the stateful PCE and the PCE-initiated LSP mechanisms to indicate path computation, path status report and path initialization within the context of a specific VTN. Information about the VTN-specific network resource and topology attributes can be obtained by the PCE either from the network planning system, or using a distributed control plane such as IGP or BGP-LS with necessary extensions. The detailed mechanism is out of the scope of this document. The obtained VTN specific attributes can be used in path computation when the VTN-ID is specified in the path computation request. With the basic path computation mechanism, the new VTN TLV can be used to indicate the VTN in which the path computation is requested. In a PCReq message, the VTN TLV MAY be carried in the LSPA Object to indicate that the path computation needs to be executed using the resource and topological attributes of the VTN. The PCE SHOULD use the network resource and topology attributes associated with the specified VTN as the parameters of path computation. In a PCRep message, the VTN TLV MAY be carried in the LSPA Object in case of failure to indicate the path computation in the VTN was not successful. The new VTN TLV can also be used in the stateful PCE mechanisms. A PCC MAY include the VTN TLV in PCRpt message to indicate the VTN in which the TE path is reported. And A PCE MAY include the VTN TLV in PCUpd Message to indicate the VTN in which the TE path needs to be updated. With the PCE-Initiated LSP mechanism, the PCE MAY include the VTN TLV in PCInitiate or PCUpd message to indicate the VTN in which the path is computed, so that the PCC will use the VTN-specific resources and data plane VTN-ID in constructing or updating the TE path. 4. Security Considerations This document defines a new VTN TLV that do not add any new security concerns beyond those discussed in [RFC5440] in itself. Some deployments may find the VTN information to be extra sensitive and could be used to influence path computation and setup with adverse effect. Additionally, snooping of PCEP messages with such data or using PCEP messages for network reconnaissance may give an attacker sensitive information about the operations of the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Dong, et al. Expires April 26, 2022 [Page 6] Internet-Draft PCEP Extensions for VTN October 2021 Security (TLS) [RFC8253]. The procedure based on TLS is considered a security enhancement and thus is much better suited for the sensitive information. 5. IANA Considerations This document makes following requests to IANA for action. IANA is requested to make the following allocations in the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Value Description Reference ----- ---------------- ------------- TBD1 VTN This document TBD2 VTN CAPABILITY This document 6. Contributors Dhruv Dhody Email: dhruv.ietf@gmail.com Zhibo Hu Email: huzhibo@huawei.com 7. Acknowledgments The authors would like to thank Zhenbin Li for his review and valuable comments. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Dong, et al. Expires April 26, 2022 [Page 7] Internet-Draft PCEP Extensions for VTN October 2021 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-17 (work in progress), July 2021. 8.2. Informative References [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . Dong, et al. Expires April 26, 2022 [Page 8] Internet-Draft PCEP Extensions for VTN October 2021 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", draft-ietf-teas-ietf- network-slices-04 (work in progress), August 2021. [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", draft-ietf-teas-enhanced-vpn-08 (work in progress), July 2021. [I-D.ietf-spring-resource-aware-segments] Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Introducing Resource Awareness to SR Segments", draft-ietf-spring-resource-aware-segments-03 (work in progress), July 2021. [I-D.ietf-spring-sr-for-enhanced-vpn] Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Z., and F. Clad, "Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- enhanced-vpn-01 (work in progress), July 2021. [I-D.dong-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network Identifier in IPv6 Extension Header", draft-dong-6man-enhanced-vpn-vtn-id-05 (work in progress), September 2021. Authors' Addresses Dong, et al. Expires April 26, 2022 [Page 9] Internet-Draft PCEP Extensions for VTN October 2021 Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Sheng Fang Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: fangsheng@huawei.com Liuyan Han China Mobile Beijing China Email: hanliuyan@chinamobile.com Minxue Wang China Mobile Beijing China Email: wangminxue@chinamobile.com Dong, et al. Expires April 26, 2022 [Page 10]