Network Working Group J. Dong Internet-Draft Z. Li Intended status: Informational Huawei Technologies Expires: May 7, 2020 F. Qin China Mobile November 4, 2019 Control Plane Considerations for Enhanced VPN draft-dong-teas-enhanced-vpn-control-plane-00 Abstract Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. [I-D.ietf-teas-enhanced-vpn] describes the framework and candidate component technologies for providing enhanced VPN services. This document describes the control plane requirements, functions and considerations to enable VPN+ services. Specifically, the scalability of control plane is analyzed, and the proposed optimization mechanisms are described. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 May 7, 2020. Dong, et al. Expires May 7, 2020 [Page 1] Internet-Draft VPN+ Control Plane November 2019 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements on Control Plane . . . . . . . . . . . . . . . . 3 2.1. Support of Isolation . . . . . . . . . . . . . . . . . . 3 2.1.1. Data Plane Isolation . . . . . . . . . . . . . . . . 3 2.1.2. Control Plane Isolation . . . . . . . . . . . . . . . 4 2.2. Attributes of Network Slice . . . . . . . . . . . . . . . 5 2.3. Number of Network Slices . . . . . . . . . . . . . . . . 5 3. Control Plane Functions . . . . . . . . . . . . . . . . . . . 6 3.1. Distributed Control Plane . . . . . . . . . . . . . . . . 6 3.2. Centralized Controller . . . . . . . . . . . . . . . . . 7 4. Scalability Considerations . . . . . . . . . . . . . . . . . 8 4.1. Distributed Control Plane . . . . . . . . . . . . . . . . 8 4.2. Centralized Control Plane . . . . . . . . . . . . . . . . 9 5. Optimization Mechanisms . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Driven largely by needs arising from the 5G mobile network, the concept of network slicing has gained traction [TS28530]. Network slicing requires to partition the physical network to several pieces to provide each network slice with the required networking, computing, and storage resources and functions to meet the requirement of slice tenants. As specified in [I-D.ietf-teas-enhanced-vpn], a transport network slice is a virtual Dong, et al. Expires May 7, 2020 [Page 2] Internet-Draft VPN+ Control Plane November 2019 (logical) network with a particular network topology and a set of shared or dedicated network resources, which are used to provide the network slice consumer with the required connectivity, appropriate isolation and specific Service Level Agreement (SLA). Virtual private networks (VPNs) have served the industry well as a means of providing different tenants with logically separated networks in a common network. Basically the VPN service is provided with two network layers: the overlay and the underlay. The underlay is responsible for establishing the network paths based on the network infrastructure, and managing the network resources to meet the requirement of overlay. The overlay is used to distribute the membership and reachability information of different tenants, and provide separation of services between tenants. The enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is targeted at new applications which require better isolation from both control plane and data plane's perspective and have more stringent performance requirements than can be provided with existing overlay VPNs. To meet the requirement of enhance VPN services, a number of virtual networks need be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific enhanced VPN or a group of enhanced VPNs. In the context of 5G, each virtual network is considered as a transport network slice. This document gives analysis to the control plane requirements, functions and considerations to enable enhanced VPN service. The focus of this document is on the underlay of the enhanced VPN, i.e. the transport network slice. 2. Requirements on Control Plane 2.1. Support of Isolation 2.1.1. Data Plane Isolation Isolation in data plane is the fundamental requirement of services which are deployed in a shared network infrastructure. Depends on the level of data plane isolation, the requirement can be categorized as soft isolation and hard isolation [I-D.ietf-teas-enhanced-vpn]. Soft isolation means that traffic of one application or tenant cannot be received or inspected by any other application or tenant in the same network. Usually soft isolation does not have strict resource or performance requirement, the underlying network resource can be shared by multiple applications or tenants, which is useful to achieve better economy with statistical multiplexing. However, with Dong, et al. Expires May 7, 2020 [Page 3] Internet-Draft VPN+ Control Plane November 2019 soft isolation, when service in one of the virtual networks experience some event such as traffic burst or congestion, this may result in negative impacts to other virtual networks in terms of packet loss, delay and jitter, etc. On the other hand, hard isolation means that any event happened to the traffic of one application or tenant in one virtual network will not interfere any other application or tenant in the same network, which means the characteristics of service can be guaranteed or more predictable. To achieve this, at least some of the network resource need to be dedicated, which may reduce the economy of multiplexing to some extent. Hard isolation is required by services that usually have their own private networks and expect to have the same network characteristics even in a shared network. It is expected that the requirement of some services or tenants can be met with soft isolation, while hard isolation is required for services or tenants which require guaranteed or more predictable performance. Although the soft are hard isolation characteristics are provided by the forwarding plane of network devices, the control plane needs to be aware of the data plane capability and provide necessary support for both soft and hard isolation. Specifically, network information needed for both soft and hard isolation needs to be collected and distributed in the network, and the route and path computation should be performed based the collected information to generate the forwarding entries for each virtual network. 2.1.2. Control Plane Isolation From routing's perspective, isolation in control plane can be achieved in different levels: isolation of routing database, and isolation of routing instances. Isolation of routing database can enable customized routing and TE attributes for different virtual networks. This can be used to generate customized virtual network topologies and compute customized paths for different applications or tenants. The Multi-Topology Routing (MTR) mechanisms [RFC4915] [RFC5120] provides the basic functionality to define separated topology and routing database for different virtual networks. MTR was not widely used in current network due to lack of use cases and some constraints in IP forwarding, but it can be considered as a candidate technology for enhanced VPN, especially when used with data plane technologies such as Segment Routing (SR) [RFC8402]. There are also emerging technologies, such as Flex-Algo as described in Dong, et al. Expires May 7, 2020 [Page 4] Internet-Draft VPN+ Control Plane November 2019 [I-D.ietf-lsr-flex-algo], which can provide customization of the topology and attributes for constraint route computation. Isolation of routing instances can provide further customization and flexibility, as different tenants or applications may choose their preferred routing protocols and provision it with customized parameters, and the operation of one routing instance can be independent from others. The cost of routing instance isolation is that it requires further complexity and more overhead of control plane resources, in some cases the scalability can become challenging. 2.2. Attributes of Network Slice According to the definition of transport network slice in [I-D.ietf-teas-enhanced-vpn], a transport network slice can be characterized by two major types of attributes: the network slice topology and the resources associated with the network slice. Each network slice tenant can specify his requirement on the connectivity and topology between the endpoints, and the requirement on service performance. Depending on the deployment of network slices, it is possible that several network slices may have the same topology, and with soft isolation it is possible that several network slices may share the same set of network resource. While each transport network slice is determined by the combination of the topology and the resource. The control plane SHOULD be able to describe and distribute both the topology attributes and the network resource attributes of each network slice. 2.3. Number of Network Slices In 5G scenarios, the number of network slices in a network is relevant to how network slicing is used in the network and the evolution of 5G for vertical industrial services. Although there is no clear answer so far about how many network slices will be deployed in a network, the potential number of network slices is analyzed by classifying the network slicing deployment scenarios into three typical phases. In the initial phase, network slicing can be used to isolate different types of business of one operator. For example, in a converged multi-service network, different network slices can be created to carry mobile service, fixed broadband service and enterprise service respectively, each type of service may be managed by a separate department or management team. Some particular service Dong, et al. Expires May 7, 2020 [Page 5] Internet-Draft VPN+ Control Plane November 2019 types, such as multicast service may also be deployed in a dedicated network slice. It is also possible that an network infrastructure operator can provide network slices to other network operators as wholesale service. In this phase, the number of network slices in a network would be relatively small, such as in the order of 10 or so. This could be the typical case in the beginning of network slicing deployment. In the second phase, network slicing can be used to provide isolated virtual networks for tenants of different vertical industries. At the early stage of the vertical industrial service deployment, a few tenants in some typical industries will begin to use network slicing to support their business, such as smart grid, public safety, games etc. Considering the number of the vertical industries, and the number of top tenants in each industry, the number of network slices may increase to around 100. In the third phase, with the evolution of 5G, network slicing could be widely used by both vertical industrial tenants and premium business tenants. The total amount of network slices could increase to the order of 1000 or more. While it is expected that the number of network slices would be still less than the number of traditional VPN services in the network. The control plane needs to be able to support different deployment phases of network slicing, and the number of network slices required in each phase. 3. Control Plane Functions In order to meet the requirements as described in section 2, the control plane of enhanced VPN could be based on a hybrid of centralized controller and distributed control plane. 3.1. Distributed Control Plane In the overlay of enhanced VPN, the distributed control plane is used to advertise the routing information of different applications tenants. BGP based L3VPN [RFC4364] and EVPN [RFC7432] can provide the functionality needed for the overlay control plane of enhanced VPN. Whether some extensions in overlay control plane are needed will depend on the service requirements. This is out of the scope of this document. In the underlay of enhanced VPN, the distributed control plane is responsible for advertising and collecting the customized topology and resource information of the virtual networks associated with different enhanced VPNs. A network node may participate in multiple Dong, et al. Expires May 7, 2020 [Page 6] Internet-Draft VPN+ Control Plane November 2019 virtual networks, in this case the node needs to obtain the information of each virtual network it participates in, so that the node can generate the routing and forwarding entries for each virtual network independently. Currently there are several candidate mechanisms for the underlay control plane. Either Multi-Topology Routing (MTR) [RFC4915] [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] can be used to specify and distribute the customized topology and some of the TE attributes of the virtual networks, then independent route computation could be performed based on the routing database of each virtual network. However, in order to support both hard and soft isolation in one network, some extensions would be needed to specify and distribute the network resource information of the underlay network and its association with each virtual network. Such extensions are defined in [I-D.dong-lsr-sr-enhanced-vpn] and other accompanying documents. 3.2. Centralized Controller With the introduction of SDN, a centralized controller can be used to collect the network topology and associated attributes from the underlay network, and provide global computation and optimization for the traffic engineered (TE) paths. Several existing control protocols have been designed for the interaction between the controller and the network nodes. While in order to provide the required functionality for different virtual networks, necessary extensions to these protocols would be needed. o BGP-LS [RFC7752] provides mechanisms to distribute the topology and TE information of the underlay network to the centralized controller. In the context of enhanced VPN, It be further extended to distribute the topology and resource attributes of the virtual networks to the controller. o PCEP [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. It can also be used for the creation and deletion of PCE-initiated paths in the network [RFC8281]. In the context of enhanced VPN, It can be further extended for path computation request, responses and path provisioning within a particular virtual network. o Netconf/YANG [RFC6241] [RFC7950] provides mechanisms for the configuration of network device and protocols. In the context of enhanced VPN, some extension to existing data models may be needed for the configuration of virtual network specific attributes. Dong, et al. Expires May 7, 2020 [Page 7] Internet-Draft VPN+ Control Plane November 2019 The detailed protocol extensions are out of the scope of this document and will be specified in separate documents. 4. Scalability Considerations With the development and evolution of 5G network slicing, more and more transport network slices will be deployed. In different transport network slices derived from the same underlay network, the computed paths between the same pair of network nodes can be different, and the resource used for packet forwarding and processing in different network slices can also be different. In order to provide routing in different transport network slices, several aspects need to be considered, such as whether separated routing protocols or routing instances need to be provided for different transport network slices, and how to identify the same network node or link in different transport network slices. The answer to these problems will impact the scalability of both the control plane and the data plane. In this section, the scalability of control plane is analyzed to understand whether or not the control plane mechanisms could support the required amount of transport network slices. 4.1. Distributed Control Plane As network slicing requires to provide customized topology and resource attributes to different applications or tenants, it is expected that more state will be introduced into the underlay network. The scalability of the distributed control plane of the underlay network needs to be considered in the following aspects: o The number of protocol instances to be maintained on each node o The number of the protocol sessions to be maintained on each node o The number of routes to be advertised in the network o The amount of information and attributes associated with each route to be advertised o The number of route computation (i.e. SPF) to be executed on each node As the number of network slices increases, it is expected that for some of the aspects listed above, the overhead in control plane may be not be affordable. For example, the overhead of maintaining separated logical routing systems for different network slices is higher than maintaining separate routing instances, which is also Dong, et al. Expires May 7, 2020 [Page 8] Internet-Draft VPN+ Control Plane November 2019 higher than maintaining separated network topologies in the same routing instance. In order to meet the requirement of increasing network slices in future, It is suggested to choose the control plane mechanisms which could improve the scalability while still provide the required functionality. 4.2. Centralized Control Plane Although the SDN approach can reduce the amount of control plane overhead in the distributed control plane, SDN may transfer some of the scalability concerns from the network to the centralized controller, thus the scalability of the controller with network slicing also needs to be considered. In order to provide global optimization for TE paths in different network slices, the controller needs to keep the information of all the network slices up to date. To achieve this, the controller may need to maintain a communication channel with each network node in the network. When there is significant change in the network and multiple network slices requires global optimization, there may be a heavy processing burden at the controller, and a heavy load in the network surrounding the controller for the distribution of the updated network state. 5. Optimization Mechanisms For the distributed control plane, several optimization mechanisms are proposed to reduce the overhead and improve the control plane scalability. The first mechanism is to reduce the amount of control plane sessions. For network slices which have the same peering relationship between two adjacent nodes, it is proposed that one single control session is shared by multiple network slices, information of different network slices can be exchanged over the same control session, with necessary information to distinguish them in the control message. This could reduce the overhead of maintaining large amount of control sessions, and could also reduce the amount of routing information flooding in the network. The second mechanism is to decouple different types of attributes of a network slice, so that different types of information can be advertised and processed separately in control plane. One example is to decouple the topology and resource attribute of the network slice. This can reduce the amount of route computation introduced by the increased number of network slices. For a group of network slices which have the same network topology, the result of topology based computation could be shared, which means the SPF computation only Dong, et al. Expires May 7, 2020 [Page 9] Internet-Draft VPN+ Control Plane November 2019 needs to be executed once for this group of network slices. This way, the computation overhead could be reduced, especially when there are a large number of network slices, with only a small set of different network topologies. In order to obtain this optimization benefit, network nodes need to be aware of which set of network slices have the same topology, even if the other attributes of the network slices (e.g. resource attributes) are different. Some mechanism to decouple the topology attributes and other attributes of the network slices would be needed. This methodology also applies to other attributes which can be processed independently. For the centralized control plane, it is considered that the centralized controller is deployed as a complementary mechanism to the distributed control plane rather than a replacement, so that the computation burden in control plane could be shared by both the centrazlied controller and the network nodes, thus the scalability of both could be improved. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD 8. Acknowledgements The authors would like to thank Zhibo Hu for his review and suggestions to this document. 9. References 9.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, . 9.2. Informative References Dong, et al. Expires May 7, 2020 [Page 10] Internet-Draft VPN+ Control Plane November 2019 [I-D.dong-lsr-sr-enhanced-vpn] Dong, J. and S. Bryant, "IGP Extensions for Segment Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- vpn-01 (work in progress), October 2018. [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-04 (work in progress), September 2019. [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Networks (VPN+) Service", draft-ietf-teas-enhanced-vpn-03 (work in progress), September 2019. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . Dong, et al. Expires May 7, 2020 [Page 11] Internet-Draft VPN+ Control Plane November 2019 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [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, . [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, . [TS28530] "3GPP TS28.530", 2016, . Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com Fengwei Qin China Mobile Email: qinfengwei@chinamobile.com Dong, et al. Expires May 7, 2020 [Page 12]