Skip to main content

Sloppy Topology Updates for ad-hoc Routing Protocols (STURP)
draft-lou-manet-sturp-02

Document Type Active Internet-Draft (individual)
Authors Zhe Lou , Luigi Iannone , Dirk Trossen , Zhaochen Shi
Last updated 2024-06-27
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-lou-manet-sturp-02
Network Working Group                                             D. Lou
Internet-Draft                                                L. Iannone
Intended status: Experimental                                 D. Trossen
Expires: 29 December 2024                                         Z. Shi
                                                                  Huawei
                                                            27 June 2024

      Sloppy Topology Updates for ad-hoc Routing Protocols (STURP)
                        draft-lou-manet-sturp-02

Abstract

   This memo describes an approach to updating topologies in typical
   MANET-like environments, relying on what is termed 'sloppy updates'
   in the remainder of this document.  Key to the approach is that
   updates are only initiated if existing communication relations may be
   effect by non-synchronized topology information, otherwise using the
   topology information as it exists.  This 'sloppy' nature of the
   approach reduces the needed updates and the associated communication
   for them, thus increases efficiency as well as performance from a
   user perspective.

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 29 December 2024.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.

Lou, et al.             Expires 29 December 2024                [Page 1]
Internet-Draft                    STURP                        June 2024

   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Protocol Interactions . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Neighbor Acquisition  . . . . . . . . . . . . . . . . . .   6
     5.2.  Topology Synchronization  . . . . . . . . . . . . . . . .   8
     5.3.  Routing Table Calculation and Configuration . . . . . . .  10
   6.  Message Encodings . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Hello Message . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Topology Synchronization Message  . . . . . . . . . . . .  12
   7.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The penetration of smart devices like smart phones, pads, smart
   watches, cameras, speakers and TVs, etc. has led to the increasing
   proliferation of mobile ad-hoc networks and communications, as shown
   in Figure 1.  A key characteristic of those environments is the
   minimization or entire absence of dedicated network infrastructure
   involved in such networks.  For instance, a smart watch can pair with
   a smart phone via bluetooth to exchange contacts and takes over phone
   calls.  It can further talk to a speaker connected to the home WiFi
   network via the smart phone.  When the smart phone is absent, a
   tablet may take over the role to bridge the link between the smart
   watch and the speaker.  Common to those scenarios is the need for a
   self organized network, with a dynamic topology comprised of the
   currently participating devices in that network.

   Looking more closely at those environments, we can recognize that
   devices may join or leave the network depending on the application,
   location, and their own status.  In the presence of such dynamicity,
   proactive network formation is desired to enable any to any as well
   as instant device communication, while ensuring the Quality of
   Experience (QoE) of any such communication.

Lou, et al.             Expires 29 December 2024                [Page 2]
Internet-Draft                    STURP                        June 2024

   As a key aspect in a routing and communication protocol for such
   environments, it is required that all devices in the network are able
   to create and periodically refresh the network topology information,
   including node addresses and link information.  For instance, the Ad
   hoc On-Demand Distance Vector (AODV) routing protocol defined in
   [RFC3561] enables dynamic, self-starting, multi-hop routing between
   network nodes to establish and maintain ad hoc networks.  However, it
   is a reactive routing protocol, creating a relatively higher end-to-
   end delay due to route discovery ([SHARMA16], [SHANKAR16]), which
   impacts the QoE of the communication.  The Optimized Link State
   Routing (OLSR) protocol defined in [RFC3626] and further optimized by
   [RFC7181], was developed as a proactive protocol for mobile ad-hoc
   networks to exchange and update the network topology periodically.
   It reduces the end-to-end latency and improves the QoE.  Although a
   set of Multi-Point Relays (MPR) is selected by each node to reflect
   control traffic efficiently, thus avoiding flooding the overall
   network, the frequent periodic refreshing leads to higher power
   consumption, which is not desirable for battery enabled devices.  RPL
   [RFC6550] (Routing Protocol for Low-Power and Lossy Networks) targets
   wireless networks with low power consumption, with the main target
   being many-to-one communication over IEEE 802.15.4, and thus possibly
   not providing the desired QoE in different use cases.  Its routing
   based on a proactive distance vector approach.  The Babel routing
   protocol, also based on a distance vector approach, has been designed
   to be robust and efficient on both wireless mesh networks and wired
   networks [RFC8966], and has been chosen by the Homenet WG as
   mandatory to implement.  It includes various mechanisms to avoid
   loops, which however may lead to slow topology updates (still,
   preserving connectivity), which may hinder QoE.  Babel does focus on
   energy efficiency for realizing its topology update.

   Having identified the topology and service updates in such dynamic
   environment as a key contributing factor to the overall QoE, this
   memo introduces a mechanism we term 'sloppy topology updates for ad-
   hoc routing protocols' (STURP) for improving on topology updates.
   This is achieved through a proactive mechanism that limits updates
   for topology changes, e.g., through nodes joining or leaving, only to
   those cases where ongoing communication relations would be affected.
   As a consequence, full topology updates are postponed to regular
   intervals instead, while ongoing communication may continue, using
   partially correct topology information only.  Through this, our
   approach strikes a balance between reducing the power consumption
   (and memory footprint) while keeping the QoE thanks to the
   proactiveness of its mechanism.

   In the remainder of this document, we first provide an overview of
   the protocol in Section 4, followed by the protocol interactions in
   Section 5.

