Internet DRAFT - draft-li-nsa-reliability

draft-li-nsa-reliability







Network Working Group                                              G. Li
Internet-Draft                                                    D. Lou
Intended status: Informational                                L. Iannone
Expires: 2 December 2022                                          Huawei
                                                             31 May 2022


         Reliability Considerations of Native Short Addressing
                      draft-li-nsa-reliability-00

Abstract

   Native Short Address (NSA [I-D.li-6lo-native-short-address]),
   proposes to algorithmically assign short addresses to nodes in a 6lo
   environment so to achieve stateless forwarding, hence, avoiding using
   a routing protocol.  NSA is more suitable in case of stable and
   static wireline connectivity, in order to avoid renumbering due to
   topology changes.  Even in such kind of scenarios, reliability
   remains an issue.  This memo tackles specifically reliability in NSA
   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 2 December 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Li, et al.               Expires 2 December 2022                [Page 1]

Internet-Draft               NSA Reliability                    May 2022


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Problem Statement  . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Potential Solution Approaches . . . . . . . . . . . . . . . .   3
     3.1.  Multi-Address Approach  . . . . . . . . . . . . . . . . .   3
       3.1.1.  Topology building . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Link Failures . . . . . . . . . . . . . . . . . . . .   7
       3.1.3.  Node Failures . . . . . . . . . . . . . . . . . . . .  11
       3.1.4.  Nodes Forwarding Procedure  . . . . . . . . . . . . .  13
     3.2.  Single-Address Approach . . . . . . . . . . . . . . . . .  15
       3.2.1.  Link Failure  . . . . . . . . . . . . . . . . . . . .  17
       3.2.2.  Node Failure  . . . . . . . . . . . . . . . . . . . .  19
       3.2.3.  Node Forwarding Procedure . . . . . . . . . . . . . .  19
   4.  Links/Nodes Failure Detection and Recovery  . . . . . . . . .  21
   5.  Robustness  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction and Problem Statement

   The common characteristic of various topological addressing schemes
   ([I-D.daniel-6lowpan-hilow-hierarchical-routing],
   [I-D.li-6lo-native-short-address], [KIM07]) is the possibility of
   nodes to forward packets without the need of routing tables, and
   hence, without the need of routing protocols.  In such context the
   addresses are build in such a way that a node is capable of
   forwarding a packet to the next hop by comparing the destination
   address with its own address.  It is not required to build routing
   table on which to execute look-up algorithms, only neighbor awareness
   is sufficient.  However, this kind of stateless forwarding typically
   works in a single topology with static paths, where high reliability
   is hard to reach.  Once a link (or a node) fails, the traffic will
   not be routable and packets will be 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 complicate in practice, since
   it implies to put the system offline during the renumbering process.



Li, et al.               Expires 2 December 2022                [Page 2]

Internet-Draft               NSA Reliability                    May 2022


   What is desirable is to have some mechanism that with little extra
   effort may quickly enable the usage of alternative paths, without the
   need to put the system offline, hence providing the desired
   reliability.  The present memo analyzes two possible approaches to
   guarantee reliability in NSA domains.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Potential Solution Approaches

   In order to improve the reliability of the system, the pre-requisite
   is to have redundant links.  This means that nodes are connected
   likely in a meshed fashion, where some of the links are actively
   used, and others not.  In a normal situation, in the context of NSA,
   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 NSA
   [I-D.li-6lo-native-short-address], all nodes, except the root, have
   at least one secondary parent, which is used only if a problem is
   detected when communicating with the primary one.  In this way, when
   the link toward the primary parent is broken, an alternative link
   toward the 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.

   Both approaches, with pros and cons, are described and analyzed
   hereafter.

3.1.  Multi-Address Approach

   In the multi-address case multiple logical topologies are built using
   different addresses and different links.  In the following it is
   assumed the two logical topologies are built on top of the physical
   connectivity, however, the principles can be easily extended to more
   than two topologies.



Li, et al.               Expires 2 December 2022                [Page 3]

Internet-Draft               NSA Reliability                    May 2022


