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