Lou, et al.             Expires 29 December 2024                [Page 3]
Internet-Draft                    STURP                        June 2024

                            +----------+
                            | WIFI AP0 |
                            +----------+
                             /        \
                            / --PLC--  \
                  +----------+       +----------+
                  | WiFi AP1 |       | WiFi AP2 |
                  +----------+       +----------+
                  /    \                /     \
                 / WiFi \              / WiFi  \
           +-----+  +-------+      +----+    +----+
           | Pad |  | Phone |      | TV |    | PC |
           +-----+  +-------+      +----+    +----+
                      /   \                     |
                     / BLE \                    | BLE
              +---------+  +-----+         +---------+
              | Watch A |  | Pod |         | Speaker |
              +---------+  +-----+         +---------+

             Figure 1: Mobile Ad-Hoc Network for Smart Devices.

2.  Terminology

   This memo uses the terms defined in the MANET Neighborhood Discovery
   Protocol (NHDP) [RFC6130], the Generalized MANET Packet/Message
   Format [RFC5444], the TLVs specified in [RFC5497], the Optimized Link
   State Routing protocol (OLSR) [RFC3626], and the Optimized Link State
   Routing protocol Version 2 (OLSRv2) [RFC7181].  This document assumes
   that the reader is familiar with the aforementioned MANET protocols
   and algorithms.

3.  Requirements Language

   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.

4.  Protocol Overview

   The protocol operates as table driven, distance vector, proactive
   routing protocol exchanging topology information regularly with
   neighbors for mobile ad-hoc networks (MANETs).  It works in a
   completely distributed manner without any centralized control entity.
   Every node in the network stores the overall network topology
   information in local table(s) in order to route packets hop-by-hop.
   Routes are immediately available when needed.

Lou, et al.             Expires 29 December 2024                [Page 4]
Internet-Draft                    STURP                        June 2024

   Network nodes periodically send Hello Messages, as shown in Figure 5,
   to their 1-hop neighbors to establish/maintain the neighbor
   relationship.  After receiving the address and link information from
   a neighbor, the node will update its Neighbor Information
   Table (NIT).  Each node furthermore maintains a sequence number for
   each neighbor to track historical progress of communication with the
   respective neighbors.

   Furthermore, the hello message is used to check whether the topology
   information is synchronized between several neighbors or not.  For
   this, a 'topology hash' is transmitted, calculated over ALL NITs
   available at a node.  Consequently, receiving the same hash value
   from a neighbor indicates that the receiving node's topology
   information is in sync with this sending neighbor, while the usage of
   a single hash value reduces the size of the message and communication
   power consumption since no full topology information is sent in the
   hello message.  As another advantage of the compact size of hello
   messages in our STURP (due to the avoidance of exchanging full
   topology information), they may be carried in the payload of link
   layer broadcast messages (e.g.  BLE, Zigbee, WIFI) as an
   optimization, further improving the energy efficiency of the system.

   Key to the 'sloppy updates' mentioned in the introduction, a 'Sync
   Radius' is introduced to reflect which part of the network is fully
   synchronized with respect to topology information.  A sync radius
   value N indicates that all nodes within N hops from the current node
   share the same topology information; the calculation of the sync
   radius is described in more detail in section Section 5.2.  As a
   consequence, a packet can be routed to any node within this 'radius'.
   With this, the sync radius value provides an easy and efficient
   manner to determine whether there is a need to perform a network
   topology refresh before launching an application/service.

   In other words, if existing service/application communication happens
   within the sync radius, it is concluded that the service is not
   affected and thus no flooding of the network is required.  Instead,
   the neighbor nodes merely update their own NITs, topology information
   and topology hash values, while the overall topology refreshing is
   triggered either in the next freshing cycle, or by a launch of new
   applications/services.

