< draft-ietf-lmap-restconf-03.txt		draft-ietf-lmap-restconf-04.txt >
	Network Working Group J. Schoenwaelder		Network Working Group J. Schoenwaelder
	Internet-Draft V. Bajpai		Internet-Draft Jacobs University Bremen
	Intended status: Standards Track Jacobs University Bremen		Intended status: Standards Track V. Bajpai
	Expires: January 9, 2017 July 8, 2016		Expires: December 4, 2017 Technical University Munich
			June 2, 2017
	Using RESTCONF with LMAP Measurement Agents		Using RESTCONF with LMAP Measurement Agents
	draft-ietf-lmap-restconf-03.txt		draft-ietf-lmap-restconf-04.txt
	Abstract		Abstract
	This document describes how RESTCONF can be used with a YANG data		This document describes how RESTCONF can be used with a YANG data
	model for Large-Scale Measurement Platforms (LMAP).		model for Large-Scale Measurement Platforms (LMAP).
	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.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 32 ¶
	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 January 9, 2017.		This Internet-Draft will expire on December 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3		2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3
	3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3		3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3
	4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 3		4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 5
	5. RESTCONF Configuration for LMAP . . . . . . . . . . . . . . . 4		5. RESTCONF Configuration for LMAP . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 4		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 4		9.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. Example RESTCONF Control Protocol Exchange . . . . . 5		Appendix A. Example RESTCONF Control Protocol Exchange . . . . . 8
	Appendix B. Example RESTCONF Report Protocol Exchange . . . . . 7		Appendix B. Example RESTCONF Report Protocol Exchange . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document discusses how a Controller can use the RESTCONF		The Framework for Large-Scale Measurement of Broadband Performance
	protocol [I-D.ietf-netconf-restconf] to configure Large-Scale		(LMAP) [RFC7594] describes an overall framework for large-scale
	Measurement of Broadband Performance (LMAP) Measurement Agents		broadband performance measurement systems. The standardization work
	[RFC7594]. It also discusses how RESTCONF can be used by a		in the IETF is restricted to the interaction between Measurement
	Measurement Agent to report measurement results to a Collector.		Agents and their Controllers and between Measurement Agents and
			result Collectors (see Figure 1 in [RFC7594]).
			The protocol selection process within the LMAP working group of the
			IETF gave preference to a solution that reuses existing IETF
			protocols rather than inventing new ones. In addition, there was a
			preference to use a protocol that is layered on top of HTTP since
			this allows to reuse implementations already widely available.
			This document discusses how the RESTCONF protocol [RFC8040] can be
			used to facilitate the communication between components implementing
			the LMAP framework. In particular, this document discusses how
			RESTCONF can be used as a Control Protocol to deliver Instruction(s)
			from a Controller to a Measurement Agent, and as a Report Protocol
			delivering Report(s) from a Measurement Agent to a Collector.
	Measurement Agents may be deployed as separate hardware devices or as		Measurement Agents may be deployed as separate hardware devices or as
	functions embedded in consumer electronic devices and home routers or		functions embedded in consumer electronic devices and home routers or
	as pure software solutions that can be installed on off-the-shelf		as pure software solutions that can be installed on off-the-shelf
	computing equipment. Measurement Agents receive instructions from a		computing equipment. Measurement Agents receive instructions from a
	Controller about when and how to conduct what measurements (the		Controller about when and how to conduct measurements (the
	measurement schedule) and how and when to report measurement results		Measurement Schedule) and how and when to report measurement results
	to a data Collector (the report schedule). Further information about		to a data Collector (the Report Schedule). Further information about
	the interaction between Measurement Agents and Controllers and		the interaction between Measurement Agents and Controllers and
	Collectors can be found in [RFC7594].		Collectors can be found in [RFC7594].
	The LMAP information model [I-D.ietf-lmap-information-model] defines		The LMAP information model [I-D.ietf-lmap-information-model] defines
	the information exchanged between a Controller and an Measurement		in a conceptual and protocol-independent way the information
	Agent and the information exchanged between an Measurement Agent and		exchanged between a Controller and a Measurement Agent as well as the
	a Collector. An information model is conceptual and protocol-		information exchanged between a Measurement Agent and a Collector. A
	independent. A concrete YANG [RFC6020] data model derived from the		concrete YANG [RFC7950] data model derived from the conceptual
	conceptual information model is defined in [I-D.ietf-lmap-yang].		information model is defined in [I-D.ietf-lmap-yang].
	1.1. Terminology
	This document uses the LMAP terminology defined in [RFC7594].		This document uses the LMAP terminology defined in [RFC7594].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2. Overview of RESTCONF		2. Overview of RESTCONF
	The RESTCONF protocol [I-D.ietf-netconf-restconf] provides a REST-		The RESTCONF protocol [RFC8040] provides an HTTP-based protocol for
	like interface to access and manipulate a so-called unified YANG		accessing data defined in YANG [RFC7950]. The basic idea behind
	datastore [RFC6020]. The basic idea behind RESTCONF is expose a YANG		RESTCONF is to expose YANG-defined data as a collection of Web
	datastores as a collection of Web resources that can be manipulated		resources that can be accessed and manipulated using standard HTTP
	using standard HTTP [RFC7230] DELETE, PATCH, POST, and PUT methods.		[RFC7230] GET, DELETE, PATCH, POST, and PUT methods. The resource
	The resource hierarchy is derived from the nesting structure of the		hierarchy is derived from the nesting structure of the YANG schema
	YANG schema tree, leading to a so-called data model driven REST API.		tree, leading to a so-called data-model-driven application
			programming interface (API).
	RESTCONF is essentially a convention how to use HTTP over TLS to		RESTCONF is essentially a convention how to use HTTP over TLS to
	access a datastore that has a structure defined by a YANG data model.		access a resources representing YANG-defined data. The resources are
	The data is exchanged in XML encoding or JSON encoding.		represented using either XML encoding (according to [RFC7950]) or
			JSON encoding (according to [RFC7951]). The examples shown in this
			document use the JSON encoding.
	The normal mode of operation is that the RESTCONF client initiates a		The normal mode of operation is that the RESTCONF client initiates a
	secure transport to the RESTCONF server. For devices located behind		secure transport to the RESTCONF server. For devices located behind
	a NAT, a so called 'call-home' mechanism has been defined		a middlebox (e.g., a network address translator or a firewall), a so
	[I-D.ietf-netconf-call-home] that enables the RESTCONF server to		called Call Home mechanism has been defined [RFC8071]. The Call Home
	establish a secure transport to a RESTCONF client. Note that call		mechanism allows the RESTCONF server to initiate a secure transport
	home only changes the TCP connection establishment, the TLS and HTTP		to a RESTCONF client. Note that Call Home only changes the TCP
	client/server roles do not change. The policy used to call home can		connection establishment, the TLS and HTTP client/server roles do not
	be configured through a configuration data model		change. The policy used to control the Call Home mechanism can be
	[I-D.ietf-netconf-server-model]. This model provides a mechanism to		configured through a configuration data model
	configure a list of redundant endpoints and it provides control over		[I-D.ietf-netconf-restconf-client-server]. This model provides a
	call-home policies (e.g, call-home frequency, idle-timers, keep-alive		mechanism to configure a list of redundant endpoints and it provides
	timers).		control over Call Home parameters (e.g, frequency of Call Home
			attempts, idle-timers, keep-alive timers).
	3. RESTCONF as LMAP Control Protocol		3. RESTCONF as LMAP Control Protocol
	It is straight-forward to use RESTCONF as a control protocol. The		The LMAP Control Protocol delivers Instruction(s) from a Controller
	YANG data model [I-D.ietf-lmap-yang] derived from the underlying		to a Measurement Agent. The LMAP Control Protocol is realized by
	information model [I-D.ietf-lmap-information-model] translates into a		running a RESTCONF server on the Measurement Agent and a RESTCONF
	collection of RESTCONF resources that can be manipulated at various		client on the Controller. Figure 1 depicts how the connection and
	levels of granularity using DELETE, PATCH, POST, and PUT methods.		the secure transport is established when the Measurement Agent is
			directly reachable from the Controller, i.e., the Measurement Agent
			has a well-known name or address and is directly reachable from the
			Controller.
	An example exchange showing a REST call to create a schedule object		Measurement Agent Controller
	is shown in Appendix A.		(RESTCONF Server) (RESTCONF Client)
			[TCP port 443]
			| |
			| TCP Connect |
			|<---------------------------|
			| TLS Exchange |
			|<-------------------------->|
			| |
			| HTTP GET / POST / ... |
			|<---------------------------|
			|--------------------------->|
			: :
			: :
			Figure 1: RESTCONF as Control protocol (without Call Home)
			In several deployment scenarios, it will not be possible for the
			Controller to initiate a connection to the Measurement Agent due to
			the presence of middleboxes such as network address translators and
			firewalls. In such a situation, the Measurement Agent running a
			RESTCONF server will Call Home to the Controller running a RESTCONF
			client as shown in Figure 2.
			Measurement Agent Controller
			(RESTCONF Server) (RESTCONF Client)
			[TCP port 4336]
			| |
			| TCP Connect |
			|--------------------------->|
			| TLS Exchange |
			|<-------------------------->|
			| |
			| HTTP GET / POST / ... |
			|<---------------------------|
			|--------------------------->|
			: :
			: :
			Figure 2: RESTCONF as Control Protocol (with Call Home)
			Note that the Call Home mechanism only 'reverses' the way the
			underlying TCP connection is established. The subsequent TLS
			exchange has the TLS server role on the RESTCONF server side and the
			TLS client role on the RESTCONF client side.
			The YANG data model [I-D.ietf-lmap-yang], derived from the underlying
			information model [I-D.ietf-lmap-information-model], translates into
			a collection of RESTCONF resources that can be accessed and
			manipulated at various levels of granularity using HTTP GET, DELETE,
			PATCH, POST, and PUT methods.
			An example exchange showing how a schedule object is installed on a
			Measurement Agent is shown in Appendix A.
			[[CREF1: Move the example inline, update it to be aligned to the
			final YANG model and use JSON encoding.]]
	4. RESTCONF as LMAP Report Protocol		4. RESTCONF as LMAP Report Protocol
	For reporting results from the Measurement Agent to a Collector, the		The LMAP Report Protocol delivers Report(s) from a Measurement Agent
	Collector is assumed to act as a RESTCONF server. The Measurement		to a Collector. The LMAP Report Protocol is realized by running a
	Agent pushes results to the Collector by invoking an operation on the		RESTCONF server on the Collector and a RESTCONF client on the
	Controller.		Measurement Agent. Figure 3 depicts how the connection and the
			secure transport is established and how reports are delivered to the
			Controller. Note that it is generally assumed that the Controller is
			directly reachable from the Measurement Agent. (In situations where
			this may not be true, RESTCONF Call Home can be used as well but this
			is not shown here.)
			Measurement Agent Collector
			(RESTCONF Client) (RESTCONF Server)
			[TCP port 443]
			| |
			| TCP Connect |
			|--------------------------->|
			| TLS Exchange |
			|<-------------------------->|
			| |
			| HTTP POST |
			|--------------------------->|
			|<---------------------------|
			: :
			: :
			Figure 3: RESTCONF as Report Protocol
			Note that the Measurement Agent pushes results to the Collector by
			invoking an operation on the Controller. This maps to an HTTP POST
			in RESTCONF. Hence, pushing results can effectively be done by
			posting a the result to a specific RESTCONF resource.
			An example exchange showing how results are reported to a Controller
			is shown in Appendix B.
			[[CREF2: Move the example inline, update it to be aligned to the
			final YANG model and use JSON encoding.]]
	5. RESTCONF Configuration for LMAP		5. RESTCONF Configuration for LMAP
	XXX: This section should explain how an LMAP implementation needs to		[[CREF3: This section could explain how an LMAP implementation needs
	be configured to make use of the call-home mechanism and how report		to be configured to make use of the Call Home mechanism and how
	tasks refer to the configuration (if any standardized) needed to		report tasks refer to the configuration (if any standardized) needed
	obtain the necessary credentials to report results. This needs to be		to obtain the necessary credentials to report results. Is this
	worked through in detail.		necessary are can we simply refer to the I-Ds that have the details?
			Note that these I-Ds are not stable yet.]]
	6. Security Considerations		6. Security Considerations
	TBD		Security and privacy aspects of the LMAP framework are discussed in
			Sections 7 and 8 of [RFC7594]. Section 12 of [RFC8040] and Section 5
			of [RFC8071] discuss the security aspects of RESTCONF and the
			RESTCONF Call Home mechanism.
			The security considerations specific to the LMAP information model
			and the YANG data model can be found in Section 6 of
			[I-D.ietf-lmap-information-model] and Section 5 of
			[I-D.ietf-lmap-yang].
	7. IANA Considerations		7. IANA Considerations
	This document has no requests for IANA.		This document has no requests for IANA.
	8. Acknowledgements		8. Acknowledgements
	Juergen Schoenwaelder and Vaibhav Bajpai worked in part on the Leone		Juergen Schoenwaelder and Vaibhav Bajpai worked in part on the Leone
	research project, which received funding from the European Union		research project, which received funding from the European Union
	Seventh Framework Programme [FP7/2007-2013] under grant agreement		Seventh Framework Programme [FP7/2007-2013] under grant agreement
	number 317647.		number 317647.
	Juergen Schoenwaelder and Vaibhav Bajpai were partly funded by		Juergen Schoenwaelder and Vaibhav Bajpai were partly funded by
	Flamingo, a Network of Excellence project (ICT-318488) supported by		Flamingo, a Network of Excellence project (ICT-318488) supported by
	the European Commission under its Seventh Framework Programme.		the European Commission under its Seventh Framework Programme.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-lmap-yang]
	Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
	LMAP Measurement Agents", draft-ietf-lmap-yang-04 (work in
	progress), March 2016.
	[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", draft-ietf-netconf-restconf-14 (work in
	progress), June 2016.
	9.2. Informative References
	[I-D.ietf-lmap-information-model]		[I-D.ietf-lmap-information-model]
	Burbridge, T., Eardley, P., Bagnulo, M., and J.		Burbridge, T., Eardley, P., Bagnulo, M., and J.
	Schoenwaelder, "Information Model for Large-Scale		Schoenwaelder, "Information Model for Large-Scale
	Measurement Platforms (LMAP)", draft-ietf-lmap-		Measurement Platforms (LMAP)", draft-ietf-lmap-
	information-model-09 (work in progress), March 2016.		information-model-16 (work in progress), January 2017.
	[I-D.ietf-netconf-call-home]		[I-D.ietf-lmap-yang]
	Watsen, K., "NETCONF Call Home and RESTCONF Call Home",		Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
	draft-ietf-netconf-call-home-17 (work in progress),		LMAP Measurement Agents", draft-ietf-lmap-yang-10 (work in
	December 2015.		progress), January 2017.
	[I-D.ietf-netconf-server-model]		[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
	Watsen, K. and J. Schoenwaelder, "NETCONF Server and		Aitken, P., and A. Akhter, "A Framework for Large-Scale
	RESTCONF Server Configuration Models", draft-ietf-netconf-		Measurement of Broadband Performance (LMAP)", RFC 7594,
	server-model-09 (work in progress), March 2016.		DOI 10.17487/RFC7594, September 2015,
			<http://www.rfc-editor.org/info/rfc7594>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	RFC2119, March 1997,		<http://www.rfc-editor.org/info/rfc8040>.
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
	the Network Configuration Protocol (NETCONF)", RFC 6020,		RFC 8071, DOI 10.17487/RFC8071, February 2017,
	DOI 10.17487/RFC6020, October 2010,		<http://www.rfc-editor.org/info/rfc8071>.
	<http://www.rfc-editor.org/info/rfc6020>.
			9.2. Informative References
			[I-D.ietf-netconf-restconf-client-server]
			Watsen, K. and J. Schoenwaelder, "RESTCONF Client and
			Server Models", draft-ietf-netconf-restconf-client-
			server-01 (work in progress), November 2016.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing", RFC		Protocol (HTTP/1.1): Message Syntax and Routing", RFC
	7230, DOI 10.17487/RFC7230, June 2014,		7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	Aitken, P., and A. Akhter, "A Framework for Large-Scale		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	Measurement of Broadband Performance (LMAP)", RFC 7594,		<http://www.rfc-editor.org/info/rfc7950>.
	DOI 10.17487/RFC7594, September 2015,
	<http://www.rfc-editor.org/info/rfc7594>.		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC
			7951, DOI 10.17487/RFC7951, August 2016,
			<http://www.rfc-editor.org/info/rfc7951>.
	Appendix A. Example RESTCONF Control Protocol Exchange		Appendix A. Example RESTCONF Control Protocol Exchange
	Below is a YANG tree diagram of a part of the data model covering		Below is a YANG tree diagram of a part of the data model covering
	schedules. This is taken from [I-D.ietf-lmap-yang].		schedules. This is taken from [I-D.ietf-lmap-yang].
	module: ietf-lmap-control		module: ietf-lmap-control
	+--rw lmap		+--rw lmap
	+--rw schedules		+--rw schedules
	+--rw schedule* [name]		+--rw schedule* [name]
	skipping to change at page 9, line 24 ¶		skipping to change at page 11, line 23 ¶
	C: HTTP/1.1 200 OK		C: HTTP/1.1 200 OK
	Authors' Addresses		Authors' Addresses
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Email: j.schoenwaelder@jacobs-university.de		Email: j.schoenwaelder@jacobs-university.de
	Vaibhav Bajpai		Vaibhav Bajpai
	Jacobs University Bremen		Technical University Munich
	Email: v.bajpai@jacobs-university.de		Email: bajpaiv@in.tum.de
End of changes. 27 change blocks.
	108 lines changed or deleted		216 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/