Internet DRAFT - draft-pfeifer-rtgwg-dmpr

draft-pfeifer-rtgwg-dmpr







Internet Engineering Task Force                      H.P.P. Pfeifer, Ed.
Internet-Draft                                              ProtocolLabs
Intended status: Informational                              S.W. Widmann
Expires: 31 May 2022              University for Applied Sciences Munich
                                                        27 November 2021


                   Dynamic MultiPath Routing Protocol
                      draft-pfeifer-rtgwg-dmpr-01

Abstract

   Dynamic MultiPath Routing (DMPR) is a loop free path vector routing
   protocol with built-in support for policy based multipath routing.
   It has been designed from scratch to work at both low and high
   bandwidth networks - even with high packet loss.  The objective was
   to keep routing overhead low and ensure a deterministic protocol
   exchange behavior.  DMPR can be used to manage larger networks with
   characteristics based on BGPv4 with transport and self-configuration
   properties taken from OSPF/OLSR.  Unlike BGPv4 or OSPF, DMPR does not
   support higher network separation concepts.  A DMPR network is a flat
   network in which DMPR nodes have equal tasks.  This also applies to
   DMPR communication.  Unlike OLSR/OSPF there is no flooding messages
   (topology broadcast), information are stored, accumulated/compressed
   and forwarded at each DMPR node.  This feature contributes to the
   message load being deterministic.

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 31 May 2022.

Copyright Notice

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



Pfeifer & Widmann          Expires 31 May 2022                  [Page 1]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Organization of this Document . . . . . . . . . . . . . .   4
     1.4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.5.  Distinction from other Routing Protocols  . . . . . . . .   5
   2.  Data Structures . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Message Information Base  . . . . . . . . . . . . . . . .   5
     2.2.  Routing Data  . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Routing Table . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Neighbor Detection  . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Multicast Neighbor Detection  . . . . . . . . . . . .   6
       3.1.2.  Unicast Neighbor Detection  . . . . . . . . . . . . .   7
     3.2.  Detection of a Lost Neighbor  . . . . . . . . . . . . . .   7
     3.3.  Interface Handling  . . . . . . . . . . . . . . . . . . .   7
     3.4.  Message Handling  . . . . . . . . . . . . . . . . . . . .   7
     3.5.  Policies  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  Link Attributes . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  Route Selection . . . . . . . . . . . . . . . . . . . . .   8
     3.8.  Routing Data Calculation  . . . . . . . . . . . . . . . .   8
     3.9.  Network Retraction  . . . . . . . . . . . . . . . . . . .   9
   4.  Protocol Parameters . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Core Configuration  . . . . . . . . . . . . . . . . . . .  10
     4.2.  Path Metric Profiles  . . . . . . . . . . . . . . . . . .  10
     4.3.  Interfaces  . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Header  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.1.  Preamble  . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.2.  Extension Header  . . . . . . . . . . . . . . . . . .  12
       5.1.3.  Payload . . . . . . . . . . . . . . . . . . . . . . .  12
         5.1.3.1.  Payload: keep-alive . . . . . . . . . . . . . . .  12
         5.1.3.2.  Payload: uncompressed JSON  . . . . . . . . . . .  13
         5.1.3.3.  Payload: compressed JSON  . . . . . . . . . . . .  13
         5.1.3.4.  Payload: Fragmentation  . . . . . . . . . . . . .  13
     5.2.  JSON Payload  . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Full Update . . . . . . . . . . . . . . . . . . . . .  17



Pfeifer & Widmann          Expires 31 May 2022                  [Page 2]

