Networking Working Group T. Iwao, Ed. Internet Draft FUJITSU LIMITED Intended status: July 2, 2009 Expires: January 2010 Distributed Autonomous Depth-first Routing Protocol in LLN draft-iwao-roll-dadr-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 2, 2009. Iwao, et al. Expires January 2, 2010 [Page 1] Internet-Draft DADR Protocol July 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document is a proposal of the distributed autonomous depth-first routing (DADR) protocol which is quite different from conventional algorithms such as AODV and OLSR. It proposes a traversable algorithm which can determine a direct path between the global source and the global destination in a low power and lossy network (LLN). We propose the DADR algorithm whose characteristics work well in LLNs with more than 10^4 nodes. This algorithm selects a direct path between the global source and the global destination based on a routing-cost- function which identifies path-candidates with good communication quality between each pair of nodes on the path. This protocol does not need to configure the equipment such as setting IP addresses, and thisresults in saving cost and time in deploying, establishing and operating a large scale network. Iwao, et al. Expires January 2, 2010 [Page 2] Internet-Draft DADR Protocol July 2009 Table of Contents 1. Introduction...................................................4 2. Terminology....................................................6 3. Overview.......................................................6 4. Operating Principle............................................7 5. Node Operation.................................................7 5.1. Time Synchronization Message..............................8 5.2. Hello Message............................................10 5.3. Data and Data ACK Message................................11 6. Message Formats...............................................12 6.1. Ad Hoc Header Format.....................................12 6.2. Time Synchronization Message Format......................13 6.3. Hello Message Format.....................................14 6.4. Hello Message Header Format..............................15 6.5. Hello Header Format......................................15 6.6. Data Frame Format........................................16 6.7. Data Header Format.......................................17 6.8. Data ACK Format..........................................17 6.9. Data ACK Header Format...................................17 7. Table Formats.................................................19 7.1. Routing Table format.....................................19 7.2. Data Management Table format.............................20 7.3. Link Table format........................................20 8. Security Considerations.......................................21 9. IANA Considerations...........................................21 10. Conclusions..................................................21 11. References...................................................21 11.1. Normative References....................................21 11.2. Informative References..................................22 12. Acknowledgments..............................................22 Appendix A. First Appendix.......................................23 A.1. First Header level.......................................23 Iwao, et al. Expires January 2, 2010 [Page 3] Internet-Draft DADR Protocol July 2009 1. Introduction A low power and lossy network (LLN) has a characteristic in which links between nodes are unstable due to interference, limited power and frequent equipment failures. Because of this characteristic, it is difficult to keep established paths between nodes in an LLN. In addition, the number of nodes in an LLN is very large. RFC5548([ROLL- Req-RFC]) mandates that the LLN must handle on the order of 10^4 nodes. Hence, a protocol which creates an LLN needs to overcome both unstable links among nodes and the huge number of nodes in a power efficient manner. Conventional protocols such as Ad hoc On-Demand Distance Vector (AODV) and Optimized Link State Routing Protocol (OLSR) are based on breadth first search and are not efficient enough to support LLNs. These protocols need to use a flooding mechanism to send messages to a large area of the network for searching for a path. This presents a scalability issue when dealing with a large number of nodes. Additionally, once a path is found, it is continuously used to maintain the paths. However, the probability that the found path will persist for a long period of time is low because of the lossy characteristics of LLN. If nodes lose the path, then they flood the "lossy" network with additional path request messages. These messages influence other nodes, and then more and more flooding messages are generated by other nodes. This potentially overloads the network and causes the network to crash due to the huge amount of path request messages. Therefore, the Breadth first search mechanism is unfit for LLNs. To become overloaded with a specific node from the point of view of power consumption is not a good efficiency in terms of a variation of a life time of each node and the network. One of the methods to achieve the "low power" network is a load distribution technique by adding a term of the load distribution and the power consumption into a path cost evaluation function. A protocol that is suited for LLNs should also support redundant paths, does not rely on flooding messages, and also flexibly handles unstable links among nodes. The Distributed Autonomous Depth-first Routing (DADR) enables nodes to efficiently form an LLN. TheDADR protocol, based on depth first search, guarantees reachability, handles failure of nodes, adapts to environmental changes, and is suited to a large scale network. This protocol uses a decentralized depth-first search algorithm for a large scale network and enables nodes to adjust their routes depending on the knowledge of the local area of each node whenever it Iwao, et al. Expires January 2, 2010 [Page 4] Internet-Draft DADR Protocol July 2009 forwards messages to others. This protocol does not place a heavy burden on the network when nodes create routes, and also makes nodes keep communication with each other under real time changes in the environment. This protocol does not need to use flooding for a path search and maintains redundant paths and flexibility with respect to an environmental change (e.g., link status or topology change).. Therefore, the DADR protocol is well suited for LLNs. Iwao, et al. Expires January 2, 2010 [Page 5] Internet-Draft DADR Protocol July 2009 2. Terminology node: a core equipment which organizes Ad hoc network neighboring node(s): a node(s) which can receive a message in one hop Ad Hoc header: Frame information encapsulating each message Global DST: Final End Destination node of the message Global SRC: Original Source node of the message Local DST: Next neighboring node of the message on the path toward a global DST Local SRC: Current node that is transmitting the message along the path toward the Global DST 3. Overview A distributed autonomous traversable routing algorithm based on a depth first search is a learning strategy that can create routes by transmitting data without using an explicit route request message. In the depth first search, a node transfers incoming data from an upstream node into a downstream node. By the use of the depth first search, all nodes can be found as long as each node is connected on the same network even if the network topology is complex. The depth first search method does not require a route request message to create a route, and this method is able to create a route through a data transmission if a node detects a neighbor node. Therefore, it can adapt to real time changes in an environment; it can select an appropriate link by switching to another candidate node (Local DST) immediately when a transmission fails due to an unstable link. One drawback of the depth first search method is that it may take a long time to find a Global DST depending on the network condition and topology. In the worst case, relaying the data message to all possible neighboring nodes is required to find the destination node. This causes significant delays and an increase of number of packets in the network. In order to overcome this problem, Hello messages are used to indicate the appropriate path. It is important for each node to select an appropriate node which has an efficient route to a Global DST. The distributed traversable routing algorithm based on a depth first search has a function that gives a direction to a Global DST in advance. One of a way to select a neighbor node which has Iwao, et al. Expires January 2, 2010 [Page 6] Internet-Draft DADR Protocol July 2009 higher reach-ability to a Global DST makes use of a Hello message. Each node sends a Hello message at a regular interval (for example, on the order of once every several minutes) to its neighbors. Every Hello message includes self information and information on other nodes in the same network, and each path cost evaluation value. Each node can reduce the search time by exchanging a Hello message that has highest evaluated value going to each Global DST. Furthermore, this Hello message is able to create an appropriate route by using a suitable cost function for each application. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 RFC-2119 [1]. 4. Operating Principle A distributed autonomous traversable routing algorithm is composed of three procedures: time synchronization, route discovery and data delivery. A time synchronization message is a message to share a specific time in network to achieve time synchronization in the network. Hello messages are exchanged among neighbors and have three meanings; 1) To notify the neighboring nodes in the same network of a nodes' information, 2) To evaluate the link cost metric for the neighbors, and 3) To exchange the current encryption key. The notification of a nodes' information indicates what kind of node this is and how much each node has for an evaluation value. Each node evaluates a link cost by exchanging both radio field strength (e.g., RSSI) and periodical variance (of RSSI?) through the Hello message. This link cost is one of parameters of the overall cost function. Each node has its own encryption key and encrypts data by using this encryption key. The Data message has two kinds of messages: with an ACK and without an ACK. Each node must return an ACK message to the Local SRC which sends a data message including an ACK requirement. 5. Node Operation All messages exchanged between nodes have an Ad Hoc header(See 6.1. ). When a node receives a message from another node, it processes the message according to the frame type in its Ad Hoc header. Iwao, et al. Expires January 2, 2010 [Page 7] Internet-Draft DADR Protocol July 2009 5.1. Time Synchronization Message First of all, a node which joins a network must synchronize a present time which other nodes consisting of the network already have. Because Hello Messages are encrypted by using both the time and a cryptographic seed (see Error! Reference source not found.), a node which doesn't have the both can not attend the network. In Ad Hoc networks, forwarding the present time from node to node is not a successful method to share a specific time among nodes. Figure 1 shows an example of failure to adjust the time of node i only with a present time. In this example, node i misunderstands 11:20 is the newest even though it is older than the time from node e. To solve this problem, each node sends a Time Synchronization Message consisting of a pair of times, present time and synchronized time, periodically (e.g. once per hour). Figure 2 shows a successful example. A node checks synchronized time before adjusting a present time. Time Synchronization Message processing is shown as follows. Upon receipt of a synchronization message, a node will compare the Synchronized time of its own clock with the synchronized time in the message. If the synchronized time in the received message is older(past)than the clock maintained at this node, discard the message. If the synchronized time in the received message is newer, adjust both the present time and the synchronized time in the node to those in the Synchronization Message. As shown in Figure 2, node i can adjust to the newer time successfully. Present time: time when a node sends the message Synchronized time: time when synchronized by a master clock Iwao, et al. Expires January 2, 2010 [Page 8] Internet-Draft DADR Protocol July 2009 +------+ |node a|(ntp or gateway) +------+ 10:00/ \ 11:00 +------+ +------+ |node b| |node e| +------+ +------+ 10:20 | | 11:02 +------+ +------+ |node c| |node i| -----> 11:20 +------+ +------+ 10:40 | / +------+ / 11:20 |node d|----/ +------+ Figure 1 Synchronizing time only with a present time (not successful) +------+ |node a|(ntp or gateway) 10:00 +------+ 11:00 10:10 / \ 11:01 +------+ +------+ |node b| |node e| 10:00 +------+ +------+ 11:00 10:20 | | 11:02 +------+ +------+ 11:00 |node c| |node i| ----> 11:02 10:00 +------+ +------+ 10:40 | / 10:00 +------+ / 11:20 |node d|----/ +------+ upper line: synchronization time lower line: present time Figure 2 Synchronizing time with synchronization time and a present time (successful) Iwao, et al. Expires January 2, 2010 [Page 9] Internet-Draft DADR Protocol July 2009 5.2. Hello Message o Each node sends a Hello Message to neighboring nodes periodically (e.g. at an interval of one minute). Link Table: 1. Register several parameters connected with Local SRC Address in the Hello Messages. 2. Initialize TTL (e.g. 6 hours) for this table entry. Routing Table: 3. Register Global DST Address as it is, if it reaches in one hop. 4. Register Global DST Address as Local DST Address if it reaches over one hop. 5. Calculate Evaluated Value with the evaluation function. Iwao, et al. Expires January 2, 2010 [Page 10] Internet-Draft DADR Protocol July 2009 5.3. Data and Data ACK Message This section describes the process of sending a Data message and handling of Data ACK message, if applicable. 1. Look up the FID of the message in the Data Management table. 2. If the entry is not found, find out a candidate next hop which has the best evaluated value among neighboring nodes in the Routing table for the global destination. 3. If the entry is found, update the Routing table, because this means retransmission has occurred. 4. Data messages may be sent with ACK response request. If ACK response is not required go to step 6 to end. 5. Wait for ACK when sending a message which requires ACK response. 6. End of procedure Iwao, et al. Expires January 2, 2010 [Page 11] Internet-Draft DADR Protocol July 2009 6. Message Formats 6.1. Ad Hoc Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Local DST Address (6) +-------------------------------+ | | | +-------------------------------+ Local SRC Address (6) | | | +---------------+-------------------------------+---------------+ | Frame Type(1) | Frame Length (2) | +---------------+-------------------------------+ Local DST Address: MAC Address Local DST Address: MAC Address Frame Type: LSB 1-4 Bit Message Identifier number message type ------------------------------ 1 Hello Message 2 Data Message 3 Data ACK Message 4 Time Synchronization Message 5 Hello Request Message 6 Hello Response Message Bit 6 Gateway information (1: From Gateway, 0: otherwise) Bit 7 Data ACK information (1: ACK request, 0: otherwise) Frame Length: Payload Length after Ad Hoc Header Iwao, et al. Expires January 2, 2010 [Page 12] Internet-Draft DADR Protocol July 2009 6.2. Time Synchronization Message Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Ad Hoc Header(15) +---------------+ | | Hop Count (1) | +---------------+-------------------------------+---------------+ | Frame Type (1)| Reserve (2) | | +---------------+-------------------------------+ + | | + NTP Time (8) +---------------+ | | | +-----------------------------------------------+ + | | + Sent Time (8) +---------------+ | | +-----------------------------------------------+ NTP Time: Sent Time: Iwao, et al. Expires January 2, 2010 [Page 13] Internet-Draft DADR Protocol July 2009 6.3. Hello Message Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Ad Hoc Header(15) +---------------+ | | | +-----------------------------------------------+ + | | ~ Hello Message Header (28) +---------------+ | | | +-----------------------------------------------+ ~ | Hello Header 1(16) | ~ +-----------------------------------------------+ | | +---------------+ : : +---------------+ | | +-----------------------------------------------+ ~ | Hello Header n(16) | ~ +-----------------------------------------------+ | | | +---------------+ Signature (8) + | | + +-----------------------------------------------+ | | +---------------+ Signature is an 8-byte hash value of the contents of the Hello message?? Iwao, et al. Expires January 2, 2010 [Page 14] Internet-Draft DADR Protocol July 2009 Hello Message Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Service Type(1)|Frame Page (1) | number of Hello Headers (2) | +---------------+---------------+-------------------------------+ | | ~ Access Key (16) ~ | | +---------------------------------------------------------------+ Service Type: number meaning ----------------------- 1 Hello All 2 Hello Update Frame Page: sequential number of Hello Message 6.4. Hello Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Global DST Address (6) +---------------+---------------+ | |Node/Hop Count | Reserve (1) | +-------------------------------+---------------+---------------+ | Link Quality (4) | +---------------------------------------------------------------+ | Return Path Quality (4) | +---------------------------------------------------------------+ Where Node/Hop Count is ?, Link Quality is ? and Return Path Quality is ?. Iwao, et al. Expires January 2, 2010 [Page 15] Internet-Draft DADR Protocol July 2009 Data Frame Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Ad Hoc Header(15) +---------------+ | | | +---------------+-------------------------------+ ~ | Data Header (20) | ~ +-----------------------------------------------+ | | | +---------------+ Payload ~ | | ~ ~ | | +---------------------------------------------------------------+ | | ~ Signature (16) ~ | | +---------------------------------------------------------------+ Iwao, et al. Expires January 2, 2010 [Page 16] Internet-Draft DADR Protocol July 2009 6.5. Data Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Global DST Address (6) +-------------------------------+ | | | +-------------------------------+ Global SRC Address (6) + | | +-------------------------------+---------------+---------------+ | Frame ID (2) | HTL (1) | Send Count(1) | +---------------+---------------+---------------+---------------+ | Data Type (1) |Retry Count(1) | +---------------+---------------+ Frame ID: HTL: ? Data Type:? Retry Count:? Signature is a 16-byte hash of the data message??? 6.6. Data ACK Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Ad Hoc Header(15) +---------------+ | | | +---------------+-------------------------------+ ~ | Data ACK Header (28) | ~ +-----------------------------------------------+ | | +---------------+ 6.7. Data ACK Header Format 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 Iwao, et al. Expires January 2, 2010 [Page 17] Internet-Draft DADR Protocol July 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame ID (2) | | +---------------+---------------+ Global SRC Address (6) + | | +---------------------------------------------------------------+ where Frame ID is a 2-byte ID of the frame that is unique. Iwao, et al. Expires January 2, 2010 [Page 18] Internet-Draft DADR Protocol July 2009 7. Table Formats 7.1. Routing Table format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Global DST Address (6) +-------------------------------+ | | | +-------------------------------+ Local DST Address 1(6) + | | +---------------+---------------+-------------------------------+ |Link Weight(1) | Hop Count(1) | Path Quality (4) ~ +---------------+---------------+-------------------------------+ ~ | Evaluated Value (4) ~ +-------------------------------+-------------------------------+ ~ + RSSI (4) ~ +-------------------------------+-------------------------------+ ~ | | +-------------------------------+ Local DST Address 2(6) + | | +---------------+---------------+-------------------------------+ |Link Weight(1) | Hop Count(1) | Path Quality (4) ~ +---------------+---------------+-------------------------------+ ~ | Evaluated Value (4) ~ +-------------------------------+-------------------------------+ ~ + RSSI (4) ~ +-------------------------------+-------------------------------+ ~ | | +-------------------------------+ Local DST Address 3(6) + | | +---------------+---------------+-------------------------------+ |Link Weight(1) | Hop Count(1) | Path Quality (4) ~ +---------------+---------------+-------------------------------+ ~ | Evaluated Value (4) ~ +-------------------------------+-------------------------------+ ~ + RSSI (4) ~ +-------------------------------+-------------------------------+ ~ + +-------------------------------+ Iwao, et al. Expires January 2, 2010 [Page 19] Internet-Draft DADR Protocol July 2009 7.2. Data Management Table format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL (1) | TTW (1) | FLAG (1) |Retry Count (1)| +---------------+---------------+---------------+---------------+ | | ~ Data Header (28) ~ | | +---------------------------------------------------------------+ | | + Local SRC Address (6) +-------------------------------+ | | | +-------------------------------+ Local DST Address 1 (6) + | | +---------------------------------------------------------------+ | | + Local DST Address 2 (6) +------------------------------+ | | | +--------------------------------+ Local DST Address 3 (6) + | | +---------------------------------------------------------------+ TTL: Time to live TTW: Time to wait for Data ACK Retry Count: Count of sending Data ACK request 7.3. Link Table format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Local DST Address (6) +---------------+---------------+ | | Path Quality | TTL (1) | +---------------+---------------+---------------+---------------+ | Transmitting | Receiving | | Quality (1) | Quality (1) | +---------------+---------------+ Iwao, et al. Expires January 2, 2010 [Page 20] Internet-Draft DADR Protocol July 2009 8. Security Considerations In a DADR network, it is possible to provide security among nodes without any central controls. To this end, two kinds of keys, a common key and an access key are required shown in Error! Reference source not found.. The common key is the same for all nodes. However it is generated in each node by using a system-specific algorithm with a cryptographic seed (e.g. stored and executed in a tamper-resistant device) and a present time (T2). It changes at relatively longer intervals (e.g. 12 hours). The access key is different for each node. It is also periodically generated in each node, for example every 10 minutes. The nodes exchange their access keys via Hello Messages encrypted by the common key. The nodes add a hash value of the message as a signature at the end of the message. The nodes are resistant to the following attacks: o Packet snooping is difficult because messages among nodes are encrypted by different access keys for each node and the nodes change their own keys within a short time(e.g. 10 minutes). o Disguise and falsification of messages can be detected by checking a signature in a message. o Denial of Service(DoS)and replay attacks are rejected by checking FID and its received time. 9. IANA Considerations 10. Conclusions 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Iwao, et al. Expires January 2, 2010 [Page 21] Internet-Draft DADR Protocol July 2009 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC5548] M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC5548, May 2009. 11.2. Informative References [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 1583. [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. 12. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Iwao, et al. Expires January 2, 2010 [Page 22] Internet-Draft DADR Protocol July 2009 Appendix A. First Appendix A.1. First Header level Text Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This code was derived from IETF RFC [insert RFC number]. Please reproduce this note if possible. Iwao, et al. Expires January 2, 2010 [Page 23] Internet-Draft DADR Protocol July 2009 Authors' Addresses Questions about this memo can be directed to: Tadashige Iwao, Kentaro Ikemoto, Kenji Yamada, Yuji Takahashi, Shunsuke Koga, Yuta Nakaya, and Sung Lee FUJITSU LIMITED Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku, Tokyo 105-7123,Japan Phone. +81-3-6252-2283 Email: smartnetpro-iwao_std@ml.css.fujitsu.com Iwao, et al. Expires January 2, 2010 [Page 24]