draft-ietf-manet-dymo-14.txt   draft-ietf-manet-dymo-15.txt 
Mobile Ad hoc Networks Working I. Chakeres Mobile Ad hoc Networks Working I. Chakeres
Group Motorola Group CenGen
Internet-Draft C. Perkins Internet-Draft C. Perkins
Intended status: Standards Track WiChorus Intended status: Standards Track WiChorus
Expires: December 27, 2008 June 25, 2008 Expires: May 20, 2009 November 16, 2008
Dynamic MANET On-demand (DYMO) Routing Dynamic MANET On-demand (DYMO) Routing
draft-ietf-manet-dymo-14 draft-ietf-manet-dymo-15
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 35 skipping to change at page 1, line 35
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 27, 2008. This Internet-Draft will expire on May 20, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 routers in wireless, multihop networks. DYMO use by mobile routers in wireless, multihop networks. DYMO
determines unicast routes among DYMO routers within the network in an determines unicast routes among DYMO routers within the network in an
on-demand fashion, offering improved convergence in dynamic on-demand fashion, offering improved convergence in dynamic
topologies. topologies.
Table of Contents Table of Contents
skipping to change at page 8, line 10 skipping to change at page 8, line 10
Route.NextHopAddress Route.NextHopAddress
The IP address of the adjacent DYMO router on the path toward the The IP address of the adjacent DYMO router on the path toward the
Route.Address. Route.Address.
Route.NextHopInterface Route.NextHopInterface
The interface used to send packets toward the Route.Address. The interface used to send packets toward the Route.Address.
Route.Forwarding Route.Forwarding
A flag indicating whether this Route can be used for forwarding A flag indicating whether this Route can be used for forwarding
data packets. data packets. This flag MAY be provided for management and
monitoring.
Route.Broken Route.Broken
A flag indicating whether this Route is broken. This flag is set A flag indicating whether this Route is broken. This flag is set
if the next-hop becomes unreachable or in response to processing a if the next-hop becomes unreachable or in response to processing a
RERR (see Section 5.5.4). RERR (see Section 5.5.4).
The following field is optional: The following field is optional:
Route.Dist Route.Dist
A metric indicating the distance traversed before reaching the A metric indicating the distance traversed before reaching the
skipping to change at page 10, line 4 skipping to change at page 10, line 4
If a packet contains only a single DYMO message and no packet TLVs, If a packet contains only a single DYMO message and no packet TLVs,
it need not include a packet-header [I-D.ietf-manet-packetbb]. it need not include a packet-header [I-D.ietf-manet-packetbb].
The aggregation of multiple messages into a packet is not specified The aggregation of multiple messages into a packet is not specified
in this document, but if aggregation does occur the IP.SourceAddress in this document, but if aggregation does occur the IP.SourceAddress
and IP.DestinationAddress of all contained messages MUST be the same. and IP.DestinationAddress of all contained messages MUST be the same.
Implementations MAY choose to temporarily delay transmission of Implementations MAY choose to temporarily delay transmission of
messages for the purpose of aggregation (into a single packet) or to messages for the purpose of aggregation (into a single packet) or to
improve performance by using jitter [I-D.ietf-manet-jitter]. improve performance by using jitter [RFC5148].
DYMO control packets SHOULD be given priority queue and channel DYMO control packets SHOULD be given priority queue and channel
access. access.
4.2.2. Routing Messages (RM) - RREQ & RREP 4.2.2. Routing Messages (RM) - RREQ & RREP
Routing Messages (RMs) are used to disseminate routing information. Routing Messages (RMs) are used to disseminate routing information.
There are two DYMO message types that are considered to be routing There are two DYMO message types that are considered to be routing
messages (RMs): RREQ and RREP. They contain very similar information messages (RMs): RREQ and RREP. They contain very similar information
and function, but have slightly different processing rules. The main and function, but have slightly different processing rules. The main
skipping to change at page 12, line 24 skipping to change at page 12, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TTL/HopLimit = 255 | | IP TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = MANET | | Destination Port = MANET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Header Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ-type |R|C|N|1|1|0|1|0| msg-size=23 | | RREQ-type |0|1|0|0|0|0|0|0| msg-size=23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit | | msg-hoplimit |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Message TLV Block Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 | | msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=2 | Rsv |0|0|0|1|0| HeadLength=3 | Head : |Number Addrs=2 |1|0|0|0|0| Rsv | HeadLength=3 | Head :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Head (cont) | Target.Tail | Orig.Tail | : Head (cont) | Target.Tail | Orig.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-block-size=6 |DYMOSeqNum-type|Rsv|0|1|0|0|0|0| | tlv-block-size=6 |DYMOSeqNum-type|0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=2 | Orig.SeqNum | | Index-start=1 | tlv-length=2 | Orig.SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
4.2.3. Route Error (RERR) 4.2.3. Route Error (RERR)
A RERR message is used to disseminate the information that a route is A RERR message is used to disseminate the information that a route is
not available for one or more particular IP addresses. not available for one or more particular IP addresses.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
| IP.DestinationAddress = LL-MANET-ROUTERS | | IP.DestinationAddress = LL-MANET-ROUTERS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.TTL/HopLimit = 255 | | IP.TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = MANET | | Destination Port = MANET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Header Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RERR-type |R|C|N|1|1|0|1|0| msg-size=15 | | RERR-type |0|1|0|0|0|0|0|0| msg-size=15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit | | msg-hoplimit |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Message TLV Block Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 | | msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=1 | Rsv |0|0|0|1|1| |Number Addrs=1 |0|0|0|0|0| Rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable.Address | | Unreachable.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-blk-size=0 | | TLV-blk-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
skipping to change at page 15, line 42 skipping to change at page 15, line 42
ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing ROUTE_DELETE_TIMEOUT before fully participating in the DYMO routing
protocol. If a DYMO control message is received during this waiting protocol. If a DYMO control message is received during this waiting
period, the DYMO router SHOULD process it normally but MUST NOT period, the DYMO router SHOULD process it normally but MUST NOT
transmit or retransmit any DYMO messages. If a data packet is transmit or retransmit any DYMO messages. If a data packet is
received for forwarding to another destination during this waiting received for forwarding to another destination during this waiting
period, the DYMO router MUST generate a RERR message indicating that period, the DYMO router MUST generate a RERR message indicating that
this route is not available and reset its waiting timeout. At the this route is not available and reset its waiting timeout. At the
end of the waiting period the DYMO router sets its OwnSeqNum to one end of the waiting period the DYMO router sets its OwnSeqNum to one
(1) and begins participating. (1) and begins participating.
The longest a node need wait is ROUTE_AGE_MAX_TIMEOUT. At the end of The longest a node need wait is ROUTE_SEQNUM_AGE_MAX_TIMEOUT. At the
the maximum waiting period a node SHOULD set its OwnSeqNum to one (1) end of the maximum waiting period a node SHOULD set its OwnSeqNum to
and begins participating. one (1) and begins participating.
5.2. DYMO Routing Table Operations 5.2. DYMO Routing Table Operations
5.2.1. Judging Routing Information's Usefulness 5.2.1. Judging Routing Information's Usefulness
Given a route table entry (Route.SeqNum, Route.Dist, and Given a route table entry (Route.SeqNum, Route.Dist, and
Route.Broken) and new incoming routing information for a particular Route.Broken) and new incoming routing information for a particular
node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/ node in a RM (Node.SeqNum, Node.Dist, and RM message type - RREQ/
RREP), the quality of the new routing information is evaluated to RREP), the quality of the new routing information is evaluated to
determine its usefulness. Incoming routing information is classified determine its usefulness. Incoming routing information is classified
skipping to change at page 17, line 41 skipping to change at page 17, line 41
5. the Route.NextHopInterface is set to the interface that this DYMO 5. the Route.NextHopInterface is set to the interface that this DYMO
packet was received on, packet was received on,
6. if known, the Route.Dist is set to the Node.Dist, 6. if known, the Route.Dist is set to the Node.Dist,
Fields without known values are not populated with any value. Fields without known values are not populated with any value.
Previous timers for this route table entry are removed. A timer for Previous timers for this route table entry are removed. A timer for
the minimum delete timeout (ROUTE_AGE_MIN) is set to the minimum delete timeout (ROUTE_AGE_MIN) is set to
ROUTE_AGE_MIN_TIMEOUT. A timer for the maximum delete timeout ROUTE_AGE_MIN_TIMEOUT. A timer for the maximum delete timeout
(ROUTE_AGE_MAX). ROUTE_AGE_MAX is set to Node.AddTLV.VALIDITY_TIME (ROUTE_SEQNUM_AGE_MAX). ROUTE_SEQNUM_AGE_MAX is set to
[I-D.ietf-manet-timetlv] if included; otherwise, ROUTE_AGE_MAX is set Node.AddTLV.VALIDITY_TIME [I-D.ietf-manet-timetlv] if included;
to ROUTE_AGE_MAX_TIMEOUT. The usage of these timers and others are otherwise, ROUTE_SEQNUM_AGE_MAX is set to
described in Section 5.2.3. ROUTE_SEQNUM_AGE_MAX_TIMEOUT. The usage of these timers and others
are described in Section 5.2.3.
At this point, a forwarding route should be created. Afterward, the At this point, a forwarding route should be created and the
route can be used to send any queued data packets and forward any Route.Forwarding flag set. Afterward, the route can be used to send
incoming data packets for Route.Address. This route also fulfills any queued data packets and forward any incoming data packets for
any outstanding route discovery attempts for Node.Address. Route.Address. This route also fulfills any outstanding route
discovery attempts for Node.Address.
5.2.3. Route Table Entry Timeouts 5.2.3. Route Table Entry Timeouts
5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN) 5.2.3.1. Minimum Delete Timeout (ROUTE_AGE_MIN)
When a DYMO router transmits a RM, other DYMO routers expect the When a DYMO router transmits a RM, other DYMO routers expect the
transmitting DYMO router to have a forwarding route to the RM transmitting DYMO router to have a forwarding route to the RM
originator. After updating a route table entry, it should be originator. After updating a route table entry, it should be
maintained for at least ROUTE_AGE_MIN. Failure to maintain the maintained for at least ROUTE_AGE_MIN. Failure to maintain the
information might result in lost messages/packets, or in the worst information might result in lost messages/packets, or in the worst
case scenario several duplicate messages. case scenario several duplicate messages.
After the ROUTE_AGE_MIN timeout a route can safely be deleted. After the ROUTE_AGE_MIN timeout a route can safely be deleted.
5.2.3.2. Maximum Delete Timeout (ROUTE_AGE_MAX) 5.2.3.2. Maximum Sequence Number Delete Timeout (ROUTE_SEQNUM_AGE_MAX)
Sequence number information is time sensitive, and MUST be deleted Sequence number information is time sensitive, and MUST be deleted
after a time in order to ensure loop-free routing. after a time in order to ensure loop-free routing.
After the ROUTE_AGE_MAX timeout a route MUST be deleted. All After the ROUTE_AGE_MAX timeout a route's sequence number information
information about the route is deleted upon ROUTE_AGE_MAX timeout. MUST be discarded.
If a forwarding route exists it is also removed.
5.2.3.3. Recently Used Timeout (ROUTE_USED) 5.2.3.3. Recently Used Timeout (ROUTE_USED)
When a route is used to forward data packets, this timer is set to When a route is used to forward data packets, this timer is set to
expire after ROUTE_USED_TIMEOUT. This operation is also discussed in expire after ROUTE_USED_TIMEOUT. This operation is also discussed in
Section 5.5.2. Section 5.5.2.
If a route has not been used recently, then a timer for ROUTE_DELETE If a route has not been used recently, then a timer for ROUTE_DELETE
is set to ROUTE_DELETE_TIMEOUT. is set to ROUTE_DELETE_TIMEOUT.
5.2.3.4. Delete Information Timeout (ROUTE_DELETE) 5.2.3.4. Delete Information Timeout (ROUTE_DELETE)
As time progresses the likelihood that old routing information is As time progresses the likelihood that old routing information is
useful decreases, especially if the network nodes are mobile. useful decreases, especially if the network nodes are mobile.
Therefore, old information should be deleted. Therefore, old information should be deleted.
After the ROUTE_DELETE timeout, the routing table entry should be After the ROUTE_DELETE timeout, the routing table entry should be
deleted. If a forwarding route exists, it should also be removed. deleted. If a forwarding route exists, it should be removed and the
Route.Forwarding flag unset.
5.3. Routing Messages 5.3. Routing Messages
5.3.1. RREQ Creation 5.3.1. RREQ Creation
Before a DYMO router creates a RREQ it SHOULD increment its OwnSeqNum Before a DYMO router creates a RREQ it SHOULD increment its OwnSeqNum
by one (1) according to the rules specified in Section 5.1.2. by one (1) according to the rules specified in Section 5.1.2.
Incrementing OwnSeqNum will ensure that all nodes with existing Incrementing OwnSeqNum will ensure that all nodes with existing
routing information will consider this new information superior to routing information will consider this new information superior to
existing routing table information. If the sequence number is not existing routing table information. If the sequence number is not
skipping to change at page 21, line 43 skipping to change at page 21, line 43
ThisNode also checks whether AddBlk.OrigNode.Address is an address ThisNode also checks whether AddBlk.OrigNode.Address is an address
handled by this DYMO router. If this node is the originating DYMO handled by this DYMO router. If this node is the originating DYMO
router, the RM is dropped. router, the RM is dropped.
ThisNode checks if the AddBlk.TargetNode.Address is a valid multihop- ThisNode checks if the AddBlk.TargetNode.Address is a valid multihop-
capable unicast IP address. If the address is not a valid unicast IP capable unicast IP address. If the address is not a valid unicast IP
address, the messages is discarded and further processing stopped. address, the messages is discarded and further processing stopped.
Next, ThisNode checks whether its routing table has an entry to the Next, ThisNode checks whether its routing table has an entry to the
AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If AddBlk.OrigNode.Address using longest-prefix matching [RFC1812]. If
a route does not exist, then the new routing information is a route with a valid Route.SeqNum does not exist, then the new
considered fresh and a new route table entry is created and updated routing information is considered fresh and a new route table entry
as described in Section 5.2.2. If a route table entry does exists, is created and updated as described in Section 5.2.2. If a route
the incoming routing information is compared with the route table table entry does exists and it has a valid Route.SeqNum, the incoming
entry following the procedure described in Section 5.2.1. If the routing information is compared with the route table entry following
incoming routing information is considered superior, the route table the procedure described in Section 5.2.1. If the incoming routing
entry is updated as described in Section 5.2.2. information is considered superior, the route table entry is updated
as described in Section 5.2.2.
After processing the OrigNode's routing information, then each After processing the OrigNode's routing information, then each
address that is not the TargetNode should be considered for creating address that is not the TargetNode should be considered for creating
and updating routes. Creating and updating routes to other nodes can and updating routes. Creating and updating routes to other nodes can
eliminate RREQ for those IP destinations, in the event that data eliminate RREQ for those IP destinations, in the event that data
needs to be forwarded to the IP destination(s) now or in the near needs to be forwarded to the IP destination(s) now or in the near
future. future.
For each of the additional addresses considered, ThisNode first For each of the additional addresses considered, ThisNode first
checks the that the address is a multihop-capable unicast IP address. checks the that the address is a multihop-capable unicast IP address.
If the address is not a unicast IP address, the address and all If the address is not a unicast IP address, the address and all
related information MUST be removed. related information MUST be removed.
If the routing table does not have a matching route for this If the routing table does not have a matching route with a valid
additional address using longest-prefix matching, then a route is Route.SeqNum for this additional address using longest-prefix
created and updated as described in Section 5.2.2. If a route table matching exists, then a route is created and updated as described in
entry exists, the incoming routing information is compared with the Section 5.2.2. If a route table entry exists with a valid
Route.SeqNum, the incoming routing information is compared with the
route table entry following the procedure described in Section 5.2.1. route table entry following the procedure described in Section 5.2.1.
If the incoming routing information is considered superior, the route If the incoming routing information is considered superior, the route
table entry is updated as described in Section 5.2.2. table entry is updated as described in Section 5.2.2.
If the routing information for an AdditionalNode.Address is not If the routing information for an AdditionalNode.Address is not
considered superior, then it is removed from the RM. Removing this considered superior, then it is removed from the RM. Removing this
information ensures that the information is not propagated. information ensures that the information is not propagated.
At this point, if the routing information for the OrigNode was not At this point, if the routing information for the OrigNode was not
superior then this RM SHOULD be discarded and no further processing superior then this RM SHOULD be discarded and no further processing
skipping to change at page 26, line 21 skipping to change at page 26, line 21
o Link layer feedback o Link layer feedback
o Neighborhood discovery [I-D.ietf-manet-nhdp] o Neighborhood discovery [I-D.ietf-manet-nhdp]
o Route timeout o Route timeout
o Other monitoring mechanisms or heuristics o Other monitoring mechanisms or heuristics
Upon determining that a link is broken or the next-hop is Upon determining that a link is broken or the next-hop is
unreachable, ThisNode MUST remove the affected forwarding routes unreachable, ThisNode MUST remove the affected forwarding routes
(those with an unreachable next-hop). ThisNode also flags the (those with an unreachable next-hop) and unset the Route.Forwarding
associated routes in DYMO's routing table as Broken. For each broken flag. ThisNode also flags the associated routes in DYMO's routing
route a timer for ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT. table as Broken. For each broken route a timer for ROUTE_DELETE is
set to ROUTE_DELETE_TIMEOUT.
5.5.2. Updating Route Lifetimes During Packet Forwarding 5.5.2. Updating Route Lifetimes During Packet Forwarding
To avoid removing the forwarding route to reach the IP.SourceAddress, To avoid removing the forwarding route to reach the IP.SourceAddress,
ThisNode SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for ThisNode SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for
the route to the IP.SourceAddress upon receiving a data packet. If a the route to the IP.SourceAddress upon receiving a data packet. If a
timer for ROUTE_DELETE is set, it is removed. timer for ROUTE_DELETE is set, it is removed.
To avoid removing the forwarding route to the IP.DestinationAddress To avoid removing the forwarding route to the IP.DestinationAddress
that is being used, ThisNode SHOULD set a timeout (ROUTE_USED) to that is being used, ThisNode SHOULD set a timeout (ROUTE_USED) to
skipping to change at page 27, line 38 skipping to change at page 27, line 38
5.5.4. RERR Processing 5.5.4. RERR Processing
First, ThisNode decides whether to process this message. ThisNode First, ThisNode decides whether to process this message. ThisNode
MAY selectively process messages based upon information in the MAY selectively process messages based upon information in the
message. ThisNode MAY choose to only process messages from adjacent message. ThisNode MAY choose to only process messages from adjacent
DYMO routers. If ThisNode chooses not to process this message, the DYMO routers. If ThisNode chooses not to process this message, the
message is discarded and further processing stopped. message is discarded and further processing stopped.
When a DYMO router processes a RERR, it processes each When a DYMO router processes a RERR, it processes each
UnreachableNode's information. The processing DYMO router removes UnreachableNode's information. The processing DYMO router removes
the forwarding route, sets the broken flag, and a timer for the forwarding route, unsets the Route.Forwarding flag, sets the
ROUTE_DELETE is set to ROUTE_DELETE_TIMEOUT for each Route.Broken flag, and a timer for ROUTE_DELETE is set to
UnreachableNode.Address found using longest prefix matching that meet ROUTE_DELETE_TIMEOUT for each UnreachableNode.Address found using
all of the following conditions: longest prefix matching that meet all of the following conditions:
1. The UnreachableNode.Address is a multihop-capable unicast IP 1. The UnreachableNode.Address is a multihop-capable unicast IP
address. address.
2. The Route.NextHopAddress is the same as the RERR 2. The Route.NextHopAddress is the same as the RERR
IP.SourceAddress. IP.SourceAddress.
3. The Route.NextHopInterface is the same as the interface on which 3. The Route.NextHopInterface is the same as the interface on which
the RERR was received. the RERR was received.
skipping to change at page 29, line 44 skipping to change at page 29, line 44
| | DYMO Router | | | | DYMO Router | |
| | A.B.C.2 | | | | A.B.C.2 | |
| +--------------+ | | +--------------+ |
| +--------------+ | | +--------------+ |
| | DYMO Router | | | | DYMO Router | |
| | A.B.C.3 | | | | A.B.C.3 | |
\ +--------------+ / \ +--------------+ /
\ / \ /
\---------------------------/ \---------------------------/
Figure 7: Simple Internet Attachment Example Figure 3: Simple Internet Attachment Example
DYMO routers wishing to be reachable from nodes in the Internet MUST DYMO routers wishing to be reachable from nodes in the Internet MUST
have IP addresses within the IDR's routable and topologically correct have IP addresses within the IDR's routable and topologically correct
prefix. Given a node with a routeable address or care-of address prefix. Given a node with a routeable address or care-of address
handled by the IDR, the IDR is responsible for routing and forwarding handled by the IDR, the IDR is responsible for routing and forwarding
packets received from the Internet destined for nodes inside its packets received from the Internet destined for nodes inside its
MANET. MANET.
When DYMO router within the MANET want to send packets to a node on When DYMO router within the MANET want to send packets to a node on
the Internet, they simply issue RREQ for those IP Destination the Internet, they simply issue RREQ for those IP Destination
skipping to change at page 31, line 15 skipping to change at page 31, line 15
6. Configuration Parameters and Other Administrative Options 6. Configuration Parameters and Other Administrative Options
Suggested Parameter Values Suggested Parameter Values
+------------------------------+-------------------+ +------------------------------+-------------------+
| Name | Value | | Name | Value |
+------------------------------+-------------------+ +------------------------------+-------------------+
| MSG_HOPLIMIT | 10 hops | | MSG_HOPLIMIT | 10 hops |
| ROUTE_TIMEOUT | 5 seconds | | ROUTE_TIMEOUT | 5 seconds |
| ROUTE_AGE_MIN_TIMEOUT | 1 second | | ROUTE_AGE_MIN_TIMEOUT | 1 second |
| ROUTE_AGE_MAX_TIMEOUT | 60 seconds | | ROUTE_SEQNUM_AGE_MAX_TIMEOUT | 60 seconds |
| ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT | | ROUTE_USED_TIMEOUT | ROUTE_TIMEOUT |
| ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT | | ROUTE_DELETE_TIMEOUT | 2 * ROUTE_TIMEOUT |
| ROUTE_RREQ_WAIT_TIME | 2 seconds | | ROUTE_RREQ_WAIT_TIME | 2 seconds |
| RREQ_TRIES | 3 tries | | RREQ_TRIES | 3 tries |
| UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second |
+------------------------------+-------------------+ +------------------------------+-------------------+
Table 2 Table 2
These suggested values work well for small and medium well connected These suggested values work well for small and medium well connected
skipping to change at page 34, line 9 skipping to change at page 34, line 9
| | | | defined in | | | | | defined in |
| | | | [I-D.ietf-manet-timetlv]. | | | | | [I-D.ietf-manet-timetlv]. |
+---------------+--------------+--------+---------------------------+ +---------------+--------------+--------+---------------------------+
Table 6 Table 6
8. Security Considerations 8. Security Considerations
This document does not mandate any specific security measures. This document does not mandate any specific security measures.
Instead, this section describes various security considerations and Instead, this section describes various security considerations and
potential avenues to secure DYMO routing messages. potential avenues to secure DYMO routing.
In situations where confidentiality of DYMO messages is important, The most important security mechanisms for DYMO routing are
cryptographic techniques SHOULD be applied. integrity/authentication and confidentiality.
Securing routing information integrity will likely require DYMO In situations where routing information or router identity are
routers to authenticate DYMO messages upon reception. IPsec could be suspect, integrity and authentication techniques SHOULD be applied to
used for this single-hop packet protection. DYMO messages. In these situations, routing information that is
distributed over multiple hops SHOULD also verify the integrity and
identity of information based on originator of the routing
information.
Also, since routing information is distributed over multiple hops, A digital signature could be used to identify the source of DYMO
DYMO routers will also likely need to authenticate the source of the messages and information, along with its authenticity. A nonce or
routing information. A digital signature could be used help identify timestamp SHOULD also be used to protect against replay attacks.
the source of a message and its authenticity, along with a nonce or S/MIME and OpenPGP are two authentication/integrity protocols that
timestamp to protect against replay attacks. S/MIME and OpenPGP are could be adapted for this purpose.
two possible authentication protocols.
In certain situations, like sending a RREP, a DYMO router may also In situations where confidentiality of DYMO messages is important,
need to provide proof that it had received valid routing information cryptographic techniques SHOULD be applied.
to reach the destination, at one point of time in the past. In these
situations, the original routing information along with its security In certain situations, like sending a RREP or RERR, a DYMO router
credentials may need to be included. could include proof that it has previously received valid routing
information to reach the destination, at one point of time in the
past. In situations where routers are suspected of transmitting
maliciously erroneous information, the original routing information
along with its security credentials SHOULD be included.
Note that if multicast is used, any confidentiality and integrity Note that if multicast is used, any confidentiality and integrity
algorithms used must permit multiple receivers to process the algorithms used must permit multiple receivers to process the
message. message.
9. Acknowledgments 9. 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 [RFC3561] and DSR [RFC4728]. Changes to protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to
previous MANET reactive protocols stem from research and previous MANET reactive protocols stem from research and
skipping to change at page 35, line 15 skipping to change at page 35, line 18
10.1. Normative References 10.1. Normative References
[I-D.ietf-manet-iana] [I-D.ietf-manet-iana]
Chakeres, I., "IANA Allocations for MANET Protocols", Chakeres, I., "IANA Allocations for MANET Protocols",
draft-ietf-manet-iana-07 (work in progress), draft-ietf-manet-iana-07 (work in progress),
November 2007. November 2007.
[I-D.ietf-manet-packetbb] [I-D.ietf-manet-packetbb]
Clausen, T., Dearlove, C., Dean, J., and C. Adjih, Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", "Generalized MANET Packet/Message Format",
draft-ietf-manet-packetbb-12 (work in progress), draft-ietf-manet-packetbb-16 (work in progress),
March 2008. September 2008.
[I-D.ietf-manet-timetlv] [I-D.ietf-manet-timetlv]
Clausen, T. and C. Dearlove, "Representing multi-value Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", draft-ietf-manet-timetlv-04 (work in time in MANETs", draft-ietf-manet-timetlv-08 (work in
progress), November 2007. progress), September 2008.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-manet-jitter]
Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in Mobile Ad Hoc Networks (MANETs)",
draft-ietf-manet-jitter-04 (work in progress),
December 2007.
[I-D.ietf-manet-nhdp] [I-D.ietf-manet-nhdp]
Clausen, T., Dearlove, C., and J. Dean, "MANET Clausen, T., Dearlove, C., and J. Dean, "MANET
Neighborhood Discovery Protocol (NHDP)", Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-06 (work in progress), March 2008. draft-ietf-manet-nhdp-07 (work in progress), July 2008.
[Perkins99] [Perkins99]
Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand
Distance Vector (AODV) Routing", Proceedings of the 2nd Distance Vector (AODV) Routing", Proceedings of the 2nd
IEEE Workshop on Mobile Computing Systems and IEEE Workshop on Mobile Computing Systems and
Applications, New Orleans, LA, pp. 90-100, Applications, New Orleans, LA, pp. 90-100, February 1999.
February 1999.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003. July 2003.
[RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
Routing Protocol (DSR) for Mobile Ad Hoc Networks for Routing Protocol (DSR) for Mobile Ad Hoc Networks for
IPv4", RFC 4728, February 2007. IPv4", RFC 4728, February 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008.
Authors' Addresses Authors' Addresses
Ian D Chakeres Ian D Chakeres
Motorola CenGen
Bangalore 9250 Bendix Road North
India Columbia, Maryland 21045
USA
Email: ian.chakeres@gmail.com Email: ian.chakeres@gmail.com
URI: http://www.ianchak.com/ URI: http://www.ianchak.com/
Charles E. Perkins Charles E. Perkins
WiChorus Inc. WiChorus Inc.
3590 North First Street, Suite 300 3590 North First Street, Suite 300
San Jose, CA 95134 San Jose, CA 95134
USA USA
skipping to change at page 37, line 44 skipping to change at line 1632
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 36 change blocks. 
84 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/