idnits 2.17.1 draft-montenegro-6lowpan-dymo-low-routing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 785. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2007) is 6148 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipv6-2461bis' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-rfc2462bis' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'AODVjr' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipngwg-icmp-v3' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'I-D.perkins-manet-aodvbis' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'KW03' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC3439' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'TinyAODV' is defined on line 700, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- No information found for draft-ietf-6lowpan-format - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6lowpan-format' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4' -- No information found for draft-perkins-manet-aodvbis - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Kim, Ed. 3 Internet-Draft picosNet Corp/Ajou Univ. 4 Intended status: Standards Track G. Montenegro 5 Expires: December 21, 2007 Microsoft Corporation 6 S. Park, Ed. 7 Mobile Platform Laboratory, 8 SAMSUNG Electronics 9 I. Chakeres 10 Boeing Phantom Works, The Boeing 11 Company 12 C. Perkins 13 Nokia Research Center 14 June 19, 2007 16 Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing 17 draft-montenegro-6lowpan-dymo-low-routing-03 19 Status of This Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 21, 2007. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 This document specifies how to use the Dynamic MANET On-demand 51 Routing Protocol over IEEE802.15.4 networks. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Simplifications for DYMO over IEEE 802.15.4 . . . . . . . 4 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 5 62 3.2. DYMO-low Messages . . . . . . . . . . . . . . . . . . . . 6 63 3.2.1. DYMO-low Routing Messages . . . . . . . . . . . . . . 6 64 4. Detailed operation . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. DYMO-low Routing Table Operations . . . . . . . . . . . . 9 66 4.1.1. Creating or Updating a Route Table Entry from New 67 Routing Information . . . . . . . . . . . . . . . . . 9 68 4.1.2. Route Table Entry Timeouts . . . . . . . . . . . . . . 10 69 4.2. Routing message . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. Routing message creation . . . . . . . . . . . . . . . 10 71 4.2.2. Routing message Processing . . . . . . . . . . . . . . 10 72 4.3. Energy-aware Route Discovery . . . . . . . . . . . . . . . 11 73 4.4. Route Maintenance . . . . . . . . . . . . . . . . . . . . 12 74 4.4.1. Monitoring of Active Links . . . . . . . . . . . . . . 12 75 4.4.2. Updating Route Lifetimes . . . . . . . . . . . . . . . 12 76 4.4.3. Route Error Generation . . . . . . . . . . . . . . . . 12 77 4.5. General DYMO-low Processing . . . . . . . . . . . . . . . 12 78 4.5.1. DYMO-low Processing . . . . . . . . . . . . . . . . . 12 79 4.5.2. DYMO-low Control Packet Transmission . . . . . . . . . 13 80 4.6. Packet Generation Limits . . . . . . . . . . . . . . . . . 13 81 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 13 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 The IEEE 802.15.4 standard [IEEE802.15.4] targets low power personal 92 area networks. The "IPv6 over IEEE 802.15.4" document [I-D.ietf- 93 6lowpan-format] defines basic functionality required to carry IPv6 94 packets over IEEE 802.15.4 networks (including an adaptation layer, 95 header compression, etc). Likewise, as mesh topologies are expected 96 to be common in LoWPAN networks, the functionality required for 97 packet delivery in IEEE 802.15.4 meshes is defined. However, neither 98 the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4" 99 specification provide any information as to how such a mesh topology 100 could be obtained and maintained. 102 This document specifies how to use the Dynamic MANET On-demand 103 Routing Protocol (DYMO) [I-D.ietf-manet-dymo] over IEEE 802.15.4 104 networks to provide mesh routing. To distinguish this instantiation 105 of the protocol from DYMO over IPv4 and DYMO over IPv6, the label 106 "DYMO-low" is used in this document. Given the very stringent 107 limitations of the target devices, this document specifies 108 simplifications that are recommended to the base DYMO specification. 110 1.1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Overview 118 The addresses used in DYMO-low control messages are either 16 bit 119 link layer short address or IEEE 64-bit extended addresses [EUI64]. 120 Additionally, it should be noted that as used in this specification, 121 DYMO-low is not layered on top of IP, but underneath it. It is an 122 underlay. As such, it creates a mesh network topology of IEEE 123 802.15.4 devices that use single wireless interface each, underneath 124 and unbeknownst to IP. IP sees a PAN as a single link. This is 125 similar to how other technologies regularly create complex structures 126 underneath IP (e.g., ethernet spanning tree bridges, token ring 127 source routing, ATM, etc). One can envision a sub-IP mesh creating 128 the illusion that all the devices on that PAN are on the same IPv6 129 link (sharing the same IPv6 prefix). At the same time, normal usage 130 of DYMO (above IP) could tie together several such "links" 131 (potentially using different technologies for each) into a larger 132 mesh. 134 DYMO over IPv4 makes use of broadcast in its route discovery. It 135 does so in order to propagate the Route Request control packets 136 (RREQs). In this specification, such broadcast packets are obtained 137 by setting the PAN id to the broadcast PAN (0xffff) and by setting 138 the link layer destination address to the broadcast short address 139 (0xffff) DYMO-low control packets use the encapsulation defined in 140 [I-D.ietf-6lowpan-format]. All DYMO-low control packets shall use 141 the prot_type value TBD (suggested value of 5). This prot_type is 142 used to send DYMO-low messages in a manner similar to how DYMO uses a 143 properly assigned UDP port. 145 2.1. Simplifications for DYMO over IEEE 802.15.4 147 This section specifies simplifications and distinctive features of 148 DYMO-low compared to the base DYMO. 150 DYMO allows for minimalist implementations by specifying non- 151 essential functionality as optional [I-D.ietf-manet-dymo]. In 152 keeping with DYMO, DYMO-low implements the routing message(RM) which 153 provides both the RREQ (route request) and the RREP (route reply). 154 Furthermore, the RERR (route error) message is implemented while UERR 155 (unsupported message error) message is obviated for simplicity. 156 DYMO-low has the following characteristics: 158 o RREQ messages are transmitted as IEEE 802.15.4 broadcast messages 159 to reach all the next hop neighbors. DYMO packets SHOULD NOT be 160 fragmented. 162 o Only the final destination SHOULD respond to a RREQ by replying 163 with a RREP. 165 o Link quality (LQI) of IEEE 802.15.4 [IEEE802.15.4] in addition to 166 the route cost is utilized for selecting best route to the 167 destination. 169 o Hello messages are not used. Instead, the IEEE 802.15.4 170 acknowledgement mechanism is used to determine if a neighbor is no 171 longer responsive. This information is obtained when transmitting 172 a packet with acknowledgement option turned on. 174 o Due to space limitations, nodes SHOULD append only one unreachable 175 destination in RERR. 177 o Sequence numbers are used for loop freedom. The size of the 178 sequence number field is reduced from 32 bits to 16 bits for 179 simplification. 181 o The transmission method for RREQ and RERR messages in DYMO is 182 link-local multicast.However, considering the energy-constrained 183 nature of 6lowpan, some efficient mechanisms other than broadcast 184 are necessitated in DYMO-low (TBD). 186 2.2. Terminology 188 Link Layer Destination Address (LinkLayerDestinationAddress) 190 The 16 bit short or EUI-64 link layer address of the destination in 191 the MAC layer. It is also called as the next-hop destination during 192 hop-by-hop forwarding of packets. 194 Link Layer Source Address (LinkLayerSourceAddress) 196 The 16 bit short or EUI-64 link layer address of the source in the 197 MAC layer. It is also called as the previous-hop source address 198 during hop-by-hop forwarding of packets. 200 Broadcast 202 A broadcast in 6lowpan implies link-local multicast in IEEE 802.15.4 203 MAC layer. This can be done by setting the link layer destination 204 field to 0xffff. 206 Valid Route 208 A known route where the Route.ValidTimeout timer is not set to the 209 current time. 211 3. Data Structures 213 3.1. Route Table Entry 215 The route table entry is a conceptual data structure. 216 Implementations may use any internal representation that conforms to 217 the semantics of a route as specified in this document. 219 Route Destination Address (Route.DestAddress) 221 The 16 bit short or EUI-64 link layer address of the final 222 destination of a route. 224 Route Delete Timeout (Route.DeleteTimeout) 226 If the current time is after Route.DeleteTimeout the corresponding 227 routing table entry MUST be deleted and the timer associated with 228 this entry are reset. 230 Route Cost (Route.RouteCost) 232 Cumulative cost metric used for allowing a node to select an optimum 233 route to the final destination. 235 Route Next Hop Address (Route.NextHopAddress) 237 The 16 bit short or EUI-64 link layer address of the next-hop node on 238 the path toward the final destination. 240 Route.ValidTimeout 242 The time at which a route table entry is scheduled to be invalidated. 243 The routing table entry is no longer considered valid when the timer 244 is set after Route.ValidTimeout, and Route.DeleteTimeOut is set. 246 3.2. DYMO-low Messages 248 DYMO-low messages are categorized either as a Routing Message (RM) or 249 a Route Error (RERR) message. 251 3.2.1. DYMO-low Routing Messages 253 A RM can be either a Route Request (RREQ) message or a Route Reply 254 (RREP) message. These messages are very similar in information but 255 vary in the way of their processing. 257 3.2.1.1. DYMO-low Route Request (RREQ) and Route Reply (RREP) messages 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | TTL |T|O|S|C|A| CT | RREQ ID | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |TRouteCost(opt)| TargetAddress (optional) / 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | OriginatorAddress / 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1 271 Message Type (Type) The following is the list of the currently 272 available message types. 274 Type Value 275 -------------------------------- ----- 276 Routing Message (RM) 1 277 Route Error (RERR) 2 279 Time To Live (TTL) 280 8-bit field that identifies the maximum number of times the message 281 is to be retransmitted. 283 Target (T-bit) 285 1 for the 16-bit address of the target. 287 0 for the EUI-64 address of the target. 289 Originator (O-bit) 291 1 for the 16-bit address of the Source. 293 0 for the EUI-64 address of the Source. 295 Solicited/Unsolicited (S-bit) 297 Route discovery is desired (solicited) if S is set. The 298 TargetAddress is only present if S is set. If S is unset (ie, zero), 299 it allows nodes to disseminate unsolicited & undirected routing 300 information. 302 Coordinator (C-bit) 304 1 if the node generating DYMO message is a PAN Coordinator (PC). 305 Allows priority routing (TBD) to node if it is a PC 0 if the node 306 generating this message is a not PC (TBD) 308 A-bit (A) 310 1-bit selector indicating whether this RM requires a RREP by the 311 TargetAddress. If A=1 the RM is a RREQ and needs a RREP. 313 Cost Type (CT) 315 3-bits of CT are currently defined as: 317 0: Hop count 319 1-0xf: TBD 321 RREQ ID 323 An identifier that uniquely identifies the particular RREQ when taken 324 in conjunction with the originator. It serves two purposes, i) It 325 allows intermediate nodes to process the RREQ message once and ii) It 326 matches a unique RREP message against unique RREQ in the wake of 327 multiple RREQ generation. 329 Target Address (TargetAddress) - (Optional) 331 The node that is the ultimate destination of the message. This field 332 is only required if the LinkLayerDestinationAddress is not the 333 BroadcastAddress. TargetAddress is present if the S-bit is set. For 334 RREQ the TargetAddress is the desired destination, the destination 335 for which a valid route does not exist. For RREP the TargetAddress 336 is the RREQ originator. During hop-by-hop transmission of a DYMO-low 337 packet the LinkLayerDestinationAddress is filled with the 338 Route.NextHopAddress of the route table entry associated with the 339 TargetAddress. In case S-bit is unset,the message is neither a RREQ 340 nor a RREP. It can be used an unsolicited routing informational 341 message. 343 Target Route Cost (TRouteCost) - (Optional) 345 8-bit field that identifies the routing cost across the number of 346 intermediate nodes through which a packet traversed on the route to 347 this particular TargetAddress. 349 Originator Address (OriginatorAddress) 351 The node that is the originator of routing message. In RREQ message, 352 the OriginatorAddress is the node that generates RREQ message. In 353 RREP, the OriginatorAddress is the node that replies to RREQ. 355 3.2.1.2. Route Error (RERR) 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | TTL |T|O|U|C|A| TargetAddress / 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | OriginatorAddress / 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | UnreachableNodeAddress / 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 2 368 U-bit (T) 370 1 for the 16-bit address of UnreachableNodeAddress. 372 0 for the EUI-64 address of UnreachableNodeAddress. 374 UnreachableNodeAddress 375 The 16-bit short or EUI-64 link layer address of the node that has 376 become unreachable. 378 OriginatorAddress 380 The 16-bit short or EUI-64 link layer address of the node that 381 generates the RERR message. 383 Target Node Address (TargetAddress) 385 The 16-bit short or EUI-64 link layer address of the node that is the 386 destination of the RERR message. 388 4. Detailed operation 390 4.1. DYMO-low Routing Table Operations 392 4.1.1. Creating or Updating a Route Table Entry from New Routing 393 Information 395 While processing a RM, as described in Section 4.2.2, a node checks 396 its routing table for an entry to the OriginatorAddress in the RREQ. 397 If a valid route exists to TargetAddress, the route can be used to 398 send any queued data packets and to fulfill any outstanding route 399 requests. 401 In the event that no matching entry is found, an entry is created. 403 If a matching entry is found, the routing information about 404 OriginatorAddress contained in this RM is considered stale if the 405 TRouteCost is greater than Route.RouteCost. 407 If there exists a route AND the TRouteCost is equal to the 408 Route.RouteCost in this RM, the information is not stale, but the 409 routing information SHOULD be disregarded and no routing update 410 should occur. 412 If the information in this RM is stale or disregarded this DYMO-low 413 packet MUST be dropped. If the route information for Originator is 414 not stale or disregarded, then the following actions occur to the 415 route table entry for OriginatorAddress: 417 1. the Route.RouteCost is set to the TRouteCost, 419 2. the Route.NextHopAddress is set to the node that transmitted this 420 DYMO-low packet (LinkLayerSourceAddress), 422 3. and the Route.ValidTimeout is set to the current time + 423 ROUTE_TIMEOUT. If a valid route exists to TargetAddress, the route 424 can be used to send any queued data packets and to fulfill any 425 outstanding route requests. 427 4.1.2. Route Table Entry Timeouts 429 If the current time is later than a routing entry's 430 Route.ValidTimeout, the route is stale and it is not to be used to 431 route packets. The information in invalid entries is still used for 432 generating RREQ messages. If the current time is after 433 Route.DeleteTimeout the corresponding routing table entry MUST be 434 deleted. 436 4.2. Routing message 438 4.2.1. Routing message creation 440 When a node creates a RREQ or RREP, it MUST create the RM. It sets 441 the OriginatorAddress to its own address. 443 4.2.2. Routing message Processing 445 After the general DYMO-low message pre-processing (Section 4.5.2), 446 the Routing message is processed to yield the route cost TRouteCost. 447 That is, the route cost TRouteCost is said to be better (or 448 equivalently smaller) than or equal to (Route.RouteCost') if the 449 following condition holds (Note that the apostrophe refers to 450 Route.RouteCost i.e., an already existing route entry in the routing 451 table) 453 TRouteCost < = Route.RouteCost' 455 If a matching entry to the OriginatorAddress in the routing message 456 is found in the routing table, the routing information about 457 OriginatorAddress contained in this routing message is considered 458 stale if TRouteCost is greater than the Route.RouteCost'. If the 459 information in this routing message is stale or disregarded this 460 DYMO-low packet MUST be dropped. 462 If there exists a route AND equal the information is not stale, then 463 the routing information SHOULD be disregarded and no routing update 464 should occur. If the route information for OriginatorAddress is not 465 stale or disregarded,then the following actions occur to the route 466 table entry for OriginatorAddress: 468 1. the Route.RouteCost is set to the TRouteCost, 470 2. the Route.NextHopAddress is set to the node that transmitted this 471 DYMO-low packet (LinkLayerSourceAddress), 473 3. and the Route.ValidTimeout is set to the current time + 474 ROUTE_TIMEOUT. 476 If this node is the TargetAddress AND the A-bit is set (A=1), this 477 node MUST respond with a RREP. The target node creates a new RM as 478 described in Section 4.2.1. The TargetAddress in the new RM is set 479 to the OriginatorAddress from the RM currently being processed. The 480 A-bit is set to (A=0). The LinkLayerDestinationAddress is set to the 481 Route.NextHopAddress for the TargetAddress. Then the new RM 482 undergoes post-processing, according to Section 4.5.3. If this node 483 is not the TargetAddress, the current RE SHOULD be handled according 484 to Section 4.5.4. 486 If this node is the TargetAddress, the current packet and any 487 additional elements are processed, but this packet is not 488 retransmitted. 490 4.3. Energy-aware Route Discovery 492 A node generates a Route Request (RREQ) to discover a valid route to 493 a particular destination (TargetAddress). A RREQ is a RM with the 494 A-bit is set to one (A=1) to indicate that the TargetAddress must 495 respond with a RREP. The LinkLayerDestinationAddress is set to the 496 BroadcastAddress. The RM is then transmitted according to the 497 procedure defined in Section 4.5.4. After issuing a RREQ, the 498 originating node waits for a route to be created to the 499 TargetAddress. If a RREP is not received within RREQ_WAIT_TIME 500 milliseconds, this node MAY again try to discover a route by issuing 501 another RREQ. An intermediate node that receives RREQ message may 502 agree broadcast it right away only if its energy level permits so. 503 Otherwise, such an energy starved node (shown in Fig. 3) may delay 504 the broadcast of RREQ message by the time factor 'INDELAY' (where the 505 notation is intended to represent induced delay) so that other nodes 506 with relatively more energy form the routing path for the 507 TargetAddress. The methods to adjust the value of INDELAY is TBD. 508 To reduce congestion in a network, repeated attempts at route 509 discovery for a particular TargetAddress SHOULD utilize a binary 510 exponential backoff. The first time a node issues a RREQ, it waits 511 RREQ_WAIT_TIME milliseconds for a route to the TargetAddress. If a 512 route is not found within that time, the node MAY send another RREQ. 513 If a route is not found within two (2) times the current waiting 514 time, another RREQ may be sent, up to a total of RREQ_TRIES. For 515 each additional attempt, the waiting time for the previous RREQ is 516 multiplied by two (2) so that the waiting time conforms to a binary 517 exponential backoff. Data packets awaiting for a route MAY be 518 buffered. If a route discovery has been attempted RREQ_TRIES times 519 without receiving a route to the TargetAddress, all data packets 520 destined to the corresponding TargetAddress SHOULD be dropped from 521 the buffer. 523 4.4. Route Maintenance 525 4.4.1. Monitoring of Active Links 527 Before a route can be used for forwarding a packet, it MUST be 528 checked to make sure that the route is still valid. If the 529 Route.ValidTimeout is earlier than the current time, the packet 530 cannot be forwarded, and a RERR message MUST be generated (seesection 531 4.4.3). In this case, the Route.DeleteTimeout is set to 532 Route.ValidTimeout + ROUTE_DELETE_TIMEOUT. If the current time is 533 after Route.DeleteTimeout, then the route SHOULD be deleted, though a 534 route MAY be deleted at any time. Upon detecting a link break the 535 detecting node MUST set the Route.ValidTimeout to the current time 536 for all active routes utilizing the broken link. A RERR MUST be 537 issued if a data packet is received and it cannot be delivered to the 538 next hop. RERR generation is described in Section 4.4.3. A RERR 539 SHOULD be issued after detecting a broken link of an active route to 540 quickly notify nodes that a link break occurred and a route or routes 541 are no longer available. 543 4.4.2. Updating Route Lifetimes 545 To avoid route timeouts for active routes, a node SHOULD update the 546 Route.ValidTimeout to the final destination address[I-D.ietf-6lowpan- 547 format] to be the current time + ROUTE_TIMEOUT upon successfully 548 transmitting a packet to the next hop. 550 4.4.3. Route Error Generation 552 When a data packet is received for a destination without a valid 553 routing table entry, a Route Error (RERR) MUST be generated by this 554 node. A RERR informs the source that the current route is no longer 555 available. In the RERR, the TargetAddress field is the address of 556 the unreachable node (final destination address) from the data 557 packet. The setting of theL inkLayerDestinationAddress of the RERR 558 and the RERR processing at the receiving node are TBD. 560 4.5. General DYMO-low Processing 562 4.5.1. DYMO-low Processing 564 The Routing Message (RM) MUST be processed completely prior to any 565 transmissions. Unless specific message processing requires dropping 566 the DYMO-low packet, it is retransmitted after processing, according 567 to the method described in Section 4.5.4. 569 4.5.1.1. Routing Message Pre-processing 571 The RM in a DYMO-low packet undergoes pre-processing before the 572 message specific processing occurs. During pre-processing, the TTL 573 is decremented by one (1). 575 4.5.1.2. Routing Message Post-processing 577 If the TTL is zero (0) the DYMO-low packet is dropped. If the TTL is 578 greater than zero the DYMO-low packet is re-transmitted after 579 processing of all messages. If the TTL of Routing Message (RM) is 580 zero (0) after processing, it MUST be removed from the DYMO-low 581 packet prior to transmission. 583 4.5.2. DYMO-low Control Packet Transmission 585 DYMO-low packet transmission and re-transmission is controlled by the 586 LinkLayerDestinationAddress. If the LinkLayerDestinationAddress is a 587 unicast address, the packet LinkLayerDestinationAddress is replaced 588 by the Route.NextHopAddress from a route table lookup for the 589 TargetAddress. If a route for the TargetAddress is unknown or 590 invalid the packet is dropped and a RERR SHOULD be generated. 592 4.6. Packet Generation Limits 594 To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT 595 control messages per second. RREQ packets SHOULD be discarded before 596 RREP or RERR packets. 598 5. Configuration Parameters 600 Here are some default parameter values for DYMO-low: 602 Parameter Name Suggested Value 603 --------------------------- --------------- 604 NET_DIAMETER 256 605 RATE_LIMIT 2 606 ROUTE_TIMEOUT 10 minutes 607 ROUTE_DELETE_TIMEOUT 2*ROUTE_TIMEOUT 608 RREQ_WAIT_TIME 1000 milliseconds 609 RREQ_TRIES 2 611 6. IANA Considerations 613 This document needs an additional IANA registry for the prot_type 614 value that indicates the DYMO-low format. 616 7. Security Considerations 618 The security considerations of the [RFC3561] are applicable to this 619 document. As described in the charter of the 6lowpan w.g., DYMO-low 620 will also try to reuse existing security considerations related to Ad 621 hoc routing protocols. Further considerations will be studied in the 622 next version. 624 8. Acknowledgements 626 Thanks to Ali Hammad Akbar, Seung-Wha Yoo, Byeong-Hee Roh, Shafique 627 Ahmad Chaudhry, Hee-Jung Kim and Hamid Mukhtar for their useful 628 discussions and supports for writing this document. 630 9. References 632 9.1. Normative References 634 [EUI64] 802.15.4-2003, IEEE Standard., 635 "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER 636 (EUI-64) REGISTRATION AUTHORITY". 638 [I-D.ietf-ipv6-2461bis] T., Narten., "Neighbor Discovery for IP 639 version 6 (IPv6)", May 2005. 641 [I-D.ietf-ipv6-rfc2462bis] S., Thomson., "IPv6 Stateless Address 642 Autoconfiguration", May 2005. 644 [I-D.ietf-manet-dymo] I., Chakeres., "Dynamic MANET On-demand 645 (DYMO) Routing", May 2007. 647 [I-D.ietf-6lowpan-format] N., Kushalnagar., Montenegro, G., Hui, 648 J., and D. Culler, "6LoWPAN: 649 Transmission of IPv6 Packets over IEEE 650 802.15.4 Networks", February 2007. 652 [RFC2119] Bradner, S., "Key words for use in RFCs 653 to Indicate Requirement Levels", BCP 14, 654 RFC 2119, March 1997. 656 [RFC2434] Narten, T. and H. Alvestrand, 657 "Guidelines for Writing an IANA 658 Considerations Section in RFCs", BCP 26, 659 RFC 2434, October 1998. 661 [RFC2460] Deering, S. and R. Hinden, "Internet 662 Protocol, Version 6 (IPv6) 663 Specification", RFC 2460, December 1998. 665 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 666 Addressing Architecture", RFC 4291, 667 February 2006. 669 [IEEE802.15.4] 802.15.4-2003, IEEE Standard., "Wireless 670 medium access control and physical layer 671 specifications for low-rate wireless 672 personal area networks.", May 2003. 674 9.2. Informative References 676 [AODVjr] I., Chakeres. and Klein-Berndt. Luke, 677 "AODVjr, AODV Simplified", July 2002. 679 [I-D.ietf-ipngwg-icmp-v3] A., Conta., "nternet Control Message 680 Protocol (ICMPv6) for the Internet 681 Protocol Version 6 (IPv6) 682 Specification", July 2005. 684 [I-D.perkins-manet-aodvbis] C., Perkins., "Ad hoc On-Demand Distance 685 Vector (AODV) Routing", February 2004. 687 [KW03] C., Karlof. and Wagner. D., "Secure 688 Routing in Sensor Networks: Attacks and 689 Countermeasures", September 2003. 691 [RFC3439] Bush, R. and D. Meyer, "Some Internet 692 Architectural Guidelines and 693 Philosophy", RFC 3439, December 2002. 695 [RFC3756] Nikander, P., Kempf, J., and E. 696 Nordmark, "IPv6 Neighbor Discovery (ND) 697 Trust Models and Threats", RFC 3756, 698 May 2004. 700 [TinyAODV] ., TinyOS Source Code Repository., 701 "TinyAODV Implementation". 703 [RFC3561] Perkins, C., Belding-Royer, E., and S. 704 Das, "Ad hoc On-Demand Distance Vector 705 (AODV) Routing", RFC 3561, July 2003. 707 Authors' Addresses 709 Kim, Ki Hyung (editor) 710 picosNet Corp/Ajou Univ. 711 San 5 Wonchun-dong, Yeongtong-gu 712 Suwon-si, Gyeonggi-do 442-749 713 KOREA 715 Phone: +82 31 219 2433 716 EMail: kkim86@picosnet.com 718 Gabriel Montenegro 719 Microsoft Corporation 721 Soohong Daniel Park (editor) 722 Mobile Platform Laboratory, SAMSUNG Electronics 723 416 Maetan-3dong, Yeongtong-gu 724 Suwon-si, Gyeonggi-do 442-742 725 KOREA 727 Phone: +82 31 200 4508 728 EMail: soohong.park@samsung.com 730 Ian Chakeres 731 Boeing Phantom Works, The Boeing Company 732 P.O. Box 3707 Mailcode 7L-49 733 Seattle, WA 98124-2207 734 USA 736 EMail: ian.chakeres@gmail.com 738 Charlie Perkins 739 Nokia Research Center 740 313 Fairchild Drive 741 Mountain View, CA 94043 742 USA 744 Phone: +1-650-625-2986 745 EMail: charles.perkins@nokia.com 747 Full Copyright Statement 749 Copyright (C) The IETF Trust (2007). 751 This document is subject to the rights, licenses and restrictions 752 contained in BCP 78, and except as set forth therein, the authors 753 retain all their rights. 755 This document and the information contained herein are provided on an 756 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 757 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 758 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 759 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 760 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 Intellectual Property 765 The IETF takes no position regarding the validity or scope of any 766 Intellectual Property Rights or other rights that might be claimed to 767 pertain to the implementation or use of the technology described in 768 this document or the extent to which any license under such rights 769 might or might not be available; nor does it represent that it has 770 made any independent effort to identify any such rights. Information 771 on the procedures with respect to rights in RFC documents can be 772 found in BCP 78 and BCP 79. 774 Copies of IPR disclosures made to the IETF Secretariat and any 775 assurances of licenses to be made available, or the result of an 776 attempt made to obtain a general license or permission for the use of 777 such proprietary rights by implementers or users of this 778 specification can be obtained from the IETF on-line IPR repository at 779 http://www.ietf.org/ipr. 781 The IETF invites any interested party to bring to its attention any 782 copyrights, patents or patent applications, or other proprietary 783 rights that may cover technology that may be required to implement 784 this standard. Please address the information to the IETF at 785 ietf-ipr@ietf.org. 787 Acknowledgement 789 Funding for the RFC Editor function is provided by the IETF 790 Administrative Support Activity (IASA).