5.  Protocol Interactions

   The protocol functionality specifies the behavior of a node
   participating in the network and running as a routing protocol.  It
   covers neighbor acquisition, topology refreshing and route
   calculation.

Lou, et al.             Expires 29 December 2024                [Page 5]
Internet-Draft                    STURP                        June 2024

5.1.  Neighbor Acquisition

   When a node receives a hello message, it records the IP address of
   the neighbor into its NIT, as shown in Table 1.  The NIT of a node
   contains the neighbor router IDs, the addresses of 1-hop neighbors,
   the type and cost of the link.  The Table 1 provides an example
   illustrating that node A has 2 neighbors, B and C.  The link between
   node A and B is bluetooth, while the link between A and C is WiFi.
   The cost of the link is defined based on the bandwidth capacity.  For
   instance the cost of WiFi will be lower than the cost of bluetooth,
   as WiFi could provide bigger bandwidth than bluetooth.

       +====================+==================+===========+======+
       | Neighbor Router ID | Neighbor Address | Link Type | Cost |
       +====================+==================+===========+======+
       | B                  | Address B        | BLE       | X    |
       +--------------------+------------------+-----------+------+
       | C                  | Address C        | WiFi      | X    |
       +--------------------+------------------+-----------+------+

                   Table 1: Neighbor Information Table

   Via neighbor detection, each node obtains the information of a list
   of 1-hop neighbors which it can communicate directly, stored in the
   NIT of this node.

   Besides the NIT, each node contains a Topology Information Database
   (TIDB).  After the exchange of the hello message, a node checks
   whether there is any update in the NIT table.  Any change in the
   "Neighbor Address" column indicates a change in the local
   neighborhood.  If it detects a new node joining, it will further
   exchange with the new node the created/updated NIT in order to
   synchronize the TIDB.  The synchronization of the TIDBs between 2
   neighbors will be done by exchanging the Topology Synchronization
   Message (TSM).  The format of TSM is depicted in section Section 6.2.
   Once the synchronization is done, the node will update the Topology
   Hash Value (THV) accordingly.  If it detects a node depart, it will
   only update the topology hash without exchanging the TSM.

   The workflow of the neighbor detection and topology exchange is shown
   in the Figure 2

     Node A                                Node B
     |----+                                  |----+
     |    | 1. node startup                  |    | 1. node startup
     |<---+                                  |<---+
     |          2. Hello Message             |
     |-------------------------------------->|

