Internet DRAFT - draft-li-native-short-address

draft-li-native-short-address







Internet Area Working Group                                        G. Li
Internet-Draft                                                    Huawei
Intended status: Experimental                               10 July 2021
Expires: 11 January 2022


              Native Short Address for Internet Expansion
                    draft-li-native-short-address-00

Abstract

   This document specifies mechanisms of NSA (Native Short Address) that
   enables IP packet transmission over links where the transmission of a
   full length address may be wasteful.  All descriptions will focus on
   carrying IP packets across LLN (Low power and Lossy Networks), those
   LLNs positioned as limited domains.  The specifications include NSA
   allocation, routing with NSA, header format design including length-
   variable fields, and how to access full IPv6 networks.

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 https://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 11 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Li                       Expires 11 January 2022                [Page 1]

Internet-Draft                     NSA                         July 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  NSA Allocation  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Routing in a NSA Network  . . . . . . . . . . . . . . . . . .   6
     5.1.  Routing within the NSA limited domain . . . . . . . . . .   6
     5.2.  Routing between NSA and IPv6 domains  . . . . . . . . . .   7
   6.  NSA Header Format . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   There is an ongoing massive expansion of the network edge that is
   driven by the "Internet of Things" (IoT) technology, especially over
   low-power links which often, in the past, didn't support IP packet
   transmission.  Particularly driven by the requirements stemming from
   Industry 4.0 and Smart City deployments, more and more devices/things
   need to connect to each other and the Internet.  Comparing with
   traditional scenarios, scalability of the (edge) network along with
   lower power consumption are key technical requirements.  Moreover,
   large-scale LLN expect optimization for IP packet transmission over
   its low-power links, together with an efficient access to IPv6
   domains.

   The work in [SIXLOWPAN]/[SIXLO]/[LPWAN] Working Groups addresses many
   foundational issues for those type of deployments.  These
   deployements can be considered an instantiation of what [RFC8799]
   calls "limited domains".  For instance, the 6lowpan compression
   technology ([RFC4944] and [RFC6282]) addresses the problem of IPv6
   transmission over low-power packet loss networks, making it possible
   to connect IoT networks to Internet via IPv6.  For routing, [RFC8138]
   introduces a framework for implementing multi-hop routing on an LLN



Li                       Expires 11 January 2022                [Page 2]

Internet-Draft                     NSA                         July 2021


   using compressed routing headers and RPLs.  This technique enables
   the ability to route IPv6 packets within the domain without
   decompressing it.  In addition, SCHC [RFC8724] utilizes a context
   mechanism to make headers very small through compression.

   On the basis of this previous work, the NSA technique would optimize
   networking of devices within IoT and towards the Internet.  It is
   independent from stateless address assignment that depends on
   specific link-layer conventions.  Also, it is different from stateful
   address allocation that requires all nodes to obtain addresses from a
   centralized DHCPv6 server, which would lead to long network startup
   time and consumption of extra bandwidth resources.  Comparing to RPL-
   based routing [RFC6550], NSA will avoid the extra overhead of RPI
   (RPL Information) encapsulation.  NSA routing does not need to spread
   routing messages to establish the node-local routing table; such
   diffusion action would consume too much network resources, thus not
   being suitable for large networks that consist of many nodes.

   Moreover, NSA is a context-independent mechanism.  Thus, it is
   possible to support simpler, dynamic, and efficient forwarding.  In
   the best case, the NSA packet header size is smaller than
   LOWPAN_IPHC's 7 octets, see Figure 1 . Considering context-based and
   stateless address configuration is not appropriate for this the
   scenario proposed in this document, 7 octets is the smallest size
   that LOWPAN_IPHC can achieve without those conditions, instead of 3
   octets.

       0   1   2   3   4   5   6   7
     +---+---+---+---+---+---+---+---+
     | 0 | 1 | 1 |  TF   |NH | HLIM  |
     +---+---+---+---+---+---+---+---+
     |CID|SAC|  SAM  | M |DAC|  DAM  |
     +---+---+---+---+---+---+---+---+
     |      SCI      |      DCI      |
     +---+---+---+---+---+---+---+---+
     |                               |
     +         Source Address        +
     |                               |
     +---+---+---+---+---+---+---+---+
     |                               |
     +       Destination Address     +
     |                               |
     +---+---+---+---+---+---+---+---+

                 Figure 1: Best case of LOWPAN_IPHC header.






Li                       Expires 11 January 2022                [Page 3]

Internet-Draft                     NSA                         July 2021


