idnits 2.17.1 draft-ietf-manet-nhdp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1618. 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 344 has weird spacing: '...ce_addr is th...' == Line 347 has weird spacing: '...ce_addr is th...' == Line 350 has weird spacing: '...YM_time is th...' == Line 353 has weird spacing: '...YM_time is th...' == Line 356 has weird spacing: '... L_time speci...' == (10 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 9, 2007) is 6284 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 13, 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 9, 2007 13 MANET Neighborhood Discovery Protocol (NHDP) 14 draft-ietf-manet-nhdp-01 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 13, 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. Neighborhood Information Base . . . . . . . . . . . . . . . . 10 60 5.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 11 62 5.3. Neighborhood Address Association Set . . . . . . . . . . . 12 63 5.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 12 64 6. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 13 65 6.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1.1. Local Interface Block . . . . . . . . . . . . . . . . 14 67 6.1.2. Address Block TLVs . . . . . . . . . . . . . . . . . . 14 68 7. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 15 69 7.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 16 70 7.1.1. HELLO Message: Jitter . . . . . . . . . . . . . . . . 17 71 8. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 18 72 8.1. Populating the Link Set . . . . . . . . . . . . . . . . . 18 73 8.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 19 74 8.3. Populating the Neighborhood Address Association Set . . . 20 75 8.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 20 76 8.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 22 77 9. Proposed Values for Constants . . . . . . . . . . . . . . . . 23 78 9.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 23 79 9.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 23 80 9.3. Jitter Times . . . . . . . . . . . . . . . . . . . . . . . 23 81 9.4. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 10.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 24 84 10.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 85 10.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 24 86 10.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 25 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 90 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 27 91 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 28 92 Appendix C. Time TLVs . . . . . . . . . . . . . . . . . . . . . 30 93 C.1. Representing Time . . . . . . . . . . . . . . . . . . . . 30 94 C.2. General Time TLV Structure . . . . . . . . . . . . . . . . 30 95 C.3. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 32 96 C.3.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . 32 97 C.3.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . 32 98 Appendix D. Message Jitter . . . . . . . . . . . . . . . . . . . 33 99 D.1. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 D.1.1. Periodic message generation . . . . . . . . . . . . . 33 101 D.1.2. Externally triggered message generation . . . . . . . 34 102 D.1.3. Message forwarding . . . . . . . . . . . . . . . . . . 34 103 Appendix E. Utilizing Link Layer Information . . . . . . . . . . 36 104 Appendix F. Security Considerations . . . . . . . . . . . . . . 38 105 Appendix F.1. Invalid HELLO messages . . . . . . . . . . . . . . . 38 106 Appendix G. Flow and Congestion Control . . . . . . . . . . . . 40 107 Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 41 108 Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 42 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 110 Intellectual Property and Copyright Statements . . . . . . . . . . 44 112 1. Introduction 114 This document describes a neighborhood discovery protocol (NHDP) for 115 a mobile ad hoc network (MANET). The protocol uses an exchange of 116 HELLO messages in order that each node can determine its 1-hop and 117 symmetric 2-hop neighborhoods. 119 This specification describes both this HELLO message exchange, the 120 messages being defined as instances of the specification [1], and the 121 information storage required for neighborhood discovery. 123 This protocol makes no assumptions about the underlying link layer, 124 other than support of link local multicast. Link layer information 125 and notifications may be used if available and applicable. 127 This protocol is based on the neighborhood discovery process 128 contained in the Optimized Link State Routing Protocol (OLSR) [3]. 130 2. Terminology 132 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC2119 [2]. 136 The terms "packet", "message", "address block", "TLV", and "TLV 137 block" in this document are to be interpreted as described in [1]. 139 Additionally, this document uses the following terminology: 141 Node - A MANET router which implements this neighborhood discovery 142 protocol. 144 MANET interface - A network device participating in a MANET and 145 using this neighborhood discovery protocol. A node may have 146 several MANET interfaces, each being assigned one or more IP 147 addresses. 149 Link - A pair of MANET interfaces from two different nodes, where at 150 least one interface is able to receive traffic from the other. 152 Symmetric link - A link where both MANET interfaces are able to 153 receive traffic from the other. 155 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if node Y 156 can hear node X (i.e. a link exists from a MANET interface on node 157 X to a MANET interface on node Y). 159 Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of 160 a node Y if a symmetric link exists from a MANET interface on node 161 X to a MANET interface on node Y. 163 Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of 164 a node Y if node X is a symmetric 1-hop neighbor of a symmetric 165 1-hop neighbor of node Y, but is not node Y itself. 167 1-hop neighborhood - The 1-hop neighborhood of a node X is the set 168 of the 1-hop neighbors of node X. 170 Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a 171 node X is the set of the symmetric 1-hop neighbors of node X. 173 Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a 174 node X is the set of the symmetric 2-hop neighbors of node X. 175 (This may include nodes in the 1-hop neighborhood, or even in the 176 symmetric 1-hop neighborhood, of node X.) 178 3. Applicability Statement 180 This neighborhood discovery protocol supports nodes which have one or 181 more interfaces participating in the MANET. It provides each node 182 with local topology information up to two hops away. This 183 information is made available to other protocols through a 184 Neighborhood Information Base, described in Section 5. 186 The protocol is designed to work in networks where messages may be 187 lost, such as due to collisions in wireless networks. If relevant 188 link layer information is available then it may be used by this 189 protocol. 191 This protocol to works in a completely distributed manner and does 192 not depend on any central entity. It does not require any changes to 193 the format of IP packets, thus any existing IP stack can be used as 194 is. 196 This protocol uses the packet and message formats specified in [1]. 197 HELLO messages specified by this protocol may be extended using the 198 TLV mechanisms described in [1]. For example, if multipoint relays 199 (MPRs) are to be calculated similarly to as in OLSR [3] and signaled 200 to neighbors, then this information may be added to HELLO messages 201 using an address block TLV. HELLO messages can also be transmitted 202 in packets with messages from other protocols that also use [1]. 204 4. Protocol Overview and Functioning 206 This protocol specifies local (one hop) signaling that: 208 o advertises the presence of a node and its MANET interfaces; 210 o discovers links to adjacent nodes; 212 o performs bidirectionality checks on the discovered links; 214 o advertises discovered links and whether each is symmetric to its 215 1-hop neighbors and hence discover symmetric 2-hop neighbors; 217 o maintains an information base describing discovered links and 218 their status, 1-hop neighbors and their MANET interfaces, 219 symmetric 1-hop neighbors and symmetric 2-hop neighbors. 221 Signaling consists of a single type of message, known as a HELLO 222 message. A HELLO message identifies its originator node and that 223 node's MANET interfaces and addresses. As a node receives HELLO 224 messages and populates its information base, a list of 1-hop 225 neighbors' MANET interface addresses and their link status (lost, 226 symmetric or heard) is included in subsequent HELLO messages. Thus, 227 the periodic transmission allows nodes to continuously track changes 228 in their 1-hop and symmetric 2-hop neighborhoods. If information 229 about link quality is available from the link layer, then this may 230 also be used, see Appendix E. 232 4.1. HELLO Message Generation 234 HELLO messages may be sent: 236 o Proactively, at a regular interval, known as HELLO_INTERVAL. 237 HELLO_INTERVAL may be fixed, as suggested in Section 9, or may be 238 dynamic. For example HELLO_INTERVAL may be backed off due to 239 congestion or network stability. Note that if HELLO_INTERVAL is 240 dynamic, it is interpreted as the interval within which the next 241 HELLO message will be sent on the same MANET interface. 243 o As a response to a change in the node itself, or its neighborhood, 244 for example on first becoming active or in response to a new, 245 broken or changed status link. 247 o In a combination of these proactive and responsive mechanisms. 249 Jittering of HELLO message generation and transmission, as described 250 in Section 7.1, may be appropriate. 252 HELLO messages are sent independently on each MANET interface. 254 4.2. HELLO message content 256 Each HELLO message sent over a MANET interface need not contain all 257 of the information appropriate to that MANET interface, however: 259 o A HELLO message MUST contain all of its own local interface 260 information. 262 o Within every time interval of length REFRESH_INTERVAL, HELLO 263 messages sent over a MANET interface MUST include all of the 264 information appropriate to that interface in at least one HELLO 265 message sent on that interface. This applies to otherwise purely 266 responsive nodes as well as proactive nodes. 268 o A HELLO message MUST include a VALIDITY_TIME message TLV that 269 indicates the length of time for which the message content is to 270 be considered valid and included in the receiving node's 271 Neighborhood Information Base. 273 o A HELLO message SHOULD include an INTERVAL_TIME message TLV that 274 indicates the current value of HELLO_INTERVAL. 276 4.3. Node Behavior 278 A node MUST: 280 o Respect a minimum interval, HELLO_MIN_INTERVAL, between successive 281 HELLO message transmissions over a given interface. If jitter is 282 used then this interval may be reduced, but only by a random value 283 not exceeding HP_MAXJITTER. 285 o Ensure that if HELLO_INTERVAL and other parameters are maintained 286 dynamically, changes do not invalidate the guarantees of 287 Section 7.1. 289 o Maintain, based on received HELLO messages, estimates of its 1-hop 290 and symmetric 2-hop neighborhoods as this protocol operates. 291 Formally defined in Section 5, this can be summarized as 292 consisting of the following sets: 294 Link Set - Records the status of all links from and to current 295 and former 1-hop neighbors. 297 Symmetric Neighbor Set - Records the status of current and former 298 symmetric 1-hop neighbors. If any of these nodes have more 299 than one MANET interface then this set may record addresses 300 that are not in the Link Set. 302 Neighborhood Address Association Set - Allows the addresses of 303 the MANET interfaces of each 1-hop neighbor to be associated 304 with each other. 306 2-Hop Neighbor Set - Records the addresses of the MANET 307 interfaces of symmetric 2-hop neighbors. 309 The information in the Link Set and Symmetric Neighbor Set MUST be 310 maintained in order for a node to correctly generate HELLO 311 messages. 313 5. Neighborhood Information Base 315 A node maintains a Neighborhood Information Base that records 316 information about its 1-hop and symmetric 2-hop neighborhoods. The 317 Neighborhood Information Base includes the Link Set, the Symmetric 318 Neighbor Set, the Neighborhood Address Association Set and the 2-Hop 319 Neighbor Set. 321 A node, X, can be present in both the 1-hop and symmetric 2-hop 322 neighborhoods of another node, Y, concurrently. This allows node X 323 to be immediately considered as a symmetric 2-hop neighbor by node Y 324 if the link between them fails. 326 All addresses MUST have an associated prefix length, which is 327 included in all addresses in the Neighborhood Information Base. 328 Prefix lengths are indicated in HELLO messages using the 329 PREFIX_LENGTH TLV specified in [1]; if an address has no such TLV, 330 then its prefix length is equal to the address length. Two addresses 331 are considered equal if and only if their associated prefix lengths 332 are also equal. 334 5.1. Link Set 336 A node's Link Set records its 1-hop neighborhood. It consists of 337 Link Tuples: 339 (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, 340 L_ASYM_time, L_time) 342 where: 344 L_local_iface_addr is the address of the local MANET interface on 345 which the 1-hop neighbor is or was heard; 347 L_neighbor_iface_addr is the address of the MANET interface of the 348 1-hop neighbor; 350 L_SYM_time is the time until which the link to the 1-hop neighbor is 351 considered symmetric; 353 L_ASYM_time is the time until which the MANET interface of the 1-hop 354 neighbor is considered heard; 356 L_time specifies when this Tuple expires and MUST be removed. 358 The status of the link, denoted L_STATUS, can be derived based on the 359 fields L_SYM_time and L_ASYM_time as defined in Table 1. 361 +-------------+-------------+-----------+ 362 | L_SYM_time | L_ASYM_time | L_STATUS | 363 +-------------+-------------+-----------+ 364 | Expired | Expired | LOST | 365 | | | | 366 | Not Expired | Expired | SYMMETRIC | 367 | | | | 368 | Not Expired | Not Expired | SYMMETRIC | 369 | | | | 370 | Expired | Not Expired | HEARD | 371 +-------------+-------------+-----------+ 373 Table 1 375 5.2. Symmetric Neighbor Set 377 A node's Symmetric Neighbor Set records its symmetric 1-hop 378 neighborhood. It consists of Symmetric Neighbor Tuples: 380 (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time) 382 where: 384 N_local_iface_addr is the address of the local MANET interface to 385 which the 1-hop neighbor has or had a symmetric link; 387 N_neighbor_iface_addr is an address of a MANET interface of a 1-hop 388 neighbor which is or was a symmetric 1-hop neighbor of this node; 390 N_SYM_time is the time until which the 1-hop neighbor is considered 391 to be a symmetric 1-hop neighbor; 393 N_time specifies when this Tuple expires and MUST be removed. 395 The status of the 1-hop neighbor, denoted N_STATUS, can be derived 396 based on the field L_SYM_time as defined in Table 2. 398 +-------------+-----------+ 399 | N_SYM_time | N_STATUS | 400 +-------------+-----------+ 401 | Expired | LOST | 402 | | | 403 | Not Expired | SYMMETRIC | 404 +-------------+-----------+ 406 Table 2 408 5.3. Neighborhood Address Association Set 410 A node's Neighborhood Address Association Set records the MANET 411 interface configuration of its 1-hop neighbors. It consists of 412 Neighborhood Address Association Tuples: 414 (NA_neighbor_iface_addr_list, NA_time) 416 where: 418 NA_neighbor_iface_addr_list is a list of interface addresses of a 419 single 1-hop neighbor; 421 NA_time specifies when this Tuple expires and MUST be removed. 423 5.4. 2-Hop Neighbor Set 425 A node's 2-Hop Neighbor Set records its symmetric 2-hop neighborhood. 426 It consists of 2-Hop Neighbor Tuples: 428 (N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr, 429 N2_time) 431 where: 433 N2_local_iface_addr is the address of the local MANET interface on 434 which this information was received; 436 N2_neighbor_iface_addr is the address of the MANET interface of a 437 symmetric 1-hop neighbor; 439 N2_2hop_iface_addr is the address of a MANET interface of a 440 symmetric 2-hop neighbor which has a symmetric link (using any 441 MANET interface) to the indicated symmetric 1-hop neighbor; 443 N2_time specifies the time at which this Tuple expires and MUST be 444 removed. 446 6. Packets and Messages 448 The packet and message format used by this neighborhood discovery 449 protocol is defined in [1], which is used with the following 450 considerations: 452 o this protocol specifies one message type, the HELLO message; 454 o HELLO message header options may be used as specified by the 455 protocol which uses this neighborhood discovery protocol; 457 o HELLO messages MUST NOT be forwarded; 459 o HELLO messages may be included in multi-message packets as 460 specified in [1]; 462 o packet header options may be used as specified by the protocol 463 which uses this neighborhood discovery protocol. 465 6.1. HELLO Messages 467 A HELLO message MUST contain: 469 o A VALIDITY_TIME message TLV as specified in Appendix C, 470 representing time value (at distance one hop) H_HOLD_TIME, which 471 MUST NOT be less than REFRESH_INTERVAL. If HELLO messages may be 472 lost then H_HOLD_TIME SHOULD be a multiple of REFRESH_INTERVAL. 474 o An address block, and associated TLV block, known as the Local 475 Interface Block, as specified in Section 6.1.1. 477 A HELLO message which is transmitted at a regular interval SHOULD 478 contain, and otherwise MAY contain: 480 o An INTERVAL_TIME message TLV as specified in Appendix C, 481 representing time value (at distance one hop) HELLO_INTERVAL. 483 A HELLO message MAY contain: 485 o One or more address blocks, with associated address block TLVs, 486 containing current or former 1-hop neighbors' MANET interface 487 addresses. Other addresses (i.e. addresses of non-neighbor nodes) 488 MAY be included in these address blocks, but MUST NOT be 489 associated with any of the TLVs specified in Section 6.1.2. 491 o Other message TLVs. 493 6.1.1. Local Interface Block 495 The first address block, plus following TLV block, in a HELLO message 496 is known as the Local Interface Block. The Local Interface Block is 497 not distinguished in any way other than by being the first address 498 block in the message. 500 The first address of the Local Interface Block MUST be the used 501 address of the MANET interface over which the HELLO message is 502 transmitted. 504 The Local Interface Block MUST contain all of the addresses of all of 505 the MANET interfaces of the originating node, and no other addresses. 506 Those addresses, if any, which correspond to MANET interfaces other 507 than that on which the HELLO message is transmitted MUST have a 508 corresponding OTHER_IF TLV as specified in Section 6.1.2, other 509 addresses (i.e. those of the MANET interface on which the HELLO 510 message is transmitted) MUST NOT use this TLV. 512 Note that a Local Interface Block MAY include more than one address 513 for each MANET interface, and hence a HELLO message MAY contain more 514 than one address without an OTHER_IF TLV. 516 6.1.2. Address Block TLVs 518 The three address block TLVs used in HELLO messages are specified in 519 Table 3. 521 +----------------+------+-------------------+-----------------------+ 522 | Name | Type | Length | Value | 523 +----------------+------+-------------------+-----------------------+ 524 | OTHER_IF | TBD | 0 bits | Not Applicable | 525 | | | | | 526 | LINK_STATUS | TBD | 8 bits | One of LOST, | 527 | | | | SYMMETRIC or HEARD | 528 | | | | | 529 | OTHER_NEIGHB | TBD | 8 bits | One of LOST or | 530 | | | | SYMMETRIC | 531 +----------------+------+-------------------+-----------------------+ 533 Table 3 535 7. HELLO Message Generation 537 HELLO messages MUST be generated and transmitted independently on 538 each MANET interface. If using the HELLO message interval 539 HELLO_INTERVAL then, following a HELLO message transmission on a 540 MANET interface, another HELLO message MUST be sent on the same 541 interface after an interval not greater than HELLO_INTERVAL. Two 542 successive HELLO message transmissions on the same MANET interface 543 MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in 544 Section 7.1.1. 546 A HELLO message MUST include a Local Interface Block as specified in 547 Section 6.1.1 as its first address block. 549 Other addresses which MUST be included in HELLO messages are: 551 o addresses of 1-hop neighbors from the Link Set; 553 o addresses of 1-hop neighbors from the Symmetric Neighbor Set. 555 These addresses MUST NOT be included in the Local Interface Block. 556 These addresses MAY be included in any HELLO messages sent on the 557 appropriate MANET interface. These addresses, and their associated 558 TLVs, are: 560 1. For each address which appears as an L_neighbor_iface_addr in one 561 or more Link Tuples whose L_local_iface_addr is an address of the 562 MANET interface over which the HELLO message is to be sent, 563 include that L_neighbor_iface_addr with an associated TLV with: 565 * Type = LINK_STATUS; AND 567 * Value = L_STATUS. 569 2. For each address which appears as an N_neighbor_iface_addr in one 570 or more Symmetric Neighbor Tuples: 572 1. if this address has already been included with an associated 573 TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not 574 add an associated TLV with Type == OTHER_NEIGHB; 576 2. otherwise if, for one or more of these Symmetric Neighbor 577 Tuples, N_STATUS == SYMMETRIC, then include this 578 N_neighbor_iface_addr with an associated TLV with: 580 + Type = OTHER_NEIGHB; AND 581 + Value = SYMMETRIC. 583 3. otherwise if, for all of these Symmetric Neighbor Tuples, 584 N_STATUS == LOST, and this address has not already been 585 included with an associated TLV with Type == LINK_STATUS and 586 Value == LOST, then include this N_neighbor_iface_addr with 587 an associated TLV with: 589 + Type = OTHER_NEIGHB; AND 591 + Value = LOST. 593 On each of its MANET interfaces, for each specified 1-hop neighbor 594 address and associated TLV, the address and associated TLV MUST be 595 included in at least one HELLO message in every interval of length 596 REFRESH_INTERVAL. 598 If an address is specified with more than one associated TLV, then 599 these TLVs MAY be independently included or excluded from each HELLO 600 messages as long as each such TLV is included associated with that 601 address in a HELLO message sent on that MANET interface in every 602 interval of length REFRESH_INTERVAL. 604 TLVs associated with the same address included in the same HELLO 605 message MAY be applied to the same or different copies of that 606 address. 608 7.1. HELLO Message: Transmission 610 Messages are transmitted in the packet/message format specified by 611 [1] using the ALL-MANET-NEIGHBORS multicast address as destination IP 612 address, and with the HELLO message hop limit = 1. 614 If the parameters of the protocol are changed, then guarantees given 615 for the old values of the parameters MUST still be respected. In 616 particular: 618 o If HELLO_INTERVAL is increased, then a HELLO message MUST be sent 619 within the old HELLO_INTERVAL of the previous HELLO message sent 620 on each MANET interface. 622 o If REFRESH_INTERVAL is increased, then all information (addresses 623 and associated TLVs) must be sent again on each MANET interface 624 within the old REFRESH_INTERVAL of the previous HELLO message that 625 included that information. 627 7.1.1. HELLO Message: Jitter 629 HELLO messages MAY be sent using periodic message generation or 630 externally triggered message generation. If using data link and 631 physical layers which are subject to packet loss due to collisions, 632 HELLO messages SHOULD be jittered as described in Appendix D. 634 Internally triggered message generation MAY be treated as if 635 externally generated message generation, or MAY be not jittered. 637 HELLO messages MUST NOT be forwarded, and thus message forwarding 638 jitter does not apply to HELLO messages. 640 Each form of jitter described in Appendix D requires a parameter 641 MAXJITTER. These parameters may be dynamic, and are specified by: 643 o For periodic message generation: HP_MAXJITTER, which MUST be 644 significantly less than HELLO_INTERVAL. 646 o For externally triggered message generation: HT_MAXJITTER. If 647 HELLO messages are also periodically generated then HT_MAXJITTER 648 also MUST be significantly less than HELLO_INTERVAL. 650 When HELLO message generation is delayed in order that a HELLO 651 message is not sent within HELLO_MIN_INTERVAL of the previous HELLO 652 message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD 653 be reduced by jitter, with maximum reduction HP_MAXJITTER. In this 654 case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. 656 8. HELLO Message Processing 658 On receiving a HELLO message, a node MUST update its neighborhood 659 information base. 661 For the purpose of this section, note the following definitions: 663 o the "validity time" of a message is calculated from the 664 VALIDITY_TIME TLV of the message as specified in Appendix C; 666 o the "Source Address" is the first address, including prefix 667 length, of the Local Interface Block in the HELLO message; 669 o the "Receiving Address" is the address, including prefix length, 670 of the MANET interface on which the HELLO message was received; 672 o the word EXPIRED indicates that a timer is set to a value clearly 673 preceding the current time (e.g. current time - 1). 675 8.1. Populating the Link Set 677 On receiving a HELLO message, a node SHOULD update its Link Set: 679 1. If there is no Link Tuple with: 681 * L_local_iface_addr == Receiving Address; AND 683 * L_neighbor_iface_addr == Source Address, 685 then create a new Link Tuple with 687 * L_local_iface_addr = Receiving Address; 689 * L_neighbor_iface_addr = Source Address; 691 * L_SYM_time = EXPIRED; 693 * L_time = current time + validity time. 695 2. This Link Tuple (existing or new) is then modified as follows: 697 1. If the node finds the Receiving Address in one of the address 698 blocks included in the HELLO message, other than the Local 699 Interface Block, then the Link Tuple is modified as follows: 701 1. If the Receiving Address in that address block is 702 associated with a TLV with Type == LINK_STATUS and Value 703 == LOST then: 705 1. if L_STATUS == SYMMETRIC: 707 o L_time = current time + max(validity time, 708 L_HOLD_TIME), 710 o L_SYM_time = EXPIRED. 712 2. Otherwise if the Receiving Address in that address block 713 is associated with a TLV with Type == LINK_STATUS and 714 (Value == HEARD or Value == SYMMETRIC) then: 716 - L_SYM_time = current time + validity time; 718 - L_time = L_SYM_time + L_HOLD_TIME. 720 2. L_ASYM_time = current time + validity time; 722 3. L_time = max(L_time, L_ASYM_time). 724 8.2. Populating the Symmetric Neighbor Set 726 On receiving a HELLO message, a node SHOULD update its Symmetric 727 Neighbor Set: 729 1. If the Receiving Address is in an address block of the HELLO 730 message, other than the Local Interface Block, with an associated 731 TLV with Type == LINK_STATUS and (Value == HEARD or Value == 732 SYMMETRIC) then: 734 1. For each address (henceforth neighbor address) in the HELLO 735 message's Local Interface Block: 737 1. If there is a Symmetric Neighbor Tuple with: 739 - N_local_iface_addr == Receiving Address; AND 741 - N_neighbor_iface_addr == neighbor address, 743 then update this Symmetric Neighbor Tuple to have: 745 - N_SYM_time = current time + validity time; 747 - N_time = N_SYM_time + N_HOLD_TIME. 749 2. Otherwise create a new Symmetric Neighbor Tuple with: 751 - N_local_iface_addr = Receiving Address; 752 - N_neighbor_iface_addr = neighbor address; 754 - N_SYM_time = current time + validity time; 756 - N_time = N_SYM_time + N_HOLD_TIME. 758 2. Otherwise if the Receiving Address is in an address block of the 759 HELLO message, other than the Local Interface Block, with an 760 associated TLV with Type == LINK_STATUS and Value == LOST, then: 762 1. For each address (henceforth neighbor address) in the HELLO 763 message Local Interface Block, if there exists a Symmetric 764 Neighbor Tuple with: 766 + N_local_iface_addr == Receiving Address; AND 768 + N_neighbor_iface_addr == neighbor address, 770 update this Symmetric Neighbor Tuple to have: 772 + N_SYM_time = EXPIRED; 774 + N_time = min(N_time, current time + N_HOLD_TIME). 776 8.3. Populating the Neighborhood Address Association Set 778 On receiving a HELLO message, the node SHOULD update its Neighborhood 779 Address Association Set: 781 1. Remove all Neighborhood Address Association Tuples where: 783 * NA_neighbor_iface_addr_list contains at least one address 784 which is contained in the Local Interface Block of the 785 received HELLO message, 787 and create a new Neighborhood Address Association Tuple with: 789 * NA_neighbor_iface_addr_list = list of all addresses contained 790 in the Local Interface Block of the received HELLO message; 792 * NA_time = current time + validity time. 794 8.4. Populating the 2-Hop Neighbor Set 796 On receiving a HELLO message the node SHOULD update its 2-Hop 797 Neighbor Set: 799 1. If there exists a Link Tuple with L_local_iface_addr == Source 800 Address and L_STATUS == SYMMETRIC then: 802 1. For each address (henceforth 2-hop neighbor address) in an 803 address block of the HELLO message, other than the Local 804 Interface Block, which is not an interface address of the 805 receiving node: 807 1. If the 2-hop neighbor address has an associated TLV with: 809 - Type == LINK_STATUS and Value == SYMMETRIC; OR 811 - Type == OTHER_NEIGHB and Value == SYMMETRIC, 813 then, if there is no 2-Hop Neighbor Tuple with: 815 - N2_local_iface_addr == Receiving Address; 817 - N2_neighbor_iface_addr == Source Address; 819 - N2_2hop_iface_addr == 2-hop neighbor address; 821 create a 2-Hop Neighbor Tuple with: 823 - N2_local_iface_addr = Receiving Address; AND 825 - N2_neighbor_iface_addr = Source Address; AND 827 - N2_2hop_iface_addr = 2-hop neighbor address. 829 This 2-Hop Neighbor Tuple (existing or new) is then 830 modified as follows: 832 - N2_time = current time + validity time. 834 2. Otherwise if the 2-hop neighbor address has a TLV with: 836 - Type == LINK_STATUS and (Value == LOST or Value == 837 HEARD); OR 839 - Type == OTHER_NEIGHB and Value == LOST; 841 then remove all 2-Hop Neighbor Tuples with: 843 - N2_local_iface_addr == Receiving Address; AND 845 - N2_neighbor_iface_addr == Source Address; AND 846 - N2_2hop_iface_addr == 2-hop neighbor address. 848 8.5. Neighborhood Changes 850 If the L_SYM_time field of a Link Tuple expires (either due to timing 851 out, or as a result of processing a TLV with Type == LINK_STATUS and 852 Value == LOST) then all 2-Hop Neighbor Tuples with: 854 o N2_local_iface_addr == L_local_iface_addr from the Link Tuple, 855 AND; 857 o N2_neighbor_iface_addr == L_neighbor_iface_addr from the Link 858 Tuple, 860 MUST be deleted. 862 In this, or any other case of neighborhood change, a node MAY send a 863 HELLO message reporting updated information, subject to the 864 constraints in Section 7. 866 9. Proposed Values for Constants 868 This section lists proposed values for the constants used in the 869 specification of the protocol. 871 9.1. Message Intervals 873 o HELLO_INTERVAL = 2 seconds 875 o REFRESH_INTERVAL = HELLO_INTERVAL 877 o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 879 9.2. Holding Times 881 o H_HOLD_TIME = 3 x REFRESH_INTERVAL 883 o L_HOLD_TIME = H_HOLD_TIME 885 o N_HOLD_TIME = H_HOLD_TIME 887 9.3. Jitter Times 889 o HP_MAXJITTER = HELLO_INTERVAL/4 891 o HT_MAXJITTER = HELLO_INTERVAL/4 893 9.4. Time 895 o C = 0.0625 second (1/16 second) 897 In order to achieve interoperability, C MUST be the same on all 898 nodes. 900 10. IANA Considerations 902 10.1. Multicast Addresses 904 A well-known link-local multicast address, ALL-MANET-NEIGHBORS, must 905 be registered and defined for both IPv6 and IPv4. 907 10.2. Message Types 909 This specification defines one message type, which must be allocated 910 from the "Assigned Message Types" repository of [1]. 912 +--------------------+-------+--------------------------------------+ 913 | Mnemonic | Value | Description | 914 +--------------------+-------+--------------------------------------+ 915 | HELLO | TBD | Local signaling | 916 +--------------------+-------+--------------------------------------+ 918 Table 4 920 10.3. TLV Types 922 This specification defines two Message TLV types, which must be 923 allocated from the "Assigned Message TLV Types" repository of [1]. 925 +--------------------+-------+--------------------------------------+ 926 | Mnemonic | Value | Description | 927 +--------------------+-------+--------------------------------------+ 928 | VALIDITY_TIME | TBD | The time (in seconds) from receipt | 929 | | | of the message during which the | 930 | | | information contained in the message | 931 | | | is to be considered valid | 932 | | | | 933 | INTERVAL_TIME | TBD | The maximum time (in seconds) | 934 | | | between two successive transmissions | 935 | | | of messages of the appropriate type | 936 +--------------------+-------+--------------------------------------+ 938 Table 5 940 This specification defines three Address Block TLV types, which must 941 be allocated from the "Assigned Address Block TLV Types" repository 942 of [1]. 944 +--------------------+-------+--------------------------------------+ 945 | Mnemonic | Value | Description | 946 +--------------------+-------+--------------------------------------+ 947 | OTHER_IF | TBD | Specifies that the address, in the | 948 | | | Local Interface Block of the | 949 | | | message, is an address associated | 950 | | | with a MANET interface other than | 951 | | | the one on which the message is | 952 | | | transmitted | 953 | | | | 954 | LINK_STATUS | TBD | Specifies the status of the link to | 955 | | | the indicated address (LOST, | 956 | | | SYMMETRIC or HEARD) | 957 | | | | 958 | OTHER_NEIGHB | TBD | Specifies that the address is | 959 | | | (SYMMETRIC) or was (LOST) of a MANET | 960 | | | interface of a symmetric 1-hop | 961 | | | neighbor of the node transmitting | 962 | | | the HELLO message, but does not have | 963 | | | a matching or better LINK_STATUS TLV | 964 +--------------------+-------+--------------------------------------+ 966 Table 6 968 10.4. LINK_STATUS and OTHER_NEIGHB Values 970 The values which the LINK_STATUS TLV can use are the following: 972 o LOST = 0 974 o SYMMETRIC = 1 976 o HEARD = 2 978 The values which the OTHER_NEIGHB TLV can use are the following: 980 o LOST = 0 982 o SYMMETRIC = 1 984 11. References 986 11.1. Normative References 988 [1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized 989 MANET Packet/Message Format", Work In 990 Progress draft-ietf-manet-packetbb-03.txt, January 2007. 992 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 993 Levels", RFC 2119, BCP 14, March 1997. 995 11.2. Informative References 997 [3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 998 Protocol", RFC 3626, October 2003. 1000 Appendix A. Address Block TLV Combinations 1002 The algorithm for generating HELLO messages in Section 7 specifies 1003 which addresses MAY be included in the address blocks after the Local 1004 Interface Block, and with which associated TLVs. These TLVs may have 1005 Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type 1006 == LINK_STATUS may have three possible values (Value == HEARD, Value 1007 == SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may 1008 have two possible values (Value == SYMMETRIC or Value == LOST). When 1009 both TLVs are associated with the same address only certain 1010 combinations of these TLV values are necessary, and are the only 1011 combinations generated by the algorithm in Section 7. These 1012 combinations are indicated in Table 7. 1014 Cells labeled with "Yes" indicate the possible combinations which are 1015 generated by the algorithm in Section 7. Cells labeled with "No" 1016 indicate combinations not generated by the algorithm in Section 7, 1017 but which are correctly parsed and interpreted by the algorithm in 1018 Section 8. 1020 +----------------+----------------+----------------+----------------+ 1021 | | Type == | Type == | Type == | 1022 | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | 1023 | | (absent) | Value == | Value == LOST | 1024 | | | SYMMETRIC | | 1025 +----------------+----------------+----------------+----------------+ 1026 | Type == | No | Yes | Yes | 1027 | LINK_STATUS | | | | 1028 | (absent) | | | | 1029 | | | | | 1030 | Type == | Yes | Yes | Yes | 1031 | LINK_STATUS, | | | | 1032 | Value == HEARD | | | | 1033 | | | | | 1034 | Type == | Yes | No | No | 1035 | LINK_STATUS, | | | | 1036 | Value == | | | | 1037 | SYMMETRIC | | | | 1038 | | | | | 1039 | Type == | Yes | Yes | No | 1040 | LINK_STATUS, | | | | 1041 | Value == LOST | | | | 1042 +----------------+----------------+----------------+----------------+ 1044 Table 7 1046 Appendix B. HELLO Message Example 1048 An example HELLO message, sent by an originator node with a single 1049 MANET interface, is as follows. The message uses IPv4 (four octet) 1050 addresses without prefix TLVs. The message is sent with a full 1051 message header (message semantics octet is 0) with a hop limit of 1 1052 and a hop count of 0. The overall message length is 50 octets. 1054 The message contains a message TLV block with content length 8 octets 1055 containing two message TLVs, of types VALIDITY_TIME and 1056 INTERVAL_TIME. Each uses a TLV with semantics value 4, indicating 1057 that no start and stop indexes are included, and each has a value 1058 length of 1 octet. The values included (0x68 and 0x50) are time 1059 codes representing the default values of parameters H_HOLD_TIME and 1060 HELLO_INTERVAL, respectively (6 seconds and 2 seconds). 1062 The first address block contains 1 local interface address. The 1063 semantics octet value 2 indicates no address tail, and the head 1064 length of 4 octets indicates no address mid sections. This address 1065 block has no TLVs (TLV block content length 0 octets). 1067 The second, and last, address block contains 4 neighbor interface 1068 addresses. The semantics octet value 2 indicates no address tail, 1069 the head length of 3 octets indicates address mid sections of one 1070 octet each. The following TLV block (content length 7 octets) 1071 includes one LINK_STATUS TLV which reports the link status values of 1072 all reported neighbors in a single multivalue TLV: the first two 1073 addresses are HEARD, the third address is SYMMETRIC and the fourth 1074 address is LOST. The TLV semantics value of 20 indicates, in 1075 addition to that this is a multivalue TLV, that no start and stop 1076 indexes are included, since values for all addresses are included. 1077 The TLV value length of 4 octets indicates one octet per value per 1078 address. 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | 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| 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Originator Address | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 |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| 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 |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| 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 |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| 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |0 0 0 0 0 1 0 0| Head | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | 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| 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Head (cont) | Mid | Mid | Mid | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 |0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | SYMMETRIC | LOST | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Appendix C. Time TLVs 1112 This appendix specifies a general time TLV structure for expressing 1113 either single time values or a set of time values with each value 1114 associated with a range of distances. Furthermore, using this 1115 general time TLV structure, this document specifies the INTERVAL_TIME 1116 and VALIDITY_TIME TLVs, which are used by NHDP. 1118 C.1. Representing Time 1120 This document specifies a TLV structure in which time values are each 1121 represented in an 8 bit time code, one or more of which may be used 1122 in a TLV's value field. Of these 8 bits, the least significant four 1123 bits represent the mantissa (a), and the most significant four bits 1124 represent the exponent (b), so that: 1126 o time value = (1 + a/16) * 2^b * C 1128 o time code = 16 * b + a 1130 All nodes in the network MUST use the same value of C, which will be 1131 specified in seconds, hence so will be all time values. Note that 1132 ascending values of the time code represent ascending time values, 1133 time values may thus be compared by comparison of time codes. 1135 An algorithm for computing the time code representing the smallest 1136 representable time value not less than the time value t is: 1138 1. find the largest integer b such that t/C >= 2^b; 1140 2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest 1141 integer; 1143 3. if a == 16 then set b = b + 1 and set a = 0; 1145 4. if a and b are in the range 0 and 15 then the required time value 1146 can be represented by the time code 16 * b + a, otherwise it can 1147 not. 1149 The minimum time value that can be represented in this manner is C. 1150 The maximum time value that can be represented in this manner is 1151 63488 * C. 1153 C.2. General Time TLV Structure 1155 A Time TLV may be a packet, message or address block TLV. If it is a 1156 packet or message TLV then it must be a single value TLV as defined 1157 in [1]; if it is an address block TLV then it may be single value or 1158 multivalue TLV. The specific Time TLVs specified in this document, 1159 in Appendix C.3 are message, and hence single value, TLVs. Note that 1160 even a single value Time TLV may contain a multiple octet 1161 field. 1163 The purpose of a single value Time TLV is to allow a single time 1164 value to be determined by a node receiving an entity containing the 1165 Time TLV, based on its distance from the entity's originator. The 1166 Time TLV may contain information that allows that time value to be a 1167 function of distance, and thus different receiving nodes may 1168 determine different time values. If a receiving node will not be 1169 able to determine its distance from the originating node, then the 1170 form of this Time TLV with a single time code in a field (or 1171 single value subfield) SHOULD be used. 1173 The field of a single value Time TLV is specified, using the 1174 regular expression syntax of [1], by: 1176 = {