3.1.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.  Nodes have the
   same role in both topologies.  Meaning that a node will have the same
   "Leaf" or "Forwarder" role in both topologies (see
   [I-D.li-6lo-native-short-address] for role definition).  The
   Allocation Function (AF) 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.  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 mean that the address of the root nodes can be used to
   actually identify the different topologies.  For both topologies, the
   address allocation works in the exact same way as described in
   [I-D.li-6lo-native-short-address], 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 the two
   parent must not have the same "node-id".

   Let's 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 with different roles, where "L" stands for leaf nodes and
   "F" stands for forwarder nodes.  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.

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


           +---+      +---+      +---+      +---+
           |F-1|      |L-1|      |F-2|      |L-2|
           +---+      +---+      +---+      +---+


       +---+      +---+      +---+
       |F-3|      |L-3|      |F-4|
       +---+      +---+      +---+


   +---+   +---+    +---+
   |L-4|   |L-5|    |L-6|
   +---+   +---+    +---+

                     Figure 1: Simple Topology example.




Li, et al.               Expires 2 December 2022                [Page 4]

Internet-Draft               NSA Reliability                    May 2022


   Let's now 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.li-6lo-native-short-address], 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|   | 110|   | 111|
        +---+    +---+   +----+   +----+
        /  \ \
       /    \ +------+
      /      \        \
     +----+  +----+   +-----+
     | 100|  | 101|   | 1010|
     +----+  +----+   +-----+
      /  \ \
     /    \ +-----------+
    /      \             \
   +----+   +-----+    +------+
   |1001|   |10011|    |100111|
   +----+   +-----+    +------+

      Figure 2: Possible NSA assignment and logical topology using R-1
                                  as root.

   In a similar way, assuming root R-2 has the address 01, and again
   applying the allocation function presented in
   [I-D.li-6lo-native-short-address], a possible outcome is the one
   presented in Figure 3, where the links selected to for the logical
   topology are shown, as well as the assigned addresses.















Li, et al.               Expires 2 December 2022                [Page 5]

Internet-Draft               NSA Reliability                    May 2022


         +---+               +---+
         |R-1|   +-----------| 01|
         +---+  /     +------+---+
               /     /       /   \
              /     /       /     \
        +---+    +---+   +----+   +----+
        |010|    |011|   |0110|   |0111|
        +---+    +---+   +----+   +----+
                       / / |
           +----------+ /  |
          /        +---+   |
         /        /        |
    +-----+  +-----+   +------+
    |01100|  |01101|   |011010|
    +-----+  +-----+   +------+
                       / / |
           +----------+ /  |
          /        +---+   |
         /        /        |
   +-------+   +--------+  +---------+
   |0110101|   |01101011|  |011010111|
   +-------+   +--------+  +---------+

      Figure 3: Possible NSA 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, choose the tree
      with the smallest value.

   Another approach could be to try to use some load balancing approach,
   where sockets open on the various nodes are bound to one of the
   available addresses based on some algorithm.  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 algorithm are out of the scope of this document.  In
   the following let's assume that a primary/secondary approach is used,
   where the topology in Figure 2 is the primary one.

   In [I-D.li-6lo-native-short-address], the root node has always
   address 1.  Such simple approach allows to easily switch between NSA
   and IPv6 addresses.  Indeed, because all NSA addresses start with a



Li, et al.               Expires 2 December 2022                [Page 6]

Internet-Draft               NSA Reliability                    May 2022


   1, to obtain an IPv6 address it is sufficient to prepend a sufficient
   number of zeros to the NSA address, so align to the /64 suffix
   length, then prepend it with the whole /64 prefix of the network.
   Vice-versa, to obtain the corresponding NSA address from an IPv6
   address, the /64 prefix is removed as well as all leading zeros in
   the remaining suffix.  This is not anymore sufficient.  Taking the
   example in Figure 3, the root node has to be aware that it does not
   have to remove the last leading zero.  In order to maintain the
   simplicity of the design of NSA, the addresses of root nodes are
   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 by
      the root.

   *  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 our 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.  Only the root nodes have to be aware of the root
   address length, because they are the only one performing address
   translation (from NSA to IPv6 and vice-versa).  Leafs and Forwarders
   do not need to be aware of the root address length, since it is
   implicit in the prefix used in the tree for the addresses.  For
   instance, the leafs at the bottom of Figure 3 can easily understand
   that the root address length is 2 because their address starts with
   01.  The only requirement imposed by this solution on the nodes is to
   allow addresses that start with zeros
   ([I-D.li-6lo-native-short-address] only specifies addresses starting
   with 1).