2.  Requirements Notation

   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 BCP
   14 [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Overview

   Native Short Address (NSA) is a distributed assigned network layer
   identifier for efficient routing in a limited domain.  It is normally
   locally assigned, using a smaller address space than IPv6.  The
   architecture of NSA network is showed in Figure 2.

    IPv6 Domain          Internet (IPv6)
                        --------+--------
       /|\                      |
        |                       |
        |               +-------+-------+
        |               | Border Router |
        |               +---------------+
        |              //---     /-\    ---\\
        |           ///         |   |        \\\
        |         //    /-\      \-/            \\
        |        /     |   |                      \
        |      |/       \-/               /-\      \|
        |     |                    /-\   |   |       |
        |     |   /-\       /-\   |   |   \-/   /-\  |
        |    |   |   |     |   |   \-/         |   |  |
        |    |    \-/       \-/                 \-/   |
        |    |                            /-\         |
        |     |        /-\               |   |       |
        |     |       |   |               \-/        |
        |      |\      \-/                         /|
        |        \Up to several thousands of nodes/
        |         \\                             /
       \|/          \\\                      ///
                       \\---    LLN     ---//
    NSA Domain              ------------

            Figure 2: The architecture of general NSA networks.









Li                       Expires 11 January 2022                [Page 4]

Internet-Draft                     NSA                         July 2021


   Our overall design objective is centered on how to minimize the
   packet overhead and message exchange to achieve energy saving, while
   being suitable for a large-scale IoT network.  This determines the
   key technologies of NSA in a limited domain, namely (i) the native
   short address allocation (see Section 4), (ii) the mechanisms for
   native table-free routing (see Section 5), and (iii) a compact header
   format design (see Section 6) that avoids context and compression.

4.  NSA Allocation

   In an NSA network, there are 3 roles for nodes, namely: * Root *
   Forwarder * Leaf

   The basic aspects of allocation include: * Root's address will always
   be '1'. * Forwarder's address will always end with '0' (least
   significative bit = 0). * Leaf's address will always end with '1'
   (least significative bit = 1).

   Normally, the root role is assigned to the border router when the LLN
   bootstraps.  All child nodes' addresses will strictly start with
   their parent's address.  An example is showed in Figure 3.

                         root

                           1  -         +--------------------------+
                            /| |--      | append more bits to form |
                          //  + \\----  | brother's address        |
                         /    |   \\  --+--------------------------+
      +---------+ 10   //   11|     \\    ----
      |forwarder|  -  /       +    110\-    111--
      |node     | | |        | |      | |      | |
      +---------+/ -   --     -        -        -
                /  | \   ---          / |
               /   |  \\    --       /  |
              /    |    \     --                              +
          100/ 101 |  1010   1011   +--------------+
           -      -      -      -   |Prefix is '10'|
          | |    | |    | |    | |  +--------------+
           -      -      -      -
          / |          / |
         /  |         /  |

                                                +

             Figure 3: An example of NSA addresses allocation.






Li                       Expires 11 January 2022                [Page 5]

Internet-Draft                     NSA                         July 2021


   Each node that wants to acquire a native short address needs to send
   an Address Request (AR) message to its link layer neighbors and wait
   for the response.  In the AR message, node needs to designate a
   'role' value (forwarder or leaf) and 'nodeid'.  If neighbor has not
   been configured with forwarder address and is not root, it will drop
   the message silently.  Or, the neighbor should pick up an address
   according to 'role' parameter in the AR message.  The allocation
   function A(role,i) is defined as shown in Figure 4.  Every forwarder
   node should maintain separate index value for leaf and forwarder
   childs.

              A(role, i) = 'root/forwarder address'
                         + (i-1)*'1'
                         + (role == leaf?'1':'0'),
              in which, i is index of leaf/forwarder at this layer.

     Figure 4: Definition of the allocation function of forwarder/root
                                   nodes.

   After neighbor forwarder node assigned an address for node n, it
   assigns the suffix of that address as the interface id from which
   receiving the AR message.  Then, it generates a response message of
   AR and sends it to the request node.

   When node n successfully acquires an address from its neighbor, it
   will become child of that neighbor.  Once a node received a valid
   response of AR, it uses that native short address for its own network
   layer address and ignores replies from other neighbors.  If node
   doesn't receive any response after an interval, it will send the AR
   message again.

5.  Routing in a NSA Network

5.1.  Routing within the NSA limited domain

   When a packet arrives at or is generated in a NSA node, the node will
   perform one of the following actions, depending on which condition
   holds:

   1.  If the destination equals the current node's address, the packet
       is delivered to the upper layers.

   2.  If the node is originating the packet and it is a leaf node, it
       sends packet to its parent.

   3.  If node is a forwarder and its address is in the same prefix of
       the Destination Address (DA), it makes the following calculation.
       It checks the bit values from bit next to the prefix, skip '1'



Li                       Expires 11 January 2022                [Page 6]

Internet-Draft                     NSA                         July 2021


       until the first '0' to find a new longer prefix.  This prefix
       should be direct child of current node.  If there are only '1's
       following, DA should be the direct leaf child of current node.

   4.  If the node is not root, it sends packet to parent

