Network Working Group                                   J. Schoenwaelder
Internet-Draft                                                 V. Bajpai
Intended status: Standards Track                Jacobs University Bremen
Expires: January May 4, 2016                                    July 3,                                    November 1, 2015

              Using RESTCONF with LMAP Measurement Agents
                    draft-ietf-lmap-restconf-00.txt
                    draft-ietf-lmap-restconf-01.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 on January May 4, 2016.

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview of RESTCONF  . . . . . . . . . . . . . . . . . . . .   2   3
   3.  RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . .   3
   4.  RESTCONF as LMAP Report Protocol  . . . . . . . . . . . . . .   3
   5.  Conclusion  . . . . . .  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Appendix A.  Response to Protocol Comparison Criteria . . . . . .   5
   Appendix B.  Example RESTCONF Control Protocol Exchange . . . . .   7   5
   Appendix C. B.  Example RESTCONF Report Protocol Exchange  . . . . .   9   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10   8

1.  Introduction

   This document discusses how a controller Controller can use the RESTCONF
   protocol [I-D.ietf-netconf-restconf] to configure Large-Scale
   Measurement of Broadband Performance (LMAP) measurement agents (MAs)
   [I-D.ietf-lmap-framework]. Measurement Agents
   [RFC7594].  It also discusses how RESTCONF can be used by a
   Measurement Agent to report measurement results to a collector.

   MAs 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 Agents receive instructions from a controller
   Controller about when and how to conduct what measurements (the
   measurement schedule) and how and when to report measurement results
   to a data
   collector Collector (the report schedule).  Further information about
   the interaction between MAs Measurement Agents and controllers Controllers and collectors
   Collectors can be found in [I-D.ietf-lmap-framework]. [RFC7594].

   The LMAP information model [I-D.ietf-lmap-information-model] defines
   the information exchanged between a controller Controller and an MA Measurement
   Agent and the information exchanged between an MA Measurement Agent and
   a collector. Collector.  An information model is conceptual and protocol-independent. protocol-
   independent.  A concrete YANG [RFC6020] data model derived from the
   conceptual information model is defined in [I-D.ietf-lmap-yang].

1.1.  Terminology

   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

   The RESTCONF protocol [I-D.ietf-netconf-restconf] provides a REST-
   like interface to access and manipulate a so-called unified YANG
   datastore [RFC6020].  The basic idea behind RESTCONF is expose a YANG
   datastores as a collection of Web resources that can be manipulated
   using standard HTTP [RFC7230] DELETE, PATCH, POST, and PUT methods.
   The resource hierarchy is derived from the nesting structure of the
   YANG schema tree, leading to a so called so-called data model driven REST API.

   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.
   The data is exchanged in XML encoding or JSON encoding.

   The normal mode of operation is that the RESTCONF client initiates a
   secure transport to the RESTCONF server.  For devices located behind
   a NAT, a so called 'call-home' mechanism has been defined
   [I-D.ietf-netconf-call-home] that enables the RESTCONF server to
   establish a secure transport to a RESTCONF client.  Note that call
   home only changes the TCP connection establishment, the TLS and HTTP
   client/server roles do not change.  The policy used to call home can
   be configured through a configuration data model
   [I-D.ietf-netconf-server-model].  This model provides a mechanism to
   configure a list of redundant endpoints and it provides control over
   call-home policies (e.g, call-home frequency, idle-timers, keep-alive
   timers).

3.  RESTCONF as LMAP Control Protocol

   It is straight-forward to user use RESTCONF as a control protocol.  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 manipulated at various
   levels of granularity using DELETE, PATCH, POST, and PUT methods.

   An example exchange showing a REST call to create a schedule object
   is shown in Appendix B. A.

4.  RESTCONF as LMAP Report Protocol

   One way of mapping the information model parts relevant for reports
   into a YANG data model is the usage of YANG notifications.  This is
   the approach currently used in [I-D.ietf-lmap-yang].  This mapping
   leads to report notifications that push measurement

   For reporting results from the
   MA Measurement Agent to a collector.  The RESTCONF protocol uses Server Sent Events as
   the underlying mechanism to stream notifications.

   A direct mapping of Collector, the information model leads to relatively verbose
   exchanges and it is possible to define more space efficient
   notifications that suppress information that is only changing rarely.

   An example exchange of a result notification is shown in Appendix C.

   Note that alternative designs are possible.  One option
   Collector is assumed to make
   the collector act as a RESTCONF server and to have the MA push server.  The Measurement
   Agent pushes results to the collector Collector by posting to resources on the controller.  Another
   option is to have the results reside invoking an operation on the MA and to export the
   results as part of the operational state of the MA.  The collector(s)
   will then use GET requests to fetch the result resources from the MA.
   Note that all three approaches can be implemented using RESTCONF and
   YANG.
   Controller.