3.1.2.  Link Failures

   In case of link failure there are three actions that need to be
   performed in order to ensure connectivity.

   1.  The parent node, with respect to the link in object, has to
       inform all the nodes between itself and the root that a certain
       sub-tree is not reachable anymore through it, by using the
       primary topology.  This can be achieved by sending an ICMPv6
       message toward the root, where each node the message traverses
       stores the sub-tree unreachability status, so that packets
       destined to that sub-tree are actually re-directed toward the



Li, et al.               Expires 2 December 2022                [Page 7]

Internet-Draft               NSA Reliability                    May 2022


       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 link in object, has to 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 can be
       achieved by sending an ICMPv6 message toward the root of the
       primary tree, but actually using the secondary tree, hence using
       the secondary address as a source of the message.  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 actually ship a packet destined to an
       address in the primary tree through the secondary tree, two
       options are possible: encapsulation or routing.

       *  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 NSA 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 primary root, hence being
          forwarded on the secondary tree, circumventing the broken
          link.

       *  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 on the broken link, is
          forwarded on the secondary tree, each node along the path
          stores the fact 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
          NSA 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 root, who will forward them to the primary root.





Li, et al.               Expires 2 December 2022                [Page 8]

Internet-Draft               NSA Reliability                    May 2022


          The first solution (encapsulation) may increase the likelihood
          to have MTU issues.  Indeed, an additional encapsulation will
          increase the packet size.  The second solution does not create
          MTU issues, but needs to store state in nodes along the
          alternative paths.  While the number of entries is certainly
          limited, because it is the number of sub-trees unreachable
          through the primary tree and using the node as part of the
          alternative path.  This may be an issue on devices with strong
          memory constraints.  Yet, if the state grows big it is the
          symptom of massive failures in the network, which may be a far
          bigger/urgent problem.  In both cases the root nodes have to
          keep some state: 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 use the secondary tree (i.e. the
       secondary address).  This can be achieved by sending a specific
       ICMPv6 message 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 describe 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 NSA
   stateless forwarding procedure.

   Using the example previously introduced, let's assume that the link
   between F-1 and F-3 breaks (cf.  Figure 1).  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 root.  Root will register that
       100-sub-tree is not reachable through 10 but has to be
       redirected.

   2.  100 sends an ICMPv6 message to 1 (root of primary tree) using
       01100 as source address (see Figure 3).  This message will be
       forwarded first to 01, the root of the secondary tree, and then




Li, et al.               Expires 2 December 2022                [Page 9]

Internet-Draft               NSA Reliability                    May 2022


       to 1.  Let's assume encapsulation is used, now root 1 has an
       entry stating:

       *  For 100-sub-tree encapsulate to 01100 and forward to 01

   3.  100 will send an ICMPv6 message to its children suggesting to use
       the secondary addresses.

   At this point connection is guaranteed.  Let's assume the in the
   primary tree (see Figure 2) nodes 11 and 1001 where communicating to
   each other.  Packets will flow in the following way:

   *  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 and transmits it to 01 (root secondary).

      3.  01 will use NSA stateless forwarding to transmit the packet to
          0110 (on the secondary tree).

      4.  0110 will use NSA stateless forwarding to transmit the packet
          to 01100 (on the secondary tree).

      5.  01100 will decapsulate, note the destination is on the primary
          tree, use the NSA 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 01100 and destination 1 (root primary
          tree) then transmits the packet to 0110 (on the secondary
          tree).

      3.  0110 will use NSA stateless forwarding to transmit the packet
          to 01 (on the secondary tree).

      4.  01 will see that packet is destined to the primary root and
          transmits it to 1.

      5.  1 will decapsulate, note the destination is on the primary
          tree, use the NSA stateless forwarding to transmit the packet
          to 11 (on the primary tree).




Li, et al.               Expires 2 December 2022               [Page 10]

