idnits 2.17.1 draft-ietf-manet-dymo-10.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 1488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1512. 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 (July 5, 2007) is 6112 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) == Unused Reference: 'RFC4291' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'Johnson96' is defined on line 1434, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-manet-iana-05 == Outdated reference: A later version (-17) exists of draft-ietf-manet-packetbb-07 == Outdated reference: A later version (-08) exists of draft-ietf-manet-timetlv-01 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-04) exists of draft-ietf-manet-jitter-01 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-04 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working I. Chakeres 3 Group Motorola 4 Internet-Draft C. Perkins 5 Intended status: Standards Track Nokia 6 Expires: January 6, 2008 July 5, 2007 8 Dynamic MANET On-demand (DYMO) Routing 9 draft-ietf-manet-dymo-10 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 January 6, 2008. 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 modes in wireless, multihop networks. It offers 44 adaptation to changing network topology and determines unicast routes 45 between DYMO routers within the network in an on-demand fashion. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 7 54 4.2. DYMO Messages . . . . . . . . . . . . . . . . . . . . . . 8 55 4.2.1. Generalized MANET Packet and Message Structure . . . . 8 56 4.2.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . 9 57 4.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 11 58 5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 13 59 5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 13 60 5.1.1. Maintaining A Node's Own Sequence Number . . . . . . . 13 61 5.1.2. Numerical Operations on OwnSeqNum . . . . . . . . . . 14 62 5.1.3. OwnSeqNum Rollover . . . . . . . . . . . . . . . . . . 14 63 5.1.4. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 14 64 5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 14 65 5.2.1. Judging Routing Information's Usefulness . . . . . . . 14 66 5.2.2. Creating or Updating a Route Table Entry with New 67 Routing Information . . . . . . . . . . . . . . . . . 16 68 5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 16 69 5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 18 70 5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 18 71 5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 19 72 5.3.3. Intermediate DYMO Router RREP Creation . . . . . . . . 19 73 5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 20 74 5.3.5. Adding Additional Routing Information to a RM . . . . 22 75 5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 23 76 5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 23 77 5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 24 78 5.5.2. Updating Route Lifetimes During Packet Forwarding . . 24 79 5.5.3. Route Error Generation . . . . . . . . . . . . . . . . 24 80 5.5.4. RERR Processing . . . . . . . . . . . . . . . . . . . 25 81 5.6. Unknown Message & TLV Types . . . . . . . . . . . . . . . 26 82 5.7. Advertising Network Addresses . . . . . . . . . . . . . . 26 83 5.8. Simple Internet Attachment and Gatewaying . . . . . . . . 26 84 5.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 28 85 5.10. Packet/Message Generation Limits . . . . . . . . . . . . . 28 86 6. Configuration Parameters and Other Administrative Options . . 28 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 88 7.1. DYMO Message Type Specification . . . . . . . . . . . . . 30 89 7.2. Packet and Message TLV Type Specification . . . . . . . . 30 90 7.3. Address Block TLV Specification . . . . . . . . . . . . . 31 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 97 Intellectual Property and Copyright Statements . . . . . . . . . . 34 99 1. Overview 101 The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, 102 multihop unicast routing between participating DYMO routers. The 103 basic operations of the DYMO protocol are route discovery and route 104 management. During route discovery, the originator's DYMO router 105 initiates dissemination of a Route Request (RREQ) throughout the 106 network to find a route to the target's DYMO router. During this 107 hop-by-hop dissemination process, each intermediate DYMO router 108 records a route to the originator. When the target's DYMO router 109 receives the RREQ, it responds with a Route Reply (RREP) sent hop-by- 110 hop toward the originator. Each intermediate DYMO router that 111 receives the RREP records a route to the target, and then the RREP is 112 unicast hop-by-hop toward the originator. When the originator's DYMO 113 router receives the RREP, routes have then been established between 114 the originating DYMO router and the target DYMO router in both 115 directions. 117 In order to preserve routes in use, DYMO routers extend route 118 lifetimes upon successfully forwarding a packet. In order to react 119 to react to changes in the network topology, DYMO routers monitor 120 links over which traffic is moving. When a data packet is received 121 for forwarding if a route for the destination is not known or the 122 route is broken, then the DYMO router of source of the packet is 123 notified. A Route Error (RERR) is sent toward the packet source to 124 indicate the current route to a particular destination is broken. 125 When the source's DYMO router receives the RERR, it deletes the 126 route. If the DYMO router later receives a packet for forwarding to 127 the same destination, it must perform route discovery again. 129 DYMO uses sequence numbers to ensure loop freedom [Perkins99]. 130 Sequence numbers enable DYMO routers to determine the order of DYMO 131 route discovery messages, thereby avoiding use of stale routing 132 information. 134 2. Applicability Statement 136 The DYMO routing protocol is designed for stub or disconnected mobile 137 ad hoc networks. DYMO handles a wide variety of mobility patterns by 138 dynamically determining routes on-demand. DYMO also handles a wide 139 variety of traffic patterns. In large networks DYMO is best suited 140 for traffic scenarios where nodes communicate with only a portion of 141 other the nodes. 143 DYMO is applicable to memory constrained devices, since little 144 routing state must be maintained in each DYMO router. Only routing 145 information related to active sources and destinations must be 146 maintained, in contrast to other routing protocols that require 147 routing information to all routers within the routing region be 148 maintained. 150 DYMO supports routers which have multiple interfaces participating in 151 the MANET. DYMO also supports nodes which have non-MANET interfaces 152 to which hosts can attach. 154 DYMO routers perform route discovery to find a route to a particular 155 destination. Therefore, DYMO routers must be configured to initiate 156 route discovery for certain destinations. When DYMO is the only 157 protocol interacting with the forwarding table, DYMO should be 158 configured to perform route discovery for all unknown unicast 159 destinations. 161 DYMO should only utilizes bidirectional links. In the case of 162 possible unidirectional links, either blacklists (see Section 7.2) or 163 other means (e.g. only accepting RM from bidirectional links as 164 indicated by NHDP [I-D.ietf-manet-nhdp]) of ensuring bi- 165 directionality should be used. Otherwise, persistent packet loss may 166 occur. 168 The routing algorithm in DYMO may be operated at layers other than 169 the network layer, using layer-appropriate addresses. Only 170 modification of the packet format is required. The routing algorithm 171 need not change. Note that, using the DYMO algorithm with message 172 formats other than those specified in this document will not be 173 interoperable. 175 3. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 Additionally, this document uses some terminology from 182 [I-D.ietf-manet-packetbb]. 184 This document defines the following terminology: 186 Distance (Dist) 187 A metric of the distance a message or piece of information has 188 traversed. The minimum value of distance is the number of IP hops 189 traversed. 191 DYMO Sequence Number (SeqNum) 192 A DYMO Sequence Number is maintained by each DYMO router. This 193 sequence number is used by other DYMO routers to identify the 194 order of routing information generated and ensure loop-free 195 routes. 197 Forwarding Route 198 A route that is used to forward data packets. Forwarding routes 199 are generally maintained in a forwarding information base (FIB) or 200 the kernel forwarding/routing table. 202 Originating Node (OrigNode) 203 The originating node is the DYMO router that creates a DYMO 204 Message in an effort to disseminate some information. The 205 originating node is also referred to as a particular message's 206 originator. 208 Route Error (RERR) 209 A RERR message is used indicate that a DYMO router does not have 210 forwarding route to one or more particular addresses. 212 Route Reply (RREP) 213 A RREP message is used to disseminate routing information about 214 the RREP OrigNode to the RREP TargetNode and the DYMO routers 215 between them. 217 Route Request (RREQ) 218 A RREQ message is issued to discover a valid route to a particular 219 destination address, called the RREQ TargetNode. When a DYMO 220 router processes a RREQ, it learns routing information on how to 221 reach the RREQ OrigNode. 223 Target Node (TargetNode) 224 The TargetNode is the ultimate destination of a message. 226 This Node (ThisNode) 227 ThisNode corresponds to the DYMO router currently performing a 228 calculation or processing a message. 230 Type-Length-Value structure (TLV) 231 A generic way to represent information, please see 232 [I-D.ietf-manet-packetbb] for additional information. 234 Unreachable Node (UnreachableNode) 235 An UnreachableNode is a node for which a forwarding route does not 236 exist. 238 4. Data Structures 240 4.1. Route Table Entry 242 The route table entry is a conceptual data structure. 243 Implementations may use any internal representation that conforms to 244 the semantics of a route as specified in this document. 246 Conceptually, a route table entry has the following fields: 248 Route.Address 249 The IP destination address of the node(s) associated with the 250 routing table entry. 252 Route.SeqNum 253 The DYMO SeqNum associated with this routing information. 255 Route.NextHopAddress 256 The IP address of the next DYMO router on the path toward the 257 Route.Address. 259 Route.NextHopInterface 260 The interface used to send packets toward the Route.Address. 262 Route.Broken 263 A flag indicating whether this Route is broken. This flag is set 264 if the next hop becomes unreachable or in response to processing a 265 RERR (see Section 5.5.4). 267 The following fields are optional: 269 Route.Dist 270 A metric indicating the distance traversed before reaching the 271 Route.Address node. 273 Route.Prefix 274 Indicates that the associated address is a network address, rather 275 than a host address. The value is the length of the netmask/ 276 prefix. If an address block does not have an associated 277 PREFIX_LENGTH TLV [I-D.ietf-manet-packetbb], the prefix may be 278 considered to have a prefix length equal to the address length (in 279 bits). 281 Not including optional information may cause performance degradation, 282 but it will not cause the protocol to operate incorrectly. 284 In addition to a route table data structure, each route table entry 285 may have several timers associated with the information. These 286 timers/timeouts are discussed in Section 5.2.3. 288 4.2. DYMO Messages 290 When describing DYMO protocol messages, it is necessary to refer to 291 fields in several distinct parts of the overall packet. These 292 locations include the IP or IPv6 header, the UDP header, and fields 293 from [I-D.ietf-manet-packetbb]. This document uses the following 294 notation conventions. Information found in the table. 296 +----------------------------+-------------------+ 297 | Information Location | Notational Prefix | 298 +----------------------------+-------------------+ 299 | IP header | IP. | 300 | UDP header | UDP. | 301 | packetbb message header | MsgHdr. | 302 | packetbb message TLV | MsgTLV. | 303 | packetbb address blocks | AddBlk. | 304 | packetbb address block TLV | AddTLV. | 305 +----------------------------+-------------------+ 307 Table 1 309 4.2.1. Generalized MANET Packet and Message Structure 311 DYMO messages conform to the generalized packet and message format as 312 described in [I-D.ietf-manet-packetbb]. Here is a brief description 313 of the format. A packet is made up of messages. A message is made 314 up of a message header, message TLV block, and zero or more address 315 blocks. Each of the address blocks may also have an associated 316 address TLV block. 318 All DYMO messages specified in this document are sent using UDP to 319 the destination port MANET [I-D.ietf-manet-iana]. 321 Most DYMO messages are sent with the IP destination address set to 322 the link-local multicast address LL MANET ROUTERS unless otherwise 323 stated. Therefore, all DYMO routers SHOULD subscribe to LL MANET 324 ROUTERS for receiving control packets. 326 Unicast DYMO messages specified in this document are sent with the IP 327 destination set to the Route.NextHopAddress of the route to the 328 TargetNode. 330 The IPv4 TTL (IPv6 Hop Limit) field for DYMO messages is set to one 331 (1) for all messages specified in this document. 333 The length of an IP address (32 bits for IPv4 and 128 bits for IPv6) 334 inside a DYMO message depends on the IP packet header containing the 335 DYMO message/packet. For example, if the IP header uses IPv6 336 addresses then all messages and addresses contained in the payload 337 use IPv6 addresses. In the case of mixed IPv6 and IPv4 addresses, 338 please see [I-D.ietf-manet-packetbb]. 340 If a packet contains only a single DYMO message and no packet TLVs, 341 it need not include a packet-header [I-D.ietf-manet-packetbb]. 343 The aggregation of multiple messages into a packet is not specified 344 in this document, but the IP.SourceAddress and IP.DestinationAddress 345 of all contained messages must be the same. 347 Implementations may choose to temporarily delay transmission of 348 messages for the purpose of aggregation (into a single packet) or to 349 improve performance by introducing jitter [I-D.ietf-manet-jitter]. 351 4.2.2. Routing Messages (RM) - RREQ & RREP 353 Routing Messages (RMs) are used to disseminate routing information. 354 There are two DYMO message types that are considered to be routing 355 messages (RMs): RREQ and RREP. They contain very similar information 356 and function, but have slightly different processing rules. The main 357 difference between the two messages is that RREQ messages generally 358 solicit a RREP, whereas a RREP is the response to RREQ. 360 RM creation and processing are described in Section 5.3. 362 A RM requires the following information: 364 IP.DestinationAddress 365 The IP address of the packet destination. For RREQ the 366 IP.DestinationAddress is set to LL MANET ROUTERS. For RREP the 367 IP.DestinationAddress is set to the NextHopAddress toward the RREP 368 TargetNode. 370 UDP.DestinationPort 371 The UDP destination port is set to MANET [I-D.ietf-manet-iana]. 373 MsgHdr.HopLimit 374 The remaining number of hops this message is allowed to traverse. 376 AddBlk.TargetNode.Address 377 The IP address of the message TargetNode. In a RREQ the 378 TargetNode is the destination for which a forwarding route does 379 not exist and route discovery is being performed. In a RREP the 380 TargetNode is the RREQ OrigNode DYMO router. The TargetNode 381 address is the first address in a routing message. 383 AddBlk.OrigNode.Address 384 The IP address of the originator. In a RREQ the OrigNode is the 385 source's DYMO router for which a route discovery is being 386 performed. In a RREP the OrigNode is the RREQ TargetNode's DYMO 387 router for which a RREP is being generated. This address is the 388 second address in the message for RREQ. 390 OrigNode.AddTLV.SeqNum 391 The DYMO sequence number of the originator's DYMO router. 393 A RM may optionally include the following information: 395 TargetNode.AddTLV.SeqNum 396 The last known DYMO sequence number of the TargetNode. 398 TargetNode.AddTLV.Dist 399 The last known distance to the TargetNode. 401 AddBlk.AdditionalNode.Address 402 The IP address of an additional node that can be reached via the 403 DYMO router adding this information. Each AdditionalNode.Address 404 must have an associated Node.SeqNum in the address TLV block. 406 AdditionalNode.AddTLV.SeqNum 407 The DYMO sequence number associated with this routing information. 409 Node.AddTLV.Dist 410 A metric of the distance to reach the associated Node.Address. 411 This field is incremented by at least one at each intermediate 412 DYMO router, except the TargetNode.AddTLV.Dist. The TargetNode's 413 distance information is not modified. 415 Node.AddTLV.Prefix 416 The Node.Address is a network address with a particular prefix 417 length. 419 Example IPv4 RREQ 421 0 1 2 3 422 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 424 IP Header 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | IP.DestinationAddress = LL MANET ROUTERS | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 ... 430 UDP Header 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Destination Port = MANET | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ... 435 Message Header 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | RREQ-type | Rsv |N|1|1|0|1| msg-size=23 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | msg-hoplimit | 440 +-+-+-+-+-+-+-+-+ 441 ... 442 Message Body - Message TLV Block 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | msg-tlv-block-size=0 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Message Body - Address Block 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |Number Addrs=2 | Resv |0|1|0| HeadLength=3 | Head : 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 : Head (cont) | Target.Tail | Orig.Tail | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Message Body - Address Block TLV Block 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | tlv-block-size=6 |DYMOSeqNum-type|Rsv|0|1|0|0|0|0| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 1 461 4.2.3. Route Error (RERR) 463 A RERR message is used to disseminate the information that a route is 464 not available for one or more particular IP addresses. 466 RERR creation and processing are described in Section 5.5. 468 A RERR requires the following information: 470 IP.DestinationAddress 471 The IP address is set to LL MANET ROUTERS. 473 UDP.DestinationPort 474 The UDP destination port is set to MANET [I-D.ietf-manet-iana]. 476 MsgHdr.HopLimit 477 The remaining number of hops this message is allowed to traverse. 479 AddBlk.UnreachableNode.Address 480 The IP address of an UnreachableNode. Multiple unreachable 481 addresses may be included in a RERR. 483 A Route Error may optionally include the following information: 485 UnreachableNode.AddTLV.SeqNum 486 The last known DYMO sequence number of the unreachable node. If a 487 SeqNum for an address is not included, it is assumed to be 488 unknown. This case occurs when a node receives a message to 489 forward to a destination for which it does not have any 490 information in its routing table. 492 Example IPv4 RERR 494 0 1 2 3 495 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 497 IP Header 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | IP.DestinationAddress = LL MANET ROUTERS | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 ... 503 UDP Header 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Destination Port = MANET | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 ... 508 Message Header 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | RERR-type |Resv |0|1|1|0|1| msg-size=15 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | msg-hoplimit | 513 +-+-+-+-+-+-+-+-+ 514 ... 515 Message Body 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | msg-tlv-block-size=0 |Number Addrs=1 | Resv |0|1|1| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Unreachable.Address | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TLV-blk-size=0 | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 2 526 5. Detailed Operation 528 5.1. DYMO Sequence Numbers 530 DYMO sequence numbers allow nodes to judge the freshness of routing 531 information and ensure loop freedom. 533 5.1.1. Maintaining A Node's Own Sequence Number 535 DYMO requires that each DYMO router in the network to maintain its 536 own DYMO sequence number (OwnSeqNum), a 16-bit unsigned integer. The 537 circumstances for ThisNode to incrementing its OwnSeqNum are 538 described in Section 5.3. 540 5.1.2. Numerical Operations on OwnSeqNum 542 When ThisNode increments its OwnSeqNum (as described in Section 5.3) 543 it MUST do so by treating the sequence number value as an unsigned 544 number. 546 Note: The sequence number zero (0) is reserved. 548 5.1.3. OwnSeqNum Rollover 550 If the sequence number has been assigned to be the largest possible 551 number representable as a 16-bit unsigned integer (i.e., 65535), then 552 the sequence number is set to 256 when incremented. Setting the 553 sequence number to 256 allows other nodes to detect that the number 554 has rolled over and the node has not lost its sequence number. 556 5.1.4. Actions After OwnSeqNum Loss 558 A node should maintain its sequence number in persistent storage, 559 between reboots. 561 If a node's OwnSeqNum is lost, it must take certain actions to avoid 562 creating routing loops. To prevent this possibility after OwnSeqNum 563 loss a node MUST wait for at least ROUTE_DELETE_TIMEOUT before fully 564 participating in the DYMO routing protocol. If a DYMO control 565 message is received during this waiting period, the node SHOULD 566 process it normally but MUST not transmit or retransmit any DYMO 567 messages. If a data packet is received for forwarding to another 568 destination during this waiting period, the node MUST generate a RERR 569 message indicating that this route is not available and reset its 570 waiting timeout. At the end of the waiting period a node sets its 571 OwnSeqNum to one (1). 573 The longest a node must wait is ROUTE_AGE_MAX_TIMEOUT. At the end of 574 the maximum waiting period a node sets its OwnSeqNum to one (1) and 575 begins participating. 577 5.2. DYMO Routing Table Operations 579 5.2.1. Judging Routing Information's Usefulness 581 Given a route table entry (Route.SeqNum, Route.Dist, and 582 Route.Broken) and new incoming routing information for a particular 583 node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/ 584 RREP), the quality of the new routing information is evaluated to 585 determine its usefulness. Incoming routing information is classified 586 as follows: 588 1. Stale 589 If Node.SeqNum - Route.SeqNum < 0 (using signed 16-bit arithmetic) 590 the incoming information is stale. Using stale routing 591 information is not allowed, since doing so might result in routing 592 loops. 594 (Node.SeqNum - Route.SeqNum < 0) 596 2. Loop-possible 597 If Node.SeqNum == Route.SeqNum the incoming information may cause 598 loops if used; in this case additional information must be 599 examined. If Route.Dist or Node.Dist is unknown or zero (0), then 600 the routing information is loop-possible. If Node.Dist > 601 Route.Dist + 1, then the routing information is loop-possible. 602 Using loop-possible routing information is not allowed, otherwise 603 routing loops may be formed. 605 (Node.SeqNum == Route.SeqNum) AND 606 ((Node.Dist is unknown) OR 607 (Route.Dist is unknown) OR 608 (Node.Dist > Route.Dist + 1)) 610 3. Inferior 611 In case of known equal SeqNum, the information is inferior, if 612 Node.Dist > Route.Dist (it is a greater distance route). In case 613 of equal SeqNum, the information is inferior, if Node.Dist == 614 Route.Dist (equal distance route) AND Route.Broken == false AND 615 this RM is a RREQ. This condition stops forwarding of RREQ with 616 equivalent distance. 618 ((Node.SeqNum == Route.SeqNum) AND 619 ((Node.Dist > Route.Dist) OR 620 ((Node.Dist == Route.Dist) AND 621 (RM is RREQ) AND (Route.Broken == false)))) 623 4. Superior 624 Incoming routing information that does not match any of the above 625 criteria is loop-free and better than the information existing in 626 the routing table. Information is always superior if Node.SeqNum 627 - Route.SeqNum > 0 (using 16-bit signed arithmetic). In the case 628 of equal sequence numbers, the information is superior, if 629 Node.Dist < Route.Dist. In the case of equal sequence numbers, 630 the information is superior, if Node.Dist == Route.Dist AND it is 631 a RREP (RREP with equal distance are forwarded) OR Route.Broken == 632 true (a broken route is being repaired). For completeness, we 633 provide the following (optimized) pseudo-code. 635 (Node.SeqNum - Route.SeqNum > 0) OR 636 ((Node.SeqNum == Route.SeqNum) AND 637 ((Node.Dist < Route.Dist) OR 638 ((Node.Dist == Route.Dist) AND 639 ((RM is RREP) OR (Route.Broken == true))))) 641 5.2.2. Creating or Updating a Route Table Entry with New Routing 642 Information 644 The route table entry is populated with the following information: 646 1. the Route.Address is set to Node.Address, 648 2. the Route.SeqNum is set to the Node.SeqNum, 650 3. the Route.NextHopAddress is set to the node that transmitted this 651 DYMO RM packet (i.e., the IP.SourceAddress), 653 4. the Route.NextHopInterface is set to the interface that this DYMO 654 packet was received on, 656 5. if known, the Route.Dist is set to the Node.Dist, 658 6. if known, the Route.Prefix is set to the Node.Prefix. 660 Fields without known values are not populated with any value. 662 Previous timers for this route table entry are removed. A timer for 663 the minimum delete timeout (ROUTE_AGE_MIN) is set to 664 ROUTE_AGE_MIN_TIMEOUT. A timer to indicate a recently learned route 665 (ROUTE_NEW) is set to ROUTE_NEW_TIMEOUT. A timer for the maximum 666 delete timeout (ROUTE_AGE_MAX). ROUTE_AGE_MAX is set to 667 Node.AddTLV.MaxAge if included; otherwise, ROUTE_AGE_MAX is set to 668 ROUTE_AGE_MAX_TIMEOUT. The usage of these timers and others are 669 described in Section 5.2.3. 671 At this point, a forwarding route should be installed. Afterward, 672 the route can be used to send any queued data packets and forward any 673 incoming data packets for Route.Address. This route also fulfills 674 any outstanding route discovery attempts for Node.Address. 676 5.2.3. Route Table Entry Timeouts 678 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) 680 When a DYMO router transmits a RM, other DYMO routers expect the 681 transmitting DYMO router to have a forwarding route to the RM 682 originator. After updating a route table entry, it should be 683 maintained for at least ROUTE_AGE_MIN. Failure to maintain the 684 information might result in lost messages/packets, or in the worst 685 case scenario several duplicate messages. 687 After the ROUTE_AGE_MIN timeout a route can safely be deleted. 689 5.2.3.2. Maximum Delete Timeout (ROUTE_AGE_MAX) 691 Sequence number information is time sensitive, and must be deleted 692 after a time in order to avoid conflicts due to reboots and 693 rollovers. When a DYMO router has lost its sequence number (e.g, due 694 to daemon reboot or node replacement) the DYMO router must wait until 695 routing information associated with that IP address and sequence 696 number are no longer maintained by other DYMO routers in the network 697 to ensure loop-free routing. 699 After the ROUTE_AGE_MAX timeout a route must be deleted. All 700 information about the route is deleted upon ROUTE_AGE_MAX timeout. 701 If a forwarding route exists it is also removed. 703 5.2.3.3. New Information Timeout (ROUTE_NEW) 705 As time progresses the likelihood that a route remains intact 706 decreases, if the network nodes are mobile. Maintaining and using 707 old routing information can lead to many DYMO messages and excess 708 route discovery delay. 710 After the ROUTE_NEW timeout if the route has not been used, a timer 711 for deleting the route (ROUTE_DELETE) is set to ROUTE_DELETE_TIMEOUT. 713 5.2.3.4. Recently Used Timeout (ROUTE_USED) 715 When a route is used to forward data packets, this timer is set to 716 expire after ROUTE_USED_TIMEOUT. This operation is also discussed in 717 Section 5.5.2. 719 If a route has not been used recently, then a timer for ROUTE_DELETE 720 is set to ROUTE_DELETE_TIMEOUT. 722 5.2.3.5. Delete Information Timeout (ROUTE_DELETE) 724 As time progresses the likelihood that old routing information is 725 useful decreases, especially if the network nodes are mobile. 726 Therefore, old information should be deleted. 728 After the ROUTE_DELETE timeout, the routing table entry should be 729 deleted. If a forwarding route exists, it should also be removed. 731 5.3. Routing Messages 733 5.3.1. RREQ Creation 735 When a DYMO router creates a RREQ it SHOULD increment its OwnSeqNum 736 by one (1) according to the rules specified in Section 5.1.2. 737 Incrementing OwnSeqNum will ensure that all nodes with existing 738 routing information to consider this new information fresh. If the 739 sequence number is not incremented, certain DYMO routers might not 740 consider this information useful if they have superior information 741 already. 743 First, ThisNode adds the AddBlk.TargetNode.Address to the RREQ; the 744 IP.DestinationAddress for which a forwarding route does not exist. 746 If a previous value of the TargetNode.SeqNum is known (from a routing 747 table entry using longest-prefix matching), it SHOULD be placed in 748 TargetNode.AddTLV.SeqNum in all but the last RREQ attempt. If a 749 TargetNode.SeqNum is not included, it is assumed to be unknown by 750 processing nodes. This operation ensures that no intermediate DYMO 751 routers reply, and ensures that the TargetNode's DYMO router 752 increments its sequence number. 754 Similarly, if a previous value of the TargetNode.Dist is known, it 755 SHOULD be placed in TargetNode.AddTLV.Dist. Otherwise, the 756 TargetNode.AddTLV.Dist is not included and assumed unknown by 757 processing nodes. 759 Next, the node adds AddBlk.OrigNode.Address to the RM and the 760 OrigNode.AddTLV.SeqNum (OwnSeqNum) in an address block TLV. 762 The OrigNode.Address is the address of the DYMO router that is 763 initiating this route discovery. The OrigNode.Address must be a 764 routable IP address. If this DYMO router is performing route 765 discovery on behalf of an attached node (the source of the data 766 packet forcing this route discovery), it MUST advertise it's address 767 and prefix that contain the source address. This information will be 768 used by nodes to create a route toward the OrigNode, enable delivery 769 of a RREP, and eventually for data packets. 771 If OrigNode.Dist is included it is set to zero (0). 773 The MsgHdr.HopLimit should be set to MAX_HOPLIMIT, but may be set 774 smaller. 776 For RREQ, the MsgHdr.HopLimit may be set in accordance with an 777 expanding ring search as described in [RFC3561] to limit the RREQ 778 propagation to a subset of the network and possibly reduce route 779 discovery overhead. 781 The IP.DestinationAddress for RREQ is set to LL MANET ROUTERS. 783 5.3.2. RREP Creation 785 When the TargetNode's DYMO router creates a RREP, if the 786 TargetNode.SeqNum was not included in the RREQ it MUST increment its 787 OwnSeqNum by one (1) according to the rules specified in 788 Section 5.1.2. 790 If TargetNode.SeqNum is included in the RM and TargetNode.SeqNum from 791 the RM is less than OwnSeqNum, OwnSeqNum SHOULD be incremented by one 792 (1) according to the rules specified in Section 5.1.2. 794 If OwnSeqNum is not incremented the routing information might be 795 considered stale. In this case, the RREP would not reach the RREP 796 Target. 798 First, the AddBlk.TargetNode.Address is added to the RREP. The 799 TargetNode is the ultimate destination of this RREP; the RREQ 800 OrigNode.Address. 802 Next, AddBlk.OrigNode.Address is added to the RREP. The 803 AddBlk.OrigNode.Address must be a routable IP address. If the RREQ 804 TargetNode is this DYMO router, its address added to the RREP as the 805 OrigNode.Address. If the RREQ TargetNode is attached to this DYMO 806 router, it MUST advertise its address and prefix that contain the 807 RREQ TargetNode.Address. The RREP OrigNode.AddTLV.SeqNum (OwnSeqNum) 808 must also added to the RREP. 810 Other AddTLVs in the RREP for the OrigNode and TargetNode SHOULD be 811 included and set accordingly. If OrigNode.Dist is included it is set 812 to zero (0). 814 The MsgHdr.HopLimit is set to MAX_HOPLIMIT. 816 The IP.DestinationAddress for RREP is set to the IP address of the 817 Route.NextHopAddress for the route to the RREP TargetNode. 819 5.3.3. Intermediate DYMO Router RREP Creation 821 Sometimes a DYMO router other than the TargetNode's DYMO router (call 822 it an "intermediate DYMO router") has routing information that can 823 satisfy an incoming RREQ. When an intermediate DYMO router 824 originates a RREP in response to a RREQ on behalf of the TargetNode, 825 it sends the RREP to the RREQ OrigNode with additional routing 826 information (Address, SeqNum, etc.) about the RREQ TargetNode. 828 Appending additional routing information is described in 829 Section 5.3.5. 831 The Intermediate DYMO router SHOULD also issue a RREP to the RREQ 832 TargetNode, so that the RREQ TargetNode receives routing information 833 on how to reach the RREQ OrigNode. 835 When an intermediate DYMO router creates this RREP, it sends a RREP 836 to the RREQ TargetNode with additional routing information (Address, 837 SeqNum, etc.) about the RREQ OrigNode. 839 5.3.4. RM Processing 841 Before processing a RM, the DYMO router checks the IP.Destination to 842 ensure that it was sent to LL MANET ROUTERS. 844 When a RM is received the MsgHdr.HopLimit is decremented by one (1) 846 For each address (except the TargetNode) in the RM that includes 847 AddTLV.Dist information, the AddTLV.Dist information is incremented 848 by one (1). 850 Next, ThisNode checks whether AddBlk.OrigNode.Address is an address 851 handled by this DYMO router. If this node is the originating DYMO 852 router, the RM is dropped. 854 Next, ThisNode checks whether its routing table has an entry to the 855 AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If 856 a route does not exist and the address is a unicast address, then the 857 new routing information is considered fresh and a new route table 858 entry is created and updated as described in Section 5.2.2. If a 859 route table entry does exists, the incoming routing information is 860 compared with the route table entry following the procedure described 861 in Section 5.2.1. If the incoming routing information is considered 862 superior, the route table entry is updated as described in 863 Section 5.2.2. 865 After processing the OrigNode's routing information, then each 866 address that is not the TargetNode should be considered for creating 867 and updating routes. Creating and updating routes to other nodes can 868 eliminate RREQ for those IP destinations, in the event that data 869 needs to be forwarded to the IP destination(s) in the near future. 871 For each of the additional addresses considered, if the address is a 872 unicast address and the routing table does not have a matching route 873 using longest-prefix matching, then a route is created and updated as 874 described in Section 5.2.2. If a route table entry exists, the 875 incoming routing information is compared with the route table entry 876 following the procedure described in Section 5.2.1. If the incoming 877 routing information is considered superior, the route table entry is 878 updated as described in Section 5.2.2. 880 If the routing information for an AdditionalNode.Address is not a 881 unicast address and considered superior, then it is removed from the 882 RM. Removing this information ensures that the information is not 883 propagated. 885 At this point, if the routing information for the OrigNode was not 886 superior then this RM should be discarded and no further processing 887 of this message is performed. 889 If the ThisNode is the DYMO router for the TargetNode and this RM is 890 a RREQ, then ThisNode responds with a RREQ flood (a RREQ addressed to 891 oneself) or a RREP to the RREQ OrigNode (the new RREP's TargetNode). 892 The procedure for issuing a new RREP is described in Section 5.3.2. 893 Note: it is important that when creating the RREP, the RREP 894 OrigNode.Address be the same as the RREQ TargetNode.Address, if 895 ThisNode is responsible for several addresses. At this point, 896 ThisNode need not perform any more operations for this RM. 898 If ThisNode is not the TargetNode, this RM is a RREQ, the RREQ 899 contains the TargetNode.AddTLV.SeqNum, and ThisNode has a forwarding 900 route to the TargetNode with a SeqNum (Route.TargetNode.SeqNum) 901 greater than or equal to the RREQ TargetNode.AddTLV.SeqNum; then this 902 node MAY respond with an intermediate DYMO router RREP. The 903 procedure for performing intermediate DYMO router RREP is described 904 in Section 5.3.3. At this point, ThisNode need not perform any more 905 operations for this RM. 907 After processing a RM or creating a new RM, a node can append 908 additional routing information to the RM, according to the procedure 909 described in Section 5.3.5. The additional routing information can 910 help reduce route discoveries at the expense of increased message 911 size. 913 For each address (except the TargetNode) in the RM that includes 914 AddTLV.Dist information, the AddTLV.Dist information is incremented 915 by a cost value. Advice regarding the cost value is not included in 916 this specification, it is left up to the implementation. 918 The updated distance value will be an measure in determining whether 919 the routing information is inferior or superior to known information 920 at other DYMO routers that process this RM. 922 If the resulting distance value for the OrigNode is greater than 254, 923 the message is discarded. If the resulting distance value for 924 another node is greater than 254, the associated address and its 925 information are removed from the RM. 927 If this RM's MsgHdr.HopLimit is greater than or equal to one (1), 928 ThisNode is not the TargetNode, AND this RM is a RREQ, then the 929 current RM (altered by the procedure defined above) SHOULD be sent to 930 the LL MANET ROUTERS IP.DestinationAddress. 932 By sending the RM ThisNode is advertising that it will provide 933 routing for IP addresses contained in the outgoing RM based on the 934 information enclosed. ThisNode MAY choose not to send the RM, though 935 not resending this RM could decrease connectivity in the network or 936 result in a non-shortest distance path. 938 Some examples of why ThisNode might choose to not send the RM are: if 939 ThisNode does not want to advertise routing for the contained IP 940 addresses because it is already congested; if ThisNode has already 941 issued nearly identical routing information (e.g. ThisNode had 942 recently issued a RM with nearly the same distance); or if ThisNode 943 is low on energy and does not want to expend energy for control 944 message sending or packet forwarding. This type of advanced behavior 945 is not defined in this specification. 947 If this RM's MsgHdr.HopLimit is greater than or equal to one (1), 948 ThisNode is not the TargetNode, AND this RM is a RREP, then the 949 current RM is sent to the Route.NextHopAddress for the RREP's 950 TargetNode.Address. If no forwarding route exists to Target.Address, 951 then a RERR is issued to the OrigNode of the RREP. 953 5.3.5. Adding Additional Routing Information to a RM 955 Appending routing information can alleviate route discovery attempts 956 to the nodes whose information is included, if other DYMO routers use 957 this information to update their routing tables. 959 DYMO routers can append routing information to a RM. This option 960 should be administratively configurable. 962 Prior to appending an address controlled by this DYMO router to a RM, 963 ThisNode MAY increment its OwnSeqNum as defined in Section 5.1.2. If 964 OwnSeqNum is not incremented the appended routing information might 965 not be considered fresh, when received by nodes with existing routing 966 information. Incrementation of the sequence number when appending 967 information to an RM in transit should be administratively 968 configurable. 970 If an address controlled by this DYMO router is included 971 ThisNode.Dist, it is set to zero (0). Additional information about 972 the address(es) can also be appended, such as a PREFIX_LENGTH AddTLV. 974 5.4. Route Discovery 976 When a source's DYMO router needs to forward a data packet and it 977 does not have a forwarding route to the IP.DestinationAddress, it 978 sends a RREQ (described in Section 5.3.1) to discover a route to the 979 particular destination (TargetNode). 981 After issuing a RREQ, the OrigNode DYMO router waits for a route to 982 be created to the TargetNode. If a route is not created within 983 RREQ_WAIT_TIME, ThisNode may again try to discover a route by issuing 984 another RREQ. 986 To reduce congestion in a network, repeated attempts at route 987 discovery for a particular TargetNode should utilize an exponential 988 backoff. 990 For example, the first time a DYMO router issues a RREQ, it waits 991 RREQ_WAIT_TIME for a route to the TargetNode. If a route is not 992 found within that time, the DYMO router MAY send another RREQ. If a 993 route is not found within two (2) times the current waiting time, 994 another RREQ may be sent, up to a total of RREQ_TRIES. For each 995 additional attempt, the waiting time for the previous RREQ is 996 multiplied by two (2) so that the waiting time conforms to a binary 997 exponential backoff. 999 Data packets awaiting a route should be buffered by the source's DYMO 1000 router. This buffer should have a fixed limited size 1001 (BUFFER_SIZE_PACKETS or BUFFER_SIZE_BYTES) and older data packets 1002 SHOULD be discarded first. 1004 Buffering of data packets may have positive or negative impact, and 1005 therefore must be administratively configurable. 1007 If a route discovery has been attempted RREQ_TRIES times without 1008 receiving a route to the TargetNode, all data packets destined for 1009 the corresponding TargetNode are dropped from the buffer and a 1010 Destination Unreachable ICMP message should be delivered to the 1011 source. 1013 5.5. Route Maintenance 1015 A RERR MUST be issued if a data packet is to be forwarded and it 1016 cannot be delivered to the next hop because no forwarding route for 1017 the IP.Destination exists; RERR generation is described in 1018 Section 5.5.3. 1020 Upon this condition, an ICMP Destination Unreachable message SHOULD 1021 NOT be generated unless this router is responsible for the 1022 IP.Destination and that IP.Destination is known to be unreachable. 1024 In addition to inability to forward a data packet, a RERR SHOULD be 1025 issued immediately after detecting a broken link of an forwarding 1026 route to quickly notify DYMO routers that a link break occurred and 1027 that certain routes are no longer available. If the route with the 1028 broken link has not been used recently (indicated by ROUTE_USED), the 1029 RERR SHOULD NOT be generated. 1031 5.5.1. Active Link Monitoring 1033 Nodes MUST monitor next hop links on forwarding routes. This 1034 monitoring can be accomplished by one or several mechanisms, 1035 including: 1037 o Link layer feedback 1039 o Neighborhood discovery [I-D.ietf-manet-nhdp] 1041 o Route timeout 1043 o Other monitoring mechanisms or heuristics 1045 Upon detecting a link break (or an unreachable next hop) ThisNode 1046 must remove the affected forwarding routes (those with an unreachable 1047 next hop). ThisNode also flags these routes as Broken. For each 1048 broken route a timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT. 1050 5.5.2. Updating Route Lifetimes During Packet Forwarding 1052 To avoid removing the forwarding route to reach the IP.SourceAddress, 1053 a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for 1054 the route to the IP.SourceAddress upon receiving a data packet. If a 1055 timer for ROUTE_DELETE is set, it is removed. 1057 To avoid removing the forwarding route to the IP.DestinationAddress 1058 that is being used, a node SHOULD set a timeout (ROUTE_USED) to 1059 ROUTE_USED_TIMEOUT for the route to the IP.DestinationAddress upon 1060 sending a data packet. If a timer for ROUTE_DELETE is set, it is 1061 removed. 1063 5.5.3. Route Error Generation 1065 A RERR informs DYMO routers that a route to certain destinations is 1066 not available through this node. 1068 When creating a new RERR, the address of first UnreachableNode 1069 (IP.DestinationAddress from a data packet or RREP.TargetNode.Address) 1070 is inserted into an Address Block AddBlk.UnreachableNode.Address. If 1071 a value for the UnreachableNode's SeqNum 1072 (UnreachableNode.AddTLV.SeqNum) is known, it SHOULD be placed in the 1073 RERR. The MsgHdr.HopLimit is set to MAX_HOPLIMIT. 1075 Additional UnreachableNodes that require the same unavailable link 1076 (routes with the same Route.NextHopAddress and 1077 Route.NextHopInterface) SHOULD be added to the RERR, as additional 1078 AddBlk.UnreachableNode.Address. The SeqNum if known SHOULD also be 1079 included. Appending UnreachableNode information notifies each 1080 processing node of additional routes that are no longer available. 1081 This option SHOULD be administratively configurable. 1083 If SeqNum information is not known or not included in the RERR, all 1084 nodes processing the RERR will assume their routing information 1085 associated with the UnreachableNode is no longer valid and flags 1086 those routes as broken. 1088 The RERR is sent to the IP.DestinationAddress LL MANET ROUTERS. 1089 Sending the RERR to the LL MANET ROUTERS address notifies nearby 1090 nodes that might depend on the now broken link. 1092 The packet or message that forced generation of this RERR is 1093 discarded. 1095 5.5.4. RERR Processing 1097 Before processing a RERR, the DYMO router checks the IP.Destination 1098 to ensure that it is addressed to LL MANET ROUTERS. 1100 When a DYMO router processes a RERR, it processes each 1101 UnreachableNode's information. The processing DYMO router removes 1102 the forwarding route and sets the broken flag for each 1103 UnreachableNode.Address found using longest prefix matching that meet 1104 all of the following conditions: 1106 1. The UnreachableNode.Address is a unicast address. 1108 2. The Route.NextHopAddress is the same as the RERR 1109 IP.SourceAddress. 1111 3. The Route.NextHopInterface is the same as the interface on which 1112 the RERR was received. 1114 4. The Route.SeqNum is zero (0), unknown, OR the 1115 UnreachableNode.SeqNum is zero (0), unknown, OR Route.SeqNum - 1116 UnreachableNode.SeqNum <= 0 (using signed 16-bit arithmetic). 1118 Each UnreachableNode that did not result in a broken route is removed 1119 from the RERR, since propagation of this information will not result 1120 in any benefit. Any other information (AddTLVs) associated with the 1121 removed address(es) is also removed. 1123 If no UnreachableNode addresses remain in the RERR, no other 1124 processing is required and the RERR is discarded. 1126 If this RERR's MsgHdr.HopLimit is greater than one (1) and at least 1127 one unreachable node address remains in the RERR, then the updated 1128 RERR is sent to the IP.DestinationAddress LL MANET ROUTERS. 1130 5.6. Unknown Message & TLV Types 1132 If a message with an unknown type is received, the message is 1133 discarded. 1135 If a message contains TLVs of an unknown type, a node ignores these 1136 during processing. The processing node can remove these TLVs from 1137 any resulting transmitted messages. The behavior for unknown TLV 1138 types should be administratively configurable. 1140 5.7. Advertising Network Addresses 1142 Any DYMO router advertises a network address by using a PREFIX_LENGTH 1143 TLV [I-D.ietf-manet-packetbb]. Any nodes (other than the advertising 1144 DYMO router) within the advertised prefix SHOULD NOT participate in 1145 the DYMO protocol directly and these nodes MUST be reachable by 1146 forwarding packets to the DYMO router advertising connectivity. 1147 Nodes other than the advertising DYMO router that do participate in 1148 DYMO must forward the DYMO control packets to the advertising DYMO 1149 router. For example, A.B.C.1 with a prefix length of 24 indicates 1150 all nodes with the matching A.B.C.X are reachable through the DYMO 1151 router with address A.B.C.1. 1153 5.8. Simple Internet Attachment and Gatewaying 1155 Simple Internet attachment consists of a stub network of MANET router 1156 connected to the Internet via a single Internet gateway node. The 1157 gateway is responsible for responding to RREQs for TargetNodes 1158 outside its configured DYMO prefix, as well as delivering packets to 1159 destinations outside the MANET. 1161 /--------------------------\ 1162 / Internet \ 1163 \ / 1164 \------------+-------------/ 1165 Gateway's | 1166 Advertised | A.B.C.X/24 1167 Prefix | 1168 +-----+-----+ 1169 | DYMO | 1170 /------| Internet |--------\ 1171 / | Gateway | \ 1172 / | A.B.C.1 | \ 1173 | +-----------+ | 1174 | DYMO Region | 1175 | | 1176 | +--------------+ | 1177 | | DYMO Router | | 1178 | | A.B.C.2 | | 1179 | +--------------+ | 1180 | +--------------+ | 1181 | | DYMO Router | | 1182 | | A.B.C.3 | | 1183 \ +--------------+ / 1184 \ / 1185 \---------------------------/ 1187 Figure 7: Simple Internet Attachament Example 1189 DYMO routers wishing to be reachable from nodes in the Internet MUST 1190 have IP addresses within the gateway's configured and advertised 1191 prefix. Given a node with a globally routeable address or care-of 1192 address handled by the gateway, the gateway is responsible for 1193 routing and forwarding packets received from the Internet destined 1194 for nodes inside its MANET. 1196 When DYMO router within the MANET want to send messages to nodes in 1197 the Internet, they simply issue RREQ for those 1198 IP.DestinationAddresses. The gateway is responsible for responding 1199 to RREQ on behalf of the Internet destinations and maintaining their 1200 associated sequence number. 1202 For an Internet gateway and other DYMO routers that maintain the 1203 sequence number on behalf of other nodes, these routers must be 1204 administratively configurable to know the IP addresses for which they 1205 must generate DYMO messages and maintain OwnSeqNum. 1207 5.9. Multiple Interfaces 1209 DYMO may be used with multiple interfaces; therefore, the particular 1210 interface over which packets arrive must be known whenever a packet 1211 is received. Whenever a new route is created, the interface through 1212 which the Route.Address can be reached is also recorded in the route 1213 table entry. 1215 When multiple interfaces are available, a node transmitting a packet 1216 with IP.DestinationAddress set to LL MANET ROUTERS SHOULD send the 1217 packet on all interfaces that have been configured for DYMO 1218 operation. 1220 Similarly, DYMO routers should subscribe to LL MANET ROUTERS on all 1221 their DYMO interfaces. 1223 5.10. Packet/Message Generation Limits 1225 To avoid congestion, a node's rate of packet/message generation 1226 should be limited. The rate and algorithm for limiting messages is 1227 left to the implementor and should be administratively configurable. 1228 Messages should be discarded in the following order of preferences 1229 RREQ, RREP, and finally RERR. 1231 6. Configuration Parameters and Other Administrative Options 1233 Suggested Parameter Values 1235 +------------------------------+------------------------+ 1236 | Name | Value | 1237 +------------------------------+------------------------+ 1238 | MAX_HOPLIMIT | 10 hops | 1239 | NET_TRAVERSAL_TIME | 1000 milliseconds | 1240 | ROUTE_TIMEOUT | 5 seconds | 1241 | ROUTE_AGE_MIN_TIMEOUT | NET_TRAVERSAL_TIME | 1242 | ROUTE_AGE_MAX_TIMEOUT | 60 seconds | 1243 | ROUTE_NEW_TIMEOUT | ROUTE_TIMEOUT | 1244 | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | 1245 | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | 1246 | ROUTE_RREQ_WAIT_TIME | 2 * NET_TRAVERSAL_TIME | 1247 | RREQ_TRIES | 3 tries | 1248 | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | 1249 +------------------------------+------------------------+ 1251 Table 2 1253 These suggested values work well for small and medium well connected 1254 networks with infrequent topology changes. These parameters should 1255 be administratively configurable for the network where DYMO is used. 1256 Ideally, for networks with frequent topology changes the DYMO 1257 parameters should be adjusted using either experimentally determined 1258 values or dynamic adaptation. For example, in networks with 1259 infrequent topology changes ROUTE_USED_TIMEOUT may be set to a much 1260 larger value. 1262 In addition to the parameters above several administrative options 1263 exist. The following table enumerates several of the options and 1264 suggested values. 1266 Suggested Options Settings 1268 +-------------------------------------+----------------------------+ 1269 | Name | Value | 1270 +-------------------------------------+----------------------------+ 1271 | RESPONSIBLE_ADDRESSES | Self or Prefix | 1272 | DYMO_INTERFACES | User Specified | 1273 | INCLUDE_INFORMATION | Yes-SeqNum,Dist,Prefix | 1274 | APPEND_ADDRESS | Yes - RREQ & RREP | 1275 | APPEND_OWN_ADDRESS_INCREMENT_SEQNUM | Yes for RREQ | 1276 | GENERATE_RERR_IMMEDIATELY | No | 1277 | RERR_INCLUDE_ALL_UNREACHABLES | Yes | 1278 | UNKNOWN_TYPE_HANDLING | Ignore | 1279 | BUFFER_SIZE_PACKETS | 50 packets | 1280 | BUFFER_SIZE_BYTES | 1500 * BUFFER_SIZE_PACKETS | 1281 +-------------------------------------+----------------------------+ 1283 Table 3 1285 7. IANA Considerations 1287 DYMO requires a UDP port number to carry protocol packets - MANET 1288 [I-D.ietf-manet-iana]. DYMO also requires the link-local multicast 1289 address LL MANET ROUTERS [I-D.ietf-manet-iana]. 1291 This section specifies several messages types, message tlv-types, and 1292 address tlv-types. 1294 Future types will be allocated using standard actions as described in 1295 [RFC2434]. 1297 7.1. DYMO Message Type Specification 1299 DYMO Message Types 1301 +------------------------+----------+ 1302 | Name | Type | 1303 +------------------------+----------+ 1304 | Route Request (RREQ) | 10 - TBD | 1305 | Route Reply (RREP) | 11 - TBD | 1306 | Route Error (RERR) | 12 - TBD | 1307 +------------------------+----------+ 1309 Table 4 1311 7.2. Packet and Message TLV Type Specification 1313 Packet TLV Types 1315 +-------------------+------+--------+-------------------------------+ 1316 | Name | Type | Length | Value | 1317 +-------------------+------+--------+-------------------------------+ 1318 | Unicast Response | 10 - | 0 | Indicates to the processing | 1319 | Request | TBD | | node that the previous hop | 1320 | | | | (IP.SourceAddress) expects a | 1321 | | | | unicast message within | 1322 | | | | UNICAST_MESSAGE_SENT_TIMEOUT. | 1323 | | | | Any unicast packet will serve | 1324 | | | | this purpose, and it MAY be | 1325 | | | | an ICMP REPLY message. If a | 1326 | | | | message is not sent, then the | 1327 | | | | previous hop may assume that | 1328 | | | | the link is unidirectional | 1329 | | | | and may blacklist the link to | 1330 | | | | this node. | 1331 +-------------------+------+--------+-------------------------------+ 1333 Table 5 1335 7.3. Address Block TLV Specification 1337 Address Block TLV Types 1339 +----------------+-------+--------+---------------------------------+ 1340 | Name | Type | Length | Value | 1341 +----------------+-------+--------+---------------------------------+ 1342 | DYMOSeqNum | 10 - | 16 | The DYMO sequence num | 1343 | | TBD | bits | associated with this address. | 1344 | | | | The sequence number may be the | 1345 | | | | last known sequence number. | 1346 | Distance | 11 - | 8 bits | A metric of the distance | 1347 | | TBD | | traversed by the information | 1348 | | | | associated with this address. | 1349 | MaxAge | 12 - | | The maximum amount of time that | 1350 | | TBD | | information can be maintained | 1351 | | | | before being deleted. This TLV | 1352 | | | | conforms to | 1353 | | | | [I-D.ietf-manet-timetlv] | 1354 | | | | VALIDITY_TIME TLV, except that | 1355 | | | | the TLV is attached to | 1356 | | | | addresses. | 1357 +----------------+-------+--------+---------------------------------+ 1359 Table 6 1361 8. Security Considerations 1363 Currently, DYMO does not specify any special security measures. 1365 In situations where confidentiality o DYMO messages is important, 1366 traditional cryptographic techniques can be applied. 1368 Securing routing information integrity will likely require DYMO 1369 routers to authenticate DYMO messages upon reception. Also, since 1370 routing information is distributed hop-by-hop, DYMO routers will also 1371 likely need to authenticate the source of the routing information, 1372 the source's DYMO router. 1374 Note that is important that any confidentiality and integrity 1375 algorithms used permit multiple receivers to process the message, 1376 since all DYMO messaging is multicast. 1378 9. Acknowledgments 1380 DYMO is a descendant of the design of previous MANET reactive 1381 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 1382 previous MANET reactive protocols stem from research and 1383 implementation experiences. Thanks to Elizabeth Belding-Royer for 1384 her long time authorship of DYMO. Additional thanks to Luke Klein- 1385 Berndt, Pedro Ruiz, Fransisco Ros, Koojana Kuladinithi, Ramon 1386 Caceres, Thomas Clausen, Christopher Dearlove, Seung Yi, Romain 1387 Thouvenin, Tronje Krop, Henner Jakob and Alexandru Petrescu for 1388 reviewing of DYMO, as well as several specification suggestions. 1390 10. References 1392 10.1. Normative References 1394 [I-D.ietf-manet-iana] 1395 Chakeres, I., "Internet Assigned Numbers Authority (IANA) 1396 Allocations for the Mobile Ad hoc Networks (MANET) 1397 Working Group", draft-ietf-manet-iana-05 (work in 1398 progress), June 2007. 1400 [I-D.ietf-manet-packetbb] 1401 Clausen, T., "Generalized MANET Packet/Message Format", 1402 draft-ietf-manet-packetbb-07 (work in progress), 1403 July 2007. 1405 [I-D.ietf-manet-timetlv] 1406 Clausen, T. and C. Dearlove, "Representing multi-value 1407 time in MANETs", draft-ietf-manet-timetlv-01 (work in 1408 progress), July 2007. 1410 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1411 RFC 1812, June 1995. 1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1414 Requirement Levels", BCP 14, RFC 2119, March 1997. 1416 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1417 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1418 October 1998. 1420 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1421 Architecture", RFC 4291, February 2006. 1423 10.2. Informative References 1425 [I-D.ietf-manet-jitter] 1426 Clausen, T., "Jitter considerations in MANETs", 1427 draft-ietf-manet-jitter-01 (work in progress), July 2007. 1429 [I-D.ietf-manet-nhdp] 1430 Clausen, T., "MANET Neighborhood Discovery Protocol 1431 (NHDP)", draft-ietf-manet-nhdp-04 (work in progress), 1432 July 2007. 1434 [Johnson96] 1435 Johnson, D. and D. Maltz, "Dynamic Source Routing (DSR) in 1436 Ad hoc Networks", In Mobile Computing, Chapter 5, pp. 153- 1437 181, 1996. 1439 [Perkins99] 1440 Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand 1441 Distance Vector (AODV) Routing", Proceedings of the 2nd 1442 IEEE Workshop on Mobile Computing Systems and 1443 Applications, New Orleans, LA, pp. 90-100, 1444 February 1999. 1446 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1447 Demand Distance Vector (AODV) Routing", RFC 3561, 1448 July 2003. 1450 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 1451 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 1452 IPv4", RFC 4728, February 2007. 1454 Authors' Addresses 1456 Ian D Chakeres 1457 Motorola 1458 Bangalore 1459 India 1461 Email: ian.chakeres@gmail.com 1462 URI: http://www.ianchak.com/ 1464 Charles E. Perkins 1465 Palo Alto Systems Research Center 1466 975 Page Mill Road, Suite 200 1467 Palo Alto, CA 94304-1003 1468 USA 1470 Phone: +1-650-496-4402 1471 Fax: +1-650-739-0779 1472 Email: charles.perkins@nokia.com 1474 Full Copyright Statement 1476 Copyright (C) The IETF Trust (2007). 1478 This document is subject to the rights, licenses and restrictions 1479 contained in BCP 78, and except as set forth therein, the authors 1480 retain all their rights. 1482 This document and the information contained herein are provided on an 1483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1485 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1486 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1490 Intellectual Property 1492 The IETF takes no position regarding the validity or scope of any 1493 Intellectual Property Rights or other rights that might be claimed to 1494 pertain to the implementation or use of the technology described in 1495 this document or the extent to which any license under such rights 1496 might or might not be available; nor does it represent that it has 1497 made any independent effort to identify any such rights. Information 1498 on the procedures with respect to rights in RFC documents can be 1499 found in BCP 78 and BCP 79. 1501 Copies of IPR disclosures made to the IETF Secretariat and any 1502 assurances of licenses to be made available, or the result of an 1503 attempt made to obtain a general license or permission for the use of 1504 such proprietary rights by implementers or users of this 1505 specification can be obtained from the IETF on-line IPR repository at 1506 http://www.ietf.org/ipr. 1508 The IETF invites any interested party to bring to its attention any 1509 copyrights, patents or patent applications, or other proprietary 1510 rights that may cover technology that may be required to implement 1511 this standard. Please address the information to the IETF at 1512 ietf-ipr@ietf.org. 1514 Acknowledgment 1516 Funding for the RFC Editor function is provided by the IETF 1517 Administrative Support Activity (IASA).