idnits 2.17.1 draft-rfmesh-anima-iot-management-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 26, 2018) is 2032 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) == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-sid' is defined on line 407, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 7575 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-07 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-03 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-04 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-07 == Outdated reference: A later version (-05) exists of draft-veillette-core-yang-library-03 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu, Ed. 3 Internet-Draft Y. Wu 4 Intended status: Standards Track Huawei Technologies 5 Expires: March 30, 2019 September 26, 2018 7 ANI Applied in IoT Network Management 8 draft-rfmesh-anima-iot-management-01 10 Abstract 12 This document describes an IoT scenario where ACP and GRASP is 13 suitable to act as a network management channel and a lightweight and 14 extensible network management protocol. Relevent GRASP extention and 15 options are also specified to fulfill the requirements of the 16 scenario. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 30, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Scenario Description . . . . . . . . . . . . . . . . . . . . 4 55 4. Why Choose GRASP as Management Protocol . . . . . . . . . . . 4 56 4.1. Candidate Technologies . . . . . . . . . . . . . . . . . 4 57 4.1.1. IETF Core . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1.2. OMA LWM2M . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Suitability of GRASP . . . . . . . . . . . . . . . . . . 5 60 5. GRASP Extention . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. GRASP over UDP . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. Reliable Transport . . . . . . . . . . . . . . . . . . . 6 63 5.3. Fragmentation Handling . . . . . . . . . . . . . . . . . 6 64 6. IoT Management Options Definition . . . . . . . . . . . . . . 6 65 6.1. IoT Management Signallings . . . . . . . . . . . . . . . 6 66 6.2. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Lightweight ACP . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 11.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 When Anima ANI [I-D.ietf-anima-reference-model] was designed, IoT 79 scenarios were under consideration. For example, one big reason of 80 introducing CBOR encoding [RFC7049] in GRASP [I-D.ietf-anima-grasp] 81 and choosing CoAP [RFC7252] for secure bootstrapping 82 [I-D.ietf-anima-grasp] is for the effiecency of transporting packets 83 over lossy IoT networks. 85 This document discusses applying GRASP and ACP into a specific IoT 86 scenario for some network management functions. The characterstics 87 of the scenario is: 89 o Low-power wireless field area network dedicated for industrial 90 usage (e.g. 6LoWPAN-based electronic metering network). 92 o The topology is mesh. It is natrual for a wireless local network. 94 o IPv6 addressing, which is beneficial for auto-configuration 96 o L3 routing is enabled (e.g. RPL). 98 o Nodes are extremelly resource constraind. (E.g., one typical 99 hardware model only has 128Kbytes RAM and 512Kbytes ROM. ) 101 o Gateway is normally a resource rich device, which acts as a 102 management server to the nodes. 104 o Normally nodes don't need to communicate with any other entities 105 beyond the gateway. 107 However, some of the ANI designs are not specifically optimized for 108 IoT scenarios: 110 o Most of the GRASP messages (except M_Discovery and M_Flood) are 111 over TCP, which is considered as a heavy burden on radio resources 112 for many IoT LLNs. 114 o Since GRASP is based on TCP, it lacks reliable transport and 115 fragmentation mechanisms by itself. 117 o VRF-based ACP is not applicapable for most of the small IoT 118 devices. 120 This document discusses choosing GRASP as the management protocol 121 over the other two candicates, which are IETF Core technologies and 122 OMA LWM2M technologies. And also discusses a potential lightweight 123 ACP. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119] when they appear in ALL CAPS. When these words are not in 131 ALL CAPS (such as "should" or "Should"), they have their usual 132 English meanings, and are not to be interpreted as [RFC2119]key 133 words. 135 This document use the key words defined in [RFC7575] . 137 The following additional terms are used throughout this document: 139 o 141 o IoT: Internet of Things 143 o BR: Bord Router 145 o CMD: Command 146 o ACK: Acknowledgement 148 o PLC: Power Line Communication 150 o LLN: Low-Power and Lossy Network 152 o RF: Radio Frequency 154 o TCP: Transport Controll Protocol 156 o RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 157 [RFC6550] . 159 3. Scenario Description 161 /--\ 162 | | /--\ 163 /--\ \--/ | | 164 | | \--/ 165 \--/ /--\ 166 /--\ 167 +--------+ | | \--/ 168 | | \--/ 169 |Border | /--\ /--\ 170 |Router | | | IoT Nodes | | 171 |(Gatewa | /--\ \--/ \--/ 172 |y) | | | /--\ /--\ 173 +--------+ \--/ | | | | 174 \--/ \--/ 175 /--\ 176 /--\ | | 177 | | \--/ 178 \--/ 180 Fig 1. Reference Scenario for Wireless Field Area IoT Networks 182 As Fig 1 depicted, the BR is the root of the wireless network and act 183 as a management server. Each node connects to the BR. 185 4. Why Choose GRASP as Management Protocol 187 4.1. Candidate Technologies 189 4.1.1. IETF Core 191 Some IoT network management standardization work has been initialed 192 in the IETF Core working group. [I-D.ietf-core-comi] describes a 193 network management interface for constrained devices and networks, 194 called CoAP Management Interface (CoMI), which is used to access data 195 resources specified in YANG, or SMIv2 converted to YANG; relevant 196 YANG library for CoMI server [I-D.veillette-core-yang-library] and 197 CBOR encoding of data modeled with YANG [I-D.ietf-core-yang-cbor] are 198 also defined. In a nutshell, these work items can be considered as 199 some adaption and optimization of Netconf/YANG technologies for IoT 200 environment. 202 Netconf/YANG mechanisms are capabal of manuplating data orgnized in a 203 sophisticated tree structure. These capabilities are necessary and 204 poweful in managing various device configurations, especially for the 205 sophisticated devices such as router. However, they might be too 206 heavy for an extremly resource constrained device as discribed above. 207 There is neither enough space for storing the programs in ROM, nor 208 running the codes in RAM. 210 4.1.2. OMA LWM2M 212 OMA had issued the LWM2M specification, which is also designed for 213 IoT network management. LWM2M also chooses CoAP as the management 214 protocol, but it doesn't choose YANG for data model, rather, it 215 defined some OMA Objects. 217 OMA objects less complete than YANG modeled data; the objects are 218 flat rather than being orgnized as a tree structure. But OMA objects 219 contain also some advanced features such as access control of each 220 object. Plus the CoAP implementation, the LWM2M solution is still 221 not ideal for the targeted scenarios in terms of ROM/RAM ocuppation. 223 4.2. Suitability of GRASP 225 According to Section 6.1 , most of the IoT commands are more like 226 "Signallings" rather than traditional "Configurations". It is 227 reasonable because the IoT nodes need to auto-configure themselves as 228 much as possible to gain maximum effiecency. Relying on a 229 centralized server configuring each node is a big challenge to the 230 lossy wireless links and might probably cause significant delay of 231 deployment. 233 Thus, we might need a different approach to consider IoT management 234 than just simply re-using Netconf/YANG in a different context (e.g. 235 CoAP). 237 5. GRASP Extention 239 This section discusses potential GRASP extention to fulfill the IoT 240 management requirements. 242 5.1. GRASP over UDP 244 Since TCP requires three times handshake, which would consume too 245 much radio resource, thus it is not acceptable in LLNs. Then UDP is 246 needed. 248 5.2. Reliable Transport 250 For some critical messages, the sender would need to confirm the 251 receiver had got the message, thus, there needs to be a reliable 252 transport mechanism extended in application layer (GRASP). 254 5.3. Fragmentation Handling 256 Since the lack of TCP, GRASP also needs to be enhanced with some a 257 fragmentation mechanism. 259 6. IoT Management Options Definition 261 6.1. IoT Management Signallings 263 This section describes a set of IoT network management commands. 264 These commands are based on a real commercial implementation, 265 however, they are general network management functions that not 266 coupled with any specific services. Thus, these command could be 267 considered as a representative of the general requirements of similar 268 scenarios. 270 1. NETWORK_HEARTBEAT 272 a. BR sends heartbeat to node, every node relay to forward, ACK is 273 optional. 275 b. node can send the ACK if needed. 277 2. NETWORK_DISMISS 279 a. CMD from BR to Node: No Options are associated with this CMD. 280 This CMD will be sent in broadcast mode. 282 3. NODE_REMOVE 284 a. CMD from BR to Node: the destination IPv6 address will identify 285 the target node to be removed. 287 b. ACK from Node to BR. 289 4. NODE_LEFT_REPORT 290 a. Parent node sends a command to BR that a node connected to it has 291 left. 293 b. BR sends ACK to the parent node. 295 5. NETWORK_PARA_CONFIG 297 a. CMD from BR to Node. BR send RF config to every node, based on 298 broadcast relay, ACK is optional. 300 6. NODE_STATUS 302 a. Request. 304 b. Response. 306 7. NODE_STATISTICS 308 a. Request. 310 b. Response. 312 8. NODE_LOG 314 a. Request. 316 b. Response. 318 9. NODE_RESET 320 a. first response then reset, when node received this message. 322 (Editor's Note: More commands to be extended.) 324 6.2. GRASP Options 326 We propose to define three Options as the following. Each of the 327 above mentioned IoT management signallings could be fit into one of 328 the three options as different elements. 330 - IoT Node Status Reporting. (Details TBD.) 332 - Management Commands to IoT Nodes. (Details TBD.) 334 - IoT Network/Node Configuration. (Details TBD.) 336 7. Lightweight ACP 338 TBD. 340 8. Security 342 TBD. 344 9. IANA Considerations 346 TBD. 348 10. Acknowledgements 350 Some technical design work was contributed by Shoushou Ren. Relative 351 implementation experence was shared by Zongxin Dou, Wanhong Wang and 352 Haiyan Mao. 354 Valuable comments were received from Delei Yu, Sheng Jiang and Chuang 355 Wang. 357 This document was produced using the xml2rfc tool [RFC2629]. 359 11. References 361 11.1. Normative References 363 [I-D.ietf-anima-grasp] 364 Bormann, C., Carpenter, B., and B. Liu, "A Generic 365 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 366 grasp-15 (work in progress), July 2017. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 374 DOI 10.17487/RFC2629, June 1999, 375 . 377 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 378 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 379 Networking: Definitions and Design Goals", RFC 7575, 380 DOI 10.17487/RFC7575, June 2015, 381 . 383 11.2. Informative References 385 [I-D.ietf-anima-autonomic-control-plane] 386 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 387 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 388 plane-18 (work in progress), August 2018. 390 [I-D.ietf-anima-bootstrapping-keyinfra] 391 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 392 S., and K. Watsen, "Bootstrapping Remote Secure Key 393 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 394 keyinfra-16 (work in progress), June 2018. 396 [I-D.ietf-anima-reference-model] 397 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 398 and J. Nobre, "A Reference Model for Autonomic 399 Networking", draft-ietf-anima-reference-model-07 (work in 400 progress), August 2018. 402 [I-D.ietf-core-comi] 403 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 404 Management Interface", draft-ietf-core-comi-03 (work in 405 progress), June 2018. 407 [I-D.ietf-core-sid] 408 Veillette, M. and A. Pelov, "YANG Schema Item iDentifier 409 (SID)", draft-ietf-core-sid-04 (work in progress), June 410 2018. 412 [I-D.ietf-core-yang-cbor] 413 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 414 Minaburo, "CBOR Encoding of Data Modeled with YANG", 415 draft-ietf-core-yang-cbor-07 (work in progress), September 416 2018. 418 [I-D.veillette-core-yang-library] 419 Veillette, M., "Constrained YANG Module Library", draft- 420 veillette-core-yang-library-03 (work in progress), 421 September 2018. 423 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 424 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 425 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 426 Low-Power and Lossy Networks", RFC 6550, 427 DOI 10.17487/RFC6550, March 2012, 428 . 430 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 431 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 432 October 2013, . 434 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 435 Application Protocol (CoAP)", RFC 7252, 436 DOI 10.17487/RFC7252, June 2014, 437 . 439 Authors' Addresses 441 Bing Liu (editor) 442 Huawei Technologies 443 Q14, Huawei Campus 444 No.156 Beiqing Road 445 Hai-Dian District, Beijing 100095 446 P.R. China 448 Email: leo.liubing@huawei.com 450 Yuefeng Wu 451 Huawei Technologies 452 N8, Huawei Campus 453 No. 101 Ruanjian Road 454 Yu-Hua-Tai District, Nanjing 210000 455 P.R. China 457 Email: wuyuefeng@huawei.com