< draft-zong-vnfpool-problem-statement-05.txt   draft-zong-vnfpool-problem-statement-06.txt >
Network Working Group N. Zong Network Working Group N. Zong
Internet-Draft L. Dunbar Internet-Draft L. Dunbar
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: November 6, 2014 M. Shore Expires: January 2, 2015 M. Shore
No Mountain Software No Mountain Software
D. Lopez D. Lopez
Telefonica Telefonica
G. Karagiannis G. Karagiannis
University of Twente University of Twente
May 5, 2014 July 1, 2014
Virtualized Network Function (VNF) Pool Problem Statement Virtualized Network Function (VNF) Pool Problem Statement
draft-zong-vnfpool-problem-statement-05 draft-zong-vnfpool-problem-statement-06
Abstract Abstract
Network functions are traditionally implemented on specialized Network functions are traditionally implemented on specialized
hardware rather than on general purpose servers, but there is a clear hardware rather than on general purpose servers, but there is a clear
trend to implement a number of network functions, such as firewall or trend to implement a number of network functions, such as firewall or
load balancer, as software on virtualized computing platforms. These load balancer, as software on virtualized computing platforms. These
virtualized functions are called Virtualized Network Functions virtualized functions are called Virtualized Network Functions
(VNFs), which can be used to build network services. The use of VNFs (VNFs), which can be used to build network services. The use of VNFs
to build network services introduces additional challenges on to build network services introduces additional challenges on
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. From Specialized Hardware to Virtualized Network Function 4 3.1. From Specialized Hardware to Virtualized Network Function 4
3.2. The Concept of VNF Set . . . . . . . . . . . . . . . . . 5 3.2. Concept of VNF Set . . . . . . . . . . . . . . . . . . . 5
3.3. Challenges to reliability . . . . . . . . . . . . . . . . 6
4. VNF Pool . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. VNF Pool . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Challenges and Open Issues . . . . . . . . . . . . . . . . . 7 5. Challenges and Open Issues . . . . . . . . . . . . . . . . . 8
5.1. Risk factors for unreliable instance . . . . . . . . . . 7 5.1. Redundancy model inside VNF . . . . . . . . . . . . . . . 8
5.2. Redundancy model inside VNF . . . . . . . . . . . . . . . 8 5.2. State synchronization inside VNF . . . . . . . . . . . . 8
5.3. State synchronization inside VNF . . . . . . . . . . . . 8 5.3. Interaction between VNF and Service Control Entity . . . 8
5.4. Interaction between VNF and Service Control Entity . . . 8 5.4. Reliable transport . . . . . . . . . . . . . . . . . . . 9
5.5. Reliable transport . . . . . . . . . . . . . . . . . . . 9 5.5. Scope Considerations . . . . . . . . . . . . . . . . . . 9
5.6. Scope Considerations . . . . . . . . . . . . . . . . . . 9
6. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Reliable Server Pool (RSerPool) . . . . . . . . . . . . . 9 6.1. Reliable Server Pooling (RSerPool) . . . . . . . . . . . 9
6.2. Virtual Router Redundancy Protocol (VRRP) . . . . . . . . 10 6.2. Virtual Router Redundancy Protocol (VRRP) . . . . . . . . 10
6.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 10 6.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 16 skipping to change at page 3, line 16
through its implementation as software instances running on general through its implementation as software instances running on general
purpose servers via a virtualization layer (i.e., hypervisor). VNFs purpose servers via a virtualization layer (i.e., hypervisor). VNFs
potentially offer benefits such as elastic service offering, reduced potentially offer benefits such as elastic service offering, reduced
operational and equipment costs [NFV-WP]. operational and equipment costs [NFV-WP].
There is a trend to move network functions from specialized hardware There is a trend to move network functions from specialized hardware
servers to general purpose servers based on virtualized computing servers to general purpose servers based on virtualized computing
platforms, in order to build network services by using VNFs. For platforms, in order to build network services by using VNFs. For
example, in Service Function Chaining (SFC), a network service can be example, in Service Function Chaining (SFC), a network service can be
built using a set of sequentially connected VNF instances deployed at built using a set of sequentially connected VNF instances deployed at
different points in the network [SFC]. We call a general set of VNF different points in the network [SFC].
instances a VNF set. A VNF set can include a single or multiple VNFs
(e.g., virtual firewall, virtual load balancer, etc.), and each VNF
may have a number of instances providing the same function. A VNF
set can be used not only as part of a SFC, but also merely as a set
of VNFs without specific topological constraint.
In order to provide reliable function, a VNF uses a VNF Pool to
contain a number of VNF instances providing the same function. In
this sense, a VNF set can be grouped into multiple VNF Pools, where
each pool corresponds to a specific VNF, thus different pools provide
different functions. A VNF also has a Pool Manager that manages the
VNF Pool and interacts with the Service Control Entity. A Service
Control Entity is an entity that combines and orchestrates a set of
network functions, i.e., VNFs, to build network services. The major
benefit of using VNF Pool is that the reliability mechanisms such as
redundancy management are achieved by the VNF Pool inside the VNF and
thus transparent to the Service Control Entity. A VNF Pool-enabled
VNF still acts as a normal VNF when orchestrated by the Service
Control Entity.
Nevertheless, the use of VNFs can pose additional challenges on the Nevertheless, the use of VNFs can pose additional challenges on the
reliability of the provided services. For a VNF instance, it reliability of the provided services. For a VNF instance, it
typically would not have built-in reliability mechanisms on its host typically would not have built-in reliability mechanisms on its host
(i.e., a general purpose server). Instead, there are more factors of (i.e., a general purpose server). Instead, there are more factors of
risk such as software failure, hardware failure, and instance risk such as software failure at various levels including hypervisors
migration that may make VNF instance unreliable. We are specifically and virtual machines, hardware failure, and instance migration that
concerned with the reliability of an individual VNF based on the VNF may make a VNF instance unreliable.
Pool managed inside the VNF. For example, how to manage the
redundancy model, e.g., active/standby for a VNF instance in a VNF In order to achieve higher reliability, a VNF may adopt a pooling
Pool? How are the service states of a VNF instance held and accessed mechanism, where a number of VNF instances with the same function can
for efficient synchronization with backup instances in a VNF Pool? be grouped as a pool to provide the function. We call such a pool a
We also consider the information exchanged between the VNF and VNF Pool. Conceptually, a Pool Manager is used to manage a VNF Pool,
Service Control Entity. For example, how can a VNF Pool be addressed e.g., selects active/standby VNF instances, and potentially interacts
by the Service Control Entity? When a live VNF instance goes out of with a Service Control Entity. A Service Control Entity is an entity
service, how does the Service Control Entity learn which VNF instance that combines and orchestrates a set of network functions, e.g.,
will replace it, and learn the characteristic of the new instance? VNFs, to build network services. The major benefit of using VNF Pool
is that the reliability mechanisms such as redundancy management are
achieved by the VNF Pool inside the VNF and thus transparent to the
Service Control Entity. A VNF Pool-enabled VNF still acts as a
normal VNF when orchestrated by the Service Control Entity.
We are specifically concerned with the reliability of an individual
VNF based on the VNF Pool managed inside the VNF. For example, how
to manage the redundancy model, e.g., select active/standby for a VNF
instance in a VNF Pool, considering the policy and the infrastructure
conditions? How are the service states of a VNF instance held and
accessed for efficient synchronization with backup instances in a VNF
Pool? What pool states need to be maintained to support the pooling
mechanism itself, and how are such states maintained? We also
consider the information exchanged between the VNF and Service
Control Entity. For example, how can a VNF Pool be addressed by the
Service Control Entity? After a VNF instance failover, how does the
Pool Manager notify the Service Control Entity of some characteristic
changes of the VNF, e.g., capacity change, but without disclosure of
the pooling procedure?
Note that we do not address the reliability related control or Note that we do not address the reliability related control or
routing between adjacent VNFs in the whole VNF set, as such routing between adjacent VNFs that can form a network service, as
coordination could be done by the Service Control Entity. Also note such coordination could be done by the Service Control Entity.
that we only focus on reliability mechanisms based on VNF Pool.
Other management aspects of VNF such as scaling, and load balancing
are out of scope, although they are probably complementary to
reliability in order to provide network services.
This document introduces a general idea of VNF Pool to support This document introduces a general idea of VNF Pool to support
reliable functions provision by the VNFs. We then highlight the reliable functions provision by the VNFs. We then highlight the
reliability challenges and issues when using the VNFs to build reliability challenges and issues when using the VNFs to build
services. Related IETF works are also briefly described. services. Related IETF works are also briefly described.
2. Terminology 2. Terminology
Reliability: capability of a functional entity to consistently Reliability: capability of a functional entity to consistently
provide its function under various dynamic and even unexpected provide its function under various dynamic and even unexpected
skipping to change at page 5, line 27 skipping to change at page 5, line 23
| + |----/ +------------------------------------------+ | + |----/ +------------------------------------------+
| Software | | Virtualization Platform | | Software | | Virtualization Platform |
+-------------+ +------------------------------------------+ +-------------+ +------------------------------------------+
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| General Purpose | | General Purpose | | General Purpose | | General Purpose |
| Server | | Server | ... | Server | | Server | ...
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 1: Example of vFW. Figure 1: Example of vFW.
3.2. The Concept of VNF Set 3.2. Concept of VNF Set
We call a general set of VNF instances a VNF set. A VNF set can We call a general set of VNF instances a VNF set. A VNF set can
include a single or multiple VNFs, and each VNF may have a number of include a single or multiple types of VNF, and each type of VNF may
instances providing the same function. The following examples are have a number of instances providing the same function. The
all valid VNF sets. following examples are all valid VNF sets.
1. n vFW instances: {vFW#1,vFW#2,...,vFW#n}. 1. n vFW instances: {vFW#1,vFW#2,...,vFW#n}.
2. m vFW instances and k virtual load balancer (vLB) instances: 2. m vFW instances and k virtual load balancer (vLB) instances:
{vFW#1,...,vFW#m,vLB#1,...,vLB#k}. {vFW#1,...,vFW#m,vLB#1,...,vLB#k}.
To be more generic, we denote VNF-A#x the xth instance of a VNF of To be more generic, we denote VNF-A#x the xth instance of a VNF of
type A (e.g., vFW), VNF-B#y the yth instance of a VNF of type B type A (e.g., vFW), VNF-B#y the yth instance of a VNF of type B
(e.g., vLB), and so on. (e.g., vLB), and so on.
skipping to change at page 6, line 33 skipping to change at page 6, line 25
\ | / \ | /
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
Figure 3: A VNF set used as multiple VNFs. Figure 3: A VNF set used as multiple VNFs.
Some more detailed use cases of VNFs are documented in other drafts Some more detailed use cases of VNFs are documented in other drafts
[VNFPOOL-UC1] [VNFPOOL-UC2] [VNFPOOL-UC3]. [VNFPOOL-UC1] [VNFPOOL-UC2] [VNFPOOL-UC3].
3.3. Challenges to reliability
The use of VNFs introduces additional challenges to the reliability
of the provided network services. For a VNF instance, it typically
would not have built-in reliability mechanisms on its host (i.e., a
general purpose server). Instead, there are more factors of risk
that may make VNF instance unreliable.
1. Instance failure due to hardware failure or status change such
as server overload.
2. Instance failure due to software failure at various levels
including hypervisor, Virtual Machine (VM), VNF.
3. Instance migration caused by instance performance downgrade
caused by load (e.g., CPU, memory, disk I/O), server consolidation
or other service requirement changes. This is distinct from a
hard failure, although it may give the appearance of one.
4. VNF Pool 4. VNF Pool
There are a number of existing technologies for providing reliable There are a number of existing technologies for providing reliable
functions, such as Reliable Server Pool (RSerPool) [RFC5351], Virtual functions, such as Reliable Server Pooling (RSerPool) [RFC5351],
Router Redundancy Protocol (VRRP) [RFC5798], amongst many others. Virtual Router Redundancy Protocol (VRRP) [RFC5798], amongst many
Both technologies provide the service with an abstract object (e.g., others. Both technologies provide the service with an abstract
pool handle in RSerPool, virtual router ID in VRRP) representing a object (e.g., pool handle in RSerPool, virtual router ID in VRRP)
group of identical functional instances. The dynamic mapping of such representing a group of identical functional instances. The dynamic
abstract object to the actual serving instance is managed internally mapping of such abstract object to the actual serving instance is
in the group to cover the failover procedure. The advantage is to managed internally in the group to cover the failover procedure. The
provide reliable functions in a transparent manner for both end-hosts advantage is to provide reliable functions in a transparent manner
and service control entities. for both end-hosts and service control entities.
We adopt the similar idea of VNF Pool to provide reliable network We adopt the similar idea of VNF Pool to provide reliable network
functions, as shown in figure 4. functions, as shown in figure 4.
+------------------------+ +------------------------+
| Service Control Entity | | Service Control Entity |
+------------------------+ +------------------------+
^ ^ ^ ^
| | | |
+-----------+ +------------+ +-----------+ +------------+
skipping to change at page 7, line 45 skipping to change at page 8, line 7
The main benefit of using VNF Pool is that the pooling mechanisms The main benefit of using VNF Pool is that the pooling mechanisms
such as redundancy management are achieved by the VNF Pool inside the such as redundancy management are achieved by the VNF Pool inside the
VNF and thus transparent to the Service Control Entity. The Service VNF and thus transparent to the Service Control Entity. The Service
Control Entity simply interacts with the Pool Manager in each VNF to Control Entity simply interacts with the Pool Manager in each VNF to
request and orchestrate the network functions with desired request and orchestrate the network functions with desired
reliability level. In another word, a VNF Pool-enabled VNF still reliability level. In another word, a VNF Pool-enabled VNF still
acts as a normal VNF when orchestrated by the Service Control Entity. acts as a normal VNF when orchestrated by the Service Control Entity.
5. Challenges and Open Issues 5. Challenges and Open Issues
5.1. Risk factors for unreliable instance 5.1. Redundancy model inside VNF
For a VNF instance, it typically would not have built-in reliability
mechanisms on its host (i.e., a general purpose server). Instead,
there are more factors of risk that may make VNF instance unreliable.
1. Instance failure due to hardware failure or status change such
as server overload.
2. Instance failure due to software failure at various levels
including hypervisor, Virtual Machine (VM), VNF.
3. Instance migration caused by instance performance downgrade
caused by load (e.g., CPU, memory, disk I/O), server consolidation
or other service requirement changes. This is distinct from a
hard failure, although it may give the appearance of one.
5.2. Redundancy model inside VNF
Before a live VNF instance fails, one or more backup instances in the Before a live VNF instance fails, one or more backup instances in the
same VNF Pool need to be selected. How to select such backup same VNF Pool need to be selected. How to select such backup
instances? Moreover, there are policies influencing the appropriate instances? Moreover, there are policies influencing the appropriate
selection of backup instance. For example, it should be avoided that selection of backup instance. For example, it should be avoided that
a live VNF instance and its backup instances are placed in a single a live VNF instance and its backup instances are placed in a single
physical server, or locations with shared risks in the network. On physical server, or locations with shared risks in the network. On
the other hand, it would be desirable to place the live and backup the other hand, it would be desirable to place the live and backup
instances in geologically closed locations. Information from the instances in geographically closed locations. Information from the
underlying network may need to be collected via - e.g., the interface underlying network may need to be collected via - e.g., the interface
with Application Layer Traffic Optimization (ALTO) [ALTO], or with Application Layer Traffic Optimization (ALTO) [ALTO], or
Interface to Routing System (I2RS) [I2RS]. Interface to Routing System (I2RS) [I2RS]. Various infrastructure
conditions may also need to be considered for appropriate placement
of instances.
5.3. State synchronization inside VNF 5.2. State synchronization inside VNF
Service states related to the specific function performed by a VNF Service states related to the specific function performed by a VNF
instance, e.g., NAT translation table, TCP connection states, should instance, e.g., NAT translation table, TCP connection states, should
be synchronized between a live VNF instance and its backup instances be synchronized between a live VNF instance and its backup instances
for stateful failover. Who is responsible for and how to collect, for stateful failover. Who is responsible for and how to collect,
hold, and access such service states to achieve efficient hold, and access such service states to achieve efficient
synchronization? A VNF instance should provide negotiated level of synchronization? A VNF instance should provide negotiated level of
state sharing with the necessary performance to fulfill the service state sharing with the necessary performance to fulfill the service
requirements - e.g., state synchronization method, format of state requirements - e.g., state synchronization method, format of state
data, location and mechanism to access state data. data, location and mechanism to access state data.
5.4. Interaction between VNF and Service Control Entity Other than service states, pool states could be operational
information of VNF pool itself, e.g. redundancy settings, backup
location/status, etc. What pool states need to be maintained to
support the pooling mechanism itself, and how are such states
maintained?
5.3. Interaction between VNF and Service Control Entity
Some information needs to be exchanged between a VNF and the Service Some information needs to be exchanged between a VNF and the Service
Control Entity when the Service Control Entity orchestrates a VNF Control Entity when the Service Control Entity orchestrates a VNF
Pool-enable VNF. For example, how can a VNF Pool be addressed by the Pool-enable VNF. For example, how can a VNF Pool be addressed by the
Service Control Entity? A Pool Manager can advertise the locator Service Control Entity? A Pool Manager can advertise the locator
(e.g., IP address) of the active instance - subject to dynamic due to (e.g., IP address) of the active instance - subject to dynamic due to
failover. It is also possible to use a virtual address for the whole failover. It is also possible to use a virtual address for the whole
VNF Pool (similar to RSerPool or VRRP), and map between virtual and VNF Pool (similar to RSerPool or VRRP), and map between virtual and
actual addresses. Moreover, when a live VNF instance goes out of actual addresses. Moreover, after a VNF instance failover, how does
service, how does the Service Control Entity learn which VNF instance the Pool Manager notify the Service Control Entity of some
will replace it, and learn the characteristic of the new instance? characteristic changes of the VNF, e.g., capacity change, but without
disclosure of the pooling procedure?
5.5. Reliable transport 5.4. Reliable transport
The transport mechanism used to carry the pool control messages, The transport mechanism used to carry the pool control messages,
e.g., redundancy management, should provide reliable message e.g., redundancy management, should provide reliable message
delivery. Transport redundancy mechanisms such as Multipath TCP delivery. Transport redundancy mechanisms such as Multipath TCP
(MPTCP) [MPTCP] and the Stream Control Transmission Protocol (SCTP) (MPTCP) [MPTCP] and the Stream Control Transmission Protocol (SCTP)
[RFC3286] will need to be evaluated for applicability. Latency [RFC3286] will need to be evaluated for applicability. Latency
requirements for pool control message delivery must also be requirements for pool control message delivery must also be
evaluated. evaluated.
5.6. Scope Considerations 5.5. Scope Considerations
Ideally, the reliability goal is that the network service provided by Ideally, the reliability goal is that the network service provided by
the VNFs will continue throughout an interruption within the VNFs , the VNFs will continue throughout an interruption within the VNFs ,
and VNF instances failure or migration will not be visible to the and VNF instances failure or migration will not be visible to the
external entities. Our work of VNF Pool initially focuses on several external entities. Our work of VNF Pool initially focuses on several
reliability mechanisms that are mainly associated with a redundancy reliability mechanisms that are mainly associated with a redundancy
model of a VNF. Additional reliability mechanisms including state model based on a VNF Pool. Additional mechanisms may include pool
synchronization may be included after future gap analysis between state maintenance only for pooling purpose. Service state
identified requirements [NFV-REL] and existing IETF technologies. We synchronization is out of scope for this phase.
currently assume that a VNF Pool contains the instances of same
functional type, e.g., FW, LB, etc. In a subsequent step, after We currently assume that a VNF Pool contains the instances of same
identifying the use cases and requirements, we may consider more functional type, e.g., FW, LB, etc. Different types of VNFs are
types of VNF Pool, such as those composed by the instances of envisioned to be held in separate VNF Pools. VNF Pool composed of
different VNF Components (VNFCs) [NFV-SWA]. both virtualized and non-virtualized functional instances may be
included after further use case and requirements study.
We are specifically concerned with the reliability of an individual We are specifically concerned with the reliability of an individual
VNF based on the VNF Pool managed inside the VNF. We do not address VNF based on the VNF Pool managed inside the VNF. We do not address
the reliability related control or routing between adjacent VNFs in the reliability related control or routing between adjacent VNFs that
the whole VNF set, as such coordination could be done by the Service can form a network service, as such coordination could be done by the
Control Entity. Service Control Entity.
We do not work on other management aspects of VNF such as scaling, or We do not intend to resolve the service availability that usually
load balancing, even though these aspects may be complementary to involves more factors including the interruptions in various OSI
reliability in order to provide network services. We do not intend layers, and even user perception on service performance.
to resolve the service availability that usually involves more
factors including the interruptions in various OSI layers, and even
user perception on service performance.
6. Related Works 6. Related Works
6.1. Reliable Server Pool (RSerPool) 6.1. Reliable Server Pooling (RSerPool)
RSerPool supports high availability and scalability of the RSerPool supports high availability and scalability of the
applications through the use of pools of servers [RFC5351]. The main applications through the use of pools of servers [RFC5351]. The main
functions of RSerPool involve server pool management, as well as functions of RSerPool involve server pool management, as well as
receiving requests from a client to bind to a desired server. The receiving requests from a client to bind to a desired server. The
applicability and gaps of RSerPool to our work of VNF Pool are applicability and gaps of RSerPool to our work of VNF Pool are
described in another draft [VNFPOOL-RSP]. described in another draft [VNFPOOL-RSP].
6.2. Virtual Router Redundancy Protocol (VRRP) 6.2. Virtual Router Redundancy Protocol (VRRP)
skipping to change at page 10, line 29 skipping to change at page 10, line 29
A service chain defines an ordered set of service functions that must A service chain defines an ordered set of service functions that must
be applied to packets [SFC]. Although the VNFs can be used as part be applied to packets [SFC]. Although the VNFs can be used as part
of a SFC, SFC and our work of VNF Pool have different focus. of a SFC, SFC and our work of VNF Pool have different focus.
As mentioned in the section of scope consideration, we mostly As mentioned in the section of scope consideration, we mostly
consider the reliability of an individual VNF based on the VNF Pool consider the reliability of an individual VNF based on the VNF Pool
inside the VNF. We do not address the reliability related control or inside the VNF. We do not address the reliability related control or
routing between adjacent VNFs in the forwarding graph. Moreover, routing between adjacent VNFs in the forwarding graph. Moreover,
according to VNF Pool architecture and principles, the VNF Pools will according to VNF Pool architecture and principles, the VNF Pools will
be orthogonal to and invisible to the SFC. A VNF Pool-enabled VNF be orthogonal to and invisible to the SFC. A VNF Pool-enabled VNF
still acts as a normal VNF when orchestrated by the SFC. Information still acts as a normal VNF when orchestrated by the SFC. Just like
exchanged between the VNF Pool and SFC could be operational the communication between any pool users and VNF Pool, the
information of the VNF Pool including pool address, pool instance information exchanged between the VNF Pool and the SFC may include
characteristic, and so on. some operational information of the VNF Pool.
7. Security Considerations 7. Security Considerations
Any technology which allows the insertion, deletion, reordering, or Any technology which allows the insertion, deletion, reordering, or
manipulation of network functions has the potential to be subverted manipulation of network functions has the potential to be subverted
by an attacker, with serious consequences. Distributed VNFs by an attacker, with serious consequences. Distributed VNFs
introduce an additional attack vector, in which bad actors join introduce an additional attack vector, in which bad actors join
several VNFs of a service. Replay attacks have the potential to several VNFs of a service. Replay attacks have the potential to
create denials of service, reordering, adding, or removing VNFs. VNF create denials of service, reordering, adding, or removing VNFs. VNF
reliability technologies must provide cryptographic protections reliability technologies must provide cryptographic protections
skipping to change at page 11, line 22 skipping to change at page 11, line 22
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Chidung Lac from Orange, Daniel King The authors would like to thank Chidung Lac from Orange, Daniel King
from Lancaster University, Lingli Deng, Zhen Cao from China Mobile, from Lancaster University, Lingli Deng, Zhen Cao from China Mobile,
Richard Yang from Yale University, Hidetoshi Yokota from KDDI, Richard Yang from Yale University, Hidetoshi Yokota from KDDI,
Mukhtiar Shaikh from Brocade, Qiang Zu from Ericsson, Marco Liebsch Mukhtiar Shaikh from Brocade, Qiang Zu from Ericsson, Marco Liebsch
from NEC, Susan Hares, for their valuable comments. from NEC, Kapil Sood from Intel, Adrian Farrel, and Susan Hares for
their valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
TBD. TBD.
10.2. Informative References 10.2. Informative References
[NFV-WP] NFV Whitepaper: "Network Function Virtualization", issue 1, [NFV-WP] NFV Whitepaper: "Network Function Virtualization", issue 1,
2012, http://portal.etsi.org/NFV/NFV_White_Paper.pdf. 2012, http://portal.etsi.org/NFV/NFV_White_Paper.pdf.
[SFC] "Service Function Chaining (SFC)", <http://datatracker.ietf.org [SFC] "Service Function Chaining (SFC)",
/wg/sfc/>. <http://datatracker.ietf.org/wg/sfc/>.
[NFV-TERM] ETSI GS NFV 003: "Terminology for Main Conceptional [NFV-TERM] ETSI GS NFV 003: "Terminology for Main Conceptional
Entities in NFV", Version 0.0.4, 2013. Entities in NFV", Version 0.0.4, 2013.
[VNFPOOL-UC1] L. Xia, Q. Wu, D. King, H. Yokota, and N. Khan, [VNFPOOL-UC1] L. Xia, Q. Wu, D. King, H. Yokota, and N. Khan,
"Requirements and Use Cases for Virtual Network Functions", draft- "Requirements and Use Cases for Virtual Network Functions", draft-
xia-vnfpool-use-cases-00, February 2014. xia-vnfpool-use-cases-00, February 2014.
[VNFPOOL-UC2] D. King, M. Liebsch, P. Willis and J. Ryoo, [VNFPOOL-UC2] D. King, M. Liebsch, P. Willis and J. Ryoo,
"Virtualization of Mobile Core Network Use Case", draft-king-vnfpool- "Virtualization of Mobile Core Network Use Case", draft-king-vnfpool-
mobile-use-case-00, February 2014. mobile-use-case-00, February 2014.
[VNFPOOL-UC3] S. Hares and K. Subramaniam, "Use Cases for Resource [VNFPOOL-UC3] S. Hares and K. Subramaniam, "Use Cases for Resource
Pools with Virtual Network Functions (VNFs)", draft-hares-vnf-pool- Pools with Virtual Network Functions (VNFs)", draft-hares-vnf-pool-
use-case-00, January 2014. use-case-00, January 2014.
[ALTO] "Application-Layer Traffic Optimization (alto)", <http:// [ALTO] "Application-Layer Traffic Optimization (alto)",
datatracker.ietf.org/wg/alto/>. <http://datatracker.ietf.org/wg/alto/>.
[I2RS] "Interface to the Routing System (i2rs)", <http:// [I2RS] "Interface to the Routing System (i2rs)",
datatracker.ietf.org/wg/i2rs/>. <http://datatracker.ietf.org/wg/i2rs/>.
[MPTCP] "Multipath TCP (mptcp)", <http://datatracker.ietf.org/wg/ [MPTCP] "Multipath TCP (mptcp)", <http://datatracker.ietf.org/wg/
mptcp/>. mptcp/>.
[RFC3286] L. Ong and J. Yoakum, "An Introduction to the Stream [RFC3286] L. Ong and J. Yoakum, "An Introduction to the Stream
Control Transmission Protocol (SCTP)", RFC3286, May 2002. Control Transmission Protocol (SCTP)", RFC3286, May 2002.
[NFV-REL] ETSI GS NFV REL 001: "Network Function Virtualization; [NFV-REL] ETSI GS NFV REL 001: "Network Function Virtualization;
Resiliency Requirements", Version 0.0.7, 2014. Resiliency Requirements", Version 0.0.7, 2014.
[NFV-SWA] ETSI GS NFV SWA 001: "Network Function Virtualization; SW [NFV-SWA] ETSI GS NFV SWA 001: "Network Function Virtualization; SW
Architecture; Virtual Network Functions Architecture", Version 0.1.0, Architecture; Virtual Network Functions Architecture", Version 0.1.0,
2014. 2014.
[RFC5351] P. Lei, L. Ong, M. Tuexen and T. Dreibholz, "An Overview of [RFC5351] P. Lei, L. Ong, M. Tuexen and T. Dreibholz, "An
Reliable Server Pooling Protocols", RFC5351, September 2008. Overview of Reliable Server Pooling Protocols", RFC5351, September
2008.
[RFC5798] S. Nadas, "Virtual Router Redundancy Protocol (VRRP) [RFC5798] S. Nadas, "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC5798, March 2010. Version 3 for IPv4 and IPv6", RFC5798, March 2010.
[VNFPOOL-RSP] T. Dreibholz, M. Tuexen, M. Shore and N. Zong, "The [VNFPOOL-RSP] T. Dreibholz, M. Tuexen, M. Shore and N. Zong, "The
Applicability of Reliable Server Pooling (RSerPool) for Virtual Applicability of Reliable Server Pooling (RSerPool) for Virtual
Network Function Resource Pooling (VNFPOOL)", draft-dreibholz- Network Function Resource Pooling (VNFPOOL)", draft-dreibholz-
vnfpool-rserpool-applic-00, October 2013. vnfpool-rserpool-applic-00, October 2013.
Authors' Addresses Authors' Addresses
Ning Zong Ning Zong
Huawei Technologies Huawei Technologies
Email: zongning@huawei.com Email: zongning@huawei.com
 End of changes. 38 change blocks. 
128 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/