Internet-Draft               NSA Reliability                    May 2022


   In case of communication toward/from the public Internet the
   procedure is similar.  For outgoing packets the primary root will
   expand the NSA header to a full IPv6 header and forward it upstream.
   For incoming packets, the root will first reduce the IPv6 header to
   an NSA header then forward it as described above.  NSA header
   expansion and IPv6 header reduction are operations described in
   [I-D.li-6lo-native-short-address].

3.1.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 may change is who is performing
   the action.  More specifically:

   1.  The parent of the failed node, has to inform all the nodes
       between itself the root that a certain sub-tree is not reachable
       anymore through it.  This is the exact same procedure like in
       Section 3.1.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.1.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.1.2, just done
       by all children.

   Using again the example previously introduced, let's assume that node
   F-3 fails (cf.  Figure 1).  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 root.  Root 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 1 (root of primary tree) using
          01100 as source address (see Figure 3).  This message will be



Li, et al.               Expires 2 December 2022               [Page 11]

Internet-Draft               NSA Reliability                    May 2022


          forwarded first to 01, the root of the secondary tree, and
          then to 1.  Let's assume encapsulation is used, now root 1 has
          an entries stating:

          -  For 1001-sub-tree encapsulate to 0110101 and forward to 01

       *  10011 sends an ICMPv6 message to 1 (root of primary tree)
          using 01100 as source address (see Figure 3).  This message
          will be forwarded first to 01, the root of the secondary tree,
          and then to 1.  Let's assume encapsulation is used, now root 1
          has an entry stating:

          -  For 10011-sub-tree encapsulate to 01101011 and forward to
             01

       *  100111 sends an ICMPv6 message to 1 (root of primary tree)
          using 01100 as source address (see Figure 3).  This message
          will be forwarded first to 01, the root of the secondary tree,
          and then to 1.  Let's assume encapsulation is used, now root 1
          has an entry stating:

          -  For 100111-sub-tree encapsulate to 011010111 and forward to
             01

   3.  The children of 100, will send an ICMPv6 message to their
       children (if any) suggesting to use the secondary addresses.

   At this point connection is guaranteed.  Let's 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
          100 and transmits it to 01 (root secondary).

      3.  01 will use NSA stateless forwarding to transmit the packet to
          0110101 (on the secondary tree).

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




Li, et al.               Expires 2 December 2022               [Page 12]

Internet-Draft               NSA Reliability                    May 2022


      1.  Because 1001 knows the upstream link is broken it encapsulates
          the packet with source 0110101 and destination 1 (root primary
          tree) then, using NSA stateless forwarding, it will transmit
          the packet to 01 (on the secondary tree).

      2.  01 will see that packet is destined to the primary root and
          transmits it to 1.

      3.  1 will decapsulate, note the destination is on the primary
          tree, use the NSA stateless forwarding to transmit the packet
          to 11 (on the primary tree).

   In case of communication toward/from the public Internet the
   procedure is the same as described in Section 3.1.2.

3.1.4.  Nodes Forwarding Procedure

   Nodes, other than leafs, 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 forwarder and
   root nodes is provided.  The mention "NSA Native Forwarding" is used
   where the original procedure described in
   [I-D.li-6lo-native-short-address] is employed.

3.1.4.1.  Forwarder Nodes

   As describe in Figure 4, in the context of multiple topologies, when
   a a forwarder node 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 needs to be encapsulated accordingly.  Then
   normal NSA forwarding is applied.


















Li, et al.               Expires 2 December 2022               [Page 13]

Internet-Draft               NSA Reliability                    May 2022


   +-----------------+
   | 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                                       |
   +-----------------+                              |
   |      NSA        |                              |
   |Native Forwarding|                              |
   +-----------------+                              |
           | <--------------------------------------+
           V
     +------------+
     |    END     |
     +------------+

     Figure 4: Forwarder node forwarding procedure in case of multiple
                                topologies.

3.1.4.2.  Root Nodes

   In the case of a root node, and in the context of multiple
   topologies, the NSA 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 2 December 2022               [Page 14]

