idnits 2.17.1 draft-clausen-manet-olsrv2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2525. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 347: '...eighborhood of N MUST have a symmetric...' RFC 2119 keyword, line 442: '...ber (PSN), which MUST be be incremente...' RFC 2119 keyword, line 455: '...re address blocks. Each address SHALL...' RFC 2119 keyword, line 459: '...hat address block. A message MAY also...' RFC 2119 keyword, line 462: '... Message content MAY (e.g. due to size...' (98 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 646 has weird spacing: '...sisting of tw...' == Line 928 has weird spacing: '...address of th...' == Line 1008 has weird spacing: '...changed betwe...' == Line 1269 has weird spacing: '.... This allow...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2005) is 6829 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 2426 looks like a reference -- Missing reference section? '5' on line 2433 looks like a reference -- Missing reference section? '1' on line 2417 looks like a reference -- Missing reference section? '2' on line 2421 looks like a reference -- Missing reference section? 'RFC3626' on line 430 looks like a reference -- Missing reference section? '0-7' on line 1769 looks like a reference -- Missing reference section? '9' on line 2447 looks like a reference -- Missing reference section? '4' on line 2430 looks like a reference -- Missing reference section? '6' on line 2436 looks like a reference -- Missing reference section? '7' on line 2441 looks like a reference -- Missing reference section? '8' on line 2443 looks like a reference -- Missing reference section? '10' on line 2450 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Expires: February 2, 2006 August 2005 6 The Optimized Link-State Routing Protocol version 2 7 draft-clausen-manet-olsrv2-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 2, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes version 2 of the Optimized Link State Routing 41 (OLSRv2) protocol for mobile ad hoc networks. The protocol is an 42 optimization of the classical link state algorithm tailored to the 43 requirements of a mobile wireless LAN. 45 The key optimization of OLSRv2 is that of multipoint relays, 46 providing an efficient mechanism for network-wide broadcast of link- 47 state information. A secondary optimization is, that OLSRv2 employs 48 partial link-state information: each node maintains information of 49 all destinations, but only a subset of links. This allows that only 50 select nodes diffuse link-state advertisements (i.e. reduces the 51 number of network-wide broadcasts) and that these advertisements 52 contain only a subset of links (i.e. reduces the size of each 53 network-wide broadcast). The partial link-state information thus 54 obtained allows each OLSRv2 node to at all times maintain optimal (in 55 terms of number of hops) routes to all destinations in the network. 57 OLSRv2 imposes minimum requirements to the network by not requiring 58 sequenced or reliable transmission of control traffic. Furthermore, 59 the only interaction between OLSRv2 and the IP stack is routing table 60 management. 62 OLSRv2 is particularly suitable for large and dense networks as the 63 technique of MPRs works well in this context. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2 Applicability Statement . . . . . . . . . . . . . . . . . 7 70 2. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 71 3. OLSRv2 Signaling Framework . . . . . . . . . . . . . . . . . . 11 72 3.1 OLSRv2 Packet Format . . . . . . . . . . . . . . . . . . . 11 73 3.2 OLSR Messages . . . . . . . . . . . . . . . . . . . . . . 12 74 3.2.1 Address Blocks . . . . . . . . . . . . . . . . . . . . 14 75 3.2.2 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.3 Message Content Fragmentation . . . . . . . . . . . . . . 15 77 4. Packet Processing and Message Forwarding . . . . . . . . . . . 17 78 4.1 Processing and Forwarding Repositories . . . . . . . . . . 17 79 4.1.1 Received Message Set . . . . . . . . . . . . . . . . . 17 80 4.1.2 Processed Set . . . . . . . . . . . . . . . . . . . . 17 81 4.1.3 Forwarded Set . . . . . . . . . . . . . . . . . . . . 18 82 4.1.4 Relay Set . . . . . . . . . . . . . . . . . . . . . . 18 83 4.2 Fragment Set . . . . . . . . . . . . . . . . . . . . . . . 18 84 4.3 Actions when Receiving an OLSRv2-Message . . . . . . . . . 19 85 4.4 Message Considered for Processing . . . . . . . . . . . . 20 86 4.5 Message Considered for Forwarding . . . . . . . . . . . . 21 87 5. Information Repositories . . . . . . . . . . . . . . . . . . . 22 88 5.1 Local Link Information Base . . . . . . . . . . . . . . . 22 89 5.1.1 Link Set . . . . . . . . . . . . . . . . . . . . . . . 22 90 5.1.2 2-hop Neighbor Set . . . . . . . . . . . . . . . . . . 23 91 5.1.3 Neighborhood Address Association Set . . . . . . . . . 23 92 5.1.4 MPR Set . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.1.5 Advertised Neighbor Set . . . . . . . . . . . . . . . 24 94 5.2 Topology Information Base . . . . . . . . . . . . . . . . 24 95 6. OLSRv2 Control Messages . . . . . . . . . . . . . . . . . . . 25 96 6.1 HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 25 97 6.2 TC Messages . . . . . . . . . . . . . . . . . . . . . . . 25 98 6.3 MA Messages . . . . . . . . . . . . . . . . . . . . . . . 25 99 7. Populating the MPR Set . . . . . . . . . . . . . . . . . . . . 26 100 8. Populating the Advertised Neighbor Set . . . . . . . . . . . . 27 101 9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 28 102 9.1 HELLO Message: Message TLVs . . . . . . . . . . . . . . . 28 103 9.2 HELLO Message: Address Blocks and Address TLVs . . . . . . 28 104 10. HELLO Message Processing . . . . . . . . . . . . . . . . . . 30 105 10.1 Populating the Link Set . . . . . . . . . . . . . . . . . 30 106 10.2 Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 32 107 10.3 Populating the Relay Set . . . . . . . . . . . . . . . . . 33 108 10.4 Neighborhood and 2-hop Neighborhood Changes . . . . . . . 33 109 11. TC Message Generation . . . . . . . . . . . . . . . . . . . 35 110 11.1 TC Message: Message TLVs . . . . . . . . . . . . . . . . . 35 111 11.2 TC Message: Address Blocks and Address TLVs . . . . . . . 35 112 12. TC Message Processing . . . . . . . . . . . . . . . . . . . 36 113 13. MA Message Generation . . . . . . . . . . . . . . . . . . . 38 114 14. MA Message Processing . . . . . . . . . . . . . . . . . . . 39 115 15. Routing Table Calculation . . . . . . . . . . . . . . . . . 40 116 16. Proposed Values for Constants . . . . . . . . . . . . . . . 43 117 16.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 43 118 16.2 Message Intervals . . . . . . . . . . . . . . . . . . . . 43 119 16.3 Holding Times . . . . . . . . . . . . . . . . . . . . . . 43 120 16.4 Willingness . . . . . . . . . . . . . . . . . . . . . . . 43 121 17. Representing Time . . . . . . . . . . . . . . . . . . . . . 44 122 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 123 A. Example Heuristic for Calculating MPRs . . . . . . . . . . . . 46 124 B. Example Algorithms for Generating Control Traffic . . . . . . 49 125 B.1 Example Algorithm for Generating HELLO messages . . . . . 49 126 B.2 Example Algorithm for Generating TC messages . . . . . . . 50 127 C. Protocol and Port Number . . . . . . . . . . . . . . . . . . . 52 128 D. OLSRv2 Packet and Message Layout . . . . . . . . . . . . . . . 53 129 D.1 General OLSR Packet Format . . . . . . . . . . . . . . . . 53 130 D.1.1 Message TLVs . . . . . . . . . . . . . . . . . . . . . 54 131 D.1.2 Address Block . . . . . . . . . . . . . . . . . . . . 54 132 D.1.3 Address Block TLV . . . . . . . . . . . . . . . . . . 56 133 D.2 Layout of OLSRv2 Specified Messages . . . . . . . . . . . 56 134 D.2.1 Layout of HELLO Messages . . . . . . . . . . . . . . . 57 135 D.2.2 Layout of TC messages . . . . . . . . . . . . . . . . 57 136 E. Node Configuration . . . . . . . . . . . . . . . . . . . . . . 59 137 E.1 IPv6 Specific Considerations . . . . . . . . . . . . . . . 59 138 F. Security Considerations . . . . . . . . . . . . . . . . . . . 60 139 F.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 60 140 F.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 60 141 F.3 Interaction with External Routing Domains . . . . . . . . 61 142 F.4 Node Identity . . . . . . . . . . . . . . . . . . . . . . 62 143 G. Flow and Congestion Control . . . . . . . . . . . . . . . . . 63 144 H. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 64 145 I. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 146 J. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 66 147 K. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 148 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 67 149 Intellectual Property and Copyright Statements . . . . . . . . 68 151 1. Introduction 153 The Optimized Link State Routing Protocol version 2 (OLSRv2) is 154 developed for mobile ad hoc networks. It operates as a table driven, 155 proactive protocol, i.e., exchanges topology information with other 156 nodes of the network regularly. Each node selects a set of its 157 neighbor nodes as "multipoint relays" (MPR). In OLSRv2, only nodes 158 that are selected as such MPRs are then responsible for forwarding 159 control traffic intended for diffusion into the entire network. MPRs 160 provide an efficient mechanism for flooding control traffic by 161 reducing the number of transmissions required. 163 Nodes, selected as MPRs, also have a special responsibility when 164 declaring link state information in the network. Indeed, the only 165 requirement for OLSRv2 to provide shortest path routes to all 166 destinations is that MPR nodes declare link-state information for 167 their MPR selectors. Additional available link-state information may 168 be utilized, e.g., for redundancy. 170 Nodes which have been selected as multipoint relays by some neighbor 171 node(s) announce this information periodically in their control 172 messages. Thereby a node announces to the network, that it has 173 reachability to the nodes which have selected it as an MPR. Then, 174 aside from being used to facilitate efficient flooding, MPRs are also 175 used for route calculation from any given node to any destination in 176 the network. 178 A node selects MPRs from among its one hop neighbors with 179 "symmetric", i.e., bi-directional, linkages. Therefore, selecting 180 the route through MPRs automatically avoids the problems associated 181 with data packet transfer over uni-directional links (such as the 182 problem of not getting link-layer acknowledgments for data packets at 183 each hop, for link-layers employing this technique for unicast 184 traffic). 186 OLSRv2 is developed to work independently from other protocols. 187 Likewise, OLSRv2 makes no assumptions about the underlying link- 188 layer. However, OLSRv2 may use link-layer information and 189 notifications when available and applicable. 191 OLSRv2, as OLSRv1, inherits the concept of forwarding and relaying 192 from HIPERLAN (a MAC layer protocol) which is standardized by ETSI 193 [3]. 195 1.1 Terminology 197 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC2119 [5]. 201 Additionally, this document uses the following terminology: 203 node - a MANET router which implements the Optimized Link State 204 Routing protocol as specified in this document. 206 OLSRv2 interface - A network device participating in a MANET running 207 OLSRv2. A node may have several OLSRv2 interfaces, each interface 208 assigned an unique IP address. 210 neighbor - A node X is a neighbor of node Y if node Y can hear node X 211 (i.e., a link exists from an OLSRv2 interface on node X to an 212 OLSRv2 interface on Y). A neighbor may also be called a 1-hop 213 neighbor. 215 2-hop neighbor - A node X is a 2-hop neighbor of node Y if node X is 216 a neighbor of a neighbor of node Y. 218 strict 2-hop neighbor - a 2-hop neighbor which is (i) not the node 219 itself, (ii) not a neighbor of the node, and (iii) not a 2-hop 220 neighbor only through a neighbor with willingness WILL_NEVER. 222 multipoint relay (MPR) - A node which is selected by its 1-hop 223 neighbor, node X, to "re-transmit" all the broadcast messages that 224 it receives from X, provided that the message is not a duplicate, 225 and that the time to live field of the message is greater than 226 one. 228 multipoint relay selector (MPR selector, MS) - A node which has 229 selected its 1-hop neighbor, node X, as its multipoint relay, will 230 be called an MPR selector of node X. 232 link - A link is a pair of OLSRv2 interfaces from two different 233 nodes, where at least one interface is able to hear (i.e. receive 234 traffic from) the other. A node is said to have a link to another 235 node when one of its interfaces has a link to one of the 236 interfaces of the other node. 238 symmetric link - A link where both interfaces have verified they are 239 able to hear the other. 241 asymmetric link - A link which is not symmetric. 243 symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of 244 any node X is the set of nodes which have at least one symmetric 245 link to X. 247 symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of X 248 is the set of nodes, excluding X itself, which have a symmetric 249 link to the symmetric 1-hop neighborhood of X. 251 symmetric strict 2-hop neighborhood - The symmetric strict 2-hop 252 neighborhood of X is the set of nodes in its symmetric 2-hop 253 neighborhood that are neither in its symmetric 1-hop neighborhood 254 nor reachable only through a symmetric 1-hop neighbor of X with 255 willingness WILL_NEVER. 257 1.2 Applicability Statement 259 OLSRv2 is a proactive routing protocol for mobile ad hoc networks 260 (MANETs) [1], [2]. It is well suited to large and dense networks of 261 mobile nodes, as the optimization achieved using the MPRs works well 262 in this context. The larger and more dense a network, the more 263 optimization can be achieved as compared to the classic link state 264 algorithm. OLSRv2 uses hop-by-hop routing, i.e., each node uses its 265 local information to route packets. 267 As OLSRv2 continuously maintains routes to all destinations in the 268 network, the protocol is beneficial for traffic patterns where the 269 traffic is random and sporadic between a large subset of nodes, and 270 where the [source, destination] pairs are changing over time: no 271 additional control traffic is generated in this situation since 272 routes are maintained for all known destinations at all times. 274 2. Protocol Overview and Functioning 276 OLSRv2 is a proactive routing protocol for mobile ad hoc networks. 277 The protocol inherits the stability of a link state algorithm and has 278 the advantage of having routes immediately available when needed due 279 to its proactive nature. OLSRv2 is an optimization over the 280 classical link state protocol, tailored for mobile ad hoc networks. 281 The main tailoring and optimizations of OLSRv2 are: 283 o periodic, unacknowledged transmission of all control messages; 285 o optimized flooding for global link-state information diffusion; 287 o partial topology maintenance -- each node will know of all 288 destinations and a subset of links in the network. 290 More specifically, OLSRv2 consists of the following main components: 292 o A general and flexible signaling framework, allowing for 293 information exchange between OLSRv2 nodes. This framework allows 294 for both local information exchange (between neighboring nodes) 295 and global information exchange using an optimized flooding 296 mechanism denoted "MPR flooding". 298 o A specification of local signaling, denoted HELLO messages. HELLO 299 messages in OLSRv2 serve to: 301 * discover links to adjacent OLSR nodes; 303 * perform bidirectionality check on the discovered links; 305 * advertise neighbors and hence discover 2-hop neighbors; 307 * signal MPR selection. 309 HELLO messages are emitted periodically, thereby allowing nodes to 310 continuously track changes in their local neighborhoods. 312 o A specification of global signaling, denoted TC messages. TC 313 messages in OLSRv2 serve to: 315 * inject link-state information into the entire network. 317 TC messages are emitted periodically, thereby allowing nodes to 318 continuously track global changes in the network. 320 Thus, through periodic exchange of HELLO messages, a node is able to 321 acquire and maintain information about its immediate neighborhood. 323 This includes information about immediate neighbors, as well as nodes 324 which are two hops away. By HELLO messages being exchanged 325 periodically, a node learns about changes in the neighborhood (new 326 nodes emerging, old nodes disappearing) without requiring explicit 327 mechanisms for doing so. 329 Based on the local topology information, acquired through the 330 periodic exchange of HELLO messages, an OLSRv2 node is able to make 331 provisions for ensuring optimized flooding, denoted "MPR flooding", 332 as well as injection of link-state information into the network. 333 This is done through the notion of Multipoint Relays. 335 The idea of multipoint relays is to minimize the overhead of flooding 336 messages in the network by reducing redundant retransmissions in the 337 same region. Each node in the network selects a set of nodes in its 338 symmetric 1-hop neighborhood which may retransmit its messages. This 339 set of selected neighbor nodes is called the "Multipoint Relay" (MPR) 340 set of that node. The neighbors of node N which are *NOT* in its MPR 341 set, receive and process broadcast messages but do not retransmit 342 broadcast messages received from node N. The MPR set of a node is 343 selected such that it covers (in terms of radio range) all symmetric 344 strict 2-hop nodes. The MPR set of N, denoted as MPR(N), is then an 345 arbitrary subset of the symmetric 1-hop neighborhood of N which 346 satisfies the following condition: every node in the symmetric strict 347 2-hop neighborhood of N MUST have a symmetric link towards MPR(N). 348 The smaller a MPR set, the less control traffic overhead results from 349 the routing protocol. [2] gives an analysis and example of MPR 350 selection algorithms. Notice, that as long as the condition above is 351 satisfied, any algorithm selecting MPR sets is acceptable in terms of 352 implementation interoperability. 354 Each node maintains information about the set of neighbors that have 355 selected it as MPR. This set is called the "Multipoint Relay 356 Selector set" (MPR Selector Set) of a node. A node obtains this 357 information from periodic HELLO messages received from the neighbors. 359 A broadcast message, intended to be diffused in the whole network, 360 coming from any of the MPR selectors of node N is assumed to be 361 retransmitted by node N, if N has not received it yet. This set can 362 change over time (i.e., when a node selects another MPR-set) and is 363 indicated by the selector nodes in their HELLO messages. 365 Using the MPR flooding mechanism, link-state information can be 366 injected into the network using TC messages: a node evaluates 367 periodically if it is required to generate TC messages and, if so, 368 which information is to be included in these TC messages. 370 OLSRv2 is designed to work in a completely distributed manner and 371 does not depend on any central entity. The protocol does NOT REQUIRE 372 reliable transmission of control messages: each node sends control 373 messages periodically, and can therefore sustain a reasonable loss of 374 some such messages. Such losses occur frequently in radio networks 375 due to collisions or other transmission problems. 377 Also, OLSRv2 does NOT REQUIRE sequenced delivery of messages. Each 378 control message contains a sequence number which is incremented for 379 each message. Thus the recipient of a control message can, if 380 required, easily identify which information is more recent - even if 381 messages have been re-ordered while in transmission. Furthermore, 382 OLSRv2 provides support for protocol extensions such as sleep mode 383 operation, multicast-routing etc. Such extensions may be introduced 384 as additions to the protocol without breaking backwards compatibility 385 with earlier versions. 387 OLSRv2 does NOT REQUIRE any changes to the format of IP packets. 388 Thus any existing IP stack can be used as is: OLSRv2 only interacts 389 with routing table management. 391 3. OLSRv2 Signaling Framework 393 In OLSRv2, signaling serves as a way for a node to express its 394 relationships with other nodes -- or more precisely, a control- 395 message in OLSRv2 states that "the address X has the following 396 special relationship with addresses W, Y and Z". This "special 397 relationship" may be advertisement of an adjacency between interface 398 X and interfaces WYZ, advertisement of an associated cost, 399 advertisement of selection as designated router etc. 401 In an OLSRv2 MANET, signaling may be either "local", intended only 402 for nodes adjacent to the originator of the signal or "global", 403 intended for all nodes in the OLSRv2 MANET. 405 In this section, the general mechanism employed for all OLSRv2 406 signaling is described. 408 This section provides abstract descriptions of message- and packet 409 formats. It is exclusively concerned with the content of messages 410 and packets relevant for OLSRv2 semantics. The precise lay-out of 411 OLSRv2 control messages and packets can be found in the complementary 412 Appendix D, including all details of the format of messages on the 413 wire (i.e. additional necessary fields exclusively used for 414 formatting and parsing, encoding of values, size of the fields, 415 padding, ...). 417 3.1 OLSRv2 Packet Format 419 OLSRv2 messages are carried in a general packet format, allowing: 421 o piggybacking of several independent messages (originated or 422 forwarded) in a single transmission; 424 o external extensibility -- i.e. new message types can be introduced 425 for auxiliary functions, while still being delivered and forwarded 426 correctly even by nodes not capable of interpreting the message; 428 o controlled-scope diffusion of messages. 430 The packet format is inherited directly from OLSRv1 [RFC3626] and 431 conforms to the following specification: 433 packet = {}* 435 with the usual notion of "*" indicating "zero or more" occurrences of 436 the preceding element, and the elements defined thus: 438 is an 8 bit field, which specifies the length (in 439 bytes) of the packet; 441 is an 16 bit field, which specifies the packet 442 sequence number (PSN), which MUST be be incremented by one each 443 time a new OLSRv2 packet is transmitted. "Wrap-around" is handled 444 as described in Appendix H. A separate Packet Sequence Number is 445 maintained for each OLSRv2 interface such that packets transmitted 446 over an interface are sequentially enumerated. 448 is the message as defined in Section 3.2. 450 3.2 OLSR Messages 452 Signals in OLSRv2 are carried through "messages". The primary 453 content of a message is a set of addresses about which the 454 originating node wishes to convey information. These addresses may 455 be divided into one or more address blocks. Each address SHALL 456 appear only once in a message. Each address block is followed by 457 zero or more TLVs, explained with more details in section 458 Section 3.2.2, which convey information (e.g. cost, link-status, ...) 459 about the addresses in that address block. A message MAY also 460 contain zero or more TLVs, associated with the whole message. 462 Message content MAY (e.g. due to size limitations) be fragmented. 463 Each fragment is transmitted such that it makes up a syntactically 464 correct message (i.e. all headers are set as if each fragment is a 465 message in its own right, and each message contains all message 466 TLVs). Content fragmentation is detailed in Section 3.3. 468 A message has the following general layout 470 message = {}* 472 msg-header = 473 475 tlv-block = * 477 with the usual notion of "*" indicating "zero or more" occurrences of 478 the preceding element, and the elements defined thus: 480 is a 16 bit field, which contains the total length (in 481 octets) of the immediately following TLV(s). If no TLV follows, 482 this field contains zero; 484 is a TLV, providing information regarding the entire message or 485 the address block which it follows. TLVs are specified in 486 Section 3.2.2; 488 is a block of addresses, with which the originator of 489 the message has a special relationship. Address blocks are 490 specified in Section 3.2.1; 492 is an 8 bit field, which specifies the type of message; 494 is an 8 bit field, which specifies for how long time after 495 reception a node MUST consider the information contained in the 496 message as valid, unless a more recent update to the information 497 is received; 499 is an 8 bit field, which specifies the size of the and the following , counted in bytes; 502 is the address of an interface of the node, 503 which originated the message. Each node SHOULD select one 504 interface address and utilize consistently as "originator address" 505 for all messages it generates; 507 is an 8 bit field, which contains the maximum number of hops a 508 message will be transmitted. Before a message is retransmitted, 509 the Time To Live MUST be decremented by 1. When a node receives a 510 message with a Time To Live equal to 0 or 1, the message MUST NOT 511 be retransmitted under any circumstances. Normally, a node would 512 not receive a message with a TTL of zero. 514 is an 8 bit field, which contains the number of hops a 515 message has attained. Before a message is retransmitted, the Hop 516 Count MUST be incremented by 1. Initially, this is set to '0' by 517 the originator of the message; 519 is a 16 bit field, which contains an unique number, 520 generated by the originator node to uniquely identify each message 521 in the network. "Wrap-around" is handled as described in 522 Appendix H. 524 TLVs associated with a message or an address block SHALL be included 525 in numerically ascending order within each TLV block. Note that this 526 means that all TLVs defined in this document appear before all other 527 TLVs in that TLV block. 529 with the elements defined thus: 531 3.2.1 Address Blocks 533 An address block represents a set of addresses in a compact form. 534 Assuming that an address can be specified as a sequence of bits of 535 the form 'head:tail', then an address-block is a set of addresses 536 sharing the same 'head' and having different 'tails'. Specifically, 537 an address block conforms to the following specification: 539 address-block = {{*}} 541 with the usual notion of "*" indicating "zero or more" occurrences of 542 the preceding element, and the elements defined thus: 544 is the number of "common leftmost bits" in a set of 545 addresses, akin to a "prefix", however with the only restriction 546 on the head-length that 0 <= head-length <= the length of the 547 address; 549 is the longest sequence of leftmost bits, which the addresses 550 in the address block have in common. Akin to a prefix; 552 is the sequence of bits which, when concatenated to the head, 553 makes up a single, complete, unique address. 555 This representation aims at providing a flexible, yet compact, way of 556 representing sets of interface addresses. 558 3.2.2 TLVs 560 A TLV is a carrier of information, relative to a message or to 561 addresses in an address block. A TLV, associated to an address- 562 block, specifies some attribute(s), which associate with address(ses) 563 in the address-block. In order to provide the largest amount of 564 flexibility to benefit from address aggregation as described in 565 Section 3.2.1, a TLV associated to an address block can apply to: 567 o a single address in the address block; 569 o all addresses in the address block; 571 o any continuous sequence of addresses in the address block; 573 Specifically, a TLV conforms to the following specification: 575 tlv = 577 where the elements are defined thus: 579 is an 8 bit field, which specifies the type of the TLV. The 580 two most significant bits are allocated with the following 581 semantics: 583 bit 7 is the "user" bit. Types with this bit unset are defined in 584 this specification or can be allocated via standards action. 585 Types with this bit set are reserved for private/local use. 587 bit 6 is the "multivalue" bit. TLVs with types with this bit unset 588 include a single value, which applies to each of the addresses 589 defined by and . TLVs with types with 590 this bit set include seperate values for each of the addresses in 591 the interval defined by and ; 593 is an 8 bit field which specifies the length, counted in 594 octets, of the data contained in . If the multivalue bit 595 is set, this MUST be an integral multiple of (-+1); 598 is an 8 bit field. For a TLV associated with an 599 address block, specifies the index of the first address in the 600 address-block (starting at zero), for which this TLV applies. For 601 a TLV associated with a message, this field SHALL be set to zero; 603 is an 8 bit field. For a TLV associated with an address 604 block, specifies the index of the last address in the address- 605 block (starting at zero) for which this TLV applies. For a TLV 606 associated with a message, this field SHALL be set to zero; 608 contains a payload, of the length specified in , 609 which is to be processed according to the specification indexed by 610 the field. If this is a TLV for an address block and the 611 multivalue bit is set, this field is divided into (- 612 +1) equal-sized fields which are applied in turn to 613 each address described by and 615 Two or more TLVs of the same type SHALL NOT apply to the same 616 address. 618 3.3 Message Content Fragmentation 620 An OLSRv2 messagemay be larger than is desirable to include, with the 621 OLSR packet and other headers (UDP, IP) in a MAC frame. In this case 622 the TC message SHOULD be fragmented. 624 An OLSRv2 message may be fragmented by dividing the address blocks 625 plus following TLVs among its fragments. It MAY be necessary to use 626 more address blocks than might otherwise be chosen without 627 fragmentation. Each message fragment may carry any number of these 628 address blocks plus following TLVs, however they must be divided in 629 order, that is if the fragments are numbered from zero, then the 630 address blocks should be reassembled from those in fragment 0 in 631 order, followed by those in fragment 1 in order and so on. 633 All message TLVs MUST be included identically in each fragment. 635 When transmitting fragmented content, each message containing a 636 fragment MUST include a message TLVs of type Content Sequence Number. 637 The value of this Content Sequence Number TLV is a 16 bit field 638 uniquely identifying the "version" of the content of the message. If 639 the content does not have an inherent sequence number or version 640 number, the value of the Content Sequence Number TLV SHOULD be set to 641 the message sequence number of the message containing the first 642 fragment. 644 A message containing a fragment MUST include a message TLV of type 645 Fragmentation. The value of this Fragmentation TLV is a 16 bit field 646 consisting of two 8 bit sub-fields describing the number of 647 fragments, and the fragment number (counting from zero). 649 If the same content with the same Content Sequence Number is sent 650 more than once by a node, the content MUST be fragmented and 651 transmitted in identically each time it is sent. 653 4. Packet Processing and Message Forwarding 655 Upon receiving a basic packet, a node examines each of the "message 656 headers". If the "message type" is known to the node, the message is 657 processed locally according to the specifications for that message 658 type -- otherwise, the message is treated as "unknown", and is 659 evaluated for forwarding. 661 4.1 Processing and Forwarding Repositories 663 The following data-structures are employed in order to ensure that a 664 message is processed at most once and is forwarded at most once per 665 interface of a node, and that fragmented content is treated 666 correctly. 668 4.1.1 Received Message Set 670 Each node maintains, for each OLSRv2 interface it possesses, a set of 671 messages received over that interface: 673 (R_addr, R_seq_number, R_time) 675 where: 677 R_addr is the originator address of the received message; 679 R_seq_number is the message sequence number of the received message; 681 R_time specifies the time at which this record expires and *MUST* be 682 removed. 684 4.1.2 Processed Set 686 Each node maintains a set of messages, which have been processed by 687 the node: 689 (P_addr, P_seq_number, P_time) 691 where: 693 P_addr is the originator address of the received message; 695 P_seq_number is the message sequence number of the received message; 696 P_time specifies the time at which this record expires and *MUST* be 697 removed. 699 4.1.3 Forwarded Set 701 Each node maintains a set of messages, which have been retransmitted/ 702 forwarded by the node: 704 (F_addr, F_seq_number, F_time) 706 where: 708 F_addr is the originator address of the received message; 710 F_seq_number is the message sequence number of the received message; 712 F_time specifies the time at which this record expires and *MUST* be 713 removed. 715 4.1.4 Relay Set 717 A node maintains a set of neighbor interfaces, in the form of "relay 718 tuples", for which it is to relay flooded messages: 720 (RS_if_addr, Rs_if_time) 722 where: 724 RS_if_addr is the address of the neighbor interface, for which a node 725 SHOULD relay flooded messages; 727 RS_if_time specifies the time at which this record expires and *MUST* 728 be removed. 730 In a node, this is denoted the "relay set". 732 4.2 Fragment Set 734 A node stores messages containing fragmented content in form of 735 "fragment tuples" until all fragments are received and the messages 736 can be processed: 738 (F_message, F_time) 740 where: 742 F_message is the message containing a fragment; 744 F_time specifies the time at which this record expires and MUST be 745 removed. 747 In a node, this is denoted the "fragment set". 749 4.3 Actions when Receiving an OLSRv2-Message 751 Upon receiving a basic packet, a node MUST perform the following 752 tasks for each encapsulated OLSRv2-message: 754 1. If the packet contains no messages (i.e., the Packet Length is 755 less than or equal to the size of the packet header), the packet 756 MUST silently be discarded. 758 2. If for the message TTL <= 0 or if the Originator Address of the 759 message is an interface address of the receiving node, then the 760 message MUST silently be dropped. 762 3. If an entry exists in the received set for the receiving 763 interface, where: 765 * R_addr == the originator of the received message, AND; 767 * R_seq_number == the sequence number of the received message. 769 then the message MUST be discarded 771 4. Otherwise: 773 1. Create an entry in the Received Set for the receiving 774 interface with: 776 + R_addr = originator address of the received message; 778 + R_seq_number = sequence number of the received message; 780 + R_time = current time + R_HOLD_TIME. 782 2. If the message type is known to the receiving node, then: 784 1. if the message contains a message TLV of type Fragment: 786 1. if the Fragment Set contains all remaining fragments 787 necessary to reconstitute the content, the messages 788 containing these fragments MUST be removed from the 789 fragment set and received message MUST be considered 790 for processing according to Section 4.4; 792 2. otherwise, the message is added to the Fragment Set 793 with a F_time of XXXX (possibly replacing an 794 identical and previous received instance of the same 795 fragment of the same content). 797 2. Otherwise, if the message does not contain a message TLV 798 of type Fragment,the message is considered for processing 799 according to Section 4.4; 801 Otherwise, if the message type is unknown to the receiving 802 node, the message is considered for forwarding according to 803 Section 4.5. 805 Notice that known message types are not automatically considered for 806 forwarding. Forwarding of known message types MUST be specified as a 807 property of processing of that message type. 809 4.4 Message Considered for Processing 811 If a message is considered for processing, the following tasks MUST 812 be performed: 814 1. If an entry exists in the Processed Set where: 816 * P_addr == the originator address of the received message, AND; 818 * P_seq_number == the sequence number of the received message. 820 the message MUST be discarded. 822 2. Otherwise: 824 1. Create an entry in the Processed Set with: 826 + P_addr = originator address of the received message; 828 + P_seq_number = sequence number of the received message; 830 + P_time = current time + P_HOLD_TIME. 832 2. Process message locally, according to the specification for 833 the received message type. 835 3. If a message of a known message type is to be forwarded, the 836 algorithm in Section 4.5 MAY be performed. 838 4.5 Message Considered for Forwarding 840 If a message is considered for forwarding, the following tasks MUST 841 be performed: 843 1. If an entry exists in the Forwarded Set where: 845 * F_addr == the originator address of the received message, AND; 847 * F_seq_number == the sequence number of the received message. 849 then the message MUST be discarded 851 2. Otherwise: 853 1. If an entry exists in the relay set, where: 855 + RS_if_addr == originator address of the received message 857 2. Create an entry in the Forwarded Set with: 859 - F_addr = originator address of the received message; 861 - F_seq_number = sequence number of the received 862 message; 864 - F_time = current time + F_HOLD_TIME. 866 3. Transmit the message on all OLSRv2 interfaces of the node 868 5. Information Repositories 870 The signaling of OLSRv2 populates a set of information repositories, 871 specified in this section. 873 5.1 Local Link Information Base 875 The local link information base stores information about links 876 between local interfaces and interfaces on adjacent nodes. 878 5.1.1 Link Set 880 A node records a set of "Link Tuples": 882 (L_local_iface_addr, L_neighbor_iface_addr, 883 L_SYM_time, L_ASYM_time, L_willingness, L_time). 885 where: 887 L_local_iface_addr is the interface address of the local node; 889 L_neighbor_iface_addr is the interface address of the neighbor node ; 891 L_SYM_time is the time until which the link is considered symmetric; 893 L_ASYM_time is the time until which the neighbor interface is 894 considered heard; 896 L_willingness is the nodes willingness to be selected as MPR; 898 L_time specifies when this record expires and *MUST* be removed. 900 +-------------+-------------+--------------+ 901 | L_SYM_time | L_ASYM_time | L_STATUS | 902 +-------------+-------------+--------------+ 903 | Expired | Expired | LOST | 904 | | | | 905 | Not Expired | Expired | SYMMETRIC | 906 | | | | 907 | Not Expired | Not Expired | SYMMETRIC | 908 | | | | 909 | Expired | Not Expired | ASYMMETRIC | 910 +-------------+-------------+--------------+ 912 Table 1 914 The status of the link, denoted L_STATUS, can be derived based on the 915 fields L_SYM_time and L_ASYM_time as defined in Table 1. 917 In a node, the set of Link Tuples are denoted the "Link Set". 919 5.1.2 2-hop Neighbor Set 921 A node records a set of "2-hop tuples" 923 (N_local_iface_addr, N_neighbor_iface_addr, N_2hop_iface_addr, N_time) 925 describing symmetric links between its neighbors and the symmetric 926 2-hop neighborhood. 928 N_local_iface_addr is the address of the local interface over which 929 the information was received; 931 N_neighbor_iface_addr is the interface address of a neighbor; 933 N_2hop_iface_addr is the interface address of a 2-hop neighbor with a 934 symmetric link to N_neighbor_iface_addr; 936 specifies the time at which the tuple expires and *MUST* be 937 removed. 939 In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor 940 Set". 942 5.1.3 Neighborhood Address Association Set 944 A node maintains, for each 1-hop and 2-hop neighbor with multiple 945 addresses participating in the OLSRv2 network, a "Neighborhood 946 Address Association Tuple", representing that "these n addresses 947 belong to the same node". 949 (I_neighbor_addr_list, I_time) 951 I_neighbor_iface_addr_list is the list of addresses of the 1-hop or 952 2-hop neighbor node; 954 I_time specifies the time at which the tuple expires and *MUST* be 955 removed. 957 In a node, the set of Neighborhood Address Association Tuples is 958 denoted the "Neighborhood Address Association Set". 960 5.1.4 MPR Set 962 A node maintains a set of neighbors which are selected as MPR. Their 963 interface addresses are listed in the MPR Set. 965 5.1.5 Advertised Neighbor Set 967 A node maintains a set of neighbor interface addresses, which are to 968 be advertised through TC messages: 970 (A_neighbor_iface_addr) 972 For this set, an Advertised Neighbor Set Sequence Number (ASSN) is 973 maintained. Each time the Advertised Neighbor Set is updated, the 974 ASSN MUST be incremented. 976 5.2 Topology Information Base 978 Each node in the network maintains topology information about the 979 network. 981 For each destination in the network, at least one "Topology Tuple" 983 (T_dest_iface_addr, T_last_iface_addr, T_seq, T_time) 985 is recorded. 987 T_dest_iface_addr is the interface address of a node, which may be 988 reached in one hop from the node with the interface address 989 T_last_iface_addr; 991 T_last_iface_addr is, conversely, the last hop towards 992 T_dest_iface_addr. Typically, T_last_iface_addr is a MPR of 993 T_dest_iface_addr; 995 T_seq is a sequence number, and T_time specifies the time at which 996 this tuple expires and *MUST* be removed. 998 In a node, the set of Topology Tuples are denoted the "Topology Set". 1000 6. OLSRv2 Control Messages 1002 OLSRv2 employs two different message types for exchanging protocol 1003 information. Those are HELLO messages, which are locally scoped, and 1004 TC messages, which are globally scoped. 1006 6.1 HELLO Messages 1008 HELLO messages are, in OLSRv2, exchanged between neighbor nodes with 1009 the purpose of populating the local link information base: 1011 o Link Sensing: detecting new and lost adjacent interfaces and 1012 performing bidirectionality check of links; 1014 o 2-hop Neighbor Discovery: detecting the 2-hop symmetric 1015 neighborhood of a node; 1017 o MPR Signaling: signal MPR selection to neighbor nodes and detect 1018 selection of MPRs 1020 HELLO messages are exchanged between neighbor nodes only, i.e. they 1021 are never forwarded by any node. 1023 6.2 TC Messages 1025 TC messages are, in OLSRv2, transmitted to the entire network with 1026 the purpose of populating the topology information base: 1028 o Topology Discovery: ensure that information is present in each 1029 node describing all destinations and (at least) a sufficient 1030 subset of links in order to provide least-hop paths to all 1031 destinations. 1033 TC messages are exchanged within the entire network, i.e. they are 1034 forwarded according to the specification in section Section 4.5. 1036 6.3 MA Messages 1038 MA messages are, in OLSRv2, transmitted by nodes with more than one 1039 address participating in the OLSRv2 network with the purpose of 1040 populating the Neighborhood Address Association Set (NAAS). 1042 MA messages are exchanged within the 2-hop neighborhood of the 1043 originator - i.e. are transmitted with a TTL=2 and are forwarded 1044 according to the specification in section Section 4.5. 1046 7. Populating the MPR Set 1048 Each node MUST select, from among its one-hop neighbors, a subset of 1049 nodes as MPR. This subset MUST be selected such that a message 1050 transmitted by the node, and retransmitted by all its MPR nodes, will 1051 be received by all nodes 2 hops away. 1053 Each node selects its MPR-set individually, utilizing the information 1054 in then neighbor set. Initially, a node will have an empty neighbor- 1055 set, thus, initially the MPR set is empty. A node SHOULD recalculate 1056 its MPR set when a change is detected to the neighbor set or 2-hop 1057 neighbor set. 1059 More specifically, a node MUST calculate MPRs per interface, the 1060 union of the MPR sets of each interface make up the MPR set for the 1061 node. 1063 MPRs are used to flood control messages from a node into the network 1064 while reducing the number of retransmissions that will occur in a 1065 region. Thus, the concept of MPR is an optimization of a classical 1066 flooding mechanism. While it is not essential that the MPR set is 1067 minimal, it is essential that all strict 2-hop neighbors can be 1068 reached through the selected MPR nodes. A node MUST select an MPR 1069 set such that any strict 2-hop neighbor is covered by at least one 1070 MPR node. A node MAY select additional MPRs beyond the minimum set. 1071 Keeping the MPR set small ensures that the overhead of OLSRv2 is kept 1072 at a minimum. 1074 Appendix A contains an example heuristic for selecting MPRs. 1076 8. Populating the Advertised Neighbor Set 1078 The Advertised Neighbor Set contains the set of neighbor addresses, 1079 to which a node advertises links through TC messages. This set 1080 SHOULD at least contain the addresses of the MPR Selector set (i.e. 1081 all addresses, associated with a MPR selector through the 1082 Neighborhood Adverticed Address Set). This set MAY contain 1083 additional neighbor addresses. 1085 Each time an address is removed from the Advertised Neighbor Set, the 1086 ASSN MUST be incremented. When an address is added to the Advertised 1087 Neighbor Set, the ASSN SHOULD be incremented. 1089 9. HELLO Message Generation 1091 An OLSRv2 HELLO message is composed as described in Section 3.2: a 1092 set of message TLVs, describing general properties of the message and 1093 the node emitting the HELLO, and a set of address blocks (with 1094 associated TLV sets), describing the links and their associated 1095 properties. 1097 OLSRv2 HELLO messages are generated and transmitted per interface, 1098 i.e. different HELLO messages are generated and transmitted per 1099 OLSRv2 interface of a node. 1101 OLSRv2 HELLO messages are generated and transmitted periodically, 1102 with a default interval between two consecutive HELLO emissions on 1103 the same interface of HELLO_INTERVAL. 1105 This section specifies the requirements, which HELLO message 1106 generation MUST fulfill. An example algorithm is proposed in 1107 Appendix B.1. 1109 9.1 HELLO Message: Message TLVs 1111 For each OLSRv2 interface a node MUST generate a HELLO message. In 1112 that HELLO message, a node MAY include a message TLV as specified in 1113 Table 2. 1115 +-------------+-------------------------------------+---------------+ 1116 | TLV Type | TLV Value | Default Value | 1117 +-------------+-------------------------------------+---------------+ 1118 | Willingness | willingness to be selected as MPR. | WILL_DEFAULT | 1119 +-------------+-------------------------------------+---------------+ 1121 Table 2 1123 If a node does not advertise a Willingness TLV in HELLO messages, the 1124 node MUST be assumed to have a willingness of WILL_DEFAULT. 1126 9.2 HELLO Message: Address Blocks and Address TLVs 1128 For each OLSRv2 interface a node MUST generate a HELLO message with 1129 address blocks and address TLVs according to Table 3. 1131 +---------------------------+---------------------------------------+ 1132 | The set of neighbor | TLV (Type = Value) | 1133 | interfaces which are.... | | 1134 +---------------------------+---------------------------------------+ 1135 | HEARD over the interface | (Link Status=HEARD); | 1136 | over which the HELLO is | (Interface=TransmittingInterface) | 1137 | being transmitted | | 1138 | | | 1139 | SYMMETRIC over the | (Link Status=SYMMETRIC); | 1140 | interface over which the | (Interface=TransmittingInterface) | 1141 | HELLO is being | | 1142 | transmitted | | 1143 | | | 1144 | LOST over the interface | (Link Status=LOST); | 1145 | over which the HELLO is | (Interface=TransmittingInterface) | 1146 | being transmitted | | 1147 | | | 1148 | SYMMETRIC over ANY | (Link Status=SYMMETRIC); | 1149 | interface of the node | (Interface=Other) | 1150 | other than the interface | | 1151 | over which the HELLO is | | 1152 | being transmitted | | 1153 | | | 1154 | selected as MPR for the | (Link Status=SYMMETRIC); | 1155 | interface over which the | (Interface=TransmittingInterface); | 1156 | HELLO is transmitted | (MPR Selection=True) | 1157 +---------------------------+---------------------------------------+ 1159 Table 3 1161 10. HELLO Message Processing 1163 Upon receiving a HELLO message, a node will update its local link 1164 information base according to the specification given in this 1165 section. 1167 For the purpose of this section, please notice the following: 1169 o the "validity time" of a message is calculated from the Vtime 1170 field of the message header as specified in Section 17; 1172 o the "originator address" refers to the address, contained in the 1173 "originator address" field of the OLSRv2 message header specified 1174 in Section 3.1; 1176 o a HELLO message MUST neither be forwarded nor be recorded in the 1177 duplicate set; 1179 o the address blocks considered exclude the originator address 1180 block, unless explicitly specified; 1182 o a HELLO message is valid when, for each address listed in the 1183 address blocks: 1185 * the address is associated with at least one TLV with Type=Link 1186 Status, AND 1188 * the address is associated with at least one TLV with 1189 Type=Interface, AND 1191 * all the TLVs with identical type, that the address is 1192 associated with, have identical values (e.g. 1193 Interface=TransmittingInterface is not compatible with 1194 Interface=Other for instance), AND 1196 * if the address is associated with one TLV "MPR Selection=True", 1197 then it MUST be associated also with one TLV "Link 1198 Status=SYMMETRIC". 1200 Invalid HELLO messages are not processed. 1202 10.1 Populating the Link Set 1204 Upon receiving a HELLO message, a node SHOULD update its Link Set 1205 with the information contained in the HELLO. Thus, for each address, 1206 listed in the HELLO message address blocks (see Section 6): 1208 1. if there exists no link tuple with 1210 * L_neighbor_iface_addr == Source Address 1212 a new tuple is created with 1214 * L_neighbor_iface_addr = Source Address; 1216 * L_local_iface_addr = Address of the interface which 1217 received the HELLO message; 1219 * L_SYM_time = current time - 1 (expired); 1221 * L_time = current time + validity time. 1223 2. The tuple (existing or new) with: 1225 * L_neighbor_iface_addr == Source Address 1227 is then modified as follows: 1229 2. if the node finds the address of the interface, which 1230 received the HELLO message, in one of the address blocks 1231 included in message, then the tuple is modified as follows: 1233 1. if the occurrence of L_local_iface_addr in the HELLO 1234 message is associated with a TLV with Type="Link Status" 1235 and value=LOST, and it is also associated with an TLV 1236 with Type="Interface" and Value="TransmittingInterface" 1237 then 1239 - L_SYM_time = current time - 1 (i.e., expired) 1241 2. else if the occurrence of L_local_iface_addr in the HELLO 1242 message is associated with a TLV with Type="Link Status" 1243 and value=SYMMETRIC or HEARD, and it is also associated 1244 with an TLV with Type="Interface" and 1245 Value="TransmittingInterface" then 1247 - L_SYM_time = current time + validity time, 1249 - L_time = L_SYM_time + NEIGHB_HOLD_TIME. 1251 3. L_ASYM_time = current time + validity time; 1253 4. L_time = max(L_time, L_ASYM_time) 1255 3. Additionally, the willingness field is updated as follows: 1257 If a TLV with Type="Willingness" is present in the message 1258 TLVs, then 1260 + L_willingness = Value of the TLV 1262 otherwise: 1264 + L_willingness = WILL_DEFAULT 1266 The rule for setting L_time is the following: a link losing its 1267 symmetry SHOULD still be advertised in HELLOs (with the remaining 1268 status as defined by Table 1) during at least the duration of the 1269 "validity time". This allows neighbors to detect the link breakage. 1271 10.2 Populating the 2-Hop Neighbor Set 1273 Upon receiving a HELLO message from a symmetric neighbor interface, a 1274 node SHOULD update its 2-hop Neighbor Set. 1276 If the Originator Address is the L_local_iface_addr from a link tuple 1277 included in the Link Set with L_STATUS equal to SYMMETRIC (in other 1278 words: if the Originator Address is a symmetric neighbor interface) 1279 then the 2-hop Neighbor Set SHOULD be updated as follows: 1281 1. for each address (henceforth: 2-hop neighbor address), listed in 1282 the HELLO message with a Link Status TLV equal to SYMMETRIC: 1284 1. if the 2-hop neighbor address is an address of the receiving 1285 node: 1287 silently discard the 2-hop neighbor address. 1289 (in other words: a node is not its own 2-hop neighbor). 1291 2. Otherwise, a 2-hop tuple is created with: 1293 + N_local_iface_addr = address of the interface over 1294 which the HELLO message was received; 1296 + N_neighbor_iface_addr = Originator Address of the message; 1298 + N_2hop_iface_addr = 2-hop neighbor address; 1300 + N_time = current time + validity time. 1302 This tuple may replace an older similar tuple with same 1303 N_local_iface_addr, N_neighbor_iface_addr and 1304 N_2hop_iface_addr values. 1306 10.3 Populating the Relay Set 1308 Upon receiving a HELLO message, if a node finds one of its own 1309 interface addresses, listed with an MPR TLV (indicating that the 1310 originator node has selected one of the receiving nodes interfaces as 1311 MPR), the Relay Set SHOULD be updated as follows: 1313 For each address in the originator address block: 1315 1. If there exists no Relay tuple with: 1317 * RS_if_addr == that address 1319 then a new tuple is created with: 1321 * RS_if_addr = that address 1323 2. The tuple (new or otherwise) with 1325 * RS_if_addr == that address 1327 is then modified as follows: 1329 * RS_time = current time + validity time. 1331 Relay tuples are removed upon expiration of RS_time, or upon link 1332 breakage as described in Section 10.4. 1334 10.4 Neighborhood and 2-hop Neighborhood Changes 1336 A change in the neighborhood is detected when: 1338 o The L_SYM_time field of a link tuple expires. This is considered 1339 as a link loss. 1341 o A new link tuple is inserted in the Link Set with a non expired 1342 L_SYM_time or a tuple with expired L_SYM_time is modified so that 1343 L_SYM_time becomes non-expired. This is considered as a link 1344 appearance if there was previously no such link tuple. 1346 A change in the 2-hop neighborhood is detected when a 2-hop neighbor 1347 tuple expires or is deleted according to section Section 10.2. 1349 The following processing occurs when changes in the neighborhood or 1350 the 2-hop neighborhood are detected: 1352 o In case of link loss, all 2-hop tuples with 1354 * N_local_iface_addr == interface address of the node where the 1355 link was lost 1357 * N_neighbor_iface_addr == interface address of the neighbor 1359 MUST be deleted. 1361 o In case of neighbor interface loss, if there exists no link left 1362 to this neighbor node, all MPR selector tuples associated with 1363 that neighbor are deleted. More precisely: 1365 * If there exists an entry in the neighbor address iface 1366 association set where 1368 + I_neighbor_iface_addr_list includes the 1369 N_neighbor_iface_addr of the lost link tuple 1371 AND such has there exists a link tuple such has 1373 + L_neighbor_iface_addr is one of the addresses in 1374 I_neighbor_iface_addr_list 1376 then a link to the neighbor interface was lost, but the 1377 neighbor node itself is still a neighbor (with another link), 1378 and the mpr selector set is not changed, 1380 * otherwise, the neighbor node is lost, and all MPR selector 1381 tuples with MS_iface_addr == interface address of the neighbor 1382 MUST be deleted, along with any interface address associated in 1383 the neighbor address iface association set. 1385 o The MPR set MUST be re-calculated when a link appearance or loss 1386 is detected, or when a change in the 2-hop neighborhood is 1387 detected. 1389 o An additional HELLO message MAY be sent when the MPR set changes. 1391 Additionally, proper update of the sets describing local topology 1392 should be made when a neighbor association address tuple has a list 1393 of addresses which is modified. 1395 11. TC Message Generation 1397 An OLSRv2 TC message is composed as described in Section 3.2: a set 1398 of message TLVs, describing general properties of the message and the 1399 node emitting the TC, and a set of address blocks (with associated 1400 TLV sets), describing the links and their associated properties. 1402 OLSRv2 TC messages are generated and transmitted per node, i.e. the 1403 same TC messages are generated and transmitted on all OLSRv2 1404 interfaces of a node. 1406 OLSRv2 TC messages are generated and transmitted periodically, with a 1407 default interval between two consecutive TC emissions by the same 1408 node of TC_INTERVAL. 1410 11.1 TC Message: Message TLVs 1412 Each OLSRv2 node, selected as MPR (i.e. a node with a non-empty MPR 1413 Selector Set) MUST generate TC messages with message TLVs according 1414 to the following table: 1416 +----------------------+----------------------+---------------------+ 1417 | TLV Type | TLV Value | Default Value | 1418 +----------------------+----------------------+---------------------+ 1419 | Content Seq. no | | | 1422 +----------------------+----------------------+---------------------+ 1424 Table 4 1426 11.2 TC Message: Address Blocks and Address TLVs 1428 Each OLSRv2 node, selected as MPR (i.e. a node with a non-empty MPR 1429 Selector Set) MUST generate TC messages with address blocks and 1430 address TLVs according to the following table: 1432 +---------------------------------+---------------------------------+ 1433 | Addresses | TLVs | 1434 +---------------------------------+---------------------------------+ 1435 | The set of neighbor interfaces, | | 1436 | which have selected the node as | | 1437 | MPR | | 1438 +---------------------------------+---------------------------------+ 1440 Table 5 1442 12. TC Message Processing 1444 Upon receiving a TC message, a node will update its topology 1445 information base according to the specification given in this 1446 section. 1448 For the purpose of this section, please notice the following: 1450 o the "validity time" of a message is calculated from the Vtime 1451 field of the message header as specified in Section 17; 1453 o the "originator address" refers to the address, contained in the 1454 "originator address" field of the OLSRv2 message header specified 1455 in Section 3.1; 1457 o the ASSN of the node, originating the TC message, is recovered as 1458 the value of the Content Seq. no message TLV in the TC message; 1460 Upon receiving a TC message, a node SHOULD update its topology set as 1461 follows: 1463 1. If the sender interface (NB: not originator) address of this 1464 message is not in the symmetric 1-hop neighborhood of this node, 1465 the message MUST be discarded; 1467 2. otherwise, if the TC message does not contain a message-TLV of 1468 type Content Seq. no., the message SHOULD be discarded; 1470 3. otherwise, if there exist some tuple in the topology set where: 1472 T_last_iface_addr == originator address in the message AND 1474 T_seq > ASSN; 1476 then the TC message SHOULD be discarded. 1478 4. The topology set is then updated in two steps: 1480 1. any topology tuple where: 1482 T_last_iface_addr == originator address in the message AND 1484 T_seq < ASSN 1486 SHOULD be removed. 1488 2. For each address, listed in the TC message: 1490 1. if there exists a tuple in the topology set where: 1492 T_dest_iface_addr == advertised neighbor address, AND 1494 T_last_iface_addr == originator address; 1496 then the tuple is updated as follows: 1498 T_time = current time + validity time. 1500 (Note that necessarily: T_seq == ASSN). 1502 2. Otherwise, a new topology tuple is created with: 1504 T_dest_iface_addr == advertised neighbor main address, 1505 AND 1507 T_last_iface_addr == originator address in the message 1508 AND 1510 T_seq == ASSN; 1512 13. MA Message Generation 1514 An OLSRv2 MA message is composed as described in Section 3.2: a set 1515 of message TLVs, describing general properties of the message and the 1516 node emitting the MA, and a set of address blocks (with associated 1517 TLV sets). These address blocks MUST list all addresses of the node 1518 which are participating in the OLSRv2 network. Other addresses of 1519 the node MAY also be included. 1521 An OLSRv2 MA message describes the set of addresses, associated to a 1522 given node. Nodes with a single address SHOULD NOT generate MA 1523 messages. Nodes with multiple addresses, participating in the OLSRv2 1524 network SHOULD generate MA messages. 1526 OLSRv2 MA messages are generated and transmitted per node, i.e. the 1527 same MA messages are generated and transmitted on all OLSRv2 1528 interfaces of a node. 1530 OLSRv2 TC messages are generated and transmitted periodically, with a 1531 default interval between two consecutive MA emissions by the same 1532 node of TC_INTERVAL. 1534 14. MA Message Processing 1536 Upon receiving a MA message the node SHOULD update its Neighborhood 1537 Address Association Set as follows: 1539 1. All neighborhood address association tuples where 1541 * I_neighbor_addr_list contains at least one address which is 1542 listed in the received MA message, 1544 SHOULD be removed, and a new neighborhood address association 1545 tuple SHOULD be created with: 1547 * I_neighbor_addr_list = list of all addresses contained in the 1548 received MA message; 1550 * I_time = current time + validity time. 1552 15. Routing Table Calculation 1554 A node records a set of "routing tuples": 1556 (R_dest_iface_addr, R_next_iface_addr, R_dist, R_iface_addr) 1558 describing the next hop and distance of the path to each destination 1559 in the network for which a route is known. 1561 R_dest_iface_addr is the interface address of the destination node; 1563 R_next_iface_addr is the interface address of the "next hop" on the 1564 path towards R_dest_iface_addr; 1566 R_dist is the number of hops on the path to R_dest_iface_addr; 1568 R_iface_addr is the address of the local interface over which a 1569 packet MUST be sent to reach R_next_iface_addr. 1571 In a node, the set of routing tuples is denoted the "routing set". 1573 The routing set is updated when a change (an entry appearing/ 1574 disappearing) is detected in: 1576 o the link set, 1578 o the neighbor address association set, 1580 o the 2-hop neighbor set, 1582 o the topology set, 1584 Updates to the routing set does not generate or trigger any messages 1585 to be transmitted. The state of the routing set SHOULD, however, be 1586 reflected in the IP routing table by adding and removing entries from 1587 the routing table as appropriate. 1589 To construct the routing set of node X, a shortest path algorithm is 1590 run on the directed graph containing the arcs X -> Y where Y is any 1591 symmetric neighbor of X (with Link Type equal to SYM), the arcs Y -> 1592 Z where Y is a neighbor node with willingness different of WILL_NEVER 1593 and there exists an entry in the 2-hop Neighbor set with Y as 1594 N_neighbor_iface_addr and Z as N_2hop_iface_addr, and the arcs U -> 1595 V, where there exists an entry in the topology set with V as 1596 T_dest_iface_addr and U as T_last_iface_addr. The graph is 1597 complemented with the arcs W0 -> W1 where W0 and W1 are two addresses 1598 of interfaces of a same neighbor (in a neighbor address association 1599 tuple). 1601 The following procedure is given as an example for (re-)calculating 1602 the routing set (with a breadth-first algorithm): 1604 1. All the tuples from the routing set are removed. 1606 2. The new routing tuples are added starting with the symmetric 1607 neighbors (h=1) as the destinations. Thus, for each tuple in the 1608 link set where: 1610 * L_STATUS = SYMMETRIC 1612 a new routing tuple is recorded in the routing set with: 1614 * R_dest_iface_addr = L_neighbor_iface_addr, of the link tuple; 1616 * R_next_iface_addr = L_neighbor_iface_addr, of the link tuple; 1618 * R_dist = 1; 1620 * R_iface_addr = L_local_iface_addr of the link tuple. 1622 3. for each neighbor address association tuple, for which two 1623 addresses A1 and A2 exist in I_neighbor_iface_addr_list where: 1625 * there exists a routing tuple with: 1627 + R_dest_iface_addr = A1 1629 * there is no routing tuple with: 1631 + R_dest_iface_addr = A2 1633 then a tuple in the routing set is created with: 1635 * R_dest_iface_addr = A2; 1637 * R_next_iface_addr = R_next_iface_addr of the route tuple of 1638 A1; 1640 * R_dist = R_dist of the route tuple of A1 (e.g. 1); 1642 * R_iface_addr = R_iface_addr of the route tuple of A1. 1644 4. for each symmetric strict 2-hop neighbor where the 1645 N_neighbor_iface_addr has a willingness different from WILL_NEVER 1646 a tuple in the routing set is created with: 1648 * R_dest_iface_addr = N_2hop_iface_addr of the 2-hop neighbor; 1650 * R_next_iface_addr = the R_next_iface_addr of the route tuple 1651 with: 1653 + R_dest_iface_addr == N_neighbor_iface_addr of the 2-hop 1654 tuple; 1656 * R_dist = 2; 1658 * R_iface_addr = the R_iface_addr of the route tuple with: 1660 + R_dest_iface_addr == N_neighbor_iface_addr of the 2-hop 1661 tuple; 1663 5. The new route tuples for the destination nodes h+1 hops away are 1664 recorded in the routing table. The following procedure MUST be 1665 executed for each value of h, starting with h=2 and incrementing 1666 by 1 for each iteration. The execution will stop if no new tuple 1667 is recorded in an iteration. 1669 1. For each topology tuple in the topology set, if its 1670 T_dest_iface_addr does not correspond to R_dest_iface_addr of 1671 any route tuple in the routing set AND its T_last_iface_addr 1672 corresponds to R_dest_iface_addr of a route tuple whose 1673 R_dist is equal to h, then a new route tuple MUST be recorded 1674 in the routing set (if it does not already exist) where: 1676 + R_dest_iface_addr = T_dest_iface_addr; 1678 + R_next_iface_addr = R_next_iface_addr of the route tuple 1679 where: 1681 - R_dest_iface_addr == T_last_iface_addr 1683 + R_dist = h+1; and 1685 + R_iface_addr = R_iface_addr of the route tuple where: 1687 - R_dest_iface_addr == T_last_iface_addr. 1689 2. Several topology tuples may be used to select a next hop 1690 R_next_iface_addr for reaching the node R_dest_iface_addr. 1691 When h=1, ties should be broken such that nodes with highest 1692 willingness and MPR selectors are preferred as next hop. 1694 16. Proposed Values for Constants 1696 This section list the values for the constants used in the 1697 description of the protocol. 1699 16.1 Message Types 1701 o HELLOv2 = 5 1703 o TCv2 = 6 1705 16.2 Message Intervals 1707 o HELLO_INTERVAL = 2 seconds 1709 o REFRESH_INTERVAL = 2 seconds 1711 o TC_INTERVAL = 5 seconds 1713 16.3 Holding Times 1715 o NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL 1717 o TOP_HOLD_TIME = 3 x TC_INTERVAL 1719 o DUP_HOLD_TIME = 30 seconds 1721 16.4 Willingness 1723 o WILL_NEVER = 0 1725 o WILL_LOW = 1 1727 o WILL_DEFAULT = 3 1729 o WILL_HIGH = 6 1731 o WILL_ALWAYS = 7 1733 17. Representing Time 1735 In HELLO messages, the 4 highest bits of the value of the TLV with 1736 Type="Htime" (see Appendix D.2.1) represent the mantissa (a) and the 1737 four lowest bits the exponent (b), yielding that the HELLO interval 1738 is expressed thus: C*(1+a/16)*2^b [in seconds] 1740 Similarily, the validity time is represented by its mantissa (four 1741 highest bits of Vtime field) and by its exponent (four lowest bits of 1742 Vtime field). In other words: 1744 o validity time = C*(1+a/16)* 2^b [in seconds] 1746 where a is the integer represented by the four highest bits of Vtime 1747 field and b the integer represented by the four lowest bits of Vtime 1748 field. The proposed value of the scaling factor C is specified in 1749 Section 16 1751 18. IANA Considerations 1753 OLSRv2 defines a TLV "Type" field for message TLVs and address block 1754 TLVs respectively. Two new registries MUST be created for values for 1755 this TLV type field, with initial assignments as specified in Table 6 1756 and Table 7 1758 Assigned message TLV Types 1760 +--------------------+--------+-------------------------------------+ 1761 | Mnemonic | Value | Description | 1762 +--------------------+--------+-------------------------------------+ 1763 | Fragmentation | 0 | Specifies behavior in case of | 1764 | | | content fragmentation | 1765 | | | | 1766 | Content Sequence | 1 | A sequence number, associated with | 1767 | Number | | the content of the message | 1768 | | | | 1769 | Willingness | 2 | Specifies a nodes willingness [0-7] | 1770 | | | to act as a relay and to parttake | 1771 | | | in network formation | 1772 +--------------------+--------+-------------------------------------+ 1774 Table 6 1776 Assigned address block TLV Types 1778 +--------------------+--------+-------------------------------------+ 1779 | Mnemonic | Value | Description | 1780 +--------------------+--------+-------------------------------------+ 1781 | Link Status | 0 | Specifies a given link's status | 1782 | | | (asymmetric, verified | 1783 | | | bidirectional, lost) | 1784 | | | | 1785 | MPR | 1 | Specifies that a given address is | 1786 | | | selected as MPR | 1787 +--------------------+--------+-------------------------------------+ 1789 Table 7 1791 OLSRv2 message types MUST be assigned from the OLSRv2 repository 1792 (HELLOv2, TCv2) 1794 Appendix A. Example Heuristic for Calculating MPRs 1796 The following specifies a proposed heuristic for selection of MPRs. 1798 In graph theory terms, MPR computation is a "set cover" problem, 1799 which is a difficult optimization problem, but for which an easy and 1800 efficient heuristics exist: the so-called "Greedy Heuristic", a 1801 variant of which is described here. In simple terms, MPR computation 1802 constructs an MPR-set that enables a node to reach any 2-hop 1803 interfaces through relaying by one MPR node. 1805 There are several peripheral issues that the algorithm need to 1806 address. The first one is that some nodes have some willingness 1807 WILL_NEVER. The second one is that some nodes may have several 1808 interfaces. 1810 The algorithm hence need to be precised in the following way: 1812 o All neighbor nodes with willingness equal to WILL_NEVER MUST 1813 ignored in the following algorithm: they are not considered as 1814 neighbors (hence not used as MPR), nor as 2-hop neighbors (hence 1815 no attempt to cover them is made). 1817 o Because link sensing is performed by interface, the local network 1818 topology, is best described in terms of links: hence the algorithm 1819 is considering neighbor interfaces, and 2-hop neighbor interfaces 1820 (and their addresses). Additionally, asymmetric links are 1821 ignored. This is reflected in the definitions below. 1823 o MPR computation is performed on each interface of the node: on 1824 each interface I, the node MUST select some neighbor interface, so 1825 that all 2-hop interfaces are reached. 1827 >From now on, MPR calculation will be described for one interface I 1828 on the node, and the following terminology will be used in describing 1829 the heuristics: 1831 neighbor interface (of I) - An interface of a neighbor to which there 1832 exist a symmetrical link on interface I. 1834 N - the set of such neighbor interfaces 1836 2-hop neighbor interface (of I) An interface of a symmetric strict 1837 2-hop neighbor and which can be reached from a neighbor interface 1838 for I. 1840 N2 - the set of such 2-hop neighbor interfaces 1842 D(y): - the degree of a 1-hop neighbor interface y (where y is a 1843 member of N), is defined as the number of symmetric neighbor 1844 interfaces of node y which are in N2 1846 MPR set - the set of the neighbor interfaces selected as MPR. 1848 The proposed heuristic selects iteratively some interfaces from N as 1849 MPR in order to cover 2-hop neighbor interfaces from N2, as follows: 1851 1. Start with an MPR set made of all members of N with N_willingness 1852 equal to WILL_ALWAYS 1854 2. Calculate D(y), where y is a member of N, for all interfaces in 1855 N. 1857 3. Add to the MPR set those interfaces in N, which are the *only* 1858 nodes to provide reachability to an interface in N2. For 1859 example, if interface B in N2 can be reached only through a 1860 symmetric link to interface A in N, then add interface B to the 1861 MPR set. Remove the interfaces from N2 which are now covered by 1862 a interface in the MPR set. 1864 4. While there exist interfaces in N2 which are not covered by at 1865 least one interface in the MPR set: 1867 1. For each interface in N, calculate the reachability, i.e., 1868 the number of interfaces in N2 which are not yet covered by 1869 at least one node in the MPR set, and which are reachable 1870 through this neighbor interface; 1872 2. Select as a MPR the interface with highest N_willingness 1873 among the interfaces in N with non-zero reachability. In 1874 case of multiple choice select the interface which provides 1875 reachability to the maximum number of interfaces in N2. In 1876 case of multiple interfaces providing the same amount of 1877 reachability, select the interface as MPR whose D(y) is 1878 greater. Remove the interfaces from N2 which are now covered 1879 by an interface in the MPR set. 1881 Other algorithms, as well as improvements over this algorithm, are 1882 possible. For example: 1884 o Some 2-hop neighbors may have several interfaces. The described 1885 algorithm attempts to reach every such interface of the nodes. 1886 However, whenever information that several 2-hop interfaces are, 1887 in fact, interfaces of the same 2-hop neighbor, is available, it 1888 can be used: only one of the interfaces of the 2-hop neighbor 1889 needs to be covered. 1891 o Assume that in a multiple-interface scenario there exists more 1892 than one link between nodes 'a' and 'b'. If node 'a' has selected 1893 node 'b' as MPR for one of its interfaces, then node 'b' can be 1894 selected as MPR with minimal performance loss by any other 1895 interfaces on node 'a'. 1897 Appendix B. Example Algorithms for Generating Control Traffic 1899 The proposed generation of the control messages proceeds in four 1900 steps. HELLO messages, like TC messages consist essentially in a 1901 list of advertised addresses of neighbors (some part of the 1902 topology). 1904 Hence, a first step is to collect the set of relevant of addresses 1905 which are to be advertised. Because there are a number of TLVs which 1906 can be associated to each address (including mandatory ones), this 1907 steps results into a list of addresses, each associated with a 1908 certain number of TLVs. 1910 Thus, the second step is then to regroup the addresses which share 1911 exactly the same TLVs (same Type and same Value), into an address 1912 block which will be associated with a list of TLVs. 1914 The third step is to pack the message header and message TLVs into a 1915 string of bytes. 1917 The fourth step consists in packing every address block obtained in 1918 the second step: by finding the longest common prefix of the 1919 addresses in the address block (the head), then, packing the list of 1920 the tail of the addresses into a string of bytes, followed by the 1921 TLVs of the address block. 1923 This generation method can be used for TC generation and HELLO 1924 generation: in each case, all what need to be specified is the 1925 message headers, message TLVs, and the list of each address with its 1926 associated TLVs. 1928 The message headers are identical to RFC 3626, and should be filled 1929 in the same way. The orginator address block MUST include all the 1930 addresses of the node (including the one of chosen for originator 1931 address in the message header) 1933 Appendix B.1 Example Algorithm for Generating HELLO messages 1935 This section proposes an algorithm for generating HELLOs 1936 Periodically, on every interface I, the node generates a HELLO 1937 message different on each interface, as follows: 1939 1. First, the list of the links of the interface is collected. It 1940 is the list of the link tuples where: 1942 * L_local_iface_addr == address of the interface 1944 Each corresponding address L_neighbor_iface_addr is then 1945 advertized with the following TLVs: 1947 * Type="Link Status", Value=L_STATUS, status of the link (see 1948 Section 5.1.1) 1950 * Type="Interface" Value="TransmittingInterface" 1952 * Type="MPR Selection", Value="True", if and only of the address 1953 L_neighbor_iface_addr is one interface address in the MPR set. 1955 2. Second, if the node has several interfaces, for each address 1956 which was not previously advertised, and for which there exists a 1957 link tuple on another interface where: 1959 * L_local_iface_addr is different from address of the interface 1960 I 1962 * L_STATUS == SYMMETRIC 1964 the corresponding address L_neighbor_iface_addr is advertized 1965 with the following TLVs: 1967 * Type="Link Status", Value=L_STATUS, status of the link (see 1968 Section 5.1.1) 1970 * Type="Interface" Value="Other" 1972 3. Then a HELLO message is generated using the previous method, with 1973 the proper headers and TLVs: 1975 * a message TLV with Type="Htime" and Value=encoding of the 1976 HELLO generation interval, is added 1978 * a message TLV with Type="Willingness" and Value=the 1979 willingness of the node. If a node has a willingness of 1980 WILL_DEFAULT, a node SHOULD NOT include a TLV with 1981 type="Willingness"; 1983 * the message header including Vtime, which MUST be set to a 1984 value higher than this generation interval, typically 3 times 1985 the generation interval, to allow for message losses. 1987 Appendix B.2 Example Algorithm for Generating TC messages 1989 Periodically, the node generates TC messages, broadcast on all the 1990 interfaces of the node, as follows: 1992 1. Each A_iface_addr in the Advertised Neighbor set, will be 1993 included in the TC message. 1995 2. The TC message is generated using the previous method with the 1996 proper headers, and including the mandatory TC message TLV, 1997 Type="ASSN" Value=the current value of the ASSN of the node. 1999 Appendix C. Protocol and Port Number 2001 Packets in OLSRv2 are communicated using UDP. Port 698 has been 2002 assigned by IANA for exclusive usage by the OLSR (v1 and v2) 2003 protocol. 2005 Appendix D. OLSRv2 Packet and Message Layout 2007 This section specifies the translation from the abstract descriptions 2008 of OLSRv2 control signals, employed in the protocol specification, 2009 and the bit-layout in the control-frames actually exchanged between 2010 the nodes. 2012 Appendix D.1 General OLSR Packet Format 2014 The basic layout of any packet in OLSRv2 is as follows (omitting IP 2015 and UDP headers): 2017 0 1 2 3 2018 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 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Packet Length | Packet Sequence Number | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Message Type | Vtime | Message Size | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Originator Address | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | Time To Live | Hop Count | Message Sequence Number | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Number of Msg TLVs | Number of Address Blocks | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Msg TLV | Msg TLV | | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2032 | | 2033 : ... : 2034 | | 2035 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | | Msg TLV | Padding | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | | 2039 | Originator Address Block: Addr Block 1 | 2040 | | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | | 2043 | Addr Block 2 | 2044 | | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | | 2047 : : 2048 | | 2049 (etc.) 2051 The generic packet format defined in RFC3626 encapsulates messages, 2052 similarly to OLSRv1. OLSRv2 messages are defined as new message 2053 types. These messages contain the same header as OLSRv1 messages, 2054 with address blocks and TLVs, as described below. 2056 Appendix D.1.1 Message TLVs 2058 The TLV format (Type-Length-Value) is used to introduce information 2059 in a flexible way. A message TLV associates some information 2060 (depending on the type) with the node/address that originated the 2061 message. 2063 0 1 2 3 2064 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 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Type | Length | | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2068 : Value ... : 2069 | | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 Appendix D.1.2 Address Block 2074 An address block is a way of representing addresses, as well as 2075 information associated with addresses, in a compact and flexible way. 2076 The proposed format of an address block is as follows: 2078 0 1 2 3 2079 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 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | # addresses | Addr. length | Head length | #TLV | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | | 2084 : Head : 2085 | | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Tail | Tail | | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2089 | | 2090 : ... : 2091 | | 2092 + +-+-+-+-+-+-+-+-+-+ 2093 | | Tail | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Addr. Block TLV | Addr. Block TLV | | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2097 | | 2098 : ... : 2099 | | 2100 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | | Addr. Block TLV | Padding | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 # addresses - The number of addresses in the address block 2106 Addr. length - The length, in bits, of an individual address. For 2107 IPv4 addresses, this field MUST be set to 32 For IPv6 addresses, 2108 this field MUST be set to 128 2110 Prefix length - The length of the common prefix of all the addresses 2111 in the address block. 0 <= Prefix length < Addr. length A prefix 2112 length of 0 indicates, that the prefix field (following) is 2113 absent. 2115 #TLV - The number of TLV's in the address block. 2117 Prefix The longest sequence of bits which is common among all the 2118 addresses, included in the address block. This field is of a 2119 fixed length, as specified in the field "prefix length" 2121 Host The host fields specifies the unique part of all the addresses, 2122 included in the address block. Indeed, letting + denote the 2123 concatenation operator, the expression prefix+host will yield a 2124 unique address. This field os of a fixed length = "Addr. length" 2125 - "Prefix length" 2127 TLV A TLV carries the information, associated to one, or a set of, 2128 addresses in the classic type-length-value format. This format is 2129 explicitly given below. 2131 Padding A variable-length field of all-zero's, to achieve 32-bit 2132 alignment of the packet. 2134 Note that no alignments are attempted -- all alignments happen in the 2135 address block listed above. 2137 Appendix D.1.3 Address Block TLV 2139 Again, the TLV format (Type-Length-Value) is used to introduce 2140 information in a flexible way inside Address Blocks. An Address 2141 Block TLV associates some information with some address(s) listed in 2142 the Address Block. 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Type | Index Start | Index Stop | Length | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | Value ... 2150 +-+-+-+-+-+-+-+-+ 2152 Type This field specifies the type of the TLV. 2154 Addr Start This field specifies to which address the TLV applies: the 2155 addresses listed between Index Start and Index Stop. 2157 Addr Stop This field specifies to which address the TLV applies: the 2158 addresses listed between Index Start and Index Stop. 2160 Length This field specifies the length of the data contained in 2161 "Value" 2163 Value This field is a field of the length specified in Length, which 2164 contains data -- information, which is to be interpreted according 2165 to the specification by the "Type" field, and in the context given 2166 by the "addr#" and "Offset" fields. 2168 Appendix D.2 Layout of OLSRv2 Specified Messages 2170 The message format specified for OLSRv2 allows a great deal of 2171 flexibility in how control messages are organized. For example, 2172 while it is possible to represent a sequence of addresses as an 2173 address-block, it is also possible -- although possibly less optimal 2174 -- to represent the same sequence as individual addresses in an 2175 OLSRv2 control message. 2177 This section will, therefore, give an example of how OLSRv2 HELLO and 2178 TC messages typically can be be generated. It is, however, important 2179 to keep in mind that this section presents one possible instance of 2180 HELLO and TC messages. 2182 Appendix D.2.1 Layout of HELLO Messages 2184 HELLO TLVs 2186 +-------------+---------------+------------+-------------------------+ 2187 | Type | Scope | Importance | Description | 2188 +-------------+---------------+------------+-------------------------+ 2189 | Status | Address Block | MUST | SYM, ASYM, LOST | 2190 | | | | | 2191 | MPR | Address Block | MUST | Nodes selected as MPR | 2192 | | | | | 2193 | Willingness | Message | MAY | Willingness information | 2194 | | | | | 2195 | Htime | Message | MUST | Htime information | 2196 +-------------+---------------+------------+-------------------------+ 2198 Table 8 2200 Appendix D.2.2 Layout of TC messages 2202 TC TLVs 2204 +------+-------+------------+-------------------------------------+ 2205 | Type | Scope | Importance | Description | 2206 +------+-------+------------+-------------------------------------+ 2207 | ASSN | Msg | MUST | Advertised Neighbor Sequence Number | 2208 +------+-------+------------+-------------------------------------+ 2210 Table 9 2212 0 1 2 3 2213 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 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | TC Msg Type | Vtime | Message Size | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | Originator Address | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | Time To Live | Hop Count | Message Sequence Number | 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Number of Msg TLVs (1) | Number of Address Blocks (1) | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | ANSN (Message TLV) | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 |# addresses(17)|Addr lgth (32) |Prefx lgth (28)| #TLV (2) | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | IP Prefix | Host1 | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Host2 | Host3 | Host4 | Host5 | Host6 | Host7 | Host8 | Host9 | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Host10| Host11| Host12| Host13| Host14| Host15| Host16| Host17| 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Same Node (Addr. Block TLV) | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 Appendix E. Node Configuration 2242 OLSRv2 does not make any assumption about node addresses, other than 2243 that each node is assumed to have a unique and routable IP address. 2245 When applicable, a recommended way of connecting an OLSR network to 2246 an existing IP routing domain is to assign an IP prefix (under the 2247 authority of the nodes/gateways connecting the MANET with the routing 2248 domain) exclusively to the OLSR area, and to configure the gateways 2249 statically to advertise routes to that IP sequence to nodes in the 2250 existing routing domain. 2252 Appendix E.1 IPv6 Specific Considerations 2254 In the case of IPv6, a node's routable IP address can either be a 2255 global address, or a manet-local address (as described in 2256 draft-wakikawa-manet-ipv6). Typically an OLSRv2 may have several 2257 addresses, for example: a link-local address and a routable address. 2258 However the link-local address is only valid within the 1-hop 2259 neighborhood. It may be used to resolve neighbor state with the 2260 Neighbor Discovery Protocol, but routes to link-local addresses MUST 2261 NOT be advertized and MUST NOT be inserted in routing tables. Only 2262 routable addresses are stored in routing tables, and a routable 2263 address MUST be used for the originator address in HELLO messages and 2264 in TC messages. 2266 OLSRv2 uses a specific flooding address (ff02::3) called the All- 2267 OLSRv2-Multicast address. This address is similar to all nodes/ 2268 routers multicast address in IPv6 specification (i.e. ff02::1 or 2269 ff02::2). The difference is that All-OLSRv2-Multicast specifies that 2270 intended receivers are OLSRv2 nodes. Since the All-OLSRv2-Multicast 2271 address is a link-local address, the message sent to the multicast 2272 address can not reach further than 1 hop. Each OLSRv2 node MUST 2273 process flooding packets and possibly re-flood the packets to the 2274 same destination (ff02::3), if they are designated forwarders. Note 2275 that although ff02::3 is a link-local address, each flooded message 2276 MUST be transmitted with a routable address as originator address. 2278 Appendix F. Security Considerations 2280 Currently, OLSR does not specify any special security measures. As a 2281 proactive routing protocol, OLSR makes a target for various attacks. 2282 The various possible vulnerabilities are discussed in this section. 2284 Appendix F.1 Confidentiality 2286 Being a proactive protocol, OLSR periodically diffuses topological 2287 information. Hence, if used in an unprotected wireless network, the 2288 network topology is revealed to anyone who listens to OLSR control 2289 messages. 2291 In situations where the confidentiality of the network topology is of 2292 importance, regular cryptographic techniques such as exchange of OLSR 2293 control traffic messages encrypted by PGP [9] or encrypted by some 2294 shared secret key can be applied to ensure that control traffic can 2295 be read and interpreted by only those authorized to do so. 2297 Appendix F.2 Integrity 2299 In OLSR, each node is injecting topological information into the 2300 network through transmitting HELLO messages and, for some nodes, TC 2301 messages. If some nodes for some reason, malicious or malfunction, 2302 inject invalid control traffic, network integrity may be compromised. 2303 Therefore, message authentication is recommended. 2305 Different such situations may occur, for instance: 2307 1. a node generates TC messages, advertising links to non-neighbor 2308 nodes; 2310 2. a node generates TC messages, pretending to be another node; 2312 3. a node generates HELLO messages, advertising non-neighbor nodes; 2314 4. a node generates HELLO messages, pretending to be another node; 2316 5. a node forwards altered control messages; 2318 6. a node does not broadcast control messages; 2320 7. a node does not select multipoint relays correctly; 2322 8. a node forwards broadcast control messages unaltered, but does 2323 not forward unicast data traffic; 2325 9. a node "replays" previously recorded control traffic from another 2326 node. 2328 Authentication of the originator node for control messages (for 2329 situation 2, 4 and 5) and on the individual links announced in the 2330 control messages (for situation 1 and 3) may be used as a 2331 countermeasure. However to prevent nodes from repeating old (and 2332 correctly authenticated) information (situation 9) temporal 2333 information is required, allowing a node to positively identify such 2334 delayed messages. 2336 In general, digital signatures and other required security 2337 information may be transmitted as a separate OLSRv2 message type, 2338 thereby allowing that "secured" and "unsecured" nodes can coexist in 2339 the same network, if desired, or signatures and security information 2340 may be transmitted within the OLSRv2 HELLO and TC messages, using the 2341 TLV mechanism. 2343 Specifically, the authenticity of entire OLSRv2 control messages can 2344 be established through employing IPsec authentication headers, 2345 whereas authenticity of individual links (situation 1 and 3) require 2346 additional security information to be distributed. 2348 An important consideration is, that all control messages in OLSR are 2349 transmitted either to all nodes in the neighborhood (HELLO messages) 2350 or broadcast to all nodes in the network (e.g., TC messages). 2352 For example, a control message in OLSRv2 is always a point-to- 2353 multipoint transmission. It is therefore important that the 2354 authentication mechanism employed permits that any receiving node can 2355 validate the authenticity of a message. As an analogy, given a block 2356 of text, signed by a PGP private key, then anyone with the 2357 corresponding public key can verify the authenticity of the text. 2359 Appendix F.3 Interaction with External Routing Domains 2361 OLSRv2 does, through the use of TC messages, provide a basic 2362 mechanism for injecting external routing information to the OLSRv2 2363 domain. Section XXX also specifies that routing information can be 2364 extracted from the topology table or the routing table of OLSR and, 2365 potentially, injected into an external domain if the routing protocol 2366 governing that domain permits. 2368 Other than as described in the section XXX, when operating nodes, 2369 connecting OLSRv2 to an external routing domain, care MUST be taken 2370 not to allow potentially insecure and un-trustworthy information to 2371 be injected from the OLSRv2 domain to external routing domains. Care 2372 MUST be taken to validate the correctness of information prior to it 2373 being injected as to avoid polluting routing tables with invalid 2374 information. 2376 A recommended way of extending connectivity from an existing routing 2377 domain to an OLSRv2 routed MANET is to assign an IP prefix (under the 2378 authority of the nodes/gateways connecting the MANET with the exiting 2379 routing domain) exclusively to the OLSRv2 MANET area, and to 2380 configure the gateways statically to advertise routes to that IP 2381 sequence to nodes in the existing routing domain. 2383 Appendix F.4 Node Identity 2385 OLSR does not make any assumption about node addresses, other than 2386 that each node is assumed to have a unique IP address. 2388 Appendix G. Flow and Congestion Control 2390 TBD 2392 Appendix H. Sequence Numbers 2394 Sequence numbers are used in OLSR with the purpose of discarding 2395 "old" information, i.e., messages received out of order. However 2396 with a limited number of bits for representing sequence numbers, 2397 wrap-around (that the sequence number is incremented from the maximum 2398 possible value to zero) will occur. To prevent this from interfering 2399 with the operation of OLSRv2, the following MUST be observed. 2401 The term MAXVALUE designates in the following the largest possible 2402 value for a sequence number. 2404 The sequence number S1 is said to be "greater than" the sequence 2405 number S2 if: 2407 o S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR 2409 o S2 > S1 AND S2 - S1 > MAXVALUE/2 2411 Thus when comparing two messages, it is possible - even in the 2412 presence of wrap-around - to determine which message contains the 2413 most recent information. 2415 Appendix I. References 2417 o [1] P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. 2418 Increasing reliability in cable free radio LANs: Low level 2419 forwarding in HIPERLAN. Wireless Personal Communications, 1996. 2421 o [2] A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An 2422 efficient technique for flooding in mobile wireless networks. 35th 2423 Annual Hawaii International Conference on System Sciences 2424 (HICSS'2001). 2426 o [3] ETSI STC-RES10 Committee. Radio equipment and systems: 2427 HIPERLAN type 1, functional specifications ETS 300-652, ETSI, June 2428 1996. 2430 o [4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network 2431 Protocols, INRIA research report RR-3965, 2000. 2433 o [5] Bradner, S., "Key words for use in RFCs to Indicate 2434 Requirement Levels", BCP 14, RFC 2119, March 1997. 2436 o [6] T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The 2437 Optimized Link State Routing Protocol, Evaluation through 2438 Experiments and Simulation. IEEE Symposium on "Wireless Personal 2439 Mobile Communications", September 2001. 2441 o [7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. 2442 Qayyum and L. Viennot. Optimized Link State Routing Protocol. 2443 IEEE INMIC Pakistan 2001. [8] Narten, T. and H. Alvestrand, 2444 "Guidelines for Writing an IANA Considerations Section in RFCs", 2445 BCP 26, RFC 2434, October 1998. 2447 o [9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message 2448 Exchange Formats", RFC 1991, August 1996. 2450 o [10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance 2451 analysis of OLSR multipoint relay flooding in two ad hoc wireless 2452 network models, INRIA research report RR-4260, 2001. 2454 Appendix J. Contributors 2456 This specification is the result of the joint efforts of the 2457 following contributers -- listed alphabetically. 2459 o Cedric Adjih, INRIA, France, 2461 o Emmanuel Baccelli, INRIA, France, 2463 o Thomas Heide Clausen, PCRI, 2465 o Justin Dean, NRL, 2467 o Christopher Dearlove, BAE Systems, UK, 2468 2470 o Satoh Hiroki, Hitachi SDL, Japan, 2472 o Monden Kazuya, Hitachi SDL, Japan, 2474 o Kenichi Mase, University, Japan, 2476 o Ryuji Wakikawa, KEIO University, Japan, 2478 Appendix K. Acknowledgements 2480 The authors would like to acknowledge the team behind OLSRv1, 2481 specified in RFC3626, including Paul Muhlethaler, Philippe Jacquet, 2482 Anis Laouiti, Pascale Minet, Laurent Viennot (all at INRIA, France), 2483 and Amir Qayuum (Center for Advanced Research in Engineering) for 2484 their contributions. 2486 The authors would like to gratefully acknowledge the following people 2487 for intense technical discussions, early reviews and comments on the 2488 specification and its components: Kenichi Mase (Niigata University), 2489 Li Li (CRC), Louise Lamont (CRC), Joe Macker (NRL), Alan Cullen (BAE 2490 Systems), Philippe Jacquet (INRIA), Khaldoun Al Agha (LRI), Richard 2491 Ogier (?), Song-Yean Cho (Samsung Software Center), Shubhranshu Singh 2492 (Samsung AIT) and the entire IETF MANET working group. 2494 Author's Address 2496 Thomas Heide Clausen 2497 LIX, Ecole Polytechnique, France 2499 Phone: +33 6 6058 9349 2500 Email: T.Clausen@computer.org 2501 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 2503 Intellectual Property Statement 2505 The IETF takes no position regarding the validity or scope of any 2506 Intellectual Property Rights or other rights that might be claimed to 2507 pertain to the implementation or use of the technology described in 2508 this document or the extent to which any license under such rights 2509 might or might not be available; nor does it represent that it has 2510 made any independent effort to identify any such rights. Information 2511 on the procedures with respect to rights in RFC documents can be 2512 found in BCP 78 and BCP 79. 2514 Copies of IPR disclosures made to the IETF Secretariat and any 2515 assurances of licenses to be made available, or the result of an 2516 attempt made to obtain a general license or permission for the use of 2517 such proprietary rights by implementers or users of this 2518 specification can be obtained from the IETF on-line IPR repository at 2519 http://www.ietf.org/ipr. 2521 The IETF invites any interested party to bring to its attention any 2522 copyrights, patents or patent applications, or other proprietary 2523 rights that may cover technology that may be required to implement 2524 this standard. Please address the information to the IETF at 2525 ietf-ipr@ietf.org. 2527 Disclaimer of Validity 2529 This document and the information contained herein are provided on an 2530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2537 Copyright Statement 2539 Copyright (C) The Internet Society (2005). This document is subject 2540 to the rights, licenses and restrictions contained in BCP 78, and 2541 except as set forth therein, the authors retain all their rights. 2543 Acknowledgment 2545 Funding for the RFC Editor function is currently provided by the 2546 Internet Society.