[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        B. Liu, Ed.
Internet-Draft                                                     Y. Wu
Intended status: Standards Track                     Huawei Technologies
Expires: January 4, 2018                                    July 3, 2017


                 ANI Applied in IoT Network Management
                  draft-rfmesh-anima-iot-management-00

Abstract

   This document describes an IoT scenario where ACP and GRASP is
   suitable to act as a network management channel and a lightweight and
   extensible network management protocol.  Relevent GRASP extention and
   options are also specified to fulfill the requirements of the
   scenario.

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 4, 2018.

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.



Liu & Wu                 Expires January 4, 2018                [Page 1]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scenario Description  . . . . . . . . . . . . . . . . . . . .   4
   4.  Why Choose GRASP as Management Protocol . . . . . . . . . . .   4
     4.1.  Candidate Technologies  . . . . . . . . . . . . . . . . .   4
       4.1.1.  IETF Core . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.2.  OMA LWM2M . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Suitability of GRASP  . . . . . . . . . . . . . . . . . .   5
   5.  GRASP Extention . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  GRASP over UDP  . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Reliable Transport  . . . . . . . . . . . . . . . . . . .   6
     5.3.  Fragmentation Handling  . . . . . . . . . . . . . . . . .   6
   6.  IoT Management Options Definition . . . . . . . . . . . . . .   6
     6.1.  IoT Management Signallings  . . . . . . . . . . . . . . .   6
     6.2.  GRASP Options . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Lightweight ACP . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   When Anima ANI [I-D.ietf-anima-reference-model] was designed, IoT
   scenarios were under consideration.  For example, one big reason of
   introducing CBOR encoding [RFC7049] in GRASP [I-D.ietf-anima-grasp]
   and choosing CoAP [RFC7252] for secure bootstrapping
   [I-D.ietf-anima-grasp] is for the effiecency of transporting packets
   over lossy IoT networks.

   This document discusses applying GRASP and ACP into a specific IoT
   scenario for some network management functions.  The characterstics
   of the scenario is:

   o  Low-power wireless field area network dedicated for industrial
      usage (e.g. 6LoWPAN-based electronic metering network).

   o  The topology is mesh.  It is natrual for a wireless local network.

   o  IPv6 addressing, which is beneficial for auto-configuration

   o  L3 routing is enabled (e.g.  RPL).




Liu & Wu                 Expires January 4, 2018                [Page 2]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


   o  Nodes are extremelly resource constraind.  (E.g., one typical
      hardware model only has 128Kbytes RAM and 512Kbytes ROM. )

   o  Gateway is normally a resource rich device, which acts as a
      management server to the nodes.

   o  Normally nodes don't need to communicate with any other entities
      beyond the gateway.

   However, some of the ANI designs are not specifically optimized for
   IoT scenarios:

   o  Most of the GRASP messages (except M_Discovery and M_Flood) are
      over TCP, which is considered as a heavy burden on radio resources
      for many IoT LLNs.

   o  Since GRASP is based on TCP, it lacks reliable transport and
      fragmentation mechanisms by itself.

   o  VRF-based ACP is not applicapable for most of the small IoT
      devices.

   This document discusses choosing GRASP as the management protocol
   over the other two candicates, which are IETF Core technologies and
   OMA LWM2M technologies.  And also discusses a potential lightweight
   ACP.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119]key
   words.

   This document use the key words defined in [RFC7575] .

   The following additional terms are used throughout this document:

   o

   o  IoT: Internet of Things

   o  BR: Bord Router

   o  CMD: Command



Liu & Wu                 Expires January 4, 2018                [Page 3]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


   o  ACK: Acknowledgement

   o  PLC: Power Line Communication

   o  LLN: Low-Power and Lossy Network

   o  RF: Radio Frequency

   o  TCP: Transport Controll Protocol

   o  RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
      [RFC6550] .

