idnits 2.17.00 (12 Aug 2021)
/tmp/idnits844/draft-zong-vnfpool-problem-statement-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 1, 2014) is 2874 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'NFV-REL' is defined on line 539, but no explicit
reference was found in the text
== Unused Reference: 'NFV-SWA' is defined on line 542, but no explicit
reference was found in the text
== Outdated reference: A later version (-02) exists of
draft-xia-vnfpool-use-cases-00
== Outdated reference: A later version (-02) exists of
draft-king-vnfpool-mobile-use-case-00
== Outdated reference: A later version (-02) exists of
draft-hares-vnf-pool-use-case-00
== Outdated reference: A later version (-09) exists of
draft-dreibholz-vnfpool-rserpool-applic-00
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group N. Zong
3 Internet-Draft L. Dunbar
4 Intended status: Informational Huawei Technologies
5 Expires: January 2, 2015 M. Shore
6 No Mountain Software
7 D. Lopez
8 Telefonica
9 G. Karagiannis
10 University of Twente
11 July 1, 2014
13 Virtualized Network Function (VNF) Pool Problem Statement
14 draft-zong-vnfpool-problem-statement-06
16 Abstract
18 Network functions are traditionally implemented on specialized
19 hardware rather than on general purpose servers, but there is a clear
20 trend to implement a number of network functions, such as firewall or
21 load balancer, as software on virtualized computing platforms. These
22 virtualized functions are called Virtualized Network Functions
23 (VNFs), which can be used to build network services. The use of VNFs
24 to build network services introduces additional challenges on
25 reliability, such as additional points of failure and the need to
26 coordinate various VNFs.
28 This document introduces a general idea of VNF Pool to support
29 reliable function provision by the VNFs. We then highlight the
30 reliability challenges and issues when using the VNFs to build
31 services. Related IETF works are also briefly described.
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on January 2, 2015.
50 Copyright Notice
52 Copyright (c) 2014 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
70 3.1. From Specialized Hardware to Virtualized Network Function 4
71 3.2. Concept of VNF Set . . . . . . . . . . . . . . . . . . . 5
72 3.3. Challenges to reliability . . . . . . . . . . . . . . . . 6
73 4. VNF Pool . . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 5. Challenges and Open Issues . . . . . . . . . . . . . . . . . 8
75 5.1. Redundancy model inside VNF . . . . . . . . . . . . . . . 8
76 5.2. State synchronization inside VNF . . . . . . . . . . . . 8
77 5.3. Interaction between VNF and Service Control Entity . . . 8
78 5.4. Reliable transport . . . . . . . . . . . . . . . . . . . 9
79 5.5. Scope Considerations . . . . . . . . . . . . . . . . . . 9
80 6. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 9
81 6.1. Reliable Server Pooling (RSerPool) . . . . . . . . . . . 9
82 6.2. Virtual Router Redundancy Protocol (VRRP) . . . . . . . . 10
83 6.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 10
84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
88 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
89 10.2. Informative References . . . . . . . . . . . . . . . . . 11
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
92 1. Introduction
94 Network functions such as firewall, load balancer, WAN optimizer are
95 conventionally deployed as specialized hardware servers in both
96 network operators' networks and data center networks, as the building
97 blocks of the network services.
99 A Virtualized Network Function (VNF) provides such network function
100 through its implementation as software instances running on general
101 purpose servers via a virtualization layer (i.e., hypervisor). VNFs
102 potentially offer benefits such as elastic service offering, reduced
103 operational and equipment costs [NFV-WP].
105 There is a trend to move network functions from specialized hardware
106 servers to general purpose servers based on virtualized computing
107 platforms, in order to build network services by using VNFs. For
108 example, in Service Function Chaining (SFC), a network service can be
109 built using a set of sequentially connected VNF instances deployed at
110 different points in the network [SFC].
112 Nevertheless, the use of VNFs can pose additional challenges on the
113 reliability of the provided services. For a VNF instance, it
114 typically would not have built-in reliability mechanisms on its host
115 (i.e., a general purpose server). Instead, there are more factors of
116 risk such as software failure at various levels including hypervisors
117 and virtual machines, hardware failure, and instance migration that
118 may make a VNF instance unreliable.
120 In order to achieve higher reliability, a VNF may adopt a pooling
121 mechanism, where a number of VNF instances with the same function can
122 be grouped as a pool to provide the function. We call such a pool a
123 VNF Pool. Conceptually, a Pool Manager is used to manage a VNF Pool,
124 e.g., selects active/standby VNF instances, and potentially interacts
125 with a Service Control Entity. A Service Control Entity is an entity
126 that combines and orchestrates a set of network functions, e.g.,
127 VNFs, to build network services. The major benefit of using VNF Pool
128 is that the reliability mechanisms such as redundancy management are
129 achieved by the VNF Pool inside the VNF and thus transparent to the
130 Service Control Entity. A VNF Pool-enabled VNF still acts as a
131 normal VNF when orchestrated by the Service Control Entity.
133 We are specifically concerned with the reliability of an individual
134 VNF based on the VNF Pool managed inside the VNF. For example, how
135 to manage the redundancy model, e.g., select active/standby for a VNF
136 instance in a VNF Pool, considering the policy and the infrastructure
137 conditions? How are the service states of a VNF instance held and
138 accessed for efficient synchronization with backup instances in a VNF
139 Pool? What pool states need to be maintained to support the pooling
140 mechanism itself, and how are such states maintained? We also
141 consider the information exchanged between the VNF and Service
142 Control Entity. For example, how can a VNF Pool be addressed by the
143 Service Control Entity? After a VNF instance failover, how does the
144 Pool Manager notify the Service Control Entity of some characteristic
145 changes of the VNF, e.g., capacity change, but without disclosure of
146 the pooling procedure?
147 Note that we do not address the reliability related control or
148 routing between adjacent VNFs that can form a network service, as
149 such coordination could be done by the Service Control Entity.
151 This document introduces a general idea of VNF Pool to support
152 reliable functions provision by the VNFs. We then highlight the
153 reliability challenges and issues when using the VNFs to build
154 services. Related IETF works are also briefly described.
156 2. Terminology
158 Reliability: capability of a functional entity to consistently
159 provide its function under various dynamic and even unexpected
160 conditions such as fault, overload, etc.
162 Service Control Entity: an entity of the service provider that
163 decides how to combine and orchestrate the network functions to build
164 network services. Examples of Service Control Entity are
165 orchestrator of DC services, SFC control plane, etc.
167 Virtualized Network Function (VNF): a VNF provides the same
168 functional behavior and interfaces as the equivalent network
169 function, but is deployed as software instance(s) building on top of
170 a virtualization layer [NFV-TERM].
172 VNF Pool: a number of VNF instances providing the same network
173 function.
175 VNF Pool Element: a VNF instance inside a VNF pool.
177 VNF Pool Manager: an entity that manages a VNF pool, and interacts
178 with the Service Control Entity to provide the network function.
180 VNF Set: a general set of VNF instances that can be grouped into
181 multiple VNF Pools, where each pool corresponds to a specific VNF and
182 different pools provide different functions.
184 3. Background
186 3.1. From Specialized Hardware to Virtualized Network Function
188 Network functions are traditionally implemented on specialized
189 hardware. There is a trend to implement a number of network
190 functions as software instances on general purpose servers, via
191 virtualized computing platforms. These virtualized functions are
192 called Virtualized Network Functions (VNFs). For example, in
193 Figure 1, virtual firewall (vFW) can be deployed as software
194 instances on general purpose servers, which could be located in Data
195 Center (DC) networks, network operators' networks, or end user
196 premises. Compared with traditional FW deployed as "standalone box"
197 built by specialized hardware and software, vFW has potential
198 advantages such as agility, scalability [NFV-WP].
200 FW vFW vFW vFW
201 +-------------+ +-----------+ +-----------+ +-----------+
202 | Specialized | |FW Software| |FW Software| |FW Software| ...
203 | Hardware |----\ +-----------+ +-----------+ +-----------+
204 | + |----/ +------------------------------------------+
205 | Software | | Virtualization Platform |
206 +-------------+ +------------------------------------------+
207 +-----------------+ +-----------------+
208 | General Purpose | | General Purpose |
209 | Server | | Server | ...
210 +-----------------+ +-----------------+
212 Figure 1: Example of vFW.
214 3.2. Concept of VNF Set
216 We call a general set of VNF instances a VNF set. A VNF set can
217 include a single or multiple types of VNF, and each type of VNF may
218 have a number of instances providing the same function. The
219 following examples are all valid VNF sets.
221 1. n vFW instances: {vFW#1,vFW#2,...,vFW#n}.
223 2. m vFW instances and k virtual load balancer (vLB) instances:
224 {vFW#1,...,vFW#m,vLB#1,...,vLB#k}.
226 To be more generic, we denote VNF-A#x the xth instance of a VNF of
227 type A (e.g., vFW), VNF-B#y the yth instance of a VNF of type B
228 (e.g., vLB), and so on.
230 A VNF set can be used as part of a Service Function Chaining (SFC)
231 [SFC], where the instances of various functions are sequentially
232 connected to build a network service. A simple example is shown in
233 Figure 2.
235 Network Service
236 +----------+ +----------+ +----------+
237 | VNF-A#x | data conn | VNF-B#y | data conn | VNF-C#z |
238 | |-----------| |-----------| |
239 +----------+ +----------+ +----------+
241 Figure 2: A VNF set used as part of a SFC.
243 Alternatively, a VNF set can be also used merely as a set of VNFs,
244 where the instances provide network functions in a parallel way. An
245 example is shown in Figure 3.
247 +----------+ +----------+ +----------+
248 | VNF-A#x | | VNF-B#y | | VNF-C#z |
249 +----------+ +----------+ +----------+
250 \ | /
251 data conn \ |data /data conn
252 \ |conn /
253 \ | /
254 +---------------+
255 | Client |
256 +---------------+
258 Figure 3: A VNF set used as multiple VNFs.
260 Some more detailed use cases of VNFs are documented in other drafts
261 [VNFPOOL-UC1] [VNFPOOL-UC2] [VNFPOOL-UC3].
263 3.3. Challenges to reliability
265 The use of VNFs introduces additional challenges to the reliability
266 of the provided network services. For a VNF instance, it typically
267 would not have built-in reliability mechanisms on its host (i.e., a
268 general purpose server). Instead, there are more factors of risk
269 that may make VNF instance unreliable.
271 1. Instance failure due to hardware failure or status change such
272 as server overload.
274 2. Instance failure due to software failure at various levels
275 including hypervisor, Virtual Machine (VM), VNF.
277 3. Instance migration caused by instance performance downgrade
278 caused by load (e.g., CPU, memory, disk I/O), server consolidation
279 or other service requirement changes. This is distinct from a
280 hard failure, although it may give the appearance of one.
282 4. VNF Pool
284 There are a number of existing technologies for providing reliable
285 functions, such as Reliable Server Pooling (RSerPool) [RFC5351],
286 Virtual Router Redundancy Protocol (VRRP) [RFC5798], amongst many
287 others. Both technologies provide the service with an abstract
288 object (e.g., pool handle in RSerPool, virtual router ID in VRRP)
289 representing a group of identical functional instances. The dynamic
290 mapping of such abstract object to the actual serving instance is
291 managed internally in the group to cover the failover procedure. The
292 advantage is to provide reliable functions in a transparent manner
293 for both end-hosts and service control entities.
295 We adopt the similar idea of VNF Pool to provide reliable network
296 functions, as shown in figure 4.
298 +------------------------+
299 | Service Control Entity |
300 +------------------------+
301 ^ ^
302 | |
303 +-----------+ +------------+
304 | |
305 v v
306 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
307 | VNF-A +--------------+ | | VNF-B +--------------+ |
308 | | Pool Manager | | | | Pool Manager | |
309 | +--------------+ | | +--------------+ |
310 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
311 | |+---------+ +---------+| | | |+---------+ +---------+| |
312 | || VNF-A#1 | ... | VNF-A#n || | | || VNF-B#1 | ... | VNF-B#m || |
313 | |+---------+ +---------+| | | |+---------+ +---------+| |
314 | | VNF-A Pool | | | | VNF-B Pool | |
315 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + |
316 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - +
318 Figure 4: VNF Pool Architecture.
320 In VNF Pool architecture, each VNF has a VNF Pool containing a number
321 of VNF instances (or VNF Pool Elements) providing the same function.
322 In this sense, a VNF set can be grouped into multiple VNF Pools,
323 where each pool corresponds to a specific VNF, thus different pools
324 provide different functions. Each VNF also has a Pool Manager that
325 manages the VNF instances in the VNF Pool. Pool Manager interacts
326 with the Service Control Entity to provide the network function.
328 The main benefit of using VNF Pool is that the pooling mechanisms
329 such as redundancy management are achieved by the VNF Pool inside the
330 VNF and thus transparent to the Service Control Entity. The Service
331 Control Entity simply interacts with the Pool Manager in each VNF to
332 request and orchestrate the network functions with desired
333 reliability level. In another word, a VNF Pool-enabled VNF still
334 acts as a normal VNF when orchestrated by the Service Control Entity.
336 5. Challenges and Open Issues
338 5.1. Redundancy model inside VNF
340 Before a live VNF instance fails, one or more backup instances in the
341 same VNF Pool need to be selected. How to select such backup
342 instances? Moreover, there are policies influencing the appropriate
343 selection of backup instance. For example, it should be avoided that
344 a live VNF instance and its backup instances are placed in a single
345 physical server, or locations with shared risks in the network. On
346 the other hand, it would be desirable to place the live and backup
347 instances in geographically closed locations. Information from the
348 underlying network may need to be collected via - e.g., the interface
349 with Application Layer Traffic Optimization (ALTO) [ALTO], or
350 Interface to Routing System (I2RS) [I2RS]. Various infrastructure
351 conditions may also need to be considered for appropriate placement
352 of instances.
354 5.2. State synchronization inside VNF
356 Service states related to the specific function performed by a VNF
357 instance, e.g., NAT translation table, TCP connection states, should
358 be synchronized between a live VNF instance and its backup instances
359 for stateful failover. Who is responsible for and how to collect,
360 hold, and access such service states to achieve efficient
361 synchronization? A VNF instance should provide negotiated level of
362 state sharing with the necessary performance to fulfill the service
363 requirements - e.g., state synchronization method, format of state
364 data, location and mechanism to access state data.
366 Other than service states, pool states could be operational
367 information of VNF pool itself, e.g. redundancy settings, backup
368 location/status, etc. What pool states need to be maintained to
369 support the pooling mechanism itself, and how are such states
370 maintained?
372 5.3. Interaction between VNF and Service Control Entity
374 Some information needs to be exchanged between a VNF and the Service
375 Control Entity when the Service Control Entity orchestrates a VNF
376 Pool-enable VNF. For example, how can a VNF Pool be addressed by the
377 Service Control Entity? A Pool Manager can advertise the locator
378 (e.g., IP address) of the active instance - subject to dynamic due to
379 failover. It is also possible to use a virtual address for the whole
380 VNF Pool (similar to RSerPool or VRRP), and map between virtual and
381 actual addresses. Moreover, after a VNF instance failover, how does
382 the Pool Manager notify the Service Control Entity of some
383 characteristic changes of the VNF, e.g., capacity change, but without
384 disclosure of the pooling procedure?
386 5.4. Reliable transport
388 The transport mechanism used to carry the pool control messages,
389 e.g., redundancy management, should provide reliable message
390 delivery. Transport redundancy mechanisms such as Multipath TCP
391 (MPTCP) [MPTCP] and the Stream Control Transmission Protocol (SCTP)
392 [RFC3286] will need to be evaluated for applicability. Latency
393 requirements for pool control message delivery must also be
394 evaluated.
396 5.5. Scope Considerations
398 Ideally, the reliability goal is that the network service provided by
399 the VNFs will continue throughout an interruption within the VNFs ,
400 and VNF instances failure or migration will not be visible to the
401 external entities. Our work of VNF Pool initially focuses on several
402 reliability mechanisms that are mainly associated with a redundancy
403 model based on a VNF Pool. Additional mechanisms may include pool
404 state maintenance only for pooling purpose. Service state
405 synchronization is out of scope for this phase.
407 We currently assume that a VNF Pool contains the instances of same
408 functional type, e.g., FW, LB, etc. Different types of VNFs are
409 envisioned to be held in separate VNF Pools. VNF Pool composed of
410 both virtualized and non-virtualized functional instances may be
411 included after further use case and requirements study.
413 We are specifically concerned with the reliability of an individual
414 VNF based on the VNF Pool managed inside the VNF. We do not address
415 the reliability related control or routing between adjacent VNFs that
416 can form a network service, as such coordination could be done by the
417 Service Control Entity.
419 We do not intend to resolve the service availability that usually
420 involves more factors including the interruptions in various OSI
421 layers, and even user perception on service performance.
423 6. Related Works
425 6.1. Reliable Server Pooling (RSerPool)
427 RSerPool supports high availability and scalability of the
428 applications through the use of pools of servers [RFC5351]. The main
429 functions of RSerPool involve server pool management, as well as
430 receiving requests from a client to bind to a desired server. The
431 applicability and gaps of RSerPool to our work of VNF Pool are
432 described in another draft [VNFPOOL-RSP].
434 6.2. Virtual Router Redundancy Protocol (VRRP)
436 VRRP specifies an election protocol that dynamically assigns
437 responsibility of a virtual router to one of the VRRP routers called
438 master on a LAN [RFC5798]. The election process provides dynamic
439 failover in the forwarding responsibility should the Master become
440 unavailable. The advantage of VRRP is a higher availability default
441 path without requiring configuration of dynamic routing or router
442 discovery protocols on every end-host.
444 6.3. Service Function Chaining (SFC)
446 A service chain defines an ordered set of service functions that must
447 be applied to packets [SFC]. Although the VNFs can be used as part
448 of a SFC, SFC and our work of VNF Pool have different focus.
450 As mentioned in the section of scope consideration, we mostly
451 consider the reliability of an individual VNF based on the VNF Pool
452 inside the VNF. We do not address the reliability related control or
453 routing between adjacent VNFs in the forwarding graph. Moreover,
454 according to VNF Pool architecture and principles, the VNF Pools will
455 be orthogonal to and invisible to the SFC. A VNF Pool-enabled VNF
456 still acts as a normal VNF when orchestrated by the SFC. Just like
457 the communication between any pool users and VNF Pool, the
458 information exchanged between the VNF Pool and the SFC may include
459 some operational information of the VNF Pool.
461 7. Security Considerations
463 Any technology which allows the insertion, deletion, reordering, or
464 manipulation of network functions has the potential to be subverted
465 by an attacker, with serious consequences. Distributed VNFs
466 introduce an additional attack vector, in which bad actors join
467 several VNFs of a service. Replay attacks have the potential to
468 create denials of service, reordering, adding, or removing VNFs. VNF
469 reliability technologies must provide cryptographic protections
470 against spoofing and insertion attacks as well as replay attacks, in
471 the form of client authentication, origin authentication on VNF
472 reliability management (control plane) traffic, and replay
473 protections. There may be circumstances under which an attacker
474 masquerading as a VNF manager can introduce data leakage or similar
475 attacks, and consequently server authentication would be required, as
476 well.
478 Failing over a VNF or otherwise transferring service state raises
479 issues related to the transfer of security state, including VNF
480 element identity and credentials, session-associated cryptographic
481 state, and so on. Where possible, transfer of security state should
482 be avoided as a matter of good practice, and this will require
483 particular attention as solutions are drafted.
485 8. IANA Considerations
487 This document has no actions for IANA.
489 9. Acknowledgements
491 The authors would like to thank Chidung Lac from Orange, Daniel King
492 from Lancaster University, Lingli Deng, Zhen Cao from China Mobile,
493 Richard Yang from Yale University, Hidetoshi Yokota from KDDI,
494 Mukhtiar Shaikh from Brocade, Qiang Zu from Ericsson, Marco Liebsch
495 from NEC, Kapil Sood from Intel, Adrian Farrel, and Susan Hares for
496 their valuable comments.
498 10. References
500 10.1. Normative References
502 TBD.
504 10.2. Informative References
506 [NFV-WP] NFV Whitepaper: "Network Function Virtualization", issue 1,
507 2012, http://portal.etsi.org/NFV/NFV_White_Paper.pdf.
509 [SFC] "Service Function Chaining (SFC)",
510 .
512 [NFV-TERM] ETSI GS NFV 003: "Terminology for Main Conceptional
513 Entities in NFV", Version 0.0.4, 2013.
515 [VNFPOOL-UC1] L. Xia, Q. Wu, D. King, H. Yokota, and N. Khan,
516 "Requirements and Use Cases for Virtual Network Functions", draft-
517 xia-vnfpool-use-cases-00, February 2014.
519 [VNFPOOL-UC2] D. King, M. Liebsch, P. Willis and J. Ryoo,
520 "Virtualization of Mobile Core Network Use Case", draft-king-vnfpool-
521 mobile-use-case-00, February 2014.
523 [VNFPOOL-UC3] S. Hares and K. Subramaniam, "Use Cases for Resource
524 Pools with Virtual Network Functions (VNFs)", draft-hares-vnf-pool-
525 use-case-00, January 2014.
527 [ALTO] "Application-Layer Traffic Optimization (alto)",
528 .
530 [I2RS] "Interface to the Routing System (i2rs)",
531 .
533 [MPTCP] "Multipath TCP (mptcp)", .
536 [RFC3286] L. Ong and J. Yoakum, "An Introduction to the Stream
537 Control Transmission Protocol (SCTP)", RFC3286, May 2002.
539 [NFV-REL] ETSI GS NFV REL 001: "Network Function Virtualization;
540 Resiliency Requirements", Version 0.0.7, 2014.
542 [NFV-SWA] ETSI GS NFV SWA 001: "Network Function Virtualization; SW
543 Architecture; Virtual Network Functions Architecture", Version 0.1.0,
544 2014.
546 [RFC5351] P. Lei, L. Ong, M. Tuexen and T. Dreibholz, "An
547 Overview of Reliable Server Pooling Protocols", RFC5351, September
548 2008.
550 [RFC5798] S. Nadas, "Virtual Router Redundancy Protocol (VRRP)
551 Version 3 for IPv4 and IPv6", RFC5798, March 2010.
553 [VNFPOOL-RSP] T. Dreibholz, M. Tuexen, M. Shore and N. Zong, "The
554 Applicability of Reliable Server Pooling (RSerPool) for Virtual
555 Network Function Resource Pooling (VNFPOOL)", draft-dreibholz-
556 vnfpool-rserpool-applic-00, October 2013.
558 Authors' Addresses
560 Ning Zong
561 Huawei Technologies
563 Email: zongning@huawei.com
565 Linda Dunbar
566 Huawei Technologies
568 Email: linda.dunbar@huawei.com
569 Melinda Shore
570 No Mountain Software
572 Email: melinda.shore@nomountain.net
574 Diego Lopez
575 Telefonica
577 Email: diego@tid.es
579 Georgios Karagiannis
580 University of Twente
582 Email: g.karagiannis@utwente.nl