idnits 2.17.1 draft-clausen-lln-loadng-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 651 has weird spacing: '...-length is an...' == Line 656 has weird spacing: '...seq-num is an...' == Line 660 has weird spacing: '...ic-type is an...' == Line 663 has weird spacing: '...-metric is a ...' == Line 668 has weird spacing: '...p-count is an...' == (30 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: +-------------------+-------------------+---------------------------+ | RREQ Element | RFC5444-Element | Considerations | +-------------------+-------------------+---------------------------+ | RREQ.addr-length | | Supports addresses from | | | | 1-16 octets | | RREQ.seq-num | | 16 bits, hence MAXVALUE | | | | (Section 8) is 65535. | | | | MUST be included | | RREQ.metric-type | METRIC Message | Encoded by way of the | | | TLV | Type-Extension of a | | | | Message-Type-specific | | | | Message TLV of type | | | | METRIC, defined in | | | | Table 8. A LOADng Router | | | | generating an RREQ (as | | | | specified in | | | | Section 12.1) when using | | | | the HOP_COUNT metric, | | | | MUST NOT add the METRIC | | | | Message TLV to the RREQ | | | | (in order to reduce | | | | overhead, as the hop | | | | count value is already | | | | encoded in | | | | RREQ.hop-count). LOADng | | | | Routers receiving an RREQ | | | | without METRIC Message | | | | TLV assume that | | | | RREQ.metric-type is | | | | HOP_COUNT, and MUST not | | | | add the METRIC Message | | | | TLV when forwarding the | | | | message. Otherwise, | | | | exactly one METRIC TLV | | | | MUST be included in each | | | | RREQ message. | | RREQ.route-metric | METRIC Message | Encoded as the value | | | TLV value | field of the METRIC TLV. | | | | (LOADng Routers | | | | generating RREQs when | | | | using the HOP_COUNT | | | | metric do not need need | | | | to add the METRIC Message | | | | TLV, as specified above | | | | for the RREQ.metric-type | | | | field.) | | RREQ.hop-limit | | 8 bits. MUST be included | | | | in an RREQ message | | RREQ.hop-count | | 8 bits, hence | | | | MAX_HOP_COUNT is 255. | | | | MUST be included in an | | | | RREQ message. | | RREQ.originator | | MUST be included in an | | | | RREQ message. | | RREQ.destination | Address in | Encoded by way of an | | | Address-Block | address in an address | | | w/TLV | block, with which a | | | | Message-Type-specific | | | | Address Block TLV of type | | | | ADDR-TYPE and with | | | | Type-Extension | | | | DESTINATION is | | | | associated, defined in | | | | Table 9. An RREQ MUST | | | | contain exactly one | | | | address with a TLV of | | | | type ADDR-TYPE and with | | | | Type-Extension | | | | DESTINATION associated. | +-------------------+-------------------+---------------------------+ == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: +-------------------+-------------------+---------------------------+ | RREP Element | RFC5444-Element | Considerations | +-------------------+-------------------+---------------------------+ | RREP.addr-length | | Supports addresses from | | | | 1-16 octets | | RREP.seq-num | | 16 bits, hence MAXVALUE | | | | (Section 8) is 65535. | | | | MUST be included | | RREP.metric-type | METRIC Message | Encoded by way of the | | | TLV | Type-Extension of a | | | | Message-Type-specific | | | | Message TLV of type | | | | METRIC, defined in | | | | Table 12. A LOADng | | | | Router generating an RREP | | | | (as specified in | | | | Section 13.1) when using | | | | the HOP_COUNT metric, | | | | MUST NOT add the METRIC | | | | Message TLV to the RREP | | | | (in order to reduce | | | | overhead, as the hop | | | | count value is already | | | | encoded in | | | | RREP.hop-count). LOADng | | | | Routers receiving an RREP | | | | without METRIC Message | | | | TLV assume that | | | | RREP.metric-type is | | | | HOP_COUNT, and MUST not | | | | add the METRIC Message | | | | TLV when forwarding the | | | | message. Otherwise, | | | | exactly one METRIC TLV | | | | MUST be included in each | | | | RREP message. | | RREP.route-metric | METRIC Message | Encoded as the value | | | TLV value | field of the METRIC TLV. | | | | (LOADng Routers | | | | generating RREPs when | | | | using the HOP_COUNT | | | | metric do not need need | | | | to add the METRIC Message | | | | TLV, as specified above | | | | for the RREP.metric-type | | | | field.) | | RREP.ackrequired | FLAGS Message TLV | Encoded by way of a | | | | Message-Type-specific | | | | Message TLV of type | | | | FLAGS, defined in | | | | Table 13. A TLV of type | | | | FLAGS MUST always be | | | | included in an RREP | | | | message. | | RREP.hop-limit | | 8 bits. MUST be included | | | | in an RREQ message | | RREP.hop-count | | 8 bits, hence | | | | MAX_HOP_COUNT is 255. | | | | MUST be included in an | | | | RREP message. | | RREP.originator | | MUST be included in an | | | | RREP message. | | RREP.destination | Address in | Encoded by way of an | | | Address-Block | address in an address | | | w/TLV | block, with which a | | | | Message-Type-specific | | | | Address Block TLV of type | | | | ADDR-TYPE and with | | | | Type-Extension | | | | DESTINATION is | | | | associated, defined in | | | | Table 14. An RREP MUST | | | | contain exactly one | | | | address with a TLV of | | | | type ADDR-TYPE and with | | | | Type-Extension | | | | DESTINATION associated. | +-------------------+-------------------+---------------------------+ -- The document date (January 7, 2013) is 4099 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: 1 error (**), 0 flaws (~~), 9 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: July 11, 2013 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 C. Perkins 19 Futurewei Inc. 20 J. Dean 21 Naval Research Laboratory 22 January 7, 2013 24 The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next 25 Generation (LOADng) 26 draft-clausen-lln-loadng-07 28 Abstract 30 This document describes the Lightweight Ad hoc On-Demand - Next 31 Generation (LOADng) distance vector routing protocol, a reactive 32 routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. This document may not be modified, 38 and derivative works of it may not be created, except to format it 39 for publication as an RFC or to translate it into languages other 40 than English. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 11, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 6 73 2.1. Message and Message Field Notation . . . . . . . . . . . . 6 74 2.2. Variable Notation . . . . . . . . . . . . . . . . . . . . 7 75 2.3. Other Notation . . . . . . . . . . . . . . . . . . . . . . 7 76 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 77 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 78 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9 79 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2. LOADng Routers and LOADng Interfaces . . . . . . . . . . . 10 81 4.3. Information Base Overview . . . . . . . . . . . . . . . . 11 82 4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . . 12 83 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 13 85 5.2. Router Parameters . . . . . . . . . . . . . . . . . . . . 13 86 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 14 87 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6. Protocol Message Content . . . . . . . . . . . . . . . . . . . 15 89 6.1. Route Request (RREQ) Messages . . . . . . . . . . . . . . 15 90 6.2. Route Reply (RREP) Messages . . . . . . . . . . . . . . . 16 91 6.3. Route Reply Acknowledgement (RREP_ACK) Messages . . . . . 17 92 6.4. Route Error (RERR) Messages . . . . . . . . . . . . . . . 18 93 7. Information Base . . . . . . . . . . . . . . . . . . . . . . . 19 94 7.1. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 19 95 7.2. Local Interface Set . . . . . . . . . . . . . . . . . . . 20 96 7.3. Blacklisted Neighbor Set . . . . . . . . . . . . . . . . . 20 97 7.4. Destination Address Set . . . . . . . . . . . . . . . . . 21 98 7.5. Pending Acknowledgment Set . . . . . . . . . . . . . . . . 21 99 8. LOADng Router Sequence Numbers . . . . . . . . . . . . . . . . 22 100 9. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 22 101 10. Unidirectional Link Handling . . . . . . . . . . . . . . . . . 24 102 10.1. Blacklist Usage . . . . . . . . . . . . . . . . . . . . . 24 103 11. Common Rules for RREQ and RREP Messages . . . . . . . . . . . 25 104 11.1. Identifying Invalid RREQ or RREP Messages . . . . . . . . 26 105 11.2. RREQ and RREP Message Processing . . . . . . . . . . . . . 26 106 12. Route Requests (RREQs) . . . . . . . . . . . . . . . . . . . . 30 107 12.1. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 30 108 12.2. RREQ Processing . . . . . . . . . . . . . . . . . . . . . 31 109 12.3. RREQ Forwarding . . . . . . . . . . . . . . . . . . . . . 31 110 12.4. RREQ Transmission . . . . . . . . . . . . . . . . . . . . 32 111 13. Route Replies (RREPs) . . . . . . . . . . . . . . . . . . . . 32 112 13.1. RREP Generation . . . . . . . . . . . . . . . . . . . . . 32 113 13.2. RREP Processing . . . . . . . . . . . . . . . . . . . . . 33 114 13.3. RREP Forwarding . . . . . . . . . . . . . . . . . . . . . 34 115 13.4. RREP Transmission . . . . . . . . . . . . . . . . . . . . 34 116 14. Route Errors (RERRs) . . . . . . . . . . . . . . . . . . . . . 35 117 14.1. Identifying Invalid RERR Messages . . . . . . . . . . . . 36 118 14.2. RERR Generation . . . . . . . . . . . . . . . . . . . . . 36 119 14.3. RERR Processing . . . . . . . . . . . . . . . . . . . . . 37 120 14.4. RERR Forwarding . . . . . . . . . . . . . . . . . . . . . 38 121 14.5. RERR Transmission . . . . . . . . . . . . . . . . . . . . 38 122 15. Route Reply Acknowledgments (RREP_ACKs) . . . . . . . . . . . 39 123 15.1. Identifying Invalid RREP_ACK Messages . . . . . . . . . . 39 124 15.2. RREP_ACK Generation . . . . . . . . . . . . . . . . . . . 39 125 15.3. RREP_ACK Processing . . . . . . . . . . . . . . . . . . . 40 126 15.4. RREP_ACK Forwarding . . . . . . . . . . . . . . . . . . . 41 127 15.5. RREP_ACK Transmission . . . . . . . . . . . . . . . . . . 41 128 16. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 129 16.1. Specifying New Metrics . . . . . . . . . . . . . . . . . . 41 130 17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 131 17.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 42 132 17.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 43 133 17.3. Channel Jamming and State Explosion . . . . . . . . . . . 44 134 17.4. Interaction with External Routing Domains . . . . . . . . 45 135 18. LOADng Specific IANA Considerations . . . . . . . . . . . . . 45 136 18.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 45 137 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 138 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 139 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 140 21.1. Normative References . . . . . . . . . . . . . . . . . . . 47 141 21.2. Informative References . . . . . . . . . . . . . . . . . . 47 142 Appendix A. LOADng Control Messages using RFC5444 . . . . . . . . 48 143 A.1. RREQ-Specific Message Encoding Considerations . . . . . . 48 144 A.2. RREP-Specific Message Encoding Considerations . . . . . . 50 145 A.3. RREP_ACK Message Encoding . . . . . . . . . . . . . . . . 52 146 A.4. RERR Message Encoding . . . . . . . . . . . . . . . . . . 53 147 A.5. RFC5444-Specific IANA Considerations . . . . . . . . . . . 54 148 A.5.1. Expert Review: Evaluation Guidelines . . . . . . . . . 54 149 A.5.2. Message Types . . . . . . . . . . . . . . . . . . . . 55 150 A.6. RREQ Message-Type-Specific TLV Type Registries . . . . . . 55 151 A.7. RREP Message-Type-Specific TLV Type Registries . . . . . . 56 152 A.8. RREP_ACK Message-Type-Specific TLV Type Registries . . . . 59 153 A.9. RERR Message-Type-Specific TLV Type Registries . . . . . . 59 154 Appendix B. LOADng Control Packet Illustrations . . . . . . . . . 60 155 B.1. RREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 156 B.2. RREP . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 157 B.3. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 63 158 B.4. RERR . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 160 1. Introduction 162 The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - 163 Next Generation (LOADng) is a routing protocol, derived from AODV 164 [RFC3561] and extended for use in Mobile Ad hoc NETworks (MANETs). 165 As a reactive protocol, the basic operations of LOADng include 166 generation of Route Requests (RREQs) by a LOADng Router (originator) 167 for when discovering a route to a destination, forwarding of such 168 RREQs until they reach the destination LOADng Router, generation of 169 Route Replies (RREPs) upon receipt of an RREQ by the indicated 170 destination, and unicast hop-by-hop forwarding of these RREPs towards 171 the originator. If a route is detected broken, i.e., if forwarding 172 of a data packet to the recorded next hop on the route towards the 173 intended destination is detected to fail, a Route Error (RERR) 174 message is returned to the originator of that data packet to inform 175 the originator about the route breakage. 177 Compared to [RFC3561], LOADng is simplified as follows: 179 o Only the destination is permitted to respond to an RREQ; 180 intermediate LOADng Routers are explicitly prohibited from 181 responding to RREQs, even if they may have active routes to the 182 sought destination, and RREQ/RREP messages generated by a given 183 LOADng Router share a single unique, monotonically increasing 184 sequence number. This also eliminates Gratuitous RREPs while 185 ensuring loop freedom. The rationale for this simplification is 186 reduced complexity of protocol operation and reduced message 187 sizes. 189 o A LOADng Router does not maintain a precursor list, thus when 190 forwarding of a data packet to the recorded next hop on the route 191 to the destination fails, an RERR is sent only to the originator 192 of that data packet. The rationale for this simplification is an 193 assumption that few overlapping routes are in use concurrently in 194 a given network. 196 Compared to [RFC3561], LOADng is extended as follows: 198 o Optimized flooding is supported, reducing the overhead incurred by 199 RREQ generation and flooding. If no optimized flooding operation 200 is specified for a given deployment, classical flooding is used by 201 default. 203 o Different address lengths are supported - from full 16 octet IPv6 204 addresses over 8 octet EUI64 addresss [EUI64], 6 octet MAC 205 addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet 206 addresses such as [RFC4944]. The only requirement is, that within 207 a given routing domain, all addresses are of the same address 208 length. 210 o Control messages are carried by way of the Generalized MANET 211 Packet/Message Format [RFC5444]. 213 o Using [RFC5444], control messages can include TLV (Type-Length- 214 Value) elements, permitting protocol extensions to be developed. 216 o LOADng supports routing using arbitrary additive metrics, which 217 can be specified as extensions to this protocol. 219 2. Terminology and Notation 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in 224 [RFC2119]. 226 Additionally, this document uses the notations in Section 2.1, 227 Section 2.2, and Section 2.3 and the terminology defined in 228 Section 2.4. 230 2.1. Message and Message Field Notation 232 LOADng Routers generate and process messages, each of which has a 233 number of distinct fields. For describing the protocol operation, 234 specifically the generation and processing of such messages, the 235 following notation is employed: 237 MsgType.field 239 where: 241 MsgType - is the type of message (e.g., RREQ or RREP); 243 field - is the field in the message (e.g., originator). 245 The different messages, their fields and their meaning are described 246 in Section 6. The encoding of messages for transmission by way of 247 [RFC5444] packets/messages is described in Appendix A, and Appendix B 248 illustrates the bit layout of LOADng control messages. 250 The motivation for separating the high-level messages and their 251 content from the low-level encoding and frame format for transmission 252 is to allow discussions of the protocol logic to be separated from 253 the message encoding and frame format - and, to support different 254 frame formats. 256 2.2. Variable Notation 258 Variables are introduced into the specification solely as a means to 259 clarify the description. The following notation is used: 261 MsgType.field - If "field" is a field in the message MsgType, then 262 MsgType.field is also used to represent the value of that field. 264 bar - A variable (not prepended by MsgType), usually obtained 265 through calculations based on the value(s) of element(s). 267 2.3. Other Notation 269 This document uses the following additional notational conventions: 271 a := b An assignment operator, whereby the left side (a) is 272 assigned the value of the right side (b). 274 c = d A comparison operator, returning TRUE if the value of the 275 left side (c) is equal to the value of the right side (d). 277 2.4. Terminology 279 This document uses the following terminology: 281 LOADng Router - A router that implements this routing protocol. A 282 LOADng Router is equipped with at least one, and possibly more, 283 LOADng Interfaces. 285 LOADng Interface - A LOADng Router's attachment to a communications 286 medium, over which it receives and generates control messages, 287 according to this specification. A LOADng Interface is assigned 288 one or more addresses. 290 Link - A link between two LOADng Interfaces exists if either can 291 receive control messages, according to this specification, from 292 the other. 294 Message - The fundamental entity carrying protocol information, in 295 the form of address objects and TLVs. 297 Link Metric - The cost (weight) of a link between a pair of LOADng 298 Interfaces. 300 Route Metric - The sum of the Link Metrics for the links that an 301 RREQ or RREP has crossed. 303 3. Applicability Statement 305 LOADng is a reactive MANET protocol, i.e., routes are discovered only 306 when a data packet is sent by a router (e.g., on behalf of an 307 attached host), and when the router has no route for this 308 destination. In that case, the router floods Route Requests (RREQ) 309 throughout the network for discovering the destination. Reactive 310 protocols require state only for the routes currently in use, 311 contrary to proactive protocols, which periodically send control 312 traffic and store routes to all destinations in the network. As 313 MANETs are often operated on wireless channels, flooding RREQs may 314 lead to frame collisions and therefore data loss. Moreover, each 315 transmission on a network interface consumes energy, reducing the 316 life-time of battery-driven routers. Consequently, in order to 317 reduce the amount of control traffic, LOADng (and in general reactive 318 protocols) are most suitable under the following constraints: 320 o Few concurrent traffic flows in the network (i.e., traffic flows 321 only between few sources and destinations); 323 o Little data traffic overall, and therefore the traffic load from 324 periodic signaling (for proactive protocols) is greater than the 325 traffic load from flooding RREQs (for reactive protocols); 327 o State requirements on the router are very stringent, i.e., it is 328 beneficial to store only few routes on a router. 330 In these specific use cases, reactive MANET protocols have shown to 331 be beneficial, and may be preferable over the more general use case 332 of proactive MANET protocols. 334 Specifically, the applicability of LOADng is determined by its 335 characteristics, which are that this protocol: 337 o Is a reactive routing protocol for Mobile Ad hoc NETworks 338 (MANETs). 340 o Is designed to work in networks with dynamic topology in which the 341 links may be lossy due to collisions, channel instability, or 342 movement of routers. 344 o Supports the use of optimized flooding for RREQs. 346 o Enables any LOADng Router to discover bi-directional routes to 347 destinations in the routing domain, i.e., to any other LOADng 348 Router, as well as hosts or networks attached to that LOADng 349 Router, in the same routing domain. 351 o Supports addresses of any length, from 16 octets to a single 352 octet. 354 o Is layer-agnostic, i.e., may be used at layer 3 as a "route over" 355 routing protocol, or at layer 2 as a "mesh under" routing 356 protocol. 358 o Supports per-destination route maintenance; if a destination 359 becomes unreachable, rediscovery of that single (bi-directional) 360 route is performed, without need for global topology 361 recalculation. 363 4. Protocol Overview and Functioning 365 The objective of this protocol is for each LOADng Router to, 366 independently: 368 o Discover a bi-directional route to any destination in the network. 370 o Establish a route only when there is data traffic to be sent along 371 that route. 373 o Maintain a route only for as long as there is data traffic being 374 sent along that route. 376 o Generate control traffic based on network events only: when a new 377 route is required, or when an active route is detected broken. 378 Specifically, this protocol does not require periodic signaling. 380 4.1. Overview 382 These objectives are achieved, for each LOADng Router, by performing 383 the following tasks: 385 o When having a data packet to deliver to a destination, for which 386 no tuple in the routing set exists and where the data packet 387 source is local to that LOADng Router (i.e., is an address in the 388 Local Interface Set or Destination Address Set of that LOADng 389 Router), generate a Route Request (RREQ) encoding the destination 390 address, and transmit this RREQ over all of its LOADng Interfaces. 392 o Upon receiving an RREQ, insert or refresh a tuple in the Routing 393 Set, recording a route towards the originator address from the 394 RREQ, as well as to the neighbor LOADng Router from which the RREQ 395 was received. This will install the Reverse Route (towards the 396 originator address from the RREQ). 398 o Upon receiving an RREQ, inspect the indicated destination address: 400 * If that address is an address in the Destination Address Set or 401 in the Local Interface Set of the LOADng Router, generate a 402 Route Reply (RREP), which is unicast in a hop-by-hop fashion 403 along the installed Reverse Route. 405 * If that address is not an address in the Destination Address 406 Set or in the Local Interface Set of the LOADng Router, 407 consider the RREQ as a candidate for forwarding. 409 o When an RREQ is considered a candidate for forwarding, retransmit 410 it according to the flooding operation, specified for the network. 412 o Upon receiving an RREP, insert or refresh a tuple in the Routing 413 Set, recording a route towards the originator address from the 414 RREP, as well as to the neighbor LOADng Router, from which that 415 RREP was received. This will install the Forward Route (towards 416 the originator address from the RREP). The originator address is 417 either an address from the Local Interface Set of the LOADng 418 Router, or an address from its Destination Address Set (i.e., an 419 address of a host attached to that LOADng Router). 421 o Upon receiving an RREP, forward it, as unicast, to the recorded 422 next hop along the corresponding Reverse Route until the RREP 423 reaches the LOADng Router that has the destination address from 424 the RREP in its Local Interface Set or Destination Address Set. 426 o When forwarding an RREQ or RREP, update the route metric, as 427 contained in that RREQ or RREP message. 429 A LOADng Router generating an RREQ specifies which metric type it 430 desires. Routers receiving an RREQ will process it and update route 431 metric information in the RREQ according to that metric, if they can. 432 All LOADng Routers, however, will update information in the RREQ so 433 as to be able to support a "hop-count" default metric. If a LOADng 434 Router is not able to understand the metric type, specified in an 435 RREQ, it will update the route metric value to its maximum value, so 436 as to ensure that this is indicated to the further recipients of the 437 RREQ. Once the route metric value is set to its maximum value, no 438 LOADng Router along the path towards the destination may change the 439 value. 441 4.2. LOADng Routers and LOADng Interfaces 443 A LOADng Router has a set of at least one, and possibly more, LOADng 444 Interfaces. Each LOADng Interface: 446 o Is configured with one or more addresses. 448 o Has a number of interface parameters. 450 In addition to a set of LOADng Interfaces as described above, each 451 LOADng Router: 453 o Has a number of router parameters. 455 o Has an Information Base. 457 o Generates and processes RREQ, RREP, RREP_ACK and RERR messages, 458 according to this specification. 460 4.3. Information Base Overview 462 Necessary protocol state is recorded by way of five information sets: 463 the "Routing Set", the "Local Interface Set", the "Blacklisted 464 Neighbor Set", the "Destination Address Set", and the "Pending 465 Acknowledgment Set". 467 The Routing Set contains tuples, each representing the next-hop on, 468 and the metric of, a route towards a destination address. 469 Additionally, the Routing Set records the sequence number of the last 470 message, received from the destination. This information is 471 extracted from the message (RREQ or RREP) that generated the tuple so 472 as to enable routing. The routing table is to be updated using this 473 Routing Set. (A LOADng Router may choose to use any or all 474 destination addresses in the Routing Set to update the routing table, 475 this selection is outside the scope of this specification.) 477 The Local Interface Set contains tuples, each representing a local 478 LOADng Interface of the LOADng Router. Each tuple contains a list of 479 one or more addresses of that LOADng Interface. 481 The Blacklisted Neighbor Set contains tuples representing neighbor 482 LOADng Interface addresses of a LOADng Router with which 483 unidirectional connectivity has been recently detected. 485 The Destination Address Set contains tuples representing addresses, 486 for which the LOADng Router is responsible, i.e., addresses of this 487 LOADng Router, or of hosts and networks directly attached to this 488 LOADng Router and which use it to connect to the routing domain. 489 These addresses may in particular belong to devices which do not 490 implement LOADng, and thus cannot process LOADng messages. A LOADng 491 Router provides connectivity to these addresses by generating RREPs 492 in response to RREQs directed towards them. 494 The Pending Acknowledgment Set contains tuples, representing 495 transmitted RREPs for which an RREP_ACK is expected, but where this 496 RREP_ACK has not yet been received. 498 The Routing Set, the Blacklisted Neighbor Set and the Pending 499 Acknowledgment Set are updated by this protocol. The Local Interface 500 Set and the Destination Address Set are used, but not updated by this 501 protocol. 503 4.4. Signaling Overview 505 This protocol generates and processes the following routing messages: 507 Route Request (RREQ) - Generated by a LOADng Router when it has a 508 data packet to deliver to a given destination, where the data 509 packet source is local to that LOADng Router (i.e., is an address 510 in the Local Interface Set or Destination Address Set of that 511 LOADng Router), but where it does not have an available tuple in 512 its Routing Set indicating a route to that destination. An RREQ 513 contains: 515 * The (destination) address to which a Forward Route is to be 516 discovered by way of soliciting the LOADng Router with that 517 destination address in its Local Interface Set or in its 518 Destination Address Set to generate an RREP. 520 * The (originator) address for which a Reverse Route is to be 521 installed by RREQ forwarding and processing, i.e., the source 522 address of the data packet which triggered the RREQ generation. 524 * The sequence number of the LOADng Router, generating the RREQ. 526 An RREQ is flooded through the network, according to the flooding 527 operation specified for the network. 529 Route Reply (RREP) - Generated as a response to an RREQ by the 530 LOADng Router which has the address (destination) from the RREQ in 531 its Local Interface Set or in its Destination Address Set. An RREP 532 is sent in unicast towards the originator of that RREQ. An RREP 533 contains: 535 * The (originator) address to which a Forward Route is to be 536 installed when forwarding the RREP. 538 * The (destination) address towards which the RREP is to be sent. 539 More precisely, the destination address determines the unicast 540 route which the RREP follows. 542 * The sequence number of the LOADng Router, generating the RREP. 544 Route Reply Acknowledgment (RREP_ACK) - Generated by a LOADng Router 545 as a response to an RREP, in order to signal to the neighbor that 546 transmitted the RREP that the RREP was successfully received. 547 Receipt of an RREP_ACK indicates that the link between these two 548 neighboring LOADng Routers is bidirectional. An RREP_ACK is 549 unicast to the neighbor from which the RREP has arrived, and is 550 not forwarded. RREP_ACKs are generated only in response to an 551 RREP which, by way of a flag, has explicitly indicated that an 552 RREP_ACK is desired. 554 Route Error (RERR) - Generated by a LOADng Router when a link on an 555 active route to a destination is detected as broken by way of 556 inability to forward a data packet towards that destination. An 557 RERR is unicast to the source of the undeliverable data packet. 559 5. Protocol Parameters 561 The following parameters and constants are used in this 562 specification. 564 5.1. Protocol and Port Numbers 566 When using LOADng as an IP routing protocol, the considerations of 567 [RFC5498] apply. 569 5.2. Router Parameters 571 NET_TRAVERSAL_TIME - is the maximum time that a packet is expected 572 to take when traversing from one end of the network to the other. 574 RREQ_RETRIES - is the maximum number of subsequent RREQs that a 575 particular LOADng Router may generate in order to discover a route 576 to a destination, before declaring that destination unreachable. 578 RREQ_MIN_INTERVAL - is the minimal interval (in milliseconds) of 579 RREQs that a particular LOADng Router is allowed to send. 581 R_HOLD_TIME - is the minimum time a Routing Tuple SHOULD be kept in 582 the Routing Set after it was last refreshed. 584 MAX_DIST - is the value representing the maximum possible metric 585 (R_metric field). 587 B_HOLD_TIME - is the time during which the link between the neighbor 588 LOADng Router and this LOADng Router MUST be considered as non- 589 bidirectional, and that therefore RREQs received from that 590 neighbor LOADng Router MUST be ignored during that time 591 (B_HOLD_TIME). B_HOLD_TIME should be greater than 2 x 592 NET_TRAVERSAL_TIME x RREQ_RETRIES, to ensure that subsequent RREQs 593 will reach the destination via a route, excluding the link to the 594 blacklisted neighbor. 596 MAX_HOP_LIMIT - is the maximum limit of the number of hops that 597 LOADng routing messages are allowed to traverse. 599 5.3. Interface Parameters 601 Different LOADng Interfaces (on the same or on different LOADng 602 Routers) MAY employ different interface parameter values and MAY 603 change their interface parameter values dynamically. A particular 604 case is where all LOADng Interfaces on all LOADng Routers within a 605 given LOADng routing domain employ the same set of interface 606 parameter values. 608 RREQ_MAX_JITTER - is the default value of MAXJITTER used in 609 [RFC5148] for RREQ messages forwarded by this LOADng Router on 610 this interface. 612 RREP_ACK_REQUIRED - is a boolean flag, which indicates (if set) that 613 the LOADng Router is configured to expect that each RREP it sends 614 be confirmed by an RREP_ACK, or, (if cleared) that no RREP_ACK is 615 expected for this interface. 617 USE_BIDIRECTIONAL_LINK_ONLY - is a boolean flag, which indicates if 618 the LOADng Router only uses verified bi-directional links for data 619 packet forwarding on this interface. It is set by default. If 620 cleared, then the LOADng Router can use links which have not been 621 verified to be bi-directional on this interface. 623 RREP_ACK_TIMEOUT - is the minimum amount of time after transmission 624 of an RREP, that a LOADng Router SHOULD wait for an RREP_ACK from 625 a neighbor LOADng Router, before considering the link to this 626 neighbor to be unidirectional. 628 5.4. Constants 630 MAX_HOP_COUNT - is the maximum number of hops as representable by 631 the encoding that is used (e.g., 255 when using [RFC5444]). It 632 SHOULD NOT be used to limit the scope of a message; the router 633 parameter MAX_HOP_LIMIT can be used to limit the scope of a LOADng 634 routing message. 636 6. Protocol Message Content 638 The protocol messages, generated and processed by LOADng, are 639 described in this section using the notational conventions described 640 in Section 2. The encoding of messages for transmission by way of 641 [RFC5444] packets/messages is described in Appendix A, and Appendix B 642 illustrates the bit layout of a selection of LOADng control messages. 643 Unless stated otherwise, the message fields described below are set 644 by the LOADng Router that generates the message, and MUST NOT be 645 changed by intermediate LOADng Routers. 647 6.1. Route Request (RREQ) Messages 649 A Route Request (RREQ) message has the following fields: 651 RREQ.addr-length is an unsigned integer field, encoding the length 652 of the originator and destination addresses as follows: 654 RREQ.addr-length := the length of an address in octets - 1 656 RREQ.seq-num is an unsigned integer field, containing the sequence 657 number (see Section 8) of the LOADng Router, generating the RREQ 658 message. 660 RREQ.metric-type is an unsigned integer field and specifies the type 661 of metric requested by this RREQ. 663 RREQ.route-metric is a unsigned integer field, of length defined by 664 RREQ.metric-type, which specifies the route metric of the route 665 (the sum of the link metrics of the links), through which this 666 RREQ has traveled. 668 RREQ.hop-count is an unsigned integer field and specifies the total 669 number of hops which the message has traversed from the 670 RREQ.originator. 672 RREQ.hop-limit is an unsigned integer field and specifies the number 673 of hops that the message is allowed to traverse. 675 RREQ.originator is an identifier of RREQ.addr-length + 1 octets, 676 specifying the address of the LOADng Interface over which this 677 RREQ was generated, and to which a route (the "reverse route") is 678 supplied by this RREQ. In case the message is generated by a 679 LOADng Router on behalf of an attached host, RREQ.originator 680 corresponds to an address of that host, otherwise it corresponds 681 to an address of the sending LOADng Interface of the LOADng 682 Router. 684 RREQ.destination is an identifier of RREQ.addr-length + 1 octets, 685 specifying the address to which the RREQ should be sent, i.e., the 686 destination address for which a route is sought. 688 The following fields of an RREQ message are immutable, i.e., they 689 MUST NOT be changed during processing or forwarding of the message: 690 RREQ.addr-length, RREQ.seq-num, RREQ.originator, and 691 RREQ.destination. 693 The following fields of an RREQ message are mutable, i.e., they will 694 be changed by intermediate routers during processing or forwarding, 695 as specified in Section 12.2 and Section 12.3: RREQ.metric-type, 696 RREQ.route-metric, RREQ.hop-limit, and RREQ.hop-count. 698 Any additional field that is added to the message by an extension to 699 this protocol, e.g., by way of TLVs, MUST be considered immutable, 700 unless the extension specifically defines the field as mutable. 702 6.2. Route Reply (RREP) Messages 704 A Route Reply (RREP) message has the following fields: 706 RREP.addr-length is an unsigned integer field, encoding the length 707 of the originator and destination addresses as follows: 709 RREP.addr-length := the length of an address in octets - 1 711 RREP.seq-num is an unsigned integer field, containing the sequence 712 number (see Section 8) of the LOADng Router, generating the RREP 713 message. 715 RREP.metric-type is an unsigned integer field and specifies the type 716 of metric, requested by this RREP. 718 RREP.route-metric is a unsigned integer field, of length defined by 719 RREP.metric-type, which specifies the route metric of the route 720 (the sum of the link metrics of the links) through which this RREP 721 has traveled. 723 RREP.ackrequired is a boolean flag which, when set ('1'), at least 724 one RREP_ACK MUST be generated by the recipient of an RREP if the 725 RREP is successfully processed. When cleared ('0'), an RREP_ACK 726 MUST NOT be generated in response to processing of the RREP. 728 RREP.hop-count is an unsigned integer field and specifies the total 729 number of hops which the message has traversed from 730 RREP.originator to RREP.destination. 732 RREP.hop-limit is an unsigned integer field and specifies the number 733 of hops that the message is allowed to traverse. 735 RREP.originator is an identifier of RREP.addr-length + 1 octets, 736 specifying the address for which this RREP was generated, and to 737 which a route (the "forward route") is supplied by this RREP. In 738 case the message is generated on a LOADng Router on behalf of an 739 attached host, RREP.originator corresponds to an address of that 740 host, otherwise it corresponds to an address of the LOADng 741 Interface of the LOADng Router, over which the RREP was generated. 743 RREP.destination is an identifier of RREP.addr-length + 1 octets, 744 specifying the address to which the RREP should be sent. (I.e., 745 this address is equivalent to RREQ.originator of the RREQ that 746 triggered the RREP.) 748 The following fields of an RREP message are immutable, i.e., they 749 MUST NOT be changed during processing or forwarding of the message: 750 RREP.addr-length, RREP.seq-num, RREP.originator, and 751 RREP.destination. 753 The following fields of an RREP message are mutable, i.e., they will 754 be changed by intermediate routers during processing or forwarding, 755 as specified in Section 13.2 and Section 13.3: RREP.metric-type, 756 RREP.route-metric, RREP.ackrequired, RREP.hop-limit, and RREP.hop- 757 count. 759 Any additional field that is added to the message by an extension to 760 this protocol, e.g., by way of TLVs, MUST be considered immutable, 761 unless the extension specifically defines the field as mutable. 763 6.3. Route Reply Acknowledgement (RREP_ACK) Messages 765 A Route Reply Acknowledgement (RREP_ACK) message has the following 766 fields: 768 RREP_ACK.addr-length is an unsigned integer field, encoding the 769 length of the destination and originator addresses as follows: 771 RREP_ACK.addr-length := the length of an address in octets - 1 773 RREP_ACK.seq-num is an unsigned integer field and contains the value 774 of RREP.seq-num from the RREP for which this RREP_ACK is sent. 776 RREP_ACK.destination is an identifier of RREP_ACK.addr-length + 1 777 octets and contains the value of the RREP.originator field from 778 the RREP for which this RREP_ACK is sent. 780 RREP_ACK messages are sent only across a single link and are never 781 forwarded. 783 6.4. Route Error (RERR) Messages 785 A Route Error (RERR) message has the following fields: 787 RERR.addr-length is an unsigned integer field, encoding the length 788 of RERR.destination and RERR.unreachableAddress, as follows: 790 RERR.addr-length := the length of an address in octets - 1 792 RERR.errorcode is an unsigned integer field and specifies the reason 793 for the error message being generated, according to Table 1. 795 RERR.unreachableAddress is an identifier of RERR.addr-length + 1 796 octets, specifying an address, which has become unreachable, and 797 for which an error is reported by way of this RERR message. 799 RERR.originator is an identifier of RERR.addr-length + 1 octets, 800 specifying the address of the LOADng Interface over which this 801 RERR was generated by a LOADng Router. 803 RERR.destination is an identifier of RERR.address-length + 1 octets, 804 specifying the destination address of this RERR message. 805 RERR.destination is, in general, the source address of a data 806 packet, for which delivery to RERR.unreachableAddress failed, and 807 the unicast destination of the RERR message is the LOADng Router 808 which has RERR.destination listed in a Local Interface Tuple or in 809 a Destination Address Tuple. 811 RERR.hop-limit is an unsigned integer field and specifies the number 812 of hops that the message is allowed to traverse. 814 The following fields of an RERR message are immutable, i.e., they 815 MUST NOT be changed during processing or forwarding of the message: 816 RERR.addr-length, RERR.errorcode, RERR.unreachableAddress, 817 RERR.originator and RERR.destination. 819 The following fields of an RERR message are mutable, i.e., they will 820 be changed by intermediate routers during processing or forwarding, 821 as specified in Section 14.3 and Section 14.4: RERR.hop-limit. 823 Any additional field that is added to the message by an extension to 824 this protocol, e.g., by way of TLVs, MUST be considered immutable, 825 unless the extension specifically defines the field as mutable. 827 7. Information Base 829 Each LOADng Router maintains an Information Base, containing the 830 information sets necessary for protocol operation, as described in 831 the following sections. The organization of information into these 832 information sets is non-normative, given so as to facilitate 833 description of message generation, forwarding and processing rules in 834 this specification. An implementation may choose any representation 835 or structure for when maintaining this information. 837 7.1. Routing Set 839 The Routing Set records the next hop on the route to each known 840 destination, when such a route is known. It consists of Routing 841 Tuples: 843 (R_dest_addr, R_next_addr, R_metric, R_metric_type, R_hop_count, 844 R_seq_num, R_bidirectional, R_local_iface_addr, R_valid_time) 846 where: 848 R_dest_addr - is the address of the destination, either an address 849 of a LOADng Interface of a destination LOADng Router, or an 850 address of an interface reachable via the destination LOADng 851 Router, but which is outside the routing domain. 853 R_next_addr - is the address of the "next hop" on the selected route 854 to the destination. 856 R_metric - is the metric associated with the selected route to the 857 destination with address R_dest_addr. 859 R_metric_type - specifies the metric type for this Routing Tuple - 860 in other words, how R_metric is defined and calculated. 862 R_hop_count - is the hop count of the selected route to the 863 destination with address R_dest_addr. 865 R_seq_num - is the value of the RREQ.seq-num or RREP.seq-num field 866 of the RREQ or RREP which installed or last updated this tuple. 867 For the Routing Tuples installed by previous hop information of 868 RREQ or RREP, R_seq_num MUST be set to -1. 870 R_bidirectional - is a boolean flag, which specifies if the Routing 871 Tuple is verified as representing a bi-directional route. Data 872 traffic SHOULD only be routed through a routing tuple with 873 R_bidirectional flag equals TRUE, unless the LOADng Router is 874 configured as accepting routes without bi-directionality 875 verification explicitly by setting USE_BIDIRECTIONAL_LINK_ONLY to 876 FALSE of the interface with R_local_iface_address. 878 R_local_iface_addr - is an address of the local LOADng Interface, 879 through which the destination can be reached. 881 R_valid_time - specifies the time until which the information 882 recorded in this Routing Tuple is considered valid. 884 7.2. Local Interface Set 886 A LOADng Router's Local Interface Set records its local LOADng 887 Interfaces. It consists of Local Interface Tuples, one per LOADng 888 Interface: 890 (I_local_iface_addr_list) 892 where: 894 I_local_iface_addr_list - is an unordered list of the network 895 addresses of this LOADng Interface. 897 The implementation MUST initialize the Local Interface Set with at 898 least one tuple containing at least one address of an LOADng 899 Interface. The Local Interface Set MUST be updated if there is a 900 change of the LOADng Interfaces of a LOADng Router (i.e., a LOADng 901 Interface is added, removed or changes addresses). 903 7.3. Blacklisted Neighbor Set 905 The Blacklisted Neighbor Set records the neighbor LOADng Interface 906 addresses of a LOADng Router, with which connectivity has been 907 detected to be unidirectional. Specifically, the Blacklisted 908 Neighbor Set records neighbors from which an RREQ has been received 909 (i.e., through which a Forward Route would possible) but to which it 910 has been determined that it is not possible to communicate (i.e., 911 forwarding Route Replies via this neighbor fails, rendering 912 installing the Forward Route impossible). It consists of Blacklisted 913 Neighbor Tuples: 915 (B_neighbor_address, B_valid_time) 917 where: 919 B_neighbor_address - is the address of the blacklisted neighbor 920 LOADng Interface. 922 B_valid_time - specifies the time until which the information 923 recorded in this tuple is considered valid. 925 7.4. Destination Address Set 927 The Destination Address Set records addresses, for which a LOADng 928 Router will generate RREPs in response to received RREQs, in addition 929 to its own LOADng Interface addresses (as listed in the Local 930 Interface Set). The Destination Address Set thus represents those 931 destinations (i.e., hosts), for which this LOADng Router is providing 932 connectivity. It consists of Destination Address Tuples: 934 (D_address) 936 where: 938 D_address - is the address of a destination (a host or a network), 939 attached to this LOADng Router and for which this LOADng Router 940 provides connectivity through the routing domain. 942 The Destination Address Set is used for generating signaling, but is 943 not itself updated by signaling specified in this document. Updates 944 to the Destination Address Set are due to changes of the environment 945 of a LOADng Router - hosts or external networks being connected to or 946 disconnected from a LOADng Router. The Destination Address Set may 947 be administrationally provisioned, or provisioned by external 948 protocols. 950 7.5. Pending Acknowledgment Set 952 The Pending Acknowledgment Set contains information about RREPs which 953 have been transmitted with the RREP.ackrequired flag set, and for 954 which an RREP_ACK has not yet been received. It consists of Pending 955 Acknowledgment Tuples: 957 (P_next_hop, P_originator, P_seq_num, 958 P_ack_received, P_ack_timeout) 960 where: 962 P_next_hop - is the address of the neighbor LOADng Interface to 963 which the RREP was sent. 965 P_originator - is the address of the originator of the RREP. 967 P_seq_num - is the RREP.seq-num field of the sent RREP. 969 P_ack_received - is a boolean flag, which specifies the tuple has 970 been acknowledged by a corresponding RREP_ACK message. The 971 default value is FALSE. 973 P_ack_timeout - is the time after which the tuple MUST be expired. 975 8. LOADng Router Sequence Numbers 977 Each LOADng Router maintains a single sequence number, which must be 978 included in each RREQ or RREP message it generates. Each LOADng 979 Router MUST make sure that no two messages (both RREQ and RREP) are 980 generated with the same sequence number, and MUST generate sequence 981 numbers such that these are monotonically increasing. This sequence 982 number is used as freshness information for when comparing routes to 983 the LOADng Router having generated the message. 985 However, with a limited number of bits for representing sequence 986 numbers, wrap-around (that the sequence number is incremented from 987 the maximum possible value to zero) can occur. To prevent this from 988 interfering with the operation of the protocol, the following MUST be 989 observed. The term MAXVALUE designates in the following the largest 990 possible value for a sequence number. The sequence number S1 is said 991 to be "greater than" (denoted '>') the sequence number S2 if: 993 S2 < S1 AND S1 - S2 <= MAXVALUE/2 OR 995 S1 < S2 AND S2 - S1 > MAXVALUE/2 997 9. Route Maintenance 999 Tuples in the Routing Set are maintained by way of five different 1000 mechanisms: 1002 o RREQ/RREP exchange, specified in Section 12 and Section 13. 1004 o Data traffic delivery success. 1006 o Data traffic delivery failure. 1008 o External signals indicating that a tuple in the Routing Set needs 1009 updating. 1011 o Information expiration. 1013 Routing Tuples in the Routing Set contain a validity time, which 1014 specifies the time until which the information recorded in this tuple 1015 is considered valid. After this time, the information in such tuples 1016 is to be considered as invalid, for the processing specified in this 1017 document. 1019 Routing Tuples for actively used routes (i.e., routes via which 1020 traffic is currently transiting) SHOULD NOT be removed, unless there 1021 is evidence that they no longer provide connectivity - i.e., unless a 1022 link on that route has broken. 1024 To this end, one or more of the following mechanisms (non-exhaustive 1025 list) MAY be used: 1027 o If a lower layer mechanism provides signals, such as when delivery 1028 to a presumed neighbor LOADng Router fails, this signal MAY be 1029 used to indicate that a link has broken, trigger early expiration 1030 of a Routing Tuple from the Routing Set, and to initiate Route 1031 Error Signaling (see Section 14). Conversely, absence of such a 1032 signal when attempting delivery MAY be interpreted as validation 1033 that the corresponding Routing Tuple(s) are valid, and their 1034 R_valid_time refreshed correspondingly. Note that when using such 1035 a mechanism, care should be taken to prevent that an intermittent 1036 error (e.g., an incidental wireless collision) triggers corrective 1037 action and signaling. This depends on the nature of the signals, 1038 provided by the lower layer, but can include the use of a 1039 hysteresis function or other statistical mechanisms. 1041 o Conversely, for each successful delivery of a packet to a neighbor 1042 or a destination, if signaled by a lower layer or a transport 1043 mechanism, or each positive confirmation of the presence of a 1044 neighbor by way of an external neighbor discovery protocol, MAY be 1045 interpreted as validation that the corresponding Routing Tuple(s) 1046 are valid, and their R_valid_time refreshed correspondingly. Note 1047 that when refreshing a Routing Tuple corresponding to a 1048 destination of a data packet, the Routing Tuple corresponding to 1049 the next hop toward that destination SHOULD also be refreshed. 1051 Furthermore, a LOADng Router may experience that a route currently 1052 used for forwarding data packets is no longer operational, and must 1053 act to either rectify this situation locally (Section 13) or signal 1054 this situation to the source of the data packets for which delivery 1055 was unsuccessful (Section 14). 1057 If a LOADng Router fails to deliver a data packet to a next-hop, it 1058 MUST generate an RERR message, as specified in Section 14. 1060 10. Unidirectional Link Handling 1062 Each LOADng Router MUST monitor the bidirectionality of the links to 1063 its neighbors and set the R_bidirectional flag of related routing 1064 tuples when processing Route Replies (RREP). To this end, one or 1065 more of the following mechanisms MAY be used (non exhaustive list): 1067 o If a lower layer mechanism provides signals, such as when delivery 1068 to a presumed neighbor LOADng Router fails, this signal MAY be 1069 used to detect that a link to this neighbor is broken or is 1070 unidirectional; the LOADng Router MUST then blacklist the neighbor 1071 (see Section 10.1). 1073 o If a mechanism such as NDP [RFC4861] is available, the LOADng 1074 Router MAY use it. 1076 o A LOADng Router MAY use a neighborhood discovery mechanism with 1077 bidirectionality verification, such as NHDP [RFC6130]. 1079 o RREP_ACK message exchange, as described in Section 15. 1081 o Upper-layer mechanisms, such as transport-layer acknowledgments, 1082 MAY be used to detect unidirectional or broken links. 1084 When a LOADng Router detects, via one of these mechanisms, that a 1085 link to a neighbor LOADng Router is unidirectional or broken, the 1086 LOADng Router MUST blacklist this neighbor, see Section 10.1. 1087 Conversely, if a LOADng Router detects via one of these mechanisms 1088 that a previously blacklisted LOADng Router has a bidirectional link 1089 to this LOADng Router, it MAY remove it from the blacklist before the 1090 B_valid_time of the corresponding tuple. 1092 10.1. Blacklist Usage 1094 The Blacklist is maintained according to Section 7.3. When an 1095 interface of neighbor LOADng Router is detected to have a 1096 unidirectional link to the LOADng Router, it is blacklisted, i.e., a 1097 tuple (B_neighbor_address, B_valid_time) is created thus: 1099 o B_neighbor_address := the address of the blacklisted neighbor 1100 LOADng Router interface 1102 o B_valid_time := current_time + B_HOLD_TIME 1104 When a neighbor LOADng Router interface is blacklisted, i.e., when 1105 there is a corresponding (B_neighbor_address, B_valid_time) tuple in 1106 the Blacklisted Neighbor Set, it is temporarily not considered as a 1107 neighbor, and thus: 1109 o Every RREQ received from this neighbor LOADng Router interface 1110 MUST be discarded; 1112 11. Common Rules for RREQ and RREP Messages 1114 RREQ and RREP messages, both, supply routes between their recipients 1115 and the originator of the RREQ or RREP message. The two message 1116 types therefore share common processing rules, and differ only in the 1117 following: 1119 o RREQ messages are multicast or broadcast, intended to be received 1120 by all LOADng Routers in the network, whereas RREP messages are 1121 all unicast, intended to be received only by LOADng Routers on a 1122 specific route towards a specific destination. 1124 o Receipt of an RREQ message by a LOADng router, which has the 1125 RREQ.destination address in its Local Interface Set or Destination 1126 Address Set MUST trigger the procedures for generation of an RREP 1127 message. 1129 o Receipt of an RREP message with RREP.ackrequired set MUST trigger 1130 generation of an RREP_ACK message. 1132 For the purpose of the processing description in this section, the 1133 following additional notation is used: 1135 received-route-metric is a variable, representing the route metric, 1136 as included in the received RREQ or RREP message, see Section 16. 1138 used-metric-type is a variable, representing the type of metric used 1139 for calculating received-route-metric, see Section 16. 1141 previous-hop is the address of the LOADng Router, from which the 1142 RREQ or RREP message was received. 1144 > is the comparison operator for sequence numbers, as specified in 1145 Section 8. 1147 MSG is a shorthand for either an RREQ or RREP message, used for when 1148 accessing message fields in the description of the common RREQ and 1149 RREP message processing in the following subsections. 1151 hop-count is a variable, representing the hop-count, as included in 1152 the received RREQ or RREP message. 1154 hop-limit is a variable, representing the hop-limit, as included in 1155 the received RREQ or RREP message. 1157 link-metric is a variable, representing the link metric between this 1158 LOADng Router and the LOADng Router from which the RREQ or RREP 1159 message was received, as calculated by the receiving LOADng 1160 Router, see Section 16. 1162 route-metric is a variable, representing the route metric, as 1163 included in the received RREQ or RREP message, plus the link- 1164 metric for the link, over which the RREQ or RREP was received, 1165 i.e., the total route cost from the originator to this LOADng 1166 Router. 1168 11.1. Identifying Invalid RREQ or RREP Messages 1170 A received RREQ or RREP message is invalid, and MUST be discarded 1171 without further processing, if any of the following conditions are 1172 true: 1174 o The address length specified by this message (i.e., MSG.addr- 1175 length + 1) differs from the length of the address(es) of this 1176 LOADng Router. 1178 o The address contained in MSG.originator is an address of this 1179 LOADng Router. 1181 o There is a tuple in the Routing Set where: 1183 * R_dest_addr = MSG.originator 1185 * R_seq_num > MSG.seq-num 1187 o For RREQ messages only, an RREQ MUST be considered invalid if the 1188 previous-hop is blacklisted (i.e., its address is in a tuple in 1189 the Blacklisted Neighbor Set, see Section 10.1). 1191 A LOADng Router MAY recognize additional reasons for identifying that 1192 an RREQ or RREP message is invalid for processing, e.g., to allow a 1193 security protocol to perform verification of integrity check values 1194 and prevent processing of unverifiable RREQ or RREP message by this 1195 protocol. 1197 11.2. RREQ and RREP Message Processing 1199 A received, and valid, RREQ or RREP message is processed as follows: 1201 1. Included TLVs are processed/updated according to their 1202 specification. 1204 2. Set the variable hop-count to MSG.hop-count + 1. 1206 3. Set the variable hop-limit to MSG.hop-limit - 1. 1208 4. If MSG.metric-type is known to this LOADng Router, and if 1209 MSG.metric-type is not HOP_COUNT, then: 1211 * Set the variable used-metric-type to the value of MSG.metric- 1212 type. 1214 * Determine the link metric over the link over which the message 1215 was received, according to used-metric-type, and set the 1216 variable link-metric to the calculated value. 1218 * Compute the route metric to MSG.originator according to used- 1219 metric-type by adding link-metric to the received-route-metric 1220 advertised by the received message, and set the variable 1221 route-metric to the calculated value. 1223 5. Otherwise: 1225 * Set the variable used-metric-type to HOP_COUNT. 1227 * Set the variable route-metric to MAX_DIST, see Section 16. 1229 * Set the variable link-metric to MAX_DIST. 1231 6. Find the Routing Tuple (henceforth, Matching Routing Tuple) 1232 where: 1234 * R_dest_addr = MSG.originator 1236 7. If no Matching Routing Tuple is found, then create a new Matching 1237 Routing Tuple (the "reverse route" for RREQ messages or "forward 1238 route" for RREP messages) with: 1240 * R_dest_addr := MSG.originator 1242 * R_next_addr := previous-hop 1244 * R_metric_type := used-metric-type 1246 * R_metric := MAX_DIST 1247 * R_hop_count := hop-count 1249 * R_seq_num := -1 1251 * R_valid_time := current time + R_HOLD_TIME 1253 * R_bidirectional := FALSE 1255 * R_local_iface_addr := the address of the LOADng Interface 1256 through which the message was received. 1258 8. The Matching Routing Tuple, existing or new, is compared to the 1259 received RREQ or RREP message: 1261 1. If 1263 + R_seq_num = MSG.seq-num; AND 1265 + R_metric_type = used-metric-type; AND 1267 + R_metric > route-metric 1269 OR 1271 + R_seq_num = MSG.seq-num; AND 1273 + R_metric_type = used-metric-type; AND 1275 + R_metric = route-metric; AND 1277 + R_hop_count > hop-count 1279 OR 1281 + R_seq_num = MSG.seq-num; AND 1283 + R_metric_type does not equal to used-metric-type; AND 1285 + R_metric_type = HOP_COUNT 1287 OR 1289 + R_seq_num < MSG.seq-num 1291 Then: 1293 1. The message is used for updating the Routing Set. The 1294 Routing Tuple, where: 1296 - R_dest_addr = MSG.originator; 1298 is updated thus: 1300 - R_next_addr := previous-hop 1302 - R_metric_type = used-metric-type 1304 - R_metric := route-metric 1306 - R_hop_count := hop-count 1308 - R_seq_num := MSG.seq-num 1310 - R_valid_time := current time + R_HOLD_TIME 1312 - R_bidirectional := TRUE, if the message being 1313 processed is an RREP. 1315 2. If previous-hop is not equal to MSG.originator, and if 1316 there is no Matching Routing Tuple in the Routing Set 1317 with R_dest_addr = previous-hop, create a new Matching 1318 Routing Tuple with: 1320 - R_dest_addr := previous-hop 1322 - R_next_addr := previous-hop 1324 3. The Routing Tuple with R_dest_addr = previous-hop, 1325 existing or new, is updated as follows 1327 - R_metric_type := used-metric-type 1329 - R_metric := link-metric 1331 - R_hop_count := 1 1333 - R_seq_num := -1 1335 - R_valid_time := current time + R_HOLD_TIME 1337 - R_bidirectional := TRUE, if the processed message is 1338 an RREP, otherwise FALSE. 1340 - R_local_iface_addr := the address of the LOADng 1341 Interface through which the message was received. 1343 2. Otherwise, if the message is an RREQ, it is not processed 1344 further and is not considered for forwarding. If it is an 1345 RREP and if RREP.ackrequired is set, an RREP_ACK message MUST 1346 be sent to the previous-hop, according to Section 15.2. The 1347 RREP is not considered for forwarding. 1349 12. Route Requests (RREQs) 1351 Route Requests (RREQs) are generated by a LOADng Router when it has 1352 data packets to deliver to a destination, where the data packet 1353 source is local to that LOADng Router (i.e., is an address in the 1354 Local Interface Set or Destination Address Set of that LOADng 1355 Router), but for which the LOADng router has no matching tuple in the 1356 Routing Set. Furthermore, if there is a matching tuple in the Routing 1357 Set with the R_bidirectional set to FALSE, and the parameter 1358 USE_BIDIRECTIONAL_LINK_ONLY of the interface with 1359 R_local_iface_address equals TRUE, an RREQ MUST be generated. 1361 After originating an RREQ, a LOADng Router waits for a corresponding 1362 RREP. If no such RREP is received within 2*NET_TRAVERSAL_TIME 1363 milliseconds, the LOADng Router MAY issue a new RREQ for the sought 1364 destination (with an incremented seq_num) up to a maximum of 1365 RREQ_RETRIES times. Two consequent RREQs generated on an interface 1366 of a LOADng Router SHOULD be separated at least RREQ_MIN_INTERVAL. 1368 12.1. RREQ Generation 1370 An RREQ message is generated according to Section 6 with the 1371 following content: 1373 o RREQ.addr-length set to the length of the address, as specified in 1374 Section 6; 1376 o RREQ.metric-type set to the desired metric type; 1378 o RREQ.route-metric := 0. 1380 o RREQ.seq-num set to the next unused sequence number, maintained by 1381 this LOADng Router; 1383 o RREQ.hop-count := 0; 1385 o RREQ.hop-limit := MAX_HOP_LIMIT; 1387 o RREQ.destination := the address to which a route is sought; 1389 o RREQ.originator := one address of the LOADng Interface of the 1390 LOADng Router that generates the RREQ. If the LOADng Router is 1391 generating RREQ on behalf of a host connected to this LOADng 1392 Router, the source address of the data packet, generated by that 1393 host, is used; 1395 12.2. RREQ Processing 1397 The variables hop-count and hop-limit have been updated in 1398 Section 11.2 (when processing the message) and are used in this 1399 section. On receiving an RREQ message, a LOADng Router MUST process 1400 the message according to this section: 1402 1. If the message is invalid for processing, as defined in 1403 Section 11.1, the message MUST be discarded without further 1404 processing. The message is not considered for forwarding. 1406 2. Otherwise, the message is processed according to Section 11.2. 1408 3. If RREQ.destination is listed in I_local_iface_addr_list of any 1409 Local Interface Tuple, or corresponds to D_address of any 1410 Destination Address Tuple of this LOADng Router, the RREP 1411 generation process in Section 13.1 MUST be applied. The RREQ is 1412 not considered for forwarding. 1414 4. Otherwise, if hop-count is less than MAX_HOP_COUNT and hop-limit 1415 is greater than 0, the message is considered for forwarding 1416 according to Section 12.3. 1418 12.3. RREQ Forwarding 1420 The variables used-metric type, hop-count, hop-limit and route-metric 1421 have been updated in Section 11.2 (when processing the message) and 1422 are used in this section to update the content of the message to be 1423 forwarded. An RREQ, considered for forwarding, MUST be updated as 1424 follows, prior to it being transmitted: 1426 1. RREQ.metric-type := used-metric-type (as set in Section 11.2) 1428 2. RREQ.route-metric := route-metric (as set in Section 11.2) 1430 3. RREQ.hop-count := hop-count (as set in Section 11.2) 1432 4. RREQ.hop-limit := hop-limit (as set in Section 11.2) 1434 An RREQ MUST be forwarded according to the flooding operation, 1435 specified for the network. This MAY be by way of classic flooding, a 1436 reduced relay set mechanism such as [RFC6621], or any other 1437 information diffusion mechanism such as [RFC6206]. Care must be 1438 taken that NET_TRAVERSAL_TIME is chosen so as to accommodate for the 1439 maximum time that may take for an RREQ to traverse the network, 1440 accounting for in-router delays incurring due to or imposed by such 1441 algorithms. 1443 12.4. RREQ Transmission 1445 RREQs, whether initially generated or forwarded, are sent to all 1446 neighbor LOADng Routers through all interfaces in the Local Interface 1447 Set. 1449 When an RREQ is transmitted, all receiving LOADng Routers will 1450 process the RREQ message and as a consequence consider the RREQ 1451 message for forwarding at the same, or at almost the same, time. If 1452 using data link and physical layers that are subject to packet loss 1453 due to collisions, such RREQ messages SHOULD be jittered as described 1454 in [RFC5148], using RREQ_MAX_JITTER, in order to avoid such losses. 1456 13. Route Replies (RREPs) 1458 Route Replies (RREPs) are generated by a LOADng Router in response to 1459 an RREQ (henceforth denoted "corresponding RREQ"), and are sent by 1460 the LOADng Router which has, in either its Destination Address Set or 1461 in its Local Interface Set, the address from RREQ.destination. RREPs 1462 are sent, hop by hop, in unicast towards the originator of the RREQ, 1463 in response to which the RREP was generated, along the Reverse Route 1464 installed by that RREQ. A LOADng Router, upon forwarding an RREP, 1465 installs the Forward Route towards the RREP.destination. 1467 Thus, with forwarding of RREQs installing the Reverse Route and 1468 forwarding of RREPs installing the Forward Route, bi-directional 1469 routes are provided between the RREQ.originator and RREQ.destination. 1471 13.1. RREP Generation 1473 At least one RREP MUST be generated in response to a (set of) 1474 received RREQ messages with identical (RREP.originator, RREP.seq- 1475 num). An RREP MAY be generated immediately as a response to each 1476 RREQ processed, in order to provide shortest possible route 1477 establishment delays, or MAY be generated after a certain delay after 1478 the arrival of the first RREQ, in order to use the "best" received 1479 RREQ (e.g., received over the lowest-cost route) but at the expense 1480 of longer route establishment delays. A LOADng Router MAY generate 1481 further RREPs for subsequent RREQs received with the same 1482 (RREP.originator, RREP.seq-num) pairs, if these indicate a better 1483 route, at the expense of additional control traffic being generated. 1484 In all cases, however, the content of an RREP is as follows: 1486 o RREP.addr-length set to the length of the address, as specified in 1487 Section 6; 1489 o RREP.seq-num set to the next unused sequence number, maintained by 1490 this LOADng Router; 1492 o RREP.metric-type set to the same value as the RREQ.metric-type in 1493 the corresponding RREQ if the metric type is known to the router. 1494 Otherwise, RREP.metric-type is set to HOP_COUNT; 1496 o RREP.route-metric := 0 1498 o RREP.hop-count := 0; 1500 o RREP.hop-limit := MAX_HOP_LIMIT; 1502 o RREP.destination := the address to which this RREP message is to 1503 be sent; this corresponds to the RREQ.originator from the RREQ 1504 message, in response to which this RREP message is generated; 1506 o RREP.originator := the address of the LOADng Router, generating 1507 the RREP. If the LOADng Router is generating an RREP on behalf of 1508 the hosts connected to it, or on behalf of one of the addresses 1509 contained in the LOADng Routers Destination Address Set, the host 1510 address is used. 1512 The RREP so generated is transmitted according to Section 13.4. 1514 13.2. RREP Processing 1516 The variables hop-count and hop-limit have been updated in 1517 Section 11.2 (when processing the message) and are used in this 1518 section. On receiving an RREP message, a LOADng Router MUST process 1519 the message according to this section: 1521 1. If the message is invalid for processing, as defined in 1522 Section 11.1, the message MUST be discarded without further 1523 processing. The message is not considered for forwarding. 1525 2. Otherwise, the message is processed according to Section 11.2. 1527 3. If RREP.ackrequired is set, an RREP_ACK message MUST be sent to 1528 the previous-hop, according to Section 15.2. 1530 4. If hop-count is equal to MAX_HOP_COUNT or hop-limit is equal to 1531 0, the message is not considered for forwarding. 1533 5. Otherwise, if RREP.destination is not listed in 1534 I_local_iface_addr_list of any Local Interface Tuple and does not 1535 correspond to D_address of any Destination Address Tuple of this 1536 LOADng Router, the RREP message is considered for forwarding 1537 according to Section 13.3. 1539 13.3. RREP Forwarding 1541 The variables used-metric type, hop-count, hop-limit and route-metric 1542 have been updated in Section 11.2 (when processing the message) and 1543 are used in this section to update the content of the message to be 1544 forwarded. An RREP message, considered for forwarding, MUST be 1545 updated as follows, prior to it being transmitted: 1547 1. RREP.metric-type := used-metric-type (as set in Section 11.2) 1549 2. RREP.route-metric := route-metric (as set in Section 11.2) 1551 3. RREP.hop-count := hop-count (as set in Section 11.2) 1553 4. RREP.hop-limit := hop-limit (as set in Section 11.2) 1555 5. The RREP is transmitted, according to Section 13.4. 1557 The RREP message is then unicast to the next hop towards 1558 RREP.destination. 1560 13.4. RREP Transmission 1562 An RREP is, ultimately, destined for the LOADng Router which has the 1563 address listed in the RREP.destination field in either of its Local 1564 Interface Set, or in its Destination Address Set. The RREP is 1565 forwarded in unicast towards that LOADng Router. The RREP MUST, 1566 however, be transmitted so as to allow it to be processed in each 1567 intermediate LOADng Router to: 1569 o Install proper forward routes; AND 1571 o Permit that RREP.hop-count be updated to reflect the route. 1573 RREP Transmission is accomplished by the following procedure: 1575 1. Find the Routing Tuple (henceforth, the "Matching Routing Tuple") 1576 in the Routing Set, where: 1578 * R_dest_addr = RREP.destination 1580 2. Find the Local Interface Tuple (henceforth, "Matching Interface 1581 Tuple), where: 1583 * I_local_iface_addr_list contains R_local_iface_addr from the 1584 Matching Routing Tuple 1586 3. If RREP_ACK_REQUIRED is set for the LOADng Interface, identified 1587 by the Matching Interface Tuple: 1589 * Create a new Pending Acknowledgment Tuple with: 1591 + P_next_hop := R_next_addr from the Matching Routing Tuple 1593 + P_originator := RREP.originator 1595 + P_seq_num := RREP.seq-num 1597 + P_ack_received := FALSE 1599 + P_ack_timeout := current_time + RREP_ACK_TIMEOUT 1601 * Set RREP.ackrequired to true 1603 4. Otherwise: 1605 * Set RREP.ackrequired to false. 1607 5. The RREP is transmitted over the LOADng Interface, identified by 1608 the Matching Interface Tuple to the neighbor LOADng Router, 1609 identified by R_next_addr from the Matching Routing Tuple. 1611 When a Pending Acknowledgement Tuple expires, if P_ack_received = 1612 FALSE, the P_next_hop address MUST be blacklisted by creating a 1613 Blacklisted Neighbor Tuple according to Section 7.3 1615 14. Route Errors (RERRs) 1617 If a LOADng Router fails to deliver a data packet to a next hop or a 1618 destination, and if neither the source nor destination address of 1619 that data packet is not in the Destination Address Set of that LOADng 1620 Router, it MUST generate a Route Error (RERR). This RERR MUST be 1621 sent along the Reverse Route towards the source of the data packet 1622 for which delivery was unsuccessful (to the last LOADng Router along 1623 the Reverse Route, if the data packet was originated by a host behind 1624 that LOADng Router). 1626 The following definition is used in this section: 1628 o "EXPIRED" indicates that a timer is set to a value clearly 1629 preceding the current time (e.g., current time - 1). 1631 14.1. Identifying Invalid RERR Messages 1633 A received RERR is invalid, and MUST be discarded without further 1634 processing, if any of the following conditions are true: 1636 o The address length specified by this message (i.e., RERR.addr- 1637 length + 1) differs from the length of the address(es) of this 1638 LOADng Router. 1640 o The address contained in RERR.originator is an address of this 1641 LOADng Router. 1643 A LOADng Router MAY recognize additional reasons, external to this 1644 specification, for identifying that an RERR message is invalid for 1645 processing, e.g., to allow a security protocol to perform 1646 verification of signatures and prevent processing of unverifiable 1647 RERR message by this protocol. 1649 14.2. RERR Generation 1651 A packet with an RERR message is generated by the LOADng Router, 1652 detecting the link breakage, with the following content: 1654 o RERR.error-code := the error code corresponding to the event 1655 causing the RERR to be generated, from among those recorded in 1656 Table 1; 1658 o RERR.addr-length := the length of the address, as specified in 1659 Section 6; 1661 o RERR.unreachableAddress := the destination address from the 1662 unsuccessfully delivered data packet. 1664 o RERR.originator := one address of the LOADng Interface of the 1665 LOADng Router that generates the RERR. 1667 o RERR.destination := the source address from the unsuccessfully 1668 delivered data packet, towards which the RERR is to be sent. 1670 o RERR.hop-limit := MAX_HOP_LIMIT; 1672 14.3. RERR Processing 1674 For the purpose of the processing description below, the following 1675 additional notation is used: 1677 previous-hop is the address of the LOADng Router, from which the 1678 RERR was received. 1680 hop-limit is a variable, representing the hop-limit, as included in 1681 the received RERR message. 1683 Upon receiving an RERR, a LOADng Router MUST perform the following 1684 steps: 1686 1. If the RERR is invalid for processing, as defined in 1687 Section 14.1, the RERR MUST be discarded without further 1688 processing. The message is not considered for forwarding. 1690 2. Included TLVs are processed/updated according to their 1691 specification. 1693 3. Set the variable hop-limit to RERR.hop-limit - 1. 1695 4. Find the Routing Tuple (henceforth "matching Routing Tuple") in 1696 the Routing Set where: 1698 * R_dest_addr = RERR.unreachableAddress 1700 * R_next_addr = previous-hop 1702 5. If no matching Routing Tuple is found, the RERR is not processed 1703 further, and is not considered for forwarding. 1705 6. Otherwise, if one matching Routing Tuple is found: 1707 1. If RERR.errorcode is 0 ("No available route", as specified in 1708 Section 18.1), this matching Routing Tuple is updated as 1709 follows: 1711 + R_valid_time := EXPIRED 1713 Extensions to this specification MAY define additional error 1714 codes in the Error Code IANA registry, and MAY insert 1715 processing rules here for RERRs with that error code. 1717 2. If hop-limit is greater than 0, the RERR message is 1718 considered for forwarding, as specified in Section 14.4 1720 14.4. RERR Forwarding 1722 An RERR is, ultimately, destined for the LOADng Router which has, in 1723 either its Destination Address Set or in its Local Interface Set, the 1724 address from RERR.originator. 1726 An RERR, considered for forwarding is therefore processed as follows: 1728 1. RERR.hop-limit := hop-limit (as set in Section 14.3) 1730 2. Find the Destination Address Tuple (henceforth, matching 1731 Destination Address Tuple) in the Destination Address Set where: 1733 * D_address = RERR.destination 1735 3. If one or more matching Destination Address Tuples are found, the 1736 RERR message is discarded and not retransmitted, as it has 1737 reached the final destination. 1739 4. Otherwise, find the Local Interface Tuple (henceforth, matching 1740 Local Interface Tuple) in the Local Interface Set where: 1742 * I_local_iface_addr_list contains RERR.destination. 1744 5. If a matching Local Interface Tuple is found, the RERR message is 1745 discarded and not retransmitted, as it has reached the final 1746 destination. 1748 6. Otherwise, if no matching Destination Address Tuples or Local 1749 Interface Tuples are found, the RERR message is transmitted 1750 according to Section 14.5. 1752 14.5. RERR Transmission 1754 An RERR is, ultimately, destined for the LOADng Router which has the 1755 address listed in the RERR.destination field in either of its Local 1756 Interface Set, or in its Destination Address Set. The RERR is 1757 forwarded in unicast towards that LOADng Router. The RERR MUST, 1758 however, be transmitted so as to allow it to be processed in each 1759 intermediate LOADng Router to: 1761 o Allow intermediate LOADng Routers to update their Routing Sets, 1762 i.e., remove tuples for this destination. 1764 RERR Transmission is accomplished by the following procedure: 1766 1. Find the Routing Tuple (henceforth, the "Matching Routing Tuple") 1767 in the Routing Set, where: 1769 * R_dest_addr = RERR.destination 1771 2. Find the Local Interface Tuple (henceforth, "Matching Interface 1772 Tuple), where: 1774 * I_local_iface_addr_list contains R_local_iface_addr from the 1775 Matching Routing Tuple 1777 3. The RERR is transmitted over the LOADng Interface, identified by 1778 the Matching Interface Tuple to the neighbor LOADng Router, 1779 identified by R_next_addr from the Matching Routing Tuple. 1781 15. Route Reply Acknowledgments (RREP_ACKs) 1783 A LOADng Router MUST signal in a transmitted RREP that it is 1784 expecting an RREP_ACK, by setting RREP.ackrequired flag in the RREP. 1785 When doing so, the LOADng Router MUST also add a tuple (P_next_hop, 1786 P_originator, P_seq_num, P_ack_timeout) to the Pending Acknowledgment 1787 Set, and set P_ack_timeout to current_time + RREP_ACK_TIMEOUT, as 1788 described in Section 13.4. 1790 The following definition is used in this section: 1792 o "EXPIRED" indicates that a timer is set to a value clearly 1793 preceding the current time (e.g., current_time - 1). 1795 15.1. Identifying Invalid RREP_ACK Messages 1797 A received RREP_ACK is invalid, and MUST be discarded without further 1798 processing, if any of the following conditions are true: 1800 o The address length specified by this message (i.e., RREP_ACK.addr- 1801 length + 1) differs from the length of the address(es) of this 1802 LOADng Router. 1804 A LOADng Router MAY recognize additional reasons, external to this 1805 specification, for identifying that an RREP_ACK message is invalid 1806 for processing, e.g., to allow a security protocol to perform 1807 verification of signatures and prevent processing of unverifiable 1808 RREP_ACK message by this protocol. 1810 15.2. RREP_ACK Generation 1812 Upon reception of an RREP message with the RREP.ackrequired flag set, 1813 a LOADng Router MUST generate at least one RREP_ACK and send this 1814 RREP_ACK in unicast to the neighbor which originated the RREP. 1816 An RREP_ACK message is generated by a LOADng Router with the 1817 following content: 1819 o RREP_ACK.addr-length := the length of the address, as specified in 1820 Section 6; 1822 o RREP_ACK.seq-num := the value of the RREP.seq-num field of the 1823 received RREP; 1825 o RREP_ACK.destination := RREP.originator of the received RREP. 1827 15.3. RREP_ACK Processing 1829 On receiving an RREP_ACK from a LOADng neighbor LOADng Router, a 1830 LOADng Router MUST do the following: 1832 1. If the RREP_ACK is invalid for processing, as defined in 1833 Section 15.1, the RREP_ACK MUST be discarded without further 1834 processing. 1836 2. Find the Routing Tuple (henceforth, Matching Routing Tuple) 1837 where: 1839 * R_dest_addr = previous-hop; 1841 The Matching Routing Tuple is updated as follows: 1843 * R_bidirectional := TRUE 1845 3. If a Pending Acknowledgement Tuple (henceforth, Matching Pending 1846 Acknowledgement Tuple) exists, where: 1848 * P_next_hop is the address of the LOADng Router from which the 1849 RREP_ACK was received. 1851 * P_originator = RREP_ACK.destination 1853 * P_seq_num = RREP_ACK.seq-num 1855 Then the RREP has been acknowledged. The Matching Pending 1856 Acknowledgement Tuple is updated as follows: 1858 * P_ack_received := TRUE 1860 * P_ack_timeout := EXPIRED 1862 15.4. RREP_ACK Forwarding 1864 An RREP_ACK is intended only for a specific direct neighbor, and MUST 1865 NOT be forwarded. 1867 15.5. RREP_ACK Transmission 1869 An RREP_ACK is transmitted, in unicast, to the neighbor LOADng Router 1870 from which the RREP was received. 1872 16. Metrics 1874 This specification enables the use of different metrics for when 1875 calculating route metrics. 1877 Metrics as defined in LOADng are additive, and the routes that are to 1878 be created are those with the minimum sum of the metrics along that 1879 route. 1881 16.1. Specifying New Metrics 1883 When defining a metric, the following considerations SHOULD be taken 1884 into consideration: 1886 o The definition of the R_metric field, as well as the value of 1887 MAX_DIST. 1889 17. Security Considerations 1891 Currently, this protocol does not specify any special security 1892 measures. As a reactive routing protocol, this protocol is a 1893 potential target for various attacks. Various possible 1894 vulnerabilities are discussed in this section. 1896 By way of (i) enabling inclusion of TLVs and (ii) permitting that 1897 LOADng recognizes external reasons for rejecting RREQ, RREP, RREP_ACK 1898 and RERR messages, development of security measures, appropriate for 1899 a given deployment, is however supported. This architecture is a 1900 result of the observation that with respect to security in LOADng 1901 routed networks, "one size rarely fits all". This, as LOADng 1902 deployment domains have varying security requirements ranging from 1903 "unbreakable" to "virtually none", depending on, e.g., physical 1904 access to the network, or on security available on other layers. The 1905 virtue of this approach is that LOADng routing protocol 1906 specifications (and implementations) can remain "generic", with 1907 extensions providing proper deployment-domain specific security 1908 mechanisms. 1910 17.1. Confidentiality 1912 This protocol floods Route Requests (RREQs) to all the LOADng Routers 1913 in the network, when there is traffic to deliver to a given 1914 destination. Hence, if used in an unprotected network (such as an 1915 unprotected wireless network): 1917 o Part of the network topology is revealed to anyone who listens, 1918 specifically (i) the identity (and existence) of the source LOADng 1919 Router; (ii) the identity of the destination; and (iii) the fact 1920 that a path exists between the source LOADng Router and the LOADng 1921 Router from which the RREQ was received. 1923 o The network traffic patterns are revealed to anyone who listens to 1924 the LOADng control traffic, specifically which pairs of devices 1925 communicate. If, for example, a majority of traffic originates 1926 from or terminates in a specific LOADng Router, this may indicate 1927 that this LOADng Router has a central role in the network. 1929 This protocol also unicasts Route Replies (RREPs) from the 1930 destination of an RREQ to the originator of that same RREQ. Hence, 1931 if used in an unprotected network (such as an unprotected wireless 1932 network): 1934 o Part of the network topology is revealed to anyone who is near or 1935 on the unicast path of the RREP (such as within radio range of 1936 LOADng Routers on the unicast path in an unprotected wireless 1937 network), specifically that a path from the originator (of the 1938 RREP) to the destination (of the RREP) exists. 1940 Finally, this protocol unicasts Route Errors (RERRs) when an 1941 intermediate LOADng Router detects that the path from a source to a 1942 destination is no longer available. Hence, if used in an unprotected 1943 network (such as an unprotected wireless network): 1945 o A disruption of the network topology is revealed to anyone who is 1946 near or on the unicast path of the RERR (such as within radio 1947 range of LOADng Routers on the unicast path in an unprotected 1948 wireless network), specifically that a path from the originator 1949 (of the RERR) to the destination (of the RERR) has been disrupted. 1951 This protocol signaling behavior enables, for example, an attacker to 1952 identify central devices in the network (by monitoring RREQs) so as 1953 to target an attack, and (by way of monitoring RERRs) to measure the 1954 success of an attack. 1956 17.2. Integrity 1958 A LOADng Router injects topological information into the network by 1959 way of transmitting RREQ and RREP messages, and removes installed 1960 topological information by way of transmitting RERR messages. If 1961 some LOADng Routers for some reason, malice or malfunction, inject 1962 invalid control traffic, network integrity may be compromised. 1963 Therefore, message authentication is recommended. 1965 Different such situations may occur, for instance: 1967 1. A LOADng Router generates RREQ messages, pretending to be another 1968 LOADng Router; 1970 2. A LOADng Router generates RREP messages, pretending to be another 1971 LOADng Router; 1973 3. A LOADng Router generates RERR messages, pretending to be another 1974 LOADng Router; 1976 4. A LOADng Router generates RERR messages, indicating that a link 1977 on a path to a destination is broken; 1979 5. A LOADng Router forwards altered control messages; 1981 6. A LOADng Router does not forward control messages; 1983 7. A LOADng Router forwards RREPs and RREQs, but does not forward 1984 unicast data traffic; 1986 8. A LOADng Router "replays" previously recorded control messages 1987 from another LOADng Router. 1989 Authentication of the originator LOADng Router for control messages 1990 (for situations 1, 2 and 3) and on individual links announced in the 1991 control message (for situation 2 and 4) may be used as a 1992 countermeasure. However, to prevent routers from repeating old (and 1993 correctly authenticated) information (situation 8), temporal 1994 information is required, requiring a router to positively identify 1995 such a delayed message. 1997 In general, integrity check values and other required security 1998 information may be transmitted as a separate Message Type, or 1999 signatures and security information may be transmitted within the 2000 control messages, using the TLV mechanism. Either option permits 2001 that "secured" and "unsecured" routers can coexist in the same 2002 network, if desired. 2004 Specifically, if LOADng is used on the IP layer, the authenticity of 2005 entire control messages can be established through employing IPsec 2006 authentication headers, whereas authenticity of individual links 2007 (situations 2 and 4) require additional security information to be 2008 distributed. 2010 17.3. Channel Jamming and State Explosion 2012 A reactive protocol, LOADng control messages are generated in 2013 response to network events. For RREQs, such an event is that a data 2014 packet is present in a router which does not have a route to the 2015 destination of the data packet, or that the router receives an RERR 2016 message, invalidating a route. For RREPs, such an event is receipt 2017 of an RREQ corresponding to a destination owned by the LOADng Router. 2018 A router, forwarding an RREQ or an RREP records state, for the 2019 reverse and forward routes, respectively. If some routers for some 2020 reason, malice or malfunction, generates excessive RREQ, RREP or 2021 RERRs, otherwise correctly functioning LOADng Routers may fall victim 2022 to either "indirect jamming" (being "tricked" into generating 2023 excessive control traffic) or an explosion in the state necessary for 2024 maintaining protocol state (potentially, exhausting the available 2025 memory resources). 2027 Different such situations may occur, for instance: 2029 1. A router, within a short time, generates RREQs to an excessive 2030 amount of destinations in the network (possibly all destinations, 2031 possibly even destinations not present in the network), causing 2032 intermediate routers to allocate state for the forward routes. 2034 2. A router generates excessively frequent RREQs to the same 2035 (existing) destination, causing the corresponding LOADng Router 2036 to generate excessive RREPs. 2038 3. A router generates RERRs for a destination to the source LOADng 2039 Router for traffic to that destination, causing that LOADng 2040 Router to flood renewed RREQs. 2042 For situation 1, the state required for recording forward and/or 2043 reverse routes may exceed the memory available in the intermediate 2044 LOADng Routers - to the detriment of being able of recording state 2045 for other routes. This, in particular, if a LOADng Router generates 2046 RREQs for destinations "not present in the network". 2048 A router which, within a short time, generates RREPs to an excessive 2049 amount of destinations in the network (possibly all destinations, 2050 possibly even destinations not present in the network), will not have 2051 the same network-wide effect: an intermediate router receiving an 2052 RREP for a destination for which no reverse route exists will neither 2053 attempt forwarding the RREP nor allocate state for the forward route. 2055 For situations 1, 2, and 3, a possible countermeasure is to rate- 2056 limit the number of control messages that a LOADng Router forwards on 2057 behalf of another LOADng Router. Such a rate limit should take into 2058 consideration the expected normal traffic for a given LOADng 2059 deployment. Authentication may furthermore be used so as to prohibit 2060 a LOADng Router from forwarding control traffic from any non- 2061 authenticated router (with the assumption being that an authenticated 2062 router is not expected to exhibit such rogue behavior). 2064 17.4. Interaction with External Routing Domains 2066 This protocol does provide a basic mechanism for a LOADng Router to 2067 be able to discover routes to external routing domains: a LOADng 2068 Router configured to "own" a given set of addresses will respond to 2069 RREQs for destinations with these addresses, and can - by whatever 2070 protocols governing the routing domain wherein these addresses exist 2071 - provide paths to these addresses. 2073 When operating routers connecting a LOADng domain to an external 2074 routing domain, destinations inside the LOADng domain can be injected 2075 into the external domain, if the routing protocol governing that 2076 domain so permits. Care MUST be taken to not allow potentially 2077 insecure and untrustworthy information to be injected into the 2078 external domain. 2080 In case LOADng is used on the IP layer, a RECOMMENDED way of 2081 extending connectivity from an external routing domain to a LOADng 2082 routed domain is to assign an IP prefix (under the authority of the 2083 routers/gateways connecting the LOADng routing domain with the 2084 external routing domain) exclusively to that LOADng routing domain, 2085 and to statically configure gateways to advertise routes for that 2086 prefix into the external domain. Within the LOADng domain, gateways 2087 SHOULD only generate RREPs for destinations which are not part of 2088 that prefix; this is in particularly important if a gateway otherwise 2089 provides connectivity to "a default route". 2091 18. LOADng Specific IANA Considerations 2093 18.1. Error Codes 2095 IANA is requested to create a new registry for Error Codes, with 2096 initial assignments and allocation policies as specified in Table 1. 2098 +---------+--------------------+-------------------+ 2099 | Code | Description | Allocation Policy | 2100 +---------+--------------------+-------------------+ 2101 | 0 | No available route | | 2102 | 1-251 | Unassigned | Expert Review | 2103 | 252-255 | Unassigned | Experimental Use | 2104 +---------+--------------------+-------------------+ 2106 Table 1: Error Codes 2108 19. Contributors 2110 This specification is the result of the joint efforts of the 2111 following contributors - listed alphabetically. 2113 o Alberto Camacho, LIX, France, 2115 o Thomas Heide Clausen, LIX, France, 2117 o Axel Colin de Verdiere, LIX, France, 2119 o Kenneth Garey, Maxim Integrated Products, USA, 2120 2122 o Ulrich Herberg, Fujitsu Laboratories of America, USA 2123 2125 o Yuichi Igarashi, Hitachi Ltd, Yokohama Research Laboratory, Japan, 2126 2128 o Cedric Lavenu, EDF R&D, France, 2130 o Afshin Niktash, Maxim Integrated Products, USA, 2131 2133 o Charles E. Perkins, Futurewei Inc, USA, 2135 o Hiroki Satoh, Hitachi Ltd, Yokohama Research Laboratory, Japan, 2136 2138 o Thierry Lys, ERDF, France, 2140 o Jiazi Yi, LIX, France, 2142 20. Acknowledgments 2144 The authors would like to acknowledge the team behind AODV [RFC3561]. 2145 The authors would also like to acknowledge the efforts of K. Kim 2146 (picosNet Corp/Ajou University), S. Daniel Park (Samsung 2147 Electronics), G. Montenegro (Microsoft Corporation), S. Yoo (Ajou 2148 University) and N. Kushalnagar (Intel Corp.) for their work on an 2149 initial version of a specification, from which this protocol is 2150 derived. 2152 21. References 2154 21.1. Normative References 2156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2157 Requirement Levels", RFC 2119, BCP 14, March 1997. 2159 [RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, 2160 "Generalized Mobile Ad Hoc Network (MANET) Packet/ 2161 Message Format", RFC 5444, February 2009. 2163 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc 2164 Network (MANET) Protocols", RFC 5498, March 2009. 2166 21.2. Informative References 2168 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc 2169 On-Demand Distance Vector (AODV) Routing", RFC 3561, 2170 July 2003. 2172 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 2173 Soliman, "Neighbor Discovery for IP version 6 2174 (IPv6)", RFC 4861, September 2007. 2176 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. 2177 Culler, "Transmission of IPv6 Packets over IEEE 2178 802.15.4 Networks", RFC 4944, September 2007. 2180 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2181 Considerations in Mobile Ad Hoc Networks (MANETs)", 2182 RFC 5148, February 2008. 2184 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 2185 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 2186 April 2011. 2188 [RFC6206] Levis, P., Clausen, T., Gnawali, O., and J. Ko, "The 2189 Trickle Algorithm", RFC 6206, March 2011. 2191 [RFC6621] Macker, J., "Simplified Multicast Forwarding", 2192 RFC 6621, May 2012. 2194 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier 2195 (EUI-64) Registration Authority". 2197 [IEEE754-2008] IEEE, "IEEE 754-2008: IEEE Standard for Floating- 2198 Point Arithmetic", 2008. 2200 Appendix A. LOADng Control Messages using RFC5444 2202 This section presents how the abstract LOADng messages, used 2203 throughout this specification, are mapped into [RFC5444] messages. 2205 A.1. RREQ-Specific Message Encoding Considerations 2207 This protocol defines, and hence owns, the RREQ Message Type. Thus, 2208 as specified in [RFC5444], this protocol generates and transmits all 2209 RREQ messages, receives all RREQ messages and is responsible for 2210 determining whether and how each RREQ message is to be processed 2211 (updating the Information Base) and/or forwarded, according to this 2212 specification. Table 2 specifies how RREQ messages are mapped into 2213 [RFC5444]-elements. 2215 +-------------------+-------------------+---------------------------+ 2216 | RREQ Element | RFC5444-Element | Considerations | 2217 +-------------------+-------------------+---------------------------+ 2218 | RREQ.addr-length | | Supports addresses from | 2219 | | | 1-16 octets | 2220 | RREQ.seq-num | | 16 bits, hence MAXVALUE | 2221 | | | (Section 8) is 65535. | 2222 | | | MUST be included | 2223 | RREQ.metric-type | METRIC Message | Encoded by way of the | 2224 | | TLV | Type-Extension of a | 2225 | | | Message-Type-specific | 2226 | | | Message TLV of type | 2227 | | | METRIC, defined in | 2228 | | | Table 8. A LOADng Router | 2229 | | | generating an RREQ (as | 2230 | | | specified in | 2231 | | | Section 12.1) when using | 2232 | | | the HOP_COUNT metric, | 2233 | | | MUST NOT add the METRIC | 2234 | | | Message TLV to the RREQ | 2235 | | | (in order to reduce | 2236 | | | overhead, as the hop | 2237 | | | count value is already | 2238 | | | encoded in | 2239 | | | RREQ.hop-count). LOADng | 2240 | | | Routers receiving an RREQ | 2241 | | | without METRIC Message | 2242 | | | TLV assume that | 2243 | | | RREQ.metric-type is | 2244 | | | HOP_COUNT, and MUST not | 2245 | | | add the METRIC Message | 2246 | | | TLV when forwarding the | 2247 | | | message. Otherwise, | 2248 | | | exactly one METRIC TLV | 2249 | | | MUST be included in each | 2250 | | | RREQ message. | 2251 | RREQ.route-metric | METRIC Message | Encoded as the value | 2252 | | TLV value | field of the METRIC TLV. | 2253 | | | (LOADng Routers | 2254 | | | generating RREQs when | 2255 | | | using the HOP_COUNT | 2256 | | | metric do not need need | 2257 | | | to add the METRIC Message | 2258 | | | TLV, as specified above | 2259 | | | for the RREQ.metric-type | 2260 | | | field.) | 2261 | RREQ.hop-limit | | 8 bits. MUST be included | 2262 | | | in an RREQ message | 2263 | RREQ.hop-count | | 8 bits, hence | 2264 | | | MAX_HOP_COUNT is 255. | 2265 | | | MUST be included in an | 2266 | | | RREQ message. | 2267 | RREQ.originator | | MUST be included in an | 2268 | | | RREQ message. | 2269 | RREQ.destination | Address in | Encoded by way of an | 2270 | | Address-Block | address in an address | 2271 | | w/TLV | block, with which a | 2272 | | | Message-Type-specific | 2273 | | | Address Block TLV of type | 2274 | | | ADDR-TYPE and with | 2275 | | | Type-Extension | 2276 | | | DESTINATION is | 2277 | | | associated, defined in | 2278 | | | Table 9. An RREQ MUST | 2279 | | | contain exactly one | 2280 | | | address with a TLV of | 2281 | | | type ADDR-TYPE and with | 2282 | | | Type-Extension | 2283 | | | DESTINATION associated. | 2284 +-------------------+-------------------+---------------------------+ 2286 Table 2: RREQ Message Elements 2288 A.2. RREP-Specific Message Encoding Considerations 2290 This protocol defines, and hence owns, the RREP Message Type. Thus, 2291 as specified in [RFC5444], this protocol generates and transmits all 2292 RREP messages, receives all RREP messages and is responsible for 2293 determining whether and how each RREP message is to be processed 2294 (updating the Information Base) and/or forwarded, according to this 2295 specification. Table 3 describes how RREP messages are mapped into 2296 [RFC5444]-elements. 2298 +-------------------+-------------------+---------------------------+ 2299 | RREP Element | RFC5444-Element | Considerations | 2300 +-------------------+-------------------+---------------------------+ 2301 | RREP.addr-length | | Supports addresses from | 2302 | | | 1-16 octets | 2303 | RREP.seq-num | | 16 bits, hence MAXVALUE | 2304 | | | (Section 8) is 65535. | 2305 | | | MUST be included | 2306 | RREP.metric-type | METRIC Message | Encoded by way of the | 2307 | | TLV | Type-Extension of a | 2308 | | | Message-Type-specific | 2309 | | | Message TLV of type | 2310 | | | METRIC, defined in | 2311 | | | Table 12. A LOADng | 2312 | | | Router generating an RREP | 2313 | | | (as specified in | 2314 | | | Section 13.1) when using | 2315 | | | the HOP_COUNT metric, | 2316 | | | MUST NOT add the METRIC | 2317 | | | Message TLV to the RREP | 2318 | | | (in order to reduce | 2319 | | | overhead, as the hop | 2320 | | | count value is already | 2321 | | | encoded in | 2322 | | | RREP.hop-count). LOADng | 2323 | | | Routers receiving an RREP | 2324 | | | without METRIC Message | 2325 | | | TLV assume that | 2326 | | | RREP.metric-type is | 2327 | | | HOP_COUNT, and MUST not | 2328 | | | add the METRIC Message | 2329 | | | TLV when forwarding the | 2330 | | | message. Otherwise, | 2331 | | | exactly one METRIC TLV | 2332 | | | MUST be included in each | 2333 | | | RREP message. | 2334 | RREP.route-metric | METRIC Message | Encoded as the value | 2335 | | TLV value | field of the METRIC TLV. | 2336 | | | (LOADng Routers | 2337 | | | generating RREPs when | 2338 | | | using the HOP_COUNT | 2339 | | | metric do not need need | 2340 | | | to add the METRIC Message | 2341 | | | TLV, as specified above | 2342 | | | for the RREP.metric-type | 2343 | | | field.) | 2344 | RREP.ackrequired | FLAGS Message TLV | Encoded by way of a | 2345 | | | Message-Type-specific | 2346 | | | Message TLV of type | 2347 | | | FLAGS, defined in | 2348 | | | Table 13. A TLV of type | 2349 | | | FLAGS MUST always be | 2350 | | | included in an RREP | 2351 | | | message. | 2352 | RREP.hop-limit | | 8 bits. MUST be included | 2353 | | | in an RREQ message | 2354 | RREP.hop-count | | 8 bits, hence | 2355 | | | MAX_HOP_COUNT is 255. | 2356 | | | MUST be included in an | 2357 | | | RREP message. | 2358 | RREP.originator | | MUST be included in an | 2359 | | | RREP message. | 2360 | RREP.destination | Address in | Encoded by way of an | 2361 | | Address-Block | address in an address | 2362 | | w/TLV | block, with which a | 2363 | | | Message-Type-specific | 2364 | | | Address Block TLV of type | 2365 | | | ADDR-TYPE and with | 2366 | | | Type-Extension | 2367 | | | DESTINATION is | 2368 | | | associated, defined in | 2369 | | | Table 14. An RREP MUST | 2370 | | | contain exactly one | 2371 | | | address with a TLV of | 2372 | | | type ADDR-TYPE and with | 2373 | | | Type-Extension | 2374 | | | DESTINATION associated. | 2375 +-------------------+-------------------+---------------------------+ 2377 Table 3: RREP Message Elements 2379 A.3. RREP_ACK Message Encoding 2381 This protocol defines, and hence owns, the RREP_ACK Message Type. 2382 Thus, as specified in [RFC5444], this protocol generates and 2383 transmits all RREP_ACK messages, receives all RREP_ACK messages and 2384 is responsible for determining whether and how each RREP_ACK message 2385 is to be processed (updating the Information Base), according to this 2386 specification. Table 4 describes how RREP_ACK Messages are mapped 2387 into [RFC5444]-elements. 2389 +----------------------+-------------------+------------------------+ 2390 | RREP_ACK Element | RFC5444-Element | Considerations | 2391 +----------------------+-------------------+------------------------+ 2392 | RREP_ACK.addr-length | | Supports addresses | 2393 | | | from 1-16 octets | 2394 | RREP_ACK.seq-num | | 16 bits, hence | 2395 | | | MAXVALUE (Section 8) | 2396 | | | is 65535. MUST be | 2397 | | | included | 2398 | RREP_ACK.destination | Address in | Encoded by way of an | 2399 | | Address-Block | address in an address | 2400 | | w/TLV | block, with which a | 2401 | | | Message-Type-specific | 2402 | | | Address Block TLV of | 2403 | | | type ADDR-TYPE and | 2404 | | | with Type-Extension | 2405 | | | DESTINATION is | 2406 | | | associated, defined in | 2407 | | | Table 17. An RREP_ACK | 2408 | | | MUST contain exactly | 2409 | | | one address with a TLV | 2410 | | | of type ADDR-TYPE and | 2411 | | | with Type-Extension | 2412 | | | DESTINATION | 2413 | | | associated. | 2414 +----------------------+-------------------+------------------------+ 2416 Table 4: RREP_ACK Message Elements 2418 A.4. RERR Message Encoding 2420 This protocol defines, and hence owns, the RERR Message Type. Thus, 2421 as specified in [RFC5444], this protocol generates and transmits all 2422 RERR messages, receives all RERR messages and is responsible for 2423 determining whether and how each RERR message is to be processed 2424 (updating the Information Base) and/or forwarded, according to this 2425 specification. Table 5 describes how RERR Messages are mapped into 2426 [RFC5444]-elements. 2428 +------------------------+------------------+-----------------------+ 2429 | RERR Element | RFC5444-Element | Considerations | 2430 +------------------------+------------------+-----------------------+ 2431 | RERR.addr-length | | from 1-16 octets | 2433 | RERR.hop-limit | | 8 bits. MUST be | 2434 | | | included in an RREQ | 2435 | | | message | 2436 | RERR.errorcode | Address Block | According to | 2437 | | TLV Value | Section 18.1. | 2438 | RERR.unreachableAddres | Address in | Encoded by way of an | 2439 | s | Address-Block | address in an address | 2440 | | w/TLV | block, with which a | 2441 | | | Message-Type-specific | 2442 | | | Address Block TLV of | 2443 | | | type ADDR-TYPE and | 2444 | | | with Type-Extension | 2445 | | | ERRORCODE is | 2446 | | | associated, defined | 2447 | | | in Table 20. | 2448 | RERR.originator | | MUST be included in | 2449 | | | an RERR message. | 2450 | RERR.destination | Address in | Encoded by way of an | 2451 | | Address-Block | address in an address | 2452 | | w/TLV | block, with which a | 2453 | | | Message-Type-specific | 2454 | | | Address Block TLV of | 2455 | | | type ADDR-TYPE and | 2456 | | | with Type-Extension | 2457 | | | DESTINATION is | 2458 | | | associated, defined | 2459 | | | in Table 20. An RERR | 2460 | | | MUST contain exactly | 2461 | | | one address with a | 2462 | | | TLV of type ADDR-TYPE | 2463 | | | and with | 2464 | | | Type-Extension | 2465 | | | DESTINATION | 2466 | | | associated. | 2467 +------------------------+------------------+-----------------------+ 2469 Table 5: RERR Message Elements 2471 A.5. RFC5444-Specific IANA Considerations 2473 This specification defines four Message Types, which must be 2474 allocated from the "Message Types" repository of [RFC5444], two 2475 Message TLV Types, which must be allocated from the "Message TLV 2476 Types" repository of [RFC5444], and four Address Block TLV Types, 2477 which must be allocated from the "Address Block TLV Types" repository 2478 of [RFC5444]. 2480 A.5.1. Expert Review: Evaluation Guidelines 2482 For the registries where an Expert Review is required, the designated 2483 expert should take the same general recommendations into 2484 consideration as are specified by [RFC5444]. 2486 A.5.2. Message Types 2488 This specification defines four Message Type, to be allocated from 2489 the 0-223 range of the "Message Types" namespace defined in 2490 [RFC5444], as specified in Table 6. 2492 +------+-----------------------------------------------+ 2493 | Type | Description | 2494 +------+-----------------------------------------------+ 2495 | TBD1 | RREQ: Route Request Message | 2496 | TBD1 | RREP: Route Reply Message | 2497 | TBD1 | RREP_ACK: Route Reply Acknowledgement Message | 2498 | TBD1 | RERR: Route Error Message | 2499 +------+-----------------------------------------------+ 2501 Table 6: Message Type assignment 2503 A.6. RREQ Message-Type-Specific TLV Type Registries 2505 IANA is requested to create a registry for Message-Type-specific 2506 Message TLVs for RREQ messages, in accordance with Section 6.2.1 of 2507 [RFC5444], and with initial assignments and allocation policies as 2508 specified in Table 7. 2510 +---------+-------------+-------------------+ 2511 | Type | Description | Allocation Policy | 2512 +---------+-------------+-------------------+ 2513 | 128 | METRIC | | 2514 | 129-223 | Unassigned | Expert Review | 2515 +---------+-------------+-------------------+ 2517 Table 7: RREQ Message-Type-specific Message TLV Types 2519 Allocation of the METRIC TLV from the RREQ Message-Type-specific 2520 Message TLV Types in Table 7 will create a new Type Extension 2521 registry, with assignments as specified in Table 8. 2523 +--------+------+-----------+------------------------+--------------+ 2524 | Name | Type | Type | Description | Allocation | 2525 | | | Extension | | Policy | 2526 +--------+------+-----------+------------------------+--------------+ 2527 | METRIC | 128 | 0 | HOP_COUNT: | | 2528 | | | | MSG.hop-count is used | | 2529 | | | | instead of the METRIC | | 2530 | | | | TLV Value. MAX_DIST | | 2531 | | | | is 255. | | 2532 | METRIC | 128 | 1 | DIMENSIONLESS: A | | 2533 | | | | 32-bit, dimensionless, | | 2534 | | | | additive metric, | | 2535 | | | | single precision | | 2536 | | | | float, formatted | | 2537 | | | | according to | | 2538 | | | | [IEEE754-2008]. | | 2539 | METRIC | 128 | 2-251 | Unassigned | Expert | 2540 | | | | | Review | 2541 | METRIC | 128 | 252-255 | Unassigned | Experimental | 2542 +--------+------+-----------+------------------------+--------------+ 2544 Table 8: Message TLV Type assignment: METRIC 2546 IANA is requested to create a registry for Message-Type-specific 2547 Address Block TLVs for RREQ messages, in accordance with Section 2548 6.2.1 of [RFC5444], and with initial assignments and allocation 2549 policies as specified in Table 9. 2551 +---------+-------------+-------------------+ 2552 | Type | Description | Allocation Policy | 2553 +---------+-------------+-------------------+ 2554 | 128 | ADDR-TYPE | Expert Review | 2555 | 129-223 | Unassigned | Expert Review | 2556 +---------+-------------+-------------------+ 2558 Table 9: RREQ Message-Type-specific Address Block TLV Types 2560 Allocation of the ADDR-TYPE TLV from the RREQ Message-Type-specific 2561 Address Block TLV Types in Table 9 will create a new Type Extension 2562 registry, with assignments as specified in Table 10. 2564 +-----------+------+----------------+-------------+-----------------+ 2565 | Name | Type | Type Extension | Description | Allocation | 2566 | | | | | Policy | 2567 +-----------+------+----------------+-------------+-----------------+ 2568 | ADDR-TYPE | 128 | 0 | DESTINATION | | 2569 | ADDR-TYPE | 128 | 2-255 | Unassigned | Expert Review | 2570 +-----------+------+----------------+-------------+-----------------+ 2572 Table 10: Address Block TLV Type assignment: ADDR-TYPE 2574 A.7. RREP Message-Type-Specific TLV Type Registries 2576 IANA is requested to create a registry for Message-Type-specific 2577 Message TLVs for RREP messages, in accordance with Section 6.2.1 of 2578 [RFC5444], and with initial assignments and allocation policies as 2579 specified in Table 11. 2581 +---------+-------------+-------------------+ 2582 | Type | Description | Allocation Policy | 2583 +---------+-------------+-------------------+ 2584 | 128 | METRIC | | 2585 | 129 | FLAGS | | 2586 | 130-223 | Unassigned | Expert Review | 2587 +---------+-------------+-------------------+ 2589 Table 11: RREP Message-Type-specific Message TLV Types 2591 Allocation of the METRIC TLV from the RREP Message-Type-specific 2592 Message TLV Types in Table 11 will create a new Type Extension 2593 registry, with assignments as specified in Table 12. 2595 +--------+------+-----------+------------------------+--------------+ 2596 | Name | Type | Type | Description | Allocation | 2597 | | | Extension | | Policy | 2598 +--------+------+-----------+------------------------+--------------+ 2599 | METRIC | 128 | 0 | HOP_COUNT: | | 2600 | | | | MSG.hop-count is used | | 2601 | | | | instead of the METRIC | | 2602 | | | | TLV Value. MAX_DIST | | 2603 | | | | is 255. | | 2604 | METRIC | 128 | 1 | DIMENSIONLESS: A | | 2605 | | | | 32-bit, dimensionless, | | 2606 | | | | additive metric, | | 2607 | | | | single precision | | 2608 | | | | float, formatted | | 2609 | | | | according to | | 2610 | | | | [IEEE754-2008]. | | 2611 | METRIC | 128 | 2-251 | Unassigned | Expert | 2612 | | | | | Review | 2613 | METRIC | 128 | 252-255 | Unassigned | Experimental | 2614 +--------+------+-----------+------------------------+--------------+ 2616 Table 12: Message TLV Type assignment: METRIC 2618 Allocation of the FLAGS TLV from the RREP Message-Type-specific 2619 Message TLV Types in Table 11 will create a new Type Extension 2620 registry, with assignments as specified in Table 13. 2622 +-------+------+-----------+---------------------------+------------+ 2623 | Name | Type | Type | Description | Allocation | 2624 | | | Extension | | Policy | 2625 +-------+------+-----------+---------------------------+------------+ 2626 | FLAGS | 129 | 0 | Bit 0 represents the | | 2627 | | | | ackrequired flag (i.e., | | 2628 | | | | ackrequired is TRUE when | | 2629 | | | | bit 0 is set to 1 and | | 2630 | | | | FALSE when bit 0 is 0.). | | 2631 | | | | All other bits are | | 2632 | | | | reserved for future use. | | 2633 | FLAGS | 129 | 1-255 | Unassigned | Expert | 2634 | | | | | Review | 2635 +-------+------+-----------+---------------------------+------------+ 2637 Table 13: Message TLV Type assignment: FLAGS 2639 IANA is requested to create a registry for Message-Type-specific 2640 Address Block TLVs for RREP messages, in accordance with Section 2641 6.2.1 of [RFC5444], and with initial assignments and allocation 2642 policies as specified in Table 14. 2644 +---------+-------------+-------------------+ 2645 | Type | Description | Allocation Policy | 2646 +---------+-------------+-------------------+ 2647 | 128 | ADDR-TYPE | Expert Review | 2648 | 129-223 | Unassigned | Expert Review | 2649 +---------+-------------+-------------------+ 2651 Table 14: RREP Message-Type-specific Address Block TLV Types 2653 Allocation of the ADDR-TYPE TLV from the RREP Message-Type-specific 2654 Address Block TLV Types in Table 14 will create a new Type Extension 2655 registry, with assignments as specified in Table 15. 2657 +-----------+------+----------------+-------------+-----------------+ 2658 | Name | Type | Type Extension | Description | Allocation | 2659 | | | | | Policy | 2660 +-----------+------+----------------+-------------+-----------------+ 2661 | ADDR-TYPE | 128 | 0 | DESTINATION | | 2662 | ADDR-TYPE | 128 | 1-255 | Unassigned | Expert Review | 2663 +-----------+------+----------------+-------------+-----------------+ 2665 Table 15: Address Block TLV Type assignment: ADDR-TYPE 2667 A.8. RREP_ACK Message-Type-Specific TLV Type Registries 2669 IANA is requested to create a registry for Message-Type-specific 2670 Message TLVs for RREP_ACK messages, in accordance with Section 6.2.1 2671 of [RFC5444], and with initial assignments and allocation policies as 2672 specified in Table 16. 2674 +---------+-------------+-------------------+ 2675 | Type | Description | Allocation Policy | 2676 +---------+-------------+-------------------+ 2677 | 128-223 | Unassigned | Expert Review | 2678 +---------+-------------+-------------------+ 2680 Table 16: RREP_ACK Message-Type-specific Message TLV Types 2682 IANA is requested to create a registry for Message-Type-specific 2683 Address Block TLVs for RREP_ACK messages, in accordance with Section 2684 6.2.1 of [RFC5444], and with initial assignments and allocation 2685 policies as specified in Table 17. 2687 +---------+-------------+-------------------+ 2688 | Type | Description | Allocation Policy | 2689 +---------+-------------+-------------------+ 2690 | 128 | ADDR-TYPE | Expert Review | 2691 | 129-223 | Unassigned | Expert Review | 2692 +---------+-------------+-------------------+ 2694 Table 17: RREP_ACK Message-Type-specific Address Block TLV Types 2696 Allocation of the ADDR-TYPE TLV from the RREP_ACK Message-Type- 2697 specific Address Block TLV Types in Table 17 will create a new Type 2698 Extension registry, with assignments as specified in Table 18. 2700 +-----------+------+----------------+-------------+-----------------+ 2701 | Name | Type | Type Extension | Description | Allocation | 2702 | | | | | Policy | 2703 +-----------+------+----------------+-------------+-----------------+ 2704 | ADDR-TYPE | 128 | 0 | DESTINATION | | 2705 | ADDR-TYPE | 128 | 2-255 | Unassigned | Expert Review | 2706 +-----------+------+----------------+-------------+-----------------+ 2708 Table 18: Address Block TLV Type assignment: ADDR-TYPE 2710 A.9. RERR Message-Type-Specific TLV Type Registries 2712 IANA is requested to create a registry for Message-Type-specific 2713 Message TLVs for RERR messages, in accordance with Section 6.2.1 of 2714 [RFC5444], and with initial assignments and allocation policies as 2715 specified in Table 19. 2717 +---------+-------------+-------------------+ 2718 | Type | Description | Allocation Policy | 2719 +---------+-------------+-------------------+ 2720 | 128-223 | Unassigned | Expert Review | 2721 +---------+-------------+-------------------+ 2723 Table 19: RERR Message-Type-specific Message TLV Types 2725 IANA is requested to create a registry for Message-Type-specific 2726 Address Block TLVs for RERR messages, in accordance with Section 2727 6.2.1 of [RFC5444], and with initial assignments and allocation 2728 policies as specified in Table 20. 2730 +---------+-------------+-------------------+ 2731 | Type | Description | Allocation Policy | 2732 +---------+-------------+-------------------+ 2733 | 128 | ADDR-TYPE | Expert Review | 2734 | 129-223 | Unassigned | Expert Review | 2735 +---------+-------------+-------------------+ 2737 Table 20: RREP_ACK Message-Type-specific Address Block TLV Types 2739 Allocation of the ADDR-TYPE TLV from the RERR Message-Type-specific 2740 Address Block TLV Types in Table 20 will create a new Type Extension 2741 registry, with assignments as specified in Table 21. 2743 +-----------+------+----------------+-------------+-----------------+ 2744 | Name | Type | Type Extension | Description | Allocation | 2745 | | | | | Policy | 2746 +-----------+------+----------------+-------------+-----------------+ 2747 | ADDR-TYPE | 128 | 0 | DESTINATION | | 2748 | ADDR-TYPE | 128 | 1 | ERRORCODE | | 2749 | ADDR-TYPE | 128 | 2-255 | Unassigned | Expert Review | 2750 +-----------+------+----------------+-------------+-----------------+ 2752 Table 21: Address Block TLV Type assignment: ADDR-TYPE 2754 Appendix B. LOADng Control Packet Illustrations 2756 This section presents example packets following this specification. 2758 B.1. RREQ 2760 RREQ messages are instances of [RFC5444] messages. This 2761 specification requires that RREQ messages contain RREQ.msg-seq-num, 2762 RREQ.msg-hop-limit, RREQ.msg-hop-count and RREQ.msg-orig-addr fields. 2764 It supports RREQ messages with any combination of remaining message 2765 header options and address encodings, enabled by [RFC5444] that 2766 convey the required information. As a consequence, there is no 2767 single way to represent how all RREQ messages look. This section 2768 illustrates an RREQ message, the exact values and content included 2769 are explained in the following text. 2771 The RREQ message's four bit Message Flags (MF) field has value 15 2772 indicating that the message header contains originator address, hop 2773 limit, hop count, and message sequence number fields. Its four bit 2774 Message Address Length (MAL) field has value 3, indicating addresses 2775 in the message have a length of four octets, here being IPv4 2776 addresses. The overall message length is 30 octets. 2778 The message has a Message TLV Block with content length 6 octets 2779 containing one TLV. The TLVs is of type METRIC and has a Flags octet 2780 (MTLVF) value 144, indicating that it has a Value, a type extension, 2781 but no start and stop indexes. The Value Length of the METRIC TLV is 2782 2 octets. 2784 The message has one Address Block. The Address Block contains 1 2785 address, with Flags octet (ATLVF) value 0, hence with no Head or Tail 2786 sections, and hence with a Mid section with length four octets. The 2787 following TLV Block (content length 2 octets) contains one TLV. The 2788 TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating 2789 no Value and no indexes. Thus, the address is associated with the 2790 Type ADDR_TYPE, i.e., it is the destination address of the RREQ. 2792 0 1 2 3 2793 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 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | RREQ | MF=15 | MAL=3 | Message Length = 30 | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | Originator Address | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | Hop Limit | Hop Count | Message Sequence Number | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 | Message TLV Block Length = 6 | METRIC | MTLVF = 144 | 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 | Type Ext. | Value Len = 2 | Value (metric) | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | Num Addrs = 1 | ABF = 0 | Mid | 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | Mid | Address TLV Block Length = 2 | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | ADDR-TYPE | ATLVF = 0 | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 B.2. RREP 2814 RREP messages are instances of [RFC5444] messages. This 2815 specification requires that RREP messages contain RREP.msg-seq-num, 2816 RREP.msg-hop-limit, RREP.msg-hop-count and RREP.msg-orig-addr fields. 2817 It supports RREP messages with any combination of remaining message 2818 header options and address encodings, enabled by [RFC5444] that 2819 convey the required information. As a consequence, there is no 2820 single way to represent how all RREP messages look. This section 2821 illustrates an RREP message, the exact values and content included 2822 are explained in the following text. 2824 The RREP message's four bit Message Flags (MF) field has value 15 2825 indicating that the message header contains originator address, hop 2826 limit, hop count, and message sequence number fields. Its four bit 2827 Message Address Length (MAL) field has value 3, indicating addresses 2828 in the message have a length of four octets, here being IPv4 2829 addresses. The overall message length is 34 octets. 2831 The message has a Message TLV Block with content length 10 octets 2832 containing two TLVs. The first TLV is of type METRIC and has a Flags 2833 octet (MTLVF) value 144, indicating that it has a Value, a type 2834 extension, but no start and stop indexes. The Value Length of the 2835 METRIC TLV is 2 octets. The second TLV is of type FLAGS and has a 2836 Flags octet (MTLVF) value of 16, indicating that it has a Value, but 2837 no type extension or start and stop indexes. The Value Length of the 2838 FLAGS TLV is 1 octet. The TLV value is 0x80 indicating that the 2839 ackrequired flag is set. 2841 The message has one Address Block. The Address Block contains 1 2842 address, with Flags octet (ATLVF) value 0, hence with no Head or Tail 2843 sections, and hence with a Mid section with length four octets. The 2844 following TLV Block (content length 2 octets) contains one TLV. The 2845 TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating 2846 no Value and no indexes. Thus, the address is associated with the 2847 Type ADDR_TYPE, i.e., it is the destination address of the RREP. 2849 0 1 2 3 2850 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 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | RREP | MF=15 | MAL=3 | Message Length = 34 | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Originator Address | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | Hop Limit | Hop Count | Message Sequence Number | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Message TLV Block Length = 10 | METRIC | MTLVF = 144 | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | Type Ext. | Value Len = 2 | Value (metric) | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | FLAGS | MTLVF = 16 | Value Len = 1 | Value (0x80) | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | Num Addrs = 1 | ABF = 0 | Mid | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | Mid | Address TLV Block Length = 2 | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | ADDR-TYPE | ATLVF = 0 | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 B.3. RREP_ACK 2873 RREP_ACK messages are instances of [RFC5444] messages. This 2874 specification requires that RREP_ACK messages contains RREP_ACK.msg- 2875 seq-num. It supports RREP_ACK messages with any combination of 2876 remaining message header options and address encodings, enabled by 2877 [RFC5444] that convey the required information. As a consequence, 2878 there is no single way to represent how all RREP_ACK messages look. 2879 This section illustrates an RREP_ACK message, the exact values and 2880 content included are explained in the following text. 2882 The RREP_ACK message's four bit Message Flags (MF) field has value 1 2883 indicating that the message header contains the message sequence 2884 number field. Its four bit Message Address Length (MAL) field has 2885 value 3, indicating addresses in the message have a length of four 2886 octets, here being IPv4 addresses. The overall message length is 18 2887 octets. 2889 The message has a Message TLV Block with content length 0 octets 2890 containing zero TLVs. 2892 The message has one Address Block. The Address Block contains 1 2893 address, with Flags octet (ATLVF) value 0, hence with no Head or Tail 2894 sections, and hence with a Mid section with length four octets. The 2895 following TLV Block (content length 2 octets) contains one TLV. The 2896 TLV is an ADDR_TYPE TLV with Flags octet (ATLVF) value 0, indicating 2897 no Value and no indexes. Thus, the address is associated with the 2898 Type ADDR_TYPE, i.e., it is the destination address of the RREP_ACK. 2900 0 1 2 3 2901 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 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | RREP_ACK | MF=1 | MAL=3 | Message Length = 18 | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 | Message Sequence Number | Message TLV Block Length = 0 | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | Num Addrs = 1 | ABF = 0 | Mid | 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 | Mid | Address TLV Block Length = 2 | 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 | ADDR-TYPE | ATLVF = 0 | 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 B.4. RERR 2916 RERR messages are instances of [RFC5444] messages. This 2917 specification supports RERR messages with any combination of message 2918 header options and address encodings, enabled by [RFC5444] that 2919 convey the required information. As a consequence, there is no 2920 single way to represent how all RERR messages look. This section 2921 illustrates an RERR message, the exact values and content included 2922 are explained in the following text. 2924 The RERR message's four bit Message Flags (MF) field has value 12 2925 indicating that the message header contains RERR.msg-orig-addr field 2926 and RERR.msg-hop-limit field. Its four bit Message Address Length 2927 (MAL) field has value 3, indicating addresses in the message have a 2928 length of four octets, here being IPv4 addresses. The overall 2929 message length is 30 octets. 2931 The message has a Message TLV Block with content length 0 octets 2932 containing zero TLVs. 2934 The message has one Address Block. The Address Block contains 2 2935 addresses, with Flags octet (ATLVF) value 128, hence with a Head 2936 section (with length 3 octets), but no Tail section, and hence with 2937 Mid sections with length one octet. The following TLV Block (content 2938 length 9 octets) contains two TLVs. The first TLV is an ADDR_TYPE 2939 TLV with Flags octet (ATLVF) value 64, indicating a single index of 2940 0, but no Value. Thus, the first address is associated with the Type 2941 ADDR_TYPE and Type Extension DESTINATION, i.e., it is the destination 2942 address of the RERR. The second TLV is an ADDR_TYPE TLV with Flags 2943 octet (ATLVF) value 208, indicating Type Extension, Value, and single 2944 index. Thus, the second address is associated with the Type 2945 ADDR_TYPE, Type Extension ERRORCODE, and Value 0, i.e., it is 2946 associated with error code 0. 2948 0 1 2 3 2949 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 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | RERR | MF=12 | MAL=3 | Message Length = 30 | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | Originator Address | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | Hop Limit | Message TLV Block Length = 0 | Num Addrs = 2 | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | ABF = 128 | Head Len = 3 | Head | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 | Head | Mid | Address TLV | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 |Block Length= 9| ADDR-TYPE | ATLVF = 64 | Index = 0 | 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 | ADDR-TYPE | ATLVF = 208 |TypEx=ERRORCODE| Index = 1 | 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Value Len = 1 | Value = 0 | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 Authors' Addresses 2970 Thomas Heide Clausen 2971 LIX, Ecole Polytechnique 2973 Phone: +33 6 6058 9349 2974 EMail: T.Clausen@computer.org 2975 URI: http://www.ThomasClausen.org/ 2977 Axel Colin de Verdiere 2978 LIX, Ecole Polytechnique 2980 Phone: +33 6 1264 7119 2981 EMail: axel@axelcdv.com 2982 URI: http://www.axelcdv.com/ 2983 Jiazi Yi 2984 LIX, Ecole Polytechnique 2986 Phone: +33 1 6933 4031 2987 EMail: jiazi@jiaziyi.com 2988 URI: http://www.jiaziyi.com/ 2990 Afshin Niktash 2991 Maxim Integrated Products 2993 Phone: +1 94 9450 1692 2994 EMail: afshin.niktash@maxim-ic.com 2995 URI: http://www.Maxim-ic.com/ 2997 Yuichi Igarashi 2998 Hitachi, Ltd., Yokohama Research Laboratory 3000 Phone: +81 45 860 3083 3001 EMail: yuichi.igarashi.hb@hitachi.com 3002 URI: http://www.hitachi.com/ 3004 Hiroki Satoh 3005 Hitachi, Ltd., Yokohama Research Laboratory 3007 Phone: +81 44 959 0205 3008 EMail: hiroki.satoh.yj@hitachi.com 3009 URI: http://www.hitachi.com/ 3011 Ulrich Herberg 3012 Fujitsu Laboratories of America 3014 Phone: +1 408 530 4528 3015 EMail: ulrich@herberg.name 3016 URI: http://www.herberg.name/ 3018 Cedric Lavenu 3019 EDF R&D 3021 Phone: +33 1 4765 2729 3022 EMail: cedric-2.lavenu@edf.fr 3023 URI: http://www.edf.fr/ 3024 Thierry Lys 3025 ERDF 3027 Phone: +33 1 8197 6777 3028 EMail: thierry.lys@erdfdistribution.fr 3029 URI: http://www.erdfdistribution.fr/ 3031 Charles E. Perkins 3032 Futurewei Inc. 3034 Phone: +1-408-421-1172 3035 EMail: charliep@computer.org 3036 URI: http://www.huawei.com/na/en/ 3038 Justin Dean 3039 Naval Research Laboratory 3041 EMail: jdean@itd.nrl.navy.mil 3042 URI: http://cs.itd.nrl.navy.mil/