Network Working Group L. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: November 15, 2014 D. King Lancaster University H. Yokota KDDI Lab N. Khan Verizon May 15, 2014 Requirements and Use Cases for Virtual Network Functions draft-xia-vnfpool-use-cases-01 Abstract Network function appliances such as subscriber termination, firewalls, tunnel switching, intrusion detection, and routing are currently provided using dedicated network function hardware. As network function is migrated from dedicated hardware platforms into a virtualized environment, a set of use cases with application specific resilience requirements begin to emerge. These use cases and requirements cover a broad range of capabilities and objectives, which will require detailed investigation and documentation in order to identify relevant architecture, protocol and procedure solutions to ensure reliance of user services using virtualized functions. This document provides an analysis of the key reliability requirements for applications and functions that may be hosted within a virtualized environment. These NFV engineering requirements are based on a variety of uses cases and goals , which include reliability scalability, performance, operation and automation. Note that this document is not intended to provide or recommend protocol solutions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Xia, et al. Expires November 15, 2014 [Page 1] Internet-Draft Requirements and Use Cases for VNF May 2014 This Internet-Draft will expire on November 15, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .3 1.1. Network Function Virtualization (NFV) Effort . . . . . .4 1.2. Virtual Network Functions (VNF) Resilience Requirements .4 1.2.1. Service Continuity . . . . . . . . . . . . . . . . .5 1.2.2. Topological Transparency . . . . . . . . . . . . . .5 1.2.3. Load Balancing or Scaling . . . . . . . . . . . . . .5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 3. Virtual Network Function (VNF) Pool Architecture. . . . . . .7 3.1. VNF Instance Resilience Objectives . . . . . . . . . . .8 3.2. Resilience of Network Connectivity . . . . . . . . . . .8 3.3. Service Continuity . . . . . . . . . . . . . . . . . . .9 4. General Resilience Requirements For VNF Use Cases . . . . . .9 4.1. Resilience for Stateful Service . . . . . . . . . . . . .9 4.1.1 State Synchronization . . . . . . . . . . . . . . . . .10 4.2. Auto Scale of Virtual Network Function Instances . . . .11 4.3. Reliable Network Connectivity between Network Nodes . . .12 4.4. Existing Operating Virtual Network Function Instance Replacement . . . . . . . . . . . . . . . . . . . . . . .13 4.5. Combining Different VNF Functions (a VNF Set) . . . . . .14 4.6. VNF Resilience Classes . . . . . . . . . . . . . . . . .15 4.7. Multi-tier Network Service . . . . . . . . . . . . . . .15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .17 6. Security Considerations . . . . . . . . . . . . . . . . . . .17 7. References . . . . . . . . . . . . . . . . . . . . . . . . .17 7.1. Normative References . . . . . . . . . . . . . . . . . .17 7.2. Informative References . . . . . . . . . . . . . . . . .17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .17 Xia, et al. Expires November 15, 2014 [Page 2] Internet-Draft Requirements and Use Cases for VNF May 2014 1. Introduction Network virtualization technologies are finding increasing support among network and Data Center (DC) operators. This is due to demonstrable capital cost reduction and operational energy savings, simplification of service management, potential for increased network and service resiliency, network automation, and service and traffic elasticity. Within traditional DC networks, varied middleware boxes including FW (Fire Wall), NAT (Network Address Translation), LB (Load Balancers), WoC (Wan Optimization Controller), etc., are being used to provide network functions, traffic control and optimization. Each function is an essential part of the entire operator and DC network, and overall service chain (required traffic path for users) Combined these functions and capabilities. Currently, a significant amount of network functions are being migrated into virtualized entities, in essence the middleware capability is implemented in software on commodity hardware using well defined industry standard servers. Thus allowing the creation, modification, deletion, scaling, and migration of single or groups of network functions, across few or many servers. These virtual network functions (VNF) may be location independent, i.e., they may exist across distributed or centralized DC hardware. This architecture will pose new issues and great challenges to the automated provisioning across the DC network, while maintaining high availability, fault-tolerant, load balancing, and plethora of other requirements some of which are technology and policy based. Today, architecture and protocol mechanisms exist for the management and operation of server hardware supporting applications, these hardware resources are known as server node pools, which may be accessed by other servers and clients. These server node pools have a well-established set of requirements related to management, availability, scalability and performance. [I-D.zong-vnfpool-problem-statement] provides an overview of the problems related to the reliability of a VNF set, and also introduces briefly a VNF pooling architecture. This document provides an analysis of the key reliability requirements for applications and functions that may be hosted within a virtualized environment. These Network Functions Virtualization (NFV) engineering requirements are based on a variety of uses cases and goals , which include reliability scalability, performance, operation and automation. This document is not intended to provide or recommend solutions. The Xia, et al. Expires November 15, 2014 [Page 3] Internet-Draft Requirements and Use Cases for VNF May 2014 intention of this document is to present an agreed set of objectives and use cases providing network function using virtualized instances, identification of key requirements across use cases. 1.1. Network Function Virtualization (NFV) Effort NFV, an initiative started within the European Telecommunications Standards Institute (ETSI), aims to transform the way that network operators architect networks by evolving standard IT virtualization technology to consolidate many network equipment types to industry standard high volume servers, switches and storage. The objectives for NFV being specified within the ETSI organization include: o Rapid service innovation through software-based deployment and operationalization of network functions and end-to-end services; o Improved operational efficiencies resulting from common automation and operating procedures; o Reduced power usage achieved by migrating workloads and powering down unused hardware; o Standardized and open interfaces between network functions and their management entities so that such decoupled network elements can be provided by different players; o Greater flexibility in assigning Virtual Network Functions (VNF) to hardware; o Improved capital efficiencies compared with dedicated hardware implementations. 1.2. Virtual Network Functions (VNF) Resilience Requirements Deployment of NFV-based services will require the transition of resilient capabilities from physical network nodes, which are typically highly available, entities running Virtual Network Functions (VNFs) on abstracted pool of hardware resources. Thus, it is critical to ensure that end-to-end user services which may require a variety of virtualized functions to be reliable, and in the event failure would support seamless failover when required to negate or minimize impact on user services. A number of requirements have been discussed and documented within the NFV Industry Steering Group (ISG) working groups, including [ETSI-HA-USECASE] and are highlighted in following sub-sections. Xia, et al. Expires November 15, 2014 [Page 4] Internet-Draft Requirements and Use Cases for VNF May 2014 1.2.1. Service Continuity VNFs provide the capability to execute and operate network functions on varying types of Virtual machines (VMs), and subsequently physical equipment. It should be possible to inherently provides resiliency at the function level, as well as physically. Network Functions (NFs) are assigned session IDs, Sequence IDs and Authentication IDs. This information may be static, dynamic and temporal so will need to be replicated and maintained as needed for failure scenarios. Hardware entity such as a storage server or networking node are assigned a unique MAC address, which is often pre-configured (hardware encoded) and static. In the event of a hardware failure or capacity limits (memory and CPU) hosting VMs and therefore VNFs, it may be necessary to move VNFs to another VM, and/or hardware platform. Therefore, service continuity must be maintained with no or negligible impact to users using with services being provided by the NFs. 1.2.2. Topological Transparency Redundant systems are typically configured as an active and standby nodes, running a specific NF in the same LAN segment. It is possible that they are assigned duplicate IP addresses, and sometimes the same MAC address as well. In the event of an active node failure the standby node can take over transparently. This should be architecture supported by any eventual solution. In order to achieve topological transparency and seamless hand-over the dependent nodes should replicate and maintain the necessary information so that in the event of failure the standby node takes over the service without any disruption to the users. 1.2.3. Load Balancing or Scaling When load-balancing or scaling of sessions, the working session may be moved to a new VNF instance, or indeed a new VM on another hardware platform. Again, service continuity must be maintained. 2. Terminology The following terms have been defined by the ETSI Industry Steering Group (ISG) responsible for the specification of NFV, and are reused in this document: Xia, et al. Expires November 15, 2014 [Page 5] Internet-Draft Requirements and Use Cases for VNF May 2014 Network Function (NF): A functional building block within a network infrastructure, which has well-defined external interfaces and a functional behavior. In practical terms, a Network Function is today often a network node or physical appliance. NFV Orchestrator: The NFV Orchestrator is in charge of the network wide orchestration and management of NFV Infrastructure (NFVI) and resources. The NFV Orchestrator has control and visibility of all VNFs running inside the NFVI. The NFV Orchestrator provides GUI and external NFV-Interfaces to the outside world to interact with the orchestration software. Service Continuity: The continuous delivery of service in conformance with service, functional and behavioral specification and SLA requirements, both in the control and data planes, for any initiated transaction or session till its full completion even in the events of intervening exceptions or anomalies, whether scheduled or unscheduled, malicious, intentional or unintentional. From an end-user perspective, service continuity implies continuation of ongoing communication sessions with multiple media traversing different network domains (access, aggregation, and core network) or different user equipment. Hypervisor: Software running on a server that allows multiple VMs to run on the same physical server. The hypervisor manages and provide network connectivity to Virtual machines [NVO3-FWK]. Network Functions Virtualization (NFV): Moving network function from dedicated hardware platforms onto industry standard high volume servers, switches and storage. Set-top Box (STB): This device contains audio and video decoders and is intended to connects to a variety of home user devices media servers and televisions. Virtual Machine (VM): Software abstraction of underlying hardware. Virtual Application (VA): A Virtual Application is the more general term for a piece of software which can be loaded into a Virtual Machine. A VNSF is just one type of VA amongst many others, which may not relate to any VNF (e.g. SW-tools or NFV-Infra-internal applications). Virtualized Network Function (VNF): a VNF provides the same functional behavior and interfaces as the equivalent network function, but is deployed as software instances building on top of a virtualization layer. The VNF Problem statement [I-D.zong-vnfpool-problem-statement] Xia, et al. Expires November 15, 2014 [Page 6] Internet-Draft Requirements and Use Cases for VNF May 2014 defines the terms reliability, VNF, VNF Pool, VNF Pool Manager, and VNF Set. This draft also uses these definitions. In addition to the terms described above, this document also uses the following additional terminology: VNF Pool: a group of VNF instances providing the same network function. VNF Pool Manager: an entity that manages a VNF pool, and interacts with the service control entity to provide the network function. VNF Set: a group of VNF instances that can be used to build network services. 3. Virtual Network Function (VNF) Pool Architecture Shifting towards virtual network function presents a number of challenges and requirements, this document focuses on those related to network function availability and reliability. In large DC environments, a virtual server may need to deal with traffic from millions of hosts. This represents a significant scaling challenge for Virtual network function deployment and operation. +------------------+ | NFV Orchestrator | +------------------+ ^ ^ | | +-----------+ +-----------+ | | v v +----------------+ +----------------+ |VNF Pool Manager|<---------->|VNF Pool Manager| +----------------+ +----------------+ ^ ^ | | v v +------------------------------+ +------------------------------+ |+----------+ +----------+ | | +----------+ +----------+| || VNF | | VNF | | | | VNF | | VNF || || Instance| ... | Instance |<+---+>| Instance| ... | Instance|| |+----------+ +----------+ | | +----------+ +----------+| | VNF Pool | | VNF Pool | +------------------------------+ +------------------------------+ Figure 1: Typical VNF Pool Network Architecture As shown in Figure 1, the overall architecture of VNF Pool-based network includes: Xia, et al. Expires November 15, 2014 [Page 7] Internet-Draft Requirements and Use Cases for VNF May 2014 o VNF Instances o VNF Pool o VNF Pool Manager Rserpool [RFC5351] has the similar architecture to provide high- availability and load balancing, However Rserpool are only used to manage physical servers and can not deal with VNF instance when it was designed. 3.1. VNF Instance Resilience Objectives In order to manage VNF-based nodes and provide fault tolerant and load sharing across nodes, the VNF instances may be initiated and established as logical element. A set of VNFs providing the same service type, is known as a VNF Pool, or groups of network functions (FW, LB, DPI) running on multiple VNFs, is known as a VNF Set. Considering the reliability requirements of a VNF-based node architecture it should support several key points detailed below: o Application resource monitoring and health checking; o Automatic detection of application failure; o Failover to another VNF instance; o Transparency to other VNF instances; o Isolation and reporting of failures; o Replication of state for active/standby network functions. 3.2. Resilience of Network Connectivity The other category of reliability requirements concerns the network connectivity between any two VNFs, across a VNF set, or between VNF Pool Manager. The connectivity between the VNF Pool Manager and the VNF instance is used to provide registry service to the VNF Set. A set of VNF Pool managers might be configured to provide reliable registration. When one VNF instance cannot obtain a register response from the assigned VNF Pool Manager, it should be capable of fail-over to Xia, et al. Expires November 15, 2014 [Page 8] Internet-Draft Requirements and Use Cases for VNF May 2014 another VNF Pool Manager. Connectivity may also be monitored by the VNF Pool Manager to the VNF Instance periodically as well. The connectivity between Pool Managers is used to maintain synchronization of data between VNFs located in different VNF Pools or VNF Sets. This allows every Pool Manager to acquire and maintain overall information of all VNFs and provide protection for each other. For all types of network connectivity discussed previously, the key reliability requirements stay consistent and include: o Automatic detection of link failure; o Failover to another usable link; o Automated routing recovery. 3.3. Service Continuity It is critical to ensure end-to-end service continuity over both physical and virtual infrastructure. A number of requests exist to maintain user services in the event of network or VNF instance failure, these include: o Storage and transfer of state information within the VNFs; o VNF capacity (memory and CPU) limitations per instance to avoid overbooking, and failure of end-to-end services; o Automated recovery of end-to-end services after failure situations; 4. General Resilience Requirements For VNF Use Cases 4.1. Resilience for Stateful Service In the service continuity use case provided by the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) Industry Specification Group (ISG) [NFV-REL-REQ] , which describes virtual middlebox appliances providing layer-3 to layer-7 services may require maintaining stateful information, e.g., stateful vFW. In case of hardware failure or processing overload of VNF, in addition to the replacement of VNF, it is necessary to move its key status information to new VNF for service continuity. See Figure 2 (Resilience for Stateful Service) for clarification. In case of multiple vFws on one VM and not enough resources are available at the time of failure, two strategies can be taken: one is Xia, et al. Expires November 15, 2014 [Page 9] Internet-Draft Requirements and Use Cases for VNF May 2014 to move as many vFws as possible to a new place according to the available resources, and the other is to suspend one or more running VNFs in the new place and move all vFws on the failed hardware to it. MAC, IP, VLAN, Session id, Sequence No, ... +-----------------+-----------------+ | ************************************* | * | |Limited | * | | * | |Resource | * Suspend| | * | V | * V +--+-+ +-*--+ +--V-+ +----+ +--V-+ +-V--+ +----+ |vFw1| |vFw1| |vFw1| |vFw2| |vFw1| |vFw1| |vFw3| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +------------+ +------------+ +-------------------+ | VM | | VM | | VM | +------------+ +------------+ +-------------------+ +------------+ +------------+ +-------------------+ /-\ | | | | | | || vServer | | vServer | | vServer | \-/ | | | | | +------------+ +------------+ +-------------------+ Hardware Failure Figure 2: Resilience for Stateful Service In both scenarios, the following requirements need to be satisfied: o Supporting status information maintaining; o Supporting status information moving; o Supporting VNF moving from one VM to another VM; o Supporting partial VNFs moving; o Seamless switching user traffic to alternative VMs and VNFs. 4.1.1 State Synchronization As identified in section 4.1 (Resilience for Stateful Service) their is a requirement for for state synchronization. A failure of a vFW would result in the loss of active connections transiting the node. Any connection-orientated or secure sessions, including enterprise and financial transactions, may be critical, and losing them would result in the loss of data. Xia, et al. Expires November 15, 2014 [Page 10] Internet-Draft Requirements and Use Cases for VNF May 2014 If required it should be possible to ensure that the VNF Pool infrastructure should minimise or negate session data traffic if a vFW failures. Prior to the failure the vFW might advertise and synch the connection information transitioning its node. The connection state synchronization to other vFWs acting as stand-by nodes would provide fast fail-over and minimal connection interruption to users. This synchronization mechanism should be supported by the (NFV) infrastructure level, that is, ideally each application does not need to code the redundancy procedures (reserve a VM resource, instantiate one or more backup server(s), copy the state, keep them in sync, etc). Also, such a state can be embedded in each vNF or stored in an external virtual storage, which should be supported by the NFV infrastructure. 4.2. Auto Scale of Virtual Network Function Instances Adjusting resource to achieve dynamic scaling of VMs described in the ETSI [NFV-INF-UC] use case and [NFV-REL-REQ]. As shown in Figure 3, if more service requests come to a VNF than one physical node can accommodate, processing overload occurs. In this case, the movement of the VNF instance to another physical node with the same resource constraints will create a similar overload situation. A more desirable approach is to replicate VNF instance to one or more new VNF instances and at the same time distribute the incoming requests to those VNF instances. In a scenario where a particular VNF requires increased resource allocation to improve overall application performance, the network function might be distributed across multiple VMs. To guarantee performance improvement, the hypervisor dynamically adjusts (scaling up or scaling down) resources to each VNF in line with the current or predicted performance needs. Xia, et al. Expires November 15, 2014 [Page 11] Internet-Draft Requirements and Use Cases for VNF May 2014 +--------------+ +-------------------+ | NFV | | | |Management and| | <===>Orchestration | | +---------+ | | Entity | | | #1 | | +--------------+ | --| vIPS/IDS|-- | /\ | | +---------+ | | || +---------+ | | |--|-- || <--|End User1| | | VM #1 | | | || +---------+ | +-------------+ | | +----\/---+ | | | | | +---------+ | +---------+ | | | | <--|End User2| | | #2 | | | | | +---------+ | --| vIPS/IDS|-- | | | | | | +---------+ | | | | | +---------+ | | ---|------- Service | <--|End User3| | | VM #2 | | | | Router | +---------+ | +-------------+ | | | | +---------+ | | | | | <--|End User4| | +---------+ | | | | +---------+ | | #3 | | | | | +---------+ | --| vIPS/IDS|-- | | | | <--|End User5| | | +---------+ | | | +---------+ +---------+ | | ---|-- : | | VM #3 | | | +-------------+ | : | | +-------------------+ Figure 3: Auto Scaling of Virtual network Function Instances In this case, the following requirements need to be satisfied: o Monitoring/fault detection/diagnosis/recovery - appropriate mechanism for monitoring/fault detection/diagnosis/recovery of all components and their states after virtualization, e.g. VNF, hardware, hypervisor; o Resource scaling - elastic service aware resource allocation to network functions. 4.3. Reliable Network Connectivity between Network Nodes In the reliable network connectivity between VNFs use case provided by ETSI [NFV-INF-UC], the management and orchestration entities must be informed of changes in network connectivity resources between VNFs. For example, Some network Xia, et al. Expires November 15, 2014 [Page 12] Internet-Draft Requirements and Use Cases for VNF May 2014 connectivity resources may be temporarily put in power savings mode when resources are not in use. This change is not desirable since it may have great impact on reachability and topology. Another example, some network connectivity resource may be temporarily in a fault state and comes back into an active state, however some other network connectivity resource becomes permanent in a fault state and is not available for use. +----------------+ |NFV Orchestrator| +----------------+ Web vDPI vCache vFW vNATPT +--------+ +--------+ +--------+ +--------+ | +----+ | | +----+ | | +-++-+ | | +----+ | |------| ------| -------| || | ----| |<----- | | | | | | | | | | | || | | | | | | | | | +----+ | | +----+ | | +-++-+ | | +----+ | | | | | | | | | | | | +----+ | | | +----+ | | +-++-+ | | | V| ,--,--,--. | | | | | | | | | | || | | | | ,-' `-. | |<->---------- | |----- | || |-----------<--> Internet ) | | | | | +----+ | | +-++-+ | | | `-. ,-' +-|--+ | | | | | | | | A `--'--'--' | | +----+ | | | | +-++-+ | | +----+ | | | | | ------------------| || ------| |<----| -------- | | | | | | || | | | | | | | +----+ | | | | +-++-+ | | +----+ | +--------+ +--------+ +--------+ +--------+ Figure 4: Reliable Network connectivity In this case, the following requirements need to be satisfied: o Quick detection of link failures; o Adding or removing VNF instances; o Adding or removing network links between VNFs. 4.4. Existing Operating Virtual Network Function Instance Replacement In the Replacement of existing operating VNF instance use case provided by ETSI [NFV-INF-UC] use case, the Management and Orchestration entity may be configured to support virtualized network function replacement. For example, the Network Service Provider has a virtual firewall that is operating. When the operating vFW Xia, et al. Expires November 15, 2014 [Page 13] Internet-Draft Requirements and Use Cases for VNF May 2014 overloads or fails, the Management and Orchestration entity determines that this vFW instance needs to be replaced by another vFW instance. +----------------+ |NFV Orchestrator| +---|---------|--+ | | Create | | Report Stats and launch | | (Traffic,CPU new vFW | | Failure..) | | +--------|---+ +--|---------+ |Host2 | |Host1 | | | | | | +---++---+ | | +---++---+ | | |vFW||vFW| | | |vFW||vFW| | | +---++---+ | | +---++---+ | | +---++---+ | | +---++---+ | | |vFW||vFW| | | |vFW||vFW| | | +---++---+ | | +---++---+ | +------------+ +------------+ Figure 5: Existing vFW replacement In this case, the following requirements need to be satisfied: o Verifying if capacity is available for a new instance of the VNF at some location; o Instantiating the new instance of a VNF at the location; o Transferring the traffic input and output connections from the old instance to the new instance. This may require transfer of state between the instances, and reconfiguration of redundancy mechanisms; o Pausing or deleting the old VNF instance. 4.5. Combining Different VNF Functions (a VNF Set) A VNF Set is used to assemble a collection of network functions together to support a type of user or end-to-end service. Connectivity between the VNF sets is known as a VNF Forwarding Graph (a graph of logical links connecting VNFs together for steering traffic between network function). To support the reliability of an end-to-end service, except for satisfying the aforementioned basic use case requirements, a VNF Set presents further requirements of reliability as followed: Xia, et al. Expires November 15, 2014 [Page 14] Internet-Draft Requirements and Use Cases for VNF May 2014 o As a whole, any failures (i.e., VNF failures, link failures, performance degradation, etc) of a VNF Set can be detected and recovered in time; o Keeping the VNF order and relation unchanged when the VNF Set is updated; o The integrated VNF Set performance is not denigrated after it is updated; 4.6. VNF Resilience Classes Different end-to-end services(e.g., Web, Video, financial backend, etc) have different classes of resilience requirement for the VNFs. The use of class-based resiliency to achieve service resiliency SLAs, without "building to peak" is critical for operators. VNF resilience classes can be specified by some attributes and metrics as followed: o Does the VNF need status synchronization; o Fault Detection and Restoration Time Objective (e.g., real-time, near-real time, non-realtime) and metrics; o Service availability metrics; o Service Quality metrics; o Service reliability; o Service Latency metrics for components. [More description is needed.] 4.7. Multi-tier Network Service Many network services require multiple network functions to be performed sequentially on data packets. A traditional model for multi-tier service is shown as below, where for each network function, all instances connect to the corresponding entrance point (e.g. LB) responsible for sending/receiving data packets to/from selected instance(s), and steering the data packets between different network functions. Xia, et al. Expires November 15, 2014 [Page 15] Internet-Draft Requirements and Use Cases for VNF May 2014 Service (e.g. VOIP, Web) +--------------+ +--------------+ +--------------+ | function#1 | | function#2 | | function#n | | +----------+ | | +----------+ | | +----------+ | | | Instance | | | | Instance | |... ...| | Instance | | | +----------+ | | +----------+ | | +----------+ | | |data | | |data | | |data | | |conn | | |conn | | |conn | | +----------+ | | +----------+ | | +----------+ | | | Entrance | | | | Entrance | | | | Entrance | | | | Point | | | | Point | | | | Point | | | +----------+ | | +----------+ | | +----------+ | +-----+--------+ +-------+------+ +-------+------+ |data conn |data conn | +-------------------+----------------------+ Figure 7: Multi-tier Service Such model works well when all instances of the same network function are topologically close to each other. However, VNF instances are highly distributed in DC networks, Network Operator networks and even customer premised. When VNF instances are topologically far from each other, there could be many network links/nodes between them for transferring the data packets. For two different VNF instances, it is possible that they are on the same physical server, but the entrance points are many links/nodes away. To improve network efficiency, it is desirable to establish direct data connections between VNF instances, as shown below: Service (e.g. VOIP, Web) +----------+ +----------+ +----------+ | VNF#1 | data conn | VNF#2 | data conn | VNF#n | | Instance |-----------| Instance |- ... ... -| Instance | +----------+ +----------+ +----------+ ^ | Virtualization +--------------------------------------------------------+ | Virtualization Platform | +--------------------------------------------------------+ Figure 8: VNF Instances Direct Connection' In this case, the following requirements need to be satisfied: o End to end failure detection of VNFs or links for multi-tier service; Xia, et al. Expires November 15, 2014 [Page 16] Internet-Draft Requirements and Use Cases for VNF May 2014 o Keep running service not be influenced during VNF instance transition or failure in the model of VNF instances direct connection. 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations TBD. 7. References 7.1. Normative References 7.2. Informative References [NFV-INF-UC] "Network Functions Virtualisation Infrastructure Architecture Part 2: Use Cases", ISG INF Use Case, June 2013. [ETSI-HA-USECASE] "Network Function Virtualisation; Use Cases;", ISG NFV Use Case, June 2013. [NFV-REL-REQ] "Network Function Virtualisation Resiliency Requirements", ISG REL Requirements, June 2013. [I-D.zong-vnfpool-problem-statement] Zong, N., "Problem Statement for Reliable Virtualized Network Function (VNF) Pool", May 2014. [NVO3-FWK] Lasserre, M., et al. "Framework for DC Network Virtualization", ID draft-ietf-nvo3-framework-05, January 2014. [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", May 2008. Authors' Addresses Xia, et al. Expires November 15, 2014 [Page 17] Internet-Draft Requirements and Use Cases for VNF May 2014 Liang Xia Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: frank.xialiang@huawei.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Daniel King Lancaster University UK Email: d.king@lancaster.ac.uk Hidetoshi Yokota KDDI Lab Japan Email: yokota@kddilabs.jp Naseem Khan Verizon USA Email: naseem.a.khan@verizon.com Xia, et al. Expires November 15, 2014 [Page 18] Internet-Draft Requirements and Use Cases for VNF May 2014