idnits 2.17.1 draft-ietf-manet-nhdp-00.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 on line 1429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1419. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (June 19, 2006) is 6513 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-01 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-02 -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '5') (Obsoleted by RFC 4291) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Expires: December 21, 2006 C. Dearlove 5 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 The OLSRv2 Design Team 10 MANET Working Group 11 June 19, 2006 13 MANET Neighborhood Discovery Protocol (NHDP) 14 draft-ietf-manet-nhdp-00 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 December 21, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document describes a neighborhood discovery protocol (NHDP) for 48 a mobile ad hoc network (MANET). The protocol provides each MANET 49 node with local topology up to two hops distant, describing a node's 50 1-hop neighbors and symmetric 2-hop neighbors. This is achieved 51 through periodic message exchange. This neighborhood discovery 52 protocol may be used by any MANET protocols which need neighborhood 53 information. 55 The protocol imposes minimum requirements to the network by not 56 requiring sequenced or reliable transmission of control traffic. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5 63 2. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 64 3. Neighborhood Information Base . . . . . . . . . . . . . . . . 9 65 3.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 10 67 3.3. Neighborhood Address Association Set . . . . . . . . . . . 11 68 3.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 11 69 4. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13 71 4.1.1. Local Interface Block . . . . . . . . . . . . . . . . 14 72 4.1.2. Message TLVs . . . . . . . . . . . . . . . . . . . . . 14 73 4.1.3. Address Block TLVs . . . . . . . . . . . . . . . . . . 16 74 5. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 17 75 5.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 18 76 6. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 19 77 6.1. Populating the Link Set . . . . . . . . . . . . . . . . . 19 78 6.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 20 79 6.3. Populating the Neighborhood Address Association Set . . . 21 80 6.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 22 81 6.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 23 82 7. Proposed Values for Constants . . . . . . . . . . . . . . . . 24 83 7.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 24 84 7.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 24 85 7.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 8.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 25 88 8.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 25 89 8.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 25 90 8.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 26 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 94 Appendix A. Heuristics for Generating HELLO Messages . . . . . . 28 95 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 31 96 Appendix C. Security Considerations . . . . . . . . . . . . . . . 33 97 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 35 98 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 36 99 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 101 Intellectual Property and Copyright Statements . . . . . . . . . . 39 103 1. Introduction 105 This document describes a neighborhood discovery protocol (NHDP) for 106 a mobile ad hoc network (MANET). It was originally developed for the 107 Optimized Link State Routing Protocol version 2 (OLSRv2) [3], based 108 on that used in the Optimized Link State Routing Protocol version 1 109 [4]. It uses an exchange of HELLO messages in order that each node 110 can determine its neighborhood up to two hops distant. This protocol 111 is used by OLSRv2 to determine a node's 1-hop neighbors for routing, 112 and to allow the selection of MultiPoint Relays (MPRs) for optimized 113 flooding and topology reporting. This specification however only 114 describes the message exchange and information storage required for 115 1-hop and symmetric 2-hop neighborhood discovery. It may be used by 116 any MANET protocols which need neighborhood information, and which 117 may add an MPR mechanism, or an alternative to it, using appropriate 118 TLVs (type-length-value objects) as specified in [1], using which 119 this protocol's HELLO message format is defined. 121 This protocol makes no assumptions about the underlying link layer, 122 other than support of local multicast. Link layer information and 123 notifications may be used if available and applicable to qualify the 124 neighborhood information. 126 1.1. Terminology 128 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC2119 [2]. 132 Additionally, this document uses the following terminology: 134 node - A MANET router which implements this neighborhood discovery 135 protocol. 137 MANET interface - A network device participating in a MANET and using 138 this neighborhood discovery protocol. A node may have several 139 MANET interfaces, each interface being assigned one or more IP 140 addresses. 142 link - A link is a pair of MANET interfaces from two different nodes, 143 where at least one interface is able to hear (i.e. receive traffic 144 from) the other. 146 symmetric link - A link where both MANET interfaces are able to hear 147 (i.e. receive traffic from) the other. 149 asymmetric link - A link which is not symmetric. 151 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if node Y 152 can hear node X (i.e. a link exists from a MANET interface on node 153 X to a MANET interface on node Y). 155 symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of 156 a node Y if a symmetric link exists from a MANET interface on node 157 X to a MANET interface on node Y. 159 symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of 160 a node Y if node X is a symmetric 1-hop neighbor of a symmetric 161 1-hop neighbor of node Y, but is not node Y itself. 163 1-hop neighborhood - The 1-hop neighborhood of a node X is the set of 164 the 1-hop neighbors of node X. 166 symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a 167 node X is the set of the symmetric 1-hop neighbors of node X. 169 symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a 170 node X is the set of the symmetric 2-hop neighbors of node X. 171 (This may include nodes in the 1-hop neighborhood, or even in the 172 symmetric 1-hop neighborhood, of node X.) 174 1.2. Applicability Statement 176 This neighborhood discovery protocol supports nodes which have one or 177 more interfaces which participate in the MANET. It provides each 178 node with local topology information up to two hops away. This 179 information is made available to other protocols through a collection 180 of sets describing the node's 1-hop neighborhood and symmetric 2-hop 181 neighborhood, collectively known as the neighborhood information 182 base. 184 The specification is designed specifically with IP (IPv4/IPv6) in 185 mind. All addresses within a control message are assumed to be of 186 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 187 addresses, IPv4 addresses are carried in IPv6 as specified in [5]. 189 The packets defined by this specification may use any transport 190 protocol appropriate to the protocol using this specification. When 191 the diffusion mechanism enabled by this specification is employed, 192 UDP may be most appropriate. 194 This protocol uses the message exchange format specified in [1]. 195 This implies that the HELLO messages specified by this protocol may 196 be extended using the TLV mechanisms described in [1], e.g. to signal 197 MPR selection as required by OLSRv2 [3]. This also implies that 198 neighborhood discovery protocol messages can be transmitted in 199 packets with messages from other protocols, so long as these 200 protocols also use [1]. 202 2. Protocol Overview and Functioning 204 This protocol consists of a specification of local signaling, which 205 serves to: 207 o advertise the presence of a node and its MANET interfaces to 208 adjacent nodes (1-hop neighbors); 210 o discover links to adjacent nodes; 212 o perform bidirectionality (symmetry) checks on the discovered 213 links; 215 o advertise discovered links and whether each is symmetric to its 216 1-hop neighbors and hence discover symmetric 2-hop neighbors; 218 o maintain an information base consisting of discovered links and 219 their status, 1-hop neighbors and their MANET interfaces, 220 symmetric 1-hop neighbors and symmetric 2-hop neighbors. 222 Signaling consists of a single type of periodically transmitted 223 message known as a HELLO message. A HELLO message identifies its 224 originator node and that node's MANET interfaces and addresses. As a 225 node receives HELLO messages and populates its information base, a 226 list of 1-hop neighbors' MANET interface addresses and their link 227 status is included in subsequent HELLO message content. Thus, the 228 periodic transmission allows nodes to continuously track changes in 229 their 1-hop and symmetric 2-hop neighborhoods. 231 Because each node sends HELLO messages periodically, the protocol can 232 tolerate reasonable message loss without requiring reliable 233 transmission. Such losses can occur frequently in radio networks due 234 to collisions or other transmission problems. 236 The nominal time interval of a node's periodic HELLO transmission is 237 known as HELLO_INTERVAL and MAY be included in the HELLO message. 238 The HELLO message MUST include a validity time value that indicates 239 the length of time for which the message content is to be considered 240 valid and included in the receiving node's information base. In some 241 uses the validity time may be a multiple of HELLO_INTERVAL to allow 242 for lossy exchange of HELLO messages. 244 HELLO messages MAY, in addition to periodic transmissions, also be 245 generated as a response to some event (e.g. a change in the 246 advertised neighborhood indicated by a received HELLO message or by a 247 layer 2 notification, if available, indicating a change in a link to 248 a neighbor). However a node MUST respect a minimum interval, 249 HELLO_MIN_INTERVAL, between successive HELLO message transmissions in 250 order to maintain an upper bound on signaling traffic. 252 This protocol is designed to work in a completely distributed manner 253 and does not depend on any central entity. This protocol does not 254 require any changes to the format of IP packets, thus any existing IP 255 stack can be used as is. 257 Each MANET node will form estimates of its 1-hop and symmetric 2-hop 258 neighborhoods as this protocol operates. These estimates can be 259 maintained in an information base comprised of the data sets listed 260 below. These are defined formally in Section 3 and can be summarized 261 as follows: 263 Link Set - This set records the status of all links from and, if 264 symmetric, to 1-hop neighbors. It also records as lost links 265 which used to be symmetric but have since failed. A node MUST 266 record the Link Set in order to correctly send HELLO messages. 268 Symmetric Neighbor Set - This set records the addresses of the MANET 269 interfaces of symmetric 1-hop neighbors, or, as lost, those which 270 used to be. Note that if any of these nodes have more than one 271 MANET interface then this set may record addresses that are not in 272 the Link Set. A node MUST record the Symmetric Neighbor Set in 273 order to correctly send HELLO messages. 275 Neighborhood Address Association Set - This set allows the addresses 276 of the MANET interfaces of each 1-hop neighbor to be associated 277 with each other. It is required for processes such as MPR 278 selection as in [3]. 280 2-Hop Neighbor Set - This set records the addresses of the MANET 281 interfaces of symmetric 2-hop neighbors. It is required for 282 processes such as MPR selection as in [3]. 284 3. Neighborhood Information Base 286 The neighborhood information base stores information about the 1-hop 287 neighborhood and the symmetric 2-hop neighborhood of a node. 289 Note that it is possible for a node, X, to be present in both the 290 1-hop and symmetric 2-hop neighborhoods of another node, Y, 291 concurrently. If the link between node X and node Y breaks, this 292 allows node X to be taken into consideration as a symmetric 2-hop 293 neighbor by node Y immediately, rather than waiting for a HELLO 294 message exchange cycle. 296 This specification assumes that all addresses have an associated 297 prefix length. The prefix length of an address is, in HELLO 298 messages, indicated using the PREFIX_LENGTH TLV specified in [1]. If 299 no PREFIX_LENGTH TLV is present for a given address, it is assumed 300 that the prefix length for that address is equal to the length of the 301 address. Two addresses are identical if and only if both the 302 addresses and their associated prefix lengths are identical. 304 Addresses recorded in the neighborhood information base 305 (L_local_iface_addr, L_neighbor_iface_addr, N_local_iface_addr, 306 N_neighbor_iface_addr, N2_local_iface_addr, N2_neighbor_iface_addr, 307 N2_2hop_iface_addr and those listed in NA_neighbor_iface_addr_list) 308 MUST all be recorded with prefix lengths, in order to allow 309 comparison with addresses received in HELLO messages. 311 3.1. Link Set 313 A node records a set of "Link Tuples", recording information about 314 its 1-hop neighborhood: 316 (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, 317 L_ASYM_time, L_time) 319 each describing a link between a MANET interface of this node and a 320 MANET interface of one of its 1-hop neighbors, where: 322 L_local_iface_addr is the address of the MANET interface of the local 323 node on which the 1-hop neighbor is or was heard; 325 L_neighbor_iface_addr is the address of the MANET interface of the 326 1-hop neighbor; 328 L_SYM_time is the time until which the link to the 1-hop neighbor is 329 considered symmetric; 331 L_ASYM_time is the time until which the MANET interface of the 1-hop 332 neighbor is considered heard; 334 L_time specifies when this Link Tuple expires and MUST be removed. 336 The status of the link, denoted L_STATUS, can be derived based on the 337 fields L_SYM_time and L_ASYM_time as defined in Table 1. 339 +-------------+-------------+-----------+ 340 | L_SYM_time | L_ASYM_time | L_STATUS | 341 +-------------+-------------+-----------+ 342 | Expired | Expired | LOST | 343 | | | | 344 | Not Expired | Expired | SYMMETRIC | 345 | | | | 346 | Not Expired | Not Expired | SYMMETRIC | 347 | | | | 348 | Expired | Not Expired | HEARD | 349 +-------------+-------------+-----------+ 351 Table 1 353 In a node, the set of Link Tuples is denoted the "Link Set". 355 3.2. Symmetric Neighbor Set 357 A node records a set of "Symmetric Neighbor Tuples", recording 358 information about its symmetric 1-hop neighborhood: 360 (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time) 362 each describing an address of a MANET interface of this node and an 363 address of a MANET interface of one of its symmetric 1-hop neighbors, 364 where: 366 N_local_iface_addr is the address of the MANET interface of the local 367 node to which the 1-hop neighbor has or had a symmetric link; 369 N_neighbor_iface_addr is an address of a MANET interface of a 1-hop 370 neighbor which is or was in this node's symmetric 1-hop 371 neighborhood; 373 N_SYM_time is the time until which the 1-hop neighbor is considered 374 to be in this node's symmetric 1-hop neighborhood; 376 N_time specifies when this Symmetric Neighborhood Tuple expires and 377 MUST be removed. 379 The status of the 1-hop neighbor, denoted N_STATUS, can be derived 380 based on the field L_SYM_time as defined in Table 2. 382 +-------------+-----------+ 383 | N_SYM_time | N_STATUS | 384 +-------------+-----------+ 385 | Expired | LOST | 386 | | | 387 | Not Expired | SYMMETRIC | 388 +-------------+-----------+ 390 Table 2 392 In a node, the set of Symmetric Neighbor Tuples is denoted the 393 "Symmetric Neighbor Set". 395 3.3. Neighborhood Address Association Set 397 A node records a set of "Neighborhood Address Association Tuples", 398 recording information about the MANET interface configuration of its 399 1-hop neighbors: 401 (NA_neighbor_iface_addr_list, NA_time) 403 NA_neighbor_iface_addr_list is a list of interface addresses of a 404 single 1-hop neighbor; 406 NA_time specifies when this Neighborhood Address Association Tuple 407 expires and MUST be removed. 409 In a node, the set of Neighborhood Address Association Tuples is 410 denoted the "Neighborhood Address Association Set". 412 3.4. 2-Hop Neighbor Set 414 A node records a set of "2-Hop Neighbor Tuples", recording 415 information about a its symmetric 2-hop neighborhood: 417 (N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr, 418 N2_time) 420 each describing a symmetric link between an address of a MANET 421 interface of one of this node's symmetric 1-hop neighbors and an 422 address of a MANET interface of a node in this node's symmetric 2-hop 423 neighborhood. 425 N2_local_iface_addr is the address of the local MANET interface over 426 which the information defining this 2-Hop Neighbor Tuple was 427 received; 429 N2_neighbor_iface_addr is the address of the MANET interface address 430 of a symmetric 1-hop neighbor; 432 N2_2hop_iface_addr is the address of a MANET interface of a symmetric 433 2-hop neighbor which has a symmetric link (not necessarily using 434 this address) to the node with MANET interface address 435 N2_neighbor_iface_addr; 437 N2_time specifies the time at which this 2-Hop Neighbor Tuple expires 438 and MUST be removed. 440 In a node, the set of 2-Hop Neighbor Tuples is denoted the "2-Hop 441 Neighbor Set". 443 4. Packets and Messages 445 The packet and message format used by this neighborhood discovery 446 protocol is defined in [1], which is used with the following 447 considerations: 449 o this protocol specifies one message type, the HELLO message, in 450 Section 4.1; 452 o HELLO message header options may be used as specified by the 453 protocol which uses this neighborhood discovery protocol; 455 o HELLO messages are transmitted only one hop, i.e. MUST NOT be 456 forwarded; 458 o multi-message packets may be created using other messages as 459 specified by the protocol which uses this neighborhood discovery 460 protocol; 462 o packet header options may be used as specified by the protocol 463 which uses this neighborhood discovery protocol. 465 4.1. HELLO Messages 467 A HELLO message MUST contain: 469 o a message TLV with Type == VALIDITY_TIME and Value == H_HOLD_TIME, 470 as specified in Section 4.1.2.1 472 o an address block known as the Local Interface Block, as specified 473 in Section 4.1.1; other addresses MUST NOT be added to this 474 address block. 476 A HELLO message MAY contain: 478 o a message TLV with Type == INTERVAL_TIME and Value == 479 HELLO_INTERVAL, as specified in Section 4.1.2.2; 481 o one or more address blocks with associated address block TLVs as 482 specified in Section 4.1.3; these address blocks contain current 483 or former 1-hop neighbors' MANET interface addresses with 484 associated TLVs. Other addresses (i.e. addresses of non-neighbor 485 nodes) MAY be added to these address blocks, however if they are 486 then these addresses MUST NOT have associated TLVs from the 487 address block TLVs specified in Section 4.1.3. 489 This protocol specifies two message TLVs and three address block TLVs 490 used in HELLO messages in Section 4.1.2 and Section 4.1.3; other TLVs 491 MAY be included as specified by the protocol which uses this 492 neighborhood discovery protocol. 494 4.1.1. Local Interface Block 496 The first address block, plus following TLV block, in a HELLO message 497 is known as the Local Interface Block. The Local Interface Block is 498 not distinguished in any way other than by being the first address 499 block in the message. 501 The first address of the Local Interface Block MUST contain the used 502 address of the interface over which the HELLO message is transmitted. 503 If that interface has an associated prefix different from the length 504 of the address, a PREFIX_LENGTH TLV MUST be associated with this 505 address. This first address, with associated prefix length, of the 506 Local Interface Block is henceforth denoted the "Source Address". 508 The Local Interface Block MUST contain all of the addresses of all of 509 the MANET interfaces of the originating node, using the standard 510 syntax specified in [1]. Those addresses, if any, 511 which correspond to MANET interfaces other than that on which the 512 HELLO message is transmitted MUST have a corresponding OTHER_IF TLV 513 as specified in Section 4.1.3, other addresses MUST NOT use this TLV. 515 Note that a Local Interface Block MAY include more than one address 516 for each MANET interface, and hence a HELLO message MAY contain more 517 than one address without an OTHER_IF TLV. A Local Interface Block 518 MUST NOT contain any addresses which are not of MANET interfaces of 519 the originating node. 521 4.1.2. Message TLVs 523 This section specifies two message TLVs: VALIDITY_TIME and 524 INTERVAL_TIME. 526 4.1.2.1. VALIDITY_TIME TLV 528 All HELLO messages MUST include a VALIDITY_TIME TLV, specifying for 529 how long a node may, upon receiving a message, consider the message 530 content to be valid. The VALIDITY_TIME TLV, described in this 531 document, contains a single value since HELLO messages are 532 transmitted only one hop. Note that [1] specifies an extended 533 version of this VALIDITY_TIME TLV, which is compatible with the 534 format of the VALIDITY_TIME TLV in this specification. 536 The VALIDITY_TIME message TLV specification is given in Table 3. 538 +----------------+------+-------------------+----------------------+ 539 | Name | Type | Length | Value | 540 +----------------+------+-------------------+----------------------+ 541 | VALIDITY_TIME | TBD | 8 bits | | 542 +----------------+------+-------------------+----------------------+ 544 Table 3 546 where is the period for which the information is valid, 547 represented as specified in Section 4.1.2.3. 549 4.1.2.2. INTERVAL_TIME TLV 551 HELLO messages MAY include an INTERVAL_TIME message TLV, specifying 552 the interval at which HELLO messages are being generated by the 553 originator node. Note that HELLO messages which are not part of a 554 regular schedule SHALL be ignored in defining the interval. If, for 555 whatever reason, HELLO messages are sent in an irregular pattern, 556 then this SHALL be the longest interval in that pattern. 558 The INTERVAL_TIME message TLV specification is given in Table 4. 560 +----------------+------+-------------------+----------------------+ 561 | Name | Type | Length | Value | 562 +----------------+------+-------------------+----------------------+ 563 | INTERVAL_TIME | TBD | 8 bits |