Network Working Group J. Schoenwaelder Internet-DraftV. BajpaiJacobs University Bremen Intended status: Standards TrackJacobs University BremenV. Bajpai Expires:January 9,December 4, 2017 Technical University Munich June 2, 2017July 8, 2016Using RESTCONF with LMAP Measurement Agentsdraft-ietf-lmap-restconf-03.txtdraft-ietf-lmap-restconf-04.txt Abstract This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onJanuary 9,December 4, 2017. Copyright Notice Copyright (c)20162017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 21.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 22. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3 3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3 4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . .35 5. RESTCONF Configuration for LMAP . . . . . . . . . . . . . . .46 6. Security Considerations . . . . . . . . . . . . . . . . . . .46 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .46 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .46 9. References . . . . . . . . . . . . . . . . . . . . . . . . .47 9.1. Normative References . . . . . . . . . . . . . . . . . .47 9.2. Informative References . . . . . . . . . . . . . . . . .47 Appendix A. Example RESTCONF Control Protocol Exchange . . . . .58 Appendix B. Example RESTCONF Report Protocol Exchange . . . . .79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .911 1. IntroductionThis document discusses how a Controller can use the RESTCONF protocol [I-D.ietf-netconf-restconf] to configureThe Framework for Large-Scale Measurement of Broadband Performance (LMAP) [RFC7594] describes an overall framework for large-scale broadband performance measurement systems. The standardization work in the IETF is restricted to the interaction between Measurement Agents[RFC7594]. It alsoand 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 usedbyto 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 toreport measurement results toa Collector. Measurement Agents may be deployed as separate hardware devices or as functions embedded in consumer electronic devices and home routers or as pure software solutions that can be installed on off-the-shelf computing equipment. Measurement Agents receive instructions from a Controller about when and how to conductwhatmeasurements (themeasurement schedule)Measurement Schedule) and how and when to report measurement results to a data Collector (thereport schedule).Report Schedule). Further information about the interaction between Measurement Agents and Controllers and Collectors can be found in [RFC7594]. The LMAP information model [I-D.ietf-lmap-information-model] defines in a conceptual and protocol-independent way the information exchanged between a Controller andana Measurement Agentandas well as the information exchanged betweenana Measurement Agent and a Collector.An information model is conceptual and protocol- independent.A concrete YANG[RFC6020][RFC7950] data model derived from the conceptual information model is defined in [I-D.ietf-lmap-yang].1.1. TerminologyThis 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 The RESTCONF protocol[I-D.ietf-netconf-restconf][RFC8040] providesa REST- like interface to access and manipulate a so-called unifiedan HTTP-based protocol for accessing data defined in YANGdatastore [RFC6020].[RFC7950]. The basic idea behind RESTCONF is to exposea YANG datastoresYANG-defined data as a collection of Web resources that can be accessed and manipulated using standard HTTP [RFC7230] GET, DELETE, PATCH, POST, and PUT methods. The resource hierarchy is derived from the nesting structure of the YANG schema tree, leading to a so-calleddata model driven REST API.data-model-driven application programming interface (API). RESTCONF is essentially a convention how to use HTTP over TLS to access adatastore that has a structure defined by a YANG data model.resources representing YANG-defined data. Thedata is exchanged inresources are 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 secure transport to the RESTCONF server. For devices located behind aNAT,middlebox (e.g., a network address translator or a firewall), a so called'call-home'Call Home mechanism has been defined[I-D.ietf-netconf-call-home] that enables[RFC8071]. The Call Home mechanism allows the RESTCONF server toestablishinitiate a secure transport to a RESTCONF client. Note thatcall homeCall Home only changes the TCP connection establishment, the TLS and HTTP client/server roles do not change. The policy used tocall homecontrol the Call Home mechanism can be configured through a configuration data model[I-D.ietf-netconf-server-model].[I-D.ietf-netconf-restconf-client-server]. This model provides a mechanism to configure a list of redundant endpoints and it provides control overcall-home policiesCall Home parameters (e.g,call-home frequency,frequency of Call Home attempts, idle-timers, keep-alive timers). 3. RESTCONF as LMAP Control ProtocolIt is straight-forwardThe LMAP Control Protocol delivers Instruction(s) from a Controller tousea Measurement Agent. The LMAP Control Protocol is realized by running a RESTCONF server on the Measurement Agent and a RESTCONF client on the Controller. Figure 1 depicts how the connection and 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. Measurement Agent Controller (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 acontrol protocol.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][I-D.ietf-lmap-yang], derived from the underlying information model[I-D.ietf-lmap-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 showinga REST call to createhow 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 ProtocolFor reporting resultsThe LMAP Report Protocol delivers Report(s) fromthea Measurement Agent to aCollector,Collector. The LMAP Report Protocol is realized by running a RESTCONF server on the Collector and a RESTCONF client on the Measurement Agent. Figure 3 depicts how the connection and the secure transport isassumedestablished and how reports are delivered toactthe 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 asawell but this is not shown here.) Measurement Agent Collector (RESTCONF Client) (RESTCONF Server) [TCP port 443] | | | TCP Connect | |--------------------------->| | TLS Exchange | |<-------------------------->| | | | HTTP POST | |--------------------------->| |<---------------------------| : : : : Figure 3: RESTCONFserver. Theas 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 LMAPXXX:[[CREF3: This sectionshouldcould explain how an LMAP implementation needs to be configured to make use of thecall-homeCall Home mechanism and how report tasks refer to the configuration (if any standardized) needed to obtain the necessary credentials to report results.This needsIs this necessary are can we simply refer tobe worked through in detail.the I-Ds that have the details? Note that these I-Ds are not stable yet.]] 6. Security ConsiderationsTBDSecurity 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 This document has no requests for IANA. 8. Acknowledgements Juergen Schoenwaelder and Vaibhav Bajpai worked in part on the Leone research project, which received funding from the European Union Seventh Framework Programme [FP7/2007-2013] under grant agreement number 317647. Juergen Schoenwaelder and Vaibhav Bajpai were partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. 9. References 9.1. Normative References [I-D.ietf-lmap-information-model] Burbridge, T., Eardley, P., Bagnulo, M., and J. Schoenwaelder, "Information Model for Large-Scale Measurement Platforms (LMAP)", draft-ietf-lmap- information-model-16 (work in progress), January 2017. [I-D.ietf-lmap-yang] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents",draft-ietf-lmap-yang-04draft-ietf-lmap-yang-10 (work in progress),March 2016. [I-D.ietf-netconf-restconf] Bierman,January 2017. [RFC7594] Eardley, P., Morton, A.,Bjorklund,Bagnulo, 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]Burbridge, T.,Eardley,Aitken, P.,Bagnulo, M.,andJ. Schoenwaelder, "Information ModelA. Akhter, "A Framework for Large-Scale MeasurementPlatformsof Broadband Performance (LMAP)",draft-ietf-lmap- information-model-09 (work in progress), March 2016. [I-D.ietf-netconf-call-home]RFC 7594, DOI 10.17487/RFC7594, September 2015, <http://www.rfc-editor.org/info/rfc7594>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <http://www.rfc-editor.org/info/rfc8040>. [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",draft-ietf-netconf-call-home-17 (work in progress), December 2015. [I-D.ietf-netconf-server-model]RFC 8071, DOI 10.17487/RFC8071, February 2017, <http://www.rfc-editor.org/info/rfc8071>. 9.2. Informative References [I-D.ietf-netconf-restconf-client-server] Watsen, K. and J. Schoenwaelder,"NETCONF Server"RESTCONF Client andRESTCONFServerConfigurationModels",draft-ietf-netconf- server-model-09draft-ietf-netconf-restconf-client- server-01 (work in progress),MarchNovember 2016.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.[RFC7594] Eardley, P., Morton, A., Bagnulo,[RFC7950] Bjorklund, M.,Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale MeasurementEd., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>. [RFC7951] Lhotka, L., "JSON Encoding ofBroadband Performance (LMAP)",Data Modeled with YANG", RFC7594,7951, DOI10.17487/RFC7594, September 2015, <http://www.rfc-editor.org/info/rfc7594>.10.17487/RFC7951, August 2016, <http://www.rfc-editor.org/info/rfc7951>. Appendix A. Example RESTCONF Control Protocol Exchange Below is a YANG tree diagram of a part of the data model covering schedules. This is taken from [I-D.ietf-lmap-yang]. module: ietf-lmap-control +--rw lmap +--rw schedules +--rw schedule* [name] +--rw name lmap:identifier +--rw event event-ref +--rw execution-mode enumeration +--rw action* [name] +--rw name string +--rw task task-ref +--rw option* [name] | +--rw id lmap:identifier | +--rw name? string | +--rw value? string +--rw destination* leafref Below is an XML representation of instance data conforming to the YANG data model is shown below. Note that some of the strings are references to other portions of the instance data not show here. This is again taken from [I-D.ietf-lmap-yang]. <lmap xmlns="urn:ietf:params:xml:ns:yang:ietf-lmap"> <schedules> <schedule> <name>hourly-schedule</name> <event>hourly</event> <execution-mode>sequential</execution-mode> <action> <name>icmp-latency-hourly</name> <task>icmp-latency-measurement</task> <destination>daily</destination> </action> </schedule> </schedules> </lmap> Below is an example showing how RESTCONF can be used to create the above schedule. The prefix C: indicates the Controller, the prefix M: indicates the Measurement Agent. This example uses a JSON encoding (and note that much of the white-space can be removed, this is only there to help with readability). C: POST /restconf/data/ietf-lmap-control:lmap/schedules HTTP/1.1 C: Host: example.com C: Content-Type: application/yang.data+json C: C: { C: "ietf-lmap-control:schedule": { C: "name": "hourly-schedule", C: "event": "hourly", C: "execution-mode": "sequential", C: "action": [ C: { C: "name": "icmp-latency-hourly", C: "task": "icmp-latency-measurement", C: "destination": "daily", C: } C: ] C: } C: } M: HTTP/1.1 201 Created M: Date: Mon, 26 Mar 2015 17:01:00 GMT M: Server: example-server M: Location: https://example.com/restconf/data M: /ietf-lmap-control:lmap/schedules/schedule=hourly-schedule M: Last-Modified: Mon, 26 Mar 2015 17:01:00 GMT M: ETag: b3a3e673be2 Appendix B. Example RESTCONF Report Protocol Exchange Below is an example showing how a Measurement Agent can submit results to a Collector running an RESTCONF server. The prefix C: indicates the Collector, the prefix M: indicates the Measurement Agent. M: POST /restconf/operations/ietf-lmap-report:report HTTP/1.1 M: Host: example.com M: Content-Type: application/yang.operation+xml M: M: <input xmlns="urn:ietf:params:xml:ns:yang:ietf-lmap-report"> M: <date>2015-10-28T13:27:42+02:00</date> M: <agent-id>550e8400-e29b-41d4-a716-446655440000</agent-id> M: <group-id>wireless measurement at the north-pole</group-id> M: <result> M: <schedule-name>pinger</schedule-name> M: <action-name>fping</action-name> M: <task-name>fping</task-name> M: <option> M: <id>display-address</id> M: <name>-A</name> M: </option> M: <option> M: <id>display-DNS-lookup</id> M: <name>-d</name> M: </option> M: <option> M: <id>number-of-packets</id> M: <name>-C</name> M: <value>5</value> M: </option> M: <option> M: <id>quiet</id> M: <name>-q</name> M: </option> M: <option> M: <id>www.example.org</id> M: <name>www.example.org</name> M: </option> M: <option> M: <id>mail.example.com</id> M: <name>mail.example.com</name> M: </option> M: <start>2016-03-21T10:48:55+01:00</start> M: <end>2016-03-21T10:48:57+01:00</end> M: <status>0</status> M: <table> M: <column>target</column> M: <column>ip</column> M: <column>rtt-1</column> M: <column>rtt-2</column> M: <column>rtt-3</column> M: <column>rtt-4</column> M: <column>rtt-5</column> M: <row> M: <value>www.example.org</value> M: <value>2001:db8::1</value> M: <value>14.15</value> M: <value>14.14</value> M: <value>14.09</value> M: <value>14.17</value> M: <value>14.51</value> M: </row> M: <row> M: <value>mail.example.org</value> M: <value>2001:db8::2</value> M: <value>12.24</value> M: <value>11.99</value> M: <value>12.49</value> M: <value>11.87</value> M: <value>12.45</value> M: </row> M: </table> M: </result> M: </input> C: HTTP/1.1 200 OK Authors' Addresses Juergen Schoenwaelder Jacobs University Bremen Email: j.schoenwaelder@jacobs-university.de Vaibhav BajpaiJacobsTechnical UniversityBremenMunich Email:v.bajpai@jacobs-university.debajpaiv@in.tum.de