Internet DRAFT - draft-dong-teas-enhanced-vpn-control-plane
draft-dong-teas-enhanced-vpn-control-plane
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,
<https://www.rfc-editor.org/info/rfc2119>.
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, <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,
<https://www.rfc-editor.org/info/rfc4915>.
[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,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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,
<https://www.rfc-editor.org/info/rfc6241>.
[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,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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,
<https://www.rfc-editor.org/info/rfc8281>.
[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,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3273>.
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]