Internet-Draft               NSA Reliability                    May 2022


   +-----------------+
   | Packet Received |
   +-----------------+
            |
            V
    +---------------+         +-----------------+
   /   Is there an   \  Yes   |   Encapsulate   |
   |   encap. rule   |------->|   according     |
   \  that applies?  /        |    to rule      |
    +--------------+          +-----------------+
            |  No                       |
            |                           |
            V                           V
   +-----------------+        +-----------------+
   |      NSA        |        | Forward  to     |
   |Native Forwarding|        | Alternative Root|
   +-----------------+        +-----------------+
           |                            |
           | <--------------------------+
           V
     +------------+
     |    END     |
     +------------+

        Figure 5: Root node forwarding procedure in case of multiple
                                topologies.

3.2.  Single-Address Approach

   In this approach, starting from the root node, we can assign a single
   address to each node in the NSA network based on the address
   allocation function described in [I-D.li-6lo-native-short-address].
   All nodes with assigned addresses will send a message to the root to
   register themselves so that the root has an overview of the nodes and
   the topology in the NSA network.  The nodes with the links used to
   assign the addresses form the primary tree topology.  By default, the
   node forwards the packet via the primary tree by using the native NSA
   forwarding method defined in [I-D.li-6lo-native-short-address].

   The 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 provide
   reliability inside the topology, each node will have at least one
   alternative parent for redundancy.  This alternative uplink is stored
   added to the already existing Neighbor Discovery table.  For a
   forwarder node, once an alternative downlink is established, because
   it is an alternative parent, it has to record this downlink into the
   ND table as well.  For leaf nodes, there will be only alternative



Li, et al.               Expires 2 December 2022               [Page 15]

Internet-Draft               NSA Reliability                    May 2022


   uplink entries.  All the alternative links will be reported to the
   root using ICMPv6 messages.  Therefore for forwarder nodes, there
   will be alternative uplink(s) and alternative downlink(s) stored in
   the ND table, and leafs nodes will have a ND table only with
   alternative uplink(s).  An example of ND table which includes the
   alternative parent(s)/children is shown in Figure 6).  In particular,
   it shows what should be the ND table content for node 100 in the
   topology shown in Figure 7.

   +-------------+-------+
   | Destination | Flags |
   +-------------+-------+
   |    100      |   I   | I   = Current Node
   +-------------+-------+
   |    10       |   PP  | PP  = Primary Parent
   +-------------+-------+
   |    1000     |   PFC | PFC = Primary Forwarder Child
   +-------------+-------+
   |    10010    |   PFC |
   +-------------+-------+
   |    1001     |   PLC | PLC = Primary Leaf Child
   +-------------+-------+
   |    10011    |   PLC |
   +-------------+-------+
   |    110      |   AP  | AP = Alternative Parent
   +-------------+-------+
   |    10100    |   AFC | AFC = Alternative Forwarder Child whose
   +-------------+-------+       alternative parent is the current node
   |    10101    |   ALC | ALC = Alternative Leaf Child whose
   +-------------+-------+       alternative parent is the current node

      Figure 6: Example of a ND Table of a forwarder node with address
                                 of '100'.

   There can be more than one forwarder and leaf children, "Primary"
   here means that they belong to the primary topology, to differentiate
   them from the backup alternative role.  The first entry of Figure 6
   shows the address of the node itself '100'.  This node's parent on
   the primary tree is '10' that is recorded in second entry and marked
   accordingly a Primary Parent (PP).  There are two Primary Forwarder
   Children (PFC), namely '1000' and '10010, followed by two Primary
   Leaf Children (PLC), namely '1001' and '10011'.  Then one alternative
   parent (AP) follows, namely '110'.  Finally, for the sake of clarity,
   two alternative children have been added to complete the table (not
   depicted in Figure 7), an Alternative Forwarder Child (AFC) with
   address 10100, and an Alternative Leaf Child (ALC) with address
   10101.




Li, et al.               Expires 2 December 2022               [Page 16]

Internet-Draft               NSA Reliability                    May 2022


   As there is only one primary tree, in general, the packet forwarding
   will follow the normal NSA forwarding method if there is no link or
   node failure.  Even when there are failures on the alternative links,
   the normal NSA forwarding method is not impacted.  However, if there
   is a link failure on the primary tree, the forwarding behavior will
   change as described in the following.

