< draft-conet-aeon-problem-statement-00.txt		draft-conet-aeon-problem-statement-01.txt >
	Internet Engineering Task Force P. Fan		Internet Engineering Task Force P. Fan
	Internet-Draft H. Deng		Internet-Draft H. Deng
	Intended status: Informational China Mobile		Intended status: Informational China Mobile
	Expires: November 22, 2014 M. Boucadair		Expires: January 4, 2015 M. Boucadair
	France Telecom		France Telecom
	T. Reddy		T. Reddy
	C. Eckel		C. Eckel
	Cisco Systems, Inc.		Cisco Systems, Inc.
	May 21, 2014		B. Williams
			Akamai, Inc.
			July 3, 2014
	Application Enabled Collaborative Networking: Problem Statement and		Application Enabled Collaborative Networking: Problem Statement
	Requirements		draft-conet-aeon-problem-statement-01
	draft-conet-aeon-problem-statement-00
	Abstract		Abstract
	Identification and treatment of application flows are important to		Identification and treatment of application flows are important to
	many application providers and network operators. They often rely on		many application providers and network operators. They often rely on
	these capabilities to deploy and/or support a wide range of		these capabilities to deploy and/or support a wide range of
	applications. These applications, and the packet flows they generate		applications. These applications generate flows that may have
	and consume, may have specific connectivity requirements that can be		specific connectivity requirements that can be met if made known to
	met if made known to the network. Historically, this functionality		the network. Historically, this functionality has been implemented
	has been implemented to the extent possible using heuristics, which		to the extent possible using heuristics, which inspect and infer flow
	inspect and infer flow characteristics. Heuristics may be based on		characteristics. Heuristics may be based on port ranges, network
	port ranges, network separation (e.g. subnets or VLANs, Deep Flow		separation (e.g. subnets or VLANs, Deep Flow Inspection (DFI), or
	Inspection (DFI), or Deep Packet Inspection (DPI). But many		Deep Packet Inspection (DPI). But many application flows in current
	application flows in current usages are dynamic, adaptive, time-		usages are dynamic, adaptive, time-bound, encrypted, peer-to-peer,
	bound, encrypted, peer-to-peer, asymmetric, used on multipurpose		asymmetric, used on multipurpose devices, and have different
	devices, and have different priorities depending on direction of		priorities depending on direction of flow, user preferences, and
	flow, user preferences, and other factors. Any combination of these		other factors. Any combination of these properties renders heuristic
	properties renders heuristic based techniques less effective and may		based techniques less effective and may result in compromises to
	result in compromises to application security or user privacy.		application security or user privacy.
	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 http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 22, 2014.
			This Internet-Draft will expire on January 4, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 33 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3		2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
	2.1. Types of Signaling . . . . . . . . . . . . . . . . . . . 3		2.1. Types of Signaling . . . . . . . . . . . . . . . . . . . 3
	3. Typical Workflows . . . . . . . . . . . . . . . . . . . . . . 4		3. Typical Workflows . . . . . . . . . . . . . . . . . . . . . . 4
	4. Limitations of Heuristic Based Solutions . . . . . . . . . . 4		4. Limitations of Heuristic Based Solutions . . . . . . . . . . 4
	5. Limitations of Existing Signaling Mechanisms . . . . . . . . 5		5. Limitations of Existing Signaling Mechanisms . . . . . . . . 5
	6. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 6		6. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 6
	7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Informative References . . . . . . . . . . . . . . . . . . . 8
	9. Informative References . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Networks today, whether public or private, are challenged with		Networks today, whether public or private, are challenged with
	demands to support rapidly increasing amounts of traffic. New		demands to support rapidly increasing amounts of traffic. New
	channels for creating and consuming rich media are deployed at a		channels for creating and consuming rich media are deployed at a
	rapid pace. Pervasive video and access on demand are becoming second		rapid pace. Pervasive video and access on demand are becoming second
	nature to consumers. Communication applications make extensive use		nature to consumers. Communication applications make extensive use
	of rich media, placing unprecedented quality of experience		of rich media, placing unprecedented quality of experience
	expectation on the underlying network. These trends present		expectation on the underlying network. These trends present
	challenges for network forecast and planning operations.		challenges for network forecast and planning operations.
	Now more so than ever before, identification and treatment of		Now more so than ever before, identification and treatment of
	application flows are critical for the successful deployment and		application flows are critical for the successful deployment and
	operation of a growing number of business and household applications.		operation of a growing number of business and household applications.
	These applications are based on wide range of signaling protocols and		These applications are based on a wide range of signaling protocols
	deployed by a diverse set of application providers that is not		and deployed by a diverse set of application providers that is not
	necessarily affiliated with the network providers across which the		necessarily affiliated with the network providers across which the
	applications are used.		applications are used.
	Historically, identification of application flows has been		Historically, identification of application flows has been
	accomplished using heuristics, which infer flow characteristics based		accomplished using heuristics, which infer flow characteristics based
	on port ranges, network separation, or inspection of the flow itself.		on port ranges, network separation, or inspection of the flow itself.
	Inspection techniques include DPI, which matches against		Inspection techniques include DPI, which matches against
	characteristic signatures (e.g. key string, binary sequence, etc.)		characteristic signatures (e.g. key string, binary sequence, etc.)
	and DFI, which analyzes statistical characteristics and connection		and DFI, which analyzes statistical characteristics and connection
	behavior of flows. Each of these techniques suffers from a set of		behavior of flows. Each of these techniques suffers from a set of
	limitations, particularly in the face of the challenges on the		limitations, particularly in the face of the network challenges
	network outlined previously.		outlined previously.
	Heuristic-based approaches may not be efficient and require		Heuristic-based approaches may not be efficient and require
	continuous updates of application signatures. Port based solutions		continuous updates of application signatures. Port based solutions
	suffer from port overloading and inconsistent port usage. Network		suffer from port overloading and inconsistent port usage. Network
	separation techniques like IP subnetting are error prone and increase		separation techniques like IP subnetting are error prone and increase
	network management complexity. DPI and DFI are computationally		network management complexity. DPI and DFI are computationally
	expensive, prone to error, and become more challenging with greater		expensive, prone to error, and become more challenging with greater
	adoption of encrypted signaling and secured media. An additional		adoption of encrypted signaling and secured media. An additional
	drawback of DPI and DFI is that any insights are not available, or		drawback of DPI and DFI is that any insights are not available, or
	need to be recomputed, at network nodes further down the application		need to be recomputed, at network nodes further down the application
	flow path.		flow path.
	As the IETF establishes default behaviors that thwart pervasive		As the IETF establishes default behaviors that thwart pervasive
	surveillance (e.g. [RFC7258]), it will be important to provide		surveillance (e.g. [RFC7258]), it will be important to offer
	mechanisms for applications that want to have the network provide		mechanisms that allow applications to request differential network
	differential flow treatment for their data. The intent is to have		treatment for their flows. The intent is to have applications
	applications protect the contents of their flows, yet have the		protect the contents of their flows, yet have the ability to opt-in
	ability to opt-in to information exchanges that provide a more		to information exchanges that provide a more precise allocation of
	precise allocation of network resources and thus a better user		network resources and thus a better user experience.
	experience.
	2. Definitions and Terminology		2. Definitions and Terminology
	2.1. Types of Signaling		2.1. Types of Signaling
	The following terms describe the relationship between signaling and		The following terms describe the relationship between signaling and
	the media to which it is associated.		the media to which it is associated.
	o off-path: signaling along a different network path than the media		o off-path: signaling along a different network path than the media
	flow		flow
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	1. Provide network operators with visibility of traffic usage and		1. Provide network operators with visibility of traffic usage and
	patterns for troubleshooting, capacity planning, and other off		patterns for troubleshooting, capacity planning, and other off
	network workflows. This is done by exporting observed traffic		network workflows. This is done by exporting observed traffic
	analysis via standard protocols such as IPFIX [RFC7011] and SNMP		analysis via standard protocols such as IPFIX [RFC7011] and SNMP
	[RFC3416]as well as by proprietary protocols and methods.		[RFC3416]as well as by proprietary protocols and methods.
	2. Provide network operators with visibility of application and data		2. Provide network operators with visibility of application and data
	usage for accounting and billing.		usage for accounting and billing.
	3. Provide differentiated network services for specific traffic		3. Provide differentiated network services for specific traffic
	according to network operator defined policies, including traffic		classes according to network operator defined policies.
	classification, policing and shaping (e.g. [RFC2475]), providing		Techniques to achieve this include traffic classification,
	admission control (e.g. [RFC6601]), impacting routing, and		policing and shaping (e.g. [RFC2475]), providing admission
	permitting passage of specific traffic (e.g. firewall functions).		control (e.g. [RFC6601]), impacting routing, and permitting
			passage of specific traffic (e.g. firewall functions).
	4. Limitations of Heuristic Based Solutions		4. Limitations of Heuristic Based Solutions
	These typical workflows, visibility and differentiated network		These workflows, visibility and differentiated network services, are
	services, are critical in many networks. However, their reliance on		critical in many networks. However, their reliance on inspection and
	inspection and observation limits the ability to enable these		observation limits their deployment. Reasons for this include the
	workflows more widely. Reasons for this include the following:		following:
	o Identification based on IP address lists is difficult to manage.		o Identification based on IP address lists is difficult to manage.
	The addresses may be numerous and may change, or they may be		The addresses may be numerous and may change, they may be dynamic,
	dynamic, private, or otherwise not meant to be exposed. With		private, or otherwise not meant to be exposed. With Content
	Content Delivery Network InterConnection (CDNI) [RFC6770], content		Delivery Network InterConnection (CDNI) [RFC6770], content could
	could be served either from an upstream CDN (uCDN) or any of a		be served either from an upstream CDN (uCDN) or any of a number of
	number of downstream CDNs (dCDN), and it will not be possible to		downstream CDNs (dCDN), and it will not be possible to manually
	manually track the IP addresses of all the CDN surrogates. Even		track the IP addresses of all the CDN surrogates. Even in cases
	in cases where identification by IP addresses is possible, more		where identification by IP addresses is possible, more granular
	granular identification of individual flows is not possible (e.g.		identification of individual flows is not possible (e.g. audio
	audio vs. video vs. data).		vs. video vs. data).
	o Classification based on TCP/UDP port numbers often result in		o Classification based on TCP/UDP port numbers often result in
	incorrect results due to port overloading (i.e. ports used by		incorrect behaviour due to port overloading (i.e. ports used by
	applications other than those claiming the port with IANA).		applications other than those claiming the port with IANA).
	o More and more traffic is encrypted, rendering DPI and DFI		o More and more traffic is encrypted, rendering DPI and DFI
	impossible, inefficient, or much more complex, and sometimes at		impossible, inefficient, or much more complex, and sometimes at
	the expense of privacy or security (e.g. need to share encryption		the expense of privacy or security (e.g. need to share encryption
	keys with intermediary proxy performing DPI/DFI).		keys with intermediary proxy performing DPI/DFI).
	o Visibility generally requires inspecting the signaling traffic of		o Visibility generally requires inspecting the signaling traffic of
	applications. This traffic may flow through a different network		applications. This traffic may flow through a different network
	path than the actual application data traffic. Impacting the		path than the actual application data traffic. Impacting the
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	o Extensions to signaling protocols and changes in the ways		o Extensions to signaling protocols and changes in the ways
	application use them can result in false negatives or false		application use them can result in false negatives or false
	positives during inspection.		positives during inspection.
	o Inspection techniques are completely non-standard, so the ability		o Inspection techniques are completely non-standard, so the ability
	and accuracy to identify traffic varies across vendors, and		and accuracy to identify traffic varies across vendors, and
	different implementation are likely to give different results for		different implementation are likely to give different results for
	the same traffic.		the same traffic.
	o Inspection techniques that require parsing the payload of packets		o Inspection techniques that require parsing the payload of packets
	(e.g. DPI) impact performance due to additional processing, and		(e.g. DPI) not only impact performance due to additional
	impact memory due to the growing number and size of signatures to		processing, but also impact memory due to the growing number and
	identify new protocols.		size of signatures to identify new protocols.
	o Network services leveraging heuristic based classification impact		o Network services leveraging heuristic based classification have a
	the application behavior by impacting its traffic, but they do not		negative effect on the application behavior by impacting its
	provide explicit feedback to the application. This results in a		traffic, while they do not provide explicit feedback to the
	lost opportunity for the application to gain insight and adjust		application. This results in a lost opportunity for the
	its operation accordingly.		application to gain insight and adjust its operation accordingly.
	5. Limitations of Existing Signaling Mechanisms		5. Limitations of Existing Signaling Mechanisms
	The IETF has standardized several mechanisms involving explicit		The IETF has standardized several mechanisms involving explicit
	signaling between applications and the network that may be used to		signaling between applications and the network that may be used to
	support visibility and differentiated network services workflows.		support visibility and differentiated network services workflows.
	Unfortunately, none of these has experienced widespread deployment		Unfortunately, none of these has experienced widespread deployment
	success, nor are they well suited for the applications usages		success, nor are they well suited for the applications usages
	described previously. Existing signaling options include the		described previously. Existing signaling options include the
	following:		following:
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	o Service Function Chaining (SFC) is a working group chartered to		o Service Function Chaining (SFC) is a working group chartered to
	address issues associated with the deployment of service functions		address issues associated with the deployment of service functions
	(e.g. firewalls, load balancers) in large-scale environments.		(e.g. firewalls, load balancers) in large-scale environments.
	Service function chaining is the definition and instantiation of		Service function chaining is the definition and instantiation of
	an ordered set of instances of such service functions, and the		an ordered set of instances of such service functions, and the
	subsequent "steering" of traffic flows through those service		subsequent "steering" of traffic flows through those service
	functions. Flow characteristics communicated via AEON could be		functions. Flow characteristics communicated via AEON could be
	used as input into an SFC classifier and it could be transported		used as input into an SFC classifier and it could be transported
	as SFC metadata.		as SFC metadata.
	7. Requirements		7. Acknowledgements
	Rather than encourage independent, protocol specific solutions to
	this problem, this document advocates a protocol and application
	independent information model and individual data models that can be
	applied in a consistent fashion across a variety of protocols to
	enable explicit communication between applications and the networks
	on which they are used. The requirements are:
	Req-1: Allow applications to explicitly signal their flow
	characteristics to the network.
	Req-2: Provide network nodes visibility to application flow
	characteristics.
	Req-3: Enable network nodes to contribute to application flow
	descriptions.
	Req-4: Allow applications to receive resulting flow descriptions as
	feedback from the network.
	Req-5: Complement existing heuristic based mechanisms.
	Req-6: Provide differentiated service for both directions of a flow,
	including flows that cross administrative boundaries.
	Req-7: Provide mechanism to authenticate and authorize endpoints/
	applications to signal flow characteristics, including 3rd party
	authentication and authorization for over-the-top (OTT)
	applications.
	Req-8: Provide mechanism for integrity protection and replay
	protection of messages exchanged between the application and the
	network.
	8. Acknowledgements
	The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine		The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine
	Choukir, Paul Jones, and Bill VerSteeg for their contributions to		Choukir, Paul Jones, and Bill VerSteeg for their contributions to
	this document.		this document.
	9. Informative References		8. Informative References
	[I-D.ietf-netconf-restconf]		[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,		Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
	"RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work		"RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work
	in progress), March 2014.		in progress), March 2014.
	[I-D.ietf-rtcweb-use-cases-and-requirements]		[I-D.ietf-rtcweb-use-cases-and-requirements]
	Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use-cases and Requirements", draft-		Time Communication Use-cases and Requirements", draft-
	ietf-rtcweb-use-cases-and-requirements-14 (work in		ietf-rtcweb-use-cases-and-requirements-14 (work in
	progress), February 2014.		progress), February 2014.
	[IEEE-802.1Q]		[IEEE-802.1Q]
	"IEEE Standards for Local and Metropolitan Area Networks:		"IEEE Standards for Local and Metropolitan Area Networks:
	Virtual Bridged Local Area Networks", IEEE 802.1Q, 2005,		Virtual Bridged Local Area Networks", IEEE 802.1Q, 2005,
	<http://standards.ieee.org/getieee802/download/		<http://standards.ieee.org/getieee802/
	802.1Q-2005.pdf>.		download/802.1Q-2005.pdf>.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
	and W. Weiss, "An Architecture for Differentiated		and W. Weiss, "An Architecture for Differentiated
	Services", RFC 2475, December 1998.		Services", RFC 2475, December 1998.
	[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the		[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
	skipping to change at line 498 ¶		skipping to change at page 11, line 4 ¶
	Email: tireddy@cisco.com		Email: tireddy@cisco.com
	Charles Eckel		Charles Eckel
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: eckelcu@cisco.com		Email: eckelcu@cisco.com
			Brandon Williams
			Akamai, Inc.
			8 Cambridge Center
			Cambridge, MA 02142
			USA
			Email: brandon.williams@akamai.com
End of changes. 19 change blocks.
	99 lines changed or deleted		65 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/