idnits 2.17.1 draft-ietf-manet-nhdp-06.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 2378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2402. 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 800 has weird spacing: '...dr_list is an...' == Line 803 has weird spacing: '...I_manet is a ...' == Line 817 has weird spacing: '...ce_addr is a ...' == Line 820 has weird spacing: '...IR_time speci...' == Line 846 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 (March 10, 2008) is 5891 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 2434 (Obsoleted by RFC 5226) 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: September 11, 2008 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 The OLSRv2 Design Team 10 MANET Working Group 11 March 10, 2008 13 MANET Neighborhood Discovery Protocol (NHDP) 14 draft-ietf-manet-nhdp-06 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 September 11, 2008. 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 51 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 52 4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 9 53 4.2. Information Base Overview . . . . . . . . . . . . . . . . 9 54 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 9 55 4.2.2. Interface Information Bases . . . . . . . . . . . . . 10 56 4.2.3. Node Information Base . . . . . . . . . . . . . . . . 10 57 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11 58 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11 59 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11 60 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12 61 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13 62 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14 63 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14 64 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14 65 5.1.2. Information Validity Times . . . . . . . . . . . . . . 15 66 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16 67 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 17 68 5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17 69 5.2.1. Information Validity Time . . . . . . . . . . . . . . 17 70 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17 71 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 19 72 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 20 73 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 20 74 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 20 75 7. Interface Information Base . . . . . . . . . . . . . . . . . . 21 76 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22 78 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23 79 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23 81 9. Local Information Base Changes . . . . . . . . . . . . . . . . 24 82 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24 83 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24 84 9.3. Adding an Address to an Interface . . . . . . . . . . . . 25 85 9.4. Removing an Address from an Interface . . . . . . . . . . 26 86 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27 87 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27 88 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28 90 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30 91 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30 92 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32 93 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32 94 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33 95 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34 96 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35 97 12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 35 98 12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 37 99 13. Other Information Base Changes . . . . . . . . . . . . . . . . 39 100 13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 39 101 13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 40 102 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 41 103 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 42 104 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 42 105 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 42 106 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 43 107 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 44 108 15. Proposed Values for Parameters and Constants . . . . . . . . . 45 109 15.1. Message Interval Interface Parameters . . . . . . . . . . 45 110 15.2. Information Validity Time Interface Parameters . . . . . . 45 111 15.3. Information Validity Time Node Parameters . . . . . . . . 45 112 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 45 113 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 45 114 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 46 115 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47 116 16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 47 117 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 118 17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 49 119 17.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 49 120 17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50 121 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 122 18.1. Normative References . . . . . . . . . . . . . . . . . . . 51 123 18.2. Informative References . . . . . . . . . . . . . . . . . . 51 124 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52 125 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53 126 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56 127 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59 128 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60 129 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61 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 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC2119 [RFC2119]. 159 The terms "packet", "message", "address", "address block", "TLV", and 160 "TLV block" in this document are to be interpreted as described in 161 [packetbb]. 163 Additionally, this document uses the following terminology: 165 Node - A MANET router which implements this neighborhood discovery 166 protocol. 168 Interface - A network device, configured and assigned one or more IP 169 addresses. 171 Address - An address, as recorded in the Information Bases specified 172 by this protocol, and included in HELLO messages generated by this 173 protocol, may be either an address or an address prefix. These 174 can be represented as a single address object in a HELLO message, 175 as defined by [packetbb]. An address so represented is considered 176 to have a prefix length equal to its length (in bits) when 177 considered as an address object, and a similar convention is used 178 in the Information Bases specified by this protocol. Two 179 addresses (address objects) are considered equal only if their 180 prefix lengths are also equal. 182 MANET interface - An interface participating in a MANET and using 183 this neighborhood discovery protocol. A node may have several 184 MANET interfaces. 186 Heard - A MANET interface of node X is considered heard on a MANET 187 interface of a node Y if the latter can receive traffic from the 188 former. 190 Link - A pair of MANET interfaces from two different nodes, where at 191 least one interface is heard by the other. 193 Symmetric link - A link where both MANET interfaces are heard by the 194 other. 196 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET 197 interface of node X is heard by a MANET interface of node Y. 199 Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of 200 a node Y if a symmetric link exists between a MANET interface on 201 node X and a MANET interface on node Y. 203 Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of 204 a node Y if node X is a symmetric 1-hop neighbor of a symmetric 205 1-hop neighbor of node Y, but is not node Y itself. 207 1-hop neighborhood - The 1-hop neighborhood of a node X is the set 208 of the 1-hop neighbors of node X. 210 Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a 211 node X is the set of the symmetric 1-hop neighbors of node X. 213 Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a 214 node X is the set of the symmetric 2-hop neighbors of node X. 215 (This may include nodes in the 1-hop neighborhood, or even in the 216 symmetric 1-hop neighborhood, of node X.) 218 Constant - A constant is a numerical value which MUST be the same 219 for all MANET interfaces of all nodes in the MANET, at all times. 221 Interface parameter - An interface parameter is a boolean or 222 numerical value, specified separately for each MANET interface of 223 each node. A node MAY change interface parameter values at any 224 time, subject to some constraints. 226 Node parameter - A node parameter is a boolean or numerical value, 227 specified for each node. A node MAY change node parameter values 228 at any time, subject to some constraints. 230 3. Applicability Statement 232 This protocol: 234 o Is applicable to networks, especially wireless networks, in which 235 unknown neighbors (i.e. other nodes with which direct 236 communication can be established) can be reached by local 237 broadcast or multicast packets. 239 o Is designed to work in networks with a dynamic topology, and in 240 which messages may be lost, such as due to collisions in wireless 241 networks. 243 o Supports nodes that each have one or more participating MANET 244 interfaces. The set of a node's interfaces may change over time. 245 Each interface may have one or more interface addresses, and these 246 may also be dynamically changing. 248 o Can use the link local multicast address and either the "manet" 249 UDP port or the "manet" IP protocol number specified in 250 [manet-iana]. 252 o Uses the packet and message formats specified in [packetbb]. Such 253 packets may contain messages specified by this protocol as well as 254 other protocols. 256 o Specifies signaling using HELLO messages. The necessary contents 257 of these messages are defined in this specification, and may be 258 extended using the TLV mechanisms described in [packetbb]. 260 o Can use relevant link layer information if it is available. 262 o Provides each node with local topology information up to two hops 263 away. This information is made available to other protocols, of 264 which this protocol may be a part, in Information Bases defined in 265 this specification. 267 o Is designed to work in a completely distributed manner, and does 268 not depend on any central entity. 270 4. Protocol Overview and Functioning 272 The objective of this protocol is, for each node: 274 o To identify other nodes with which bidirectional links can be 275 established (symmetric 1-hop neighbors). 277 o To agree on the status of such links with the corresponding 278 symmetric 1-hop neighbor. 280 o To find the node's symmetric 2-hop neighbors. 282 o To record this information in Information Bases that can be used 283 by other protocols, of which this neighborhood discovery protocol 284 may be a part. 286 These objectives are achieved using local (one hop) signaling that: 288 o Advertises the presence of a node and its interfaces. 290 o Discovers links with adjacent nodes. 292 o Performs bidirectionality checks on the discovered links. 294 o Advertises discovered links, and whether each is symmetric, to its 295 1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 297 This specification defines, in turn: 299 o Parameters and constants used by the protocol. Parameters used by 300 this protocol may be, where appropriate, specific to a MANET 301 interface. This protocol allows all parameters to be changed 302 dynamically. 304 o The Information Bases describing local interfaces, discovered 305 links and their status, current and former 1-hop neighbors, and 306 symmetric 2-hop neighbors. 308 o The format of the HELLO message that is used for local signaling. 310 o The generation of HELLO messages from some of the information in 311 the Information Bases. 313 o The updating of the Information Bases according to received HELLO 314 messages and other events. 316 4.1. Nodes and Interfaces 318 In order for a node to participate in a MANET, it MUST have at least 319 one, and possibly more, MANET interfaces. Each MANET interface: 321 o Is characterized by a set of interface parameters, defining the 322 behavior of this MANET interface. Each MANET interface MAY be 323 individually parameterized. 325 o Has an Interface Information Base, recording information regarding 326 links to this MANET interface and symmetric 2-hop neighbors which 327 can be reached through such links. 329 o Generates and processes HELLO messages, according to the interface 330 parameters for that MANET interface. 332 In addition to a set of MANET interfaces as described above, each 333 node has: 335 o A Local Information Base, containing the addresses of the 336 interfaces (MANET and non-MANET) of this node. The contents of 337 this Information Base are not changed by signaling. 339 o A Node Information Base, recording information regarding current 340 and recently lost 1-hop neighbors of this node. 342 A node may have both MANET interfaces and non-MANET interfaces. 343 Interfaces of both of these types are recorded in a node's Local 344 Information Base, which is used, but not updated, by the signaling of 345 this protocol. 347 4.2. Information Base Overview 349 Each node maintains the Information Bases described in the following 350 sections. These are used for describing the protocol in this 351 document. An implementation of this protocol MAY maintain this 352 information in the indicated form, or in any other organization which 353 offers access to this information. In particular note that it is not 354 necessary to remove Tuples from Sets at the exact time indicated, 355 only to behave as if the Tuples were removed at that time. 357 4.2.1. Local Information Base 359 Each node maintains a Local Information Base, which contains: 361 o The Local Interface Set, which consists of Local Interface Tuples, 362 each of which records the addresses of an interface (MANET or non- 363 MANET) of the node. 365 o The Removed Interface Address Set, which consists of Removed 366 Interface Address Tuples, each of which records a recently used 367 address of an interface (MANET or non-MANET) of the node. 369 4.2.2. Interface Information Bases 371 Each node maintains, for each of its MANET interfaces, an Interface 372 Information Base, which contains: 374 o A Link Set, which records information about current and recently 375 lost links between this interface and MANET interfaces of 1-hop 376 neighbors. The Link Set consists of Link Tuples, each of which 377 contains information about a single link. Recently lost links are 378 recorded so that they can be advertised in HELLO messages, 379 accelerating their removal from relevant 1-hop neighbors' Link 380 Sets. Link quality information, if used and available, is 381 recorded in Link Tuples and may indicate that links are treated as 382 lost. 384 o A 2-Hop Set, which records the existence of bidirectional links 385 between symmetric 1-hop neighbors of this MANET interface and 386 other nodes (symmetric 2-hop neighbors). The 2-Hop Set consists 387 of 2-Hop Tuples, each of which records an interface address of a 388 symmetric 2-hop neighbor, and all interface addresses of the 389 corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated 390 by the signaling of this protocol, but is not itself reported in 391 that signaling. 393 4.2.3. Node Information Base 395 Each node maintains a Node Information Base, which contains: 397 o The Neighbor Set, which records 1-hop neighbors, each of which 398 must be currently heard, although this may be over a link with 399 insufficient link quality. The Neighbor Set consists of Neighbor 400 Tuples, each of which records all interface addresses (whether 401 directly linked or not) of a single 1-hop neighbor. Neighbor 402 Tuples are maintained as long as there are corresponding current 403 Link Tuples. 405 o The Lost Neighbor Set, which records recently lost symmetric 1-hop 406 neighbors. The Lost Neighbor Set consists of Lost Neighbor 407 Tuples, each of which records an interface address of such a 408 neighbor. These are recorded so that they can be advertised in 409 HELLO messages, accelerating their removal from other nodes' 2-Hop 410 Sets. 412 4.3. Signaling Overview 414 This protocol contains a signaling mechanism for maintaining the 415 Interface Information Bases and the Node Information Base. If 416 information from the link layer, or any other source, is available 417 and appropriate, it may also be used to update these Information 418 Bases. Such updates are subject to the constraints specified in 419 Appendix C. 421 Signaling consists of a single type of message, known as a HELLO 422 message. Each node generates HELLO messages on each of its MANET 423 interfaces. Each HELLO message identifies that MANET interface, and 424 reports the other interfaces (MANET and non-MANET) of the node. Each 425 HELLO message includes information from the Link Set of the Interface 426 Information Base of the MANET interface, and from the Node 427 Information Base. 429 4.3.1. HELLO Message Generation 431 HELLO messages are generated by a node for each of its MANET 432 interfaces, and MAY be sent: 434 o Proactively, at a regular interval, known as HELLO_INTERVAL. 435 HELLO_INTERVAL may be fixed, or may be dynamic. For example 436 HELLO_INTERVAL may be backed off due to congestion or network 437 stability. 439 o As a response to a change in the node itself, or its 1-hop 440 neighborhood, for example on first becoming active or in response 441 to a new, broken, or changed status link. 443 o In a combination of these proactive and responsive mechanisms. 445 Jittering of HELLO message generation and transmission, as described 446 in Section 11.2, SHOULD be used if appropriate. 448 HELLO messages are generated independently on each MANET interface of 449 a node. HELLO messages MAY be scheduled independently for each MANET 450 interface, or, interface parameters permitting, using the same 451 schedule for all MANET interfaces of a node. 453 4.3.2. HELLO Message Content 455 Each HELLO message sent over a MANET interface need not contain all 456 of the information appropriate to that MANET interface, however: 458 o A HELLO message MUST contain all of the addresses in the Local 459 Interface Set of the node to which the MANET interface belongs. 461 o Within every time interval of length REFRESH_INTERVAL, the HELLO 462 messages sent on each MANET interface of a node MUST collectively 463 include: 465 * All of the relevant information in the Link Set of the 466 Interface Information Base of that MANET interface. 468 * All of the relevant information in the Node Information Base of 469 that node. 471 This applies to otherwise purely responsive nodes as well as to 472 proactive nodes. In either case it means that all information 473 appropriate to that MANET interface will have always been 474 transmitted, in one or more HELLO messages, since the time 475 REFRESH_INTERVAL ago. 477 o A HELLO message MUST include a VALIDITY_TIME message TLV that 478 indicates the length of time for which the message content is to 479 be considered valid, and included in the receiving node's 480 Interface Information Base. 482 o A periodically generated HELLO message SHOULD include an 483 INTERVAL_TIME message TLV that indicates the current value of 484 HELLO_INTERVAL for that MANET interface, i.e. the period within 485 which a further HELLO message is guaranteed to be sent on that 486 MANET interface. 488 o Additional information may be added by a protocol using this 489 protocol using the TLV mechanisms described in [packetbb]. For 490 example, if multipoint relays (MPRs) are to be calculated 491 similarly to as in OLSR [RFC3626] and signaled to neighbors, then 492 this information may be added to HELLO messages using an address 493 block TLV. 495 4.3.3. HELLO Message Processing 497 All HELLO messages received by a node are used to update: 499 o The Interface Information Base for the MANET interface on which 500 that HELLO message is received. 502 o The Node Information Base. 504 Specifically: 506 o The node ensures that there is a single Neighbor Tuple 507 corresponding to the originator of that HELLO message. 509 o If a Link Tuple corresponding to the link on which that HELLO 510 message was received exists, then its duration is extended, 511 otherwise such a Link Tuple is created. If the HELLO message 512 indicates that the receiving MANET interface has been heard, then 513 the link is considered symmetric, or its duration as symmetric is 514 extended. If the HELLO message indicates that the receiving MANET 515 interface is lost, then the link is no longer considered 516 symmetric. In this case one or more Lost Neighbor Tuples may be 517 created. 519 o If the link on which the HELLO message is received is symmetric, 520 then any symmetrically advertised neighbors in the HELLO message 521 are added to the 2-Hop Set for the receiving interface, or if 522 already present, the durations of the corresponding 2-Hop Tuples 523 are extended. 525 In all cases the processing takes account of unexpected and erroneous 526 information in the HELLO message, maintaining the constraints 527 specified in Appendix C. 529 4.4. Link Quality 531 Some links in a MANET may be marginal, e.g. due to adverse wireless 532 propagation. In order to avoid using such marginal links, a link 533 quality is associated with each link in the Link Set, and links with 534 insufficient link quality are considered lost. Modifying the link 535 quality of a link is OPTIONAL. If link quality is not to be modified 536 it MUST be set to indicate an always usable quality link. Link 537 quality information is only used locally, it is not used in 538 signaling, and nodes may interoperate whether they are using the 539 same, different, or no, link quality information. 541 5. Protocol Parameters and Constants 543 The parameters and constants used in this specification are described 544 in this section. 546 5.1. Interface Parameters 548 The interface parameters used by this specification may be classified 549 into the following four categories: 551 o Message intervals 553 o Information validity times 555 o Link quality 557 o Jitter 559 These are detailed in the following sections. 561 Different MANET interfaces (on the same or on different nodes) MAY 562 employ different interface parameter values, and may change their 563 interface parameter values dynamically, subject to the constraints 564 given in this section. A particular case is where all MANET 565 interfaces on all MANET nodes within a given MANET employ the same 566 set of interface parameter values. 568 5.1.1. Message Intervals 570 The following interface parameters regulate HELLO message 571 transmissions over a given MANET interface. 573 HELLO messages serve two principal functions: 575 o To advertise this node's own addresses to its 1-hop neighbors. 576 The frequency of these advertisements is regulated by the 577 interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. 579 o To advertise this node's knowledge of each of its 1-hop neighbors. 580 The frequency of the advertisement of each such neighbor is 581 regulated by the interface parameter REFRESH_INTERVAL. 583 Specifically, these parameters are as follows: 585 HELLO_INTERVAL - is the maximum time between the transmission of two 586 successive HELLO messages on this MANET interface. If using 587 periodic transmission of HELLO messages, these SHOULD be at a 588 separation of HELLO_INTERVAL, possibly modified by jitter as 589 specified in [RFC5148]. 591 HELLO_MIN_INTERVAL - is the minimum interval between transmission of 592 two successive HELLO messages, on this MANET interface. (This 593 minimum interval MAY be modified by jitter, as defined in 594 [RFC5148].) 596 REFRESH_INTERVAL - is the maximum interval between advertisements in 597 a HELLO message of each 1-hop neighbor address and its status. In 598 all intervals of length REFRESH_INTERVAL, a node MUST include all 599 1-hop neighbor information which it is specified as sending in at 600 least one HELLO message on this MANET interface. 602 The following constraints apply to these interface parameters: 604 o HELLO_INTERVAL > 0 606 o HELLO_MIN_INTERVAL >= 0 608 o HELLO_INTERVAL >= HELLO_MIN_INTERVAL 610 o REFRESH_INTERVAL >= HELLO_INTERVAL 612 o If INTERVAL_TIME message TLVs as defined in [timetlv] are included 613 in HELLO messages, then HELLO_INTERVAL MUST be representable as 614 described in [timetlv]. 616 If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its 617 neighbor advertisements between HELLO messages in any manner, subject 618 to the constraints above. 620 For a node to employ this protocol in a purely responsive manner on a 621 MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be 622 set to a value such that a responsive HELLO message is always 623 expected in a shorter period than this value. 625 5.1.2. Information Validity Times 627 The following interface parameters manage the validity time of link 628 information: 630 L_HOLD_TIME - is the period of advertisement, on this MANET 631 interface, of former 1-hop neighbor addresses as lost in HELLO 632 messages, allowing recipients of these HELLO messages to 633 accelerate removal of information from their Link Sets. 634 L_HOLD_TIME can be set to zero if accelerated information removal 635 is not required. 637 H_HOLD_TIME - is used as the value in the VALIDITY_TIME message TLV 638 included in all HELLO messages on this MANET interface. 640 The following constraints apply to these interface parameters: 642 o L_HOLD_TIME >= 0 644 o H_HOLD_TIME >= REFRESH_INTERVAL 646 o If HELLO messages can be lost then both SHOULD be significantly 647 greater than REFRESH_INTERVAL. 649 o H_HOLD_TIME MUST be representable as described in [timetlv]. 651 5.1.3. Link Quality 653 The following interface parameters manage the usage of link quality 654 (see Section 4.4): 656 HYST_ACCEPT - is the link quality threshold at or above which a link 657 becomes usable, if it was not already so. 659 HYST_REJECT - is the link quality threshold below which a link 660 becomes unusable, if it was not already so. 662 INITIAL_QUALITY - is the initial quality of a newly identified link. 664 INITIAL_PENDING - if true, then a newly identified link is 665 considered pending, and is not usable until the link quality has 666 reached or exceeded the HYST_ACCEPT threshold. 668 The following constraints apply to these interface parameters: 670 o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 672 o 0 <= INITIAL_QUALITY <= 1. 674 o If link quality is not updated, then INITIAL_QUALITY >= 675 HYST_ACCEPT. 677 o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false. 679 o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true. 681 5.1.4. Jitter 683 If jitter, as defined in [RFC5148], is used then these parameters are 684 as follows: 686 HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 687 for periodically generated HELLO messages on this MANET interface. 689 HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 690 for externally triggered HELLO messages on this MANET interface. 692 For constraints on these interface parameters see [RFC5148]. 694 5.2. Node Parameters 696 The two node parameters defined by this specification are in the 697 category of information validity time. 699 5.2.1. Information Validity Time 701 The following node parameter manages the validity time of lost 702 symmetric 1-hop neighbor information: 704 N_HOLD_TIME - is used as the period during which former 1-hop 705 neighbor addresses are advertised as lost in HELLO messages, 706 allowing recipients of these HELLO messages to accelerate removal 707 of information from their 2-Hop Sets. N_HOLD_TIME can be set to 708 zero if accelerated information removal is not required. 710 I_HOLD_TIME - is the period for which a recently used local 711 interface address is recorded. 713 The following constraints applies to these node parameters: 715 o N_HOLD_TIME >= 0 717 o I_HOLD_TIME >= 0 719 5.3. Parameter Change Constraints 721 This section presents guidelines, applicable if protocol parameters 722 are changed dynamically. 724 HELLO_INTERVAL 726 * If the HELLO_INTERVAL for a MANET interface increases, then the 727 next HELLO message on this MANET interface MUST be generated 728 according to the previous, shorter, HELLO_INTERVAL. Additional 729 subsequent HELLO messages MAY be generated according to the 730 previous, shorter, HELLO_INTERVAL (but MUST include times 731 according to current parameters). 733 * If the HELLO_INTERVAL for a MANET interface decreases, then the 734 following HELLO messages on this MANET interface MUST be 735 generated according to this current, shorter, HELLO_INTERVAL. 737 REFRESH_INTERVAL 739 * If the REFRESH_INTERVAL for a MANET interface increases, then 740 the content of subsequent HELLO messages must be organized such 741 that the specification of the old value of REFRESH_INTERVAL is 742 satisfied for a further period equal to the old value of 743 REFRESH_INTERVAL. 745 * If the REFRESH_INTERVAL for a MANET interface decreases, then 746 it MAY be necessary to reschedule HELLO message generation on 747 that MANET interface, in order that the specification of 748 REFRESH_INTERVAL is satisfied from the time of change. 750 HYST_ACCEPT and HYST_REJECT 752 * If HYST_ACCEPT or HYST_REJECT changes, then the appropriate 753 actions for link quality change, as specified in Section 14.3 754 MUST be taken. 756 L_HOLD_TIME 758 * If L_HOLD_TIME changes, then L_time for all relevant Link 759 Tuples MUST be changed. 761 N_HOLD_TIME 763 * If N_HOLD_TIME changes, then NL_time for all relevant Lost 764 Neighbor Tuples MUST be changed. 766 HP_MAXJITTER 768 * If HP_MAXJITTER changes, then the periodic HELLO message 769 schedule on this MANET interface MAY be changed. 771 HT_MAXJITTER 773 * If HT_MAXJITTER changes, then externally triggered HELLO 774 messages on this MANET interface MAY be rescheduled. 776 5.4. Constants 778 The constant C (time granularity) is used as specified in [timetlv]. 780 6. Local Information Base 782 A node maintains a Local Information Base that records information 783 about its interfaces (MANET and non-MANET). Each interface MUST have 784 at least one address, and MAY have more than one address. 786 The Local Information Base is not modified by signaling. If a node's 787 interface configuration changes, then the Local Information Base MUST 788 reflect these changes. This MAY also result in signaling to 789 advertise these changes. 791 6.1. Local Interface Set 793 A node's Local Interface Set records its local interfaces. It 794 consists of Local Interface Tuples, one per interface: 796 (I_local_iface_addr_list, I_manet) 798 where: 800 I_local_iface_addr_list is an unordered list of the addresses of 801 this interface. 803 I_manet is a boolean flag, describing if this interface is a MANET 804 interface. 806 6.2. Removed Interface Address Set 808 A node's Removed Interface Address Set records addresses which were 809 recently local interface addresses. If a node's interface addresses 810 are immutable then this set is always empty and MAY be omitted. It 811 consists of Removed Interface Address Tuples, one per address: 813 (IR_local_iface_addr, IR_time) 815 where: 817 IR_local_iface_addr is a recently used address of an interface of 818 this node. 820 IR_time specifies when this Tuple expires and MUST be removed. 822 7. Interface Information Base 824 A node maintains an Interface Information Base for each of its MANET 825 interfaces. This records information about links to that MANET 826 interface and symmetric 2-hop neighbors which can be reached in two 827 hops using those links as the first hop. The Interface Information 828 Base includes the Link Set and the 2-Hop Set. 830 A MANET interface address can be present as of both a 1-hop neighbor 831 and a symmetric 2-hop neighbor. This allows the node with this MANET 832 interface address to be immediately considered as a symmetric 2-hop 833 neighbor if it fails to be a symmetric 1-hop neighbor. 835 7.1. Link Set 837 A node's Link Set records links from other nodes which are, or 838 recently were, 1-hop neighbors. It consists of Link Tuples, each 839 representing a single link: 841 (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, 842 L_quality, L_pending, L_lost, L_time) 844 where: 846 L_neighbor_iface_addr_list is an unordered list of the addresses of 847 the MANET interface of the 1-hop neighbor; 849 L_HEARD_time is the time until which the MANET interface of the 850 1-hop neighbor would be considered heard if not considering link 851 quality; 853 L_SYM_time is the time until which the link to the 1-hop neighbor 854 would be considered symmetric if not considering link quality; 856 L_quality is a dimensionless number between 0 (inclusive) and 1 857 (inclusive) describing the quality of a link; a greater value of 858 L_quality indicating a higher quality link; 860 L_pending is a boolean flag, describing if a link is considered 861 pending (i.e. a candidate, but not yet established, link); 863 L_lost is a boolean flag, describing if a link is considered lost 864 due to link quality; 866 L_time specifies when this Tuple expires and MUST be removed. 868 The status of the link, as obtained through HELLO message exchange, 869 and also taking link quality into account is denoted L_status. 871 L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The 872 values LOST, SYMMETRIC and HEARD are defined in Section 17.3. The 873 value PENDING is never used in a message, it is only used locally by 874 a node, and any value distinct from LOST, SYMMETRIC and HEARD may be 875 used. 877 L_status is defined by: 879 1. If L_pending is true, then L_status = PENDING; 881 2. otherwise, if L_lost is true, then L_status = LOST; 883 3. otherwise, if L_SYM_time is not expired, then L_status = 884 SYMMETRIC; 886 4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD; 888 5. otherwise, L_status = LOST. 890 7.2. 2-Hop Set 892 A node's 2-Hop Set records symmetric 2-hop neighbors, and the 893 symmetric links to symmetric 1-hop neighbors through which the 894 symmetric 2-hop neighbors can be reached. It consists of 2-Hop 895 Tuples, each representing a single interface address of a symmetric 896 2-hop neighbor, and a single MANET interface of a symmetric 1-hop 897 neighbor. 899 (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) 901 where: 903 N2_neighbor_iface_addr_list is an unordered list of the addresses of 904 the MANET interface of the symmetric 1-hop neighbor from which 905 this information was received; 907 N2_2hop_iface_addr is an address of an interface of a symmetric 908 2-hop neighbor which has a symmetric link (using any MANET 909 interface) to the indicated symmetric 1-hop neighbor; 911 N2_time specifies when this Tuple expires and MUST be removed. 913 8. Node Information Base 915 Each node maintains a Node Information Base that records information 916 about addresses of current and recently symmetric 1-hop neighbors. 918 8.1. Neighbor Set 920 A node's Neighbor Set records all interface addresses of each 1-hop 921 neighbor. It consists of Neighbor Tuples, each representing a single 922 1-hop neighbor: 924 (N_neighbor_iface_addr_list, N_symmetric) 926 where: 928 N_neighbor_iface_addr_list is an unordered list of the interface 929 addresses of a 1-hop neighbor; 931 N_symmetric is a boolean flag, describing if this is a symmetric 932 1-hop neighbor. 934 8.2. Lost Neighbor Set 936 A node's Lost Neighbor Set records addresses of all interfaces of 937 nodes which recently were symmetric 1-hop neighbors, but are now 938 advertised as lost. It consists of Lost Neighbor Tuples, each 939 representing a single such address: 941 (NL_neighbor_iface_addr, NL_time) 943 where: 945 NL_neighbor_iface_addr is an address of an interface of a node which 946 recently was a symmetric 1-hop neighbor of this node; 948 NL_time specifies when this Tuple expires and MUST be removed. 950 9. Local Information Base Changes 952 The Local Information Base MUST change to respond to changes in the 953 node's local interface configuration. The node MUST update its 954 Interface and Node Information Bases in response to such changes. If 955 any changes in the Interface and Node Information Bases satisfy any 956 of the conditions described in Section 13, then those changes must be 957 applied immediately, unless noted otherwise. 959 A node MAY transmit HELLO messages in response to these changes. 961 9.1. Adding an Interface 963 If an interface is added to the node then this is indicated by the 964 addition of a Local Interface Tuple to the Local Interface Set. If 965 the new interface is a MANET interface then an initially empty 966 Interface Information Base MUST be created for this new MANET 967 interface. The actions in Section 9.3 MUST be taken for each address 968 of this added interface. A HELLO message MAY be sent on all MANET 969 interfaces, it SHOULD be sent on the new interface if it is a MANET 970 interface. If using scheduled messages, then a message schedule MUST 971 be established on a new MANET interface. 973 9.2. Removing an Interface 975 If an interface is removed from the node, then this MUST result in 976 changes to the Local Information Base and the Node Information Base 977 as follows: 979 1. Identify the Local Interface Tuple that corresponds to the 980 interface to be removed. 982 2. For each address (henceforth removed address) in the 983 I_local_iface_addr_list of that Local Interface Tuple, create a 984 Removed Interface Address Tuple with: 986 * IR_local_iface_addr = removed address; 988 * IR_time = current time + I_HOLD_TIME. 990 3. Remove that Local Interface Tuple from the Local Interface Set. 992 4. If the interface to be removed is a MANET interface (i.e. with 993 I_manet == true) then: 995 1. Remove the Interface Information Base for that MANET 996 interface; 998 2. All Neighbor Tuples for which none of the addresses in its 999 N_neighbor_iface_addr_list are found in any 1000 L_neighbor_iface_addr_list in any remaining Link Set, are 1001 removed. 1003 If a node removes the Local Interface Tuple that contains the 1004 interface address that is used to define the node's originator 1005 address, as defined in [packetbb], then the node MAY change 1006 originator address. 1008 If the removed interface is the last MANET interface of the node, 1009 then there will be no remaining Interface Information Bases, and the 1010 node will longer participate in this protocol. 1012 After removing the interface and making these changes, a HELLO 1013 message MAY be sent on all remaining MANET interfaces. 1015 9.3. Adding an Address to an Interface 1017 If an address is added to an interface then this is indicated by the 1018 addition of an address to the appropriate I_local_iface_addr_list. 1019 The following changes MUST be made to the Information Bases: 1021 1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list 1022 contains the added address, are removed. 1024 2. Any Link Tuples, in any Link Set, whose 1025 L_neighbor_iface_addr_list contains: 1027 * the added address; OR 1029 * any address in the N_neighbor_iface_addr_list of the removed 1030 Neighbor Tuples, if any 1032 are removed; apply Section 13.1, but not Section 13.3. 1034 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the 1035 added address, are removed. 1037 4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address, 1038 are removed. 1040 After adding the address and making these changes, a HELLO message 1041 MAY be sent on all MANET interfaces. 1043 9.4. Removing an Address from an Interface 1045 If an address (henceforth removed address) is removed from an 1046 interface then: 1048 1. Identify the Local Interface Tuple that corresponds to the 1049 interface to be removed. 1051 2. If this is the only address of that interface (the only address 1052 in the corresponding I_local_iface_addr_list) then remove that 1053 interface as specified in Section 9.2. 1055 3. Otherwise: 1057 1. Remove the removed address from this I_local_iface_addr_list. 1059 2. Create a Removed Interface Address Tuple with: 1061 + IR_local_iface_addr = removed address; 1063 + IR_time = current time + I_HOLD_TIME. 1065 If a node removes the interface address that is used to define the 1066 node's originator address, as defined in [packetbb], then the node 1067 MAY change originator address. 1069 After removing the address and making these changes, a HELLO message 1070 MAY be sent on all MANET interfaces. 1072 10. Packets and Messages 1074 The packet and message format used by this protocol is defined in 1075 [packetbb], which is used with the following considerations: 1077 o This protocol specifies one message type, the HELLO message. 1079 o HELLO message header options MAY be used as specified by a 1080 protocol which uses this neighborhood discovery protocol. 1082 o HELLO messages MUST NOT be forwarded. 1084 o HELLO messages MAY be included in multi-message packets as 1085 specified in [packetbb]. 1087 o Packet header options MAY be used as specified by a protocol which 1088 uses this neighborhood discovery protocol. 1090 o Received HELLO messages MUST be parsed in accordance with 1091 [packetbb]. A HELLO message which is not in conformance with 1092 [packetbb] MUST be discarded. 1094 o This protocol specifies three address block TLVs. It also uses 1095 two message TLVs defined in [timetlv]. These five TLV types are 1096 all defined only with Type Extension == 0. TLVs of other types, 1097 and of these types but without Type Extension == 0, are ignored by 1098 this protocol. All references in this protocol to, for example, a 1099 TLV with Type == LINK_STATUS, are to be considered as referring to 1100 a TLV with Type == LINK_STATUS and Type Extension == 0. 1102 10.1. HELLO Messages 1104 A HELLO message MUST contain: 1106 o A VALIDITY_TIME message TLV as specified in [timetlv], 1107 representing H_HOLD_TIME for the transmitting MANET interface. 1108 The options included in [timetlv] for representing zero and 1109 infinite times MUST NOT be used. 1111 A HELLO message which is transmitted periodically SHOULD contain, and 1112 otherwise MAY contain: 1114 o An INTERVAL_TIME message TLV as specified in [timetlv], 1115 representing HELLO_INTERVAL for the transmitting MANET interface. 1116 The options included in [timetlv] for representing zero and 1117 infinite times MUST NOT be used. 1119 A HELLO message MAY contain: 1121 o One or more address blocks, each with an associated TLV block. 1123 o Other message TLVs. 1125 10.1.1. Address Blocks 1127 All addresses in a node's Local Interface Set (i.e. in any 1128 I_local_iface_addr_list) MUST be included in the address blocks in 1129 all generated HELLO messages with the following exception. If the 1130 MANET interface on which the HELLO message is to be sent has a single 1131 interface address with maximum prefix length then that address MAY be 1132 omitted. All addresses of the node's interfaces included in an 1133 address block MUST be associated with a TLV with Type == LOCAL_IF, as 1134 defined in Table 1. 1136 +----------+--------+-----------------------------------------------+ 1137 | Name | Value | Description | 1138 | | Length | | 1139 +----------+--------+-----------------------------------------------+ 1140 | LOCAL_IF | 1 | Specifies that the address is an address | 1141 | | octet | associated with the interface on which the | 1142 | | | message was sent (THIS_IF), another interface | 1143 | | | of the sending node (OTHER_IF), or an | 1144 | | | unspecified interface of the sending node | 1145 | | | (UNSPEC_IF). | 1146 +----------+--------+-----------------------------------------------+ 1148 Table 1 1150 Note that the value UNSPEC_IF is not used by this protocol. It is 1151 provided for an expected alternative use of this TLV. 1153 Address blocks MAY contain current or recently lost 1-hop neighbors' 1154 interface addresses, each of which is associated with address block 1155 TLVs as described in Table 2. 1157 +--------------+--------+-------------------------------------------+ 1158 | Name | Value | Description | 1159 | | Length | | 1160 +--------------+--------+-------------------------------------------+ 1161 | LINK_STATUS | 1 | Specifies the status of the link from the | 1162 | | octet | indicated address (LOST, SYMMETRIC or | 1163 | | | HEARD). | 1164 | | | | 1165 | OTHER_NEIGHB | 1 | Specifies that the address is (SYMMETRIC) | 1166 | | octet | or was (LOST) of an interface of a | 1167 | | | symmetric 1-hop neighbor of the node | 1168 | | | transmitting the HELLO message. | 1169 +--------------+--------+-------------------------------------------+ 1171 Table 2 1173 A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == 1174 LOST) also performs the function of a TLV with Type == OTHER_NEIGHB 1175 and the same value. The latter SHOULD NOT also be included. If a 1176 TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with 1177 a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter 1178 MUST be ignored, and SHOULD NOT be included. See Appendix A. 1180 Other addresses MAY be included in address blocks, but MUST NOT be 1181 associated with any of the TLVs specified in this section. 1183 11. HELLO Message Generation 1185 Each MANET interface MUST generate HELLO messages according to the 1186 specification in this section. HELLO message generation and 1187 scheduling MUST be according to the interface parameters for that 1188 MANET interface and MAY be independent for each MANET interface or, 1189 interface parameters permitting, MANET interfaces MAY use the same 1190 schedule. 1192 If transmitting periodic HELLO messages then, following a HELLO 1193 message transmission on a MANET interface, another HELLO message MUST 1194 be transmitted on the same MANET interface after an interval not 1195 greater than HELLO_INTERVAL. Two successive HELLO message 1196 transmissions on the same MANET interface MUST be separated by at 1197 least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. 1199 11.1. HELLO Message Specification 1201 HELLO messages are generated independently on each MANET interface. 1203 All addresses in any I_local_iface_addr_list MUST be included, except 1204 that: 1206 o If the interface on which the HELLO message is to be sent has a 1207 single interface address with maximum prefix length then that 1208 interface address MAY be omitted. 1210 All such included addresses MUST be associated with a TLV with Type 1211 == LOCAL_IF and value according to the following: 1213 o If the address is of the sending interface, then Value == THIS_IF. 1215 o Otherwise, Value == OTHER_IF. 1217 The following addresses of current or former 1-hop neighbors MAY be 1218 included in any HELLO message: 1220 o Addresses of MANET interfaces of 1-hop neighbors from the Link Set 1221 of the Interface Information Base for this MANET interface. 1223 o Other addresses of symmetric 1-hop neighbors from the Neighbor Set 1224 of this node's Node Information Base. 1226 o Addresses of MANET interfaces of previously symmetric or heard 1227 1-hop neighbors connected on this MANET interface from the Link 1228 Set of the Interface Information Base for this MANET interface. 1229 (These are advertised for a period equal to this interface's 1230 L_HOLD_TIME after loss.) 1232 o Other addresses of previously symmetric 1-hop neighbors from the 1233 Lost Neighbor Set of this node's Node Information Base. (These 1234 are advertised for a period equal to N_HOLD_TIME after loss.) 1236 Each such address MUST be associated with one or more appropriate 1237 TLVs, respecting the parameter REFRESH_INTERVAL for each association 1238 for each MANET interface. Specifically: 1240 1. For each address (henceforth linked address) which appears in a 1241 Link Tuple in the Link Set for this MANET interface, for which 1242 L_status does not equal PENDING, include the linked address with 1243 an associated TLV with: 1245 * Type = LINK_STATUS; AND 1247 * Value = L_status. 1249 2. For each address (henceforth neighbor address) which appears in 1250 an N_neighbor_iface_addr_list in a Neighbor Tuple with 1251 N_symmetric == true, and which has not already been included with 1252 an associated TLV with (Type == LINK_STATUS and Value == 1253 SYMMETRIC), include the neighbor address with an associated TLV 1254 with: 1256 * Type = OTHER_NEIGHB; AND 1258 * Value = SYMMETRIC. 1260 3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr 1261 (henceforth lost address) has not already been included, include 1262 the lost address with an associated TLV with: 1264 * Type = OTHER_NEIGHB; AND 1266 * Value = LOST. 1268 If a 1-hop neighbor address is specified with more than one 1269 associated TLV, then these TLVs MAY be independently included or 1270 excluded from each HELLO message. Each such TLV MUST be included 1271 associated with that address in a HELLO message sent on that MANET 1272 interface in every interval of length equal to that MANET interface's 1273 parameter REFRESH_INTERVAL. TLVs associated with the same address 1274 included in the same HELLO message MAY be applied to the same or 1275 different copies of that address. 1277 11.2. HELLO Message Transmission 1279 HELLO messages are transmitted in the packet/message format specified 1280 by [packetbb] using the "LL-MANET-Routers" multicast address 1281 specified by [manet-iana] as destination IP address, using either the 1282 "manet" UDP port, or the "manet" IP protocol number specified in 1283 [manet-iana]. 1285 11.2.1. HELLO Message Jitter 1287 HELLO messages MAY be sent using periodic message generation or 1288 externally triggered message generation. If using data link and 1289 physical layers which are subject to packet loss due to collisions, 1290 HELLO messages SHOULD be jittered as described in [RFC5148]. 1292 Internally triggered message generation (such as due to a change in 1293 local interfaces) MAY be treated as if externally generated message 1294 generation, or MAY be not jittered. 1296 HELLO messages MUST NOT be forwarded, and thus message forwarding 1297 jitter does not apply to HELLO messages. 1299 Each form of jitter described in [RFC5148] requires a parameter 1300 MAXJITTER. These interface parameters may be dynamic, and are 1301 specified by: 1303 o For periodic message generation: HP_MAXJITTER. 1305 o For externally triggered message generation: HT_MAXJITTER. 1307 When HELLO message generation is delayed in order that a HELLO 1308 message is not sent within HELLO_MIN_INTERVAL of the previous HELLO 1309 message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD 1310 be reduced by jitter, with maximum reduction HP_MAXJITTER. In this 1311 case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. 1313 12. HELLO Message Processing 1315 On receiving a HELLO message, a node MUST first check if any address 1316 associated with a TLV with Type == LOCAL_IF is one of the receiving 1317 node's current or recently used interface addresses (i.e. is in any 1318 I_local_iface_addr_list in the Local Interface Set or is equal to any 1319 IR_local_iface_addr in the Removed Interface Address Set). If so 1320 then the HELLO message MUST be discarded. 1322 Otherwise the receiving node MUST update its appropriate Interface 1323 Information Base and its Node Information Base according to this 1324 section. Section 12.1 to Section 12.4 MUST be performed in the order 1325 presented. If any changes satisfy any of the conditions described in 1326 Section 13 then the indicated consequences MUST be applied 1327 immediately, unless noted otherwise. 1329 For the purpose of this section, note the following definitions: 1331 o "validity time" is calculated from the VALIDITY_TIME message TLV 1332 of the HELLO message as specified in [timetlv]. All information 1333 in the HELLO message has the same validity time. 1335 o "Receiving Address List" is the I_local_iface_addr_list 1336 corresponding to the MANET interface on which the HELLO message 1337 was received 1339 o "Sending Address List" is the list of the addresses contained in 1340 the HELLO message with an associated TLV with Type == LOCAL_IF and 1341 Value == THIS_IF. If the Sending Address List is otherwise empty, 1342 then the Sending Address List contains a single address (with 1343 maximum prefix length) equal to the sending address of the IP 1344 datagram in which the HELLO message was included. 1346 o "Neighbor Address List" is the Sending Address List, plus the 1347 addresses contained in the HELLO message with an associated TLV 1348 with Type == LOCAL_IF and Value == OTHER_IF. 1350 o EXPIRED indicates that a timer is set to a value clearly preceding 1351 the current time (e.g. current time - 1). 1353 o "Removed Address List" is a list of addresses created by this 1354 HELLO message processing which were formerly reported as local by 1355 the node originating the HELLO message, but which are not included 1356 in the Neighbor Address List. This list is initialized as empty. 1358 o "Lost Address List" is a subset of the Removed Address List 1359 containing addresses which were formerly considered as symmetric. 1360 This list is initialized as empty. 1362 12.1. Updating the Neighbor Set 1364 On receiving a HELLO message, the node MUST update its Neighbor Set 1365 and populate the Removed Address List and Lost Address List: 1367 1. Find all Neighbor Tuples (hereafter matching Neighbor Tuples) 1368 where: 1370 * N_neighbor_iface_addr_list contains at least one address in 1371 the Neighbor Address List. 1373 2. If there are no matching Neighbor Tuples, then: 1375 1. Create a new Neighbor Tuple with: 1377 + N_neighbor_iface_addr_list = Neighbor Address List; 1379 + N_symmetric = false. 1381 3. If there is one matching Neighbor Tuple, then: 1383 1. If the N_neighbor_iface_addr_list of the matching Neighbor 1384 Tuple is not equal to the Neighbor Address List, then: 1386 1. For each address (henceforth removed address) which is in 1387 the N_neighbor_iface_addr_list, but not in the Neighbor 1388 Address List: 1390 1. Add the removed address to the Removed Address List. 1392 2. If N_symmetric == true, then add the removed address 1393 to the Lost Address List. 1395 2. Update the matching Neighbor Tuple by: 1397 - N_neighbor_iface_addr_list = Neighbor Address List. 1399 4. If there are two or more matching Neighbor Tuples, then: 1401 1. For each address (henceforth removed address) which is in the 1402 N_neighbor_iface_addr_list of any of the matching Neighbor 1403 Tuples: 1405 1. Add the removed address to the Removed Address List. 1407 2. If N_symmetric == true, then add the removed address to 1408 the Lost Address List. 1410 2. Replace the matching Neighbor Tuples by a single Neighbor 1411 Tuple with: 1413 + N_neighbor_iface_addr_list = Neighbor Address List; 1415 + N_symmetric = false 1417 12.2. Updating the Lost Neighbor Set 1419 On receiving a HELLO message, a node MUST update its Lost Neighbor 1420 Set: 1422 1. For each address (henceforth lost address) in the Lost Address 1423 List, if no Lost Neighbor Tuple with NL_neighbor_iface_addr == 1424 lost address exists, then add a Lost Neighbor Tuple with: 1426 * NL_neighbor_iface_addr = lost address; 1428 * NL_time = current time + N_HOLD_TIME. 1430 12.3. Updating the Link Set 1432 On receiving a HELLO message, a node MUST update its Link Set for the 1433 MANET interface on which the HELLO message is received: 1435 1. Remove all addresses in the Removed Address List from the 1436 L_neighbor_iface_addr_list of all Link Tuples. 1438 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 1439 empty; apply Section 13.1, but not Section 13.3. 1441 3. Find all Link Tuples (hereafter matching Link Tuples) where: 1443 * L_neighbor_iface_addr_list contains one or more addresses in 1444 the Sending Address List. 1446 4. If there is more than one matching Link Tuple, then remove them 1447 all; apply Section 13.1, but not Section 13.3. 1449 5. If no matching Link Tuples remain, then create a new matching 1450 Link Tuple with: 1452 * L_neighbor_iface_addr_list = empty; 1454 * L_HEARD_time = EXPIRED; 1456 * L_SYM_time = EXPIRED; 1457 * L_quality = INITIAL_QUALITY; 1459 * L_pending = INITIAL_PENDING; 1461 * L_lost = false; 1463 * L_time = current time + validity time. 1465 6. The matching Link Tuple, existing or new, is then modified as 1466 follows: 1468 1. If the node finds any address (henceforth receiving address) 1469 in the Receiving Address List in an address block in the 1470 HELLO message, then the Link Tuple is modified as follows: 1472 1. If any receiving address in the HELLO message is 1473 associated with a TLV with Type == LINK_STATUS and (Value 1474 == HEARD or Value == SYMMETRIC) then: 1476 - L_SYM_time = current time + validity time. 1478 2. Otherwise if any receiving address in the HELLO message 1479 is associated with a TLV with Type == LINK_STATUS and 1480 Value == LOST then: 1482 1. if L_SYM_time has not expired, then: 1484 1. L_SYM_time = EXPIRED. 1486 2. if L_status == HEARD or SYMMETRIC, then: 1488 * L_time = current time + L_HOLD_TIME. 1490 2. L_neighbor_iface_addr_list = Sending Address List. 1492 3. L_HEARD_time = max(current time + validity time, L_SYM_time). 1494 4. If L_status == PENDING, then: 1496 + L_time = max(L_time, L_HEARD_time). 1498 5. Otherwise if L_status == HEARD or SYMMETRIC, then: 1500 + L_time = max(L_time, L_HEARD_time + L_HOLD_TIME). 1502 12.4. Updating the 2-Hop Set 1504 On receiving a HELLO message a node MUST update its 2-Hop Set for the 1505 MANET interface on which the HELLO message was received: 1507 1. Remove all addresses in the Removed Address List from the 1508 N2_neighbor_iface_addr_list of all 2-Hop Tuples. 1510 2. If the Link Tuple with L_neighbor_iface_addr_list == Sending 1511 Address List has L_status == SYMMETRIC then: 1513 1. For each address (henceforth 2-hop address) in an address 1514 block of the HELLO message, which is not in the Neighbor 1515 Address List, in any I_local_iface_addr_list, or equal to any 1516 IR_local_iface_addr: 1518 1. If the 2-hop address has an associated TLV with: 1520 - Type == LINK_STATUS and Value == SYMMETRIC; OR 1522 - Type == OTHER_NEIGHB and Value == SYMMETRIC, 1524 then, if there is no 2-Hop Tuple such that: 1526 - N2_neighbor_iface_addr_list contains one or more 1527 addresses in the Sending Address List; AND 1529 - N2_2hop_iface_addr == 2-hop address. 1531 then create a 2-Hop Neighbor Tuple with: 1533 - N2_2hop_iface_addr = 2-hop address. 1535 This 2-Hop Tuple (existing or new) is then modified as 1536 follows: 1538 - N2_neighbor_iface_addr_list = Sending Address List; 1540 - N2_time = current time + validity time. 1542 2. Otherwise if the 2-hop address has a TLV with: 1544 - Type == LINK_STATUS and (Value == LOST or Value == 1545 HEARD); OR 1547 - Type == OTHER_NEIGHB and Value == LOST; 1549 then remove all 2-Hop Tuples with: 1551 - N2_neighbor_iface_addr_list contains one or more 1552 addresses in the Sending Address List; AND 1554 - N2_2hop_iface_addr == 2-hop address. 1556 13. Other Information Base Changes 1558 The Interface and Node Information Bases MUST be changed when some 1559 events occur. These events may result from HELLO message processing, 1560 or may be otherwise generated (e.g. expiry of timers or link quality 1561 changes). 1563 Events which cause changes in the Information Bases are: 1565 o A Link Tuple's state changes from symmetric, or the Link Tuple is 1566 removed. 1568 o A Link Tuple's state changes to symmetric. 1570 o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. 1572 o Local interface address changes, as specified in Section 9. 1574 o Link quality changes, as specified in Section 14. 1576 A node MAY report updated information in response to any of these 1577 changes in HELLO message(s), subject to the constraints in 1578 Section 11. 1580 A node which transmits HELLO messages in response to such changes 1581 SHOULD transmit a HELLO message: 1583 o On all MANET interfaces, if the Neighbor Set changes such as to 1584 indicate the change in symmetry of any 1-hop neighbors (including 1585 addition or removal of symmetric 1-hop neighbors). 1587 o Otherwise, on all those MANET interfaces whose Link Set changes 1588 such as to indicate a change in status of any 1-hop neighbors 1589 (including the addition or removal of any 1-hop neighbors, other 1590 than those considered pending). 1592 13.1. Link Tuple Not Symmetric 1594 If for any Link Tuple with L_status == SYMMETRIC: 1596 o L_status changes to any other value; OR 1598 o the Link Tuple is removed; 1600 then: 1602 1. All 2-Hop Tuples for the same MANET interface with: 1604 * N2_neighbor_iface_addr_list contains one or more addresses in 1605 L_neighbor_iface_addr_list; 1607 are removed. 1609 2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1610 L_neighbor_iface_addr_list: 1612 1. If there are no remaining Link Tuples for any MANET interface 1613 with: 1615 + L_neighbor_iface_addr_list contained in 1616 N_neighbor_iface_addr_list; AND 1618 + L_status == SYMMETRIC; 1620 then modify the Neighbor Tuple by: 1622 1. N_symmetric = false. 1624 2. For each address (henceforth neighbor address) in 1625 N_neighbor_iface_addr_list, add a Lost Neighbor Tuple 1626 with: 1628 - NL_neighbor_iface_addr = neighbor address; 1630 - NL_time = current time + N_HOLD_TIME. 1632 13.2. Link Tuple Symmetric 1634 If, for any Link Tuple which does not have L_status == SYMMETRIC: 1636 o L_status changes to SYMMETRIC; 1638 (this includes a newly created Link Tuple which is immediately 1639 updated to have L_status == SYMMETRIC) then: 1641 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list includes 1642 L_neighbor_iface_addr_list, set: 1644 * N_symmetric = true. 1646 2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is 1647 included in that N_neighbor_iface_addr_list. 1649 13.3. Link Tuple Heard Timeout 1651 If, for any Link Tuple: 1653 o L_HEARD_time expires; OR 1655 o the Link Tuple is removed; 1657 then: 1659 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1660 L_neighbor_iface_addr_list, if no Link Tuples for any MANET 1661 interface remain with: 1663 * L_neighbor_iface_addr_list contained in 1664 N_neighbor_iface_addr_list; AND 1666 * L_HEARD_time is not expired; 1668 then remove the Neighbor Tuple. 1670 14. Link Quality 1672 Link quality is a mechanism whereby a node MAY take considerations 1673 other than message exchange into account for determining when a link 1674 is and is not a candidate for being considered as HEARD or SYMMETRIC. 1676 For deployments where no link quality is used, the considerations in 1677 Section 14.1 apply. For deployments were link quality is used, the 1678 general principles of link quality usage are described in 1679 Section 14.2. Section 14.3 and Section 14.4 detail link quality 1680 functioning. 1682 Link quality is used only locally by a node, and nodes may fully 1683 interoperate whether they are using the same, different or no link 1684 quality methods. 1686 14.1. Deployment Without Link Quality 1688 In order for a node to not employ link quality, the node MUST define: 1690 o INITIAL_PENDING = false; 1692 o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define 1693 INITIAL_QUALITY = 1). 1695 14.2. Basic Principles of Link Quality 1697 To enable link quality usage, the L_quality value of a Link Tuple is 1698 used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, 1699 to set the flags L_pending and L_lost of that Link Tuple. Based on 1700 these flags, the link status to advertise for that Link Tuple is 1701 determined as described in Section 7.1. 1703 The use of two thresholds implements link hysteresis, whereby a link 1704 which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either 1705 accepted or rejected (depending on which threshold it has most 1706 recently crossed, or if neither the value of INITIAL_QUALITY). With 1707 appropriate values of these parameters, this prevents over-rapid 1708 changes of link status. 1710 The basic principles of link quality usage are as follows: 1712 o A node does not advertise a neighbor interface in any state until 1713 L_quality is acceptable: 1715 * If INITIAL_PENDING == true, then this is such that L_quality >= 1716 HYST_ACCEPT. 1718 * Otherwise this is such that L_quality >= HYST_REJECT. To 1719 ensure this, a node MUST NOT define INITIAL_PENDING == false 1720 and INITIAL_QUALITY < HYST_REJECT. (A node also MUST NOT 1721 define INITIAL_PENDING == true and INITIAL_QUALITY >= 1722 HYST_ACCEPT.) 1724 * A link which is not yet advertised has L_pending == true. 1726 o Once L_quality >= HYST_ACCEPT, the L_pending flag is set false, 1727 indicating that the link can be advertised. 1729 o A link for which L_pending == false is advertised until its 1730 L_quality drops below HYST_REJECT. 1732 o If a link has L_pending == false and L_quality < HYST_REJECT, the 1733 link is LOST and is advertised as such. This link is not 1734 reconsidered as a candidate HEARD or SYMMETRIC link until 1735 L_quality >= HYST_ACCEPT. 1737 o A link which has an acceptable quality may be advertised as HEARD, 1738 SYMMETRIC or LOST according to the exchange of HELLO messages. 1740 14.3. When Link Quality Changes 1742 If L_quality for a link changes, then the following actions MUST be 1743 taken: 1745 1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1746 modified by: 1748 1. L_pending = false. 1750 2. L_lost = false. 1752 3. If L_status == HEARD or L_status == SYMMETRIC, then: 1754 + L_time = max(L_time, L_HEARD_time + L_HOLD_TIME) 1756 2. If L_status is not equal to PENDING, and L_quality < HYST_REJECT 1757 then the corresponding Link Tuple is modified by: 1759 1. If L_lost == false, then: 1761 + L_lost = true 1763 + L_time = min(L_time, current time + L_HOLD_TIME) 1765 Any appropriate action indicted in Section 13 MUST also be taken. 1767 If L_quality for a link is updated based on HELLO message reception, 1768 or on reception of a packet including a HELLO message, then L_quality 1769 MUST be updated prior to the HELLO message processing described in 1770 Section 12. (If the receipt of the HELLO message, or the packet 1771 containing it, creates the Link Tuple then the Link Tuple MUST be 1772 created with the appropriately updated L_quality value, rather than 1773 with L_quality = INITIAL_QUALITY.) 1775 14.4. Updating Link Quality 1777 A node MAY update link quality based on any information available to 1778 it. Particular cases that MAY be used include: 1780 o Information from the link layer, such as signal to noise ratio or 1781 acknowledgement reception and loss information. 1783 o Receipt or loss of packets. If packets include a packet sequence 1784 number as defined in [packetbb], then packets on a link SHOULD 1785 have sequential packet sequence numbers, whether or not they 1786 include HELLO messages. Link quality can be updated when a packet 1787 is received based on, for example, whether the last N out of M 1788 packets on the link were received, or a "leaky integrator" 1789 tracking packets. 1791 o Receipt or loss of HELLO messages. If the maximum interval 1792 between HELLO messages is known (such as by inclusion of a message 1793 TLV with Type == INTERVAL_TIME, as defined in [timetlv], in HELLO 1794 messages) then the loss of HELLO messages can be determined 1795 without the need to receive a HELLO message. Note that if this 1796 case is combined with the previous case then care must be taken to 1797 avoid "double counting" a lost HELLO message in a lost packet. 1799 15. Proposed Values for Parameters and Constants 1801 This section lists the parameters and constants used in the 1802 specification of the protocol, and proposed values of each which may 1803 be used when a single value of each is used. 1805 15.1. Message Interval Interface Parameters 1807 o HELLO_INTERVAL = 2 seconds 1809 o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 1811 o REFRESH_INTERVAL = HELLO_INTERVAL 1813 15.2. Information Validity Time Interface Parameters 1815 o H_HOLD_TIME = 3 x REFRESH_INTERVAL 1817 o L_HOLD_TIME = H_HOLD_TIME 1819 15.3. Information Validity Time Node Parameters 1821 o N_HOLD_TIME = L_HOLD_TIME 1823 o I_HOLD_TIME = N_HOLD_TIME 1825 15.4. Link Quality Interface Parameters 1827 If link quality is changed, then parameter values will depend on the 1828 link quality process. If link quality is not changed, then: 1830 o HYST_ACCEPT = 1 1832 o HYST_REJECT = 0 1834 o INITIAL_QUALITY = 1 1836 o INITIAL_PENDING = false 1838 15.5. Jitter Interface Parameters 1840 o HP_MAXJITTER = HELLO_INTERVAL/4 1842 o HT_MAXJITTER = HP_MAXJITTER 1844 15.6. Constants 1846 o C = 1/1024 second 1848 16. Security Considerations 1850 The objective of this protocol is to allow each node in the network 1851 to acquire information describing its 1-hop and symmetric 2-hop 1852 neighborhoods. This is acquired through message exchange between 1853 neighboring nodes. The information is made available through the 1854 Interface Information Bases and Node Information Base, describing the 1855 node's 1-hop neighborhood and symmetric 2-hop neighborhood. 1857 Under normal circumstances, the information recorded in these 1858 Information Bases is correct - i.e. corresponds to the actual network 1859 topology, apart from any changes which have not (yet) been tracked by 1860 the HELLO message exchanges. 1862 If some node for some reason, malice or malfunction, injects invalid 1863 HELLO messages, incorrect information may be recorded in the 1864 Information Bases. The protocol specification does, however, prevent 1865 inconsistent information from being injected in the protocol sets 1866 through the constraints in Appendix C. The exact consequence of 1867 information inexactness depends on the use of these Information 1868 Bases, and should be reflected in the specification of protocols 1869 which use information provided by NHDP. 1871 This section, therefore, only outlines the ways in which correctly 1872 formed, but still invalid, HELLO messages may appear. 1874 16.1. Invalid HELLO messages 1876 A correctly formed, but still invalid, HELLO message may take any of 1877 the following forms. Note that a present or absent address in an 1878 address block, does not in and by itself cause a problem. It is the 1879 presence, absence, or incorrectness of associated LOCAL_IF, 1880 LINK_STATUS and OTHER_NEIGHB TLVs that causes problems. 1882 A node may provide false information about its own identity: 1884 * The HELLO message may contain addresses with an associated 1885 LOCAL_IF TLV which do not correspond to addresses of interfaces 1886 of the node transmitting the HELLO message. 1888 * The HELLO message may omit addresses, or their associated 1889 LOCAL_IF TLV, of interfaces of the local node transmitting the 1890 HELLO message (other than the allowed omission of the only 1891 local interface address of the MANET interface over which the 1892 HELLO message is transmitted, if that is the case). 1894 * The HELLO message may incorrectly specify the LOCAL_IF TLV 1895 value associated with one or more local interface addresses, 1896 indicating incorrectly whether they are associated with the 1897 MANET interface over which the HELLO message is transmitted. 1899 A node may provide false information about the identity of other 1900 nodes: 1902 * A present LINK_STATUS TLV may, incorrectly, identify an address 1903 as being of a MANET interface which is or was heard on the 1904 MANET interface over which the HELLO message is transmitted. 1906 * A consistently absent LINK_STATUS TLV may, incorrectly, fail to 1907 identify an address as being of a MANET interface which is or 1908 was heard on the MANET interface over which the HELLO message 1909 is transmitted. 1911 * A present OTHER_NEIGHB TLV may, incorrectly, identify an 1912 address as being of a node which is or was in the sending 1913 node's symmetric 1-hop neighborhood; 1915 * A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail 1916 to identify an address as being of a node which is or was in 1917 the sending node's symmetric 1-hop neighborhood; 1919 * The value of a LINK_STATUS TLV may incorrectly indicate the 1920 status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop 1921 neighbor. 1923 * The value of an OTHER_NEIGHB TLV may incorrectly indicate the 1924 status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor. 1926 17. IANA Considerations 1928 17.1. Message Types 1930 This specification defines one message type, which must be allocated 1931 from the "Assigned Message Types" repository of [packetbb] with 1932 assignment as specified in Table 3. 1934 +-------+------+------------------+ 1935 | Name | Type | Description | 1936 +-------+------+------------------+ 1937 | HELLO | TBD1 | Local signaling. | 1938 +-------+------+------------------+ 1940 Table 3 1942 17.2. TLV Types 1944 This specification defines three address block TLV types, which must 1945 be allocated from the "Assigned Address Block TLV Types" repository 1946 of [packetbb] with assignments as specified in Table 4. 1948 +--------------+------+-----------+---------------------------------+ 1949 | Name | Type | Type | Description | 1950 | | | extension | | 1951 +--------------+------+-----------+---------------------------------+ 1952 | LOCAL_IF | TBD2 | 0 | Specifies that the address is | 1953 | | | | associated with a local | 1954 | | | | interface of the sending node. | 1955 | | | | | 1956 | | | 1-255 | RESERVED | 1957 | | | | | 1958 | LINK_STATUS | TBD3 | 0 | Specifies the status of the | 1959 | | | | link from the indicated address | 1960 | | | | (LOST, SYMMETRIC or HEARD). | 1961 | | | | | 1962 | | | 1-255 | RESERVED | 1963 | | | | | 1964 | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | 1965 | | | | (SYMMETRIC) or recently was | 1966 | | | | (LOST) of an interface of a | 1967 | | | | symmetric 1-hop neighbor of the | 1968 | | | | node transmitting the message. | 1969 | | | | | 1970 | | | 1-255 | RESERVED | 1971 +--------------+------+-----------+---------------------------------+ 1973 Table 4 1975 Type extensions indicated as RESERVED may be allocated by standards 1976 action, as specified in [RFC2434]. 1978 17.3. LINK_STATUS and OTHER_NEIGHB Values 1980 The values which the LOCAL_IF TLV can use are the following: 1982 o UNSPEC_IF = 0 1984 o THIS_IF = 1 1986 o OTHER_IF = 2 1988 The values which the LINK_STATUS TLV can use are the following: 1990 o LOST = 0 1992 o SYMMETRIC = 1 1994 o HEARD = 2 1996 The values which the OTHER_NEIGHB TLV can use are the following: 1998 o LOST = 0 2000 o SYMMETRIC = 1 2002 18. References 2004 18.1. Normative References 2006 [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 2007 "Generalized MANET Packet/Message Format", Work In 2008 Progress draft-ietf-manet-packetbb-12.txt, March 2008. 2010 [manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols", 2011 Work In Progress draft-ietf-manet-iana-07.txt, 2012 November 2007. 2014 [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value 2015 time in MANETs", Work In 2016 Progress draft-ietf-manet-timetlv-04.txt, 2017 November 2007. 2019 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2020 considerations in MANETs", RFC 5148, February 2008. 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2023 Requirement Levels", RFC 2119, BCP 14, March 1997. 2025 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 2026 an IANA Considerations Section in RFCs", RFC 2434, 2027 BCP 26, October 1998. 2029 18.2. Informative References 2031 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 2032 Routing Protocol", RFC 3626, October 2003. 2034 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 2035 (MANET): Routing Protocol Performance Issues and 2036 Evaluation Considerations", RFC 2501, January 1999. 2038 Appendix A. Address Block TLV Combinations 2040 The algorithm for generating HELLO messages in Section 11 specifies 2041 which 1-hop addresses may be included in the address blocks, and with 2042 which associated TLVs. These TLVs may have Type == LINK_STATUS or 2043 Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may 2044 have three possible values (Value == HEARD, Value == SYMMETRIC or 2045 Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two 2046 possible values (Value == SYMMETRIC or Value == LOST). When both 2047 TLVs are associated with the same address only certain combinations 2048 of these TLV values are necessary, and are the only combinations 2049 generated by the algorithm in Section 11. These combinations are 2050 indicated in Table 5. 2052 Cells labeled with "Yes" indicate the possible combinations which are 2053 generated by the algorithm in Section 11. Cells labeled with "No" 2054 indicate combinations not generated by the algorithm in Section 11, 2055 but which are correctly parsed and interpreted by the algorithm in 2056 Section 12. 2058 +----------------+----------------+----------------+----------------+ 2059 | | Type == | Type == | Type == | 2060 | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | 2061 | | (absent) | Value == | Value == LOST | 2062 | | | SYMMETRIC | | 2063 +----------------+----------------+----------------+----------------+ 2064 | Type == | No | Yes | Yes | 2065 | LINK_STATUS | | | | 2066 | (absent) | | | | 2067 | | | | | 2068 | Type == | Yes | Yes | Yes | 2069 | LINK_STATUS, | | | | 2070 | Value == HEARD | | | | 2071 | | | | | 2072 | Type == | Yes | No | No | 2073 | LINK_STATUS, | | | | 2074 | Value == | | | | 2075 | SYMMETRIC | | | | 2076 | | | | | 2077 | Type == | Yes | Yes | No | 2078 | LINK_STATUS, | | | | 2079 | Value == LOST | | | | 2080 +----------------+----------------+----------------+----------------+ 2082 Table 5 2084 Appendix B. HELLO Message Example 2086 An example HELLO message, transmitted by an originator node with a 2087 single MANET interface, is as follows. The message uses IPv4 (four 2088 octet) addresses without specified prefix lengths. The message is 2089 transmitted with a full message header other than version number 2090 (message semantics octet is 30) with a hop limit of 1 and a hop count 2091 of 0. The overall message length is 49 octets. 2093 The message contains a message TLV block with content length 8 octets 2094 containing two message TLVs, of types VALIDITY_TIME and 2095 INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating 2096 that each has a value. Each has a value length of 1 octet; the 2097 values included (0x64 and 0x58) are time codes representing the 2098 default values of parameters H_HOLD_TIME and HELLO_INTERVAL, 2099 respectively (6 seconds and 2 seconds) assuming the default value of 2100 constant C (1/1024 second). 2102 The message has a single address block containing 5 addresses. The 2103 semantics octet value 1 indicates an address head but no address 2104 tail. The head length of 3 octets indicates address mid sections of 2105 one octet each (Mid 0 to Mid 4). 2107 The following TLV block (content length 14 octets) includes two TLVs. 2108 The first is a LOCAL_IF TLV which (with semantics value 10) indicates 2109 that a single address, with index 0 (i.e. Head:Mid 0) is the single 2110 local interface address of this node (the 1 octet value LOCAL_IF 2111 indicates that this address is of this interface). The second is a 2112 LINK_STATUS TLV which (with semantics octet 44) specifies the link 2113 status values of all reported neighbors in a single multivalue TLV 2114 which covers the addresses with indexes 1 to 4. The TLV value length 2115 of 4 octets indicates one octet per value per address. The last four 2116 addresses are first and second HEARD, third SYMMETRIC, and fourth 2117 LOST. 2119 0 1 2 3 2120 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 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | HELLO |0 0 0 1 1 1 1 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1| 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Originator Address | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0| 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 0 1 0 0 0| 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1| 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 |0 0 0 0 0 0 1 1| Head | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | Mid 0 | Mid 1 | Mid 2 | Mid 3 | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 |0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | LINK_STATUS |0 0 1 0 1 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | LOST | 2147 +-+-+-+-+-+-+-+-+ 2149 Note that this example is for illustrative purposes. The essential 2150 information can be conveyed, more efficiently (assuming that the 2151 local interface address will be supplied by IP, and that the 2152 INTERVAL_TIME is not needed) by the 29 octets: 2154 0 1 2 3 2155 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 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | 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| 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0| 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 |0 0 0 0 0 0 1 1| Head | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Mid 1 | Mid 2 | Mid 3 | Mid 4 | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 1 0 1 0 0 0| 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 | LOST | 2172 +-+-+-+-+-+-+-+-+ 2174 Appendix C. Constraints 2176 Any process which updates the Local Information Base or the Node 2177 Information Base MUST ensure that all constraints specified in this 2178 appendix are maintained. 2180 In each Local Interface Tuple: 2182 o I_local_iface_addr_list MUST NOT be empty. 2184 o I_local_iface_addr_list MUST NOT contain any duplicated addresses. 2186 o I_local_iface_addr_list MUST NOT contain any address which is in 2187 the I_local_iface_addr_list of any other Local Interface Tuple. 2189 In each Removed Interface Address Tuple: 2191 o IR_local_iface_addr MUST NOT contain any address which is in the 2192 I_local_iface_addr_list of any Local Interface Tuple. 2194 o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any 2195 other Removed Interface Address Tuple. 2197 In each Link Tuple: 2199 o L_neighbor_iface_addr_list MUST NOT be empty. 2201 o L_neighbor_iface_addr_list MUST NOT contain any address which is 2202 in the I_local_iface_addr_list of any Local Interface Tuple or the 2203 IR_local_iface_addr of any Removed Interface Address Tuple. 2205 o L_neighbor_iface_addr_list MUST NOT contain any duplicated 2206 addresses. 2208 o L_neighbor_iface_addr_list MUST NOT contain any address which is 2209 in the L_neighbor_iface_addr_list of any other Link Tuple in the 2210 same Link Set. 2212 o If L_HEARD_time has not expired then there MUST be a Neighbor 2213 Tuple whose N_neighbor_iface_addr_list contains 2214 L_neighbor_iface_addr_list. 2216 o L_HEARD_time MUST NOT be greater than L_time. 2218 o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are 2219 expired). 2221 o L_quality MUST NOT be less than 0 or greater than 1. 2223 o If L_quality >= HYST_ACCEPT then L_pending MUST be false. 2225 o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST. 2227 o L_pending MUST NOT be set to true if it is currently false. 2229 In each Neighbor Tuple: 2231 o N_neighbor_iface_addr_list MUST NOT contain any address which is 2232 in the I_local_iface_addr_list of any Local Interface Tuple or the 2233 IR_local_iface_addr of any Removed Interface Address Tuple. 2235 o N_neighbor_iface_addr_list MUST NOT contain any duplicated 2236 addresses. 2238 o N_neighbor_iface_addr_list MUST NOT contain any address which is 2239 in the N_neighbor_iface_addr_list of any other Neighbor Tuple. 2241 o If N_symmetric == true, then there MUST be one or more Link Tuples 2242 with: 2244 * L_neighbor_iface_addr_list contained in 2245 N_neighbor_iface_addr_list; AND 2247 * L_status == SYMMETRIC. 2249 o If N_symmetric == false, then there MUST be one or more Link 2250 Tuples with: 2252 * L_neighbor_iface_addr_list contained in 2253 N_neighbor_iface_addr_list. 2255 All such Link Tuples MUST NOT have L_status == SYMMETRIC. At 2256 least one such Link Tuple MUST have L_HEARD_time not expired. 2258 In each Lost Neighbor Tuple: 2260 o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list 2261 of any Local Interface Tuple or the IR_local_iface_addr of any 2262 Removed Interface Address Tuple. 2264 o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr 2265 of any other Lost Neighbor Tuple. 2267 o NL_neighbor_iface_addr MUST NOT be in the 2268 N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric 2269 == true. 2271 In each 2-Hop Tuple: 2273 o There MUST be a Link Tuple associated with the same MANET 2274 interface with: 2276 * L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND 2278 * L_status == SYMMETRIC. 2280 o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of 2281 any Local Interface Tuple or the IR_local_iface_addr of any 2282 Removed Interface Address Tuple. 2284 o N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other 2285 2-Hop Tuple in the same 2-Hop Set and with the same 2286 N2_neighbor_iface_addr_list. 2288 o N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list 2289 of the same 2-Hop Tuple. 2291 Appendix D. Flow and Congestion Control 2293 This protocol specifies one message type, the HELLO message. The 2294 maximum size of a HELLO message is proportional to the size of the 2295 originating node's 1-hop neighborhood. HELLO messages MUST NOT be 2296 forwarded. 2298 A node MUST report its 1-hop neighborhood in HELLO messages on each 2299 of its MANET interfaces at least each REFRESH_INTERVAL. This puts a 2300 lower bound on the control traffic generated by each node in the 2301 network employing this protocol. 2303 A node MUST ensure that two successive HELLO messages sent on the 2304 same MANET interface are separated by at least HELLO_MIN_INTERVAL. 2305 (If using jitter then this may be reduced to a mean minimum value of 2306 HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound 2307 on the control traffic generated by each node in the network 2308 employing this protocol. 2310 Appendix E. Contributors 2312 This specification is the result of the joint efforts of the 2313 following contributors, listed alphabetically. 2315 o Brian Adamson, NRL, USA, 2317 o Cedric Adjih, INRIA, France, 2319 o Thomas Heide Clausen, LIX, France, 2321 o Justin Dean, NRL, USA, 2323 o Christopher Dearlove, BAE Systems, UK, 2324 2326 o Philippe Jacquet, INRIA, France, 2328 Appendix F. Acknowledgements 2330 The authors would like to acknowledge the team behind OLSRv1, 2331 specified in RFC3626 for their contributions. 2333 The authors would like to gratefully acknowledge the following people 2334 for intense technical discussions, early reviews and comments on the 2335 specification and its components: Joe Macker (NRL), Alan Cullen (BAE 2336 Systems), and the entire IETF MANET working group. 2338 Authors' Addresses 2340 Thomas Heide Clausen 2341 LIX, Ecole Polytechnique, France 2343 Phone: +33 6 6058 9349 2344 EMail: T.Clausen@computer.org 2345 URI: http://www.ThomasClausen.org/ 2347 Christopher Dearlove 2348 BAE Systems Advanced Technology Centre 2350 Phone: +44 1245 242194 2351 EMail: chris.dearlove@baesystems.com 2352 URI: http://www.baesystems.com/ 2354 Justin W. Dean 2355 Naval Research Laboratory 2357 Phone: +1 202 767 3397 2358 EMail: jdean@itd.nrl.navy.mil 2359 URI: http://pf.itd.nrl.navy.mil/ 2361 The OLSRv2 Design Team 2362 MANET Working Group 2364 Full Copyright Statement 2366 Copyright (C) The IETF Trust (2008). 2368 This document is subject to the rights, licenses and restrictions 2369 contained in BCP 78, and except as set forth therein, the authors 2370 retain all their rights. 2372 This document and the information contained herein are provided on an 2373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2375 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2376 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2377 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2380 Intellectual Property 2382 The IETF takes no position regarding the validity or scope of any 2383 Intellectual Property Rights or other rights that might be claimed to 2384 pertain to the implementation or use of the technology described in 2385 this document or the extent to which any license under such rights 2386 might or might not be available; nor does it represent that it has 2387 made any independent effort to identify any such rights. Information 2388 on the procedures with respect to rights in RFC documents can be 2389 found in BCP 78 and BCP 79. 2391 Copies of IPR disclosures made to the IETF Secretariat and any 2392 assurances of licenses to be made available, or the result of an 2393 attempt made to obtain a general license or permission for the use of 2394 such proprietary rights by implementers or users of this 2395 specification can be obtained from the IETF on-line IPR repository at 2396 http://www.ietf.org/ipr. 2398 The IETF invites any interested party to bring to its attention any 2399 copyrights, patents or patent applications, or other proprietary 2400 rights that may cover technology that may be required to implement 2401 this standard. Please address the information to the IETF at 2402 ietf-ipr@ietf.org.