Internet DRAFT - draft-wang-nfv-high-availability-gap-analysis
draft-wang-nfv-high-availability-gap-analysis
Network Working Group Y. Wang
Internet-Draft Huawei
Intended status: Standards Track December 30, 2013
Expires: July 3, 2014
NFV High-Availability Technologies Gap Analysis
draft-wang-nfv-high-availability-gap-analysis-00
Abstract
High-Availability (HA) is a very important requirement throughout the
history of carrier network, many technologies have emerged for it.
With the trend of Network Function Virtualization (NFV), network
function are migrated from dedicated hardware to software running
over COTS servers, the same SLA of HA should be provided depending on
network service itself. But some new challenges are brought by NFV,
one example is Virtualized Network Function (VNF) cluster caused by
the HA and performance limitation of individual VNF instance. For
the VNF cluster, some gaps exist between with the available HA
technologies on issues of multi-homing, state synchronization, share-
risk prevention and HA role election, especially in the network which
has a large scale deployment of NFV.
This document firstly identifies the challenges emerged within NFV
deployed networks. Then, available HA technologies are reviewed and
the detailed gap analysis between them with the new challenges is
discussed in depth. At last, the summary of these gaps is presented.
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 July 3, 2014.
Copyright Notice
Wang Expires July 3, 2014 [Page 1]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New challenges and requirements to NFV HA solution . . . . . . 5
3.1. New features of NFV . . . . . . . . . . . . . . . . . . . 5
3.2. VNF cluster . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Failure detection and handling . . . . . . . . . . . . . . 6
3.4. Consideration of central management server . . . . . . . . 7
3.5. Policy enforcement . . . . . . . . . . . . . . . . . . . . 7
3.6. NFV HA solution requirements . . . . . . . . . . . . . . . 7
4. Gaps between available HA solutions and NFV's challenges . . . 9
4.1. VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. APS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. NSR, NSF, SSO and GR . . . . . . . . . . . . . . . . . . . 11
4.5. STP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Wang Expires July 3, 2014 [Page 2]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
1. Introduction
For the benefits of reduced operational and capital costs, automated
deployment, and enhanced elasticity, Network Function (e.g.
Firewall, IPS, Load Balancer, etc) Virtualization technology would be
widely supported by DC and Carrier network. But, one key issue, the
HA requirement of NFV should be considered over again to provide the
same SLA of HA depending on the network services itself.
Considering the reliability requirements, NFV HA architecture should
support several key points detailed below:
o Redundancy mechanism: LACP, VRRP, ECMP, etc;
o Failure detection: IEEE 802.1ag, ITU-T Y.1731, BFD, MPLS(-TP) OAM,
etc;
o Failure notification: APS, etc;
o State synchronization: NSR, NSF, SSO, GR, etc;
o failure handling (switchover and failover): STP, EAPS, MPLS FRR,
etc.
[VNFP-PS] has provided the problem statement and working scope
analysis focusing on the VNF reliability and high availability
issues. One accompany draft [VNFP-UC] provides an overview of VNF HA
use cases.
In this document, we reviewed the challenges of NFV and traditional
HA solution, and summarize the gap between them.
Wang Expires July 3, 2014 [Page 3]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
2. Terminology
NFV Network Function Virtualization
VRRP Virtual Router Redundancy Protocol
STP Spanning Tree Protocol
FRR Fast Reroute
BFD Bidirectional Forwarding Detection
APS Automatic Protection Switching
HA High Availability
Wang Expires July 3, 2014 [Page 4]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
3. New challenges and requirements to NFV HA solution
As described in [VNFP-PS] and [VNFP-UC], NFV brings some new features
and requirements to current network, which also results in new
challenges to NFV HA solution in the following aspects:
3.1. New features of NFV
NFV network should support high scalability, cost reduction, high
flexibility, high automation.
o High scalability: NFV HA solution should support the large scale
network. To support the HA of large number of VNFs in virtual
network, the highly efficient and minimum impact to network HA
solution is surely needed. NFV HA solution should also support an
automatic and fast mechanism to discover and add/delete new VNFs
into/out of VNF cluster;
o Cost reduction: One of the intentions of deploying NFV is to
reduce the cost, thus, whether for the VNF cluster or working/
protection group deployment, making full use of its members by
active/active mode is the preferred choice. And, 1:N redundancy
mechanism should be the basic requirement rather than 1:1, 1+1 or
1+N. But, multiple active VNFs maybe result in a performance
problem. Because every active VNF needs to synchronize its state
to every other VNF in the same VNF cluster. The full-mesh
connectivity for state synchronization is very complex and will
consume too much bandwidth and system resource to bring additional
delay;
o High flexibility: NFV brings high flexibility to network to make
it easy for operator to scale up or down the virtualized network,
and migrate VNF instances to other location on demand. Thus, VNF
instances can be highly distributed in DC networks, Carrier
networks and even customer premises, and they can be migrated
dynamically. It is hard to located VNF VMs to fixed hosts. If
the VNF instances in the same VNF cluster are located in the same
host or the chains of VNF are crossed, it will reduce the SLA of
HA due to share-risk problem. Another problem is related to
service chain. For the consideration of HA, the working and
backup service chains should not be crossed in the same location
(e.g. host, hypervisor, VM, VNF), otherwise it will lead to a
single point of failure;
o High automation: NFV deployed network can be a large scale, highly
distributed, and highly dynamic network. Which means a large
amount of operations and functions must be automatically
performed. Otherwise, too much manual configurations and
Wang Expires July 3, 2014 [Page 5]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
interventions are not affordable. For example, the deployment and
configuration of redundancy mechanisms, the failure detection and
switchover, the adaptation to dynamic changes of VNFs should all
be performed automatically and quickly.
3.2. VNF cluster
NFV has transferred the running network functions from physical
platform to virtualized platform, always result in the limitation of
individual VNF instance's performance and reliability. So, NFV
normally uses cluster with more members to meet the performance and
reliability requirement. With the VNF numbers in VNF cluster
increasing, some aspects should be considered:
o State synchronization: State synchronization is the essential
function for NFV, especially for the clustering mechanism.
Otherwise, VNF cluster cannot work in several scenarios. One
example is when forward flow and return flow hit different VNFs.
The other example is switchover case. With the number of VNFs in
cluster increased, state synchronization between them with full
mesh becomes more complex and resource consuming. A general and
efficient technology of state synchronization for various kinds of
VNFs is needed;
o Dynamic change of VNF members' role: A VNF member's role (active,
especially standby) in VNF cluster can dynamically change in the
run time due to switchover, NFV HA solution must adapt to it.
3.3. Failure detection and handling
o Failure detection: In NFV infrastructure, failure can happen in
multiple layers: hardware, hypervisor, VM, or VNF instance. So,
the new failure detection mechanism should have the capability to
detect the failure in all these layers. This mechanism should be
simple, uniform, protocol independent, and software driven. One
candidate is BFD;
o Failure handling approaches: NFV technology brings new approaches
to handle failures rather than traditional network. For instance,
scaling up can resolve the problem of over-load. Restarting VNF
instance or VNF dynamic relocation can all be used when VNF fails.
The new HA solutions should make full use of these new NFV
features.
Wang Expires July 3, 2014 [Page 6]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
3.4. Consideration of central management server
The north bound interfaces of VNF can be connected to the central
management server to report VNF's running status. By this way,
central management server can decide the roles of VNFs in VNF cluster
and be used for the switchover mechanism. It can also be used for
the state synchronization.
3.5. Policy enforcement
There could be some policies reflecting the different reliability
class of the service and hence affecting the selection of VNF
instances. Examples would include isolation policies requiring that
VNF instances be placed on separate physical servers or separate DC
sites. Another example is to place some VNF instances in
topologically closed locations. Other policies and related HA issues
are TBD.
3.6. NFV HA solution requirements
For coping with the above new challenges, the NFV HA solution should
provide the functionalities as following:
o Redundancy mechanism
* The function to support VNF cluster with active/active mode
* The function to support 1:N redundancy of VNF cluster;
* The function to support VNFs to join/leave or scale up/down
efficiently and automatically;
* The function of share-risk prevention.
o Failure detection
* The simple, uniform, protocol independent, and software driven
function to detect the failure of multiple layers of NFV
infrastructure.
o Failure notification
* The function to notify central management server about VNF
failure;
* The function to notify other interested or influenced VNF about
VNF failure.
Wang Expires July 3, 2014 [Page 7]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
o State synchronization
* The function to support the dynamic change of VNF member's role
in VNF cluster due to switchover by tracking the binding
relationship between active VNFs with standby VNFs;
* The function to support VNF keep-alive monitoring and efficient
state synchronization to avoid full mesh connectivity by using
central controlled technology.
o Failure handling (switchover and failover)
* The function to support quick convergence for large VNF
cluster;
* The function to support central management server;
* The function to utilize new NFV features, for example scaling
up/down, restarting and dynamic relocation of VNF to overcome
VNF failure or over-load.
o Compatibility
* Supporting different provider's VNF;
* The compatibility to existed hardware network elements.
Wang Expires July 3, 2014 [Page 8]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
4. Gaps between available HA solutions and NFV's challenges
The available HA solutions are the combination of several
technologies deployed in different points of network. The overview
is as followed:
o VRRP is a common redundancy mechanisms in Layer 3 and supports
failure handling;
o BFD is a common technology for failure detection;
o APS protocol is mainly used for failure notification which
naturally leads to failure handling process;
o NSR, NSF, SSO and GR can support state synchronization between
neighboring devices or standby RP during the device restarts;
o STP and MPLS FRR are deployed as failure handling mechanisms in
Layer 2 or 3.
4.1. VRRP
The Virtual Router Redundancy Protocol (VRRP) is designed to
eliminate the single point of failure inherent in the static default
routed environment over Layer 3. The nodes or ports in the same
group share the same virtual IP address with different MAC addresses.
The elements in VRRP group elect the active role using pre-set
priority. This priority/role changes only if switchover or fallback
occurred. The active VRRP element notifies hosts in the subnet using
gratuitous ARP. If the active VRRP element fails, the standby
elements in the VRRP group would select a new active element. The
new active element will sent gratuitous ARP to notify the
corresponding hosts to update their MAC table. Consequently, the
flows with the corresponding virtual IP as destination IP will be
lead to the new active element.
VRRP works as an integration solution of redundancy and failure
handling mechanism.
For requirements of redundancy mechanism:
o VRRP supports cluster. However, there is only one active element
per VRRP group. It does not support multiple active elements in
the same group. Multiple active elements means multiple different
VRRP groups distinguished by different virtual IP. The related
hosts' gateway configuration should be planned carefully to these
IPs, which is very inflexible;
Wang Expires July 3, 2014 [Page 9]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
o VRRP can only support most 255 elements in one group, this maybe a
drawback for NFV deployment in cross DC site scenarios in the
future;
o Only active element can send VRRP ADVERTISEMENT message to notify
standby elements in same group, however standby elements can not
announce their presence. Thus the automatic discovery of new
elements is a problem for state synchronization;
o VRRP does not support share-risk prevention.
For requirements of failure handling:
o VRRP group is an autonomy system without the support of central
management server.Thus, it cannot take advantage of it to make an
optimized choice between the VRRP elements flexibly according to
their respective performance;
o The standby elements take over the load of active element when it
fails. While, if the active one fails due to overload, this is
not effective. VNF can scale up to solve this problem, while VRRP
cannot.
4.2. BFD
BFD is a lightweight hello protocol designed to run over multiple
transport protocols (e.g. IPv4, IPv6, MPLS, etc) used for Layer 3
failure detection. Any interested client (e.g. OSPF, BFP, HSRP,
etc) registers with BFD and is notified as soon as BFD detects a
neighbor loss. BFD establishes monitoring sessions between two
neighbors and detects link or node failures if no BFD packet is
received for a period.
IBFD is a good candidate of failure detection solution for the NFV
network due to its features of simplicity, efficiency, uniformity,
protocol independence, software driven. But, BFD can only detect the
failures of Layer 3 and does not support Layer 2. How it supports
the failure detection for VNF cluster and multiple layer NFV
infrastructures also needs more study.
4.3. APS
APS (Automatic Protection Switching) protocol is a mature and proven
mechanism specified for bidirectional protection switching which
needs the coordination of the two endpoints of the transport entity
in SONET/SDH networks. It can also be used for Ethernet [ITU-T
G.8031] and MPLS [ITU-T Y.1720] network now.
Wang Expires July 3, 2014 [Page 10]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
One endpoint transmits a new APS packet immediately to inform the far
end endpoint for the coordination of protection switching when a
change in the transmitted status occurs (e.g. link/node failure,
force switch, signal fail, etc).
APS protocol is mainly used for failure notification which will
naturally leads to failure handling process.
For requirements of redundancy mechanism:
o APS does not support VNF cluster with active/active mode;
o Usually, APS provide 1:1 or 1+1 backup, and no more than 1:14
backup will limit the scale of NFV network;
o APS does not support dynamic election mechanism of path role. The
role of path is pre-configured;
o APS does not support share-risk prevention.
For requirements of failure notification:
o APS does not provide north bound interface to central management
server.
For requirements of failure handling:
o APS does not support the new NFV failure handling features.
4.4. NSR, NSF, SSO and GR
TBD.
4.5. STP
The Spanning Tree Protocol (STP) is a network protocol that ensures a
loop-free topology for any bridged Ethernet local area network. The
basic function of STP is to prevent bridge loops and the broadcast
storm that results from them. Spanning tree also allows a network
design to include spare (redundant) links to provide automatic backup
paths if an active link fails, without the danger of bridge loops, or
the need for manual enabling/disabling of these backup links.
STP works as an integration solution of redundancy and failure
handling mechanism.
For requirements of redundancy mechanism:
Wang Expires July 3, 2014 [Page 11]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
o STP does not support VNF cluster with active/active mode;
o STP do not provide the elect mechanism for dynamically electing
active and standby elements in elements groups, the roles is
determined by configured network layout and pre- assigned priority
and port ID etc. After convergence, the role of port can only be
changed by manual configuration or at next time of convergence
when some ports fail;
o STP does not provide the share-risk prevention mechanism.
For requirements of failure handling:
o STP does not provide north bound interface to central management
server;
o STP does not support new NFV failure handling features.
4.6. FRR
MPLS Fast Reroute is a local restoration network resiliency
mechanism. It is actually a feature of resource reservation protocol
(RSVP) traffic engineering (RSVP-TE). In MPLS local protection each
label switched path (LSP) passing through a facility is protected by
a backup path which originates at the node immediately upstream to
that facility.
FRR works as an integration solution of redundancy and failure
handling mechanism.
For requirements of redundancy mechanism:
o FRR does not support VNF cluster with active/active mode;
o The FRR paths cannot dynamically elect active or standby paths, it
is manual configured or layout by aptotic algorithms like LFA(loop
free alternate)[RFC 5286] ;
o FRR does not support share-risk prevention;
o Usually, 2 or a little more paths can be protected in FRR, the
large number of VNFs in a cluster will make network layout very
complex.
For requirements of failure handling:
o FRR does not provide north bound interfaces to central management
server;
Wang Expires July 3, 2014 [Page 12]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
o FRR also has the similar problem with VRRP in the deployment of
new NFV failure handling features.
4.7. OAM
TBD
Wang Expires July 3, 2014 [Page 13]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
5. Summary
In conclusion, there is a gap between the available HA technologies
and the new challenges of NFV.
+--------------------+---------+---------+---------+---------+
| | VRRP | APS | STP | FRR |
+--------------------+---------+---------+---------+---------+
| Support | | | | |
| active/active | no | no | no | no |
| cluster | | | | |
+--------------------+---------+---------+---------+---------+
| Support 1:N | no | no | no | no |
| backup | | | | |
+--------------------+---------+---------+---------+---------+
| Automatic | no | no | no | no |
| scalability | | | | |
+--------------------+---------+---------+---------+---------+
| Share-risk | no | no | no | no |
| prevention | | | | |
+--------------------+---------+---------+---------+---------+
Figure 1: Gap Analysis Table of Redundancy Mechanism
Note:
1. For NFV, VNF cluster with active/active mode is one of the basic
requirements;
2. 1:N backup means 1 standby element for N active elements in one
VNF cluster.
+--------------------------------------+--------------------+
| | BFD |
+--------------------------------------+--------------------+
| Support failure detection of | TBD |
| VNF cluster and multiple layers | |
+--------------------------------------+--------------------+
Figure 2: Gap Analysis Table of failure Detection
Wang Expires July 3, 2014 [Page 14]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
+--------------------------------+--------------+
| | APS |
+--------------------------------+--------------+
| Notify central network | no |
| server | |
+--------------------------------+--------------+
| Notify related VNF | yes |
+--------------------------------+--------------+
Figure 3: Gap Analysis Table of failure Notification
+-----------------------------------------+---------------------+
| | |
+-----------------------------------------+---------------------+
| Dynamically election | |
+-----------------------------------------+---------------------+
| Full mesh avoiding | |
+-----------------------------------------+---------------------+
Figure 4: Gap Analysis Table of State Synchronization
+-------------------+---------+--------+----------+----------+
| | | | | |
| |VRRP |APS |STP |FRR |
| | | | | |
| | | | | |
+-------------------+---------+--------+----------+----------+
| North bound API |no |no |no |no |
+-------------------+---------+--------+----------+----------+
| Support new |no |no |no |no |
| NFV | | | | |
| approaches | | | | |
+-------------------+---------+--------+----------+----------+
Figure 5: Gap Analysis Table of failure handling
Wang Expires July 3, 2014 [Page 15]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
6. IANA Considerations
This document has no actions for IANA.
Wang Expires July 3, 2014 [Page 16]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
7. Security Considerations
TBD.
Wang Expires July 3, 2014 [Page 17]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
8. Informative References
[VNF-PS] Zong, N., "Problem Statement for Reliable Virtualized
Network Function (VNF) Pool",
ID draft-zong-vnfpool-problem-statement-01, September 2013.
[VNF-UC] Xia, L., "Use cases and Requirements for Virtual Service
Node Pool Management",
ID draft-xia-vsnpool-management-use-case-01, October 2013.
Wang Expires July 3, 2014 [Page 18]
Internet-Draft NFV HA Technologies Gap Analysis December 2013
Author's Address
Yang Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: alex.wangyang@huawei.com
Wang Expires July 3, 2014 [Page 19]
