idnits 2.17.1 draft-pfeifer-rtgwg-dmpr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 November 2021) is 873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H.P.P. Pfeifer, Ed. 3 Internet-Draft ProtocolLabs 4 Intended status: Informational S.W. Widmann 5 Expires: 31 May 2022 University for Applied Sciences Munich 6 27 November 2021 8 Dynamic MultiPath Routing Protocol 9 draft-pfeifer-rtgwg-dmpr-01 11 Abstract 13 Dynamic MultiPath Routing (DMPR) is a loop free path vector routing 14 protocol with built-in support for policy based multipath routing. 15 It has been designed from scratch to work at both low and high 16 bandwidth networks - even with high packet loss. The objective was 17 to keep routing overhead low and ensure a deterministic protocol 18 exchange behavior. DMPR can be used to manage larger networks with 19 characteristics based on BGPv4 with transport and self-configuration 20 properties taken from OSPF/OLSR. Unlike BGPv4 or OSPF, DMPR does not 21 support higher network separation concepts. A DMPR network is a flat 22 network in which DMPR nodes have equal tasks. This also applies to 23 DMPR communication. Unlike OLSR/OSPF there is no flooding messages 24 (topology broadcast), information are stored, accumulated/compressed 25 and forwarded at each DMPR node. This feature contributes to the 26 message load being deterministic. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 31 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Organization of this Document . . . . . . . . . . . . . . 4 65 1.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.5. Distinction from other Routing Protocols . . . . . . . . 5 67 2. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Message Information Base . . . . . . . . . . . . . . . . 5 69 2.2. Routing Data . . . . . . . . . . . . . . . . . . . . . . 6 70 2.3. Routing Table . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Neighbor Detection . . . . . . . . . . . . . . . . . . . 6 73 3.1.1. Multicast Neighbor Detection . . . . . . . . . . . . 6 74 3.1.2. Unicast Neighbor Detection . . . . . . . . . . . . . 7 75 3.2. Detection of a Lost Neighbor . . . . . . . . . . . . . . 7 76 3.3. Interface Handling . . . . . . . . . . . . . . . . . . . 7 77 3.4. Message Handling . . . . . . . . . . . . . . . . . . . . 7 78 3.5. Policies . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.6. Link Attributes . . . . . . . . . . . . . . . . . . . . . 8 80 3.7. Route Selection . . . . . . . . . . . . . . . . . . . . . 8 81 3.8. Routing Data Calculation . . . . . . . . . . . . . . . . 8 82 3.9. Network Retraction . . . . . . . . . . . . . . . . . . . 9 83 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 84 4.1. Core Configuration . . . . . . . . . . . . . . . . . . . 10 85 4.2. Path Metric Profiles . . . . . . . . . . . . . . . . . . 10 86 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 87 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 11 88 5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 5.1.1. Preamble . . . . . . . . . . . . . . . . . . . . . . 11 90 5.1.2. Extension Header . . . . . . . . . . . . . . . . . . 12 91 5.1.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.1.3.1. Payload: keep-alive . . . . . . . . . . . . . . . 12 93 5.1.3.2. Payload: uncompressed JSON . . . . . . . . . . . 13 94 5.1.3.3. Payload: compressed JSON . . . . . . . . . . . . 13 95 5.1.3.4. Payload: Fragmentation . . . . . . . . . . . . . 13 96 5.2. JSON Payload . . . . . . . . . . . . . . . . . . . . . . 14 97 5.2.1. Full Update . . . . . . . . . . . . . . . . . . . . . 17 98 5.2.2. Partial Update . . . . . . . . . . . . . . . . . . . 18 99 5.3. Requests . . . . . . . . . . . . . . . . . . . . . . . . 19 100 5.4. Reflections . . . . . . . . . . . . . . . . . . . . . . . 19 101 6. Optional Features . . . . . . . . . . . . . . . . . . . . . . 20 102 6.1. Asymmetric Link Detection . . . . . . . . . . . . . . . . 20 103 6.2. Full Only Mode . . . . . . . . . . . . . . . . . . . . . 20 104 7. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 20 105 8. Bidirectional Forwarding Detection . . . . . . . . . . . . . 20 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 108 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 111 12.2. Informative References . . . . . . . . . . . . . . . . . 21 112 Appendix A. Policies . . . . . . . . . . . . . . . . . . . . . . 21 113 A.1. Low Loss Policy . . . . . . . . . . . . . . . . . . . . . 21 114 A.2. High Bandwidth Policy . . . . . . . . . . . . . . . . . . 22 115 Appendix B. Tuneables . . . . . . . . . . . . . . . . . . . . . 22 116 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 22 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 119 1. Introduction 121 Todays mobile wireless networks have a diversity of requirements on 122 the wireless links. To meet these requirements, it is possible to 123 attach multiple network access technologies on the router and select, 124 depending on the CoS of the packet, over which wireless link the 125 packet is sent. This is the main idea of policy based multipath 126 routing. The established routing protocols do not support the use of 127 multiple access technologies on a single router. To tackle this 128 issues, DMPR as been developed as a protocol for policy based 129 multipath routing in and between mobile networks, which consist of 130 multiple wireless links with different characteristics. DMPR makes 131 it possible to calculate multiple routing tables and maintain the 132 best paths for multiple policies. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 1.2. Terminology 142 The following list describes the terminology used in this RFC 143 Router, Node 144 A router (or a node) is a routing entity of a network. It runs an 145 implementation of DMPR, has zero or more networks attached and at 146 least one link to another router. 148 Link 149 A link is the direct connection between two interfaces of two 150 distinct routers. 152 Link Attribute 153 A link attribute is a basic attribute of a link, for example the 154 maximum bandwidth, the average packet loss or the cost of the 155 link. 157 Path 158 A Path in DMPR is one or more successive, directly connected links 159 which define a loop-free path from one node to another. 161 Policy 162 A policy describes an arrangement relation over a set of paths 163 using the link attributes of these paths. Note that to guarantee 164 loop-free properties this arranging function MUST be commutative 165 and associative. Policy examples can be found in Appendix A 167 1.3. Organization of this Document 169 Section 2 describes the information every node has and gets and how 170 it should handle this information. Section 3 describes the behavior 171 of the protocol in different scenarios and how it achieves particular 172 features. Section 5 describes the message format in detail. 173 Section 6 describes optional features that can be implemented to 174 improve or extend DMPR but are not required for the basic 175 functionality of propagating routing information. 177 Appendix A has a few policy examples. Appendix B lists all constants 178 used in this RFC where some of them are configurable. Appendix C 179 shows a few simple examples of how DMPR behaves under specific 180 network conditions. 182 1.4. Overview 184 Every router periodically sends out unicast or multicast messages to 185 all routing enabled links. This message already includes routers 186 database (best path to each node) known by this router. A router 187 receiving this message adds itself to all these paths, chooses the 188 best path to each node among all those it got from its neighbors and 189 advertises these paths itself via unicast or multicast messages (if 190 received as Unicast, it MUST be returned as unicast). This is 191 standard procedure in a path-vector routing protocol. In DMPR the 192 paths are further separated by a policy, therefore it is possible to 193 have more than one path to each node. Also included in the message 194 are all attributes of this path so that the receiving node can make 195 informed decisions on whether this path is the best under the current 196 policy. In the end there exist multiple paths through the network 197 and packets can be routed according to their requirements which for 198 example can be the path with the highest bandwidth or with the lowest 199 latency. 201 1.5. Distinction from other Routing Protocols 203 Traditionally, routing protocols find the best path using a scalar 204 metric. This metric may be a simple constant stating the preference 205 of the link or may be a computed metric using several factors such as 206 bandwidth, latency or cost. Furthermore, this metric is only known 207 locally or, for example in the case of BGP-4, where external paths 208 can be marked with a local preference for internal peers, to a small 209 subset of the network. In DMPR a policy is a globally defined 210 function that defines a function how to determinate the best path. 211 For this reason, the policy has all link attributes of each path at 212 its disposal and therefore has a higher control over which path it 213 chooses. 215 2. Data Structures 217 To maintain the routing data, all data extracted from the received 218 routing messages is organized in different data structures. These 219 data structures are used for calculating the routes and creating of 220 the routing tables. 222 2.1. Message Information Base 224 Every message received by a node is saved in the Message Information 225 Base. This data structure is the basis for all subsequently emitted 226 routing messages and the routing table. The Message Information Base 227 contains the latest (by sequence number) received message for each 228 neighbor. Each entry is controlled by a hold timer and is purged 229 after the hold timer expires. This timer is reset as soon as a new 230 valid message from this neighbor is received. This data structure 231 contains potentially duplicate or conflicting data since many 232 neighbors send their paths and subnet information for all nodes they 233 know of. This is intended and required because any message may be 234 deleted at almost any time when its hold timer expires. 236 2.2. Routing Data 238 The Routing Data is computed from the Message Information Base. In 239 contrast to the Message Information Base this is data structure 240 contains no conflicting information and can be seen as the single 241 source of truth for the routing table and routing message generation. 242 It contains the best path to each known node grouped by policy. 243 Furthermore the advertised subnets from each node are combined while 244 following the network retraction rules (see Section 3.9). 246 2.3. Routing Table 248 The routing table contains the best path to each known subnet grouped 249 by policy. This table is meant to be inserted into the underlying 250 operating system's routing table. 252 3. Behavior 254 3.1. Neighbor Detection 256 DMPR supports unicast and multicast neighbor detection and transport 257 schemes. The scheme MUST be configurable at link level (e.g. eth0: 258 multicast, eth1: unicast). Multicast provides ad-hoc capabilities 259 without prior knowledge of neighbor nods. The multicast detection 260 mechanism and transport mechanism are similar to those of other ad- 261 hoc routing protocols such as OLSR. 263 Unicast detection and transport lacks support of ad-hoc 264 configuration: the neighbor list must be configured a prior. The 265 advantage of using unicast is that DMPR can also be used on networks 266 that do not or insufficiently support multicast. Notes: an 267 alternative for the use of unicast is the use of tunnels (IPIP, GRE, 268 ...). For example, the tunnel is the preferred solution when BGAN 269 terminals or routing foreign segments must be bridged. 271 DMPR is build around the concept of identifying nodes uniquely via 272 DMPR ID. It is therefore irrelevant whether neighbours are detected 273 several times via different links and unicast or multicast. 275 3.1.1. Multicast Neighbor Detection 277 Each node listens to a unicast or multicast address at each enabled 278 DMPR link. If multicast, the multicast address SHOULD be 279 configurable. Periodically, after a defined message interval + 280 jitter, a node sends out its routing message, which includes: 282 * All nodes it has a path to, including the networks they advertise 283 * For each policy, a path to each node it knows of. 285 * The attributes of the links between the paths. 287 When a node receives a message, it deduces a connection and therefore 288 a path to the sender via the interface that message came in. With 289 this mechanism the path to a node propagates through the network. 290 Every received message SHOULD be assigned to a hold timer. When this 291 hold timer expires, the message MUST be deleted from the Message 292 Information Base. The timeout SHOULD be a multiple of the routing 293 message interval. Asymmetric links are handled with a feature called 294 reflection, which is described in Section 5.4. 296 3.1.2. Unicast Neighbor Detection 298 For unicast, DMPR MUST support a list of IPv4/IPv6 addresses of DMPR 299 neighbors at a particular link. The messages and timeout constraints 300 are identical to previous multicast section. 302 3.2. Detection of a Lost Neighbor 304 Whenever a neighbor is not reachable anymore (e.g. due to topology 305 change), no further routing messages will be received from this 306 neighbor. As all the received messages are assigned to a timer, no 307 routing messages of the lost neighbor will be present in the Message 308 Information Base, after the expiration of this timer. This means, 309 that the loss of the neighbor is detected after the timeout of the 310 last received routing message of the concerned neighbor. For this 311 reason, the routing table SHOLD be recalculated, whenever the Message 312 Information Base is purged due to timeouts. 314 3.3. Interface Handling 316 In DMPR all interfaces that are registered with the DMPR daemon are 317 treated completely separate from each other. Routing messages are 318 sent over each one individually. This ensures that all possibly 319 accessible neighbors are reachable. The message information base 320 (seeSection 2.1) is grouped by interface. Therefore nodes can detect 321 links on each interface individually. 323 3.4. Message Handling 325 Each message received by a neighbor is saved in the Message 326 Information Base (seeSection 2.1). With this message a hold timer is 327 set that purges the messages after the given time. To improve the 328 message size a node can choose to only send partial updates (i.e. 329 differential, only the changes since the last full update). To 330 support this a node has to retain the a version from the last full 331 message so it can apply the new partial message. 333 3.5. Policies 335 To support routing different traffic types over different routes, 336 DMPR supports multiple policies. A policy defines, how the best path 337 to a destination is computed using the available link attributes. 338 For all the defined policies, seperate routes will be calculated to 339 every reachable destination. The best path to all destinations is 340 included in the routing message for every policy. For each policy, a 341 seperate routing table MUST be generated. In large networks, this 342 results in a multi topology routing. When different parts of the 343 network have different attributes (e.g. one path has a low loss rate, 344 another path in contrast has a higher bandwidth), different subsets 345 of the topology will be used to forward packets that require 346 different policies (Class of Service). 348 3.6. Link Attributes 350 DMPR MUST know the link attributes that are required to determinate 351 the best path for all the registered policies on all links 352 (interfaces) to the router. These attributes can either be 353 configured staticly by the network administrator or can be 354 dynamically gathered from the attached modem devices. This RFC does 355 not specify how the link information has to be gained. There is no 356 specification defining which attributes must be given to the protocol 357 (e.g bandwidth, loss rate, latency). The requirement of attributes 358 depends on the policies meant to be used. 360 3.7. Route Selection 362 The calculation of the best route MUST be defined for each policy 363 separately. For example simple policies only consider a single link 364 metric (such as bandwidth or loss rate) for the calculation of the 365 best route. Combined policies might use a combination of multiple 366 link metrics. The route selection mechanism is part of a policy's 367 definition and therefore can be individually defined. 369 3.8. Routing Data Calculation 371 For every reachable destination, the routing data is calculated for 372 all defined policies using the policy's specific route selection 373 mechanism. As a result, there MUST be a seperate routing table for 374 every defined policy. Whenever new crucial information is received, 375 the routing data MUST be recalculated. Information that causes a 376 recalculation of the routing data can be: 378 * A destination is reachable via a new interface 379 * The hold timer of a message in the Message Information Base is 380 expired (a destination is not reachable anymore via a specific 381 interface 383 * Link attributes have changed 385 3.9. Network Retraction 387 Each network advertised in a message has an optional flag called 388 "retracted". This flag is set to true when a node no longer 389 advertises this network as available. The only node to ever set this 390 flag to true MUST be the originally advertising node. A set 391 retracted flag always supersedes an unset flag. Networks are 392 forwarded with this ruleset: 394 +==============+===========+==============+=======================+ 395 | Network | Network | Network set | Action to take | 396 | known as not | known as | as retracted | | 397 | retracted | retracted | in a message | | 398 +==============+===========+==============+=======================+ 399 | false | false | false | Insert network in | 400 | | | | known networks and | 401 | | | | forward | 402 +--------------+-----------+--------------+-----------------------+ 403 | false | false | true | ignore network, do | 404 | | | | not forward | 405 +--------------+-----------+--------------+-----------------------+ 406 | false | true | false | forward network as | 407 | | | | retracted | 408 +--------------+-----------+--------------+-----------------------+ 409 | false | true | true | forward network as | 410 | | | | retracted | 411 +--------------+-----------+--------------+-----------------------+ 412 | true | false | false | just forward network | 413 +--------------+-----------+--------------+-----------------------+ 414 | true | false | true | set network in known | 415 | | | | networks as retracted | 416 | | | | and forward retracted | 417 +--------------+-----------+--------------+-----------------------+ 418 | true | true | false | illegal | 419 +--------------+-----------+--------------+-----------------------+ 420 | true | true | true | illegal | 421 +--------------+-----------+--------------+-----------------------+ 423 Table 1 425 4. Protocol Parameters 427 The parameters described in this section SHOULD be configured at the 428 startup of the router. This specification does not define any values 429 for the parameters. 431 4.1. Core Configuration 433 Core Configuration describes the fields which MUST be the same on all 434 routers in the neworks. 436 * Multicast IPv4 Address: This is the address, where the routing 437 messages are sent to. DMPR listens to this interfaces for 438 incoming routing messages. 440 * Multicast IPv6 Address: This is the address, where the routing 441 messages are sent to. DMPR listens to this interfaces for 442 incoming routing messages. 444 * Routing message interval: The interval of sending the routing 445 messages to the defined multicast address. 447 * Routing message hold time: Timeout of the received routing 448 messages. After expiration of this timeout, the received messages 449 are deleted from the Message Information Base. The hold time 450 SHOULD be a multiple of the Routing message interval. 452 4.2. Path Metric Profiles 454 This field describes a list with all the policies which should be 455 considered by the routing protocol. The policies are referenced by 456 name. For every listed policy, the routing protocol MUST implement 457 the according route selection mechanism. 459 4.3. Interfaces 461 This field describes a list with all the routers physical interfaces, 462 which are used as DMPR interfaces. For all interfaces following 463 fields are required: 465 * The name of the interfaces 467 * IPv4 Address of the interface 469 * IPv6 Address of the interface 470 * All link attributes which are available to describe the interface. 471 These attributes are used to calculate the best routes for the 472 defined policies. All the attributes which are considered by at 473 least one of the defined policies are required for every 474 interface. Common attribues are for example bandwith, loss rate 475 and latency. 477 5. Message Format 479 5.1. Header 481 A DMPR packet consists of a preamble, followed by zero or more 482 extension headers followed by zero or one payload. Each extension 483 header and payload is defined by a type. 485 +=========+============================================+ 486 | Type | Use | 487 +=========+============================================+ 488 | 0-119 | Extension Header | 489 +---------+--------------------------------------------+ 490 | 120-127 | Extension Header, reserved for private use | 491 +---------+--------------------------------------------+ 492 | 128-247 | Payload | 493 +---------+--------------------------------------------+ 494 | 248-255 | Payload, reserved for private use | 495 +---------+--------------------------------------------+ 497 Table 2: Possible Types 499 Possible Types are defined in further detail below 501 5.1.1. Preamble 503 The preamble of a DMPR packet is as follows 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 |Magic| Reserved| NextType | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 The preamble of a packet 513 Magic 514 A 3-bit Magic: 0b010 516 Reserved 517 Reserved for future use 519 NextType 520 The type of the next header or payload. 522 5.1.2. Extension Header 524 An extension header consists of the type immediately following this 525 header, a length specifier, and the Extension Header data. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | NextType | Length | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 532 | | 533 + Data + 534 | | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 NextType 538 8-bit unsigned integer: The type of the immediately following 539 header or payload (same as specified in the packet preamble 540 description) 542 Length 543 8-bit unsigned integer: The length of the Data field in 2-octets, 544 this does not include NextType and Length itself 546 Data 547 The header-specific data according to length. The encoding and 548 type is specified by the header itself. 550 5.1.3. Payload 552 The Payload consists of the data from the end of the preamble or last 553 extension header until the end of the packet. Payloads may be 554 recursive, i.e. contain a valid packet (or parts of it) in 555 themselves. Payload processors therefore MUST have the ability to 556 feed their result back into the message processing chain. This 557 behavior is defined by the payload itself. 559 5.1.3.1. Payload: keep-alive 561 Type: 127 563 This is a keep-alive packet, the payload length is zero. 564 Implementations SHOULD reset the message hold timer for the sending 565 node upon receiving a keep-alive packet 567 5.1.3.2. Payload: uncompressed JSON 569 Type: 128 571 Unkompressed, plain, standard-compliant I-JSON data as described in 572 [RFC7493]. This is the main routing data; its structure is defined 573 in Section 5.2 575 5.1.3.3. Payload: compressed JSON 577 Type: 129 579 LZMA-compressed standard-compliant I-JSON data as described in 580 [RFC7493]. This is the main routing data; its structure is defined 581 in Section 5.2 583 5.1.3.4. Payload: Fragmentation 585 Type: 130 587 A packet greater than the MTU between two nodes SHOULD be fragmented 588 using the fragmentation payload. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Identifier |L|Packet offset| | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 595 | Payload | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 The Fragmentation Payload Header 600 Identifier 601 Identifies possibly concurrent fragmented packets. 602 Implementations SHOULD use an incrementing counter to practically 603 eliminate the possibility of a collision. 605 L(ast) 606 Last, set to 1 if this packet has the highest packet offset in 607 this fragmentation collection, i.e. is the last packet. 609 Packet index 610 7-bit unsigned integer. Defines the index of this packet in the 611 list of fragments resulting in the fragmentation of the original 612 packet. The first packet has offset zero. 614 When a packet is larger than the MTU of the link between two nodes it 615 SHOULD be fragmented. For this purpose, the sending node computes 616 the maximum effective payload size for packets sent (i.e MTU less 617 preamble, possibly extension headers and the fragmentation header) 618 and splits the original packet into parts with this size. For each 619 of these parts, it sends a packet with the fragmentation header set 620 to a common identifier, a corresponding packet offset and the LAST 621 bit set for the last fragment. 623 The receiving node keeps track of all received fragments, grouping 624 them by source address and identifier. As soon as all fragments of a 625 packet have been received, the reconstructed packet MUST be fed back 626 into the message processing chain as if it were a new, just received 627 packet. Fragments MUST be regularly purged based on a hold timer. 629 5.2. JSON Payload 631 A JSON payload is an ASCII-7 encoded JSON object. A sending node 632 SHOULD use ascii-encoding for the JSON data. A receiving node MUST 633 be able to decode UTF-8 encoded data. The payload can be zip 634 compressed. A compressed payload has to be announced in the header. 636 Augmented requirements language for this section: 638 REQUIRED 639 This field is required, the sending node MUST include it. 641 REQUIRED if not empty 642 If the field would be empty, it can be omitted, otherwise it is 643 REQUIRED 645 OPTIONAL 646 This field can be inserted to activate specific features or use 647 other functionality. A sending node can choose to omit it and a 648 receiving node MUST be able to work without this field. 650 General Message Structure 651 { 652 "id": , 653 "seq": , 654 "type": , 655 "partial-base": , 656 "addr-v4": , 657 "addr-v6": , 658 "networks": { 659 : {}, 660 : { 661 "retracted": true 662 } 663 }, 664 "routing-data": { 665 : { 666 : { 667 "path": 668 } 669 } 670 }, 671 "node-data": { 672 : { 673 "networks": { 674 : {}, 675 : { 676 "retracted": true 677 } 678 } 679 } 680 }, 681 "link-attributes": { 682 : { 683 : 684 } 685 }, 686 "request-full": union(true, [, ...]), 687 "reflect": { 688 : 689 } 690 "reflected": { 691 : { 692 : 693 } 694 } 695 } 697 Key and value description: 699 id 700 string: The sending node's id, NODE_ID: MUST NOT contain any of 701 the brackets: ()[]{}<> 703 seq 704 integer: The message sequence number, strictly monotonically 705 increasing 707 type 708 string: The type of the message, specified in further detail below 709 Section 5.2, Paragraph 8 711 partial-base 712 integer: The base message of a partial update, the message then 713 only includes the difference between the actual data and the base 714 message 716 addr-v4 717 string: The IPv4 address of the sending node over the link this 718 packet has been sent. 720 addr-v6 721 string: The IPv6 address of the sending node over the link this 722 packet has been sent. 724 networks 725 object: The networks advertised by this node. The keys are valid 726 IPv4/IPv6 network identifications with subnet prefix. If the 727 value of a network key is a object itself and the "retracted" key 728 of this object is set to true, the network MUST be handled as 729 retracted. See Section 3.9 731 routing-data 732 object: A path to each reachable node for each policy. POLICY is 733 the name of a policy defined in the sending node. If the 734 receiving node does not understand this policy the entry MUST be 735 ignored. PATH: a path to a node described according to this 736 syntax: 738 path = node [node-id ">[" link-attribute-id "]>" path] 739 node-id = *ALPHA 740 link-attribute-id = *DIGIT 742 node-data 743 object: a list of networks for each reachable node defined in 744 "routing-data". "networks" is handled like "networks" defined 745 above. 747 link-attributes 748 object: the set of link-attributes used in the paths of routing- 749 data. Each key SHOULD be an integer and MUST NOT contain any of 750 the brackets ()[]{}<> The value of an entry is itself a object 751 containing LINK_ATTRIBUTE: METRIC pairs where LINK_ATTRIBUTE is 752 the name of a link attribute and metric is its value as defined in 753 Section 1.2 755 request-full 756 array or true: A list of NODE_IDs from which the sending node 757 requests a full update message. If true the node requests a full 758 update from all neighbors. 760 reflect 761 object: arbitrary data the sending node wants to have included in 762 the "reflected" object in the next message of the receiver 764 reflected 765 object: a set of reflected data, contains, for each neighboring 766 node the data the node requested to reflect. 768 Each message has a type. This RFC describes two types, namely full 769 and partial, which are described in further detail here. 771 5.2.1. Full Update 773 A full update SHOULD replace all data from the sending node in the 774 receivers Message Information Base. It MUST NOT require any previous 775 knowledge of the sender by the receiver. The following keys are 776 specified: 778 addr-v4 779 string, REQUIRED: The IPv4 address of the sending node over the 780 link this packet has been sent. 782 addr-v6 783 string: REQUIRED: The IPv6 address of the sending node over the 784 link this packet has been sent. 786 Note: Only one of addr-v4 and addr-v6 is required 788 networks 789 object, REQUIRED if not empty: The networks advertised by this 790 node. See above 792 routing-data 793 object, REQUIRED if not empty: The paths advertised by the sender, 794 grouped by POLICY and target NODE_ID. The syntax of a path is 795 described above. A path MUST include the sender of this message, 796 all hops with their link-attribute IDs and the target node. 798 node-data 799 object, OPTIONAL: The networks from other nodes known to the 800 sender including their retraction status. 802 link-attributes 803 object, REQUIRED if not empty: The link-attributes used in 804 "routing-data". Each entry MUST contain all attributes known to 805 the sender, even if they are not needed by a policy. 807 5.2.2. Partial Update 809 A partial update only replaces the changed data in the receivers 810 message information base. It therefore has the additional field 811 "partial-base" which describes the sequence number of the base 812 message, which MUST be a full update message, to which the changes 813 apply. Note: A partial update only describes changes to a previous 814 full update, never to a previous partial update. If the receiving 815 node is unable to apply the partial update, e.g because it lacks the 816 base message, then this node SHOULD use the "request-full" procedure 817 to request a new full update (seeSection 5.3). 819 The following keys are specified: 821 addr-v4 822 string, OPTIONAL: The IPv4 address of the sending node over the 823 link this packet has been sent, only included if it has not 824 changed. If it became invalid, the value is null. 826 addr-v6 827 string, OPTIONAL: The IPv6 address of the sending node over the 828 link this packet has been sent, only included if it has not 829 changed. If it became invalid, the value is null. 831 Note: A partial update MUST NOT produce an invalid configuration 832 by deleting the only address available for a node. 834 networks 835 object, OPTIONAL: The networks advertised by the sender. The 836 entries replace the base message entries on a per NODE_ID basis. 837 If an entry has been deleted, the value for the specific NODE_ID 838 is null. 840 routing-data 841 object, OPTIONAL: The paths advertised by the sender, grouped by 842 POLICY and target NODE_ID. The entries replace the base message 843 entries on a per NODE_ID basis. If an entry has been deleted, the 844 value for the specific NODE_ID is null. 846 node-data 847 object, OPTIONAL: The networks from other nodes known to the 848 sender. The entries replace the base message entries on a per 849 NODE_ID basis. If an entry has been deleted, the value for the 850 specific NODE_ID is null. 852 link-attributes 853 object, REQUIRED if not empty: The link-attributes used in 854 "routing-data". Note that link-attributes are only valid on a 855 per-message basis and MUST NOT replace link-attribute entries in 856 the base message. 858 5.3. Requests 860 When a node is not able to apply a partial update or just joined a 861 network, it SHOULD send out a request for a full update using the 862 request-full key in the message. This key may be an array containing 863 NODE_IDs from which a full message is needed or may be the Boolean 864 value true, to indicate that a full message from every neighbor is 865 required. When a node receives a request-full key in a message that 866 either has the value true or its ID present in the array, it MUST do 867 one of the following: variant1: schedule the next message it sents to 868 be a full message. variant2: send a full update immediately and 869 reset its message interval timer, except when the last message 870 already was a out-of-band full message, in which case it MUST/SHOULD 871 schedule the next message according to the message interval timer to 872 be a full message. 874 5.4. Reflections 876 Reflections are a extensible mechanism and allow a node to exchange 877 data with neighboring nodes, with 2-hop neighbors and with itself. 878 When a node includes arbitrary JSON data in the reflect key in its 879 message, each node receiving this message MUST send this data in the 880 reflected key of its messages under the corresponding NODE_ID. A 881 node MUST support reflecting all requests but is not required to 882 actually parse that data. Because the messages are sent to all 883 neighbors, every 2-hop neighbor becomes aware of the reflected data 884 of a node. This fact is not used in this RFC but may be used in 885 extensions of this protocol. 887 6. Optional Features 889 6.1. Asymmetric Link Detection 891 How asymmetric link detection should work/how it can be implemented 893 6.2. Full Only Mode 895 When/how to switch the mode 897 7. Introduction 899 The original specification of xml2rfc format is in RFC 2629 900 [RFC2629]. 902 8. Bidirectional Forwarding Detection 904 Bidirectional Forwarding Detection CAN be used to detect link 905 abortions. DMPR is designed to reduce the network usage to a 906 minimum. Operating additionally BFD may increase the load 907 unnecessarily. 909 An alternative is to increase the transmission interval of DMPR 910 directly. The advantage is that no "context free" BFD packet are 911 transmitted additionally, but in-line DMPR packets which reduce the 912 convergence time in the entire network. BFD would have advantages if 913 the DMPR interval is in the higher minute range, but here it would 914 have to be considered whether to reduce the interval and do without 915 BFD. 917 9. Acknowledgements 919 This template was derived from an initial version written by Pekka 920 Savola and contributed by him to the xml2rfc project. 922 10. IANA Considerations 924 This memo includes no request to IANA. 926 All drafts are required to have an IANA considerations section (see 927 Guidelines for Writing an IANA Considerations Section in RFCs 928 [RFC5226] for a guide). If the draft does not require IANA to do 929 anything, the section contains an explicit statement that this is the 930 case (as above). If there are no requirements for IANA, the section 931 will be removed during conversion into an RFC by the RFC Editor. 933 11. Security Considerations 935 All drafts are required to have a security considerations section. 936 See RFC 3552 [RFC3552] for a guide. Due to the Multicast 937 Transmission, the routing message's payload data is unencrypted. 939 12. References 941 12.1. Normative References 943 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, 947 DOI 10.17487/RFC2119, March 1997, 948 . 950 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 951 DOI 10.17487/RFC7493, March 2015, 952 . 954 12.2. Informative References 956 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 957 DOI 10.17487/RFC2629, June 1999, 958 . 960 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 961 Text on Security Considerations", BCP 72, RFC 3552, 962 DOI 10.17487/RFC3552, July 2003, 963 . 965 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 966 IANA Considerations Section in RFCs", RFC 5226, 967 DOI 10.17487/RFC5226, May 2008, 968 . 970 Appendix A. Policies 972 many exchangeable policies 974 A.1. Low Loss Policy 976 use path with lowest overall loss. Overall loss is the accumulation 977 of the loss rates of all hops to a destination. Required link 978 attributes: 980 * Loss rate 982 A.2. High Bandwidth Policy 984 use path with highest bandwidth In multihop topologies, the overall 985 bandwith is the minimum of the bandwidths between the hops to a 986 destination. Required link attributes: 988 * Bandwidth 990 Appendix B. Tuneables 992 The different magic values and what they affect, how they could/ 993 should be set 995 Appendix C. Examples 997 Examples 999 Authors' Addresses 1001 Hagen Paul Pfeifer (editor) 1002 ProtocolLabs 1003 Haslangstr. 7 1004 80689 Munich 1005 Germany 1007 Phone: +49 174 54 55 209 1008 Email: hagen@jauu.net 1009 URI: http://www.jauu.net/ 1011 Sebastian Widmann 1012 University for Applied Sciences Munich 1013 Loth Str. 64 1014 80335 Munich 1015 Germany 1017 Email: sebastian-widmann@t-online.de