3.2.1.  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 where broken links could be avoided.

                            1                          '1'
                               /-\                 /-\
                              |   |\----------\...|   |.......
                               \-/\  \--\......\...\-/.       .
                              / |   \....\- \...\.     .       .
                            /  .|.... \...... \_._\-----.-----\ .
                          /.... |  .... \      .  \__    .     \ .
                 10     /..   11| .       \ 110      \__  .111  \ . 1110
                    /-\ .      /-\          /-\         \ /-\    \- /-\
                   |   |.     |   |       .|   |         |   |     |   |
                   /\-/\....   \-/      .. .\-\           \-/       \-/
                  /  |  \ \ ...    ..... .. .  \
                 /   |   \  \.. .....  ..  .   \
                /    |    \.. \  ..  .. ...     \
      Failure  X     | ....  ...\ . .    . ..   \
              /     ...   ..\ .. .\     .    ..  \
             /   ... | ...   \.     \  .       ..\
        100 /-\..101/-\.     /-\1010 \/-\ 1011   .\/-\ 1101
           |   |   |   |   .|   |    |   |        |   |
            \-/ \   \-/  . . \-/      \-/          \-/
           / | \ \     .  .  . .
          /  |  \ \ ..  .   .  .
         /   |   \..\ .    ..  .
        /    |   .\ . \   .    .
       /     | .   .    \..    .
      /     ...   . \  .. \    .
     /   ... |   .   \.     \  .
    /-\..   /-\..    /-\     \/-\
   |   |   |   |    |   |    |   |
    \-/     \-/      \-/      \-/
   1000     1001     10010     10011

      Figure 7: An example of link failure in single address topology.




Li, et al.               Expires 2 December 2022               [Page 17]

Internet-Draft               NSA Reliability                    May 2022


   In order to give an example to what happens to packets flowing
   downlink, let's assume a packet initiated from node 1101 destined to
   node 1001, and 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.  Packet is transmitted from node 1101 to the root 1, using NSA
       native forwarding.

   2.  Root 1 is aware that the path to destinations in the 100 sub-tree
       are not reachable through normal NSA forwarding because of the
       link failure, hence computes an alternative path.  In this
       example: 1 -> 110 -> 100 -> 1001.  Since normal NSA 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 segmented routing
       [I-D.geng-spring-sr-redundancy-protection].

   3.  Once packet reaches 100, the segment routing extension is
       dropped, and the packet is sent to its destination 1001 using NSA
       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 NSA
       native forwarding.

   2.  Packet is transmitted from root 1 to node 10, following the
       normal NSA 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
       message notifying the failure of the link, receives the
       encapsulated packet and, after decapsulation, it operates like in
       the previous example.  Since it is now aware that the path to
       destinations in the 100 sub-tree are not reachable through normal
       NSA forwarding because of the link failure, hence computes an
       alternative path.  In this example: 1 -> 110 -> 100 -> 1001.
       Since normal NSA 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 segmented routing
       [I-D.geng-spring-sr-redundancy-protection].



Li, et al.               Expires 2 December 2022               [Page 18]

Internet-Draft               NSA Reliability                    May 2022


   5.  Once packet reaches 100, segment routing extension dropped, and
       packet is sent to its destination 1001 using NSA native
       forwarding.

   Let's now look at what happens to packets flowing in the opposite
   direction, when packets are sent 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.  Packet is transmitted from node 1001 to node 100 using NSA native
       forwarding.

   2.  Because of the failed link, node 100 sends the packet to an
       alternative parent node.

   3.  NSA native forwarding is used then.  If the alternative parent is
       in the same sub-tree like the destination, the packet is
       forwarded down ward to the right child, otherwise it is sent
       upward to the 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 forwarder child, until it reaches the
       destination.  In our example the path would be: 100 -> 110 ->
       1101.

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

3.2.3.  Node Forwarding Procedure

3.2.3.1.  Forwarder Node















Li, et al.               Expires 2 December 2022               [Page 19]

Internet-Draft               NSA Reliability                    May 2022


          +----------------+
          | Received Packet|
          +-------+--------+
                  |
                  V
      +------------------------+
      | Perform NSA 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 Forwarder Node

   As describe in Figure 8, in the context of single-address approach,
   when a forwarder node receives a packet, it performs the normal NSA
   native forwarding (after decapsulation, if needed).  If case of link
   failure, the forwarder will take different actions depending on
   downlink or uplink failure, as depicted in the Section 3.2.1.