Internet-Draft          Dynamic MultiPath Routing          November 2021


       5.2.2.  Partial Update  . . . . . . . . . . . . . . . . . . .  18
     5.3.  Requests  . . . . . . . . . . . . . . . . . . . . . . . .  19
     5.4.  Reflections . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  Optional Features . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Asymmetric Link Detection . . . . . . . . . . . . . . . .  20
     6.2.  Full Only Mode  . . . . . . . . . . . . . . . . . . . . .  20
   7.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  Bidirectional Forwarding Detection  . . . . . . . . . . . . .  20
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     12.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Policies . . . . . . . . . . . . . . . . . . . . . .  21
     A.1.  Low Loss Policy . . . . . . . . . . . . . . . . . . . . .  21
     A.2.  High Bandwidth Policy . . . . . . . . . . . . . . . . . .  22
   Appendix B.  Tuneables  . . . . . . . . . . . . . . . . . . . . .  22
   Appendix C.  Examples . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Todays mobile wireless networks have a diversity of requirements on
   the wireless links.  To meet these requirements, it is possible to
   attach multiple network access technologies on the router and select,
   depending on the CoS of the packet, over which wireless link the
   packet is sent.  This is the main idea of policy based multipath
   routing.  The established routing protocols do not support the use of
   multiple access technologies on a single router.  To tackle this
   issues, DMPR as been developed as a protocol for policy based
   multipath routing in and between mobile networks, which consist of
   multiple wireless links with different characteristics.  DMPR makes
   it possible to calculate multiple routing tables and maintain the
   best paths for multiple policies.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Terminology

   The following list describes the terminology used in this RFC






Pfeifer & Widmann          Expires 31 May 2022                  [Page 3]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   Router, Node
      A router (or a node) is a routing entity of a network.  It runs an
      implementation of DMPR, has zero or more networks attached and at
      least one link to another router.

   Link
      A link is the direct connection between two interfaces of two
      distinct routers.

   Link Attribute
      A link attribute is a basic attribute of a link, for example the
      maximum bandwidth, the average packet loss or the cost of the
      link.

   Path
      A Path in DMPR is one or more successive, directly connected links
      which define a loop-free path from one node to another.

   Policy
      A policy describes an arrangement relation over a set of paths
      using the link attributes of these paths.  Note that to guarantee
      loop-free properties this arranging function MUST be commutative
      and associative.  Policy examples can be found in Appendix A

1.3.  Organization of this Document

   Section 2 describes the information every node has and gets and how
   it should handle this information.  Section 3 describes the behavior
   of the protocol in different scenarios and how it achieves particular
   features.  Section 5 describes the message format in detail.
   Section 6 describes optional features that can be implemented to
   improve or extend DMPR but are not required for the basic
   functionality of propagating routing information.

   Appendix A has a few policy examples.  Appendix B lists all constants
   used in this RFC where some of them are configurable.  Appendix C
   shows a few simple examples of how DMPR behaves under specific
   network conditions.

1.4.  Overview

   Every router periodically sends out unicast or multicast messages to
   all routing enabled links.  This message already includes routers
   database (best path to each node) known by this router.  A router
   receiving this message adds itself to all these paths, chooses the
   best path to each node among all those it got from its neighbors and
   advertises these paths itself via unicast or multicast messages (if
   received as Unicast, it MUST be returned as unicast).  This is



Pfeifer & Widmann          Expires 31 May 2022                  [Page 4]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   standard procedure in a path-vector routing protocol.  In DMPR the
   paths are further separated by a policy, therefore it is possible to
   have more than one path to each node.  Also included in the message
   are all attributes of this path so that the receiving node can make
   informed decisions on whether this path is the best under the current
   policy.  In the end there exist multiple paths through the network
   and packets can be routed according to their requirements which for
   example can be the path with the highest bandwidth or with the lowest
   latency.

1.5.  Distinction from other Routing Protocols

   Traditionally, routing protocols find the best path using a scalar
   metric.  This metric may be a simple constant stating the preference
   of the link or may be a computed metric using several factors such as
   bandwidth, latency or cost.  Furthermore, this metric is only known
   locally or, for example in the case of BGP-4, where external paths
   can be marked with a local preference for internal peers, to a small
   subset of the network.  In DMPR a policy is a globally defined
   function that defines a function how to determinate the best path.
   For this reason, the policy has all link attributes of each path at
   its disposal and therefore has a higher control over which path it
   chooses.

2.  Data Structures

   To maintain the routing data, all data extracted from the received
   routing messages is organized in different data structures.  These
   data structures are used for calculating the routes and creating of
   the routing tables.

2.1.  Message Information Base

   Every message received by a node is saved in the Message Information
   Base.  This data structure is the basis for all subsequently emitted
   routing messages and the routing table.  The Message Information Base
   contains the latest (by sequence number) received message for each
   neighbor.  Each entry is controlled by a hold timer and is purged
   after the hold timer expires.  This timer is reset as soon as a new
   valid message from this neighbor is received.  This data structure
   contains potentially duplicate or conflicting data since many
   neighbors send their paths and subnet information for all nodes they
   know of.  This is intended and required because any message may be
   deleted at almost any time when its hold timer expires.







