Internet DRAFT - draft-li-6lo-pasa-reliability
draft-li-6lo-pasa-reliability
6lo Working Group G. Li
Internet-Draft D. Lou
Intended status: Informational L. Iannone
Expires: 5 September 2024 Huawei
4 March 2024
Reliability Considerations of Path-Aware Semantic Addressing
draft-li-6lo-pasa-reliability-03
Abstract
Path-Aware Semantic Address (PASA), proposes to algorithmically
assign addresses to nodes in a 6lo environment so to achieve
stateless forwarding, hence, allowing to avoid using a routing
protocol. PASA is more suitable for stable and static wireline
connectivity, in order to avoid renumbering due to topology changes.
Even in such kind of scenarios, reliability remains a concern. This
memo tackles specifically reliability in PASA deployments, analyzing
possible broad solution categories to solve the issue.
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 5 September 2024.
Copyright Notice
Copyright (c) 2024 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
Li, et al. Expires 5 September 2024 [Page 1]
Internet-Draft PASA Reliability March 2024
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 2
2. Solution Alternatives . . . . . . . . . . . . . . . . . . . . 3
3. Multi-Address Approach . . . . . . . . . . . . . . . . . . . 4
3.1. Topology Building . . . . . . . . . . . . . . . . . . . . 4
3.2. Link Failures . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Link Failure Example . . . . . . . . . . . . . . . . 10
3.3. Node Failures . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Node Failure Example . . . . . . . . . . . . . . . . 12
3.4. Node Forwarding Procedure . . . . . . . . . . . . . . . . 14
3.4.1. PASA Router Operation . . . . . . . . . . . . . . . . 14
3.4.2. PASA Root Operation . . . . . . . . . . . . . . . . . 15
4. Single-Address Approach . . . . . . . . . . . . . . . . . . . 16
4.1. Topology Building . . . . . . . . . . . . . . . . . . . . 16
4.2. Link Failures . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Node Failures . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Node Forwarding Procedure . . . . . . . . . . . . . . . . 20
4.4.1. PASA Router Operation . . . . . . . . . . . . . . . . 20
4.4.2. PASA Root Operation . . . . . . . . . . . . . . . . . 21
5. Links/Nodes Failure Detection and Recovery . . . . . . . . . 22
6. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction and Problem Statement
The common characteristic of various topological addressing schemes
([I-D.daniel-6lowpan-hilow-hierarchical-routing],
[I-D.ietf-6lo-path-aware-semantic-addressing], [KIM07]) is the
possibility of nodes to forward packets without the need of discovery
the whole network topology using routing protocols. In such context
the addresses are built in such a way that a node is capable of
forwarding a packet to the next hop by comparing the destination
address either with its own address or with the address of its
neighbors. It is not required to build a routing table for the whole
topology, on which to execute look-up algorithms, only neighbor
awareness is sufficient.
Li, et al. Expires 5 September 2024 [Page 2]
Internet-Draft PASA Reliability March 2024
This kind of stateless forwarding typically works in a simple
topology with static paths, because high resiliency is hard to
achieve. Once a link (or a node) fails, the traffic may become
impossible to forward, and packets are dropped, even in the presence
of alternative physical paths. Indeed, in order to use these
alternative paths renumbering is necessary to (re)build an
alternative logical topology. Such a solution, while looking as a
simple operation, may be not enough, and is complicate in practice,
since it implies to put the system offline during the renumbering
process. What is desirable is to have some mechanisms to quickly
enable the usage of alternative paths with little extra effort,
without the need to put the system offline, hence providing higher
resiliency.
The present memo focuses on how increase resiliency in the specific
context of Path-Aware Semantic Address (PASA) networks, analyzing two
possible approaches. As such this document assumes that the reader
is familiar with [I-D.ietf-6lo-path-aware-semantic-addressing].
2. Solution Alternatives
In order to improve the reliability of the system, the pre-requisite
is to have redundant links. This means that nodes are likely
connected in a meshed fashion, where some of the links are actively
used, and others not. In a normal situation, in the context of PASA,
the actively used links form a tree. This is the same concept of
spanning trees used in layer 2 technologies (e.g. [IEEE802.1W]).
When a problem is detected, various possibilities arise in order to
logically guarantee connectivity by starting using previously unused
links. In the specific case of PASA
[I-D.ietf-6lo-path-aware-semantic-addressing], the assumption is that
all nodes, except the root, have at least one secondary parent, which
will only be used if the primary one is not reachable. In this way,
when the link toward the primary parent is broken, an alternative
link toward a secondary parent can be used. In such context two
different approaches can be identified:
* Multi-Address: using multiple addresses per node, one for each
alternative parent (logically creating multiple topologies).
* Single-Address: using one single address per node, even if an
alternative parent is present. The single address of the node
comes from his primary parent.
Both approaches, with their pros and cons, are described and analyzed
hereafter.
Li, et al. Expires 5 September 2024 [Page 3]
Internet-Draft PASA Reliability March 2024
3. Multi-Address Approach
In the multi-address case, multiple logical topologies are built by
using different addresses and different links. This is equivalent of
using several contexts of Virtual Routing and Forwarding (VRF). In
the following it is assumed that two logical topologies are built on
top of the physical connectivity, however, the principles can be
easily extended to more than two logical topologies.
3.1. Topology Building
In the multi-address case, two root nodes are used. Each root node
is the root of a different tree covering all the nodes. The Address
Assignment Function (AAF) used to assign addresses in the two
parallel topologies might differ. However, attention should be given
to guarantee that addresses in the two topologies are different and
not overlapping. in the specific case of PASA, this can be easily
achieved by using two different addresses for the root nodes.
Indeed, such addresses will be the prefix of the whole tree, which
also means that the address of the root nodes can be used to actually
identify the different topologies. For both topologies, the address
allocation procedure works in the exact same way as described in
[I-D.ietf-6lo-path-aware-semantic-addressing], the only additional
action to be taken is that a node cannot choose the same parent node
in both topologies. This can be easily achieved by imposing that two
parents must not have the same "node-id".
Let us make a simple example with the topology depicted in Figure 1,
where there are two root nodes, named "R-1" and "R-2" and a set of
few nodes N-XY, where X represent the depth in the tree and Y a
unique number for that level of the tree. Physical links are not
depicted in the figure but, as already mentioned, the assumption is
that each node is connected at least to two potential parents.
Li, et al. Expires 5 September 2024 [Page 4]
Internet-Draft PASA Reliability March 2024
+---+ +---+
|R-1| |R-2|
+---+ +---+
+----+ +----+ +----+ +----+
|N-11| |N-12| |N-13| |N-14|
+----+ +----+ +----+ +----+
+----+ +----+ +----+
|N-21| |N-22| |N-23|
+----+ +----+ +----+
+----+ +----+ +----+
|N-31| |N-32| |N-33|
+----+ +----+ +----+
Figure 1: Simple Topology example.
Let us also assume that R-1 has the address 1, which is used to
allocate the address to other nodes. After applying the allocation
function presented in [I-D.ietf-6lo-path-aware-semantic-addressing],
a possible outcome is the one presented in Figure 2, where the links
selected to form the logical topology are shown, as well as the
assigned addresses.
+---+ +---+
| 1|----------+ |R-2|
+---+-----+ \ +---+
/ \ \ \
/ \ \ \
+---+ +---+ +----+ +----+
| 10| | 11| | 111| |1111|
+---+ +---+ +----+ +----+
/ \ \
/ \ +------+
/ \ \
+----+ +----+ +-----+
| 100| | 101| | 1011|
+----+ +----+ +-----+
/ \ \
/ \ +-----------+
/ \ \
+----+ +-----+ +------+
|1001| |10011| |100111|
+----+ +-----+ +------+
Figure 2: Possible PASA assignment and logical topology using R-1
as root.
Li, et al. Expires 5 September 2024 [Page 5]
Internet-Draft PASA Reliability March 2024
In a similar way, assuming root R-2 has the address 01, and again
applying the allocation function presented in
[I-D.ietf-6lo-path-aware-semantic-addressing], a possible outcome is
the one presented in Figure 3, where the links selected to form the
second logical topology are shown, as well as the assigned addresses.
+---+ +---+
|R-1| +-----------| 01|
+---+ / +------+---+
/ / / \
/ / / \
+---+ +----+ +---+ +-----+
|011| |0111| |010| |01111|
+---+ +----+ +---+ +-----+
/ / |
+----------+ / |
/ +---+ |
/ / |
+-----+ +-----+ +------+
| 0101| |01011| | 0100 |
+-----+ +-----+ +------+
/ / |
+----------+ / |
/ +---+ |
/ / |
+-----+ +------+ +-------+
|01001| |010011| |0100111|
+-----+ +------+ +-------+
Figure 3: Possible PASA assignment and logical topology using R-2
as root.
When everything is working without problem, one of the logical
topologies can be used as primary topology, while using the second
one only in case of link/node failures. A simple selection can be
done for example with the rule:
* Interpreting root nodes' addresses as integers, and choosing the
tree with the smallest value.
Li, et al. Expires 5 September 2024 [Page 6]
Internet-Draft PASA Reliability March 2024
Another approach could be trying to use some load balancing
approaches, where sockets open on the various nodes are bound to one
of the available addresses based on some algorithms. The algorithm
can be as simple as a random choice. However, it has to be
considered that random local choices can uniformly distribute
connections on different addresses, but it does not mean that the
traffic is uniformly distributed on the network as a whole [SINGH20].
Such kind of optimization algorithms are out of the scope of this
document. In the following, it is assumed that a primary/secondary
approach is used, where the topology in Figure 2 is the primary one.
As described in [I-D.ietf-6lo-path-aware-semantic-addressing],
rebuilding the full IPv6 address from the PASA address is simply done
via a coalescence operation with the PASA prefix (cf. Section 4.3.1
of [RFC8138]). The opposite operation, obtaining the corresponding
PASA address from an IPv6 address is done by removing the /64 PASA
prefix and then, in the remaining suffix, all leading zeros are also
removed. When using multiple addresses, the latter procedure is not
sufficient anymore. Taking the example in Figure 3, nodes have to be
aware that the root node has actually a two-bits address, namely
"01". In order to maintain the simplicity of the design of PASA, the
addresses of root nodes can be assigned as follows:
* Each root has an address where the least significant bit is set to
1 and all the others to zero.
* Each root has a different address length that has to be known.
* An address length of 1, means no leading zeros.
* An address length of n, means n-1 leading zeros followed by 1.
Coming back to the example, root R-1, has an address length equal to
1, hence its address is "1", as depicted in Figure 2, while R-2 has
an address length equal to 2, hence its address is "01", as depicted
in Figure 3. PASA Hosts and PASA Routers need to be aware of the
PASA Root address length. For instance, the PASA Hosts at the bottom
of Figure 3 need to know that the root address length is 2, so that
their addresses start with 01. Hence, the only requirement imposed
by this solution on the nodes is to allow addresses that start with
zeros and explicitly know the PASA Root's address length
([I-D.ietf-6lo-path-aware-semantic-addressing] only specifies
addresses starting with 1 and the root's address length is implicitly
always one).
Li, et al. Expires 5 September 2024 [Page 7]
Internet-Draft PASA Reliability March 2024
3.2. Link Failures
In case of link failure, there are three actions that need to be
taken in order to ensure connectivity.
1. The parent node, with respect to the link in object (the one
failed), has to inform all the nodes between itself and the root
that a certain sub-tree is not reachable anymore through it, when
using the primary topology. This can be achieved by sending an
ICMPv6 message announcing the sub-tree unreachability status. To
this end, the link's parent node sends such a message to its
parent, which will store the unreachable status of the sub-tree
prefix, and additionally it will also forward the same message to
its own parent. Recursively, eventually, the root will receive
the same message and store the unreachable status of the sub-tree
prefix. In this way, packets destined to that sub-tree are
actually re-directed toward the root. After this procedure, when
a node sees a packet that is destined to the node in the
unreachable sub-tree, it sends it up to the root.
2. The child node, with respect to the failed link, has to inform
the root that its sub-tree can still be reached, if traffic is
sent through the secondary topology, by using the secondary
address of this node. This can be achieved by sending an ICMPv6
message toward the root of the secondary tree, hence using the
secondary address as a source of the message. The secondary root
will then forward the message, to the root of the primary tree.
With this operation the root of the primary tree is now aware
that to reach a certain sub-tree, traffic has to be sent through
the secondary tree to a specific address (the secondary address
of the child on the broken link). In order to actually ship a
packet destined to an address in the primary tree through the
secondary tree, two options are possible: encapsulation or
routing.
Li, et al. Expires 5 September 2024 [Page 8]
Internet-Draft PASA Reliability March 2024
* Encapsulation is pretty simple. Whenever there is a packet
destined to the sub-tree with a redirect entry on the primary
root, the root encapsulates (tunnels) the packet to the
secondary address of the child node of the broken link and
sends it to the secondary root. The packet will be forwarded
according to the stateless PASA procedure until it reaches the
intended node. There, it is decapsulated and the original
packet is routed in the sub-tree until its final destination.
In the other direction, all packets coming from the sub-tree
can be encapsulated toward the secondary root, using the
procedure described in
[I-D.ietf-6lo-path-aware-semantic-addressing]. The secondary
root will forward the packet to the primary root if the
destination address is in the primary topology. In this way
the broken link is circumvented.
* Routing relies on some forwarding entries stored on the nodes
along the path on the secondary tree. Basically, when the
ICMPv6 message, sent by the child node of the broken link, is
forwarded along the secondary tree using the same recursive
approach previously described, each node along the path stores
the information that they are part of a forwarding path toward
the sub-tree specified in the ICMPv6 message itself. In this
way, no additional encapsulation is necessary, since the
packet can be forwarded from the primary root to the secondary
root, who in turn will forward it to the child from which it
received the ICMPv6 message, and so on until the message
reaches the sub-tree where it is forwarded using the normal
PASA stateless forwarding. In the opposite direction, for
packets coming from the sub-tree, nodes along the alternate
path on the secondary tree will simply forward the packets to
the secondary PASA Root, who will forward them to the primary
PASA Root.
The first solution (encapsulation) may increase the likelihood
to have Maximum Transmission Unit (MTU) issues. Indeed, an
additional encapsulation will increase the packet size.
Furthermore, packets need as well to undergo several header
compression/decompression operations which will increase the
latency and consume more energy. The second solution does not
create overhead, but needs to store state in nodes along the
alternative paths. The number of entries is certainly
limited, because it is just the number of sub-trees
unreachable through the primary tree and using the node as
part of the alternative path. However, this may be an issue
on devices with strong memory constraints. Yet, if the state
grows bigger, it is the symptom of massive failures in the
network, which may be a far bigger and more urgent problem.
Li, et al. Expires 5 September 2024 [Page 9]
Internet-Draft PASA Reliability March 2024
In both cases the root nodes have to keep some state, namely
the redirection rules for all unreachable sub-trees. This is
not a problem since root gateways are usually more powerful
than the other nodes and do not run on batteries. However, if
the number of entries grows large, this is again a symptom of
massive failures.
3. Optionally, for optimization purposes, the child node, with
respect to the link in object, may inform all the nodes of its
sub-tree that they should start using the secondary tree (i.e.
the secondary address). This can be achieved by sending specific
ICMPv6 messages to all of its children, who will do the same
recursively. In this way communications will take advantage from
the stateless forwarding. However, communication using the
primary address, with the mechanism described in the previous
points must still be supported, for ongoing communications that
would otherwise break and for any communication initiated from
the Internet toward and address in the primary tree. For
instance, because only primary addresses are shared publicly (via
DNS or other means).
All of the above-mentioned ICMPv6 messages are forwarded using PASA
stateless forwarding procedure as for
[I-D.ietf-6lo-path-aware-semantic-addressing].
3.2.1. Link Failure Example
Using the example previously introduced in Figure 1, let us assume
that the link between N-11 and N-21 breaks. This means that in the
primary topology (see Figure 2) the link between nodes 10 and 100 is
broken. According the procedure presented above, the following
action are taken:
1. 10 sends an ICMPv6 message to the PASA Root. The latter will
register that 100-sub-tree is not reachable through 10. Messages
have to be redirected.
2. 100 sends an ICMPv6 message to 01 (root of the secondary tree)
using 0101 as source address (see Figure 3) using the recursive
procedure through node 010. Once this message reaches 01, the
PASA Root of the secondary tree, it will be forwarded to 1, the
PASA Root of the primary tree. Now PASA Root 1 has an entry
stating:
* For 100-sub-tree encapsulate to 0101 and forward to 01
3. 100 will send an ICMPv6 message to its children suggesting to use
their secondary addresses.
Li, et al. Expires 5 September 2024 [Page 10]
Internet-Draft PASA Reliability March 2024
At this point connection is guaranteed. Let us assume the in the
primary tree (see Figure 2) nodes 11 and 1001 where communicating to
each other. Packets will flow in the following path:
* From 11 to 1001:
1. Packet is transmitted from 11 to 1 (on the primary tree).
2. Because of the redirect entry, 1 encapsulates packet toward
100 using its secondary address 0101 and then transmits it to
01 (root secondary).
3. 01 will use PASA stateless forwarding to transmit the packet
to 010 (on the secondary tree).
4. 010 will use PASA stateless forwarding to transmit the packet
to 0101 (on the secondary tree).
5. 0101 will decapsulate, note the destination is on the primary
tree, use the PASA stateless forwarding to transmit the packet
to 1001 (on the primary tree).
* From 1001 to 11:
1. Packet is transmitted from 1001 to 100 (on the primary tree).
2. Because 100 knows the upstream link is broken it encapsulates
the packet with source 0101 and destination 01 (root primary
tree) then transmits the packet to 010 (on the secondary
tree).
3. 010 will use PASA stateless forwarding to transmit the packet
to 01 (on the secondary tree).
4. 01 will decapsulate and see that packet is destined a node in
the primary tree and transmits it to 1.
5. 1 will use the PASA stateless forwarding to transmit the
packet to 11 (on the primary tree).
In case of communication toward/from outside the local PASA domain
the procedure is similar. For outgoing packets, the primary PASA
Root will forward the packet upstream. For incoming packets, the
PASA Root will firstly reduce the IPv6 header to a PASA header, then
forwards it as described above. PASA header expansion and IPv6
header reduction are operations described in
[I-D.ietf-6lo-path-aware-semantic-addressing].
Li, et al. Expires 5 September 2024 [Page 11]
Internet-Draft PASA Reliability March 2024
3.3. Node Failures
In case that an entire node fails, several links will not be usable
anymore. Nevertheless, the procedure described in the previous
section can be still applied, what changes is which node is
performing the action. More specifically:
1. The parent of the failed node, has to inform all the nodes
between itself and the root that a certain sub-tree is not
reachable anymore through it. This is the exact same procedure
like in Section 3.2.
2. All of the children of the failed node, have to independently
inform the root that its sub-tree can still be reached if traffic
is sent through the secondary topology, using the secondary
address of the node that is the root of the sub-tree. This is
the exact same procedure like in Section 3.2, just done by all
children.
3. All of the children of the node, optionally, for optimization
purposes, may inform all the nodes of their sub-trees that they
should start use the secondary tree (i.e. the secondary address).
This is the exact same procedure like in Section 3.2, just done
by all children.
3.3.1. Node Failure Example
Using again the example previously introduced, let us assume that
node N-21 in Figure 1 fails. This means that in the primary topology
(see Figure 2) the links between nodes 10 and 100 is unusable, as
well as the links between 100 and its three children, namely 1001,
10011, and 100111. According the procedure presented above, the
following action are taken:
1. 10 sends an ICMPv6 message to the primary PASA Root. The latter
will register that 100-sub-tree is not reachable through 10 but
has to be redirected.
2. The three children of 100 will perform the following:
* 1001 sends an ICMPv6 message to 01 (root of secondary tree)
using 01001 as source address (see Figure 3). This message
will then be forwarded to 1, the PASA Root of the primary
tree. Now PASA Root 1 has an entry stating:
- For 1001-sub-tree encapsulate to 01001 and forward to 01
Li, et al. Expires 5 September 2024 [Page 12]
Internet-Draft PASA Reliability March 2024
* 10011 sends an ICMPv6 message to 01 (root of secondary tree)
using 010011 as source address (see Figure 3). This message
will then be forwarded to 1, the PASA Root of the primary
tree. Now PASA Root 1 has an entry stating:
- For 10011-sub-tree encapsulate to 010011 and forward to 01
* 100111 sends an ICMPv6 message to 01 (root of secondary tree)
using 0100111 as source address (see Figure 3). This message
will then be forwarded to 1, the PASA Root of the primary
tree. Now PASA Root 1 has an entry stating:
- For 100111-sub-tree encapsulate to 0100111 and forward to
01
At this point connection is guaranteed. Let us assume, like in the
example for the link failure, that in the primary tree (see Figure 2)
nodes 11 and 1001 where communicating to each other. Packets will
flow in the following path:
* From 11 to 1001:
1. Packet is transmitted from 11 to 1 (on the primary tree).
2. Because of the redirect entry, 1 encapsulates packet toward
1001 using its secondary address 01001 and then transmits it
to 01 (root secondary).
3. 01 will use PASA stateless forwarding to transmit the packet
to 01001 (on the secondary tree).
4. 01001 will decapsulate, note the destination is its own
primary address, the packet will be decapsulate once more and
delivered to the upper layer.
* From 1001 to 11:
1. Because 1001 knows the upstream link is broken it encapsulates
the packet with source 01001 and destination 01 (root
secondary tree).
2. 01 will see that packet is destined to a node in the primary
tree and transmits it to 1.
3. 1 will use the PASA stateless forwarding to transmit the
packet to 11 (on the primary tree).
Li, et al. Expires 5 September 2024 [Page 13]
Internet-Draft PASA Reliability March 2024
In case of communication toward/from outside the local PASA domain,
the procedure is the same as described in Section 3.2.
3.4. Node Forwarding Procedure
Nodes, have to forward packets according to the procedures described
in the previous sections. Nevertheless, compared to the original
specification the modifications are very limited. Hereafter, the
forwarding procedure for both PASA Routers and PASA Root is provided.
The mention "PASA Native Forwarding" is used where the original
procedure described in [I-D.ietf-6lo-path-aware-semantic-addressing]
is employed.
3.4.1. PASA Router Operation
As described in Figure 4, in the context of multiple topologies, when
a PASA Router receives a packet, it needs first to verify if there is
any rule that redirects the packet. If it is not the case, it needs
to check if there is an encapsulation rule, if it is the case then
the packets need to be encapsulated accordingly. Then normal PASA
forwarding is applied.
Li, et al. Expires 5 September 2024 [Page 14]
Internet-Draft PASA Reliability March 2024
+-----------------+
| Packet Received |
+-----------------+
|
V
+---------------+ +-----------------+
/ Is there a \ Yes | Forward |
| redirect rule |------->| according |---+
\ that applies? / | to rule | |
+--------------+ +-----------------+ |
| No |
| |
V |
+---------------+ +-----------------+ |
/ Is there an \ Yes | Encapsulate | |
| encap. rule |------->| according | |
\ that applies? / | to rule | |
+--------------+ +-----------------+ |
| No | |
|<--------------------------+ |
V |
+-----------------+ |
| PASA | |
|Native Forwarding| |
+-----------------+ |
| <--------------------------------------+
V
+------------+
| END |
+------------+
Figure 4: Forwarding procedure in case of multiple topologies.
3.4.2. PASA Root Operation
In the case of a PASA Root, and in the context of multiple
topologies, the PASA native forwarding is always applied for outward
packets. Only in case of inward packets, the node has to check
whether there is an encapsulation rule through an alternative
topology to bypass a failed link/node. Figure 5 show this simple
case.
Li, et al. Expires 5 September 2024 [Page 15]
Internet-Draft PASA Reliability March 2024
+-----------------+
| Packet Received |
+-----------------+
|
V
+---------------+ +-----------------+
/ Is there an \ Yes | Encapsulate |
| encap. rule |------->| according |
\ that applies? / | to rule |
+--------------+ +-----------------+
| No |
| |
V V
+-----------------+ +-----------------+
| PASA | | Forward to |
|Native Forwarding| | Alternative Root|
+-----------------+ +-----------------+
| |
| <--------------------------+
V
+------------+
| END |
+------------+
Figure 5: Root node forwarding procedure in case of multiple
topologies.
4. Single-Address Approach
4.1. Topology Building
In this approach, starting from the root node, we can assign a single
address to each node in the PASA network based on the Tree Address
Assignment Function (TAAF) described in
[I-D.ietf-6lo-path-aware-semantic-addressing]. All nodes with
assigned addresses will send a message to the PASA Root to register
themselves so that the PASA Root has an overview of the nodes and the
topology in the PASA network. By default, a PASA Routers forward
packets via the tree by using the native PASA forwarding method
defined in [I-D.ietf-6lo-path-aware-semantic-addressing].
The PASA Root will have a backup with the same address 1, and Virtual
Router Redundancy Protocol (VRRP [RFC5798]) could be used to
implement same address root redundancy. In order to increase the
resilience of the network, each node will have at least one
alternative parent for redundancy. This alternative uplink is added
to the already existed Neighbor Discovery table. For PASA Hosts,
there will be only alternative uplink entries. For PASA Routers,
Li, et al. Expires 5 September 2024 [Page 16]
Internet-Draft PASA Reliability March 2024
there will be alternative uplink(s) and alternative downlink(s)
stored in the ND table. All the alternative links will be reported
to the root by using dedicated messages.
+---+ +---+
| 1 | |'1'|
/ +---+____________ .+---+
/ .|..\___ .......\.
/ . | .\...... .\
/ . | . \ . \_______
/ . | . \ . \
+---+. +---+ +---+ +---+
| 10| | 11| |110| |111|
+---+ ... +---+ .+---+ +---+
/ | \\__ ............... \
/ | \ \ .. . \
/ | \ \____ . . . \
Failure X .|.....\.......\. . . \
/ . | . \ . \ . . \
/ . | . \ . \ . . \
+---+ +---+ +----+ +----+ +----+
|100| |101| |1010| |1011| |1101|
+---+ +---+ +----+ +----+ +----+
/ | \\. \\
/ | \ \. \ \______
/ | \ \ .. \ \
/ | \ \ . . \ \
/ | \ \ . .......\ ..... \
/ | \ \ ........ \ .. \
/ | \ \ .\ .\
+----+ +----+ +-----+ +-----+ +-----+ +-----+
|1000| |1001| |10010| |10011| |10100| |10101|
+----+ +----+ +-----+ +-----+ +-----+ +-----+
Figure 6: An example of link failure in single address topology.
Let us make an example using as reference the topology depicted in
Figure 6. The figure shows the main links used in the PASA topology
and the alternative links relevant to our example (depicting all
alternative links would make the picture too cluttered). Figure 7
shows the corresponding ND table for the PASA Router 100.
Li, et al. Expires 5 September 2024 [Page 17]
Internet-Draft PASA Reliability March 2024
+-------------+-------+
| Destination | Flags |
+-------------+-------+
| 100 | I | I = Current Node
+-------------+-------+
| 10 | PP | PP = Primary Parent
+-------------+-------+
| 1000 | PPRC | PPRC = Primary PASA Router Child
+-------------+-------+
| 10010 | PPRC |
+-------------+-------+
| 1001 | PPHC | PPHC = Primary PASA Host Child
+-------------+-------+
| 10011 | PPHC |
+-------------+-------+
| 110 | AP | AP = Alternative Parent
+-------------+-------+
| 10100 | APRC | APRC = Alternative PASA Router Child whose
+-------------+-------+ alternative parent is the current node
| 10101 | APHC | APHC = Alternative PASA Host Child whose
+-------------+-------+ alternative parent is the current node
Figure 7: Example of a ND Table of a PASA Router with address '100'.
"Primary" here means that they belong to the PASA topology, to
differentiate them from the backup alternative role. The first entry
of Figure 7 shows the address of the node itself '100'. This node's
parent on the tree is '10' that is recorded in second entry and
marked accordingly a Primary Parent (PP). There are two Primary PASA
Router Children (PPRC), namely '1000' and '10010, followed by two
Primary PASA Host Children (PPHC), namely '1001' and '10011'. Then
one alternative parent (AP) follows, namely '110'. Finally, two
alternative children complete the table, an Alternative PASA Router
Child (APRC) with address 10100, and an Alternative PASA Host Child
(APHC) with address 10101.
As there is only one tree, in general, the packet forwarding will
follow the normal PASA forwarding method by using the primary PASA
topology if there is no link or node failure. Even when there are
failures on the alternative links, the normal PASA forwarding method
is not impacted. However, if there is a link failure on the PASA
tree, the forwarding behavior will change as described in the
following.
Li, et al. Expires 5 September 2024 [Page 18]
Internet-Draft PASA Reliability March 2024
4.2. Link Failures
Upon a link failure an ICMPv6 message will be generated to report the
event to the root. The root will then compute a new forwarding path
based on the current state and encapsulate (tunnel) the packet to
nodes where broken links could be avoided.
In order to give an example illustrating what happens to packets
flowing downlink, let us assume a packet initiated from node 1101 and
destined to node 1001. And the link between node 10 and node 100 is
broken.
When the link fails, upon detection of the failure, node 10 will send
an ICMPv6 message to the root, to make it aware of the failure. The
packet forwarding will happen as follows:
1. The packet is transmitted from node 1101 to the root 1, using
PASA stateless forwarding.
2. Root 1 is aware that the path to destinations in the 100 sub-tree
is not reachable through normal PASA forwarding because of the
link failure, hence computing an alternative path. In this
example: 1 -> 110 -> 100 -> 1001. Since normal PASA forwarding
does not allow to go first through node 110 and then node 100,
the root 1 will encapsulate the addresses of node 110 and node
100 in an extension header so to perform segment routing
[I-D.geng-spring-sr-redundancy-protection].
3. Once the packet reaches 100, the segment routing extension is
dropped, and the packet is sent to its destination 1001 by using
PASA native forwarding.
In the unlikely case that the root is not yet aware of the link
failure during the packet transmission, the packet forwarding will
happen as follows:
1. Packet is transmitted from node 1101 to the root 1, using PASA
native forwarding.
2. Packet is transmitted from root 1 to node 10, following the
normal PASA forwarding method.
3. Node 10, which is aware about the link failure, redirects the
packet back to the root with SRv6 encapsulation.
4. Root 1, which should in the meantime have received an ICMPv6 link
failure notification message, receives the encapsulated packet
and, after decapsulation, it operates like point 2 of the
previous example.
Li, et al. Expires 5 September 2024 [Page 19]
Internet-Draft PASA Reliability March 2024
5. Once packet reaches 100, segment routing extension is dropped,
and packet is sent to its destination 1001 by using PASA native
forwarding.
Let us now look at what happens to packets flowing in the opposite
direction, from 1001 to 1101, with the same link failed, namely the
link between 100 and 10. Upon link failure detection by 100, the
node will send an ICMPv6 message through an alternative parent,
toward the root, to report the link failure. The packet will be
handled as follows:
1. The packet is transmitted from node 1001 to node 100 using PASA
native forwarding.
2. Because of the failed link, node 100 sends the packet to an
alternative parent node.
3. PASA native forwarding is then used. If the alternative parent
is in the same sub-tree like the destination, the packet is
forwarded downward to the right child, otherwise it is sent
upward to its own parent. This goes on recursively until the
packet reaches the root in the worst case, where it is then sent
downward to the correct sub-tree, until it reaches the
destination. In this example, the path is: 100 -> 110 -> 1101.
4.3. Node Failures
As for the multiple-address case, a node failure can be seen as
multiple link failures, basically all links the node connects to. In
this case, the parent of the failed node and its children will simply
apply the same procedure described in the previous section.
4.4. Node Forwarding Procedure
4.4.1. PASA Router Operation
As describe in Figure 8, in the context of single-address approach,
when a PASA Router receives a packet, it performs the normal PASA
native forwarding (after decapsulation, if needed). If case of link
failure, the PASA Router will take different actions depending on
downlink or uplink failure, as depicted in the Section 4.2.
Li, et al. Expires 5 September 2024 [Page 20]
Internet-Draft PASA Reliability March 2024
+----------------+
| Received Packet|
+-------+--------+
|
V
+------------------------+
| Perform PASA Forwarding |
+-----------+------------+
|
V
+---------------------+
/ \
| Outgoing Link working?|---------------------------------+
\ / Yes |
+---------------------+ |
| |
| No |
V |
+---------------------+ V
/ \ Down +-------------------+ +-----+
| Down/Up Link Failure? |----->| Redirect to Root |--->| END |
\ / +-------------------+ +-----+
+--------------------+ ^
| |
| Up |
V |
+---------------------+ |
| Send the Packet to | |
| the Alternative |----------------------------------+
| Parent |
+---------------------+
Figure 8: Forwarding Procedure of PASA Router
4.4.2. PASA Root Operation
In the case of a root node, and in the context of single-address
approach, the PASA native forwarding is always applied, for outward
packets. Only in case of inward packets, the node has to check
whether there is a redirection needed. If it is the case, it will
compute the path and define the segment routing header in order to
forward the packet to avoid the broken link(s).
Li, et al. Expires 5 September 2024 [Page 21]
Internet-Draft PASA Reliability March 2024
+----------------+
| Received Packet|
+-------+--------+
|
V
+---------------------+
/ Is the a \ No
| redirect rule due to |-----------+
\ broken links / |
+---------------------+ |
|Yes |
V |
+---------------------+ |
| Encapsulate to | |
| alternative path | |
+---------------------+ |
| |
V |
+------------------------+ |
| PASA Native Forwarding |<---------+
+------------------------+
|
V
+-------+
| END |
+-------+
Figure 9: Forwarding Procedure on root node.
5. Links/Nodes Failure Detection and Recovery
Previous sections describe actions and possible solutions to failure
events, but did not discuss how failures are detected. This memo
assumes that depending on the specific technology in use, and the
level of desired reliability, the most suitable failure detection
mechanism is used to trigger the above-described actions. It is
considered not desirable to define one single failure detection
technique to be used in the context of PASA, neither to define new
ones.
The link failure could be detected by leveraging layer 2 feedbacks,
like for instance the lack of acknowledgement upon packet
transmission. It can also be detected using existing network layer
solutions, like for instance the Bidirectional Forwarding Detection
(BFD) [RFC7130] or IPv6 specific mechanisms [RFC5534].
Another aspect of the general failure management is to recover from
failures, going back to the original state. In the context of PASA
there are a couple of possible approaches that can be used, e.g. by
Li, et al. Expires 5 September 2024 [Page 22]
Internet-Draft PASA Reliability March 2024
using PASA addresses lifetime. Addresses can be assigned associated
with a lifetime. When such lifetime expires, node have to undergo
the same initial procedure for address allocation. This is also a
good moment to check whether a certain link or node is back to normal
functioning. If it is not the case, the algorithmic procedure will
anyway create topologies that do not consider failed links/nodes. A
faster alternative approach could be based, like in the case of
failure detection, on periodic checks that may leverage on layer 2
features or on some neighbor discovery messages. The former method
is more effective, while the latter introduces communication
overhead.
6. Resiliency
Real resiliency provided by the different approaches depends on the
specific topology.
The single-address solution may introduce more state. Indeed, the
root has the overview of the PASA network. It knows all nodes'
addresses, the alternative links and the broken links. It is able to
compute a usable path towards a destination. This comes with the
benefit of potentially being able to find a higher number of
alternative paths, hence, in the end providing a stronger protection
against multiple failures. The PASA Router and PASA Host are rather
dummy, performing PASA stateless forwarding. They only are aware of
the link state toward their direct neighbors, and act accordingly.
However, the use of source routing may create MTU issues if the path
is too long.
The multi-address approach leverages more on the stateless forwarding
of PASA. The root is in general unaware of nodes' addresses, and the
network topology. In case of failure, a redirection rule is set on
the root, hence the amount of states is proportional to the number of
failures. This means less state overall, but may be less robust to
multiple failures. Differently from the single address solution, a
small state is also required on PASA Routers, because if a link fails
a redirect rule has to be used.
The above-mentioned pros and cons need to be pondered when choosing a
reliability solution to be deployed in an PASA domain.
7. Security Considerations
This document discusses reliability issues and does not specify any
new mechanism. As such there are no new security threats introduced
by this document. As for the PASA specification, consideration in
[I-D.ietf-6lo-path-aware-semantic-addressing] apply.
Li, et al. Expires 5 September 2024 [Page 23]
Internet-Draft PASA Reliability March 2024
8. IANA Considerations
This document contains no requests to IANA.
9. References
9.1. Normative References
[I-D.ietf-6lo-path-aware-semantic-addressing]
Iannone, L., Li, G., Lou, Z., Liu, P., Long, R.,
Makhijani, K., and P. Thubert, "Path-Aware Semantic
Addressing (PASA) for Low power and Lossy Networks", Work
in Progress, Internet-Draft, draft-ietf-6lo-path-aware-
semantic-addressing-04, 1 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
path-aware-semantic-addressing-04>.
[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/rfc/rfc8138>.
9.2. Informative References
[I-D.daniel-6lowpan-hilow-hierarchical-routing]
Park, S. D., "Hierarchical Routing over 6LoWPAN (HiLow)",
Work in Progress, Internet-Draft, draft-daniel-6lowpan-
hilow-hierarchical-routing-01, 18 June 2007,
<https://datatracker.ietf.org/doc/html/draft-daniel-
6lowpan-hilow-hierarchical-routing-01>.
[I-D.geng-spring-sr-redundancy-protection]
Geng, X., Chen, M., Yang, F., Camarillo, P., and G. S.
Mishra, "SRv6 for Redundancy Protection", Work in
Progress, Internet-Draft, draft-geng-spring-sr-redundancy-
protection-05, 2 August 2021,
<https://datatracker.ietf.org/doc/html/draft-geng-spring-
sr-redundancy-protection-05>.
[IEEE802.1W]
"IEEE Std 802.1w-2001, IEEE Std for Local and metropolitan
are networks - Common specifications Part 3; Media Access
Control (MAC) Bridges - Amendment 2; Rapid
Reconfiguration", n.d.,
<https://standards.ieee.org/ieee/802.1w/1046/>.
Li, et al. Expires 5 September 2024 [Page 24]
Internet-Draft PASA Reliability March 2024
[KIM07] Kim, Y.-S., Lee, E. J., Kim, B. S., and H. S. Kim,
"Extended Tree-Based Routing Algorithm in IPv6-enabled
Wireless Sensor Networks", IEEE 2007 International
Conference on Convergence Information Technology (ICCIT
2007), pp. 1269-1274, 2007.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/rfc/rfc5534>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/rfc/rfc5798>.
[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed.,
Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG)
Interfaces", RFC 7130, DOI 10.17487/RFC7130, February
2014, <https://www.rfc-editor.org/rfc/rfc7130>.
[SINGH20] Singh, S. K. and J. Prakash, "Energy Efficiency and Load
Balancing in MANET: A Survey", IEEE 2020 6th International
Conference on Advanced Computing and Communication Systems
(ICACCS), 2020, pp. 832-837, 2020.
Authors' Addresses
Guangpeng Li
Huawei Technologies
Beiqing Road, Haidian District
Beijing
100095
China
Email: liguangpeng@huawei.com
David Lou
Huawei Technologies
Riesstrasse 25
80992 Munich
Germany
Email: zhe.lou@huawei.com
Li, et al. Expires 5 September 2024 [Page 25]
Internet-Draft PASA Reliability March 2024
Luigi Iannone
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: luigi.iannone@huawei.com
Li, et al. Expires 5 September 2024 [Page 26]
