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, . 9.2. Informative References [DetNet] "DetNet WG", 2016, . [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, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . 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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [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, . 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]