Pfeifer & Widmann          Expires 31 May 2022                  [Page 5]

Internet-Draft          Dynamic MultiPath Routing          November 2021


2.2.  Routing Data

   The Routing Data is computed from the Message Information Base.  In
   contrast to the Message Information Base this is data structure
   contains no conflicting information and can be seen as the single
   source of truth for the routing table and routing message generation.
   It contains the best path to each known node grouped by policy.
   Furthermore the advertised subnets from each node are combined while
   following the network retraction rules (see Section 3.9).

2.3.  Routing Table

   The routing table contains the best path to each known subnet grouped
   by policy.  This table is meant to be inserted into the underlying
   operating system's routing table.

3.  Behavior

3.1.  Neighbor Detection

   DMPR supports unicast and multicast neighbor detection and transport
   schemes.  The scheme MUST be configurable at link level (e.g. eth0:
   multicast, eth1: unicast).  Multicast provides ad-hoc capabilities
   without prior knowledge of neighbor nods.  The multicast detection
   mechanism and transport mechanism are similar to those of other ad-
   hoc routing protocols such as OLSR.

   Unicast detection and transport lacks support of ad-hoc
   configuration: the neighbor list must be configured a prior.  The
   advantage of using unicast is that DMPR can also be used on networks
   that do not or insufficiently support multicast.  Notes: an
   alternative for the use of unicast is the use of tunnels (IPIP, GRE,
   ...).  For example, the tunnel is the preferred solution when BGAN
   terminals or routing foreign segments must be bridged.

   DMPR is build around the concept of identifying nodes uniquely via
   DMPR ID.  It is therefore irrelevant whether neighbours are detected
   several times via different links and unicast or multicast.

3.1.1.  Multicast Neighbor Detection

   Each node listens to a unicast or multicast address at each enabled
   DMPR link.  If multicast, the multicast address SHOULD be
   configurable.  Periodically, after a defined message interval +
   jitter, a node sends out its routing message, which includes:

   *  All nodes it has a path to, including the networks they advertise




Pfeifer & Widmann          Expires 31 May 2022                  [Page 6]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   *  For each policy, a path to each node it knows of.

   *  The attributes of the links between the paths.

   When a node receives a message, it deduces a connection and therefore
   a path to the sender via the interface that message came in.  With
   this mechanism the path to a node propagates through the network.
   Every received message SHOULD be assigned to a hold timer.  When this
   hold timer expires, the message MUST be deleted from the Message
   Information Base.  The timeout SHOULD be a multiple of the routing
   message interval.  Asymmetric links are handled with a feature called
   reflection, which is described in Section 5.4.

3.1.2.  Unicast Neighbor Detection

   For unicast, DMPR MUST support a list of IPv4/IPv6 addresses of DMPR
   neighbors at a particular link.  The messages and timeout constraints
   are identical to previous multicast section.

3.2.  Detection of a Lost Neighbor

   Whenever a neighbor is not reachable anymore (e.g. due to topology
   change), no further routing messages will be received from this
   neighbor.  As all the received messages are assigned to a timer, no
   routing messages of the lost neighbor will be present in the Message
   Information Base, after the expiration of this timer.  This means,
   that the loss of the neighbor is detected after the timeout of the
   last received routing message of the concerned neighbor.  For this
   reason, the routing table SHOLD be recalculated, whenever the Message
   Information Base is purged due to timeouts.

3.3.  Interface Handling

   In DMPR all interfaces that are registered with the DMPR daemon are
   treated completely separate from each other.  Routing messages are
   sent over each one individually.  This ensures that all possibly
   accessible neighbors are reachable.  The message information base
   (seeSection 2.1) is grouped by interface.  Therefore nodes can detect
   links on each interface individually.

3.4.  Message Handling

   Each message received by a neighbor is saved in the Message
   Information Base (seeSection 2.1).  With this message a hold timer is
   set that purges the messages after the given time.  To improve the
   message size a node can choose to only send partial updates (i.e.
   differential, only the changes since the last full update).  To
   support this a node has to retain the a version from the last full