3.  Scenario Description

                                       /--\
                                      |    |      /--\
                          /--\         \--/      |    |
                         |    |                   \--/
                          \--/                                  /--\
                                          /--\
       +--------+                        |    |                 \--/
       |        |                         \--/
       |Border  |                 /--\                /--\
       |Router  |                |    |  IoT Nodes   |    |
       |(Gatewa |       /--\      \--/                \--/
       |y)      |      |    |              /--\                    /--\
       +--------+       \--/              |    |                  |    |
                                           \--/                    \--/
                                                       /--\
                                  /--\                |    |
                                 |    |                \--/
                                  \--/

   Fig 1.  Reference Scenario for Wireless Field Area IoT Networks

   As Fig 1 depicted, the BR is the root of the wireless network and act
   as a management server.  Each node connects to the BR.

4.  Why Choose GRASP as Management Protocol

4.1.  Candidate Technologies

4.1.1.  IETF Core

   Some IoT network management standardization work has been initialed
   in the IETF Core working group.  [I-D.ietf-core-comi] describes a
   network management interface for constrained devices and networks,



Liu & Wu                 Expires January 4, 2018                [Page 4]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


   called CoAP Management Interface (CoMI), which is used to access data
   resources specified in YANG, or SMIv2 converted to YANG; relevant
   YANG library for CoMI server [I-D.veillette-core-yang-library] and
   CBOR encoding of data modeled with YANG [I-D.ietf-core-yang-cbor] are
   also defined.  In a nutshell, these work items can be considered as
   some adaption and optimization of Netconf/YANG technologies for IoT
   environment.

   Netconf/YANG mechanisms are capabal of manuplating data orgnized in a
   sophisticated tree structure.  These capabilities are necessary and
   poweful in managing various device configurations, especially for the
   sophisticated devices such as router.  However, they might be too
   heavy for an extremly resource constrained device as discribed above.
   There is neither enough space for storing the programs in ROM, nor
   running the codes in RAM.

4.1.2.  OMA LWM2M

   OMA had issued the LWM2M specification, which is also designed for
   IoT network management.  LWM2M also chooses CoAP as the management
   protocol, but it doesn't choose YANG for data model, rather, it
   defined some OMA Objects.

   OMA objects less complete than YANG modeled data; the objects are
   flat rather than being orgnized as a tree structure.  But OMA objects
   contain also some advanced features such as access control of each
   object.  Plus the CoAP implementation, the LWM2M solution is still
   not ideal for the targeted scenarios in terms of ROM/RAM ocuppation.

4.2.  Suitability of GRASP

   According to Section 6.1 , most of the IoT commands are more like
   "Signallings" rather than traditional "Configurations".  It is
   reasonable because the IoT nodes need to auto-configure themselves as
   much as possible to gain maximum effiecency.  Relying on a
   centralized server configuring each node is a big challenge to the
   lossy wireless links and might probably cause significant delay of
   deployment.

   Thus, we might need a different approach to consider IoT management
   than just simply re-using Netconf/YANG in a different context (e.g.
   CoAP).

5.  GRASP Extention

   This section discusses potential GRASP extention to fulfill the IoT
   management requirements.




Liu & Wu                 Expires January 4, 2018                [Page 5]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


5.1.  GRASP over UDP

   Since TCP requires three times handshake, which would consume too
   much radio resource, thus it is not acceptable in LLNs.  Then UDP is
   needed.

5.2.  Reliable Transport

   For some critical messages, the sender would need to confirm the
   receiver had got the message, thus, there needs to be a reliable
   transport mechanism extended in application layer (GRASP).

5.3.  Fragmentation Handling

   Since the lack of TCP, GRASP also needs to be enhanced with some a
   fragmentation mechanism.

6.  IoT Management Options Definition

