idnits 2.17.1 draft-ietf-manet-nhdp-07.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2484. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 861 has weird spacing: '...dr_list is an...' == Line 864 has weird spacing: '...I_manet is a ...' == Line 878 has weird spacing: '...ce_addr is a ...' == Line 881 has weird spacing: '...IR_time speci...' == Line 907 has weird spacing: '...dr_list is an...' == (13 more instances...) -- 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 (July 10, 2008) is 5769 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5148 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 Intended status: Standards Track C. Dearlove 5 Expires: January 11, 2009 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 The OLSRv2 Design Team 10 MANET Working Group 11 July 10, 2008 13 MANET Neighborhood Discovery Protocol (NHDP) 14 draft-ietf-manet-nhdp-07 16 Status of This Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 11, 2009. 41 Abstract 43 This document describes a 1-hop and symmetric 2-hop neighborhood 44 discovery protocol (NHDP) for mobile ad hoc networks (MANETs). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 52 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9 53 4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 10 54 4.2. Information Base Overview . . . . . . . . . . . . . . . . 10 55 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 10 56 4.2.2. Interface Information Bases . . . . . . . . . . . . . 11 57 4.2.3. Node Information Base . . . . . . . . . . . . . . . . 11 58 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 12 59 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 12 60 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 12 61 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 13 62 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 14 63 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 15 64 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 15 65 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 15 66 5.1.2. Information Validity Times . . . . . . . . . . . . . . 16 67 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 17 68 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 18 69 5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 18 70 5.2.1. Information Validity Time . . . . . . . . . . . . . . 18 71 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 18 72 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 20 73 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21 74 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21 75 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 21 76 7. Interface Information Base . . . . . . . . . . . . . . . . . . 22 77 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 23 79 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 24 80 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24 81 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 24 82 9. Local Information Base Changes . . . . . . . . . . . . . . . . 25 83 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25 84 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 25 85 9.3. Adding an Address to an Interface . . . . . . . . . . . . 26 86 9.4. Removing an Address from an Interface . . . . . . . . . . 27 87 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28 88 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 28 89 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29 90 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31 91 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31 92 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33 93 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33 94 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34 95 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 35 96 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 36 97 12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 36 98 12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 38 99 13. Other Information Base Changes . . . . . . . . . . . . . . . . 40 100 13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 40 101 13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41 102 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42 103 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43 105 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43 106 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44 107 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45 108 15. Proposed Values for Parameters and Constants . . . . . . . . . 46 109 15.1. Message Interval Interface Parameters . . . . . . . . . . 46 110 15.2. Information Validity Time Interface Parameters . . . . . . 46 111 15.3. Information Validity Time Node Parameters . . . . . . . . 46 112 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46 113 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46 114 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47 115 16. Security Considerations . . . . . . . . . . . . . . . . . . . 48 116 16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48 117 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 118 17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 119 17.2. Address Block TLV Types . . . . . . . . . . . . . . . . . 50 120 17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 51 121 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 122 18.1. Normative References . . . . . . . . . . . . . . . . . . . 53 123 18.2. Informative References . . . . . . . . . . . . . . . . . . 53 124 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54 125 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 55 126 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 58 127 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61 128 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 62 129 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 63 131 1. Introduction 133 This document describes a neighborhood discovery protocol (NHDP) for 134 a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an 135 exchange of HELLO messages in order that each node can determine the 136 presence and status of its 1-hop and symmetric 2-hop neighbors. 137 Messages are defined as instances of the specification [packetbb]. 139 This neighborhood information is recorded in the form of Information 140 Bases. These may be used by other protocols, such as MANET routing 141 protocols, for determining local connectivity and node configuration. 142 This protocol is designed to maintain this information in the 143 presence of a dynamic network topology. 145 This protocol makes no assumptions about the underlying link layer, 146 other than support of link local broadcast or multicast. Link layer 147 information may be used if available and applicable. 149 This protocol is based on the neighborhood discovery process 150 contained in the Optimized Link State Routing Protocol (OLSR) 151 [RFC3626]. 153 1.1. Motivation 155 MANETs differ from more traditional wired and infrastructure based 156 wireless networks, due to their envisioned applicability also over 157 more challenging network interfaces (e.g. wireless, lossy, broadcast 158 interfaces with moderate and shared bandwidth, hidden and exposed 159 terminals and interference from other network interfaces and the 160 environment) and in more challenging topological conditions (e.g. 161 rapid and unpredictable mobility, dynamic and non-predetermined 162 network membership). An approach, often taken by MANET routing 163 protocols, is to collect local topological information up to 2 hops, 164 in order to, for example, optimize their flooding performance within 165 the MANET. 167 Due to the properties of wireless transmissions, communication 168 between two network interfaces on neighboring nodes may not be bi- 169 directional; even if node A is able to receive a packets from node B, 170 the converse is not guaranteed to be true. Furthermore, because of 171 the localized nature of wireless broadcasts communication, differing 172 neighbor sets often exist for differing neighboring nodes within the 173 same communications channel. If node A is able to exchange packets 174 with node B and node B is able to exchange packets with node C on the 175 same interface, this does not guarantee that node A and node C can 176 exchange packets directly. 178 Nodes in a MANET may have multiple heterogeneous interfaces 179 participating in the same MANET routing protocol, each of which with 180 the characteristics as described above. Between the same pair of 181 nodes more than one distinct communications channel (links) may 182 therefore exist, with different properties. 184 For MANET routing protocols to correctly identify candidate links for 185 inclusion in a routing path, the existence and bi-directionality of 186 such distinct links between a node and its neighbors must be 187 established and monitored. 189 The set of neighbor nodes of a given MANET node may be continuously 190 changing, often due to node mobility or due to a changing physical 191 environment in which the MANET is located. There are typically no 192 signals from lower layers which would enable an IP routing protocol 193 to detect and, as appropriate, react to such changes. Yet as such 194 changes are can often take place on the order of seconds, requiring 195 MANET IP routing protocols to also act rapidly to ensure sufficient 196 convergence properties. 198 MANET routing protocols often employ relay set reductions in order to 199 conserve network capacity when maintaining network-wide topological 200 information, with calculation of these reduced relay sets employing 201 up to 2-hop information. Such is the case e.g. for [RFC3626]. 203 The neighborhood discovery protocol specified in this document 204 provides continued tracking of neighborhood changes, continued bi- 205 directionality tracking of links between neighbors and local 206 topological information up to two hops. Combined, this allows a 207 MANET routing protocol access to information describing link 208 establishment/disappearance, and provides the necessary topological 209 information for reduced relay set selection and other purposes. 211 2. Terminology 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in 216 [RFC2119]. 218 The terms "packet", "message", "address", "address block", "TLV", and 219 "TLV block" in this document are to be interpreted as described in 220 [packetbb]. 222 Additionally, this document uses the following terminology: 224 Node - A MANET router which implements this neighborhood discovery 225 protocol. 227 Interface - A network device, configured and assigned one or more IP 228 addresses. 230 Address - An address, as recorded in the Information Bases specified 231 by this protocol, and included in HELLO messages generated by this 232 protocol, may be either an address or an address prefix. The 233 exception to this is addresses described as originator addresses; 234 these must be simple addresses without a prefix length. Non- 235 originator addresses can be represented as a single address object 236 in a HELLO message, as defined by [packetbb]. An address so 237 represented is considered to have a prefix length equal to its 238 length (in bits) when considered as an address object, and a 239 similar convention is used in the Information Bases specified by 240 this protocol. Two addresses (address objects) are considered 241 equal only if their prefix lengths are also equal. 243 MANET interface - An interface participating in a MANET and using 244 this neighborhood discovery protocol. A node may have several 245 MANET interfaces. 247 Heard - A MANET interface of node X is considered heard on a MANET 248 interface of a node Y if the latter can receive traffic from the 249 former. 251 Link - A pair of MANET interfaces from two different nodes, where at 252 least one interface is heard by the other. 254 Symmetric link - A link where both MANET interfaces are heard by the 255 other. 257 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET 258 interface of node X is heard by a MANET interface of node Y. 260 Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of 261 a node Y if a symmetric link exists between a MANET interface on 262 node X and a MANET interface on node Y. 264 Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of 265 a node Y if node X is a symmetric 1-hop neighbor of a symmetric 266 1-hop neighbor of node Y, but is not node Y itself. 268 1-hop neighborhood - The 1-hop neighborhood of a node X is the set 269 of the 1-hop neighbors of node X. 271 Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a 272 node X is the set of the symmetric 1-hop neighbors of node X. 274 Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a 275 node X is the set of the symmetric 2-hop neighbors of node X. 276 (This may include nodes in the 1-hop neighborhood, or even in the 277 symmetric 1-hop neighborhood, of node X.) 279 Constant - A constant is a numerical value which MUST be the same 280 for all MANET interfaces of all nodes in the MANET, at all times. 282 Interface parameter - An interface parameter is a boolean or 283 numerical value, specified separately for each MANET interface of 284 each node. A node MAY change interface parameter values at any 285 time, subject to some constraints. 287 Node parameter - A node parameter is a boolean or numerical value, 288 specified for each node. A node MAY change node parameter values 289 at any time, subject to some constraints. 291 3. Applicability Statement 293 This protocol: 295 o Is applicable to networks, especially wireless networks, in which 296 unknown neighbors (i.e. other nodes with which direct 297 communication can be established) can be reached by local 298 broadcast or multicast packets. 300 o Is designed to work in networks with a dynamic topology, and in 301 which messages may be lost, such as due to collisions in wireless 302 networks. 304 o Supports nodes that each have one or more participating MANET 305 interfaces. The set of a node's interfaces may change over time. 306 Each interface may have one or more interface addresses, and these 307 may also be dynamically changing. 309 o Can use the link local multicast address "LL-MANET-Routers", and 310 either the "manet" UDP port or the "manet" IP protocol number, all 311 as specified in [manet-iana]. 313 o Uses the packet and message formats specified in [packetbb]. Such 314 packets may contain messages specified by this protocol as well as 315 other protocols. 317 o Specifies signaling using HELLO messages. The necessary contents 318 of these messages are defined in this specification, and may be 319 extended using the TLV mechanisms described in [packetbb]. 321 o Can use relevant link layer information if it is available. 323 o Provides each node with local topology information up to two hops 324 away. This information is made available to other protocols, of 325 which this protocol may be a part, in Information Bases defined in 326 this specification. 328 o Is designed to work in a completely distributed manner, and does 329 not depend on any central entity. 331 4. Protocol Overview and Functioning 333 The objective of this protocol is, for each node: 335 o To identify other nodes with which bidirectional links can be 336 established (symmetric 1-hop neighbors). 338 o To agree on the status of such links with the corresponding 339 symmetric 1-hop neighbor. 341 o To find the node's symmetric 2-hop neighbors. 343 o To record this information in Information Bases that can be used 344 by other protocols, of which this neighborhood discovery protocol 345 may be a part. 347 These objectives are achieved using local (one hop) signaling that: 349 o Advertises the presence of a node and its interfaces. 351 o Discovers links with adjacent nodes. 353 o Performs bidirectionality checks on the discovered links. 355 o Advertises discovered links, and whether each is symmetric, to its 356 1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 358 This specification defines, in turn: 360 o Parameters and constants used by the protocol. Parameters used by 361 this protocol may be, where appropriate, specific to a MANET 362 interface. This protocol allows all parameters to be changed 363 dynamically. 365 o The Information Bases describing local interfaces, discovered 366 links and their status, current and former 1-hop neighbors, and 367 symmetric 2-hop neighbors. 369 o The format of the HELLO message that is used for local signaling. 371 o The generation of HELLO messages from some of the information in 372 the Information Bases. 374 o The updating of the Information Bases according to received HELLO 375 messages and other events. 377 4.1. Nodes and Interfaces 379 In order for a node to participate in a MANET, it MUST have at least 380 one, and possibly more, MANET interfaces. Each MANET interface: 382 o Is characterized by a set of interface parameters, defining the 383 behavior of this MANET interface. Each MANET interface MAY be 384 individually parameterized. 386 o Has an Interface Information Base, recording information regarding 387 links to this MANET interface and symmetric 2-hop neighbors which 388 can be reached through such links. 390 o Generates and processes HELLO messages, according to the interface 391 parameters for that MANET interface. 393 In addition to a set of MANET interfaces as described above, each 394 node has: 396 o A Local Information Base, containing the addresses of the 397 interfaces (MANET and non-MANET) of this node. The contents of 398 this Information Base are not changed by signaling. 400 o A Node Information Base, recording information regarding current 401 and recently lost 1-hop neighbors of this node. 403 A node may have both MANET interfaces and non-MANET interfaces. 404 Interfaces of both of these types are recorded in a node's Local 405 Information Base, which is used, but not updated, by the signaling of 406 this protocol. 408 4.2. Information Base Overview 410 Each node maintains the Information Bases described in the following 411 sections. These are used for describing the protocol in this 412 document. An implementation of this protocol MAY maintain this 413 information in the indicated form, or in any other organization which 414 offers access to this information. In particular note that it is not 415 necessary to remove Tuples from Sets at the exact time indicated, 416 only to behave as if the Tuples were removed at that time. 418 4.2.1. Local Information Base 420 Each node maintains a Local Information Base, which contains: 422 o The Local Interface Set, which consists of Local Interface Tuples, 423 each of which records the addresses of an interface (MANET or non- 424 MANET) of the node. 426 o The Removed Interface Address Set, which consists of Removed 427 Interface Address Tuples, each of which records a recently used 428 address of an interface (MANET or non-MANET) of the node. 430 4.2.2. Interface Information Bases 432 Each node maintains, for each of its MANET interfaces, an Interface 433 Information Base, which contains: 435 o A Link Set, which records information about current and recently 436 lost links between this interface and MANET interfaces of 1-hop 437 neighbors. The Link Set consists of Link Tuples, each of which 438 contains information about a single link. Recently lost links are 439 recorded so that they can be advertised in HELLO messages, 440 accelerating their removal from relevant 1-hop neighbors' Link 441 Sets. Link quality information, if used and available, is 442 recorded in Link Tuples and may indicate that links are treated as 443 lost. 445 o A 2-Hop Set, which records the existence of bidirectional links 446 between symmetric 1-hop neighbors of this MANET interface and 447 other nodes (symmetric 2-hop neighbors). The 2-Hop Set consists 448 of 2-Hop Tuples, each of which records an interface address of a 449 symmetric 2-hop neighbor, and all interface addresses of the 450 corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated 451 by the signaling of this protocol, but is not itself reported in 452 that signaling. 454 4.2.3. Node Information Base 456 Each node maintains a Node Information Base, which contains: 458 o The Neighbor Set, which records 1-hop neighbors, each of which 459 must be currently heard, although this may be over a link with 460 insufficient link quality. The Neighbor Set consists of Neighbor 461 Tuples, each of which records all interface addresses (whether 462 directly linked or not) of a single 1-hop neighbor. Neighbor 463 Tuples are maintained as long as there are corresponding current 464 Link Tuples. 466 o The Lost Neighbor Set, which records recently lost symmetric 1-hop 467 neighbors. The Lost Neighbor Set consists of Lost Neighbor 468 Tuples, each of which records an interface address of such a 469 neighbor. These are recorded so that they can be advertised in 470 HELLO messages, accelerating their removal from other nodes' 2-Hop 471 Sets. 473 4.3. Signaling Overview 475 This protocol contains a signaling mechanism for maintaining the 476 Interface Information Bases and the Node Information Base. If 477 information from the link layer, or any other source, is available 478 and appropriate, it may also be used to update these Information 479 Bases. Such updates are subject to the constraints specified in 480 Appendix C. 482 Signaling consists of a single type of message, known as a HELLO 483 message. Each node generates HELLO messages on each of its MANET 484 interfaces. Each HELLO message identifies that MANET interface, and 485 reports the other interfaces (MANET and non-MANET) of the node. Each 486 HELLO message includes information from the Link Set of the Interface 487 Information Base of the MANET interface, and from the Node 488 Information Base. 490 4.3.1. HELLO Message Generation 492 HELLO messages are generated by a node for each of its MANET 493 interfaces, and MAY be sent: 495 o Proactively, at a regular interval, known as HELLO_INTERVAL. 496 HELLO_INTERVAL may be fixed, or may be dynamic. For example 497 HELLO_INTERVAL may be backed off due to congestion or network 498 stability. 500 o As a response to a change in the node itself, or its 1-hop 501 neighborhood, for example on first becoming active or in response 502 to a new, broken, or changed status link. 504 o In a combination of these proactive and responsive mechanisms. 506 Jittering of HELLO message generation and transmission, as described 507 in Section 11.2, SHOULD be used if appropriate. 509 HELLO messages are generated independently on each MANET interface of 510 a node. HELLO messages MAY be scheduled independently for each MANET 511 interface, or, interface parameters permitting, using the same 512 schedule for all MANET interfaces of a node. 514 4.3.2. HELLO Message Content 516 Each HELLO message sent over a MANET interface need not contain all 517 of the information appropriate to that MANET interface, however: 519 o A HELLO message MUST contain all of the addresses in the Local 520 Interface Set of the node to which the MANET interface belongs. 522 o Within every time interval of length REFRESH_INTERVAL, the HELLO 523 messages sent on each MANET interface of a node MUST collectively 524 include: 526 * All of the relevant information in the Link Set of the 527 Interface Information Base of that MANET interface. 529 * All of the relevant information in the Node Information Base of 530 that node. 532 This applies to otherwise purely responsive nodes as well as to 533 proactive nodes. In either case it means that all information 534 appropriate to that MANET interface will have always been 535 transmitted, in one or more HELLO messages, since the time 536 REFRESH_INTERVAL ago. 538 o A HELLO message MUST include a VALIDITY_TIME message TLV that 539 indicates the length of time for which the message content is to 540 be considered valid, and included in the receiving node's 541 Interface Information Base. 543 o A periodically generated HELLO message SHOULD include an 544 INTERVAL_TIME message TLV that indicates the current value of 545 HELLO_INTERVAL for that MANET interface, i.e. the period within 546 which a further HELLO message is guaranteed to be sent on that 547 MANET interface. 549 o Additional information may be added by a protocol using this 550 protocol using the TLV mechanisms described in [packetbb]. For 551 example, if multipoint relays (MPRs) are to be calculated 552 similarly to as in OLSR [RFC3626] and signaled to neighbors, then 553 this information may be added to HELLO messages using an address 554 block TLV. 556 4.3.3. HELLO Message Processing 558 All HELLO messages received by a node are used to update: 560 o The Interface Information Base for the MANET interface on which 561 that HELLO message is received. 563 o The Node Information Base. 565 Specifically: 567 o The node ensures that there is a single Neighbor Tuple 568 corresponding to the originator of that HELLO message. 570 o If a Link Tuple corresponding to the link on which that HELLO 571 message was received exists, then its duration is extended, 572 otherwise such a Link Tuple is created. If the HELLO message 573 indicates that the receiving MANET interface has been heard, then 574 the link is considered symmetric, or its duration as symmetric is 575 extended. If the HELLO message indicates that the receiving MANET 576 interface is lost, then the link is no longer considered 577 symmetric. In this case one or more Lost Neighbor Tuples may be 578 created. 580 o If the link on which the HELLO message is received is symmetric, 581 then any symmetrically advertised neighbors in the HELLO message 582 are added to the 2-Hop Set for the receiving interface, or if 583 already present, the durations of the corresponding 2-Hop Tuples 584 are extended. 586 In all cases the processing takes account of unexpected and erroneous 587 information in the HELLO message, maintaining the constraints 588 specified in Appendix C. 590 4.4. Link Quality 592 Some links in a MANET may be marginal, e.g. due to adverse wireless 593 propagation. In order to avoid using such marginal links, a link 594 quality is associated with each link in the Link Set, and links with 595 insufficient link quality are considered lost. Modifying the link 596 quality of a link is OPTIONAL. If link quality is not to be modified 597 it MUST be set to indicate an always usable quality link. Link 598 quality information is only used locally, it is not used in 599 signaling, and nodes may interoperate whether they are using the 600 same, different, or no, link quality information. 602 5. Protocol Parameters and Constants 604 The parameters and constants used in this specification are described 605 in this section. 607 5.1. Interface Parameters 609 The interface parameters used by this specification may be classified 610 into the following four categories: 612 o Message intervals 614 o Information validity times 616 o Link quality 618 o Jitter 620 These are detailed in the following sections. 622 Different MANET interfaces (on the same or on different nodes) MAY 623 employ different interface parameter values, and may change their 624 interface parameter values dynamically, subject to the constraints 625 given in this section. A particular case is where all MANET 626 interfaces on all MANET nodes within a given MANET employ the same 627 set of interface parameter values. 629 5.1.1. Message Intervals 631 The following interface parameters regulate HELLO message 632 transmissions over a given MANET interface. 634 HELLO messages serve two principal functions: 636 o To advertise this node's own addresses to its 1-hop neighbors. 637 The frequency of these advertisements is regulated by the 638 interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. 640 o To advertise this node's knowledge of each of its 1-hop neighbors. 641 The frequency of the advertisement of each such neighbor is 642 regulated by the interface parameter REFRESH_INTERVAL. 644 Specifically, these parameters are as follows: 646 HELLO_INTERVAL - is the maximum time between the transmission of two 647 successive HELLO messages on this MANET interface. If using 648 periodic transmission of HELLO messages, these SHOULD be at a 649 separation of HELLO_INTERVAL, possibly modified by jitter as 650 specified in [RFC5148]. 652 HELLO_MIN_INTERVAL - is the minimum interval between transmission of 653 two successive HELLO messages, on this MANET interface. (This 654 minimum interval MAY be modified by jitter, as defined in 655 [RFC5148].) 657 REFRESH_INTERVAL - is the maximum interval between advertisements in 658 a HELLO message of each 1-hop neighbor address and its status. In 659 all intervals of length REFRESH_INTERVAL, a node MUST include all 660 1-hop neighbor information which it is specified as sending in at 661 least one HELLO message on this MANET interface. 663 The following constraints apply to these interface parameters: 665 o HELLO_INTERVAL > 0 667 o HELLO_MIN_INTERVAL >= 0 669 o HELLO_INTERVAL >= HELLO_MIN_INTERVAL 671 o REFRESH_INTERVAL >= HELLO_INTERVAL 673 o If INTERVAL_TIME message TLVs as defined in [timetlv] are included 674 in HELLO messages, then HELLO_INTERVAL MUST be representable as 675 described in [timetlv]. 677 If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its 678 neighbor advertisements between HELLO messages in any manner, subject 679 to the constraints above. 681 For a node to employ this protocol in a purely responsive manner on a 682 MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be 683 set to a value such that a responsive HELLO message is always 684 expected in a shorter period than this value. 686 5.1.2. Information Validity Times 688 The following interface parameters manage the validity time of link 689 information: 691 L_HOLD_TIME - is the period of advertisement, on this MANET 692 interface, of former 1-hop neighbor addresses as lost in HELLO 693 messages, allowing recipients of these HELLO messages to 694 accelerate removal of information from their Link Sets. 695 L_HOLD_TIME can be set to zero if accelerated information removal 696 is not required. 698 H_HOLD_TIME - is used as the value in the VALIDITY_TIME message TLV 699 included in all HELLO messages on this MANET interface. 701 The following constraints apply to these interface parameters: 703 o L_HOLD_TIME >= 0 705 o H_HOLD_TIME >= REFRESH_INTERVAL 707 o If HELLO messages can be lost then both SHOULD be significantly 708 greater than REFRESH_INTERVAL. 710 o H_HOLD_TIME MUST be representable as described in [timetlv]. 712 5.1.3. Link Quality 714 The following interface parameters manage the usage of link quality 715 (see Section 4.4): 717 HYST_ACCEPT - is the link quality threshold at or above which a link 718 becomes usable, if it was not already so. 720 HYST_REJECT - is the link quality threshold below which a link 721 becomes unusable, if it was not already so. 723 INITIAL_QUALITY - is the initial quality of a newly identified link. 725 INITIAL_PENDING - if true, then a newly identified link is 726 considered pending, and is not usable until the link quality has 727 reached or exceeded the HYST_ACCEPT threshold. 729 The following constraints apply to these interface parameters: 731 o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 733 o 0 <= INITIAL_QUALITY <= 1. 735 o If link quality is not updated, then INITIAL_QUALITY >= 736 HYST_ACCEPT. 738 o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false. 740 o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true. 742 5.1.4. Jitter 744 If jitter, as defined in [RFC5148], is used then these parameters are 745 as follows: 747 HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 748 for periodically generated HELLO messages on this MANET interface. 750 HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 751 for externally triggered HELLO messages on this MANET interface. 753 For constraints on these interface parameters see [RFC5148]. 755 5.2. Node Parameters 757 The two node parameters defined by this specification are in the 758 category of information validity time. 760 5.2.1. Information Validity Time 762 The following node parameter manages the validity time of lost 763 symmetric 1-hop neighbor information: 765 N_HOLD_TIME - is used as the period during which former 1-hop 766 neighbor addresses are advertised as lost in HELLO messages, 767 allowing recipients of these HELLO messages to accelerate removal 768 of information from their 2-Hop Sets. N_HOLD_TIME can be set to 769 zero if accelerated information removal is not required. 771 I_HOLD_TIME - is the period for which a recently used local 772 interface address is recorded. 774 The following constraints applies to these node parameters: 776 o N_HOLD_TIME >= 0 778 o I_HOLD_TIME >= 0 780 5.3. Parameter Change Constraints 782 This section presents guidelines, applicable if protocol parameters 783 are changed dynamically. 785 HELLO_INTERVAL 787 * If the HELLO_INTERVAL for a MANET interface increases, then the 788 next HELLO message on this MANET interface MUST be generated 789 according to the previous, shorter, HELLO_INTERVAL. Additional 790 subsequent HELLO messages MAY be generated according to the 791 previous, shorter, HELLO_INTERVAL (but MUST include times 792 according to current parameters). 794 * If the HELLO_INTERVAL for a MANET interface decreases, then the 795 following HELLO messages on this MANET interface MUST be 796 generated according to this current, shorter, HELLO_INTERVAL. 798 REFRESH_INTERVAL 800 * If the REFRESH_INTERVAL for a MANET interface increases, then 801 the content of subsequent HELLO messages must be organized such 802 that the specification of the old value of REFRESH_INTERVAL is 803 satisfied for a further period equal to the old value of 804 REFRESH_INTERVAL. 806 * If the REFRESH_INTERVAL for a MANET interface decreases, then 807 it MAY be necessary to reschedule HELLO message generation on 808 that MANET interface, in order that the specification of 809 REFRESH_INTERVAL is satisfied from the time of change. 811 HYST_ACCEPT and HYST_REJECT 813 * If HYST_ACCEPT or HYST_REJECT changes, then the appropriate 814 actions for link quality change, as specified in Section 14.3 815 MUST be taken. 817 L_HOLD_TIME 819 * If L_HOLD_TIME changes, then L_time for all relevant Link 820 Tuples MUST be changed. 822 N_HOLD_TIME 824 * If N_HOLD_TIME changes, then NL_time for all relevant Lost 825 Neighbor Tuples MUST be changed. 827 HP_MAXJITTER 829 * If HP_MAXJITTER changes, then the periodic HELLO message 830 schedule on this MANET interface MAY be changed. 832 HT_MAXJITTER 834 * If HT_MAXJITTER changes, then externally triggered HELLO 835 messages on this MANET interface MAY be rescheduled. 837 5.4. Constants 839 The constant C (time granularity) is used as specified in [timetlv]. 841 6. Local Information Base 843 A node maintains a Local Information Base that records information 844 about its interfaces (MANET and non-MANET). Each interface MUST have 845 at least one address, and MAY have more than one address. 847 The Local Information Base is not modified by signaling. If a node's 848 interface configuration changes, then the Local Information Base MUST 849 reflect these changes. This MAY also result in signaling to 850 advertise these changes. 852 6.1. Local Interface Set 854 A node's Local Interface Set records its local interfaces. It 855 consists of Local Interface Tuples, one per interface: 857 (I_local_iface_addr_list, I_manet) 859 where: 861 I_local_iface_addr_list is an unordered list of the addresses of 862 this interface. 864 I_manet is a boolean flag, describing if this interface is a MANET 865 interface. 867 6.2. Removed Interface Address Set 869 A node's Removed Interface Address Set records addresses which were 870 recently local interface addresses. If a node's interface addresses 871 are immutable then this set is always empty and MAY be omitted. It 872 consists of Removed Interface Address Tuples, one per address: 874 (IR_local_iface_addr, IR_time) 876 where: 878 IR_local_iface_addr is a recently used address of an interface of 879 this node. 881 IR_time specifies when this Tuple expires and MUST be removed. 883 7. Interface Information Base 885 A node maintains an Interface Information Base for each of its MANET 886 interfaces. This records information about links to that MANET 887 interface and symmetric 2-hop neighbors which can be reached in two 888 hops using those links as the first hop. The Interface Information 889 Base includes the Link Set and the 2-Hop Set. 891 A MANET interface address can be present as of both a 1-hop neighbor 892 and a symmetric 2-hop neighbor. This allows the node with this MANET 893 interface address to be immediately considered as a symmetric 2-hop 894 neighbor if it fails to be a symmetric 1-hop neighbor. 896 7.1. Link Set 898 A node's Link Set records links from other nodes which are, or 899 recently were, 1-hop neighbors. It consists of Link Tuples, each 900 representing a single link: 902 (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, 903 L_quality, L_pending, L_lost, L_time) 905 where: 907 L_neighbor_iface_addr_list is an unordered list of the addresses of 908 the MANET interface of the 1-hop neighbor; 910 L_HEARD_time is the time until which the MANET interface of the 911 1-hop neighbor would be considered heard if not considering link 912 quality; 914 L_SYM_time is the time until which the link to the 1-hop neighbor 915 would be considered symmetric if not considering link quality; 917 L_quality is a dimensionless number between 0 (inclusive) and 1 918 (inclusive) describing the quality of a link; a greater value of 919 L_quality indicating a higher quality link; 921 L_pending is a boolean flag, describing if a link is considered 922 pending (i.e. a candidate, but not yet established, link); 924 L_lost is a boolean flag, describing if a link is considered lost 925 due to link quality; 927 L_time specifies when this Tuple expires and MUST be removed. 929 The status of the link, as obtained through HELLO message exchange, 930 and also taking link quality into account is denoted L_status. 932 L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The 933 values LOST, SYMMETRIC and HEARD are defined in Section 17.3. The 934 value PENDING is never used in a message, it is only used locally by 935 a node, and any value distinct from LOST, SYMMETRIC and HEARD may be 936 used. 938 L_status is defined by: 940 1. If L_pending is true, then L_status = PENDING; 942 2. otherwise, if L_lost is true, then L_status = LOST; 944 3. otherwise, if L_SYM_time is not expired, then L_status = 945 SYMMETRIC; 947 4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD; 949 5. otherwise, L_status = LOST. 951 7.2. 2-Hop Set 953 A node's 2-Hop Set records symmetric 2-hop neighbors, and the 954 symmetric links to symmetric 1-hop neighbors through which the 955 symmetric 2-hop neighbors can be reached. It consists of 2-Hop 956 Tuples, each representing a single interface address of a symmetric 957 2-hop neighbor, and a single MANET interface of a symmetric 1-hop 958 neighbor. 960 (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) 962 where: 964 N2_neighbor_iface_addr_list is an unordered list of the addresses of 965 the MANET interface of the symmetric 1-hop neighbor from which 966 this information was received; 968 N2_2hop_iface_addr is an address of an interface of a symmetric 969 2-hop neighbor which has a symmetric link (using any MANET 970 interface) to the indicated symmetric 1-hop neighbor; 972 N2_time specifies when this Tuple expires and MUST be removed. 974 8. Node Information Base 976 Each node maintains a Node Information Base that records information 977 about addresses of current and recently symmetric 1-hop neighbors. 979 8.1. Neighbor Set 981 A node's Neighbor Set records all interface addresses of each 1-hop 982 neighbor. It consists of Neighbor Tuples, each representing a single 983 1-hop neighbor: 985 (N_neighbor_iface_addr_list, N_symmetric) 987 where: 989 N_neighbor_iface_addr_list is an unordered list of the interface 990 addresses of a 1-hop neighbor; 992 N_symmetric is a boolean flag, describing if this is a symmetric 993 1-hop neighbor. 995 8.2. Lost Neighbor Set 997 A node's Lost Neighbor Set records addresses of all interfaces of 998 nodes which recently were symmetric 1-hop neighbors, but are now 999 advertised as lost. It consists of Lost Neighbor Tuples, each 1000 representing a single such address: 1002 (NL_neighbor_iface_addr, NL_time) 1004 where: 1006 NL_neighbor_iface_addr is an address of an interface of a node which 1007 recently was a symmetric 1-hop neighbor of this node; 1009 NL_time specifies when this Tuple expires and MUST be removed. 1011 9. Local Information Base Changes 1013 The Local Information Base MUST change to respond to changes in the 1014 node's local interface configuration. The node MUST update its 1015 Interface and Node Information Bases in response to such changes. If 1016 any changes in the Interface and Node Information Bases satisfy any 1017 of the conditions described in Section 13, then those changes must be 1018 applied immediately, unless noted otherwise. 1020 A node MAY transmit HELLO messages in response to these changes. 1022 9.1. Adding an Interface 1024 If an interface is added to the node then this is indicated by the 1025 addition of a Local Interface Tuple to the Local Interface Set. If 1026 the new interface is a MANET interface then an initially empty 1027 Interface Information Base MUST be created for this new MANET 1028 interface. The actions in Section 9.3 MUST be taken for each address 1029 of this added interface. A HELLO message MAY be sent on all MANET 1030 interfaces, it SHOULD be sent on the new interface if it is a MANET 1031 interface. If using scheduled messages, then a message schedule MUST 1032 be established on a new MANET interface. 1034 9.2. Removing an Interface 1036 If an interface is removed from the node, then this MUST result in 1037 changes to the Local Information Base and the Node Information Base 1038 as follows: 1040 1. Identify the Local Interface Tuple that corresponds to the 1041 interface to be removed. 1043 2. For each address (henceforth removed address) in the 1044 I_local_iface_addr_list of that Local Interface Tuple, create a 1045 Removed Interface Address Tuple with: 1047 * IR_local_iface_addr = removed address; 1049 * IR_time = current time + I_HOLD_TIME. 1051 3. Remove that Local Interface Tuple from the Local Interface Set. 1053 4. If the interface to be removed is a MANET interface (i.e. with 1054 I_manet == true) then: 1056 1. Remove the Interface Information Base for that MANET 1057 interface; 1059 2. All Neighbor Tuples for which none of the addresses in its 1060 N_neighbor_iface_addr_list are found in any 1061 L_neighbor_iface_addr_list in any remaining Link Set, are 1062 removed. 1064 If a node removes the Local Interface Tuple that contains the 1065 interface address that is used to define the node's originator 1066 address, as defined in [packetbb], then the node MAY change 1067 originator address. 1069 If the removed interface is the last MANET interface of the node, 1070 then there will be no remaining Interface Information Bases, and the 1071 node will longer participate in this protocol. 1073 After removing the interface and making these changes, a HELLO 1074 message MAY be sent on all remaining MANET interfaces. 1076 9.3. Adding an Address to an Interface 1078 If an address is added to an interface then this is indicated by the 1079 addition of an address to the appropriate I_local_iface_addr_list. 1080 The following changes MUST be made to the Information Bases: 1082 1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list 1083 contains the added address, are removed. 1085 2. Any Link Tuples, in any Link Set, whose 1086 L_neighbor_iface_addr_list contains: 1088 * the added address; OR 1090 * any address in the N_neighbor_iface_addr_list of the removed 1091 Neighbor Tuples, if any 1093 are removed; apply Section 13.1, but not Section 13.3. 1095 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the 1096 added address, are removed. 1098 4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address, 1099 are removed. 1101 After adding the address and making these changes, a HELLO message 1102 MAY be sent on all MANET interfaces. 1104 9.4. Removing an Address from an Interface 1106 If an address (henceforth removed address) is removed from an 1107 interface then: 1109 1. Identify the Local Interface Tuple that corresponds to the 1110 interface to be removed. 1112 2. If this is the only address of that interface (the only address 1113 in the corresponding I_local_iface_addr_list) then remove that 1114 interface as specified in Section 9.2. 1116 3. Otherwise: 1118 1. Remove the removed address from this I_local_iface_addr_list. 1120 2. Create a Removed Interface Address Tuple with: 1122 + IR_local_iface_addr = removed address; 1124 + IR_time = current time + I_HOLD_TIME. 1126 If a node removes the interface address that is used to define the 1127 node's originator address, as defined in [packetbb], then the node 1128 MAY change originator address. 1130 After removing the address and making these changes, a HELLO message 1131 MAY be sent on all MANET interfaces. 1133 10. Packets and Messages 1135 The packet and message format used by this protocol is defined in 1136 [packetbb], which is used with the following considerations: 1138 o This protocol specifies one message type, the HELLO message. 1140 o HELLO message header options MAY be used as specified by a 1141 protocol which uses this neighborhood discovery protocol. 1143 o HELLO messages MUST NOT be forwarded. 1145 o HELLO messages MAY be included in multi-message packets as 1146 specified in [packetbb]. 1148 o Packet header options MAY be used as specified by a protocol which 1149 uses this neighborhood discovery protocol. 1151 o Received HELLO messages MUST be parsed in accordance with 1152 [packetbb]. A HELLO message which is not in conformance with 1153 [packetbb] MUST be discarded. 1155 o This protocol specifies three address block TLVs. It also uses 1156 two message TLVs defined in [timetlv]. These five TLV types are 1157 all defined only with Type Extension == 0. TLVs of other types, 1158 and of these types but without Type Extension == 0, are ignored by 1159 this protocol. All references in this protocol to, for example, a 1160 TLV with Type == LINK_STATUS, are to be considered as referring to 1161 a TLV with Type == LINK_STATUS and Type Extension == 0. 1163 10.1. HELLO Messages 1165 A HELLO message MUST contain: 1167 o A VALIDITY_TIME message TLV as specified in [timetlv], 1168 representing H_HOLD_TIME for the transmitting MANET interface. 1169 The options included in [timetlv] for representing zero and 1170 infinite times MUST NOT be used. 1172 A HELLO message which is transmitted periodically SHOULD contain, and 1173 otherwise MAY contain: 1175 o An INTERVAL_TIME message TLV as specified in [timetlv], 1176 representing HELLO_INTERVAL for the transmitting MANET interface. 1177 The options included in [timetlv] for representing zero and 1178 infinite times MUST NOT be used. 1180 A HELLO message MAY contain: 1182 o One or more address blocks, each with an associated TLV block. 1184 o Other message TLVs. 1186 10.1.1. Address Blocks 1188 All addresses in a node's Local Interface Set (i.e. in any 1189 I_local_iface_addr_list) MUST be included in the address blocks in 1190 all generated HELLO messages with the following exception. If the 1191 MANET interface on which the HELLO message is to be sent has a single 1192 interface address with maximum prefix length then that address MAY be 1193 omitted. All addresses of the node's interfaces included in an 1194 address block MUST be associated with a TLV with Type == LOCAL_IF, as 1195 defined in Table 1. 1197 +----------+---------+----------------------------------------------+ 1198 | Name | Value | Description | 1199 | | Length | | 1200 +----------+---------+----------------------------------------------+ 1201 | LOCAL_IF | 1 octet | Specifies that the address is an address | 1202 | | | associated with the interface on which the | 1203 | | | message was sent (THIS_IF), another | 1204 | | | interface of the sending node (OTHER_IF), or | 1205 | | | an unspecified interface of the sending node | 1206 | | | (UNSPEC_IF). | 1207 +----------+---------+----------------------------------------------+ 1209 Table 1 1211 Note that the value UNSPEC_IF is not used by this protocol. It is 1212 provided for an expected alternative use of this TLV. 1214 Address blocks MAY contain current or recently lost 1-hop neighbors' 1215 interface addresses, each of which is associated with address block 1216 TLVs as described in Table 2. 1218 +--------------+---------+------------------------------------------+ 1219 | Name | Value | Description | 1220 | | Length | | 1221 +--------------+---------+------------------------------------------+ 1222 | LINK_STATUS | 1 octet | Specifies the status of the link from | 1223 | | | the indicated address (LOST, SYMMETRIC | 1224 | | | or HEARD). | 1225 | | | | 1226 | OTHER_NEIGHB | 1 octet | Specifies that the address is | 1227 | | | (SYMMETRIC) or was (LOST) of an | 1228 | | | interface of a symmetric 1-hop neighbor | 1229 | | | of the node transmitting the HELLO | 1230 | | | message. | 1231 +--------------+---------+------------------------------------------+ 1233 Table 2 1235 A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == 1236 LOST) also performs the function of a TLV with Type == OTHER_NEIGHB 1237 and the same value. The latter SHOULD NOT also be included. If a 1238 TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with 1239 a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter 1240 MUST be ignored, and SHOULD NOT be included. See Appendix A. 1242 Other addresses MAY be included in address blocks, but MUST NOT be 1243 associated with any of the TLVs specified in this section. 1245 11. HELLO Message Generation 1247 Each MANET interface MUST generate HELLO messages according to the 1248 specification in this section. HELLO message generation and 1249 scheduling MUST be according to the interface parameters for that 1250 MANET interface and MAY be independent for each MANET interface or, 1251 interface parameters permitting, MANET interfaces MAY use the same 1252 schedule. 1254 If transmitting periodic HELLO messages then, following a HELLO 1255 message transmission on a MANET interface, another HELLO message MUST 1256 be transmitted on the same MANET interface after an interval not 1257 greater than HELLO_INTERVAL. Two successive HELLO message 1258 transmissions on the same MANET interface MUST be separated by at 1259 least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. 1261 11.1. HELLO Message Specification 1263 HELLO messages are generated independently on each MANET interface. 1265 All addresses in any I_local_iface_addr_list MUST be included, except 1266 that: 1268 o If the interface on which the HELLO message is to be sent has a 1269 single interface address with maximum prefix length then that 1270 interface address MAY be omitted. 1272 All such included addresses MUST be associated with a TLV with Type 1273 == LOCAL_IF and value according to the following: 1275 o If the address is of the sending interface, then Value == THIS_IF. 1277 o Otherwise, Value == OTHER_IF. 1279 The following addresses of current or former 1-hop neighbors MAY be 1280 included in any HELLO message: 1282 o Addresses of MANET interfaces of 1-hop neighbors from the Link Set 1283 of the Interface Information Base for this MANET interface. 1285 o Other addresses of symmetric 1-hop neighbors from the Neighbor Set 1286 of this node's Node Information Base. 1288 o Addresses of MANET interfaces of previously symmetric or heard 1289 1-hop neighbors connected on this MANET interface from the Link 1290 Set of the Interface Information Base for this MANET interface. 1291 (These are advertised for a period equal to this interface's 1292 L_HOLD_TIME after loss.) 1294 o Other addresses of previously symmetric 1-hop neighbors from the 1295 Lost Neighbor Set of this node's Node Information Base. (These 1296 are advertised for a period equal to N_HOLD_TIME after loss.) 1298 Each such address MUST be associated with one or more appropriate 1299 TLVs, respecting the parameter REFRESH_INTERVAL for each association 1300 for each MANET interface. Specifically: 1302 1. For each address (henceforth linked address) which appears in a 1303 Link Tuple in the Link Set for this MANET interface, for which 1304 L_status does not equal PENDING, include the linked address with 1305 an associated TLV with: 1307 * Type = LINK_STATUS; AND 1309 * Value = L_status. 1311 2. For each address (henceforth neighbor address) which appears in 1312 an N_neighbor_iface_addr_list in a Neighbor Tuple with 1313 N_symmetric == true, and which has not already been included with 1314 an associated TLV with (Type == LINK_STATUS and Value == 1315 SYMMETRIC), include the neighbor address with an associated TLV 1316 with: 1318 * Type = OTHER_NEIGHB; AND 1320 * Value = SYMMETRIC. 1322 3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr 1323 (henceforth lost address) has not already been included, include 1324 the lost address with an associated TLV with: 1326 * Type = OTHER_NEIGHB; AND 1328 * Value = LOST. 1330 If a 1-hop neighbor address is specified with more than one 1331 associated TLV, then these TLVs MAY be independently included or 1332 excluded from each HELLO message. Each such TLV MUST be included 1333 associated with that address in a HELLO message sent on that MANET 1334 interface in every interval of length equal to that MANET interface's 1335 parameter REFRESH_INTERVAL. TLVs associated with the same address 1336 included in the same HELLO message MAY be applied to the same or 1337 different copies of that address. 1339 11.2. HELLO Message Transmission 1341 HELLO messages are transmitted in the packet/message format specified 1342 by [packetbb] using the "LL-MANET-Routers" multicast address 1343 specified by [manet-iana] as destination IP address, using either the 1344 "manet" UDP port, or the "manet" IP protocol number specified in 1345 [manet-iana]. 1347 11.2.1. HELLO Message Jitter 1349 HELLO messages MAY be sent using periodic message generation or 1350 externally triggered message generation. If using data link and 1351 physical layers which are subject to packet loss due to collisions, 1352 HELLO messages SHOULD be jittered as described in [RFC5148]. 1354 Internally triggered message generation (such as due to a change in 1355 local interfaces) MAY be treated as if externally generated message 1356 generation, or MAY be not jittered. 1358 HELLO messages MUST NOT be forwarded, and thus message forwarding 1359 jitter does not apply to HELLO messages. 1361 Each form of jitter described in [RFC5148] requires a parameter 1362 MAXJITTER. These interface parameters may be dynamic, and are 1363 specified by: 1365 o For periodic message generation: HP_MAXJITTER. 1367 o For externally triggered message generation: HT_MAXJITTER. 1369 When HELLO message generation is delayed in order that a HELLO 1370 message is not sent within HELLO_MIN_INTERVAL of the previous HELLO 1371 message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD 1372 be reduced by jitter, with maximum reduction HP_MAXJITTER. In this 1373 case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. 1375 12. HELLO Message Processing 1377 On receiving a HELLO message, a node MUST first check if any address 1378 associated with a TLV with Type == LOCAL_IF is one of the receiving 1379 node's current or recently used interface addresses (i.e. is in any 1380 I_local_iface_addr_list in the Local Interface Set or is equal to any 1381 IR_local_iface_addr in the Removed Interface Address Set). If so 1382 then the HELLO message MUST be discarded. 1384 Otherwise the receiving node MUST update its appropriate Interface 1385 Information Base and its Node Information Base according to this 1386 section. Section 12.1 to Section 12.4 MUST be performed in the order 1387 presented. If any changes satisfy any of the conditions described in 1388 Section 13 then the indicated consequences MUST be applied 1389 immediately, unless noted otherwise. 1391 For the purpose of this section, note the following definitions: 1393 o "validity time" is calculated from the VALIDITY_TIME message TLV 1394 of the HELLO message as specified in [timetlv]. All information 1395 in the HELLO message has the same validity time. 1397 o "Receiving Address List" is the I_local_iface_addr_list 1398 corresponding to the MANET interface on which the HELLO message 1399 was received 1401 o "Sending Address List" is the list of the addresses contained in 1402 the HELLO message with an associated TLV with Type == LOCAL_IF and 1403 Value == THIS_IF. If the Sending Address List is otherwise empty, 1404 then the Sending Address List contains a single address (with 1405 maximum prefix length) equal to the sending address of the IP 1406 datagram in which the HELLO message was included. 1408 o "Neighbor Address List" is the Sending Address List, plus the 1409 addresses contained in the HELLO message with an associated TLV 1410 with Type == LOCAL_IF and Value == OTHER_IF. 1412 o EXPIRED indicates that a timer is set to a value clearly preceding 1413 the current time (e.g. current time - 1). 1415 o "Removed Address List" is a list of addresses created by this 1416 HELLO message processing which were formerly reported as local by 1417 the node originating the HELLO message, but which are not included 1418 in the Neighbor Address List. This list is initialized as empty. 1420 o "Lost Address List" is a subset of the Removed Address List 1421 containing addresses which were formerly considered as symmetric. 1422 This list is initialized as empty. 1424 12.1. Updating the Neighbor Set 1426 On receiving a HELLO message, the node MUST update its Neighbor Set 1427 and populate the Removed Address List and Lost Address List: 1429 1. Find all Neighbor Tuples (hereafter matching Neighbor Tuples) 1430 where: 1432 * N_neighbor_iface_addr_list contains at least one address in 1433 the Neighbor Address List. 1435 2. If there are no matching Neighbor Tuples, then: 1437 1. Create a new Neighbor Tuple with: 1439 + N_neighbor_iface_addr_list = Neighbor Address List; 1441 + N_symmetric = false. 1443 3. If there is one matching Neighbor Tuple, then: 1445 1. If the N_neighbor_iface_addr_list of the matching Neighbor 1446 Tuple is not equal to the Neighbor Address List, then: 1448 1. For each address (henceforth removed address) which is in 1449 the N_neighbor_iface_addr_list, but not in the Neighbor 1450 Address List: 1452 1. Add the removed address to the Removed Address List. 1454 2. If N_symmetric == true, then add the removed address 1455 to the Lost Address List. 1457 2. Update the matching Neighbor Tuple by: 1459 - N_neighbor_iface_addr_list = Neighbor Address List. 1461 4. If there are two or more matching Neighbor Tuples, then: 1463 1. For each address (henceforth removed address) which is in the 1464 N_neighbor_iface_addr_list of any of the matching Neighbor 1465 Tuples: 1467 1. Add the removed address to the Removed Address List. 1469 2. If N_symmetric == true, then add the removed address to 1470 the Lost Address List. 1472 2. Replace the matching Neighbor Tuples by a single Neighbor 1473 Tuple with: 1475 + N_neighbor_iface_addr_list = Neighbor Address List; 1477 + N_symmetric = false 1479 12.2. Updating the Lost Neighbor Set 1481 On receiving a HELLO message, a node MUST update its Lost Neighbor 1482 Set: 1484 1. For each address (henceforth lost address) in the Lost Address 1485 List, if no Lost Neighbor Tuple with NL_neighbor_iface_addr == 1486 lost address exists, then add a Lost Neighbor Tuple with: 1488 * NL_neighbor_iface_addr = lost address; 1490 * NL_time = current time + N_HOLD_TIME. 1492 12.3. Updating the Link Set 1494 On receiving a HELLO message, a node MUST update its Link Set for the 1495 MANET interface on which the HELLO message is received: 1497 1. Remove all addresses in the Removed Address List from the 1498 L_neighbor_iface_addr_list of all Link Tuples. 1500 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 1501 empty; apply Section 13.1, but not Section 13.3. 1503 3. Find all Link Tuples (hereafter matching Link Tuples) where: 1505 * L_neighbor_iface_addr_list contains one or more addresses in 1506 the Sending Address List. 1508 4. If there is more than one matching Link Tuple, then remove them 1509 all; apply Section 13.1, but not Section 13.3. 1511 5. If no matching Link Tuples remain, then create a new matching 1512 Link Tuple with: 1514 * L_neighbor_iface_addr_list = empty; 1516 * L_HEARD_time = EXPIRED; 1518 * L_SYM_time = EXPIRED; 1519 * L_quality = INITIAL_QUALITY; 1521 * L_pending = INITIAL_PENDING; 1523 * L_lost = false; 1525 * L_time = current time + validity time. 1527 6. The matching Link Tuple, existing or new, is then modified as 1528 follows: 1530 1. If the node finds any address (henceforth receiving address) 1531 in the Receiving Address List in an address block in the 1532 HELLO message, then the Link Tuple is modified as follows: 1534 1. If any receiving address in the HELLO message is 1535 associated with a TLV with Type == LINK_STATUS and (Value 1536 == HEARD or Value == SYMMETRIC) then: 1538 - L_SYM_time = current time + validity time. 1540 2. Otherwise if any receiving address in the HELLO message 1541 is associated with a TLV with Type == LINK_STATUS and 1542 Value == LOST then: 1544 1. if L_SYM_time has not expired, then: 1546 1. L_SYM_time = EXPIRED. 1548 2. if L_status == HEARD or SYMMETRIC, then: 1550 * L_time = current time + L_HOLD_TIME. 1552 2. L_neighbor_iface_addr_list = Sending Address List. 1554 3. L_HEARD_time = max(current time + validity time, L_SYM_time). 1556 4. If L_status == PENDING, then: 1558 + L_time = max(L_time, L_HEARD_time). 1560 5. Otherwise if L_status == HEARD or SYMMETRIC, then: 1562 + L_time = max(L_time, L_HEARD_time + L_HOLD_TIME). 1564 12.4. Updating the 2-Hop Set 1566 On receiving a HELLO message a node MUST update its 2-Hop Set for the 1567 MANET interface on which the HELLO message was received: 1569 1. Remove all addresses in the Removed Address List from the 1570 N2_neighbor_iface_addr_list of all 2-Hop Tuples. 1572 2. If the Link Tuple with L_neighbor_iface_addr_list == Sending 1573 Address List has L_status == SYMMETRIC then: 1575 1. For each address (henceforth 2-hop address) in an address 1576 block of the HELLO message, which is not in the Neighbor 1577 Address List, in any I_local_iface_addr_list, or equal to any 1578 IR_local_iface_addr: 1580 1. If the 2-hop address has an associated TLV with: 1582 - Type == LINK_STATUS and Value == SYMMETRIC; OR 1584 - Type == OTHER_NEIGHB and Value == SYMMETRIC, 1586 then, if there is no 2-Hop Tuple such that: 1588 - N2_neighbor_iface_addr_list contains one or more 1589 addresses in the Sending Address List; AND 1591 - N2_2hop_iface_addr == 2-hop address. 1593 then create a 2-Hop Neighbor Tuple with: 1595 - N2_2hop_iface_addr = 2-hop address. 1597 This 2-Hop Tuple (existing or new) is then modified as 1598 follows: 1600 - N2_neighbor_iface_addr_list = Sending Address List; 1602 - N2_time = current time + validity time. 1604 2. Otherwise if the 2-hop address has a TLV with: 1606 - Type == LINK_STATUS and (Value == LOST or Value == 1607 HEARD); OR 1609 - Type == OTHER_NEIGHB and Value == LOST; 1611 then remove all 2-Hop Tuples with: 1613 - N2_neighbor_iface_addr_list contains one or more 1614 addresses in the Sending Address List; AND 1616 - N2_2hop_iface_addr == 2-hop address. 1618 13. Other Information Base Changes 1620 The Interface and Node Information Bases MUST be changed when some 1621 events occur. These events may result from HELLO message processing, 1622 or may be otherwise generated (e.g. expiry of timers or link quality 1623 changes). 1625 Events which cause changes in the Information Bases are: 1627 o A Link Tuple's state changes from symmetric, or the Link Tuple is 1628 removed. 1630 o A Link Tuple's state changes to symmetric. 1632 o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. 1634 o Local interface address changes, as specified in Section 9. 1636 o Link quality changes, as specified in Section 14. 1638 A node MAY report updated information in response to any of these 1639 changes in HELLO message(s), subject to the constraints in 1640 Section 11. 1642 A node which transmits HELLO messages in response to such changes 1643 SHOULD transmit a HELLO message: 1645 o On all MANET interfaces, if the Neighbor Set changes such as to 1646 indicate the change in symmetry of any 1-hop neighbors (including 1647 addition or removal of symmetric 1-hop neighbors). 1649 o Otherwise, on all those MANET interfaces whose Link Set changes 1650 such as to indicate a change in status of any 1-hop neighbors 1651 (including the addition or removal of any 1-hop neighbors, other 1652 than those considered pending). 1654 13.1. Link Tuple Not Symmetric 1656 If for any Link Tuple with L_status == SYMMETRIC: 1658 o L_status changes to any other value; OR 1660 o the Link Tuple is removed; 1662 then: 1664 1. All 2-Hop Tuples for the same MANET interface with: 1666 * N2_neighbor_iface_addr_list contains one or more addresses in 1667 L_neighbor_iface_addr_list; 1669 are removed. 1671 2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1672 L_neighbor_iface_addr_list: 1674 1. If there are no remaining Link Tuples for any MANET interface 1675 with: 1677 + L_neighbor_iface_addr_list contained in 1678 N_neighbor_iface_addr_list; AND 1680 + L_status == SYMMETRIC; 1682 then modify the Neighbor Tuple by: 1684 1. N_symmetric = false. 1686 2. For each address (henceforth neighbor address) in 1687 N_neighbor_iface_addr_list, add a Lost Neighbor Tuple 1688 with: 1690 - NL_neighbor_iface_addr = neighbor address; 1692 - NL_time = current time + N_HOLD_TIME. 1694 13.2. Link Tuple Symmetric 1696 If, for any Link Tuple which does not have L_status == SYMMETRIC: 1698 o L_status changes to SYMMETRIC; 1700 (this includes a newly created Link Tuple which is immediately 1701 updated to have L_status == SYMMETRIC) then: 1703 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list includes 1704 L_neighbor_iface_addr_list, set: 1706 * N_symmetric = true. 1708 2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is 1709 included in that N_neighbor_iface_addr_list. 1711 13.3. Link Tuple Heard Timeout 1713 If, for any Link Tuple: 1715 o L_HEARD_time expires; OR 1717 o the Link Tuple is removed; 1719 then: 1721 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1722 L_neighbor_iface_addr_list, if no Link Tuples for any MANET 1723 interface remain with: 1725 * L_neighbor_iface_addr_list contained in 1726 N_neighbor_iface_addr_list; AND 1728 * L_HEARD_time is not expired; 1730 then remove the Neighbor Tuple. 1732 14. Link Quality 1734 Link quality is a mechanism whereby a node MAY take considerations 1735 other than message exchange into account for determining when a link 1736 is and is not a candidate for being considered as HEARD or SYMMETRIC. 1738 For deployments where no link quality is used, the considerations in 1739 Section 14.1 apply. For deployments were link quality is used, the 1740 general principles of link quality usage are described in 1741 Section 14.2. Section 14.3 and Section 14.4 detail link quality 1742 functioning. 1744 Link quality is used only locally by a node, and nodes may fully 1745 interoperate whether they are using the same, different or no link 1746 quality methods. 1748 14.1. Deployment Without Link Quality 1750 In order for a node to not employ link quality, the node MUST define: 1752 o INITIAL_PENDING = false; 1754 o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define 1755 INITIAL_QUALITY = 1). 1757 14.2. Basic Principles of Link Quality 1759 To enable link quality usage, the L_quality value of a Link Tuple is 1760 used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, 1761 to set the flags L_pending and L_lost of that Link Tuple. Based on 1762 these flags, the link status to advertise for that Link Tuple is 1763 determined as described in Section 7.1. 1765 The use of two thresholds implements link hysteresis, whereby a link 1766 which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either 1767 accepted or rejected (depending on which threshold it has most 1768 recently crossed, or if neither the value of INITIAL_QUALITY). With 1769 appropriate values of these parameters, this prevents over-rapid 1770 changes of link status. 1772 The basic principles of link quality usage are as follows: 1774 o A node does not advertise a neighbor interface in any state until 1775 L_quality is acceptable: 1777 * If INITIAL_PENDING == true, then this is such that L_quality >= 1778 HYST_ACCEPT. 1780 * Otherwise this is such that L_quality >= HYST_REJECT. To 1781 ensure this, a node MUST NOT define INITIAL_PENDING == false 1782 and INITIAL_QUALITY < HYST_REJECT. (A node also MUST NOT 1783 define INITIAL_PENDING == true and INITIAL_QUALITY >= 1784 HYST_ACCEPT.) 1786 * A link which is not yet advertised has L_pending == true. 1788 o Once L_quality >= HYST_ACCEPT, the L_pending flag is set false, 1789 indicating that the link can be advertised. 1791 o A link for which L_pending == false is advertised until its 1792 L_quality drops below HYST_REJECT. 1794 o If a link has L_pending == false and L_quality < HYST_REJECT, the 1795 link is LOST and is advertised as such. This link is not 1796 reconsidered as a candidate HEARD or SYMMETRIC link until 1797 L_quality >= HYST_ACCEPT. 1799 o A link which has an acceptable quality may be advertised as HEARD, 1800 SYMMETRIC or LOST according to the exchange of HELLO messages. 1802 14.3. When Link Quality Changes 1804 If L_quality for a link changes, then the following actions MUST be 1805 taken: 1807 1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1808 modified by: 1810 1. L_pending = false. 1812 2. L_lost = false. 1814 3. If L_status == HEARD or L_status == SYMMETRIC, then: 1816 + L_time = max(L_time, L_HEARD_time + L_HOLD_TIME) 1818 2. If L_status is not equal to PENDING, and L_quality < HYST_REJECT 1819 then the corresponding Link Tuple is modified by: 1821 1. If L_lost == false, then: 1823 + L_lost = true 1825 + L_time = min(L_time, current time + L_HOLD_TIME) 1827 Any appropriate action indicted in Section 13 MUST also be taken. 1829 If L_quality for a link is updated based on HELLO message reception, 1830 or on reception of a packet including a HELLO message, then L_quality 1831 MUST be updated prior to the HELLO message processing described in 1832 Section 12. (If the receipt of the HELLO message, or the packet 1833 containing it, creates the Link Tuple then the Link Tuple MUST be 1834 created with the appropriately updated L_quality value, rather than 1835 with L_quality = INITIAL_QUALITY.) 1837 14.4. Updating Link Quality 1839 A node MAY update link quality based on any information available to 1840 it. Particular cases that MAY be used include: 1842 o Information from the link layer, such as signal to noise ratio or 1843 acknowledgement reception and loss information. 1845 o Receipt or loss of packets. If packets include a packet sequence 1846 number as defined in [packetbb], then packets on a link SHOULD 1847 have sequential packet sequence numbers, whether or not they 1848 include HELLO messages. Link quality can be updated when a packet 1849 is received based on, for example, whether the last N out of M 1850 packets on the link were received, or a "leaky integrator" 1851 tracking packets. 1853 o Receipt or loss of HELLO messages. If the maximum interval 1854 between HELLO messages is known (such as by inclusion of a message 1855 TLV with Type == INTERVAL_TIME, as defined in [timetlv], in HELLO 1856 messages) then the loss of HELLO messages can be determined 1857 without the need to receive a HELLO message. Note that if this 1858 case is combined with the previous case then care must be taken to 1859 avoid "double counting" a lost HELLO message in a lost packet. 1861 15. Proposed Values for Parameters and Constants 1863 This section lists the parameters and constants used in the 1864 specification of the protocol, and proposed values of each which may 1865 be used when a single value of each is used. 1867 15.1. Message Interval Interface Parameters 1869 o HELLO_INTERVAL = 2 seconds 1871 o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 1873 o REFRESH_INTERVAL = HELLO_INTERVAL 1875 15.2. Information Validity Time Interface Parameters 1877 o H_HOLD_TIME = 3 x REFRESH_INTERVAL 1879 o L_HOLD_TIME = H_HOLD_TIME 1881 15.3. Information Validity Time Node Parameters 1883 o N_HOLD_TIME = L_HOLD_TIME 1885 o I_HOLD_TIME = N_HOLD_TIME 1887 15.4. Link Quality Interface Parameters 1889 If link quality is changed, then parameter values will depend on the 1890 link quality process. If link quality is not changed, then: 1892 o HYST_ACCEPT = 1 1894 o HYST_REJECT = 0 1896 o INITIAL_QUALITY = 1 1898 o INITIAL_PENDING = false 1900 15.5. Jitter Interface Parameters 1902 o HP_MAXJITTER = HELLO_INTERVAL/4 1904 o HT_MAXJITTER = HP_MAXJITTER 1906 15.6. Constants 1908 o C = 1/1024 second 1910 16. Security Considerations 1912 The objective of this protocol is to allow each node in the network 1913 to acquire information describing its 1-hop and symmetric 2-hop 1914 neighborhoods. This is acquired through message exchange between 1915 neighboring nodes. The information is made available through the 1916 Interface Information Bases and Node Information Base, describing the 1917 node's 1-hop neighborhood and symmetric 2-hop neighborhood. 1919 Under normal circumstances, the information recorded in these 1920 Information Bases is correct - i.e. corresponds to the actual network 1921 topology, apart from any changes which have not (yet) been tracked by 1922 the HELLO message exchanges. 1924 If some node for some reason, malice or malfunction, injects invalid 1925 HELLO messages, incorrect information may be recorded in the 1926 Information Bases. The protocol specification does, however, prevent 1927 inconsistent information from being injected in the protocol sets 1928 through the constraints in Appendix C. The exact consequence of 1929 information inexactness depends on the use of these Information 1930 Bases, and should be reflected in the specification of protocols 1931 which use information provided by NHDP. 1933 This section, therefore, only outlines the ways in which correctly 1934 formed, but still invalid, HELLO messages may appear. 1936 16.1. Invalid HELLO messages 1938 A correctly formed, but still invalid, HELLO message may take any of 1939 the following forms. Note that a present or absent address in an 1940 address block, does not in and by itself cause a problem. It is the 1941 presence, absence, or incorrectness of associated LOCAL_IF, 1942 LINK_STATUS and OTHER_NEIGHB TLVs that causes problems. 1944 A node may provide false information about its own identity: 1946 * The HELLO message may contain addresses with an associated 1947 LOCAL_IF TLV which do not correspond to addresses of interfaces 1948 of the node transmitting the HELLO message. 1950 * The HELLO message may omit addresses, or their associated 1951 LOCAL_IF TLV, of interfaces of the local node transmitting the 1952 HELLO message (other than the allowed omission of the only 1953 local interface address of the MANET interface over which the 1954 HELLO message is transmitted, if that is the case). 1956 * The HELLO message may incorrectly specify the LOCAL_IF TLV 1957 value associated with one or more local interface addresses, 1958 indicating incorrectly whether they are associated with the 1959 MANET interface over which the HELLO message is transmitted. 1961 A node may provide false information about the identity of other 1962 nodes: 1964 * A present LINK_STATUS TLV may, incorrectly, identify an address 1965 as being of a MANET interface which is or was heard on the 1966 MANET interface over which the HELLO message is transmitted. 1968 * A consistently absent LINK_STATUS TLV may, incorrectly, fail to 1969 identify an address as being of a MANET interface which is or 1970 was heard on the MANET interface over which the HELLO message 1971 is transmitted. 1973 * A present OTHER_NEIGHB TLV may, incorrectly, identify an 1974 address as being of a node which is or was in the sending 1975 node's symmetric 1-hop neighborhood; 1977 * A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail 1978 to identify an address as being of a node which is or was in 1979 the sending node's symmetric 1-hop neighborhood; 1981 * The value of a LINK_STATUS TLV may incorrectly indicate the 1982 status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop 1983 neighbor. 1985 * The value of an OTHER_NEIGHB TLV may incorrectly indicate the 1986 status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor. 1988 17. IANA Considerations 1990 17.1. Message Types 1992 This specification defines one message type, to be allocated from the 1993 0-223 range of the "Message Types" namespace defined in [packetbb], 1994 as specified in Table 3. 1996 +-------+------+------------------+ 1997 | Name | Type | Description | 1998 +-------+------+------------------+ 1999 | HELLO | TBD1 | Local signaling. | 2000 +-------+------+------------------+ 2002 Table 3 2004 17.2. Address Block TLV Types 2006 This specification defines three address block TLV types, which must 2007 be allocated from the "Address Block TLV Types" namespace defined in 2008 [packetbb]. IANA are requested to make allocations in the 8-127 2009 range for these types. This will create three new type extension 2010 registries with assignments as specified in Table 4, Table 5 and 2011 Table 6. Specifications of these TLVs are in Section 10.1.1, with 2012 value constants defined in Section 17.3. 2014 +----------+------+-----------+-------------------------------------+ 2015 | Name | Type | Type | Description | 2016 | | | extension | | 2017 +----------+------+-----------+-------------------------------------+ 2018 | LOCAL_IF | TBD2 | 0 | Specifies that the address is | 2019 | | | | associated with a local interface | 2020 | | | | of the sending node. | 2021 | | | | | 2022 | | | 1-255 | Expert Review | 2023 +----------+------+-----------+-------------------------------------+ 2025 Table 4 2027 +-------------+------+-----------+----------------------------------+ 2028 | Name | Type | Type | Description | 2029 | | | extension | | 2030 +-------------+------+-----------+----------------------------------+ 2031 | LINK_STATUS | TBD3 | 0 | Specifies the status of the link | 2032 | | | | from the indicated address | 2033 | | | | (LOST, SYMMETRIC or HEARD). | 2034 | | | | | 2035 | | | 1-255 | Expert Review | 2036 +-------------+------+-----------+----------------------------------+ 2038 Table 5 2040 +--------------+------+-----------+---------------------------------+ 2041 | Name | Type | Type | Description | 2042 | | | extension | | 2043 +--------------+------+-----------+---------------------------------+ 2044 | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | 2045 | | | | (SYMMETRIC) or recently was | 2046 | | | | (LOST) of an interface of a | 2047 | | | | symmetric 1-hop neighbor of the | 2048 | | | | node transmitting the message. | 2049 | | | | | 2050 | | | 1-255 | Expert Review | 2051 +--------------+------+-----------+---------------------------------+ 2053 Table 6 2055 Type extensions indicated as Expert Review SHOULD be allocated as 2056 described in [packetbb], based on Expert Review as defined in 2057 [RFC5226]. 2059 17.3. LINK_STATUS and OTHER_NEIGHB Values 2061 The values which the LOCAL_IF TLV can use are the following: 2063 o UNSPEC_IF = 0 2065 o THIS_IF = 1 2067 o OTHER_IF = 2 2069 The values which the LINK_STATUS TLV can use are the following: 2071 o LOST = 0 2073 o SYMMETRIC = 1 2074 o HEARD = 2 2076 The values which the OTHER_NEIGHB TLV can use are the following: 2078 o LOST = 0 2080 o SYMMETRIC = 1 2082 18. References 2084 18.1. Normative References 2086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2087 Requirement Levels", RFC 2119, BCP 14, March 1997. 2089 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2090 considerations in MANETs", RFC 5148, February 2008. 2092 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2093 an IANA Considerations Section in RFCs", RFC 5226, 2094 BCP 26, May 2008. 2096 [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 2097 "Generalized MANET Packet/Message Format", Work In 2098 Progress draft-ietf-manet-packetbb-13.txt, June 2008. 2100 [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value 2101 time in MANETs", Work In 2102 Progress draft-ietf-manet-timetlv-04.txt, 2103 November 2007. 2105 [manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols", 2106 Work In Progress draft-ietf-manet-iana-07.txt, 2107 November 2007. 2109 18.2. Informative References 2111 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 2112 (MANET): Routing Protocol Performance Issues and 2113 Evaluation Considerations", RFC 2501, January 1999. 2115 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 2116 Routing Protocol", RFC 3626, October 2003. 2118 Appendix A. Address Block TLV Combinations 2120 The algorithm for generating HELLO messages in Section 11 specifies 2121 which 1-hop addresses may be included in the address blocks, and with 2122 which associated TLVs. These TLVs may have Type == LINK_STATUS or 2123 Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may 2124 have three possible values (Value == HEARD, Value == SYMMETRIC or 2125 Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two 2126 possible values (Value == SYMMETRIC or Value == LOST). When both 2127 TLVs are associated with the same address only certain combinations 2128 of these TLV values are necessary, and are the only combinations 2129 generated by the algorithm in Section 11. These combinations are 2130 indicated in Table 7. 2132 Cells labeled with "Yes" indicate the possible combinations which are 2133 generated by the algorithm in Section 11. Cells labeled with "No" 2134 indicate combinations not generated by the algorithm in Section 11, 2135 but which are correctly parsed and interpreted by the algorithm in 2136 Section 12. 2138 +----------------+----------------+----------------+----------------+ 2139 | | Type == | Type == | Type == | 2140 | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | 2141 | | (absent) | Value == | Value == LOST | 2142 | | | SYMMETRIC | | 2143 +----------------+----------------+----------------+----------------+ 2144 | Type == | No | Yes | Yes | 2145 | LINK_STATUS | | | | 2146 | (absent) | | | | 2147 | | | | | 2148 | Type == | Yes | Yes | Yes | 2149 | LINK_STATUS, | | | | 2150 | Value == HEARD | | | | 2151 | | | | | 2152 | Type == | Yes | No | No | 2153 | LINK_STATUS, | | | | 2154 | Value == | | | | 2155 | SYMMETRIC | | | | 2156 | | | | | 2157 | Type == | Yes | Yes | No | 2158 | LINK_STATUS, | | | | 2159 | Value == LOST | | | | 2160 +----------------+----------------+----------------+----------------+ 2162 Table 7 2164 Appendix B. HELLO Message Example 2166 An example HELLO message, transmitted by an originator node with a 2167 single MANET interface, is as follows. The message uses IPv4 (four 2168 octet) addresses without specified prefix lengths. The message is 2169 transmitted with a full message header (flags octet value is 240) 2170 with a hop limit of 1 and a hop count of 0. The overall message 2171 length is 49 octets. 2173 The message contains a message TLV block with content length 8 octets 2174 containing two message TLVs, of types VALIDITY_TIME and 2175 INTERVAL_TIME. Each uses a TLV with flags octet value 16, indicating 2176 that each has a value. Each has a value length of 1 octet; the 2177 values included (0x64 and 0x58) are time codes representing the 2178 default values of parameters H_HOLD_TIME and HELLO_INTERVAL, 2179 respectively (6 seconds and 2 seconds) assuming the default value of 2180 constant C (1/1024 second). 2182 The message has a single address block containing 5 addresses. The 2183 flags octet value 128 indicates an address head but no address tail. 2184 The head length of 3 octets indicates address mid sections of one 2185 octet each (Mid 0 to Mid 4). 2187 The following TLV block (content length 14 octets) includes two TLVs. 2188 The first is a LOCAL_IF TLV which (with flags octet value 80) 2189 indicates that a single address, with index 0 (i.e. Head:Mid 0) is 2190 the single local interface address of this node (the 1 octet value 2191 THIS_IF indicates that this address is of this interface). The 2192 second is a LINK_STATUS TLV which (with flags octet value 48) 2193 specifies the link status values of all reported neighbors in a 2194 single multivalue TLV which covers the addresses with indexes 1 to 4. 2195 The TLV value length of 4 octets indicates one octet per value per 2196 address. The last four addresses are first and second HEARD, third 2197 SYMMETRIC, and fourth LOST. 2199 0 1 2 3 2200 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 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | HELLO |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1| 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Originator Address | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0| 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0| 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 |0 0 0 0 0 0 1 1| Head | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Mid 0 | Mid 1 | Mid 2 | Mid 3 | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | LOST | 2227 +-+-+-+-+-+-+-+-+ 2229 Note that this example is for illustrative purposes. The essential 2230 information can be conveyed, more efficiently (assuming that the 2231 local interface address will be supplied by IP, and that the 2232 INTERVAL_TIME is not needed) by the 29 octets: 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1| 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0| 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 |0 0 0 0 0 0 1 1| Head | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Mid 1 | Mid 2 | Mid 3 | Mid 4 | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0| 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | LOST | 2252 +-+-+-+-+-+-+-+-+ 2254 Appendix C. Constraints 2256 Any process which updates the Local Information Base or the Node 2257 Information Base MUST ensure that all constraints specified in this 2258 appendix are maintained. 2260 In each Local Interface Tuple: 2262 o I_local_iface_addr_list MUST NOT be empty. 2264 o I_local_iface_addr_list MUST NOT contain any duplicated addresses. 2266 o I_local_iface_addr_list MUST NOT contain any address which is in 2267 the I_local_iface_addr_list of any other Local Interface Tuple. 2269 In each Removed Interface Address Tuple: 2271 o IR_local_iface_addr MUST NOT contain any address which is in the 2272 I_local_iface_addr_list of any Local Interface Tuple. 2274 o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any 2275 other Removed Interface Address Tuple. 2277 In each Link Tuple: 2279 o L_neighbor_iface_addr_list MUST NOT be empty. 2281 o L_neighbor_iface_addr_list MUST NOT contain any address which is 2282 in the I_local_iface_addr_list of any Local Interface Tuple or the 2283 IR_local_iface_addr of any Removed Interface Address Tuple. 2285 o L_neighbor_iface_addr_list MUST NOT contain any duplicated 2286 addresses. 2288 o L_neighbor_iface_addr_list MUST NOT contain any address which is 2289 in the L_neighbor_iface_addr_list of any other Link Tuple in the 2290 same Link Set. 2292 o If L_HEARD_time has not expired then there MUST be a Neighbor 2293 Tuple whose N_neighbor_iface_addr_list contains 2294 L_neighbor_iface_addr_list. 2296 o L_HEARD_time MUST NOT be greater than L_time. 2298 o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are 2299 expired). 2301 o L_quality MUST NOT be less than 0 or greater than 1. 2303 o If L_quality >= HYST_ACCEPT then L_pending MUST be false. 2305 o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST. 2307 o L_pending MUST NOT be set to true if it is currently false. 2309 In each Neighbor Tuple: 2311 o N_neighbor_iface_addr_list MUST NOT contain any address which is 2312 in the I_local_iface_addr_list of any Local Interface Tuple or the 2313 IR_local_iface_addr of any Removed Interface Address Tuple. 2315 o N_neighbor_iface_addr_list MUST NOT contain any duplicated 2316 addresses. 2318 o N_neighbor_iface_addr_list MUST NOT contain any address which is 2319 in the N_neighbor_iface_addr_list of any other Neighbor Tuple. 2321 o If N_symmetric == true, then there MUST be one or more Link Tuples 2322 with: 2324 * L_neighbor_iface_addr_list contained in 2325 N_neighbor_iface_addr_list; AND 2327 * L_status == SYMMETRIC. 2329 o If N_symmetric == false, then there MUST be one or more Link 2330 Tuples with: 2332 * L_neighbor_iface_addr_list contained in 2333 N_neighbor_iface_addr_list. 2335 All such Link Tuples MUST NOT have L_status == SYMMETRIC. At 2336 least one such Link Tuple MUST have L_HEARD_time not expired. 2338 In each Lost Neighbor Tuple: 2340 o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list 2341 of any Local Interface Tuple or the IR_local_iface_addr of any 2342 Removed Interface Address Tuple. 2344 o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr 2345 of any other Lost Neighbor Tuple. 2347 o NL_neighbor_iface_addr MUST NOT be in the 2348 N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric 2349 == true. 2351 In each 2-Hop Tuple: 2353 o There MUST be a Link Tuple associated with the same MANET 2354 interface with: 2356 * L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND 2358 * L_status == SYMMETRIC. 2360 o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of 2361 any Local Interface Tuple or the IR_local_iface_addr of any 2362 Removed Interface Address Tuple. 2364 o N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other 2365 2-Hop Tuple in the same 2-Hop Set and with the same 2366 N2_neighbor_iface_addr_list. 2368 o N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list 2369 of the same 2-Hop Tuple. 2371 Appendix D. Flow and Congestion Control 2373 This protocol specifies one message type, the HELLO message. The 2374 maximum size of a HELLO message is proportional to the size of the 2375 originating node's 1-hop neighborhood. HELLO messages MUST NOT be 2376 forwarded. 2378 A node MUST report its 1-hop neighborhood in HELLO messages on each 2379 of its MANET interfaces at least each REFRESH_INTERVAL. This puts a 2380 lower bound on the control traffic generated by each node in the 2381 network employing this protocol. 2383 A node MUST ensure that two successive HELLO messages sent on the 2384 same MANET interface are separated by at least HELLO_MIN_INTERVAL. 2385 (If using jitter then this may be reduced to a mean minimum value of 2386 HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound 2387 on the control traffic generated by each node in the network 2388 employing this protocol. 2390 Appendix E. Contributors 2392 This specification is the result of the joint efforts of the 2393 following contributors, listed alphabetically. 2395 o Brian Adamson, NRL, USA, 2397 o Cedric Adjih, INRIA, France, 2399 o Thomas Heide Clausen, LIX, France, 2401 o Justin Dean, NRL, USA, 2403 o Christopher Dearlove, BAE Systems, UK, 2404 2406 o Philippe Jacquet, INRIA, France, 2408 Appendix F. Acknowledgements 2410 The authors would like to acknowledge the team behind OLSRv1, 2411 specified in RFC3626 for their contributions. 2413 The authors would like to gratefully acknowledge the following people 2414 for intense technical discussions, early reviews and comments on the 2415 specification and its components (listed alphabetically): Alan Cullen 2416 (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe 2417 Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), 2418 and the entire IETF MANET working group. 2420 Authors' Addresses 2422 Thomas Heide Clausen 2423 LIX, Ecole Polytechnique, France 2425 Phone: +33 6 6058 9349 2426 EMail: T.Clausen@computer.org 2427 URI: http://www.ThomasClausen.org/ 2429 Christopher Dearlove 2430 BAE Systems Advanced Technology Centre 2432 Phone: +44 1245 242194 2433 EMail: chris.dearlove@baesystems.com 2434 URI: http://www.baesystems.com/ 2436 Justin W. Dean 2437 Naval Research Laboratory 2439 Phone: +1 202 767 3397 2440 EMail: jdean@itd.nrl.navy.mil 2441 URI: http://pf.itd.nrl.navy.mil/ 2443 The OLSRv2 Design Team 2444 MANET Working Group 2446 Full Copyright Statement 2448 Copyright (C) The IETF Trust (2008). 2450 This document is subject to the rights, licenses and restrictions 2451 contained in BCP 78, and except as set forth therein, the authors 2452 retain all their rights. 2454 This document and the information contained herein are provided on an 2455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2457 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2458 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2459 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2462 Intellectual Property 2464 The IETF takes no position regarding the validity or scope of any 2465 Intellectual Property Rights or other rights that might be claimed to 2466 pertain to the implementation or use of the technology described in 2467 this document or the extent to which any license under such rights 2468 might or might not be available; nor does it represent that it has 2469 made any independent effort to identify any such rights. Information 2470 on the procedures with respect to rights in RFC documents can be 2471 found in BCP 78 and BCP 79. 2473 Copies of IPR disclosures made to the IETF Secretariat and any 2474 assurances of licenses to be made available, or the result of an 2475 attempt made to obtain a general license or permission for the use of 2476 such proprietary rights by implementers or users of this 2477 specification can be obtained from the IETF on-line IPR repository at 2478 http://www.ietf.org/ipr. 2480 The IETF invites any interested party to bring to its attention any 2481 copyrights, patents or patent applications, or other proprietary 2482 rights that may cover technology that may be required to implement 2483 this standard. Please address the information to the IETF at 2484 ietf-ipr@ietf.org.