idnits 2.17.1 draft-zu-nfvrg-elasticity-vnf-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: ---------------------------------------------------------------------------- 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 (March 2, 2015) is 3343 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2234' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force (IRTF) Z. Qiang 2 Internet Draft Robert Szabo 3 Intended status: Informational Ericsson 4 Expires: September 2015 March 2, 2015 6 Elasticity VNF 7 draft-zu-nfvrg-elasticity-vnf-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This document may contain material from IETF Documents or IETF 15 Contributions published or made publicly available before November 16 10, 2008. The person(s) controlling the copyright in some of this 17 material may not have granted the IETF Trust the right to allow 18 modifications of such material outside the IETF Standards Process. 19 Without obtaining an adequate license from the person(s) controlling 20 the copyright in such materials, this document may not be modified 21 outside the IETF Standards Process, and derivative works of it may 22 not be created outside the IETF Standards Process, except to format 23 it for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on September 3, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 This draft is an analysis of Network Function Virtualization (NFV) 62 applications based on the NFV architecture, use cases and 63 requirements. The purpose of this analysis is to identify any NFV 64 characteristics related issues. The analysis is focusing on elastic 65 VNF with predicable performance, reliability and security. Only the 66 issues which are unique to NFV are discussed in this document. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Conventions used in this document..............................3 72 3. Terminology....................................................4 73 4. Network Function Virtualization................................5 74 4.1. NFV Requirements..........................................5 75 4.2. NFV Use Cases.............................................6 76 4.2.1. Network Function Virtualization Infrastructure.......6 77 4.2.2. Telecom Network Functions Migration..................7 78 5. Elasticity in a Distributed Cloud..............................7 79 5.1. NFV Infrastructure........................................8 80 5.2. Elastic VNF...............................................8 81 5.3. VNF Forwarding Graphs.....................................9 82 5.4. VNF scaling across multiple NFVI PoPs....................10 83 6. Elasticity with Predicable Performance........................10 84 6.1. Predicable Performance...................................10 85 6.2. Hardware virtualization features.........................11 86 6.3. Network Overlay..........................................12 87 7. Elasticity with Reliability...................................12 88 8. Elasticity with Security......................................13 89 9. Security Considerations.......................................13 90 10. IANA Considerations..........................................13 91 11. References...................................................13 92 11.1. Normative References....................................13 93 11.2. Informative References..................................13 94 12. Acknowledgments..............................................14 96 1. Introduction 98 Network Functions Virtualization (NFV) is a network architecture 99 concept that proposes using IT virtualization related technologies, 100 to virtualize entire classes of network node functions into building 101 blocks that may be connected, or chained, together to create 102 communication services. NFV aims to transform the traditional 103 operator architect networks by evolving standard IT virtualization 104 technology to consolidate network equipment types onto industry 105 standard high volume services, switches and storage, which could be 106 located in a variety of NFV Infrastructure Point of Presences (NFVI 107 PoPs) including Data Center (DC), network nodes and in end user 108 premises. It is also indicated that an important part of controlling 109 the NFV environment should be done through automation network 110 management and orchestration. 112 This draft is an analysis of NFV applications based on the NFV 113 architecture, use cases and requirements. The purpose of this 114 analysis is to identify any NFV characteristics related issues. The 115 analysis is focusing on elastic VNFs with predicable performance, 116 reliability and security. Only the issues which are unique to NFV 117 are discussed in this document. The intention is to identify what is 118 missing, and what is needed to be addressed in terms of protocol / 119 solution specifications which may be the potential work for IETF. 121 The reader is assumed to be familiar with the terminology as defined 122 in the NFV document [nfv-tem]. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119 [RFC2119]. 130 In this document, these words will appear with that interpretation 131 only when in ALL CAPS. Lower case uses of these words are not to be 132 interpreted as carrying RFC-2119 significance. 134 3. Terminology 136 This document uses the same terminology as found in the NFV end to 137 end architecture [nfv-tem]: 139 Network Function Consumer: a Network Function Consumer (NFC) is the 140 consumer of virtual network functions. It can be either an 141 individual user, home user or the enterprise user. 143 NFV: network function virtualization. NFV technology uses the 144 commodity servers to replace the dedicated hardware boxes for the 145 network functions, for example, home gateway, enterprise access 146 router, carrier grade NAT and etc. So as to improve the 147 reusability, allow more vendors into the market, and reduce time to 148 market. NFV architecture includes a NFV Control and Management Plane 149 (orchestrator) to manage the virtual network functions and the 150 infrastructure resources. 152 NF: A functional building block within an operator's network 153 infrastructure, which has well-defined external interfaces and a 154 well-defined functional behavior. Note that the totality of all 155 network functions constitutes the entire network and services 156 infrastructure of an operator/service provider. In practical terms, 157 a Network Function is today often a network node or physical 158 appliance. 160 Network Function Provider: a Network Function Provider (NFP) 161 provides virtual network function software. 163 Network Service Provider (NSP): a company or organization that 164 provides a network service on a commercial basis to third parties. A 165 network service is a composition of network functions and defined by 166 its functional and behavior specification. The NSP operates the NFV 167 Control Plane. 169 NFV Infrastructure (NFVI): NFV Infrastructure indicates the 170 computing, storage and network resources to implement the virtual 171 network function. High performance acceleration platform is also 172 part of it. 174 VNF: virtual network function, an implementation of an executable 175 software program that constitutes the whole or a part of an NF that 176 can be deployed on a virtualization infrastructure. 178 VM: virtual machines, a program and configuration of part of a host 179 computer server. Note that the Virtual Machine inherits the 180 properties of its host computer server e.g. location, network 181 interfaces. 183 NFV Control and Management Plane (NFVCMP): a NFV Control and 184 Management Plane is operated by a NSP and orchestrates the NFV NFV 185 Overview 187 4. Network Function Virtualization 189 4.1. NFV Requirements 191 There are many virtualization requirements described by NFV in [nfv- 192 req]. The followings are highlights of a few NFV requirements which 193 are related to this document: 195 - Portability: VNF portability is a reasonable generic 196 virtualization requirement. It allows VNF mobility across 197 different but standard multi-vendor environment. However, moving a 198 VNF within the NFV framework with the Service Level Specification 199 (SLA) requirements including performance, reliability and security 200 could be a challenge. 201 - Performance: Virtualization adds additional processing overhead 202 and increases the latency. For latency-sensitive VNFs, it is a big 203 concern for NFV on how to achieve predictable low-latency 204 performance. 205 - Elasticity: NFV elasticity requirement allows the VNF to be scaled 206 within NFVI. Within the NFV framework, it is important to support 207 VNF scaling with the SLA requirements including performance, 208 reliability and security. 209 - Resiliency: NFV resiliency is a must requirement for NFV network, 210 including both the control plane and data plane. Necessary 211 mechanisms must be provided to improve the service availability 212 and fault management. 213 - Security: The traditional telecom network functions are developed 214 in dedicated hardware located in an isolated network. Security is 215 provided by underlay network. When moving VNF into a DC network 216 with shared Infrastructure, security becomes a big concern. 217 - Service Continuity: At VNF failure over, migration, mobility, and 218 upgrading, service downtime may not be avoided. In NFV, service 219 continuity must be supported which means the provided service must 220 be restored at the VNF instance updated / replaced / recovered. 221 This procedure includes the restoration of any ongoing data 222 sessions. And it shall be transparent to the user of NFV service. 224 4.2. NFV Use Cases 226 Multiple use cases are described by NFV in [nfv-uc]. The followings 227 are a highlight of the NFV use cases. 229 4.2.1. Network Function Virtualization Infrastructure 231 Network Function Virtualization Infrastructure as a Service 232 (NFVIaaS), Virtual Network Function as a Service (VNFaaS) and 233 Virtual Network Platform as a Service (VNPaaS) are the NFV use cases 234 which describe how the telecom operators would like to build up 235 their telecom cloud infrastructure using virtualization. 237 Network Function Virtualization Infrastructure (NFVI) is the 238 totality of all hardware and software components which build up the 239 environment in which VNFs are deployed. The NFVI can span across 240 several locations. The network providing connectivity between these 241 locations is regarded to be part of the NFVI. 243 NFVIaaS is a generic IaaS plus NaaS requirement which allows the 244 telecom operator to build up a VNF cloud on top of their own DCs 245 Infrastructure and any external DCs Infrastructure. This will allow 246 a telecom operator to migrate some of its network functions into a 247 3rd party DC when it is needed. Furthermore, a larger telecom 248 operator may have multiple DCs in different geography locations. The 249 operator may want to setup multiple virtual data center (vDC), where 250 each vDC may cross several of its physical DCs geography locations. 251 Each vDC is defined for providing one specific function, e.g. Telco 252 Cloud. 254 VNFaaS is more focusing on enterprise network which may have its own 255 cloud infrastructure with some specific services / applications 256 running. VNFaaS allows the enterprise to merge and/or extend its 257 specific services / applications into a 3rd party commercial DC 258 provided by a telecom operator. With this VNFaaS, the enterprise 259 does not need to manage and control the NFVI or the VNF. However, 260 NFV Performance & portability considerations will apply to 261 deployments that strive to meet high performance and low latency 262 considerations. 263 With VNPaaS, the mobile network traffic, including WiFi traffic, is 264 routed based on the APN to a specific packet data service server 265 over the mobile packet core network. Applications running at the 266 packet data service server may be provided by the enterprise. And it 267 is possible to have an interface to route the traffic into an 268 enterprise network. But the infrastructure hosting the application 269 is fully under controlled by the operator. However, the enterprise 270 has full admin control of the application and needs to apply all 271 configurations on its own, potentially via a vDC like management 272 interface with support of the hosting operator. 274 All the above use cases need solutions for the operator to share the 275 infrastructure resources with 3rd parties. Therefore cross domain 276 orchestration with access control is needed. Besides, the 277 infrastructure resource management needs to provide a mechanism to 278 isolate the traffic, not only based on the traffic type, but also 279 from different operators and enterprises. 281 4.2.2. Telecom Network Functions Migration 283 Virtualization of telecom network functions, including Mobile Core 284 Network functions, IMS functions, Mobile base station functions, 285 Content Delivery Networks (CDN) functions, Home Environment 286 functions, and Fixed Access Network functions, are described in the 287 NFV use case document [nfv-uc]. In additional, VNF forwarding Graphs 288 is another use case which describes how the user data packets are 289 forwarded by traversing more than one operator service chain 290 functions, such as DPI, Firewall, Content Filtering, before reaching 291 the service server. 292 Migrate the telecom functions includes moving the control plane, 293 data plane and service network into a cloud based network and using 294 cloud based protocol to control the data plane. Service continuity, 295 network security, service availability, resiliency in both control 296 plane and data plane must be ensured at this migration. 298 5. Elasticity in a Distributed Cloud 300 Today the usage of personal devices, e.g. smartphones, for internet 301 service traffic, telecom specific service access, and accessing the 302 corporate network, is increased significantly. At the same time, 303 telecom operators are under pressure to accommodate the increased 304 service traffic in a fine-grained manner. Services provided by 305 telecom network must be done in an environment of increased 306 security, compliance, and auditing requirements, along with traffic 307 load may be changed dramatically overtime. Providing self-service 308 provisioning in telecom cloud requires elastic scaling of the VNF 309 based on the dynamic service traffic load and resource management 310 e.g. computing, storage, and networking. 312 The existing telecom network functions may not be cloud technologies 313 ready yet. Most of the NFV functions are stateful and running on 314 either specific hardware or a big VM. It is not designed to tolerate 315 any system failure in many VMs. The network functions are very 316 difficult in term of configuration, scale updating, etc. 318 Re-engineering may be needed for virtualization enabling, e.g. 319 software adaption for software and hardware decoupling. For cloud 320 technologies readiness, telecom network functions need to be re- 321 designed to run on small VMs with multiple instances which can 322 provide higher application availability. Such VMs may be stateless 323 in operations or may need to support state migration (e.g., OpenNF 324 http://opennf.cs.wisc.edu/). With cloud ready network functions, 325 applications' dynamic scaling can be achieved by adding more VMs 326 into the service. 328 Virtualization provides the elasticity ability to scale up / down, 329 scale out / in with guaranteed computational resources, security 330 isolation and API access for provisioning it all, without any of the 331 overhead of managing physical servers. However, there are still many 332 optimizations which can be used to avoid the increasingly overhead. 334 5.1. NFV Infrastructure 336 Virtualized Network Function (VNF) is an implementation of a network 337 function that can be deployed on Network Function Virtualization 338 Infrastructure (NFVI). 340 For a large telecom operator, multiple NFVI Point of Presences (NFVI 341 PoPs) may be created according to multiple physical data centers. As 342 NFVI PoPs may be located in different geography locations, 343 networking characteristics should be taken into account when 344 selecting an NFVI PoP to host a VNF. 346 5.2. Elastic VNF 348 In many cases, a VNF may not be designed for scaling up/down. As 349 scaling up/down may require a restart of the VNF which the state 350 data may be lost. In that case either stateless operation is needed, 351 or the support of state information migration procedure is required, 352 which will increase the complexities of the VNF implementation. 354 Normally a VNF may be capable for scaling in/out only. Such VNF is 355 designed running on top of a small VM and grouped as a pool of one 356 VNF function. 358 VNF capacity may be limited if it only can be scaled within one NFVI 359 PoP, e.g., within one DC in a geography location. As an NFVI which 360 may be crossing multiple NFVI PoPs (or data center)s, it is possible 361 to scale an elastic VNF crossing different network zones if it is 362 needed. At cross DC scaling, the result is that the new VNF instance 363 may be placed at a remote cloud location. It is a must requirement 364 to provide the same level of SLA including performance, reliability 365 and security. 367 5.3. VNF Forwarding Graphs 369 In NFV network, a VNF Forwarding Graph (VNF FG) (an application) may 370 consist of multiple VNFs, where each VNF may consist of multiple VNF 371 instances. Normally the VNFs are working as such that the services 372 provided by the VNFs may need to process the user data packets with 373 several selected VNF instances before delivering it to its 374 destination 376 For instance, when mobile users setup a PDN connection for IMS 377 services, there are multiple network entities involved along the PDN 378 connection, including eNB, Serving GW, PDN GW, P-CSCF, S-CSCF, etc. 379 Another example is service function chaining, where a service chain 380 is referring to one or more service processing functions in a 381 specific order which are chained to provide a composite service. 383 In telecom cloud, a service session may traverse multiple stateful 384 and stateless VNF functions of a VNF set. And with an NFVI 385 consisting of multiple NFVI PoPs, it may be crossing multiple DCs. 386 In such cloud, an incoming data packet may be processed by multi-VNF 387 instance before delivering to the final destination. Therefore the 388 east-west traffic (i.e. data traffic between VNFs within the DC) is 389 much heavier comparing to the north-south traffic (i.e. data traffic 390 in/out from the DC). 391 When placing VNF Forwarding Graphs, it is better spread the VNF 392 components across many NFVI PoPs, which may give a better 393 availability. However, multiple NFVI PoPs may also increases the 394 network latency, which can be considerably big compared to latencies 395 within a single NFVI PoP. Therefore, the whole VNF Forwarding Graph 396 should be taken into account instead of a single VNF component 397 during orchestration. Furthermore, during VNF scaling, dependencies 398 (interconnection) with other service instances of the VNF Forwarding 399 Graph shall also be considered. 401 When scaling, VNFs are not scaled only in relation to compute and 402 storage PoPs. VNF instances may need to be grouped together 403 according to the VNF FG and subjected to auto-scaling techniques to 404 the entire group. The scaling policies, e.g., ratio between the 405 different VNFs, need to be applied on the VNF FG in aggregate to 406 control the scaling process. 407 5.4. VNF scaling across multiple NFVI PoPs 409 Since in general, a VNF is part of a VNF Forwarding Graph (or a 410 service function chain), meaning the data traffic may traverse 411 multiple stateful and stateless VNF functions in sequence. When some 412 VNF instances of a given service function chain are placed / scaled 413 out in a distant cloud execution, the service traffic may have to 414 traverse multiple VNF instances which are located in multiple 415 physical locations. In the worst case, the data traffic may ping- 416 pong between multiple physical locations. 418 Therefore it is important to take the whole service function chain's 419 performance into consideration when placing and scaling one of its 420 VNF instance. Network and cloud resources need mutual considerations 421 [unify1]. 423 | Incoming traffic 424 +-----+------------+ +--------------------+ 425 | | NFVI-PoP1 | | NFVI-PoP2 | 426 | V | | +-------+ | 427 | +-------+ +----+ +----+ | VNF-2 | | 428 | | VNF-1 +----->| GW |----->| GW |----->| | | 429 | +-------+ | | | | | | | 430 | +--| |<-----| |<-----| | | 431 | +-------+ | +----+ +----+ +-------+ | 432 | | VNF-3 | <-+ | | | 433 | +-------+ | | | 434 | | | | | 435 +-----+------------+ +--------------------+ 436 | 437 V outgoing traffic 438 Figure 1 a data traffic flow traversing distributed VNF cloud 440 6. Elasticity with Predicable Performance 442 6.1. Predicable Performance 444 High performance with low-latency VNF is expected in the NFV 445 framework. The NFVI metrics are related to any kind of metrics 446 generated by the NFVI, including not only CPU load on a VM, CPU load 447 on a host, but also interrupt rate handled by the hypervisor or 448 network latency/packet loss. 450 Virtualization adds additional overhead which impacts the 451 performance. This additional extra distortion shall be avoided or, 452 at least, minimized. It is a big concern for NFV on how to achieve 453 predictable and low-latency performance, not only at placing a VNF 454 into the DC, but also at VNF scaling. 456 Operator may wish to run standard test and use the result to provide 457 KPIs of the VNF. A significant part of a VNF vendor's performance 458 guarantees will depend on the choice of the virtualization 459 technology. 460 Network latency may not be at the same level if the physical 461 connections between the servers are various. Furthermore, geography 462 location of the physical servers also increases the network latency. 463 When placing or moving a VNF, the location of other VNFs of the same 464 VNF set shall be considered to avoid network latency issue. For 465 instance, VNF-a, VNF-b, and VND-c are grouped as one VNF set. When 466 moving VNF-b into a new location, the network connection between the 467 new location and the existing location may be a concern. As the 468 traffic may traverse from VNF-a to VNF-b, then VND-c, moving the 469 VNF-b into a new location may create Ping-Pong type of traffic, 470 which the network latency may be doubled. The best choice would be 471 to move the whole VNF set into the new location instead of only one 472 VNF. 473 6.2. Hardware virtualization features 475 Virtualization layer adds minimal overhead and delivers a 476 predictable performance between a minimum and maximum threshold for 477 latency and jitter which are far more important. Light weight 478 virtualization, e.g. container or bare metal, may be considered for 479 performance sensitive VNF applications. In additional, hardware 480 virtualization features (e.g. SR-IOV) are important to be supported 481 in order to provide some performance improvement. Many VNF requires 482 direct access to the device hardware so that they can offload 483 functionality with throughput rates of millions of packets a second. 484 Another alternative, which may be more attractive for latency- 485 sensitive applications, is using and non-hypervisor virtualization, 486 including bare metal and Linux container. 487 Optimization to drive high-throughput network workloads associated 488 with such functions as traffic filtering, NATing and firewalling. 489 Avoiding performance bottleneck, the virtualization layer shall have 490 a suitably-architected I/O stack. 492 6.3. Network Overlay 494 Network overlay adds additional overhead when forwarding the data 495 packets. Reference [vxlan-p] is a VXLAN performance testing report 496 which indicates the overlay performance is a concern. Avoiding 497 overlay connections may be one option which is more attractive for 498 latency-sensitive applications. 500 Furthermore, additional network latency may be added when traversing 501 the cross-DC overlay connections. To avoid any additional network 502 latency, all the functions of a VNF set may be placed in the same 503 low-latency network zone, e.g. same host or same DC. However, when 504 the capacity limitation the network zone is reached, scaling-out one 505 VNF into another network zone may be needed. In this case, as the 506 service session has to traverse the same path, the Ping-Pong traffic 507 between the network zones cannot be avoided. Depends on the network 508 overlay technologies used for the cross network zone connection, the 509 overhead network latency can be various. In another words, the 510 network performance may become unpredictable. 511 7. Elasticity with Reliability 513 NFV resiliency is a must requirement for NFV network, including both 514 the control plane and data plane. Necessary mechanisms must be 515 provided to improve the service availability and fault management. 517 With virtualization, the use of VNFs can pose additional challenges 518 on the reliability of the provided services. For a VNF instance, it 519 typically would not have built-in reliability mechanisms on its host 520 (i.e., a general purpose server). Instead, there are more factors 521 of risk such as software failure at various levels including 522 hypervisors and virtual machines, hardware failure, and instance 523 migration that may make a VNF instance unreliable. Even for cloud 524 ready NFV applications, a HA may still be needed as the storage, 525 load balancer may be failure. Service restoration solution is still 526 needed. 528 One alternative to improve the VNF resiliency is to take snapshot of 529 the VM periodically. At VNF failure, the network can restore the VM 530 at same or different host using the stored snapshot. However, there 531 is a downtime of the provided service due to the snapshot 532 recovering. And the downtime is much longer than the expected value 533 which could be tolerated by NFV. NFV has a completely different 534 level of reliability requirements, e.g. recovering time, comparing 535 to enterprise cloud applications. 537 To improve the network function resiliency, some kind high 538 availability (HA) solutions may be needed for NFV network, which has 539 the potential to minimize the service downtime at failure. However, 540 in most of the telecom use cases, there are application level 541 restoration procedures available which makes the high availability 542 solution less important. 544 The VNF reliability can be achieved by eliminating any single points 545 of failure by creating a redundancy of resources, normally, 546 including enough excess capacity in the design to compensate for the 547 performance decline and even failure of individual resources; that 548 is, a group of VNF instances providing the same function works as a 549 network function cluster or pool, which provides protection (e.g. 550 failover) for the applications and therefore an increased 551 availability. 553 8. Elasticity with Security 555 TDB 557 9. Security Considerations 559 This is a discussion paper which provides inputs for NFV related 560 discussions and in itself does not introduce any new security 561 concerns. 562 10. IANA Considerations 564 No actions are required from IANA for this informational document. 565 11. References 567 11.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 573 Syntax Specifications: ABNF", RFC 2234, Internet Mail 574 Consortium and Demon Internet Ltd., November 1997. 576 11.2. Informative References 578 [nfv-arch] Network Functions Virtualization Infrastructure 579 Architecture Overview; GS NFV INF 001. 581 [nfv-rel] Network Function Virtualization (NFV) Resiliency 582 Requirements; ETSI GS NFV-REL 001. 584 [nfv-uc] Network Function Virtualization (NFV) Use Cases; ETSI GS 585 NFV 001 587 [nfv-req] Network Function Virtualization (NFV) Virtualization 588 Requirements; ETSI GS NFV 004 590 [nfv-sec] Network Function Virtualization (NFV) NFV Security Problem 591 Statement; ETSI NFV-SEC 001 593 [nfv-tem] Network Function Virtualization (NFV) Terminology for Main 594 Concepts in NFV; ETSI GS NFV 003 596 [vxlan-p] Problem Statement for VxLAN Performance Test, draft-liu- 597 nvo3-ps-vxlan-perfomance, (working in progress) 599 [unify1] Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., and D. 600 Daino, "Unifying Carrier and Cloud Networks: Problem 601 Statement and Challenges", draft-unify-nfvrg-challenges-00 602 (work in progress), October 2014. 604 12. Acknowledgments 606 Many people have contributed to the development of this document and 607 many more will probably do so before we are done with it. While we 608 cannot thank all contributors, some have played an especially 609 prominent role. The following have provided essential input: Suresh 610 Krishnan. 612 Authors' Addresses 613 Zu Qiang 614 Ericsson 615 8400, boul. Decarie 616 Ville Mont-Royal, QC, 617 Canada 619 Email: Zu.Qiang@Ericsson.com 621 Robert Szabo 622 Ericsson Research, Hungary 623 Irinyi Jozsef u. 4-20 624 Budapest 1117 625 Hungary 626 Email: robert.szabo@ericsson.com 627 URI: http://www.ericsson.com/