idnits 2.17.1 draft-clausen-lln-loadng-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 == Line 1069 has weird spacing: '...te-cost is a ...' == Line 1073 has weird spacing: '...-metric is a ...' == Line 1076 has weird spacing: '...ous-hop is th...' == Line 1503 has weird spacing: '...ous-hop is th...' -- The document date (April 22, 2012) is 4388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft A. Colin de Verdiere 4 Intended status: Standards Track J. Yi 5 Expires: October 24, 2012 LIX, Ecole Polytechnique 6 A. Niktash 7 Maxim Integrated Products 8 Y. Igarashi 9 H. Satoh 10 Hitachi, Ltd., Yokohama Research 11 Laboratory 12 U. Herberg 13 Fujitsu Laboratories of America 14 C. Lavenu 15 EDF R&D 16 T. Lys 17 ERDF 18 April 22, 2012 20 The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next 21 Generation (LOADng) 22 draft-clausen-lln-loadng-04 24 Abstract 26 This document describes the LLN Ad hoc On-Demand - Next Generation 27 (LOADng) distance vector routing protocol, a reactive routing 28 protocol intended for use in Low power and Lossy Networks (LLN). The 29 protocol is derived from AODV (RFC3561) and extended for use in LLNs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. This document may not be modified, 35 and derivative works of it may not be created, except to format it 36 for publication as an RFC or to translate it into languages other 37 than English. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 24, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 6 69 2.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 7 72 2.1.3. Conventions . . . . . . . . . . . . . . . . . . . . . 7 73 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 74 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 75 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 76 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . . 10 78 4.3. Information Base Overview . . . . . . . . . . . . . . . . 10 79 4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11 80 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 12 81 6. Information Base . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.2. Local Interface Set . . . . . . . . . . . . . . . . . . . 15 84 6.3. Blacklisted Neighbor Set . . . . . . . . . . . . . . . . . 15 85 6.4. Destination Address Set . . . . . . . . . . . . . . . . . 15 86 6.5. Pending Acknowledgment Set . . . . . . . . . . . . . . . . 16 87 7. LOADng Router Sequence Numbers . . . . . . . . . . . . . . . . 16 88 8. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 17 89 8.1. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 19 91 8.2.1. RREQ and RREP Message Format . . . . . . . . . . . . . 19 92 8.2.2. RREP_ACK Message Format . . . . . . . . . . . . . . . 20 93 8.2.3. RERR Message Format . . . . . . . . . . . . . . . . . 21 94 9. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 21 95 10. Unidirectional Link Handling . . . . . . . . . . . . . . . . . 23 96 10.1. Blacklist Usage . . . . . . . . . . . . . . . . . . . . . 23 97 11. Common Rules for RREQ and RREP Messages . . . . . . . . . . . 24 98 11.1. Identifying Invalid RREQ or RREP Messages . . . . . . . . 24 99 11.2. RREQ and RREP Message Processing . . . . . . . . . . . . . 25 100 11.3. Updating Routing Tuples In Response to RREQ and RREP . . . 27 101 12. Route Requests (RREQs) . . . . . . . . . . . . . . . . . . . . 27 102 12.1. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 28 103 12.2. RREQ Processing . . . . . . . . . . . . . . . . . . . . . 29 104 12.3. RREQ Forwarding . . . . . . . . . . . . . . . . . . . . . 29 105 12.4. RREQ Transmission . . . . . . . . . . . . . . . . . . . . 30 106 13. Route Replies (RREPs) . . . . . . . . . . . . . . . . . . . . 30 107 13.1. RREP Generation . . . . . . . . . . . . . . . . . . . . . 30 108 13.2. RREP Processing . . . . . . . . . . . . . . . . . . . . . 31 109 13.3. RREP Forwarding . . . . . . . . . . . . . . . . . . . . . 32 110 13.4. RREP Transmission . . . . . . . . . . . . . . . . . . . . 32 111 14. Route Errors (RERRs) . . . . . . . . . . . . . . . . . . . . . 32 112 14.1. Identifying Invalid RERR Messages . . . . . . . . . . . . 33 113 14.2. RERR Generation . . . . . . . . . . . . . . . . . . . . . 33 114 14.3. RERR Processing . . . . . . . . . . . . . . . . . . . . . 33 115 14.4. RERR Forwarding . . . . . . . . . . . . . . . . . . . . . 34 116 14.5. RERR Transmission . . . . . . . . . . . . . . . . . . . . 35 117 15. Route Reply Acknowledgments (RREP_ACKs) . . . . . . . . . . . 35 118 15.1. RREP_ACK Generation . . . . . . . . . . . . . . . . . . . 35 119 15.2. RREP_ACK Processing . . . . . . . . . . . . . . . . . . . 36 120 15.3. RREP_ACK Forwarding . . . . . . . . . . . . . . . . . . . 36 121 15.4. RREP_ACK Transmission . . . . . . . . . . . . . . . . . . 36 122 16. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 123 16.1. The <= Comparison Operator . . . . . . . . . . . . . . . . 37 124 16.2. Specifying New Metrics . . . . . . . . . . . . . . . . . . 37 125 16.3. Default Metric: Hop Count With Weak Links . . . . . . . . 38 126 16.3.1. R_dist Definition . . . . . . . . . . . . . . . . . . 38 127 16.3.2. Weak Link Definition . . . . . . . . . . . . . . . . . 38 128 16.3.3. Required TLVs . . . . . . . . . . . . . . . . . . . . 38 129 16.3.4. The <= Comparison Operator . . . . . . . . . . . . . . 38 130 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 131 17.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 39 132 17.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 40 133 17.3. Channel Jamming and State Explosion . . . . . . . . . . . 41 134 17.4. Interaction with External Routing Domains . . . . . . . . 42 135 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 136 18.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 43 137 18.2. Packet Types . . . . . . . . . . . . . . . . . . . . . . . 43 138 18.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 43 139 18.4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 43 140 18.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 44 141 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 142 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 143 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 144 21.1. Normative References . . . . . . . . . . . . . . . . . . . 45 145 21.2. Informative References . . . . . . . . . . . . . . . . . . 45 146 Appendix A. LOADng Control Packet Illustrations . . . . . . . . . 46 147 A.1. RREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 148 A.2. RREP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 149 A.3. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 47 150 A.4. RERR . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 152 1. Introduction 154 The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next 155 Generation (LOADng) is a routing protocol, derived from AODV 156 [RFC3561] and extended for use in Low power and Lossy Networks 157 (LLNs). As a reactive protocol, the basic operations of LOADng 158 include generation of Route Requests (RREQs) by a router (originator) 159 for when discovering a route to a destination, forwarding of such 160 RREQs until they reach the destination router, generation of Route 161 Replies (RREPs) upon receipt of an RREQ by the indicated destination, 162 and unicast hop-by-hop forwarding of these RREPs towards the 163 originator. If a route is detected broken, i.e., if forwarding of a 164 data packet to the recorded next hop on the route to the destination 165 is detected to fail, a Route Error (RERR) message is returned to the 166 originator of that data packet. 168 Compared to [RFC3561], LOADng is simplified as follows: 170 o Only the destination is permitted to respond to an RREQ; 171 intermediate routers are explicitly prohibited from responding to 172 RREQs, even if they may have active routes to the sought 173 destination, and all messages (RREQ or RREPs) generated by a given 174 router share a single unique, monotonically increasing sequence 175 number. This also eliminates Gratuitous RREPs while ensuring loop 176 freedom. The rationale for this simplification is reduced 177 complexity of protocol operation and reduced message sizes. 179 o A LOADng Router does not maintain a precursor list, thus when 180 forwarding of a data packet to the recorded next hop on the route 181 to the destination fails, an RERR is sent only to the originator 182 of that data packet. The rationale for this simplification is an 183 assumption that few overlapping routes are in use concurrently in 184 a given network. 186 Compared to [RFC3561], LOADng is extended as follows: 188 o Optimized Flooding is supported, reducing the overhead incurred by 189 RREQ generation and flooding. If no optimized flooding operation 190 is specified for a given deployment, classical flooding is used by 191 default. 193 o Different address lengths are supported - from full 16 octet IPv6 194 addresses over 6 octet Ethernet MAC addresses and 4 octet IPv4 195 addresses to shorter 1 and 2 octet addresses. The only 196 requirement is, that within a given routing domain, all addresses 197 are of the same address length. 199 o Control messages can include TLV (Type-Length-Value) elements, 200 permitting protocol extensions to be developed. 202 LOADng supports routing using arbitrary metrics, which can be 203 specified as extensions using the TLV mechanism. In order to provide 204 a "fallback", in case a router on a route does not understand a given 205 metric, LOADng always provides a default "hop-count-with-weak-links" 206 metric - the philosophy being that "any route, even if not with the 207 metric desired, is better than no route". 209 2. Terminology and Notation 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described in 214 [RFC2119]. 216 Additionally, this document uses the notations in Section 2.1 and the 217 terminology defined in Section 2.2. 219 2.1. Notations 221 The following notations, for elements and variables, are used in this 222 document. 224 This format uses network byte order (most significant octet first) 225 for all fields. The most significant bit in an octet is numbered bit 226 0, and the least significant bit of an octet is numbered bit 7 227 [Stevens]. 229 2.1.1. Elements 231 This specification defines elements. An element is a group of any 232 number of consecutive bits that together form a syntactic entity 233 represented using the notation . Each element in this 234 document is defined as either: 236 o a specifically sized field of bits OR 238 o a composite element, composed of other s. 240 A composite element is defined as follows: 242 := specification 244 where, on the right hand side following :=, specification is 245 represented using the regular expression syntax defined in 246 [SingleUNIX]. Only the following notation is used: 248 - Indicates that is immediately 249 followed by . 251 () - Indicates a grouping of the elements 252 enclosed by the parentheses. 254 ? - Zero or one occurrences of the preceding element or group. 256 * - Zero or more occurrences of the preceding element or group. 258 2.1.2. Variables 260 Variables are introduced into the specification solely as a means to 261 clarify the description. The following two notations are used: 263 - If is an unsigned integer field, then is also 264 used to represent the value of that field. 266 bar - A variable, usually obtained through calculations based on the 267 value(s) of element(s). 269 2.1.3. Conventions 271 This document uses the following notational conventions: 273 a := b - An assignment operator, whereby the left side (a) is 274 assigned the value of the right side (b). 276 c = d - A comparison operator, returning true if the value of the 277 left side (c) is equal to the value of the right side (d). 279 2.2. Terminology 281 This document uses the following terminology: 283 LOADng Router - A router that implements this routing protocol. A 284 LOADng router can be equipped with one or multiple distinct 285 interfaces. 287 Interface - A router's attachment to a communications medium. An 288 interface is assigned one or more addresses. 290 Packet - The top level entity in this specification. A packet 291 contains a Packet Header and zero or one message. 293 Message - The fundamental entity carrying protocol information, in 294 the form of address objects and TLVs. 296 Link Cost - The cost (weight) between a pair of LOADng Routers, 297 determined by a LOADng Router upon receipt of a packet. 299 Route Cost - The sum of the Link Costs for the links that an RREQ or 300 RREP has crossed. 302 Weak Link - A link that is marginally usable, i.e., which MAY be 303 used if no other links are available, but which SHOULD be avoided 304 if at all possible - even if it entails ultimately longer routes. 305 As an example, a Weak Link might be defined as a link with a 306 nominatively high bit-rate (thus, a priori attractive) while 307 suffering a significant loss-rate. 309 3. Applicability Statement 311 This protocol: 313 o Is a reactive routing protocol for Low power and Lossy Networks 314 (LLNs). 316 o Supports the use of optimized flooding for RREQs. 318 o Enables any router in the LLN to discover bi-directional routes to 319 destinations in the LLN (i.e., any other router, as well as hosts 320 or networks attached to that router). 322 o Supports addresses of any length, from 16 octets to a single 323 octet. 325 o Is layer-agnostic, i.e., may be used at layer 3 as a "route over" 326 routing protocol, or at layer 2 as a "mesh under" routing 327 protocol. 329 o Supports per-destination route maintenance; if a destination 330 becomes unreachable, rediscovery of that single (bi-directional) 331 route is performed, without need for global topology 332 recalculation. 334 4. Protocol Overview and Functioning 336 The objective of this protocol is for each LOADng Router to, 337 independently: 339 o Discover a bi-directional route to any destination in the network. 341 o Establish routes only when there is data traffic to be sent along 342 that route. 344 o Maintain a route only for as long as it is an active route, i.e., 345 there is traffic using the route. 347 o Generate control traffic based on network events only: when a new 348 route is required, or when an active route is detected broken. 349 Specifically, this protocol does not require periodic signaling. 351 4.1. Overview 353 These objectives are achieved, for each LOADng Router, by performing 354 the following tasks: 356 o When having a data packet to deliver to a destination, for which 357 no tuple in the routing table exists, generate a Route Request 358 (RREQ) encoding the destination address, and transmit this to all 359 of its neighbors. 361 o Upon receiving an RREQ, install or refresh a tuple in the routing 362 table towards the originator address from the RREQ, as well as to 363 the neighbor LOADng Router from which the RREQ was received. This 364 will install the Reverse Route (towards the originator address 365 from the RREQ). 367 o Upon receiving an RREQ, inspect the indicated destination address: 369 * If that address is an address in the Destination Address Set of 370 the LOADng Router, generate a Route Reply (RREP), which is 371 unicast in a hop-by-hop fashion along the installed Reverse 372 Route. 374 * If that address is not an address in the Destination Address 375 Set of the LOADng Router, consider the RREQ as a candidate for 376 forwarding. 378 o When an RREQ is considered a candidate for forwarding, retransmit 379 it according to the flooding operation, specified for the network. 381 o Upon receiving an RREP, install a route towards the originator 382 address from the RREP, as well as to the neighbor LOADng Router, 383 from which that RREP was received. This will install the Forward 384 Route (towards the originator address from the RREP). The 385 originator address is either an address from the Local Interface 386 Set of the LOADng Router, or an address from its Destination 387 Address Set (i.e. an address of a host attached to that router). 389 o Upon receiving an RREP, forward it, as unicast, to the recorded 390 next hop along the corresponding Reverse Route until the RREP gets 391 to the LOADng Router that has the destination address from the 392 RREP in its Local Interface Set or Destination Address Set. 394 A router generating an RREQ specifies which metric it desires. 395 Routers receiving an RREQ will process it and update route cost 396 information in the RREQ according to that metric, if they can. All 397 routers, however, will update information in the RREQ so as to be 398 able to support the "hop-count-with-weak-links" default metric. If a 399 router is not able to understand the specified metric in an RREQ, it 400 will change the metric type in the RREQ to "hop-count-with-weak- 401 links" so as to ensure that it be indicated what metric is supported 402 by the path taken by that copy of the RREQ. 404 4.2. Routers and Interfaces 406 In order for a LOADng Router to participate in a LLN, it MUST have at 407 least one, and possibly more, LOADng interfaces. Each LOADng 408 interface: 410 o Is configured with one or more interface addresses. 412 In addition to a set of LOADng interfaces as described above, each 413 LOADng Router: 415 o Has a number of router parameters. 417 o Has an Information Base. 419 o Generates and processes RREQ, RREP, RREP_ACK and RERR messages, 420 according to this specification. 422 4.3. Information Base Overview 424 Necessary protocol state is recorded by way of five information sets: 425 the "Routing Set", the "Local Interface Set", the "Blacklisted 426 Neighbor Set", the "Destination Address Set", and the "Pending 427 Acknowledgment Set". 429 The Routing Set contains tuples, each representing the next-hop on, 430 and the cost of, a route towards a destination address. 431 Additionally, the Routing Set records the sequence number of the last 432 message, received from the destination. This information is 433 extracted from the message (RREQ or RREP) that generated the tuple so 434 as to enable routing. The routing table is to be updated using this 435 Routing Set. (A router MAY choose to use any or all destination 436 addresses in the Routing Set to update the routing table, this 437 selection is outside the scope of this specification.) 439 The Local Interface Set contains tuples, each representing a local 440 interface of the router. Each tuple contains a list of one or more 441 addresses of that interface. 443 The Blacklisted Neighbor Set contains tuples representing neighbor 444 LOADng Routers with which unidirectional connectivity has been 445 recently detected. 447 The Destination Address Set contains tuples representing addresses, 448 for which the LOADng Router is responsible; i.e., be addresses of 449 this LOADng Router, or of hosts and networks directly attached to 450 this router and which use it to connect to the LLN. These addresses 451 may in particular belong to devices which do not implement LOADng, 452 and thus cannot process LOADng messages. This router SHOULD provide 453 connectivity to these addresses by generating RREPs in response to 454 RREQs directed towards them. 456 The Pending Acknowledgment Set contains tuples, representing 457 transmitted RREPs for which an RREP_ACK is expected, but where this 458 RREP_ACK has not yet been received. 460 The Routing Set, the Blacklisted Neighbor Set and the Pending 461 Acknowledgment Set are updated by this protocol. The Destination 462 Address Set is used, but not updated, by this protocol. 464 4.4. Signaling Overview 466 This protocol generates and processes the following routing messages: 468 Route Request (RREQ) - Generated by a LOADng Router when it has a 469 data packet to deliver to a given destination, but when it does 470 not have an available tuple in its Routing Set indicating a route 471 to that destination. An RREQ contains: 473 * The address (destination) to which a Forward Route is to be 474 discovered by way of soliciting the LOADng Router with that 475 destination address in its Local Interface Set or in its 476 Destination Address Set to generate an RREP. 478 * The address for which a Reverse Route is to be installed 479 (originator) by RREQ forwarding and processing, i.e., the 480 source address of the data packet which triggered the RREQ 481 generation. 483 * The sequence number of the LOADng Router, generating the RREQ. 485 An RREQ is flooded through the network, according to the flooding 486 operation specified for the network. 488 Route Reply (RREP) - Generated as a response to an RREQ by the 489 LOADng Router which has the address (destination) from the RREQ in 490 its Local Interface Set or in its Destination Address Set. An RREP 491 is sent in unicast towards the originator of that RREQ. An RREP 492 contains: 494 * The address (originator) to which a Forward Route is to be 495 installed when forwarding the RREP. 497 * The address (destination) towards which the RREP is to be sent. 498 More precisely, the destination address indicates the unicast 499 route which the RREP follows. 501 * The sequence number of the LOADng Router, generating the RREP. 503 Route Reply Acknowledgment (RREP_ACK) - Generated by a LOADng Router 504 as a response to an RREP, in order to signal to the neighbor that 505 transmitted the RREP that the RREP was successfully received. 506 Receipt of an RREP_ACK indicates that the link between these two 507 neighboring LOADng Routers is bidirectional. An RREP_ACK is 508 unicast to the neighbor from which the RREP has arrived, and is 509 not forwarded. RREP_ACKs are generated only in response to an 510 RREP which, by way of a flag, has explicitly indicated that an 511 RREP_ACK is desired. 513 Route Error (RERR) - Generated by a LOADng Router when a link on an 514 active route to a destination is detected as broken by way of 515 inability to forward a data packet towards that destination. An 516 RERR is unicast to the source of the undeliverable data packet. 518 5. Protocol Parameters and Constants 520 The following router parameters and constants are used in this 521 specification. 523 LL-LLN-Routers - is a link-local-scoped multicast address of a 524 group, which all LOADng Routers MUST join if LOADng is used as 525 route-over protocol using IP. 527 NET_TRAVERSAL_TIME - is the maximum time that a packet is expected 528 to take when traversing from one end of the network to the other. 530 RREQ_RETRIES - is the maximum number of subsequent RREQs that a 531 particular router may generate in order to discover a route to a 532 destination, before declaring that destination unreachable. 534 RREQ_RATELIMIT - is the maximum number of RREQs that a particular 535 router is allowed to send per time interval. 537 R_HOLD_TIME - is the minimum time a Routing Tuple SHOULD be kept in 538 the Routing Set after it was last refreshed. This MAY be a 539 network-wide constant, but MAY also be a variable whose value is 540 defined by an auxiliary mechanism, e.g., by an extension to this 541 protocol. 543 MAX_DIST - is the value (tuple) representing the maximum possible 544 distance (R_dist field). 546 RREP_ACK_REQUIRED - is a boolean flag, which indicates (if set) that 547 the router is configured to expect that each RREP it sends be 548 confirmed by an RREP_ACK or (if cleared) that no RREP_ACK is 549 expected. 551 RREP_ACK_TIMEOUT - is the minimum time after transmission of an 552 RREP, that a LOADng Router SHOULD wait for an RREP_ACK from a 553 neighbor LOADng Router, before considering that the link to this 554 neighbor is unidirectional. 556 B_HOLD_TIME - is the time during which the link between the neighbor 557 LOADng Router and this LOADng Router MUST be considered as non- 558 bidirectional, and that therefore RREQs received from that 559 neighbor LOADng Router MUST be ignored after being added. 560 B_HOLD_TIME should be greater than 2 x NET_TRAVERSAL_TIME x 561 RREQ_RETRIES, to ensure that subsequent RREQs will reach the 562 destination via a route, excluding this link. 564 USE_BIDIRECTIONAL_LINK_ONLY - is a boolean flag, which indicates if 565 the LOADng Router only uses verified bi-directional links for data 566 packet forwarding. It is set by default. If cleared, then the 567 LOADng Router can use links which have not been verified to be bi- 568 directional. 570 HOP_COUNT_WITH_WEAK_LINKS - is the value representing the default 571 hop count with weak links metric, see Section 16. 573 6. Information Base 575 Each LOADng Router maintains an Information Base, containing the 576 information sets necessary for protocol operation, as described in 577 the following sections. The organization of information into these 578 information sets is non-normative, given so as to facilitate 579 description of message generation, forwarding and processing rules in 580 this specification. An implementation may choose any representation 581 or structure for when maintaining this information. 583 6.1. Routing Set 585 The Routing Set records the next hop on the route to each known 586 destination, when such a route is known. It consists of Routing 587 Tuples: 589 (R_dest_addr, R_next_addr, R_dist, R_metric, 590 R_seq_num, R_valid_time, R_bidirectional, R_local_iface_addr) 592 where: 594 R_dest_addr - is the address of the destination, either the address 595 of an interface of a destination LOADng Router, or the address of 596 an interface reachable via the destination LOADng Router, but 597 which is outside the LLN. 599 R_next_addr - is the address of the "next hop" on the selected route 600 to the destination. 602 R_dist - is the distance associated with the selected route to the 603 destination with address R_dest_addr. R_dist is a tuple 604 containing Route Cost, Weak Links and (depending on the metric 605 used) additional fields; see Section 16. 607 R_metric - specifies how R_dist is defined and calculated, as well 608 as the comparison operator '<=' for determining which of two route 609 costs is lower. This is specified in Section 16. 611 R_seq_num - is the value of the field of the RREQ or RREP 612 which installed or last updated this tuple. For the routing 613 tuples installed by previous hop information of RREQ or RREP, 614 R_seq_num MUST be set to -1. 616 R_valid_time - specifies the time until which the information 617 recorded in this tuple is considered valid. 619 R_bidirectional - is a boolean flag, which specifies if the routing 620 tuple is verified as representing a bi-directional route. Data 621 traffic SHOULD only be routed through a routing tuple with 622 R_bidirectional flag equals TRUE, unless the router is configured 623 as accepting routes without bi-directionality verification 624 explicitly by setting the USE_BIDIRECTIONAL_LINK_ONLY to FALSE. 626 R_local_iface_addr - is the address of the local interface, through 627 which the destination can be reached. 629 6.2. Local Interface Set 631 A router's Local Interface Set records its local interfaces. It 632 consists of Local Interface Tuples, one per interface: 634 (I_local_iface_addr_list) 636 where: 638 I_local_iface_addr_list - is an unordered list of the network 639 addresses of this interface. 641 The implementation MUST initialize the Local Interface Set with at 642 least one tuple containing at least one address of an interface. 643 Moreover, the implementation MUST update the Local Interface Set if 644 there is a change of the interfaces of a LOADng router (i.e. a new 645 interface, a removed interface, or a change of addresses of an 646 interface). 648 6.3. Blacklisted Neighbor Set 650 The Blacklisted Neighbor Set records the neighbor interface addresses 651 of a LOADng Router, with which connectivity has been detected to be 652 unidirectional. Specifically, the Blacklisted Neighbor Set records 653 neighbors from which an RREQ has been received (i.e., through which a 654 Forward Route would possible) but to which it has been determined 655 that it is not possible to communicate (i.e., forwarding Route 656 Replies via this neighbor fails, rendering installing the Forward 657 Route impossible). It consists of Blacklisted Neighbor Tuples: 659 (B_neighbor_address, B_valid_time) 661 where: 663 B_neighbor_address - is the address of the blacklisted neighbor 664 interface. 666 B_valid_time - specifies the time until which the information 667 recorded in this tuple is considered valid. 669 6.4. Destination Address Set 671 The Destination Address Set records addresses, for which a LOADng 672 Router will generate RREPs in response to received RREQs, in addition 673 to its own interface addresses (as listed in the Local Interface 674 Set). The Destination Address Set thus represents those destinations 675 (i.e. hosts), for which this LOADng Router is providing connectivity. 676 It consists of destination address tuples: 678 (D_address) 680 where: 682 D_address - is the address of a destination (a host or a network), 683 attached to this LOADng Router and for which this LOADng Router 684 provides connectivity through the LLN. 686 The Destination Address Set is used for generating signaling, but is 687 not itself updated by signaling specified in this document. Updates 688 to the Destination Address Set are due to changes of the environment 689 of a LOADng Router - hosts or external networks being connected to or 690 disconnected from a LOADng Router. The Destination Address Set may 691 be administrationally provisioned, or provisioned by external 692 protocols. 694 6.5. Pending Acknowledgment Set 696 The Pending Acknowledgment Set contains information about RREPs which 697 have been transmitted with the ACK_REQUIRED flag set, and for which 698 an RREP_ACK has not yet been received. It consists of Pending 699 Acknowledgment Tuples: 701 (P_next_hop, P_originator, P_seq_num, P_ack_timeout) 703 where: 705 P_next_hop - is the address of the neighbor interface to which the 706 RREP was sent. 708 P_originator - is the address of the originator of the RREP. 710 P_seq_num - corresponds to the field of the sent RREP. 712 P_ack_timeout - is the time after which the neighbor is considered 713 not to have a bidirectional link to this router and MUST be added 714 to the Blacklisted Neighbor Set; the tuple MUST then be discarded. 716 7. LOADng Router Sequence Numbers 718 Each LOADng Router maintains a single sequence number, which must be 719 included in each RREQ or RREP message it generates. Each router MUST 720 make sure that no two messages (both RREQ and RREP) are generated 721 with the same sequence number, and MUST generate sequence numbers 722 such that these are monotonically increasing. This sequence number 723 is used as freshness information for when comparing routes to the 724 router having generated the message. 726 However, with a limited number of bits for representing sequence 727 numbers, wrap-around (that the sequence number is incremented from 728 the maximum possible value to zero) will occur. To prevent this from 729 interfering with the operation of the protocol, the following MUST be 730 observed. The term MAXVALUE designates in the following the largest 731 possible value for a sequence number. The sequence number S1 is said 732 to be "greater than" (denoted '>') the sequence number S2 if: 734 S2 < S1 AND S1 - S2 <= MAXVALUE/2 OR 736 S1 < S2 AND S2 - S1 > MAXVALUE/2 738 8. Packet Format 740 The packet format, used by this protocol, is described in this 741 section using the notational conventions described in Section 2. 742 Example packets are illustrated in Appendix A. 744 The general format for all packets, generated, forwarded and 745 processed by this specification, is as follows: 747 := 748 749 750 752 where: 754 is an 8 bit unsigned integer field and specifies the type of 755 the field, specified in Section 8.2. 757 is a 4 bit unsigned integer field, encoding the length 758 of the destination and originator addresses of the field 759 ( and ) as follows: 761 := the length of an address in octets - 1 763 is thus 1 for 16 bit short addresses [RFC4944], 3 764 for IPv4 addresses, 7 for 64 bit extended addresses [RFC4944] or 765 15 for IPv6 addresses. 767 is specified in Section 8.1. 769 is specified in Section 8.2. 771 8.1. TLV Block 773 The TLV Block contains zero or more Type-Length-Value elements 774 (TLVs). A TLV allows the association of an arbitrary attribute with 775 a packet. The attribute (value) is made up from an integer number of 776 consecutive octets. Different attributes have different types; 777 attributes which are unknown when parsing can be skipped, as 778 specified by flags associated with a given TLV. 780 := 781 ()* 783 where: 785 is a 4 bit unsigned integer field, specifying the number 786 of TLVs included. 788 is an 8 bit unsigned integer field, specifying the type 789 of the TLV. 791 is an 8 bit field specifying processing and forwarding 792 rules related to the TLV processing: 794 bit 0 (difunknown): If cleared (0), indicates that if a LOADng 795 Router does not understand the , then it MAY process 796 the packet, and all TLVs with fields which it 797 understands. If set (1), indicates that if a LOADng Router 798 does not understand the , then it MUST NOT process or 799 forward the packet and the packet MUST be silently dropped. 801 bit 1 (rifunknown): If cleared (0), indicates that if a LOADng 802 Router does not understand the , then it MAY keep the 803 TLV when processing (which is then determined by the value of 804 the pifunknown flag) and (for packets, intended to be 805 forwarded) forwarding. If set (1), indicates that if a LOADng 806 Router does not understand the , it MUST remove the 807 TLV from the packet prior to processing and (for packets, 808 intended to be forwarded) forwarding. 810 difunknown and rifunknown flags MUST NOT be set (1) in the same 811 time. 813 bit 2-7 (RESERVED): SHOULD be set to zero on transmission and 814 SHOULD be ignored upon receipt. 816 is an 8 bit unsigned integer field that equals or is 817 greater than 0, specifying the length of the following 818 field in octets. 820 is a field of length octets. 822 8.2. Message Format 824 This section specifies the format of the field for message 825 types RREQ, RREP, RREP_ACK and RERR. 827 8.2.1. RREQ and RREP Message Format 829 The format of Route Request (RREQ) and Route Reply (RREP) messages is 830 identical, RREQ and RREP messages being distinguished by the 831 field in the packet. They are as follows: 833 := 834 835 836 837 838 839 841 where: 843 is a 16 bit unsigned integer field, containing the 844 sequence number (see Section 7) of the LOADng Router, generating 845 the RREQ or RREP message. 847 is an 8 bit unsigned integer field and specifies how the 848 route cost is to be calculated, as well as the comparison operator 849 '<=' used for when determining which among two route costs is 850 lower. The route cost calculation MAY be based on the and fields of the packet. It MAY also use 852 additional information, encoded in TLVs. 854 is a 4 bit unsigned integer field and specifies the 855 interpretation of the remainder of the message. 857 For RREQ messages: 859 bit 0-3 (RESERVED): SHOULD be set to zero on transmission and 860 SHOULD be ignored upon receipt. 862 For RREP messages: 864 bit 0 (ackrequired): When set ('1'), an RREP_ACK MUST be 865 generated by the recipient of an RREP if the RREP is 866 successfully processed. When cleared ('0'), an RREP_ACK 867 MUST NOT be generated in response to processing of the RREP. 869 bit 1-3 (RESERVED): SHOULD be set to zero on transmission and 870 SHOULD be ignored upon receipt. 872 is a 4 bit unsigned integer field and specifies the 873 total number of weak links on the route from the originator to the 874 destination. This field MAY be updated when a packet is 875 forwarded, see Section 11.2. 877 is an 8 bit unsigned integer field and specifies the 878 total number of hops which the packet has traversed from the 879 to the . This field MUST be updated, 880 when a packet is forwarded, see Section 12.3 and Section 13.3. 882 is an identifier of + 1 octets, 883 specifying the interface address for which this message was 884 generated, and to which a route is supplied by this message. For 885 an RREQ, the route supplied corresponds to the "reverse route", 886 whereas for an RREP the route supplied corresponds to the "forward 887 route". In case the message is generated on a LOADng router on 888 behalf of an attached host, the address corresponds 889 to an interface address of that host, otherwise it corresponds to 890 an address of the sending interface of the LOADng router. 892 is an identifier of + 1 octets, 893 specifying the address to which the RREQ or RREP should be sent. 894 (I.e., for an RREQ, this address would be the interface address 895 for which a route is sought. For an RREP, this address is 896 equivalent to the address of the RREQ that triggered 897 the RREP.) 899 8.2.2. RREP_ACK Message Format 901 The format of a Route Reply Acknowledgment (RREP_ACK) message is as 902 follows: 904 := 905 907 where: 909 is a 16 bit unsigned integer field and contains the value 910 of the field from the RREP for which this RREP_ACK is 911 sent. 913 is an identifier of + 1 octets and 914 contains the value of the field from the RREP for 915 which this RREP_ACK is sent. 917 8.2.3. RERR Message Format 919 The format of a Route Error (RERR) message is as follows: 921 := 922 923 925 where: 927 is an 8 bit unsigned integer field and specifies the 928 reason for the error message being generated, according to 929 Table 4. 931 is an identifier of + 1 octets, 932 specifying the source address of a data packet, for which delivery 933 to failed. The unicast destination of the RERR 934 message is the LOADng Router which has listed in a 935 Local Interface Tuple or in a Destination Address Tuple. 937 is an identifier of + 1 octets, 938 specifying the address of the destination, which has become 939 unreachable, and for which an error is reported. 941 9. Route Maintenance 943 Tuples in the Routing Set are maintained by way of five different 944 mechanisms: 946 o RREQ/RREP exchange, specified in Section 12 and Section 13. 948 o Data traffic delivery success. 950 o Data traffic delivery failure. 952 o External signals indicating that a tuple in the Routing Set 953 necessitates updating. 955 o Information expiration. 957 Routing Tuples in the Routing Set contain a validity time, which 958 specifies the time until which the information recorded in this tuple 959 is considered valid. After this time, the information in such tuples 960 is to be considered as invalid, for the processing specified in this 961 document. 963 Routing Tuples for actively used routes (i.e., a route via which 964 traffic is currently transiting) SHOULD NOT be removed, unless there 965 is evidence that they no longer provide connectivity - i.e., unless a 966 link on that route has broken. 968 To this end, one or more of the following mechanisms (non-exhaustive 969 list) MAY be used: 971 o If a lower layer mechanism provides signals, such as when delivery 972 to a presumed neighbor LOADng Router fails, this signal MAY be 973 used to indicate that a link has broken, trigger early expiration 974 of a Routing Tuple from the Routing Set, and to initiate Route 975 Error Signaling (see Section 14). Conversely, absence of such a 976 signal when attempting delivery MAY be interpreted as validation 977 that the corresponding Routing Tuple(s) are valid, and their 978 R_valid_time refreshed correspondingly. Note that when using such 979 a mechanism, care should be taken to prevent that an intermittent 980 error (e.g., an incidental wireless collision) triggers corrective 981 action and signaling. This depends on the nature of the signals, 982 provided by the lower layer, but can include the use of a 983 hysteresis function or other statistical mechanisms. 985 o Conversely, for each successful delivery of a packet to a neighbor 986 or a destination, if signaled by a lower layer or a transport 987 mechanism, or each positive confirmation of the presence of a 988 neighbor by way of an external neighbor discovery protocol, MAY be 989 interpreted as validation that the corresponding Routing Tuple(s) 990 are valid, and their R_valid_time refreshed correspondingly. 992 Furthermore, a LOADng Router may experience that a route currently 993 used for forwarding data packets is no longer operational, and must 994 act to either rectify this situation locally (Section 13) or signal 995 this situation to the source of the data packets for which delivery 996 was unsuccessful (Section 14). 998 10. Unidirectional Link Handling 1000 Each LOADng Router MUST monitor the bidirectionality of the links to 1001 its neighbors and set the R_bidirectional flag of related routing 1002 tuples when processing Route Replies (RREP). To this end, one or 1003 more of the following mechanisms MAY be used (non exhaustive list): 1005 o If a lower layer mechanism provides signals, such as when delivery 1006 to a presumed neighbor LOADng Router fails, this signal MAY be 1007 used to detect that a link to this neighbor is broken or is 1008 unidirectional; the LOADng Router MUST then blacklist the 1009 neighbor, see Section 10.1. 1011 o If a mechanism such as NDP [RFC4861] is available, the LOADng 1012 Router MAY use it. 1014 o RREP_ACK message exchange, as described in Section 15. 1016 o Upper-layer mechanisms, such as transport-layer acknowledgments, 1017 MAY be used to detect unidirectional or broken links. 1019 When a LOADng Router detects, via one of these mechanisms, that a 1020 link to a LOADng neighbor router is unidirectional or broken, the 1021 router MUST blacklist this neighbor, see Section 10.1. Conversely, 1022 if a LOADng Router detects via one of these mechanisms that a 1023 previously blacklisted LOADng Router has a bidirectional link to this 1024 router, it MAY remove it from the blacklist before the 1025 of the corresponding tuple. 1027 10.1. Blacklist Usage 1029 The Blacklist is maintained according to Section 6.3. When a LOADng 1030 Router is detected to have a unidirectional link to the LOADng 1031 Router, it is blacklisted, i.e., a tuple (B_neighbor_address, 1032 B_valid_time) is created thus: 1034 o B_neighbor_address := the address of the blacklisted neighbor 1036 o B_valid_time := current_time + B_HOLD_TIME 1038 When a LOADng neighbor router is blacklisted, i.e., when there is a 1039 corresponding (B_neighbor_address, B_valid_time) tuple in the 1040 Blacklisted Neighbor Set, it is temporarily not considered as a 1041 neighbor, and thus: 1043 o Every RREQ received from this neighbor MUST be discarded; 1045 11. Common Rules for RREQ and RREP Messages 1047 RREQ and RREP messages, both, supply routes between their recipients 1048 and the originator of the RREQ or RREP message. The two message 1049 types therefore share common processing rules, and differ only in the 1050 following: 1052 o RREQ messages are multicast or broadcast, intended to be received 1053 by all LOADng Routers in the network, whereas RREP messages are 1054 all unicast, intended to be received only by routers on a specific 1055 route towards a specific destination. 1057 o Receipt of an RREQ message MAY trigger generation of an RREP 1058 message. 1060 o Receipt of an RREP message MAY trigger generation of an RREP_ACK 1061 message. 1063 For the purpose of the processing description in this section, the 1064 following additional notation is used: 1066 <= is the comparison operator specified by the field in the 1067 RREQ or RREP message and described in Section 16. 1069 received-route-cost is a variable, representing the cost of the 1070 route, as calculated based on the received message, see 1071 Section 16. 1073 used-metric is a variable, representing the metric used for 1074 calculating received-route-cost, see Section 16. 1076 previous-hop is the address of the LOADng Router, from which the 1077 RREQ or RREP message was received. 1079 > is the comparison operator for specified in Section 8. 1081 11.1. Identifying Invalid RREQ or RREP Messages 1083 A received RREQ or RREP message is invalid, and MUST be discarded 1084 without further processing, if any of the following conditions are 1085 true: 1087 o The address length specified by this message (i.e., 1088 + 1) differs from the length of the address(es) of this router. 1090 o The address contained in the field is an address of 1091 this router. 1093 o There is a tuple in the Routing Set where: 1095 * R_dest_addr = 1097 * R_seq_num > 1099 o For RREQ messages only, an RREQ MUST be considered invalid if the 1100 previous-hop is blacklisted (i.e. its address is in a tuple in the 1101 Blacklisted Neighbor Set, see Section 10.1). 1103 A LOADng Router MAY recognize additional reasons for identifying that 1104 an RREQ or RREP message is invalid for processing, e.g., to allow a 1105 security protocol to perform verification of signatures and prevent 1106 processing of unverifiable RREQ or RREP message by this protocol. 1108 11.2. RREQ and RREP Message Processing 1110 A received, and valid, RREQ or RREP message is processed as follows: 1112 1. Included TLVs are processed/removed/updated according to their 1113 specification. 1115 2. If the RREQ or RREP message was received over a "weak link", 1116 increment the field in the received RREQ or RREP by 1117 one. 1119 3. If the , indicated in the message, is known to this 1120 LOADng Router, then: 1122 * Set the variable used-metric to the value of . 1124 4. Otherwise, if the , indicated in the message, is unknown 1125 to this LOADng Router: 1127 * Set the variable used-metric to HOP_COUNT_WITH_WEAK_LINKS. 1129 5. Set the variable received-route-cost to the route cost, 1130 calculated according to used-metric. 1132 6. Find the Routing Tuple (henceforth, matching Routing Tuple) 1133 where: 1135 * R_dest_addr = 1137 * R_metric = used-metric 1139 7. If no matching Routing Tuple is found, then create a new matching 1140 Routing Tuple (the "reverse route" for RREQ messages or "forward 1141 route" for RREP messages) with: 1143 * R_dest_addr := 1145 * R_next_addr := previous-hop 1147 * R_metric := used-metric 1149 * R_dist := MAX_DIST 1151 * R_seq_num := -1 1153 * R_valid_time := current time + R_HOLD_TIME 1155 * R_bidirectional := FALSE 1157 * R_local_iface_addr := the interface address through which the 1158 packet was received. 1160 8. The matching Routing Tuple, existing or new, is compared to the 1161 received RREQ or RREP message: 1163 1. If 1165 + received-route-cost < R_dist; AND 1167 + R_seq_num = 1169 OR 1171 + > R_seq_num 1173 Then: 1175 + The message is used for updating the Routing Set according 1176 to Section 11.3. 1178 + If there is no matching Routing Tuple in the Routing Set 1179 with R_dest_addr = previous-hop, create a new matching 1180 Routing Tuple with: 1182 - R_dest_addr := previous-hop 1184 - R_next_addr := previous-hop 1185 - R_metric := HOP_COUNT_WITH_WEAK_LINKS 1187 - R_dist := (HC, WL), where HC = 1 and WL = 1 if the 1188 message was received over a "weak link". Otherwise, WL 1189 = 0 1191 - R_seq_num := -1 1193 - R_valid_time := current time + R_HOLD_TIME 1195 - R_bidirectional := TRUE, if the processed message is an 1196 RREP, otherwise FALSE. 1198 - R_local_iface_addr := the interface address through 1199 which the packet was received. 1201 2. Otherwise, the RREQ or RREP message is not processed further, 1202 and is not considered for forwarding. 1204 11.3. Updating Routing Tuples In Response to RREQ and RREP 1206 A Routing Tuple in the Routing Set is updated when a received RREQ or 1207 RREP message provides a better route to the than the 1208 route current recorded for a given metric. The Routing Tuple, where: 1210 o R_dest_addr = ; AND 1212 o R_metric = used-metric 1214 is updated thus: 1216 o R_next_addr := previous-hop 1218 o R_dist := received-route-cost 1220 o R_seq_num := 1222 o R_valid_time := current time + R_HOLD_TIME 1224 o R_bidirectional := TRUE, if the message being processed is an 1225 RREP. 1227 12. Route Requests (RREQs) 1229 Route Requests (RREQs) are generated by a LOADng Router when it has 1230 data packets to deliver to a destination for which it has no matching 1231 bi-directional tuple in the Routing Set (i.e., with R_bidirectional 1232 set to TRUE). Only when the router is configured explicitly as being 1233 able to use routing tuples without bi-directionality verification 1234 (i.e., with R_bidirectional set to FALSE) by setting 1235 USE_BIDIRECTIONAL_LINK_ONLY flag to FALSE, can the router use the 1236 routing tuple without initiating an RREQ. The RREQ is transmitted to 1237 all directly reachable neighbor LOADng Routers. 1239 After originating an RREQ, a LOADng Router waits for a corresponding 1240 RREP. If no such RREP is received within 2*NET_TRAVERSAL_TIME 1241 milliseconds, the LOADng Router MAY issue a new RREQ for the sought 1242 destination (with an incremented seq_num) up to a maximum of 1243 RREQ_RETRIES times. A LOADng Router SHOULD NOT originate more than 1244 RREQ_RATELIMIT RREQs per second. A LOADng Router MAY use mechanisms 1245 such as exponential backoff to determine the rate at which it 1246 originates RREQs. 1248 12.1. RREQ Generation 1250 A packet with an RREQ message is generated according to Section 8.2 1251 with the following content: 1253 o := RREQ; 1255 o set to the length of the address, as specified in 1256 Section 8; 1258 o set to indicate how route costs are to be calculated and 1259 compared, according to Table 3; 1261 o := 0; 1263 o set to the next unused sequence number, maintained by 1264 this router; 1266 o := 1; 1268 o := the address to which a route is sought; 1270 o := one address of the LOADng Router interface that 1271 generates the RREQ. If the LOADng Router is generating RREQ on 1272 behalf of a host connected to this LOADng Router, the sender 1273 address of the host is used; 1275 o TLVs, as neccessary for the (if any), see Section 16. 1277 12.2. RREQ Processing 1279 On receiving an RREQ message, a LOADng Router MUST process the 1280 message according to this section: 1282 1. If the message is invalid for processing, as defined in 1283 Section 11.1, the message MUST be discarded without further 1284 processing. The message is not considered for forwarding. 1286 2. Otherwise, the message is processed according to Section 11.2. 1288 3. If the field equals MAX_HOP_COUNT (i.e., 255), or the 1289 field equals MAX_WEAK_LINKS (i.e., 15), the message 1290 is not considered for forwarding. 1292 4. If in the RREQ message is not listed in 1293 I_local_iface_addr_list of any Local Interface Tuple, or does 1294 correspond to D_address of any Destination Address Tuple of this 1295 LOADng Router, then the message is considered for forwarding 1296 according to Section 12.3. 1298 5. Otherwise, an RREP can be generated, see Section 13.1. The RREQ 1299 is not considered for forwarding. 1301 12.3. RREQ Forwarding 1303 An RREQ, considered for forwarding, MUST be updated as follows, prior 1304 to it being transmitted: 1306 1. := used-metric (as set in Section 11.2) 1308 2. := + 1 1310 3. TLVs used by updated according to the specification of 1311 included in the RREQ, see Section 16. 1313 An RREQ is forwarded according to the flooding operation, specified 1314 for the network. This MAY be by way of classic flooding, or the 1315 flooding operation for a given network MAY employ a reduced relay set 1316 mechanism such as [SMF] or any other information diffusion mechanism 1317 such as [RFC6206]. Care must be taken that NET_TRAVERSAL_TIME is 1318 chosen so as to accommodate for the maximum time that may take for an 1319 RREQ to traverse the network, accounting for in-router delays 1320 incurring due to or imposed by such algorithms. 1322 12.4. RREQ Transmission 1324 RREQs, initially generated or forwarded, are sent to all neighbor 1325 LOADng Routers. If LOADng is operating as an IP routing protocol, 1326 the destination address for this RREQ MUST be the link local 1327 multicast address LL-LLN-Routers, and the source address MUST be the 1328 address of the interface over which the RREQ is sent. 1330 When an RREQ is transmitted, all receiving LOADng Routers will 1331 process the RREQ message and MAY consider the RREQ message for 1332 forwarding at the same, or at almost the same, time. If using data 1333 link and physical layers that are subject to packet loss due to 1334 collisions, such RREQ messages SHOULD be jittered as described in 1335 [RFC5148]. 1337 13. Route Replies (RREPs) 1339 Route Replies (RREPs) are generated by a LOADng Router in response to 1340 an RREQ, and is sent by the LOADng Router which has, in either its 1341 Destination Address Set or in its Local Interface Set, the address 1342 which is contained in the element of the received RREQ. 1343 RREPs are sent, hop by hop, in unicast towards the originator of the 1344 corresponding RREQ, along the Reverse Route installed by that RREQ. 1345 A router, upon forwarding an RREP, installs the Forward Route towards 1346 the . 1348 Thus, with forwarding of RREQs installing the Reverse Route and 1349 forwarding of RREPs installing the Forward Route, bi-directional 1350 routes are provided between the and 1351 indicated in the RREQ. 1353 13.1. RREP Generation 1355 At least one RREP MUST be generated in response to a (set of) 1356 received RREQ messages with identical (,). An 1357 RREP can be generated immediately as a response to each RREQ 1358 processed, or can be generated after a certain delay after the 1359 arrival of the first RREQ, in order to use the "best" received RREQ 1360 (received over lowest-cost route, over the route with least Weak 1361 Links etc). A LOADng Router MAY generate further RREPs for 1362 subsequent RREQs received with the same (,) 1363 pairs, if these indicate a better route. The content of an RREP is 1364 as follows: 1366 o := RREP; 1368 o bit-0 ackrequired flag set to ('1') if RREP_ACK is required 1369 by the router (i.e. if RREP_ACK_REQUIRED is set to TRUE). 1371 Otherwise, bit-0 is cleared ('0'); 1373 o set to the length of the address, as specified in 1374 Section 8; 1376 o set to the next unused sequence number, maintained by 1377 this LOADng Router; 1379 o set to the same value as the in the 1380 corresponding RREQ; 1382 o := 0; 1384 o := 1; 1386 o := the address to which this RREP message is to be 1387 sent; this corresponds to the address from the RREQ 1388 message, in response to which this RRREP message is generated; 1390 o := the address of the LOADng Router, generating the 1391 RREP. If the LOADng Router is generating RREP on behalf of the 1392 hosts connected to it, or on behalf of one of the addresses 1393 contained in the routers Destination Address Set, the host address 1394 is used. 1396 o TLVs, as neccessary for the (if any), see Section 16. 1398 The specification of the TLVs included in the of the RREQ 1399 responsible to generate the RREP MUST stipulate if, and under which 1400 conditions, these are to be included in the of the RREP. 1402 13.2. RREP Processing 1404 On receiving an RREP message, a LOADng Router MUST process the 1405 message according to this section: 1407 1. If the message is invalid for processing, as defined in 1408 Section 11.1, the message MUST be discarded without further 1409 processing. The message is not considered for forwarding. 1411 2. Otherwise, the message is processed according to Section 11.2. 1413 3. If the RREP message has the ackrequired flag set, an RREP_ACK 1414 message MUST be sent to the previous-hop, according to 1415 Section 15.1. 1417 4. If the field equals MAX_HOP_COUNT (i.e., 255), or the 1418 field equals MAX_WEAK_LINKS (i.e., 15), the message 1419 is not considered for forwarding. 1421 5. If the in the RREP message is not listed in 1422 I_local_iface_addr_list of any Local Interface Tuple and does not 1423 correspond to D_address of any Destination Address Tuple of this 1424 LOADng Router, the RREP message is considered for forwarding 1425 according to Section 13.3. 1427 13.3. RREP Forwarding 1429 An RREP message, considered for forwarding, MUST be updated as 1430 follows, prior to it being transmitted: 1432 1. := used-metric (as set in Section 11.2) 1434 2. := + 1 1436 3. TLVs used by updated according to the specification of 1437 included in the RREQ, see Section 16. 1439 4. If this LOADng Router is configured to use RREP_ACKs in order to 1440 check the bidirectionality of the links (i.e. RREP_ACK_REQUIRED 1441 is set to TRUE), the ackrequired flag MUST be set to (1), 1442 according to Section 15. 1444 The RREP message is then unicast to the next hop towards the 1445 indicated in the RREP. 1447 13.4. RREP Transmission 1449 An RREP is, ultimately, destined for the LOADng Router listed in the 1450 field, and is forwarded in unicast towards this LOADng 1451 Router. The RREP MUST, however, be transmitted so as to allow it to 1452 be processed in each intermediate LOADng Router to: 1454 o Install proper forward routes; 1456 o Permit that and be updated to reflect the 1457 route; AND 1459 o Permit that TLVs included may be processed/added/removed according 1460 to their specification. 1462 14. Route Errors (RERRs) 1464 If a LOADng Router fails to deliver a data packet to a next hop or a 1465 destination, it MUST generate a Route Error (RERR), and send this 1466 RERR along the Reverse Route towards the source of the data packet 1467 for which delivery was unsuccessful (to the last router along the 1468 Reverse Route, if the data packet was originated by a host behind 1469 that router). 1471 14.1. Identifying Invalid RERR Messages 1473 A LOADng Router MAY recognize reasons, external to this 1474 specification, for identifying that an RERR message is invalid for 1475 processing, e.g., to allow a security protocol to perform 1476 verification of signatures and prevent processing of unverifiable 1477 RERR message by this protocol. 1479 14.2. RERR Generation 1481 A packet with an RERR message is generated by the LOADng Router, 1482 detecting the link breakage, with the following content: 1484 o := RERR; 1486 o := the most appropriate error code from among those 1487 recorded in Table 4; 1489 o := the length of the address, as specified in 1490 Section 8; 1492 o := the source address from the unsuccessfully 1493 delivered data packet. 1495 o := the destination address from the unsuccessfully 1496 delivered data packet. 1498 14.3. RERR Processing 1500 For the purpose of the processing description below, the following 1501 additional notation is used: 1503 previous-hop is the address of the LOADng Router, from which the 1504 RERR was received. 1506 Upon receiving an RERR, a LOADng Router MUST perform the following 1507 steps: 1509 1. Included TLVs are processed/removed/updated according to their 1510 specification. 1512 2. Find the Routing Tuple (henceforth "matching Routing Tuple") in 1513 the Routing Set where: 1515 * R_dest_addr = 1517 * R_next_addr = previous-hop 1519 3. If no matching Routing Tuple is found, the RERR is not processed 1520 further, and is not considered for forwarding. 1522 4. Otherwise, if one matching Routing Tuple is found, this matching 1523 Routing Tuple is updated as follows: 1525 * R_valid_time := expired 1527 The RERR message is, then, considered for forwarding. 1529 14.4. RERR Forwarding 1531 An RERR is, ultimately, destined for the LOADng Router on which the 1532 address from the field is listed in 1533 I_local_iface_addr_list of any Local Interface Tuple or which 1534 corresponds to D_address of any Destination Address Tuple. 1536 An RERR, considered for forwarding is therefore processed as follows: 1538 1. Find the Destination Address Tuple (henceforth, matching 1539 Destination Address Tuple) in the Destination Address Set where: 1541 * D_address = the address from the field of the 1542 RERR. 1544 2. If one or more matching Destination Address Tuples are found, the 1545 RERR message is discarded and not retransmitted, as it has 1546 reached the final destination. 1548 3. Otherwise, find the Local Interface Tuple (henceforth, matching 1549 Local Interface Tuple) in the Local Interface Set where: 1551 * I_local_iface_addr_list contains the address from the 1552 field of the RERR. 1554 4. If a matching Local Interface Tuple is found, the RERR message is 1555 discarded and not retransmitted, as it has reached the final 1556 destination. 1558 5. Otherwise, if no matching Destination Address Tuples or Local 1559 Interface Tuples are found, the RERR message is transmitted 1560 according to Section 14.5. 1562 14.5. RERR Transmission 1564 An RERR is transmitted, as unicast, to the LOADng Router, recorded 1565 the next hop for the indicated in the RERR message. The 1566 RERR MUST be transmitted hop-by-hop such that it can be processed in 1567 each intermediate LOADng Router. This serves to: 1569 o Allow intermediate routers to update their Routing Sets, i.e., 1570 remove tuples for this destination. 1572 o Permit that TLVs included may be processed/added/removed according 1573 to their specification. 1575 15. Route Reply Acknowledgments (RREP_ACKs) 1577 A LOADng Router SHOULD use RREP_ACK exchange to monitor 1578 bidirectionality of links with neighbor routers, except if another 1579 mechanism, as described in Section 10, provides for such 1580 bidirectionality information. 1582 A LOADng Router MUST signal in a transmitted RREP that it is 1583 expecting an RREP_ACK, by setting the ackrequired flag in the RREP. 1584 When doing so, the LOADng Router MUST also add a tuple (P_next_hop, 1585 P_originator, P_seq_num, P_ack_timeout) to the Pending Acknowledgment 1586 Set, and set P_ack_timeout to RREP_ACK_TIMEOUT. 1588 15.1. RREP_ACK Generation 1590 Upon reception of an RREP message with the ackrequired flag set, a 1591 LOADng Router MUST generate an RREP_ACK and send this RREP_ACK in 1592 unicast to the neighbor which originated the RREP. 1594 A packet with an RREP_ACK message is generated by a LOADng Router 1595 with the following content: 1597 o := RREP_ACK; 1599 o := the length of the address, as specified in 1600 Section 8; 1602 o := the field of the received RREP; 1604 o := the field of the received RREP. 1606 15.2. RREP_ACK Processing 1608 On receiving an RREP_ACK from a LOADng neighbor router, a LOADng 1609 Router MUST do the following: 1611 1. The TLV fields are added/removed/updated according to their 1612 specification. 1614 2. Find the Routing Tuple (henceforth, matching Routing Tuple) 1615 where: 1617 * R_dest_addr = previous-hop; 1619 and update the tuple with: 1621 * R_bidirectional := TRUE 1623 3. Check whether a corresponding RREP is pending, i.e. if the 1624 Pending Acknowledgment Set contains a tuple (P_next_hop, 1625 P_originator, P_seq_num, P_ack_timeout) such as: 1627 * P_next_hop is the address of the LOADng neighbor router from 1628 which the RREP_ACK was received. 1630 * P_originator corresponds to the field of the 1631 RREP_ACK. 1633 * P_seq_num corresponds to the field of the RREP_ACK. 1635 4. If such a tuple exists, then the RREP has been correctly 1636 acknowledged and the tuple MUST be discarded. 1638 5. Otherwise, i.e. if no such tuple exists, then no further 1639 processing is required. 1641 15.3. RREP_ACK Forwarding 1643 An RREP_ACK is intended only for a specific direct neighbor, and MUST 1644 NOT be forwarded. 1646 15.4. RREP_ACK Transmission 1648 An RREP_ACK is transmitted, in unicast, to the neighbor LOADng Router 1649 from which the RREP was received. 1651 16. Metrics 1653 This specification enables the use of different metrics for when 1654 calculating route costs, and specifies one particularly simplified 1655 such metric in Section 16.3, for use as a default ensuring 1656 interoperability even if routers in a network are configured to use 1657 different metrics. It is encouraged that more appropriate metrics be 1658 developed for different deployment environments. 1660 16.1. The <= Comparison Operator 1662 The objective of the <= comparison operator is to be able to 1663 determine which of two routes is "better", i.e., which route has the 1664 lowest cost. A link between a pair of interfaces may have a nominal 1665 and administratively assigned cost associated (such as, for example, 1666 representing a nominal bandwidth), however may also have a dynamic 1667 component making a link with an otherwise low cost a less attractive 1668 choice for when establishing a new route (such as, for example, if a 1669 high loss-rate is experienced across that link). 1671 16.2. Specifying New Metrics 1673 When defining a metric, the following considerations SHOULD be taken 1674 into consideration, and MUST be taken into consideration when 1675 requesting a code-point from IANA for the 1-8 range of the Cost Types 1676 registry defined in Table 3: 1678 o The definition of the R_dist field, as well as the value of 1679 MAX_DIST. 1681 o The mechanism for determining when a link qualifies as a "Weak 1682 Link". Examples include when an SNR or SIR is above/below a given 1683 threshold, etc. This MAY be by way of lower-layer information, 1684 message statistics or any other means. 1686 o The required TLVs for calculating the route cost, as well as the 1687 mechanism for determining how to update those fields when an RREP 1688 or RREQ is transmitted over an interface. 1690 o The <= comparison operator, which MUST specify a strict ordering 1691 of the R_dist space, i.e. R_dist1 can always be compared to 1692 R_dist2 and (R_dist1 <= R_dist2 && R_dist2 <= R_dist1) if and only 1693 if R_dist1 = R_dist2. 1695 16.3. Default Metric: Hop Count With Weak Links 1697 This section specifies a simple "Hop-Count-With-Weak-Links" metric, 1698 which is both the default metric provided for interoperability, and 1699 is intended to exemplify of how to specify metrics in general. It 1700 represents a simple "hop count" based cost, permitting avoiding weak 1701 links. It is RECOMMENDED to define a more appropriate metric for the 1702 environment in which the protocol is to operate. 1704 16.3.1. R_dist Definition 1706 R_dist := (HC, WL) where HC is the Hop Count, and WL the number of 1707 Weak Links. MAX_DIST := (255, 15). 1709 16.3.2. Weak Link Definition 1711 A link is considered a weak link when information is available from a 1712 lower layer, indicating that the link falls below an acceptable 1713 threshold according to that lower layer specification. For IEEE 1714 802.15.4, for example, this can be derived from the Link Quality 1715 Indicator. 1717 Otherwise, if such information is not available from a lower layer, a 1718 link is never considered a Weak Link. 1720 16.3.3. Required TLVs 1722 This metric requires no TLVs. 1724 16.3.4. The <= Comparison Operator 1726 Let (HC, WL) be the pair (hop-count, weak-links) received in one RREQ 1727 or RREP, and let (HC', WL') be the pair (hop-count, weak-links) 1728 received in another RREQ or RREP. The comparison operator <= is then 1729 defined as: 1731 (HC,WL) <= (HC',WL') if and only if: 1733 WL < WL'; OR 1734 WL == WL' AND HC <= HC' 1736 17. Security Considerations 1738 Currently, this protocol does not specify any special security 1739 measures. As a reactive routing protocol, this protocol is a 1740 potential target for various attacks. Various possible 1741 vulnerabilities are discussed in this section. 1743 By way of (i) enabling inclusion of TLVs and (ii) permitting that 1744 LOADng recognizes external reasons for rejecting RREQ, RREP, RREP_ACK 1745 and RERR messages, development of security measures, appropriate for 1746 a given deployment, is however supported. This architecture is a 1747 result of the observation that with respect to security in LOADng 1748 routed networks, "one size rarely fits all". This, as LOADng 1749 deployment domains have varying security requirements ranging from 1750 "unbreakable" to "virtually none", depending on, e.g., physical 1751 access to the network, or on security available on other layers. The 1752 virtue of this approach is that LOADng routing protocol 1753 specifications (and implementations) can remain "generic", with 1754 extensions providing proper deployment-domain specific security 1755 mechanisms. 1757 17.1. Confidentiality 1759 This protocol floods Route Requests (RREQs) to all the LOADng routers 1760 in the network, when there is traffic to deliver to a given 1761 destination. Hence, if used in an unprotected network (such as an 1762 unprotected wireless network): 1764 o Part of the network topology is revealed to anyone who listens, 1765 specifically (i) the identity (and existence) of the source LOADng 1766 router; (ii) the identity of the destination; and (iii) the fact 1767 that a path exists between the source LOADng router and the LOADng 1768 router from which the RREQ was received. 1770 o The network traffic patterns are revealed to anyone who listens to 1771 the LOADng control traffic, specifically which pairs of devices 1772 communicate. If, for example, a majority of traffic originates 1773 from or terminates in a specific LOADng router, this may indicate 1774 that this LOADng router has a central role in the network. 1776 This protocol also unicasts Route Replies (RREPs) from the 1777 destination of an RREQ to the originator of that same RREQ. Hence, 1778 if used in an unprotected network (such as an unprotected wireless 1779 network): 1781 o Part of the network topology is revealed to anyone who is near or 1782 on the unicast path of the RREP (such as within radio range of 1783 LOADng routers on the unicast path in an unprotected wireless 1784 network), specifically that a path from the originator (of the 1785 RREP) to the destination (of the RREP) exists. 1787 Finally, this protocol unicasts Route Errors (RERRs) when an 1788 intermediate router detects that the path from a source to a 1789 destination is no longer available. Hence, if used in an unprotected 1790 network (such as an unprotected wireless network): 1792 o A disruption of the network topology is revealed to anyone who is 1793 near or on the unicast path of the RERR (such as within radio 1794 range of LOADng routers on the unicast path in an unprotected 1795 wireless network), specifically that a path from the originator 1796 (of the RERR) to the destination (of the RERR) has been disrupted. 1798 This protocol signaling behavior enables, for example, an attacker to 1799 identify central devices in the network (by monitoring RREQs) so as 1800 to target an attack, and (by way of monitoring RERRs) to measure the 1801 success of an attack. 1803 17.2. Integrity 1805 A LOADng router injects topological information into the network by 1806 way of transmitting RREQ and RREP messages, and removes installed 1807 topological information by way of transmitting RERR messages. If 1808 some routers for some reason, malice or malfunction, inject invalid 1809 control traffic, network integrity may be compromised. Therefore, 1810 message authentication is recommended. 1812 Different such situations may occur, for instance: 1814 1. A router generates RREQ messages, pretending to be another 1815 router; 1817 2. A router generates RREP messages, pretending to be another 1818 router; 1820 3. A router generates RERR messages, pretending to be another 1821 router; 1823 4. A router generates RERR messages, indicating that a link on a 1824 path to a destination is broken; 1826 5. A router forwards altered control messages; 1828 6. A router does not forward control messages; 1830 7. A router forwards RREPs and RREQs, but does not forward unicast 1831 data traffic; 1833 8. A router "replays" previously recorded control messages from 1834 another router. 1836 Authentication of the originator LOADng router for control messages 1837 (for situations 1, 2 and 3) and on individual links announced in the 1838 control message (for situation 2 and 4) may be used as a 1839 countermeasure. However, to prevent routers from repeating old (and 1840 correctly authenticated) information (situation 8), temporal 1841 information is required, requiring a router to positively identify 1842 such a delayed message. 1844 In general, integrity check values and other required security 1845 information may be transmitted as a separate Message Type, or 1846 signatures and security information may be transmitted within the 1847 control messages, using the TLV mechanism. Either option permits 1848 that "secured" and "unsecured" routers can coexist in the same 1849 network, if desired. 1851 Specifically, if LOADng is used on the IP layer, the authenticity of 1852 entire control messages can be established through employing IPsec 1853 authentication headers, whereas authenticity of individual links 1854 (situations 2 and 4) require additional security information to be 1855 distributed. 1857 17.3. Channel Jamming and State Explosion 1859 A reactive protocol, LOADng control messages are generated in 1860 response to network events. For RREQs, such an event is that a data 1861 packet is present in a router which does not have a route to the 1862 destination of the data packet, or that the router receives an RERR 1863 message, invalidating a route. For RREPs, such an event is receipt 1864 of an RREQ corresponding to a destination owned by the LOADng router. 1865 A router, forwarding an RREQ or an RREP records state, for the 1866 reverse and forward routes, respectively. If some routers for some 1867 reason, malice or malfunction, generates excessive RREQ, RREP or 1868 RERRs, otherwise correctly functioning LOADng routers may fall victim 1869 to either "indirect jamming" (being "tricked" into generating 1870 excessive control traffic) or an explosion in the state necessary for 1871 maintaining protocol state (potentially, exhausting the available 1872 memory resources). 1874 Different such situations may occur, for instance: 1876 1. A router, within a short time, generates RREQs to an excessive 1877 amount of destinations in the network (possibly all destinations, 1878 possibly even destinations not present in the network), causing 1879 intermediate routers to allocate state for the forward routes. 1881 2. A router generates excessively frequent RREQs to the same 1882 (existing) destination, causing the corresponding LOADng router 1883 to generate excessive RREPs. 1885 3. A router generates RERRs for a destination to the source LOADng 1886 router for traffic to that destination, causing that LOADng 1887 router to flood renewed RREQs. 1889 For situation 1, the state required for recording forward and/or 1890 reverse routes may exceed the memory available in the intermediate 1891 LOADng routers - to the detriment of being able of recording state 1892 for other routes. This, in particular, if a LOADng router generates 1893 RREQs for destinations "not present in the network". 1895 A router which, within a short time, generates RREPs to an excessive 1896 amount of destinations in the network (possibly all destinations, 1897 possibly even destinations not present in the network), will not have 1898 the same network-wide effect: an intermediate router receiving an 1899 RREP for a destination for which no reverse route exists will neither 1900 attempt forwarding the RREP nor allocate state for the forward route. 1902 For situations 1, 2, and 3, a possible countermeasure is to rate- 1903 limit the number of control messages that a LOADng router forwards on 1904 behalf of another LOADng router. Such a rate limit should take into 1905 consideration the expected normal traffic for a given LOADng 1906 deployment. Authentication may furthermore be used so as to prohibit 1907 a LOADng router from forwarding control traffic from any non- 1908 authenticated router (with the assumption being that an authenticated 1909 router is not expected to exhibit such rogue behavior). 1911 17.4. Interaction with External Routing Domains 1913 This protocol does provide a basic mechanism for a LOADng router to 1914 be able to discover routes to external routing domains: a LOADng 1915 router configured to "own" a given set of addresses will respond to 1916 RREQs for destinations with these addresses, and can - by whatever 1917 protocols governing the routing domain wherein these addresses exist 1918 - provide paths to these addresses. 1920 When operating routers connecting a LOADng domain to an external 1921 routing domain, destinations inside the LOADng domain can be injected 1922 into the external domain, if the routing protocol governing that 1923 domain so permits. Care MUST be taken to not allow potentially 1924 insecure and untrustworthy information to be injected into the 1925 external domain. 1927 In case LOADng is used on the IP layer, a RECOMMENDED way of 1928 extending connectivity from an external routing domain to a LOADng 1929 routed domain is to assign an IP prefix (under the authority of the 1930 routers/gateways connecting the LOADng routing domain with the 1931 external routing domain) exclusively to that LOADng routing domain, 1932 and to statically configure gateways to advertise routes for that 1933 prefix into the external domain. Within the LOADng domain, gateways 1934 SHOULD only generate RREPs for destinations which are not part of 1935 that prefix; this is in particularly important if a gateway otherwise 1936 provides connectivity to "a default route". 1938 18. IANA Considerations 1940 18.1. Multicast Addresses 1942 IANA is requested to allocate LL-LLN-ROUTERS well-known, link-scoped 1943 multicast addresses for both IPv4 and IPv6. 1945 18.2. Packet Types 1947 IANA is requested to create a new registry for packet types, with 1948 initial assignments and allocation policies as specified in Table 1. 1950 +---------+-------------------------------------+-------------------+ 1951 | Type | Description | Allocation Policy | 1952 +---------+-------------------------------------+-------------------+ 1953 | 0 | Route Request (RREQ) | | 1954 | 1 | Route Reply (RREP) | | 1955 | 2 | Route Error (RERR) | | 1956 | 3 | Route Reply Acknowledgment | | 1957 | | (RREP_ACK) | | 1958 | 4-251 | Unassigned | Expert Review | 1959 | 252-255 | Unassigned | Experimental Use | 1960 +---------+-------------------------------------+-------------------+ 1962 Table 1: Packet Types 1964 18.3. TLV Types 1966 IANA is requested to create a new registry for TLV types, with 1967 initial assignments and allocation policies as specified in Table 2. 1969 +---------+-------------+-------------------+ 1970 | Type | Description | Allocation Policy | 1971 +---------+-------------+-------------------+ 1972 | 0-251 | Unassigned | Expert Review | 1973 | 252-255 | Unassigned | Experimental Use | 1974 +---------+-------------+-------------------+ 1976 Table 2: TLV Types 1978 18.4. Metrics 1980 IANA is requested to create a new registry for Metrics, with initial 1981 assignments and allocation policies as specified in Table 3. 1983 +---------+----------------------------------------+----------------+ 1984 | Code | Description | Allocation | 1985 | | | Policy | 1986 +---------+----------------------------------------+----------------+ 1987 | 0 | Hop Count While Avoiding Weak Links | | 1988 | | (Section 16) | | 1989 | 1-251 | Unassigned | Expert Review | 1990 | 252-255 | Unassigned | Experimental | 1991 | | | Use | 1992 +---------+----------------------------------------+----------------+ 1994 Table 3: Metrics 1996 When assigning a new Metric, the specification requesting that 1997 assignment MUST specify the way in which each LOADng Router 1998 calculates the field and TLVs for calculating the route 1999 cost in RREQs and RREPs, as well as the criteria for incrementing the 2000 field in RREQs and RREPs. The specification MUST also 2001 specify the comparison operation '<=' for determining, from among two 2002 RREQs (or RREPs) for the same destination, which message represents 2003 the shortest route; note that this comparison operation SHOULD 2004 involve the field and MAY use other information such as 2005 or content of specific TLV types included in the RREQ or 2006 RREP. 2008 18.5. Error Codes 2010 IANA is requested to create a new registry for Error Codes, with 2011 initial assignments and allocation policies as specified in Table 4. 2013 +---------+--------------------+-------------------+ 2014 | Code | Description | Allocation Policy | 2015 +---------+--------------------+-------------------+ 2016 | 0 | No available route | | 2017 | 1-251 | Unassigned | Expert Review | 2018 | 252-255 | Unassigned | Experimental Use | 2019 +---------+--------------------+-------------------+ 2021 Table 4: Error Codes 2023 19. Contributors 2025 This specification is the result of the joint efforts of the 2026 following contributors -- listed alphabetically. 2028 o Alberto Camacho, LIX, France, 2029 o Thomas Heide Clausen, LIX, France, 2031 o Axel Colin de Verdiere, LIX, France, 2033 o Kenneth Garey, Maxim Integrated Products, USA, 2034 2036 o Ulrich Herberg, Fujitsu Laboratories of America, USA 2037 2039 o Yuichi Igarashi, Hitachi Ltd, Yokohama Research Laboratory, Japan, 2040 2042 o Afshin Niktash, Maxim Integrated Products, USA, 2043 2045 o Hiroki Satoh, Hitachi Ltd, Yokohama Research Laboratory, Japan, 2046 2048 o Jiazi Yi, LIX, France, 2050 20. Acknowledgments 2052 The authors would like to acknowledge the team behind AODV, specified 2053 in RFC3561 for their contributions. The authors would also like to 2054 acknowledge the efforts of K. Kim (picosNet Corp/Ajou University), S. 2055 Daniel Park (Samsung Electronics), G. Montenegro (Microsoft 2056 Corporation), S. Yoo (Ajou University) and N. Kushalnagar (Intel 2057 Corp.) for their work on an initial version of a specification, from 2058 which this protocol is derived. 2060 21. References 2062 21.1. Normative References 2064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2065 Requirement Levels", RFC 2119, BCP 14, March 1997. 2067 21.2. Informative References 2069 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 2070 Demand Distance Vector (AODV) Routing", RFC 3561, 2071 July 2003. 2073 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. 2074 Culler, "Transmission of IPv6 Packets over IEEE 2075 802.15.4 Networks", RFC 4944, September 2007. 2077 [RFC6206] Levis, P., Clausen, T., Gnawali, O., and J. Ko, "The 2078 Trickle Algorithm", RFC 6206, March 2011. 2080 [SMF] Macker, J., "Simplified Multicast Forwarding", 2081 draft-ietf-manet-smf-14 (work in progress), March 2012. 2083 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2084 Considerations in Mobile Ad Hoc Networks (MANETs)", 2085 RFC 5148, February 2008. 2087 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2088 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2089 September 2007. 2091 [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The 2092 Protocols", 1994. 2094 [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC1/SC22/ 2095 WG15, "Single UNIX Specification, Version 3, 2004 2096 Edition", April 2004. 2098 Appendix A. LOADng Control Packet Illustrations 2100 This section presents example packets following this specification. 2102 A.1. RREQ 2104 This figure depicts the format of a sample packet with an RREQ 2105 message using IPv4 addresses. The packet is as follows: 2107 0 1 2 3 2108 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 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 | RREQ | 3 | 0 | Sequence number | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Metric | 0 | WL | Hop-count | Originator ...| 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 |... address (IPv4) | Destination...| 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |... address (IPv4) | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 A.2. RREP 2121 This figure depicts the format of a sample packet with an RREP 2122 message using IPv4 addresses, with the ackrequired flag set. The 2123 packet is as follows: 2125 0 1 2 3 2126 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 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | RREQ | 3 | 0 | Sequence number | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | Metric |1| 0 | WL | Hop-count | Originator ...| 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 |... address (IPv4) | Destination...| 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 |... address (IPv4) | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 A.3. RREP_ACK 2139 This figure depicts the format of a sample packet with an RREP_ACK 2140 message using IPv4 addresses, as follows: 2142 0 1 2 3 2143 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 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | R_ACK | 3 | 0 | Sequence number | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Originator address (IPv4) | 2148 +-+-+--+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 A.4. RERR 2152 This figure depicts the format of a sample packet with an RERR 2153 message using IPv4 addresses, as follows: 2155 0 1 2 3 2156 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 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | RERR | 3 | 0 | Error code | Originator ...| 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 |... address (IPv4) | Destination...| 2161 +-+-+--+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 |... address (IPv4) | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 Authors' Addresses 2167 Thomas Heide Clausen 2168 LIX, Ecole Polytechnique 2170 Phone: +33 6 6058 9349 2171 EMail: T.Clausen@computer.org 2172 URI: http://www.ThomasClausen.org/ 2174 Axel Colin de Verdiere 2175 LIX, Ecole Polytechnique 2177 Phone: +33 6 1264 7119 2178 EMail: axel@axelcdv.com 2179 URI: http://www.axelcdv.com/ 2181 Jiazi Yi 2182 LIX, Ecole Polytechnique 2184 Phone: +33 1 6933 4031 2185 EMail: jiazi@jiaziyi.com 2186 URI: http://www.jiaziyi.com/ 2188 Afshin Niktash 2189 Maxim Integrated Products 2191 Phone: +1 94 9450 1692 2192 EMail: afshin.niktash@maxim-ic.com 2193 URI: http://www.Maxim-ic.com/ 2195 Yuichi Igarashi 2196 Hitachi, Ltd., Yokohama Research Laboratory 2198 Phone: +81 45 860 3083 2199 EMail: yuichi.igarashi.hb@hitachi.com 2200 URI: http://www.hitachi.com/ 2201 Hiroki Satoh 2202 Hitachi, Ltd., Yokohama Research Laboratory 2204 Phone: +81 44 959 0205 2205 EMail: hiroki.satoh.yj@hitachi.com 2206 URI: http://www.hitachi.com/ 2208 Ulrich Herberg 2209 Fujitsu Laboratories of America 2211 Phone: +1 408 530 4528 2212 EMail: ulrich@herberg.name 2213 URI: http://www.herberg.name/ 2215 Cedric Lavenu 2216 EDF R&D 2218 Phone: +33 1 4765 2729 2219 EMail: cedric-2.lavenu@edf.fr 2220 URI: http://www.edf.fr/ 2222 Thierry Lys 2223 ERDF 2225 Phone: +33 1 8197 6777 2226 EMail: thierry.lys@erdfdistribution.fr 2227 URI: http://www.erdfdistribution.fr/