Pfeifer & Widmann          Expires 31 May 2022                  [Page 7]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   message so it can apply the new partial message.

3.5.  Policies

   To support routing different traffic types over different routes,
   DMPR supports multiple policies.  A policy defines, how the best path
   to a destination is computed using the available link attributes.
   For all the defined policies, seperate routes will be calculated to
   every reachable destination.  The best path to all destinations is
   included in the routing message for every policy.  For each policy, a
   seperate routing table MUST be generated.  In large networks, this
   results in a multi topology routing.  When different parts of the
   network have different attributes (e.g. one path has a low loss rate,
   another path in contrast has a higher bandwidth), different subsets
   of the topology will be used to forward packets that require
   different policies (Class of Service).

3.6.  Link Attributes

   DMPR MUST know the link attributes that are required to determinate
   the best path for all the registered policies on all links
   (interfaces) to the router.  These attributes can either be
   configured staticly by the network administrator or can be
   dynamically gathered from the attached modem devices.  This RFC does
   not specify how the link information has to be gained.  There is no
   specification defining which attributes must be given to the protocol
   (e.g bandwidth, loss rate, latency).  The requirement of attributes
   depends on the policies meant to be used.

3.7.  Route Selection

   The calculation of the best route MUST be defined for each policy
   separately.  For example simple policies only consider a single link
   metric (such as bandwidth or loss rate) for the calculation of the
   best route.  Combined policies might use a combination of multiple
   link metrics.  The route selection mechanism is part of a policy's
   definition and therefore can be individually defined.

3.8.  Routing Data Calculation

   For every reachable destination, the routing data is calculated for
   all defined policies using the policy's specific route selection
   mechanism.  As a result, there MUST be a seperate routing table for
   every defined policy.  Whenever new crucial information is received,
   the routing data MUST be recalculated.  Information that causes a
   recalculation of the routing data can be:

   *  A destination is reachable via a new interface



