idnits 2.17.1 draft-liu-nvo3-naas-arch-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** There is 1 instance of lines with control characters in the document. 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 (June 30, 2014) is 3588 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 374 looks like a reference -- Missing reference section? 'I-D.ietf-i2rs-architecture' on line 379 looks like a reference -- Missing reference section? 'I-D.ietf-idr-ls-distribution' on line 383 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group Vic Liu 2 Internet Draft China Mobile 3 Category: Standard Track L. Xia 4 Huawei 5 Zu Qiang 6 Ericsson 7 Expires: December, 2014 June 30, 2014 9 Network as a Service Architecture 10 draft-liu-nvo3-naas-arch-01 12 Abstract 14 This draft provides an high-level overview architecture of Network 15 as a Service (NaaS) system, and describes how every component of it 16 works together from different aspects (i.e., data plane, control 17 plane, management plane, etc) of NaaS system. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 30, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Table of Contents 56 1. Introduction ................................................ 3 57 1.1. Conventions used in this document ...................... 4 58 1.2. Terminology ............................................ 4 59 2. Overview .................................................... 5 60 2.1. New Features ........................................... 5 61 2.2. Main Challenges......................................... 6 62 3. NaaS Architecture ........................................... 6 63 4. Data Plane of NaaS System ................................... 8 64 4.1. Centralized NaaS Network ............................... 8 65 4.2. Distributed NaaS Network ............................... 9 66 4.3. Comparison ............................................. 9 67 5. Control Plane of NaaS Network ............................... 9 68 6. Management Plane of NaaS Network ............................ 9 69 7. Security Considerations ..................................... 9 70 8. Acknowledgements ............................................ 9 71 9. IANA Considerations ......................................... 9 72 10. References ................................................. 9 73 10.1. Normative References .................................. 9 74 10.2. Informative References ................................ 9 76 1. Introduction 78 Network as a Service (NaaS) is a new network business model provided 79 by more and more operators. It is a novel class of services for 80 cloud computing that provides virtualized E2E connectivity to end 81 users at different levels of reliability, traffic QoS and 82 transparency in a flexible and scalable way. From the technical 83 point of view, the essential part of it is network virtualization. 84 That means, virtual network (including sub-network, gateway, network 85 routing, bandwidth, network service, etc) as the resource provided 86 by operator, can be got on-demand by clients by the way of pay as 87 you go service. Clients can make the network provision and use their 88 own virtual network flexibly according to specific requirements. By 89 this way, operators' network infrastructure can be virtualized and 90 multiplexed for selling, and clients can improve the flexibility of 91 their network to reduce cost because of better visibility and 92 efficient control over their own virtual network. 94 The common use case for NaaS is to construct the virtual private 95 cloud network (VPCN) for tenant (i.e., enterprise, organization, etc) 96 over the public cloud provided by operator. Its main characteristic 97 is that tenant can custom their own VPCN, i.e., network topology, 98 VPN connection, network services, etc. Following Figure 1 is an 99 example for VPCN: 101 ............................. 102 . ...... . 103 . .... .... . 104 . . +-----+ . . 105 .. +-+ TS | . . 106 .. | +---+-+ . . 107 ...... . . +-----+ . . 108 ... ... . ....subnet.... . 109 .. . . ...... . 110 . Internet . . | . 111 .. . . | . 112 ... ... . +---+--+ . 113 ...... . | VPN | . 114 | . | GW | branch site . 115 | . +--+---+ or other VPCN. 116 | .........|................... 117 | |VPN connection 118 +---+----+ +---+---+ 119 ................|Internet|.........| VPN |............... 121 . ........ | GW | | GW | . 122 . .+---+ . +---+----+ +---+---+ ........ . 123 . .|NAT| . | | .+---+ . . 124 . .+---+ . +------------------+ .|NAT| . . 125 . .+---+ . | | .+---+ . . 126 . .|FW | . +---+--+ +---+--+ .+---+ . . 127 . .+---+ .-----+ GW | | GW +----.|FW | . . 128 . .+---+ . +--+---+ +--+---+ .+---+ . . 129 . .|...| . | | .+---+ . . 130 . .+---+ ...... ...... .|...| . . 131 . ....... .... .... .... .... .+---+ . 132 . . +-----+ . . +-----+ . ....... . 133 . . +-+ TS | . . +-+ TS | . . 134 . . | +---+-+ . . | +---+-+ . . 135 . . +-----+ . . +-----+ . . 136 . ....subnet.... ....subnet.... . 137 .VPCN ...... ...... . 138 ........................................................... 139 Figure 1: VPCN example 141 In a VPCN, tenant has several subnets for different application or 142 service, gateways work for the inter-subnet traffics. Some network 143 services (i.e., NAT, FW, etc) may be needed to work together with 144 gateways. If the VPCN provides services to internet, or needs to 145 access to internet, the internet gateway is needed to support this. 146 The VPCN can also have the VPN gateway for interconnecting tenant's 147 branch sites or other VPCNs through VPN connections. 149 In addition to the VPCN, a complete NaaS system consists of other 150 components. They involve different aspects of NaaS system, i.e., 151 data plane, control plane, management plane. This draft provides an 152 high-level overview architecture of NaaS system, and describes how 153 every component of it works together from different aspects of NaaS 154 system. 156 1.1. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC-2119 [RFC2119]. 162 1.2. Terminology 164 To be added. 166 2. Overview 168 For better understanding what influence NaaS may introduce into 169 current network technologies, this section gives a brief summary of 170 new features and main challenges introduced by NaaS. 172 2.1. New Features 174 NaaS introduces a lot of new features to current network for 175 consideration; most of them are listed below: 177 o Network virtualization: NaaS must support Multi-tenancy 178 requirement. And it should hide the implementation details of the 179 network infrastructure; 181 o Close integration with virtual IT resources (compute, storage): 182 NaaS must have the capabilities of VM auto-discovery, integrated 183 operation/provision together with IT resources; 185 o Elasticity/High Availability: NaaS must have the capabilities of 186 on-demand bandwidth allocation, dynamic link/network creation, 187 dynamic and geographically distributed pools of shared ICT 188 resources, etc; 190 o Flexible service chain: Flexible interposition of various middle 191 boxes in the NaaS network becomes an essential and valuable 192 requirement for it and an IETF WG (SFC: Service Function Chaining) 193 has been created to study and resolve the series of requirements; 195 o SDN paradigm: SDN is optional paradigm, but provides great 196 flexibility and efficiency in network resource management, 197 optimized path selection for DC interconnection; 199 o Automation: This feature should be achieved in many aspects for 200 saving manual labor, which includes automatic collection of the 201 network topology information, policy auto distribution, OAM, auto 202 recovery, etc; 204 o Open interface to user: Making virtual network resource can be 205 managed by user themselves. For simplifying the operation, this 206 interface should provide network resource 207 abstraction/presentation, comprehensive service template, etc. 209 2.2. Main Challenges 211 Despite the above features introduced by NaaS, a series of 212 challenges also appear in front of the implementation, as listed 213 below: 215 o Constraints of physical DC: Traditional network technologies such 216 as vlan, broadcast domain, acl, firewall setting, etc, have put 217 so much constraints because of their location dependent feature; 219 o Distributed subnet: One L3 subnet can span across the whole DC by 220 virtualization technology. Hosts in a L3 subnet are no longer 221 limited in one location. This kind of distributed subnet scenario 222 brings new challenges of hosts' unified identification and access 223 control; 225 o Programmable network: SDN paradigm needs to define information 226 model and data model used by the related interfaces, and the 227 information mapping between overlay and underlay network; 229 o On-demand and flexible service chain: It means dynamic service 230 awareness and automatic service provision; 232 o End to end connection provision: How to provide the End to end 233 VPN service to users when the wan/man network and DC network are 234 separated? How to integrate enterprise's current infrastructure 235 and NaaS in cloud seamlessly and securely? How to guarantee the 236 End to end SLA, including bandwidth, latency, etc? 238 o Backwards compatibility and smooth migration; 240 o Security related issue; 242 3. NaaS Architecture 244 A complete and high-level architecture of NaaS system is shown in 245 Figure 2 followed: 247 +-----+ +-----+ +-----+ +-----+ 248 | NMS | | APP | | APP | | APP | 249 +--A--+ +--A--+ +--A--+ +--A--+ 250 | | | | 251 | +-------V---------V---------V-------+ 252 | | Orchestrator | 253 +------> | 254 | +-----------------A-----------------+ 255 | +---------------+---------------+ 256 | | | | 257 | +-----V----+ +-----V----+ +-----V----+ 258 | |Controller| |Controller| |Controller| 259 +--> | | | | | 260 | +------A---+ +-----A----+ +-----A----+ 261 | | | | 262 | | | | 263 | +---V----+ +---V----+ +----V---+ 264 +----->physical| |vswitch | |vswitch | 265 |switch | | | | | 266 +-+----+-+ +-+----+-+ ++-----+-+ 267 | | | | | | 268 | | | | | | 269 +-++ +-++ +-++ +-++ ++-+ +-++ 270 |TS| |SN| |TS| |TS| |TS| |SN| 271 +--+ +--+ +--+ +--+ +--+ +--+ 272 Figure 2: NaaS Architecture 274 In the above architecture, a NaaS system can divide into 4 layers: 276 o Application layer This layer consists of application (APP) and/or 277 network management system (NMS). Applications having the 278 visibility to network resource is beneficial for them to use 279 network resource better. Various standard interfaces can be used 280 among applications and orchestrator, i.e., Restful API, Java, 281 JSON, netconf, etc. NMS is used for the management or 282 configuration of the network devices (i.e., physical/virtual 283 switch), policies in controller, etc. NMS is an independent 284 system which can communicate and manage objects of every layers; 286 o Orchestrator layer: This layer is mainly used for integrating all 287 the resource (i.e., computing, store, network, etc) and 288 controlling them in centralized way. By providing standard 289 interface in northbound and southbound, it can support different 290 types of controller and hide the difference from application 291 layer; 293 o Controller layer: The core layer for the NaaS system. It is 294 responsible for transforming service requests from application 295 layer into forwarding information (e.g., flow table) in the 296 network devices. It collects network states, status and warnings 297 from network devices and synthesizes them for the path 298 computation. It can distribute various policies (i.e., ACL, QoS, 299 access control, etc) to network devices. Controller can be the 300 centralized or distributed system. It uses standard protocols 301 (i.e., Openflow, Netconf, I2RS [I-D.ietf-i2rs-architecture], BGP- 302 LS [I-D.ietf-idr-ls-distribution], etc) to communicate with 303 network devices; 305 o Network layer: This layer consists of all the network devices for 306 switching traffic, also all the tenant systems (TS) and service 307 nodes (SN: i.e., FW, NAT, etc). The network devices and service 308 nodes receive the forwarding information and policies from 309 controller layer and process the traffic in data plane 310 accordingly. 312 Four layers of component work together through standard interfaces 313 and protocols among them, form a complete and high-level 314 architecture of NaaS system. 316 In the following sections, NaaS system is described in details from 317 different aspects. 319 4. Data Plane of NaaS System 321 In data plane, NaaS system is mainly related to the network layer. 322 Depending on the network scalability and traffic throughput of it, 323 the provision of network layer can have two models: centralized NaaS 324 network and distributed NaaS network. 326 4.1. Centralized NaaS Network 328 Main characteristic of centralized NaaS network is the centralized 329 gateway and related service nodes normally located at the core or 330 aggregation layer of network. This deployment model is more suitable 331 for small/middle scale network. Most tenant systems are in the layer 332 2 network, traffic among them is switched locally. Other types of 333 traffic (i.e., inter network traffic, internet traffic, VPN traffic, 334 etc) among a small part of tenant systems need to traverse the 335 centralized gateway and related services nodes to get the unified 336 process. 338 4.2. Distributed NaaS Network 340 Being opposite to centralized NaaS network, distributed NaaS network 341 requires multiple gateways and related service nodes can be 342 distributed in different places of network. This helps to improve 343 the overall network performance and avoid the single point of 344 failure. This deployment model is more suitable for large scale 345 network. Most of the inter network traffic is processed locally in 346 the distributed gateway and related service nodes. 348 4.3. Comparison 350 To be added. 352 5. Control Plane of NaaS Network 354 To be added. 356 6. Management Plane of NaaS Network 358 To be added. 360 7. Security Considerations 362 TBD. 364 8. Acknowledgements 366 9. IANA Considerations 368 The document does not require any IANA action. 370 10. References 372 10.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC2119, March 1997. 377 10.2. Informative References 379 [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, 380 D., and T.Nadeau, "An Architecture for the Interface to the Routing 381 System", (work in progress), February 2014 383 [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., 384 Farrel, A., and S.Ray, "North-Bound Distribution of Link-State and 385 TE Information using BGP", (work in progress), November 2013. 387 Authors' Addresses 389 Vic Liu 390 China Mobile 391 32 Xuanwumen West Ave, Beijing, China 392 Email: liuzhiheng@chinamobile.com 394 Liang Xia 395 Huawei Technologies 397 Email: frank.xialiang@huawei.com 399 Zu Qiang 400 Ericsson 401 8400, boul. Decarie 402 Ville Mont-Royal, QC, 403 Canada 405 Email: Zu.Qiang@Ericsson.com