3.2.3.2.  Root Node

   In the case of a root node, and in the context of single-address
   approach, the NSA 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 2 December 2022               [Page 20]

Internet-Draft               NSA Reliability                    May 2022


            +----------------+
            | Received Packet|
            +-------+--------+
                    |
                    V
          +---------------------+
         /      Is the a         \  No
         | redirect rule due to  |-----------+
         \     broken links      /           |
          +---------------------+            |
                    |Yes                     |
                    V                        |
          +---------------------+            |
          |   Encapsulate to    |            |
          | alternative path    |            |
          +---------------------+            |
                    |                        |
                    V                        |
         +------------------------+          |
         | NSA Native  Forwarding |<---------+
         +------------------------+
                    |
                    V
                +-------+
                |  END  |
                +-------+

                Figure 9: Forwarding Procedure on root node.

4.  Links/Nodes Failure Detection and Recovery

   Previous sections describe actions and possible solution to failures
   events, but never discussed 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 NSA, neither to define new
   ones.
   The link failure could be detected leveraging layer 2 feedback, like
   for instance the lack of acknowledgement upon packet transmission.
   It can also be detected using existing network layer solution, like
   for instance using 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 NSA
   there are a couple of possible approaches that can be used.  Use



Li, et al.               Expires 2 December 2022               [Page 21]

Internet-Draft               NSA Reliability                    May 2022


   native addresses lifetime.  Addresses can be assigned associated with
   a lifetime.  When such lifetime expires, node have to undergo the
   same initial procedure 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 take into account failed links/
   nodes.  A faster 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 being more
   effective, the latter introducing communication overhead.

5.  Robustness

   Real robustness provided by the different approaches depends from the
   specific topology.  The single-address solution may introduce more
   state.  Indeed, the root has the overview of the NSA 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 path, hence, in the end providing a
   stronger protection against multiple failures.  The forwarder node
   and the leaf node are rather dummy and use NSA stateless forwarding.
   They only are aware of link state toward their direct neighbors, and
   take action accordingly.  The multi-address approach leverages more
   on the stateless forwarding of NSA.  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 there amount of state is
   proportional to the number of failures.  This means less state, but
   may be less robust to multiple failures.  Differently from the single
   address solution, a small amount state is also required on forwarder
   nodes, 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 NSA domain.

6.  Security Considerations

   TBD

7.  IANA Considerations

   TBD.

8.  References

8.1.  Normative References





Li, et al.               Expires 2 December 2022               [Page 22]

Internet-Draft               NSA Reliability                    May 2022


   [I-D.li-6lo-native-short-address]
              Li, G., Lou, D., Iannone, L., Liu, P., and R. Long,
              "Native Short Addressing for Low power and Lossy Networks
              Expansion", Work in Progress, Internet-Draft, draft-li-
              6lo-native-short-address-02, 4 March 2022,
              <https://www.ietf.org/archive/id/draft-li-6lo-native-
              short-address-02.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.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://www.ietf.org/archive/id/draft-daniel-6lowpan-
              hilow-hierarchical-routing-01.txt>.

   [I-D.geng-spring-sr-redundancy-protection]
              Geng, X., Chen, M., Yang, F., Garvia, P. C., and G.
              Mishra, "SRv6 for Redundancy Protection", Work in
              Progress, Internet-Draft, draft-geng-spring-sr-redundancy-
              protection-05, 2 August 2021,




Li, et al.               Expires 2 December 2022               [Page 23]

Internet-Draft               NSA Reliability                    May 2022


              <https://www.ietf.org/archive/id/draft-geng-spring-sr-
              redundancy-protection-05.txt>.

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

   [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


   Luigi Iannone
   Huawei Technologies France S.A.S.U.
   18, Quai du Point du Jour
   92100 Boulogne-Billancourt
   France




Li, et al.               Expires 2 December 2022               [Page 24]

Internet-Draft               NSA Reliability                    May 2022


   Email: luigi.iannone@huawei.com


















































Li, et al.               Expires 2 December 2022               [Page 25]