idnits 2.17.1
draft-schoenw-lmap-restconf-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** There are 2 instances of too long lines in the document, the longest one
being 43 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 323 has weird spacing: '...chedule lea...'
== Line 325 has weird spacing: '... timing lea...'
-- The document date (March 26, 2015) is 3318 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-14) exists of
draft-ietf-lmap-framework-12
== Outdated reference: A later version (-18) exists of
draft-ietf-lmap-information-model-04
== Outdated reference: A later version (-17) exists of
draft-ietf-netconf-call-home-04
== Outdated reference: A later version (-18) exists of
draft-ietf-netconf-restconf-04
== Outdated reference: A later version (-09) exists of
draft-ietf-netconf-server-model-06
-- Obsolete informational reference (is this intentional?): RFC 7223
(Obsoleted by RFC 8343)
-- Obsolete informational reference (is this intentional?): RFC 7230
(Obsoleted by RFC 9110, RFC 9112)
-- Obsolete informational reference (is this intentional?): RFC 7277
(Obsoleted by RFC 8344)
Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Schoenwaelder
3 Internet-Draft V. Bajpai
4 Intended status: Standards Track Jacobs University Bremen
5 Expires: September 27, 2015 March 26, 2015
7 Using RESTCONF with LMAP Measurement Agents
8 draft-schoenw-lmap-restconf-00.txt
10 Abstract
12 This document describes how RESTCONF can be used with a YANG data
13 model for Large-Scale Measurement Platforms (LMAP).
15 Status of This Memo
17 This Internet-Draft is submitted in full conformance with the
18 provisions of BCP 78 and BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF). Note that other groups may also distribute
22 working documents as Internet-Drafts. The list of current Internet-
23 Drafts is at http://datatracker.ietf.org/drafts/current/.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 This Internet-Draft will expire on September 27, 2015.
32 Copyright Notice
34 Copyright (c) 2015 IETF Trust and the persons identified as the
35 document authors. All rights reserved.
37 This document is subject to BCP 78 and the IETF Trust's Legal
38 Provisions Relating to IETF Documents
39 (http://trustee.ietf.org/license-info) in effect on the date of
40 publication of this document. Please review these documents
41 carefully, as they describe your rights and restrictions with respect
42 to this document. Code Components extracted from this document must
43 include Simplified BSD License text as described in Section 4.e of
44 the Trust Legal Provisions and are provided without warranty as
45 described in the Simplified BSD License.
47 Table of Contents
49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
50 2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 2
51 3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3
52 4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 3
53 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
56 8. Informative References . . . . . . . . . . . . . . . . . . . 4
57 Appendix A. Response to Protocol Comparison Criteria . . . . . . 5
58 Appendix B. Example RESTCONF Control Protocol Exchange . . . . . 7
59 Appendix C. Example RESTCONF Report Protocol Exchange . . . . . 9
60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
62 1. Introduction
64 This document discusses how a controller can use the RESTCONF
65 protocol [I-D.ietf-netconf-restconf] to configure Large-Scale
66 Measurement of Broadband Performance (LMAP) measurement agents (MAs)
67 [I-D.ietf-lmap-framework]. It also discusses how RESTCONF can be
68 used to report measurement results to a collector.
70 MAs may be deployed as separate hardware devices or as functions
71 embedded in consumer electronic devices and home routers or as pure
72 software solutions that can be installed on off-the-shelf computing
73 equipment. Measurement agents receive instructions from a controller
74 about when and how to conduct what measurements (the measurement
75 schedule) and how and when to report measurement results to a data
76 collector (the report schedule). Further information about the
77 interaction between MAs and controllers and collectors can be found
78 in [I-D.ietf-lmap-framework].
80 The LMAP information model [I-D.ietf-lmap-information-model] defines
81 the information exchanged between a controller and an MA and the
82 information exchanged between an MA and a collector. An information
83 model is conceptual and protocol-independent. A concrete YANG
84 [RFC6020] data model derived from the conceptual information model is
85 defined in [I-D.schoenw-lmap-yang].
87 2. Overview of RESTCONF
89 The RESTCONF protocol [I-D.ietf-netconf-restconf] provides a REST-
90 like interface to access and manipulate a so-called unified YANG
91 datastore [RFC6020]. The basic idea behind RESTCONF is expose a YANG
92 datastores as a collection of Web resources that can be manipulated
93 using standard HTTP [RFC7230] DELETE, PATCH, POST, and PUT methods.
95 The resource hierarchy is derived from the nesting structure of the
96 YANG schema tree, leading to a so called data model driven REST API.
98 RESTCONF is essentially a convention how to use HTTP over TLS to
99 access a datastore that has a structure defined by a YANG data model.
100 The data is exchanged in XML encoding or JSON encoding.
102 The normal mode of operation is that the RESTCONF client initiates a
103 secure transport to the RESTCONF server. For devices located behind
104 a NAT, a so called 'call-home' mechanism has been defined
105 [I-D.ietf-netconf-call-home] that enables the RESTCONF server to
106 establish a secure transport to a RESTCONF client. Note that call
107 home only changes the TCP connection establishment, the TLS and HTTP
108 client/server roles do not change. The policy used to call home can
109 be configured through a configuration data model
110 [I-D.ietf-netconf-server-model]. This model provides mechanism to
111 configure a list of redundant endpoints and it provides control over
112 call-home policies (e.g, call-home frequency, idle-timers, keep-alive
113 timers).
115 3. RESTCONF as LMAP Control Protocol
117 It is straight-forward to user RESTCONF as a control protocol. The
118 YANG data model [I-D.schoenw-lmap-yang] derived from the underlying
119 information model [I-D.ietf-lmap-information-model] translates into a
120 collection of RESTCONF resources that can be manipulated at various
121 levels of granularity using DELETE, PATCH, POST, and PUT methods.
123 An example exchange showing a REST call to create a schedule object
124 is shown in Appendix B.
126 4. RESTCONF as LMAP Report Protocol
128 One way of mapping the information model parts relevant for reports
129 into a YANG data model is the usage of YANG notifications. This is
130 the approach currently used in [I-D.schoenw-lmap-yang]. This mapping
131 leads to report notifications that push measurement results from the
132 MA to a collector. The RESTCONF protocol uses Server Sent Events as
133 the underlying mechanism to stream notifications.
135 A direct mapping of the information model leads to relatively verbose
136 exchanges and it is possible to define more space efficient
137 notifications that suppress information that is only changing rarely.
139 An example exchange of a result notification is shown in Appendix C.
141 Note that alternative designs are possible. One option is to make
142 the collector a RESTCONF server and to have the MA push results to
143 the collector by posting to resources on the controller. Another
144 option is to have the results reside on the MA and to export the
145 results as part of the operational state of the MA. The collector(s)
146 will then use GET requests to fetch the result resources from the MA.
147 Note that all three approaches can be implemented using RESTCONF and
148 YANG.
150 5. Conclusion
152 This document discusses how RESTCONF can be used as a control
153 protocol and a report protocol for Large-Scale Measurement Platforms
154 (LMAP). The benefit of using RESTCONF is that no new protocol work
155 needs to be done. Additional benefits derive from using YANG and a
156 data model driven approach. Despite the reuse of existing tools,
157 using a data model driven approach allows to easily reuse other data
158 models (e.g., network interfaces [RFC7223], [RFC7277] or general
159 system services [RFC7317]) in order to export additional status
160 information about an MA to a controller.
162 6. IANA Considerations
164 This document has no requests for IANA.
166 7. Acknowledgements
168 Juergen Schoenwaelder and Vaibhav Bajpai work in part on the Leone
169 research project, which receives funding from the European Union
170 Seventh Framework Programme [FP7/2007-2013] under grant agreement
171 number 317647.
173 8. Informative References
175 [I-D.ietf-lmap-framework]
176 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
177 Aitken, P., and A. Akhter, "A framework for Large-Scale
178 Measurement of Broadband Performance (LMAP)", draft-ietf-
179 lmap-framework-12 (work in progress), March 2015.
181 [I-D.ietf-lmap-information-model]
182 Burbridge, T., Eardley, P., Bagnulo, M., and J.
183 Schoenwaelder, "Information Model for Large-Scale
184 Measurement Platforms (LMAP)", draft-ietf-lmap-
185 information-model-04 (work in progress), March 2015.
187 [I-D.ietf-netconf-call-home]
188 Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
189 draft-ietf-netconf-call-home-04 (work in progress),
190 February 2015.
192 [I-D.ietf-netconf-restconf]
193 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
194 Protocol", draft-ietf-netconf-restconf-04 (work in
195 progress), January 2015.
197 [I-D.ietf-netconf-server-model]
198 Watsen, K. and J. Schoenwaelder, "NETCONF Server and
199 RESTCONF Server Configuration Models", draft-ietf-netconf-
200 server-model-06 (work in progress), February 2015.
202 [I-D.schoenw-lmap-yang]
203 Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
204 LMAP Measurement Agents", draft-schoenw-lmap-yang-02 (work
205 in progress), January 2015.
207 [I-D.starkcarey-lmap-protocol-criteria]
208 Stark, B. and T. Carey, "LMAP Protocol Selection
209 Criteria", draft-starkcarey-lmap-protocol-criteria-01
210 (work in progress), March 2015.
212 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
213 Network Configuration Protocol (NETCONF)", RFC 6020,
214 October 2010.
216 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
217 Management", RFC 7223, May 2014.
219 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
220 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
221 2014.
223 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
224 7277, June 2014.
226 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
227 System Management", RFC 7317, August 2014.
229 Appendix A. Response to Protocol Comparison Criteria
231 A set of control and report protocol comparison criteria has been
232 defined in [I-D.starkcarey-lmap-protocol-criteria]. This section
233 compares the usage of RESTCONF against the criteria.
235 CP-MUST-1 yes (RFC6241 RFC6242, RFC5539),
236 [I-D.ietf-netconf-restconf]
238 CP-MUST-2 yes [I-D.ietf-netconf-call-home]
239 CP-MUST-3 yes SSH / TLS (NETCONF), TLS (RESTCONF)
241 CP-MUST-4 yes YANG data models [RFC6020] have a well defined
242 versioning and extension model
244 CP-DIFF-1 1
246 CP-DIFF-2 1
248 CP-DIFF-3 yes
250 CP-DIFF-4 yes (NETCONF|RESTCONF) call home
252 CP-DIFF-5 (underspecified - it is JSON or XML over HTTP/TLS)
254 CP-DIFF-6 (underspecified - it is JSON or XML over HTTP/TLS)
256 CP-DIFF-7 HTTP and JSON/XML are pretty much everywhere
258 CP-DIFF-8 YANG tools are out there and the rest will develop, HTTP
259 and TLS are pretty well understood
261 CP-DIFF-9 yes
263 CP-DIFF-10 many tools out there to create REST code, YANG tools
264 available
266 CP-DIFF-11 yes, YANG RFC 6020 data models have a version model
268 CP-DIFF-12 additional YANG modules can augment the standard data
269 model
271 CP-DIFF-13 JSON and XML, CBOR in the making
273 RP-MUST-1 yes [I-D.ietf-netconf-call-home]
275 RP-MUST-2 SSH / TLS (NETCONF), TLS (RESTCONF)
277 RP-MUST-3 YANG RFC 6020 data models have a version model
279 RP-DIFF-1 TCP
281 RP-DIFF-2 yes
283 RP-DIFF-3 (underspecified - it is HTTP over TLS)
285 RP-DIFF-4 yes
286 RP-DIFF-5 yes
288 RP-DIFF-6 yes (as part of HTTP encoding negotiations)
290 RP-DIFF-7 (underspecified - it is JSON or XML over HTTP/TLS)
292 RP-DIFF-8 HTTP and JSON/XML are pretty much everywhere
294 RP-DIFF-9 many tools out there to create REST code, YANG tools
295 available
297 RP-DIFF-10 yes
299 RP-DIFF-11 many tools out there to create REST code, YANG tools
300 available
302 RP-DIFF-12 JSON and XML, CBOR in the making
304 Appendix B. Example RESTCONF Control Protocol Exchange
306 Below is a YANG tree diagram of a part of the data model covering
307 schedules. This is taken from [I-D.schoenw-lmap-yang].
309 module: ietf-lmap
310 +--rw lmap
311 +--rw schedules
312 +--rw schedule* [name]
313 +--rw name string
314 +--rw action* [name]
315 | +--rw name string
316 | +--rw task leafref
317 | +--rw option* [name]
318 | | +--rw name string
319 | | +--rw value? string
320 | +--rw destination* [name]
321 | +--rw name string
322 | +--rw output* uint16
323 | +--rw schedule leafref
324 | +--rw action leafref
325 +--rw timing leafref
327 Below is an XML representation of instance data conforming to the
328 YANG data model is shown below. Note that some of the strings are
329 references to other portions of the instance data not show here.
330 This is again taken from [I-D.schoenw-lmap-yang].
332
333
334
335 hourly
336
337 icmp-latency-hourly
338 icmp-latency-measurement
339
340 q-all
341 daily
342 report-daily
343
344
345 hourly
346
347
348
350 Below is an example showing how RESTCONF can be used to create the
351 above schedule. The prefix C: indicates the controller, the prefix
352 M: indicates the measurement agent. This example uses a JSON
353 encoding (and note that much of the white-space can be removed, this
354 is only there to help with readability).
356 C: POST /restconf/data/ietf-lmap:lmap/schedules HTTP/1.1
357 C: Host: example.com
358 C: Content-Type: application/yang.data+json
359 C:
360 C: {
361 C: "ietf-lmap:schedule": {
362 C: "name": "hourly",
363 C: "action": [
364 C: {
365 C: "name": "icmp-latency-hourly",
366 C: "task": "icmp-latency-measurement",
367 C: "destination": [
368 C: {
369 C: "name": "q-all",
370 C: "schedule": "daily",
371 C: "action": "report-daily"
372 C: }
373 C: ]
374 C: }
375 C: ],
376 C: "timing": "hourly"
377 C: }
378 C: }
380 M: HTTP/1.1 201 Created
381 M: Date: Mon, 23 Apr 2012 17:01:00 GMT
382 M: Server: example-server
383 M: Location: https://example.com/restconf/data/ietf-lmap:lmap/schedules/schedule=hourly
384 M: Last-Modified: Mon, 23 Apr 2012 17:01:00 GMT
385 M: ETag: b3a3e673be2
387 Appendix C. Example RESTCONF Report Protocol Exchange
389 The first step taken by the collector is to lookup the event stream
390 resource.
392 C: GET /restconf/data/ietf-restconf-monitoring:restconf-state/streams/stream=NETCONF/encoding=xml/events HTTP/1.1
393 C: Host: example.com
394 C: Accept: application/yang.data+xml
396 M: HTTP/1.1 200 OK
397 M: Content-Type: application/yang.api+xml
398 M:
399 M:
401 M: https://example.com/streams/NETCONF
402 M:
404 Once the event stream resource is known (information might be
405 cached), the collector subscribes to the event stream resource.
407 C: GET /streams/NETCONF HTTP/1.1
408 C: Host: example.com
409 C: Accept: text/event-stream
410 C: Cache-Control: no-cache
411 C: Connection: keep-alive
413 M: data:
415 M: data: 2013-12-21T00:01:00Z
416 M: data:
417 M: data:
418 M: data:
420 M: data: {
421 M: data: "ietf-restconf:notification": {
422 M: data: "event-time": "2015-02-25T00:01:00Z",
423 M: data: "ietf-lmap:report": {
424 M: data: "date": "2015-02-25T00:01:00Z",
425 M: data: "agent-id": "xxx",
426 M: data: "header": {
427 M: data: "column": "target",
428 M: data: "column": "rtt"
429 M: data: }
430 M: data: "row": {
431 M: data: "start": "2015-02-25T00:01:00Z",
432 M: data: "value": "192.0.2.1",
433 M: data: "value": 42
434 M: data: }
435 M: data: "row": {
436 M: data: "start": "2015-02-25T00:01:00Z",
437 M: data: "value": "192.0.2.2",
438 M: data: "value": 24
439 M: data: }
440 M: data: }
441 M: data: }
442 M: data: }
444 Authors' Addresses
446 Juergen Schoenwaelder
447 Jacobs University Bremen
449 Email: j.schoenwaelder@jacobs-university.de
450 Vaibhav Bajpai
451 Jacobs University Bremen
453 Email: v.bajpai@jacobs-university.de