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]
