Skip to main content

Reliability Considerations of Path-Aware Semantic Addressing
draft-li-6lo-pasa-reliability-04

Document Type Active Internet-Draft (individual)
Authors Guangpeng Li , Zhe Lou , Luigi Iannone
Last updated 2024-09-18
Replaces draft-li-nsa-reliability
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-6lo-pasa-reliability-04
6lo Working Group                                                  G. Li
Internet-Draft                                                    D. Lou
Intended status: Informational                                L. Iannone
Expires: 22 March 2025                                            Huawei
                                                       18 September 2024

      Reliability Considerations of Path-Aware Semantic Addressing
                    draft-li-6lo-pasa-reliability-04

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 22 March 2025.

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 22 March 2025                 [Page 1]
Internet-Draft              PASA Reliability              September 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 Failure  . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Link Failure Example  . . . . . . . . . . . . . . . .  10
     3.3.  Node Failure  . . . . . . . . . . . . . . . . . . . . . .  11
       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 Failure  . . . . . . . . . . . . . . . . . . . . . .  19
     4.3.  Node Failure  . . . . . . . . . . . . . . . . . . . . . .  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 . . . . . . . . . . . . . . . . . . .  24
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

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
   entire topology, on which to execute look-up algorithms, only
   neighbor awareness is sufficient.

Li, et al.                Expires 22 March 2025                 [Page 2]
Internet-Draft              PASA Reliability              September 2024

   Depending on the specific algorithm used, 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 not be sufficient, and is complicate in
   practice, since it implies to put the system (partially) 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 22 March 2025                 [Page 3]
Internet-Draft              PASA Reliability              September 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 and the Tree Address
   Assignment Function (TAAF), 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-X.Y, 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 22 March 2025                 [Page 4]
Internet-Draft              PASA Reliability              September 2024

                    +---+                   +---+
                    |R-1|                   |R-2|
                    +---+                   +---+

             +-----+     +-----+     +-----+     +-----+
             |N-1.1|     |N-1.2|     |N-1.3|     |N-1.4|
             +-----+     +-----+     +-----+     +-----+

        +-----+     +-----+     +-----+
        |N-2.1|     |N-2.2|     |N-2.3|
        +-----+     +-----+     +-----+

   +-----+    +-----+    +-----+
   |N-3.1|    |N-3.2|    |N-3.3|
   +-----+    +-----+    +-----+

                     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 22 March 2025                 [Page 5]
Internet-Draft              PASA Reliability              September 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, as well as the assigned addresses are shown.

         +---+               +---+
         |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 22 March 2025                 [Page 6]
Internet-Draft              PASA Reliability              September 2024

   Another approach could be trying to use some form load balancing,
   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, removing all leading zeros.
   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, 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.

   In conclusion, it can be stated that the only additional requirement
   imposed on the nodes by this solution is to allow addresses that
   start with zeros and explicitly state the PASA Root's address length.
   The Tree Address Allocation Function (TAAF) defined in
   [I-D.ietf-6lo-path-aware-semantic-addressing] assumes one PASA Root
   whose address is always 1, hence, implicitly setting the root's
   address length to one.

Li, et al.                Expires 22 March 2025                 [Page 7]
Internet-Draft              PASA Reliability              September 2024

3.2.  Link Failure

   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, when using the primary topology, a certain sub-tree is not
       reachable anymore through it.  This can be achieved by sending an
       ICMPv6 message announcing the sub-tree unreachability status
       (e.g., with a Destination Unreachable message).  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 source address of the message (e.g., with a
       Redirect 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.

       *  Encapsulation:  Encapsulating packets 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].

Li, et al.                Expires 22 March 2025                 [Page 8]
Internet-Draft              PASA Reliability              September 2024

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

Li, et al.                Expires 22 March 2025                 [Page 9]
Internet-Draft              PASA Reliability              September 2024

       recursively (e.g., Router Advertisement changing the default
       gateway address).  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-1.1 and N-2.1 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 diverted.

   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.

   At this point connection is assured.  Let us assume the in the
   primary tree (see Figure 2) nodes 11 and 1001 where communicating to
   each other.  Packets will flow through the following path:

   *  From 11 to 1001:

      1.  Packet is transmitted from 11 to 1 (on the primary tree).

Li, et al.                Expires 22 March 2025                [Page 10]
Internet-Draft              PASA Reliability              September 2024

      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 that the destination is on the
          primary tree, thus 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].

3.3.  Node Failure

   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:

