Network Working Group K. Kim, Ed.
Internet-Draft Ajou University
Expires: April 15, 2006 G. Montenegro
Microsoft Corporation
S. Daniel Park, Ed.
SAMSUNG Electronics
I. Chakeres
UC Santa Barbara
S. Yoo
Ajou University
Oct 16, 2005
Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing
draft-montenegro-6lowpan-dymo-low-routing-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies how to use the Dynamic MANET On-demand
Routing Protocol over IEEE802.15.4 networks.
Kim, et al. Expires April 15, 2006 [Page 1]
Internet-Draft DYMO-low October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Notation . .. . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Simplifications for DYMO over IEEE 802.15.4. . . . . . . . . 4
2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Route Table Entry . . . . . . . . . . . . . . . . . . . . 6
3.2 DYMO-low Message Elements . . . . . . . . . . . . . . . . 7
3.2.1 Generic DYMO-low Element Structure . . . . . . . . . . 7
3.2.2 Routing Element (RE) . . . . . . . . . . . . . . . . . 8
3.2.3 Route Error (RERR) . . . . . . . . . . . . . . . . . . 10
4. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 11
4.1 DYMO-low Routing Table Operations . . . . . . . . . . . . 11
4.1.1 Creating or Updating a Route Table Entry from a
Routing Block . . . . . . . . . . . . . . . . . . . . 11
4.1.2 Route Table Entry Timeouts . . . . . . . . . . . . . . 11
4.2 Routing Element . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Routing Element Creation . . . . . . . . . . . . . . . 12
4.2.2 Routing Element Processing . . . . . . . . . . . . . . 12
4.3 Route Discovery . . . . . . . . . . . . . . . . . . . . . 12
4.4 Route Maintenance . . . . . . . . . . . . . . . . . . . . 13
4.4.1 Monitoring of Active Links . . . . . . . . . . . . . . 13
4.4.2 Updating Route Lifetimes . . . . . . . . . . . . . . . 14
4.4.3 Route Error Generation . . . . . . . . . . . . . . . . 14
4.5 General DYMO-low Processing . . . . . . . . . . . . . . . 14
4.5.1 DYMO-low Control Packet Processing . . . . . . . . . . 14
4.5.2 Generic Element Pre-processing . . . . . . . . . . . . 14
4.5.3 Generic Element Post-processing . . . . . . . . . . . 14
4.5.4 DYMO-low Control Packet Transmission . . . . . . . . . 15
4.6 Packet Generation Limits . . . . . . . . . . . . . . . . . 15
4.7 Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 15
4.7.1 Sequence Number Rollover .. . . . . . . . . . . . . . 15
5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Kim, et al. Expires April 15, 2006 [Page 2]
Internet-Draft DYMO-low October 2005
1. Introduction
The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal
area networks. The "IPv6 over IEEE 802.15.4" document [I-D.ietf-
6lowpan-format] defines basic functionality required to carry IPv6
packets over IEEE 802.15.4 networks (including an adaptation layer,
header compression, etc). Likewise, as mesh topologies are expected
to be common in LoWPAN networks, the functionality required for
packet delivery in IEEE 802.15.4 meshes is defined. However, neither
the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4"
specification provide any information as to how such a mesh topology
could be obtained and maintained.
This document specifies how to use the Dynamic MANET On-demand
Routing Protocol (DYMO) [I-D.ietf-manet-dymo] over IEEE 802.15.4
networks to provide mesh routing. To distinguish this instantiation
of the protocol from DYMO over IPv4 and DYMO over IPv6, the label
"DYMO-low" is used in this document. Given the very stringent
limitations of the target devices, this document specifies
simplifications that are recommended to the base DYMO specification.
1.1 Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Overview
The addresses used in DYMO-low control messages are either 16 bit
link layer short address or IEEE 64-bit extended addresses [EUI64].
Additionally, it should be noted that as used in this specification,
DYMO-low is not layered on top of IP, but underneath it. It is an
underlay. As such, it creates a mesh network topology underneath
and unbeknownst to IP. IP sees a PAN as a single link. This is
similar to how other technologies regularly create complex
structures underneath IP (e.g., ethernet spanning tree bridges,
token ring source routing, ATM, etc). One can envision a sub-IP mesh
creating the illusion that all the devices on that PAN are on the
same IPv6 link (sharing the same IPv6 prefix). At the same time,
normal usage of DYMO (above IP) could tie together several such
"links" (potentially using different technologies for each) into
a larger mesh.
Kim, et al. Expires April 15, 2006 [Page 3]
Internet-Draft DYMO-low October 2005
DYMO over IPv4 makes use of broadcast in its route discovery. It
does so in order to propagate the Route Request control packets
(RREQs). In this specification, such broadcast packets are obtained
by setting the PAN id to the broadcast PAN (0xffff) and by setting
the link layer destination address to the broadcast short address
(0xffff)
DYMO-low control packets use the encapsulation defined in
[I-D.ietf-6lowpan-format]. All DYMO-low control packets shall use
the prot_type value TBD (suggested value of 5). This prot_type is
used to send DYMO-low messages in a manner similar to how DYMO uses
a properly assigned UDP port.
2.1 Simplifications for DYMO over IEEE 802.15.4
This section specifies simplifications and distinctive features of
DYMO-low compared to the base DYMO.
DYMO allows for minimalist implementations by specifying non-
essential functionality as optional [I-D.ietf-manet-dymo]. In
keeping with DYMO, DYMO-low implements the routing element(RE) which
provides both the RREQ (route request) and the RREP (route reply).
Furthermore, the RERR (route error) element is implemented while
UERR (unsupported element error) element is obviated for simplicity.
DYMO-low has the following characteristics:
o DYMOcast is mapped as broadcast. Hence, RREQ messages use an IEEE
802.15.4 broadcast message to reach all the next hop neighbors.
o Only the final destination responds to a RREQ by replying with a
RREP.
o Cumulative route cost is employed for selecting best route to the
destination. In the simplest case, only hop count could be used to
determine best route. However, it is suggested to use other
criteria involving the link quality by utilizing the LQI (link
quality indicator) of IEEE 802.15.4[ieee802.15.4].
o Hello messages are not used. Instead, the IEEE 802.15.4
acknowledgement mechanism is used to determine if a neighbor is no
longer responsive. This information is obtained when transmitting
a packet with acknowledgement option turned on.
o Due to space limitations, nodes SHOULD NOT append or transmit any
accumulated path information. That is, only one routing block
(RBlock) could be inserted into a single routing element(RE).
Kim, et al. Expires April 15, 2006 [Page 4]
Internet-Draft DYMO-low October 2005
o Due to space limitations, nodes SHOULD append only one unreachable
destination in RERR.
o Even though there exists space limitations, multiple routing
elements are allowed in a control packet for saving power
consumption. If there are multiple routing elements to send to the
same node, it is more energy-efficient to send them in a packet
rather than sending them individually.
o DYMO imposes a limit on the number of control messages sent
per second by a node. This limit (RATE_LIMIT) is reduced by
DYMO-low from the default value of 10 to 2.
o Sequence numbers are used for loop freedom. The size of the
sequence number field is reduced from 32 bits to 8 bits for
simplification.
o The transmission method for RERR elements in DYMO is DYMOcast.
However, considering the energy-constrained nature of 6lowpan,
some efficient mechanisms other than DYMOcast are necessitated
in DYMO-low (TBD).
o An error code field (ErrCode) is inserted into the RERR format to
indicate a particular type of route error in 6lowpan such as low
battery level.
2.2 Terminology
Link Layer Destination Address (LinkLayerDestinationAddress)
The 16 bit short or EUI-64 link layer address of the
destination in the MAC layer. It is also called as the next-hop
destination during hop-by-hop forwarding of packets.
Link Layer Source Address (LinkLayerSourceAddress)
The 16 bit short or EUI-64 link layer address of the source
in the MAC layer. It is also called as the previous-hop source
address during hop-by-hop forwarding of packets.
DYMOcast
DYMOcast in 6lowpan implies the broadcast in IEEE 802.15.4
MAC layer. This can be done by setting the link layer
destination field to 0xffff.
Kim, et al. Expires April 15, 2006 [Page 5]
Internet-Draft DYMO-low October 2005
Valid Route
A known route where the Route.ValidTimeout is greater than the
current time.
3. Data Structures
3.1 Route Table Entry
The route table entry is a conceptual data structure.
Implementations may use any internal representation that conforms to
the semantics of a route as specified in this document.
o Route.DestAddress
o Route.DeleteTimeout
o Route.RouteCost
o Route.NextHopAddress
o Route.ValidTimeout
These fields are defined as follows:
Route Destination Address (Route.DestAddress)
The 16 bit short or EUI-64 link layer address of the final
destination of a route.
Route Delete Timeout (Route.DeleteTimeout)
If the current time is after Route.DeleteTimeout the
corresponding routing table entry MUST be deleted.
Route Cost (Route.RouteCost)
Cumulative cost metric used for allowing a node to select an
optimum route to the final destination.
Route Next Hop Address (Route.NextHopAddress)
The 16 bit short or EUI-64 link layer address of the next-hop
node on the path toward the final destination.
Kim, et al. Expires April 15, 2006 [Page 6]
Internet-Draft DYMO-low October 2005
Route.ValidTimeout
The time at which a route table entry is scheduled to be
invalidated. The routing table entry is no longer considered
valid if the current time is after Route.ValidTimeout.
3.2 DYMO-low Message Elements
3.2.1 Generic DYMO-low Element Structure
All DYMO-low message elements MUST conform to the fixed data structure
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | TTL |T| Res | TSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. TargetAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Element Type (Type)
The following is the list of the currently available element
types.
Type Value
-------------------------------- -----
Routing Element (RE) 1
Route Error (RERR) 2
T-bit (T)
1 for the 16-bit address of the target.
0 for the EUI-64 address of the target.
Reserved (Reserved, Reservd, Res, R)
Reserved bits. These bits are set to zero (0) during element
creation and ignored during processing.
Kim, et al. Expires April 15, 2006 [Page 7]
Internet-Draft DYMO-low October 2005
Element Time to Live (TTL)
8-bit field that identifies the maximum number of times the
element is to be retransmitted. When TTL reaches zero (0) the
element is dropped.
Target Sequence Number (TSeqNum)
The sequence number of the ultimate destination of this Routing
Element. If the Sequence Number is unknown for this particular
Route.DestAddress then TSeqNum is set to zero (0).
Element Target Address (TargetAddress)
The node that is the ultimate destination of the element. This
field is only required if the LinkLayerDestinationAddress is not
the DYMOcastAddress. During hop-by-hop transmission of a
DYMO-low packet the LinkLayerDestinationAddress is filled with
the Route.NextHopAddress of the route table entry associated with
the TargetAddress.
3.2.2 Routing Element (RE)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | TTL |T|A| Res | TSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. TargetAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRouteCost | .
+-+-+-+-+-+-+-+-+ .
. Routing Block (RBlock) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
A-bit (A)
1-bit selector indicating whether this RE requires a RREP by
the TargetAddress. If A=1 a RREP is required. The
instructions for generating a RREP are described in
Section 4.3.
Kim, et al. Expires April 15, 2006 [Page 8]
Internet-Draft DYMO-low October 2005
Element Target Address (TargetAddress)
The node that is the ultimate destination of the Routing
Element.
Target Route Cost (TRouteCost)
8-bit field that identifies the routing cost across the number
of intermediate nodes through which a packet traversed on the
route to this particular TargetAddress the last time a route
was available. The TRouteCost is the Route.RouteCost of the
TargetAddress, stored in the routing table of the RREQ
originator. If the route cost information is not available
at the originating node then the TRouteCost is set to zero (0).
Routing Block (RBlock)
Data structure that describes routing information related to the
source node of which link layer address is RBNodeAddress.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|B| RBRouteCost | RBSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. RBNodeAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
G-bit (G)
1-bit selector to indicate whether the RBNodeAddress is a
gateway. If G=1 RBNodeAddress is a gateway. The usage of
this bit is TBD.
B-bit (B)
1 for 16-bit link layer address of the RBNode
0 for EUI-64 link layer address of the RBNode
Kim, et al. Expires April 15, 2006 [Page 9]
Internet-Draft DYMO-low October 2005
Routing Block Node Sequence Number (RBSeqNum)
The sequence number of the node associated with this RBlock.
Routing Block Node Address (RBNodeAddress)
The 16-bit short or EUI-64 address of the node associated
with RBlock.
3.2.3 Route Error (RERR)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | TTL |T| Res | TSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ErrCode | TargetAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Unreachable Target Node Address (TargetAddress)
The 16-bit short or EUI-64 link layer address of the target
node that has become unreachable.
Error Code (ErrorCode)
Numeric value for describing errors
0x00 = No available route
0x01 = Low Battery
0x02 - 0xff = Reserved (TBD)
Kim, et al. Expires April 15, 2006 [Page 10]
Internet-Draft DYMO-low October 2005
4. Detailed Operation
4.1 DYMO-low Routing Table Operations
4.1.1 Creating or Updating a Route Table Entry from a Routing Block
While processing a RE, as described in Section 4.2.2, a node checks
its routing table for an entry to the RBNodeAddress. In the event
that no matching entry is found, an entry is created.
If a matching entry is found, the routing information about
RBNodeAddress contained in this RBlock is considered stale if the
RBRouteCost is greater than Route.RouteCost. If there exists a route
AND the RBRouteCost is equal to the Route.RouteCost 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 this
DYMO-low packet MUST be dropped. If the route information for
RBNodeAddress is not stale or disregarded, then the following
actions occur to the route table entry for RBNodeAddress:
1. the Route.RouteCost is set to the RBRouteCost,
2. the Route.NextHopAddress is set to the node that transmitted this
DYMO-low packet (LinkLayerSourceAddress),
3. and the Route.ValidTimeout is set to the current time +
ROUTE_TIMEOUT.
If a valid route exists to RBNodeAddress, the route can be used to
send any queued data packets and to fulfill any outstanding route
requests.
4.1.2 Route Table Entry Timeouts
If the current time is later than a routing entry's
Route.ValidTimeout, the route is stale and it is not to be used to
route packets. The information in invalid entries is still used for
generating RREQ messages.
If the current time is after Route.DeleteTimeout the corresponding
routing table entry MUST be deleted.
Kim, et al. Expires April 15, 2006 [Page 11]
Internet-Draft DYMO-low October 2005
4.2 Routing Element
4.2.1 Routing Element Creation
When a node creates a RREQ or RREP, it MUST create the RBlock.
It sets the RBNodeAddress to its own address.
4.2.2 Routing Element Processing
After general DYMO-low element pre-processing (Section 4.5.2), the
RBRouteCost for the RBlock is calculated in a cumulative manner
(which is TBD). A route to the RBNodeAddress is then created or
updated, as described in Section 4.1.1. If this RBlock does not
result in a valid route the packet MUST be dropped.
If this node is the TargetAddress AND the A-bit is set (A=1), this
node MUST respond with a RREP. The target node creates a new RE as
described in Section 4.2.1. The TargetAddress in the new RE is set
to the RBNodeAddress from the RE currently being processed. The A-bit
is set to (A=0). The LinkLayerDestinationAddress is set to the
Route.NextHopAddress for the TargetAddress. Then the new RE
undergoes post-processing, according to Section 4.5.3.
If this node is not the TargetAddress, the current RE SHOULD be
handled according to Section 4.5.4.
If this node is the TargetAddress, the current packet and any
additional elements are processed, but this packet is not
retransmitted.
4.3 Route Discovery
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-bit is set to one (A=1) to indicate that the TargetNode must
respond with a RREP. If a route cost is known for the TargetAddress
it is placed in the TRouteCost field. Otherwise, the TRouteCost is
set to zero(0). The LinkLayerDestinationAddress is set to the
DYMOcastAddress. The RE is then transmitted according to
the procedure defined in Section 4.5.4.
After issuing a RREQ, the originating node waits for a route to be
created to the TargetNode. If a RREP is not received within
RREQ_WAIT_TIME milliseconds, this node MAY again try to discover a
route by issuing another RREQ.
Kim, et al. Expires April 15, 2006 [Page 12]
Internet-Draft DYMO-low October 2005
To reduce congestion in a network, repeated attempts at route
discovery for a particular TargetNode SHOULD utilize a binary
exponential backoff. The first time a node issues a RREQ, it waits
RREQ_WAIT_TIME milliseconds for a route to the TargetNode. If a
route is not found within that time, the node MAY send another RREQ.
If a route is not found within two (2) times the current waiting
time, another RREQ may be sent, up to a total of RREQ_TRIES. For
each additional attempt, the waiting time for the previous RREQ is
multiplied by two (2) so that the waiting time conforms to a binary
exponential backoff.
Data packets awaiting for a route MAY be buffered.
If a route discovery has been attempted RREQ_TRIES times without
receiving a route to the TargetAddress, all data packets destined to
the corresponding TargetAddress SHOULD be dropped from the buffer.
4.4 Route Maintenance
4.4.1 Monitoring of Active Links
Before a route can be used for forwarding a packet, it MUST be
checked to make sure that the route is still valid. If the
Route.ValidTimeout is earlier than the current time, the packet
cannot be forwarded, and a RERR message MUST be generated (see
section 4.4.3). In this case, the Route.DeleteTimeout is set
to Route.ValidTimeout + ROUTE_DELETE_TIMEOUT.
If the current time is after Route.DeleteTimeout, then the route
SHOULD be deleted, though a route MAY be deleted at any time.
Upon detecting a link break the detecting node MUST set the
Route.ValidTimeout to the current time for all active routes
utilizing the broken link.
A RERR MUST be issued if a data packet is received and it cannot be
delivered to the next hop. RERR generation is described in
Section 4.4.3. A RERR SHOULD be issued after detecting a broken link
of an active route to quickly notify nodes that a link break occurred
and a route or routes are no longer available.
Kim, et al. Expires April 15, 2006 [Page 13]
Internet-Draft DYMO-low October 2005
4.4.2 Updating Route Lifetimes
To avoid route timeouts for active routes, a node SHOULD update the
Route.ValidTimeout to the final destination address[I-D.ietf-6lowpan
-format] to be the current time + ROUTE_TIMEOUT upon successfully
transmitting a packet to the next hop.
4.4.3 Route Error Generation
When a data packet is received for a destination without a valid
routing table entry, a Route Error (RERR) MUST be generated by this
node. A RERR informs the source that the current route is no longer
available.
In the RERR, the TargetAddress field is the address of the
unreachable node (final destination address) from the data packet.
The setting of the LinkLayerDestinationAddress of the RERR and the
RERR processing at the receiving node are TBD.
4.5 General DYMO-low Processing
4.5.1 DYMO-low Control Packet Processing
A DYMO-low packet may consist of multiple DYMO-low elements.
Each element is processed individually and in sequence, from first
to last. An incoming DYMO-low packet MUST be completely processed
prior to any DYMO-low packet transmissions.
Unless specific element processing requires dropping the DYMO-low
packet, it is retransmitted after processing, according to the method
described in Section 4.5.4.
4.5.2 Generic Element Pre-processing
Each element in a DYMO-low packet undergoes pre-processing before the
element specific processing occurs. During pre-processing, the TTL
is decremented by one (1).
4.5.3 Generic Element Post-processing
If the first element TTL is zero (0) the DYMO-low packet is dropped
after processing of all elements. If the TTL of the first element is
greater than zero the DYMO-low packet is re-transmitted after
processing of all elements. If the TTL of any element is zero (0)
after processing, it MUST be removed from the DYMO-low packet prior to
transmission.
Kim, et al. Expires April 15, 2006 [Page 14]
Internet-Draft DYMO-low October 2005
4.5.4 DYMO-low Control Packet Transmission
DYMO-low packet transmission and re-transmission is controlled by the
LinkLayerDestinationAddress. If the LinkLayerDestinationAddress is
a unicast address, the packet LinkLayerDestinationAddress is replaced
by the Route.NextHopAddress from a route table lookup for the
TargetAddress. If a route for the TargetAddress is unknown or invalid
the packet is dropped and a RERR SHOULD be generated.
4.6 Packet Generation Limits
To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT
control messages per second. RREQ packets SHOULD be discarded before
RREP or RERR packets.
4.7 Sequence Numbers
The usage of sequence numbers in DYMO-low follows the base DYMO
except the sequence number rollover.
4.7.1 Sequence Number Rollover
If the sequence number has been assigned to be the largest possible
number representable as a 8-bit unsigned integer, then the sequence
number MUST be set to one (1) when incremented.
5. Configuration Parameters
Here are some default parameter values for DYMO-low:
Parameter Name Suggested Value
--------------------------- ---------------
NET_DIAMETER 256
RATE_LIMIT 2
ROUTE_TIMEOUT 10 minutes
ROUTE_DELETE_TIMEOUT 2*ROUTE_TIMEOUT
RREQ_WAIT_TIME 1000 milliseconds
RREQ_TRIES 2
6. IANA Considerations
This document needs an additional IANA registry for the prot_type
value that indicates the DYMO-low format.
Kim, et al. Expires April 15, 2006 [Page 15]
Internet-Draft DYMO-low October 2005
7. Security Considerations
The security considerations of the [RFC3561] are applicable to this
document. As described in the charter of the 6lowpan w.g., DYMO-low
will also try to reuse existing security considerations related to
Ad hoc routing protocols. Further considerations will be studied in
the next version.
8. Acknowledgments
Thanks to Byeong-Hee Roh, Shafique Ahmad Chaudhry, Ali Hammad Akbar,
and Hee-Jung Kim for their useful discussions and supports for writing
this document.
Kim, et al. Expires April 15, 2006 [Page 16]
Internet-Draft DYMO-low October 2005
9. References
9.1 Normative References
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/
regauth/oui/tutorials/EUI64.html.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-03 (work in progress), May 2005.
[I-D.ietf-ipv6-rfc2462bis]
Thomson, S., "IPv6 Stateless Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08 (work in progress),
May 2005.
[I-D.ietf-manet-dymo]
Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing",
draft-ietf-manet-dymo-02 (work in progress), June 2005.
[I-D.ietf-6lowpan-format]
Montenegro, G., "Transmission of IPv6 Packets over IEEE
802.15.4 Networks",
draft-ietf-6lowpan-format-00 (work in
progress), July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[ieee802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2003",
October 2003.
Kim, et al. Expires April 15, 2006 [Page 17]
Internet-Draft DYMO-low October 2005
9.2 Informative References
[AODVjr] Chakeres, Ian and Klein-Berndt, Luke, "AODVjr, AODV
Simplified", ACM SIGMOBILE Mobile Computing and
Communications Review pp. 100-101, July 2002.
[I-D.ietf-ipngwg-icmp-v3]
Conta, A., "Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress),
July 2005.
[I-D.perkins-manet-aodvbis]
Perkins, C., "Ad hoc On-Demand Distance Vector (AODV)
Routing", draft-perkins-manet-aodvbis-01 (work in
progress), February 2004.
[KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor
Networks: Attacks and Countermeasures", Elsevier's AdHoc
Networks Journal, Special Issue on Sensor Network
Applications and Protocols vol 1, issues 2-3,
September 2003.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[TinyAODV]
"TinyAODV Implementation", TinyOS Source Code Repository h
ttp://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/
contrib/hsn/.
Kim, et al. Expires April 15, 2006 [Page 18]
Internet-Draft DYMO-low October 2005
Authors' Addresses
Ki-Hyung Kim, Editor
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 219 2433
Email: kkim86@ajou.ac.kr
Gabriel Montenegro
Microsoft Corporation
Email: gabriel_montenegro_2000@yahoo.com
Soohong Daniel Park, Editor
Mobile Platform Laboratory, SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-742
KOREA
Phone: +82 31 200 4508
Email: soohong.park@samsung.com
Ian Chakeres
University of California Santa Barbara
Dept. of Electrical and Computer Engineering
Santa Barbara, CA 93106
USA
Seung Wha Yoo
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 219 1603
Email: swyoo@ajou.ac.kr
Kim, et al. Expires April 15, 2006 [Page 19]
Internet-Draft DYMO-low October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim, et al. Expires April 15, 2006 [Page 20]