TEAS working group J. Dong
Internet-Draft Z. Li
Intended status: Standard Track Huawei
Expires: August 2020 F. Qin
China Mobile
February 10, 2020
Virtual Transport Network (VTN) Scalability Considerations for
Enhanced VPN
draft-dong-teas-enhanced-vpn-vtn-scalability-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 could be used
for transport network slicing in 5G, 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 scalability
considerations in the control plane and data plane to enable VPN+
services, some optimization mechanisms are also described.
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 August 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dong, et al. Expires August 10, 2020 [Page 1]
Internet-Draft VPN+ Scalability Considerations February 2020
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 Language........................................ 3
3. Scalability Requirement ..................................... 3
4. Scalability Considerations .................................. 5
4.1. Control Plane Scalability Considerations ............... 5
4.1.1. Distributed Control Plane ............................ 5
4.1.2. Centralized Control Plane ............................ 6
4.2. Data Plane Scalability Considerations .................. 6
4.3. Gap Analysis of Existing Mechanism ..................... 7
5. Possible Optimization ....................................... 7
5.1. Control Plane Optimization ............................. 7
5.2. Data Plane Optimization ................................ 9
6. Solution Evolution for Improved Scalability ................ 11
7. Security Considerations .................................... 11
IANA Considerations ........................................... 11
Acknowledgments ............................................... 11
References .................................................... 12
Normative References........................................ 12
Informative References ..................................... 12
Authors' Addresses ............................................ 13
1. Introduction
Virtual private networks (VPNs) have served the industry well as a
means of providing different groups of users with logically isolated
connectivity over a common network. The VPN service is provided with
two network layers: the overlay and the underlay. The underlay is
responsible for establishing the network connectivity and managing
network resources to meet the service requirement. The overlay is
used to distribute the membership and reachability information of
the tenants, and provide logical separation of services between
different tenants.
Dong, et al. Expires August 10, 2020 [Page 2]
Internet-Draft VPN+ Scalability Considerations February 2020
Enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is targeted
at new applications which require better isolation and have more
stringent performance requirements than can be provided with
existing overlay VPNs. To meet the requirement of enhanced VPN
services, a number of virtual transport networks (VTN) need to 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 VPN+ service or a group of VPN+ services. The overlay VPN
together with the corresponding VTN in the underlay provide the
enhanced VPN service.
[I-D.ietf-teas-enhanced-vpn] provides some general analysis to the
scalability of VPN+. This document gives detailed analysis to the
scalability considerations to enable enhanced VPN service. The
focus of this document is on the underlay of the enhanced VPN, i.e.
the virtual transport network.
In the context of 5G, enhanced VPN can be used to provide network
slicing in transport network.
2. 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
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Scalability Requirement
As mentioned in [I-D.ietf-teas-enhanced-vpn], VPN+ services may
require to install some additional state within the network to
achieve the additional features. This introduces some scalability
concerns to the network. This section gives some analysis about the
number of VPN+ services needed in a network.
The number of enhanced VPNs required in a network is determined by
the use cases. One typical use case of enhanced VPN is to provide
transport network slicing for applications or services in 5G. With
the development and evolution of 5G, it is expected that more
network slices will be needed. The number of network slices required
in a network is relevant to how network slicing is used in the
network and the evolution of 5G for vertical industrial services.
The potential number of network slices is analyzed by classifying
the network slicing deployment into three typical types of scenarios:
Dong, et al. Expires August 10, 2020 [Page 3]
Internet-Draft VPN+ Scalability Considerations February 2020
1. Network slicing can be used to isolate different types of
business of the network 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 could be managed by a
separate department or management team. Some particular service
types, such as multicast service may also be deployed in a
dedicated network slice. It is also possible that a
infrastructure network operator can provide network slices to
other network operators as wholesale service. In this scenario,
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.
2. Network slicing can be used to provide isolated and customized
virtual networks for tenants of different vertical industries. At
the early stage of the vertical industrial service deployment, a
few top tenants in some typical industries will begin to use
network slicing to support their business, such as smart grid,
manufacture, public safety, on-line 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.
3. 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 may 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.
In 3GPP [TS23501], a network slice is identified using Single
Network Slice Selection Assistance Information (S-NSSAI), which is a
32-bit identifier comprised of 8-bit Slice/Service Type (SST) and
24-bit Slice Differentiator (SD). This allows the mobile network
(RAN and CN) to provide a large number of network slices. Although
it is possible that several network slices in RAN and CN can be
mapped to the same transport network slice, the scalability of
transport network slices needs to be taken into consideration from
the beginning.
Dong, et al. Expires August 10, 2020 [Page 4]
Internet-Draft VPN+ Scalability Considerations February 2020
8-bit 24-bit
+------------+-------------------------+
| SST | Slice Differentiator |
+------------+-------------------------+
Figure 1 Format of Network Slice Identifier in 3GPP
Enhanced VPN needs to meet the scalability requirement of network
slicing in different scenarios. The increased number of enhanced
VPNs will introduce additional complexity and overhead to both the
control plane and data plane, especially for the underlying virtual
transport network.
4. Scalability Considerations
In this section, the scalability of control plane and data plane is
analyzed to understand whether the existing mechanisms could meet
the scalability requirement of enhanced VPNs, and to identify
possible optimizations.
4.1. Control Plane Scalability Considerations
As described in section 3.1 of [I-D.ietf-teas-enhanced-vpn], the
control plane of enhanced VPN could be based on a hybrid of
centralized controller and distributed control plane.
4.1.1. Distributed Control Plane
As the underlay of VPN+ service, it is required that the different
VTNs need to be created to provide customized topology and resource
attributes for different applications or tenants, and the state of
each VTN needs to be exchanged in control plane. The scalability of
the distributed control plane for the establishment and maintenance
of VTNs needs to be considered in the following aspects:
o The number of control protocol instances maintained on each
node
o The number of the protocol sessions maintained on each node
o The number of routes advertised by each node
o The amount of attributes associated with each route
o The number of route computation (i.e. SPF) executed on each
node
Dong, et al. Expires August 10, 2020 [Page 5]
Internet-Draft VPN+ Scalability Considerations February 2020
As the number of VTNs increases, it is expected that for some of the
above aspects, the overhead in control plane may become unaffordable.
For example, the overhead of maintaining separated routing instances
for different VTNs is considered higher than maintaining separated
virtual network topologies for different VTNs in the same routing
instance, and the overhead of maintaining separate protocol sessions
for each VTN is higher than using a shared protocol session for the
information exchange of multiple VTNs. In order to meet the
requirement of the increasing number of VTNs, It is suggested to
choose the control plane mechanisms which could improve the
scalability while still provide the required functionality.
4.1.2. Centralized Control Plane
Although the SDN approach can reduce the amount of control plane
overhead in the distributed control plane, it may transfer some of
the scalability concerns from the network to the centralized
controller, thus the scalability of the controller also needs to be
considered.
In order to provide global optimization for TE paths in different
VTNs, the controller needs to keep the topology and resource
information of all the VTNs 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 VTNs requires global optimization
concurrently, there may be a heavy processing burden at the
controller, and also a heavy load in the network surrounding the
controller for the distribution of the updated network state.
4.2. Data Plane Scalability Considerations
To provide different enhanced VPNs with the required isolation and
performance, it is necessary to allocate different set of network
resources to different VTNs to provide the underlay for different
enhanced VPNs. As the number of enhanced VPNs increases, the number
of VTNs would increase accordingly. This requires the underlying
network to provide finer-granular network resource partitioning,
which means the amount of states about the reserved network
resources to be maintained on network nodes will also increase.
In a network, traffic of different VPN+ services need to be
processed separately according to the topology and resource
constraints of the corresponding VTN, thus the identifier of the
corresponding VTN needs to be carried either directly or implicitly
in the data packet. Different representations of the VTN ID in data
Dong, et al. Expires August 10, 2020 [Page 6]
Internet-Draft VPN+ Scalability Considerations February 2020
packet has different scalability characteristics. It is possible to
reuse some existing fields in packet header to additionally identify
the VTN the packet belongs to, while this may result in more of the
existing identifiers being allocated than expected in the original
design. An alternative is to introduce a new identifier in the
packet for VTN identification.
In addition, the introduction of per VTN forwarding has impact on
the scalability of the forwarding entries on network nodes, as a
network node needs to maintain separate forwarding entries for each
VTN it participates.
4.3. Gap Analysis of Existing Mechanism
One candidate approach to build VTN is using Segment Routing (either
SR-MPLS or SRv6) as data plane and distributing the customized
topology and resource attribute based on Multi-topology [RFC4915]
[RFC5120] and/or Flex-Algo [I-D.ietf-lsr-flex-algo] mechanism in
control plane. While if the number of VTNs increases to more than
100, such approach may have several scalability issues:
1. The number of SR SIDs needed would increase proportional to
the number of VTNs in the network, which would bring challenge
both to the control plane distribution of the SIDs and to the
installation of data plane forwarding entries for the SIDs.
2. The number of SPF computation would also increase proportional
to the number of VTNs in the network, which can introduce
significant overhead to the control plane of network nodes.
3. The maximum number of virtual network instances supported by
OSPF Multi-topology and Flex-Algo is 128, which may not meet
the required number of VTNs in a network.
5. Possible Optimization
5.1. Control Plane Optimization
For the distributed control plane, several optimizations are
proposed to reduce the overhead and improve the control plane
scalability.
The first proposed mechanism is to reduce the amount of control
plane sessions used for the establishment and maintenance of the
VTNs. For multiple VTNs which have the same peering relationship
between two adjacent network nodes, it is proposed that one single
Dong, et al. Expires August 10, 2020 [Page 7]
Internet-Draft VPN+ Scalability Considerations February 2020
control session is used for the establishment of multiple VTNs.
Information of different VTNs can be exchanged over the same control
session, with necessary identification information to distinguish
them in the control messages. This could reduce the overhead of
maintaining large amount of control sessions, and could also reduce
the amount of control message flooding in the network.
The second proposed mechanism is to decompose the attributes of a
VTN into different groups, so that different types of attribute can
be advertised and processed separately in the control plane. For a
VTN, there are two basic types of attributes, the topology attribute
and the associated network resource attribute. In a network,
multiple VTNs could share the same topology, and multiple VTNs may
share the same set of network resource on particular network
segments. It would be more efficient if only one copy of the
topology attribute is advertised, then multiple VTNs referring to
the same topology could share the topology information and the
result of topology based route computation. Similarly, information
of a subset of reserved network resource could be advertised once
and then be used by multiple VTNs. This methodology also applies to
other attributes of VTN which may be introduced later and can be
processed independently.
O#####O#####O O*****O*****O
# # # * * *
# # # * * *
O#####O#####O O*****O*****O
VTN-1 VTN-2
O-----O-----O
| | |
| | |
O-----O-----O
Shared Network Topology
Legend
O Virtual node
### Virtual links with a set of reserved resource
*** Virtual links with another set of reserved resource
Figure 2 Topology Sharing between VTNs
Dong, et al. Expires August 10, 2020 [Page 8]
Internet-Draft VPN+ Scalability Considerations February 2020
Figure 1 gives an example of multiple VTNs which shares the same
topology attribute. As shown in the figure, VTN-1 and VTN-2 have the
same topology, while the resource attributes on links of each VTN
are different. In this case, only one copy of the network topology
information needs to be advertised, and the topology based route
computation result can be used by both VTNs to generate their
routing tables.
O#####O#####O O- -O#####O
# # # \/ # #
# # # /\ # #
O#####O#####O O- -O#####O
VTN-1 VTN-2
Legend
O Virtual node
### Virtual links with a set of reserved resource
--- Virtual links with another set of reserved resource
Figure 3 Resource Sharing between VTNs
Figure 2 gives another example of multiple VTNs which shares the
same set of network resources on some links. Similarly, information
about the reserved resource on each link only needs to be advertised
once, then both VTN-1 and VPN-2 could refer to the link resource for
constraint based computation.
For the centralized control plane, it is suggested that the
centralized controller is deployed as a complementary mechanism to
the distributed control plane rather than a total replacement, so
that the computation burden in control plane could be shared by both
the centralized controller and the network nodes, thus the
scalability of both system could be improved.
5.2. Data Plane Optimization
In order to support more enhanced VPNs services while keeping the
amount of data plane state in a reasonable scale, one possible
approach is to classify a set of enhanced VPN services which has
similar service characteristics and performance requirements into a
group, and such group of enhanced VPNs is mapped to one VTN which is
allocated with an aggregated set of network resources to meet the
service requirement of the whole group of enhanced VPNs. Different
Dong, et al. Expires August 10, 2020 [Page 9]
Internet-Draft VPN+ Scalability Considerations February 2020
groups of enhanced VPNs need to be mapped to different VTNs with
different set of network resources allocated. With appropriate
grouping of enhanced VPN services, a reasonable number of VTNs with
network resources aggregation could still meet the service
requirements.
Another optimization in data plane is to decouple the identifier
used for topology based forwarding and the identifier used for the
resource specific processing introduced by VTN. One possible
mechanism is to introduce a dedicated field in packet header to
uniquely identify the set of local network resources allocated to
the VTN on each network node for the processing of the received
packet. Then the existing identifier in packet header used for
topology based forwarding is kept unchanged. The benefit is the
number of existing topology-specific identifiers will only increase
as the number of the virtual network topologies increases, so that
the scalability of the existing identifier will not be impacted by
the increase of VTN. Note this probably requires network nodes to
support a hierarchical forwarding table in the data plane. Figure 3
shows
+--------------------------+
| Packet Header |
| |
| +----------------------+ |
| | Topology-specific ID | |
| +----------------------+ |
| |
| +----------------------+ |
| | VTN ID | |
| +----------------------+ |
+--------------------------+
Figure 4 Decoupled Data Plane Identifiers
In an IPv6 [RFC8200] based network, this could be achieved by
introducing a dedicated field in the IPv6 fixed header or one of the
extension headers to carry the VTN identifier for the resource
specific forwarding, while keeping the destination IP address field
used for routing towards the destination prefix in the corresponding
topology. Note that the VTN ID needs to be parsed by every node
along the path which is capable of VTN specific forwarding. In an
MPLS [RFC3032] based network, this may be achieved by introducing a
new dedicated MPLS label to identify the VTN instance, while the
existing MPLS labels could be used for topology based packet
Dong, et al. Expires August 10, 2020 [Page 10]
Internet-Draft VPN+ Scalability Considerations February 2020
forwarding towards the associated destination prefix. This requires
that both labels be parsed by each node along the forwarding path of
the packet. The detailed extensions in IPv6 and MPLS encapsulation
are out of the scope of this document.
6. Solution Evolution for Improved Scalability
Based on the analysis in this document, the solution for enhanced
VPN needs to evolve to support the increasing number of enhanced
VPNs in the network.
For example, by introducing resource awareness to segment routing
SIDs [I-D.dong-spring-sr-for-enhanced-vpn], and using Multi-Topology
or Flex-Algo as control plane could provide a solution for building
a limited set of VTNs in the network to meet the requirement of a
small number of enhanced VPNs in the network. Such mechanism can be
called SR-VTN.
As the number of required enhanced VPNs increases, more VTNs needs
to be created, then the control plane scalability could be improved
by introducing topology sharing between multiple VTNs. Such
mechanism can be called Topology Independent (TR) SR-VTN.
In order to further improve the data plane scalability, dedicated
data plane identifiers of VTN can be introduced to decouple the
topology based forwarding and the resource based processing in the
data plane. Such mechanism can be called Resource Independent (RI)
SR-VTN.
7. Security Considerations
TBD
IANA Considerations
This document makes no request of IANA.
Acknowledgments
The authors would like to thank XXX for the review and valuable
comments.
Dong, et al. Expires August 10, 2020 [Page 11]
Internet-Draft VPN+ Scalability Considerations February 2020
References
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Informative References
[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-04
(work in progress), January 2020.
[I-D.dong-spring-sr-for-enhanced-vpn] Dong, J., Bryant, S., Miyasaka,
T., Zhu, Y., Qin, F., and Z. Li, "Segment Routing for
Enhanced VPN Service", draft-dong-spring-sr-for-enhanced-
vpn-06 (work in progress), December 2019.
[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>.
[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-05 (work in progress), November
2019.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/
RFC8200, July 2017, <https://www.rfc-editor.org/info/
rfc8200>.
Dong, et al. Expires August 10, 2020 [Page 12]
Internet-Draft VPN+ Scalability Considerations February 2020
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[TS23501] "3GPP TS23.501", 2019,
<https://portal.3gpp.org/desktopmodules/Specifications/Spe
cificationDetails.aspx?specificationId=3144>.
Authors' Addresses
Jie Dong
Huawei
Email: jie.dong@huawei.com
Zhenbin Li
Huawei
Email: lizhenbin@huawei.com
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Dong, et al. Expires August 10, 2020 [Page 13]