idnits 2.17.1 draft-ietf-lmap-restconf-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 342 has weird spacing: '...on-mode enum...' -- The document date (June 2, 2017) is 2518 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 (-18) exists of draft-ietf-lmap-information-model-16 == Outdated reference: A later version (-12) exists of draft-ietf-lmap-yang-10 ** Downref: Normative reference to an Informational RFC: RFC 7594 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-restconf-client-server-01 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Standards Track V. Bajpai 5 Expires: December 4, 2017 Technical University Munich 6 June 2, 2017 8 Using RESTCONF with LMAP Measurement Agents 9 draft-ietf-lmap-restconf-04.txt 11 Abstract 13 This document describes how RESTCONF can be used with a YANG data 14 model for Large-Scale Measurement Platforms (LMAP). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 4, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Overview of RESTCONF . . . . . . . . . . . . . . . . . . . . 3 52 3. RESTCONF as LMAP Control Protocol . . . . . . . . . . . . . . 3 53 4. RESTCONF as LMAP Report Protocol . . . . . . . . . . . . . . 5 54 5. RESTCONF Configuration for LMAP . . . . . . . . . . . . . . . 6 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 9.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Appendix A. Example RESTCONF Control Protocol Exchange . . . . . 8 62 Appendix B. Example RESTCONF Report Protocol Exchange . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 The Framework for Large-Scale Measurement of Broadband Performance 68 (LMAP) [RFC7594] describes an overall framework for large-scale 69 broadband performance measurement systems. The standardization work 70 in the IETF is restricted to the interaction between Measurement 71 Agents and their Controllers and between Measurement Agents and 72 result Collectors (see Figure 1 in [RFC7594]). 74 The protocol selection process within the LMAP working group of the 75 IETF gave preference to a solution that reuses existing IETF 76 protocols rather than inventing new ones. In addition, there was a 77 preference to use a protocol that is layered on top of HTTP since 78 this allows to reuse implementations already widely available. 80 This document discusses how the RESTCONF protocol [RFC8040] can be 81 used to facilitate the communication between components implementing 82 the LMAP framework. In particular, this document discusses how 83 RESTCONF can be used as a Control Protocol to deliver Instruction(s) 84 from a Controller to a Measurement Agent, and as a Report Protocol 85 delivering Report(s) from a Measurement Agent to a Collector. 87 Measurement Agents may be deployed as separate hardware devices or as 88 functions embedded in consumer electronic devices and home routers or 89 as pure software solutions that can be installed on off-the-shelf 90 computing equipment. Measurement Agents receive instructions from a 91 Controller about when and how to conduct measurements (the 92 Measurement Schedule) and how and when to report measurement results 93 to a data Collector (the Report Schedule). Further information about 94 the interaction between Measurement Agents and Controllers and 95 Collectors can be found in [RFC7594]. 97 The LMAP information model [I-D.ietf-lmap-information-model] defines 98 in a conceptual and protocol-independent way the information 99 exchanged between a Controller and a Measurement Agent as well as the 100 information exchanged between a Measurement Agent and a Collector. A 101 concrete YANG [RFC7950] data model derived from the conceptual 102 information model is defined in [I-D.ietf-lmap-yang]. 104 This document uses the LMAP terminology defined in [RFC7594]. 106 2. Overview of RESTCONF 108 The RESTCONF protocol [RFC8040] provides an HTTP-based protocol for 109 accessing data defined in YANG [RFC7950]. The basic idea behind 110 RESTCONF is to expose YANG-defined data as a collection of Web 111 resources that can be accessed and manipulated using standard HTTP 112 [RFC7230] GET, DELETE, PATCH, POST, and PUT methods. The resource 113 hierarchy is derived from the nesting structure of the YANG schema 114 tree, leading to a so-called data-model-driven application 115 programming interface (API). 117 RESTCONF is essentially a convention how to use HTTP over TLS to 118 access a resources representing YANG-defined data. The resources are 119 represented using either XML encoding (according to [RFC7950]) or 120 JSON encoding (according to [RFC7951]). The examples shown in this 121 document use the JSON encoding. 123 The normal mode of operation is that the RESTCONF client initiates a 124 secure transport to the RESTCONF server. For devices located behind 125 a middlebox (e.g., a network address translator or a firewall), a so 126 called Call Home mechanism has been defined [RFC8071]. The Call Home 127 mechanism allows the RESTCONF server to initiate a secure transport 128 to a RESTCONF client. Note that Call Home only changes the TCP 129 connection establishment, the TLS and HTTP client/server roles do not 130 change. The policy used to control the Call Home mechanism can be 131 configured through a configuration data model 132 [I-D.ietf-netconf-restconf-client-server]. This model provides a 133 mechanism to configure a list of redundant endpoints and it provides 134 control over Call Home parameters (e.g, frequency of Call Home 135 attempts, idle-timers, keep-alive timers). 137 3. RESTCONF as LMAP Control Protocol 139 The LMAP Control Protocol delivers Instruction(s) from a Controller 140 to a Measurement Agent. The LMAP Control Protocol is realized by 141 running a RESTCONF server on the Measurement Agent and a RESTCONF 142 client on the Controller. Figure 1 depicts how the connection and 143 the secure transport is established when the Measurement Agent is 144 directly reachable from the Controller, i.e., the Measurement Agent 145 has a well-known name or address and is directly reachable from the 146 Controller. 148 Measurement Agent Controller 149 (RESTCONF Server) (RESTCONF Client) 150 [TCP port 443] 151 | | 152 | TCP Connect | 153 |<---------------------------| 154 | TLS Exchange | 155 |<-------------------------->| 156 | | 157 | HTTP GET / POST / ... | 158 |<---------------------------| 159 |--------------------------->| 160 : : 161 : : 163 Figure 1: RESTCONF as Control protocol (without Call Home) 165 In several deployment scenarios, it will not be possible for the 166 Controller to initiate a connection to the Measurement Agent due to 167 the presence of middleboxes such as network address translators and 168 firewalls. In such a situation, the Measurement Agent running a 169 RESTCONF server will Call Home to the Controller running a RESTCONF 170 client as shown in Figure 2. 172 Measurement Agent Controller 173 (RESTCONF Server) (RESTCONF Client) 174 [TCP port 4336] 175 | | 176 | TCP Connect | 177 |--------------------------->| 178 | TLS Exchange | 179 |<-------------------------->| 180 | | 181 | HTTP GET / POST / ... | 182 |<---------------------------| 183 |--------------------------->| 184 : : 185 : : 187 Figure 2: RESTCONF as Control Protocol (with Call Home) 189 Note that the Call Home mechanism only 'reverses' the way the 190 underlying TCP connection is established. The subsequent TLS 191 exchange has the TLS server role on the RESTCONF server side and the 192 TLS client role on the RESTCONF client side. 194 The YANG data model [I-D.ietf-lmap-yang], derived from the underlying 195 information model [I-D.ietf-lmap-information-model], translates into 196 a collection of RESTCONF resources that can be accessed and 197 manipulated at various levels of granularity using HTTP GET, DELETE, 198 PATCH, POST, and PUT methods. 200 An example exchange showing how a schedule object is installed on a 201 Measurement Agent is shown in Appendix A. 203 [[CREF1: Move the example inline, update it to be aligned to the 204 final YANG model and use JSON encoding.]] 206 4. RESTCONF as LMAP Report Protocol 208 The LMAP Report Protocol delivers Report(s) from a Measurement Agent 209 to a Collector. The LMAP Report Protocol is realized by running a 210 RESTCONF server on the Collector and a RESTCONF client on the 211 Measurement Agent. Figure 3 depicts how the connection and the 212 secure transport is established and how reports are delivered to the 213 Controller. Note that it is generally assumed that the Controller is 214 directly reachable from the Measurement Agent. (In situations where 215 this may not be true, RESTCONF Call Home can be used as well but this 216 is not shown here.) 218 Measurement Agent Collector 219 (RESTCONF Client) (RESTCONF Server) 220 [TCP port 443] 221 | | 222 | TCP Connect | 223 |--------------------------->| 224 | TLS Exchange | 225 |<-------------------------->| 226 | | 227 | HTTP POST | 228 |--------------------------->| 229 |<---------------------------| 230 : : 231 : : 233 Figure 3: RESTCONF as Report Protocol 235 Note that the Measurement Agent pushes results to the Collector by 236 invoking an operation on the Controller. This maps to an HTTP POST 237 in RESTCONF. Hence, pushing results can effectively be done by 238 posting a the result to a specific RESTCONF resource. 240 An example exchange showing how results are reported to a Controller 241 is shown in Appendix B. 243 [[CREF2: Move the example inline, update it to be aligned to the 244 final YANG model and use JSON encoding.]] 246 5. RESTCONF Configuration for LMAP 248 [[CREF3: This section could explain how an LMAP implementation needs 249 to be configured to make use of the Call Home mechanism and how 250 report tasks refer to the configuration (if any standardized) needed 251 to obtain the necessary credentials to report results. Is this 252 necessary are can we simply refer to the I-Ds that have the details? 253 Note that these I-Ds are not stable yet.]] 255 6. Security Considerations 257 Security and privacy aspects of the LMAP framework are discussed in 258 Sections 7 and 8 of [RFC7594]. Section 12 of [RFC8040] and Section 5 259 of [RFC8071] discuss the security aspects of RESTCONF and the 260 RESTCONF Call Home mechanism. 262 The security considerations specific to the LMAP information model 263 and the YANG data model can be found in Section 6 of 264 [I-D.ietf-lmap-information-model] and Section 5 of 265 [I-D.ietf-lmap-yang]. 267 7. IANA Considerations 269 This document has no requests for IANA. 271 8. Acknowledgements 273 Juergen Schoenwaelder and Vaibhav Bajpai worked in part on the Leone 274 research project, which received funding from the European Union 275 Seventh Framework Programme [FP7/2007-2013] under grant agreement 276 number 317647. 278 Juergen Schoenwaelder and Vaibhav Bajpai were partly funded by 279 Flamingo, a Network of Excellence project (ICT-318488) supported by 280 the European Commission under its Seventh Framework Programme. 282 9. References 284 9.1. Normative References 286 [I-D.ietf-lmap-information-model] 287 Burbridge, T., Eardley, P., Bagnulo, M., and J. 288 Schoenwaelder, "Information Model for Large-Scale 289 Measurement Platforms (LMAP)", draft-ietf-lmap- 290 information-model-16 (work in progress), January 2017. 292 [I-D.ietf-lmap-yang] 293 Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 294 LMAP Measurement Agents", draft-ietf-lmap-yang-10 (work in 295 progress), January 2017. 297 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 298 Aitken, P., and A. Akhter, "A Framework for Large-Scale 299 Measurement of Broadband Performance (LMAP)", RFC 7594, 300 DOI 10.17487/RFC7594, September 2015, 301 . 303 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 304 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 305 . 307 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 308 RFC 8071, DOI 10.17487/RFC8071, February 2017, 309 . 311 9.2. Informative References 313 [I-D.ietf-netconf-restconf-client-server] 314 Watsen, K. and J. Schoenwaelder, "RESTCONF Client and 315 Server Models", draft-ietf-netconf-restconf-client- 316 server-01 (work in progress), November 2016. 318 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 319 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 320 7230, DOI 10.17487/RFC7230, June 2014, 321 . 323 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 324 RFC 7950, DOI 10.17487/RFC7950, August 2016, 325 . 327 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 328 7951, DOI 10.17487/RFC7951, August 2016, 329 . 331 Appendix A. Example RESTCONF Control Protocol Exchange 333 Below is a YANG tree diagram of a part of the data model covering 334 schedules. This is taken from [I-D.ietf-lmap-yang]. 336 module: ietf-lmap-control 337 +--rw lmap 338 +--rw schedules 339 +--rw schedule* [name] 340 +--rw name lmap:identifier 341 +--rw event event-ref 342 +--rw execution-mode enumeration 343 +--rw action* [name] 344 +--rw name string 345 +--rw task task-ref 346 +--rw option* [name] 347 | +--rw id lmap:identifier 348 | +--rw name? string 349 | +--rw value? string 350 +--rw destination* leafref 352 Below is an XML representation of instance data conforming to the 353 YANG data model is shown below. Note that some of the strings are 354 references to other portions of the instance data not show here. 355 This is again taken from [I-D.ietf-lmap-yang]. 357 358 359 360 hourly-schedule 361 hourly 362 sequential 363 364 icmp-latency-hourly 365 icmp-latency-measurement 366 daily 367 368 369 370 372 Below is an example showing how RESTCONF can be used to create the 373 above schedule. The prefix C: indicates the Controller, the prefix 374 M: indicates the Measurement Agent. This example uses a JSON 375 encoding (and note that much of the white-space can be removed, this 376 is only there to help with readability). 378 C: POST /restconf/data/ietf-lmap-control:lmap/schedules HTTP/1.1 379 C: Host: example.com 380 C: Content-Type: application/yang.data+json 381 C: 382 C: { 383 C: "ietf-lmap-control:schedule": { 384 C: "name": "hourly-schedule", 385 C: "event": "hourly", 386 C: "execution-mode": "sequential", 387 C: "action": [ 388 C: { 389 C: "name": "icmp-latency-hourly", 390 C: "task": "icmp-latency-measurement", 391 C: "destination": "daily", 392 C: } 393 C: ] 394 C: } 395 C: } 397 M: HTTP/1.1 201 Created 398 M: Date: Mon, 26 Mar 2015 17:01:00 GMT 399 M: Server: example-server 400 M: Location: https://example.com/restconf/data 401 M: /ietf-lmap-control:lmap/schedules/schedule=hourly-schedule 402 M: Last-Modified: Mon, 26 Mar 2015 17:01:00 GMT 403 M: ETag: b3a3e673be2 405 Appendix B. Example RESTCONF Report Protocol Exchange 407 Below is an example showing how a Measurement Agent can submit 408 results to a Collector running an RESTCONF server. The prefix C: 409 indicates the Collector, the prefix M: indicates the Measurement 410 Agent. 412 M: POST /restconf/operations/ietf-lmap-report:report HTTP/1.1 413 M: Host: example.com 414 M: Content-Type: application/yang.operation+xml 415 M: 416 M: 417 M: 2015-10-28T13:27:42+02:00 418 M: 550e8400-e29b-41d4-a716-446655440000 419 M: wireless measurement at the north-pole 420 M: 421 M: pinger 422 M: fping 423 M: fping 424 M: 428 M: 432 M: 437 M: 441 M: 445 M: 449 M: 2016-03-21T10:48:55+01:00 450 M: 2016-03-21T10:48:57+01:00 451 M: 0 452 M: 453 M: target 454 M: ip 455 M: rtt-1 456 M: rtt-2 457 M: rtt-3 458 M: rtt-4 459 M: rtt-5 460 M: 461 M: www.example.org 462 M: 2001:db8::1 463 M: 14.15 464 M: 14.14 465 M: 14.09 466 M: 14.17 467 M: 14.51 468 M: 469 M: 470 M: mail.example.org 471 M: 2001:db8::2 472 M: 12.24 473 M: 11.99 474 M: 12.49 475 M: 11.87 476 M: 12.45 477 M: 478 M:
479 M: 480 M: 482 C: HTTP/1.1 200 OK 484 Authors' Addresses 486 Juergen Schoenwaelder 487 Jacobs University Bremen 489 Email: j.schoenwaelder@jacobs-university.de 491 Vaibhav Bajpai 492 Technical University Munich 494 Email: bajpaiv@in.tum.de