idnits 2.17.1 draft-ietf-manet-dymo-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1401. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a node's OwnSeqNum is lost, it must take certain actions to avoid creating routing loops. To prevent this possibility after OwnSeqNum loss a node MUST wait for at least ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing protocol. If a DYMO control message is received during this waiting period, the node SHOULD process it normally but MUST not transmit or retransmit any DYMO messages. If a data packet is received for forwarding to another destination during this waiting period, the node MUST generate a RERR message indicating that this route is not available and reset its waiting timeout. At the end of the waiting period a node sets its OwnSeqNum to one (1). -- 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 6285 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-02 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Boeing 4 Internet-Draft C. Perkins 5 Intended status: Standards Track Nokia 6 Expires: August 13, 2007 February 9, 2007 8 Dynamic MANET On-demand (DYMO) Routing 9 draft-ietf-manet-dymo-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 13, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Dynamic MANET On-demand (DYMO) routing protocol is intended for 43 use by mobile nodes in wireless, multihop networks. It offers 44 adaptation to changing network topology and determines unicast routes 45 between nodes within the network on-demand. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 6 54 4.2. DYMO Messages . . . . . . . . . . . . . . . . . . . . . . 7 55 4.2.1. Generalized MANET Packet and Message Structure . . . . 7 56 4.2.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . 8 57 4.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 10 58 5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 12 59 5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 12 60 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 12 61 5.1.2. Incrementing OwnSeqNum . . . . . . . . . . . . . . . . 13 62 5.1.3. OwnSeqNum Rollover . . . . . . . . . . . . . . . . . . 13 63 5.1.4. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 13 64 5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 13 65 5.2.1. Judging Routing Information's Usefulness . . . . . . . 13 66 5.2.2. Creating or Updating a Route Table Entry with New 67 Routing Information . . . . . . . . . . . . . . . . . 15 68 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 15 69 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 17 70 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 17 71 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 18 72 5.3.3. Intermediate Node RREP Creation . . . . . . . . . . . 18 73 5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 19 74 5.3.5. Adding Additional Routing Information to a RM . . . . 20 75 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 21 76 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 22 77 5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 22 78 5.5.2. Updating Route Lifetimes during Packet Forwarding . . 22 79 5.5.3. Route Error Generation . . . . . . . . . . . . . . . . 22 80 5.5.4. Route Error Processing . . . . . . . . . . . . . . . . 23 81 5.6. Unknown Message & TLV Types . . . . . . . . . . . . . . . 24 82 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 24 83 5.8. Simple Internet Attachment and Gatewaying . . . . . . . . 24 84 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 26 85 5.10. Packet/Message Generation Limits . . . . . . . . . . . . . 26 86 6. Configuration Parameters and Other Administrative Options . . 26 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 7.1. DYMO Message Type Specification . . . . . . . . . . . . . 28 89 7.2. Packet TLV Type Specification . . . . . . . . . . . . . . 28 90 7.3. Address Block TLV Specification . . . . . . . . . . . . . 29 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 97 Intellectual Property and Copyright Statements . . . . . . . . . . 32 99 1. Overview 101 The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, 102 multihop routing between participating nodes that wish to 103 communicate. The basic operations of the DYMO protocol are route 104 discovery and route management. During route discovery the 105 originating node initiates dissemination of a Route Request (RREQ) 106 throughout the network to find the target node. During this 107 dissemination process, each intermediate node records a route to the 108 originating node. When the target node receives the RREQ, it 109 responds with a Route Reply (RREP) sent hop-by-hop toward the 110 originating node. Each node that receives the RREP records a route 111 to the target node, and then the RREP is unicast toward the 112 originating node. When the originating node receives the RREP, 113 routes have then been established between the originating node and 114 the target node in both directions. 116 In order to react to changes in the network topology nodes maintain 117 their routes and monitor links over which traffic is moving. When a 118 data packet is received for forwarding if a route is not known or the 119 route is broken, then the source of the packet is notified. A Route 120 Error (RERR) is sent to the packet source to indicate the current 121 route is broken. When the source receives the RERR, it knows that it 122 must perform route discovery if it still has packets to deliver. 124 DYMO uses sequence numbers to ensure loop freedom [Perkins99]. 125 Sequence numbers enable nodes to determine the order of DYMO route 126 discovery messages, thereby avoiding use of stale routing 127 information. 129 2. Applicability 131 The DYMO routing protocol is designed for stub mobile ad hoc 132 networks. DYMO handles a wide variety of mobility patterns by 133 dynamically determining routes on-demand. DYMO also handles a wide 134 variety of traffic patterns. In large networks DYMO is best suited 135 for traffic scenarios where nodes communicate with only a portion of 136 other the nodes. 138 DYMO is applicable to memory constrained devices, since little 139 routing state needs to be maintained. Only routing information 140 related to active sources and destinations must be maintained, in 141 contrast to other routing protocols that require routing information 142 to all nodes within the autonomous system be maintained. 144 The routing algorithm in DYMO may be operated at layers other than 145 the network layer, using layer-appropriate addresses. Only 146 modification of the packet format is required. The routing algorithm 147 need not change. Note that, using the DYMO algorithm with message 148 formats (other than those specified in this document) will not be 149 interoperable. 151 3. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 This document uses some terminology from [I-D.ietf-manet-packetbb]. 159 This document defines the following terminology: 161 DYMO Sequence Number (SeqNum) 162 A DYMO Sequence Number is maintained by each node. This sequence 163 number is used by other nodes to identify the order of routing 164 information generated by a node and to ensure loop-free routes. 166 Forwarding Route 167 A route that is used to forward data packets. Forwarding routes 168 are generally maintained in a forwarding information base (FIB) or 169 the kernel forwarding/routing table. 171 Hop Count (HopCnt) 172 The number of IP hops a message or piece of information has 173 traversed. 175 Originating Node (OrigNode) 176 The originating node is the node that created a DYMO Message in an 177 effort to disseminate some information. The originating node is 178 also referred to as a particular message's originator. 180 Route Error (RERR) 181 A node generates and disseminates a RERR to indicate that it does 182 not have forwarding route to a one or more particular addresses. 184 Route Reply (RREP) 185 A RREP is used to disseminate routing information about the RREP 186 OrigNode to the TargetNode and the nodes between them. 188 Route Request (RREQ) 189 A node (the RREQ OrigNode) generates a RREQ to discover a valid 190 route to a particular destination address, called the RREQ 191 TargetNode. When a node processes a RREQ, it learns routing 192 information on how to reach the RREQ OrigNode. 194 Target Node (TargetNode) 195 The TargetNode is the ultimate destination of a message. 197 This Node (ThisNode) 198 ThisNode corresponds to the node currently performing a 199 calculation or processing a message. 201 Type-Length-Value structure (TLV) 202 A generic way to represent information, see 203 [I-D.ietf-manet-packetbb]. 205 Unreachable Node (UnreachableNode) 206 An UnreachableNode is a node for which ThisNode does not have a 207 forwarding route. 209 4. Data Structures 211 4.1. Route Table Entry 213 The route table entry is a conceptual data structure. 214 Implementations may use any internal representation that conforms to 215 the semantics of a route as specified in this document. 217 Conceptually, a route table entry has the following fields: 219 Route.Address 220 The IP destination address of the node associated with the routing 221 table entry. 223 Route.SeqNum 224 The DYMO SeqNum associated with this routing information. 226 Route.NextHopAddress 227 The IP address of the next node on the path toward the 228 Route.Address. 230 Route.NextHopInterface 231 The interface used to send packets toward the Route.Address. 233 Route.Broken 234 A flag indicating whether this Route is broken. This flag is set 235 if the next hop becomes unreachable or in response to processing a 236 RERR (see Section 5.5.4). 238 The following fields are optional: 240 Route.HopCnt 241 The number of intermediate node hops traversed before reaching the 242 Route.Address node. Route.HopCnt assists in determining whether 243 received routing information is superior to existing known 244 information. 246 Route.Prefix 247 Indicates that the associated address is a network address, rather 248 than a host address. The value is the length of the netmask/ 249 prefix. If an address block does not have an associated 250 PREFIX_LENGTH TLV [I-D.ietf-manet-packetbb] , the prefix may be 251 considered to have a prefix length equal to the address length (in 252 bits). 254 Not including optional information may cause performance degradation, 255 but it will not cause the protocol to operate incorrectly otherwise. 257 In addition to a route table data structure, each route table entry 258 may have several timers associated with the information. These 259 timers/timeouts are discussed in Section 5.2.3. 261 4.2. DYMO Messages 263 When describing DYMO protocol messages, it is necessary to refer to 264 fields in several distinct parts of the overall packet. These 265 locations include the IP or IPv6 header, the UDP header, and fields 266 from [I-D.ietf-manet-packetbb]. This document uses the following 267 notation conventions. Information found in the table. 269 +----------------------------+-------------------+ 270 | Information Location | Notational Prefix | 271 +----------------------------+-------------------+ 272 | IP header | IP. | 273 | UDP header | UDP. | 274 | packetbb message header | MsgHdr. | 275 | packetbb message TLV | MsgTLV. | 276 | packetbb address blocks | AddBlk. | 277 | packetbb address block TLV | AddTLV. | 278 +----------------------------+-------------------+ 280 Table 1 282 4.2.1. Generalized MANET Packet and Message Structure 284 DYMO messages conform to the generalized packet and message format as 285 described in [I-D.ietf-manet-packetbb]. Here is a brief description 286 of the format. A packet is made up of messages. A message is made 287 up of a message header, message TLV block, and zero or more address 288 blocks. Each of the address blocks may also have an associated 289 address TLV block. 291 All DYMO messages specified in this document are sent using UDP to 292 the destination port TBD. 294 Most DYMO messages are sent with the IP destination address set to 295 the link local multicast address LL_ALL_MANET_ROUTER unless otherwise 296 stated. Unicast DYMO messages specified in this document are sent 297 with the IP destination set to the Route.NextHopAddress of the route 298 to the TargetNode. 300 The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) 301 for all messages specified in this document. 303 The length of an IP address (32 bits for IPv4 and 128 bits for IPv6) 304 inside a DYMO message depends on the IP packet header containing the 305 DYMO message/packet. For example, if the IP header uses IPv6 306 addresses then all messages and addresses contained in the payload 307 use IPv6 addresses. In the case of mixed IPv6 and IPv4 addresses, 308 IPv4 addresses are carried in IPv6 as specified in [RFC4291]. 310 4.2.2. Routing Messages (RM) - RREQ & RREP 312 Routing Messages (RMs) are used to disseminate routing information. 313 There are two DYMO message types that are considered to be routing 314 messages (RMs): RREQ and RREP. They contain very similar information 315 and function, but have slightly different processing rules. The main 316 difference between the two messages is that RREQ messages solicit a 317 RREP, whereas a RREP is the response to RREQ. 319 RM creation and processing are described in Section 5.3. 321 A RM requires the following information: 323 IP.DestinationAddress 324 The IP address of the packet destination. For RREQ the 325 IP.DestinationAddress is set to LL_ALL_MANET_ROUTERS. For RREP 326 the IP.DestinationAddress is set to the NextHopAddress toward the 327 TargetNode. 329 UDP.DestinationPort 330 The UDP destination port is set to TBD. 332 MsgHdr.HopLimit 333 The remaining number of hops this message is allowed to traverse. 335 AddBlk.TargetNode.Address 336 The IP address of the message TargetNode. In a RREQ the 337 TargetNode is the destination for which a forwarding route does 338 not exist and route discovery is being performed. In a RREP the 339 target node is the RREQ OrigNode. The TargetNode address is the 340 first address in the routing message. 342 AddBlk.OrigNode.Address 343 The IP address of the OrigNode. This address is in an address 344 block and not in the message header to allow for address 345 compression and additional AddTLVs. This address is the second 346 address in the message for RREQ. 348 AddTLV.OrigNode.SeqNum 349 The DYMO sequence number of the OrigNode. 351 A RM may optionally include the following information: 353 AddTLV.TargetNode.SeqNum 354 The last known DYMO sequence number of the TargetNode. 356 AddTLV.TargetNode.HopCnt 357 The last known HopCnt to the TargetNode. 359 AddBlk.AdditionalNode.Address 360 The IP address of an additional node that can be reached via the 361 node adding this information. Each AdditionalNode.Address must 362 have an associated SeqNum in the address TLV block. 364 AddTLV.AdditionalNode.SeqNum 365 The DYMO sequence number of an additional intermediate node's 366 routing information. 368 AddTLV.Node.HopCnt 369 The number of IP hops to reach the associated Node.Address. This 370 field is incremented at each intermediate hop, for each node 371 except the TargetNode's HopCnt information. 373 AddTLV.Node.Prefix 374 The Node.Address is a network address with a particular prefix 375 length. 377 Example IPv4 RREQ 379 0 1 2 3 380 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 382 IP Header 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | IP.DestinationAddress=LL_ALL_MANET_ROUTERS | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 ... 388 UDP Header 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Destination Port=TBD | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 ... 393 Message Header 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | RREQ-type | Resv |0|0|1| msg-size=23 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | msg-hoplimit | msg-hopcnt | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 ... 400 Message Body - Message TLV Block 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | msg-tlv-block-size=0 | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Message Body - Address Block 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |Number Addrs=2 |0|HeadLength=3 | Head : 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 : (cont) | Target.Tail | Orig.Tail | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Message Body - Address Block TLV Block 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 1 419 4.2.3. Route Error (RERR) 421 A RERR message is used to disseminate the information that a route is 422 not available for one or more particular IP addresses. 424 RERR creation and processing are described in Section 5.5. 426 A RERR requires the following information: 428 IP.DestinationAddress 429 The IP address is set to LL_ALL_MANET_ROUTERS. 431 UDP.DestinationPort 432 The UDP destination port is set to TBD. 434 MsgHdr.HopLimit 435 The remaining number of hops this message is allowed to traverse. 437 AddBlk.UnreachableNode.Address 438 The IP address of an UnreachableNode. Multiple unreachable 439 addresses may be included in a RERR. 441 A Route Error may optionally include the following information: 443 AddTLV.UnreachableNode.SeqNum 444 The last known DYMO sequence number of the unreachable node. If a 445 SeqNum for an address is not included, it is assumed to be 446 unknown. This case occurs when a node receives a message to 447 forward for which it does not have any information in its routing 448 table. 450 Example IPv4 RERR 452 0 1 2 3 453 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 455 IP Header 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | IP.DestinationAddress=LL_ALL_MANET_ROUTERS | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ... 461 UDP Header 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Destination Port=TBD | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 ... 466 Message Header 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | RERR-type | Resv |0|0|1| msg-size=16 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | msg-hoplimit | msg-hopcnt | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 ... 473 Message Body 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | msg-tlv-block-size=0 |Number Addrs=1 |1|HeadLength=4 | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Unreachable.Address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | TLV-blk-size=0 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 2 484 5. Detailed Operation 486 5.1. DYMO Sequence Numbers 488 DYMO sequence numbers allow nodes to judge the freshness of routing 489 information and ensure loop freedom. 491 5.1.1. Maintaining A Node's Own Sequence Number 493 DYMO requires that each node in the network to maintain its own DYMO 494 sequence number (OwnSeqNum), a 16-bit unsigned integer. The 495 circumstances for ThisNode to incrementing its OwnSeqNum are 496 described in Section 5.3. 498 5.1.2. Incrementing OwnSeqNum 500 When ThisNode increments its OwnSeqNum (as described in Section 5.3) 501 it MUST do so by treating the sequence number value as an unsigned 502 number. 504 Note: The sequence number zero (0) is reserved. 506 5.1.3. OwnSeqNum Rollover 508 If the sequence number has been assigned to be the largest possible 509 number representable as a 16-bit unsigned integer (i.e., 65535), then 510 the sequence number is set to 256 when incremented. Setting the 511 sequence number to 256 allows other nodes to detect that the number 512 has rolled over and the node has not lost its sequence number. 514 5.1.4. Actions After OwnSeqNum Loss 516 A node should maintain its sequence number in persistent storage, 517 between reboots. 519 If a node's OwnSeqNum is lost, it must take certain actions to avoid 520 creating routing loops. To prevent this possibility after OwnSeqNum 521 loss a node MUST wait for at least ROUTE_DELETE_TIMEOUT before fully 522 participating in the DYMO routing protocol. If a DYMO control 523 message is received during this waiting period, the node SHOULD 524 process it normally but MUST not transmit or retransmit any DYMO 525 messages. If a data packet is received for forwarding to another 526 destination during this waiting period, the node MUST generate a RERR 527 message indicating that this route is not available and reset its 528 waiting timeout. At the end of the waiting period a node sets its 529 OwnSeqNum to one (1). 531 The longest a node must wait is ROUTE_AGE_MAX_TIMEOUT. At the end of 532 the maximum waiting period a node sets its OwnSeqNum to one (1) and 533 begins participating. 535 5.2. DYMO Routing Table Operations 537 5.2.1. Judging Routing Information's Usefulness 539 Given a route table entry (Route.SeqNum, Route.HopCnt, and 540 Route.Broken) and new routing information for a particular node in a 541 RM (Node.SeqNum, Node.HopCnt, and RM message type - RREQ/RREP), the 542 quality of the new routing information is evaluated to determine its 543 usefulness. Incoming routing information is classified as follows: 545 1. Stale 546 If Node.SeqNum - Route.SeqNum < 0 (using signed 16-bit arithmetic) 547 the information is stale. Using stale routing information is not 548 allowed, since doing so might result in routing loops. 550 (Node.SeqNum - Route.SeqNum < 0) 552 2. Loop-possible 553 If Node.SeqNum == Route.SeqNum the information may cause loops if 554 used; in this case additional information must be examined. If 555 Route.HopCnt or Node.HopCnt is unknown or zero (0), then the 556 routing information is loop-possible. If Node.HopCnt > 557 Route.HopCnt + 1, then the routing information is loop-possible. 558 Using loop-possible routing information is not allowed, otherwise 559 routing loops may be formed. 561 (Node.SeqNum == Route.SeqNum) AND 562 ((Node.HopCnt is unknown) 563 OR (Route.HopCnt is unknown) 564 OR (Node.HopCnt > Route.HopCnt +1)) 566 3. Inferior 567 If Node.SeqNum == Route.SeqNum the information may be inferior; 568 additional information must be examined. If Node.HopCnt >= to 569 Route.HopCnt, the current route is not Broken, and the message is 570 a RREQ, then the new information is inferior. If Node.HopCnt > 571 Route.HopCnt + 1, the current route is not Broken and the message 572 is RREP, then the new information is inferior. Inferior routes 573 will not cause routing loops if introduced, but should not be used 574 since better information is already available. 576 (Node.SeqNum == Route.SeqNum) AND 577 (Route.Broken == false) AND 578 ((Node.HopCnt > Route.HopCnt) AND (RM is RREQ)) 579 OR ((Node.HopCnt > Route.HopCnt + 1) AND (RM is RREP))) 581 4. Superior 582 Routing information that does not match any of the above criteria 583 is loop-free and better than the information existing in the 584 routing table. This type of information is used to update the 585 routing table. For completeness, the following other cases are 586 possible: 588 (Node.SeqNum - Route.SeqNum > 0) OR 589 ((Node.SeqNum == Route.Seqnum) 590 AND ((Node.HopCnt == Route.HopCnt + 1) 591 OR (Node.HopCnt == Route.HopCnt)) 592 AND (((Route.Broken == true) AND (RM is RREQ)) 593 OR ((Route.Broken == false) AND (RM is RREP)))) OR 594 ((Node.HopCnt < Route.HopCnt + 1) AND (Route.Broken == false)) 596 5.2.2. Creating or Updating a Route Table Entry with New Routing 597 Information 599 The route table entry is populated with the following information: 601 1. the Route.Address is set to Node.Address, 603 2. the Route.SeqNum is set to the Node.SeqNum, 605 3. the Route.NextHopAddress is set to the node that transmitted this 606 DYMO RM packet (i.e., the IP.SourceAddress), 608 4. the Route.NextHopInterface is set to the interface that this DYMO 609 packet was received on, 611 5. if known, the Route.HopCnt is set to the Node.HopCnt, 613 6. if known, the Route.Prefix is set to the Node.Prefix. 615 Fields without known values are not populated with any value. 617 Previous timers for this route table entry are removed. A timer for 618 the minimum delete timeout (ROUTE_AGE_MIN) is set to 619 ROUTE_AGE_MIN_TIMEOUT. A timer to indicate a recently learned route 620 (ROUTE_NEW) is set to ROUTE_NEW_TIMEOUT. A timer for the maximum 621 delete timeout (ROUTE_AGE_MAX). ROUTE_AGE_MAX is set to 622 Node.AddTLV.MaxAge if included; otherwise, ROUTE_AGE_MAX is set to 623 ROUTE_AGE_MAX_TIMEOUT. The usage of these timers and others are 624 described in Section 5.2.3. 626 At this point, a forwarding route should be installed. Afterward, 627 the route can be used to send any queued data packets and forwarding 628 any incoming data packets for Route.Address. This route also 629 fulfills any outstanding route discovery attempts for Node.Address. 631 5.2.3. Route Table Entry Timeouts 632 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) 634 When a node transmits a RM, other nodes expect the transmitting node 635 to have a forwarding route to the RM originator. After updating a 636 route table entry, it should be maintained for at least 637 ROUTE_AGE_MIN. Failure to maintain the information might result in 638 lost messages/packets, or in the worst case scenario several 639 duplicate messages. 641 After the ROUTE_AGE_MIN timeout a route can safely be deleted. 643 5.2.3.2. Maximum Delete Timeout (ROUTE_AGE_MAX) 645 Sequence number information is time sensitive, and must be deleted 646 after a time in order to avoid conflicts due to reboots and 647 rollovers. When a node has lost its sequence number (e.g, due to 648 daemon reboot or node replacement) the node must wait until routing 649 information associated with its IP address and sequence number are no 650 longer maintained by other nodes in the network to ensure loop-free 651 routing. 653 After the ROUTE_AGE_MAX timeout a route must be deleted. All 654 information about the route is deleted upon ROUTE_AGE_MAX timeout. 655 If a forwarding route exists it is also removed. 657 5.2.3.3. New Information Timeout (ROUTE_NEW) 659 As time progresses the likelihood that a route remains intact 660 decreases, if the network nodes are mobile. Maintaining and using 661 old routing information can lead to many DYMO messages and excess 662 route discovery delay. 664 After the ROUTE_NEW timeout if the route has not been used, a timer 665 for deleting the route (ROUTE_DELETE) is set to ROUTE_DELETE_TIMEOUT. 667 5.2.3.4. Recently Used Timeout (ROUTE_USED) 669 When a route is used to forward data packets, this timer is set to 670 expire after ROUTE_USED_TIMEOUT. This operation is also discussed in 671 Section 5.5.2. 673 If a route has not been used recently, then a timer for ROUTE_DELETE 674 is set to ROUTE_DELETE_TIMEOUT. 676 5.2.3.5. Delete Information Timeout (ROUTE_DELETE) 678 As time progresses the likelihood that old routing information is 679 useful decreases, especially if the network nodes are mobile. 681 Therefore, old information should be deleted. 683 After the ROUTE_DELETE timeout, the routing table entry should be 684 deleted. If a forwarding route exists, it should also be removed. 686 5.3. Routing Messages 688 5.3.1. RREQ Creation 690 When a node creates a RREQ it SHOULD increment its OwnSeqNum by one 691 (1) according to the rules specified in Section 5.1.2. Incrementing 692 OwnSeqNum will ensure that all nodes with existing routing 693 information to consider this new information fresh. If the sequence 694 number is not incremented, certain nodes might not consider this 695 information useful if they have better information already. 697 First, the node adds the AddBlk.TargetNode.Address to the RREQ. 699 If a previous value of the TargetNode.SeqNum is known (from a routing 700 table entry), it SHOULD be placed in AddTLV.TargetNode.SeqNum in the 701 first few RREQ attempts. If a TargetNode.SeqNum is not included, it 702 is assumed to be unknown by processing nodes, ensures no intermediate 703 nodes reply, and ensures that the TargetNode increments its sequence 704 number. 706 Similarly, if a previous value of the TargetNode.HopCnt is known, it 707 SHOULD be placed in AddTLV.TargetNode.HopCnt. Otherwise, the 708 AddTLV.TargetNode.HopCnt is not included and assumed unknown by 709 processing nodes. 711 Next, the node adds AddBlk.OrigNode.Address to the RM and the 712 AddTLV.OrigNode.SeqNum (OwnSeqNum) in an address block TLV. The 713 OrigNode.Address is this node's address, and it must be a routable IP 714 address. This information will be used by nodes to create a route 715 toward the OrigNode and enable delivery of a RREP. 717 If OrigNode.HopCnt is included it is set to zero (0). 719 The MsgHdr.HopCnt is set to zero (0). The MsgHdr.HopLimit should be 720 set to NET_DIAMETER, but may be set smaller. For RREQ, the 721 MsgHdr.HopLimit may be set in accordance with an expanding ring 722 search as described in [RFC3561] to limit the RREQ propagation to a 723 subset of the network and possibly reduce route discovery overhead. 725 The IP.DestinationAddress for RREQ is set to LL_ALL_MANET_ROUTERS. 727 5.3.2. RREP Creation 729 When ThisNode creates a RREP, if the ThisNode.SeqNum was not included 730 in the RREQ it SHOULD increment its OwnSeqNum by one (1) according to 731 the rules specified in Section 5.1.2. 733 If ThisNode.SeqNum is included in the RM and ThisNode.SeqNum from the 734 RM is less than OwnSeqNum, OwnSeqNum SHOULD be incremented by one (1) 735 according to the rules specified in Section 5.1.2. 737 If OwnSeqNum is not incremented the routing information might be 738 considered stale. In this case, the RREP would not reach the RREP 739 Target. 741 Since RREP messages are not broadcast throughout the network, changes 742 to the sequence number are unlikely to reach most nodes in the 743 network. Therefore, it is important to avoid incrementing the 744 sequence number when issuing a RREP is an important mechanism to 745 reduce the unnecessary devaluing of good routing information, and the 746 ability to issue intermediate node replies. When intermediate node 747 replies are coupled with expanding ring search, route discovery cost 748 can be reduced. 750 ThisNode first adds the RREP AddBlk.TargetNode.Address to the RREP. 751 The TargetNode is the ultimate destination of this RREP. 753 ThisNode then adds the RREP AddBlk.OrigNode.Address 754 (ThisNode.Address) and the RREP AddTLV.OrigNode.SeqNum (OwnSeqNum) to 755 the RREP. 757 Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be 758 included and set accordingly. If OrigNode.HopCnt is included it is 759 set to zero (0). 761 The MsgHdr.HopCnt is set to zero (0). The MsgHdr.HopLimit is set to 762 NET_DIAMETER. 764 The IP.DestinationAddress for RREP is set to the IP address of the 765 Route.NextHopAddress for the route to the RREP TargetNode. 767 5.3.3. Intermediate Node RREP Creation 769 Sometimes a node other than the TargetNode (call it an "intermediate 770 node") has routing information that can satisfy an incoming RREQ. 771 When an intermediate node originates a RREP in response to a RREQ, it 772 sends the RREP to the RREQ OrigNode with additional routing 773 information (Address, SeqNum, etc.) about the RREQ TargetNode. 774 Appending additional routing information is described in 775 Section 5.3.5. 777 The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ 778 TargetNode, so that the RREQ TargetNode receives routing information 779 on how to reach the RREQ OrigNode. 781 When an intermediate node creates a gratuitous RREP, it sends a RREP 782 to the RREQ TargetNode with additional routing information (Address, 783 SeqNum, etc.) about the RREQ OrigNode. 785 5.3.4. RM Processing 787 Before processing a RM, a node checks the IP.Destination to ensure 788 that it is a link local packet. 790 When a RM is received the MsgHdr.HopLimit is decremented by one (1) 791 and MsgHdr.HopCnt is incremented by one (1). 793 For each address (except the TargetNode) in the RM that includes 794 AddTLV.HopCnt information, the AddTLV.HopCnt information is 795 incremented by one (1). 797 Next, this node checks whether its routing table has an entry to the 798 AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If 799 a route does not exist, the new routing information is considered 800 fresh and a new route table entry is created and updated as described 801 in Section 5.2.2. If a route table entry does exists, the new node's 802 information is compared with the route table entry following the 803 procedure described in Section 5.2.1. If the new node's routing 804 information is considered superior, the route table entry is updated 805 as described in Section 5.2.2. 807 After processing the OrigNode's routing information, then each 808 address that is not the TargetNode should be considered for creating 809 and updating routes. Creating and updating routes to other nodes can 810 eliminate RREQ for those IP destinations, in the event that data 811 needs to be forwarded to the IP destination(s) in the near future. 813 For each of the additional addresses considered, if the routing table 814 does not have a matching route using longest-prefix matching, then a 815 route is created and updated as described in Section 5.2.2. If a 816 route table entry exists, the new node's information is compared with 817 the route table entry following the procedure described in 818 Section 5.2.1. If the new node's routing information is considered 819 superior, the route table entry is updated as described in 820 Section 5.2.2. 822 If the routing information for an AdditionalNode.Address is not 823 considered superior, then it is removed from the RM. Removing this 824 information ensures that the information is not propagated. 826 At this point, if the routing information for the OrigNode was not 827 superior then this RM should be discarded and no further processing 828 of this message is performed. 830 If the ThisNode is the TargetNode and this RM is a RREQ, then 831 ThisNode responds with a RREQ flood (a RREQ addressed to oneself) or 832 a RREP to the RREQ OrigNode (the new RREP's TargetNode). The 833 procedure for issuing a new RREP is described in Section 5.3.2. 834 Note: it is important that when creating the RREP, the RREP 835 OrigNode.Address be the same as the RREQ TargetNode.Address, if 836 ThisNode has several addresses. At this point, ThisNode need not 837 perform any more operations for this RM. 839 If ThisNode is not the TargetNode, this RM is a RREQ, the RREQ 840 contains the AddBlk.TargetNode.SeqNum, and ThisNode has an forwarding 841 route to the TargetNode with a SeqNum (Route.TargetNode.SeqNum) 842 greater than or equal to the RREQ AddBlk.TargetNode.SeqNum; then this 843 node MAY respond with an intermediate node RREP. The procedure for 844 performing intermediate node RREP is described in Section 5.3.3. At 845 this point, ThisNode need not perform any more operations for this 846 RM. 848 After processing a RM or creating a new RM, a node can append 849 additional routing information to the RM, according to the procedure 850 described in Section 5.3.5. The additional routing information can 851 help reduce route discoveries at the expense of increased message 852 size. 854 If this RM's MsgHdr.HopLimit is greater than one (1), ThisNode is not 855 the TargetNode, AND this RM is a RREQ, then the current RM (altered 856 by the procedure defined above) is sent to the LL_ALL_MANET_ROUTERS 857 IP.DestinationAddress. 859 If this RM's MsgHdr.HopLimit is greater than one (1), ThisNode is not 860 the TargetNode, AND this RM is a RREP, then the current RM is sent to 861 the Route.NextHopAddress for the RREP's TargetNode.Address. If no 862 forwarding route exists to Target.Address, then a RERR is issued to 863 the OrigNode of the RREP. 865 5.3.5. Adding Additional Routing Information to a RM 867 Appending routing information can alleviate route discovery attempts 868 to the nodes whose information is included, if other nodes use this 869 information to update their routing tables. 871 Nodes can append routing information to a RM, and should if ThisNode 872 believes that the additional routing information will alleviate 873 future RREQ. This option should be administratively configurable. 875 Prior to appending its own address to a RM, ThisNode MAY increment 876 its OwnSeqNum as defined in Section 5.1.2. If OwnSeqNum is not 877 incremented the appended routing information might not be considered 878 fresh, when received by nodes with existing routing information. 879 Incrementation of the sequence number when appending information to 880 an RM in transit should be administratively configurable. 882 If included the Node.HopCnt for ThisNode is included, it is set to 883 zero (0). Additional information about the address(es) can also be 884 appended, such as a PREFIX_LENGTH AddTLV. 886 5.4. Route Discovery 888 A node creates and sends a RREQ (described in Section 5.3.1) to 889 discover a route to a particular destination (TargetNode) for which 890 it does not currently have a forwarding route. 892 After issuing a RREQ, the OrigNode waits for a route to be created to 893 the TargetNode. If a route is not created within RREQ_WAIT_TIME, 894 ThisNode may again try to discover a route by issuing another RREQ. 896 To reduce congestion in a network, repeated attempts at route 897 discovery for a particular TargetNode should utilize an exponential 898 backoff. 900 For example, the first time a node issues a RREQ, it waits 901 RREQ_WAIT_TIME for a route to the TargetNode. If a route is not 902 found within that time, the node MAY send another RREQ. If a route 903 is not found within two (2) times the current waiting time, another 904 RREQ may be sent, up to a total of RREQ_TRIES. For each additional 905 attempt, the waiting time for the previous RREQ is multiplied by two 906 (2) so that the waiting time conforms to a binary exponential 907 backoff. 909 Data packets awaiting a route should be buffered. This buffer should 910 have a fixed limited size (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES) 911 and older data packets SHOULD be discarded first. 913 If a route discovery has been attempted RREQ_TRIES times without 914 receiving a route to the TargetNode, all data packets destined for 915 the corresponding TargetNode are dropped from the buffer and a 916 Destination Unreachable ICMP message should be delivered to the 917 application. 919 5.5. Route Maintenance 921 A RERR MUST be issued if a data packet is received and it cannot be 922 delivered to the next hop when no forwarding route exists; RERR 923 generation is described in Section 5.5.3. 925 In addition to inability to deliver a data packet, a RERR SHOULD be 926 issued immediately after detecting a broken link of an forwarding 927 route to quickly notify nodes that a link break occurred and that 928 certain routes are no longer available. If the route with the broken 929 link has not been used recently (indicated by ROUTE_USED), the RERR 930 SHOULD NOT be generated. 932 5.5.1. Active Link Monitoring 934 Nodes MUST monitor next hop links on forwarding routes. This 935 monitoring can be accomplished by one or several mechanisms, 936 including: 938 o Link layer feedback 940 o Neighborhood discovery [I-D.ietf-manet-nhdp] 942 o Route timeout 944 o Other monitoring mechanisms or heuristics 946 Upon detecting a link break (or an unreachable next hop) ThisNode 947 must remove the affected forwarding routes (those with an unreachable 948 next hop). ThisNode also flags these routes as Broken. For each 949 broken route a timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT. 951 5.5.2. Updating Route Lifetimes during Packet Forwarding 953 To avoid removing forwarding routes that are being used, a node 954 SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for the route 955 to the IP.SourceAddress upon receiving a data packet. If a timer for 956 ROUTE_DELETE is set, it is removed. 958 To avoid removing forwarding routes that are being used, a node 959 SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for the route 960 to the IP.DestinationAddress upon sending a data packet. If a timer 961 for ROUTE_DELETE is set, it is removed. 963 5.5.3. Route Error Generation 965 A RERR informs the IP.SourceAddress or RREP.OrigNode.Address that the 966 route does not exist, and a route is not available through this node. 968 When creating a new RERR, the address of first UnreachableNode 969 (IP.DestinationAddress from the data packet or 970 RREP.TargetNode.Address) is inserted. If a value for the 971 UnreachableNode's SeqNum (AddTLV.UnreachableNode.SeqNum) is known, it 972 SHOULD be placed in the RERR. The MsgHdr.HopLimit is set to 973 NET_DIAMETER. The MsgHdr.HopCnt is set to one (1). 975 Additional UnreachableNodes that require the same unavailable link 976 (routes with the same Route.NextHopAddress and 977 Route.NextHopInterface) SHOULD be added to the RERR. The SeqNum if 978 known SHOULD also be included. Appending UnreachableNode information 979 notifies each processing node of additional routes that are no longer 980 available. This option SHOULD be administratively configurable. 982 If SeqNum information is not known or not included in the RERR, all 983 nodes processing the RERR will assume their routing information 984 associated with the UnreachableNode is no longer valid. 986 The RERR is sent to the IP.DestinationAddress LL_ALL_MANET_ROUTERS. 987 Sending the RERR to the LL_ALL_MANET_ROUTERS address notifies nearby 988 nodes that might depend on the now broken link. 990 The packet or message that forced generation of this RERR is 991 discarded. 993 5.5.4. Route Error Processing 995 Before processing a RERR, a node checks the IP.Destination to ensure 996 that it is a link local packet. 998 When a node processes a RERR, it processes each UnreachableNode's 999 information. The processing node removes the forwarding route and 1000 sets the broken flag for each UnreachableNode.Address found using 1001 longest prefix matching that meet all of the following conditions: 1003 1. The Route.NextHopAddress is the same as the RERR 1004 IP.SourceAddress. 1006 2. The Route.NextHopInterface is the same as the interface on which 1007 the RERR was received. 1009 3. The Route.SeqNum is zero (0), unknown, OR the 1010 UnreachableNode.SeqNum is zero (0), unknown, OR 1011 UnreachableNode.SeqNum - Route.SeqNum <= 0 (using signed 16-bit 1012 arithmetic). 1014 Each UnreachableNode that did not result in a broken route is removed 1015 from the RERR, since propagation of this information will not result 1016 in any benefit. Any other information (AddTLVs) associated with the 1017 removed address(es) is also removed. 1019 If no UnreachableNode addresses remain in the RERR, no other 1020 processing is required and the RERR is discarded. 1022 If this RERR's MsgHdr.HopLimit is greater than one (1) and at least 1023 one unreachable node address remains in the RERR, then the updated 1024 RERR is sent to the IP.DestinationAddress LL_ALL_MANET_ROUTERS. 1026 5.6. Unknown Message & TLV Types 1028 If a message with an unknown type is received, the message is 1029 discarded. 1031 If a message contains TLVs of an unknown type, a node ignores these 1032 during processing. The processing node can remove these TLVs from 1033 any resulting transmitted messages. The behavior for unknown TLV 1034 types should be administratively configurable. 1036 5.7. Advertising Network Addresses 1038 Any node can advertise a network address by using a PREFIX_LENGTH TLV 1039 [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising 1040 node) within the advertised prefix SHOULD NOT participate in the DYMO 1041 protocol directly and these nodes MUST be reachable by forwarding 1042 packets to the node advertising connectivity. Nodes other than the 1043 advertising node that do participate in DYMO must forward the DYMO 1044 control packets to the advertising node. For example, A.B.C.1 with a 1045 prefix length of 24 indicates all nodes with the matching A.B.C.X are 1046 reachable through the node with address A.B.C.1. 1048 5.8. Simple Internet Attachment and Gatewaying 1050 Simple Internet attachment consists of a network of MANET nodes 1051 connected to the Internet via a single Internet gateway node. The 1052 gateway is responsible for responding to RREQs for TargetNodes 1053 outside its configured DYMO prefix, as well as delivering packets to 1054 destinations outside the MANET. 1056 /--------------------------\ 1057 / Internet \ 1058 \ / 1059 \------------+-------------/ 1060 Gateway's | 1061 Advertised | A.B.C.X 1062 Prefix | 1063 +-----+-----+ 1064 | DYMO | 1065 /------| Internet |------\ 1066 / | Gateway | \ 1067 / | A.B.C.1 | \ 1068 | +-----------+ | 1069 | DYMO Region | 1070 | | 1071 | +------------+ | 1072 | | DYMO Node | | 1073 | | A.B.C.2 | | 1074 | +------------+ | 1075 | +------------+ | 1076 | | DYMO Node | | 1077 | | A.B.C.3 | | 1078 \ +------------+ / 1079 \ / 1080 \-------------------------/ 1082 Figure 7: Simple Internet Attachament Example 1084 DYMO nodes wishing to be reachable from nodes in the Internet MUST 1085 have IP addresses within the gateway's configured and advertised 1086 prefix. Given a node with a globally routeable address or care-of 1087 address handled by the gateway, the gateway is responsible for 1088 routing and forwarding packets received from the Internet destined 1089 for nodes inside its MANET. 1091 When nodes within the MANET want to send messages to nodes in the 1092 Internet, they simply issue RREQ for those IP.DestinationAddresses. 1093 The gateway is responsible for responding to RREQ on behalf of the 1094 Internet destinations and maintaining their associated sequence 1095 numbers. 1097 For an Internet gateway and other nodes that maintain the sequence 1098 number on behalf of other nodes, these routers must be 1099 administratively configurable to know the IP addresses for which they 1100 must generate DYMO messages and maintain OwnSeqNum. 1102 5.9. Multiple Interfaces 1104 DYMO will often be used with multiple interfaces; therefore, the 1105 particular interface over which packets arrive must be known whenever 1106 a packet is received. Whenever a new route is created, the interface 1107 through which the Route.Address can be reached is also recorded in 1108 the route table entry. 1110 When multiple interfaces are available, a node transmitting a packet 1111 with IP.DestinationAddress set to LL_ALL_MANET_ROUTERS SHOULD send 1112 the packet on all interfaces that have been configured for DYMO 1113 operation. 1115 5.10. Packet/Message Generation Limits 1117 To avoid congestion, a node's rate of packet/message generation 1118 should be limited. The rate and algorithm for limiting messages is 1119 left to the implementor and should be administratively configurable. 1120 Messages should be discarded in the following order of preferences 1121 RREQ, RREP, and finally RERR. 1123 6. Configuration Parameters and Other Administrative Options 1125 Suggested Parameter Values 1127 +------------------------------+------------------------+ 1128 | Name | Value | 1129 +------------------------------+------------------------+ 1130 | NET_DIAMETER | 10 hops | 1131 | NET_TRAVERSAL_TIME | 1000 milliseconds | 1132 | ROUTE_TIMEOUT | 5 seconds | 1133 | ROUTE_AGE_MIN_TIMEOUT | NET_TRAVERSAL_TIME | 1134 | ROUTE_AGE_MAX_TIMEOUT | 60 seconds | 1135 | ROUTE_NEW_TIMEOUT | ROUTE_TIMEOUT | 1136 | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | 1137 | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | 1138 | ROUTE_RREQ_WAIT_TIME | 2 * NET_TRAVERSAL_TIME | 1139 | RREQ_TRIES | 3 tries | 1140 | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | 1141 +------------------------------+------------------------+ 1143 Table 2 1145 These suggested values work well for small and medium well connected 1146 networks with infrequent topology changes. These parameters should 1147 be administratively configurable for the network where DYMO is used. 1148 Ideally, for networks with frequent topology changes the DYMO 1149 parameters should be adjusted using either experimentally determined 1150 values or dynamic adaptation. For example, in networks with 1151 infrequent topology changes ROUTE_USED_TIMEOUT may be set to a much 1152 larger value. 1154 In addition to the parameters above several administrative options 1155 exist. The following table enumerates several of the options and 1156 suggested values. 1158 Suggested Options Settings 1160 +-------------------------------------+----------------------------+ 1161 | Name | Value | 1162 +-------------------------------------+----------------------------+ 1163 | RESPONSIBLE_ADDRESSES | Self or Prefix | 1164 | DYMO_INTERFACES | User Specified | 1165 | INCLUDE_INFORMATION | Yes-SeqNum,HopCnt,Prefix | 1166 | APPEND_ADDRESS | Yes - RREQ & RREP | 1167 | APPEND_OWN_ADDRESS_INCREMENT_SEQNUM | Yes for RREQ | 1168 | GENERATE_RERR_IMMEDIATELY | No | 1169 | RERR_INCLUDE_ALL_UNREACHABLES | Yes | 1170 | UNKNOWN_TYPE_HANDLING | Ignore | 1171 | BUFFER_SIZE_PACKETS | 50 packets | 1172 | BUFFER_SIZE_BYTES | 1500 * BUFFER_SIZE_PACKETS | 1173 +-------------------------------------+----------------------------+ 1175 Table 3 1177 7. IANA Considerations 1179 DYMO requires a UDP port number to carry protocol packets - TBD. 1180 DYMO also requires the link-local multicast address 1181 LL_ALL_MANET_ROUTERS; IPv4 TBD, IPv6 TBD [I-D.chakeres-manet-iana]. 1183 This section specifies several messages types, message tlv-types, and 1184 address tlv-types. 1186 Future types will be allocated using standard actions as described in 1187 [RFC2434]. 1189 7.1. DYMO Message Type Specification 1191 DYMO Message Types 1193 +------------------------+----------+ 1194 | Name | Type | 1195 +------------------------+----------+ 1196 | Route Request (RREQ) | 10 - TBD | 1197 | Route Reply (RREP) | 11 - TBD | 1198 | Route Error (RERR) | 12 - TBD | 1199 +------------------------+----------+ 1201 Table 4 1203 7.2. Packet TLV Type Specification 1205 Packet TLV Types 1207 +-------------------+------+--------+-------------------------------+ 1208 | Name | Type | Length | Value | 1209 +-------------------+------+--------+-------------------------------+ 1210 | Unicast Response | 10 - | 0 | Indicates to the processing | 1211 | Request | TBD | | node that the previous hop | 1212 | | | | (IP.SourceAddress) expects a | 1213 | | | | unicast message within | 1214 | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | 1215 | | | | Any unicast packet will serve | 1216 | | | | this purpose, and it MAY be | 1217 | | | | an ICMP REPLY message. If a | 1218 | | | | message is not sent, then the | 1219 | | | | previous hop may assume that | 1220 | | | | the link is unidirectional | 1221 | | | | and may blacklist the link to | 1222 | | | | this node. | 1223 +-------------------+------+--------+-------------------------------+ 1225 Table 5 1227 7.3. Address Block TLV Specification 1229 Address Block TLV Types 1231 +----------------+------+---------+---------------------------------+ 1232 | Name | Type | Length | Value | 1233 +----------------+------+---------+---------------------------------+ 1234 | DYMOSeqNum | 10 - | 16 bits | The DYMO sequence num | 1235 | | TBD | | associated with this address. | 1236 | | | | The sequence number may be the | 1237 | | | | last known sequence number. | 1238 | HopCount | 11 - | 8 bits | The number of hops traversed by | 1239 | | TBD | | the information associated with | 1240 | | | | this address. | 1241 | MaxAge | 12 - | Any | The maximum number of | 1242 | | TBD | length | milliseconds that the | 1243 | | | | associated routing information | 1244 | | | | can be kept before being | 1245 | | | | deleted. | 1246 +----------------+------+---------+---------------------------------+ 1248 Table 6 1250 8. Security Considerations 1252 Currently, DYMO does not specify any special security measures. 1253 Routing protocols, however, are prime targets for impersonation 1254 attacks. In networks where the node membership is not known, it is 1255 difficult to determine the occurrence of impersonation attacks, and 1256 security prevention techniques are difficult at best. However, when 1257 the network membership is known and there is a danger of such 1258 attacks, DYMO messages must be protected by the use of authentication 1259 techniques, such as those involving generation of unforgeable and 1260 cryptographically strong message digests or digital signatures. 1261 While DYMO does not place restrictions on the authentication 1262 mechanism used for this purpose, IPsec Authentication Message (AH) is 1263 an appropriate choice for cases where the nodes share an appropriate 1264 security association that enables the use of AH. 1266 In particular, RM messages SHOULD be authenticated to avoid creation 1267 of spurious routes to a destination. Otherwise, an attacker could 1268 masquerade as that destination and maliciously deny service to the 1269 destination and/or maliciously inspect and consume traffic intended 1270 for delivery to the destination. RERR messages SHOULD be 1271 authenticated in order to prevent malicious nodes from disrupting 1272 active routes between communicating nodes. 1274 If the mobile nodes in the ad hoc network have pre-established 1275 security associations, the purposes for which the security 1276 associations are created should include that of authorizing the 1277 processing of DYMO control packets. Given this understanding, the 1278 mobile nodes should be able to use the same authentication mechanisms 1279 based on their IP addresses as they would have used otherwise. 1281 9. Acknowledgments 1283 DYMO is a descendant of the design of previous MANET reactive 1284 protocols, especially AODV [RFC3561] and DSR [Johnson96]. Changes to 1285 previous MANET reactive protocols stem from research and 1286 implementation experiences. Thanks to Elizabeth Belding-Royer for 1287 her long time authorship of DYMO. Additional thanks to Luke Klein- 1288 Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon 1289 Caceres, Thomas Clausen, Christopher Dearlove, and Seung Yi for 1290 reviewing of DYMO, as well as several specification suggestions. 1292 10. References 1294 10.1. Normative References 1296 [I-D.ietf-manet-packetbb] 1297 Clausen, T., "Generalized MANET Packet/Message Format", 1298 draft-ietf-manet-packetbb-02 (work in progress), 1299 July 2006. 1301 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1302 RFC 1812, June 1995. 1304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1305 Requirement Levels", BCP 14, RFC 2119, March 1997. 1307 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1308 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1309 October 1998. 1311 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1312 Architecture", RFC 4291, February 2006. 1314 10.2. Informative References 1316 [I-D.chakeres-manet-iana] 1317 Chakeres, I., "MANET IANA Needs", 1318 draft-chakeres-manet-iana-02 (work in progress), 1319 October 2006. 1321 [I-D.ietf-manet-nhdp] 1322 Clausen, T., "MANET Neighborhood Discovery Protocol 1323 (NHDP)", draft-ietf-manet-nhdp-00 (work in progress), 1324 June 2006. 1326 [Johnson96] 1327 Johnson, D. and D. Maltz, "Dynamic Source Routing (DSR) in 1328 Ad hoc Networks", In Mobile Computing, Chapter 5, pp. 153- 1329 181, 1996. 1331 [Perkins99] 1332 Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand 1333 Distance Vector (AODV) Routing", Proceedings of the 2nd 1334 IEEE Workshop on Mobile Computing Systems and 1335 Applications, New Orleans, LA, pp. 90-100, 1336 February 1999. 1338 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1339 Demand Distance Vector (AODV) Routing", RFC 3561, 1340 July 2003. 1342 Authors' Addresses 1344 Ian Chakeres 1345 Boeing Phantom Works 1346 The Boeing Company 1347 P.O. Box 3707 Mailcode 7L-49 1348 Seattle, WA 98124-2207 1349 USA 1351 Email: ian.chakeres@gmail.com 1353 Charles E. Perkins 1354 Palo Alto Systems Research Center 1355 975 Page Mill Road, Suite 200 1356 Palo Alto, CA 94304-1003 1357 USA 1359 Phone: +1-650-496-4402 1360 Fax: +1-650-739-0779 1361 Email: charles.perkins@nokia.com 1363 Full Copyright Statement 1365 Copyright (C) The IETF Trust (2007). 1367 This document is subject to the rights, licenses and restrictions 1368 contained in BCP 78, and except as set forth therein, the authors 1369 retain all their rights. 1371 This document and the information contained herein are provided on an 1372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1375 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1379 Intellectual Property 1381 The IETF takes no position regarding the validity or scope of any 1382 Intellectual Property Rights or other rights that might be claimed to 1383 pertain to the implementation or use of the technology described in 1384 this document or the extent to which any license under such rights 1385 might or might not be available; nor does it represent that it has 1386 made any independent effort to identify any such rights. Information 1387 on the procedures with respect to rights in RFC documents can be 1388 found in BCP 78 and BCP 79. 1390 Copies of IPR disclosures made to the IETF Secretariat and any 1391 assurances of licenses to be made available, or the result of an 1392 attempt made to obtain a general license or permission for the use of 1393 such proprietary rights by implementers or users of this 1394 specification can be obtained from the IETF on-line IPR repository at 1395 http://www.ietf.org/ipr. 1397 The IETF invites any interested party to bring to its attention any 1398 copyrights, patents or patent applications, or other proprietary 1399 rights that may cover technology that may be required to implement 1400 this standard. Please address the information to the IETF at 1401 ietf-ipr@ietf.org. 1403 Acknowledgment 1405 Funding for the RFC Editor function is provided by the IETF 1406 Administrative Support Activity (IASA).