Segment Routing for Enhanced VPN Service
draft-dong-spring-sr-for-enhanced-vpn-00

Network Working Group                                            J. Dong
Internet-Draft                                                 S. Bryant
Intended status: Standards Track                     Huawei Technologies
Expires: September 6, 2018                                         Z. Li
                                                            China Mobile
                                                             T. Miyasaka
                                                        KDDI Corporation
                                                           March 5, 2018

                Segment Routing for Enhanced VPN Service
                draft-dong-spring-sr-for-enhanced-vpn-00

Abstract

   Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it
   to support the needs of new applications, particularly applications
   that are associated with 5G services.  These applications require
   better isolation and have more stringent performance requirements
   than can be provided with overlay VPNs.  The characteristics of an
   enhanced VPN as perceived by its tenant needs to be comparable to
   those of a dedicated private network.  This requires tight
   integration between the overlay VPN and the underlay network
   resources in a scalable manner.  An enhanced VPN may form the
   underpin of 5G network slicing, but will also be of use in its own
   right.  This document describes the use of segment routing based
   mechanisms to provide the enhanced VPN service with dedicated
   underlay network resources.

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

Dong, et al.            Expires September 6, 2018               [Page 1]
Internet-Draft                 SR for VPN+                    March 2018

   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 September 6, 2018.

Copyright Notice

   Copyright (c) 2018 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.  Segment Routing with Resource Reservation . . . . . . . . . .   3
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Topology and Resource Computation . . . . . . . . . . . .   5
     3.2.  Network Resource and SID Allocation . . . . . . . . . . .   5
     3.3.  Construction of Isolated Virtual Networks . . . . . . . .   5
     3.4.  VPN to Virtual Network Mapping  . . . . . . . . . . . . .   5
   4.  Benefits of SR based Mechanism  . . . . . . . . . . . . . . .   6
     4.1.  MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Classic SR  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  SR with Resource Reservation  . . . . . . . . . . . . . .   7
   5.  Service Assurance . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Driven largely by needs arising from the 5G mobile network design,
   the concept of network slicing has gained traction.  There is a need
   to create a VPN with enhanced characteristics.  Specifically there is

