idnits 2.17.1 draft-bryant-rtgwg-enhanced-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-bryant-mpls-unified-ip-sr-00 == Outdated reference: A later version (-01) exists of draft-galis-netslices-revised-problem-statement-00 == Outdated reference: A later version (-02) exists of draft-geng-netslices-architecture-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-00 == Outdated reference: A later version (-01) exists of draft-qiang-netslices-gap-analysis-00 == Outdated reference: A later version (-04) exists of draft-xu-mpls-unified-source-routing-instruction-02 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Bryant 3 Internet-Draft J. Dong 4 Intended status: Informational Huawei 5 Expires: January 4, 2018 July 3, 2017 7 Enhanced Virtual Private Networks (VPN+) 8 draft-bryant-rtgwg-enhanced-vpn-00 10 Abstract 12 This draft describes a number of enhancements that need to be made to 13 virtual private networks (VPNs) to support the needs of new 14 applications, particularly applications that are associated with 5G 15 services. A network enhanced with these properties may form the 16 underpin of network slicing, but will also be of use in its own 17 right. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 4, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of the Requirements . . . . . . . . . . . . . . . . 3 56 3.1. Isolation between VPNs . . . . . . . . . . . . . . . . . 3 57 3.2. Guaranteed Performance . . . . . . . . . . . . . . . . . 4 58 3.3. Customized Control Plane . . . . . . . . . . . . . . . . 5 59 4. Components of VPN+ . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Use of Segment Routing Constructs . . . . . . . . . . . . 5 61 4.2. Latency Support . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Support of an IP underlay . . . . . . . . . . . . . . . . 7 63 4.4. Application Specific Network Types . . . . . . . . . . . 7 64 4.5. A Hybrid Control Plane . . . . . . . . . . . . . . . . . 7 65 5. Applicability to Network Slicing . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Virtual networks, often referred to as virtual private networks 76 (VPNs) have served the industry well as a means of providing 77 different groups of users with logically isolated access to a common 78 network. The common or base network that is used to provide the VPNs 79 is often referred to as the underlay, and the VPN is often called an 80 overlay. 82 Driven largely by needs surfacing from 5G, the concept of network 83 slicing has gained traction. The network slicing problem is 84 described in [I-D.galis-netslices-revised-problem-statement] and the 85 network slicing architecture is described in 86 [I-D.geng-netslices-architecture]. A study of the new work needed in 87 the IETF to address the gap between the requirements and existing 88 IETF protocols is discussed in [I-D.qiang-netslices-gap-analysis]. 90 Setting aside the details of the life-cycle management of a network 91 slice instance (NSI), the underpinning technology in the transport 92 network is a type of virtual network which provides the client with 93 dedicated (private) networking, computing and storage resources drawn 94 from a shared pool. The tenant of the NSI can require a degree of 95 isolation and performance that previously could only be satisfied by 96 dedicated networks. Additionally the tenant may ask for some level 97 of control of the network slice, e.g. to customize the service paths 98 in the network slice. 100 These new network layer properties are of interest as part of a 101 network slicing solution, as a precursor to the full roll-out of 102 network slicing, and in their own right. These properties cannot be 103 met with pure overlay networks, as they require tighter coordination 104 and integration between the underlay and the overlay network. This 105 document introduces a new network service called enhanced VPN (VPN+). 106 VPN+ refers to a virtual network which has dedicated network 107 resources allocated from the underlay network, and can achieve a 108 greater isolation and lower latency than traditional VPN. 110 In this draft we identify the new and modified components that need 111 to be provided in the network layer and their associated control and 112 monitoring of an enhanced VPN. Specifically we are concerned with 113 the technology needed to be provided by the enhanced VPN underlay, 114 the enhanced VPN data-plane and the necessary protocols in both the 115 underlay and the overlay of enhanced VPN. It is likely that these 116 enhanced VPNs will be used to create network slices with different 117 isolation requirements. Different service types, e.g. emergency 118 services, enterprise service and broadband services etc. may be 119 partitioned into different "hard" slices according to the isolation 120 requirement. These "hard" slices might then be used to carry one or 121 multiple VPNs. VPNs on such a hard slice may be only partially 122 isolated (so called "soft" slices). 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 3. Overview of the Requirements 133 In this section we provide an overview of the requirements of an 134 enhanced VPN. 136 3.1. Isolation between VPNs 138 The requirement is to provide both hard and soft isolation between 139 the tenants/applications using one enhanced VPN and the tenants/ 140 applications using another enhanced VPN. Hard isolation is needed so 141 that applications with exacting requirements can function correctly 142 despite a flash demand being created on another VPN competing for the 143 underlying resources. An example might be a network supporting both 144 emergency services and public broadband multi-media services. 146 During a major incident the VPNs supporting these services would both 147 be expected to experience high data volumes, and it is important that 148 both make progress in the transmission of their data. In these 149 circumstances the VPNs would require an appropriate degree of 150 isolation to be able to continue to operate acceptably. 152 We introduce the terms hard and soft isolation to cover cases such as 153 the above. A VPN has soft isolation if the traffic of one VPN cannot 154 be inspected by the traffic of another. An IP and MPLS VPNs are 155 examples of soft isolated VPNs because the network delivers the 156 traffic only to the required VPN endpoints. However the traffic from 157 one or more VPNs and regular network traffic may congest the network 158 resulting in delays for other VPNs operating normally. The ability 159 for a VPN to be sheltered from this effect is called hard isolation, 160 and this property is required by some critical applications. A 161 network slice that experiences only soft isolation is said to be soft 162 sliced, and a network slice that has hard isolation is said to be 163 hard sliced. 165 Although these isolation requirements are triggered by the needs of 166 network slicing in support of 5G networks, they have general utility. 168 It is of course possible to achieve high degrees of isolation in the 169 optical layer. However this is done at the cost of allocating 170 resources on a long term basis and end-to-end basis. Such an 171 arrangement means that the full cost of the resources must be borne 172 by the service that is allocated the resources. On the other hand, 173 isolation at the packet layer allows the resources to be shared 174 amongst many services and only dedicated to a service on a temporary 175 basis. This allows greater statistical multiplexing of network 176 resources and amortizes the cost over many services, leading to 177 better economy. However, the degree of isolation required by network 178 slicing cannot easily be met with MPLS-TE packet LSPs. Thus some 179 trade-off between the two approaches needs to be considered to 180 provide the required isolation between virtual networks while still 181 allows reasonable sharing inside each VPN. 183 3.2. Guaranteed Performance 185 There are several aspects to guaranteed performance, guaranteed 186 maximum packet loss, guaranteed maximum delay and guaranteed delay 187 variation. 189 Guaranteed maximum packet loss is a common parameter, and is usually 190 addressed by setting the packet priorities, queue size and discard 191 policy. However this becomes more difficult when the requirement 192 combine with the latency requirement. 194 Guaranteed maximum latency is required in a number of applications 195 particularly real-time control applications and some types of virtual 196 reality applications. The work of the IETF Deterministic Networking 197 (DetNet) Working Group is relevant, however the scope needs to be 198 extended to methods of enhancing the IP/MPLS underlay to better 199 support the delay guarantee, and to integrate these enhancements with 200 the overall service provision. 202 Guaranteed maximum delay variation is a service that may also be 203 needed. Time transfer is one example of a service that needs this, 204 although the fungible nature of time means that it might be delivered 205 by the underlay and not provided through different virtual networks. 206 The need for guaranteed maximum delay variation as a general 207 requirement is for further study. 209 A possible mechanism to address these guarantees is to provide 210 enhancement to the underlay network through technologies such as 211 Flexible Ethernet [FLEXE]. 213 3.3. Customized Control Plane 215 In some cases it is desirable that an enhanced VPN has a custom 216 control plane, so that the tenant of the enhanced VPN can have some 217 control to the resources and functions partitioned for this VPN. 219 Further detail on this requirement will be provided in a future 220 version of the draft. 222 4. Components of VPN+ 224 4.1. Use of Segment Routing Constructs 226 Clearly we can use traditional constructs to create a VPN, but there 227 are advantages to the use of Segment Routing (SR) in the creation of 228 virtual networks with enhanced properties. 230 Segment Routing [I-D.ietf-spring-segment-routing] is a method that 231 prepends instructions to packets at entry and possibly at various 232 points as it passes though the network. These instructions allow 233 packets to be routed on paths other than the shortest path for 234 various traffic engineering reasons. These paths can be strict or 235 loose paths, depending on the compactness required of the instruction 236 list and the degree of autonomy granted to the network (for example 237 to support ECMP). With current segment routing, the instructions are 238 used to specify the nodes and links to be traversed. However, in 239 order to achieve the required isolation between different services, 240 new instructions can be created which can be prepended to a packet to 241 steer it through specific dedicated network resources and functions, 242 e.g. queues, processors, links, services etc. New instructions can 243 also be created to specify not only which resources are traversed, 244 but in some cases how they are traversed. For example, it may be 245 possible to specify not only the queue to be used but the policy to 246 be applied when enqueuing and dequeuing. 248 With SR, a path is dynamically created through a set of resources by 249 simply specifying the Segment IDs (SIDs), i.e. instructions rooted at 250 a particular point in the network. Thus if a path is to be 251 provisioned from some ingress point A to some egress point B in the 252 underlay, A is provided with the A..B SID list and instructions on 253 how to identify the packets to which the SID list is to be prepended. 255 The SIDs may be used to specify both network paths, or service 256 functions as described in 257 [I-D.xu-mpls-unified-source-routing-instruction]. 259 Dynamic creation of a VPN path using SR requires less state 260 maintenance in the network core at the expense of larger VPN headers 261 on the packet. The scaling properties will reduce roughly from a 262 function of (N/2)^2 to a function of N, where N is the VPN path 263 length in intervention points (hops plus network functions). 264 Reducing the state in the network is important to VPN+, as VPN+ 265 requires the overlay to be more closely integrated with the underlay 266 than with traditional VPNs. This tighter coupling would normally 267 mean that significant state needed to be created and maintained in 268 the core. However, a segment routed approach allows much of this 269 state to be spread amongst the network ingress nodes, and transiently 270 carried in the packets as SIDs. 272 4.2. Latency Support 274 The IETF has ongoing work on support for a latency ceiling 275 [I-D.ietf-detnet-architecture]. The provision of a latency ceiling 276 is a requirement of the application seeking the use of enhanced 277 virtual networks. The current design of DetNet assumes the design of 278 the underlay network is unchanged. In this section we look at some 279 changes that could be used to assist in achieving low latency ceiling 280 across the wide area. 282 Traditionally a traffic engineered path operates with a granularity 283 of a link with hints about priority provided through the use of the 284 traffic class field in the header. However to achieve the latency 285 and isolation characteristics that are sought, steering packets 286 through specific queues may be required. This allows a much finer 287 control of which services wait for which, and a much finer 288 granularity of queue management policy. 290 This may be introduced into traditional path construction techniques 291 such as RSVP-TE and MPLS-TP, or it may be introduced by specifying 292 the queue in an SR instruction list. 294 4.3. Support of an IP underlay 296 Where an underlay needs to be provided by IP, a number of options 297 present themselves. We could allocate an IP address to that path and 298 construct a path through the network for that IP address. The path 299 could be laid in with RSVP signaling or through SDN controller. This 300 path could have all of the required properties including specifying 301 resources to use and functions to visit. Although this construct has 302 been considered many time over the years, such a mechanism, at least 303 to the author's knowledge, has not found favor in deployment. 305 There are two ways that segment routing might be used to adapt the 306 system described above to an IP context. One is to use the method 307 described in [I-D.ietf-6man-segment-routing-header] in which each 308 segment (instruction) is encoded as a normal IPv6 address. An 309 alternative is to use the more compact representation considered in 310 [I-D.xu-mpls-unified-source-routing-instruction] and 311 [I-D.bryant-mpls-unified-ip-sr]. 313 4.4. Application Specific Network Types 315 Although the transport service that underpins the extended VPN is 316 likely MPLS/IP based, it needs to be able to carry application 317 specific non-MPLS/IP traffic. This can be accommodated through the 318 use of pseudowires (PWs). 320 4.5. A Hybrid Control Plane 322 It is expected that VPN+ would be based on a hybrid control 323 mechanism, which takes advantage of the logically centralized 324 controller for on-demand provisioning and global optimization, whilst 325 still relies on distributed control plane to provide scalability, 326 high reliability, fast reaction, automatic failure recovery etc. 327 Extension and optimization to the distributed control plane is needed 328 to support the enhanced properties of VPN+. 329 [I-D.king-teas-applicability-actn-slicing] describes the use of ACTN 330 to network slicing. This approach may be considered as part of the 331 centralized control plane of VPN+ in some applications. 333 5. Applicability to Network Slicing 335 In [I-D.geng-netslices-architecture] a network slice is defined to 336 be: 338 "A managed group of subsets of resources, network functions / network 339 virtual functions at the data, control, management/orchestration 340 planes and services at a given time. Network slice is programmable 341 and has the ability to expose its capabilities. The behaviour of the 342 network slice realized via network slice instance(s)." 344 A network slice instance (NSI) is then defined as: 346 "An activated network slice. It is created based on network 347 template. 348 A set of managed run-time network functions, and resources to run 349 these network functions, forming a complete instantiated logical 350 network to meet certain network characteristics required by the 351 service instance(s). 352 It provides the network characteristics that are required by a 353 service instance. A network slice instance may also be shared across 354 multiple service instances provided by the network operator. The 355 network slice instance may be composed by none, one or more sub- 356 network instances, which may be shared by another network slice 357 instance." 359 A network slice can thus be thought of as a customized set of logical 360 network and compute resources required by the service the slice is 361 supporting. These resources support both virtual services in the 362 data path and operation of the slice, for example by providing 363 routing services. The customization includes the connectivity, 364 performance, and isolation characteristics. These characteristics 365 can be provided by the enhanced VPN described in this draft. 367 6. Security Considerations 369 All types of virtual network require special consideration to be 370 given to the isolation between the tenants. However in an enhanced 371 virtual network service hard isolation needs to be considered. If a 372 service requires a specific latency then it can be damaged by simply 373 delaying the packet through the activities of another tenant. In a 374 network with virtual functions, depriving a function used by another 375 tenant of compute resources can be just as damaging as delaying 376 transmission of a packet in the network. 378 7. IANA Considerations 380 There are no requested IANA actions. 382 8. References 384 8.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 8.2. Informative References 393 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 394 . 397 [I-D.bryant-mpls-unified-ip-sr] 398 Bryant, S., Xu, X., Chen, M., Farrel, A., and J. Drake, "A 399 Unified Approach to IP Segment Routing", draft-bryant- 400 mpls-unified-ip-sr-00 (work in progress), June 2017. 402 [I-D.galis-netslices-revised-problem-statement] 403 Galis, A., "Network Slicing - Revised Problem Statement", 404 draft-galis-netslices-revised-problem-statement-00 (work 405 in progress), June 2017. 407 [I-D.geng-netslices-architecture] 408 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 409 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 410 Architecture", draft-geng-netslices-architecture-01 (work 411 in progress), June 2017. 413 [I-D.ietf-6man-segment-routing-header] 414 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 415 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 416 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 417 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 418 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 419 segment-routing-header-06 (work in progress), March 2017. 421 [I-D.ietf-detnet-architecture] 422 Finn, N., Thubert, P., Varga, B., and J. Farkas, 423 "Deterministic Networking Architecture", draft-ietf- 424 detnet-architecture-02 (work in progress), June 2017. 426 [I-D.ietf-spring-segment-routing] 427 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 428 and R. Shakir, "Segment Routing Architecture", draft-ietf- 429 spring-segment-routing-12 (work in progress), June 2017. 431 [I-D.king-teas-applicability-actn-slicing] 432 King, D., "Applicability of Abstraction and Control of TE 433 Networks (ACTN) to Network Slicing", draft-king-teas- 434 applicability-actn-slicing-00 (work in progress), June 435 2017. 437 [I-D.qiang-netslices-gap-analysis] 438 Qiang, L., Martinez-Julia, P., 67, 4., Dong, J., 439 kiran.makhijani@huawei.com, k., Galis, A., Hares, S., and 440 S. Slawomir, "Gap Analysis for Network Slicing", draft- 441 qiang-netslices-gap-analysis-00 (work in progress), June 442 2017. 444 [I-D.xu-mpls-unified-source-routing-instruction] 445 Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, 446 L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and 447 S. Ma, "Unified Source Routing Instruction using MPLS 448 Label Stack", draft-xu-mpls-unified-source-routing- 449 instruction-02 (work in progress), June 2017. 451 Authors' Addresses 453 Stewart Bryant 454 Huawei 456 Email: stewart.bryant@gmail.com 458 Jie Dong 459 Huawei 461 Email: jie.dong@huawei.com