6Lo Working Group G. Li
Internet-Draft D. Lou
Intended status: Experimental L. Iannone
Expires: 27 April 2023 Huawei
P. Liu
R. Long
China Mobile
K. Makhijani
Futurewei
P. Thubert
Cisco
24 October 2022
Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks
draft-li-6lo-path-aware-semantic-addressing-00
Abstract
This document specifies a topological addressing scheme, Path-Aware
Semantic Addressing (PASA) that enables IP packet transmission over
links where the transmission of a full length address may not be
desirable. Furthermore, packet forwarding is stateless, meaning that
no routing table needs to be built, rather, the forwarding decision
is based solely on the destination address structure. This document
focuses on carrying IP packets across an LLN (Low power and Lossy
Network), in which the topology is static, where nodes' location is
fixed, and the connection between nodes is also rather stable. This
specifications details the PASA architecture, address allocation,
forwarding mechanism, header format design, including length-variable
fields, and IPv6 interconnection support.
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 27 April 2023.
Li, et al. Expires 27 April 2023 [Page 1]
Internet-Draft PASA October 2022
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Comprehensive Use Cases . . . . . . . . . . . . . . . . . . . 4
3.1. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Smart Home . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Data Center Monitoring . . . . . . . . . . . . . . . . . 7
3.4. Industrial Operational Technology Networks . . . . . . . 9
4. Architectural Overview . . . . . . . . . . . . . . . . . . . 10
5. PASA Allocation . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. PASA Addresses and IPv6 Addresses . . . . . . . . . . . . 17
5.2. Limitation of Number of Children Nodes . . . . . . . . . 18
6. The PASA-6LoRH Header . . . . . . . . . . . . . . . . . . . . 18
6.1. PASA-6loRH Sequence . . . . . . . . . . . . . . . . . . . 18
6.2. PASA-6loRH Format . . . . . . . . . . . . . . . . . . . . 19
6.3. PASA-6loRH and LOWPAN_IPHC co-existence . . . . . . . . . 20
7. Forwarding in a PASA Network . . . . . . . . . . . . . . . . 21
7.1. Forwarding toward a local PASA endpoint . . . . . . . . . 22
7.2. Forwarding toward an external IPv6 node . . . . . . . . . 25
8. PASA Control Messages . . . . . . . . . . . . . . . . . . . . 25
8.1. New Control Message . . . . . . . . . . . . . . . . . . . 25
8.2. Address Configuration based on 6LOWPAN-ND . . . . . . . . 26
8.2.1. PASA Request Address Option (PRAO) Format . . . . . . 27
8.2.2. PASA Assign Address Option (PAAO) Format . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. Critical 6LoWPAN Routing Header Type for PASA-6LoRH . . . 29
9.2. Allocation Function Registry . . . . . . . . . . . . . . 29
9.3. ICMP PASA Control Message . . . . . . . . . . . . . . . . 29
9.4. PASA Neighbor Discovery Options . . . . . . . . . . . . . 30
10. Reliability Considerations . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Li, et al. Expires 27 April 2023 [Page 2]
Internet-Draft PASA October 2022
Normative References . . . . . . . . . . . . . . . . . . . . . 31
Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
There is an ongoing massive expansion of the network edge, driven by
the "Internet of Things" (IoT), especially over low-power links which
often, in the past, did not support IP packet transmission.
Particularly driven by the requirements stemming from Industry 4.0,
Smart Grid and Smart City deployments, more and more devices/things
are connected to the Internet. Sensors in plants/parking bays/mines/
datacenters, temperature/humidity/flash sensors in buildings/museums,
normally are located in a fixed position and are networked by low
power and lossy links even in hardwired networks. Comparing with
traditional scenarios, scalability of the (edge) network along with
lower power consumption are key technical requirements. Moreover,
large-scale Low power Lossy Networks (LLNs) are expected to be able
to carry IPv6 packets over their links, together with an efficient
access to native IPv6 domains.
The work in [SIXLOWPAN]/[SIXLO]/[LPWAN] Working Groups addresses many
fundamental issues for those type of deployments, which can be
considered an instantiation of what [RFC8799] defines as "limited
domains". For instance, the 6lowpan compression ([RFC4944],
[RFC6282]) addresses the problem of IPv6 transmission over LLNs,
making it possible to interconnect IPv6-based IoT networks and the
Internet. [RFC8138] introduces a framework for implementing multi-
hop routing on an LLN using a compressed routing header, which works
also with RPL (Routing Protocol for LLNs [RFC6550]). This technique
enables the ability to forward IPv6 packets within the domain without
the need of decompression. In addition, SCHC (Generic Framework for
Static Context Header Compression and Fragmentation [RFC8724])
enables even more compression by using a common static context.
The aforementioned technologies, which leverage on the presence of a
routing protocol, are suitable in general for all IoT scenarios.
However, there could be more simplified solutions for those scenarios
and applications with static network topologies and stable network
connections, typically leveraging on wired technologies
[I-D.ietf-6lo-use-cases] (e.g. PLC [I-D.ietf-6lo-plc] or MS/TP
[RFC8163], and Industrial IoT technologies like [RS485], etc.). In
those kinds of deployments, topologies are planned in advance and
well provisioned, with sensor nodes usually in fixed locations. This
document introduces a topology-based addressing mechanism with that
allows to avoid the use of routing protocol in favor of a topological
stateless forwarding algorithm (see Section 3).
Li, et al. Expires 27 April 2023 [Page 3]
Internet-Draft PASA October 2022
The specifications in this document leverage on the 6Lo Routing
Header (6LoRH) af defined in [RFC8138].
This means that except the addresses (source and destination) the
other fields of the header will be compressed according to
LOWPAN_IPHC. The proposed addressing is independent of Unique Local
Addresses [RFC4193], which has a dependency on specific link-layer
conventions [RFC6282]. It is also different from stateful address
allocation that requires all nodes to obtain addresses from a
centralized DHCP server, which leads to increased network startup
time and consumption of extra bandwidth. Compared to RPL-based
routing [RFC6550], PASA avoids the extra overhead of address
assignment by integrating address assignment and tree forming
together. Furthermore, PASA provides much smaller forwarding table
size than storing mode RPL.
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. Comprehensive Use Cases
As mentioned in Section 1, the [I-D.ietf-6lo-use-cases] provides some
6lo use cases with wired connectivity, tree-based topology, and no
mobility requirement (cf. Table 2 of [I-D.ietf-6lo-use-cases]).
These use cases, where PASA can be used, include Smart Grid, Smart
Building, etc. The PASA solution utilizes stable and static topology
information to allocate addresses for nodes, which enables the
forwarding in stead of routing. It saves overhead of messages
triggered by routing protocols and reduces RAM footprint for routing
table storage. Thus, it will reduce the overall energy consumption.
The PASA forwarding logic is extreme simple, few lines of code is
sufficient to implement the stack. It enables the solution being
ported onto extreme constrained nodes. In the following paragraphs,
we will dive deeper into a few use cases to demo the applicability of
the PASA solution.
3.1. Smart Grid
A typical smart grid network topology whose purpose is to distribute
electricity to homes in a residential area consists of Smart Circuit
Breaker (SCB), Phase Change Switch (PCS), Cable Branch Box (CBB) and
Power Distribution Cabinet (PDC), as shown in the figure Figure 1.
The PDC containing a few SCBs, phase compensation units, sensors and
actuators is responsible for the power distribution towards CBB. The
Li, et al. Expires 27 April 2023 [Page 4]
Internet-Draft PASA October 2022
CBB containing SCBs and sensors further distributes the power to PCS
and eventual the home. The smart grid power distribution network
forms a typical tree topology, where the PLC communication technology
is used to collect data (meter numbers, phases, etc.) and perform
control/management of the overall system.
+---Voltage Transformer
|
+----------+-----------+
| PDC +-+-+ | SCB:Smart Circuit Breaker
| |SCB| | PCS:Phase Change Switch
| +-+-+ | CBB:Cable Branch Box
| +------+-------+ | PDC:Power Distribution
| +-+-+ +-+-+ +-+-+ | Cabinet
| |SCB| |SCB| |SCB| |
| +-+-+ +-+-+ +-+-+ |
+--+--------+-------+--+
| | |
| | +-------------------------+
+----+ +----------+ |
| | |
+-----------+----------+ +-----------+----------+ |
| CBB | | | CBB | | Chargers |
| +-------+------+ | | +-------+------+ | ++ |
| +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | ||---+
| |SCB| |SCB| |SCB| | | |SCB| |SCB| |SCB| | ++ |
| +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | ++ |
+---+-------+------+---+ +---+-------+------+---+ ||---+
| | | | | | ++ |
| | | +-++ +-++ +--++
+-+-+ +-+-+ +-+-+ +--+ +--+ +--+|
|PCS| |PCS| |PCS| Monitors for end |
+---+ +---+ +---+ |
+CBB-------+----------+
| +-------+-------+ |
|+-+-+ +-+-+ +-+-+|
||SCB| |SCB| |SCB||
|+---+ +---+ +---+|
+---------------------+
Figure 1: The topology of smart grid.
Li, et al. Expires 27 April 2023 [Page 5]
Internet-Draft PASA October 2022
3.2. Smart Home
Smart home or home domotica is another example, as shown in figure
Figure 2, where a PLC gateway in each room is used to connect home
appliances (boiler, dishwasher, fridge, etc.) and devices (lights,
doorbell, sound boxes, etc.) to the Internet. The network can be
further extended if a switch/router is connected. As it leverages
the power line distribution, the network forms a typical tree
topology as well. Some observations and considerations are:
* Usually there is a Home Gateway to bridge the smart home to the
Internet.
* The Home Gateway, the PLC gateway, and most of the home appliance
are fixed in different locations. They rarely move after setup.
* The smart home automation requires any to any communication.
* Lightweight communication stack with limited MCU and RAM
consumption is desired.
/----------\
| Internet |
\-----+----/
|
+------+------+
| Home Gateway|
+------+------+
|
+-----------------------++--------+-----------++-------------------+
| +----++--------+-----------++---------+ Kitchen|
| Living +--+---+|| +---+--+ Bedroom|| +---+--+ |
| Room |PLC GW||| |PLC GW| || |PLC GW| |
| +---+--+|| +--+---+ || +---+--+ |
| | || | || | |
| | || | || | |
| +-----+-----+----+ || +----+--+------+ || +------+------+ |
| | | | | || | | | || | | | |
| | | | | || | | | || | | | |
| /+\ /+\ /+\ /+\ || /+\ /+\ /+\ || /+\ /+\ /+\ |
|| | | | | || | ||| | | | | |||| | | | | ||
| \-/ \-/ \-/ \-/ || \-/ \-/ \-/ || \-/ \-/ \-/ |
| Switches Door ||Strip Voice Sound||Boiler Fridge Dish|
|Light TV bell ||Light Command Boxes|| Washer|
+-----------------------+| Device |+-------------------+
+--------------------+
Figure 2: The topology of smart home.
Li, et al. Expires 27 April 2023 [Page 6]
Internet-Draft PASA October 2022
3.3. Data Center Monitoring
Data centers is a significant infrastructure for network management
and service quality, which requires numerous safeguards in place to
protect hardware assets against cyber-attacks. Besides,
environmental issues such as extreme temperature, high humidity,
water leakage and high dust concentration can cause device failures
as well. Therefore, it is critical to deploy sensors to monitor
environmental factors to make sure data center is running
efficiently.
The network topology of the data center supervision system is
hierarchical, and mainly consists of Network Management System (NMS),
Supervision Center (SC), Field Supervision Unit (FSU), dumb and smart
devices, as shown in the figure Figure 3. The smart devices refer to
smart air conditioner, smart door lock and power equipment with
embedded sensors to report their working status. The dumb devices
refer to the many devices without embedded sensors, which require
additional sensors to collect and update information of environment.
Li, et al. Expires 27 April 2023 [Page 7]
Internet-Draft PASA October 2022
NMS:Network Management System /----\ //------\\
SC :Supervisor Center / \ || ||
FSU:Field Supervisor Unit | SC +---------+| NMS ||
\ / \\------//
\----/
/ \
/ \
/ \
/ \
/-/--\ \
/ \ \
| SC | \
\ / \
\--X-/ \
/ \ \
/ \ \
/ \ \
/ \ \
/-/-\ /-\-\ /---\
| FSU | | FSU | | FSU |
\-X-/ \-X-/ \-X-/
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
+-/-+ /-\\ +-/-+ /-\\ +-/-+ /-\\
| | | | | | | | | | | |
| | | | | | | | | | | |
+---+ \--/ +---+ \--/ +---+ \--/
Smart dumb Smart dumb Smart dumb
Device Device Device Device Device Device
Figure 3: The topology of Power & Environment Supervisor System.
Both dumb and smart devices are connected to the FSU, which monitors
and connects all devices of the whole floor. The number of ports on
FSU is limited, where one FSU usually contains 8 analog input ports,
16 digital input ports, 4 digital output ports, 8 RS485 ports and 4
IP ports. The terminal devices report working status and
environmental information to FSUs every 3 second. If values that are
abnormal or above a certain threshold are detected, the FSU reports
it to the SC immediately and keeps on reporting it in real-time for
next couple of hours, until the manager issues new commands. The SC
can be constructed as required. The FSU reports to the local SC
first, then relay the message to the central SC for data analyzing
and management.
In this scenario, deployed devices (usually 600-1000 sensors per
floor) rarely. Due to the shortage of ports and limitation of
Li, et al. Expires 27 April 2023 [Page 8]
Internet-Draft PASA October 2022
voltage supply, additional power supply or batteries are often used.
Since battery replacement and maintenance is costly, it is desired to
have low energy consumption for longer service life. We should not
only reduce the power consumption on the device level, but also on
the data transmission level. The data transmission also causes huge
power consumption, which can be reduced by leveraging low power
transmission protocol. The FSU connects to sensors with wired
technology, such as AI/DI/RS232/RS485/single pair ethernet. Multiple
FSUs will connect to hierarchical supervision centers and then make
data communication with supervision platform by IPv6.
3.4. Industrial Operational Technology Networks
The Operational Technology (OT) networks are not pure IP networks.
Shop floors deploy fieldbus protocols such as Modbus, Profinet/IP,
BacNET, CAN etc. for process control using field devices (sensors and
actuators). To improve automation, Industry 4.0 is looking at means
to integrate process control in OT domain with the applications
residing in IPv6 domains (the enterprise networks). This leads to
three primary requirements:
* Continuity in connectivity between the end devices and
applications, both of which follow different address structures.
* The OT networks are traditionally designed as layer-2 and OT
operators are not expected to deploy or maintain IT style routing
infrastructure, hence auto-configuration mechanisms for device
addresses and reachability are preferred.
* The OT networks are also delay-intolerant; therefore, compact and
lean message structures are favored over encapsulations to
minimize processing and translation overheads.
Using PASA, as described in details later in this document, the
following applies:
* The OT network is represented as PASA domain, interfacing with
native IPv6 applications, e.g., Human-Machine Interface (HMI),
Manufacturing Execution System (MES). In general on shop floors,
devices are at fixed locations or cell-sites and the PASA tree
hierarchy described in Figure 4 applies suitably.
* In an idealized PASA-based OT domain, a leaf-node could be a field
device (sensor or actuator) that always connects to PLC serving as
last node forwarding traffic to/from the leaves, i.e. sensors and
actuators.
Li, et al. Expires 27 April 2023 [Page 9]
Internet-Draft PASA October 2022
* The border node may be at the root for any IT application
requirement. Then the packet communication inside the PASA domain
will strictly follow PASA structure whereas communications with
IPv6 domain networks will use the Border router for translations.
IPV6 +------+------------+
+---------------| HMI/MES/FW/Gateway|----------+
| PASA +------+------------+ |
| |
+----|------------------+ | PASA
| +--+---+ | |
| |PLC |--------------+-----------+ |
| +---+--+ | | +--------+---------+
| | profinet | +--------+----+ | | |
| | | | +-----+ | | +--+--+ |
| +-----+-----+----+ | | | PLC | | | | PLC | |
| | | | | | | +--+--+ | | +--+--+ |
| | | | | | | | | | | |
| /+\ /+\ /+\ /+\ | | profi|bus | | | modbus |
| \-/ \-/ \-/ \-/ | | +---+---+ | | +-----+------+ |
| sensors/actuators | | | | | | | | | |
| cell-site-A | | | | | | | | | |
+-----------------------+ | /+\ /+\ | | /+\ /+\ /+\ |
| \-/ \-/ | | \-/ \-/ \-/ |
| | | sensors/actuators|
| cell site B | | cell site C |
+-------------+ +------------------+
Figure 4: Industrial Operational Technology Network topology.
4. Architectural Overview
Path-Aware Semantic Addressing (PASA) is an efficient topology-based
network layer address assignment and packet forwarding mechanism.
The PASA nodes are aware of their own IPv6 address, constructed by
IPv6 prefix and the PASA itself (see Section 5.1 and Section 7.2).
Inside the PASA domain, nodes communicate with each other by using
only PASA addresses. It is a smaller addressing space compared to
the huge IPv6 addressing space, but enabling stateless forwarding.
When IPv6 communication occurs between nodes inside the PASA domain
and external IPv6 nodes, the border router, which plays as well the
role of "root" in the addressing tree, performs network address
translation (as per Section 7.2 and [RFC6282]). The architecture of
PASA network is showed in Figure 5.
Li, et al. Expires 27 April 2023 [Page 10]
Internet-Draft PASA October 2022
/|\ Internet (IPv6)
| --------+--------
IPv6 Domain | |
| |
| +-------+-------+
---------------------------- | Border Router |
| | (PASA Root) |
| +---------------+
|
| O
|
| O O O
| O O
| O O
PASA Domain | O
| O O O O O O
| O
| O O
| O
| O
|
\|/ Low-Power and Lossy Network
Figure 5: The architecture of general PASA networks.
In the PASA network, there are 3 types of nodes, the root node, the
forwarder node and the leaf node. There is typically only one root
node in the PASA network.
* PASA Root: The root node is responsible for the management of the
whole PASA network and routing/forwarding both internal and
external traffic. It stores the IPv6 prefix of the domain in
order to perform the network address translation for external
communications. It also stores the address Allocation Function
(AF) and performs the address assignment for its children. After
successful address assignment, the root will keep the state of its
direct children. The root node functions as gateway between the
PASA domain and the Internet. As such it also operates the
translation between LOWPAN and IPv6 format (cf. Section 7).
* Forwarder: A forwarder is a node, different from the root node,
containing at least one child. A forwarder node is basically the
root of a subtree and its role is to forward traffic between its
parent and its children according to the addressing. When
handling a packet, if the destination is in one of its subtrees,
it forwards the packet to the right child, otherwise it simply
sends it to its parent.
Li, et al. Expires 27 April 2023 [Page 11]
Internet-Draft PASA October 2022
* Leaf: A leaf node is a node with no children. Its operation is
simple since it is either a destination or source of every packet
it handles. If it is the source of packets, it simply sends the
packets to its parent.
Each node acquiring a PASA address needs to send an Address Request
(AR) message to its link layer neighbors and wait for the response.
In the AR message, the node needs to designate a 'role' value
(forwarder or leaf) and the "node-id". The latter is a unique
identifier of each PASA node, including root, forwarders, and leaves.
This document assumes the use of the smallest link-layer address of
the node as 'node-id'.
Forwarder and Leaf roles can be assigned similarly to IEEE 802.15.4,
which distinguishes between Full-Function Devices (FFD) and reduced
function devices (RFD) (cf., [ZigBee]). If a neighbor is neither a
forwarder nor the root, it will drop the AR message silently.
Otherwise, the neighbor will calculate an address based on parameters
in the AR message. After the neighbor node assigns an address to the
node, using a Allocation function (AF), it stores the suffix of that
address as the interface ID towards the node. Then, it generates and
sends Address Assignment (AA) message back and becomes the parent
node.
This address assignment relies on the base mechanism described in
6lowpan-ND ([RFC6775]), but defines two new options of ND message,
whose format is defined in Section 8.2.1 and Section 8.2.2.
The acceptance of the address assignment follows "first come first
serve" principle. Once a node receives a valid AA response, it uses
that assigned address as its own network layer address, thus becomes
a child of the address assigner. It will then ignore replies from
other neighbors.
If a node does not receive any response after
RTR_SOLICITATION_INTERVAL (10 seconds defined in [RFC6775]), it will
send the AR message again. It is RECOMMENDED that nodes re-send the
AR message up to MAX_RTR_SOLICITATIONS (3 transmissions defined in
[RFC6775]), if no answer is received, they SHOULD stop.
The overall design objective is centered on reducing the size (or
completely avoid the usage) of routing/forwarding table by using a
topological addressing scheme. PASA eliminates compression/
decompression of the address and also reduces the amount of
information synchronization messages, so it actually reduces
computation complexity during packets parsing and forwarding. As
such, PASA may save communication energy in an IoT LLN network.
Li, et al. Expires 27 April 2023 [Page 12]
Internet-Draft PASA October 2022
PASA uses a context-independent address encoding mechanism. It does
not carry any field about address context in the packet. It carries
source and destination addresses as variable length fields whose size
can be reduced to one octet each in the best case.
There are three distinct PASA features that allow PASA to be
efficient, namely:
1. PASA Address allocation (see Section 5),
2. Stateless forwarding (see Section 7),
5. PASA Allocation
The basic rules of allocation include:
* Each node's address is prefixed by their parent's address.
* The root/forwarder runs an AF (Allocation Function) to generate
its children's addresses.
* All nodes run the same AF in the same network instance.
* The maximum length of the PASA address MUST NOT exceed 64 bits.
Normally, the root role is assigned to the border router when the LLN
bootstraps. An example of a possible result of an PASA deployment is
shown in Figure 6.
root +--------------------------+
1 | append more bits to form |
O ----+ | brother's address |
/ | \ \ +--------------------------+
/ | \ \
/ | \ \
+---------+ / | \ \
|forwarder| 10 / 11 110\ \ 111
|node | O - O O O
+---------+/ |\ \ | \
/ | \ \ | \
/ | \ \ O O
/ | \ \
100/ 1010| 101 1011 +--------------+
O O O O |Prefix is '10'|
/| /| +--------------+
/ | / |
O O O O
1001 10011 10101 101011
Li, et al. Expires 27 April 2023 [Page 13]
Internet-Draft PASA October 2022
Figure 6: An example of PASA addresses allocation.
The allocation function AF(role,i) used in this document is defined
in Figure 7. Every forwarder node stores and maintain two indexes,
one for the children that are forwarders and one for the children
that are leaves (starting at 0 for the first child in each role).
Let's call the first index 'f', as of forwarders, and the second 'l'
as for leaves. The '+' symbol indicates a concatenation operation.
The b() operation indicates the binary string of '1' with length
equal to its argument, for instance b(3) returns '111'.
AF(role, f, l) = 'address of the node performing the function'
+ (role == leaf? b(l++):b(f++))
+ (role == leaf?'1':'0'),
in which, f and l are the indexes of respectively the forwarders
and the leaves at this layer (starting at 0).
Figure 7: Definition of the Allocation Function (AF) of
forwarder/root nodes.
Taking the example of the topology in Figure 6, the proposed AF works
as follows.
At the top level, there are 4 children of root, two are forwarders
and the other two are leaves. Starting from the left most node and
moving to the right, the root node applies the AF as follows:
* For the first child, which is a forwarder:
- A('forwarder', 0, 0) = '1'(root address) + b(0) + '0' = '1' +
'' + '0' = 10
- Index f is increased by one and is now equal 1 (f=1)
* For the second child, which is a leaf:
- A('leaf', 1, 0) = '1'(root address) + b(0) + '1' = '1' + '' +
'1' = 11
- Index l is increased by one and is now equal 1 (l=1)
* For the third child, which is a forwarder:
- A('forwarder', 1, 1) = '1'(root address) + b(1) + '0' = '1' +
'1' + '0' = 110
- Index f is increased by one and is now equal 2 (f=2)
Li, et al. Expires 27 April 2023 [Page 14]
Internet-Draft PASA October 2022
* For the fourth child, which is a leaf:
- A('leaf', 2, 1) = '1'(root address) + b(1) + '1' = '1' + '1' +
'1' = 111
- Index l is increased by one and is now equal 2 (l=2)
The first level addresses have now been assigned. Let's now have a
look how the node 10 (the first forwarder child of the root) applies
the same Allocation Function. Note that node 10 will use its own 'f'
and 'l' indexes initialized to 0. Starting again from the left most
node, node 10 applies the AF as follows:
* For the first child, which is a forwarder:
- A('forwarder', 0, 0) = '10'(node address) + b(0) + '0' = '10' +
'' + '0' = 100
- Index f is increased by one and is now equal 1 (f=1)
* For the second child, which is a leaf:
- A('leaf', 1, 0) = '10'(node address) + b(0) + '1' = '10' + '' +
'1' = 101
- Index l is increased by one and is now equal 1 (l=1)
* For the third child, which is a forwarder:
- A('forwarder', 1, 1) = '10'(node address) + b(1) + '0' = '10' +
'1' + '0' = 1010
- Index f is increased by one and is now equal 2 (f=2)
* For the fourth child, which is a leaf:
- A('leaf', 2, 1) = '10'(node address) + b(1) + '1' = '10' + '1'
+ '1' = 1011
- Index l is increased by one and is now equal 2 (l=2)
Note how the children of the same parent all have the same prefix (10
in this example). The proposed AF algorithmically assigns addresses
to the different nodes without the need to know the topology in
advance. However, the largest address of the network will depend on
the actual topology. Indeed, the maximum length of an address with
the proposed AF grows linearly at each level of the tree with the
number of siblings from the same parent. Let's take again the
Li, et al. Expires 27 April 2023 [Page 15]
Internet-Draft PASA October 2022
example in Figure 6 and let's assume that the children of node 10 are
all leaves, for the largest address we need 2 bits to encode the
parent node prefix (10 in this case) to which we need to add a number
of '1' equal to the value of the l index which is the number of
leaves minus one (because the first leaf has index 0), in this case
since there are 4 leaves, the index value is 3 and we add the '111'
string, hence the address length would be 6 (2 for the prefix, 3 to
encode the 4th leaf address, and one for the final 1 the ends all
leaves addresses). In a more formal way the maximum address length
at each level can be calculated as:
Max_Length = length(Parent address)
length(b(max(f,l)))
+ 1
Where f and l are the indexes counting respectively the forwarders
and the leaves at this level.
The Allocation Function can be different from the one defined in
Figure 7, where all nodes know which one to use by configuration.
The use of one and only one AF is allowed in an PASA domain. It is
RECOMMENDED that implementations support at least the AF proposed in
this document (cf. Section 9).
Different allocation functions may, for example, leverage on a priori
knowledge of the topology in order to optimize the maximum address
size and make it smaller. For instance, because the order of address
allocation has an impact on the size, the address of children with
the largest subtree should be allocated in the first place so to
reduce the average address length of the whole subtree. Also,
knowing the traffic in advance, or being able to have an estimation,
can help to minimize the size of addresses that have a lot of
traffic. This kind of optimization can be an option, the
specification of optimizations is out of the scope of this document
and may be defined in new Allocation Functions to be added to the
"Allocation Function Registry" (see Section 9).
Li, et al. Expires 27 April 2023 [Page 16]
Internet-Draft PASA October 2022
5.1. PASA Addresses and IPv6 Addresses
Obtaining a full IPv6 address from a PASA address is pretty
straightforward. First the PASA address is concatenated to the
configured IPv6 prefix. Since the length of the PASA address is
smaller than or equal to 64 bits (the interface ID length in IPv6),
the node needs to pad it with zeros ('0') used as most significant
bits. The full IPv6 address will look like: IPv6 prefix +
"000...000" + PASA (or in IPv6 notation <IPv6 Prefix>::<PASA>). This
is equivalent of doing a coalescence operation as described in
[RFC8138]. The PASA is assigned by the root/forwarder as previously
described.
In an IPv6 communication, the node will derive the PASA address as
the short source address from its own IPv6 address by simply removing
the IPv6 prefix and all leading zeros before the PASA part. The node
will compare the destination IPv6 address with its own IPv6 address.
If they have the same prefix, it means that the destination is in the
local PASA domain and its corresponding PASA address will be
extracted as the short destination address. Otherwise, it will be a
communication towards the Internet. In that case, a mapping
mechanism implemented in the root node will generate a short address
to be mapped to the full IPv6 destination address. For instance, the
mapped short address can be generated using the least significant
bits of the original IPv6 address. As previously stated, the mapping
mechanism is out of the scope of this document.
Since the short mapped address is generated on the root, when the
node first opens the connection toward the external site, the
forwarding of this initial packet toward the root will follow
[RFC9008]. Once the packet arrives at the root node, by performing
the destination address lookup, the root will notice that a full IPv6
address is being used and will trigger the short address generation
mechanism and create a new mapping. Such a mapping is communicated
to the source node via a new dedicated ICMP message (see Section 8).
Once the node originating the communication receives such a message
it SHOULD use the mapped short address for any further communication.
PASA does not prevent the normal checksum calculation for the
transport layer (namely TCP or UDP) or IPSec encapsulation. Indeed,
any PASA node is aware of its full IP address, which can be used for
the calculation. For communication to/from the Internet, PASA nodes
store the mappings between the external remote address and the short
mapped address, hence checksum calculation can be performed as usual.
Li, et al. Expires 27 April 2023 [Page 17]
Internet-Draft PASA October 2022
5.2. Limitation of Number of Children Nodes
The maximum number of child nodes is determined by the specific AF
used. IEEE 802.15.5 has explored the use of a per-branch setup,
which, however, incurs scalability problems [LEE10]. PASA allocation
design is more flexible and extensible than the one proposed in IEEE
802.15.5. The AF used as example in this document does not need any
specific setup network by network, though it is still limited by the
maximum length of addresses. For the special case of the parent
connecting to huge amount of children, a variant of the proposed AF
can be designed to fulfill the requirement and optimize the address
allocation (as previously described).
6. The PASA-6LoRH Header
The PASA encodes path information into addresses to enable stateless
forwarding. Such operation can be performed without touching the
stateful forwarding procedure (based on the presence of a routing
protocol like RPL), aka without modifying the 6LowPAN architecture,
rather leveraging on mechanism already defined. In particular, by
using the 6LowPAN Routing Headers in Page 1, defined in [RFC8138], it
is possible to define an new Critical 6LowPAN Routing Header Type,
named PASA-6loRH, that will be used by nodes to perform stateless
PASA forwarding as described in Section 7.
6.1. PASA-6loRH Sequence
The extension octets typical sequence for a compressed 6LowPAN packet
with PASA Routing Header is shown in Figure 8, following the
specification of [RFC8138].
+-----------+----....----+--------...------+----...----+
| 11110001 | PASA-6LoRH | LOWPAN_IPHC | Payload |
| Page 1 | Type 6 | | |
+-----------+----....----+--------...------+----...----+
Figure 8: A lowPAN encapsulated IPv6 header compressed packet
with PASA-6loRH and LOWPAN_IPC headers
Where:
* PASA-6LoRH: is the PASA specific extension. See Section 6.2 for
details.
* LOWPAN_IPHC: IPv6 compressed header according to [RFC6282].
These two fields are followed by the packet payload.
Li, et al. Expires 27 April 2023 [Page 18]
Internet-Draft PASA October 2022
All nodes of an PASA domain MUST recognize the PASA critical 6LoWPAN
Routing point and be able to handle the packets according to these
specifications. Otherwise, packets can be dropped, hence disrupting
communications.
6.2. PASA-6loRH Format
The format of the PASA-6loRH header, is shown in Figure 9.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 0 | 0 |AddrT. | Size | 6LoRH Type |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Quad 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Quad 2 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
~ ... ~
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Quad N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Where N = Size + 1, and 6LoRH Type = PASA
Figure 9: The PASA 6Lo Routing Header format.
Where:
* Address Type (AddrT.): a two flags field indicating the type of
address in the PASA 6loRH header. The first bit of the filed (bit
3 of the first octet in Figure 9) is named I/O and the second bit
of the field (bit 4 of the first octet in Figure 9) is named MA
and their purpose is as follows:
- I/O: indicates whether this packet is destined to a inner-
domain node (value '1') or an outer-domain node (value '0'),
where the former means from an PASA or IPv6 node to a PASA
destination, while the latter means the packet is sent towards
an external IPv6 destination (see Section 7 for details).
- MA: indicates whether the source address is actually a Mapped
Address generated by the root or not. When it is '1', the
source address of the packet is a mapped address of an external
IPv6 address, while if it is '0', the source address of the
packet is an PASA address belonging to the local domain.
Table 1 summarizes the various combinations of the Address Type
flags.
Li, et al. Expires 27 April 2023 [Page 19]
Internet-Draft PASA October 2022
+-------------+------------------------------------------+
| Addr. Type | Address Type in the PASA 6LoRH header |
+=============+==========================================+
| 00 | Size is set to 15 and Quad 1 to Quad N |
| | carry a full IPv6 address as destination |
+-------------+------------------------------------------+
| 01 | Quad 1 to Quad N carry Mapped Short |
| | Address as destination |
+-------------+------------------------------------------+
| 10 | Quad 1 to Quad N carry PASA as |
| | destination and Source Address |
+-------------+------------------------------------------+
| 11 | Quad 1 to Quad N carry PASA as |
| | destination |
+-------------+------------------------------------------+
Table 1: Destination address type encoding in the
Address Type field.
* Size: indicates the length of the PASA address in quads (i.e. 2
octets). The length N equals Size plus 1, which indicates that
the length of the PASA address in PASA-6LoRH is at least 1 quad (2
octets) and no more than 16 octets (equal to a non compressed IPv6
address).
* Quad 1 .. Quad N: the PASA destination address used for forwarding
purposes. See Section 7 for detailed forwarding operation. PASA
addresses are aligned on the least significant bits. For
instance, to encode the address b1011, which is the address of a
leaf node since it terminates with '1', the corresponding quad
would be b0000000000001011 (or in hexadecimal: 0x000B).
6.3. PASA-6loRH and LOWPAN_IPHC co-existence
In an PASA domain every node has to use PASA the compress/uncompress
PASA addresses according to this specification. The reference prefix
of the PASA domain represents a context that can be used to compress
addresses in accordance to [RFC6282] and decompress using the context
and the coalescence procedure in [RFC8138]. As such the simplest
mode of co-existence of PASA-6loRH with LOWPAN_IPHC is to use
stateful address compression in the LOWPAN_IPHC header using the PASA
context, then the PASA engine can just read the destination address
from the LOWPAN_IPHC header, encoding it in the PASA_6loRH header
according to format previously described in Section 6.2. However,
this mode of operation is sub-optimal because PASA-6loRH already
includes the destination address, it can be completely elided from
the LOWPAN_IPHC header.
Li, et al. Expires 27 April 2023 [Page 20]
Internet-Draft PASA October 2022
For nodes sending packets, the first step is to create a compressed
packet using [RFC6282], where the source addresses is statefully
compressed using the context and the destination address statefully
completely elided. The destination address is then encoded in the
PASA-6loRH in its shorter form, setting the Address Type and Size
accordingly. In case of the destination address is an external
address the corresponding mapped short address (if available) MUST be
used in the PASA- 6loRH header otherwise the address is used at its
full length.
The root node, when relaying a packet coming from outside the PASA
domain, MUST compress the source address in the LOWPAN_IPHC header
using the corresponding mapped short address.
The opposite operations need to be performed on the receiving node.
Since the destination address is completely elided in LOWPAN_IPHC the
IID is obtained by its encapsulation, in this case the PASA-6loRH.
The full destination address, including the IID, can be obtained via
a coalescence operation with the PASA prefix in the context as
described in Section 4.3.1 of [RFC8138]. The same coalescence
operation is done on the source address, in order to have the full
128-bits length. As an example, let's assume that the PASA IPv6
prefix is 2001:db8::/64, as for [RFC8138] the reference address will
be 2001:db8:0:0. Let PASA address in the PASA-6loRH header be
111110, which in hexadecimal is 0x3E, then the complete IPv6 address
is:
2001:db8:0:0:0:0:0:0 Reference address
3E Compressed address
2001:db8:0:0:0:0:0:3E Coalesced address
In compact notation the address is: 2001:db8::3E. In case that the
address to be expanded is a mapped short address, no coalescence
operation is needed, the node will replace the mapped short address
with its associated external IPv6 address.
7. Forwarding in a PASA Network
Internal and external communications in an PASA network work slightly
differently. For internal communications, among PASA endpoints,
packets carry PASA destination addresses in the PASA-6loRH Header.
For external communications, the root is responsible to perform the
translation between PASA addresses and IPv6 addresses. For instance,
for a packet entering into the PASA domain, the root will extract the
PASA of the destination from the suffix of the IPv6 address, reducing
it to the smallest set of quad that can contain the address, by
removing all leading quads that are just equal to 0x0000. It will
also map the source IPv6 address to a mapped short address, in order
Li, et al. Expires 27 April 2023 [Page 21]
Internet-Draft PASA October 2022
to make it more efficient for communication inside the PASA domain.
The the root will compress the original IPv6 and transport header
according to [RFC6282] and prepend the PASA-6loRH header according to
[RFC8138].
The root has to store the mapping between external IPv6 addresses and
their mapped short addresses. The method of generating those mapping
is out of scope of this document, however, the addressing space for
the external short address has to be maintained separate from the
internal PASA address space. Overlap are allowed since the two
addressing spaces are distinguishable in the packets by the use of
the Address Type field, as explained later on.
The following paragraphs will detail the forwarding operations for
both internal and external communication. The intra-network
forwarding decision depends on the specific AF used. Here we will
use the AF previously introduced (see Figure 7) to illustrate the
forwarding procedure.
7.1. Forwarding toward a local PASA endpoint
To perform forwarding operations, PASA nodes access the Address Type
field in the PASA-6loRH header (see Section 6). When the I/O flag
its is 1, the packet is destined to an internal PASA node, so it is
an inner-domain packet. Otherwise, the packet is destined to an
external IPv6 node. It is called an outer-domain packet. Inner-
domain packets carry an PASA destination address in the PASA-6loRH
header. More specifically the destination address field is the
address of another node in the same PASA domain. As such an PASA
node performs the following sequence of actions (also see Figure 10):
1. Get destination address from the PASA-6loRH (abbreviated to DA)
and the current node's address (abbreviated to CA). Go to step
2.
2. If length of DA is smaller than length of CA, send the packet to
parent node, exit. Otherwise, go to step 3.
3. If length of DA equals to length of CA, go to step 4. Otherwise,
go to step 5.
4. If DA and CA are the same, the packet arrived at destination,
exit. Otherwise, send the packet to parent node, exit.
5. Check whether CA is equal to the prefix of DA. If yes, go to
step 6. Otherwise, send the packet to parent node, exit.
Li, et al. Expires 27 April 2023 [Page 22]
Internet-Draft PASA October 2022
6. Calculate which child is the next hop address and forward packet
to it. With the AF proposed in this document, such operation is
reduced to reading the DA's bits starting from the position
equals to the length of CA, then skip all '1' until the first '0'
or the last bit of DA. The sub-string obtained in such a way is
the address of direct child of current node.
7. If any exception happens in the above steps, drop the packet and
send an ICMPv6 "No Route to Host" notification back to the source
address.
Li, et al. Expires 27 April 2023 [Page 23]
Internet-Draft PASA October 2022
/*\ DA:Destination Address
|***| CA:Current Node's Address
\*/
|
+--------+--------+
|Parse DA from pkt|
+--------+--------+
|
\|/
+-------+------+
/ \ yes
| Len(DA)<Len(CA)? |-------------------------------+
\ / |
+-------+------+ |
| no |
\|/ |
+-------+------+ +--------------+ |
/ \ yes / \ no |
| Len(DA)=Len(CA)? |------>| CA == DA ? |--->+
\ / \ / |
+-------+------+ +-------+------+ |
| no | yes |
\|/ /*\ |
+-------+------+ |***| |
/ \ no \*/ |
| CA==PrefixOf(DA)?|------------------------------>+
\ / |
+-------+------+ |
| yes |
\|/ \|/
+---------+---------+ +---------+---------+
| Calculate next-hop| | Forward to Parent |
| & | +---------+---------+
| Forward | |
+---------+---------+ |
|<---------------------------------------+
\|/
/*\
|***|
\*/
Figure 10: Flow Chart of Internal Forwarding Procedure
In the case of packets arriving from the Internet (external IPv6
domain toward the local PASA domain) header adaptation operation is
performed by the root node. It first compresses the IPv6 header
according to [RFC6282] and also described in Section 6.3. It checks
whether it exists already a mapping between the source address and a
Li, et al. Expires 27 April 2023 [Page 24]
Internet-Draft PASA October 2022
mapped PASA address to be used as source address in the PASA-6loRH
header. If not it creates one. Concerning the destination address,
the root builds the PASA address of the destination by removing the
prefix and the leading '0's quads of the suffix of the destination
address. Then the root creates the inner-domain packet with the
PASA-6loRH header. It uses the PASA address as destination setting
the I/O field to 1 so to route the packet to as described above to
the destination node. The mapped PASA address is used as source
address and the fact that is a Mapped Address is signaled by setting
to 1 the MA field, hence having globally the Address Type field set
to 11.
7.2. Forwarding toward an external IPv6 node
In the case that the I/O field (cf. Section 6) is set to 0, the
packet is destined to an external IPv6 node, it is an outer-domain
packet. As such the destination address in the PASA-6loRH header a
mapped short address generated by the root node and not belonging to
any node inside the PASA domain.
All PASA nodes (except root) just send packets that are destined
outside the local domain (I/O field equal 0) to their parent, not
even looking at the actual destination address. Eventually all
packets will reach the root node, which acts as gateway. The root
node is able to map the destination PASA address to the corresponding
full IPv6 address.
For the first packet of a connection, when there is not yet a mapped
short address assigned by the root, the forwarding procedure of
[RFC9008] are used.
8. PASA Control Messages
8.1. New Control Message
This documents specifies only one new ICMPv6 PASA Control Message,
namely the PASA Mapped Address Advertisement described in Section 5.
The purpose of such a message is communicate the mapping of an IPv6
address into a PASA address. The map is performed by the root node
and sent to the node originating the communication encapsulated
according to 6LowPAN specification and the PASA-6loRH header defined
in this document. The root and the node originating the
communication keep a copy of the mapping to be used for future
packets. The format is shown in Figure 11.
Li, et al. Expires 27 April 2023 [Page 25]
Internet-Draft PASA October 2022
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code = 0x00 | Reserved | PASA Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target IPv6 Address (Fixed length 128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target PASA Address (Variable length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ICMPv6 PASA Control Message
Where:
* Type: Type value identifying PASA Control Message. Value to be
assigned by IANA (cf. Section 9)
* Code: This field identifies the specific control message. In this
case it is set to the value 0x00 "PASA Mapped Address for External
IPv6 Address".
* Reserved: It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.
* PASA Length: This field indicates the length of the Target PASA
Address at the end of the message, expressed in octets.
The "PASA Mapped Address for External IPv6 Address" is a variable
length message, however, the first five fields of the message, namely
Type, Code Reserved, PASA Length, and Target IPv6 address, have a
fixed length of 160 bits (20 octets), hence the length of the PASA
address is sufficient to calculate the length of the entire packet:
20 octets + "PASA length".
8.2. Address Configuration based on 6LOWPAN-ND
According to [RFC6775], neighbor discovery is available in 6LowPANs.
This document specifies PASA address configuration mechanism based on
RS (Router Solicitation) and solicited RA (Router Advertisement)
defined in [RFC4861]. In order for an PASA node to request an
address, it uses a newly defined 'PASA Request Address Option (PRAO)'
in RS messages. The corresponding solicited RA will contain the
'PASA Assign Address Option (PAAO)' with the assigned address. These
messages use link-local addresses or multicast addresses that do not
need to be encapsulated with a PASA-6loRH header.
Li, et al. Expires 27 April 2023 [Page 26]
Internet-Draft PASA October 2022
8.2.1. PASA Request Address Option (PRAO) Format
This option will be carried in RS messages [RFC4861] when node
initializes. The same RS messages MUST carry the Source Link-Layer
Address Option (SLLAO) ([RFC4861], [RFC6775]) as well. The link-
layer address in SLLAO (Source Link-Layer Address Option will be used
to identify unique PASA node. The PRAO option, respecting the
specifications in [RFC6775], has the format shown in Figure 12.
+---------------+--------------+-------------------------------+
| Type | Length | Expected Address Lifetime |
+---------------+--------------+-------------------------------+
| Reserved |
+--------------------------------------------------------------+
Figure 12: PASA Request Address Option Format
Where:
* Type: 136 (see Section 9).
* Length: 8-bit unsigned integer. The length of the option
(including the Type and Length fields) in units of 8 octets. This
field is always set to 1.
* Expected Address Lifetime: The sender of the RS message notifies
the node that assigns the address for how long is expected to be
valid. The receiver MAY ignore this field. As for [RFC6775] the
unit is set to 60 seconds (1 minute). This field MUST be set to
zero by sender if there is no requirement on the lifetime.
* Reserved: This field is not used. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
8.2.2. PASA Assign Address Option (PAAO) Format
This option will be carried in the RA message solicited by the an RS
message as for the usual Neighbor Discovery workflow. The PAAO
option, respecting the specifications in [RFC6775], has the format
depicted in Figure 13.
Li, et al. Expires 27 April 2023 [Page 27]
Internet-Draft PASA October 2022
+---------------+--------------+-------------------------------+
| Type | Length | Address Lifetime |
+---------------+--------------+-------------------------------+
| Prefix Length | Reserved |
+---------------+----------------------------------------------+
| |
| |
| |
| PASA with IPv6 Prefix |
| |
| |
| |
+--------------------------------------------------------------+
Figure 13: PASA Assign Address Option Format
Where:
* Type: 137 (see Section 9).
* Length: 8-bit unsigned integer. The length of the option
(including the Type and Length fields) in units of 8 octets. This
field is always set to the value 3.
* Address Lifetime: The maximum time for the PASA being valid. As
for [RFC6775] the unit is set to 60 seconds (1 minute). The node
with this address MUST stop using this address for packet
transmission when the life time expires. When the Address
Lifetime is zero, the node must drop the address immediately.
When the lifetime field is 0xFFFF, the address will be valid
forever until the node sends another PAAO to update the lifetime.
* Prefix Length: This field will notifies the receiver the length of
the IPv6 prefix, expressed in octets.
* Reserved: This field is not used. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
* PASA with IPv6 Prefix: This field is filled by the node with the
IPv6 prefix (according with the length field), the PASA address as
the least significant bits of the IPv6 address, and padding the
remaining bits in the middle with zeros.
9. IANA Considerations
Li, et al. Expires 27 April 2023 [Page 28]
Internet-Draft PASA October 2022
9.1. Critical 6LoWPAN Routing Header Type for PASA-6LoRH
This document requires IANA to assign one value of the "Critical
6LoWPAN Routing Header Type" registry, to be used according to the
specification in this document, as shown in Table 2. [Note to RFC
Editor: If IANA assign different values the authors will update the
document accordingly]
+-------+-------------+-----------------+
| Value | Description | Reference |
+=======+=============+=================+
| 6 | PASA-6LoRH | [This Document] |
+-------+-------------+-----------------+
Table 2: Critical 6LoWPAN Routing
Header Type for PASA
9.2. Allocation Function Registry
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the PASA
specification, in accordance with BCP 26 [RFC8126].
IANA is asked to create a registry named "Path-Aware Semantic
Addressing (PASA) Parameters".
Such registry should be populated with a one octet sub registry named
"Allocation Function" and used to identify the AF used in a PASA
deployment. The sub registry is populated as shown in Table 3:
+-----------+--------------------------+-----------------+
| Value | AF Name | Reference |
+===========+==========================+=================+
| 0x00 | PASA Allocation Function | [This Document] |
+-----------+--------------------------+-----------------+
| 0x01-0xFF | Un-assigned | |
+-----------+--------------------------+-----------------+
Table 3: Allocation Function sub-registry
Values can be assigned by IANA on a "First Come, First Served" basis
according to [RFC8126].
9.3. ICMP PASA Control Message
IANA is requested to allocate an ICMPv6 type value from the "ICMPv6
Parameters" registry to be used by "PASA Control Message".
Li, et al. Expires 27 April 2023 [Page 29]
Internet-Draft PASA October 2022
Also IANA is requested to create an "PASA Control Codes" sub
registry, for the Code field of the ICMPv6 PASA Control Message.
New codes are allocated through the "Specification Required"
procedure as defined in [RFC8126]. The initial content of the
registry is shown in Table 4.
+-----------+-------------------------+-----------+
| Code | Description | Reference |
+===========+=========================+===========+
| 0x00 | PASA Mapped Address for | [This |
| | External IPv6 Address | Document] |
+-----------+-------------------------+-----------+
| 0x01-0xFF | Un-assigned | |
+-----------+-------------------------+-----------+
Table 4: Control Codes for PASA type
9.4. PASA Neighbor Discovery Options
IANA is requested to allocate two values from the "IPv6 Neighbor
Discovery Option Formats" registry to be used by PRAO and PAAO as
shown in Table 5. [Note to RFC Editor: If IANA assign different
values the authors will update the document accordingly]
+------+-----------------------------+-----------------+
| Code | Description | Reference |
+======+=============================+=================+
| 136 | PASA Request Address Option | [This Document] |
+------+-----------------------------+-----------------+
| 137 | PASA Assign Address Option | [This Document] |
+------+-----------------------------+-----------------+
Table 5: PASA Neighbor Discovery Options
10. Reliability Considerations
Because PASA uses algorithmically generated addresses based on the
network topology, nodes do not generate and store forwarding table
entries in the normal case. One of the potential issues is the risk
of renumbering of addresses in case of topology changes. Because of
the applicability domain of PASA, the common case of topology change
is known in advance and can be planned, so to reduce disruption due
to renumbering. Another case is temporary link failures, where the
underlying technology is still able to provide connectivity through
alternative links, which is strictly related to the underlying
technology, the network topology, the deployed redundancy, and the
expected reliability.
Li, et al. Expires 27 April 2023 [Page 30]
Internet-Draft PASA October 2022
More complex reliability scenarios and alternative solutions are
beyond the scope of this document, which is focused only on the
address allocation framework and stateless forwarding. Furthermore,
specific reliability solutions can depend as well on the specific
Allocation Function used (different from the one presented in this
document). Reliability is discussed in more details in
[I-D.li-6lo-pasa-reliability].
11. 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], [RFC8066] apply.
Acknowledgements
This document received many discussion and help from community
people. Dominique Barthel, Adnan Rashid, Michael Richardson, provide
technical comments for this document. There are other people helped
on improving this document who want to be unnamed. The authors would
present thanks to all of them.
References
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>.
[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>.
[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>.
Li, et al. Expires 27 April 2023 [Page 31]
Internet-Draft PASA October 2022
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J.
Woodyatt, "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) ESC Dispatch Code Points and
Guidelines", RFC 8066, DOI 10.17487/RFC8066, February
2017, <https://www.rfc-editor.org/info/rfc8066>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[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>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
Informative References
[I-D.ietf-6lo-plc]
Hou, J., Liu, B. R., Hong, Y., Tang, X., and C. E.
Perkins, "Transmission of IPv6 Packets over PLC Networks",
Work in Progress, Internet-Draft, draft-ietf-6lo-plc-11,
18 May 2022, <https://www.ietf.org/archive/id/draft-ietf-
6lo-plc-11.txt>.
[I-D.ietf-6lo-use-cases]
Hong, Y., Gomez, C., Sangi, A. R., and S. Chakrabarti,
"IPv6 over Constrained Node Networks (6lo) Applicability &
Use cases", Work in Progress, Internet-Draft, draft-ietf-
6lo-use-cases-13, 11 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-6lo-use-cases-
13.txt>.
Li, et al. Expires 27 April 2023 [Page 32]
Internet-Draft PASA October 2022
[I-D.li-6lo-pasa-reliability]
Li, G., Lou, Z., and L. Iannone, "Reliability
Considerations of Path-Aware Semantic Addressing", Work in
Progress, Internet-Draft, draft-li-6lo-pasa-reliability-
00, 24 October 2022, <https://www.ietf.org/archive/id/
draft-li-6lo-pasa-reliability-00.txt>.
[LEE10] Lee, M., Zhang, R., Zheng, J., Ahn, G., Zhu, C., Park, T.,
Cho, S., Shin, C., and J. Ryu, "IEEE 802.15.5 WPAN mesh
standard-low rate part: Meshing the wireless sensor
networks", DOI 10.1109/jsac.2010.100902, IEEE Journal on
Selected Areas in Communications vol. 28, no. 7, pp.
973-983, September 2010,
<https://doi.org/10.1109/jsac.2010.100902>.
[LPWAN] "IPv6 over Low Power Wide-Area Networks (lpwan) WG", n.d.,
<https://datatracker.ietf.org/wg/lpwan/about/>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "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>.
[RS485] "TIA-485-A Revision of EIA-485", n.d..
[SIXLO] "IPv6 over Networks of Resource-constrained Nodes (6lo)
WG", n.d., <https://datatracker.ietf.org/wg/6lo/about/>.
Li, et al. Expires 27 April 2023 [Page 33]
Internet-Draft PASA October 2022
[SIXLOWPAN]
"IPv6 over Low power WPAN (6lowpan) - Concluded WG", n.d.,
<https://datatracker.ietf.org/wg/6lowpan/about/>.
[ZigBee] "ZigBee Wireless Networks and Transceivers",
DOI 10.1016/b978-0-7506-8393-7.x0001-5, Elsevier book,
2008,
<https://doi.org/10.1016/b978-0-7506-8393-7.x0001-5>.
Authors' Addresses
Guangpeng Li
Huawei Technologies
Beiqing Road, Haidian District
Beijing
100095
China
Email: liguangpeng@huawei.com
David Lou
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: zhe.lou@huawei.com
Luigi Iannone
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: luigi.iannone@huawei.com
Peng Liu
China Mobile
No. 53, Xibianmen Inner Street, Xicheng District
Beijing
100053
China
Email: liupengyjy@chinamobile.com
Li, et al. Expires 27 April 2023 [Page 34]
Internet-Draft PASA October 2022
Rong Long
China Mobile
No. 53, Xibianmen Inner Street, Xicheng District
Beijing
100053
China
Email: longrong@chinamobile.com
Kiran Makhijani
Futurewei
United States of America
Email: kiranm@futurewei.com
Pascal Thubert
Cisco Systems, Inc.
France
Email: pthubert@cisco.com
Li, et al. Expires 27 April 2023 [Page 35]