Network Working Group S. Oh
Internet-Draft KNU
Expires: January 3, 2008 E. Kim
D. Kaspar
ETRI
H. Jeong
D. Kim
KNU
J. Park
ETRI
July 2, 2007
Packet Building Block and DYMO Applicability for 6LoWPAN
draft-oh-6lowpan-packetbb-dymoapp-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 January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the applicability of the generalized MANET
Oh, et al. Expires January 3, 2008 [Page 1]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
packet/message format (packetbb) and the dynamic MANET on-demand
(DYMO) routing protocol over 6LoWPAN. In order to achieve low memory
usage and low processing overhead, this document suggests what is to
be modified from the MANET base specifications.
Oh, et al. Expires January 3, 2008 [Page 2]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PacketBB for 6LoWPAN . . . . . . . . . . . . . . . . . . . . . 5
3.1. PacketBB Simplification . . . . . . . . . . . . . . . . . 5
3.2. Syntactical message format . . . . . . . . . . . . . . . . 7
3.3. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . . 7
3.4. Generic Message Header and Body Structure . . . . . . . . 8
3.4.1. Generic Message Header (MsgHdr) for 6lowpan . . . . . 8
3.4.2. Message Body . . . . . . . . . . . . . . . . . . . . . 9
4. Data Structure for applying DYMO to 6LoWPAN . . . . . . . . . 10
4.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 10
4.2. Routing Messages (RM) - RREQ & RREP . . . . . . . . . . . 11
4.3. Route Error (RERR) . . . . . . . . . . . . . . . . . . . . 14
5. Comparison of Detailed Operation . . . . . . . . . . . . . . . 15
5.1. DYMO Sequence Numbers . . . . . . . . . . . . . . . . . . 15
5.1.1. Actions After OwnSeqNum Loss . . . . . . . . . . . . . 15
5.2. DYMO Routing Table Operations . . . . . . . . . . . . . . 15
5.2.1. Judging Routing Information's Usefulness . . . . . . . 15
5.2.2. Creating or Updating a Route Table Entry with New
Routing Information . . . . . . . . . . . . . . . . . 16
5.2.3. Route Table Entry Timeouts . . . . . . . . . . . . . . 16
5.2.4. Additional Routing Table Operations . . . . . . . . . 17
5.3. Routing Messages . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. RREQ Creation . . . . . . . . . . . . . . . . . . . . 17
5.3.2. RREP Creation . . . . . . . . . . . . . . . . . . . . 17
5.3.3. Intermediate Node RREP Creation . . . . . . . . . . . 17
5.3.4. RM Processing . . . . . . . . . . . . . . . . . . . . 18
5.3.5. Adding Additional Routing Information to a RM . . . . 18
5.4. Route Discovery . . . . . . . . . . . . . . . . . . . . . 18
5.5. Route Maintenance . . . . . . . . . . . . . . . . . . . . 18
5.5.1. Active Link Monitoring . . . . . . . . . . . . . . . . 18
5.5.2. Updating Route Lifetimes During Packet Forwarding . . 19
5.5.3. Route Error Generation . . . . . . . . . . . . . . . . 19
5.5.4. RERR Processing . . . . . . . . . . . . . . . . . . . 19
5.6. Unknown Messages & TLV Types . . . . . . . . . . . . . . . 20
5.7. Other Considerations . . . . . . . . . . . . . . . . . . . 20
6. Configuration Parameters and Other Administrative Options . . 20
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Oh, et al. Expires January 3, 2008 [Page 3]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
1. Introduction
A Low-power wireless personal area networks (LoWPAN) is a simple low
cost communication network that allows wireless connectivity in
applications with limited power and relaxed throughput requirements.
LoWPANs must support various topologies including mesh and star.
Mesh topologies imply multi-hop routing to a desired destination.
However, the IEEE 802.15.4 standard [ieee802.15.4] does not provide
specific information about how mesh routing could be achieved. Thus,
it is necessary to find a solution for multi-hop mesh network in
LoWPAN.
This can be achieved by applying existing routing protocols or
designing new ones, if necessary. A number of experimental protocols
have been developed in the Mobile Ad-hoc Networks (MANET) working
group, such as AODV [RFC3561], OLSR [RFC3626], or DYMO
[I-D.ietf-manet-dymo]. These protocols, however, are designed to use
IP-based addresses and impose large overhead on LoWPAN devices.
LoWPAN devices are characterized by short range, low bit rate, low
power and low cost [ieee802.15.4], and it is required that the
routing packets fit within a single IEEE 802.15.4 frame to reduce
packet overhead and energy consumption. Thus, simplification of
routing packets and operations must be done in order to reuse the
existing solutions in below IP layer.
This document provides informative guidelines on how to apply
existing MANET solutions in 6LoWPAN, based on several experiments to
port existing MANET routing solutions on IEEE 802.15.4 sensor nodes.
The MANET routing solutions are based on a generalized packet and
message format, the PacketBB [I-D.ietf-manet-packetbb], which should
be considered together with an existing MANET routing protocol.
Similarly, this document specifies the following:
o The 16-bit or 64-bit MAC address of the destination node
associated with the routing table entry.
o How to apply the generalized packet and message formats for MANET
routing protocols (PacketBB) into 6LoWPAN.
o How to apply the dynamic MANET on-demand (DYMO) routing protocol
into 6LoWPAN.
For 6LoWPAN, 16-bit short or 64-bit (EUI-64) addresses are used
instead of IP addresses. Many elements in PacketBB used in MANET
DYMO are needed to be removed or combined into one single message
header, in order to fit into a single IEEE 802.15.4 frame. DYMO
Routing messages are based on the modified PacketBB for 6LoWPAN.
Many routing operations including the routing table have been
simplified.
Oh, et al. Expires January 3, 2008 [Page 4]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
2. Terminology
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].
Additionally, this document uses terminologies from
[I-D.ietf-manet-packetbb] and [I-D.ietf-manet-dymo].
3. PacketBB for 6LoWPAN
3.1. PacketBB Simplification
The MANET base DYMO specification conforms to the generalized packet
and message format as described in [I-D.ietf-manet-packetbb] (also
refered to as PacketBB). However, due to the following reasons, the
MANET PacketBB cannot be applied to 6LoWPAN without modification: (a)
highly flexible packet/message structure consumes more processing
time, and (b) TLV blocks make packets bigger and consume more memory
during transmission. Thus, we first analyzed each element of the
MANET PacketBB and built a simplified message structure similar by
using the elements shown in Table 1. This table shows comparison of
PacketBB information for DYMO in MANET and 6LoWPAN.
The IP and UDP headers are not used since the PacketBB and DYMO for
6LoWPAN run in the adaptation layer, below the IP and on top of the
link layer. Instead, MAC header information is used (refer to
Table 2).
MANET base DYMO specification defines 'Unicast response request' TLV.
In this 6lowpan applicable format, U-bit of MsgHdr field indicates
whether unicast responses are required or not (refer to Section 3.4).
To reduce parsing overhead, the structure of an address block and
address block TLV blocks are fixed and the address information of the
original node is merged into a routing block (RBlock), which is newly
defined for simplified packet format for 6lowpan. An RBlock has an
address and associated fields such as Cost (Instead of HopCnt) and
SeqNum. Note that only Cost and SeqNum are allowed as associated
attributes in the 6LoWPAN PacketBB.
Oh, et al. Expires January 3, 2008 [Page 5]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
+----------+--------------------------+------------+----------------+
| PacketBB | Field Name | used in | used in |
| Prefix | | MANET DYMO | 6LoWPAN |
+----------+--------------------------+------------+----------------+
| MsgHdr | MsgHdr.Type | Mandatory | Applied |
| | MsgHdr.HopLimit | Mandatory | Applied |
| | MsgHdr.HopCnt | Mandatory | Applied |
| MsgTLV | Message TLV Block | Optional | Modified |
| AddBlk | TargetNode.Address | Included | Included in |
| | | in address | MsgHdr |
| | | block | |
| | OrigNode.Address | Included | Included in |
| | | in address | RBlock (newly |
| | | block | defined) |
| | AdditionalNode | Optional | Optional |
| AddTLV | TargetNode.AddTLV.SeqNum | used | not used |
| | TargetNode.AddTLV.HopCnt | used | not used |
| | OrigNode.AddTLV.SeqNum | used | used |
| | OrigNode.AddTLV.HopCnt | used | .Cost(instead |
| | | | of HopCnt) |
+----------+--------------------------+------------+----------------+
Table 1
TargetNode.Address is included in MsgHdr. Unlikely from
OrigNode.AddTLV, TargetNode.AddTLV is not used for simplified format,
due to simplified operations for routing table (refer to
Section 5.2). For 6LoWPAN, most DYMO messages are sent with the MAC
destination address set to the IEEE 802.15.4 broadcast address,
instead of LL MANET ROUTERS. Unicast DYMO messages are sent with the
MAC destination address set to the Route.NextHopAddress toward the
TargetNode.
This document uses the following notation conventions to describe
6LoWPAN-based DYMO protocol messages:
Oh, et al. Expires January 3, 2008 [Page 6]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
+------------------------------+-------------------+
| Information Location | Notational Prefix |
+------------------------------+-------------------+
| IEEE 802.15.4 MAC header | MAC |
| Message header | MsgHdr |
| Message body (routing block) | MsgBody |
+------------------------------+-------------------+
Table 2
3.2. Syntactical message format
Information is carried through messages, and the messages contain
message header and message body. <message> is defined by:
<message> = <MsgHdr>
<MsgBody>
<MsgHdr> = <Msg-Type>
<Msg-header-info>
<TargetNode.address>
<Msg-header-info> = <Msg-semantics>
<hopLimit>
<hopCnt>
Figure 1
The newly defined RBlock which will be in MsgBody is defined in
Section 3.4.2.
3.3. LoWPAN Encapsulation
All messages specified in this document SHOULD be encapsulated as
defined in [I-D.ietf-6lowpan-format]. Detailed packet structure is
described below.
A LoWPAN encapsulated DYMO message:
+---------------+-------------+--------------+-----
| DYMO Dispatch | DYMO MsgHdr | DYMO MsgBody | ...
+---------------+-------------+--------------+-----
Figure 2
Oh, et al. Expires January 3, 2008 [Page 7]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
3.4. Generic Message Header and Body Structure
3.4.1. Generic Message Header (MsgHdr) for 6lowpan
Generic message header used in MANET DYMO from MANET PacketBB are
redesigned to simplify for 6lowpan messages. All DYMO messages
specified in this document conform to the fixed header (MsgHdr)
structure described 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 |A|U| Reserved | HopLimit | HopCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Message Type (Type)
This 8-bit field specifies the type of the DYMO messages. This
field uses the same value as in the MANET base DYMO specification.
A-bit (A)
16-bit short address : 0
64-bit (EUI-64) address : 1
U-bit (U)
Unicast response request bit. If U-bit is set to one (1), this
indicates to the processing node that the previous hop
(MAC.PrevHopAddress) expects a unicast message within
UNICAST_MESSAGE_SENT_TIMEOUT.
Reserved
This 6-bit field is reserved for future use.
Hop Limit (HopLimit)
This 8-bit field specifies the number of hops that the packet can
be transmitted.
Hop Count (HopCnt)
This 8-bit field contains the number of hops this message has
traversed.
Address of Target Node (TargetNode.Address)
Oh, et al. Expires January 3, 2008 [Page 8]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
If the message is a RM, this field denotes the address of target
node. If the message is a RERR, this field denotes the address of
unreachable node. This field can be either 16-bit and 64-bit
according to A-bit.
3.4.2. Message Body
A routing block (RBlock) is defined to contain routing information.
It is a combination of an address and associated TLV blocks. After
the MsgHdr, RBlock can follow in message body area. Message body of
a RM consists of one or more routing blocks (RBlock), as described
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|C| Reserved | Node.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node.SeqNum | Node.Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
A RBlock contains following information:
A-bit (A)
16-bit short address : 0
64-bit (EUI-64) address : 1
C-bit (C)
Set to zero (0) if Node.Cost is not included.
Set to one (1) if Node.Cost is included.
Node.Address
The 16-bit or 64-bit address of the node associated with the
RBlock.
Node.SeqNum
The 16-bit DYMO SeqNum of the node.
Node.Cost
The 16-bit cost metric between the Node.Address and ThisNode.
Oh, et al. Expires January 3, 2008 [Page 9]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
4. Data Structure for applying DYMO to 6LoWPAN
4.1. Route Table Entry
Due to the processing power and memory limitations of 6LoWPAN
devices, route table entries should be minimized. Recommended route
table entries and the comparison with the MANET base DYMO
specification are as follows:
+------------------------+-----------------+------------------------+
| Field Name | MANET DYMO | Simplified 6LoWPAN |
| | Routing Table | Routing Table |
+------------------------+-----------------+------------------------+
| Route.Address | Mandatory | Mandatory |
| Route.SeqNum | Mandatory, | Mandatory, 16-bit |
| | 16-bit | |
| Route.NextHopAddress | Mandatory, | Mandatory, |
| | IPv4/IPv6 | 16-bit/64-bit MAC |
| | | address |
| Route.NextHopInterface | Mandatory | SHOULD NOT be used |
| Route.Broken | Mandatory | SHOULD NOT be used |
| Route.HopCnt | Optional | Route.Cost / Optional |
| Route.Prefix | Optional | Not used |
+------------------------+-----------------+------------------------+
Table 3
Route.Address
The 16-bit or 64-bit MAC address of the destination node
associated with the routing table entry.
Route.SeqNum
The DYMO SeqNum associated with this routing information.
Route.NextHopAddress
The 16-bit or 64-bit MAC address of the next node on the path
toward the Route.Address.
The following fields are optional:
Route.HopCnt (Route.Cost)
Hop count to destination. Route.Cost is used instead of
Route.HopCount. Route.Cost can be any cumulative cost metric of
the route, e.g. hop count or link quality indication (LQI). Hop
count is RECOMMENDED, as in the MANET base DYMO specification.
The following fields are removed from the MANET base DYMO
specification:
Oh, et al. Expires January 3, 2008 [Page 10]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Route.NextHopInterface
Usually 6LoWPAN nodes have only one interface. Thus, to save
memory, this field SHOULD NOT be used.
Route.Broken
Due to memory limitations, expired or invalid routes should be
removed immediately (refer to Section 5.2.3). Thus, Route.Broken
should not be used.
Route.Prefix
This field is not used.
4.2. Routing Messages (RM) - RREQ & RREP
All routing messages (RMs) conform to the format described below.
Oh, et al. Expires January 3, 2008 [Page 11]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Example 16-bit address RREQ
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
MAC Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC.DestinationAddress = 0xffff|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
LoWPAN Encapsulation Header
+-+-+-+-+-+-+-+-+
| DYMO Dispatch |
+-+-+-+-+-+-+-+-+
...
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ-Type |0|0| Reserved | HopLimit | HopCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body (RBlock) - Originator Node
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Reserved | OrigNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNode.SeqNum | OrigNode.Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body (RBlock) - Additional Nodes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Reserved | AdditionalNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AdditionalNode.SeqNum | AdditionalNode.Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Figure 5
A RM requires the following information:
MAC.DestinationAddress
The MAC address of the destination. For RREQ the
MAC.DestinationAddress is set to the IEEE 802.15.4 broadcast
address. For RREP the MAC.DestinationAddress is set to the
Route.NextHopAddress toward the TargetNode.
Oh, et al. Expires January 3, 2008 [Page 12]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
MAC.DestinationPANid
The PAN id of the destination. For broadcast PAN the
MAC.DestiationPANid is set to 0xffff.
MsgHdr.TargetNode.Address
The 16-bit or 64-bit MAC address of the TargetNode.
MsgBody.OrigNode.Address
The 16-bit or 64-bit MAC address of the OrigNode.
MsgBody.OrigNode.SeqNum
The sequence number of the OrigNode.
MsgBody.Orig.Cost
Route cost metric between OrigNode and ThisNode.
MsgBody.AdditionalNode.Address
The 16-bit or 64-bit MAC address of an additional node that can be
reached via the node adding this information.
MsgBody.AdditionalNode.SeqNum
The sequence number of an additional node.
MsgBody.AdditionalNode.Cost
The route cost between AddtionalNode and ThisNode.
Oh, et al. Expires January 3, 2008 [Page 13]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
4.3. Route Error (RERR)
RERR messages conform to the format described below.
Example 16-bit address 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
MAC Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC.DestinationAddress = 0xffff|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
LoWPAN Encapsulation Header
+-+-+-+-+-+-+-+-+
| DYMO Dispatch |
+-+-+-+-+-+-+-+-+
...
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RERR-Type |0|0| Reserved | HopLimit | HopCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnreachableNode.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnreachableNode.SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
A RERR requires the following information:
MAC.DestinationAddress
MAC.DestinationAddress is set to IEEE 802.15.4 broadcast address.
Address of Unreachable Node (MsgHdr.TargetNode.Address)
The 16-bit or 64-bit MAC address of the UnreachableNode.
MsgBody.UnreachableNode.SeqNum
The sequence number of the UnreachableNode. Zero (0) if unknown.
Oh, et al. Expires January 3, 2008 [Page 14]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
5. Comparison of Detailed Operation
In this section, we recommend some modifications to the MANET base
DYMO operations based on our experimental results for 6LoWPAN.
Default operations are not changed unless otherwise stated.
5.1. DYMO Sequence Numbers
6LoWPAN operations for DYMO sequence numbers, except actions after
OwnSeqNum loss, are exactly the same as those of the MANET base DYMO
specification.
5.1.1. Actions After OwnSeqNum Loss
Since the route table entry timeout operations defined in this
document are different from those of the MANET base DYMO
specification (see Section 5.2.3), actions after OwnSeqNum loss are
also different from those in the MANET base DYMO specification.
When a node lost its OwnSeqNum, it MUST wait for at least
ROUTE_TIMEOUT, instead of waiting ROUTE_DELETE_TIMEOUT.
Other actions are not changed.
5.2. DYMO Routing Table Operations
5.2.1. Judging Routing Information's Usefulness
The SeqNum is used in the same manner as in the MANET base DYMO
specification. However, since we use Route.Cost instead of
Route.HopCnt, the term Route.HopCnt in the MANET base DYMO
specification is changed to Route.Cost. Moreover, since we a use
cummulative cost metric (Route.Cost) instead of HopCnt, the
classification of incoming routing information is changed as follows:
1. Stale
Not changed.
2. Loop-possible
Since we use the cumulative cost metric Route.Cost instead of
Route.HopCnt, it is no use checking whether Node.Cost is greater
than Route.Cost + 1. Thus, the condition for possible loops is
changed as follows:
(Node.SeqNum == Route.SeqNum) AND
((Node.Cost is unknown) OR
(Route.Cost is unknown))
If hop count is used as a cost metric, the condition (Node.Cost >
Route.Cost + 1) is still useful.
Oh, et al. Expires January 3, 2008 [Page 15]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
3. Inferior
Since we do not use Route.Broken (this implies that existing
route table entries are always valid, i.e. Route.Broken is
always false), the condition for inferior is changed as follows:
(Node.SeqNum - Route.SeqNum < 0) OR
((Node.SeqNum == Route.SeqNum) AND
((Node.Cost > Route.Cost) OR
((Node.Cost == Route.Cost) AND
RM is RREQ)))
4. Superior
Not changed. Note that Route.Broken is not used and it can be
treated as if it is false as stated above.
5.2.2. Creating or Updating a Route Table Entry with New Routing
Information
As in DYMO for MANET, the route table entry is populated as follows:
1. The Route.Address is set to Node.Address.
2. The Route.SeqNum is set to Node.SeqNum.
3. The Route.NextHopAddress is set to MAC.PrevHopAddress (the node
that transmitted this RM). This is because DYMO for 6LoWPAN runs
below the IP layer.
4. If Node.Cost is known, the Route.Cost is set to Node.Cost.
Node.Cost is used instead of Node.HopCnt.
The previous timer for this route table entry is removed. A timer to
indicate a valid route (and for delete timeout) is set to
ROUTE_TIMEOUT. The usage of this timer is described in
Section 5.2.3.
5.2.3. Route Table Entry Timeouts
Maintaining various timeouts can cause unnecessary overhead. Thus,
unlike the MANET base DYMO specification, we use only one timeout
called valid timeout denoted by ROUTE_VALID. ROUTE_AGE_MIN,
ROUTE_AGE_MAX, ROUTE_NEW, ROUTE_USED and ROUTE_DELETE are not used
within 6LoWPAN.
5.2.3.1. Valid Timeout (ROUTE_TIMEOUT)
When a route table entry is created, it should be maintained for at
least ROUTE_TIMEOUT. After the timer is expired, the entry should be
deleted immediately as if the delete information timeout in the MANET
base DYMO specification were expired.
Oh, et al. Expires January 3, 2008 [Page 16]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
5.2.4. Additional Routing Table Operations
5.2.4.1. Route Table Entry Replacement Policy
Due to the memory limitation of 6LoWPAN devices, the route table may
be overflown. However, the DYMO specification for MANET does not
specify any routing table entry replacement policy. For 6LoWPAN, the
following replacement policy is recommended:
If new incoming routing information cannot be added to the route
table due to route table overflow, the least recently used route
table entry SHOULD be deleted, i.e. LRU algorithm SHOULD be used for
route table entry replacement policy. This can be determined by
examining valid timeout values in the routing table; a route table
entry which has the earliest timeout value is the least recently used
entry.
5.3. Routing Messages
5.3.1. RREQ Creation
RREQ creation is the same as the specified for DYMO in MANET, but the
message structure described in Section 4.2 is used.
First, the node adds the MsgHdr.TargetNode.Address to the RREQ. Note
that TargetNode.SeqNum and TargetNode.Cost are unknown since invalid
route table entries are deleted immediately.
Next, the node sets its address and SeqNum to OrigNode.Address and
OrigNode.SeqNum. The OrigNode.Cost and is set to zero (0).
Other fields are set as specified in the MANET base DYMO
specification.
5.3.2. RREP Creation
RREPs are created as specified in the MANET base DYMO specification
except for the message structure. The message structure of a RREP
conforms to Section 4.2.
5.3.3. Intermediate Node RREP Creation
Since all RMs do not have a TargetNode.SeqNum, intermediate nodes
cannot satisfy the intermediate RREP creation condition specified in
the MANET base DYMO specification. However, if the target network is
supposed to be static, intermediate nodes may generate RREP messages
without comparing Target.SeqNum. If the intermediate node RREP is
used, it should be done as specified in the MANET base DYMO
Oh, et al. Expires January 3, 2008 [Page 17]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
specification.
5.3.4. RM Processing
Nodes should process RMs as specified in the MANET base DYMO
specification. However, since we use RBlock instead of AddBlk and
AddTLV and Node.Cost instead of Node.HopCnt, actions about
AdditionalNode.AddTLV.HopCnt are changed as follows:
For each address in the RM that includes Node.Cost, the Node.Cost is
increased according to the cost metric between MAC.PrevHopAddress and
ThisNode. We provide the following pseudo-code for clarification:
Node.Cost = Node.Cost
+ (cost between MAC.PrevHopAddress and ThisNode)
5.3.5. Adding Additional Routing Information to a RM
To avoid fragmentation, appending additional routing information to a
RM SHOULD NOT be used. If used, it is done the same way as specified
by the MANET base DYMO.
5.4. Route Discovery
The route discovery process can be carried out according to the MANET
base DYMO specification. Note that RREQ is created using the message
structure described in Section 4.2.
5.5. Route Maintenance
Route maintenance process is basically the same as in the MANET base
DYMO specification. Since we do not use recently used timeout
(ROUTE_USED), a node does not have to check whether the broken link
has recently been used or not.
5.5.1. Active Link Monitoring
The MANET base DYMO specification recommends the following mechanisms
for active link monitoring:
o Link layer feedback
o Neighborhood discovery [I-D.ietf-manet-nhdp]
o Route timeout
o Other monitoring mechanisms or heuristics
Among them, NHDP or similar HELLO mechanisms SHOULD be avoided in
order to reduce periodic broadcast. Instead, link layer feedback
(LLF) SHOULD be used for active link monitoring.
Oh, et al. Expires January 3, 2008 [Page 18]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
When the network is congested, there are many spurious link failures
caused by collisions. If an active link is removed even in case of a
single link failure, nodes will try to find a new route and it causes
the network to become even more congested. In contrast, if an active
link is not removed even in case of a series of failures, packets
cannot be delivered properly. Thus, to alleviate the effect of
spurious link failure caused by congestion, ThisNode must remove the
affected forwarding routes when MAX_LINK_LAYER_FAILURES consecutive
transmissions have failed for a certain link.
5.5.2. Updating Route Lifetimes During Packet Forwarding
Since we use only one timeout, updating route lifetime is different
from that of the MANET base DYMO specification. This is done like
this:
When a node receives a data packet, it should reset a valid timeout
for the route to the source address of the packet to ROUTE_TIMEOUT.
Likewise, a node should reset a valid timeout to ROUTE_TIMEOUT for
the route to the destination address of the packet which has been
successfully transmitted.
5.5.3. Route Error Generation
The meaning and the basic operation of RERR is the same as in the
base DYMO specification for MANET. However, creating a new RERR is a
bit different due to our new message structure; when a node creates
an RERR, the address of UnreachableNode is inserted into
MsgHdr.TargetNode. The MsgHdr.HopLimit is set to MAX_HOPLIMIT and
the MsgHdr.HopCnt is set to one (1).
Unlike the DYMO specification for MANET, the simplified message
structure for 6LoWPAN does not allow to insert additional unreachable
nodes, in order to avoid fragmentation.
The RERR is sent to IEEE 802.15.4 broadcast address.
5.5.4. RERR Processing
When processing a RERR, Route.SeqNum is assumed as unknown. Since
Route.NextHopInterface is omitted in route table entry, it is
considered to be the same as the interface on which the RERR was
received. With this, RERRs can be processed in the same manner as
specified by DYMO for MANET.
Oh, et al. Expires January 3, 2008 [Page 19]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
5.6. Unknown Messages & TLV Types
If a received message has unknown type, it is discarded in the same
way as per MANET base DYMO specification. However, because of the
simplified 6LoWPAN PacketBB, there will be no unknown TLV types.
Instead, if a node has a trouble to interpret RBlocks properly, the
RM is dropped.
5.7. Other Considerations
DYMO, as specified for MANET, has considerations about other
operations such as advertising network addresses, simple internet
attachment and gatewaying, and multiple interfaces. However, since
they are out of 6LoWPAN's scope, we do not consider their
applicability.
6. Configuration Parameters and Other Administrative Options
Based on our experimental results, some parameters are adjusted for
operation in 6LoWPAN. The default value of the MANET base DYMO
specification is used if it is not stated here.
Suggested Parameter Values
+-------------------------+---------+
| Name | Value |
+-------------------------+---------+
| ROUTE_TIMEOUT | 10 min. |
| RATE_LIMIT | 3 |
| MAX_LINK_LAYER_FAILURES | 2 |
+-------------------------+---------+
Table 4
These suggested values work well for small and medium networks with
no topology changes.
Oh, et al. Expires January 3, 2008 [Page 20]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Suggested Option Settings
+-------------------------------+---------------------------+
| Name | Value |
+-------------------------------+---------------------------+
| RERR_INCLUDE_ALL_UNREACHABLES | No |
| BUFFER_SIZE_PACKETS | 3 packets |
| BUFFER_SIZE_BYTES | 102 * BUFFER_SIZE_PACKETS |
+-------------------------------+---------------------------+
Table 5
According to [ieee802.15.4], the maximum allowable frame size at the
media access control layer (we use this value as a BUFFER_SIZE_BYTES)
is calculated as follows:
BUFFER_SIZE_BYTES = aMaxPHYPacketSize (127) - aMaxFrameOverhead (25)
BUFFER_SIZE_PACKETS is determined by how much memory the nodes have.
Our suggested value is fit to nodes which have a small memory, e.g.
4KB.
7. Summary
The table below summarizes the difference between DYMO over MANET and
DYMO over 6LoWPAN, including the PacketBB
DYMO over MANET vs. DYMO over 6LoWPAN
+---------------+---------------------+-----------------------------+
| | DYMO over MANET | DYMO over 6LoWPAN |
| | (including | (including PacketBB) |
| | PacketBB) | |
+---------------+---------------------+-----------------------------+
| Addressing | IPv4 and IPv6 | 16-bit short address and |
| | | EUI-64 address |
| Message | MANET packetbb | Simplified packetbb for |
| Structure | compliant | 6lowpan |
| Timeout | Various timeouts | Only route valid timeout |
| Routing Table | Mandatory fields | Mandatory fields |
| Entries | +Optional fields | -Route.NextHopInterface |
| | | -Route.Broken +Route.Cost |
| Target.SeqNum | Optional | No |
| and | | |
| Target.HopCnt | | |
| Supported | Everything defined | Only Cost and SeqNum |
| TLVs | | |
Oh, et al. Expires January 3, 2008 [Page 21]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
| Routing | Hop count | Any cumulative cost metric |
| Metric | | including hop count |
+---------------+---------------------+-----------------------------+
Table 6
8. IANA Considerations
In addition to the MANET base DYMO specification, this document also
requires an IANA registry entry for a 6LoWPAN DYMO dispatch type
shown in Section 3.3.
9. Security Considerations
The security considerations of the base DYMO specification for MANET
can be applied to this document since this document does not specify
a new protocol.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-manet-dymo]
Perkins, C. and I. Chakeres, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-09 (work in
progress), May 2007.
[I-D.ietf-manet-packetbb]
Clausen, T., "Generalized MANET Packet/Message Format",
draft-ietf-manet-packetbb-06 (work in progress),
June 2007.
[I-D.ietf-6lowpan-format]
Montenegro, G., "Transmission of IPv6 Packets over IEEE
802.15.4 Networks", draft-ietf-6lowpan-format-13 (work in
progress), April 2007.
[ieee802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2003",
October 2003.
Oh, et al. Expires January 3, 2008 [Page 22]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
10.2. Informative References
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[I-D.ietf-manet-nhdp]
Clausen, T., "MANET Neighborhood Discovery Protocol
(NHDP)", draft-ietf-manet-nhdp-03 (work in progress),
May 2007.
Authors' Addresses
Sutaek Oh
Kyungpook National University
1370 Sankyuk-dong, Buk-gu
Daegu 702-701
Korea
Phone: +82 53 940 8590
Fax: +82 53 957 4846
Email: stoh@monet.knu.ac.kr
Eunsook Kim
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6124
Fax: +82 42 861 5404
Email: eunah.ietf@gmail.com
Oh, et al. Expires January 3, 2008 [Page 23]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Dominik Kaspar
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 1072
Fax: +82 42 861 5404
Email: dominik.ietf@gmail.com
Hong-Jong Jeong
Kyungpook National University
1370 Sankyuk-dong, Buk-gu
Daegu 702-701
Korea
Phone: +82 53 940 8590
Fax: +82 53 957 4846
Email: hjjeong@monet.knu.ac.kr
Dongkyun Kim
Kyungpook National University
1370 Sankyuk-dong, Buk-gu
Daegu 702-701
Korea
Phone: +82 53 950 7571
Fax: +82 53 957 4846
Email: dongkyun@knu.ac.kr
Jungsoo Park
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6514
Fax: +82 42 861 5404
Email: pjs@etri.re.kr
Oh, et al. Expires January 3, 2008 [Page 24]
Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Oh, et al. Expires January 3, 2008 [Page 25]