idnits 2.17.00 (12 Aug 2021) /tmp/idnits35614/draft-ietf-manet-dymo-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 4822 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: draft-ietf-manet-iana has been published as RFC 5498 == Outdated reference: draft-ietf-manet-packetbb has been published as RFC 5444 == Outdated reference: draft-ietf-manet-timetlv has been published as RFC 5497 == Outdated reference: draft-ietf-manet-nhdp has been published as RFC 6130 == Outdated reference: draft-ietf-ospf-multi-instance has been published as RFC 6549 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working I. Chakeres 3 Group CenGen 4 Internet-Draft C. Perkins 5 Intended status: Standards Track WiChorus 6 Expires: September 9, 2009 March 8, 2009 8 Dynamic MANET On-demand (DYMO) Routing 9 draft-ietf-manet-dymo-17 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 9, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Dynamic MANET On-demand (DYMO) routing protocol is intended for 48 use by mobile routers in wireless, multihop networks. DYMO 49 determines unicast routes among DYMO routers within the network in an 50 on-demand fashion, offering improved convergence in dynamic 51 topologies. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 7 60 4.2. DYMO Messages . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2.1. Generalized Packet and Message Structure . . . . . . . 9 62 4.2.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . 10 63 4.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 12 64 5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 14 66 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 15 67 5.1.2. Numerical Operations on OwnSeqNum . . . . . . . . . . 15 68 5.1.3. OwnSeqNum Rollover . . . . . . . . . . . . . . . . . . 15 69 5.1.4. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 15 70 5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 15 71 5.2.1. Judging Routing Information's Usefulness . . . . . . . 15 72 5.2.2. Creating or Updating a Route Table Entry with 73 Received Superior Routing Information . . . . . . . . 17 74 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 18 75 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 18 76 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 18 77 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 19 78 5.3.3. Intermediate DYMO Router RREP Creation . . . . . . . . 20 79 5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 21 80 5.3.5. Adding Additional Routing Information to a RM . . . . 24 81 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 25 82 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 26 83 5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 26 84 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 26 85 5.5.3. RERR Generation . . . . . . . . . . . . . . . . . . . 27 86 5.5.4. RERR Processing . . . . . . . . . . . . . . . . . . . 28 87 5.6. DYMO Identifier (DID) . . . . . . . . . . . . . . . . . . 29 88 5.7. Unknown Message & TLV Types . . . . . . . . . . . . . . . 29 89 5.8. Advertising Network Addresses . . . . . . . . . . . . . . 30 90 5.9. Simple Internet Attachment . . . . . . . . . . . . . . . . 30 91 5.10. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 31 92 5.11. DYMO Control Packet/Message Generation Limits . . . . . . 31 93 6. Configuration Parameters and Other Administrative Options . . 32 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 95 7.1. DYMO Message Type Specification . . . . . . . . . . . . . 33 96 7.2. Packet and Message TLV Type Specification . . . . . . . . 33 97 7.3. Address Block TLV Specification . . . . . . . . . . . . . 34 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 99 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 105 1. Overview 107 The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, 108 multihop unicast routing among participating DYMO routers. The basic 109 operations of the DYMO protocol are route discovery and route 110 maintenance. 112 During route discovery, the originator's DYMO router initiates 113 dissemination of a Route Request (RREQ) throughout the network to 114 find a route to the target's DYMO router. During this hop-by-hop 115 dissemination process, each intermediate DYMO router records a route 116 to the originator. When the target's DYMO router receives the RREQ, 117 it responds with a Route Reply (RREP) sent hop-by-hop toward the 118 originator. Each intermediate DYMO router that receives the RREP 119 creates a route to the target, and then the RREP is unicast hop-by- 120 hop toward the originator. When the originator's DYMO router 121 receives the RREP, routes have then been established between the 122 originating DYMO router and the target DYMO router in both 123 directions. 125 Route maintenance consists of two operations. In order to preserve 126 routes in use, DYMO routers extend route lifetimes upon successfully 127 forwarding a packet. In order to react to changes in the network 128 topology, DYMO routers monitor routers over which traffic is flowing. 129 When a data packet is received for forwarding and a route for the 130 destination is not known or the route is broken, then the DYMO router 131 of source of the packet is notified. A Route Error (RERR) is sent 132 toward the packet source to indicate the route to that particular 133 destination is invalid or missing. When the source's DYMO router 134 receives the RERR, it deletes the route. If the source's DYMO router 135 later receives a packet for forwarding to the same destination, it 136 will need to perform route discovery again for that destination. 138 DYMO uses sequence numbers to ensure loop freedom [Perkins99]. 139 Sequence numbers enable DYMO routers to determine the temporal order 140 of DYMO route discovery messages, thereby avoiding use of stale 141 routing information. 143 2. Applicability Statement 145 The DYMO routing protocol is designed for stub or disconnected mobile 146 ad hoc networks (MANETs). DYMO handles a wide variety of mobility 147 patterns by dynamically determining routes on-demand. DYMO also 148 handles a wide variety of traffic patterns. In networks with a large 149 number of routers, DYMO is best suited for sparse traffic scenarios 150 where routers forward packets to with only a small portion of the 151 other DYMO routers, due to the reactive nature of route discovery and 152 route maintenance. 154 DYMO is applicable to memory constrained devices, since very little 155 routing state is maintained in each DYMO router. Only routing 156 information related to active sources and destinations is maintained, 157 in contrast to most other more proactive routing protocols that 158 require routing information to all routers within the routing region 159 be maintained. 161 DYMO supports routers with multiple interfaces participating in the 162 MANET. DYMO routers can also perform routing on behalf of other 163 nodes, attached via participating or non-participating interfaces. 165 DYMO routers perform route discovery to find a route to a particular 166 destination. Therefore, DYMO routers MUST be configured to initiate 167 route discovery on behalf of certain sources and find routes to 168 certain destinations. When DYMO is the only protocol interacting 169 with the forwarding table, DYMO MAY be configured to perform route 170 discovery for all unknown unicast destinations. 172 DYMO MUST only utilizes bidirectional links. In the case of possible 173 unidirectional links, either blacklists ( see Section 7.2) or other 174 means (e.g. adjacency establishment with only neighboring routers 175 that have bidirectional communication as indicated by NHDP 176 [I-D.ietf-manet-nhdp]) of ensuring bi-directionality should be used. 177 Otherwise, persistent packet loss may occur. 179 The routing algorithm in DYMO may be operated at layers other than 180 the network layer, using layer-appropriate addresses. For operation 181 at other layers DYMO's routing algorithm likely will not need to 182 change. Although, modification of the packet/message format may be 183 required. 185 3. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 Additionally, this document uses some terminology from 192 [I-D.ietf-manet-packetbb]. 194 This document defines the following terminology: 196 Adjacency 197 A relationship formed between selected bi-directional neighboring 198 routers for the purpose of exchanging routing information. Not 199 every pair of neighboring routers become adjacent. Neighboring 200 routers may form an adjacency based several different pieces of 201 information or protocols; for example, exchange of DYMO routing 202 messages, other protocols (e.g. NDP [RFC4861] or NHDP 203 [I-D.ietf-manet-nhdp]), or manual configuration. 205 Distance (Dist) 206 A metric of the distance a message or piece of information has 207 traversed. The minimum value of distance is the number of IP hops 208 traversed. The maximum value is 65,535. 210 DYMO Identifier (DID) 211 A DID is maintained by each DYMO routing protocol instance 212 (ThisNode.DID), and the default value is zero (0). Each routing 213 message is tagged with its associated DID (MsgTLV.DID), unless 214 zero (0). Upon receipt of DYMO protocol message a DYMO routing 215 protocol instance SHOULD only process messages with a matching DID 216 value. 218 DYMO Sequence Number (SeqNum) 219 A DYMO Sequence Number is maintained by each DYMO router. This 220 sequence number is used by other DYMO routers to identify the 221 temporal order of routing information generated and ensure loop- 222 free routes. 224 Forwarding Route 225 A route that is used to forward data packets. Forwarding routes 226 are generally maintained in a forwarding information base (FIB) or 227 the kernel forwarding/routing table. 229 Multihop-capable Unicast IP Address 230 A multihop-capable unicast IP address is a unicast IP address that 231 when put into the IP.SoureAddress or IP.DestinationAddress field 232 is scoped sufficiently to be forwarded by a router. For example, 233 site-scoped or globally-scoped unicast IP addresses. 235 Originating Node (OrigNode) 236 The originating node is the source, its DYMO router creates a DYMO 237 control message on its behalf in an effort to disseminate some 238 routing information. The originating node is also referred to as 239 a particular message's originator. 241 Route Error (RERR) 242 A RERR message is used indicate that a DYMO router does not have 243 forwarding route to one or more particular addresses. 245 Route Reply (RREP) 246 A RREP message is used to disseminate routing information about 247 the RREP OrigNode, to the RREP TargetNode and the DYMO routers 248 between them. 250 Route Request (RREQ) 251 A RREQ message is issued to discover a valid route to a particular 252 destination address, called the RREQ TargetNode. When a DYMO 253 router processes a RREQ, it learns routing information on how to 254 reach the RREQ OrigNode. 256 Target Node (TargetNode) 257 The TargetNode is the ultimate destination of a message. 259 This Node (ThisNode) 260 ThisNode corresponds to the DYMO router currently performing a 261 calculation or processing a message. 263 Type-Length-Value structure (TLV) 264 A generic way to represent information, please see 265 [I-D.ietf-manet-packetbb] for additional information. 267 Unreachable Node (UnreachableNode) 268 An UnreachableNode is a node for which a forwarding route does not 269 exist. 271 4. Data Structures 273 4.1. Route Table Entry 275 The route table entry is a conceptual data structure. 276 Implementations may use any internal representation that conforms to 277 the semantics of a route as specified in this document. 279 Conceptually, a route table entry has the following fields: 281 Route.Address 282 The IP (host or network) destination address of the node(s) 283 associated with the routing table entry. 285 Route.Prefix 286 Indicates that the associated address is a network address, rather 287 than a host address. The value is the length of the netmask/ 288 prefix. 290 Route.SeqNum 291 The DYMO SeqNum associated with this routing information. 293 Route.NextHopAddress 294 The IP address of the adjacent DYMO router on the path toward the 295 Route.Address. 297 Route.NextHopInterface 298 The interface used to send packets toward the Route.Address. 300 Route.Forwarding 301 A flag indicating whether this Route can be used for forwarding 302 data packets. This flag MAY be provided for management and 303 monitoring. 305 Route.Broken 306 A flag indicating whether this Route is broken. This flag is set 307 if the next-hop becomes unreachable or in response to processing a 308 RERR (see Section 5.5.4). 310 The following field is optional: 312 Route.Dist 313 A metric indicating the distance traversed before reaching the 314 Route.Address node. 316 Not including optional information may cause performance degradation, 317 but it will not cause the protocol to operate incorrectly. 319 In addition to a route table data structure, each route table entry 320 may have several timers associated with the information. These 321 timers/timeouts are discussed in Section 5.2.3. 323 4.2. DYMO Messages 325 When describing DYMO protocol messages, it is necessary to refer to 326 fields in several distinct parts of the overall packet. These 327 locations include the IP or IPv6 header, the UDP header, and fields 328 from [I-D.ietf-manet-packetbb]. This document uses the following 329 notation conventions. Information found in the table. 331 +----------------------------+-------------------+ 332 | Information Location | Notational Prefix | 333 +----------------------------+-------------------+ 334 | IP header | IP. | 335 | UDP header | UDP. | 336 | packetbb message header | MsgHdr. | 337 | packetbb message TLV | MsgTLV. | 338 | packetbb address blocks | AddBlk. | 339 | packetbb address block TLV | AddTLV. | 340 +----------------------------+-------------------+ 342 Table 1 344 4.2.1. Generalized Packet and Message Structure 346 DYMO messages conform to the generalized packet and message format as 347 described in [I-D.ietf-manet-packetbb]. Here is a brief description 348 of the format. A packet is made up of messages. A message is made 349 up of a message header, message TLV block, and zero or more address 350 blocks. Each of the address blocks may also have an associated 351 address TLV block. 353 All DYMO messages specified in this document are sent using UDP to 354 the destination port MANET [I-D.ietf-manet-iana]. 356 Most DYMO messages are sent with the IP destination address set to 357 the link-local multicast address LL-MANET-ROUTERS 358 [I-D.ietf-manet-iana] unless otherwise stated. Therefore, all DYMO 359 routers SHOULD subscribe to LL-MANET-ROUTERS [I-D.ietf-manet-iana] 360 for receiving control packets. Note that multicast packets may be 361 sent via unicast. For example, this may occur for certain link-types 362 (non broadcast mediums), improved robustness, or manually configured 363 router adjacency. 365 Unicast DYMO messages (e.g. RREP) unless otherwise specified in this 366 document are sent with the IP destination set to the 367 Route.NextHopAddress of the route to the TargetNode. 369 The IPv4 TTL (IPv6 Hop Limit) field for all packets containing DYMO 370 messages is set to 255. If a packet is received with a value other 371 than 255, it is discarded. This mechanism helps to ensures packets 372 have not passed through any intermediate routers, and it is known as 373 GTSM [RFC5082]. 375 The length of an IP address (32 bits for IPv4 and 128 bits for IPv6) 376 inside a DYMO message depends on the IP packet header containing the 377 DYMO message/packet. For example, if the IP header uses IPv6 378 addresses then all addresses contained in the payload use IPv6 379 addresses of the same length. In the case of mixed IPv6 and IPv4 380 addresses, please use the methods specified in 381 [I-D.ietf-manet-packetbb]. 383 If a packet contains only a single DYMO message and no packet TLVs, 384 it need not include a packet-header [I-D.ietf-manet-packetbb]. 386 The aggregation of multiple messages into a packet is not specified 387 in this document, but if aggregation does occur the IP.SourceAddress 388 and IP.DestinationAddress of all contained messages MUST be the same. 390 Implementations MAY choose to temporarily delay transmission of 391 messages for the purpose of aggregation (into a single packet) or to 392 improve performance by using jitter [RFC5148]. 394 DYMO control packets SHOULD be given priority queue and channel 395 access. 397 4.2.2. Routing Messages (RM) - RREQ & RREP 399 Routing Messages (RMs) are used to disseminate routing information. 400 There are two DYMO message types that are considered to be routing 401 messages (RMs): RREQ and RREP. They contain very similar information 402 and function, but have slightly different processing rules. The main 403 difference between the two messages is that RREQ messages generally 404 solicit a RREP, whereas a RREP is the response to RREQ. 406 RM creation and processing are described in Section 5.3. 408 A RM requires the following information: 410 IP.SourceAddress 411 The IP address of the node currently sending this packet. This 412 field is generally filled automatically by the operating system 413 and should not require special handling. 415 IP.DestinationAddress 416 The IP address of the packet destination. For multicast RREQ the 417 IP.DestinationAddress is set to LL-MANET ROUTERS 418 [I-D.ietf-manet-iana]. For unicast RREQ and RREP the 419 IP.DestinationAddress is set to the NextHopAddress toward the RREP 420 TargetNode. 422 UDP.DestinationPort 423 By default, the UDP destination port is set to MANET 424 [I-D.ietf-manet-iana]. 426 MsgHdr.HopLimit 427 The remaining number of hops this message is allowed to traverse. 429 AddBlk.TargetNode.Address 430 The IP address of the message TargetNode. In a RREQ the 431 TargetNode is the destination address for which route discovery is 432 being performed. In a RREP the TargetNode is the RREQ OrigNode 433 address. The TargetNode address is the first address in a routing 434 message. 436 AddBlk.OrigNode.Address 437 The IP address of the originator and its associated prefix length. 438 In a RREQ the OrigNode is the source's address and prefix. In a 439 RREP the OrigNode is the RREQ TargetNode's address and prefix for 440 which a RREP is being generated. This address is the second 441 address in the message for RREQ. 443 OrigNode.AddTLV.SeqNum 444 The DYMO sequence number of the originator's DYMO router. 446 A RM may optionally include the following information: 448 TargetNode.AddTLV.SeqNum 449 The last known DYMO sequence number of the TargetNode. 451 TargetNode.AddTLV.Dist 452 The last known Distance to the TargetNode. 454 AddBlk.AdditionalNode.Address 455 The IP address of an additional node that can be reached via the 456 DYMO router adding this information. Each AdditionalNode.Address 457 MUST include its prefix. Each AdditionalNode.Address MUST also 458 have an associated Node.SeqNum in the address TLV block. 460 AdditionalNode.AddTLV.SeqNum 461 The DYMO sequence number associated with this routing information. 463 OrigNode.AddTLV.Dist 464 A metric of the distance to reach the associated OrigNode.Address. 465 This field is incremented by at least one at each intermediate 466 DYMO router. 468 AdditionalNode.AddTLV.Dist 469 A metric of the distance to reach the associated 470 AdditionalNode.Address. This field is incremented by at least one 471 at each intermediate DYMO router. 473 Example IPv4 RREQ 475 0 1 2 3 476 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 477 IP Header 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IP.SourceAddress | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | IP.DestinationAddress = LL-MANET-ROUTERS | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | IP TTL/HopLimit = 255 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 UDP Header 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Destination Port = MANET | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Message Header 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | RREQ-type |0|1|0|0|0|0|0|0| msg-size=23 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | msg-hoplimit | 495 +-+-+-+-+-+-+-+-+ 496 Message TLV Block 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | msg-tlv-block-size=0 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Message Body - Address Block 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |Number Addrs=2 |1|0|0|0|0| Rsv | HeadLength=3 | Head : 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 : Head (cont) | Target.Tail | Orig.Tail | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Message Body - Address Block TLV Block 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | tlv-block-size=6 |DYMOSeqNum-type|0|1|0|1|0|0|Rsv| 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 1 515 4.2.3. Route Error (RERR) 517 A RERR message is used to disseminate the information that a route is 518 not available for one or more particular IP addresses. 520 RERR creation and processing are described in Section 5.5. 522 A RERR requires the following information: 524 IP.SourceAddress 525 The IP address of the node currently sending this packet. This 526 field is generally filled automatically by the operating system 527 and should not require special handling. 529 IP.DestinationAddress 530 For multicast RERR messages, The IP address is set to LL-MANET- 531 ROUTERS [I-D.ietf-manet-iana]. For unicast RERR messages, The IP 532 address is set to the NextHopAddress. 534 UDP.DestinationPort 535 By default, the UDP destination port is set to MANET 536 [I-D.ietf-manet-iana]. 538 MsgHdr.HopLimit 539 The remaining number of hops this message is allowed to traverse. 541 AddBlk.UnreachableNode.Address 542 The IP address of an UnreachableNode and its associated prefix 543 length. Multiple unreachable addresses may be included in a RERR. 545 A Route Error may optionally include the following information: 547 UnreachableNode.AddTLV.SeqNum 548 The last known DYMO sequence number of the unreachable node. If a 549 SeqNum for an address is not included, it is assumed to be 550 unknown. This case occurs when a node receives a message to 551 forward to a destination for which it does not have any 552 information in its routing table. 554 Example IPv4 RERR 556 0 1 2 3 557 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 558 IP Header 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | IP.SourceAddress | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | IP.DestinationAddress = LL-MANET-ROUTERS | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | IP.TTL/HopLimit = 255 | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 UDP Header 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Destination Port = MANET | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Message Header 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | RERR-type |0|1|0|0|0|0|0|0| msg-size=15 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | msg-hoplimit | 575 +-+-+-+-+-+-+-+-+ 576 Message TLV Block 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | msg-tlv-block-size=0 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Message Body - Address Block 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |Number Addrs=1 |0|0|0|0|0| Rsv | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | UnreachableNode.Address | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Message Body - Address Block TLV Block 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | TLV-blk-size=0 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 2 593 5. Detailed Operation 595 5.1. DYMO Sequence Numbers 597 DYMO sequence numbers allow nodes to judge the freshness of routing 598 information and ensure loop freedom. 600 5.1.1. Maintaining A Node's Own Sequence Number 602 DYMO requires that each DYMO router in the network to maintain its 603 own DYMO sequence number (OwnSeqNum), a 16-bit unsigned integer. The 604 circumstances for ThisNode to incrementing its OwnSeqNum are 605 described in Section 5.3. 607 5.1.2. Numerical Operations on OwnSeqNum 609 When ThisNode increments its OwnSeqNum (as described in Section 5.3) 610 it MUST do so by treating the sequence number value as an unsigned 611 number. 613 5.1.3. OwnSeqNum Rollover 615 If the sequence number has been assigned to be the largest possible 616 number representable as a 16-bit unsigned integer (i.e., 65,535), 617 then the sequence number SHOULD be set to one (1) incremented. 619 5.1.4. Actions After OwnSeqNum Loss 621 A DYMO router SHOULD maintain its sequence number in persistent 622 storage. 624 If a DYMO router's OwnSeqNum is lost, it MUST take certain actions to 625 avoid creating routing loops. To prevent this possibility after 626 OwnSeqNum loss a DYMO router MUST wait for at least 627 ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing 628 protocol. If a DYMO control message is received during this waiting 629 period, the DYMO router SHOULD process it normally but MUST NOT 630 transmit or retransmit any DYMO messages. If a data packet is 631 received for forwarding to another destination during this waiting 632 period, the DYMO router MUST generate a RERR message indicating that 633 this route is not available and reset its waiting timeout. At the 634 end of the waiting period the DYMO router sets its OwnSeqNum to one 635 (1) and begins participating. 637 The longest a node need wait is ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the 638 end of the maximum waiting period a node SHOULD set its OwnSeqNum to 639 one (1) and begins participating. 641 5.2. DYMO Routing Table Operations 643 5.2.1. Judging Routing Information's Usefulness 645 Given a route table entry (Route.SeqNum, Route.Dist, and 646 Route.Broken) and new incoming routing information for a particular 647 node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/ 648 RREP), the quality of the new routing information is evaluated to 649 determine its usefulness. Incoming routing information is classified 650 as follows: 652 1. Stale 653 If Node.SeqNum - Route.SeqNum < 0 (using signed 16-bit arithmetic) 654 the incoming information is stale. Using stale routing 655 information is not allowed, since doing so might result in routing 656 loops. 658 (Node.SeqNum - Route.SeqNum < 0) 659 using signed 16-bit arithmetic 661 2. Loop-possible 662 If Node.SeqNum == Route.SeqNum the incoming information may cause 663 loops if used; in this case additional information MUST be 664 examined. If Route.Dist or Node.Dist is unknown or zero (0), then 665 the routing information is loop-possible. If Node.Dist > 666 Route.Dist + 1, then the routing information is loop-possible. 667 Using loop-possible routing information is not allowed, otherwise 668 routing loops may be formed. 670 (Node.SeqNum == Route.SeqNum) AND 671 ((Node.Dist is unknown) OR 672 (Route.Dist is unknown) OR 673 (Node.Dist > Route.Dist + 1)) 675 3. Inferior 676 In case of known equal SeqNum, the information is inferior in 677 multiple cases: (case i) if Node.Dist == Route.Dist + 1 (it is a 678 greater distance route) AND Route.Broken == false; (case ii) if 679 Node.Dist == Route.Dist (equal distance route) AND Route.Broken == 680 false AND this RM is a RREQ. The inferior condition stops 681 forwarding of RREQ with equivalent distance. 683 ((Node.SeqNum == Route.SeqNum) AND 684 (((Node.Dist == Route.Dist + 1) AND (Route.Broken == false)) OR 685 ((Node.Dist == Route.Dist) AND 686 (RM is RREQ) AND (Route.Broken == false)))) 688 4. Superior 689 Incoming routing information that does not match any of the above 690 criteria is loop-free and better than the information existing in 691 the routing table. Information is always superior if Node.SeqNum 692 - Route.SeqNum > 0 (using signed 16-bit arithmetic). In the case 693 of equal sequence numbers, the information is superior in multiple 694 cases: (case i) if Node.Dist < Route.Dist; (case ii) if Node.Dist 695 == Route.Dist + 1 AND Route.Broken == true (a broken route is 696 being repaired); (case iii) if Node.Dist == Route.Dist AND it is a 697 RREP (RREP with equal distance are forwarded) OR Route.Broken == 698 true (a broken route is being repaired). For completeness, we 699 provide the following (optimized) pseudo-code. 701 (Node.SeqNum - Route.SeqNum > 0) OR 702 using signed 16-bit arithmetic 703 ((Node.SeqNum == Route.SeqNum) AND 704 ((Node.Dist < Route.Dist) OR 705 ((Node.Dist == Route.Dist + 1) AND (Route.Broken == true)) OR 706 ((Node.Dist == Route.Dist) AND 707 ((RM is RREP) OR (Route.Broken == true))))) 709 5.2.2. Creating or Updating a Route Table Entry with Received Superior 710 Routing Information 712 The route table entry is populated with the following information: 714 1. the Route.Address is set to Node.Address, 716 2. the Route.Prefix is set to the Node.Prefix. 718 3. the Route.SeqNum is set to the Node.SeqNum, 720 4. the Route.NextHopAddress is set to the node that transmitted this 721 DYMO RM packet (i.e., the IP.SourceAddress), 723 5. the Route.NextHopInterface is set to the interface that this DYMO 724 packet was received on, 726 6. if known, the Route.Dist is set to the Node.Dist, 728 Fields without known values are not populated with any value. 730 Previous timers for this route table entry are removed. A timer for 731 the minimum delete timeout (ROUTE_AGE_MIN) is set to 732 ROUTE_AGE_MIN_TIMEOUT. A timer for the maximum delete timeout 733 (ROUTE_SEQNUM_AGE_MAX). ROUTE_SEQNUM_AGE_MAX is set to 734 Node.AddTLV.VALIDITY_TIME [I-D.ietf-manet-timetlv] if included; 735 otherwise, ROUTE_SEQNUM_AGE_MAX is set to 736 ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others 737 are described in Section 5.2.3. 739 At this point, a forwarding route should be created and the 740 Route.Forwarding flag set. Afterward, the route can be used to send 741 any queued data packets and forward any incoming data packets for 742 Route.Address. This route also fulfills any outstanding route 743 discovery attempts for Node.Address. 745 5.2.3. Route Table Entry Timeouts 747 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) 749 When a DYMO router transmits a RM, other DYMO routers expect the 750 transmitting DYMO router to have a forwarding route to the RM 751 originator. After updating a route table entry, it should be 752 maintained for at least ROUTE_AGE_MIN. Failure to maintain the 753 information might result in lost messages/packets, or in the worst 754 case scenario several duplicate messages. 756 After the ROUTE_AGE_MIN timeout a route can safely be deleted. 758 5.2.3.2. Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_MAX) 760 Sequence number information is time sensitive, and MUST be deleted 761 after a time in order to ensure loop-free routing. 763 After the ROUTE_AGE_MAX timeout a route's sequence number information 764 MUST be discarded. 766 5.2.3.3. Recently Used Timeout (ROUTE_USED) 768 When a route is used to forward data packets, this timer is set to 769 expire after ROUTE_USED_TIMEOUT. This operation is also discussed in 770 Section 5.5.2. 772 If a route has not been used recently, then a timer for ROUTE_DELETE 773 is set to ROUTE_DELETE_TIMEOUT. 775 5.2.3.4. Delete Information Timeout (ROUTE_DELETE) 777 As time progresses the likelihood that old routing information is 778 useful decreases, especially if the network nodes are mobile. 779 Therefore, old information should be deleted. 781 After the ROUTE_DELETE timeout, the routing table entry should be 782 deleted. If a forwarding route exists, it should be removed and the 783 Route.Forwarding flag unset. 785 5.3. Routing Messages 787 5.3.1. RREQ Creation 789 Before a DYMO router creates a RREQ it SHOULD increment its OwnSeqNum 790 by one (1) according to the rules specified in Section 5.1.2. 791 Incrementing OwnSeqNum will ensure that all nodes with existing 792 routing information will consider this new information superior to 793 existing routing table information. If the sequence number is not 794 incremented, certain DYMO routers might not consider this information 795 superior, if they have existing better routing information already. 797 First, ThisNode adds the AddBlk.TargetNode.Address to the RREQ; the 798 unicast IP Destination Address for which a forwarding route does not 799 exist. 801 If a previous value of the TargetNode.SeqNum is known (from a routing 802 table entry using longest-prefix matching), it SHOULD be placed in 803 TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a 804 TargetNode.SeqNum is not included, it is assumed to be unknown by 805 processing nodes. This operation ensures that no intermediate DYMO 806 routers reply, and ensures that the TargetNode's DYMO router 807 increments its sequence number. 809 Next, the node adds AddBlk.OrigNode.Address, its prefix, and the 810 OrigNode.AddTLV.SeqNum (OwnSeqNum) to the RM. 812 The OrigNode.Address is the address of the source for which this DYMO 813 router is initiating this route discovery. The OrigNode.Address MUST 814 be a unicast IP address. This information will be used by nodes to 815 create a route toward the OrigNode, enabling delivery of a RREP, and 816 eventually used for proper forwarding of data packets. 818 If OrigNode.Dist is included it is set to a number greater than zero 819 (0). 821 The MsgHdr.HopLimit SHOULD be set to MSG_HOPLIMIT. 823 For RREQ, the MsgHdr.HopLimit MAY be set in accordance with an 824 expanding ring search as described in [RFC3561] to limit the RREQ 825 propagation to a subset of the local network and possibly reduce 826 route discovery overhead. 828 The IP.DestinationAddress for multicast RREQ is set to LL-MANET- 829 ROUTERS. The IP.DestinationAddress for unicast RREQ is set to the 830 NextHopAddress. 832 Each DYMO routing protocol message SHOULD contain ThisNode.DID's 833 value in a message TLV (MsgTLV.DID). If ThisNode.DID value is zero 834 (0) it MAY be omitted. 836 5.3.2. RREP Creation 838 First, the AddBlk.TargetNode.Address is added to the RREP. The 839 TargetNode is the ultimate destination of this RREP; the RREQ 840 OrigNode.Address. 842 Next, AddBlk.OrigNode.Address and prefix are added to the RREP. The 843 AddBlk.OrigNode.Address is the RREQ TargetNode.Address. The 844 AddBlk.OrigNode.Address MUST be a unicast IP address. ThisNode 845 SHOULD advertise the largest known prefix containing 846 AddBlk.OrigNode.Address. 848 When the TargetNode's DYMO router creates a RREP, if the 849 TargetNode.SeqNum was not included in the RREQ, ThisNode MUST 850 increment its OwnSeqNum by one (1) according to the rules specified 851 in Section 5.1.2. 853 If TargetNode.SeqNum is included in the RM and TargetNode.SeqNum - 854 OwnSeqNum < 0 (using signed 16-bit arithmetic), OwnSeqNum SHOULD be 855 incremented by one (1) according to the rules specified in 856 Section 5.1.2. 858 If TargetNode.SeqNum is included in the RM and TargetNode.SeqNum == 859 OwnSeqNum (using signed 16-bit arithmetic) and Dist will not be 860 included in the RREP being generated, OwnSeqNum SHOULD be incremented 861 by one (1) according to the rules specified in Section 5.1.2. 863 If OwnSeqNum is not incremented the routing information might be 864 considered stale. In this case, the RREP might not reach the RREP 865 Target. 867 After any of the sequence number operations above, the RREP 868 OrigNode.AddTLV.SeqNum (OwnSeqNum) MUST also added to the RREP. 870 Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be 871 included and set accordingly. If OrigNode.Dist is included it is set 872 to a number greater than zero (0) and less than 65,535. The Distance 873 value will influence judgment of the routing information 874 (Section 5.2.1) against known information at other DYMO routers that 875 process this RM. 877 The MsgHdr.HopLimit is set to MSG_HOPLIMIT. 879 The IP.DestinationAddress for RREP is set to the IP address of the 880 Route.NextHopAddress for the route to the RREP TargetNode. 882 Each DYMO routing protocol message SHOULD contain ThisNode.DID's 883 value in a message TLV (MsgTLV.DID). If ThisNode.DID value is zero 884 (0) it MAY be omitted. 886 5.3.3. Intermediate DYMO Router RREP Creation 888 Sometimes a DYMO router other than the TargetNode's DYMO router (call 889 it an "intermediate DYMO router") has routing information that can 890 satisfy an incoming RREQ. An intermediate DYMO router can issue a 891 intermediate DYMO router RREP on behalf of the TargetNode's DYMO 892 router. 894 Before creating a intermediate DYMO router RREP, OwnSeqNum SHOULD be 895 incremented by one (1) according to the rules specified in 896 Section 5.1.2. 898 If OwnSeqNum is not incremented the routing information about 899 ThisNode might be considered stale by a processing DYMO router. In 900 this case, the RREP would not reach the RREP TargetNode. 902 When an intermediate DYMO router originates a RREP in response to a 903 RREQ on behalf of the TargetNode's DYMO router, it sends the RREP to 904 the RREQ OrigNode with additional routing information (Address, 905 Prefix, SeqNum, Dist, etc.) about the RREQ TargetNode. Appending 906 additional routing information is described in Section 5.3.5. 908 The Intermediate DYMO router SHOULD also issue a RREP to the RREQ 909 TargetNode, so that the RREQ TargetNode receives routing information 910 on how to reach the RREQ OrigNode. 912 When an intermediate DYMO router creates this RREP, it sends a RREP 913 to the RREQ TargetNode with additional routing information (Address, 914 Prefix, SeqNum, Dist, etc.) about the RREQ OrigNode. 916 5.3.4. RM Processing 918 First, ThisNode decides whether to process this message. If the 919 message contains a MsgTLV.DID it SHOULD match ThisNode.DID's value. 920 If the message does not contain a MsgTLV.DID it is assumed to be zero 921 (0) and SHOULD be discarded if ThisNode.DID's value is not zero (0). 923 Next, ThisNode MAY selectively process messages based upon 924 information in the message. ThisNode SHOULD only process messages 925 from adjacent DYMO routers. If ThisNode chooses not to process this 926 message, the message is discarded and further processing stopped. 928 ThisNode checks if the AddBlk.OrigNode.Address is a valid multihop- 929 capable (e.g. site or global scope) unicast IP address. If the 930 address is not a valid unicast IP address, the messages is discarded 931 and further processing stopped. 933 ThisNode also checks whether AddBlk.OrigNode.Address is an address 934 handled by this DYMO router. If this node is the originating DYMO 935 router, the RM is dropped. 937 ThisNode checks if the AddBlk.TargetNode.Address is a valid multihop- 938 capable unicast IP address. If the address is not a valid unicast IP 939 address, the messages is discarded and further processing stopped. 941 Next, ThisNode checks whether its routing table has an entry to the 942 AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If 943 a route with a valid Route.SeqNum does not exist, then the new 944 routing information is considered fresh and a new route table entry 945 is created and updated as described in Section 5.2.2. If a route 946 table entry does exists and it has a valid Route.SeqNum, the incoming 947 routing information is compared with the route table entry following 948 the procedure described in Section 5.2.1. If the incoming routing 949 information is considered superior, the route table entry is updated 950 as described in Section 5.2.2. 952 For each address (except the TargetNode) in the RM that includes 953 AddTLV.Dist information, the AddTLV.Dist information MAY be 954 incremented. The updated Distance value will influence judgment of 955 the routing information (Section 5.2.1). 957 If the resulting Distance value for the OrigNode is greater than 958 65,535, the message is discarded. If the resulting Distance value 959 for another node is greater than 65,535, the associated address and 960 its information are removed from the RM. 962 After processing the OrigNode's routing information, then each 963 address that is not the TargetNode should be considered for creating 964 and updating routes. Creating and updating routes to other nodes can 965 eliminate RREQ for those IP destinations, in the event that data 966 needs to be forwarded to the IP destination(s) now or in the near 967 future. 969 For each of the additional addresses considered, ThisNode first 970 checks the that the address is a multihop-capable unicast IP address. 971 If the address is not a unicast IP address, the address and all 972 related information MUST be removed. 974 If the routing table does not have a matching route with a valid 975 Route.SeqNum for this additional address using longest-prefix 976 matching exists, then a route is created and updated as described in 977 Section 5.2.2. If a route table entry exists with a valid 978 Route.SeqNum, the incoming routing information is compared with the 979 route table entry following the procedure described in Section 5.2.1. 980 If the incoming routing information is considered superior, the route 981 table entry is updated as described in Section 5.2.2. 983 If the routing information for an AdditionalNode.Address is not 984 considered superior, then it is removed from the RM. Removing this 985 information ensures that the information is not propagated. 987 At this point, if the routing information for the OrigNode was not 988 superior then this RM SHOULD be discarded and no further processing 989 of this message SHOULD be performed. 991 If the ThisNode is the DYMO router responsible for the TargetNode and 992 this RM is a RREQ, then ThisNode responds with a RREP to the RREQ 993 OrigNode (the new RREP's TargetNode). The procedure for issuing a 994 new RREP is described in Section 5.3.2. At this point, ThisNode need 995 not perform any more operations for this RM. 997 Alternatively, ThisNode MAY choose to distribute routing information 998 about ThisNode (the RREQ TargetNode) more widely, ThisNode MAY 999 optionally perform a route discovery; by issuing a RREQ with ThisNode 1000 listed as the TargetNode, using the procedure in Section 5.3.1. At 1001 this point, ThisNode need not perform any more operations for the 1002 original RM. 1004 If ThisNode is not the TargetNode, this RM is a RREQ, the RREQ 1005 contains the TargetNode.AddTLV.SeqNum, and ThisNode has a forwarding 1006 route to the TargetNode with a SeqNum where Route.TargetNode.SeqNum - 1007 RREQ.TargetNode.AddTLV.SeqNum >= 0 (using signed 16-bit arithmetic); 1008 then this node MAY respond with an intermediate DYMO router RREP. 1009 The procedure for performing intermediate DYMO router RREP is 1010 described in Section 5.3.3. If an intermediate DYMO router RREP is 1011 sent, ThisNode need not perform any more operations for the original 1012 RM. 1014 After processing a RM or creating a new RM, a node can append 1015 additional routing information to the RM, according to the procedure 1016 described in Section 5.3.5. The additional routing information can 1017 help reduce route discoveries at the expense of increased message 1018 size. 1020 For each address (except the TargetNode) in the RM that includes 1021 AddTLV.Dist information, the AddTLV.Dist information is incremented 1022 by at least one (1). The updated Distance value will influence 1023 judgment of the routing information (Section 5.2.1) against known 1024 information at other DYMO routers that process this RM. 1026 If the resulting Distance value for the OrigNode is greater than 1027 65,535, the message is discarded. If the resulting Distance value 1028 for another node is greater than 65,535, the associated address and 1029 its information are removed from the RM. 1031 Next, the MsgHdr.HopLimit is decremented by one (1). If this RM's 1032 MsgHdr.HopLimit is greater than or equal to one (1), ThisNode is not 1033 the TargetNode, AND this RM is a RREQ, then the current RM (altered 1034 by the procedure defined above) SHOULD be sent to the 1035 IP.DestinationAddress LL-MANET-ROUTERS [I-D.ietf-manet-iana]. If the 1036 RREQ is unicast, the IP.DestinationAddress is set to the 1037 NextHopAddress. 1039 If this RM's MsgHdr.HopLimit is greater than or equal to one (1), 1040 ThisNode is not the TargetNode, AND this RM is a RREP, then the 1041 current RM is sent to the Route.NextHopAddress for the RREP's 1042 TargetNode.Address. If no forwarding route exists to Target.Address, 1043 then a RERR SHOULD be issued to the OrigNode of the RREP. 1045 By sending the updated RM ThisNode is advertising that it will 1046 provide routing for IP addresses contained in the outgoing RM based 1047 on the information enclosed. ThisNode MAY choose not to send the RM, 1048 though not resending this RM could decrease connectivity in the 1049 network or result in a non-shortest distance path. 1051 Some examples of why ThisNode might choose to not re-issue a RM are: 1052 if ThisNode does not want to advertise routing for the contained IP 1053 addresses because it is already heavily loaded; if ThisNode has 1054 already issued nearly identical routing information (e.g. ThisNode 1055 had recently issued a RM with nearly the same distance); or if 1056 ThisNode is low on energy and does not want to expend energy for 1057 control message sending or packet forwarding. This type of advanced 1058 behavior is not defined in this specification. 1060 5.3.5. Adding Additional Routing Information to a RM 1062 Appending routing information can alleviate route discovery attempts 1063 to the nodes whose information is included, if other DYMO routers use 1064 this information to update their routing tables. 1066 DYMO routers can append routing information to a RM. This option 1067 should be administratively configurable or intelligently controlled.o 1069 Prior to appending an address controlled by this DYMO router to a RM, 1070 ThisNode MAY increment its OwnSeqNum as defined in Section 5.1.2. If 1071 OwnSeqNum is not incremented the appended routing information might 1072 not be considered superior, when received by nodes with existing 1073 routing information. Incrementation of the sequence number when 1074 appending information to an RM in transit should be administratively 1075 configurable or intelligently controlled. 1077 If an address controlled by this DYMO router includes ThisNode.Dist, 1078 it is set to a number greater than zero (0). 1080 For added addresses (and their prefixes) not controlled by this DYMO 1081 router, Route.Dist can be included if known. If Route.Dist is not 1082 known, it MUST NOT be included. 1084 MaxAge information about the appended address(es) MUST be included. 1086 Additional information (e.g. SeqNum and Dist) about any appended 1087 address(es) SHOULD be included. 1089 Note that, the routing information about the TargetNode MUST NOT be 1090 added. Also, duplicate address entries SHOULD NOT be added. 1091 Instead, only the best routing information (Section 5.2.1) for a 1092 particular address SHOULD be included. 1094 5.4. Route Discovery 1096 When a source's DYMO router needs to forward a data packet on behalf 1097 of an attached node and it does not have a forwarding route to the 1098 data packet's unicast IP destination address, ThisNode sends a RREQ 1099 (described in Section 5.3.1) to discover a route to the particular 1100 destination (TargetNode). 1102 After issuing a RREQ, the OrigNode DYMO router waits for a route to 1103 be created to the TargetNode. If a route is not created within 1104 RREQ_WAIT_TIME, ThisNode may again try to discover a route by issuing 1105 another RREQ using the procedure defined in Section 5.3.1 again. 1107 To reduce congestion in a network, repeated attempts at route 1108 discovery for a particular TargetNode SHOULD utilize an exponential 1109 backoff. 1111 For example, the first time a DYMO router issues a RREQ, it waits 1112 RREQ_WAIT_TIME for a route to the TargetNode. If a route is not 1113 found within that time, the DYMO router MAY send another RREQ. If a 1114 route is not found within two (2) times the current waiting time, 1115 another RREQ may be sent, up to a total of RREQ_TRIES. For each 1116 additional attempt, the waiting time for the previous RREQ is 1117 multiplied by two (2) so that the waiting time conforms to a binary 1118 exponential backoff. 1120 Data packets awaiting a route SHOULD be buffered by the source's DYMO 1121 router. This buffer SHOULD have a fixed limited size 1122 (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES) and older data packets 1123 SHOULD be discarded first. 1125 Buffering of data packets can have both positive and negative 1126 effects, and therefore buffer settings SHOULD be administratively 1127 configurable or intelligently controlled. 1129 If a route discovery has been attempted RREQ_TRIES times without 1130 receiving a route to the TargetNode, all data packets destined for 1131 the corresponding TargetNode are dropped from the buffer and a 1132 Destination Unreachable ICMP message should be delivered to the 1133 source. 1135 5.5. Route Maintenance 1137 A RERR SHOULD be issued if a data packet is to be forwarded and it 1138 cannot be delivered to the next-hop because no forwarding route for 1139 the IP.DestinationAddress exists; RERR generation is described in 1140 Section 5.5.3. 1142 Upon this condition, an ICMP Destination Unreachable message SHOULD 1143 NOT be generated unless this router is responsible for the 1144 IP.DestinationAddress and that IP.DestinationAddress is known to be 1145 unreachable. 1147 In addition to inability to forward a data packet, a RERR SHOULD be 1148 issued immediately after detecting a broken link of an forwarding 1149 route to quickly notify DYMO routers that a link break occurred and 1150 that certain routes are no longer available. If the route with the 1151 broken link has not been used recently (indicated by ROUTE_USED), the 1152 RERR SHOULD NOT be generated. 1154 5.5.1. Active Link Monitoring 1156 Nodes MUST monitor next-hop links on forwarding routes. This 1157 monitoring can be accomplished by one or several mechanisms, 1158 including: 1160 o Link layer feedback 1162 o Neighborhood discovery [I-D.ietf-manet-nhdp] 1164 o Route timeout 1166 o Other monitoring mechanisms or heuristics 1168 Upon determining that a link is broken or the next-hop is 1169 unreachable, ThisNode MUST remove the affected forwarding routes 1170 (those with an unreachable next-hop) and unset the Route.Forwarding 1171 flag. ThisNode also flags the associated routes in DYMO's routing 1172 table as Broken. For each broken route a timer for ROUTE_DELETE is 1173 set to ROUTE_DELETE_TIMEOUT. 1175 5.5.2. Updating Route Lifetimes During Packet Forwarding 1177 To avoid removing the forwarding route to reach the IP.SourceAddress, 1178 ThisNode SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for 1179 the route to the IP.SourceAddress upon receiving a data packet. If a 1180 timer for ROUTE_DELETE is set, it is removed. 1182 To avoid removing the forwarding route to the IP.DestinationAddress 1183 that is being used, ThisNode SHOULD set a timeout (ROUTE_USED) to 1184 ROUTE_USED_TIMEOUT for the route to the IP.DestinationAddress upon 1185 sending a data packet. If a timer for ROUTE_DELETE is set, it is 1186 removed. 1188 5.5.3. RERR Generation 1190 A RERR informs DYMO routers that a route to certain destinations is 1191 not available through ThisNode. 1193 When creating a new RERR, the address of first UnreachableNode 1194 (IP.DestinationAddress from a data packet or RREP.TargetNode.Address) 1195 is inserted into an Address Block AddBlk.UnreachableNode.Address. If 1196 a prefix is known for the UnreachableNode.Address, it SHOULD be 1197 included. Otherwise, the UnreachableNode.Address assumed to be a 1198 host address with a full length prefix. If a value for the 1199 UnreachableNode's SeqNum (UnreachableNode.AddTLV.SeqNum) is known, it 1200 SHOULD be placed in the RERR. The MsgHdr.HopLimit is set to 1201 MSG_HOPLIMIT. 1203 Additional UnreachableNodes that require the same unavailable link 1204 (routes with the same Route.NextHopAddress and 1205 Route.NextHopInterface) SHOULD be added to the RERR, as additional 1206 AddBlk.UnreachableNode.Address entries with their associated prefix. 1207 The SeqNum if known SHOULD also be included. Appending 1208 UnreachableNode information notifies each processing node of 1209 additional routes that are no longer available. This option SHOULD 1210 be administratively configurable or intelligently controlled. 1212 If SeqNum information is not known or not included in the RERR, all 1213 nodes processing the RERR will assume their routing information 1214 associated with the UnreachableNode is no longer valid and flag those 1215 routes as broken. 1217 Each DYMO routing protocol message SHOULD contain ThisNode.DID's 1218 value in a message TLV (MsgTLV.DID). If ThisNode.DID value is zero 1219 (0) it MAY be omitted. 1221 A multicast RERR is sent to the IP.DestinationAddress LL-MANET- 1222 ROUTERS [I-D.ietf-manet-iana]. Sending the RERR to the LL-MANET- 1223 ROUTERS address notifies all nearby DYMO routers that might depend on 1224 the now broken link. If the RERR is unicast, the 1225 IP.DestinationAddress is set to the NextHopAddress. 1227 At this point, the packet or message that forced generation of this 1228 RERR SHOULD be discarded. 1230 5.5.4. RERR Processing 1232 First, ThisNode decides whether to process this message. If the 1233 message contains a MsgTLV.DID it SHOULD match ThisNode.DID's value. 1234 If the message does not contain a MsgTLV.DID it is assumed to be zero 1235 (0) and SHOULD be discarded if ThisNode.DID's value is not zero (0). 1237 Next, ThisNode MAY selectively process messages based upon 1238 information in the message. ThisNode MAY choose to only process 1239 messages from adjacent DYMO routers. If ThisNode chooses not to 1240 process this message, the message is discarded and further processing 1241 stopped. 1243 When a DYMO router processes a RERR, it processes each 1244 UnreachableNode's information. The processing DYMO router removes 1245 the forwarding route, unsets the Route.Forwarding flag, sets the 1246 Route.Broken flag, and a timer for ROUTE_DELETE is set to 1247 ROUTE_DELETE_TIMEOUT for each UnreachableNode.Address found using 1248 longest prefix matching that meet all of the following conditions: 1250 1. The UnreachableNode.Address is a multihop-capable unicast IP 1251 address. 1253 2. The Route.NextHopAddress is the same as the RERR 1254 IP.SourceAddress. 1256 3. The Route.NextHopInterface is the same as the interface on which 1257 the RERR was received. 1259 4. The Route.SeqNum is zero (0), unknown, OR the 1260 UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - 1261 UnreachableNode.SeqNum <= 0 (using signed 16-bit arithmetic). 1263 During processing if Route.SeqNum is zero (0) or unknown and 1264 UnreachableNode.SeqNum exists in the RERR, then Route.SeqNum MAY be 1265 set to UnreachableNode.SeqNum. Setting Route.SeqNum can reduce 1266 future RRER processing and forwarding. 1268 Each UnreachableNode that did not result in a broken route is removed 1269 from the RERR, since propagation of this information will not result 1270 in any benefit. 1272 Each UnreachableNode that did result in a broken route SHOULD remain 1273 in the RERR. 1275 If any UnreachableNode was removed, all other information (AddTLVs) 1276 associated with the removed address(es) MUST also removed. 1278 After processing if Route.SeqNum is known and an 1279 UnreachableNode.SeqNum is not included in the RERR, then Route.SeqNum 1280 (i.e. UnreachableNode.SeqNum) MAY be added to the RERR. Including 1281 UnreachableNode.SeqNum can reduce future RRER processing and 1282 forwarding. 1284 If no UnreachableNode addresses remain in the RERR, no other 1285 processing is required and the RERR is discarded. 1287 If processing continues, the MsgHdr.HopLimit is decremented by one 1288 (1). Further, if this RERR's new MsgHdr.HopLimit is greater than one 1289 (1) and at least one unreachable node address remains in the RERR, 1290 then the updated RERR SHOULD be sent. 1292 A multicast RERR is sent to the IP.DestinationAddress LL-MANET- 1293 ROUTERS [I-D.ietf-manet-iana]. If the RERR is unicast, the 1294 IP.DestinationAddress is set to the NextHopAddress. 1296 5.6. DYMO Identifier (DID) 1298 Each DYMO routing protocol instance MUST have an associated DYMO 1299 Identifier (DID). The default value is zero (0). The DID value 1300 should be administratively configured. 1302 Each DYMO routing protocol message sent SHOULD contain its associated 1303 DID in a message TLV. If the DID value is zero (0) it MAY be 1304 omitted. 1306 Upon receipt of DYMO protocol message a DYMO routing protocol 1307 instance SHOULD only process messages with a DID (MsgTLV.DID) value 1308 matching its own DID (ThisNode.DID). 1310 The DID allows multiple DYMO routing protocol instances to operate 1311 over the same links and same node independently. 1313 The DID fulfills a function similar to OSPF Instance ID [RFC2740] 1314 [I-D.ietf-ospf-multi-instance], OSPF Area ID [RFC2328] [RFC2740], 1315 and/or the MANET_ID TLV [I-D.chakeres-manet-manetid]. 1317 5.7. Unknown Message & TLV Types 1319 If a message with an unknown type is received, the message is 1320 discarded. 1322 For processing of messages that contain unknown TLV types, operation 1323 should be administratively controlled. 1325 5.8. Advertising Network Addresses 1327 DYMO routers advertise specify the prefix length for each advertised 1328 address. Any nodes (other than the advertising DYMO router) within 1329 the advertised prefix MUST NOT participate in the DYMO protocol 1330 directly. For example, A.B.C.1 with a prefix length of 24 indicates 1331 all nodes with the matching A.B.C.X are reachable through the DYMO 1332 router with address A.B.C.1. 1334 5.9. Simple Internet Attachment 1336 Simple Internet attachment consists of a stub network of MANET 1337 routers connected to the Internet via a single Internet DYMO router 1338 (IDR). The Internet may be connected via multiple DYMO routers, but 1339 such behavior is not specified in this document. 1341 The IDR is responsible for responding to RREQs for DYMO routers on 1342 behalf of TargetNodes on the Internet, as well as delivering packets 1343 to destinations on the Internet. 1345 /--------------------------\ 1346 / Internet \ 1347 \ / 1348 \------------+-------------/ 1349 | 1350 Routable & | 1351 Topologically | A.B.C.X/24 1352 Correct | 1353 Prefix | 1354 +-----+-----+ 1355 | Internet | 1356 /------| DYMO |--------\ 1357 / | Router | \ 1358 / | A.B.C.1 | \ 1359 | +-----------+ | 1360 | DYMO Region | 1361 | | 1362 | +--------------+ | 1363 | | DYMO Router | | 1364 | | A.B.C.2 | | 1365 | +--------------+ | 1366 | +--------------+ | 1367 | | DYMO Router | | 1368 | | A.B.C.3 | | 1369 \ +--------------+ / 1370 \ / 1371 \---------------------------/ 1372 Figure 3: Simple Internet Attachment Example 1374 DYMO routers wishing to be reachable from nodes in the Internet MUST 1375 have IP addresses within the IDR's routable and topologically correct 1376 prefix. Given a node with a routeable address or care-of address 1377 handled by the IDR, the IDR is responsible for routing and forwarding 1378 packets received from the Internet destined for nodes inside its 1379 MANET. 1381 When DYMO router within the MANET want to send packets to a node on 1382 the Internet, they simply issue RREQ for those IP Destination 1383 Addresses; using normal DYMO route discovery. The IDR is responsible 1384 for properly responding to RREQ on behalf of the Internet 1385 destinations, and maintaining their associated sequence number(s). 1387 For an IDR and other DYMO routers that maintain the sequence number 1388 on behalf of other nodes, these routers MUST know the IP addresses 1389 for which they MUST generate DYMO messages and maintain OwnSeqNum. 1390 Likewise, they MUST be capable of advertising an address within the 1391 same prefix as these IP addresses. Alternatively, they may behave as 1392 a proxy on behalf of Internet destinations. 1394 5.10. Multiple Interfaces 1396 DYMO may be used with multiple interfaces; therefore, the particular 1397 interface over which packets arrive MUST be known whenever a packet 1398 is received. Whenever a new route is created, the interface through 1399 which the Route.Address can be reached is also recorded in the route 1400 table entry. 1402 When multiple interfaces are available, a node transmitting a 1403 multicast packet with IP.DestinationAddress set to LL-MANET-ROUTERS 1404 SHOULD send the packet on all interfaces that have been configured 1405 for DYMO operation. 1407 Similarly, DYMO routers should subscribe to LL-MANET-ROUTERS on all 1408 their DYMO interfaces. 1410 5.11. DYMO Control Packet/Message Generation Limits 1412 To ensure predictable control overhead, DYMO router's rate of packet/ 1413 message generation SHOULD be limited. The rate and algorithm for 1414 limiting messages is left to the implementor and should be 1415 administratively configurable or intelligently controlled. DYMO 1416 control messages SHOULD be discarded in the following order of 1417 preferences RREQ, RREP, and finally RERR. 1419 6. Configuration Parameters and Other Administrative Options 1421 Suggested Parameter Values 1423 +------------------------------+-------------------+ 1424 | Name | Value | 1425 +------------------------------+-------------------+ 1426 | MSG_HOPLIMIT | 10 hops | 1427 | ROUTE_TIMEOUT | 5 seconds | 1428 | ROUTE_AGE_MIN_TIMEOUT | 1 second | 1429 | ROUTE_SEQNUM_AGE_MAX_TIMEOUT | 60 seconds | 1430 | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | 1431 | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | 1432 | ROUTE_RREQ_WAIT_TIME | 2 seconds | 1433 | RREQ_TRIES | 3 tries | 1434 | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | 1435 +------------------------------+-------------------+ 1437 Table 2 1439 These suggested values work well for small and medium well connected 1440 networks with moderate topology changes. These parameters SHOULD be 1441 administratively configurable for the network where DYMO is used. 1442 Ideally, for networks with frequent topology changes the DYMO 1443 parameters should be adjusted using either experimentally determined 1444 values or dynamic adaptation. For example, in networks with 1445 infrequent topology changes ROUTE_USED_TIMEOUT may be set to a much 1446 larger value. 1448 In addition to the parameters above several administrative options 1449 exist. Many of these options can be administratively controlled, but 1450 they may be better served by intelligent control. The following 1451 table enumerates several of the options. 1453 Important Settings 1455 +------------------------+------------------------------------------+ 1456 | Name | Description | 1457 +------------------------+------------------------------------------+ 1458 | RESPONSIBLE_ADDRESSES | List of addresses, and their associated | 1459 | | prefix, for which this DYMO router is | 1460 | | responsible. | 1461 | DYMO_INTERFACES | List of the interfaces participating in | 1462 | | DYMO routing protocol. | 1463 +------------------------+------------------------------------------+ 1465 Table 3 1467 Note: several fields have limited size (bits or bytes) these sizes 1468 and their encoding may place specific limitations on the values that 1469 can be set. For example, MsgHdr.HopLimit is a 8-bit field and 1470 therefore MSG_HOPLIMIT cannot be larger than 255. 1472 7. IANA Considerations 1474 In its default mode of operation, DYMO uses the UDP port MANET 1475 [I-D.ietf-manet-iana] to carry protocol packets. DYMO also uses the 1476 link-local multicast address LL-MANET-ROUTERS [I-D.ietf-manet-iana]. 1478 This section specifies several messages types, message tlv-types, and 1479 address tlv-types. 1481 7.1. DYMO Message Type Specification 1483 DYMO Message Types 1485 +------------------------+----------+ 1486 | Name | Type | 1487 +------------------------+----------+ 1488 | Route Request (RREQ) | 10 - TBD | 1489 | Route Reply (RREP) | 11 - TBD | 1490 | Route Error (RERR) | 12 - TBD | 1491 +------------------------+----------+ 1493 Table 4 1495 7.2. Packet and Message TLV Type Specification 1497 Packet TLV Types 1499 +-------------------+------+--------+-------------------------------+ 1500 | Name | Type | Length | Value | 1501 +-------------------+------+--------+-------------------------------+ 1502 | Unicast Response | 10 - | 0 | Indicates to the processing | 1503 | Request | TBD | octets | node that the previous hop | 1504 | | | | (IP.SourceAddress) expects a | 1505 | | | | unicast message within | 1506 | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | 1507 | | | | Any unicast packet will serve | 1508 | | | | this purpose, and it MAY be | 1509 | | | | an ICMP REPLY message. If a | 1510 | | | | message is not sent, then the | 1511 | | | | previous hop can assume that | 1512 | | | | the link is unidirectional | 1513 | | | | and MAY blacklist the link to | 1514 | | | | this node. | 1515 +-------------------+------+--------+-------------------------------+ 1517 Table 5 1519 7.3. Address Block TLV Specification 1521 Address Block TLV Types 1523 +---------------+--------------+--------+---------------------------+ 1524 | Name | Type | Length | Value | 1525 +---------------+--------------+--------+---------------------------+ 1526 | DYMO | 9 - TBD | DID | ThisNode.DID's value. | 1527 | Identifier | | length | More information can be | 1528 | (DID) | | | found in Section 5.6 | 1529 | DYMO Sequence | 10 - TBD | up to | The DYMO sequence num | 1530 | Number | | 2 | associated with this | 1531 | (DYMOSeqNum) | | octets | address. The sequence | 1532 | | | | number may be the last | 1533 | | | | known sequence number. | 1534 | Distance | 11 - TBD | up to | A metric of the distance | 1535 | | | 2 | traversed by the | 1536 | | | octets | information associated | 1537 | | | | with this address. | 1538 | VALIDITY_TIME | TBD | | The maximum amount of | 1539 | - AKA MaxAge | [I-D.ietf-ma | | time that information can | 1540 | | n et-timetlv | | be maintained before | 1541 | | ] | | being deleted. The | 1542 | | | | VALIDITY_TIME TLV is | 1543 | | | | defined in | 1544 | | | | [I-D.ietf-manet-timetlv]. | 1545 +---------------+--------------+--------+---------------------------+ 1546 Table 6 1548 8. Security Considerations 1550 This document does not mandate any specific security measures. 1551 Instead, this section describes various security considerations and 1552 potential avenues to secure DYMO routing. 1554 The most important security mechanisms for DYMO routing are 1555 integrity/authentication and confidentiality. 1557 In situations where routing information or router identity are 1558 suspect, integrity and authentication techniques SHOULD be applied to 1559 DYMO messages. In these situations, routing information that is 1560 distributed over multiple hops SHOULD also verify the integrity and 1561 identity of information based on originator of the routing 1562 information. 1564 A digital signature could be used to identify the source of DYMO 1565 messages and information, along with its authenticity. A nonce or 1566 timestamp SHOULD also be used to protect against replay attacks. 1567 S/MIME and OpenPGP are two authentication/integrity protocols that 1568 could be adapted for this purpose. 1570 In situations where confidentiality of DYMO messages is important, 1571 cryptographic techniques SHOULD be applied. 1573 In certain situations, like sending a RREP or RERR, a DYMO router 1574 could include proof that it has previously received valid routing 1575 information to reach the destination, at one point of time in the 1576 past. In situations where routers are suspected of transmitting 1577 maliciously erroneous information, the original routing information 1578 along with its security credentials SHOULD be included. 1580 Note that if multicast is used, any confidentiality and integrity 1581 algorithms used must permit multiple receivers to process the 1582 message. 1584 9. Acknowledgments 1586 DYMO is a descendant of the design of previous MANET reactive 1587 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 1588 previous MANET reactive protocols stem from research and 1589 implementation experiences. Thanks to Elizabeth Belding-Royer for 1590 her long time authorship of DYMO. Additional thanks to Luke Klein- 1591 Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon 1592 Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain 1593 Thouvenin, Tronje Krop, Henner Jakob, Alexandru Petrescu, Christoph 1594 Sommer, Cong Yuan, Lars Kristensen, and Derek Atkins for reviewing of 1595 DYMO, as well as several specification suggestions. 1597 10. References 1599 10.1. Normative References 1601 [I-D.ietf-manet-iana] 1602 Chakeres, I., "IANA Allocations for MANET Protocols", 1603 draft-ietf-manet-iana-07 (work in progress), 1604 November 2007. 1606 [I-D.ietf-manet-packetbb] 1607 Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1608 "Generalized MANET Packet/Message Format", 1609 draft-ietf-manet-packetbb-17 (work in progress), 1610 November 2008. 1612 [I-D.ietf-manet-timetlv] 1613 Clausen, T. and C. Dearlove, "Representing multi-value 1614 time in MANETs", draft-ietf-manet-timetlv-08 (work in 1615 progress), September 2008. 1617 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1618 RFC 1812, June 1995. 1620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1621 Requirement Levels", BCP 14, RFC 2119, March 1997. 1623 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1624 Pignataro, "The Generalized TTL Security Mechanism 1625 (GTSM)", RFC 5082, October 2007. 1627 10.2. Informative References 1629 [I-D.chakeres-manet-manetid] 1630 Chakeres, I., "MANET_ID TLV", 1631 draft-chakeres-manet-manetid-03 (work in progress), 1632 February 2008. 1634 [I-D.ietf-manet-nhdp] 1635 Clausen, T., Dearlove, C., and J. Dean, "MANET 1636 Neighborhood Discovery Protocol (NHDP)", 1637 draft-ietf-manet-nhdp-07 (work in progress), July 2008. 1639 [I-D.ietf-ospf-multi-instance] 1640 Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi- 1641 Instance Extensions", draft-ietf-ospf-multi-instance-00 1642 (work in progress), February 2009. 1644 [Perkins99] 1645 Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand 1646 Distance Vector (AODV) Routing", Proceedings of the 2nd 1647 IEEE Workshop on Mobile Computing Systems and 1648 Applications, New Orleans, LA, pp. 90-100, February 1999. 1650 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1652 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1653 RFC 2740, December 1999. 1655 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1656 Demand Distance Vector (AODV) Routing", RFC 3561, 1657 July 2003. 1659 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 1660 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 1661 IPv4", RFC 4728, February 2007. 1663 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1664 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1665 September 2007. 1667 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 1668 Considerations in Mobile Ad Hoc Networks (MANETs)", 1669 RFC 5148, February 2008. 1671 Authors' Addresses 1673 Ian D Chakeres 1674 CenGen 1675 9250 Bendix Road North 1676 Columbia, Maryland 21045 1677 USA 1679 Email: ian.chakeres@gmail.com 1680 URI: http://www.ianchak.com/ 1681 Charles E. Perkins 1682 WiChorus Inc. 1683 3590 North First Street, Suite 300 1684 San Jose, CA 95134 1685 USA 1687 Phone: +1-408-421-1172 1688 Email: charliep@computer.org