Network Working Group S. Oh, Ed. Internet-Draft KNU Expires: January 10, 2008 E. Kim, Ed. D. Kaspar ETRI H. Jeong D. Kim KNU J. Park ETRI July 9, 2007 Packet Building Block and DYMO Applicability for 6LoWPAN draft-oh-6lowpan-packetbb-dymoapp-01 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 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Oh, et al. Expires January 10, 2008 [Page 1] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 Abstract This document describes the applicability of the generalized MANET 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 10, 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 . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 20 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 10, 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 10, 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 10, 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 10, 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. is defined by: = = = 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 10, 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 10, 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 10, 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 indicator (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 10, 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 10, 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 10, 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 10, 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 10, 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' explained in Section 5.1.1, are exactly the same as those of the MANET base DYMO specification. 5.1.1. Actions After OwnSeqNum Loss As the timeout operations for route table entry 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, as the simplified DYMO for 6lowpan uses only one timeout value (see Section 5.2.3). 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, but Route.HopCnt related actions is changed. The Route.HopCnt in the MANET base DYMO specification is changed to Route.Cost. The cumulative cost metric, Route.Cost, makes the classification of incoming routing information changed as follows: 1. Stale Not changed. 2. Loop-possible In addition, it is no use to check if Node.Cost is greater than Route.Cost + 1, as Route.Cost is cumulative metric. The condition for possible loops is changed as follows: (Node.SeqNum == Route.SeqNum) AND ((Node.Cost is unknown) OR (Route.Cost is unknown)) Oh, et al. Expires January 10, 2008 [Page 15] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 If hop count is used as a cost metric, the condition (Node.Cost > Route.Cost + 1) will be applied as it is. 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 for 6LoWPAN 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. Oh, et al. Expires January 10, 2008 [Page 16] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 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 (ROUTE_DELETE)' has been expired. 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 if we runs in the same way with the MANET base DYMO specification. However, the DYMO specification for MANET does not specify any replacement policy for routing table entry. Thus, this document suggests the following replacement policy for 6lowpan: If new incoming routing information cannot be added to the route table due to the routing table overflow, the least recently used route table entry SHOULD be deleted, i.e. LRU algorithm SHOULD be used as the replacement policy for the route table entry. 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 because invalid route table entries are deleted immediately. Next, the node sets its address and SeqNum to OrigNode.Address and OrigNode.SeqNum. The OrigNode.Cost 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. Oh, et al. Expires January 10, 2008 [Page 17] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 5.3.3. Intermediate Node RREP Creation As all RMs described in this document do not have a TargetNode.SeqNum, intermediate nodes cannot satisfy the condition for the 'Intermediate RREP creation' 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 specification. 5.3.4. RM Processing Nodes should process RMs as specified in the MANET base DYMO specification, except the modified packet vaules. We use RBlock instead of AddBlk and AddTLV, and Node.Cost instead of Node.HopCnt, so the 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 with 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: Oh, et al. Expires January 10, 2008 [Page 18] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 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. When the network is congested, there are many spurious link failures caused by collisions. If an active link is removed even in the 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 the 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 to ROUTE_TIMEOUT for the route to the source address of the packet. 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 MANET base DYMO specification. 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 MANET base DYMO specification, 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. Oh, et al. Expires January 10, 2008 [Page 19] Internet-Draft PacketBB & DYMO Applicability for 6LoWPAN July 2007 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. 5.6. Unknown Messages & TLV Types If a received message has unknown type, it is discarded in the same way as MANET base DYMO specification describes. However, no unknown TLV types can be made by the simplified PacketBB for 6LoWPAN. Instead, if a node has a trouble to interpret RBlocks properly, the RM is simply 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 operations 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 10, 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 the memory size that 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 10, 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 10, 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 (editor) 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 (editor) 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 10, 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 10, 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 10, 2008 [Page 25]