idnits 2.17.1 draft-huang-nvo3-naas-usecases-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 date (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 285, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nvo3 L. Huang, Ed. 3 Internet-Draft R. Gu, Ed. 4 Intended status: Informational China Mobile 5 Expires: April 30, 2015 L. Xia 6 Huawei Technologies 7 Q. Zu 8 Ericsson 9 October 27, 2014 11 Network as a Service in datacenters use cases 12 draft-huang-nvo3-naas-usecases-00 14 Abstract 16 Network as a Service (NaaS) is a new network business model in the 17 cloud computing area where virtualized E2E connectivity to end users 18 is provided to make the network more flexible and scalable. 20 This draft describes Network as a Service (NaaS) system use cases in 21 datacenters that are deployed typically for different applications. 22 Considerations about the use cases are pointed out. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 30, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 2 57 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Use cases 1 VPN . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Use cases 2 Intelligent traffic engineering across 60 datacenters . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. OAM considerations . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 63 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Network as a Service (NaaS) is a new network business model which 71 describes services for network transport connectivity in the cloud 72 computing area. Considering network and computing resources as a 73 whole, resource allocations are optimized. The target of NaaS is to 74 provide end to end virtual network with capacity for tenants in cloud 75 datacenter, which is the essential part from the technical point of 76 view. In NaaS, operators' network infrastructure can be virtualized 77 and multiplexed for selling, while clients can make the network 78 provision and use their own virtual network according to specific 79 requirements. 81 In this draft, we focus on proposing network use cases of NaaS in 82 datacenters. Two typical use cases are provided. One is about the 83 virtual private cloud network and another is the intelligent traffic 84 engineering across the datacenters. In both use cases, basic network 85 models are introduced and considerations about the use cases are 86 pointed out. 88 2. Definition of terms 90 VPCN: virtual private cloud network 92 FW: firewall 94 NAT: network address translation 96 LB: load balance 97 TS: tenant systems 99 VM: virtual machine 101 CE: customer edge 103 PE: provider edge 105 3. Use cases 107 3.1. Use cases 1 VPN 109 One of the typical use cases in NaaS is to construct the virtual 110 private cloud network (VPCN) for tenants (i.e., enterprise, 111 organization, etc) over the public cloud provided by the operators. 112 Its main characteristic is that tenants can custom their own VPCN, 113 i.e., network topology, VPN connection, network services, etc. 114 Following Figure 1 is an logical network example for VPCN. 116 ............................................................. 117 . VPCN +----+---+ . 118 . |Internet| . 119 . | | . 120 . +----+---+ . 121 . | . 122 . ........... | . 123 . . +---+ . +----+---+ . 124 . . |NAT| . |Internet| . 125 . . +---+ . | GW | . 126 . . . +----+---+ . 127 . . +---+ . | . 128 . . |FW | . | . 129 . . +---+ . +----+---+ . 130 . . . | GW | . 131 . . +---+ .------------- | | . 132 . . |LB | . +----+---+ . 133 . . +---+ . | . 134 . . . | . 135 . . +---+ . +----+---+ . 136 . . |...| . | TS | . 137 . . +---+ . | | . 138 . ........... +----+---+ . 139 ............................................................. 141 Figure 1: VPCN example 143 NaaS provides the network more convinent to the tenants. In 144 traditional service, it takes a long time for tenants to rent their 145 own network, while it costs more time for tenants to configure their 146 network. Because the all the configurations are delivered by 147 adminstrators manually.Besides, extensibility is limited to the 148 number of vlan supported.Tenants are not avaliable to monitor their 149 network.So it turns to NaaS in VPCN. 151 In NaaS, the tenants can define their networks by themselves simply 152 by Graphical User Interface. And the network they construct can be 153 controlled by themselves as well. The administrators can take a 154 global control from the management plane. NaaS provides it available 155 that networks rather than unique devices are for sale. 157 In such a framework, the interface information from the tenants' side 158 can be an issue, as the standard interface has several features. 159 Tenants apply for the virtual network construction they need to 160 deploy the end to end network. Different tenants are isolated from 161 each other with their access policies defined by themselves. The 162 virtual network can be managed, monitored and configured by tenants. 163 Because of the open access of network to the tenants, the network 164 model aimed at the tenants should be thoughtful. The network model 165 is constituted of node, link, flow and policy. Node acts as the role 166 of forwarding or processing the dataflow by some policies.Service 167 node provides the service, while computer node refers to the VMs. 168 Link connects two nodes. The network model can be divided into 169 several typical models to provide one of network service, something 170 like LBaaS, FWaaS or DNSaaS and so on. 172 ............................................ 173 . +----+----+ . 174 . |Mnagement| ................... . 175 . | | . service node . . 176 . +----+----+ . +---+ +---+ . . 177 . | . |NAT| |LB | . . 178 . +----+----+ policy. +---+ +---+ . . 179 . | Router |-------. +---+ +---+ . . 180 . | node | link . |FW | |...| . . 181 . +----+----+ . +---+ +---+ . . 182 . | ................... . 183 . ...... . 184 . ... ... . 185 . ... Subnet ... . 186 . ... ... ................... . 187 . ...... . computer node . . 188 . | . +---+ +---+ . . 189 . ... . |VM | |VM | . . 190 . .. .. policy . +---+ +---+ . . 191 . . Port .------ . +---+ +---+ . . 192 . .. .. link . |VM | |VM | . . 193 . ... . +---+ +---+ . . 194 . ................... . 195 ............................................ 197 Figure 2: VPCN logical network 199 3.2. Use cases 2 Intelligent traffic engineering across datacenters 201 The intelligent traffic engineering can be regarded as another 202 typical use case of Network as a Service, such as the network 203 management across the data center. NaaS can provide the virtual 204 network across datacenters with intelligent traffic engineering and 205 load balancing. With the virtualized network and centralized 206 controlling, NaaS offers the capability of scheduling the traffic at 207 different levels of traffic QoS, reliability and transparency in a 208 flexible and scalable way. Besides due to the virtual network, 209 virtual machines can migrate from one datacenter to another flexibly. 210 The network model is constituted of node, link, flow and policy as 211 well. 213 Superior to the traditional network with the condition of congestion, 214 virtualized network provides the advantage of network bandwidth 215 optimization. By the statistical data of the current traffic, 216 Network as a Service schedules the traffic based on centralized 217 computing intelligently. 219 In addition, services and tenants can be labeled in different 220 priority due to their features. Thus QoS can be guaranteed. 222 ....................................................................... 223 . +---------------+ . 224 . |+-+-+ IDC | . 225 . ||VM | +---+ | . 226 . |+-+-+ |CE | | . 227 . | +-+-+ | . 228 . +---------+-----+ . 229 . +-+-+ . 230 . |PE | . 231 . +-+-+ . 232 . load balancing at the output | . 233 . bandwidth/QoS ....................... . 234 . ......... ......... . 235 . ......... IP/MPLS ......... . 236 . ..... WAN ..... . 237 . ......... ......... . 238 . ......... ......... . 239 . | ....................... | . 240 . | | . 241 . +-+-+ +-+-+ . 242 . |PE | |PE | . 243 . +-+-+ +-+-+ . 244 . +---------+-----+ +---------+-----+ . 245 . | IDC +-+-+ | | IDC +-+-+ | . 246 . | |CE | | | |CE | | . 247 . |+-+-+ +---+ | |+---+ +---+ | . 248 . ||VM | | ||VM | | . 249 . |+-+-+ | |+-+-+ | . 250 . +--+------------+ +--+------------+ . 251 . |----------- VM migration ---------| . 252 ....................................................................... 254 Figure 3: Intelligent traffic engineering across the datacenter model 256 4. OAM considerations 258 TBD. 260 5. Security considerations 262 In NaaS, security can be a problem in several aspects. To meet the 263 requirement of the tenants, the virtual network should be secured and 264 tenants' traffic should be isolated with each other. On the other 265 side, the security in NaaS is reflected in that traffic access should 266 be authorized. Other security in such as VM migration can also be an 267 issue. 269 6. Summary 271 This draft describes some typical use cases of NaaS in datacenters. 272 NaaS provides network as a service to tenants. Tenants can build 273 their own network by NaaS easily with the basic network model 274 provided. Through NaaS, traffic across the datacenters can be 275 optimized by intelligent traffic engineering. It's expressed in 276 given use cases that network virtualized with basic models can be 277 helpful in providing NaaS. 279 7. IANA Considerations 281 The document does not require any IANA action. 283 8. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 Authors' Addresses 290 Lu Huang (editor) 291 China Mobile 292 32 Xuanwumen West Ave, Xicheng District 293 Beijing 100053 294 China 296 Email: huanglu@chinamobile.com 298 Rong Gu (editor) 299 China Mobile 300 32 Xuanwumen West Ave, Xicheng District 301 Beijing 100053 302 China 304 Email: gurong@chinamobile.com 306 Fank Xia 307 Huawei Technologies 309 Email: frank.xialiang@huawei.com 310 Qiang Zu 311 Ericsson 312 8400, boul. Decarie Ville Mont-Royal 313 QC 314 Canada 316 Email: Zu.Qiang@Ericsson.com