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/