Internet Engineering Task Force H. Pfeifer, Ed.
Internet-Draft ProtocolLabs
Intended status: Informational S. Widmann
Expires: August 15, 2019 University for Applied Sciences Munich
February 11, 2019
Dynamic MultiPath Routing Protocol
draft-pfeifer-rtgwg-dmpr-00
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 upper limit.
DMPR can be used to manage huge networks with a similar feature set
as BGPv4 except for the concept of autonomous systems.
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 August 15, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Pfeifer & Widmann Expires August 15, 2019 [Page 1]
Internet-Draft Dynamic MultiPath Routing February 2019
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Routing Table . . . . . . . . . . . . . . . . . . . . . . 6
3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Neighbor Detection . . . . . . . . . . . . . . . . . . . 6
3.2. Detection of a Lost Neighbor . . . . . . . . . . . . . . 6
3.3. Interface Handling . . . . . . . . . . . . . . . . . . . 6
3.4. Message Handling . . . . . . . . . . . . . . . . . . . . 7
3.5. Policies . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Link Attributes . . . . . . . . . . . . . . . . . . . . . 7
3.7. Route Selection . . . . . . . . . . . . . . . . . . . . . 7
3.8. Routing Data Calculation . . . . . . . . . . . . . . . . 8
3.9. Network Retraction . . . . . . . . . . . . . . . . . . . 8
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 9
4.1. Core Configuration . . . . . . . . . . . . . . . . . . . 9
4.2. Path Metric Profiles . . . . . . . . . . . . . . . . . . 9
4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 9
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Preamble . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Extension Header . . . . . . . . . . . . . . . . . . 11
5.1.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3.1. Payload: keep-alive . . . . . . . . . . . . . . . 11
5.1.3.2. Payload: uncompressed JSON . . . . . . . . . . . 12
5.1.3.3. Payload: compressed JSON . . . . . . . . . . . . 12
5.1.3.4. Payload: Fragmentation . . . . . . . . . . . . . 12
5.2. JSON Payload . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Full Update . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. Partial Update . . . . . . . . . . . . . . . . . . . 17
5.3. Requests . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Reflections . . . . . . . . . . . . . . . . . . . . . . . 18
6. Optional Features . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Asymmetric Link Detection . . . . . . . . . . . . . . . . 19
6.2. Full Only Mode . . . . . . . . . . . . . . . . . . . . . 19
7. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 19
Pfeifer & Widmann Expires August 15, 2019 [Page 2]
Internet-Draft Dynamic MultiPath Routing February 2019
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Policies . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Low Loss Policy . . . . . . . . . . . . . . . . . . . . . 20
A.2. High Bandwidth Policy . . . . . . . . . . . . . . . . . . 20
Appendix B. Tuneables . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
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
Pfeifer & Widmann Expires August 15, 2019 [Page 3]
Internet-Draft Dynamic MultiPath Routing February 2019
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 a multicast message to all its
neighbors. This message includes the 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
multicast messages. This is 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.
Pfeifer & Widmann Expires August 15, 2019 [Page 4]
Internet-Draft Dynamic MultiPath Routing February 2019
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.
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).
Pfeifer & Widmann Expires August 15, 2019 [Page 5]
Internet-Draft Dynamic MultiPath Routing February 2019
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
Each node listens to a multicast address. This multicast address
SHOULD be configurable. Periodically, after a defined message
interval + jitter, a node sends out its routing message, which
includes:
o All nodes it has a path to, including the networks they advertise
o For each policy, a path to each node it knows of.
o 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.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
Pfeifer & Widmann Expires August 15, 2019 [Page 6]
Internet-Draft Dynamic MultiPath Routing February 2019
(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
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.
Pfeifer & Widmann Expires August 15, 2019 [Page 7]
Internet-Draft Dynamic MultiPath Routing February 2019
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:
o A destination is reachable via a new interface
o The hold timer of a message in the Message Information Base is
expired (a destination is not reachable anymore via a specific
interface
o 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 | known as | as retracted | |
| not | retracted | in a message | |
| retracted | | | |
+-------------+------------+---------------+------------------------+
| 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 |
+-------------+------------+---------------+------------------------+
Pfeifer & Widmann Expires August 15, 2019 [Page 8]
Internet-Draft Dynamic MultiPath Routing February 2019
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.
o Multicast IPv4 Address: This is the address, where the routing
messages are sent to. DMPR listens to this interfaces for
incoming routing messages.
o Multicast IPv6 Address: This is the address, where the routing
messages are sent to. DMPR listens to this interfaces for
incoming routing messages.
o Routing message interval: The interval of sending the routing
messages to the defined multicast address.
o 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:
o The name of the interfaces
o IPv4 Address of the interface
o IPv6 Address of the interface
o All link attributes which are available to describe the interface.
These attributes are used to calculate the best routes for the
Pfeifer & Widmann Expires August 15, 2019 [Page 9]
Internet-Draft Dynamic MultiPath Routing February 2019
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 |
+---------+--------------------------------------------+
Possible Types are defined in further detail below
Table 1: Possible Types
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
NextType
The type of the next header or payload.
Pfeifer & Widmann Expires August 15, 2019 [Page 10]
Internet-Draft Dynamic MultiPath Routing February 2019
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 August 15, 2019 [Page 11]
Internet-Draft Dynamic MultiPath Routing February 2019
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 August 15, 2019 [Page 12]
Internet-Draft Dynamic MultiPath Routing February 2019
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.
Pfeifer & Widmann Expires August 15, 2019 [Page 13]
Internet-Draft Dynamic MultiPath Routing February 2019
General Message Structure
{
"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>
}
}
}
Pfeifer & Widmann Expires August 15, 2019 [Page 14]
Internet-Draft Dynamic MultiPath Routing February 2019
Key and value description:
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 5
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
Pfeifer & Widmann Expires August 15, 2019 [Page 15]
Internet-Draft Dynamic MultiPath Routing February 2019
object: a list of networks for each reachable node defined in
"routing-data". "networks" is handled like "networks" defined
above.
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 August 15, 2019 [Page 16]
Internet-Draft Dynamic MultiPath Routing February 2019
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 August 15, 2019 [Page 17]
Internet-Draft Dynamic MultiPath Routing February 2019
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 August 15, 2019 [Page 18]
Internet-Draft Dynamic MultiPath Routing February 2019
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. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.
9. 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.
10. 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.
11. References
11.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>.
Pfeifer & Widmann Expires August 15, 2019 [Page 19]
Internet-Draft Dynamic MultiPath Routing February 2019
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
11.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:
o Loss rate
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:
o Bandwidth
Appendix B. Tuneables
The different magic values and what they affect, how they could/
should be set
Pfeifer & Widmann Expires August 15, 2019 [Page 20]
Internet-Draft Dynamic MultiPath Routing February 2019
Appendix C. Examples
Examples
Authors' Addresses
Hagen Paul Pfeifer (editor)
ProtocolLabs
Agnes Bernauer Str. 84
Munich 80687
DE
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
Munich 80335
DE
Email: sebastian-widmann@t-online.de
Pfeifer & Widmann Expires August 15, 2019 [Page 21]