Lou, et al.             Expires 29 December 2024                [Page 6]
Internet-Draft                    STURP                        June 2024

     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
     | | Addr A| Hash(0)| Sync R.(0) |       |
     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
     |<--------------------------------------|
     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |       | Addr B| Hash(0)| Sync R.(0) | |
     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                                       |
     | 3. Create NIT A                       | 3. Create NIT B
     | +-+-+-+-+-+-+-+-+-+-+-+               | +-+-+-+-+-+-+-+-+-+-+-+
     | |N. addr| Link | Cost |               | |N. addr| Link | Cost |
     | +-+-+-+-+-+-+-+-+-+-+-+               | +-+-+-+-+-+-+-+-+-+-+-+
     | |Addr B | BLE  |  XXX |               | |Addr A | BLE  |  XXX |
     | +-+-+-+-+-+-+-+-+-+-+-+               | +-+-+-+-+-+-+-+-+-+-+-+
     |                                       |
     | 4. Create TIDB A                      | 4. Create TIDB B
     | +-+-+                                 | +-+-+
     | | A |                                 | | B |
     | +-+-+                                 | +-+-+
     |                                       |
     |       5. Topology Sync Message        |
     |<------------------------------------->|
     |                                       |
     | 6. Update TIDB A                      | 6. Update TIDB B
     | +-+-+                                 | +-+-+
     | | A |                                 | | A |
     | +-+-+                                 | +-+-+
     | | B |                                 | | B |
     | +-+-+                                 | +-+-+
     |                                       |
     |          7. Hello Message             |
     |-------------------------------------->|
     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
     | | Addr A| Hash(X)| Sync R.(0) |       |
     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
     |<--------------------------------------|
     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |       | Addr B| Hash(X)| Sync R.(0) | |
     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                                       |
     | 8. Update Sync Radius                 | 8. Update Sync R.
     | Sync R. = 1                           | Sync R. = 1
     |                                       |

        Figure 2: Neighbor Detection and Topology Exchange Workflow.

Lou, et al.             Expires 29 December 2024                [Page 7]
Internet-Draft                    STURP                        June 2024

   step 1, node A and B start up.  step 2, node A and B exchange hello
   messages.  As there is no topology and sync radius information, both
   values are set to zero.  step 3, upon receiving the hello message
   from each other, node A and B create their NITs.  step 4, based on
   the newly created neighbor information tables, node A and B create
   their TIDBs.  At this stage, the topology information database only
   contains their own addresses.  step 5, node A and B exchange topology
   sync message...  step 6, upon receiving the topology sync message
   from each other, node A and B updated their TIDBs.  Now both TIDBs
   are identical, leading to the same THV.  step 7, node A and B
   exchange hello messages with the same topology hash value Hash(X) in
   the next period.  Since the hash values are identical, both update
   their sync radius to 1.

5.2.  Topology Synchronization

   The periodical exchange of the hello message updates the NIT and TIDB
   between 1-hop neighbors.  A node 2-hops away gets informed of the
   topology change via the THV it received.  However, it may not trigger
   the overall network topology synchronization as long as it doesn't
   impact on existing applications and services.  Compared with neighbor
   detection, the network topology synchronization is performed
   periodically as well, but in much slower sync cycles.  When it get
   triggered, the nodes broadcast hello messages to exchange their THVs.
   The ones receive different THVs (comparing with their own) will send
   unicast topology sync messages (request) to all neighbors with
   different THV values, which respond back with their own TIDB in the
   form of TSM, as shown in Figure 3.

   All nodes update their TIDBs and calculate new THVs based on received
   TSM messages.  Hello messages will be then broadcasted with updated
   THVs.  If the THV alters, the node continues sending unicast TSM
   (request) to all neighbors with different THV values until all THVs
   stay the same.

Lou, et al.             Expires 29 December 2024                [Page 8]
Internet-Draft                    STURP                        June 2024

   +----------------------------------+
   |     Start Topology Refreshing    |
   +----------------------------------+
                    |
                    V
      +--------------------------+
      |  Broadcast Hello Message |
      |  to all neighbors        |<------------------+
      +--------------------------+                   |
                    |                                |
                    V                                |
      +-------------------------+       +--------------------------+
     /                           \  No  | Unicast TSM to neighbors |
    |  THV(received) == THV(own)  | --> |  with different THVs     |
     \                           /      +--------------------------+
      +-------------------------+
                    |  Yes
                    V
              +------------+
              |    END     |
              +------------+

                Figure 3: The Topology Refreshing Procedure.

   Then hello messages will be sent out to compute the sync radius
   value, as shown in Figure 4 depends on the THV.  Assuming node A has
   K neighbors (N1, N2,..., Nk), the THV is Hash(A) and the sync radius
   is R(A).

