Network Working Group L. Xia Internet-Draft Q. Wu Intended status: Standards Track Huawei Expires: January 16, 2014 D. King Lancaster University July 15, 2013 Use cases and Requirements for Virtual Service Node Pool Management draft-xia-vsnpool-management-use-case-00 Abstract Network edge applications 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 goals including: virtual application security, reliability, scalability, performance, management and automation. Note that this document is not intended to provide or recommend 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." This Internet-Draft will expire on January 16, 2014. Xia, et al. Expires January 16, 2014 [Page 1] Internet-Draft VSNPool July 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Application Availability and Reliability . . . . . . . . . . . 6 3.1. Virtualized Server . . . . . . . . . . . . . . . . . . . . 6 3.2. Virtual Service Nodes Pool (VSNP) . . . . . . . . . . . . 6 3.3. The Connectivity between Service Nodes . . . . . . . . . . 7 3.4. The Connectivity between Virtual Service Nodes Pools . . . 7 3.5. The Connectivity between Virtual Service Node Pool and Service Node . . . . . . . . . . . . . . . . . . . . . . . 8 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. IP Multimedia Core Network Subsystem (IMS) . . . . . . . . 9 4.2. Resilience for Stateful Service . . . . . . . . . . . . . 10 4.3. Auto Scale of Virtual Network Function Instances . . . . . 11 4.4. Reliable Network Connectivity between Network Nodes . . . 13 4.5. Existing Operating Virtual Network Function Instance Replacement . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Reliable Traffic Steering . . . . . . . . . . . . . . . . 15 4.7. Reliable Quality Content Offering . . . . . . . . . . . . 16 4.8. Availability of High Bandwidth Access . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Xia, et al. Expires January 16, 2014 [Page 2] Internet-Draft VSNPool July 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, and potential for increased resiliency and elasticity. Within traditional DC networks, multiple middleware boxes including FW (Fire Wall), NAT (Network Address Translation), LB (Load Balance), WoC (Wan Optimization Controller), etc., are being used to provide services, traffic control and optimization. Each function is an essential part of the entire DC network, and overall service chain. Combined these functions and capabilities can be termed as service nodes. In terms of virtualizing the DC network, a significant amount of Service nodes and Function instances within the service nodes can be initiated and virtualized, 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 are location independent, i.e., they may exist across distributed or centralized DC hardware. This architecture will pose new issues and great challenges to the automatic provision 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, mechanisms exist to define architecture and protocols 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 nodes 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, management and automation. This document is not intended to provide or recommend solutions. The Xia, et al. Expires January 16, 2014 [Page 3] Internet-Draft VSNPool July 2013 intention of this document is to present an agreed set of objectives for VSNPs, identify requirements and present architecture framing. Xia, et al. Expires January 16, 2014 [Page 4] Internet-Draft VSNPool July 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) Set-top Box (STB): This device contains Audio and Video decoders and is intended to connect to a television set and media source. Virtual Machine (VM): Software abstraction of underlying hardware. Virtualized Server (VS): A virtualized server runs a hypervisor supporting one or more VMs [NVO3-FWK]. Virtual Service Node Pool (VSNP): Virtualized server resources supporting a variety of applications. Xia, et al. Expires January 16, 2014 [Page 5] Internet-Draft VSNPool July 2013 3. Application Availability and Reliability Shifting towards virtualization of hardware function presents a number of challenges and requirements related to application availability and reliability. Redundancy via multiple instances of virtualized network function in the virtualized server (VS) or virtual service node pool (VSNP) may insulate applications and client services ultimately from certain hardware related failures and errors, but it does not present a scalable solution. Hosted applications in large DC environments, may need to deal with traffic from millions of hosts. Furthermore, there are separate availability and reliability requirements and objectives for the Virtualized Server and a VSNP, and the connectivity between VSNPs or even traditional service node pools. 3.1. Virtualized Server As highlighted earlier in this document, a number of functions or function instances may be provided on a VS. Using a VS providing firewall(FW) application as an example, VS provides multiple firewall function instances for reliability consideration, in the event of one function instance failure or resource insufficient in a VS, it would be important to detect faults and take the necessary action to resolve the problem and ensure client traffic continues to be inspected and forwarded by the FW application running on the VS. This example can be articulated as a number of objectives, documented as requirements, which are detailed below: o Application resource monitoring and health checking; o Automatic detection of application failure; o Failover to another virtual server; o Isolation and reporting of failures; o Replication of state for active/standby applications; 3.2. Virtual Service Nodes Pool (VSNP) The VS may have one or more virtual network functions running on the hypervisor. These virtual network functions may provide the same type of service or each provides different type of service. In many cases, these virtual network function instances may belong to several different VSs. In order to manage server virtualization across a set of virtualized Xia, et al. Expires January 16, 2014 [Page 6] Internet-Draft VSNPool July 2013 servers and provide fault tolerant and load sharing across VSs, the VSNPs may be initiated, facilitating the migration of a large number of virtual network function instances running on different hypervisors and belonging to different VSs to register into and deregister out. In case of function instance failure or VS overloading, such VSNPs can be used to support traditional service node replacement or service node adding. Therefore a number of similar objectives for VS instances, documented as requirements, are detailed below: o Application resource monitoring and health checking; o Automatic detection of application failure; o Failover to another VSNP; o Virtual node pool with the necessary resource availability; o Isolation and reporting of failures; o Replication of state for active/standby applications; 3.3. The Connectivity between Service Nodes The connectivity between service nodes can be used to deliver service through a set of service nodes to meet the service requirements. 3.4. The Connectivity between Virtual Service Nodes Pools One virtual service node pools can not provide registration service for all the virtual network function instances running on different hypervisor and belonging to different virtualization sever. Therefore usually we uses multiple service node pools to provide a fully distributed and fault-tolerant registration service. The connectivity between virtual service node pools can be used to maintain synchronization of data Concerning virtual network function instance scattered in different virtual service pool. By this means, every service node pool can acquire the overall information of all the virtual service nodes and provide protection for each other. Also a number of mechanisms, documented as requirements are detailed below: o Automatic detection of service node pool failure; o Failover to another virtual service node pool Xia, et al. Expires January 16, 2014 [Page 7] Internet-Draft VSNPool July 2013 o virtual node pool with the necessary resource availability; 3.5. The Connectivity between Virtual Service Node Pool and Service Node The connectivity between virtual service node pool and service node is used by virtual service pool to provide registry service to the virtual network function instance belonging to different virtual server and provide failover of the service node. A set of virtual service node pools can be configured to provide reliable registration. When one service node cannot get a register response from one virtual service node pool, it can go to another pool for registration. Xia, et al. Expires January 16, 2014 [Page 8] Internet-Draft VSNPool July 2013 4. Use Cases 4.1. IP Multimedia Core Network Subsystem (IMS) 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 1: Virtualized mobile core network and IMS). Typically these services are time dependent and may require a large number of computing resources. 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 network functions(e.g., virtualized S/P-GW and IMS functions) are down or overloaded, dynamic relocation of those virtualized network function 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 virtualized network function instance must be routed to the new location and it is desirable that the movement of the virtual network function is transparent to other virtual network function instances and or physical network entities such as client application on the UE. That is to say the other virtual network function instances 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 1: Virtualized Mobile Core Network and IMS Xia, et al. Expires January 16, 2014 [Page 9] Internet-Draft VSNPool July 2013 In this use case, the following requirements need to be satisfied: o Resource scaling - elastic service aware resource allocation to network functions; o State maintenance - network and network function state management during network function 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 Impact on other relevant functions: Minimize impact on existing non-virtualized network functions and supporting Network Operation Systems (NOS). 4.2. Resilience for Stateful Service In the Service continuity use case provided by ETSI [NFV-REL-REQ], it describes virtual middlebox appliances providing layer-3 to layer-7 services may require maintaining status information, e.g., stateful vFW. In case of hardware failure or processing overload, it is necessary to move that status information to where the vFW can keep accessing. In the meanwhile the vFW function instance offering firewall service can be moved as well and the offered service and its performance can be maintained. Another typical example is a session-based service such as SIP. The status information can be restored in the same VM where the vCSCF is moved (1:1 Resiliency) or in a different VM (1:N Resiliency) as far as the vFw can keep accessing it. In case of multiple vFw on one VM and not enough resources are available at the time of failure, a possible approach is to move some part of the virtual network function instances to a new place desirably based on the Service Level Agreement (SLA). 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 virtual network function instances in the new place and move all vFws on the failed hardware. Xia, et al. Expires January 16, 2014 [Page 10] Internet-Draft VSNPool July 2013 Limited | | Resource| Suspend| V V +----+ +----+ +----+ +----+ +----+ +----+ +----+ |vFw1| |vFw1| |vFw1| |vFw2| |vFw1| |vFw1| |vFw3| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +------------+ +------------+ +-------------------+ | VM | | VM | | VM | +------------+ +------------+ +-------------------+ +------------+ +------------+ +-------------------+ /-\ | | | | | | || Server | | Server | | Server | \-/ | | | | | +------------+ +------------+ +-------------------+ Hardware Failure Figure 2:Resilience for Stateful Service In this case, the following requirements need to be satisfied: o Support status information maintaining o Support status information moving o Support virtual network function instance moved from one VM to another VM. o Support partial virtual network function instances moving 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], the management and orchestration entity may be configured by to support dynamic scaling (increase or decrease) of allocated VMs hosting virtual network functions (see Figure 5: Auto Scale of Virtual Network Function Instance). If more service requests come to a Virtual Network Function Instance than can be accommodated in one physical hardware node, processing overload starts to occur. In this case, the movement of the Virtual Network Function Instance to another physical node with the same performance will just create the same overload situation. A more desirable approach is to replicate the Virtual Network Function Instance and distribute ones to multiple physical hardware nodes and at the same time distribute the incoming requests to those nodes. For example, some particular virtual network function instances requiring increased performance might be partitioned across multiple VMs. To guarantee this performance, the Xia, et al. Expires January 16, 2014 [Page 11] Internet-Draft VSNPool July 2013 hypervisor dynamically mediates(scaling up or scaling down) resources to each virtual network function instances 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 3: Auto Scale 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 January 16, 2014 [Page 12] Internet-Draft VSNPool July 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] use case, 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. 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 4. Reliable Network connectivity In this case, the following requirements need to be satisfied: o Adding network node instances, compute node instances and/or hypervisor instances o Removing network node instances, compute node instances and/or hypervisor instances Xia, et al. Expires January 16, 2014 [Page 13] Internet-Draft VSNPool July 2013 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 firwall 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. In this case, the following requirements need to be satisfied: 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 o Verify capacity is available for a new instance of the virtual network function instance at some location; o Instantiate the new instance of the VNF at the location; o Transfers 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 Pauses or deletes the old virtual network function instance. Xia, et al. Expires January 16, 2014 [Page 14] Internet-Draft VSNPool July 2013 4.6. 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 4: 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. --,--.,--,--,--.--,--. ,-' `-. , - Home ( ------- | | - Enviroment ( +-|--+ +-|-++----++----+ +----+ ) +-----------+( |vDPI| |vLB||vFW1||vNAT| |vFW2| ) | |( +----+ +---++----++----+ +----+ ) | +----+ |( \ | / / ) | |STB |\ |( \ | / / ) | +----+ \|--` \ / /-------/ / ) | |( \ +---+ ,--,+---+_._ _ _ / -) | +----+ |( --- | |----'|SBR|-- . ) | |PC |++++++++++++|SBR| +---+ |') ) | +----+ |(------ | |+ +---+ ) | +----+ /|( +---+ ++++'++'| |------- ) | |iPad|/ |( |SBR| ) | +----+ |( | |++++++- ) | |( +---+ ) +-----------+ . ) `- SBR-Service Border Router ,-' `-. --,--.,--,--,--.--,- , Figure 6: Reliable traffic steering Xia, et al. Expires January 16, 2014 [Page 15] Internet-Draft VSNPool July 2013 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; 4.7. Reliable Quality Content Offering Virtualization of CDNs described in the ETSI [NFV-ISG-UC] use case (see Figure 3: Virtualized CDNs network), the CDN controller (a centralized component) selects a Cache Node (CN), or a pool of CNs, to satisfy user requests and demand. A number of CNs are distributed within the network and to meet user requests and deliver content [RFC6707]. In order to deal with exponential growth of content traffic delivered to users, whilst achieving acceptable performance by shifting from broadcast to unicast delivery [RFC6707], the CDN Controller and CNs may be virtualized and the content placed closer to the user. This provides network bandwidth savings and delivery of high bandwidth content more reliably. Deploying CNs as virtual appliances on a standardized commodity hardware also allows efficient and cost effective scaling and delivery of content. Xia, et al. Expires January 16, 2014 [Page 16] Internet-Draft VSNPool July 2013 | +----------+ | | | CDN | | | |Controller| | +-+---++----------+ +-+---+ +-------+ +-------+ |vCN1 | |vCN2 | | CSP-1 | | CSP-2 | +-+-|-+ +|+---+ +-------+ +-------+ | \ /| | | | \ ,--,--,--. / | ,--,--,--./ +----------+ | ,-' `-/ | ,-' `-. | End User | =|(CDN Provider 'B')=|====(CDN Provider 'A') +----------+ | `-. (CDN-B) ,-' | `-. (CDN-A) ,-' | `--/--'\-' | `--'--'--' | / \ --+---+ +--+--+ / \---|vCN1 | |vCN2 |-/ ------+ +--+--| | | | | | vCN1-vCache Node1 vCN2=vCache Node2 CSP-1 Content Service Provider1 CSP-2 Content Service Provider2 Figure 7: Virtualized CDNs network In this case, the following requirements should be satisfied: o Cost-efficiency (cache software is often relative simple software, deployed on low-cost servers); o Performance ratio in comparison to bare metal (loss need to be outweighed by operational benefits); o Performance predictability (dimensioning would remain stable whatever the use of virtualized HW resources); o Balance of network I/O, CPU, Power, Storage I/O, Performance (including RAM and HDD); o Flexibility to fulfil 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). Xia, et al. Expires January 16, 2014 [Page 17] Internet-Draft VSNPool July 2013 4.8. Availability of High Bandwidth Access In the ETSI Virtualization of Home Environment use case [NFV-ISG-UC] it describes how home devices including the Residential Gateway (RGW) and Set-top Box (STB) (see Figure 2: Virtualized Home Network) providing service and functionality are virtualized and migrated to the service platform located in the network for provisioning simplification and service integration. The virtualized RGW (vRGW) [WT-317]provides private address to the home and deliver services to home devices. The Virtual STB (vSTB) uses a public IP address to communicate with the vRGW and its service platforms (IPTV or Internet platforms) via Broadband Network Gateway (BNG). +-----------------+ ---- | Home Network | ///- -\\\ | | / \ | +------+ | | | | | STB |-------+-+ +--| Data Center | | +------+ | | | | | | | | | \ / | +------------+ | |+------+ +-----+ | \\\- -/// | | | | || | | | | ---- | | Small +--+-++ vRGW +-----|vSTB | | | | HDMI Dongle| | || | | | | | | | | |+------+ +--+--+ | | +------------+ | | | | ---- | | | | | ///- -\\\ | | | +--+--+ | / \ | +------+ | | | | | | | | | STB +-------+-+ |BNG +---+--+ Internet | | +------+ | | | | | | | +-----+ \ / +-----------------+ \\\- -/// ---- Figure 8 Virtualized Home Network Virtualization of media services such as those provided by the vSTB will pose a variety of CPU, memory and bandwidth challenges: o Deployment of virtualized media functions, each home may source an order of 2-4 HD (or higher) streams at peak time, which adds up to more than 10-25 Mbps per home o Simplification of the home decoding functionality, streaming functionality and content protection functionality shifted to the network requires more intensive computation In this use case, the following requirements must be satisfied: Xia, et al. Expires January 16, 2014 [Page 18] Internet-Draft VSNPool July 2013 o Improved QoE by functionality such as remote access to all content and services, multi-screen support and mobility o Scalability: the functionality migration from home devices (e.g., STB, RGW, etc.) to the network implies huge amount of virtualized devices will be supported in the network. It arises the scalability challenges in terms of resource management, network bandwidth, fault detection and recovery, service availability, etc; o Service dynamics: The dynamics of the end user's applications and services drives the virtual service node to accommodate to it by frequent change of their topologies or functions; o User management and resiliency: Users expect to manage and configure their CPE devices even when they are virtualized and provided as a service. An additional challenge is to guarantee service continuity at the home during network or access link failure. Also, integration of existing management and OSS technologies must be considered. Xia, et al. Expires January 16, 2014 [Page 19] Internet-Draft VSNPool July 2013 5. IANA Considerations This document has no actions for IANA. Xia, et al. Expires January 16, 2014 [Page 20] Internet-Draft VSNPool July 2013 6. Security Considerations TBC. Xia, et al. Expires January 16, 2014 [Page 21] Internet-Draft VSNPool July 2013 7. Informative 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. [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. [RFC6707] Niven-Jenkins, B., "Content Distribution Network Interconnection (CDNI) Problem Statement", September 2012. [TR-101] Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", 2006. [VNF-PS] Zong, N., "Problem Statement for Reliable Virtualized Network Function (VNF) Pool", July 2013. [WT-317] Broadband Forum, "Network Enhanced Residential Gateway", 2013. Xia, et al. Expires January 16, 2014 [Page 22] Internet-Draft VSNPool July 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: sunseawq@huawei.com Daniel King Lancaster University UK Email: d.king@lancaster.ac.uk Xia, et al. Expires January 16, 2014 [Page 23]