Routing Area Working Group S. Bryant Internet-Draft J. Dong Intended status: Informational Huawei Expires: January 4, 2018 July 3, 2017 Enhanced Virtual Private Networks (VPN+) draft-bryant-rtgwg-enhanced-vpn-00 Abstract This draft describes a number of enhancements that need to be made to virtual private networks (VPNs) to support the needs of new applications, particularly applications that are associated with 5G services. A network enhanced with these properties may form the underpin of network slicing, but will also be of use in its own right. 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 http://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 January 4, 2018. Copyright Notice Copyright (c) 2017 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 (http://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 Bryant & Dong Expires January 4, 2018 [Page 1] Internet-Draft VPN+ July 2017 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. Overview of the Requirements . . . . . . . . . . . . . . . . 3 3.1. Isolation between VPNs . . . . . . . . . . . . . . . . . 3 3.2. Guaranteed Performance . . . . . . . . . . . . . . . . . 4 3.3. Customized Control Plane . . . . . . . . . . . . . . . . 5 4. Components of VPN+ . . . . . . . . . . . . . . . . . . . . . 5 4.1. Use of Segment Routing Constructs . . . . . . . . . . . . 5 4.2. Latency Support . . . . . . . . . . . . . . . . . . . . . 6 4.3. Support of an IP underlay . . . . . . . . . . . . . . . . 7 4.4. Application Specific Network Types . . . . . . . . . . . 7 4.5. A Hybrid Control Plane . . . . . . . . . . . . . . . . . 7 5. Applicability to Network Slicing . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Virtual networks, often referred to as virtual private networks (VPNs) have served the industry well as a means of providing different groups of users with logically isolated access to a common network. The common or base network that is used to provide the VPNs is often referred to as the underlay, and the VPN is often called an overlay. Driven largely by needs surfacing from 5G, the concept of network slicing has gained traction. The network slicing problem is described in [I-D.galis-netslices-revised-problem-statement] and the network slicing architecture is described in [I-D.geng-netslices-architecture]. A study of the new work needed in the IETF to address the gap between the requirements and existing IETF protocols is discussed in [I-D.qiang-netslices-gap-analysis]. Setting aside the details of the life-cycle management of a network slice instance (NSI), the underpinning technology in the transport network is a type of virtual network which provides the client with dedicated (private) networking, computing and storage resources drawn from a shared pool. The tenant of the NSI can require a degree of isolation and performance that previously could only be satisfied by Bryant & Dong Expires January 4, 2018 [Page 2] Internet-Draft VPN+ July 2017 dedicated networks. Additionally the tenant may ask for some level of control of the network slice, e.g. to customize the service paths in the network slice. These new network layer properties are of interest as part of a network slicing solution, as a precursor to the full roll-out of network slicing, and in their own right. These properties cannot be met with pure overlay networks, as they require tighter coordination and integration between the underlay and the overlay network. This document introduces a new network service called enhanced VPN (VPN+). VPN+ refers to a virtual network which has dedicated network resources allocated from the underlay network, and can achieve a greater isolation and lower latency than traditional VPN. In this draft we identify the new and modified components that need to be provided in the network layer and their associated control and monitoring of an enhanced VPN. Specifically we are concerned with the technology needed to be provided by the enhanced VPN underlay, the enhanced VPN data-plane and the necessary protocols in both the underlay and the overlay of enhanced VPN. It is likely that these enhanced VPNs will be used to create network slices with different isolation requirements. Different service types, e.g. emergency services, enterprise service and broadband services etc. may be partitioned into different "hard" slices according to the isolation requirement. These "hard" slices might then be used to carry one or multiple VPNs. VPNs on such a hard slice may be only partially isolated (so called "soft" slices). 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 [RFC2119]. 3. Overview of the Requirements In this section we provide an overview of the requirements of an enhanced VPN. 3.1. Isolation between VPNs The requirement is to provide both hard and soft isolation between the tenants/applications using one enhanced VPN and the tenants/ applications using another enhanced VPN. Hard isolation is needed so that applications with exacting requirements can function correctly despite a flash demand being created on another VPN competing for the Bryant & Dong Expires January 4, 2018 [Page 3] Internet-Draft VPN+ July 2017 underlying resources. An example might be a network supporting both emergency services and public broadband multi-media services. During a major incident the VPNs supporting these services would both be expected to experience high data volumes, and it is important that both make progress in the transmission of their data. In these circumstances the VPNs would require an appropriate degree of isolation to be able to continue to operate acceptably. We introduce the terms hard and soft isolation to cover cases such as the above. A VPN has soft isolation if the traffic of one VPN cannot be inspected by the traffic of another. An IP and MPLS VPNs are examples of soft isolated VPNs because the network delivers the traffic only to the required VPN endpoints. However the traffic from one or more VPNs and regular network traffic may congest the network resulting in delays for other VPNs operating normally. The ability for a VPN to be sheltered from this effect is called hard isolation, and this property is required by some critical applications. A network slice that experiences only soft isolation is said to be soft sliced, and a network slice that has hard isolation is said to be hard sliced. Although these isolation requirements are triggered by the needs of network slicing in support of 5G networks, they have general utility. It is of course possible to achieve high degrees of isolation in the optical layer. However this is done at the cost of allocating resources on a long term basis and end-to-end basis. Such an arrangement means that the full cost of the resources must be borne by the service that is allocated the resources. On the other hand, isolation at the packet layer allows the resources to be shared amongst many services and only dedicated to a service on a temporary basis. This allows greater statistical multiplexing of network resources and amortizes the cost over many services, leading to better economy. However, the degree of isolation required by network slicing cannot easily be met with MPLS-TE packet LSPs. Thus some trade-off between the two approaches needs to be considered to provide the required isolation between virtual networks while still allows reasonable sharing inside each VPN. 3.2. Guaranteed Performance There are several aspects to guaranteed performance, guaranteed maximum packet loss, guaranteed maximum delay and guaranteed delay variation. Guaranteed maximum packet loss is a common parameter, and is usually addressed by setting the packet priorities, queue size and discard Bryant & Dong Expires January 4, 2018 [Page 4] Internet-Draft VPN+ July 2017 policy. However this becomes more difficult when the requirement combine with the latency requirement. Guaranteed maximum latency is required in a number of applications particularly real-time control applications and some types of virtual reality applications. The work of the IETF Deterministic Networking (DetNet) Working Group is relevant, however the scope needs to be extended to methods of enhancing the IP/MPLS underlay to better support the delay guarantee, and to integrate these enhancements with the overall service provision. Guaranteed maximum delay variation is a service that may also be needed. Time transfer is one example of a service that needs this, although the fungible nature of time means that it might be delivered by the underlay and not provided through different virtual networks. The need for guaranteed maximum delay variation as a general requirement is for further study. A possible mechanism to address these guarantees is to provide enhancement to the underlay network through technologies such as Flexible Ethernet [FLEXE]. 3.3. Customized Control Plane In some cases it is desirable that an enhanced VPN has a custom control plane, so that the tenant of the enhanced VPN can have some control to the resources and functions partitioned for this VPN. Further detail on this requirement will be provided in a future version of the draft. 4. Components of VPN+ 4.1. Use of Segment Routing Constructs Clearly we can use traditional constructs to create a VPN, but there are advantages to the use of Segment Routing (SR) in the creation of virtual networks with enhanced properties. Segment Routing [I-D.ietf-spring-segment-routing] is a method that prepends instructions to packets at entry and possibly at various points as it passes though the network. These instructions allow packets to be routed on paths other than the shortest path for various traffic engineering reasons. These paths can be strict or loose paths, depending on the compactness required of the instruction list and the degree of autonomy granted to the network (for example to support ECMP). With current segment routing, the instructions are used to specify the nodes and links to be traversed. However, in Bryant & Dong Expires January 4, 2018 [Page 5] Internet-Draft VPN+ July 2017 order to achieve the required isolation between different services, new instructions can be created which can be prepended to a packet to steer it through specific dedicated network resources and functions, e.g. queues, processors, links, services etc. New instructions can also be created to specify not only which resources are traversed, but in some cases how they are traversed. For example, it may be possible to specify not only the queue to be used but the policy to be applied when enqueuing and dequeuing. With SR, a path is dynamically created through a set of resources by simply specifying the Segment IDs (SIDs), i.e. instructions rooted at a particular point in the network. Thus if a path is to be provisioned from some ingress point A to some egress point B in the underlay, A is provided with the A..B SID list and instructions on how to identify the packets to which the SID list is to be prepended. The SIDs may be used to specify both network paths, or service functions as described in [I-D.xu-mpls-unified-source-routing-instruction]. Dynamic creation of a VPN path using SR requires less state maintenance in the network core at the expense of larger VPN headers on the packet. The scaling properties will reduce roughly from a function of (N/2)^2 to a function of N, where N is the VPN path length in intervention points (hops plus network functions). Reducing the state in the network is important to VPN+, as VPN+ requires the overlay to be more closely integrated with the underlay than with traditional VPNs. This tighter coupling would normally mean that significant state needed to be created and maintained in the core. However, a segment routed approach allows much of this state to be spread amongst the network ingress nodes, and transiently carried in the packets as SIDs. 4.2. Latency Support The IETF has ongoing work on support for a latency ceiling [I-D.ietf-detnet-architecture]. The provision of a latency ceiling is a requirement of the application seeking the use of enhanced virtual networks. The current design of DetNet assumes the design of the underlay network is unchanged. In this section we look at some changes that could be used to assist in achieving low latency ceiling across the wide area. Traditionally a traffic engineered path operates with a granularity of a link with hints about priority provided through the use of the traffic class field in the header. However to achieve the latency and isolation characteristics that are sought, steering packets through specific queues may be required. This allows a much finer Bryant & Dong Expires January 4, 2018 [Page 6] Internet-Draft VPN+ July 2017 control of which services wait for which, and a much finer granularity of queue management policy. This may be introduced into traditional path construction techniques such as RSVP-TE and MPLS-TP, or it may be introduced by specifying the queue in an SR instruction list. 4.3. Support of an IP underlay Where an underlay needs to be provided by IP, a number of options present themselves. We could allocate an IP address to that path and construct a path through the network for that IP address. The path could be laid in with RSVP signaling or through SDN controller. This path could have all of the required properties including specifying resources to use and functions to visit. Although this construct has been considered many time over the years, such a mechanism, at least to the author's knowledge, has not found favor in deployment. There are two ways that segment routing might be used to adapt the system described above to an IP context. One is to use the method described in [I-D.ietf-6man-segment-routing-header] in which each segment (instruction) is encoded as a normal IPv6 address. An alternative is to use the more compact representation considered in [I-D.xu-mpls-unified-source-routing-instruction] and [I-D.bryant-mpls-unified-ip-sr]. 4.4. Application Specific Network Types Although the transport service that underpins the extended VPN is likely MPLS/IP based, it needs to be able to carry application specific non-MPLS/IP traffic. This can be accommodated through the use of pseudowires (PWs). 4.5. A Hybrid Control Plane It is expected that VPN+ would be based on a hybrid control mechanism, which takes advantage of the logically centralized controller for on-demand provisioning and global optimization, whilst still relies on distributed control plane to provide scalability, high reliability, fast reaction, automatic failure recovery etc. Extension and optimization to the distributed control plane is needed to support the enhanced properties of VPN+. [I-D.king-teas-applicability-actn-slicing] describes the use of ACTN to network slicing. This approach may be considered as part of the centralized control plane of VPN+ in some applications. Bryant & Dong Expires January 4, 2018 [Page 7] Internet-Draft VPN+ July 2017 5. Applicability to Network Slicing In [I-D.geng-netslices-architecture] a network slice is defined to be: "A managed group of subsets of resources, network functions / network virtual functions at the data, control, management/orchestration planes and services at a given time. Network slice is programmable and has the ability to expose its capabilities. The behaviour of the network slice realized via network slice instance(s)." A network slice instance (NSI) is then defined as: "An activated network slice. It is created based on network template. A set of managed run-time network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the service instance(s). It provides the network characteristics that are required by a service instance. A network slice instance may also be shared across multiple service instances provided by the network operator. The network slice instance may be composed by none, one or more sub- network instances, which may be shared by another network slice instance." A network slice can thus be thought of as a customized set of logical network and compute resources required by the service the slice is supporting. These resources support both virtual services in the data path and operation of the slice, for example by providing routing services. The customization includes the connectivity, performance, and isolation characteristics. These characteristics can be provided by the enhanced VPN described in this draft. 6. Security Considerations All types of virtual network require special consideration to be given to the isolation between the tenants. However in an enhanced virtual network service hard isolation needs to be considered. If a service requires a specific latency then it can be damaged by simply delaying the packet through the activities of another tenant. In a network with virtual functions, depriving a function used by another tenant of compute resources can be just as damaging as delaying transmission of a packet in the network. Bryant & Dong Expires January 4, 2018 [Page 8] Internet-Draft VPN+ July 2017 7. IANA Considerations There are no requested IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, . [I-D.bryant-mpls-unified-ip-sr] Bryant, S., Xu, X., Chen, M., Farrel, A., and J. Drake, "A Unified Approach to IP Segment Routing", draft-bryant- mpls-unified-ip-sr-00 (work in progress), June 2017. [I-D.galis-netslices-revised-problem-statement] Galis, A., "Network Slicing - Revised Problem Statement", draft-galis-netslices-revised-problem-statement-00 (work in progress), June 2017. [I-D.geng-netslices-architecture] 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing Architecture", draft-geng-netslices-architecture-01 (work in progress), June 2017. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-header-06 (work in progress), March 2017. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-02 (work in progress), June 2017. Bryant & Dong Expires January 4, 2018 [Page 9] Internet-Draft VPN+ July 2017 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-12 (work in progress), June 2017. [I-D.king-teas-applicability-actn-slicing] King, D., "Applicability of Abstraction and Control of TE Networks (ACTN) to Network Slicing", draft-king-teas- applicability-actn-slicing-00 (work in progress), June 2017. [I-D.qiang-netslices-gap-analysis] Qiang, L., Martinez-Julia, P., 67, 4., Dong, J., kiran.makhijani@huawei.com, k., Galis, A., Hares, S., and S. Slawomir, "Gap Analysis for Network Slicing", draft- qiang-netslices-gap-analysis-00 (work in progress), June 2017. [I-D.xu-mpls-unified-source-routing-instruction] Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and S. Ma, "Unified Source Routing Instruction using MPLS Label Stack", draft-xu-mpls-unified-source-routing- instruction-02 (work in progress), June 2017. Authors' Addresses Stewart Bryant Huawei Email: stewart.bryant@gmail.com Jie Dong Huawei Email: jie.dong@huawei.com Bryant & Dong Expires January 4, 2018 [Page 10]