Network Working Group                                   J. Schoenwaelder
Internet-Draft                                                 V. Bajpai                                  Jacobs University Bremen
Intended status: Standards Track                Jacobs University Bremen                               V. Bajpai
Expires: January 9, December 4, 2017                    Technical University Munich
                                                            June 2, 2017                                    July 8, 2016

              Using RESTCONF with LMAP Measurement Agents
                    draft-ietf-lmap-restconf-03.txt
                    draft-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 on January 9, December 4, 2017.

Copyright Notice

   Copyright (c) 2016 2017 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  . . . . . . . . . . . . . . . . . . . .   3
   3.  RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . .   3
   4.  RESTCONF as LMAP Report Protocol  . . . . . . . . . . . . . .   3   5
   5.  RESTCONF Configuration for LMAP . . . . . . . . . . . . . . .   4   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   4   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   4   7
   Appendix A.  Example RESTCONF Control Protocol Exchange . . . . .   5   8
   Appendix B.  Example RESTCONF Report Protocol Exchange  . . . . .   7   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9  11

1.  Introduction

   This document discusses how a Controller can use the RESTCONF
   protocol [I-D.ietf-netconf-restconf] to configure

   The 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 also 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 by 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 report measurement results to a 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 conduct what measurements (the
   measurement schedule)
   Measurement Schedule) and how and when to report measurement results
   to a data Collector (the report 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 and an a Measurement Agent and as well as the
   information exchanged between an a 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.  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] [RFC8040] provides a REST-
   like interface to access and manipulate a so-called unified an HTTP-based protocol for
   accessing data defined in YANG
   datastore [RFC6020]. [RFC7950].  The basic idea behind
   RESTCONF is to expose a YANG
   datastores YANG-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-called data model driven REST API. data-model-driven application
   programming interface (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. resources representing YANG-defined data.  The data is exchanged in resources 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
   a NAT, 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 to
   establish initiate a secure transport
   to a RESTCONF client.  Note that call
   home 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 control 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 over
   call-home policies Call Home parameters (e.g, call-home frequency, frequency of Call Home
   attempts, idle-timers, keep-alive timers).

3.  RESTCONF as LMAP Control Protocol

   It is straight-forward

   The LMAP Control Protocol delivers Instruction(s) from a Controller
   to use a 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 control protocol. 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] [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 showing a REST call to create 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

   For reporting results

   The LMAP Report Protocol delivers Report(s) from the a Measurement Agent
   to a Collector, 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 is assumed established and how reports are delivered to act 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 a 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 server.  The as Report Protocol

   Note that the Measurement Agent pushes results to the Collector by invoking an operation on 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
   Controller.
   final YANG model and use JSON encoding.]]

5.  RESTCONF Configuration for LMAP

   XXX:

   [[CREF3: This section should could explain how an LMAP implementation needs
   to be configured to make use of the call-home Call Home mechanism and how
   report tasks refer to the configuration (if any standardized) needed
   to obtain the necessary credentials to report results.  This needs  Is this
   necessary are can we simply refer to be
   worked through in detail. the I-Ds that have the details?
   Note that these I-Ds are not stable yet.]]

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

   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-04 draft-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., and J.
              Schoenwaelder, "Information Model A. Akhter, "A Framework for Large-Scale
              Measurement Platforms of 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 and
              RESTCONF
              Server Configuration Models", draft-ietf-netconf-
              server-model-09 draft-ietf-netconf-restconf-client-
              server-01 (work in progress), March November 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
              Measurement Ed., "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 of Broadband Performance (LMAP)", Data Modeled with YANG", RFC 7594,
              7951, DOI 10.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 Bajpai
   Jacobs
   Technical University Bremen Munich

   Email: v.bajpai@jacobs-university.de bajpaiv@in.tum.de