5.  Conclusion

   This document discusses how RESTCONF can be used as a control
   protocol and a report protocol for Large-Scale Measurement Platforms
   (LMAP).  The benefit of using RESTCONF is that no new protocol work
   needs to be done.  Additional benefits derive from using YANG and a
   data model driven approach.  Despite the reuse of existing tools,
   using a data model driven approach allows to easily reuse other data
   models (e.g., network interfaces [RFC7223], [RFC7277] or general
   system services [RFC7317]) in order to export additional status
   information about an MA to a controller.  Security Considerations

   TBD

6.  IANA Considerations

   This document has no requests for IANA.

7.  Acknowledgements

   Juergen Schoenwaelder and Vaibhav Bajpai work worked in part on the Leone
   research project, which receives 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.

8.  Informative References

   [I-D.ietf-lmap-framework]
              Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A framework for Large-Scale
              Measurement of Broadband Performance (LMAP)", draft-ietf-
              lmap-framework-12 (work in progress), March 2015.

   [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-06 (work in progress), July 2015.

   [I-D.ietf-lmap-yang]
              Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
              LMAP Measurement Agents", draft-ietf-lmap-yang-01 (work in
              progress), July 2015.

   [I-D.ietf-netconf-call-home]
              Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              draft-ietf-netconf-call-home-08
              draft-ietf-netconf-call-home-11 (work in progress), June
              September 2015.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-06 draft-ietf-netconf-restconf-08 (work in
              progress), June October 2015.

   [I-D.ietf-netconf-server-model]
              Watsen, K. and J. Schoenwaelder, "NETCONF Server and
              RESTCONF Server Configuration Models", draft-ietf-netconf-
              server-model-06
              server-model-08 (work in progress), February October 2015.

   [I-D.starkcarey-lmap-protocol-criteria]
              Stark, B. and T. Carey, "LMAP Protocol Selection
              Criteria", draft-starkcarey-lmap-protocol-criteria-01
              (work

   [RFC2119]  Bradner, S., "Key words for use in progress), RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 2015. 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. 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014. 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7230]  Fielding, R. R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing", RFC
              7230, DOI 10.17487/RFC7230, June
              2014. 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management", RFC
              7277, DOI 10.17487/RFC7277, June 2014. 2014,
              <http://www.rfc-editor.org/info/rfc7277>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014.

Appendix A.  Response to Protocol Comparison Criteria

   A set of control
              2014, <http://www.rfc-editor.org/info/rfc7317>.

   [RFC7594]  Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and report protocol comparison criteria has been
   defined in [I-D.starkcarey-lmap-protocol-criteria].  This section
   compares the usage A. Akhter, "A Framework for Large-Scale
              Measurement of RESTCONF against the criteria.

   CP-MUST-1   yes (RFC6241 RFC6242, RFC5539),
               [I-D.ietf-netconf-restconf]

   CP-MUST-2   yes [I-D.ietf-netconf-call-home]
   CP-MUST-3   yes SSH / TLS (NETCONF), TLS (RESTCONF)

   CP-MUST-4   yes YANG data models [RFC6020] have a well defined
               versioning and extension model

   CP-DIFF-1   1

   CP-DIFF-2   1

   CP-DIFF-3   yes

   CP-DIFF-4   yes (NETCONF|RESTCONF) call home

   CP-DIFF-5   (underspecified - it is JSON or XML over HTTP/TLS)

   CP-DIFF-6   (underspecified - it is JSON or XML over HTTP/TLS)

   CP-DIFF-7   HTTP and JSON/XML are pretty much everywhere

   CP-DIFF-8   YANG tools are out there and the rest will develop, HTTP
               and TLS are pretty well understood

   CP-DIFF-9   yes

   CP-DIFF-10  many tools out there to create REST code, YANG tools
               available

   CP-DIFF-11  yes, YANG RFC 6020 data models have a version model

   CP-DIFF-12  additional YANG modules can augment the standard data
               model

   CP-DIFF-13  JSON and XML, CBOR in the making

   RP-MUST-1   yes [I-D.ietf-netconf-call-home]

   RP-MUST-2   SSH / TLS (NETCONF), TLS (RESTCONF)

   RP-MUST-3   YANG Broadband Performance (LMAP)", RFC 6020 data models have a version model

   RP-DIFF-1   TCP

   RP-DIFF-2   yes

   RP-DIFF-3   (underspecified - it is HTTP over TLS)

   RP-DIFF-4   yes
   RP-DIFF-5   yes

   RP-DIFF-6   yes (as part of HTTP encoding negotiations)

   RP-DIFF-7   (underspecified - it is JSON or XML over HTTP/TLS)

   RP-DIFF-8   HTTP and JSON/XML are pretty much everywhere

   RP-DIFF-9   many tools out there to create REST code, YANG tools
               available

   RP-DIFF-10  yes

   RP-DIFF-11  many tools out there to create REST code, YANG tools
               available

   RP-DIFF-12  JSON and XML, CBOR in the making 7594,
              DOI 10.17487/RFC7594, September 2015,
              <http://www.rfc-editor.org/info/rfc7594>.

Appendix B. 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
      +--rw lmap
         +--rw schedules
            +--rw schedule* [name]
               +--rw name      string
               +--rw event     leafref
               +--rw action* [name]
               |  +--rw name           string
               |  +--rw task           leafref
               |  +--rw option* [name]
               |  |  +--rw name       string
               |  |  +--rw value?     string
               |  +--rw destination*  leafref
               +--rw execution-mode   enumeration

   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>
           <action>
             <name>icmp-latency-hourly</name>
             <task>icmp-latency-measurement</task>
             <destination>daily</destination>
           </action>
           <execution-mode>sequential</execution-mode>
         </schedule>
       </schedules>
     </lmap>

   Below is an example showing how RESTCONF can be used to create the
   above schedule.  The prefix C: indicates the controller, Controller, the prefix
   M: indicates the measurement agent. 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:lmap/schedules HTTP/1.1
     C: Host: example.com
     C: Content-Type: application/yang.data+json
     C:
     C:   {
     C:     "ietf-lmap:schedule": {
     C:       "name": "hourly-schedule",
     C:       "event": "hourly",
     C:       "action": [
     C:         {
     C:           "name": "icmp-latency-hourly",
     C:           "task": "icmp-latency-measurement",
     C:           "destination": "daily",
     C:         }
     C:       ],
     C:       "execution-mode": "sequential"
     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:lmap/schedules/schedule=hourly-schedule
     M: Last-Modified: Mon, 26 Mar 2015 17:01:00 GMT
     M: ETag: b3a3e673be2

Appendix C. B.  Example RESTCONF Report Protocol Exchange

   The first step taken by the collector

   Below is an example showing how a Measurement Agent can submit
   results to lookup the event stream
   resource.

     C: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ a Collector running an RESTCONF server.  The prefix C:     /streams/stream=NETCONF/encoding=json/events
   indicates the Collector, the prefix M: indicates the Measurement
   Agent.

     M: POST /restconf/operations/ietf-lmap-report:report HTTP/1.1
     C:
     M: Host: example.com
     C: Accept: application/yang.data+xml

     M: HTTP/1.1 200 OK
     M: Content-Type: application/yang.api+xml application/yang.operation+xml
     M:
     M: <events <input>
     M:  xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">   <report xmlns="urn:ietf:params:xml:ns:yang:ietf-lmap-report">
     M:  https://example.com/streams/NETCONF-json     <date>2015-10-28T13:27:42+02:00</date>
     M: </events>

   Once the event stream resource is known (information might be
   cached), the collector subscribes to     <agent-id>550e8400-e29b-41d4-a716-446655440000</agent-id>
     M:     <group-id>wireless measurement at the event stream resource.

     C: GET /streams/NETCONF-json HTTP/1.1
     C: Host: example.com
     C: Accept: text/event-stream
     C: Cache-Control: no-cache
     C: Connection: keep-alive north-pole</group-id>
     M: data: {     <task>
     M: data:    "ietf-restconf:notification": {       <name>icmp-latency-measurement</name>
     M: data:      "event-time": "2015-03-25T00:01:00+00:00",       <metric>
     M: data:      "ietf-lmap:report": {         <uri>urn:....</uri>
     M: data:         "date": "2015-03-25T00:01:00+00:00",
     M: data:         "agent-id": "xxx",       </metric>
     M: data:         "header": {       <header>
     M: data:           "column": "target",
     M: data:           "column": "rtt"         <column>target</column>
     M: data:         }         <column>rtt</column>
     M: data:         "row": {       </header>
     M: data:           "start": "2015-03-25T00:00:55+00:00",
     M: data:           "value": "192.0.2.1",
     M: data:           "value": 42       <row>
     M: data:         }         <start-time>2015-03-25T00:00:55+00:00</start-time>
     M: data:         "row": {         <value>192.0.2.1</value>
     M: data:           "start": "2015-03-25T00:00:56+00:00",
     M: data:           "value": "192.0.2.2",
     M: data:           "value": 24         <value>42</value>
     M: data:         }       </row>
     M: data:      }       <row>
     M: data:    }         <start-time>2015-03-25T00:00:56+00:00</start-time>
     M: data: }         <value>192.0.2.1</value>
     M:         <value>42</value>
     M:       </row>
     M:     </task>
     M:   </report>
     M: </input>

     C: HTTP/1.1 200 OK

Authors' Addresses

   Juergen Schoenwaelder
   Jacobs University Bremen

   Email: j.schoenwaelder@jacobs-university.de

   Vaibhav Bajpai
   Jacobs University Bremen

   Email: v.bajpai@jacobs-university.de