< draft-irtf-nfvrg-gaps-network-virtualization-08.txt		draft-irtf-nfvrg-gaps-network-virtualization-09.txt >
	NFVRG CJ. Bernardos		NFVRG CJ. Bernardos
	Internet-Draft UC3M		Internet-Draft UC3M
	Intended status: Informational A. Rahman		Intended status: Informational A. Rahman
	Expires: June 2, 2018 InterDigital		Expires: September 1, 2018 InterDigital
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	LM. Contreras		LM. Contreras
	TID		TID
	P. Aranda		P. Aranda
	UC3M		UC3M
	P. Lynch		P. Lynch
	Ixia		Ixia
	November 29, 2017		February 28, 2018
	Network Virtualization Research Challenges		Network Virtualization Research Challenges
	draft-irtf-nfvrg-gaps-network-virtualization-08		draft-irtf-nfvrg-gaps-network-virtualization-09
	Abstract		Abstract
	This document describes open research challenges for network		This document describes open research challenges for network
	virtualization. Network virtualization is following a similar path		virtualization. Network virtualization is following a similar path
	as previously taken by cloud computing. Specifically, cloud		as previously taken by cloud computing. Specifically, cloud
	computing popularized migration of computing functions (e.g.,		computing popularized migration of computing functions (e.g.,
	applications) and storage from local, dedicated, physical resources		applications) and storage from local, dedicated, physical resources
	to remote virtual functions accessible through the Internet. In a		to remote virtual functions accessible through the Internet. In a
	similar manner, network virtualization is encouraging migration of		similar manner, network virtualization is encouraging migration of
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	virtualized pool of resources. However, network virtualization can		virtualized pool of resources. However, network virtualization can
	be considered to be a more complex problem than cloud computing as it		be considered to be a more complex problem than cloud computing as it
	not only involves virtualization of computing and storage functions		not only involves virtualization of computing and storage functions
	but also involves abstraction of the network itself. This document		but also involves abstraction of the network itself. This document
	describes current research and engineering challenges in network		describes current research and engineering challenges in network
	virtualization including guaranteeing quality-of-service, performance		virtualization including guaranteeing quality-of-service, performance
	improvement, supporting multiple domains, network slicing, service		improvement, supporting multiple domains, network slicing, service
	composition, device virtualization, privacy and security, separation		composition, device virtualization, privacy and security, separation
	of control concerns, network function placement and testing. In		of control concerns, network function placement and testing. In
	addition, some proposals are made for new activities in IETF/IRTF		addition, some proposals are made for new activities in IETF/IRTF
	that could address some of these challenges.		that could address some of these challenges. This document is a
			product of the Network Function Virtualization Research Group
			(NFVRG).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://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 June 2, 2018.		This Internet-Draft will expire on September 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 and scope . . . . . . . . . . . . . . . . . . . 3		1. Introduction and scope . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	dimensioning, and dynamic energy policies to reduce the electricity		dimensioning, and dynamic energy policies to reduce the electricity
	consumption.		consumption.
	This document presents research and engineering challenges in network		This document presents research and engineering challenges in network
	virtualization that need to be addressed in order to achieve these		virtualization that need to be addressed in order to achieve these
	goals, spanning from pure research and engineering/standards space.		goals, spanning from pure research and engineering/standards space.
	The objective of this memo is to document the technical challenges		The objective of this memo is to document the technical challenges
	and corresponding current approaches and to expose requirements that		and corresponding current approaches and to expose requirements that
	should be addressed by future research and standards work.		should be addressed by future research and standards work.
			This document represents the consensus of the NFV Research Group. It
			has been reviewed by the Research Group members active in the
			specific areas of work covered by the document.
	2. Terminology		2. Terminology
	The following terms used in this document are defined by the ETSI		The following terms used in this document are defined by the ETSI
	Network Function Virtualization (NVF) Industrial Study Group (ISG)		Network Function Virtualization (NVF) Industrial Study Group (ISG)
	[etsi_gs_nfv_003], the ONF [onf_tr_521] and the IETF [RFC7426]		[etsi_gs_nfv_003], the ONF [onf_tr_521] and the IETF [RFC7426]
	[RFC7665]:		[RFC7665]:
	Application Plane - The collection of applications and services		Application Plane - The collection of applications and services
	that program network behavior.		that program network behavior.
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 45 ¶
	disrupting one, some autonomous IoT devices will have very low		disrupting one, some autonomous IoT devices will have very low
	throughput, will have much longer sleep cycles (and therefore high		throughput, will have much longer sleep cycles (and therefore high
	latency), and a battery life time exceeding by a factor of thousands		latency), and a battery life time exceeding by a factor of thousands
	that of smart phones or some other devices that will have almost		that of smart phones or some other devices that will have almost
	continuous control and data communications. Hence, it is envisioned		continuous control and data communications. Hence, it is envisioned
	that a customized network slice will have to be stitched together		that a customized network slice will have to be stitched together
	from virtual resources or sub-slices to meet these requirements.		from virtual resources or sub-slices to meet these requirements.
	The actual definition of network slice from an IP infrastructure		The actual definition of network slice from an IP infrastructure
	viewpoint is currently undergoing intense debate		viewpoint is currently undergoing intense debate
	[I-D.galis-netslices-revised-problem-statement]		[I-D.geng-coms-problem-statement] [I-D.gdmb-netslices-intro-and-ps]
	[I-D.gdmb-netslices-intro-and-ps]
	[I-D.defoy-netslices-3gpp-network-slicing] [ngmn_5G_whitepaper].		[I-D.defoy-netslices-3gpp-network-slicing] [ngmn_5G_whitepaper].
	Network slicing is a key for introducing new actors in existing		Network slicing is a key for introducing new actors in existing
	market at low cost -- by letting new players rent "blocks" of		market at low cost -- by letting new players rent "blocks" of
	capacity, if the new business model enables performance that meets		capacity, if the new business model enables performance that meets
	the application needs (e.g., broadcasting updates to many sensors		the application needs (e.g., broadcasting updates to many sensors
	with satellite broadcasting capabilities). However, more work needs		with satellite broadcasting capabilities). However, more work needs
	to be done to define the basic architectural approach of how network		to be done to define the basic architectural approach of how network
	slices will be defined and formed. For example, is it mostly a		slices will be defined and formed. For example, is it mostly a
	matter of defining the appropriate network models (e.g. YANG) to		matter of defining the appropriate network models (e.g. YANG) to
	stitch the network slice from existing components. Or do end-to-end		stitch the network slice from existing components. Or do end-to-end
	skipping to change at page 26, line 15 ¶		skipping to change at page 26, line 15 ¶
	clone in the networking infrastructure). This is, for example, being		clone in the networking infrastructure). This is, for example, being
	explored by the European H2020 ICIRRUS project (www.icirrus-		explored by the European H2020 ICIRRUS project (www.icirrus-
	5gnet.eu).		5gnet.eu).
	4.8. Security and Privacy		4.8. Security and Privacy
	Similar to any other situation where resources are shared, security		Similar to any other situation where resources are shared, security
	and privacy are two important aspects that need to be taken into		and privacy are two important aspects that need to be taken into
	account.		account.
	In the case of security, there are situations where multiple vendors		In the case of security, there are situations where multiple service
	will need to coexist in a virtual or hybrid physical/virtual		providers will need to coexist in a virtual or hybrid physical/
	environment. This requires attestation procedures amongst different		virtual environment. This requires attestation procedures amongst
	virtual/physical functions and resources, as well as ongoing external		different virtual/physical functions and resources, as well as
	monitoring. Similarly, different network slices operating on the		ongoing external monitoring. Similarly, different network slices
	same infrastructure can present security problems, for instance if		operating on the same infrastructure can present security problems,
	one slice running critical applications (e.g. support for a safety		for instance if one slice running critical applications (e.g. support
	system) is affected by another slice running a less critical		for a safety system) is affected by another slice running a less
	application. In general, the minimum common denominator for security		critical application. In general, the minimum common denominator for
	measures on a shared system should be equal or higher than the one		security measures on a shared system should be equal or higher than
	required by the most critical application. Multiple and continuous		the one required by the most critical application. Multiple and
	threat model analysis, as well as DevOps model are required to		continuous threat model analysis, as well as DevOps model are
	maintain a certain level of security in an NFV system.		required to maintain a certain level of security in an NFV system.
	Simplistically, DevOps is a process that combines multiple functions		Simplistically, DevOps is a process that combines multiple functions
	into single cohesive teams in order to quickly produce quality		into single cohesive teams in order to quickly produce quality
	software. It typically relies on also applying the Agile development		software. It typically relies on also applying the Agile development
	process, which focuses on (among many things) dividing large features		process, which focuses on (among many things) dividing large features
	into multiple, smaller deliveries. One part of this is to		into multiple, smaller deliveries. One part of this is to
	immediately test the new smaller features in order to get immediate		immediately test the new smaller features in order to get immediate
	feedback on errors so that if present, they can be immediately fixed		feedback on errors so that if present, they can be immediately fixed
	and redeployed.		and redeployed.
	On the other hand, privacy in its strictest interpretation refers to		On the other hand, privacy refers to concerns about the control of
	concerns about exposing users of the system to individual threats		personal data and the decision of what to reveal to whom. In this
	such as surveillance, identification, stored data compromise,		case, the storage, transmission, collection, and potential
	secondary use, intrusion, etc. In this case, the storage,		correlation of information in the NFV system, for purposes not
	transmission, collection, and potential correlation of information in		originally intended or not known by the user, should be avoided.
	the NFV system, for purposes not originally intended or not known by		This is particularly challenging, as future intentions and threats
	the user, should be avoided. This is particularly challenging, as		cannot be easily predicted, and still can be applied on data
	future intentions and threats cannot be easily predicted, and still		collected in the past. Therefore, well-known techniques such as data
	can be applied on data collected in the past. Therefore, well-known		minimization, using privacy features as default, and allowing users
	techniques such as data minimization, using privacy features as		to opt in/out should be used to prevent potential privacy issues.
	default, and allowing users to opt in/out should be used to prevent
	potential privacy issues.
	Compared to traditional networks, NFV will result in networks that		Compared to traditional networks, NFV will result in networks that
	are much more dynamic (in function distribution and topology) and		are much more dynamic (in function distribution and topology) and
	elastic (in size and boundaries). NFV will thus require network		elastic (in size and boundaries). NFV will thus require network
	operators to evolve their operational and administrative security		operators to evolve their operational and administrative security
	solutions to work in this new environment. For example, in NFV the		solutions to work in this new environment. For example, in NFV the
	network orchestrator will become a key node to provide security		network orchestrator will become a key node to provide security
	policy orchestration across the different physical and virtual		policy orchestration across the different physical and virtual
	components of the virtualized network. For highly confidential data,		components of the virtualized network. For highly confidential data,
	for example, the network orchestrator should take into account if		for example, the network orchestrator should take into account if
	skipping to change at page 27, line 29 ¶		skipping to change at page 27, line 27 ¶
	be run by a different operator and/or cloud service provider (see		be run by a different operator and/or cloud service provider (see
	also Section 4.4). Thus, there will be multiple administrative		also Section 4.4). Thus, there will be multiple administrative
	domains involved, making security policy coordination more complex.		domains involved, making security policy coordination more complex.
	For example, who will be in charge of provisioning and maintaining		For example, who will be in charge of provisioning and maintaining
	security credentials such as public and private keys? Also, should		security credentials such as public and private keys? Also, should
	private keys be allowed to be replicated across the NFV for		private keys be allowed to be replicated across the NFV for
	redundancy reasons? Alternatively, it can be investigated how to		redundancy reasons? Alternatively, it can be investigated how to
	develop a mechanism that avoid such a security policy coordination,		develop a mechanism that avoid such a security policy coordination,
	this making the system more robust.		this making the system more robust.
	On a positive note, NFV will may better defense against Denial of		On a positive note, NFV may better defense against Denial of Service
	Service (DoS) attacks because of the distributed nature of the		(DoS) attacks because of the distributed nature of the network (i.e.
	network (i.e. no single point of failure) and the ability to steer		no single point of failure) and the ability to steer (undesirable)
	(undesirable) traffic quickly [etsi_gs_nfv_sec_001]. Also, NFVs		traffic quickly [etsi_gs_nfv_sec_001]. Also, NFVs which have
	which have physical HW which is distributed across multiple data		physical HW which is distributed across multiple data centers will
	centers will also provide better fault isolation environments. This		also provide better fault isolation environments. This holds true in
	holds true in particular if each data center is protected separately		particular if each data center is protected separately via firewalls,
	via firewalls, DMZs and other network protection techniques.		DMZs and other network protection techniques.
	SDN can also be used to help improve security by facilitating the		SDN can also be used to help improve security by facilitating the
	operation of existing protocols, such as Authentication,		operation of existing protocols, such as Authentication,
	Authorization and Accounting (AAA). The management of AAA		Authorization and Accounting (AAA). The management of AAA
	infrastructures, namely the management of AAA routing and the		infrastructures, namely the management of AAA routing and the
	establishment of security associations between AAA entities, can be		establishment of security associations between AAA entities, can be
	performed using SDN, as analyzed in [I-D.marin-sdnrg-sdn-aaa-mng].		performed using SDN, as analyzed in [I-D.marin-sdnrg-sdn-aaa-mng].
	4.9. Separation of control concerns		4.9. Separation of control concerns
	skipping to change at page 34, line 34 ¶		skipping to change at page 34, line 34 ¶
	NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.		NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.
	[etsi_gs_nfv_eve005]		[etsi_gs_nfv_eve005]
	ETSI NFV ISG, "Network Functions Virtualisation (NFV);		ETSI NFV ISG, "Network Functions Virtualisation (NFV);
	Ecosystem; Report on SDN Usage in NFV Architectural		Ecosystem; Report on SDN Usage in NFV Architectural
	Framework", ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005,		Framework", ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005,
	December 2015, <http://www.etsi.org/deliver/etsi_gs/NFV-		December 2015, <http://www.etsi.org/deliver/etsi_gs/NFV-
	EVE/001_099/005/01.01.01_60/gs_NFV-EVE005v010101p.pdf>.		EVE/001_099/005/01.01.01_60/gs_NFV-EVE005v010101p.pdf>.
	[etsi_gs_nfv_per_001]		[etsi_gs_nfv_per_001]
	ETSI GS NFV-PER 001 V1.1.2, , "Network Functions		ETSI GS NFV-PER 001 V1.1.2, "Network Functions
	Virtualisation (NFV); NFV Performance & Portability Best		Virtualisation (NFV); NFV Performance & Portability Best
	Practises", ETSI GS NFV-PER 001 V1.1.2 NFV-PER 001,		Practises", ETSI GS NFV-PER 001 V1.1.2 NFV-PER 001,
	December 2014, <http://www.etsi.org/deliver/etsi_gs/NFV-		December 2014, <http://www.etsi.org/deliver/etsi_gs/NFV-
	PER/001_099/001/01.01.02_60/gs_NFV-PER001v010102p.pdf>.		PER/001_099/001/01.01.02_60/gs_NFV-PER001v010102p.pdf>.
	[etsi_gs_nfv_sec_001]		[etsi_gs_nfv_sec_001]
	ETSI GS NFV-SEC 001 V1.1.1, , "Network Functions		ETSI GS NFV-SEC 001 V1.1.1, "Network Functions
	Virtualisation (NFV); NFV Security; Problem Statement",		Virtualisation (NFV); NFV Security; Problem Statement",
	ETSI GS NFV-SEC 001 V1.1.1 NFV-SEC 001, October 2014,		ETSI GS NFV-SEC 001 V1.1.1 NFV-SEC 001, October 2014,
	<http://www.etsi.org/deliver/etsi_gs/NFV-		<http://www.etsi.org/deliver/etsi_gs/NFV-
	SEC/001_099/001/01.01.01_60/gs_NFV-SEC001v010101p.pdf>.		SEC/001_099/001/01.01.01_60/gs_NFV-SEC001v010101p.pdf>.
	[etsi_nvf_whitepaper_3]		[etsi_nvf_whitepaper_3]
	"Network Functions Virtualisation (NFV). White Paper 3",		"Network Functions Virtualisation (NFV). White Paper 3",
	October 2014.		October 2014.
	[google_sdn_wan]		[google_sdn_wan]
	Sushant Jain et al., , "B4: experience with a globally-		Sushant Jain et al., "B4: experience with a globally-
	deployed Software Defined WAN", Proceedings of the ACM		deployed Software Defined WAN", Proceedings of the ACM
	SIGCOMM 2013 , August 2013.		SIGCOMM 2013 , August 2013.
	[I-D.bagnulo-nfvrg-topology]		[I-D.bagnulo-nfvrg-topology]
	Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology:		Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology:
	Problem Statement", draft-bagnulo-nfvrg-topology-01 (work		Problem Statement", draft-bagnulo-nfvrg-topology-01 (work
	in progress), March 2016.		in progress), March 2016.
	[I-D.bernardos-nfvrg-multidomain]		[I-D.bernardos-nfvrg-multidomain]
	Bernardos, C., Contreras, L., Vaishnavi, I., and R. Szabo,		Bernardos, C., Contreras, L., Vaishnavi, I., and R. Szabo,
	"Multi-domain Network Virtualization", draft-bernardos-		"Multi-domain Network Virtualization", draft-bernardos-
	nfvrg-multidomain-03 (work in progress), September 2017.		nfvrg-multidomain-03 (work in progress), September 2017.
	[I-D.defoy-netslices-3gpp-network-slicing]		[I-D.defoy-netslices-3gpp-network-slicing]
	Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",		Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",
	draft-defoy-netslices-3gpp-network-slicing-02 (work in		draft-defoy-netslices-3gpp-network-slicing-02 (work in
	progress), October 2017.		progress), October 2017.
	[I-D.galis-netslices-revised-problem-statement]
	Galis, A., "Network Slicing - Revised Problem Statement",
	draft-galis-netslices-revised-problem-statement-01 (work
	in progress), July 2017.
	[I-D.gdmb-netslices-intro-and-ps]		[I-D.gdmb-netslices-intro-and-ps]
	Galis, A., Dong, J., kiran.makhijani@huawei.com, k.,		Galis, A., Dong, J., kiran.makhijani@huawei.com, k.,
	Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network		Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network
	Slicing - Introductory Document and Revised Problem		Slicing - Introductory Document and Revised Problem
	Statement", draft-gdmb-netslices-intro-and-ps-02 (work in		Statement", draft-gdmb-netslices-intro-and-ps-02 (work in
	progress), February 2017.		progress), February 2017.
			[I-D.geng-coms-problem-statement]
			67, 4., Wang, L., Slawomir, S., Qiang, L., Matsushima, S.,
			Galis, A., and L. Contreras, "Problem Statement of
			Supervised Heterogeneous Network Slicing", draft-geng-
			coms-problem-statement-01 (work in progress), October
			2017.
	[I-D.irtf-sdnrg-layered-sdn]		[I-D.irtf-sdnrg-layered-sdn]
	Contreras, L., Bernardos, C., Lopez, D., Boucadair, M.,		Contreras, L., Bernardos, C., Lopez, D., Boucadair, M.,
	and P. Iovanna, "Cooperating Layered Architecture for		and P. Iovanna, "Cooperating Layered Architecture for
	SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress),		SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress),
	October 2016.		October 2016.
	[I-D.marin-sdnrg-sdn-aaa-mng]		[I-D.marin-sdnrg-sdn-aaa-mng]
	Lopez, R. and G. Lopez-Millan, "Software-Defined		Lopez, R. and G. Lopez-Millan, "Software-Defined
	Networking (SDN)-based AAA Infrastructures Management",		Networking (SDN)-based AAA Infrastructures Management",
	draft-marin-sdnrg-sdn-aaa-mng-00 (work in progress),		draft-marin-sdnrg-sdn-aaa-mng-00 (work in progress),
	skipping to change at page 37, line 22 ¶		skipping to change at page 37, line 22 ¶
	[nfv_sota_research_challenges]		[nfv_sota_research_challenges]
	Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De		Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De
	Turck, F., and R. Boutaba, "Network Function		Turck, F., and R. Boutaba, "Network Function
	Virtualization: State-of-the-art and Research Challenges",		Virtualization: State-of-the-art and Research Challenges",
	IEEE Communications Surveys & Tutorials Volume: 18, Issue:		IEEE Communications Surveys & Tutorials Volume: 18, Issue:
	1, September 2015.		1, September 2015.
	[ngmn_5G_whitepaper]		[ngmn_5G_whitepaper]
	"NGMN 5G. White Paper", February 2015.		"NGMN 5G. White Paper", February 2015.
	[omniran] 802.1cf, Draft 0.4, , "802.1CF Network Reference Model and		[omniran] IEEE 802.1CF, "Recommended Practice for Network Reference
	Functional Description of IEEE 802 Access Network",		Model and Functional Description of IEEE 802 Access
	802.1cf, Draft 0.4 802.1cf, February 2017.		Network", Draft 1.0 , December 2017.
	[onf_tr_521]		[onf_tr_521]
	ONF, "SDN Architecture, Issue 1.1", ONF TR-521 TR-521,		ONF, "SDN Architecture, Issue 1.1", ONF TR-521 TR-521,
	February 2016,		February 2016,
	<https://www.opennetworking.org/images/stories/downloads/		<https://www.opennetworking.org/images/stories/downloads/
	sdn-resources/technical-reports/TR-		sdn-resources/technical-reports/
	521_SDN_Architecture_issue_1.1.pdf>.		TR-521_SDN_Architecture_issue_1.1.pdf>.
	[openmano_dataplane]		[openmano_dataplane]
	Lopez, D., "OpenMANO: The Dataplane Ready Open Source NFV		Lopez, D., "OpenMANO: The Dataplane Ready Open Source NFV
	MANO Stack", March 2015,		MANO Stack", March 2015,
	<https://www.ietf.org/proceedings/92/slides/slides-92-		<https://www.ietf.org/proceedings/92/slides/
	nfvrg-7.pdf>.		slides-92-nfvrg-7.pdf>.
	[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,		[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
	Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and		Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
	J. Halpern, "Forwarding and Control Element Separation		J. Halpern, "Forwarding and Control Element Separation
	(ForCES) Protocol Specification", RFC 5810,		(ForCES) Protocol Specification", RFC 5810,
	DOI 10.17487/RFC5810, March 2010, <https://www.rfc-		DOI 10.17487/RFC5810, March 2010,
	editor.org/info/rfc5810>.		<https://www.rfc-editor.org/info/rfc5810>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014, <https://www.rfc-		DOI 10.17487/RFC7252, June 2014,
	editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,		[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
	Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-		Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
	Defined Networking (SDN): Layers and Architecture		Defined Networking (SDN): Layers and Architecture
	Terminology", RFC 7426, DOI 10.17487/RFC7426, January		Terminology", RFC 7426, DOI 10.17487/RFC7426, January
	2015, <https://www.rfc-editor.org/info/rfc7426>.		2015, <https://www.rfc-editor.org/info/rfc7426>.
	[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for		[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
	Service Function Chaining", RFC 7498,		Service Function Chaining", RFC 7498,
	DOI 10.17487/RFC7498, April 2015, <https://www.rfc-		DOI 10.17487/RFC7498, April 2015,
	editor.org/info/rfc7498>.		<https://www.rfc-editor.org/info/rfc7498>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015, <https://www.rfc-		DOI 10.17487/RFC7665, October 2015,
	editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic		[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
	Event Delivery Using HTTP Push", RFC 8030,		Event Delivery Using HTTP Push", RFC 8030,
	DOI 10.17487/RFC8030, December 2016, <https://www.rfc-		DOI 10.17487/RFC8030, December 2016,
	editor.org/info/rfc8030>.		<https://www.rfc-editor.org/info/rfc8030>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8172] Morton, A., "Considerations for Benchmarking Virtual		[RFC8172] Morton, A., "Considerations for Benchmarking Virtual
	Network Functions and Their Infrastructure", RFC 8172,		Network Functions and Their Infrastructure", RFC 8172,
	DOI 10.17487/RFC8172, July 2017, <https://www.rfc-		DOI 10.17487/RFC8172, July 2017,
	editor.org/info/rfc8172>.		<https://www.rfc-editor.org/info/rfc8172>.
	[sfc_challenges]		[sfc_challenges]
	Medhat, A., Taleb, T., Elmangoush, A., Carella, G.,		Medhat, A., Taleb, T., Elmangoush, A., Carella, G.,
	Covaci, S., and T. Magedanz, "Service Function Chaining in		Covaci, S., and T. Magedanz, "Service Function Chaining in
	Next Generation Networks: State of the Art and Research		Next Generation Networks: State of the Art and Research
	Challenges", IEEE Communications Magazine vol. 55, no. 2,		Challenges", IEEE Communications Magazine vol. 55, no. 2,
	pp. 216-223, February 2017.		pp. 216-223, February 2017.
	[virtualization_mobile_device]		[virtualization_mobile_device]
	William D. Sproule, , "Virtualization of Mobile Device		William D. Sproule, "Virtualization of Mobile Device User
	User Experience", Patent US 9.542.062 B2 , January 2017.		Experience", Patent US 9.542.062 B2 , January 2017.
	[vnf-p] Moens, H. and Filip De Turck, "VNF-P: A model for		[vnf-p] Moens, H. and Filip De Turck, "VNF-P: A model for
	efficient placement of virtualized network functions",		efficient placement of virtualized network functions",
	10th International Conference on Network and Service		10th International Conference on Network and Service
	Management (CNSM) and Workshop pp. 418-423, 2014.		Management (CNSM) and Workshop pp. 418-423, 2014.
	[vnf_benchmarking]		[vnf_benchmarking]
	Rosa, R., Rothenberg, C., and R. Szabo, "A VNF Testing		Rosa, R., Rothenberg, C., and R. Szabo, "A VNF Testing
	Framework Design, Implementation and Partial Results",		Framework Design, Implementation and Partial Results",
	November 2016,		November 2016,
	<https://www.ietf.org/proceedings/97/slides/slides-97-		<https://www.ietf.org/proceedings/97/slides/
	nfvrg-06-vnf-benchmarking-00.pdf>.		slides-97-nfvrg-06-vnf-benchmarking-00.pdf>.
	Authors' Addresses		Authors' Addresses
	Carlos J. Bernardos		Carlos J. Bernardos
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad, 30		Av. Universidad, 30
	Leganes, Madrid 28911		Leganes, Madrid 28911
	Spain		Spain
	Phone: +34 91624 6236		Phone: +34 91624 6236
End of changes. 29 change blocks.
	74 lines changed or deleted		79 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/