6.1.  IoT Management Signallings

   This section describes a set of IoT network management commands.
   These commands are based on a real commercial implementation,
   however, they are general network management functions that not
   coupled with any specific services.  Thus, these command could be
   considered as a representative of the general requirements of similar
   scenarios.

   1.  NETWORK_HEARTBEAT

   a.  BR sends heartbeat to node, every node relay to forward, ACK is
       optional.

   b.  node can send the ACK if needed.

   2.  NETWORK_DISMISS

   a.  CMD from BR to Node: No Options are associated with this CMD.
       This CMD will be sent in broadcast mode.

   3.  NODE_REMOVE

   a.  CMD from BR to Node: the destination IPv6 address will identify
       the target node to be removed.

   b.  ACK from Node to BR.

   4.  NODE_LEFT_REPORT



Liu & Wu                 Expires January 4, 2018                [Page 6]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


   a.  Parent node sends a command to BR that a node connected to it has
       left.

   b.  BR sends ACK to the parent node.

   5.  NETWORK_PARA_CONFIG

   a.  CMD from BR to Node.  BR send RF config to every node, based on
       broadcast relay, ACK is optional.

   6.  NODE_STATUS

   a.  Request.

   b.  Response.

   7.  NODE_STATISTICS

   a.  Request.

   b.  Response.

   8.  NODE_LOG

   a.  Request.

   b.  Response.

   9.  NODE_RESET

   a.  first response then reset, when node received this message.

   (Editor's Note: More commands to be extended.)

6.2.  GRASP Options

   We propose to define three Options as the following.  Each of the
   above mentioned IoT management signallings could be fit into one of
   the three options as different elements.

   - IoT Node Status Reporting.  (Details TBD.)

   - Management Commands to IoT Nodes.  (Details TBD.)

   - IoT Network/Node Configuration.  (Details TBD.)






Liu & Wu                 Expires January 4, 2018                [Page 7]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


7.  Lightweight ACP

   TBD.

8.  Security

   TBD.

9.  IANA Considerations

   TBD.

10.  Acknowledgements

   Some technical design work was contributed by Shoushou Ren. Relative
   implementation experence was shared by Zongxin Dou, Wanhong Wang and
   Haiyan Mao.

   Valuable comments were received from Delei Yu, Sheng Jiang and Chuang
   Wang.

   This document was produced using the xml2rfc tool [RFC2629].

11.  References

11.1.  Normative References

   [I-D.ietf-anima-grasp]
              Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-14 (work in progress), July 2017.

   [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>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <http://www.rfc-editor.org/info/rfc7575>.





Liu & Wu                 Expires January 4, 2018                [Page 8]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


11.2.  Informative References

   [I-D.ietf-anima-autonomic-control-plane]
              Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
              Control Plane", draft-ietf-anima-autonomic-control-
              plane-06 (work in progress), March 2017.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-06 (work in progress), May 2017.

   [I-D.ietf-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
              Reference Model for Autonomic Networking", draft-ietf-
              anima-reference-model-03 (work in progress), March 2017.

   [I-D.ietf-core-comi]
              Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP
              Management Interface", draft-ietf-core-comi-00 (work in
              progress), January 2017.

   [I-D.ietf-core-sid]
              Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A.
              Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf-
              core-sid-01 (work in progress), May 2017.

   [I-D.ietf-core-yang-cbor]
              Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
              Minaburo, "CBOR Encoding of Data Modeled with YANG",
              draft-ietf-core-yang-cbor-04 (work in progress), February
              2017.

   [I-D.veillette-core-yang-library]
              Veillette, M., "Constrained YANG Module Library", draft-
              veillette-core-yang-library-00 (work in progress), January
              2017.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.





Liu & Wu                 Expires January 4, 2018                [Page 9]


Internet-Draft      draft-rfmesh-anima-iot-management          July 2017


   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

Authors' Addresses

   Bing Liu (editor)
   Huawei Technologies
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: leo.liubing@huawei.com


   Yuefeng Wu
   Huawei Technologies
   N8, Huawei Campus
   No. 101 Ruanjian Road
   Yu-Hua-Tai District, Nanjing  210000
   P.R. China

   Email: wuyuefeng@huawei.com






















Liu & Wu                 Expires January 4, 2018               [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/