idnits 2.17.1 draft-kumaki-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 (May 29, 2014) is 3592 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ceccarelli-actn-framework-01 == Outdated reference: A later version (-03) exists of draft-leeking-actn-problem-statement-01 Summary: 0 errors (**), 0 flaws (~~), 5 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: November 30, 2014 May 29, 2014 7 ACTN : Use case for Multi Tenant VNO 8 draft-kumaki-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 November 30, 2014. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . 8 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. This 103 use case supports Abstraction and Control of Transport Networks 104 (ACTN). The aim of ACTN is to facilitate virtual network operation, 105 creation of a virtualized environment allowing operators to view and 106 control multi-subnet multi-technology networks into a single 107 virtualized network. Related documents are: 108 [I-D.leeking-actn-problem-statement] and 109 [I-D.ceccarelli-actn-framework] which provide detailed information 110 regarding this work. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Motivation 120 One of the main motivations for multi-tenant virtual networks that 121 share the common core transport network resource is to increase the 122 network utilization of the core transport network. As each service 123 network has evolved in a different time with different service needs, 124 many dedicated overlay networks have formed to support different 125 service needs. This results in an inefficient use of network 126 resources and the complexity in operating such diverse service 127 networks. Due to the lack of the coordination across different 128 service networks and the common service platform, the introduction of 129 new services is not as speedy as the operators' desire. Part of the 130 reasons for this difficulty is due to the lack of the virtual network 131 infrastructure. Figure 1 shows an illustration of the current 132 multiple service network architecture. 134 +-----------+ +-----------+ 135 | Service A | | Service A | 136 | Network |\ /| Network | 137 | | \ / | | 138 +-----------+ \+-------------------------+/ +-----------+ 139 | | 140 +-----------+ | Core Transport | +-----------+ 141 | Service B | | Network | | Service B | 142 | Network |---| |---| Network | 143 | | | | | | 144 +-----------+ | | +-----------+ 145 +-------------------------+ 146 +-----------+ / \ +-----------+ 147 | Service C | / \ | Service C | 148 | Network |/ \| Network | 149 | | | | 150 +-----------+ +-----------+ 152 Figure 1: Multiple Services Network Architecture 154 The characteristics of the multiple services network are as follows: 156 o Each service has its own dedicated access points (e.g., PE 157 routers) in the core network. 159 o Each service or a group of services may be operated in a different 160 service operations department within an operator. For instance, 161 the VPN service and the mobile service may be operated by two 162 different departments while whole sale Internet service by another 163 department. 165 o There may be dedicated core transport network resources for some 166 services to ensure a strict service guarantee. 168 o There may be little or no coordination for operating multiple 169 services in terms of network resource allocation or sharing of the 170 resources. 172 4. Multi-tenant Virtual Network Consolidation 174 This section discusses key aspects to support multi-tenant virtual 175 network consolidation. 177 4.1. Service Consolidation 179 Multi-tenant virtual network operation should support different 180 services as the tenants that share the common core transport network 181 resources. Therefore, it is important to understand the type of 182 various services and its service requirement. 184 4.2. VPN Service Consolidation 186 Network providers have many different service networks such as VPNs 187 of various types and different QoS requirements. Within VPNs, there 188 are several QoS levels. Some VPN is best-effort VPN while other VPNs 189 require a strict QoS such as bandwidth guarantee and latency. 190 Therefore, multi-level VPNs should be supported in multi-tenant 191 virtual network consolidation. 193 4.3. Network Wholesale Service 195 Network providers want to provide a network resource (i.e. a network 196 slice) to ISPs. In this case, the network provider must guarantee 197 the SLA to each ISP. There may be different level of SLA as well as 198 different level of virtual network granularity for each ISP. The ISP 199 should be given its virtual network(s) as well as an independent 200 domain control of allocated virtual network(s). It is also to be 201 noted that there may be different grade of services required 202 depending on the nature of the whole sale. For instance, CATV 203 operator may require a different grade of service than best-effort 204 internet services. Therefore, multi-level wholesale services should 205 be supported in multi-tenant virtual network consolidation. Also, 206 network providers should not provide unnecessary network information 207 (e.g. TE database and IGP information in core transport network) to 208 ISPs. To provide unnecessary information in core transport network 209 poses security issues. Therefore, network providers should provide 210 only necessary network information to create ISP's virtual network. 212 4.4. On-demand Network Service 214 Some ISPs may need a network resource (i.e. a network slice) during 215 the specific time and period. This is referred to as on-demand 216 network service. This implies that virtual networks should be 217 created/deleted dynamically and the resources (e.g. bandwidth) of 218 virtual networks should be added/decreased dynamically. 220 4.5. Redundant Network Service 222 Some service requires a number of redundant network paths that are 223 physically diverse from one another. This implies that the virtual 224 networks should indicate link and node diversity constraints. 226 4.6. Mobile/LTE Access Service 228 Consumer mobile/LTE access can be a tenant that shares the resources 229 of the core transport network. In such case, a strict latency with a 230 guaranteed bandwidth should be supported by multi-tenant virtual 231 network operation. 233 5. Multi-tenant Virtual Network Operation Coordination 235 The following Figure 2 depicts a functional control architecture that 236 shows the need to support virtual networks to a number of different 237 service networks that share the common core network resources. 239 +-----------------+ 240 | Multi-tenant | 241 | VN Coordination | 242 +-----------+ +-----------------+ +-----------+ 243 | Service A |-+ | | | | Service A |-+ 244 | Control |B|-+ | | | | Control |B|-+ 245 +-----------+ |C|---------| | |---------+-----------+ |C| 246 +-----------+ | | +-----------+ | 247 +-----------+ +---------------+ +-----------+ 248 |Core Transport | 249 /------\ |Network Control| /------\ 250 // \\ +---------------+ // \\ 251 | Service A | | | Service A | 252 \\ // ---------- /\ // 253 ------ \ //// \\\\ / ------ 254 /------\ \|| ||/ /------\ 255 // \\ | Core Transport | // \\ 256 | Service B |----| |----| Service B | 257 \\ // || Network || \\ // 258 \------/ \\\\ //// \------/ 259 /------\ / ---------- \ /------\ 260 // \\ / \ // \\ 261 | Service C | \| Service C | 262 \\ // \\ // 263 ------ ------ 265 Figure 2: Multi-tenant control architecture 267 There are a few characteristics of the above architecture. 269 1. The core transport network is the common transport network 270 resource pool for a number of multiple tenants, which is referred 271 to as network tenancy. 273 2. Each service is a client to the common transport network. 275 3. Each service should be guaranteed its operational independence 276 from other services. The separation of service control (depicted 277 as separate boxes) in the above figure represents an operational 278 independence. 280 4. The virtual network for each service is created and assigned by 281 the multi-tenant virtual network coordination function. This is 282 a functional entity that communicates with each service control 283 and the core transport network control/management entities in 284 order to coordinate with the necessary communication. 286 5. Each service instantiates its service instance based on its 287 virtual network. 289 6. Each service is in control of its virtual network and operates on 290 the virtual network. 292 7. As a number of services carried on the common transport network 293 sharing a common network resource, operational independence for 294 each service has to be guaranteed as if each service owns its 295 dedicated resources. 297 8. The level of abstraction of a virtual network is determined by 298 each service and may differ from one another. In some cases, a 299 virtual network should represent a graph form of topology 300 abstraction of the virtual network. 302 6. High-level Requirements for Multi-tenant Virtual Network Operations 304 Based on the discussion in the previous sections, this section 305 provides the overall requirements that must be supported. 307 6.1. Dynamic binding - On-demand Virtual Network Service Creation 309 The solution needs to provide the ability to create a new virtual 310 network on demand. The virtual network should be built dynamically. 312 6.2. Domain Control Plane/Routing Layer Separation 314 The solution needs to support an independent control plane for a 315 domain service control. This implies that each service domain has 316 its own VN control scheme that is independent of other domain or the 317 core transport network control. 319 6.3. Separate Operation of Virtual Services 321 The solution needs to support an independent operation of a virtual 322 network and a service. Each Service Administrators should be able to 323 control and manage its virtual network in terms of policy and 324 resource allocation (e.g., CPU, Memory, other resources.) In 325 addition, the virtualized networks should not affect each other in 326 any way. 328 6.4. QoS/SLA 330 The solution needs to provide an independent QoS/SLA per a virtual 331 network depending on a service level. Each QoS on the virtual 332 network should support multiple service levels. Each SLA on the 333 virtual network should fulfill a bandwidth and a latency required by 334 each service. 336 6.5. VN diversity 338 Each service should be able to create multiple diverse VNs for the 339 diversity purpose. The diversity for VNs must be physically diverse 340 in the core transport network. This implies that the core transport 341 network control/management plane must be able to factor the SRLG 342 information when creating multiple VNs to ensure VN diversity. 344 6.6. Security Concerns 346 The solution needs to keep the confidentiality between the services. 347 A service should not have the connectivity to an another service 348 through the common core transport network. 350 7. Acknowledgments 352 The authors wish to thank Young Lee for the discussions in the 353 document. 355 8. IANA Considerations 357 9. Security Considerations 359 10. References 360 10.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 10.2. Informational References 367 [I-D.ceccarelli-actn-framework] 368 Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, 369 "Framework for Abstraction and Control of Transport 370 Networks", draft-ceccarelli-actn-framework-01 (work in 371 progress), February 2014. 373 [I-D.leeking-actn-problem-statement] 374 Lee, Y., King, D., Boucadair, M., and R. Jing, "Problem 375 Statement for Abstraction and Control of Transport 376 Networks", draft-leeking-actn-problem-statement-01 (work 377 in progress), February 2014. 379 Authors' Addresses 381 Kenji Kumaki 382 KDDI Corporation 383 Garden Air Tower 384 Iidabashi, Chiyoda-ku, Tokyo, 102-8460 385 Japan 387 Email: ke-kumaki@kddi.com 389 Takuya Miyasaka 390 KDDI Corporation 391 Garden Air Tower 392 Iidabashi, Chiyoda-ku, Tokyo, 102-8460 393 Japan 395 Email: ta-miyasaka@kddi.com