Pfeifer & Widmann          Expires 31 May 2022                  [Page 8]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   *  The hold timer of a message in the Message Information Base is
      expired (a destination is not reachable anymore via a specific
      interface

   *  Link attributes have changed

3.9.  Network Retraction

   Each network advertised in a message has an optional flag called
   "retracted".  This flag is set to true when a node no longer
   advertises this network as available.  The only node to ever set this
   flag to true MUST be the originally advertising node.  A set
   retracted flag always supersedes an unset flag.  Networks are
   forwarded with this ruleset:

    +==============+===========+==============+=======================+
    |   Network    |  Network  | Network set  | Action to take        |
    | known as not |  known as | as retracted |                       |
    |  retracted   | retracted | in a message |                       |
    +==============+===========+==============+=======================+
    |    false     |   false   |    false     | Insert network in     |
    |              |           |              | known networks and    |
    |              |           |              | forward               |
    +--------------+-----------+--------------+-----------------------+
    |    false     |   false   |     true     | ignore network, do    |
    |              |           |              | not forward           |
    +--------------+-----------+--------------+-----------------------+
    |    false     |    true   |    false     | forward network as    |
    |              |           |              | retracted             |
    +--------------+-----------+--------------+-----------------------+
    |    false     |    true   |     true     | forward network as    |
    |              |           |              | retracted             |
    +--------------+-----------+--------------+-----------------------+
    |     true     |   false   |    false     | just forward network  |
    +--------------+-----------+--------------+-----------------------+
    |     true     |   false   |     true     | set network in known  |
    |              |           |              | networks as retracted |
    |              |           |              | and forward retracted |
    +--------------+-----------+--------------+-----------------------+
    |     true     |    true   |    false     | illegal               |
    +--------------+-----------+--------------+-----------------------+
    |     true     |    true   |     true     | illegal               |
    +--------------+-----------+--------------+-----------------------+

                                  Table 1






Pfeifer & Widmann          Expires 31 May 2022                  [Page 9]

Internet-Draft          Dynamic MultiPath Routing          November 2021


4.  Protocol Parameters

   The parameters described in this section SHOULD be configured at the
   startup of the router.  This specification does not define any values
   for the parameters.

4.1.  Core Configuration

   Core Configuration describes the fields which MUST be the same on all
   routers in the neworks.

   *  Multicast IPv4 Address: This is the address, where the routing
      messages are sent to.  DMPR listens to this interfaces for
      incoming routing messages.

   *  Multicast IPv6 Address: This is the address, where the routing
      messages are sent to.  DMPR listens to this interfaces for
      incoming routing messages.

   *  Routing message interval: The interval of sending the routing
      messages to the defined multicast address.

   *  Routing message hold time: Timeout of the received routing
      messages.  After expiration of this timeout, the received messages
      are deleted from the Message Information Base.  The hold time
      SHOULD be a multiple of the Routing message interval.

4.2.  Path Metric Profiles

   This field describes a list with all the policies which should be
   considered by the routing protocol.  The policies are referenced by
   name.  For every listed policy, the routing protocol MUST implement
   the according route selection mechanism.

4.3.  Interfaces

   This field describes a list with all the routers physical interfaces,
   which are used as DMPR interfaces.  For all interfaces following
   fields are required:

   *  The name of the interfaces

   *  IPv4 Address of the interface

   *  IPv6 Address of the interface






Pfeifer & Widmann          Expires 31 May 2022                 [Page 10]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   *  All link attributes which are available to describe the interface.
      These attributes are used to calculate the best routes for the
      defined policies.  All the attributes which are considered by at
      least one of the defined policies are required for every
      interface.  Common attribues are for example bandwith, loss rate
      and latency.

5.  Message Format

5.1.  Header

   A DMPR packet consists of a preamble, followed by zero or more
   extension headers followed by zero or one payload.  Each extension
   header and payload is defined by a type.

         +=========+============================================+
         |   Type  | Use                                        |
         +=========+============================================+
         |  0-119  | Extension Header                           |
         +---------+--------------------------------------------+
         | 120-127 | Extension Header, reserved for private use |
         +---------+--------------------------------------------+
         | 128-247 | Payload                                    |
         +---------+--------------------------------------------+
         | 248-255 | Payload, reserved for private use          |
         +---------+--------------------------------------------+

                         Table 2: Possible Types

   Possible Types are defined in further detail below

5.1.1.  Preamble

   The preamble of a DMPR packet is as follows

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Magic| Reserved|    NextType   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The preamble of a packet

   Magic
      A 3-bit Magic: 0b010

   Reserved
      Reserved for future use



Pfeifer & Widmann          Expires 31 May 2022                 [Page 11]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   NextType
      The type of the next header or payload.

5.1.2.  Extension Header

   An extension header consists of the type immediately following this
   header, a length specifier, and the Extension Header data.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    NextType   |     Length    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                              Data                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NextType
      8-bit unsigned integer: The type of the immediately following
      header or payload (same as specified in the packet preamble
      description)

   Length
      8-bit unsigned integer: The length of the Data field in 2-octets,
      this does not include NextType and Length itself

   Data
      The header-specific data according to length.  The encoding and
      type is specified by the header itself.

5.1.3.  Payload

   The Payload consists of the data from the end of the preamble or last
   extension header until the end of the packet.  Payloads may be
   recursive, i.e. contain a valid packet (or parts of it) in
   themselves.  Payload processors therefore MUST have the ability to
   feed their result back into the message processing chain.  This
   behavior is defined by the payload itself.

5.1.3.1.  Payload: keep-alive

   Type: 127

   This is a keep-alive packet, the payload length is zero.
   Implementations SHOULD reset the message hold timer for the sending
   node upon receiving a keep-alive packet




Pfeifer & Widmann          Expires 31 May 2022                 [Page 12]

Internet-Draft          Dynamic MultiPath Routing          November 2021


5.1.3.2.  Payload: uncompressed JSON

   Type: 128

   Unkompressed, plain, standard-compliant I-JSON data as described in
   [RFC7493].  This is the main routing data; its structure is defined
   in Section 5.2

5.1.3.3.  Payload: compressed JSON

   Type: 129

   LZMA-compressed standard-compliant I-JSON data as described in
   [RFC7493].  This is the main routing data; its structure is defined
   in Section 5.2

5.1.3.4.  Payload: Fragmentation

   Type: 130

   A packet greater than the MTU between two nodes SHOULD be fragmented
   using the fragmentation payload.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Identifier  |L|Packet offset|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                            Payload                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Fragmentation Payload Header

   Identifier
      Identifies possibly concurrent fragmented packets.
      Implementations SHOULD use an incrementing counter to practically
      eliminate the possibility of a collision.

   L(ast)
      Last, set to 1 if this packet has the highest packet offset in
      this fragmentation collection, i.e. is the last packet.

   Packet index
      7-bit unsigned integer.  Defines the index of this packet in the
      list of fragments resulting in the fragmentation of the original
      packet.  The first packet has offset zero.





Pfeifer & Widmann          Expires 31 May 2022                 [Page 13]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   When a packet is larger than the MTU of the link between two nodes it
   SHOULD be fragmented.  For this purpose, the sending node computes
   the maximum effective payload size for packets sent (i.e MTU less
   preamble, possibly extension headers and the fragmentation header)
   and splits the original packet into parts with this size.  For each
   of these parts, it sends a packet with the fragmentation header set
   to a common identifier, a corresponding packet offset and the LAST
   bit set for the last fragment.

   The receiving node keeps track of all received fragments, grouping
   them by source address and identifier.  As soon as all fragments of a
   packet have been received, the reconstructed packet MUST be fed back
   into the message processing chain as if it were a new, just received
   packet.  Fragments MUST be regularly purged based on a hold timer.

5.2.  JSON Payload

   A JSON payload is an ASCII-7 encoded JSON object.  A sending node
   SHOULD use ascii-encoding for the JSON data.  A receiving node MUST
   be able to decode UTF-8 encoded data.  The payload can be zip
   compressed.  A compressed payload has to be announced in the header.

   Augmented requirements language for this section:

   REQUIRED
      This field is required, the sending node MUST include it.

   REQUIRED if not empty
      If the field would be empty, it can be omitted, otherwise it is
      REQUIRED

   OPTIONAL
      This field can be inserted to activate specific features or use
      other functionality.  A sending node can choose to omit it and a
      receiving node MUST be able to work without this field.

   General Message Structure














Pfeifer & Widmann          Expires 31 May 2022                 [Page 14]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   {
     "id": <NODE_ID>,
     "seq": <SEQUENCE_NUMBER>,
     "type": <TYPE>,
     "partial-base": <SEQUENCE_NUMBER>,
     "addr-v4": <IPv4_ADDRESS>,
     "addr-v6": <IPv6_ADDRESS>,
     "networks": {
       <IPvX_NETWORK>: {},
       <IPvX_NETWORK>: {
         "retracted": true
       }
     },
     "routing-data": {
       <POLICY>: {
         <NODE_ID>: {
           "path": <PATH>
         }
       }
     },
     "node-data": {
       <NODE_ID>: {
         "networks": {
           <IPvX_NETWORK>: {},
           <IPvX_NETWORK>: {
             "retracted": true
           }
         }
       }
     },
     "link-attributes": {
       <LINK_ATTRIBUTE_ID>: {
         <LINK_ATTRIBUTE>: <METRIC>
       }
     },
     "request-full": union(true, [<NODE_ID>, ...]),
     "reflect": {
       <REFLECT_DATA>: <DATA>
     }
     "reflected": {
       <NODE_ID>: {
         <REFLECT_DATA>: <DATA>
       }
     }
   }

   Key and value description:




Pfeifer & Widmann          Expires 31 May 2022                 [Page 15]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   id
      string: The sending node's id, NODE_ID: MUST NOT contain any of
      the brackets: ()[]{}<>

   seq
      integer: The message sequence number, strictly monotonically
      increasing

   type
      string: The type of the message, specified in further detail below
      Section 5.2, Paragraph 8

   partial-base
      integer: The base message of a partial update, the message then
      only includes the difference between the actual data and the base
      message

   addr-v4
      string: The IPv4 address of the sending node over the link this
      packet has been sent.

   addr-v6
      string: The IPv6 address of the sending node over the link this
      packet has been sent.

   networks
      object: The networks advertised by this node.  The keys are valid
      IPv4/IPv6 network identifications with subnet prefix.  If the
      value of a network key is a object itself and the "retracted" key
      of this object is set to true, the network MUST be handled as
      retracted.  See Section 3.9

   routing-data
      object: A path to each reachable node for each policy.  POLICY is
      the name of a policy defined in the sending node.  If the
      receiving node does not understand this policy the entry MUST be
      ignored.  PATH: a path to a node described according to this
      syntax:

      path = node [node-id ">[" link-attribute-id "]>" path]
      node-id = *ALPHA
      link-attribute-id = *DIGIT

   node-data
      object: a list of networks for each reachable node defined in
      "routing-data". "networks" is handled like "networks" defined
      above.




Pfeifer & Widmann          Expires 31 May 2022                 [Page 16]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   link-attributes
      object: the set of link-attributes used in the paths of routing-
      data.  Each key SHOULD be an integer and MUST NOT contain any of
      the brackets ()[]{}<> The value of an entry is itself a object
      containing LINK_ATTRIBUTE: METRIC pairs where LINK_ATTRIBUTE is
      the name of a link attribute and metric is its value as defined in
      Section 1.2

   request-full
      array or true: A list of NODE_IDs from which the sending node
      requests a full update message.  If true the node requests a full
      update from all neighbors.

   reflect
      object: arbitrary data the sending node wants to have included in
      the "reflected" object in the next message of the receiver

   reflected
      object: a set of reflected data, contains, for each neighboring
      node the data the node requested to reflect.

   Each message has a type.  This RFC describes two types, namely full
   and partial, which are described in further detail here.

5.2.1.  Full Update

   A full update SHOULD replace all data from the sending node in the
   receivers Message Information Base.  It MUST NOT require any previous
   knowledge of the sender by the receiver.  The following keys are
   specified:

   addr-v4
      string, REQUIRED: The IPv4 address of the sending node over the
      link this packet has been sent.

   addr-v6
      string: REQUIRED: The IPv6 address of the sending node over the
      link this packet has been sent.

  
      Note: Only one of addr-v4 and addr-v6 is required

   networks
      object, REQUIRED if not empty: The networks advertised by this
      node.  See above






Pfeifer & Widmann          Expires 31 May 2022                 [Page 17]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   routing-data
      object, REQUIRED if not empty: The paths advertised by the sender,
      grouped by POLICY and target NODE_ID.  The syntax of a path is
      described above.  A path MUST include the sender of this message,
      all hops with their link-attribute IDs and the target node.

   node-data
      object, OPTIONAL: The networks from other nodes known to the
      sender including their retraction status.

   link-attributes
      object, REQUIRED if not empty: The link-attributes used in
      "routing-data".  Each entry MUST contain all attributes known to
      the sender, even if they are not needed by a policy.

5.2.2.  Partial Update

   A partial update only replaces the changed data in the receivers
   message information base.  It therefore has the additional field
   "partial-base" which describes the sequence number of the base
   message, which MUST be a full update message, to which the changes
   apply.  Note: A partial update only describes changes to a previous
   full update, never to a previous partial update.  If the receiving
   node is unable to apply the partial update, e.g because it lacks the
   base message, then this node SHOULD use the "request-full" procedure
   to request a new full update (seeSection 5.3).

   The following keys are specified:

   addr-v4
      string, OPTIONAL: The IPv4 address of the sending node over the
      link this packet has been sent, only included if it has not
      changed.  If it became invalid, the value is null.

   addr-v6
      string, OPTIONAL: The IPv6 address of the sending node over the
      link this packet has been sent, only included if it has not
      changed.  If it became invalid, the value is null.

  
      Note: A partial update MUST NOT produce an invalid configuration
      by deleting the only address available for a node.

   networks
      object, OPTIONAL: The networks advertised by the sender.  The
      entries replace the base message entries on a per NODE_ID basis.
      If an entry has been deleted, the value for the specific NODE_ID
      is null.



Pfeifer & Widmann          Expires 31 May 2022                 [Page 18]

Internet-Draft          Dynamic MultiPath Routing          November 2021


   routing-data
      object, OPTIONAL: The paths advertised by the sender, grouped by
      POLICY and target NODE_ID.  The entries replace the base message
      entries on a per NODE_ID basis.  If an entry has been deleted, the
      value for the specific NODE_ID is null.

   node-data
      object, OPTIONAL: The networks from other nodes known to the
      sender.  The entries replace the base message entries on a per
      NODE_ID basis.  If an entry has been deleted, the value for the
      specific NODE_ID is null.

   link-attributes
      object, REQUIRED if not empty: The link-attributes used in
      "routing-data".  Note that link-attributes are only valid on a
      per-message basis and MUST NOT replace link-attribute entries in
      the base message.

5.3.  Requests

   When a node is not able to apply a partial update or just joined a
   network, it SHOULD send out a request for a full update using the
   request-full key in the message.  This key may be an array containing
   NODE_IDs from which a full message is needed or may be the Boolean
   value true, to indicate that a full message from every neighbor is
   required.  When a node receives a request-full key in a message that
   either has the value true or its ID present in the array, it MUST do
   one of the following: variant1: schedule the next message it sents to
   be a full message.  variant2: send a full update immediately and
   reset its message interval timer, except when the last message
   already was a out-of-band full message, in which case it MUST/SHOULD
   schedule the next message according to the message interval timer to
   be a full message.

5.4.  Reflections

   Reflections are a extensible mechanism and allow a node to exchange
   data with neighboring nodes, with 2-hop neighbors and with itself.
   When a node includes arbitrary JSON data in the reflect key in its
   message, each node receiving this message MUST send this data in the
   reflected key of its messages under the corresponding NODE_ID.  A
   node MUST support reflecting all requests but is not required to
   actually parse that data.  Because the messages are sent to all
   neighbors, every 2-hop neighbor becomes aware of the reflected data
   of a node.  This fact is not used in this RFC but may be used in
   extensions of this protocol.





Pfeifer & Widmann          Expires 31 May 2022                 [Page 19]

Internet-Draft          Dynamic MultiPath Routing          November 2021


6.  Optional Features

6.1.  Asymmetric Link Detection

   How asymmetric link detection should work/how it can be implemented

6.2.  Full Only Mode

   When/how to switch the mode

7.  Introduction

   The original specification of xml2rfc format is in RFC 2629
   [RFC2629].

8.  Bidirectional Forwarding Detection

   Bidirectional Forwarding Detection CAN be used to detect link
   abortions.  DMPR is designed to reduce the network usage to a
   minimum.  Operating additionally BFD may increase the load
   unnecessarily.

   An alternative is to increase the transmission interval of DMPR
   directly.  The advantage is that no "context free" BFD packet are
   transmitted additionally, but in-line DMPR packets which reduce the
   convergence time in the entire network.  BFD would have advantages if
   the DMPR interval is in the higher minute range, but here it would
   have to be considered whether to reduce the interval and do without
   BFD.

9.  Acknowledgements

   This template was derived from an initial version written by Pekka
   Savola and contributed by him to the xml2rfc project.

10.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   Guidelines for Writing an IANA Considerations Section in RFCs
   [RFC5226] for a guide).  If the draft does not require IANA to do
   anything, the section contains an explicit statement that this is the
   case (as above).  If there are no requirements for IANA, the section
   will be removed during conversion into an RFC by the RFC Editor.






