Network Working Group L. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: August, 2014 D. King Lancaster University H. Yokota KDDI Lab N. Khan Verizon February 14, 2014 Requirements and Use Cases for Virtual Network Functions draft-xia-vnfpool-use-cases-00 Abstract Network edge 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/. Xia, et al. Expires August 1, 2014 [Page 1] Internet-Draft VNFPool Use Cases February 2014 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." This Internet-Draft will expire on August 1, 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 . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Concept of Virtual Service Node (VSN) . . . . . . . . . . . . 8 3.1. Resilience within a VSN and related Components . . . . . 10 3.2. Resilience of VSN Network Connectivity . . . . . . . . . 10 3.3. Service Continuity . . . . . . . . . . . . . . . . . . . 11 4. General Resilience Requirements For VNF Use Cases . . . . . . 11 4.1. Resilience for Stateful Service . . . . . . . . . . . . . 11 4.2. Auto Scale of Virtual Network Function Instances . . . . 13 4.3. Reliable Network Connectivity between Network Nodes . . . 14 4.4. Existing Operating Virtual Network Function Instance Replacement . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. VSN Cluster . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. VSN Resilience Classes . . . . . . . . . . . . . . . . . 18 4.7. Reliable Traffic Steering . . . . . . . . . . . . . . . . 19 4.8. Multi-tier Network Service . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Xia, et al. Expires August 1, 2014 [Page 2] Internet-Draft VNFPool Use Cases February 2014 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 applications (services), 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 can be termed as service nodes. In terms of virtualizing network functions, a significant amount of service nodes and function instances within the service nodes can be 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, scaling, migration, modification, and deletion of single or groups of functions, across few or many service nodes. These virtual service nodes 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. Within this document we refer to virtualization of server node pools as Virtual Service Node Pool (VSNP). [I-D.zong-vnfpool-problem-statement] provides an overview of the problems related to the reliability of a VNF set, and also introduces Xia, et al. Expires August 1, 2014 [Page 3] Internet-Draft VNFPool Use Cases February 2014 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 intention of this document is to present an agreed set of objectives and use cases for VSNPs, identify requirements and present architecture framing. 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 that are typically highly available, to highly available end-to-end services comprised Xia, et al. Expires August 1, 2014 [Page 4] Internet-Draft VNFPool Use Cases February 2014 of 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 are reliable, and in the event failure will 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. 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. These informations 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. Xia, et al. Expires August 1, 2014 [Page 5] Internet-Draft VNFPool Use Cases February 2014 1.2.3. Load Balancing or Scaling When load-balancing or scaling of sessions, the end user session may be moved to a new NF 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: 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. Network Service (NS): A composition of Network Functions and defined by its functional and behavioral specification. The Network Service contributes to the behavior of the higher layer service, which is characterized by at least performance, dependability, and security specifications. Network Stability: The ability of a network to maintain steadfastness or to resume its designated state as soon as possible against change, deterioration or displacement by anomaly that does not exceed its design limit. NF Forwarding Graph: A graph of logical links connecting NF nodes for the purpose of describing traffic flow between these network functions. 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 Xia, et al. Expires August 1, 2014 [Page 6] Internet-Draft VNFPool Use Cases February 2014 traversing different network domains (access, aggregation, and core network) or different user equipment. 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): An implementation of an NF that can be deployed on a Network Function Virtualisation Infrastructure (NFVI). The VNF Problem statement [I-D.zong-vnfpool-problem-statement] defines the terms reliability, VNF, VNF Pool, VNF Pool Element, VNF Pool User, VNF Pool Manager, and VNF Set. This draft also uses these defintions. In addition to the terms described above, this document also uses the following additional terminology: Broadband Network Gateway (BNG): IP Edge Route where bandwidth and QoS policies may be applied, to support multi-service delivery [TR-101]. Call Session Control Function (CSCF): A function that is used to manage the mobile IP Multimedia Subsystem (IMS) signaling from users to services and network gateways. 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]. IP Multimedia Subsystem (IMS): The IP Multimedia Subsystem used within mobile core networks. Network Functions Virtualization (NFV): Moving network function from dedicated hardware platforms onto industry standard high volume servers, switches and storage. Residential Gateway (RGW): A device located in the home network performing gateway function. 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. VNF Pool: a group of VNF instances providing same network function. Xia, et al. Expires August 1, 2014 [Page 7] Internet-Draft VNFPool Use Cases February 2014 Virtualized Server (VServer): A virtualized server runs a hypervisor supporting one or more VMs [NVO3-FWK]. Virtualized Service Node (VSN): A virtualized network function instance implemented in software on Virtualized Server. Virtual Service Node Pool (VSNP): Virtualized Server resources supporting a variety of network functions.. 3. Concept of Virtual Service Node (VSN) Shifting towards virtualization of hardware 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 Service Node (VSN) may need to deal with traffic from millions of hosts. This represents a significant scaling challenge for VSN deployment and operation. Xia, et al. Expires August 1, 2014 [Page 8] Internet-Draft VNFPool Use Cases February 2014 +----------------------+ | | | Network application | | | +---------/-\----------+ // \\ // \\ / \\ +-------------+ // \\ +-------------+ | VSNP |// \\| VSNP | | Manager +----------------------+ Manager | | | | | +---/-\-------+ +-----/-\-----+ / \ / \ / \ / \ / \ / \ -/----- ------------ \ // \\ //--- ---\\ // +--+-+ +----+\\ /// \\\ / |vSN1| |vSN2| \ // \\ | +----+ +----+ | // \\ | +----+ ------+ | /+----+ +----+ +----- +----+ +----\ | |VM1 | | VM2 | | | |vSN3| |vSN4| |vSN5| |vSN6| |vSN7|| | +----+ +-----+ | | +----+ +----+ +----+ +----+ +----+ | | +------------+ | | +------------+ +-------------------+ | | | | | | | VM3 | | VM4 | | | | vServer1 | | | +------------+ +-------------------+ | \ | | / | +------------+ +-------------------+ | \\ |------------// | | | | | | \\- VSNP -// | | vServer2 | | vServer3 | -------- \| | | / \\-----------+ +-----------------//+ \\ // \\\ VSNP /// \\--- ---// ------------ Figure 1: Overall Architecture of VSNP As shown in Figure 1, the overall architecture of VSNP includes VSN, VSNP, VSNP manager and the connectivity between any two VSNs, between VSN and VSNP manager. The terms of VSN, VSNP, VSNP manager have the same meaning with the terms of VNF, VNF Pool, VNF Pool Manager defined in [I-D.zong-vnfpool-problem-statement]. Rserpool [RFC5351] has the similar architecture to provide high- availability and load balancing, However Rserpool are only used to Xia, et al. Expires August 1, 2014 [Page 9] Internet-Draft VNFPool Use Cases February 2014 manage physical servers and can not deal with virtualized function instance when it was designed. Note that VSNP and VSNP manager also can be used to manage traditional service nodes. 3.1. Resilience within a VSN and related Components The VSN, VServer and VSNP components are implemented in different network layers and should be considered as different hardware or logical elements. Multiple VSNs can be provided on one or more VServers for increased reliability. If a VServer detects the failure of the VSNs, it should take the appropriate action for failover and ensures the service continuity. In order to manage server virtualization across a set of VServers and provide fault tolerant and load sharing across VServers, the VSNPs may be initiated and established as logical element(e.g., a set of VSN providing the same service type), facilitating the migration of a large number of VSNs running on different hypervisors and belonging to different VServers to register into and deregister out. In case of VSN failure or VServer overloading, such VSNPs can be used to support both traditional and virtualized service node replacement or service node adding. However when VSNPs is used to support the operation of traditional service nodes, this doesn't scale very well. Considering the reliability requirements, VSNP architecture should support several key points detailed below: o Application resource monitoring and health checking; o Automatic detection of application failure; o Failover to another VServer or VSNP; o Transparency to other VSNs, VServers or VSNPs; o Isolation and reporting of failures; o Replication of state for active/standby network functions. 3.2. Resilience of VSN Network Connectivity The other category of reliability requirements concerns the network connectivity between any two VSNs, any two VSNP managers, and the network connectivity between VSN and VSN manager. Xia, et al. Expires August 1, 2014 [Page 10] Internet-Draft VNFPool Use Cases February 2014 The connectivity between VSNs is used to deliver service through a set of VSNs to meet the service requirements. The connectivity between VSNP manager and VSN is used by the VSNP manager to provide registry service to the VSN belonging to different VServer and provide failover of the VSN. A set of VSNP managers can be configured to provide reliable registration. When one VSN cannot obtain a register response from one VSNP manager, it can go to another VSNP manager for registration. This connectivity can also be used by VSNP to monitor the work status of VSNs periodically. The connectivity between VSNP managers is used to maintain synchronization of data between VSNs located in different VSNP. This allows every VSNP to acquire and maintain overall information of all VSNs and provide protection for each other. For all types of network connectivity discussed previously, the key 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 failure, these include: o Storage and transfer of state information within the VSN; o VSN 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 Xia, et al. Expires August 1, 2014 [Page 11] Internet-Draft VNFPool Use Cases February 2014 layer-7 services may require maintaining stateful information, e.g., stateful vFW. In case of hardware failure or processing overload of VSN, in addition to the replacement of VSN, it is necessary to move its key status information to new VSN for service continuity. See Figure 3 (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 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 VSNs 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 VSN moving from one VM to another VM; o Supporting partial VSNs moving; o Seamless switching user traffic to alternative VMs and VSNs. Xia, et al. Expires August 1, 2014 [Page 12] Internet-Draft VNFPool Use Cases February 2014 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 4, if more service requests come to a VSN than one physical node can accommodate, processing overload occurs. In this case, the movement of the VSN to another physical node with the same resource constraints will create a similar overload situation. A more desirable approach is to replicate the VSN and distribute service node instances ones to one or more new VSNs and at the same time distribute the incoming requests to those nodes. In a scenario where a particular VSN 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 VSNs in line with the current or predicted performance needs. Xia, et al. Expires August 1, 2014 [Page 13] Internet-Draft VNFPool Use Cases February 2014 +--------------+ +-------------------+ | | | | |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 network nodes use case provided by ETSI [NFV-INF-UC], the management and orchestration entities must be informed of changes in network connectivity resources between network nodes. For example, Some network Xia, et al. Expires August 1, 2014 [Page 14] Internet-Draft VNFPool Use Cases February 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. +------------+ |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 network node instances, compute node instances and/or hypervisor instances; o Removing network node instances, compute node instances and/or hypervisor instances; o Adding or removing network links between nodes. Xia, et al. Expires August 1, 2014 [Page 15] Internet-Draft VNFPool Use Cases February 2014 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 overloads or fails, the Management and Orchestration entity determines that this vFW instance needs to be replaced by another vFW instance. Direct flow to new | | +------------+ vFW | | |Orchestrator|---------------| | | +-|---------|+ | +-V---V+ | | --------|,--,--|/ Create and launch | Report Statist ,-' +------+`-. new vFW | (Traffic,CPU ( ') | | Failure..) `-. +-------+,-' | | `| APP | +--------|---+ +--|---------+ | Server| |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 VSN at some location; o Instantiating the new instance of VSN 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 VSN instance. Xia, et al. Expires August 1, 2014 [Page 16] Internet-Draft VNFPool Use Cases February 2014 4.5. VSN Cluster VSN cluster is a set of VSNs which assemble together to support load balancing and high availability. It tends to be a common case in virtual networks for the following reasons: o The performance of VSN is usually not as good as the appliances on dedicated hardware (e.g., physical FW, LB, etc) for VSN is realized mainly depending on software, not on dedicated hardware. VSN cluster should be supported to achieve the same performance as hardware appliance; o New requirements of network virtualization as well as multi-tenant support result in a large number of virtual DC network and a large amount of traffic going through them. VSN cluster can be a good choice to deal with this challenge. There may be multiple different types of VSN clusters in one network. A large number of VSNs dispersed in the network brings difficulty to connect part of them and assemble them as an integrated network function. Also, there should be a flexible load balancing policy between all VSNs in one cluster to achieve good performance. At last, synchronization of status information between lots of VSNs in one or more clusters is more complicated than before and needs more consideration. Xia, et al. Expires August 1, 2014 [Page 17] Internet-Draft VNFPool Use Cases February 2014 --------------- /-------- --------\ ///// +----------+ +----------+\\\ //// |+---++---+| |+---++---+| \\\\ /// ||vFw||vFw|| ||vLB||vLB|| \\\ // |+---++---+| |+---++---+| \\ | /||vFw||vFw|| ||vLB||vLB|| | || // |+---++---+| |+---++---+| || | // +----------+ +--/-------+ | | // // | | +----/------+ +------/------+ | | | | | | | -+---------+ SBR +----...-----+ SBR +--------... | | | | | | | | +-----------+ +-------------+ | | | | | \\ // \\\ /// \\\\ //// \\\\\ ///// \-------- --------/ --------------- Figure 6: VSNs cluster As shown in Figure 10, two VSNs clusters are in network, each one consists of 4 VSNs to provide the FW and LB function in a tenant network. The service border routers connecting to them distribute different flows to each VSN for load balancing. In this case, the following requirements must be satisfied: o Supporting the integration of all connecting VSNs in one cluster to provide one network function for services; o Improving performance by providing flexible load balancing policy between VSNs in one cluster; o Supporting the synchronization of status information between lots of VSNs in one or more clusters while minimizing the complication and impaction of signaling traffic. 4.6. VSN Resilience Classes Different end-to-end services(e.g., Web, Video, financial backend, etc) have different classes of resilience requirement for the VNFs. Xia, et al. Expires August 1, 2014 [Page 18] Internet-Draft VNFPool Use Cases February 2014 The use of class-based resiliency to achieve service resiliency SLAs, without "building to peak" is critical for operators. VSN resilience classes can be specified by some attributes and metrics as followed: o Does VSN 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. Reliable Traffic Steering The characteristics shared by aggregation and mobile-backhaul networks, include a large number of nodes, middlebox appliances and applications providing layer-3 to layer-7 services. Connections are relatively static tunnel, that provide traffic multiplexing for many flows (see Figure 11: Reliable Traffic Steering). These networks are also known for their stringent requirements with regard to reliability and short recovery times. The virtualization of the aggregation network will provide optimization of resource allocation and improved traffic forwarding. Within the aforementioned networks subscriber traffic may be steered through more than one appliances or bypass some appliances completely. For example, traffic may pass through virtualized DPI and FW functions, However, once the type of the flow has been determined by the virtualized DPI function, the operator may decide to modify the services applied to it. For example, if the flow is an internet video stream, it may no longer need to pass the FW service, reducing traffic load on it. Furthermore, in order to reduce traffic load on some appliances or isolate fault on some appliances, after the service type has been detected, the subsequent packets of the same flow may no longer need to pass the LB service either; hence the path of the flow can be updated. Xia, et al. Expires August 1, 2014 [Page 19] Internet-Draft VNFPool Use Cases February 2014 --,--.,--,--,--.--,--. ,-' `-. , - Home ( ------- | | - Enviroment ( +-|--+ +-|-++----++----+ +----+ ) +-----------+( |vDPI| |vLB||vFW1||vNAT| |vFW2| ) | |( +----+ +---++----++----+ +----+ ) | +----+ |( \ | / / ) | |STB |\ |( \ | / / ) | +----+ \|--` \ / /-------/ / ) | |( \ +---+ ,--,+---+_._ _ _ / -) | +----+ |( --- | |----'|SBR|-- . ) | |PC |++++++++++++|SBR| +---+ |') ) | +----+ |(------ | |+ +---+ ) | +----+ /|( +---+ ++++'++'| |------- ) | |iPad|/ |( |SBR| ) | +----+ |( | |++++++- ) | |( +---+ ) +-----------+ . ) `- SBR-Service Border Router ,-' `-. --,--.,--,--,--.--,- , Figure 7: Reliable traffic steering In this case, the following requirements need to be satisfied: o Dynamic steering traffic through a set of virtual service nodes with each providing the same or different service [BBF-FSC-UC]; o Dynamic changes to the data path for a given traffic session/flow [BBF-FSC-UC]; o Virtualization transparency to services - services using a network function need not know whether it's a virtual function or a non- virtualized; o Virtualization transparency to network control and management - network control and management plane need not be aware whether a function is virtualized or not; o Traffic control mechanism - data and management traffic identification/separation for non-virtualized and virtualized mobile core networks. Xia, et al. Expires August 1, 2014 [Page 20] Internet-Draft VNFPool Use Cases February 2014 4.8. 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. 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 8: 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: Xia, et al. Expires August 1, 2014 [Page 21] Internet-Draft VNFPool Use Cases February 2014 Service (e.g. VOIP, Web) +----------+ +----------+ +----------+ | VNF#1 | data conn | VNF#2 | data conn | VNF#n | | Instance |-----------| Instance |- ... ... -| Instance | +----------+ +----------+ +----------+ ^ | Virtualization +--------------------------------------------------------+ | Virtualization Platform | +--------------------------------------------------------+ Figure 9: 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; 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 [BBF-FSC-UC] Broadband Forum, "Flexible Service Chaining", 2013. Xia, et al. Expires August 1, 2014 [Page 22] Internet-Draft VNFPool Use Cases February 2014 [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. [TR-101] Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", 2006. [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", January 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 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 Xia, et al. Expires August 1, 2014 [Page 23] Internet-Draft VNFPool Use Cases February 2014 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 August 1, 2014 [Page 24] Internet-Draft VNFPool Use Cases February 2014