idnits 2.17.1 draft-kumaki-teas-actn-multitenant-vno-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ceccarelli-teas-actn-framework-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kumaki 3 Internet-Draft T. Miyasaka 4 Intended status: Informational KDDI Corporation 5 Expires: January 7, 2016 July 6, 2015 7 ACTN : Use case for Multi Tenant VNO 8 draft-kumaki-teas-actn-multitenant-vno-00 10 Abstract 12 This document provides a use case that addresses the need for 13 facilitating virtual network operation: creation and operation of 14 multi-tenant virtual networks that use the common core network 15 resources. This will accelerate a rapid service deployment of new 16 services, including more dynamic and elastic services, and improve 17 overall network operations and scaling of existing services. This 18 use case addresses the aforementioned needs within a single operator 19 network. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Multi-tenant Virtual Network Consolidation . . . . . . . . . 4 71 4.1. Service Consolidation . . . . . . . . . . . . . . . . . . 4 72 4.2. VPN Service Consolidation . . . . . . . . . . . . . . . . 5 73 4.3. Network Wholesale Service . . . . . . . . . . . . . . . . 5 74 4.4. On-demand Network Service . . . . . . . . . . . . . . . . 5 75 4.5. Redundant Network Service . . . . . . . . . . . . . . . . 6 76 4.6. Mobile/LTE Access Service . . . . . . . . . . . . . . . 6 77 5. Multi-tenant Virtual Network Operation Coordination . . . . . 6 78 6. High-level Requirements for Multi-tenant Virtual Network 79 Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6.1. Dynamic binding - On-demand Virtual Network Service 81 Creation . . . . . . . . . . . . . . . . . . . . . . . . 7 82 6.2. Domain Control Plane/Routing Layer Separation . . . . . . 8 83 6.3. Separate Operation of Virtual Services . . . . . . . . . 8 84 6.4. QoS/SLA . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 6.5. VN diversity . . . . . . . . . . . . . . . . . . . . . . 8 86 6.6. Security Concerns . . . . . . . . . . . . . . . . . . . . 8 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 92 10.2. Informational References . . . . . . . . . . . . . . . . 9 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 95 1. Introduction 97 This document provides a use case that addresses the need for 98 facilitating virtual network operation: creation and operation of 99 multi-tenant virtual networks that use the common core network 100 resources. This will accelerate a rapid service deployment of new 101 services, including more dynamic and elastic services, and improve 102 overall network operations and scaling of existing services. 104 Generally, carrier's core network consists of multi-domain networks. 105 For instance, a network may have multiple confederation ASes that 106 have each own IGP network using IS-IS or OSPF. In other instance, a 107 network may consist of multiple vendor's optical transport networks 108 that have each own Network Management System (NMS). In such a 109 carrier's multi-domain core network, it is difficult to create an 110 end-to-end virtual network that meets customer's requirements (e.g. 111 topology, AS, bandwidth, delay and jitter). 113 This use case supports Abstraction and Control of Transport Networks 114 (ACTN). The aim of ACTN is to facilitate virtual network operation, 115 creation of a virtualized environment allowing operators to view and 116 control multi-subnet multi-technology networks into a single 117 virtualized network. Related documents are: 118 [I-D.leeking-teas-actn-problem-statement] and 119 [I-D.ceccarelli-teas-actn-framework] which provide detailed 120 information regarding this work. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Motivation 130 One of the main motivations for multi-tenant virtual networks that 131 share the common core transport network resource is to increase the 132 network utilization of the core transport network. As each service 133 network has evolved in a different time with different service needs, 134 many dedicated overlay networks have formed to support different 135 service needs. This results in an inefficient use of network 136 resources and the complexity in operating such diverse service 137 networks. Due to the lack of the coordination across different 138 service networks and the common service platform, the introduction of 139 new services is not as speedy as the operators' desire. Part of the 140 reasons for this difficulty is due to the lack of the virtual network 141 infrastructure. Figure 1 shows an illustration of the current 142 multiple service network architecture. 144 +-----------+ +-----------+ 145 | Service A | | Service A | 146 | Network |\ /| Network | 147 | | \ / | | 148 +-----------+ \+-------------------------+/ +-----------+ 149 | | 150 +-----------+ | Core Transport | +-----------+ 151 | Service B | | Network | | Service B | 152 | Network |---| |---| Network | 153 | | | | | | 154 +-----------+ | | +-----------+ 155 +-------------------------+ 156 +-----------+ / \ +-----------+ 157 | Service C | / \ | Service C | 158 | Network |/ \| Network | 159 | | | | 160 +-----------+ +-----------+ 162 Figure 1: Multiple Services Network Architecture 164 The characteristics of the multiple services network are as follows: 166 o Each service has its own dedicated access points (e.g., PE 167 routers) in the core network. 169 o Each service or a group of services may be operated in a different 170 service operations department within an operator. For instance, 171 the VPN service and the mobile service may be operated by two 172 different departments while whole sale Internet service by another 173 department. 175 o There may be dedicated core transport network resources for some 176 services to ensure a strict service guarantee. 178 o There may be little or no coordination for operating multiple 179 services in terms of network resource allocation or sharing of the 180 resources. 182 4. Multi-tenant Virtual Network Consolidation 184 This section discusses key aspects to support multi-tenant virtual 185 network consolidation. 187 4.1. Service Consolidation 189 Multi-tenant virtual network operation should support different 190 services as the tenants that share the common core transport network 191 resources. Therefore, it is important to understand the type of 192 various services and its service requirement. 194 4.2. VPN Service Consolidation 196 Network providers have many different service networks such as VPNs 197 of various types and different QoS requirements. Within VPNs, there 198 are several QoS levels. Some VPN is best-effort VPN while other VPNs 199 require a strict QoS such as bandwidth guarantee and latency. 200 Therefore, multi-level VPNs should be supported in multi-tenant 201 virtual network consolidation. 203 4.3. Network Wholesale Service 205 Network providers want to provide a network resource (i.e. a network 206 slice) to ISPs. Generally, ISPs have each own ASes and they do not 207 want to change their own network policy. We can deploy these network 208 wholesale services by using "carrier's carrier" in [RFC4364]. 209 However, ISPs need to change their network policy and run LDP at an 210 edge router at ISP's edge routers although just IP is running on 211 their original network. Additionally, they (i.e. network architects 212 at ISPs) need to transfer MPLS knowledge to their network operators. 214 In another aspect, the network provider must guarantee the SLA to 215 each ISP. There may be different level of SLA as well as different 216 level of virtual network granularity for each ISP. The ISP should be 217 given its virtual network(s) as well as an independent domain control 218 of allocated virtual network(s). It is also to be noted that there 219 may be different grade of services required depending on the nature 220 of the whole sale. For instance, CATV operator may require a 221 different grade of service than best-effort internet services. 222 Therefore, multi-level wholesale services should be supported in 223 multi-tenant virtual network consolidation. Also, network providers 224 should not provide unnecessary network information (e.g. TE database 225 and IGP information in core transport network) to ISPs. To provide 226 unnecessary information in core transport network poses security 227 issues. Therefore, network providers should provide only necessary 228 network information to create ISP's virtual network. 230 4.4. On-demand Network Service 232 Some ISPs may need a network resource (i.e. a network slice) during 233 the specific time and period. This is referred to as on-demand 234 network service. This implies that virtual networks should be 235 created/deleted dynamically and the resources (e.g. bandwidth) of 236 virtual networks should be added/decreased dynamically. 238 4.5. Redundant Network Service 240 Some service requires a number of redundant network paths that are 241 physically diverse from one another. This implies that the virtual 242 networks should indicate link and node diversity constraints. 244 4.6. Mobile/LTE Access Service 246 Consumer mobile/LTE access can be a tenant that shares the resources 247 of the core transport network. In such case, a strict latency with a 248 guaranteed bandwidth should be supported by multi-tenant virtual 249 network operation. 251 5. Multi-tenant Virtual Network Operation Coordination 253 The following Figure 2 depicts a functional control architecture that 254 shows the need to support virtual networks to a number of different 255 service networks that share the common core network resources. 257 +-----------------+ 258 | Multi-tenant | 259 | VN Coordination | 260 +-----------+ +-----------------+ 261 | Service A |-+ | | 262 | Control |B|-+ | | 263 +-----------+ |C|---------| | 264 +-----------+ | | 265 +-----------+ +---------------+ 266 |Core Transport | 267 /------\ |Network Control| /------\ 268 // \\ +---------------+ // \\ 269 | Service A | | | Service A | 270 \\ // ---------- /\ // 271 ------ \ //// \\\\ / ------ 272 /------\ \|| ||/ /------\ 273 // \\ | Core Transport | // \\ 274 | Service B |----| |----| Service B | 275 \\ // || Network || \\ // 276 \------/ \\\\ //// \------/ 277 /------\ / ---------- \ /------\ 278 // \\ / \ // \\ 279 | Service C | \| Service C | 280 \\ // \\ // 281 ------ ------ 283 Figure 2: Multi-tenant control architecture 285 There are a few characteristics of the above architecture. 287 1. The core transport network is the common transport network 288 resource pool for a number of multiple tenants, which is referred 289 to as network tenancy. 291 2. Each service is a client to the common transport network. 293 3. Each service should be guaranteed its operational independence 294 from other services. The separation of service control (depicted 295 as separate boxes) in the above figure represents an operational 296 independence. 298 4. The virtual network for each service is created and assigned by 299 the multi-tenant virtual network coordination function. This is 300 a functional entity that communicates with each service control 301 and the core transport network control/management entities in 302 order to coordinate with the necessary communication. 304 5. Each service instantiates its service instance based on its 305 virtual network. 307 6. Each service is in control of its virtual network and operates on 308 the virtual network. 310 7. As a number of services carried on the common transport network 311 sharing a common network resource, operational independence for 312 each service has to be guaranteed as if each service owns its 313 dedicated virtual resources. 315 8. The level of abstraction of a virtual network is determined by 316 each service and may differ from one another. In some cases, a 317 virtual network should represent a graph form of topology 318 abstraction of the virtual network. 320 6. High-level Requirements for Multi-tenant Virtual Network Operations 322 Based on the discussion in the previous sections, this section 323 provides the overall requirements that must be supported. 325 6.1. Dynamic binding - On-demand Virtual Network Service Creation 327 The solution needs to provide the ability to create a new virtual 328 network on demand. The virtual network should be built dynamically. 330 6.2. Domain Control Plane/Routing Layer Separation 332 The solution needs to support an independent control plane for a 333 domain service control. This implies that each service domain has 334 its own VN control scheme that is independent of other domain or the 335 core transport network control. 337 6.3. Separate Operation of Virtual Services 339 The solution needs to support an independent operation of a virtual 340 network and a service. Each Service Administrators should be able to 341 control and manage its virtual network in terms of policy and 342 resource allocation (e.g., CPU, Memory, other resources.) In 343 addition, the virtualized networks should not affect each other in 344 any way. 346 6.4. QoS/SLA 348 The solution needs to provide an independent QoS/SLA per a virtual 349 network depending on a service level. Each QoS on the virtual 350 network should support multiple service levels. Each SLA on the 351 virtual network should fulfill a bandwidth and a latency required by 352 each service. 354 6.5. VN diversity 356 Each service should be able to create multiple diverse VNs for the 357 diversity purpose. The diversity for VNs must be physically diverse 358 in the core transport network. This implies that the core transport 359 network control/management plane must be able to factor the SRLG 360 information when creating multiple VNs to ensure VN diversity. 362 6.6. Security Concerns 364 The solution needs to keep the confidentiality between the services. 365 A service should not have the connectivity to an another service 366 through the common core transport network. 368 7. Acknowledgments 370 The authors wish to thank Young Lee and Dhruv Dhody for the 371 discussions in the document. 373 8. IANA Considerations 374 9. Security Considerations 376 10. References 378 10.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 384 Networks (VPNs)", RFC 4364, February 2006. 386 10.2. Informational References 388 [I-D.ceccarelli-teas-actn-framework] 389 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 390 Control of Transport Networks", draft-ceccarelli-teas- 391 actn-framework-00 (work in progress), June 2015. 393 [I-D.leeking-teas-actn-problem-statement] 394 Lee, Y., King, D., Boucadair, M., Jing, R., and L. 395 Contreras, "Problem Statement for Abstraction and Control 396 of Transport Networks", draft-leeking-teas-actn-problem- 397 statement-00 (work in progress), June 2015. 399 Authors' Addresses 401 Kenji Kumaki 402 KDDI Corporation 403 1-20-1 Nishishinjuku 404 Shinjuku-ku, Tokyo 160-0023 405 Japan 407 Email: ke-kumaki@kddi.com 409 Takuya Miyasaka 410 KDDI Corporation 411 1-20-1 Nishishinjuku 412 Shinjuku-ku, Tokyo 160-0023 413 Japan 415 Email: ta-miyasaka@kddi.com