< draft-king-vnfpool-mobile-use-case-00.txt		draft-king-vnfpool-mobile-use-case-01.txt >
			Network Working Group D. King
	Network Working Group D. King		Internet-Draft Lancaster University
	Internet-Draft Lancaster University		Intended status: Standards Track M. Liebsch
	Intended status: Standards Track M. Liebsch		Expires: December 8, 2014 NEC
	Expires: August, 2014 NEC		P. Willis
	P. Willis		BT
	BT		J. Ryoo
	J. Ryoo		ETRI
	ETRI		June 8, 2014
	February 14, 2014
	Virtualisation of Mobile Core Network Use Case		Virtualisation of Mobile Core Network Use Case
	draft-king-vnfpool-mobile-use-case-00		draft-king-vnfpool-mobile-use-case-01
	Abstract		Abstract
	Accessing the Internet via mobile data services using smartphones,		Accessing the Internet via mobile data services using smartphones,
	tablets, and mobile data USB dongles has increased rapidly, as		tablets, and mobile data USB dongles has increased rapidly, as
	high-speed packet data networks provide the bandwidth required for		high-speed packet data networks provide the bandwidth required for
	today's Internet applications. Mobile operators will continue to		today's Internet applications. Mobile operators will continue to
	evolve their core networks to the Long Term Evolution (LTE)		evolve their core networks to the Long Term Evolution (LTE)
	Evolved Packet Core (EPC) to meet the mobility, latency and		Evolved Packet Core (EPC) to meet the mobility, latency and
	bandwidth requirements for mobile data users.		bandwidth requirements for mobile data users.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 48 ¶
	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 August, 2014.		This Internet-Draft will expire on December 8, 2014.
	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
	1.1 Operator Benefits of Virtualization.........................3		1.1 Operator Benefits of Virtualization.........................3
	2. Terminology....................................................3		2. Terminology....................................................3
	3. Virtual Evolved Packet Core (vEPC).............................4		3. Virtual Evolved Packet Core (vEPC).............................4
	3.1 Mobile Core Network Components..............................4		3.1 Mobile Core Network Components..............................5
	3.1.1 Mobile Network Nodes...................................5		3.1.1 Mobile Network Nodes...................................5
	3.1.2 Mobile Network Functions...............................5		3.1.2 Mobile Network Functions...............................5
	3.2 Resiliency Requirements for the vEPC........................5		3.2 Resiliency Requirements for the vEPC........................6
	3.2.1 Handling Unplanned Traffic Peaks.......................6		3.2.1 Handling Unplanned Traffic Peaks.......................7
	3.2.2 Scaling and Load Balancing of Resources and Functions..7		3.2.2 Scaling of Resources and Functions.....................7
	3.2.3 vEPC Failure Handling..................................9		3.2.3 vEPC Failure Handling..................................10
	3.3 Reliable vEPC Service Function Chains (SFC).................10		3.2.4 State Synchronization..................................12
	3.4 Applicability of Virtual Network Function Pool (VNFPool)....10		3.3 Applicability of Virtual Network Function Pool (VNF Pool)...12
	4. IANA Considerations............................................11		3.3.1 VNF Pool Definitions...................................13
	5. Security Considerations........................................11		4. IANA Considerations............................................13
	6. References.....................................................11		5. Security Considerations........................................13
	6.1 Normative References.......................................11		6. References.....................................................13
	6.2 Informative References.....................................11		6.1 Normative References.......................................13
	Authors' Addresses................................................11		6.2 Informative References.....................................13
			Authors' Addresses................................................13
	1. Introduction		1. Introduction
	Mobile operators have deploying Long Term Evolution (LTE) Evolved		Mobile operators have deploying Long Term Evolution (LTE) Evolved
	Packet Core (EPC) to meet the mobility, latency and bandwidth		Packet Core (EPC) to meet the mobility, latency and bandwidth
	requirements for a variety of mobile data users. The EPC is the		requirements for a variety of mobile data users. The EPC is the
	latest evolution of the [3GPP-R8] core network architecture, and is		latest evolution of the [3GPP-R8] core network architecture, and is
	based on IP.		based on IP.
	The EPC architecture is said to have a "flat architecture" with		The EPC architecture is said to have a "flat architecture" with
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 12 ¶
	Evolved Packet Core (EPC): is an evolution of the 3GPP GPRS system		Evolved Packet Core (EPC): is an evolution of the 3GPP GPRS system
	characterized by a higher-data-rate, lower-latency, packet-		characterized by a higher-data-rate, lower-latency, packet-
	optimized system.		optimized system.
	Home Subscriber Server (HSS): a database that contains		Home Subscriber Server (HSS): a database that contains
	user-related and subscriber-related information. It also provides		user-related and subscriber-related information. It also provides
	support functions in mobility management, call and session setup,		support functions in mobility management, call and session setup,
	user authentication and access authorization.		user authentication and access authorization.
	Mobility Management Entity (MME) provides the signalling related		Mobility Management Entity (MME) provides the signaling related
	to mobility and security for Evolved UMTS Terrestrial Radio Access		to mobility and security for Evolved UMTS Terrestrial Radio Access
	Network (E-UTRAN) access.		Network (E-UTRAN) access.
	Packet Data Network Gateway (PDN GW): is the point of interconnect		Packet Data Network Gateway (PDN GW): is the point of interconnect
	between the EPC and the external IP networks.		between the EPC and the external IP networks.
	Policy and Charging Rules Function (PCRF): provides policy and		Policy and Charging Rules Function (PCRF): provides policy and
	service control and the appropriate interfaces towards the mobile		service control and the appropriate interfaces towards the mobile
	charging and billing systems.		charging and billing systems.
	Serving GW (SGW): is the interconnect between the radio-side and the		Serving GW (SGW): is the interconnect between the radio-side and the
	EPC. The SGW serves the User Equipment (UE) by routing the incoming		EPC. The SGW serves the User Equipment (UE) by routing the incoming
	and outgoing IP packets.		and outgoing IP packets.
			Virtualized Network Function (VNF): a VNF provides the same
			functional behavior and interfaces as the equivalent network
			function, but is deployed as software instances building on top of a
			virtualization layer.
			VNF Pool: a group of VNF instances providing the same network
			function.
			VNF Pool Element: a VNF instance inside a VNF pool.
			VNF Pool Manager: an entity that manages a VNF pool, and interacts
			with the service control entity to provide the network function.
			VNF Set: a group of VNF instances that can be used to build network
			services.
	3. Virtual Evolved Packet Core (vEPC)		3. Virtual Evolved Packet Core (vEPC)
	Deploying and operating mobile core network functions on		Deploying and operating mobile core network functions on
	commodity hardware resources may provide significant network usage		commodity hardware resources may provide significant network usage
	efficiency and reductions in operational expenditure. Increased		efficiency and reductions in operational expenditure. Increased
	automation would also accommodate scaling of voice and mobile data		automation would also accommodate scaling of voice and mobile data
	demands.		demands.
	The ETSI NFV use case [NFV-ISG-UC] describes requirements for		The ETSI NFV use case [NFV-ISG-UC] describes requirements for
	server and packet gateways used for Packet Data Network		server and packet gateways used for Packet Data Network
	skipping to change at page 5, line 35 ¶		skipping to change at page 6, line 4 ¶
	o Network Address Translation (NAT);		o Network Address Translation (NAT);
	o Load Balancing (LB);		o Load Balancing (LB);
	o Deep Packet Inspection (DPI);		o Deep Packet Inspection (DPI);
	o TCP Optimization of Traffic Flows;		o TCP Optimization of Traffic Flows;
	o HTTP Enrichment of Traffic Flows;		o HTTP Enrichment of Traffic Flows;
	o Video Stream Optimization;		o Video Stream Optimization;
	o Video Content Caching.		o Video Content Caching.
	3.2 vEPC Resiliency Requirements		3.2 vEPC Resiliency Requirements
	When those virtualized service nodes(e.g., virtualized S/P-GW and		When those virtualized service nodes(e.g., virtualized S/P-GW and
	IMS functions) are failed or overloaded, dynamic relocation of		IMS functions) are failed or overloaded, dynamic relocation of
	those VSNs can be performed, the relocation of the managed		VNFs can be performed, the relocation of the managed
	sessions and/or connections must be accordingly managed. It also		sessions and/or connections must be accordingly managed. It also
	should be noted in [NFV-REL-REQ] that the traffic in the original		should be noted in [NFV-REL-REQ] that the traffic in the original
	VSN must be routed to the new location and it is desirable that		VSN must be routed to the new location and it is desirable that
	the movement of the VSN is transparent to other VSN and or		the movement of the VSN is transparent to other VSN and or
	physical network entities such as client application on the UE.		physical network entities such as client application on the UE.
	That is to say the other VSNs do not require to take any special		That is to say the other VSNs do not require to take any special
	action to this movement.		action to this movement.
	+----------------+ +---------------------------------+		+----------------+ +---------------------------------+
	| vEPC | | vIMS |		| vEPC | | vIMS |
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 28 ¶
	unplanned traffic surges due to unforeseen circumstances:		unplanned traffic surges due to unforeseen circumstances:
	o A recent earthquake in Japan caused the demand for calls to		o A recent earthquake in Japan caused the demand for calls to
	increase to 150% capacity in the effected area. Calls were dropped		increase to 150% capacity in the effected area. Calls were dropped
	due to the network capacity.		due to the network capacity.
	o At the time the capacity in other areas was only 50%. In a vEPC		o At the time the capacity in other areas was only 50%. In a vEPC
	environment the free resources from the other areas could have been		environment the free resources from the other areas could have been
	used to manage this additional load.		used to manage this additional load.
	3.2.2 Scaling and Load Balancing of Resources and Functions		3.2.2 Scaling of Resources and Functions
	The Evolved Packet System (EPS) is built from logical network		The Evolved Packet System (EPS) is built from logical network
	functions, e.g. MME, PDN Gateway, Serving Gateway and Radio Base		functions, e.g. MME, PDN Gateway, Serving Gateway and Radio Base
	station (evolved NodeB) which are connected through the specified		station (evolved NodeB) which are connected through the specified
	architectures references points. The 3GPP standard considers load		architectures references points. The 3GPP standard considers load
	balancing between different logical network functions of the same		balancing between different logical network functions of the same
	type. For example, Radio Base stations can choose one out of		type. For example, Radio Base stations can choose one out of
	multiple available MMEs according to load-based weight factors to		multiple available MMEs according to load-based weight factors to
	register an attaching mobile device. Mobile network operators can		register an attaching mobile device. Mobile network operators can
	dimension their network in terms of numbers of required MMEs or		dimension their network in terms of numbers of required MMEs or
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 51 ¶
	Virtualization technology enables adding additional resources as		Virtualization technology enables adding additional resources as
	logical network functions by means of instantiation of the relevant		logical network functions by means of instantiation of the relevant
	functions in virtual machines. The instantiation of additional		functions in virtual machines. The instantiation of additional
	virtualized PDN Gateways or MMEs requires the announcement of their		virtualized PDN Gateways or MMEs requires the announcement of their
	availability to other network components of the EPS. New attachments		availability to other network components of the EPS. New attachments
	can then be balanced and distributed between an increased number of		can then be balanced and distributed between an increased number of
	available network functions. Such procedure for scale-out suits the		available network functions. Such procedure for scale-out suits the
	adaptation of the EPS resources to an increasing demand with low time		adaptation of the EPS resources to an increasing demand with low time
	constraints, e.g. due to an expected increase in subscribers or		constraints, e.g. due to an expected increase in subscribers or
	traffic		traffic volume.
	volume.
	Unexpected increase in traffic or subscribers' attempt to request		Unexpected increase in traffic or subscribers' attempt to request
	mobile service can result from scheduled events, e.g. festivals, or		mobile service can result from scheduled events, e.g. festivals, or
	in particular after disaster events, such as an earthquake. The		in particular after disaster events, such as an earthquake. The
	latter case in particular requires the mobile network to handle		latter case in particular requires the mobile network to handle
	service requests and traffic from a huge amount of active mobile		service requests and traffic from a huge amount of active mobile
	subscribers.		subscribers.
	Communication services during disaster events are essential, not only		Communication services during disaster events are essential, not only
	to provide a communication platform for rescue workers, but also to		to provide a communication platform for rescue workers, but also to
	allow private subscribers to communicate with relatives.		allow private subscribers to communicate with relatives.
	Such unexpected increase in active subscribers and traffic volume		Such unexpected increase in active subscribers and traffic volume
	should not result in dropped connections, e.g. forced disconnects to		should not result in dropped connections, e.g. forced disconnects to
	offload existing subscriber states and traffic volume. It is		offload existing subscriber states and traffic volume. It is
	preferable to scale-out resources internal to a single logical		preferable to scale-out resources internal to a single logical
	network function, e.g. an MME or a PDN Gateway. The advantage of		network function, e.g. an MME or a PDN Gateway. The advantage of
	such network function-internal resources scaling is the in-dependency		such network function-internal resources scaling is the in-dependency
	of and transparency to external network functions and EPC protocols.		of and transparency to external network functions and EPC protocols.
	Functionality and resources for a virtualized Network Function (vNF)		Functionality and resources for a particular Virtualized Network
	may be provisioned by the interplay of multiple virtualized Network		Function (VNF) may be provisioned by the interplay of multiple
	Function Component (vNFC), whose instances map 1:1 to virtual		virtualized Network Function Components (VNFC), whose instances
	machines. Scale-out internally to a single instance of a vNF can		map 1:1, or m:1, to virtual machines. Scaling up internally of a
	be accomplished by the instantiation of additional vNFC instances.		single instance of a VNF may be accomplished by the instantiation
	Load on the vNF must then be balanced between the multiple vNFC		of additional VNFC instances. Load on the VNF must then be
	instances (LB). Such scaling must remain transparent to external		balanced between the multiple VNFC instances (LB). Such scaling
	network entities.		must remain transparent to external network entities and to other
			VNFs.
	Virtual Network Function		Virtual Network Function
	+-----------------------------+		+-----------------------------+
	| +--+ +----+ |		| +--+ +----+ |
	<========>|LB|<--+--->|vNFC| |		<========>|LB|<--+--->|vNFC| |
	| +--+ | +----+ |		| +--+ | +----+ |
	| +----+ | +----+ |		| +----+ | +----+ |
	| |vNFC|<--+--->|vNFC| |		| |vNFC|<--+--->|vNFC| |
	| +----+ +----+ |		| +----+ +----+ |
	| |		| |
	+-----------------------------+		+-----------------------------+
	Figure 2: Composition of multiple vNFC instances		Figure 2: Composition of multiple VNFC instances to build a single
	to build a single vNF.		VNF.
	Technology for vNF scaling must also provide means to scale-in and		Technology for VNF scaling must also provide means to scale-in and
	reduce the number of resources in terms of required vNFCs, which		reduce the number of resources in terms of required VNFCs, which
	build a vNF.		provide the required network function.
	Some key requirements for scaling in the view of virtualized EPC		Technology for VNF scaling must also provide means to scale-in and
			reduce the number of resources in terms of required VNFs, which
			provide the required network function.
			Some general requirements for scaling in the view of virtualized EPC
	network functions:		network functions:
	o Transparency and compatibility of network functions virtualization		o Transparency and compatibility of network functions virtualization
	to legacy EPS components;		to legacy EPS components;
	o Support for scale-out of virtualized Network Functions,		o Support for scale-out of VNFs, representing additional logical
	representing additional logical EPC network functions;		EPC network functions;
	o Inter-working with configuration management (OSS) to configure and		o Inter-working with configuration management (OSS) to configure and
	announce new Network Functions to the EPS;		announce new Network Functions to the EPS;
	o Automation of scaling and simplified OAM;		o Automation of scaling and simplified OAM;
	o Virtualized Network Function-internal scale-out and load balancing;		o VNF-internal scale-out and resiliency management;
			o Support of scale-in and associated shut down of VNFC instances;
			handling of states associated with VNFCs, which are to be shut
			down (state depletion vs. state transfer/offload);
	o Support of scale-in and associated shut down of vNFC instances;
	handling of states associated with vNFCs, which are to be shut down
	(state depletion vs. state transfer/offload);
	o (non-critical: VM aggregation to fewer host servers, e.g. to enable		o (non-critical: VM aggregation to fewer host servers, e.g. to enable
	host server power saving).		host server power saving).
			Service requirements for the scaling of VNFs from VNFPool
			perspective, based on the current working group scope of
			work:
			o Balancing load between VNFs within a VNFPool;
			o Inter-working with system-wide (e.g. EPS) load balancing, e.g.
			cellular-specific selection of VNFs;
			o Compatibility with system-wide addressing of selected VNFs.
			VNFPool solutions may consider different addressing schemes
			and associated address mapping within and outside a VNFPool;
			o Coordination of scale-out and scale-in of VNFs within a VNFPool;
			o Coordination of the use, visibility and addressability of
			additional VNF resources. New VNFs, which carry a new system-wide
			identifier, need to be announced to the system. New VNFs, which
			carry only a new VNFPool-internal identifier and provide additional
			VNF resources for an existing instance of a network function
			(system is aware of the network function instance's
			identifier) require only VNFPool-internal coordination.
			Selects Selects and
			Selects and VNF and addresses
			addresses VNF maps address. VNFC.
			System -------------->|PoolManager|------------>|VNF|--->|VNFC|
			|<----------VNFPool---------->|
			Figure: Scope of VNFPool and coordination between VNFPool-internal
			and system-wide selection, balancing and addressing of
			network functions
	3.2.3 Failure Handling		3.2.3 Failure Handling
	During vEPC deployment, various failures can occur, for instance		During vEPC deployment, various failures can occur, for instance
	virtual machine failure, hypervisor failure, a broken host server,		virtual machine failure, hypervisor failure, a broken host server,
	failure in a datacenter's transport network infrastructure, as well		failure in a datacenter's transport network infrastructure, as well
	as failure of network links which connect a datacenter to the global		as failure of network links which connect a datacenter to the global
	network infrastructure.		network infrastructure.
	It is unlikely that a single solution suits the handling of all kind		It is unlikely that a single solution suits the handling of all kind
	of failures. Typically for today's products, function redundancy and		of failures. Typically for today's products, function redundancy and
	skipping to change at page 9, line 33 ¶		skipping to change at page 10, line 41 ¶
	be possible for an operator to meet agreed service levels in all		be possible for an operator to meet agreed service levels in all
	cases.		cases.
	Due to the variety of different failure reasons, detection of the		Due to the variety of different failure reasons, detection of the
	failure type may be required to initiate the appropriate procedure		failure type may be required to initiate the appropriate procedure
	for failover handling. Mobile operators have strong requirements to		for failover handling. Mobile operators have strong requirements to
	minimize the time of system outage as experiences by subscribers,		minimize the time of system outage as experiences by subscribers,
	hence require minimal detection and failover handling latencies.		hence require minimal detection and failover handling latencies.
	Referring to the architecture of a virtualized Network Function as		Referring to the architecture of a virtualized Network Function as
	depicted in Figure 2, some virtualized Network Function Components		depicted in Figure 2, some VNFCs may require synchronization of
	may require synchronization of states with a standby vNFC of the		states with a standby VNFC instance of the same kind to introduce
	same kind to introduce redundancy on vNFC level. Others may not		redundancy on VNFC level. Others may not require state
	require state synchronization but simply a backup vNFC with the same		synchronization but rely simply a backup VNFC with the same
	functionality, as in case of failure, states can be recovered and		functionality, as in case of failure, states can be recovered and
	retrieved from a different vNFC, which holds the same or a sub-set of		retrieved from a different VNF, which holds the same or a sub-set of
	these states. Hence, redundancy management and failover mechanisms		these states. Hence, redundancy management and failover mechanisms
	can be vNFC- specific.		can be VNFC-specific.
	Disaster events, such as an earthquake, can have impact to the		Disaster events, such as an earthquake, can have impact to the
	availability of a larger vNF set or even to the access to a complete		availability of a larger VNF Set (a group of VNFs providing different
	data center in case the data center's links to the global network		functions) or even to the access to a complete data center in case
	infrastructure breaks. In such case, even the availability of a		the data center's links to the global network infrastructure
	backup system in a globally and topologically distant data center can		breaks. In such case, even the availability of a backup system in
	meet the requirement of service continuation. Seamless		a globally and topologically distant data center can meet the
	continuation of subscribers' services is unlikely, as it would		requirement of service continuation. Seamless continuation of
	require maintenance of state synchronization between functions		subscribers' services is unlikely, as it would require maintenance
	being instantiated in different data centers. But solely the		of state synchronization between functions being instantiated in
	provisioning of backup vNFs allows subscribers to re-attach to the		different data centers. But solely the provisioning of backup vNFs
	mobile communication system and place new calls. Handling such		allows subscribers to re-attach to the mobile communication system
	failover requires macroscopic indirection of the EPC reference		and place new calls. Handling such failover requires macroscopic
	points to a set of backup vNFs in a different data center.		indirection of the EPC reference points to a set of backup VNFs in
			a different data center.
	Some key requirements for failure detection and failover handling in		Some general requirements for failure detection and failover handling
	the view of virtualized EPC network functions:		in the view of virtualized EPC network functions:
	o Support function-specific redundancy and failover management;		o Support function-specific redundancy and failover management;
	o Support different kinds of redundancy for failover (state		o Support different kinds of redundancy for failover (state
	synchronization between vNFCs, state recovery at backup vNFC, state		synchronization between VNF instances, state recovery at backup VNF
	re-establishment at backup vNFC) ;		instances, state re-establishment at a backup VNF instance);
	o Selection of appropriate commodity hardware for backup and failover		o Selection of appropriate commodity hardware for backup and failover
	(resources availability);		(resources availability);
	o Minimize state synchronization- and failover latency;		o Minimize state synchronization- and failover latency;
	o Detection of failure;		o Detection of failure;
	o Detection of failure type and level (e.g. vNFC, hypervisor,		o Detection of failure type and level (e.g. VNF, hypervisor,
	hardware, network);		hardware, network);
	o Enforcement of failover strategy according to failure type;		o Enforcement of failover strategy according to failure type;
	o Automated detection and failure handling.		o Automated detection and failure handling.
	3.3 Reliable vEPC Service Function Chains (SFC)		Service requirements for failure handling from VNFPool perspective,
			based on the current working group scope of work:
	To be discussed.		o Selection of suitable resources (host server, rack, topological
			location) for redundant VNFs;
	[draft-liu-sfc-use-cases-00]		o Instantiation and installation of redundant resources on VNF-level;
	[draft-haeffner-sfc-use-case-mobility-00]		o Policing and enforcement of different redundancy schemes (e.g.
			active/standby synchronization, backup VNF);
	3.4 What does that mean for Virtual Network Function Pool (VNFPool)?		o Inter-working between VNF-internal (active/standby VNFC) and
			external (VNF redundancy) redundancy management;
	For VNFPool in the view of EPC, it is to be investigated where an		o Failover between VNFs within a VNFPool;
			o Handling of VNFPool-internal addressing and identification in case
			of failover;
			Addresses
			VNF
			System ------>|Pool Manager|--+-->VNF-----+->VNFC
			| failover|
			failover,| +->VNFC
			address |
			handling +-->VNF
			|<------VNFPool ----->|
			Figure: Scope of VNFPool and coordination between VNFPool-internal
			when handling failures.
			3.2.4 State Synchronization
			vEPC components may be split into control (signaling) and forwarding
			(data) plane traffic. A failure of a control plane traffic may result
			in the loss of communication between EPC functions. This should not
			impact user forwarding traffic, and it may be necessary for control
			functions to have state maintained and synchronized with back-up
			VNF instances hosting control elements.
			Also it may be necessary for data plane state to also be
			synchronized so certain connections continue to be operational
			and capable of forwarding traffic during from one VNF to
			another.
			3.3 What does that mean for Virtual Network Function Pool (VNF Pool)?
			For VNF Pool in the view of EPC, it is to be investigated where an
	IETF-based generalized functional architecture and common protocol		IETF-based generalized functional architecture and common protocol
	can support vEPC scaling, failure detection and handling. Such		can support vEPC scaling, failure detection and handling. Such
	common protocol components should allow inter-working with vNFC-		common protocol components should allow inter-working with VNF-
	specific and possibly proprietary but highly efficient mechanisms		specific and possibly proprietary but highly efficient mechanisms
	for redundancy and fault management.		for redundancy and fault management.
	The granularity of a VNF Pool Element (PE)		The granularity of a VNF Pool Manager[zong-vnfpool-problem-
	[zong-vnfpool-problem-statement] may be a vNF or a vNFC. The first		statement] may be a VNF, VNF Pool or VNF Set. It is assumed that a
	case assumes that a Pool Manager handles PEs with the granularity of		Pool Manager handles VNFs with the granularity of EPC network
	EPC network functions (MME, PDN Gateway), hence may not be aware		functions (MME, PDN Gateway).
	of vNFCs. The second case implies that vNFCs, from which a vNF is
	built, distribute between multiple VNF Pools. IN such case, the
	role of the relevant VNF Pool Managers is to be investigated.
	A VNF Pool Manager's role for load balancing between PEs is to be		A VNF Pool Manager's role for load balancing between PEs is to be
	investigated, taking additional and independent load balancing		investigated, taking additional and independent load balancing
	instances for macroscopic (system-wide) load balancing within the EPS		instances for macroscopic (system-wide) load balancing within the EPS
	and for microscopic load balancing (between multiple vNFCs of a		and for microscopic load balancing (between multiple VNFs of a
	single logical vNF) into account.		single logical VNF instance) into account.
			3.3.1 VNF Pool Definitions
			There is a hierarchy of terms used to describe VNF Pool components
			and their relationship:
			o An instantiation of a VNF is known as a VNF instance;
			o A group of VNF instances is known as a VNF Set;
			o A managed VNF Set is known as a VNF Pool;
			o A VNF pool is managed using a VNF Pool Manager.
			These definitions will be moved into the terminology section if they
			are agreed by the working group.
	4. IANA Considerations		4. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	5. Security Considerations		5. Security Considerations
	[To be discussed.]		[To be discussed.]
	6. References		6. References
	skipping to change at page 11, line 37 ¶		skipping to change at page 13, line 47 ¶
	[NFV-ISG-UC]		[NFV-ISG-UC]
	"Network Function Virtualisation; Use Cases;", ISG NFV Use		"Network Function Virtualisation; Use Cases;", ISG NFV Use
	Case, June 2013.		Case, June 2013.
	[NFV-REL-REQ]		[NFV-REL-REQ]
	"Network Function Virtualisation Resiliency Requirements",		"Network Function Virtualisation Resiliency Requirements",
	ISG REL Requirements, June 2013.		ISG REL Requirements, June 2013.
	[zong-vnfpool-problem-statement]		[zong-vnfpool-problem-statement]
	Zong, N., "Problem Statement for Reliable Virtualized		Zong, N., "Problem Statement for Reliable Virtualized
	Network Function (VNF) Pool", January 2014.		Network Function (VNF) Pool", May 2014.
	Authors' Addresses		Authors' Addresses
	Peter Willis		Peter Willis
	British Telecom		British Telecom
	UK		UK
	Email: peter.j.willis@bt.com		Email: peter.j.willis@bt.com
	Daniel King		Daniel King
	Lancaster University		Lancaster University
	UK		UK
	Email: d.king@lancaster.ac.uk		Email: d.king@lancaster.ac.uk
	Jeong-dong Ryoo		Jeong-dong Ryoo
	ETRI		ETRI
	Email: ryoo@etri.re.kr		Email: ryoo@etri.re.kr
End of changes. 39 change blocks.
	92 lines changed or deleted		196 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/