Internet DRAFT - draft-ietf-lmap-restconf
draft-ietf-lmap-restconf
Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Bremen
Intended status: Standards Track V. Bajpai
Expires: December 4, 2017 Technical University Munich
June 2, 2017
Using RESTCONF with LMAP Measurement Agents
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 December 4, 2017.
Copyright Notice
Copyright (c) 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.
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 1]
Internet-Draft LMAP using RESTCONF June 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3
3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3
4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 5
5. RESTCONF Configuration for LMAP . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Example RESTCONF Control Protocol Exchange . . . . . 8
Appendix B. Example RESTCONF Report Protocol Exchange . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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 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
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 measurements (the
Measurement Schedule) and how and when to report measurement results
to a data Collector (the Report Schedule). Further information about
the interaction between Measurement Agents and Controllers and
Collectors can be found in [RFC7594].
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 2]
Internet-Draft LMAP using RESTCONF June 2017
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 a Measurement Agent as well as the
information exchanged between a Measurement Agent and a Collector. A
concrete YANG [RFC7950] data model derived from the conceptual
information model is defined in [I-D.ietf-lmap-yang].
This document uses the LMAP terminology defined in [RFC7594].
2. Overview of RESTCONF
The RESTCONF protocol [RFC8040] provides an HTTP-based protocol for
accessing data defined in YANG [RFC7950]. The basic idea behind
RESTCONF is to expose 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 application
programming interface (API).
RESTCONF is essentially a convention how to use HTTP over TLS to
access a resources representing YANG-defined data. The 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 middlebox (e.g., a network address translator or a firewall), a so
called Call Home mechanism has been defined [RFC8071]. The Call Home
mechanism allows the RESTCONF server to initiate 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 control the Call Home mechanism can be
configured through a configuration data 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 parameters (e.g, frequency of Call Home
attempts, idle-timers, keep-alive timers).
3. RESTCONF as LMAP Control Protocol
The LMAP Control Protocol delivers Instruction(s) from a Controller
to 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
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 3]
Internet-Draft LMAP using RESTCONF June 2017
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 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
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 4]
Internet-Draft LMAP using RESTCONF June 2017
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
The LMAP Report Protocol delivers Report(s) from a Measurement Agent
to a 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 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
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 5]
Internet-Draft LMAP using RESTCONF June 2017
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
[[CREF3: This section could explain how an LMAP implementation needs
to be configured to make use of the Call Home mechanism and how
report tasks refer to the configuration (if any standardized) needed
to obtain the necessary credentials to report results. Is this
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
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.
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 6]
Internet-Draft LMAP using RESTCONF June 2017
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-10 (work in
progress), January 2017.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", 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",
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, "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
Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7950] Bjorklund, M., 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 Data Modeled with YANG", RFC
7951, DOI 10.17487/RFC7951, August 2016,
<http://www.rfc-editor.org/info/rfc7951>.
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 7]
Internet-Draft LMAP using RESTCONF June 2017
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).
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 8]
Internet-Draft LMAP using RESTCONF June 2017
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>
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 9]
Internet-Draft LMAP using RESTCONF June 2017
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>
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 10]
Internet-Draft LMAP using RESTCONF June 2017
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
Technical University Munich
Email: bajpaiv@in.tum.de
Schoenwaelder & Bajpai Expires December 4, 2017 [Page 11]