Li, et al.                Expires 22 March 2025                [Page 11]
Internet-Draft              PASA Reliability              September 2024

   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.

   What changes is that the node itself is not reachable anymore.  In
   case of a packet destined to such a node, after the above actions
   that packet will end up in the main root, who knows that the node is
   not reachable through the primary tree and did not receive any
   redirect request from the secondary root, hence it can drop the
   packet and send back to the source an ICMPv6 message No Route to
   Host.

3.3.1.  Node Failure Example

   Using again the example previously introduced, let us assume that
   node N-2.1 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 22 March 2025                [Page 12]
Internet-Draft              PASA Reliability              September 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 22 March 2025                [Page 13]
Internet-Draft              PASA Reliability              September 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 PASA native
   forwarding is applied.

Li, et al.                Expires 22 March 2025                [Page 14]
Internet-Draft              PASA Reliability              September 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: PASA Router 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 22 March 2025                [Page 15]
Internet-Draft              PASA Reliability              September 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: PASA Root forwarding procedure in case of multiple
                                topologies.

4.  Single-Address Approach

4.1.  Topology Building

   In this approach, starting from the root node, a single address can
   be assigned 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, 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 [RFC9568]) 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 22 March 2025                [Page 16]
Internet-Draft              PASA Reliability              September 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.
      Dshed lines indicate primary links, while dotted lines indicate
                        alternative (backup) links.

   Let us make an example using as reference the topology depicted in
   Figure 6.  The figure shows the primary 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 22 March 2025                [Page 17]
Internet-Draft              PASA Reliability              September 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 PASA native 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 22 March 2025                [Page 18]
Internet-Draft              PASA Reliability              September 2024

4.2.  Link Failure

   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 so that broken links could be avoided.

   In order to give an example illustrating what happens to packets
   flowing downlink, let us assume a packet initiated by node 1101 and
   destined to node 1001. let us also assume that 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 it will compute 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 can 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 22 March 2025                [Page 19]
Internet-Draft              PASA Reliability              September 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 through the correct 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 Failure

   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).  In 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 22 March 2025                [Page 20]
Internet-Draft              PASA Reliability              September 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 22 March 2025                [Page 21]
Internet-Draft              PASA Reliability              September 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 particular, since,
   according to [RFC8505] and
   [I-D.ietf-6lo-path-aware-semantic-addressing], nodes are supposed to

Li, et al.                Expires 22 March 2025                [Page 22]
Internet-Draft              PASA Reliability              September 2024

   keep addressing state in non-volatile memory, upon failure recovery
   nodes can just re-register addresses rather than restart the
   addressing process.  This allows as well to signal node recovery,
   since the recovered node will re-register the previously obtained
   address, signaling that it is back.  For link recovery detection, in
   the context of PASA, there are a couple of possible approaches that
   can be used, e.g. by using PASA addresses lifetime.  Addresses can be
   assigned associated with a lifetime.  When such lifetime expires,
   node have to undergo the same initial procedure to re-obtain the same
   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.  However, this will cause
   renumbering, which, depending on the topology and the location of the
   failure, may not be the best solution.  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 presented in
   this document depends on the specific topology.

   The single-address solution may introduce more state.  Indeed, the
   root has full knowledge 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.

Li, et al.                Expires 22 March 2025                [Page 23]
Internet-Draft              PASA Reliability              September 2024

   Both approaches, presented in previous sections, rely on the presence
   of more than one PASA Root, which provides resilient connectivity
   toward other networks (or the Internet).  In case of one PASA Root
   failure, the procedures described in the present document apply, and
   external connectivity is provided by the other PASA Roots.  The same
   applies if one of the link between the PASA Roots and their children
   fail; procedures described in this document provide resilient
   connectivity.  Resiliency in the external connectivity depend on the
   specific deployment, provisioning, and technology used, which are out
   of the scope of this document.

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.

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-07, 21 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
              path-aware-semantic-addressing-07>.

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

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/rfc/rfc8505>.

9.2.  Informative References

Li, et al.                Expires 22 March 2025                [Page 24]
Internet-Draft              PASA Reliability              September 2024

   [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/>.

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

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

   [RFC9568]  Lindem, A. and A. Dogra, "Virtual Router Redundancy
              Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,
              DOI 10.17487/RFC9568, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9568>.

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

Li, et al.                Expires 22 March 2025                [Page 25]
Internet-Draft              PASA Reliability              September 2024

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

   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 22 March 2025                [Page 26]