idnits 2.17.1 draft-ietf-manet-nhdp-02.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 1962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1986. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 357 has weird spacing: '...dr_list is a ...' == Line 392 has weird spacing: '...ce_addr is th...' == Line 395 has weird spacing: '...dr_list is a ...' == Line 398 has weird spacing: '...YM_time is th...' == Line 401 has weird spacing: '...YM_time is th...' == (15 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2007) is 6273 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) == Outdated reference: A later version (-17) exists of draft-ietf-manet-packetbb-03 Summary: 2 errors (**), 0 flaws (~~), 9 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: August 5, 2007 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 The OLSRv2 Design Team 10 MANET Working Group 11 February 2007 13 MANET Neighborhood Discovery Protocol (NHDP) 14 draft-ietf-manet-nhdp-02 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 August 5, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document describes a 1-hop and symmetric 2-hop neighborhood 48 discovery protocol (NHDP) for mobile ad hoc networks (MANETs). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 56 4.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 7 57 4.2. HELLO message content . . . . . . . . . . . . . . . . . . 8 58 4.3. Node Behavior . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Local Information Base . . . . . . . . . . . . . . . . . . . . 10 60 5.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 10 61 6. Neighborhood Information Base . . . . . . . . . . . . . . . . 11 62 6.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 12 64 6.3. Neighborhood Address Association Set . . . . . . . . . . . 13 65 6.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 13 66 7. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 15 67 7.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 15 68 7.1.1. Local Interface Block . . . . . . . . . . . . . . . . 16 69 7.1.2. Address Block TLVs . . . . . . . . . . . . . . . . . . 16 70 8. Local Information Base Changes . . . . . . . . . . . . . . . . 17 71 8.1. Adding a MANET Interface . . . . . . . . . . . . . . . . . 17 72 8.2. Removing a MANET Interface . . . . . . . . . . . . . . . . 17 73 8.3. Adding an Address to a MANET Interface . . . . . . . . . . 18 74 8.4. Removing an Address from a MANET Interface . . . . . . . . 18 75 8.5. Changing the Principal Address of a MANET Interface . . . 18 76 9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 19 77 9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 20 78 9.1.1. HELLO Message: Jitter . . . . . . . . . . . . . . . . 21 79 10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 22 80 10.1. Populating the Link Set . . . . . . . . . . . . . . . . . 22 81 10.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 23 82 10.3. Populating the Neighborhood Address Association Set . . . 24 83 10.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 25 84 10.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 26 85 11. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 27 86 11.1. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 28 87 12. Proposed Values for Constants . . . . . . . . . . . . . . . . 29 88 12.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 29 89 12.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 29 90 12.3. Hysteresis values . . . . . . . . . . . . . . . . . . . . 29 91 12.4. Jitter Times . . . . . . . . . . . . . . . . . . . . . . . 30 92 12.5. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 94 13.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 31 95 13.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 31 96 13.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 31 97 13.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 32 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 100 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 101 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 34 102 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 35 103 Appendix C. Time TLVs . . . . . . . . . . . . . . . . . . . . . 37 104 C.1. Representing Time . . . . . . . . . . . . . . . . . . . . 37 105 C.2. General Time TLV Structure . . . . . . . . . . . . . . . . 37 106 C.3. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 39 107 C.3.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . 39 108 C.3.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . 39 109 Appendix D. Message Jitter . . . . . . . . . . . . . . . . . . . 40 110 D.1. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 40 111 D.1.1. Periodic message generation . . . . . . . . . . . . . 40 112 D.1.2. Externally triggered message generation . . . . . . . 41 113 D.1.3. Message forwarding . . . . . . . . . . . . . . . . . . 42 114 D.1.4. Maximum Jitter Determination . . . . . . . . . . . . . 43 115 Appendix E. Utilizing Link Layer Information . . . . . . . . . . 44 116 Appendix F. Security Considerations . . . . . . . . . . . . . . 46 117 Appendix F.1. Invalid HELLO messages . . . . . . . . . . . . . . . 46 118 Appendix G. Flow and Congestion Control . . . . . . . . . . . . 48 119 Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 49 120 Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 50 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 122 Intellectual Property and Copyright Statements . . . . . . . . . . 52 124 1. Introduction 126 This document describes a neighborhood discovery protocol (NHDP) for 127 a mobile ad hoc network (MANET). The protocol uses an exchange of 128 HELLO messages in order that each node can determine its 1-hop and 129 symmetric 2-hop neighborhoods. 131 This specification describes both this HELLO message exchange, the 132 messages being defined as instances of the specification [1], and the 133 information storage required for neighborhood discovery. 135 This protocol makes no assumptions about the underlying link layer, 136 other than support of link local multicast. Link layer information 137 and notifications may be used if available and applicable. 139 This protocol is based on the neighborhood discovery process 140 contained in the Optimized Link State Routing Protocol (OLSR) [3]. 142 2. Terminology 144 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC2119 [2]. 148 The terms "packet", "message", "address block", "TLV", and "TLV 149 block" in this document are to be interpreted as described in [1]. 151 Additionally, this document uses the following terminology: 153 Node - A MANET router which implements this neighborhood discovery 154 protocol. 156 MANET interface - A network device participating in a MANET and 157 using this neighborhood discovery protocol. A node may have 158 several MANET interfaces, each being assigned one or more IP 159 addresses. 161 Link - A pair of MANET interfaces from two different nodes, where at 162 least one interface is able to receive traffic from the other. 164 Symmetric link - A link where both MANET interfaces are able to 165 receive traffic from the other. 167 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if node Y 168 can hear node X (i.e. a link exists from a MANET interface on node 169 X to a MANET interface on node Y). 171 Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of 172 a node Y if a symmetric link exists from a MANET interface on node 173 X to a MANET interface on node Y. 175 Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of 176 a node Y if node X is a symmetric 1-hop neighbor of a symmetric 177 1-hop neighbor of node Y, but is not node Y itself. 179 1-hop neighborhood - The 1-hop neighborhood of a node X is the set 180 of the 1-hop neighbors of node X. 182 Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a 183 node X is the set of the symmetric 1-hop neighbors of node X. 185 Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a 186 node X is the set of the symmetric 2-hop neighbors of node X. 187 (This may include nodes in the 1-hop neighborhood, or even in the 188 symmetric 1-hop neighborhood, of node X.) 190 3. Applicability Statement 192 This neighborhood discovery protocol supports nodes which have one or 193 more interfaces participating in the MANET. It provides each node 194 with local topology information up to two hops away. This 195 information is made available to other protocols through a 196 Neighborhood Information Base, described in Section 6. 198 The protocol is designed to work in networks where messages may be 199 lost, such as due to collisions in wireless networks. If relevant 200 link layer information is available then it may be used by this 201 protocol. 203 This protocol to works in a completely distributed manner and does 204 not depend on any central entity. It does not require any changes to 205 the format of IP packets, thus any existing IP stack can be used as 206 is. 208 This protocol uses the packet and message formats specified in [1]. 209 HELLO messages specified by this protocol may be extended using the 210 TLV mechanisms described in [1]. For example, if multipoint relays 211 (MPRs) are to be calculated similarly to as in OLSR [3] and signaled 212 to neighbors, then this information may be added to HELLO messages 213 using an address block TLV. HELLO messages can also be transmitted 214 in packets with messages from other protocols that also use [1]. 216 4. Protocol Overview and Functioning 218 This protocol specifies local (one hop) signaling that: 220 o advertises the presence of a node and its MANET interfaces; 222 o discovers links to adjacent nodes; 224 o performs bidirectionality checks on the discovered links; 226 o advertises discovered links and whether each is symmetric to its 227 1-hop neighbors and hence discover symmetric 2-hop neighbors; 229 o maintains an information base describing discovered links and 230 their status, 1-hop neighbors and their MANET interfaces, 231 symmetric 1-hop neighbors and symmetric 2-hop neighbors. 233 Signaling consists of a single type of message, known as a HELLO 234 message. A HELLO message identifies its originator node and that 235 node's MANET interfaces and addresses. As a node receives HELLO 236 messages and populates its information base, a list of 1-hop 237 neighbors' MANET interface addresses and their link status (lost, 238 symmetric or heard) is included in subsequent HELLO messages. Thus, 239 the periodic transmission allows nodes to continuously track changes 240 in their 1-hop and symmetric 2-hop neighborhoods. If information 241 about link quality is available from the link layer, then this may 242 also be used, see Appendix E. 244 4.1. HELLO Message Generation 246 HELLO messages MAY be sent: 248 o Proactively, at a regular interval, known as HELLO_INTERVAL. 249 HELLO_INTERVAL may be fixed, as suggested in Section 12, or may be 250 dynamic. For example HELLO_INTERVAL may be backed off due to 251 congestion or network stability. Note that if HELLO_INTERVAL is 252 dynamic, it is interpreted as the interval within which the next 253 HELLO message will be sent on the same MANET interface. 255 o As a response to a change in the node itself, or its neighborhood, 256 for example on first becoming active or in response to a new, 257 broken or changed status link. 259 o In a combination of these proactive and responsive mechanisms. 261 Jittering of HELLO message generation and transmission, as described 262 in Section 9.1, MAY be used if appropriate. 264 HELLO messages are sent independently on each MANET interface. 266 4.2. HELLO message content 268 Each HELLO message sent over a MANET interface need not contain all 269 of the information appropriate to that MANET interface, however: 271 o A HELLO message MUST contain all of its own local interface 272 information. 274 o Within every time interval of length REFRESH_INTERVAL, HELLO 275 messages sent over a MANET interface MUST include all of the 276 information appropriate to that interface in at least one HELLO 277 message sent on that interface. This applies to otherwise purely 278 responsive nodes as well as proactive nodes. 280 o A HELLO message MUST include a VALIDITY_TIME message TLV that 281 indicates the length of time for which the message content is to 282 be considered valid and included in the receiving node's 283 Neighborhood Information Base. 285 o A HELLO message SHOULD include an INTERVAL_TIME message TLV that 286 indicates the current value of HELLO_INTERVAL. 288 4.3. Node Behavior 290 A node MUST: 292 o Respect a minimum interval, HELLO_MIN_INTERVAL, between successive 293 HELLO message transmissions over a given interface. If jitter is 294 used then this interval MAY be reduced, but only by a random value 295 not exceeding HP_MAXJITTER. 297 o Ensure that if HELLO_INTERVAL and other parameters are maintained 298 dynamically, changes do not invalidate the guarantees of 299 Section 9.1. 301 o Maintain, based on received HELLO messages, estimates of its 1-hop 302 and symmetric 2-hop neighborhoods as this protocol operates. 303 Formally defined in Section 6, this can be summarized as 304 consisting of the following sets: 306 Link Set - Records the status of all links from and to current 307 and former 1-hop neighbors. 309 Symmetric Neighbor Set - Records the status of current and former 310 symmetric 1-hop neighbors. If any of these nodes have more 311 than one MANET interface then this set may record addresses 312 that are not in the Link Set. 314 Neighborhood Address Association Set - Allows the addresses of 315 the MANET interfaces of each 1-hop neighbor to be associated 316 with each other. 318 2-Hop Neighbor Set - Records the addresses of the MANET 319 interfaces of symmetric 2-hop neighbors. 321 The information in the Link Set and Symmetric Neighbor Set MUST be 322 maintained in order for a node to correctly generate HELLO 323 messages. 325 5. Local Information Base 327 A node maintains a Local Information Base that records information 328 about its MANET interfaces. Each MANET interface MUST have at least 329 one address, and MAY have more than one address. All addresses have 330 an associated prefix length, which is included all addresses in the 331 Local Information Base. If an address otherwise does not have a 332 prefix length it is set equal to the address length. Two addresses 333 are considered equal if and only if their associated prefix lengths 334 are also equal. 336 One of the addresses of each MANET interface is denoted the principal 337 address of that interface. A node MAY choose which address is the 338 principal address in any manner; it SHOULD choose the address so as 339 to minimize changes of principal address. The selection of an 340 address as a principal address only affects how the node organizes 341 its information storage, it has no effect on the messages it creates 342 and sends. 344 The Local Information Base is not modified by this protocol. This 345 protocol may respond to changes of this Local Information Base which 346 MUST reflect corresponding changes in the node's status. 348 5.1. Local Interface Set 350 A node's Local Interface Set records its local MANET interfaces. It 351 consists of Local Interface Tuples, one per MANET interface: 353 (I_local_iface_addr_list) 355 where: 357 I_local_iface_addr_list is a list of the addresses of this MANET 358 interface, with the first of the listed addresses being considered 359 as the principal address of the interface. 361 6. Neighborhood Information Base 363 A node maintains a Neighborhood Information Base that records 364 information about its 1-hop and symmetric 2-hop neighborhoods. The 365 Neighborhood Information Base includes the Link Set, the Symmetric 366 Neighbor Set, the Neighborhood Address Association Set and the 2-Hop 367 Neighbor Set. 369 A node, X, can be present in both the 1-hop and symmetric 2-hop 370 neighborhoods of another node, Y, concurrently. This allows node X 371 to be immediately considered as a symmetric 2-hop neighbor by node Y 372 if the link between them fails. 374 All addresses MUST have an associated prefix length, which is 375 included in all addresses in the Neighborhood Information Base. 376 Prefix lengths are indicated in HELLO messages using the 377 PREFIX_LENGTH TLV specified in [1]; if an address has no such TLV, 378 then its prefix length is equal to the address length. Two addresses 379 are considered equal if and only if their associated prefix lengths 380 are also equal. 382 6.1. Link Set 384 A node's Link Set records its 1-hop neighborhood. It consists of 385 Link Tuples: 387 (L_local_iface_addr, L_neighbor_iface_addr_list, L_SYM_time, 388 L_ASYM_time, L_LOST_time, L_quality, L_pending, L_lost, L_time) 390 where: 392 L_local_iface_addr is the principal address of the local MANET 393 interface on which the 1-hop neighbor is or was heard; 395 L_neighbor_iface_addr_list is a list of the addresses of the MANET 396 interface of the 1-hop neighbor; 398 L_SYM_time is the time until which the link to the 1-hop neighbor is 399 considered symmetric; 401 L_ASYM_time is the time until which the MANET interface of the 1-hop 402 neighbor is considered heard; 404 L_LOST_time is the time until which the MANET interface of the 1-hop 405 neighbor is considered lost; if L_lost is true and L_LOST_time is 406 expired, then this Tuple MUST be removed; 408 L_quality is a dimensionless number between 0 (included) and 1 409 (included) describing the quality of a link; 411 L_pending is a boolean flag, describing if a link is considered 412 pending (i.e. a candidate, but not yet established, link); 414 L_lost is a boolean flag, describing if a link is considered lost 415 due to link quality and hysteresis; 417 L_time specifies when this Tuple expires and MUST be removed. 419 The status of the link as obtained through simple message exchange, 420 denoted H_STATUS, can be derived based on the elements L_SYM_time and 421 L_ASYM_time as defined in Table 1. 423 +-------------+-------------+-----------+ 424 | L_SYM_time | L_ASYM_time | H_STATUS | 425 +-------------+-------------+-----------+ 426 | Expired | Expired | LOST | 427 | | | | 428 | Not Expired | Expired | SYMMETRIC | 429 | | | | 430 | Not Expired | Not Expired | SYMMETRIC | 431 | | | | 432 | Expired | Not Expired | HEARD | 433 +-------------+-------------+-----------+ 435 Table 1 437 The status of the link, taking link quality and hysteresis into 438 account, denoted L_STATUS, is defined by: 440 1. if L_pending is true, then L_STATUS = PENDING; 442 2. otherwise, if L_lost is true, then L_STATUS = LOST; 444 3. otherwise, if L_LOST_time is not expired, then L_STATUS = LOST; 446 4. otherwise, L_STATUS = H_STATUS. 448 6.2. Symmetric Neighbor Set 450 A node's Symmetric Neighbor Set records its symmetric 1-hop 451 neighborhood. It consists of Symmetric Neighbor Tuples: 453 (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time) 455 where: 457 N_local_iface_addr is the principal address of the local MANET 458 interface to which the 1-hop neighbor has or had a symmetric link; 460 N_neighbor_iface_addr is an address of a MANET interface of a 1-hop 461 neighbor which is or was a symmetric 1-hop neighbor of this node; 463 N_SYM_time is the time until which the 1-hop neighbor is considered 464 to be a symmetric 1-hop neighbor; 466 N_time specifies when this Tuple expires and MUST be removed. 468 The status of the 1-hop neighbor, denoted N_STATUS, can be derived 469 based on the field N_SYM_time as defined in Table 2. 471 +-------------+-----------+ 472 | N_SYM_time | N_STATUS | 473 +-------------+-----------+ 474 | Expired | LOST | 475 | | | 476 | Not Expired | SYMMETRIC | 477 +-------------+-----------+ 479 Table 2 481 6.3. Neighborhood Address Association Set 483 A node's Neighborhood Address Association Set records the MANET 484 interface configuration of its 1-hop neighbors. It consists of 485 Neighborhood Address Association Tuples: 487 (NA_neighbor_iface_addr_list, NA_time) 489 where: 491 NA_neighbor_iface_addr_list is a list of interface addresses of a 492 1-hop neighbor; 494 NA_time specifies when this Tuple expires and MUST be removed. 496 6.4. 2-Hop Neighbor Set 498 A node's 2-Hop Neighbor Set records its symmetric 2-hop neighborhood. 499 It consists of 2-Hop Neighbor Tuples: 501 (N2_local_iface_addr, N2_neighbor_iface_addr_list, 502 N2_2hop_iface_addr, N2_time) 504 where: 506 N2_local_iface_addr is the principal address of the local MANET 507 interface on which this information was received; 509 N2_neighbor_iface_addr_list is a list of the addresses of the MANET 510 interface of the 1-hop neighbor from which this information was 511 received; 513 N2_2hop_iface_addr is an address of a MANET interface of a symmetric 514 2-hop neighbor which has a symmetric link (using any MANET 515 interface) to the indicated symmetric 1-hop neighbor; 517 N2_time specifies the time at which this Tuple expires and MUST be 518 removed. 520 7. Packets and Messages 522 The packet and message format used by this neighborhood discovery 523 protocol is defined in [1], which is used with the following 524 considerations: 526 o this protocol specifies one message type, the HELLO message; 528 o HELLO message header options may be used as specified by the 529 protocol which uses this neighborhood discovery protocol; 531 o HELLO messages MUST NOT be forwarded; 533 o HELLO messages may be included in multi-message packets as 534 specified in [1]; 536 o packet header options may be used as specified by the protocol 537 which uses this neighborhood discovery protocol. 539 7.1. HELLO Messages 541 A HELLO message MUST contain: 543 o A VALIDITY_TIME message TLV as specified in Appendix C, 544 representing time value (at distance one hop) H_HOLD_TIME, which 545 MUST NOT be less than REFRESH_INTERVAL. If HELLO messages may be 546 lost then H_HOLD_TIME SHOULD be a multiple of REFRESH_INTERVAL. 548 o An address block, and associated TLV block, known as the Local 549 Interface Block, as specified in Section 7.1.1. 551 A HELLO message which is transmitted at a regular interval SHOULD 552 contain, and otherwise MAY contain: 554 o An INTERVAL_TIME message TLV as specified in Appendix C, 555 representing time value (at distance one hop) HELLO_INTERVAL. 557 A HELLO message MAY contain: 559 o One or more address blocks, with associated address block TLVs, 560 containing current or former 1-hop neighbors' MANET interface 561 addresses. Other addresses (i.e. addresses of non-neighbor nodes) 562 MAY be included in these address blocks, but MUST NOT be 563 associated with any of the TLVs specified in Section 7.1.2. 565 o Other message TLVs. 567 7.1.1. Local Interface Block 569 The first address block, plus following TLV block, in a HELLO message 570 is known as the Local Interface Block. The Local Interface Block is 571 not distinguished in any way other than by being the first address 572 block in the message. 574 The Local Interface Block MUST contain all of the addresses of all of 575 the MANET interfaces of the originating node (i.e. all addresses 576 appearing in an I_local_iface_addr_list). Those addresses, if any, 577 which correspond to MANET interfaces other than that on which the 578 HELLO message is transmitted MUST be associated with a corresponding 579 TLV with Type == OTHER_IF as specified in Section 7.1.2, addresses of 580 the MANET interface on which the HELLO message is transmitted MUST 581 NOT be associated with such a TLV. Other addresses (i.e. not of any 582 MANET interface of this node) which are local to this node only may 583 be included in the Local Interface Block, they MUST be included in 584 HELLO messages transmitted on all MANET interfaces, and MUST always 585 be associated with a TLV with Type == OTHER_IF. 587 Note that a Local Interface Block MAY include more than one address 588 for each MANET interface, and hence a HELLO message MAY contain more 589 than one address without an OTHER_IF TLV. 591 7.1.2. Address Block TLVs 593 The three address block TLVs used in HELLO messages are specified in 594 Table 3. 596 +----------------+------+-------------------+-----------------------+ 597 | Name | Type | Length | Value | 598 +----------------+------+-------------------+-----------------------+ 599 | OTHER_IF | TBD | 0 bits | Not Applicable | 600 | | | | | 601 | LINK_STATUS | TBD | 8 bits | One of LOST, | 602 | | | | SYMMETRIC or HEARD | 603 | | | | | 604 | OTHER_NEIGHB | TBD | 8 bits | One of LOST or | 605 | | | | SYMMETRIC | 606 +----------------+------+-------------------+-----------------------+ 608 Table 3 610 8. Local Information Base Changes 612 The Local Information Base MUST change to respond to changes in the 613 node's MANET interfaces. The protocol MUST update its Neighborhood 614 Information Base in response to such changes, and MAY transmit HELLO 615 messages in response to such changes. 617 8.1. Adding a MANET Interface 619 If a MANET interface is added to the node then this is indicated by 620 the addition of a Local Interface Tuple to the Local Interface Set. 621 The Neighbor Interface Base is not changed. A HELLO message MAY be 622 sent on all MANET interfaces, it SHOULD be sent on the new interface. 623 If using scheduled messages, a message schedule MUST be established 624 on the new interface. 626 8.2. Removing a MANET Interface 628 If a MANET interface is removed from the node, then this MUST result 629 be the removal of information from the Local Information Base and the 630 Neighborhood Information Base as follows: 632 1. Identify the Local Interface Tuple from the Local Interface Set 633 which corresponds to the interface to be removed, and: 635 1. all Link Tuples whose L_local_iface_addr is included in the 636 I_local_iface_addr_list of that Local Interface Tuple MUST be 637 removed; 639 2. all Symmetric Neighbor Tuples whose N_local_iface_addr is 640 included in the I_local_iface_addr_list of that Local 641 Interface Tuple MUST be removed; 643 3. all 2-Hop Neighbor Tuples whose N2_local_iface_addr is 644 included in the I_local_iface_addr_list of the Local 645 Interface Tuple MUST be removed; 647 4. the Local Interface Tuple MUST be removed from the Local 648 Interface Set. 650 2. All Neighborhood Address Association Tuples for which none of the 651 addresses in its NA_neighbor_iface_addr_list may be found in any 652 L_neighbor_iface_addr_list in the Link Set SHOULD be removed. 654 If the removed interface is the last MANET interface of the node, 655 then the Neighborhood Information Base SHOULD be empty, and the node 656 no longer participates in the protocol. 658 A HELLO message MAY be sent on all remaining MANET interfaces. 660 8.3. Adding an Address to a MANET Interface 662 If an address is added to a MANET interface then this is indicated by 663 the addition of an address to the appropriate 664 I_local_iface_addr_list. No change is made to the Neighbor 665 Information Base. A HELLO message MAY be sent on all MANET 666 interfaces. 668 8.4. Removing an Address from a MANET Interface 670 If an address is removed from a MANET interface then this is 671 indicated by the removal of an address to the appropriate 672 I_local_iface_addr_list. No change is made to the Neighbor 673 Information Base unless the removed address is the principal address 674 of the MANET Interface, in which case first a new principal address 675 of the interface is selected, as described in Section 8.5. A HELLO 676 message MAY be sent on all MANET interfaces. 678 8.5. Changing the Principal Address of a MANET Interface 680 If the principal address of a MANET interface of a node is changed 681 then this is indicated by a reordering of the appropriate 682 I_local_iface_addr_list. The following changes MUST be made to the 683 Local Information Base: 685 1. all Link Tuples whose L_local_iface_addr is equal to the old 686 first address in this I_local_iface_addr_list have that 687 L_local_iface_addr set equal to the new first address in this 688 I_local_iface_addr_list; 690 2. all Symmetric Neighbor Tuples whose N_local_iface_addr is equal 691 to the old first address in this I_local_iface_addr_list have 692 that N_local_iface_addr set equal to the new first address in 693 this I_local_iface_addr_list; 695 3. all 2-Hop Neighbor Tuples whose N2_local_iface_addr is equal to 696 the old first address in this I_local_iface_addr_list have that 697 N2_local_iface_addr set equal to the new first address in this 698 I_local_iface_addr_list. 700 A HELLO message SHOULD NOT be sent in response to this change. 702 9. HELLO Message Generation 704 HELLO messages MUST be generated and transmitted independently on 705 each MANET interface. If using the HELLO message interval 706 HELLO_INTERVAL then, following a HELLO message transmission on a 707 MANET interface, another HELLO message MUST be sent on the same 708 interface after an interval not greater than HELLO_INTERVAL. Two 709 successive HELLO message transmissions on the same MANET interface 710 MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in 711 Section 9.1.1. 713 A HELLO message MUST include a Local Interface Block as specified in 714 Section 7.1.1 as its first address block. 716 Other addresses which MUST be included in HELLO messages are: 718 o addresses of 1-hop neighbors from the Link Set; 720 o addresses of 1-hop neighbors from the Symmetric Neighbor Set. 722 These addresses MUST NOT be included in the Local Interface Block. 723 These addresses MAY be included in any HELLO messages sent on the 724 appropriate MANET interface. These addresses, and their associated 725 TLVs, are: 727 1. For each address which appears in an L_neighbor_iface_addr_list 728 (a neighbor address) in one or more Link Tuples whose 729 L_local_iface_addr is the principal address of the MANET 730 interface over which the HELLO message is to be sent (i.e. the 731 first address listed in the corresponding 732 I_local_iface_addr_list), and whose L_STATUS does not equal 733 PENDING, include the neighbor address with an associated TLV 734 with: 736 * Type = LINK_STATUS; AND 738 * Value = L_STATUS. 740 2. For each address which appears as an N_neighbor_iface_addr in one 741 or more Symmetric Neighbor Tuples: 743 1. if this address has already been included with an associated 744 TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not 745 add an associated TLV with Type == OTHER_NEIGHB; 747 2. otherwise if, for one or more of these Symmetric Neighbor 748 Tuples, N_STATUS == SYMMETRIC, then include this 749 N_neighbor_iface_addr with an associated TLV with: 751 + Type = OTHER_NEIGHB; AND 753 + Value = SYMMETRIC. 755 3. otherwise if, for all of these Symmetric Neighbor Tuples, 756 N_STATUS == LOST, and this address has not already been 757 included with an associated TLV with Type == LINK_STATUS and 758 Value == LOST, then include this N_neighbor_iface_addr with 759 an associated TLV with: 761 + Type = OTHER_NEIGHB; AND 763 + Value = LOST. 765 On each of its MANET interfaces, for each specified 1-hop neighbor 766 address and associated TLV, the address and associated TLV MUST be 767 included in at least one HELLO message in every interval of length 768 REFRESH_INTERVAL. 770 If an address is specified with more than one associated TLV, then 771 these TLVs MAY be independently included or excluded from each HELLO 772 messages as long as each such TLV is included associated with that 773 address in a HELLO message sent on that MANET interface in every 774 interval of length REFRESH_INTERVAL. 776 TLVs associated with the same address included in the same HELLO 777 message MAY be applied to the same or different copies of that 778 address. 780 9.1. HELLO Message: Transmission 782 Messages are transmitted in the packet/message format specified by 783 [1] using the ALL-MANET-NEIGHBORS multicast address as destination IP 784 address, and with the HELLO message hop limit = 1. 786 If the parameters of the protocol are changed, then guarantees given 787 for the old values of the parameters MUST still be respected. In 788 particular: 790 o If HELLO_INTERVAL is increased, then a HELLO message MUST be sent 791 within the old HELLO_INTERVAL of the previous HELLO message sent 792 on each MANET interface. 794 o If REFRESH_INTERVAL is increased, then all information (addresses 795 and associated TLVs) must be sent again on each MANET interface 796 within the old REFRESH_INTERVAL of the previous HELLO message that 797 included that information. 799 9.1.1. HELLO Message: Jitter 801 HELLO messages MAY be sent using periodic message generation or 802 externally triggered message generation. If using data link and 803 physical layers which are subject to packet loss due to collisions, 804 HELLO messages SHOULD be jittered as described in Appendix D. 806 Internally triggered message generation MAY be treated as if 807 externally generated message generation, or MAY be not jittered. 809 HELLO messages MUST NOT be forwarded, and thus message forwarding 810 jitter does not apply to HELLO messages. 812 Each form of jitter described in Appendix D requires a parameter 813 MAXJITTER. These parameters may be dynamic, and are specified by: 815 o For periodic message generation: HP_MAXJITTER, which MUST be 816 significantly less than HELLO_INTERVAL. 818 o For externally triggered message generation: HT_MAXJITTER. If 819 HELLO messages are also periodically generated then HT_MAXJITTER 820 also MUST be significantly less than HELLO_INTERVAL. 822 When HELLO message generation is delayed in order that a HELLO 823 message is not sent within HELLO_MIN_INTERVAL of the previous HELLO 824 message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD 825 be reduced by jitter, with maximum reduction HP_MAXJITTER. In this 826 case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. 828 10. HELLO Message Processing 830 On receiving a HELLO message, a node MUST update its neighborhood 831 information base. 833 For the purpose of this section, note the following definitions: 835 o the "validity time" of a message is calculated from the 836 VALIDITY_TIME TLV of the HELLO message as specified in Appendix C; 838 o the "Receiving Address List" is the I_local_iface_addr_list 839 corresponding to the MANET interface on which the HELLO message 840 was received; 842 o the "Receiving Address" is the first address in the Receiving 843 Address List, i.e. is the principal address of the MANET interface 844 on which the HELLO message was received; 846 o the "Sending Address List" is the list of the addresses contained 847 in the Local Interface Block of the HELLO message which do not 848 have an associated TLV with Type == OTHER_IF; 850 o the word EXPIRED indicates that a timer is set to a value clearly 851 preceding the current time (e.g. current time - 1). 853 10.1. Populating the Link Set 855 On receiving a HELLO message, a node SHOULD update its Link Set: 857 1. If there is no Link Tuple such that: 859 * L_local_iface_addr == Receiving Address; AND 861 * L_neighbor_iface_addr_list contains one or more addresses in 862 the Sending Address List. 864 then create a new Link Tuple with: 866 * L_local_iface_addr = Receiving Address; 868 * L_SYM_time = EXPIRED; 870 * L_quality = INITIAL_QUALITY; 872 * L_pending = INITIAL_PENDING; 874 * L_lost = false; 875 * L_LOST_time = EXPIRED; 877 * L_time = current time + validity time. 879 2. This Link Tuple (existing or new) is then modified as follows: 881 1. If the node finds any address in the Receiving Address List 882 in one of the address blocks included in the HELLO message, 883 other than the Local Interface Block, then the Link Tuple is 884 modified as follows: 886 1. If any such address in the HELLO message is associated 887 with a TLV with Type == LINK_STATUS and (Value == HEARD 888 or Value == SYMMETRIC) then: 890 - L_SYM_time = current time + validity time; 892 - L_time = L_SYM_time + L_HOLD_TIME. 894 2. Otherwise if any such address in the HELLO message is 895 associated with a TLV with Type == LINK_STATUS and Value 896 == LOST then: 898 1. if L_STATUS == SYMMETRIC: 900 o L_time = current time + max(validity time, 901 L_HOLD_TIME), 903 o L_SYM_time = EXPIRED. 905 2. L_neighbor_iface_addr_list = Sending Address List; 907 3. L_ASYM_time = current time + validity time; 909 4. L_time = max(L_time, L_ASYM_time). 911 10.2. Populating the Symmetric Neighbor Set 913 On receiving a HELLO message, a node SHOULD update its Symmetric 914 Neighbor Set: 916 1. If any address in the Receiving Address List is in an address 917 block of the HELLO message, other than the Local Interface Block, 918 with an associated TLV with Type == LINK_STATUS and (Value == 919 HEARD or Value == SYMMETRIC) then: 921 1. For each address (henceforth neighbor address) in the HELLO 922 message's Local Interface Block where a corresponding link 923 tuple with L_STATUS == SYMMETRIC exists in the link set: 925 1. If there is no Symmetric Neighbor Tuple such that: 927 - N_local_iface_addr == Receiving Address; AND 929 - N_neighbor_iface_addr == neighbor address, 931 then create a new Symmetric Neighbor Tuple with: 933 - N_local_iface_addr = Receiving Address; 935 - N_neighbor_iface_addr = neighbor address; 937 2. This Symmetric Neighbor Tuple (existing or new) is then 938 modified as follows: 940 - N_SYM_time = current time + validity time; 942 - N_time = N_SYM_time + N_HOLD_TIME. 944 2. Otherwise if any address in the Receiving Address List is in an 945 address block of the HELLO message, other than the Local 946 Interface Block, with an associated TLV with Type == LINK_STATUS 947 and Value == LOST, then: 949 1. For each address (henceforth neighbor address) in the HELLO 950 message Local Interface Block, if there exists a Symmetric 951 Neighbor Tuple with: 953 + N_local_iface_addr == Receiving Address; AND 955 + N_neighbor_iface_addr == neighbor address, 957 then update this Symmetric Neighbor Tuple to have: 959 + N_SYM_time = EXPIRED; 961 + N_time = min(N_time, current time + N_HOLD_TIME). 963 10.3. Populating the Neighborhood Address Association Set 965 On receiving a HELLO message, the node SHOULD update its Neighborhood 966 Address Association Set: 968 1. Remove all Neighborhood Address Association Tuples where: 970 * NA_neighbor_iface_addr_list contains at least one address 971 which is contained in the Local Interface Block of the 972 received HELLO message, 974 and create a new Neighborhood Address Association Tuple with: 976 * NA_neighbor_iface_addr_list = list of all addresses contained 977 in the Local Interface Block of the received HELLO message; 979 * NA_time = current time + validity time. 981 10.4. Populating the 2-Hop Neighbor Set 983 On receiving a HELLO message the node SHOULD update its 2-Hop 984 Neighbor Set: 986 1. If there exists a Link Tuple with L_local_iface_addr == Source 987 Address and for which L_STATUS == SYMMETRIC then: 989 1. For each address (henceforth 2-hop neighbor address) in an 990 address block of the HELLO message, other than the Local 991 Interface Block, which is not in any I_local_iface_addr_list 992 (i.e. is not an address of a MANET interface of the receiving 993 node): 995 1. If the 2-hop neighbor address has an associated TLV with: 997 - Type == LINK_STATUS and Value == SYMMETRIC; OR 999 - Type == OTHER_NEIGHB and Value == SYMMETRIC, 1001 then, if there is no 2-Hop Neighbor Tuple such that: 1003 - N2_local_iface_addr == Receiving Address; 1005 - N2_neighbor_iface_addr_list contains one or more 1006 addresses in the Sending Address List; AND 1008 - N2_2hop_iface_addr == 2-hop neighbor address. 1010 then create a 2-Hop Neighbor Tuple with: 1012 - N2_local_iface_addr = Receiving Address; 1014 - N2_2hop_iface_addr = 2-hop neighbor address. 1016 This 2-Hop Neighbor Tuple (existing or new) is then 1017 modified as follows: 1019 - N2_neighbor_iface_addr_list = Sending Address List; 1021 - N2_time = current time + validity time. 1023 2. Otherwise if the 2-hop neighbor address has a TLV with: 1025 - Type == LINK_STATUS and (Value == LOST or Value == 1026 HEARD); OR 1028 - Type == OTHER_NEIGHB and Value == LOST; 1030 then remove all 2-Hop Neighbor Tuples with: 1032 - N2_local_iface_addr == Receiving Address; AND 1034 - N2_neighbor_iface_addr_list contains one or more 1035 addresses in the Sending Address List; AND 1037 - N2_2hop_iface_addr == 2-hop neighbor address. 1039 10.5. Neighborhood Changes 1041 If L_STATUS of a Link Tuple changes from SYMMETRIC to any other 1042 status, due to any of: 1044 o L_SYM_time expires; 1046 o L_SYM_time is set to EXPIRED as result of processing a TLV with 1047 Type == LINK_STATUS and Value == LOST; 1049 o A change in L_quality resulting in L_quality < HYST_REJECT 1051 then all 2-Hop Neighbor Tuples with: 1053 o N2_local_iface_addr == L_local_iface_addr from the Link Tuple, 1054 AND; 1056 o N2_neighbor_iface_addr_list contains one or more addresses in the 1057 L_neighbor_iface_addr_list from the Link Tuple, 1059 MUST be deleted. 1061 In this, or any other case of neighborhood change, a node MAY send a 1062 HELLO message reporting updated information, subject to the 1063 constraints in Section 9. 1065 11. Link Hysteresis 1067 Link hysteresis allows associating a L_quality value with a link. 1068 Using this L_quality in conjunction with two thresholds, HYST_ACCEPT 1069 and HYST_REJECT, as well as for each link a L_pending and a L_lost 1070 flag, Section 6.1 allows determining the L_STATUS of a link. 1072 The basic principles of link hysteresis are as follows: 1074 o A node does not advertise a neighbor interface in any state until 1075 L_quality is acceptable. If INITIAL_PENDING == true, this is such 1076 that L_quality >= HYST_ACCEPT, otherwise this is such that 1077 L_quality >= HYST_REJECT; to ensure the latter a node MUST NOT 1078 define INITIAL_PENDING == false and INITIAL_QUALITY < HYST_REJECT. 1079 (A node also MUST NOT define INITIAL_PENDING == true and 1080 INITIAL_QUALITY >= HYST_ACCEPT.) A link which is not yet 1081 advertised has L_pending == true. 1083 o Once L_quality >= HYST_ACCEPT, the L_pending flag is set false, 1084 indicating that the link can be advertised. 1086 o A link for which L_pending == false is advertised until its 1087 L_quality drops below HYST_REJECT. 1089 o If a link has L_pending == false and L_quality < HYST_REJECT, the 1090 link is LOST and is advertised as such. This link is not 1091 reconsidered as a candidate HEARD or SYMMETRIC link until 1092 L_quality >= HYST_ACCEPT. 1094 o A link which has an acceptable quality may be advertised as HEARD, 1095 SYMMETRIC or LOST according to the exchange of HELLO messages. 1097 If L_quality for a link changes, the following actions MUST be taken: 1099 1. if L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1100 modified by: 1102 * L_pending = false; 1104 * L_lost = false; 1106 * L_LOST_time = EXPIRED. 1108 2. if L_quality < HYST_REJECT then the corresponding Link Tuple is 1109 modified by: 1111 * L_lost = true 1112 * L_LOST_time = current time + L_HOLD_TIME 1114 Any corresponding Tuples in the Symmetric Neighbor Set and 2-Hop 1115 Neighbor Set MUST be removed. 1117 If L_quality for a link is updated based on HELLO message reception, 1118 or on reception of a packet including a HELLO message, then L_quality 1119 MUST be updated prior to the HELLO processing described in 1120 Section 10. (If the receipt of the HELLO message, or the packet 1121 containing it, creates the Link Tuple then instead the Link Tuple 1122 MUST be created with the updated L_quality value.) 1124 11.1. Link Quality 1126 A node MAY never update link quality (L_quality). In this case the 1127 node MUST define: 1129 o INITIAL_PENDING = false; 1131 o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define 1132 INITIAL_QUALITY = 1). 1134 A node MAY update link quality based on any information available to 1135 it. Particular cases that MAY be used include: 1137 o Link layer information, see Appendix E. 1139 o Receipt or loss of packets. Provided packets include a packet 1140 sequence number as defined in [1], packets on a link SHOULD have 1141 sequential packet sequence numbers, whether or not they include 1142 HELLO messages. Link quality can be updated when a packet is 1143 received based on, for example, whether the last N out of M 1144 packets on the link were received, or a "leaky integrator" 1145 tracking packets. 1147 o Receipt or loss of HELLO messages. If the maximum interval 1148 between HELLO messages is known (possibly by inclusion of a 1149 message TLV with Type == INTERVAL_TIME as defined in Appendix C.2 1150 in HELLO messages) then the loss of HELLO messages can be 1151 determined without the need to receive a HELLO message. Note that 1152 if this case is combined with the previous case then care must be 1153 taken to avoid "double counting" a lost HELLO message in a lost 1154 packet. 1156 12. Proposed Values for Constants 1158 This section lists proposed values for the constants used in the 1159 specification of the protocol. 1161 12.1. Message Intervals 1163 o HELLO_INTERVAL = 2 seconds 1165 o REFRESH_INTERVAL = HELLO_INTERVAL 1167 o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 1169 12.2. Holding Times 1171 o H_HOLD_TIME = 3 x REFRESH_INTERVAL 1173 o L_HOLD_TIME = H_HOLD_TIME 1175 o N_HOLD_TIME = H_HOLD_TIME 1177 12.3. Hysteresis values 1179 If link quality is not changed then: 1181 o HYST_ACCEPT = 1 1183 o HYST_REJECT = 0 1185 o INITIAL_QUALITY = 1 1187 o INITIAL_PENDING = false 1189 Otherwise, i.e. if link quality is changed, then these parameters 1190 will be dependent on the link quality process used. Example possible 1191 parameters are: 1193 o HYST_ACCEPT = 0.75 1195 o HYST_REJECT = 0.25 1197 o INITIAL_QUALITY = 0.5 1199 o INITIAL_PENDING = true 1201 12.4. Jitter Times 1203 o HP_MAXJITTER = HELLO_INTERVAL/4 1205 o HT_MAXJITTER = HELLO_INTERVAL/4 1207 12.5. Time 1209 o C = 0.0625 second (1/16 second) 1211 In order to achieve interoperability, C MUST be the same on all 1212 nodes. 1214 13. IANA Considerations 1216 13.1. Multicast Addresses 1218 A well-known link-local multicast address, ALL-MANET-NEIGHBORS, must 1219 be registered and defined for both IPv6 and IPv4. 1221 13.2. Message Types 1223 This specification defines one message type, which must be allocated 1224 from the "Assigned Message Types" repository of [1]. 1226 +--------------------+-------+--------------------------------------+ 1227 | Mnemonic | Value | Description | 1228 +--------------------+-------+--------------------------------------+ 1229 | HELLO | TBD | Local signaling | 1230 +--------------------+-------+--------------------------------------+ 1232 Table 4 1234 13.3. TLV Types 1236 This specification defines two Message TLV types, which must be 1237 allocated from the "Assigned Message TLV Types" repository of [1]. 1239 +--------------------+-------+--------------------------------------+ 1240 | Mnemonic | Value | Description | 1241 +--------------------+-------+--------------------------------------+ 1242 | VALIDITY_TIME | TBD | The time (in seconds) from receipt | 1243 | | | of the message during which the | 1244 | | | information contained in the message | 1245 | | | is to be considered valid | 1246 | | | | 1247 | INTERVAL_TIME | TBD | The maximum time (in seconds) | 1248 | | | between two successive transmissions | 1249 | | | of messages of the appropriate type | 1250 +--------------------+-------+--------------------------------------+ 1252 Table 5 1254 This specification defines three Address Block TLV types, which must 1255 be allocated from the "Assigned Address Block TLV Types" repository 1256 of [1]. 1258 +--------------------+-------+--------------------------------------+ 1259 | Mnemonic | Value | Description | 1260 +--------------------+-------+--------------------------------------+ 1261 | OTHER_IF | TBD | Specifies that the address, in the | 1262 | | | Local Interface Block of the | 1263 | | | message, is an address associated | 1264 | | | with a MANET interface other than | 1265 | | | the one on which the message is | 1266 | | | transmitted | 1267 | | | | 1268 | LINK_STATUS | TBD | Specifies the status of the link to | 1269 | | | the indicated address (LOST, | 1270 | | | SYMMETRIC or HEARD) | 1271 | | | | 1272 | OTHER_NEIGHB | TBD | Specifies that the address is | 1273 | | | (SYMMETRIC) or was (LOST) of a MANET | 1274 | | | interface of a symmetric 1-hop | 1275 | | | neighbor of the node transmitting | 1276 | | | the HELLO message, but does not have | 1277 | | | a matching or better LINK_STATUS TLV | 1278 +--------------------+-------+--------------------------------------+ 1280 Table 6 1282 13.4. LINK_STATUS and OTHER_NEIGHB Values 1284 The values which the LINK_STATUS TLV can use are the following: 1286 o LOST = 0 1288 o SYMMETRIC = 1 1290 o HEARD = 2 1292 The values which the OTHER_NEIGHB TLV can use are the following: 1294 o LOST = 0 1296 o SYMMETRIC = 1 1298 14. References 1300 14.1. Normative References 1302 [1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized 1303 MANET Packet/Message Format", Work In 1304 Progress draft-ietf-manet-packetbb-03.txt, January 2007. 1306 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1307 Levels", RFC 2119, BCP 14, March 1997. 1309 14.2. Informative References 1311 [3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 1312 Protocol", RFC 3626, October 2003. 1314 Appendix A. Address Block TLV Combinations 1316 The algorithm for generating HELLO messages in Section 9 specifies 1317 which addresses MAY be included in the address blocks after the Local 1318 Interface Block, and with which associated TLVs. These TLVs may have 1319 Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type 1320 == LINK_STATUS may have three possible values (Value == HEARD, Value 1321 == SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may 1322 have two possible values (Value == SYMMETRIC or Value == LOST). When 1323 both TLVs are associated with the same address only certain 1324 combinations of these TLV values are necessary, and are the only 1325 combinations generated by the algorithm in Section 9. These 1326 combinations are indicated in Table 7. 1328 Cells labeled with "Yes" indicate the possible combinations which are 1329 generated by the algorithm in Section 9. Cells labeled with "No" 1330 indicate combinations not generated by the algorithm in Section 9, 1331 but which are correctly parsed and interpreted by the algorithm in 1332 Section 10. 1334 +----------------+----------------+----------------+----------------+ 1335 | | Type == | Type == | Type == | 1336 | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | 1337 | | (absent) | Value == | Value == LOST | 1338 | | | SYMMETRIC | | 1339 +----------------+----------------+----------------+----------------+ 1340 | Type == | No | Yes | Yes | 1341 | LINK_STATUS | | | | 1342 | (absent) | | | | 1343 | | | | | 1344 | Type == | Yes | Yes | Yes | 1345 | LINK_STATUS, | | | | 1346 | Value == HEARD | | | | 1347 | | | | | 1348 | Type == | Yes | No | No | 1349 | LINK_STATUS, | | | | 1350 | Value == | | | | 1351 | SYMMETRIC | | | | 1352 | | | | | 1353 | Type == | Yes | Yes | No | 1354 | LINK_STATUS, | | | | 1355 | Value == LOST | | | | 1356 +----------------+----------------+----------------+----------------+ 1358 Table 7 1360 Appendix B. HELLO Message Example 1362 An example HELLO message, sent by an originator node with a single 1363 MANET interface, is as follows. The message uses IPv4 (four octet) 1364 addresses without prefix TLVs. The message is sent with a full 1365 message header (message semantics octet is 0) with a hop limit of 1 1366 and a hop count of 0. The overall message length is 50 octets. 1368 The message contains a message TLV block with content length 8 octets 1369 containing two message TLVs, of types VALIDITY_TIME and 1370 INTERVAL_TIME. Each uses a TLV with semantics value 4, indicating 1371 that no start and stop indexes are included, and each has a value 1372 length of 1 octet. The values included (0x68 and 0x50) are time 1373 codes representing the default values of parameters H_HOLD_TIME and 1374 HELLO_INTERVAL, respectively (6 seconds and 2 seconds). 1376 The first address block contains 1 local interface address. The 1377 semantics octet value 2 indicates no address tail, and the head 1378 length of 4 octets indicates no address mid sections. This address 1379 block has no TLVs (TLV block content length 0 octets). 1381 The second, and last, address block contains 4 neighbor interface 1382 addresses. The semantics octet value 2 indicates no address tail, 1383 the head length of 3 octets indicates address mid sections of one 1384 octet each. The following TLV block (content length 7 octets) 1385 includes one LINK_STATUS TLV which reports the link status values of 1386 all reported neighbors in a single multivalue TLV: the first two 1387 addresses are HEARD, the third address is SYMMETRIC and the fourth 1388 address is LOST. The TLV semantics value of 20 indicates, in 1389 addition to that this is a multivalue TLV, that no start and stop 1390 indexes are included, since values for all addresses are included. 1391 The TLV value length of 4 octets indicates one octet per value per 1392 address. 1394 0 1 2 3 1395 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 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0| 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Originator Address | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 0 1 0 0| 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0| 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 |0 0 0 0 0 1 0 0| Head | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Head (cont) |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Head (cont) | Mid | Mid | Mid | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 |0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | SYMMETRIC | LOST | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Appendix C. Time TLVs 1426 This appendix specifies a general time TLV structure for expressing 1427 either single time values or a set of time values with each value 1428 associated with a range of distances. Furthermore, using this 1429 general time TLV structure, this document specifies the INTERVAL_TIME 1430 and VALIDITY_TIME TLVs, which are used by NHDP. 1432 C.1. Representing Time 1434 This document specifies a TLV structure in which time values are each 1435 represented in an 8 bit time code, one or more of which may be used 1436 in a TLV's value field. Of these 8 bits, the least significant four 1437 bits represent the mantissa (a), and the most significant four bits 1438 represent the exponent (b), so that: 1440 o time value = (1 + a/16) * 2^b * C 1442 o time code = 16 * b + a 1444 All nodes in the network MUST use the same value of C, which will be 1445 specified in seconds, hence so will be all time values. Note that 1446 ascending values of the time code represent ascending time values, 1447 time values may thus be compared by comparison of time codes. 1449 An algorithm for computing the time code representing the smallest 1450 representable time value not less than the time value t is: 1452 1. find the largest integer b such that t/C >= 2^b; 1454 2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest 1455 integer; 1457 3. if a == 16 then set b = b + 1 and set a = 0; 1459 4. if a and b are in the range 0 and 15 then the required time value 1460 can be represented by the time code 16 * b + a, otherwise it can 1461 not. 1463 The minimum time value that can be represented in this manner is C. 1464 The maximum time value that can be represented in this manner is 1465 63488 * C. 1467 C.2. General Time TLV Structure 1469 A Time TLV may be a packet, message or address block TLV. If it is a 1470 packet or message TLV then it must be a single value TLV as defined 1471 in [1]; if it is an address block TLV then it may be single value or 1472 multivalue TLV. The specific Time TLVs specified in this document, 1473 in Appendix C.3 are message, and hence single value, TLVs. Note that 1474 even a single value Time TLV may contain a multiple octet 1475 field. 1477 The purpose of a single value Time TLV is to allow a single time 1478 value to be determined by a node receiving an entity containing the 1479 Time TLV, based on its distance from the entity's originator. The 1480 Time TLV may contain information that allows that time value to be a 1481 function of distance, and thus different receiving nodes may 1482 determine different time values. If a receiving node will not be 1483 able to determine its distance from the originating node, then the 1484 form of this Time TLV with a single time code in a field (or 1485 single value subfield) SHOULD be used. 1487 The field of a single value Time TLV is specified, using the 1488 regular expression syntax of [1], by: 1490 = {