Pfeifer & Widmann          Expires 31 May 2022                 [Page 20]

Internet-Draft          Dynamic MultiPath Routing          November 2021


11.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.  Due to the Multicast
   Transmission, the routing message's payload data is unencrypted.

12.  References

12.1.  Normative References

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

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

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

12.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

Appendix A.  Policies

   many exchangeable policies

A.1.  Low Loss Policy

   use path with lowest overall loss.  Overall loss is the accumulation
   of the loss rates of all hops to a destination.  Required link
   attributes:

   *  Loss rate



Pfeifer & Widmann          Expires 31 May 2022                 [Page 21]

Internet-Draft          Dynamic MultiPath Routing          November 2021


A.2.  High Bandwidth Policy

   use path with highest bandwidth In multihop topologies, the overall
   bandwith is the minimum of the bandwidths between the hops to a
   destination.  Required link attributes:

   *  Bandwidth

Appendix B.  Tuneables

   The different magic values and what they affect, how they could/
   should be set

Appendix C.  Examples

   Examples

Authors' Addresses

   Hagen Paul Pfeifer (editor)
   ProtocolLabs
   Haslangstr. 7
   80689 Munich
   Germany

   Phone: +49 174 54 55 209
   Email: hagen@jauu.net
   URI:   http://www.jauu.net/


   Sebastian Widmann
   University for Applied Sciences Munich
   Loth Str. 64
   80335 Munich
   Germany

   Email: sebastian-widmann@t-online.de














Pfeifer & Widmann          Expires 31 May 2022                 [Page 22]