One document matched: draft-xia-vsnpool-management-use-case-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-xia-vsnpool-management-use-case-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="VSNPool">Use cases and Requirements for Virtual Service
Node Pool Management</title>
<author fullname="Liang Xia" initials="L." surname="Xia">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>frank.xialiang@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Daniel King" initials="D." surname="King">
<organization>Lancaster University</organization>
<address>
<postal>
<street></street>
<country>UK</country>
</postal>
<email>d.king@lancaster.ac.uk</email>
</address>
</author>
<date year="2013" />
<area>Routing Area</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Virtual Service Node Pool</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
<t>Note that this document is not intended to provide or recommend
solutions.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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).</t>
<t>[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. </t>
<t>This document is not intended to provide or recommend solutions. The
intention of this document is to present an agreed set of objectives for
VSNPs, identify requirements and present architecture framing.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="Broadband Network Gateway (BNG):">IP Edge Route where
bandwidth and QoS policies may be applied, to support multi-service
delivery [TR-101].</t>
<t hangText="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.</t>
<t hangText="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].</t>
<t hangText="IP Multimedia Subsystem (IMS):">The IP Multimedia
Subsystem used within mobile core networks.</t>
<t hangText="Network Functions Virtualization (NFV):">Moving network
function from dedicated hardware platforms onto industry standard
high volume servers, switches and storage.</t>
<t hangText="Residential Gateway (RGW)"></t>
<t hangText="Set-top Box (STB):">This device contains Audio and
Video decoders and is intended to connect to a television set and
media source.</t>
<t hangText="Virtual Machine (VM):">Software abstraction of
underlying hardware.</t>
<t hangText="Virtualized Server (VS):">A virtualized server runs a
hypervisor supporting one or more VMs [NVO3-FWK].</t>
<t hangText="Virtual Service Node Pool (VSNP):">Virtualized server
resources supporting a variety of applications.</t>
</list></t>
</section>
<section title="Application Availability and Reliability">
<t>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. </t>
<t>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.</t>
<section title="Virtualized Server">
<t>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: <list style="symbols">
<t>Application resource monitoring and health checking;</t>
<t>Automatic detection of application failure;</t>
<t>Failover to another virtual server;</t>
<t>Isolation and reporting of failures;</t>
<t>Replication of state for active/standby applications;</t>
</list></t>
</section>
<section title="Virtual Service Nodes Pool (VSNP)">
<t>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. </t>
<t>In order to manage server virtualization across a set of
virtualized 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: <list style="symbols">
<t>Application resource monitoring and health checking;</t>
<t>Automatic detection of application failure;</t>
<t>Failover to another VSNP;</t>
<t>Virtual node pool with the necessary resource availability;</t>
<t>Isolation and reporting of failures;</t>
<t>Replication of state for active/standby applications;</t>
</list></t>
</section>
<section title="The Connectivity between Service Nodes">
<t>The connectivity between service nodes can be used to deliver
service through a set of service nodes to meet the service
requirements.</t>
</section>
<section title="The Connectivity between Virtual Service Nodes Pools">
<t>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.</t>
<t>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:
<list style="symbols">
<t>Automatic detection of service node pool failure;</t>
<t>Failover to another virtual service node pool</t>
<t>virtual node pool with the necessary resource availability;</t>
</list></t>
</section>
<section title="The Connectivity between Virtual Service Node Pool and Service Node ">
<t>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.</t>
</section>
</section>
<section title="Use Cases">
<section title="IP Multimedia Core Network Subsystem (IMS)">
<t>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.</t>
<figure title="Figure 1: Virtualized Mobile Core Network and IMS">
<artwork>
+----------------+ +---------------------------------+
| vEPC | | vIMS |
| | | |
| +---------+ | | +----------+ |
| | | | | | | |
| | vP/SGW +---+-+-| +--+ vS-CSCF | |
| | | | | | | | | |
| +---------+ | | | +--------+ | +----------+ |
|Overload/Failure| |-+-| +---| Overload/Failure |
| | | | P-CSCF | |
| | ++++| +++++ |
| +---------+ | + | +--------+ + +----------+ |
| | | | + | + | | |
| | vP/SGW +++++++ | +++| vS-CSCF | |
| | | | | | | |
| +---------+ | | +----------+ |
| | | |
| PDN Connection| | IMS Session |
+----------------+ +---------------------------------+
</artwork>
</figure>
<t>In this use case, the following requirements need to be
satisfied:<list style="symbols">
<t>Resource scaling - elastic service aware resource allocation to
network functions;</t>
<t>State maintenance - network and network function state
management during network function relocation, replication, and
resource scaling;</t>
<t>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;</t>
<t>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;</t>
<t>Impact on other relevant functions: Minimize impact on existing
non-virtualized network functions and supporting Network Operation
Systems (NOS).</t>
</list></t>
</section>
<section title="Resilience for Stateful Service">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure title="Figure 2:Resilience for Stateful Service">
<artwork>
Limited | |
Resource| Suspend|
V V
+----+ +----+ +----+ +----+ +----+ +----+ +----+
|vFw1| |vFw1| |vFw1| |vFw2| |vFw1| |vFw1| |vFw3|
+----+ +----+ +----+ +----+ +----+ +----+ +----+
+------------+ +------------+ +-------------------+
| VM | | VM | | VM |
+------------+ +------------+ +-------------------+
+------------+ +------------+ +-------------------+
/-\ | | | | |
| || Server | | Server | | Server |
\-/ | | | | |
+------------+ +------------+ +-------------------+
Hardware
Failure
</artwork>
</figure>
<t>In this case, the following requirements need to be satisfied:<list
style="symbols">
<t>Support status information maintaining</t>
<t>Support status information moving</t>
<t>Support virtual network function instance moved from one VM to
another VM.</t>
<t>Support partial virtual network function instances moving</t>
</list></t>
</section>
<section title="Auto Scale of Virtual Network Function Instances">
<t>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 hypervisor dynamically
mediates(scaling up or scaling down) resources to each virtual network
function instances in line with the current or predicted performance
needs.</t>
<figure title="Figure 3: Auto Scale of virtual network Function Instances">
<artwork>
+--------------+
+-------------------+ | |
| | |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 | |
| +-------------+ | :
| |
+-------------------+</artwork>
</figure>
<t>In this case, the following requirements need to be satisfied:<list
style="symbols">
<t>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;</t>
<t>Resource scaling - elastic service aware resource allocation to
network functions;</t>
</list></t>
</section>
<section title="Reliable Network Connectivity between Network Nodes">
<t>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.</t>
<figure title="Figure 4. Reliable Network connectivity">
<artwork>
+-----------+
|Ochestrator|
+-----------+
Web
vDPI vCache vFW vNATPT
+--------+ +--------+ +--------+ +--------+
| +----+ | | +----+ | | +-++-+ | | +----+ |
|------| ------| -------| || | ----| |<-----
| | | | | | | | | | | || | | | | | | |
| | +----+ | | +----+ | | +-++-+ | | +----+ | |
| | | | | | | | | |
+----+ | | | +----+ | | +-++-+ | | | V| ,--,--,--.
| | | | | | | | | | || | | | | ,-' `-.
| |<->---------- | |----- | || |-----------<--> Internet )
| | | | | +----+ | | +-++-+ | | | `-. ,-'
+-|--+ | | | | | | | | A `--'--'--'
| | +----+ | | | | +-++-+ | | +----+ | |
| | | ------------------| || ------| |<----|
-------- | | | | | | || | | | | | |
| +----+ | | | | +-++-+ | | +----+ |
+--------+ +--------+ +--------+ +--------+
</artwork>
</figure>
<t>In this case, the following requirements need to be satisfied:<list
style="symbols">
<t>Adding network node instances, compute node instances and/or
hypervisor instances</t>
<t>Removing network node instances, compute node instances and/or
hypervisor instances</t>
<t>Adding or removing network links between nodes</t>
</list></t>
</section>
<section title="Existing Operating Virtual Network Function Instance Replacement">
<t>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: <figure
title="Figure 5. Existing vFW replacement">
<artwork>
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| |
| +---++---+ | | +---++---+ |
+------------+ +------------+
</artwork>
</figure><list style="symbols">
<t>Verify capacity is available for a new instance of the virtual
network function instance at some location;</t>
<t>Instantiate the new instance of the VNF at the location;</t>
<t>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;</t>
<t>Pauses or deletes the old virtual network function
instance.</t>
</list></t>
</section>
<section title="Reliable Traffic Steering">
<t>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.</t>
<t>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.</t>
<figure title="Figure 6: Reliable traffic steering">
<artwork> --,--.,--,--,--.--,--.
,-' `-.
, -
Home ( ------- | | -
Enviroment ( +-|--+ +-|-++----++----+ +----+ )
+-----------+( |vDPI| |vLB||vFW1||vNAT| |vFW2| )
| |( +----+ +---++----++----+ +----+ )
| +----+ |( \ | / / )
| |STB |\ |( \ | / / )
| +----+ \|--` \ / /-------/ / )
| |( \ +---+ ,--,+---+_._ _ _ / -)
| +----+ |( --- | |----'|SBR|-- . )
| |PC |++++++++++++|SBR| +---+ |') )
| +----+ |(------ | |+ +---+ )
| +----+ /|( +---+ ++++'++'| |------- )
| |iPad|/ |( |SBR| )
| +----+ |( | |++++++- )
| |( +---+ )
+-----------+ . )
`- SBR-Service Border Router ,-'
`-. --,--.,--,--,--.--,- ,</artwork>
</figure>
<t>In this case, the following requirements need to be satisfied:<list
style="symbols">
<t>Dynamic steering traffic through a set of virtual service nodes
with each providing the same or different service
[BBF-FSC-UC];</t>
<t>Dynamic changes to the data path for a given traffic
session/flow [BBF-FSC-UC];</t>
<t>Virtualization transparency to services - services using a
network function need not know whether it's a virtual function or
a non- virtualized;</t>
<t>Virtualization transparency to network control and management -
network control and management plane need not be aware whether a
function is virtualized or not;</t>
<t>Traffic control mechanism - data and management traffic
identification/separation for non-virtualized and virtualized
mobile core networks;</t>
</list></t>
</section>
<section title="Reliable Quality Content Offering">
<t>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.</t>
<figure title="Figure 7: Virtualized CDNs network">
<artwork> | +----------+ |
| | 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</artwork>
</figure>
<t>In this case, the following requirements should be satisfied:<list
style="symbols">
<t>Cost-efficiency (cache software is often relative simple
software, deployed on low-cost servers);</t>
<t>Performance ratio in comparison to bare metal (loss need to be
outweighed by operational benefits);</t>
<t>Performance predictability (dimensioning would remain stable
whatever the use of virtualized HW resources);</t>
<t>Balance of network I/O, CPU, Power, Storage I/O, Performance
(including RAM and HDD);</t>
<t>Flexibility to fulfil specific storage density requirements,
e.g. to cache a large catalog of popular content;</t>
<t>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).</t>
</list></t>
</section>
<section title="Availability of High Bandwidth Access">
<t>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).</t>
<figure>
<artwork>
+-----------------+ ----
| Home Network | ///- -\\\
| | / \
| +------+ | | |
| | STB |-------+-+ +--| Data Center |
| +------+ | | | | |
| | | | \ /
| +------------+ | |+------+ +-----+ | \\\- -///
| | | | || | | | | ----
| | Small +--+-++ vRGW +-----|vSTB | |
| | HDMI Dongle| | || | | | |
| | | | |+------+ +--+--+ |
| +------------+ | | | | ----
| | | | | ///- -\\\
| | | +--+--+ | / \
| +------+ | | | | | | |
| | STB +-------+-+ |BNG +---+--+ Internet |
| +------+ | | | | |
| | +-----+ \ /
+-----------------+ \\\- -///
----
Figure 8 Virtualized Home Network</artwork>
</figure>
<t>Virtualization of media services such as those provided by the vSTB
will pose a variety of CPU, memory and bandwidth challenges: <list
style="symbols">
<t>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</t>
<t>Simplification of the home decoding functionality, streaming
functionality and content protection functionality shifted to the
network requires more intensive computation</t>
</list></t>
<t>In this use case, the following requirements must be satisfied:
<list style="symbols">
<t>Improved QoE by functionality such as remote access to all
content and services, multi-screen support and mobility</t>
<t>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;</t>
<t>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;</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Security Considerations">
<t>TBC.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="NFV-ISG-UC">
<front>
<title>Network Function Virtualisation; Use Cases;</title>
<author>
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
<seriesInfo name="ISG" value="NFV Use Case" />
</reference>
<reference anchor="NFV-INF-UC">
<front>
<title>Network Functions Virtualisation Infrastructure Architecture
Part 2: Use Cases</title>
<author>
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
<seriesInfo name="ISG" value="INF Use Case" />
</reference>
<reference anchor="NFV-REL-REQ">
<front>
<title>Network Function Virtualisation Resiliency
Requirements</title>
<author>
<organization></organization>
</author>
<date month="June" year="2013" />
</front>
<seriesInfo name="ISG" value="REL Requirements" />
</reference>
<reference anchor="VNF-PS">
<front>
<title>Problem Statement for Reliable Virtualized Network Function
(VNF) Pool</title>
<author fullname="Ning.Zong" initials="N." surname="Zong">
<organization></organization>
</author>
<date month="July" year="2013" />
</front>
</reference>
<reference anchor="TR-101">
<front>
<title>Migration to Ethernet-Based DSL Aggregation</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="WT-317">
<front>
<title>Network Enhanced Residential Gateway</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="BBF-FSC-UC">
<front>
<title>Flexible Service Chaining</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="NVO3-FWK">
<front>
<title>Framework for DC Network Virtualization</title>
<author fullname="M.Lasserre" initials="M." surname="Lasserre">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-nvo3-framework-00" />
</reference>
<reference anchor="RFC6707">
<front>
<title>Content Distribution Network Interconnection (CDNI) Problem
Statement</title>
<author fullname="B.Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:45:29 |