5.2.  Routing between NSA and IPv6 domains

   For downlink traffic (Internet toward NSA domain):

   1.  The border router (i.e., the root node) can construct IPv6
       address for nodes by concatenating IPv6 prefix and native short
       address.  The IPv6 prefix can be obtained by configuration.  The
       border router can keep IPv6 addresses for all nodes in the
       domain.

   2.  The root will get native short address from those IPv6 addresses,
       while native table free routing will be used for packet
       transmission (cf., previous section).

   For uplink traffic (NSA domain toward the Internet):

   1.  Border router maintains a table that maps IPv6 destinations to
       native short addresses, which will be seen as index of IPv6
       address table.

   2.  Packet carries an index of table item when transmitting in the
       domain.  Border router will look up real IPv6 destination before
       sending the packets to IPv6 domain.

6.  NSA Header Format

   As per Section 4, the address field would be variable in length.  In
   this section, we outline the design of the header format partially
   based on the format of 6lowpan, accommodating the variable length
   fields in the packet.  The header format is shown in Figure 5.

      0                                       1
      0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    | 0 | 1 | 0 | 1 |  TF   |NH |HL | Payload Length(Variable Len)  |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |I/O|AM |    SA(Variable Len)   |         DA(Variable Len)      |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |                        In-line fields ...                     |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                   Figure 5: Header format of NSA packets



Li                       Expires 11 January 2022                [Page 7]

Internet-Draft                     NSA                         July 2021


   The first 4 bits would be new dispatch type that will be introduced
   in Section 7.

   *  TF: Same definition as in [RFC6282] Section 3.1.1.

   *  NH: Same definition as in [RFC6282] Section 3.1.1.

   *  HL: This field indicates the hop limit.  When HL is 0, a hop limit
      field defined in [RFC2460] locates in in-line fields, while HL is
      1 means no hop limit header in packet.

   *  Payload length is a variable length field.  It normally occupies
      an octet assuming most packets are smaller than 252 bytes.  For
      larger packets, payload length may expand to 2 to 3 octets.  The
      encoding method is defined as follows.  When the first octet has
      value of:

      -  0~252: Indicates how many octets the payload consist of.

      -  253: Indicates that there is an extra octet for payload length,
         with the actual length value equal to the last byte value plus
         252.

      -  254: Indicates that there is an extra two octets for payload
         length, with the actual length value equal to the value of the
         second byte multiple 256 plus value of the last byte plus 252.

      -  255: Reserved.

   *  I/O: Indicates whether this packet belongs to uplink or downlink
      traffic, where the former means from an NSA node to IPv6
      destination in the Internet, while the latter means opposite
      direction.  This field is meaningless when the traffic is inside
      the NSA domain.

   *  AM: Indicates the address mode.  When it is '0', the SA of
      downlink packets or DA of uplink packets is a full IPv6 address,
      while if it is '1', the SA of downlink packets or DA of uplink
      packets is a native short address that indexes the full IPv6
      address on root node.  This field is meaningless when the traffic
      is inside the NSA domain.

   For length variable native short address encoding, for both Source
   Address (SA) and Destination Address (DA), the definition is:

   *  0~252: if the address value locates in this interval, one octet is
      used to encode the value




Li                       Expires 11 January 2022                [Page 8]

Internet-Draft                     NSA                         July 2021


   *  253: indicates that the address is encoded in 2 octets.

   *  254: indicates that the following 4 octets encode the address.

   *  255: indicates that the following octet defines the length of
      address in octets, followed by the address value octets.

7.  IANA Considerations

   This document requires IANA to assign the range 0101000 to 0101111 of
   the "Dispatch Type Field" registry as follows:

   +---------+---------------------------+-----------------+
   |0101TTNH | LOWPAN NSA IP(LOWPAN_NIP) | [This Document] |
   +---------+---------------------------+-----------------+

         Figure 6: LOWPAN Dispatch Type Field requested allocation

8.  Security Considerations

   An extended security analysis will be provided in future revision of
   this document.  As of this point we consider that the security
   considerations of [RFC4944], [RFC6282] apply.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.





Li                       Expires 11 January 2022                [Page 9]

Internet-Draft                     NSA                         July 2021


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [LPWAN]    "IPv6 over Low Power Wide-Area Networks (lpwan) WG", n.d.,
              <https://datatracker.ietf.org/wg/lpwan/about/>.

   [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,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zúñiga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [SIXLO]    "IPv6 over Networks of Resource-constrained Nodes (6lo)
              WG", n.d., <https://datatracker.ietf.org/wg/6lo/about/>.

   [SIXLOWPAN]
              "IPv6 over Low power WPAN (6lowpan) - Concluded WG", n.d.,
              <https://datatracker.ietf.org/wg/6lowpan/about/>.

Author's Address

   Guangpeng Li
   Huawei Technologies
   Beiqing Road, Haidian District
   Beijing
   100095
   China

   Email: liguangpeng@huawei.com



Li                       Expires 11 January 2022               [Page 10]