< draft-khasnabish-cloud-reference-framework-07.txt		draft-khasnabish-cloud-reference-framework-08.txt >
	Internet Engineering Task Force B. Khasnabish		Internet Engineering Task Force B. Khasnabish
	Internet-Draft ZTE (TX) Inc.		Internet-Draft ZTE (TX) Inc.
	Intended status: Informational J. Chu		Intended status: Informational J. Chu
	Expires: April 10, 2015 S. Ma		Expires: October 11, 2015 S. Ma
	ZTE		ZTE
	N. So		N. So
	Vinci Systems		Vinci Systems
	P. Unbehagen		P. Unbehagen
	Avaya		Avaya
	M. Morrow		M. Morrow
	Cisco Sys. GmbH		Cisco Sys. GmbH
	M. Hasan		M. Hasan
	Cisco Systems		Cisco Systems
	Y. Demchenko		Y. Demchenko
	Univ. of Amsterdam		Univ. of Amsterdam
	Y. Meng		Y. Meng
	.		.
	October 7, 2014		April 9, 2015
	Cloud Reference Framework		Cloud Reference Framework
	draft-khasnabish-cloud-reference-framework-07.txt		draft-khasnabish-cloud-reference-framework-08.txt
	Abstract		Abstract
	This document presents a cloud reference framework that intends to		This document presents a cloud reference framework that intends to
	provide a basis for designing interoperable cloud services and their		provide a basis for designing interoperable cloud services and their
	integration into existing open Internet and enterprise IT		integration into existing open Internet and enterprise IT
	infrastructures.		infrastructures.
	In general, a cloud-based system utilizes virtualized computing /		In general, a cloud-based system utilizes virtualized computing /
	communications / storage resources and applications, and allows their		communications / storage resources and applications, and allows their
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	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 April 10, 2015.		This Internet-Draft will expire on October 11, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	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
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	3.3. User/Customer Side Functions and Resources . . . . . . . . 21		3.3. User/Customer Side Functions and Resources . . . . . . . . 21
	4. Inter-Cloud Framework . . . . . . . . . . . . . . . . . . . . 22		4. Inter-Cloud Framework . . . . . . . . . . . . . . . . . . . . 22
	4.1. Inter-Cloud Requirements . . . . . . . . . . . . . . . . . 23		4.1. Inter-Cloud Requirements . . . . . . . . . . . . . . . . . 23
	4.2. Intercloud Control and Management Plane (ICCMP) . . . . . 25		4.2. Intercloud Control and Management Plane (ICCMP) . . . . . 25
	4.3. Intercloud Federation Framework (ICFF) . . . . . . . . . . 27		4.3. Intercloud Federation Framework (ICFF) . . . . . . . . . . 27
	4.4. Intercloud Operation and Management Framework (ICOMF) . . 33		4.4. Intercloud Operation and Management Framework (ICOMF) . . 33
	5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 35		5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	5.1. Virtual Network Management . . . . . . . . . . . . . . . . 35		5.1. Virtual Network Management . . . . . . . . . . . . . . . . 35
	5.2. Telecom Network Virtualization . . . . . . . . . . . . . . 35		5.2. Telecom Network Virtualization . . . . . . . . . . . . . . 35
	5.3. Virtual Data Center . . . . . . . . . . . . . . . . . . . 37		5.3. Virtual Data Center . . . . . . . . . . . . . . . . . . . 37
	5.4. Security Framework for VDCS . . . . . . . . . . . . . . . 38		5.4. GEANT Open Cloud eXchange (gOCX) . . . . . . . . . . . . . 38
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 40		5.4.1. gOCX Concept . . . . . . . . . . . . . . . . . . . . . 38
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 41		5.4.2. gOCX Architecture . . . . . . . . . . . . . . . . . . 39
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 42		5.5. Security Framework for VDCS . . . . . . . . . . . . . . . 40
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	10. Normative references . . . . . . . . . . . . . . . . . . . . . 44		7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
			10. Normative references . . . . . . . . . . . . . . . . . . . . . 45
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
	1. Introduction		1. Introduction
	Clouds are emerging as a common way of provisioning virtualized		Clouds are emerging as a common way of provisioning virtualized
	infrastructure services that are provisioned on demand (and		infrastructure services that are provisioned on demand (and
	configured for specific customer needs or tasks). Current		configured for specific customer needs or tasks). Current
	development of the cloud technologies demonstrate movement to		development of the cloud technologies demonstrate movement to
	developing Intercloud models, architectures and integration tools		developing Intercloud models, architectures and integration tools
	that could allow integrating cloud based infrastructure services into		that could allow integrating cloud based infrastructure services into
	existing enterprise and campus infrastructures, on one hand, and		existing enterprise and campus infrastructures, on one hand, and
	skipping to change at page 25, line 37 ¶		skipping to change at page 25, line 37 ¶
	4.2. Intercloud Control and Management Plane (ICCMP)		4.2. Intercloud Control and Management Plane (ICCMP)
	The ICCMP defines functionality and functional components for		The ICCMP defines functionality and functional components for
	Intercloud applications/infrastructure control and management,		Intercloud applications/infrastructure control and management,
	including inter-applications signaling, synchronization and session		including inter-applications signaling, synchronization and session
	management, configuration, monitoring, runtime infrastructure		management, configuration, monitoring, runtime infrastructure
	optimization. ICCMP should support also more complex operations such		optimization. ICCMP should support also more complex operations such
	as VM migration, resources scaling, and jobs/objects/data routing		as VM migration, resources scaling, and jobs/objects/data routing
	The ICCMP definition/development attempts to leverage the general		The ICCMP definition/development attempts to leverage the general
	Internet technologies such as provided by CDN [CNDI, I-D], XMPP		Internet technologies such as provided by CDN [CDNI, I-D], XMPP
	[XMPP, RFC] and the Generalized Multi-Protocol Label Switching		[XMPP, RFC] and the Generalized Multi-Protocol Label Switching
	(GMPLS) [GMPLS, RFC].		(GMPLS) [GMPLS, RFC].
	Figure 4.2 illustrates an example where two different cloud/segments		Figure 4.2 illustrates an example where two different cloud/segments
	domains IaaS and PaaS need to interact (communicate) to allow		domains IaaS and PaaS need to interact (communicate) to allow
	applications from one domain to control underlying virtualized		applications from one domain to control underlying virtualized
	resources and infrastructure in another domain. Upper layer (north		resources and infrastructure in another domain. Upper layer (north
	band) interfaces facing customer applications are typically		band) interfaces facing customer applications are typically
	standardised and can use e.g. Open Cloud Computing Interface (OCCI)		standardised and can use e.g. Open Cloud Computing Interface (OCCI)
	[OCCI] as a standard interface or Amazon Web Services (AWS) as an		[OCCI] as a standard interface or Amazon Web Services (AWS) as an
	skipping to change at page 31, line 33 ¶		skipping to change at page 31, line 33 ¶
	Each Federated Cloud infrastructure instance typically contains Cloud		Each Federated Cloud infrastructure instance typically contains Cloud
	Service Broker and trust Broker or manager that support		Service Broker and trust Broker or manager that support
	correspondingly dynamic services federation and dynamic trust		correspondingly dynamic services federation and dynamic trust
	establishment. Each Cloud Provider domain also includes Identity		establishment. Each Cloud Provider domain also includes Identity
	Provider IDP and Authentication, Authorisation, Accounting (AAA)		Provider IDP and Authentication, Authorisation, Accounting (AAA)
	services, both of them supporting federated identity and federation		services, both of them supporting federated identity and federation
	policy.		policy.
	Recent research and developments in Intercloud architecture have		Recent research and developments in Intercloud architecture have
	defined a new component of the federated Intercloud network		defined a new component of the federated Intercloud network
	infrastructure the Open Cloud eXchange (OCX) [OCX, 2013]. The OCX		infrastructure the Open Cloud eXchange (OCX) [OCX, 2015]. The OCX
	has been proposed to bridge the gap between the two major components		has been proposed to bridge the gap between the two major components
	of the general cloud services provisioning and delivery		of the general cloud services provisioning and delivery
	infrastructure: (1) the Cloud Service Provider (CSP) infrastructure		infrastructure: (1) the Cloud Service Provider (CSP) infrastructure
	which either has a global footprint, or is intended to serve global		which either has a global footprint, or is intended to serve global
	customer community, including those customers who target to deliver		customer community, including those customers who target to deliver
	services to the global/worldwide community; and (2) cloud services		services to the global/worldwide community; and (2) cloud services
	delivery infrastructure which in many cases requires dedicated local		delivery infrastructure which in many cases requires dedicated local
	infrastructure and quality of services that cannot be delivered by		infrastructure and quality of services that cannot be delivered by
	the public Internet infrastructure. The OCX will remain neutral to		the public Internet infrastructure. The OCX will remain neutral to
	actual cloud services provisioning and limit its services to Layer 0		actual cloud services provisioning and limit its services to Layer 0
	skipping to change at page 38, line 20 ¶		skipping to change at page 38, line 20 ¶
	o Core SW (switch) - high capacity core node aggregating multiple		o Core SW (switch) - high capacity core node aggregating multiple
	ToRs. This is usually a cost effective Ethernet switch. Core		ToRs. This is usually a cost effective Ethernet switch. Core
	switches can also support routing capabilities.		switches can also support routing capabilities.
	o DC GW - gateway to the outside world providing DC Interconnect and		o DC GW - gateway to the outside world providing DC Interconnect and
	connectivity to Internet and VPN customers. In the current DC		connectivity to Internet and VPN customers. In the current DC
	network model, this may be a Router with Virtual Routing		network model, this may be a Router with Virtual Routing
	capabilities and/or an IPVPN/L2VPN PE.		capabilities and/or an IPVPN/L2VPN PE.
	5.4. Security Framework for VDCS		5.4. GEANT Open Cloud eXchange (gOCX)
			The Open Cloud eXchange (OCX) has been proposed by the GEANT project
			as a new conceptual and functional component of the general inter-
			cloud service delivery infrastructure with the intent to bridge the
			gap between the cloud provider's infrastructure and National Research
			Network Infrastructure (NREN) and/or campus infrastructure, in
			particular, to solve the "last-mile" problem in delivering cloud
			services to customer locations and individuals or end-users [OCX1,
			2013], [OCX2, 2015].
			5.4.1. gOCX Concept
			The proposed OCX concept is based on and extends the Internet
			eXchange Points (IXP) and GLIF Optical Lightpath Exchange (GOLE)
			service models with additional functionalities to allow ad hoc
			dynamic Intercloud federation establishment and non- restricted
			peering between cloud providers, customers, and also local
			infrastructure providers, in case cloud services delivery requires
			involvement of such entities.
			Additionally to providing physical location for (network)
			interconnecting of all involved actors, the OCX declares two basic
			principles that simplify and facilitate services delivery:
			o No value-added third party services (i.e. service composition,
			integration or operation). In this way, OCX will not be involved
			in the business dealings related to the actual cloud services
			provisioning and delivery;
			o Trusted Third Party (TTP) services for ad-hoc/dynamic federations
			establishment: OCX may provide the directory service, trusted
			repository of provider certificates operating under supervision of
			the community (representatives), which can act as a policy
			authority for security and operational practices.
			The proposed OCX role as a TTP will facilitate creation of dynamic
			federations and establishment of dynamic trust relation between CSPs
			and customers.
			Referring to the generic Cloud Services Model defined in section 3 of
			current document, the OCX functionality can be related to the Access
			and Service Delivery Layer (ASDL) layer where the main goal is to
			deliver cloud based services to organizational customers and end
			users. Structurally ASDL includes all infrastructure components
			between the CSP, the final consumer and other entities involved into
			cloud services delivery and operation. However, to allow easy
			integration into existing cloud infrastructures and remain
			transparent to current service models, the OCX limits its services to
			Layer 0 through Layer 2 transport (or bearer) networks. OCX can be
			similarly defined as a place for inter-connection and peering between
			CSPs and customers. Thus, it may also benefit from being collocated
			with the service provider, NREN exchange points or regional data
			centers servicing the regional/national research community.
			5.4.2. gOCX Architecture
			Architecturally and functionally, the OCX includes the following
			services and functional components (see Figure 4.4):
			o Physical Point of Presence (PoP) or OCX Access Points (OCXP) for
			providers and customers
			o L0-L2 network interconnection facility (optionally also
			connectivity with dedicated optical links). The associated
			service should allow customer related topology information
			exchange (such as related to virtual private clouds) between
			providers and customers in a secure and consistent way (this is of
			extreme importance since topology information in most cases is
			considered as commercial or restricted information)
			o Trusted Third Party (TTP) services for support of dynamic peering,
			business/service and trust relations establishment between OCX
			members; the specific services may include:
			* Trusted Certificates repository and associated Trusted
			Introducer service to allow dynamic trust associations and/or
			federations establishment
			* Additionally Trust Broker service can be provided and supported
			by either or both Trusted Introducer and privacy/data security
			policy Registry or clearinghouse.
			5.5. Security Framework for VDCS
	Virtualized Data Center Services (VDCS) Security Framework is a		Virtualized Data Center Services (VDCS) Security Framework is a
	reference framework to build secure and interoperable services on top		reference framework to build secure and interoperable services on top
	of a virtualized infrastructure. A security framework and the		of a virtualized infrastructure. A security framework and the
	associated requirements for Protocols, Profiles, Network Interfaces,		associated requirements for Protocols, Profiles, Network Interfaces,
	Operations and Management, and Application Interfaces(APIs) need to		Operations and Management, and Application Interfaces(APIs) need to
	be proposed in an environment where virtualized resources are shared		be proposed in an environment where virtualized resources are shared
	among a variety of public and private subscribers/clients seamlessly.		among a variety of public and private subscribers/clients seamlessly.
	The various applications and interworking protocols developed by the		The various applications and interworking protocols developed by the
	skipping to change at page 45, line 33 ¶		skipping to change at page 46, line 33 ¶
	NIST, "NIST SP 500-292, Cloud Computing Reference		NIST, "NIST SP 500-292, Cloud Computing Reference
	Architecture, v1.0", October 2011.		Architecture, v1.0", October 2011.
	[NIST Cloud]		[NIST Cloud]
	NIST, "NIST SP 800-145, A NIST definition of cloud		NIST, "NIST SP 800-145, A NIST definition of cloud
	computing", October 2011.		computing", October 2011.
	[OASIS IDCloud]		[OASIS IDCloud]
	OASIS IDCloud TC, "OASIS Identity in the Cloud", May 2012.		OASIS IDCloud TC, "OASIS Identity in the Cloud", May 2012.
	[OCX, 2013]		[OCX1, 2013]
	Demchenko, Y., "Open Cloud eXchange (OCX): Architecture		Demchenko, Y., "Open Cloud eXchange (OCX): Architecture
	and Functional Components. Proc. "The 3rd workshop on		and Functional Components. Proc. "The 3rd workshop on
	Network Infrastructure Services as part of Cloud Computing		Network Infrastructure Services as part of Cloud Computing
	(NetCloud 2013)", in conjunction with The 5th IEEE		(NetCloud 2013)", in conjunction with The 5th IEEE
	International Conference and Workshops on Cloud Computing		International Conference and Workshops on Cloud Computing
	Technology and Science (CloudCom2013), 2-5 December 2013,		Technology and Science (CloudCom2013), 2-5 December 2013,
	Bristol, UK.", December 2013.		Bristol, UK.", December 2013.", December 2013.
			[OCX2, 2015]
			Demchenko, Y., "Open Cloud eXchange (OCX): A Pivot for
			Intercloud Services Federation in Multi-provider Cloud
			Market Environment. Proc. IEEE 4th International Workshop
			on Cloud Computing Interclouds, Multiclouds, Federations,
			and Interoperability (Intercloud 2015), at IEEE
			International Conference on Cloud Engineering (IC2E),
			March 12, 2015, Tempe, USA.", March 2015.
	[RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement		[RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	[RFC4741] IETF, "NETCONF Configuration Protocol", December 2006.		[RFC4741] IETF, "NETCONF Configuration Protocol", December 2006.
	[TMF] TMF, "TM Forum Frameworx", March 2012.		[TMF] TMF, "TM Forum Frameworx", March 2012.
	[TMF SLAM]		[TMF SLAM]
	TMF, "TMF SLA Management", November 2011.		TMF, "TMF SLA Management", November 2011.
End of changes. 11 change blocks.
	17 lines changed or deleted		112 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/