Lou, et al.             Expires 29 December 2024                [Page 9]
Internet-Draft                    STURP                        June 2024

   +-----------------+
   |     R(A) = 0    |
   +-----------------+
            |
            V
   +------------------+
   | Exchange TIDB&THV|
   | with neighbors   |<---------------+
   +------------------+                |
            |                          |
            V                          |
    +-------------------+    No   +----------+
   / for i = (1, 2...K)  \ -----> | R(A) = 0 |
   \ Hash(A) = Hash(Ni)? /        +----------+
    +-------------------+
            |  Yes
            V
   +----------------------------------------+
   | R(A) = min[R(N1), R(N2),...,R(Nk)] + 1 |
   +----------------------------------------+
           |
           V
     +------------+
     |    END     |
     +------------+

                     Figure 4: Sync Radius Calculation.

   From Figure 4, one can see that the calculation of the sync radius
   value can be accomplished by exchanging TIDB&THV only with neighbors
   without involving >2 hops communication.

   The network topology synchronization can be triggered by application
   launch as well.  A node can launch an application as long as it meets
   the following 2 conditions: - Its THV equals the THV from one of the
   neighbors - Its sync radius value is larger or equal to the number of
   hops between the source and the destination Otherwise, TSMs will be
   flooded to synchronize the network topology.

5.3.  Routing Table Calculation and Configuration

   Each node maintains a routing table which allows it to route data,
   destined for the other nodes in the network.  The routing table is
   based on the information contained in the TIDB.  If the TIDB is
   updated, the routing table is recalculated to update the route
   information about each destination in the network.  The route entries
   are recorded in the routing table in the following format:

Lou, et al.             Expires 29 December 2024               [Page 10]
Internet-Draft                    STURP                        June 2024

        1.  Dest_addr, Next_addr, Link
        2.  Dest_addr, Next_addr, Link
        3.      ,,         ,,       ,,

   Each entry in the table consists of Dest_addr, Next_addr and Link.
   Such entry specifies that for a specific application routing towards
   the Dest_addr, the enxt hop is Next_addr that is reachable through
   the media "Link".  Entries are recorded in the routing table for each
   destination in the network for which a route is known.  All the
   destinations, for which a route is broken or only partially known,
   are not recorded in the table.

6.  Message Encodings

6.1.  Hello Message

   A node periodically exchanges the hello message with its neighbors to
   create/maintain the NIT.  The format of the hello message is as
   follows:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Router Id                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Topology Hash                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Reserved                        |   Sync Radius   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: Hello Message Format.

   *  Router ID: Unique router identifier.  Could be the address of the
      node.

   *  Topology Hash: It is a 32-bit hash value of the topology
      compromising of all NITs stored locally.

   *  Reserved: Field reserved for future use.  MUST be set to zero on
      transmission and MUST be ignored on reception.

   *  Sync Radius: The 1-byte sync radius N indicates that all nodes
      within N hops share the same topology information at the moment.
      The sync radius of a node changes as the network topology alters.

Lou, et al.             Expires 29 December 2024               [Page 11]
Internet-Draft                    STURP                        June 2024

6.2.  Topology Synchronization Message

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |     Type      |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Router ID                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Nonce                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        No. of Records         |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Record 1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .......                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Record N                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: Topology Sync Message Format.

   *  Version: This 8-bit field is assigned to the version of this
      protocol.  Implementations of the specifications in this document
      MUST use the value 1.

   *  Type: This 8-bit field shows the type of the message (1 = Request;
      2 = Response).

   *  Reserved: Field reserved for future use.  MUST be set to zero on
      transmission and MUST be ignored on reception.

   *  Router ID: Unique router identifier.  Could be the address of the
      node.

   *  Nonce: This is an 4-octet random value created by the sender of
      the request This nonce will be returned in the corresponding
      reply.  The nonce is used as an index to identify the
      corresponding request when a reply message is received.  The nonce
      MUST be generated by a properly seeded pseudo-random source; for
      example, see [RFC4086].

   *  No. of Records: It shows the number of records in the TIDB
      attached to this message.

