[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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


   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",
   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

   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

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

   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

   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

   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

   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

7.  Security Considerations


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

              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.

              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.

              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, <https://www.rfc-editor.org/info/rfc4364>.

   [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, <https://www.rfc-editor.org/info/rfc7432>.

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, <https://www.rfc-editor.org/info/rfc8402>.

   [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]