idnits 2.17.1 draft-deng-nfvcon-nb-use-cases-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 : ---------------------------------------------------------------------------- ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 4, 2014) is 3613 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MCN' is mentioned on line 253, but not defined == Outdated reference: A later version (-01) exists of draft-zhou-opsawg-vnf-config-arch-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Deng 3 Internet-Draft China Mobile 4 Intended status: Informational H. Song 5 Expires: December 6, 2014 Huawei 6 G. Karagian 7 U. of Twente 8 E. Haleplidis 9 U. of Patras 10 B. Martini 11 CNIT 12 June 4, 2014 14 NFV configuration north bound use cases 15 draft-deng-nfvcon-nb-use-cases-00 17 Abstract 19 This specification lists some classical use cases of NFV 20 configuration, especially those related to the north bound operation 21 with the involvement of network function provider and the network 22 function consumers, for example VNF installation, migration, 23 replication, on-demand resource allocation and etc.. These use cases 24 are only relative to the virtualization characteristics of network 25 functions. These use cases will be used to identify the proper 26 standard space and scope for the NFV configuration. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 6, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. VNF store: NSP's app store for VNFs . . . . . . . . . . . 5 66 3.2. VNF as a Service (VNFaaS): configuration and management . 5 67 3.3. VNF as a Platform (VNFaaP): configuration and management 7 68 3.4. VNF migration: travel with your NSP "devices" . . . . . . 9 69 3.5. VNF installation: customizing personal VNFs . . . . . . . 10 70 3.6. VNF template: common profile for managing multiple VNF 71 instances . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.7. Dynamic resource usage . . . . . . . . . . . . . . . . . 11 73 3.8. Service Function Chaining . . . . . . . . . . . . . . . . 11 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 6.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document describes the typical use cases for NFV (Network 84 Function Virtualization) configuration and management. Based on the 85 Network Function Configuration Architecture, see VNF configuration 86 architecture [I-D.zhou-opsawg-vnf-config-arch], four key roles can be 87 identified in these use cases, (1), the network function provider, 88 (2) network service provider, (3), the network function consumer, 89 (4), the NFV control plane, (5), the NFV infrastructure, see 90 Figure 1. 92 Network function providers provide the network function software and 93 related description information that are necessary for the network 94 function consumer to know. Network function providers are 95 responsible for the lifecycle management of the network functions, 96 for example, on-shelf, updates, and delete. 98 Network function consumers are those who use the network functions 99 deployed inside the network service provider, i.e. NSP's network. 100 The network function consumers can be the home user, the enterprise 101 user or the NSP. Home user and enterprise user can directly manage 102 their network functions such like virtual firewall or virtual 103 residential gateway in the provider's network. But NSPs can also be 104 the user of network functions, for example, carrier grade NAT. 106 +----------------+ +----------------+ +----------------+ 107 |Network Function| |Network Function| |Network Service | 108 | Provider | |Consumer | | | 109 +----------------+ +-------+--------+ +----------------+ 110 -- | -- 111 -- | -- 112 -- | --- 113 -- | --- 114 -- | -- 115 -- | --- 116 -- | -- 117 +--------------------------------+ 118 |NFV Control and Management Plane| 119 +--------------------------------+ 120 | 121 | 122 | 123 +-------------------+---------------------+ 124 | NFV Infrastructure | 125 |+----------+ +---------+ +--------+ | 126 || Computing| | Storage | | Network| | 127 |+----------+ +---------+ +--------+ | 128 +-----------------------------------------+ 130 Figure 1 Key roles used in use cases 131 (Note: this architecture will be mapped to the published ETSI NFV architecture) 133 There are many issues that the NFV control plane may be involved in, 134 and it is assumed that the existing standard protocols have already 135 solved the physical network functions' management and operation 136 problems (despite the fact that they have not), but they have not 137 solved the new problems introduced by the virtualization of network 138 functions, for example, the virtualization network function 139 installation, the dynamic lifecycle management, the dynamic 140 migration, the revocable of a particular network function. In this 141 document, only those use cases relative to the new problems will be 142 introduced. 144 2. Terminology 146 Note: The following terms used in this document will be aligned with 147 their definitions from ETSI GS NFV 003[ETSI_GS_NFV_003] . (Note: It 148 will aovid confusion of different terms. But what about the 149 copyright issue? or there is no copyright issue?) 151 Network Function Provider: a Network Function Provider (NFP) provides 152 virtual network function software. 154 Network Service Provider (NSP): a company or organization, that 155 provides a network service on a commercial basis to third parties. A 156 network service is a composition of network functions and defined by 157 its functional and behavior specification. The NSP operates the NFV 158 Control Plane. 160 Network Function Consumer: a Network Function Consumer (NFC) is the 161 consumer of virtual network functions. It can be either an 162 individual user, home user or the enterprise user. 164 Virtual Network Function: an implementation of an executable software 165 program that constitutes the whole or a part of a network function 166 that can be deployed on a virtualization infrastructure. 168 Physical Network Function: a physical network function indicates a 169 physical appliance of functional building block within an operator's 170 network infrastructure, which has well-defined external interfaces 171 and a well-defined functional behavior. 173 NFV Infrastructure: NFV Infrastructure indicates the computing, 174 storage and network resources to implement the virtual network 175 function. High performance acceleration platform is also part of it. 177 NFV Control and Management Plane: a NFV Control and Management Plane 178 is operated by a NSP and orchestrates the NFV Infrastructure to 179 provide NFV service to NFC. 181 3. Use Cases 182 3.1. VNF store: NSP's app store for VNFs 184 By the decoupling between the software implementation and hardware 185 platform of network devices enabled by virtualization technology, it 186 is envisioned that various functional components of consumer/network 187 devices (e.g. gateway, firewall, IDS, WAN acceleration), which are 188 traditionally provided by the local NSP/ third party device 189 manufactures in the form of dedicated hardware boxes, can be deployed 190 into a virtual machine within the local NSP's data center as a piece 191 of software instance (i.e. virtual network function or VNF). 193 By setting up an VNF store, an NSP operated application store 194 dedicated for various VNFs, the local NSP would be able to provide a 195 much convenient way for its users (both enterprise and individual 196 consumers) to search for, learn more about, compare between and make 197 purchase for specific NSP VNFs according to its personalized needs, 198 and a more convenient way for the network function providers to 199 provide their software package. Please note that a NSP itself can be 200 the customer of the VNF store. The main motivation for a NSP to 201 become the customer is for its transparent service to its 202 subscribers, for example, traffic optimization, carrier grade NAT and 203 etc. 205 (Note: the authors will add the list of what should be done in the 206 context of NFVCon.) 208 3.2. VNF as a Service (VNFaaS): configuration and management 210 This use case is based on Use case #2: Virtual Network Function as a 211 Service (VNFaaS) described in ETSI GS NFV 001[ETSI_GS_NFV_001] . This 212 use case focuses on the configuration of a virtualized enterprise 213 service, where the VNF is the NSP's application and the enterprise 214 user is the consumer of this service. By making the VNF 215 functionality available to enterprise users as a service is 216 comparable to the cloud computing concept denoted as the Software as 217 a Service (SaaS). According to NIST SP 800-146 [NIST_SP_800-146] 218 SaaS is the possibility for the consumer to use software applications 219 running on a cloud infrastructure. The consumer, however, cannot 220 manage the application only from a configuration perspective and 221 cannot control the underlying infrastructure. 223 The main motivation of specifying such virtualized enterprise service 224 is that rather than that enterprise users invest their own capital in 225 deployment of networking infrastructure, the NSP may be able to 226 provide advanced networking features as a measured service on an 227 expense basis. 229 Several examples of VNFaaS are provided in ETSI GS NFV 230 001[ETSI_GS_NFV_001]. For example, in use case #2: Virtual Network 231 Function as a Service (VNFaaS), the VNFaaS is related to the services 232 that are deployed by enterprise users at the edge of branch offices. 233 Due to the fact that the enterprise users are faced with big required 234 investments, such enterprise users are looking for outsource 235 alternatives, which can be the virtualization of the enterprise CPE 236 (e.g., VFN of an access router) into the NSP's network. In this 237 example the used VNFs are the virtualized CPE and PE (Provider 238 Equiment). In use case #5: Virtualization of Mobile Core and IMS (IP 239 Multimedia Subsystem), the VNFaaS is related to services that are 240 related to the virtualization of the EPC (Evolved Packet Core). The 241 EPC and IMS are standardized by the 3GPP standardization body. In 242 this example the VNFs are the network entities supported by the EPC, 243 such as the MME (Mobility Management Entity), P-GW (Packet Data 244 Network Gateway), S-GW (Serving Gateway), Home Subscriber System 245 (HSS). In this example the VNFaaS is the EPCaaS. 247 Both that VNFaaS provider and enterprise consumer share the 248 responsibility for the management of the VNFaaS. The NSP is 249 responsible for the lifecycle management of the VNFaaS instances to 250 provide the expected service level (SLA) for the subscribers to the 251 VNFaaS. The VNFaaS lifecycle management is similar to the cloud 252 lifecycle management steps. In particular, the EU FP7 project Mobile 253 Cloud Networking (MCN) [MCN], defined the following lifecycle 254 management steps that can also be applied for the VNFaaS lifecycle 255 management: 257 o Design: at this stage the service's technical design is carried 258 out. 260 o Implement: with a service design the service is implemented. 262 o Deploy and provision: The VNF management is deployed and the 263 necessary service instances are starting to be created. o 265 o Runtime and Operation: the created VNF and service instances for 266 each tenant are monitored and managed. It is during this step 267 where scaling in and out of VFNs is carried out. Scaling in 268 occurs when a VFN is releasing resources and scaling out occurs 269 when new resources are allocated to a VFN. 271 o Disposal: the VFNs associated with a service instance are 272 disposed. 274 The enterprise users expect to manage and configure their customer 275 premises entities. 277 The NFVcon can focus on providing the interfaces and protocols 278 required by the network function provider, network service provider 279 and the network function consumer to configure and manage the VNFaaS. 281 Some challenges that need to be solved are: 283 o Appropriate authentication and authorization mechanism are 284 required to support the orchestration of VNF instances. For 285 example only authorized VNF instances are permitted to execute on 286 the NFVI. Moreover, mechanisms should be provided such that VNF 287 instances can only access the physical and virtual terminations to 288 which their access is authorized. 290 o A virtualized environment needs to guarantee complete isolation 291 among the network function consumers. Special considerations are 292 needed for protecting network function consumer data and 293 configuration files. 295 o By providing a VNFaaS as a measured service requires usage 296 measurement metrics and infrastructure appropriate to the type of 297 VNF as well as appropriate Service Level Agreements. VNFaaS usage 298 measurements need the appropriately auditable accounting treatment 299 to be used as basis for service billing arrangements. 301 o Resource scaling: scaling up and down network resources used by 302 VNFs 304 o Service awareness: service aware resource allocation to network 305 functions 307 o State maintenance: Network and network function state management 308 during network function relocation, replication and resource 309 scaling 311 o Appropriate mechanism for monitoring/fault detection/diagnosis 312 of all components and their states after virtualization, e.g., VNF 313 instances, hardware, hypervisor 315 o Traffic control separation mechanism: Data and management 316 traffic identification/separation for non-virtualized and 317 virtualized networks. 319 3.3. VNF as a Platform (VNFaaP): configuration and management 321 This use case is based on Use case #3: Virtual Network Platfom as a 322 Service (VNPaaS) described in ETSI GS NFV 001[ETSI_GS_NFV_001]. This 323 use case focuses on the configuration of a virtualized network 324 platform, where a network service provider makes available a suite of 325 infrastructure and applications as a platform on which the enterprise 326 users can deploy their own network applications. By using this 327 platform, the enterprise users could develop their own network 328 service that is customized to their business purposes. 330 Making the VNF platform available to enterprise users as a service is 331 comparable to the cloud computing concept as a Platform as a Service 332 (PaaS), which is defined in NIST SP 800-146 [NIST_SP_800-146] as 333 follows. PaaS is the possibility for the consumer to use software 334 applications running on a cloud infrastructure. The consumer can 335 control the deployed application, but it cannot control the 336 underlying network or the cloud infrastructure (i.e., the NFVI). 338 In this use case the NSP provides a toolkit of (1) networking and 339 computing infrastructure and (2) potentially some VNFs as a platform, 340 for the creation of a virtual network, denoted as Virtual Network 341 Platform as a Service (VNPaaS). The enterprise consumer uses this 342 toolkit to develop its own virtual network. 344 The VNPaaS is similar to VNFaaS, but it differs mainly on the scope 345 of control provided to the consumer of the service. The VNPaaS is 346 able to provide a larger scale service, which typically will be the 347 provision of a virtual network rather than a single virtual network 348 function. In particular, the VNFaaS is limited to the configuration 349 of a set of VNF instances made available by the NSP, while the VNPaaS 350 provides the possibility to the enterprise consumer to introduce 351 their own VNF instances as well. 353 Several types of services can be supported by a VNPaaS, ranging from 354 a simple firewall service for a single enterprise to a whole business 355 communication suite based on an IMS network for a 3rd party. 357 The NFVcon can focus on providing the interfaces and protocols 358 required by the network function provider, network service provider 359 and the network function consumer to configure and manage the VNPaaS. 361 In addition to the VNFaaS challenges listed in Section 3.3, some 362 additional challenges need to solved: 364 o Access control should be based on an authorized user identity 366 o Infrastructure resources need to provide mechanisms to separate 367 workloads from different network service providers. 369 o Infrastructure resources and network functions support an 370 interface used to monitor, guarantee and limit the usage of the 371 resources by each network service provider. 373 3.4. VNF migration: travel with your NSP "devices" 375 A travelling consumer's experience would be highly improved if he/she 376 found that all their subscribed network devices are also travelling 377 with them automatically/on demand. The portability of VNF-based NSP 378 services is based on VNF migration within the local NSP's data 379 centers or even across different NSPs' domains. 381 +----------------+ 2.vRGW is migrated to a +----------------+ 382 | Haibin's vRGW +----------------------------> Haibin's vRGW | 383 +--------+-------+ data center in Shenzhen +--------+-------+ 384 | | 385 | | 386 Previous | | 387 | | Now 388 | | 389 | | 390 | | 391 +---+--+ 1.Haibin left Nanjing +---+--+ 392 |Haibin+------------------------------------->|Haibin| 393 +------+ and moved to Shenzhen +------+ 395 Nanjing Shenzhen 397 Figure 2. VNF migration 399 As shown in Figure 2, while Haibin moves from Nanjing to Shenzhen, 400 his virtual residential gateway (including DHCP, firewall and ALG 401 functions and etc) is also migrated from Nanjing to Shenzhen. This 402 kind of migration, when compared with the dedicated hardware box 403 residential gateway, can improve the user's experience as he did not 404 lose any data or configuration. 406 Usually it has the following features: 408 o It allows a network function consumer to do migration 409 configuration/subscription for a given VNF; 411 o It allows the local NSP to detect the movement of a travelling 412 consumer and trigger subsequent VNF migration accordingly; 414 o It provides robust authentication mechanism for a roaming user 415 to access a migrated VNF; 417 o It provides clearly stated resource requirement for 418 accommodating a migrated VNF in a visiting datacenter/NSP domain, 419 and provide reliable resource/performance splicing for a migrated 420 VNF against local abuse from bugs/holes in third party developed 421 software. This may not be visible to the NFC, but the SLA will be 422 met during and after the migration. 424 3.5. VNF installation: customizing personal VNFs 426 A NSC may want to customize its VNF instance, to specialize its 427 installation of functional building blocks, with regarding to its own 428 requirements from traffic pattern, service preference, and security/ 429 privacy sensitivity. 431 Take traffic pattern for example, if there is a VNF for censoring the 432 traffic, if the traffic sent to this VNF are video packets, then the 433 NSC may want to install a video censoring function block, e.g. for 434 pornography. If the traffic sent to the VNF is text packets then the 435 user may want to install a text censoring function block. If the 436 traffic is a combination of video and text, then the NSC may need to 437 install another functional block for classification. NFCs do not 438 need to install unnecessary function blocks on their own VNFs. 440 There are also considerations from security or privacy aspects. A 441 website's owner has much more concerns on security protection than an 442 individual subscriber, while a habitual on-line shopper cares much 443 more on privacy protection than a webpage visitor. This also brings 444 different components to be installed on the NFC's VNF. 446 Deployment position considerations can be another advantage of 447 virtualization. 449 The difference between this VNF installation and the traditional 450 dedicated hardware physical network function appliance is that a NFC 451 can customize his VNF and the position of the VNF, and make the VNF 452 run immediately after his requirements are sent to the NFV control 453 plane. 455 (Note: the authors will add the list of what should be done in the 456 context of NFVCon.) 458 3.6. VNF template: common profile for managing multiple VNF instances 460 For enterprise scenario, it is often the case that an IT personnel is 461 responsible for setting up the network access environments for a 462 potentially quite large number of individual employees. Although 463 there maybe variations among employees' requirements and entitlements 464 according to their roles and ranks in the organizational hierarchy, 465 it is expected that by predefining some general applicable VNF 466 templates to capture the common demand for a group and allowing the 467 consumer to apply them to multiple VNF instances simultaneously with 468 a simple command/interface, the management cost would be greatly 469 reduced. This kind of VNF includes the virtual firewall. 471 If there are some exactly same VNFs, the NFV control and management 472 plane (1) can map the same configuration to multiple replicas, 473 without that the NFC needs to know the position of the VNFs, and (2) 474 operates them individually. 476 This use case has the following features: 478 o It allows pre-defined template for VNF configuration; 480 o It allows for template-based VNF group management. 482 (Note: the authors will add the list of what should be done in the 483 context of NFVCon.) 485 3.7. Dynamic resource usage 487 Network function customers may have demand for automatic scale out 488 and scale in for resource usage, and pay for the amount of resource 489 it has used. This is extremely useful when the NFC cannot predict 490 his resource usage or the resource usage is not stable. For example, 491 one enterprise user as a NFC may have much traffic processing load on 492 its VNF(s) during the daytime, but in the night, the NFC does not 493 have any load on its VNF(s). Automatic scale out and scale in can be 494 implemented in different ways, such like automatically generating/ 495 deleting new VNF instances while monitoring the load status. 497 This use case may require the NFC and the NFV control and management 498 plane to negotiate the policy of it. 500 3.8. Service Function Chaining 502 For service function chains, NFC tells the NFV control and management 503 plane about the specific service processing order, to make specific 504 traffic go through that order. The service functions can be inside 505 one VNF, different VNFs in one physical server or different VNFs in 506 different physical servers. The description from the NFC to the NFV 507 control and management plane may include the traffic classification 508 rules, and the service chaining order, and other relative policies. 509 The control and management plane can be agnostic of the service 510 chaining logic, but must be able to pass the right chain description/ 511 policy to the right VNF. 513 4. Security Considerations 515 Network function virtualization may make attacks easier, when using 516 standard IT method to normalize the dedicated network function 517 appliances, and make it easily accessed by the consumers. In 518 particular, the following security considerations need to be taken 519 into account: 521 o Access control should be based on an authorized user identity 523 o Provide robust authentication mechanism for a roaming user to 524 access a migrated VNF 526 o Appropriate authentication and authorization mechanism are 527 required to support the orchestration of VNF instances. For 528 example only authorized VNF instances are permitted to execute on 529 the NFVI. Moreover, mechanisms should be provided such that VNF 530 instances can only access the physical and virtual terminations to 531 which their access is authorized. 533 o A virtualized environment needs to guarantee complete isolation 534 among the network function consumers. Special considerations are 535 needed for protecting network function consumer data and 536 configuration files. 538 5. Acknowledgement 540 Thanks to Diego Lopez for his valuable comments to this document. 541 And thanks to the people who joined the succesful side meeting 542 discussion, some of the ideas are from the discussion. The main 543 people are: Diego Lopez, Mehmet Ersue, Melinda Shore, Juergen 544 Schoenwaelder, Jiang Yuanlong, Cathy Zhou, Zhen Cao,Hui Deng, 545 Georgios Karagian, Evangelos Haleplidis, Deng Lingli, Kostas 546 Pentikousis, Michael Scharf. 548 6. References 550 6.1. Normative References 552 [I-D.zhou-opsawg-vnf-config-arch] 553 Zhou, H., Song, H., and F. Qiao, "Virtual Network Function 554 Configuration Architecture", draft-zhou-opsawg-vnf-config- 555 arch-00 (work in progress), September 2013. 557 6.2. Informative References 559 [ETSI_GS_NFV_001] 560 "Network Functions Virtualisation (NFV); Use Cases", ETSI 561 GS NFV specification Network Functions Virtualisation 562 (NFV) ETSI ISG, ETSI GS NFV 001, v1.1.1, October 2013. 564 [ETSI_GS_NFV_003] 565 "Network Function Virtualisation (NFV); Terminology for 566 Main Concepts in NFV", ETSI GS NFV specification Network 567 Function VIrtualisation (NFV) ETSI ISG, ETSI GS NFV 003, 568 v1.1.1, Oct 2013. 570 [NIST_SP_800-146] 571 "Draft Cloud Computing Synopsis and recommendations", NIST 572 specifications , May 2011. 574 Authors' Addresses 576 Deng Lingli 577 China Mobile 579 Email: denglingli@chinamobile.com 581 Haibin Song 582 Huawei 584 Email: haibin.song@huawei.com 586 Georgios Karagian 587 U. of Twente 589 Email: karagian@cs.utwente.nl 591 Evangelos Haleplidis 592 U. of Patras 594 Email: ehalep@gmail.com 596 Barbara Martini 597 CNIT 599 Email: barbara.martini@cnit.it