Lou, et al.             Expires 29 December 2024               [Page 12]
Internet-Draft                    STURP                        June 2024

   *  Reserved: Field reserved for future use.  MUST be set to zero on
      transmission and MUST be ignored on reception.

   *  Record 1..N: The appended records from the TIDB.  Each records
      represents a neighbor information advertisement message.

   The format of the Record is as follows:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |No.of Neighbors|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Node ID                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved             |     Sequence Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Neighbors                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Extension                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: Neighbor Information Table Advertisement Message Format.

   *  Type: This 8-bit field indicates the type of NITA.

   *  Length: It indicates the length of this NITA message in bytes.

   *  No. of Neighbors: It indicates the number of neighbors of the
      node.

   *  Reserved: Field reserved for future use.  MUST be set to zero on
      transmission and MUST be ignored on reception.

   *  Node ID: The unique identifier of the node, could be the address
      of the node.

   *  Reserved: Field reserved for future use.  MUST be set to zero on
      transmission and MUST be ignored on reception.

   *  Sequence Number: It is a self-incremental value, starting from a
      random number.  A bigger number indicates a more recent version of
      the NIT.

Lou, et al.             Expires 29 December 2024               [Page 13]
Internet-Draft                    STURP                        June 2024

   *  Neighbors: The neighbor information message, as defined in
      Figure 8, a 12-byte message illustrating the type and cost of the
      link, as well as the address of the neighbor.

   *  Extension: The extension field can be filed with addtional
      application layer node information so that it can be spread
      throughout the network along with the routing information, in
      order to improve the overall messaging efficiency.  For instance,
      inserting the service capabilities onto the extension field enable
      the node to directly find the services in the local routing
      information database, instead of looking up services across the
      network using mDNS and DNS-SD protocol.  Integrating the public
      key onto the extension field enables secure communicate without
      explicit key exchange.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type               |            Cost                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8: Link Message Format.

   *  Destination Address: It is the IP address of the node at the other
      side of the link.

   *  Type: It refers the type of the link, e.g.  WiFi, Ethernet,
      Bluetooth, etc..

   *  Cost: The cost of the link, defined as follows:??

7.  Conclusions

   TBD.

8.  Security Considerations

   TBD. # IANA Considerations

   TBD.

9.  References

9.1.  Normative References

Lou, et al.             Expires 29 December 2024               [Page 14]
Internet-Draft                    STURP                        June 2024

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

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              DOI 10.17487/RFC3561, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3561>.

   [RFC3626]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003,
              <https://www.rfc-editor.org/rfc/rfc3626>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
              <https://www.rfc-editor.org/rfc/rfc5444>.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              DOI 10.17487/RFC5497, March 2009,
              <https://www.rfc-editor.org/rfc/rfc5497>.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6130>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6550>.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, DOI 10.17487/RFC7181, April 2014,
              <https://www.rfc-editor.org/rfc/rfc7181>.

Lou, et al.             Expires 29 December 2024               [Page 15]
Internet-Draft                    STURP                        June 2024

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

   [RFC8966]  Chroboczek, J. and D. Schinazi, "The Babel Routing
              Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8966>.

9.2.  Informative References

   [SHANKAR16]
              Shankar, A., Chelle, L., and , "Performance Comparison of
              AODV, DSR, DSDV and OLSR MANET Routing Protocols", ESRSA
              Publications Pvt. Ltd., International Journal of
              Engineering Research and vol. V5, no. 10,
              DOI 10.17577/ijertv5is100173, October 2016,
              <https://doi.org/10.17577/ijertv5is100173>.

   [SHARMA16] Sharma, A. and R. Kumar, "Performance comparison and
              detailed study of AODV, DSDV, DSR, TORA and OLSR routing
              protocols in ad hoc networks", IEEE, 2016 Fourth
              International Conference on Parallel, Distributed and Grid
              Computing (PDGC), DOI 10.1109/pdgc.2016.7913218, 2016,
              <https://doi.org/10.1109/pdgc.2016.7913218>.

Authors' Addresses

   Zhe 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

   Dirk Trossen
   Huawei Technologies Dusseldorf GmbH.
   Riesstrasse 25
   80992 Munich
   Germany

Lou, et al.             Expires 29 December 2024               [Page 16]
Internet-Draft                    STURP                        June 2024

   Email: dirk.trossen@huawei.com

   Zhaochen Shi
   Huawei Technologies
   Beijing
   100095
   China
   Email: shizhaochen@huawei.com

Lou, et al.             Expires 29 December 2024               [Page 17]