Mobile Ad hoc Networks Working I. Chakeres Group Boeing Internet-Draft
E. Belding-Royer Expires: April 26, 2006 UC Santa BarbaraC. Perkins Expires: September 6, 2006 Nokia October 23, 2005March 5, 2006 Dynamic MANET On-demand (DYMO) Routing draft-ietf-manet-dymo-03draft-ietf-manet-dymo-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26,September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005).(2006). Abstract The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network.network on-demand. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 3.18 3.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 7 3.28 3.2. DYMO Message Elements . . .Messages . . . . . . . . . . . . . . . 8 3.2.1 Generic DYMO Element Structure .. . . . . . . 10 3.2.1. Generalized MANET Packet and Message Structure . . . . 9 3.2.210 3.2.2. Routing Element (RE)Message (RM) . . . . . . . . . . . . . . . . . 11 3.2.310 3.2.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . 14 3.2.4 Unsupported-element Error (UERR) . . . . . . . . . . . 1512 4. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 16 4.114 4.1. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 16 4.1.114 4.1.1. Maintaining a Sequence Number . . . . . . . . . . . . 16 4.1.214 4.1.2. Incrementing a Sequence Number . . . . . . . . . . . . 16 4.1.314 4.1.3. Sequence Number Rollover . . . . . . . . . . . . . . . 16 4.1.414 4.1.4. Actions After Sequence Number Loss . . . . . . . . . . 16 4.214 4.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 16 4.2.114 4.2.1. Creating or Updating a Route Table Entry from aRouting Block . . . . . . .Message Information . . . . . . . . . . . . . 16 4.2.214 4.2.2. Route Table Entry Timeouts . . . . . . . . . . . . . . 18 4.316 4.3. Routing ElementMessage . . . . . . . . . . . . . . . . . . . . . 18 4.3.116 4.3.1. Routing ElementMessage Creation . . . . . . . . . . . . . . . 18 4.3.216 4.3.2. Routing ElementMessage Processing . . . . . . . . . . . . . . 18 4.3.316 4.3.3. Appending Additional Routing Information to an Existing Routing ElementMessage . . . . . . . . . . . . . . . 19 4.417 4.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 19 4.518 4.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 20 4.5.118 4.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 20 4.5.218 4.5.2. Updating Route Lifetimes . . . . . . . . . . . . . . . 21 4.5.319 4.5.3. Route Error Generation . . . . . . . . . . . . . . . . 21 4.5.419 4.5.4. Route Error Processing . . . . . . . . . . . . . . . . 22 4.620 4.6. General DYMO Packet and Message Processing . . . . . . . . 21 4.6.1. Packet Processing . . . . . . . . . 22 4.6.1 DYMO Control Packet Processing . . .. . . . . . . . . 22 4.6.221 4.6.2. Generic ElementMessage Pre-processing . . . . . . . . . . . . 23 4.6.321 4.6.3. Processing Unsupported DYMO ElementUnknown Message and TLV Types . . . . . . 23 220.127.116.11 Generating an Unsupported-element Error .. . . . 24 4.6.421 4.6.4. Generic ElementMessage Post-processing . . . . . . . . . . . 24 4.6.521 4.6.5. DYMO Control Packet Transmission . . . . . . . . . . . 24 4.721 4.7. Routing Prefix . . . . . . . . . . . . . . . . . . . . . . 24 4.821 4.8. Simple Internet Attachment and Gatewaying . . . . . . . . . . . . . . . . . . . 25 4.922 4.9. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25 4.1022 4.10. Packet Generation Limits . . . . . . . . . . . . . . . . . 2523 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 2624 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2725 7. Security Considerations . . . . . . . . . . . . . . . . . . . 2826 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2927 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.128 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.228 9.2. Informative References . . . . . . . . . . . . . . . . . . 3028 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30. . 29 Intellectual Property and Copyright Statements . . . . . . . . 32. . 30 1. Overview The Dynamic MANET On-demand (DYMO) routing protocol enables reactive, multihop routing between participating nodes that wish to communicate. The basic operations of the DYMO protocol are route discovery and route management. During route discovery the originating node initiates dissemination of a Route Request (RREQ) throughout the network to find the target node. During this dissemination process, each intermediate node records a route to the originating node. When the target node receives the RREQ, it responds with a Route Reply (RREP) unicast toward the originating node. Each node that receives the RREP records a route to the target node, and then the RREP is unicast toward the originating node. When the originating node receives the RREP, routes have then been established between the originating node and the target node in both directions. In order to react to changes in the network topology nodes maintain their routes and monitor their links. When a data packet is received for a route or link that is no longer available the source of the packet is notified. A Route Error (RERR) is sent to the packet source to indicate the current route is broken. Once the source receives the RERR, it re-initiatescan perform route discovery if it still has packets to deliver. In order to enable extension of the base specification, DYMO defines a generic element structure and handling of future extensions. By defining a fixed structureuses the generalized MANET packet and message format . Additionally, by following the defined default handling,behavior for nodes not understanding a particular type of information, future extensionsenhancements are handled in aan understood and predetermined fashion. DYMO uses sequence numbers as they have been proven to ensure loop freedom . Sequence numbers enable nodes to determine the order of DYMO route discovery packets,messages, thereby avoiding use of stale routing information. All DYMO packetsmessages conform to the generalized MANET message and packet format  and are transmitted via UDP on port TBD. 2. Terminology IP Destination Address (IPDestinationAddress) The destination of a packet, indicatedDYMO Sequence Number (SeqNum) A DYMO Sequence Number is 16-bit number maintained by examining the IP header. IPeach node, and it is used to ensure loop-free routes. Hop Count (HopCnt) The number of hops a particular message or piece of information has traversed. IP Destination Address (IPDestinationAddress) The destination of a packet, determined by examining the IP header. IP Source Address (IPSourceAddress) The source of a packet, indicateddetermined by examining the IP header. DYMOcastMANETcast Packet transmission to all DYMOneighboring MANET routers. DYMOcastMANETcast packets should be sent with an IPDestinationAddress of IPv4 TBD (IPv6 TBD), the DYMOcastAddress.MANETcastAddress. Originator (Orig) The Originator is the node that created a Routing Message in an effort to disseminate and possibly learn new routing information. Prefix A Prefix indicates that an address is a network address, rather than a host address. If a Prefix is omitted, the address is assumed to be a host address. Routing Element (RE)Message (RM) A DYMO message elementthat is used to distribute routing information. Route Invalidation Disabling the use of a route,route; causing it to be unavailable for forwarding data. Route Reply (RREP) Upon receiving a RREQ,RREQ during route discovery, the target node generates a Route Reply (RREP). A RREP is used to disseeminate routing information on how to reach the Target. A RREP is a RERM with a unicast IPDestinationAddress, indicating that this RERM is to be unicast hop-by-hop toward the TargetAddress.Target. Route Error (RERR) A node generates a Route Error (RERR) to disseminate that it does not have correct routing information about a particular destination, or set of destinations. A RERR is most often generated in response to a request to forward a data packet for which the current node does not have a valid route. Route Request (RREQ) A node generates a Route Request (RREQ) to discover a valid route to a particular destination (TargetAddress).(Target). A RREQ is used to disseminate routing information on how to reach the Originator of the RREQ. A RREQ is simply a RERM with the DYMOcastAddressMANETcastAddress in the IPDestinationAddress field of the IP packet. Also, the A-bit is set to one (A=1)packet, causing distribution to indicate thatall neighboring DYMO routers. Target The Target is the TargetNode must respond withultimate destination of a RREP.message. For RREQ this will be the desired destination. For RREP this will be the Originator of the RREQ. Valid Route A known route where the Route.ValidTimeout is greater than the current time. 3. Data Structures 3.13.1. Route Table Entry The route table entry is a conceptual data structure. Implementations may use any internal representation that conforms to the semantics of a route as specified in this document. o Route.DestAddress o Route.DeleteTimeout o Route.HopCnt o Route.IsGateway o Route.NextHopAddress o Route.NextHopInterface o Route.Prefix o Route.SeqNum o Route.ValidTimeout These fields are defined as follows: Route Node Address (Route.DestAddress) The IP address of the node associated with the routing table entry. Route Delete Timeout (Route.DeleteTimeout) If the time current is after Route.DeleteTimeout the corresponding routing table entry MUST be deleted. Route Hop Count (Route.HopCnt) The number of intermediate node hops before reaching the Route.DestAddress. Route Is Gateway (Route.IsGateway) 1-bit selector indicating whether the Route.DestAddress is a gateway.gateway, see Section 4.8. Route Next Hop Address (Route.NextHopAddress) The IP address of the next node on the path toward the Route.DestAddress. Route Next Hop Interface (Route.NextHopInterface) The interface used to send packets toward the Route.DestAddress. Route Prefix (Route.Prefix) 6-bit8-bit field that specifies the size of the subnet reachable through the Route.DestAddress, see Section 4.7. The definition of the Prefix field is different for gateways; entries with Route.IsGateway set to one (1).(1), see Section 4.8. Route Sequence Number (Route.SeqNum) The sequence number of the Route.DestAddress.Route.DestAddress, zero (0) if unknown. Route.ValidTimeout The time at which a route table entry is scheduled to be invalidated. The routing table entry is no longer considered valid if the current time is after Route.ValidTimeout. 3.23.2. DYMO Messages 3.2.1. Generalized MANET Packet and Message Elements 3.2.1 Generic DYMO ElementStructure All DYMO message elements MUSTmessages conform to the fixed data structure below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4generalized packet and message format as described in . 3.2.2. Routing Message (RM) Routing messages are used to disseminate routing information. The two message types are RREQ and RREP and they have the same general format. RREQ messages require a response, while RREP are responses to RREQ. Routing message creation and processing are described in Section 4.3. Example Simple RREQ/RREP Routing Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Len | TTL |I|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . NotifyAddress (Only Types with M-bit set) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TargetAddress (for non-DYMOcastAddress IPDestinationAddresses). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Data . . Type-Specific Payload . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Element Type (Type) 0 0 0 12 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typemsg-type | = |M| HRSRV |U|N|0|1| msg-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-ttl | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+msg-hopcnt | msg-tlv-block-size=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head Length | Head |Number Tails=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TailOrig | TailTarget | tlv-block-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DYMOSEQNUM-type| TLV Length | Orig.SeqNum.: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :.Orig.SeqNum | Target.SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 The Type field identifies1 o RM conform to the elementgeneralized message format. o msg-type = DYMO-RREQ or DYMO-RREP o msg-semantics * RM indicate inclusion of msg-ttl and msg-hop-count in msg- header-info, by setting bit 1 o msg-header-info * RM contains msg-ttl * RM contains msg-hop-count o add-block entries * RM contain 1 and only 1 address marked as wellOriginator - If no address is marked as the handling by nodes that do not implement or understand the element. The most significant bit,originator the M-bit, denotes whetherfirst address is assumed to be the element requires notification via an Unsupported-element Error (UERR) whenOriginator * if the elementRM is unicast (the IPDestinationAddress is not understood or handled bya particular node. The next two bits, H-bits, identify howunicast address), RM contain 1 and only 1 address marked as Target (Target) - if no address is marked the Typesecond address is assumed to be handled by nodes not implementingthe Type, regardless of UERR delivery. Section 4.6.3 describesTarget o add-tlv * RM contain the handling behavior based onDYMO Sequence Number of the Type. I-bit (I) 1-bit selector indicating whetherOriginator (Orig.SeqNum) in a DYMO Sequence Number tlv * RM should contain the element has been ignored by some node that has relayed this element.SeqNum for each address. If I=1the element has been ignored. Reserved (Reserved, Reservd, Res, R) Reserved bits. These bits are set to zeroSeqNum is not included a value of Zero (0) is assumed. For the Target the SeqNum will be the Last Known SeqNum (Target.SeqNum) or Zero (0) during element creation and ignored during processing. Element Timeto Live (TTL) 6-bit fieldindicate that identifiesonly the maximum number of timesTarget can reply * RM should contain the elementHopCnt for each address. If HopCnt is not included, it is assumed to be retransmitted. The TTL field operates similar to IPTTL (MaxCount) and is decremented at each hop. When TTL reacheszero (0) the element is dropped. Element Length (Len) 12-bit field that indicates(unknown). For the size ofTarget the element in bytes, includingHopCnt should be the fixed portion. Element Notify Address (NotifyAddress) The node to sendLast Known HopCnt (Target.HopCnt) * RM should contain a UERR if the Element TypePrefix for each address that is unsupported ornot handled by the processing node. The NotifyAddress fielda host address. If a prefix is only present if the Type field has the M-bitnot included in conjunction with an address, it is set to one (1). Element Target Address (TargetAddress) The nodeassumed zero (host address only). For more information on advertising a Prefix see Section 4.7. * RM should contain a Gateway tlv for an address that is the ultimate destination of the element. This fielda gateway. If gateway indicator is only required ifnot included in association with an address, the IPDestinationAddressaddress is assumed to not the DYMOcastAddress. During hop-by-hop transmission ofbe a DYMO packet the IPDestinationAddress is filled with the Route.NextHopAddress of the route table entry associated with the TargetAddress. Element Data (Data) Type-specific payload. 3.2.2 Routing Element (RE)gateway. For more information on gateway operation see Section 4.8. 3.2.3. Route Error (RERR) Example Simple RERR Message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Lenrerr-msg-type | TTL |I|A|S| ResRSRV |U|N|0|1| msg-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TargetAddress .| msg-ttl | msg-hopcnt | msg-tlv-block-size=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetSeqNumHead Length | Head |Number Tails=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | THopCnt |Res| . +-+-+-+-+-+-+-+-+ . . . . Routing Block 1 (RBlock1) . . .Tail1 | tlv-block-size |dymo-seqnum-typ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additional Routing Blocks . . .| TLV Length | Tail1.SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 A-bit (A) 1-bit selector indicating whether this RE requires a RREP by2 o RERR conform to the TargetAddress. If A=1 a RREP is required. The instructions for generating a RREP are described in Section 4.3.2. S-bit (S) 1-bit selector indicating whether this RE requires a unicastgeneralized message be sent toformat. o msg-type = DYMO-RERR o msg-semantics * RERR indicates inclusion of msg-ttl and msg-hop-count in msg- header-info, using bit 1 o msg-header-info * RERR contain msg-ttl * RERR contain msg-hop-count o add-block entries * All addresses are considered unreachable unless marked otherwise o add-tlvs * RERR should contain SeqNum for each unreachable node. If the previous hop address. This message MAY used bySeqNum is not included in the previous hopmessage it is assumed to ensure thatbe zero (unknown) * RERR should contain the link traversedLast Known HopCnt for each unreachable node. If the HopCnt is not unidirectional. The handling instructions forincluded in the S-bitmessage it is explainedassumed to be zero (unknown) 4. Detailed Operation 4.1. Sequence Numbers 4.1.1. Maintaining a Sequence Number DYMO requires each node in Section 4.3.2. Element Target Address (TargetAddress)the network to maintain its own DYMO sequence number (OwnSeqNum), a 16-bit unsigned integer. The circumstances for a node that is the ultimate destination of the Routing Element. Targetto change its OwnSeqNum are described in Section 4.3.1. 4.1.2. Incrementing a Sequence Number (TargetSeqNum)When a node increments its OwnSeqNum (as described in Section 4.3.1 and Section 4.3.2) it MUST do so by treating the sequence number value as if it was an unsigned number. The sequence number of the ultimate destination of this Routing Element. If the Sequence Numberzero (0) is unknown for this particular Route.DestAddress then TargetSeqNumreserved and is setused in several DYMO data structures to zero (0). Target Hop Count (THopCnt) 6-bit field that identifiesrepresent an unknown sequence number. 4.1.3. Sequence Number Rollover If the sequence number of intermediate nodes through which a packet traversed on the routehas been assigned to this particular TargetAddressbe the last timelargest possible number representable as a route was available. The THopCnt is the Route.HopCnt of16-bit unsigned integer (i.e., 65535), then the TargetAddress, stored insequence number MUST be set to 256 when incremented. Setting the routing table of the RREQ originator. If the hop count information is not available at the originating node then the THopCnt is set to zero (0). Routing Block (RBlock) Data structure that describes routing information related to a particular IP address, RBNodeAddress. Routing Block (RBlock) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| RBPrefix |Res| RBHopCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . RBNodeAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBNodeSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 G-bit (G) 1-bit selector to indicate whether the RBNodeAddress is a gateway. If G=1 RBNodeAddress is a gateway. For more information on gateway operation see Section 4.8. Prefix Size (Prefix) 7-bit field that specifies the size of the subnet reachable through the associated node, see Section 4.7. The definition of Prefix is different for gateways. Routing Block Hop Count (RBHopCnt) 6-bit field that identifies the number of intermediate nodes through which the associated RBlock has passed. Routing Block Node Address (RBNodeAddress) The IP address of the node associated with this RBlock. Routing Block Node Sequence Number (RBNodeSeqNum) The sequence number of the node associated with this RBlock. 3.2.3 Route Error (RERR) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Len | TTL |I|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . UNodeAddress1 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UNodeSeqNum1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Additional UNodeAddressN (if needed) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional UNodeSeqNumN (if needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Unreachable Node Address (UNodeAddress) The IP address of the unreachable node. Unreachable Node Sequence Number (UNodeSeqNum) The sequence number of the unreachable node, if known; otherwise, zero (0). RERR generation is described in Section 4.5.3. 3.2.4 Unsupported-element Error (UERR) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Len | TTL |I|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TargetAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . UElemTargetAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . UERRNodeAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UElemType | +-+-+-+-+-+-+-+-+ Figure 6 Element Target Address (TargetAddress) The node that is the ultimate destination of the element, NotifyAddress. Unsupported-element Target Address (UElemTargetAddress) Address of the destination of the element that caused generation of this UERR; TargetAddress from the offending fixed DYMO element. Unsupported-element Node Address (UERRNodeAddress) The IP address of the node that created the UERR. Unsupported-element Type (UElemType) The Type that required generation of the UERR. 4. Detailed Operation 4.1 Sequence Numbers 4.1.1 Maintaining a Sequence Number DYMO requires each node in the network to maintain its ownsequence number (OwnSeqNum). The circumstances for a nodeto change its OwnSeqNum are described in Section 4.3.1. 4.1.2 Incrementing a Sequence Number When a node increments its OwnSeqNum (as described in Section 4.3.1 and Section 4.3.2) it MUST do so by treating the sequence number value as if it was an unsigned number. The sequence number zero (0) is reserved and is used in several DYMO data structures256 allows other nodes to represent an unknown sequence number. 4.1.3 Sequence Number Rollover Ifdetect that the sequencenumber has been assigned to be the largest possible number representable as a 32-bit unsigned integer (i.e., 4294967295), thenrolled over and the node has not lost its sequence number MUST be set to one (1) when incremented. 4.1.4number. 4.1.4. Actions After Sequence Number Loss A node SHOULD maintain its sequence number in persistent storage. If a node's OwnSeqNum is lost, it must take certain actions to avoid creating routing loops. To prevent this possibility after sequence number loss a node MUST wait for at least ROUTE_DELETE_PERIOD before transmitting anyfully participating in the DYMO packet other than RERR generated by this node.routing protocol. If a DYMO control packetmessage is received during this waiting period, the node SHOULD process it normally but MUST not transmit or retransmit any DYMO control packets.RM. If a data packet is received for forwarding to another destination during this waiting period the node MUST sendgenerate a RERR message to the IPSourceAddress with the UNodeSeqNum set to zero (0)indicating that this route is not available and restartreset its waiting period before transmitting any DYMO control packets exceptperiod. RERR generated by this node. 4.2generation is described in Section 4.5.3. At the end of the waiting period a node sets its sequence number to one (1). 4.2. DYMO Routing Table Operations 18.104.22.168.1. Creating or Updating a Route Table Entry from aRouting BlockMessage Information While processing a RE,RM, as described in Section 4.3.2, a node checks its routing table for an entry to the RBNodeAddressNode.Address using longest- prefix matching.matching . In the event that no matching entry is found, an entry is created. If a matching entry is found, the routing information about RBNodeAddress contained in this RBlock is NOT stale if the result of subtracting the Route.SeqNum from RBNodeSeqNum is greater than zero (0) using signed 32-bit arithmetic. If a matching entry is found, the routing information about RBNodeAddressNode.Address contained in this RBlockRM is NOT stale if the result of subtracting the Route.SeqNum from RBNodeSeqNumNode.SeqNum is equal to zero (0) using signed 32-bit16-bit arithmetic but it SHOULD be disregarded if: o the Route.ValidTimeout has not passed and RBHopCntNode.HopCnt is greater than or equal to Route.HopCnt, OR o the Route.ValidTimeout has passed and RBHopCntNode.HopCnt is greater than Route.HopCnt plus one (1). If the information inassociated with this RBlockNode.Address is stale or disregarded and this RBlockNode.Address is the first RBlock in a RREQOriginator then this DYMO packetmessage MUST be dropped. For other RBlocks containingNode.Addresses that are stale or disregarded routing information,disregarded, the RBlockinformation is simply removed from this RE andthe RELen adjusted.RM. Removing stale and disregarded RBlocksrouting informations ensures that unused information is not propagated further. If the route information for RBNodeAddressNode.Address is not stale, disregardedstale or a disregarded RREP,disregarded, then the following actions occur to the route table entry for RBNodeAddress:Node.Address: 1. the Route.HopCnt is set to the RBHopCnt,Node.HopCnt, 2. the Route.IsGateway is set to the G-bit, 3. the Route.NextHopAddress is set to the node that transmitted this DYMO packet (IPSourceAddress), 4. the Route.NextHopInterface is set to the interface that this DYMO packet was received on, 5. the Route.Prefix is set to RBPrefix,Node.Prefix,, 6. the Route.SeqNum is set to the RBNodeSeqNum,Node.SeqNum, 7. and the Route.ValidTimeout is set to the current time + ROUTE_TIMEOUT. If a valid route exists to RBNodeAddress,Node.Address at this point, the route can be used to send any queued data packets and to fulfill any outstanding route requests. 22.214.171.124.2. Route Table Entry Timeouts If the current time is after Route.DeleteTimeout the corresponding routing table entry MUST be deleted. If the current time is later than a routing entry's Route.ValidTimeout, the route is stale and it is not be used to route packets. The information in invalid entries iscan still be used for generating RREQ messages. If the current time is after Route.DeleteTimeout the corresponding routing table entry MUST be deleted. 4.3filling fields in outgoing RM with last known values. 4.3. Routing Element 4.3.1Message 4.3.1. Routing ElementMessage Creation When a node creates a RREQ it SHOULD increment its OwnSeqNum by one according to the rules specified in Section 4.1.2. When a node creates a RREP, thenRREP in response to a RREQ, it incrementsMUST increment its OwnSeqNum under the following conditions: o TargetSeqNumTarget.SeqNum is greater than OwnSeqNum OR o TargetSeqNumTarget.SeqNum is equal to OwnSeqNum AND Target.HopCnt is unknown OR o Target.SeqNum is equal to OwnSeqNum AND Orig.HopCnt is unknown OR o Target.SeqNum is equal to OwnSeqNum AND THopCntTarget.HopCnt (the last know hop count value) is less than to RBHopCnt.Orig.HopCnt (the number of hops traversed by this RREQ to reach the target). In either case (for(both RREQ orand RREP), the node MUST createadd the first RBlock.Orig.Address to the add-block and the Orig.SeqNum to the add-tlv- block. It sets the RBNodeAddressOrig.Address to its own address. The RBNodeSeqNumOrig.SeqNum is the node's OwnSeqNum. The node mayMAY advertise a prefix using the Prefix field,add-tlv, as described in Section 4.7. Otherwise, the Prefix fieldadd-tlv is set to zero (0).not included. The node mayMAY advertise it is a gateway by setting the G-bit if it isusing a gateway,gateway add-tlv, as described in Section 4.8. Otherwise, the G-bitgateway add-tlv is set to zero (0).not included. The TTLmsg-ttl SHOULD be set to NET_DIAMETER, but MAY be set smaller. ForThe msg-hopcnt is set to zero (0). the case of RREQ, the TTLmsg-ttl MAY be set in accordance with an expanding ring search as described in . 4.3.2 to limit the RREQ propagation to a subset of the network and possibly reduce route discovery overhead. 4.3.2. Routing ElementMessage Processing After general DYMO elementmessage pre-processing (Section 4.6.2), the RBHopCnt for the first RBlock is incremented by one (1). Aa route to the first RBlockOriginator is then created or updated, as described in Section 4.2.1. If this RBlock does not result ina valid route to the packetOriginator is not created or updated then the message MUST be dropped. Each additional RBlockaddress in the address block(s) SHOULD be processed.processed except the Target. For each RBlockof these addresses the Node.HopCnt associated with the RBHopCntaddress is incremented by one (1),(1) if it exists and is not zero, then a route is created or updated as defined in Section 4.2.1. The updating of the HopCnt occurs after processing. Each RBlockaddress resulting in a valid route entry may alleviate a future route discovery. Any RBlocksaddresses that do not result inyield a valid route updateor that are not processed MUST be removed from the RE.RM. Only valid routing information is propagated within RM messages. If this node is the TargetAddressTarget AND the A-bitthis is set (A=1),a RREQ, this node MUST respondresponds with a RREP. The target nodeTarget creates a new RERREP as described in Section 4.3.1. The TargetAddressTarget.Address in the new RERM is set to the RBNodeAddress1Orig.Address from the RERM currently being processed. The THopCntTarget.HopCnt is the hop count for the TargetAddress. The A-bit is set to (A=0).Orig.Address. The IPDestinationAddress is set to the Route.NextHopAddress for the TargetAddress.Orig.Address of the current RM being processed. The TargetSeqNumTarget.SeqNum is set to Route.SeqNum for Orig.Address from the TargetAddress.current RM being processed. Then the new RERM undergoes post-processing, according to Section 4.6.4. After processing a RE,RM, a node MAY append its routing information to the RE,RM, according to the process described in Section 4.3.3. The additional routing information will reduce route discoveries to this node. If all nodes along the path append their information path information will also be available. If this node is not the TargetAddress,Target.Address and this is a RREQ the current RERM SHOULD be handled according to Section 4.6.4.MANETcast. If this node is not the TargetAddress, the current packetTarget Address and any additional elements are processed, butthis packet is not retransmitted. If the S-bitis set to one (1) in the RE, thena unicast messageRREP the current RM SHOULD be sent or have been sentunicast to the previousnext hop within UNICAST_MESSAGE_SENT_TIMEOUT. Any unicast packet will serve this purpose, but it MAY be an ICMP REPLY message.address on the route to the Target. If a messagethis node is not sent, thenthe previous hop may assume thatTarget.Address, the linkcurrent message is unidirectional and may blacklistprocessed, but this node. 4.3.3message is not forwarded or retransmitted. 4.3.3. Appending Additional Routing Information to an Existing Routing ElementMessage Appending routing information will alleviate route discovery attempts to this node from other nodes that process the resultant RE.RM information. Nodes MAY append a RBlocktheir routing information to REa RM processed if the believesthey believe that this additional routing information will alleviate future RREQ. Prior to appending a RBlocktheir address to a RE,RM, a node MUST increment its OwnSeqNum as defined in Section 4.1.2. Then it appends its IP address, OwnSeqNum,address and OwnSeqNum. It MAY also append its Prefix and G-bit to the RE in a RBlock. The RBHopCntRM. This Node.HopCnt is set to zero (0). The RE Len isone (1) if included. Several length fields MUST also be adjusted accordingto include the number of RBlocks in the RE. 4.4newly inserted information. 4.4. Route Discovery A node generates a Route Request (RREQ) to discover a validroute to a particular destination (TargetAddress). A RREQ is a RE with the A-bit is set to one (A=1) to indicate that the TargetNode must respond with a RREP.(Target). If a sequence number is known for the TargetAddressTarget it is placed in the TargetSeqNum field.RREQ. Otherwise, TargetSeqNum is setTarget.SeqNum assumed to zero (0).be unknown by processing nodes. A TargetSeqNumTarget.SeqNum of zero (0) MAY be set to indicate that only the destination may respond to this RREQ. If a hop countprevious value of the HopCnt is known for the TargetAddressTarget it is placed in the THopCnt field.a corresponding add-tlv HopCnt. Otherwise, the THopCntHopCnt is set to zero (0).not included. The IPDestinationAddress is set to the DYMOcastAddress.MANETcastAddress. Then the RERM is thentransmitted according to the procedure defined in Section 4.6.5. After issuing a RREQ, the originating node waits for a route to be created to the TargetNode.Target. If a route is not receivedfound within RREQ_WAIT_TIME milliseconds, this node MAY again try to discover a route by issuing another RREQ. To reduce congestion in a network, repeated attempts at route discovery for a particular TargetNodeTarget SHOULD utilize a binary exponential backoff. The first time a node issues a RREQ, it waits RREQ_WAIT_TIME milliseconds for a route to the TargetNode.Target. If a route is not found within that time, the node MAY send another RREQ. If a route is not found within two (2) times the current waiting time, another RREQ may be sent, up to a total of RREQ_TRIES. For each additional attempt, the waiting time for the previous RREQ is multiplied by two (2) so that the waiting time conforms to a binary exponential backoff. Data packets awaiting fora route SHOULD be buffered. If a route discovery has been attempted RREQ_TRIES times without receiving a route to the TargetNode,Target, all data packets destined for the corresponding TargetNodeTarget SHOULD be dropped from the buffer and a Destination Unreachable ICMP message SHOULD be delivered to the application. 4.54.5. Route Maintenance 126.96.36.199.1. Active Link Monitoring Before a route can be used for forwarding a packet, it MUST be checked to make sure that the route is still valid. If the Route.ValidTimeout is earlier than the current time, the packet cannot be forwarded, and a RERR message MUST be generated (see section Section 4.5.3). In this case, the Route.DeleteTimeout is set to Route.ValidTimeout + ROUTE_DELETE_TIMEOUT. If the current time is after Route.DeleteTimeout, then the route SHOULDMUST be deleted, though a route MAY be deleted at any time. Nodes MUST monitor links on active routes. This may be accomplished by one or several mechanisms. Including: o Link layer feedback o Hello messages o Neighbor discovery o Route timeout o Other monitoring mechanisms or heuristics Upon detecting a link break the detecting node MUST set the Route.ValidTimeout to the current time for all routesactive routes utilizing the broken link. A RERR MUST be issued if a data packet is received and it cannot be delivered to the next hop. RERR generation is described in Section 4.5.3. A RERR SHOULDMAY be issued after detecting a broken link of an active route to quickly notify nodes that a link break occurred and a route or routes are no longer available. If a route has not been used, a RERR SHOULD NOT be generated. 4.5.2generated unless generation is expected to reduce future control traffic. 4.5.2. Updating Route Lifetimes To avoid route timeouts for active routes, a node MUST update the Route.ValidTimeout to the IPSourceAddress to be the current time + ROUTE_TIMEOUT upon receiving a data packet. To avoid route timeouts for active routes, a node SHOULD update the Route.ValidTimeout to the IPDestinationAddress to be the current time + ROUTE_TIMEOUT upon successfully transmitting a packet to the next hop. 188.8.131.52.3. Route Error Generation When a data packet is received for a destination without a valid routing table entry, a Route Error (RERR) MUST be generated by this node. A RERR informs the source that the currentroute does not exist, is no longer available.available, or is now invalid. In thea new RERR, the UNodeAddress1 field is theaddress of theunreachable node (IPDestinationAddress) from the data packet.packet is inserted. If a value for the UNodeSeqNumunreachable node's SeqNum is known, it is placed in the RERR; otherwise, if unknown it will be assumed to be zero (0) is placed in the UNodeSeqNum field of the RERR.(0). The TTLmsg-ttl SHOULD be set to NET_DIAMETER, but may be set smaller. The IPDestinationAddress is setsmaller to limit the DYMOcastAddress. Additional unreachable nodes that required the same unavailable link (routes with the same Route.NextHopAddress and Route.NextHopInterface) as the UNodeAddress1 SHOULD be appended toscope of the RERR. For each unreachable node the UNodeAddress and UNodeSeqNum are appended.The Lenmsg-hopcnt is set accordingly.to zero (0). The RERRIPDestinationAddress is then processed as described in Section 4.6.5. 4.5.4 Route Error Processing When a node processes a RERR after generic element pre-processing (Section 4.6.2), it SHOULDset the Route.ValidTimeoutto the current time for each route to a UNodeAddress that meets all of the following conditions: 1. The Route.NextHopAddress is the same as the RERR IPSourceAddress. 2. The Route.NextHopInterface is the same as the interface on which the RERR was received. 3. The UNodeSeqNum is zero (0) ORMANETcastAddress. This option will notify the resultmaximum number of subtracting Route.SeqNum from UNodeSeqNum is less than or equal to zero using signed 32-bit arithmetic. Each UNodeAddress that did not result in a change to Route.ValidTimeout SHOULD be removed from the RERR. Prior to generic post processing a node MAY remove any UNodeAddressN, UNodeSeqNumN pairs except UNodeAddress1 to decrease the element size. If at least one UNodeAddress remains and at least one route remains in the RERR it SHOULD be handled as described in Section 4.6.4 to continue notificationnodes of the broken link. Additional unreachable nodes effected bythat required the broken link. Otherwise,same unavailable link (routes with the RERR is dropped. 4.6 General DYMO Processing 4.6.1 DYMO Control Packet Processing A DYMO packet may consist of multiple DYMO elements. Each element is processed individuallysame Route.NextHopAddress and in sequence, from first to last. An incoming DYMO packet MUSTRoute.NextHopInterface) MAY be completely processed prioradded to any DYMO packet transmissions. The length of IP addresses (32-bits for IPv4 and 128-bits for IPv6) inside DYMO elements is dependent onthe IP packet header.RERR. For example, ifeach unreachable node the IP headerAddress is IPv6 then all DYMO elements contained in the payload use IPv6 addresses. Unless specific elementappended. The SeqNum if know should also be included. Appending additional routing information notifies each processing requires dropping the DYMO packet, itnode of additional routes that are no longer available. The RERR is retransmitted after processing, according to the methodthen processed as described in Section 4.6.5. 4.6.2 Generic Element Pre-processing Each element in4.5.4. Route Error Processing When a DYMO packet undergoes pre-processing before the element specific processing occurs. During pre-processing,node processes a RERR, it SHOULD set the TTL is decremented by one (1). 4.6.3 Processing Unsupported DYMO Element Types This section describesRoute.ValidTimeout to the processingcurrent time for unsupported DYMO element Types. The Type field identifies the handling by nodeseach Address that do not implement, support or understand a particular Element Type.meets all of the following conditions: 1. The most significant bit (M-bit) indicates whether an Unsupported-element Error (UERR) SHOULD be sent toRoute.NextHopAddress is the same as the NotifyAddress.RERR IPSourceAddress. 2. The next two bits (H-bits) identify howRoute.NextHopInterface is the element should be handled. 0 0 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Type | = |M| H | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Ifsame as the interface on which the RERR was received. 3. The Node.SeqNum is zero (0), unknown, OR the M-bitresult of subtracting Route.SeqNum from Node.SeqNum is set in a DYMO element being processed by a nodeless than or equal to zero using signed 16-bit arithmetic. Each Node.Address that doesdid not support this Element Typeresult in a UERRchange to Route.ValidTimeout SHOULD be sent to the NotifyAddress. This is accomplished by followingremoved from the instructions in Section 184.108.40.206. RegardlessRERR, since propagation of whether orthis information should not a UERR is sentresult in responseany benefit. Prior to this unsupported Element Type, thepost processing a node MUST also examine the H-bits to determine how this unsupported element is handled. The unsupported element Type MUST be handled as follows: o If H == 00 skip the elementMAY remove any unreachable node address and continue as ifits associated information to decrease the packet did not contain this element. omessage size. If H == 01 remove the unsupported element (using the Len field) fromthis node is the packetTarget and continue as ifthe packet did not include this element. oIPDestinationAddress is its own Address then it may stop processing. If H == 10 setat least one unreachable node address remains in the ignored bit (I-bit) skip this element and continue,RERR it SHOULD be handled as ifdescribed in Section 4.6.4 to continue notification of nodes effected by the packet did not contain this element. o If H == 11 dropbroken link. Otherwise, the packet without processing any other DYMO elements. 220.127.116.11 Generating an Unsupported-element Error When an unsupported element typeRERR is received with the M-bit set, the processing node SHOULD generate an Unsupported-element Error (UERR).dropped. 4.6. General DYMO Packet and Message Processing 4.6.1. Packet Processing The TargetAddress is set tolength of IP addresses (32-bits for IPv4 and 128-bits for IPv6) inside DYMO messages are dependent on the NotifyAddress. The IPDestinationAddress is set toIP packet header. For example, if the Route.NextHopAddress towardIP header uses IPv6 addresses then all messages and addresses contained in the NotifyAddress. The UElemTargetAddress is set topayload use IPv6 addresses. 4.6.2. Generic Message Pre-processing Each message undergoes pre-processing before the TargetAddress frommessage specific processing occurs. During pre-processing, the unsupported element. The UERRNodeAddressmsg-ttl is set todecremented by one (1) and the node address generating this UERR. The UElemTypemsg-hopcnt is incremented by one (1). 4.6.3. Processing Unknown Message and TLV Types We expect the Type fromnext version of the unsupported element. The TTL SHOULD be setgeneralized MANET packet and message format  to NET_DIAMETER, but MAY be set smaller. The Len is setinclude message semantic bits and tlv semantic bits to control the total numberbehavior of bytes in this UERR. The element is then processed as described in Sectionunknown types. 4.6.4. 4.6.4Generic ElementMessage Post-processing If the first element TTL is zero (0) the DYMO packet is dropped after processing of all elements. If the TTL of the first element is greater than zero the DYMO packet is re-transmitted after processing of all elements. If the TTLmsg-ttl of any elementmessage is zero (0) after processing it MUST be removed from the DYMO packet prior to transmission. 4.6.5dropped. 4.6.5. DYMO Control Packet Transmission DYMO packetPacket transmission and re-transmission isare controlled by the IPDestinationAddress. If the IPDestinationAddress is a unicast address, the packet IPDestinationAddress is replaced by the Route.NextHopAddress from a route table lookup for the TargetAddress.Target. If a route for the TargetAddressTarget is unknown or invalid the packet is dropped and a RERR SHOULD be generated. For all currently defined DYMO packets the IPTTL (IPMaxCount) SHOULD be set to 1 (IPTTL=1), since all DYMO packet communications are exchanged between direct neighbors. 4.7neighbors only. 4.7. Routing Prefix Any node canMAY advertise connectivity to a subset of other nodesnode addresses within its address space by using the prefix field in RE.a Prefix tlv . The nodes (other than the advertising node) within the advertised prefixPrefix SHOULD NOT participate in the MANET and MUST be reachable by forwarding packets to the node advertising connectivity. For example, 192.168.1.1 with a prefix of 16 indicates all nodes with the prefix 192.168.X.X are reachable through 192.168.1.1. The meaning of the prefixPrefix field is altered for routes to the gateway; Route.IsGateway is one (1). If the G-bit is set the prefixPrefix in association with the IP address indicates that all nodes outside the subnet are reachable via the gateway node. For example, a route to a gateway with IP address 192.168.1.1 and a prefix of 16 indicates that all nodes with an IP address NOT matching 192.168.X.X are reachable via this route. 4.8node. 4.8. Simple Internet Attachment and Gatewaying Simple Internet attachment consists of a network of MANET nodes connected to the Internet via a single gateway node. The gateway is responsible for responding to RREQs for TargetNodesTargets outside its configured MANET subnet, as well as delivering packets to destinations outside the MANET subnet.MANET. MANET nodes wishing to be reachable from nodes in the Internet MUST have IP addresses within the gateway's configured and advertised MANET subnet. Given a node with a globally routeable address or care-of address handled by the gateway, the gateway is responsible for routing and forwarding packets received from the Internet destined for nodes inside its MANET subnet. Since many nodes may commonly wish to communicate with the gateway, the gateway SHOULD indicate to nodes that it is a gateway by settingusing the gateway bit (G-bit)tlv in any RERM created or processed. The G-bit flaggateway tlv indicates to nodes in the MANET that the RBNodeAddressNode.Address is attached to the Internet and is capable of routing data packets to all nodes outside of the configured MANET subnet, describeddefined by the RBNodeAddressNode.Address and RBPrefixNode.Prefix fields. 4.94.9. Multiple Interfaces It is likely that DYMO will be used with multiple wireless interfaces; therefore, the particular interface over which packets arrive must be known whenever a packet is received. Whenever a new route is created, the interface through which the Route.DestAddressRoute.Address can be reached is also recorded intoin the route table entry. When multiple interfaces are available, a node transmitting a DYMOcastMANETcast packet SHOULD send the packet on all interfaces that have been configured for operation in the MANET. 4.10DYMO operation. 4.10. Packet Generation Limits To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT control messages per second. RREQ packets SHOULD be discarded before RREP or RERR packets. 5. Configuration Parameters Here are some default parameter values for DYMO: Parameter Name Suggested Value --------------------------- --------------- NET_DIAMETER 10 RATE_LIMIT 10 ROUTE_TIMEOUT 30005000 milliseconds ROUTE_DELETE_TIMEOUT 5*ROUTE_TIMEOUT RREQ_WAIT_TIME 1000 milliseconds RREQ_TRIES 3 For large networks or networks with frequent topology changes the default DYMO parameters should be adjusted using either experimentally determined values or dynamic adaptation. For example, in networks with infrequent topology changes ROUTE_TIMEOUT may be set to a much larger value. It is assumed that all nodes in the network share the same parameter settings. Different parameter values for ROUTE_TIMEOUT or ROUTE_DELETE_TIMEOUT in addition to arbitrary packet delays may result in frequent route breaks or routing loops. 6. IANA Considerations DYMO defines a Type field for each element within a packet sent to port TBD.several message-types and tlv-types. A new registry will be created for the values for this Type field,the various type fields, and the following values will be assigned: Typemsg-type Value -------------------------------- ----- Routing Element (RE) 1------- Route Request (DYMO-RREQ) 8 - TBD Route Reply (DYMO-RREP) 9 - TBD Route Error (RERR) 2 Unsupported-element Error (UERR) 3(DYMO-RERR) 10 - TBD address-tlv Value -------------------------------- ----- DYMO SeqNum (multivalue) 20 - TBD HopCnt (multivalue) 21 - TBD Prefix (multivalue) 0  Gateway (zero length) 22 - TBD Originator 23 - TBD Target 24 - TBD Future values of the Type will be allocated using standard actions as described in . For future Types with the M-bit set NotifyAddress MUST be included. Similarly for future Typesthat are unicast hop- by-hophop-by-hop (packets not sent to the DYMOcastAddress),MANETcastAddress), these Types MUST include the TargetAddressTarget.Address field. 7. Security Considerations Currently, DYMO does not specify any special security measures. Routing protocols, however, are prime targets for impersonation attacks. In networks where the node membership is not known, it is difficult to determine the occurrence of impersonation attacks, and security prevention techniques are difficult at best. However, when the network membership is known and there is a danger of such attacks, DYMO elementsmessages must be protected by the use of authentication techniques, such as those involving generation of unforgeable and cryptographically strong message digests or digital signatures. While DYMO does not place restrictions on the authentication mechanism used for this purpose, IPsec Authentication ElementMessage (AH) is an appropriate choice for cases where the nodes share an appropriate security association that enables the use of AH. In particular, RERM messages SHOULD be authenticated to avoid creation of spurious routes to a destination. Otherwise, an attacker could masquerade as that destination and maliciously deny service to the destination and/or maliciously inspect and consume traffic intended for delivery to the destination. RERR messages, while slightly less dangerous, SHOULD be authenticated in order to prevent malicious nodes from disrupting active routes between communicating nodes. If the mobile nodes in the ad hoc network have pre-established security associations, the purposes for which the security associations are created should include that of authorizing the processing of DYMO control packets. Given this understanding, the mobile nodes should be able to use the same authentication mechanisms based on their IP addresses as they would have used otherwise. 8. Acknowledgments DYMO is a descendant of the design of previous MANET reactive protocols, especially AODV  and DSR . Changes to previous MANET reactive protocols stem from research and implementation experiences. Thanks to Elizabeth Belding-Royer for her long time authorship of DYMO. Additional thanks to Luke Klein-Berndt, Pedro Ruiz, Fransisco Ros and Koojana Kuladinithi for reviewing of DYMO, as well as several specification suggestions. 9. References 9.19.1. Normative References  Narten, T. Nartenand H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.  C.Perkins, E.C., Belding-Royer, E., and S. Das, "Ad hoc On-demand Distance Vector (AODV) Routing", RFC 3561, July 2003. 9.2 Baker, R., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 9.2. Informative References  Perkins, C. Perkinsand E. Belding-Royer, "Ad hoc On-Demand Distance Vector (AODV) Routing", Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, pp. 90-100, February 1999.  Johnson, D. Johnsonand D. Maltz, "Dynamic Source Routing (DSR) in Ad hoc Networks", In Mobile Computing, Chapter 5, pp. 153-181, 1996.  Clausen, T., Dearlove, C., and J. Dean, "Generalized MANET Packet/Message Format", February 2006. Authors' Addresses Ian Chakeres Boeing Phantom Works The Boeing Company P.O. Box 3707 Mailcode 7L-49 Seattle, WA 98124-2207 USA Email: firstname.lastname@example.org Elizabeth Belding-Royer University of California Santa Barbara Dept. of Computer Science Santa Barbara, CA 93106-5110 USA Phone: +1-805-893-3411 Fax: +1-805-893-8553 Email: email@example.comCharlie Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1-650-625-2986 Fax: +1-650-625-2502 Email: firstname.lastname@example.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005).(2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.