Dong, et al.            Expires September 6, 2018               [Page 2]
Internet-Draft                 SR for VPN+                    March 2018

   a need for a transport network supporting a set of virtual networks
   each of which provides the client with dedicated (private) network
   resources drawn from a shared pool.  The tenant of such a network can
   require a degree of isolation and performance that previously could
   only be satisfied by dedicated networks.  Additionally the tenant may
   ask for some level of control of their virtual network e.g. to
   customize the service paths in the network slice.

   The enhanced VPN service (VPN+) as specified in
   [I-D.bryant-rtgwg-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.  An
   enhanced VPN may form the underpin of 5G network slicing, but will
   also be of use in its own right.  Although VPNs can be associated
   with dedicated RSVP-TE [RFC3209] LSPs to provide some guarantee to
   service performance, such end-to-end per-flow based resource
   reservation for each VPN has well-known scalability issues and has
   not been the choice in most IP/MPLS networks.

   Segment Routing (SR) [I-D.ietf-spring-segment-routing] specifies a
   mechanism to steer packet through an ordered list of segments.  It
   can achieve explicit source routing without introducing per-flow
   state into the network.  However, currently SR does not have the
   capability of resource reservation, it relies on the DiffServ QoS
   model to provide coarse-grained service differentiation in the
   network.  While this may be sufficient for some traditional services,
   it cannot meet the requirement of the emerging services.

   This document describes the use of segment routing based mechanisms
   to provide the enhanced VPN service with dedicated underlay network
   resources.

2.  Segment Routing with Resource Reservation

   In segment routing, several types of segments are defined to
   represent either topological elements or service instructions.  Node
   segment and adjacency segment are two major types of topological
   segments.  Some other segments may be associated with specific
   service functions for service chaining purpose.  However, currently
   the segments are not associated with network resources for the QoS
   purpose.

   In order to provide the enhanced VPN for the emerging applications
   which require guaranteed performance and isolation from other service
   in the network, the overlay VPN needs to been deeply integrated with
   underlay network.  This requires that some dedicated network
   resources need to be allocated exclusively for each enhanced VPN.
   When segment routing is used in the network, it is necessary to

Dong, et al.            Expires September 6, 2018               [Page 3]
Internet-Draft                 SR for VPN+                    March 2018

   introduce resource reservation into segment routing to meet the
   enhanced VPN requirements.

   Following the segment routing paradigm, on each network segment,
   dedicated network resources are reserved for a particular enhanced
   VPN.  This avoids introducing per-flow state into the network.
   Specifically, this per-segment resource reservation is achieved by
   associating the adjacency segments and node segments with resources
   reserved on the corresponding links and nodes.  For example, multiple
   adjacency segment identifiers (Adj-SIDs) can be allocated for one
   link, each of which is associated with a set of resource reserved on
   this link for a particular enhanced VPN, such as link bandwidth,
   queues, etc.  For one particular node, multiple node-SIDs can be
   allocated for one node, each of which is associated with a set of
   resource reserved on this node for a particular enhanced VPN.  Note
   that when node-SID is used to build a loose SR path for a particular
   enhanced VPN, Penultimate Hop Popping (PHP) MUST be disabled, so that
   every node could use the node-SID to identify the enhanced VPN and
   the corresponding network resources.

   According to the requirement from a particular customer for an
   enhanced VPN service, the underlay network sub-topology used to
   support this enhanced VPN is determined.  In this sub-topology, the
   network resources required on each network element are also
   determined.  Network resources are reserved for this enhanced VPN
   customer in a per-segment manner, and are represented by dedicated
   node and adjacency SIDs.  All the node and adjacency SIDs allocated
   for this enhanced VPN constitute a virtual SR network, which is used
   as the underlay of the enhanced VPN service.  The extensions to IGP
   protocol to support the segment routing based resource reservation
   for enhanced VPN is specified in another document.

3.  Procedures

   This section describes the detailed procedures of provisioning an
   enhanced VPN service using segment routing based resource reservation
   for the enhanced VPN.

   Assume that customer A requests an enhanced VPN service from the
   network operator.  The fundamental requirement is that customer A's
   traffic does not experience interference from other traffic in the
   network, such as traffic in other VPNs, or the default traffic in the
   network.  The detailed requirements can be described with following
   characteristics:

   o  Service topology

   o  Service bandwidth

Dong, et al.            Expires September 6, 2018               [Page 4]
Internet-Draft                 SR for VPN+                    March 2018

   o  Reliability

   o  Latency, jitter, etc.

3.1.  Topology and Resource Computation

   It is assumed that a centralized network controller is responsible
   for the provisioning of enhanced VPNs.  The controller needs to
   collect the network connectivity, resources and other relevant
   network state information of the underlay network.  This usually can
   be done using either the IGP [RFC5305] [RFC3630] or BGP-LS [RFC7752].

   Based on the network information collected from the elements in the
   underlay, the controller can compute the best way to meet the
   requirements of a new tenant whilst maintaining the needs of the
   existing tenants that are using the same network.  The output of the
   computation is a sub-topology of the underlay network, along with the
   network resources needed on each network element (e.g. links and
   nodes) in the sub-topology.  This is the underlay network which can
   fully meet the customer's service requirement.

3.2.  Network Resource and SID Allocation

   According to the computation output, the network controller sends
   requests to all the network devices involved in the sub-topology to
   allocate the network resources required for this enhanced VPN.  This
   can be done with either PCEP [RFC5440] or Netconf [RFC6241] with
   necessary extensions.  The network resources are allocated in a per-
   segment manner.  Dedicated segment identifiers, e.g. node-SIDs and
   adj-SIDs are allocated for each network segment along with the
   network resources reserved for this enhanced VPN.

3.3.  Construction of Isolated Virtual Networks

   A virtual SR network can then be constructed using the node-SIDs and
   adj-SIDs allocated for this enhanced VPN.  Unlike classical segment
   routing in which network resources are shared between different
   services and customers, the proposed mechanism provides a virtual
   network with dedicated resource reserved in the underlay, so that it
   can always meet the service requirement of the customer and provide
   the required isolation from other customers in the same network.

3.4.  VPN to Virtual Network Mapping

   The services of an enhanced VPN customer would be provisioned using
   the customized virtual SR networks as the underlay.  This ensures
   that services of different enhanced VPNs will only use the network
   resources reserved for them and not interfere with each other.  For

Dong, et al.            Expires September 6, 2018               [Page 5]
Internet-Draft                 SR for VPN+                    March 2018

   each enhanced VPN customer, the service paths can be customized for
   different services within the virtual SR network, and the reserved
   network resources can be shared by different services of the same
   enhanced VPN customer.

4.  Benefits of SR based Mechanism

   The SR based mechanism described in this document provides three
   things:

   o  More flexibility and better scaling.

   o  Lower state maintenance overhead and fewer protocols types in the
      code than RSVP-TE.

   o  Better isolation and performance than Classic SR due to allocation
      of resources in the underlay to specific services.

   This SR based mechanism can provide the required isolation between
   different enhanced VPNs, without introducing per-flow state into the
   network.  For each enhanced VPN, the resource reservation is done in
   a per-segment manner, which aligns with the segment routing paradigm.
   This provides better scalability compared to RSVP-TE based per-flow
   resource reservation.

   In addition to isolation, the SR based mechanism also allows resource
   sharing between different services of the same enhanced VPN customer.
   This gives the customer more flexibility and control in service
   planning and provisioning in their dedicated virtual networks, the
   experience is similar to using a dedicated private network.  The
   performance of critical services in a particular enhanced VPN can be
   further ensured using the mechanisms defined in [DetNet].

   The detailed comparison with other candidates are given in the
   following sub-sections.

4.1.  MPLS-TP

   MPLS-TP could be enhanced to include the allocation of specific
   resources along the path to a specific LSP.  This would require that
   the SDN system set up and maintain every resource at every path for
   every tenant, and map this to the LSP and hence the unique LSP label
   at every hop.  Whilst this would be a way to produce a proof of
   concept for network slicing of an MPLS underlay, delegation would be
   difficult, resulting in a high overhead and high touch system.  This
   leads to scaling concerns.  The number of labels needed at any node
   would be the total number of services passing through that node.

Dong, et al.            Expires September 6, 2018               [Page 6]
Internet-Draft                 SR for VPN+                    March 2018

   Experience with early pseudowire designs shows that this can lead to
   scaling issues.

4.2.  RSVP-TE

   RSVP-TE would have the same scaling concern as MPLS-TP in terms of
   the number of LSPs that need to be maintained being equal to the
   number of service passing through any given node.  Additionally it
   would have the two RSVP disadvantages that basic SR seeks to address:

   o  The use of additional protocol (RSVP) in addition to the routing
      protocol used to discover the topology and the network resources.

   o  The overhead of the soft-state maintenance associated with RSVP.
      The impact of this overhead would be exacerbated by the increased
      number of end to end paths requiring state maintenance.

4.3.  Classic SR

   Classic SR minimizes the number of control protocols compared to RSVP
   to just the routing protocol.  It also attempts to minimize the core
   state by pushing state into the packet.  It is not entirely
   successful with this in that in practise binding SIDs are required to
   overcome limitations in the ability of some nodes to push large label
   stacks.  Binding SIDs increase network state at strategic places in
   order to overcome the imposition SID size limit.

   In addition, classic SR does not have any resource reservation system
   below the level of link, and none at node level, which restricts the
   extent to which some particular tenant traffic can be isolated from
   other traffic in the network.

4.4.  SR with Resource Reservation

   The approach described in this document seeks to achieve a compromise
   between the state limitations of classic TE system and the lack of
   resource reservation in classic SR.

   Specifically, by segmenting the path and allocating resources to
   virtual network topologies, the operator can choose the granularity
   of resource to path binding within a topology.  In network segments
   where resource is scarce such that the service requirement cannot be
   delivered, the SR approach is able to allocate specific resources to
   a particular service.  By contrast, in other parts of the network
   where resource is plentiful, the resource may be shared by a number
   of services.  The decision to do this is in the hands of the operator
   or the tenant.  Because of the segmented nature of the path, resource
   aggregation is possible in a way that is not possible with RSVP and

Dong, et al.            Expires September 6, 2018               [Page 7]
Internet-Draft                 SR for VPN+                    March 2018

   MPLS-TP due to the use of dedicated label to identify each end-to-end
   path.

5.  Service Assurance

   In order to provide service assurance it is necessary to instrument
   the network at multiple levels.  The network operator needs to
   ascertain that the underlay is operating correctly.  A tenant needs
   to ascertain that their services are correctly operating.  In
   principle these can use existing techniques.  These are well known
   problems and solutions either exist or are in development to address
   them.

   However new work is needed to instrument the virtual network slices
   that are created.  Such instrumentation needs to operate without
   causing disruption to other services using the network.  Given the
   sensitivity of some applications care needs to be taken to ensure
   that the instrumentation itself does not cause disruption either to
   the service being instrumented or to another service.

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

   The normal security considerations of VPNs are applicable and it is
   assumed that industry best practise is applied to an enhanced VPN.

   The security considerations of segment routing are applicable and it
   is assumed that these are applied to an enhanced VPN that uses SR.

   Some applications of enhanced VPNs are sensitive to packet latency,
   and the enhanced VPNs provisioned to carry their traffic have latency
   SLAs.  By disrupting the latency of such traffic an attack can be
   directly targeted at the customer application, or can be targeted at
   the network operator by causing them to violate their service level
   agreement and thus causing them commercial consequences.  Dynamic
   attacks of this sort are not something that networks have
   traditionally guarded against, and networking techniques need to be
   developed to defend against this type of attack.  By rigorously
   policing ingress traffic and carefully provisioning the resources
   provided to critical services this type of attack can be prevented.
   However case needs to be taken where it is necessary to provide

Dong, et al.            Expires September 6, 2018               [Page 8]
Internet-Draft                 SR for VPN+                    March 2018

   shared resources, and when the network needs to be reconfigured as
   part of ongoing maintenance or in response to a failure.

   It is important that steps are taken to ensure that details of the
   underlay are not exposed to third parties to minimise the possibility
   that an exploit be developed as a result of exploiting a shared
   resource.

8.  Acknowledgements

   The authors would like to thank Mach Chen, Zhenbin Li for the
   discussion and suggestions to this document.

9.  References

9.1.  Normative References

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [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

   [DetNet]   "DetNet WG", 2016,
              <https://datatracker.ietf.org/wg/detnet>.

   [I-D.bryant-rtgwg-enhanced-vpn]
              Bryant, S. and J. Dong, "Enhanced Virtual Private Networks
              (VPN+)", draft-bryant-rtgwg-enhanced-vpn-01 (work in
              progress), October 2017.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

Dong, et al.            Expires September 6, 2018               [Page 9]
Internet-Draft                 SR for VPN+                    March 2018

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

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

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

Authors' Addresses

   Jie Dong
   Huawei Technologies

   Email: jie.dong@huawei.com

   Stewart Bryant
   Huawei Technologies

   Email: stewart.bryant@gmail.com

   Zhenqiang Li
   China Mobile

   Email: li_zhenqiang@hotmail.com

   Takuya Miyasaka
   KDDI Corporation

   Email: ta-miyasaka@kddi.com

Dong, et al.            Expires September 6, 2018              [Page 10]