draft-ietf-manet-dymo-02.txt   draft-ietf-manet-dymo-03.txt 
Mobile Ad hoc Networks Working I. Chakeres Mobile Ad hoc Networks Working I. Chakeres
Group E. Belding-Royer Group Boeing
Internet-Draft UC Santa Barbara Internet-Draft E. Belding-Royer
Expires: December 23, 2005 C. Perkins Expires: April 26, 2006 UC Santa Barbara
C. Perkins
Nokia Nokia
June 21, 2005 October 23, 2005
Dynamic MANET On-demand (DYMO) Routing Dynamic MANET On-demand (DYMO) Routing
draft-ietf-manet-dymo-02 draft-ietf-manet-dymo-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2005. This Internet-Draft will expire on April 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Dynamic MANET On-demand (DYMO) routing protocol is intended for The Dynamic MANET On-demand (DYMO) routing protocol is intended for
use by mobile nodes in wireless multihop networks. It offers use by mobile nodes in wireless multihop networks. It offers
adaptation to changing network topology and determines unicast routes adaptation to changing network topology and determines unicast routes
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.3.3 Appending Additional Routing Information to an 4.3.3 Appending Additional Routing Information to an
Existing Routing Element . . . . . . . . . . . . . . . 19 Existing Routing Element . . . . . . . . . . . . . . . 19
4.4 Route Discovery . . . . . . . . . . . . . . . . . . . . . 19 4.4 Route Discovery . . . . . . . . . . . . . . . . . . . . . 19
4.5 Route Maintenance . . . . . . . . . . . . . . . . . . . . 20 4.5 Route Maintenance . . . . . . . . . . . . . . . . . . . . 20
4.5.1 Active Link Monitoring . . . . . . . . . . . . . . . . 20 4.5.1 Active Link Monitoring . . . . . . . . . . . . . . . . 20
4.5.2 Updating Route Lifetimes . . . . . . . . . . . . . . . 21 4.5.2 Updating Route Lifetimes . . . . . . . . . . . . . . . 21
4.5.3 Route Error Generation . . . . . . . . . . . . . . . . 21 4.5.3 Route Error Generation . . . . . . . . . . . . . . . . 21
4.5.4 Route Error Processing . . . . . . . . . . . . . . . . 22 4.5.4 Route Error Processing . . . . . . . . . . . . . . . . 22
4.6 General DYMO Processing . . . . . . . . . . . . . . . . . 22 4.6 General DYMO Processing . . . . . . . . . . . . . . . . . 22
4.6.1 DYMO Control Packet Processing . . . . . . . . . . . . 22 4.6.1 DYMO Control Packet Processing . . . . . . . . . . . . 22
4.6.2 Generic Element Pre-processing . . . . . . . . . . . . 22 4.6.2 Generic Element Pre-processing . . . . . . . . . . . . 23
4.6.3 Processing Unsupported DYMO Element Types . . . . . . 23 4.6.3 Processing Unsupported DYMO Element Types . . . . . . 23
4.6.3.1 Generating an Unsupported-element Error . . . . . 23 4.6.3.1 Generating an Unsupported-element Error . . . . . 24
4.6.4 Generic Element Post-processing . . . . . . . . . . . 24 4.6.4 Generic Element Post-processing . . . . . . . . . . . 24
4.6.5 DYMO Control Packet Transmission . . . . . . . . . . . 24 4.6.5 DYMO Control Packet Transmission . . . . . . . . . . . 24
4.7 Routing Prefix . . . . . . . . . . . . . . . . . . . . . . 24 4.7 Routing Prefix . . . . . . . . . . . . . . . . . . . . . . 24
4.8 Internet Attachment . . . . . . . . . . . . . . . . . . . 25 4.8 Internet Attachment . . . . . . . . . . . . . . . . . . . 25
4.9 Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25 4.9 Multiple Interfaces . . . . . . . . . . . . . . . . . . . 25
4.10 Packet Generation Limits . . . . . . . . . . . . . . . . . 25 4.10 Packet Generation Limits . . . . . . . . . . . . . . . . . 25
5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 26 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 11, line 15 skipping to change at page 11, line 15
Element Data (Data) Element Data (Data)
Type-specific payload. Type-specific payload.
3.2.2 Routing Element (RE) 3.2.2 Routing Element (RE)
0 1 2 3 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 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|A| Res | | Type | Len | TTL |I|A|S| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. TargetAddress . . TargetAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetSeqNum | | TargetSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| THopCnt |Res| . | THopCnt |Res| .
+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+ .
. . . .
. Routing Block 1 (RBlock1) . . Routing Block 1 (RBlock1) .
. . . .
skipping to change at page 11, line 41 skipping to change at page 11, line 41
Figure 3 Figure 3
A-bit (A) A-bit (A)
1-bit selector indicating whether this RE requires a RREP by 1-bit selector indicating whether this RE requires a RREP by
the TargetAddress. If A=1 a RREP is required. The the TargetAddress. If A=1 a RREP is required. The
instructions for generating a RREP are described in instructions for generating a RREP are described in
Section 4.3.2. Section 4.3.2.
S-bit (S)
1-bit selector indicating whether this RE requires a unicast
message be sent to the previous hop address. This message MAY
used by the previous hop to ensure that the link traversed is
not unidirectional. The handling instructions for the S-bit is
explained in Section 4.3.2.
Element Target Address (TargetAddress) Element Target Address (TargetAddress)
The node that is the ultimate destination of the Routing The node that is the ultimate destination of the Routing
Element. Element.
Target Sequence Number (TargetSeqNum) Target Sequence Number (TargetSeqNum)
The sequence number of the ultimate destination of this Routing The sequence number of the ultimate destination of this Routing
Element. If the Sequence Number is unknown for this particular Element. If the Sequence Number is unknown for this particular
Route.DestAddress then TargetSeqNum is set to zero (0). Route.DestAddress then TargetSeqNum is set to zero (0).
Target Hop Count (THopCnt) Target Hop Count (THopCnt)
skipping to change at page 17, line 4 skipping to change at page 17, line 4
4.2 DYMO Routing Table Operations 4.2 DYMO Routing Table Operations
4.2.1 Creating or Updating a Route Table Entry from a Routing Block 4.2.1 Creating or Updating a Route Table Entry from a Routing Block
While processing a RE, as described in Section 4.3.2, a node checks While processing a RE, as described in Section 4.3.2, a node checks
its routing table for an entry to the RBNodeAddress using longest- its routing table for an entry to the RBNodeAddress using longest-
prefix matching. In the event that no matching entry is found, an prefix matching. In the event that no matching entry is found, an
entry is created. entry is created.
If a matching entry is found, the routing information about If a matching entry is found, the routing information about
RBNodeAddress contained in this RBlock is considered stale if: 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.
o the result of subtracting the Route.SeqNum from RBNodeSeqNum is If a matching entry is found, the routing information about
less than zero (0) using signed 32-bit arithmetic, OR RBNodeAddress contained in this RBlock is NOT stale if the result of
subtracting the Route.SeqNum from RBNodeSeqNum is equal to zero (0)
using signed 32-bit arithmetic but it SHOULD be disregarded if:
o the result of subtracting the Route.SeqNum from RBNodeSeqNum is o the Route.ValidTimeout has not passed and RBHopCnt is greater than
equal to zero (0) using signed 32-bit arithmetic AND the RBHopCnt or equal to Route.HopCnt, OR
is greater than Route.HopCnt.
If there exists a route AND the result of subtracting the o the Route.ValidTimeout has passed and RBHopCnt is greater than
Route.SeqNum from RBNodeSeqNum is equal to zero (0) using signed 32- Route.HopCnt plus one (1).
bit arithmetic AND the RBHopCnt is equal to the Route.HopCnt in this
RBlock the information is not stale, but the routing information
SHOULD be disregarded and no routing update should occur.
If the information in this RBlock is stale or disregarded and this If the information in this RBlock is stale or disregarded and this
RBlock is the first node in the RR this DYMO packet MUST be dropped. RBlock is the first RBlock in a RREQ this DYMO packet MUST be
For other RBlocks containing stale or disregarded routing dropped. For other RBlocks containing stale or disregarded routing
information, the RBlock is simply removed from this RE and the RELen information, the RBlock is simply removed from this RE and the RELen
adjusted. Removing stale and disregarded RBlocks ensures that unused adjusted. Removing stale and disregarded RBlocks ensures that unused
information is not propagated further. information is not propagated further.
If the route information for RBNodeAddress is not stale or If the route information for RBNodeAddress is not stale, disregarded
disregarded, then the following actions occur to the route table or a disregarded RREP, then the following actions occur to the route
entry for RBNodeAddress: table entry for RBNodeAddress:
1. the Route.HopCnt is set to the RBHopCnt, 1. the Route.HopCnt is set to the RBHopCnt,
2. the Route.IsGateway is set to the G-bit, 2. the Route.IsGateway is set to the G-bit,
3. the Route.NextHopAddress is set to the node that transmitted this 3. the Route.NextHopAddress is set to the node that transmitted this
DYMO packet (IPSourceAddress), DYMO packet (IPSourceAddress),
4. the Route.NextHopInterface is set to the interface that this DYMO 4. the Route.NextHopInterface is set to the interface that this DYMO
packet was received on, packet was received on,
skipping to change at page 19, line 28 skipping to change at page 19, line 28
additional routing information will reduce route discoveries to this additional routing information will reduce route discoveries to this
node. node.
If this node is not the TargetAddress, the current RE SHOULD be If this node is not the TargetAddress, the current RE SHOULD be
handled according to Section 4.6.4. handled according to Section 4.6.4.
If this node is the TargetAddress, the current packet and any If this node is the TargetAddress, the current packet and any
additional elements are processed, but this packet is not additional elements are processed, but this packet is not
retransmitted. retransmitted.
If the S-bit is set to one (1) in the RE, then a unicast message
SHOULD be sent or have been sent to the previous hop within
UNICAST_MESSAGE_SENT_TIMEOUT. Any unicast packet will serve this
purpose, but it MAY be an ICMP REPLY message. If a message is not
sent, then the previous hop may assume that the link is
unidirectional and may blacklist this node.
4.3.3 Appending Additional Routing Information to an Existing Routing 4.3.3 Appending Additional Routing Information to an Existing Routing
Element Element
Appending routing information will alleviate route discovery attempts Appending routing information will alleviate route discovery attempts
to this node from other nodes that process the resultant RE. Nodes to this node from other nodes that process the resultant RE. Nodes
SHOULD append a RBlock to RE processed. MAY append a RBlock to RE processed if the believes that this
additional routing information will alleviate future RREQ.
Prior to appending a RBlock to a RE, a node MUST increment its Prior to appending a RBlock to a RE, a node MUST increment its
OwnSeqNum as defined in Section 4.1.2. Then it appends its IP OwnSeqNum as defined in Section 4.1.2. Then it appends its IP
address, OwnSeqNum, Prefix and G-bit to the RE in a RBlock. The address, OwnSeqNum, Prefix and G-bit to the RE in a RBlock. The
RBHopCnt is set to zero (0). The RE Len is also adjusted according RBHopCnt is set to zero (0). The RE Len is also adjusted according
to the number of RBlocks in the RE. to the number of RBlocks in the RE.
4.4 Route Discovery 4.4 Route Discovery
A node generates a Route Request (RREQ) to discover a valid route to A node generates a Route Request (RREQ) to discover a valid route to
a particular destination (TargetAddress). A RREQ is a RE with the 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 A-bit is set to one (A=1) to indicate that the TargetNode must
respond with a RREP. If a sequence number is known for the respond with a RREP. If a sequence number is known for the
TargetAddress it is placed in the TargetSeqNum field. Otherwise, TargetAddress it is placed in the TargetSeqNum field. Otherwise,
TargetSeqNum is set to zero (0). Similarly, if a hop count is known TargetSeqNum is set to zero (0). A TargetSeqNum of zero MAY be set
for the TargetAddress it is placed in the THopCnt field. Otherwise, to indicate that only the destination may respond to this RREQ. If a
the THopCnt is set to zero ()). The IPDestinationAddress is set to hop count is known for the TargetAddress it is placed in the THopCnt
the DYMOcastAddress. Then the RE is then transmitted according to field. Otherwise, the THopCnt is set to zero (0). The
the procedure defined in Section 4.6.5. IPDestinationAddress is set to the DYMOcastAddress. Then the RE is
then transmitted according to the procedure defined in Section 4.6.5.
After issuing a RREQ, the originating node waits for a route to be After issuing a RREQ, the originating node waits for a route to be
created to the TargetNode. If a route is not received within created to the TargetNode. If a route is not received within
RREQ_WAIT_TIME milliseconds, this node MAY again try to discover a RREQ_WAIT_TIME milliseconds, this node MAY again try to discover a
route by issuing another RREQ. route by issuing another RREQ.
To reduce congestion in a network, repeated attempts at route To reduce congestion in a network, repeated attempts at route
discovery for a particular TargetNode SHOULD utilize a binary discovery for a particular TargetNode SHOULD utilize a binary
exponential backoff. The first time a node issues a RREQ, it waits exponential backoff. The first time a node issues a RREQ, it waits
RREQ_WAIT_TIME milliseconds for a route to the TargetNode. If a RREQ_WAIT_TIME milliseconds for a route to the TargetNode. If a
skipping to change at page 21, line 16 skipping to change at page 21, line 24
o Route timeout o Route timeout
Upon detecting a link break the detecting node MUST set the Upon detecting a link break the detecting node MUST set the
Route.ValidTimeout to the current time for all routes active routes Route.ValidTimeout to the current time for all routes active routes
utilizing the broken link. utilizing the broken link.
A RERR MUST be issued if a data packet is received and it cannot be 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 delivered to the next hop. RERR generation is described in
Section 4.5.3. A RERR SHOULD be issued after detecting a broken link Section 4.5.3. A RERR SHOULD be issued after detecting a broken link
of an active route to quickly notify nodes that a link break occurred of an active route to quickly notify nodes that a link break occurred
and a route or routes are no longer available. and a route or routes are no longer available. If a route has not
been used, a RERR SHOULD NOT be generated.
4.5.2 Updating Route Lifetimes 4.5.2 Updating Route Lifetimes
To avoid route timeouts for active routes, a node MUST update the To avoid route timeouts for active routes, a node MUST update the
Route.ValidTimeout to the IPSourceAddress to be the current time + Route.ValidTimeout to the IPSourceAddress to be the current time +
ROUTE_TIMEOUT upon receiving a data packet. ROUTE_TIMEOUT upon receiving a data packet.
To avoid route timeouts for active routes, a node SHOULD update the To avoid route timeouts for active routes, a node SHOULD update the
Route.ValidTimeout to the IPDestinationAddress to be the current time Route.ValidTimeout to the IPDestinationAddress to be the current time
+ ROUTE_TIMEOUT upon successfully transmitting a packet to the next + ROUTE_TIMEOUT upon successfully transmitting a packet to the next
skipping to change at page 29, line 10 skipping to change at page 29, line 10
associations are created should include that of authorizing the associations are created should include that of authorizing the
processing of DYMO control packets. Given this understanding, the processing of DYMO control packets. Given this understanding, the
mobile nodes should be able to use the same authentication mechanisms mobile nodes should be able to use the same authentication mechanisms
based on their IP addresses as they would have used otherwise. based on their IP addresses as they would have used otherwise.
8. Acknowledgments 8. Acknowledgments
DYMO is a descendant of the design of previous MANET reactive DYMO is a descendant of the design of previous MANET reactive
protocols, especially AODV [2] and DSR [4]. Changes to previous protocols, especially AODV [2] and DSR [4]. Changes to previous
MANET reactive protocols stem from research and implementation MANET reactive protocols stem from research and implementation
experiences. Thanks to Luke Klein-Berndt for reviewing of DYMO, as experiences. Thanks to Luke Klein-Berndt, Pedro Ruiz, Fransisco Ros
well as several specification suggestions. and Koojana Kuladinithi for reviewing of DYMO, as well as several
specification suggestions.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [1] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
[2] C. Perkins, E. Belding-Royer, and S. Das, "Ad hoc On-demand [2] C. Perkins, E. Belding-Royer, and S. Das, "Ad hoc On-demand
Distance Vector (AODV) Routing", RFC 3561, July 2003. Distance Vector (AODV) Routing", RFC 3561, July 2003.
skipping to change at page 30, line 28 skipping to change at page 30, line 28
Vector (AODV) Routing", Proceedings of the 2nd IEEE Workshop on Vector (AODV) Routing", Proceedings of the 2nd IEEE Workshop on
Mobile Computing Systems and Applications, New Orleans, LA, pp. Mobile Computing Systems and Applications, New Orleans, LA, pp.
90-100, February 1999. 90-100, February 1999.
[4] D. Johnson and D. Maltz, "Dynamic Source Routing (DSR) in Ad hoc [4] D. Johnson and D. Maltz, "Dynamic Source Routing (DSR) in Ad hoc
Networks", In Mobile Computing, Chapter 5, pp. 153-181, 1996. Networks", In Mobile Computing, Chapter 5, pp. 153-181, 1996.
Authors' Addresses Authors' Addresses
Ian Chakeres Ian Chakeres
University of California Santa Barbara Boeing Phantom Works
Dept. of Electrical and Computer Engineering The Boeing Company
Santa Barbara, CA 93106 P.O. Box 3707 Mailcode 7L-49
Seattle, WA 98124-2207
USA USA
Phone: +1-805-893-8981 Email: ian.chakeres@gmail.com
Fax: +1-805-893-8553
Email: idc@engineering.ucsb.edu
Elizabeth Belding-Royer Elizabeth Belding-Royer
University of California Santa Barbara University of California Santa Barbara
Dept. of Computer Science Dept. of Computer Science
Santa Barbara, CA 93106-5110 Santa Barbara, CA 93106-5110
USA USA
Phone: +1-805-893-3411 Phone: +1-805-893-3411
Fax: +1-805-893-8553 Fax: +1-805-893-8553
Email: ebelding@cs.ucsb.edu Email: ebelding@cs.ucsb.edu
 End of changes. 22 change blocks. 
40 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/