[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/