Native Short Address for Internet Expansion

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

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

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 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     +
  |                               |
  +---+---+---+---+---+---+---+---+

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

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'|
       | |    | |    | |    | |  +--------------+
        -      -      -      -
       / |          / |
      /  |         /  |

                                             +

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.

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

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

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¶
• 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] |
+---------+---------------------------+-----------------+

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

Author's Address