Network Working Group L. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: April 24, 2014 D. King Lancaster University H. Yokota KDDI Lab October 21, 2013 Use cases and Requirements for Virtual Service Node Pool Management draft-xia-vsnpool-management-use-case-01 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 requirements begin to emerge. These use cases and requirements cover a broad range of capability and objectives, which will require detailed investigation and documentation in order to identify relevant architecture, protocol and procedure solutions. This document provides an analysis of the key management requirements for applications that may be hosted within a virtualized environment. These engineering requirements are based on a variety of uses cases and goals , which include: virtual application security, 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 April 24, 2014 [Page 1] Internet-Draft VSNPool October 2013 This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 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. Xia, et al. Expires April 24, 2014 [Page 2] Internet-Draft VSNPool October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Virtual Service Node (VSN) Overview . . . . . . . . . . . . . 7 3.1. Reliability of VSN, VServer, VSNP . . . . . . . . . . . . 8 3.2. Reliability of Network Connectivity . . . . . . . . . . . 9 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Virtualized Mobile Core Network and Service Systems . . . 10 4.2. Resilience for Stateful Service . . . . . . . . . . . . . 11 4.3. Auto Scale of Virtual Network Function Instances . . . . . 12 4.4. Reliable Network Connectivity between Network Nodes . . . 14 4.5. Existing Operating Virtual Network Function Instance Replacement . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Reliable vCDN . . . . . . . . . . . . . . . . . . . . . . 16 4.7. VSN Cluster . . . . . . . . . . . . . . . . . . . . . . . 16 4.8. VSN Resilience Classes . . . . . . . . . . . . . . . . . . 18 4.9. Reliable Traffic Steering . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Xia, et al. Expires April 24, 2014 [Page 3] Internet-Draft VSNPool October 2013 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, 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 environments, 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). [VNF-PS] provides an overview of the problem space related to service node reliability. This document provides an analysis of the key applications that may be hosted within a virtualized environment. These engineering requirements are based on a variety of objectives related to virtual application security, reliability, scalability, performance, operation and automation. Xia, et al. Expires April 24, 2014 [Page 4] Internet-Draft VSNPool October 2013 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. Xia, et al. Expires April 24, 2014 [Page 5] Internet-Draft VSNPool October 2013 2. 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. 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.. Xia, et al. Expires April 24, 2014 [Page 6] Internet-Draft VSNPool October 2013 3. Virtual Service Node (VSN) Overview 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 operation. +----------------------+ | | | network application | | | +---------/-\----------+ // \\ // \\ / \\ +-------------+ // \\ +-------------+ | VSNP |// \\| VSNP | | manager +----------------------+ manager | | | | | +---/-\-------+ +-----/-\-----+ / \ / \ / \ / \ / \ / \ -/----- ------------ \ // \\ //--- ---\\ // +--+-+ +----+\\ /// \\\ / |vSN1| |vSN2| \ // \\ | +----+ +----+ | // \\ | +----+ ------+ | /+----+ +----+ +----- +----+ +----\ | |VM1 | | VM2 | | | |vSN3| |vSN4| |vSN5| |vSN6| |vSN7|| | +----+ +-----+ | | +----+ +----+ +----+ +----+ +----+ | | +------------+ | | +------------+ +-------------------+ | | | | | | | VM3 | | VM4 | | | | vServer1 | | | +------------+ +-------------------+ | \ | | / | +------------+ +-------------------+ | \\ |------------// | | | | | | \\- VSNP -// | | vServer2 | | vServer3 | -------- \| | | / \\-----------+ +-----------------//+ \\ // \\\ VSNP /// \\--- ---// ------------ Xia, et al. Expires April 24, 2014 [Page 7] Internet-Draft VSNPool October 2013 Figure 1: Overall Architecture of VSNP As shown in Figure 1, the overall architecture of VSNP includes VS, VSN, VSNP, VSNP manager and the connectivity between any two VSs, and the connectivity between VSN and VSNP 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 virtualized function instance when it was designed. Note that VSNP and VSNP manager also can be used to manage traditional service node. 3.1. Reliability of VSN, VServer, VSNP 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; Xia, et al. Expires April 24, 2014 [Page 8] Internet-Draft VSNPool October 2013 o Replication of state for active/standby network functions. 3.2. Reliability of Network Connectivity The other category of reliability requirements concerns the network connectivity between any two VSNs,or any two VSNP managers and the network connectivity between VSN and VSN manager. 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 consistant and include: o Automatic detection of link failure; o Failover to another usable link; o Automated routing recovery. Xia, et al. Expires April 24, 2014 [Page 9] Internet-Draft VSNPool October 2013 4. Use Cases 4.1. Virtualized Mobile Core Network and Service Systems A key use case for NFV is the virtualization of key mobile core network functions. The ETSI NFV use case [NFV-ISG-UC] describes requirements for server and packet gateways (S/P-GW) used for Packet Data Network (PDN) connections and IMS session (see Figure 2: Virtualized mobile core network and IMS). These services are typically time dependent and may require a large number of computing resources in proportion to the number of users and/or service requests. Therefore it is desirable to scale them according to their specific computing requirements. The virtualization can be applied to the Evolved Packet Core (EPC) and the IMS to provide end to end service with service availability and resilience. When those virtualized service nodes(e.g., virtualized S/P-GW and IMS functions) are failed or overloaded, dynamic relocation of those VSNs can be performed, the relocation of the managed sessions and/or connections must be accordingly managed. It also should be noted in [NFV-REL- REQ]that the traffic in the original VSN must be routed to the new location and it is desirable that the movement of the VSN is transparent to other VSN and or physical network entities such as client application on the UE. That is to say the other VSNs don't require to take any special action to this movement. +----------------+ +---------------------------------+ | vEPC | | vIMS | | | | | | +---------+ | | +----------+ | | | | | | | | | | | vP/SGW +---+-+-| +--+ vS-CSCF | | | | | | | | | | | | | +---------+ | | | +--------+ | +----------+ | |Overload/Failure| |-+-| +---| Overload/Failure | | | | | P-CSCF | | | | ++++| +++++ | | +---------+ | + | +--------+ + +----------+ | | | | | + | + | | | | | vP/SGW +++++++ | +++| vS-CSCF | | | | | | | | | | | +---------+ | | +----------+ | | | | | | PDN Connection| | IMS Session | +----------------+ +---------------------------------+ Figure 2: Virtualized Mobile Core Network and IMS In this use case, the following requirements need to be satisfied: Xia, et al. Expires April 24, 2014 [Page 10] Internet-Draft VSNPool October 2013 o Resource scaling - elastic service aware resource allocation to network functions; o State maintenance - network and network function state management during VSN relocation, replication, and resource scaling; 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 Service Availability - achieving the same level of service availability for the end-to-end virtualized mobile core network as in non-virtualized networks with reduced cost; o Minimum impact on other relevant functions. [More detailed description needs to be discussed.] 4.2. 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 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. Xia, et al. Expires April 24, 2014 [Page 11] Internet-Draft VSNPool October 2013 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 3: 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. 4.3. 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 Xia, et al. Expires April 24, 2014 [Page 12] Internet-Draft VSNPool October 2013 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. +--------------+ +-------------------+ | | | | |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 4: 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. Xia, et al. Expires April 24, 2014 [Page 13] Internet-Draft VSNPool October 2013 4.4. 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 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. +-----------+ |Ochestrator| +-----------+ Web vDPI vCache vFW vNATPT +--------+ +--------+ +--------+ +--------+ | +----+ | | +----+ | | +-++-+ | | +----+ | |------| ------| -------| || | ----| |<----- | | | | | | | | | | | || | | | | | | | | | +----+ | | +----+ | | +-++-+ | | +----+ | | | | | | | | | | | | +----+ | | | +----+ | | +-++-+ | | | V| ,--,--,--. | | | | | | | | | | || | | | | ,-' `-. | |<->---------- | |----- | || |-----------<--> Internet ) | | | | | +----+ | | +-++-+ | | | `-. ,-' +-|--+ | | | | | | | | A `--'--'--' | | +----+ | | | | +-++-+ | | +----+ | | | | | ------------------| || ------| |<----| -------- | | | | | | || | | | | | | | +----+ | | | | +-++-+ | | +----+ | +--------+ +--------+ +--------+ +--------+ Figure 5: 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; Xia, et al. Expires April 24, 2014 [Page 14] Internet-Draft VSNPool October 2013 o Removing network node instances, compute node instances and/or hypervisor instances; o Adding or removing network links between nodes. 4.5. 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 6: 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 Xia, et al. Expires April 24, 2014 [Page 15] Internet-Draft VSNPool October 2013 mechanisms; o Pausing or deleting the old VSN instance. 4.6. Reliable vCDN Virtualization of CDNs in the ETSI [NFV-ISG-UC] use case described the CDN controller (a centralized component such as Global Load- Balancer(GLB)) selects a Cache Node(CN), or a pool of CNs, to redirect the proper CN which will deliver user request's content. The CDN Controller and CNs may be virtualized so that the resources for the vCDN can be scaled up and down according to the volume of user requests. Then, content placed closer to the user is delivered for providing cost-effective resource utilization and network bandwidth savings. In this case, the following requirements need to be satisfied: o Resource scaling (elastic virtual CN allocation according to the number of requests, proximity, etc); o Acceleration of network I/O (I/O centric application needs to overcome the network I/O degradation on the virtualized environment); o Performance monitoring (vCDN should be monitored in terms of the number of sessions, load balancing, storage usage, network throughput, etc); o Interoperating 3rd party DC infra (3rd party DC infra can be utilized to enhance vCDN coverage globally and to reduce infra cost for delivering the short-term international event); o Flexibility to fulfill specific storage density requirements, e.g. to cache a large catalog of popular content; o Ability of cache nodes to comply with main monitoring and reporting requirements (e.g., SNMP, syslog, etc. so that operator shall be able to manage different types of cache node for a Delivery Service). [More description is needed.] 4.7. 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: Xia, et al. Expires April 24, 2014 [Page 16] Internet-Draft VSNPool October 2013 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. --------------- /-------- --------\ ///// +----------+ +----------+\\\ //// |+---++---+| |+---++---+| \\\\ /// ||vFw||vFw|| ||vLB||vLB|| \\\ // |+---++---+| |+---++---+| \\ | /||vFw||vFw|| ||vLB||vLB|| | || // |+---++---+| |+---++---+| || | // +----------+ +--/-------+ | | // // | | +----/------+ +------/------+ | | | | | | | -+---------+ SBR +----...-----+ SBR +--------... | | | | | | | | +-----------+ +-------------+ | | | | | \\ // \\\ /// \\\\ //// \\\\\ ///// \-------- --------/ --------------- Figure 10: 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 Xia, et al. Expires April 24, 2014 [Page 17] Internet-Draft VSNPool October 2013 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.8. VSN 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. 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.9. 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 Xia, et al. Expires April 24, 2014 [Page 18] Internet-Draft VSNPool October 2013 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. --,--.,--,--,--.--,--. ,-' `-. , - Home ( ------- | | - Enviroment ( +-|--+ +-|-++----++----+ +----+ ) +-----------+( |vDPI| |vLB||vFW1||vNAT| |vFW2| ) | |( +----+ +---++----++----+ +----+ ) | +----+ |( \ | / / ) | |STB |\ |( \ | / / ) | +----+ \|--` \ / /-------/ / ) | |( \ +---+ ,--,+---+_._ _ _ / -) | +----+ |( --- | |----'|SBR|-- . ) | |PC |++++++++++++|SBR| +---+ |') ) | +----+ |(------ | |+ +---+ ) | +----+ /|( +---+ ++++'++'| |------- ) | |iPad|/ |( |SBR| ) | +----+ |( | |++++++- ) | |( +---+ ) +-----------+ . ) `- SBR-Service Border Router ,-' `-. --,--.,--,--,--.--,- , Figure 11: 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]; Xia, et al. Expires April 24, 2014 [Page 19] Internet-Draft VSNPool October 2013 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 April 24, 2014 [Page 20] Internet-Draft VSNPool October 2013 5. IANA Considerations This document has no actions for IANA. Xia, et al. Expires April 24, 2014 [Page 21] Internet-Draft VSNPool October 2013 6. Security Considerations TBD. Xia, et al. Expires April 24, 2014 [Page 22] Internet-Draft VSNPool October 2013 7. References 7.1. Normative References [BBF-FSC-UC] Broadband Forum, "Flexible Service Chaining", 2013. [NFV-INF-UC] "Network Functions Virtualisation Infrastructure Architecture Part 2: Use Cases", ISG INF Use Case, June 2013. [NFV-ISG-UC] "Network Function Virtualisation; Use Cases;", ISG NFV Use Case, June 2013. [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", May 2008. [RFC6707] Niven-Jenkins, B., "Content Distribution Network Interconnection (CDNI) Problem Statement", September 2012. [TR-101] Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", 2006. [WT-317] Broadband Forum, "Network Enhanced Residential Gateway", 2013. 7.2. Informative References [NFV-REL-REQ] "Network Function Virtualisation Resiliency Requirements", ISG REL Requirements, June 2013. [NVO3-FWK] Lasserre, M., "Framework for DC Network Virtualization", ID draft-ietf-nvo3-framework-00, September 2012. [VNF-PS] Zong, N., "Problem Statement for Reliable Virtualized Network Function (VNF) Pool", July 2013. Xia, et al. Expires April 24, 2014 [Page 23] Internet-Draft VSNPool October 2013 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 Daniel King Lancaster University UK Email: d.king@lancaster.ac.uk Hidetoshi Yokota KDDI Lab Japan Email: yokota@kddilabs.jp Xia, et al. Expires April 24, 2014 [Page 24]