idnits 2.17.1 draft-bernini-nfvrg-vnf-orchestration-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 date (October 4, 2016) is 2758 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.zong-vnfpool-problem-statement' is defined on line 646, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-05 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFV Research Group G. Bernini 3 Internet-Draft G. Landi 4 Intended status: Informational Nextworks 5 Expires: April 7, 2017 D. Lopez 6 P. Aranda Gutierrez 7 Telefonica 8 October 4, 2016 10 VNF Pool Orchestration For Automated Resiliency in Service Chains 11 draft-bernini-nfvrg-vnf-orchestration-03 13 Abstract 15 Network Function Virtualisation (NFV) aims at evolving the way 16 network operators design, deploy and provision their networks by 17 leveraging on standard IT virtualisation technologies to move and 18 consolidate a wide range of network functions and services onto 19 industry standard high volume servers, switches and storage. The 20 primary target for operators, stimulated by the recent updates on NFV 21 and SDN, is the network edge. In fact, operators are considering 22 their future datacentres and Points of Presence (PoPs) as 23 increasingly dynamic infrastructures where Virtualised Network 24 Functions (VNFs) and on-demand chained services with high elasticity 25 will be deployed. 27 This document presents an orchestration framework for automated 28 deployment of highly available VNF chains. Resiliency of VNFs and 29 chained services is a key requirement for operators to improve, ease, 30 automate and speed up services lifecycle management. The proposed 31 VNFs orchestration framework is also positioned with respect to 32 current NFV and Service Function Chaining (SFC) architectures and 33 solutions. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 7, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. VNF Pool Orchestration for Resilient Virtual Appliances . . . 4 71 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Orchestration Framework . . . . . . . . . . . . . . . . . 6 73 3.2.1. Orchestrator . . . . . . . . . . . . . . . . . . . . 8 74 3.2.2. SDN Controller . . . . . . . . . . . . . . . . . . . 8 75 3.2.3. Service Function Path Manager . . . . . . . . . . . . 9 76 3.2.4. Edge Configurator . . . . . . . . . . . . . . . . . . 10 77 3.3. Resiliency Control Functions for Chained VNFs . . . . . . 10 78 4. Positioning in Existing NFV and SFC Frameworks . . . . . . . 12 79 4.1. Mapping into NFV Architecture . . . . . . . . . . . . . . 12 80 4.2. Mapping into SFC Architecture . . . . . . . . . . . . . . 13 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 8.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 Current Telco infrastructures are facing the rapid development of the 92 cloud market, which includes a broad range of emerging virtualised 93 services and distributed applications. Network Function 94 Virtualisation (NFV) is gaining wide interest across operators as a 95 means to evolve the way networks are operated and provisioned, with 96 network functions and services traditionally integrated in hardware 97 devices executed in virtualised environments. 99 A Virtualised Network Function (VNF) provides the same function as 100 its non virtualised equivalent (e.g. firewall, load balancer) but is 101 deployed as a software instance running on general purpose servers 102 using virtualisation technologies. The main idea, therefore, is to 103 run network functions in datacentres or commodity network nodes that 104 are, in some cases, close to the end user premises. With NFV, 105 network functions are moved from specialised hardware devices to 106 self-contained virtual machines running in general purpose servers. 107 These virtualised functions can be deployed in multiple instances or 108 moved to various locations in the network, adapting themselves to 109 traffic dynamicity and customer demands without the overhead cost and 110 management of installing new equipment. 112 Operator networks are populated with a large and increasing variety 113 of proprietary software and hardware tools and appliances. The 114 deployment of new network services in operational environments is 115 often a complex and costly procedure, where additional physical space 116 and power are required to accommodate new boxes. Additionally, 117 current hardware-based appliances rapidly reach end of life. This 118 requires that much of the design integration and deployment cycle be 119 repeated with little revenue benefit. In this context, the 120 transition of network functions and appliances from hardware to 121 software solutions by means of NFV promises to address and overcome 122 these hindrances for network operators. 124 The considerations above are valid for stand-alone VNFs running 125 independently. However, additional challenges and requirements raise 126 for network operators when services offered to customers are built by 127 the composition of multiple VNFs. In this case, the deployment and 128 provisioning of each (virtual) service component for the customer 129 needs to be coordinated with the other VNFs, applying control 130 functions to steer the traffic through them following a predefined 131 order (i.e. according to the specific service function path). An 132 orchestration framework capable of coordinating the automated 133 deployment, configuration, provisioning and chaining of multiple VNFs 134 would ease the management of the whole lifecycle of services offered 135 to customers. Additionally, when dealing with virtualised functions, 136 resiliency and high availability of chained services pose additional 137 requirements for a VNF orchestration framework, in terms of detection 138 of software failures at various levels (including hypervisors and 139 virtual machines, hardware failure), and dynamic and intellingent 140 reaction (virtual appliance migration, deployment of new VNFs, re- 141 adapt the VNF chain). 143 This document presents an orchestration framework for automated 144 deployment of high available VNF chains, and introduces its 145 architecture and building blocks. Resiliency for both stand-alone 146 VNFs and chained services is considered in this document as a key 147 control function based on VNF pool concepts. The proposed VNF pool 148 orchestration framework is also positioned with respect to approaches 149 and architectures currently defined for Network Function 150 Virtualisation and Service Function Chaining (SFC). 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 The following acronyms are used in this document: 160 NFV: Network Function Virtualisation. 162 SDN: Software Defined Networking. 164 VNF: Virtualised Network Function. 166 SFC: Service Function Chaining. 168 CPE: Customer Premise Equipment. 170 VPN: Virtual Private Network. 172 EMS: Element Management System. 174 PoP: Point of Presence. 176 VM: Virtual Machine. 178 3. VNF Pool Orchestration for Resilient Virtual Appliances 180 The telco market is rapidly moving towards an "Everything as a 181 Service" model, where the virtualisation of traditionally in-the-box 182 network functions can benefit from Software Defined Networking (SDN) 183 tools and technologies. As said, the recent updates and proposed 184 solutions on NFV and SDN is practically bringing, from an operator 185 perspective, a deep evolution on how the network edge is architected, 186 operated and provisioned, since that is the place where VNFs and 187 virtual services can be deployed and provisioned close to the 188 customers. Operators target to evolve their datacentres and PoPs 189 into increasingly dynamic infrastructures where VNFs and chained 190 services can be deployed with high availability and high elasticity 191 to scale up and down while optimizing performances and resources 192 utilization. 194 This section introduces the VNF pool orchestration framework for the 195 deployment, provisioning and chaining of resilient virtual appliances 196 and services within operator data-centres proposed in this document. 198 3.1. Problem Statement 200 The orchestration framework proposed in this document aims at solving 201 some of the challenges that operators face when, trying to apply the 202 base NFV concepts, they replace hardware devices implementing well- 203 known network functions with software-based virtual appliances. In 204 particular, this VNF orchestration framework targets an automated, 205 flexible and elastic provisioning of service chains within operators' 206 datacentres. 208 When operators need to compose and chain multiple VNFs to provision a 209 given service to the customer, they need to operate network and 210 computing resources in a coordinated way, and above all to implement 211 control mechanisms and procedures to steer the traffic through the 212 different VNFs and the customer sites. As an example, the 213 virtualisation of the Customer Premises Equipment (CPE) is emerging 214 as one of the first applications of the Network Functions 215 Virtualisation (NFV) architecture that is currently being 216 commercialized by several software (and hardware) vendors. It has 217 the potential to generate a significant impact on the operators 218 businesses. The term virtual CPE (vCPE) refers to the execution in a 219 virtual environment of the network functions that traditionally 220 integrated in hardware gears at customer premises, like BGP speakers, 221 firewall, NAT, etc. 223 Different scenarios and use cases exist for the vCPE. Currently, the 224 typical scenario is the vCPE in the PoP, that actually provides 225 softwarization and shift to the first PoP of the operator for those 226 network functions normally deployed at customer premises (e.g. NAT, 227 Firewall, etc.). The goal is to manage the whole LAN environment of 228 the customer, while preserving QoE of its services, providing added 229 value services to users not willing to get involved with technology 230 issues, and reducing maintenance trouble tickets and the need for in- 231 house problem solving. In addition, the vCPE can be used in the 232 operator's datacenter to implement in software those chained network 233 functions to provision automated VPN services for customers 234 [VCPE-T2], in order to dynamically and automatically extend existing 235 L3 VPNs (e.g. connecting remote customer sites) to incorporate new 236 virtual assets (like virtual machines) into a private cloud. 238 As additional requirements for the proposed orchestration framework, 239 the use of VNFs opens new challenges concerning the reliability of 240 provided virtual services. When network functions are deployed on 241 monolithic hardware platforms, the lifecycle of individual services 242 is strictly bound to the availability of the physical device, and 243 management tools may detect outages and migrate affected services to 244 new instances deployed on backup hardware. When introducing VNFs, 245 individual network functions may still fail, but with more risk 246 factors such as software failure at various levels, including 247 hypervisors and virtual machines, hardware failure, and virtual 248 appliance migration. Moreover, when considering chains of VNFs, the 249 management and control tools used by the operators have to consider 250 and apply reliability mechanisms at the service level, including 251 transparent migration to backup VNFs and synchronization of state 252 information. In this context, VNF pooling mechanisms and concepts 253 are valid and applicable, thus considering VNF instances grouped as 254 pools to provide the same function in a reliable way. 256 3.2. Orchestration Framework 258 The VNF pool orchestration framework proposed in this document aims 259 to provide automated functions for the deployment, provisioning and 260 composition of resilient VNFs within operators' datacentres. 261 Figure Figure 1 presents the high level architecture, including 262 building blocks and functional components. 264 This VNF pool orchestration framework is built around two key 265 components: the orchestrator and the SDN controller. The 266 orchestrator includes all the functions related to the management, 267 coordination, and control of VNFs instantiation, configuration and 268 composition. It is the component at the highest level of the 269 architecture and represents the access point to the VNF pool 270 orchestration framework for the operator. On the other hand, the SDN 271 controller provides dynamic traffic steering and flexible network 272 provisioning within the datacenter as needed by the VNF chains. The 273 basic controller functions are augmented by a set of enhanced network 274 applications deployed on top, that might be themselves control and 275 management VNFs for operator use (i.e. not related to customers and 276 users functions). 278 Therefore, the architecture depicted in Figure Figure 1 is a 279 practical demonstration of how SDN and NFV technologies and concepts 280 can be integrated to provide substantial benefits to network 281 operators in terms of robustness, ease of management, control and 282 provisioning of their network infrastructures and services. SDN and 283 NFV are clearly complementary solutions for enabling virtualisation 284 of network infrastructures, services and functions while supporting 285 dynamic and flexible network traffic engineering. 287 +----------------------------------------------+ 288 | Orchestrator | 289 +-----+----------------+----------------+------+ 290 | | | 291 V V V 292 +------------+ +-------------+ +-------------+ 293 | | | | | | 294 | VNF Pool | | Service Fcn | | Edge | 295 | Manager | | Path Mgr | |Configurator | 296 | | | | | | 297 +-----+------+ +------+------+ +------+------+ 298 | | | 299 V V V 300 +----------------------------------------------+ 301 | SDN Controller | 302 +--------------+---+----+---------------+------+ 303 +.......................+ | | | | 304 : +--------+ \ | | | +-----+ 305 : |+-------++ :| +-----+---+----+----+ | 306 : +| || :\ | +-----------------+-+ +---+----+ 307 : /|| VNF1 || : | | | +---------------+-+-+ | | 308 : / || || :..+ | | | Virtual | | +-------+ Edge | 309 : / ++-------+| : : | | | Switch(es) | | +-------+ Router | 310 : / +---+----+ : :| +-+-+---------------+ | | | | 311 : / | : :\ +-+-----------------+ | +--------+ 312 : +--+-----+ | : : | +-----+---+---+-----+ 313 : |+-------++ | : : \ | | | 314 : || || | : : | | | | 315 : || VNF2 || | : : \---------+---+---+------+ 316 : || || | : : | | 317 : ++-------+| | : : | | 318 : +--+-+---+ | : : | Virtual Compute | 319 : \ +----+---+ : : | Infrastructure | 320 : \|+-------++ : : | | 321 : +| || : : | | 322 : || VNF3 || : : /------------------------+ 323 : || || : : | 324 : ++-------+| : : | 325 : +--------+ : : | 326 :Service Chain "X" : : / 327 +.......................+ : | 328 :Service Chain "Y" :/ 329 +........................+ 331 Figure 1: VNF Pool Orchestration Framework Architecture. 333 SDN focuses on network programmability, traffic steering and multi- 334 tenancy by means of a common, open, and dynamic abstraction of 335 network resources. NFV targets a progressive migration of network 336 elements, network appliances and fixed function boxes into VMs that 337 can be ran on commodity hardware, enabling the benefits of cloud and 338 datacentres to be applied to network functions. 340 3.2.1. Orchestrator 342 The VNF orchestrator implements a set of functions to seamlessly 343 control and manage in a coordinated way the instantiation and 344 deployment of VNFs on one hand, and their composition and chaining to 345 steer the traffic through them on the other. It is fully controlled 346 and operated by the network operator, and basically it is the highest 347 control and orchestration layer that sits above all the softwarized 348 and virtualised components in the proposed architecture. 350 Therefore the VNF orchestrator provides a consistent way to access 351 the system and provision chains of VNFs to the operator. It exposes 352 a set of primitives to instantiate, configure VNFs and compose them 353 according to the specific service chain requirements. Practically, 354 it aims at enabling an efficient and dynamic management of operator's 355 infrastructure resources with great flexibility by means of a 356 consistent set of APIs. 358 To enable this, the VNF orchestrator can be seen as a composition of 359 several internal functionalities, each providing a given coordination 360 function needed to orchestrate the lower layer control and management 361 functions depicted in Figure Figure 1 (i.e. VNF chain configuration, 362 VNF pool provisioning, etc.). In practice, the VNF orchestrator 363 needs to include at least an internal component to manage the 364 instantiation and configuration of stand-alone VNFs (e.g. implemented 365 by a self-contained VM) that might be directly interfaced with the 366 physical servers in the datacenter. And also a dedicated component 367 for programmatic coordination and provisioning of VNF chains is 368 needed to properly orchestrate the traffic steering through VNFs 369 belonging to the same service chain. This should also provide multi- 370 tenant functionalities and maintain isolation across VNF chains 371 deployed for different customers. It is then clear that the VNF 372 orchestrator is the overall coordinator of the proposed framework, 373 and it drives all the lower layer components that implement the 374 actual control logic. 376 3.2.2. SDN Controller 378 The SDN controller provides the logic for network control, 379 provisioning and monitoring. It is the component where the SDN 380 abstraction happens. This means it exposes a set of primitives to 381 configure the datacenter network according to the requirements of the 382 VNF chains to be provisioned, while hiding the specific technology 383 constraints and capabilities of the software switches and edge 384 routers underneath. The deployment of an SDN controller allows to 385 implement a software driven VNF orchestration, with flexible and 386 programmable network functions for service chaining and resilient 387 virtual appliances. 389 At its southbound interface, the SDN controller interfaces with 390 software switches running in servers, physical switches 391 interconnecting them and edge routers connecting the datacenter with 392 external networks. Multiple control protocols can be used at this 393 southbound interface to actually provision the datacenter network and 394 enable traffic steering through VNFs, including OpenFlow, OVSDB, 395 NETCONF and others. 397 Therefore the SDN controller provides the basic network provisioning 398 functions needed by upper layer coordination functions to perform 399 service chain and VNF pool-wide actions. Indeed, the logic and the 400 state at the service level is only maintained and coordinated by 401 network applications on top of the SDN controller. 403 3.2.3. Service Function Path Manager 405 The service function path manager is deployed as a bridging component 406 between the orchestrator and the SDN controller, and it is mostly 407 dedicated to the implementation of VNF chaining and composition 408 logic. It computes a suitable path to interconnect the involved VNFs 409 (already instantiated and identified by the orchestrator) and 410 forwards the network configuration request to the SDN controller for 411 each new VNF chain requested by the orchestrator. 413 Following the datacenter service chains and related traffic types 414 defined in [I-D.ietf-sfc-dc-use-cases], the service function path 415 manager should implement its coordination logic to support both 416 north-south and east-west chains. The former refer to network 417 traffic staying within the datacenter but coming from a remote 418 datacenter or a user through the edge router connecting to an 419 external network. In this case, the service function path manager 420 should also coordinate with the edge configurator to properly 421 provision the datacenter edge router. Moreover, this north-south 422 case may also refer to VNF chains spanning multiple datacentres, thus 423 requiring a further inter-datacenter coordination between service 424 function path managers and orchestrators. These coordination 425 functions are out of the scope of this document. On the other hand, 426 the east-west chains refer to VNFs treating network traffic that do 427 not exit the datacenter. For both cases, the service function path 428 manager (in combination with the SDN controller) should implement and 429 support proper service chains encapsulation solutions 430 [I-D.ietf-sfc-nsh] to isolate and segregate traffic related to VNF 431 chains belonging to different tenants. 433 Different deployment models may exist for the service function path 434 manager: a dedicated configurator for each chain, or a single 435 configurator for all the VNF chains. In the first approach, the 436 orchestrator needs to implement some coordination logic related to 437 the dynamic instantiation of configurators when new VNF chains are 438 provisioned. 440 3.2.4. Edge Configurator 442 The edge configurator is a network control application deployed on 443 top of the SDN controller. Its main role is to coordinate the 444 provisioning and configuration of the edge router for those north- 445 south VNF chains exiting the datacenter. In particular, it keeps the 446 binding between the traffic steered through the VNFs and the related 447 network service outside the datacenter terminated at the edge router 448 (e.g. a L3 VPN, VLAN, VXLAN, VRF etc), possibly considering the 449 service chain encapsulation implemented within the VNF chain. The 450 mediation of the SDN controller allows to support a variety of 451 control and management protocols for the actual configuration of the 452 datacenter edge router. 454 3.3. Resiliency Control Functions for Chained VNFs 456 In the proposed orchestration architecture, the resiliency control 457 functions that have been identified as a key feature for a flexible 458 and dynamic provisioning of chained VNF services are implemented by 459 the VNF pool manager depicted in Figure Figure 1. It is the entity 460 that manages and coordinates VNFs reliability providing high 461 availability and resiliency features at both stand-alone and chained 462 VNFs level. 464 The deployment of VNF based services requires moving the resiliency 465 capabilities and mechanisms from physical network devices (which are 466 typically highly available and often specialized) to entities (like 467 self-contained VMs) running VNFs in the context of pools of 468 virtualised resources. When moving towards a resilient approach for 469 VNF deployment and operation, in line with ETSI NFV Resiliency 470 Requirements (NFV-REL001), the generic high availability requirements 471 to be matched are translated into: 473 Service continuity: when a hardware failure or capacity limits 474 (memory and CPU) occur on platforms hosting VMs (and therefore 475 VNFs), it is necessary to migrate VNFs to other VMs and/or 476 hardware platforms to guarantee service continuity with minimum 477 impact on the users 479 Topological transparency: the hand-over between live and backup VNFs 480 must be implemented in a transparent way for the user and also for 481 the service chain itself. The backup VNF instances need to 482 replicate the necessary information (configuration, addressing, 483 etc.) so that the network function is taken over without any 484 topological disruption (i.e. at the VNF chain level) 486 Load balancing or scaling: migration of VNF instances may also 487 happen for load-balancing purposes (e.g. for CPU, memory overload 488 in virtualised platforms) or scaling of network services (with 489 VNFs moved to new hardware platforms). In both cases the working 490 network function is moved to a new VNF instance and the service 491 continuity must be maintained. 493 Auto scale of VNFs instances: when a VNF requires increased resource 494 allocation to improve overall service performance, the network 495 function could be distributed across multiple VMs, and to 496 guarantee the performance improvement dedicated pooling mechanisms 497 for scaling up or down resources to each VNF in a consistent way 498 are needed. 500 Multiple VNF resiliency classes: each type of end-to-end service 501 (e.g. web, financial backend, video streaming, etc.) has its own 502 specific resiliency requirements for the related VNFs. While for 503 operators it is not easy to achieve service resiliency SLAs 504 without building to peak, a basic set of VNF resiliency classes 505 can be defined to identify some metrics, such as: if a VNF needs 506 status synchronization; fault detection and restoration time 507 objective (e.g. real-time); service availability metrics; service 508 quality metrics; service latency metrics for VNF chain components. 510 The aim of the VNF pool orchestration presented in this document is 511 to address the above requirements by introducing the VNF pool manager 512 that follows the principles of the IETF VNFPOOL architecture [I- 513 D.zong-vnfpool-arch], where a pool manager coordinates the 514 reliability of stand-alone VNFs, by selecting the active instance and 515 interacting with the Service Control Entity for consistent end-to-end 516 service chain reliability and provisioning. In the VNF pool 517 orchestration architecture illustrated in Figure Figure 1, the 518 Service Control Entity is implemented by the combination of the 519 orchestrator (for overall coordination of service chains) and the VNF 520 chain configuration (for actual provisioning and coordination of 521 individual service chains). 523 Different deployment models may exist for the VNF pool manager: a 524 dedicated manager for each VNF chain, or a single one for all the 525 chains. 527 In terms of offered resiliency functionalities, the VNF pool manager 528 provides some post-configuration functions to instantiate VNFs (as 529 self-contained VMs) with the desired degree of reliability and 530 redundancy. This translates into further actions to create and 531 configure additional VMs as backups, therefore building a pool for 532 each VNF in the chain. 534 The VNF pool manager is conceived to offer several types and degrees 535 of reliability functions. First, it provides specific functions for 536 the persistence of VNFs configuration, including making periodic 537 snapshots of the VMs running the VNF. Moreover, at runtime (i.e. 538 with the service chain in place), it monitors the operational status 539 and performances of the master VNFs VMs, and collects notifications 540 about VMs status, e.g. by registering as an observer to dedicated 541 services offered by the virtualisation platform used within the 542 virtual compute infrastructure. Moreover, VNF pool manager reacts to 543 any failure condition by autonomously replacing the master VNF with 544 one of its backup on the pool, basically implementing a swap of VMs 545 for service chain recovery purposes. Thus, the VNF pool manager also 546 takes care in coordination with the service function path manager of 547 implementing those resiliency mechanisms at the chain level. Two 548 options have been identified so far: cold recovery and hot recovery. 549 In the former, backup VNFs, properly configured with the same master 550 configuration, are kept ready (but switched off) to be started when 551 the master dies. In this case the recovery time depends on the 552 specific VNF and its type of function, e.g. it may depend on 553 convergence time for a virtual BGP router. In the hot recovery, 554 active backup VNFs are kept synchronized with the master ones, and 555 the recovery of the service chain (mostly performed at the service 556 function path manager) in case of failure is faster than cold 557 recovery. 559 4. Positioning in Existing NFV and SFC Frameworks 561 4.1. Mapping into NFV Architecture 563 For the presented solution to be integrated in the ETSI NFV reference 564 architecture, some modifications need to be applied to it, with main 565 focus on the Management and Orchestration (MANO) functions. The VNF 566 pools replace the VNFs in the architecture. They are then controlled 567 by the Element Management System (EMS) on the northbound. So the EMS 568 has to be made VNFPOOL aware. Additional elements that need to 569 support the mechanisms proposed by VNFPOOL are the VNF managers, 570 which need to implement the resiliency and VNF scaling 571 (up-/downscale) functions. This has also implications on the NFV 572 Orchestrator, which has to be aware of the augmented functionality 573 offered by the VNF Manager. In fact, the NFV Orchestrator also 574 provides primitives for VNFs chaining, matching the Service Control 575 Entity in the VNFPool architecture. Therefore, even if ETSI NFV MANO 576 does not include explicitely SDN, the Edge Configurator, and part of 577 the Service Function Path Manager features might be also covered by 578 an augmented NFV Orchestrator. 580 4.2. Mapping into SFC Architecture 582 [I-D.ietf-sfc-architecture] describes the Service Function Chaining 583 (SFC) architecture. It describes the concept of a service function 584 (SF) and how to chain SFs and provides only little detail of the SFC 585 control plane, which is responsible with the coordination of the SFs 586 and their stitching into SFCs. The combination of orchestrator, 587 service function path manager and VNF pool manager functionalities 588 described in this document cover most of the functions expected from 589 the SFC control plane. 591 The interaction with the SFC Classifier is left for further study. 592 We expect the VNFPOOL architecture to leverage on it to make sure 593 that all VNFPOOL instances will be served traffic on during scale-up 594 and that no traffic will be lost during scale-down. 596 5. IANA Considerations 598 This draft does not have any IANA consideration. 600 6. Security Considerations 602 Security issues related to VNF pool orchestration and resiliency of 603 service chains are left for further study. 605 7. Acknowledgements 607 This work has been partially supported by the European Commission 608 through the H2020 5G Crosshaul (The integrated fronthaul/backhaul, 609 grant agreement no:H2020-671598) and Selfnet (Framework for Self- 610 organized network management in virtualized and software defined 611 networks, grant agreement no:H2020-671672) projects. The views 612 expressed here are those of the authors only. The European 613 Commission is not liable for any use that may be made of the 614 information in this document. 616 Authors would also like to thank V. Maffione and G. Carrozzo from 617 Nextworks for valuable discussions and contributions to the topics 618 addressed in this document. 620 8. References 622 8.1. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, 626 DOI 10.17487/RFC2119, March 1997, 627 . 629 8.2. Informative References 631 [I-D.ietf-sfc-dc-use-cases] 632 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 633 Homma, "Service Function Chaining Use Cases In Data 634 Centers", draft-ietf-sfc-dc-use-cases-05 (work in 635 progress), August 2016. 637 [I-D.ietf-sfc-architecture] 638 Halpern, J. and C. Pignataro, "Service Function Chaining 639 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 640 in progress), July 2015. 642 [I-D.ietf-sfc-nsh] 643 Quinn, P. and U. Elzur, "Network Service Header", draft- 644 ietf-sfc-nsh-10 (work in progress), September 2016. 646 [I-D.zong-vnfpool-problem-statement] 647 Zong, N., Dunbar, L., Shore, M., Lopez, D., and G. 648 Karagiannis, "Virtualized Network Function (VNF) Pool 649 Problem Statement", draft-zong-vnfpool-problem- 650 statement-06 (work in progress), July 2014. 652 [VCPE-T2] G. Bernini, G. Carrozzo, P. A. Gutierrez, D. R. Lopez, , 653 "Virtualising the Network Edge: Virtual CPE for the 654 datacenter and the PoP", European Conference on Networks 655 and Communications , June 2014. 657 Authors' Addresses 659 Giacomo Bernini 660 Nextworks 661 Via Livornese 1027 662 San Piero a Grado, Pisa 56122 663 Italy 665 Phone: +39 050 3871600 666 Email: g.bernini@nextworks.it 667 Giada Landi 668 Nextworks 669 Via Livornese 1027 670 San Piero a Grado, Pisa 56122 671 Italy 673 Phone: +39 050 3871600 674 Email: g.landi@nextworks.it 676 Diego R. Lopez 677 Telefonica 678 C. Zurbaran, 12 679 Madrid 28010 680 Spain 682 Email: diego.r.lopez@telefonica.com 684 Pedro Andres Aranda Gutierrez 685 Telefonica 686 C. Zurbaran, 12 687 Madrid 28010 688 Spain 690 Email: pedroa.aranda@telefonica.com