idnits 2.17.00 (12 Aug 2021) /tmp/idnits32073/draft-thubert-roll-fundamentals-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 326: '... the LLN Routers MUST obey the followi...' RFC 2119 keyword, line 359: '...already part of a tree MAY move at any...' RFC 2119 keyword, line 362: '... an LLN Router MUST NOT move down th...' RFC 2119 keyword, line 438: '...following values MUST not change durin...' RFC 2119 keyword, line 440: '...The Default flag MAY only be reset. A...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The following values MUST not change during the propagation of the TIO down the tree: G, Sequence Number, Tree Delay and Tree ID. The Default flag MAY only be reset. All other fields are updated at each hop of the propagation. -- The document date (April 9, 2009) is 4783 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-17 == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: draft-ietf-roll-indus-routing-reqs has been published as RFC 5673 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 == Outdated reference: draft-ietf-roll-urban-routing-reqs has been published as RFC 5548 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track T. Watteyne 5 Expires: October 11, 2009 UC Berkeley 6 Z. Shelby 7 Sensinode 8 D. Barthel 9 Orange Labs 10 April 9, 2009 12 LLN Routing Fundamentals 13 draft-thubert-roll-fundamentals-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 11, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a basic set of fundamental mechanisms for 52 routing on a Low-power and Lossy Network (LLN). It does not intend 53 to specify a full-blown protocol. It is rather offered as a basis to 54 support the discussion while designing the ROLL protocol. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.2. Needs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.2. Discovery Information . . . . . . . . . . . . . . . . . . 10 64 2.3. Stability . . . . . . . . . . . . . . . . . . . . . . . . 11 65 3. Route Dissemination . . . . . . . . . . . . . . . . . . . . . 11 66 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.2. Disseminated Information . . . . . . . . . . . . . . . . . 12 68 3.3. LLN Router Operation . . . . . . . . . . . . . . . . . . . 13 69 4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.1. Upstream Forwarding . . . . . . . . . . . . . . . . . . . 15 71 4.2. Downstream Forwarding . . . . . . . . . . . . . . . . . . 17 72 5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 18 73 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.2. Receiver Flow . . . . . . . . . . . . . . . . . . . . . . 18 75 5.3. Source flow . . . . . . . . . . . . . . . . . . . . . . . 19 76 6. Advanced Features . . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. Interaction with other routing protocols . . . . . . . . . 19 78 6.1.1. AODV/DYMO . . . . . . . . . . . . . . . . . . . . . . 19 79 6.1.2. OSPF/OLSR . . . . . . . . . . . . . . . . . . . . . . 20 80 6.1.3. MIP6/NEMO . . . . . . . . . . . . . . . . . . . . . . 21 81 6.2. Route Optimization . . . . . . . . . . . . . . . . . . . . 21 82 6.2.1. Node-to-node routing . . . . . . . . . . . . . . . . . 21 83 6.2.2. Offline Path Computation . . . . . . . . . . . . . . . 21 84 6.2.3. Graph forwarding . . . . . . . . . . . . . . . . . . . 22 85 6.3. Density . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 6.4. Digraph Dissemination . . . . . . . . . . . . . . . . . . 24 87 6.5. Multiple LBRs and Trees . . . . . . . . . . . . . . . . . 24 88 6.6. Aggregation for Route Dissemination . . . . . . . . . . . 24 89 6.7. Advanced Forwarding . . . . . . . . . . . . . . . . . . . 25 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 This document describes a basic set of fundamental mechanisms for 102 routing on a Low-power and Lossy Network (LLN) appropriate for 103 scenarios identified by the ROLL working group. It does not intend 104 to specify a full-blown protocol. It is rather offered as a basis to 105 support the discussion while designing the ROLL protocol. The 106 fundamental mechanisms proposed stem from our analysis that current 107 academic, industrial and IETF protocols suitable to ROLL scenarios 108 are reduceable to those basic mechanisms. 110 Those mechanisms provide a core set of functionality that can be 111 complemented by specific extensions to implement the needs expressed 112 in the ROLL routing requirement drafts: 114 o Urban WSNs Routing Requirements in Low Power and Lossy Networks 115 [I-D.ietf-roll-urban-routing-reqs] 117 o Building Automation Routing Requirements in Low Power and Lossy 118 Networks [I-D.ietf-roll-building-routing-reqs] 120 o Home Automation Routing Requirements in Low Power and Lossy 121 Networks [I-D.ietf-roll-home-routing-reqs] 123 o Industrial Routing Requirements in Low Power and Lossy Networks 124 [I-D.ietf-roll-indus-routing-reqs] 126 The constraints expressed in the routing requirement documents (such 127 as on node memory and communication cost) narrow the choice of 128 fundamental mechanisms down to very simple ones. 130 Due to the highly directed flows in LLNs, a tree structure comes 131 naturally to mind as a bare minimum. In a slightly more elaborate 132 mechanism, we propose that each router memorizes a few best neighbor 133 routers (not only among its parents up the tree, but also among its 134 siblings), to choose from (using some routing metric) when routing 135 towards LLN Border Routers (LBR). However, to reduce complexity, we 136 propose that only the best parent be advertised up the structure 137 towards the LBRs, giving each of them a simple tree representation to 138 be used for routing downstream traffic or for making other global 139 decisions. Since links and nodes are expected to come and go over 140 time, mechanisms for tree reorganization are described. However, on 141 a shorter time scale, transient link failures are bound to happen. 142 In such a case, we recommend that the link-layer passes packets back 143 to the network layer for re-routing along alternate paths. 145 In terms of routing, the basic fundamental methods include uni/ 146 anycast routing up the graph and unicast routing down the tree 147 (either hop-by-hop or source-based). The best neighbor selection 148 mechanism is left to the protocol design phase. We even suggest that 149 it be left as a plug-in for future evolution. However, a set of 150 basic tree discovery and forwarding rules, described here, prevents 151 loops from forming, in most cases, whatever the routing algorithm 152 eventually implemented. 154 More advanced mechanisms which can be built upon the fundamental 155 mechanisms are also described. They include route optimizations, 156 dissemination of a digraph, dissemination and maintenance of multiple 157 overlapping trees, prefix aggregation and advanced forwarding rules. 159 This document is organized as follows: 161 Section 1.1 defines the terminology used in this document. 163 Section 2 concentrates on the basic tree discovery and maintenance 164 mechanism. 166 Section 3 introduces the basic distance-vector route dissemination 167 mechanism. 169 Section 4 describes the upstream and downstream forwarding rules. 171 Section 5 describes multicast support. 173 Section 6 describes advanced mechanisms which can be built upon 174 these fundamentals. 176 1.1. Terminology 178 The terminology used in this document is consistent with and 179 incorporates that described in [I-D.ietf-roll-terminology]. This 180 terminology is extended in this document as follows: 182 to Attach: the action of establishing a child-to-parent relationship 183 in Tree Discovery. 185 Tree Depth: the maximum number of edges that need to be traversed 186 from any tree node to the root. 188 Discovery: a mechanism by which a logical representation of the 189 network is built. 191 Floating, Grounded: a tree is said to be Grounded if it is connected 192 to a high-capacity backbone or backhaul link to a network such as 193 the Internet. By contrast, a tree is said to be Floating if it is 194 not Grounded. 196 Graph: a set of vertices and edges to represent a network of nodes 197 and links. A Directed Acyclic Graph (DAG) is a graph with 198 directional edges where no loop is formed. 200 Uniform Path Metric: A scalar measure for the quality of the bi- 201 directional path between the LLN Router and the root. 203 Route Dissemination: the action of establishing state within the 204 network so that routers know how to forward packets related to 205 some source-destination pairs. 207 Router: a network node that is capable of forwarding packets on 208 behalf of other nodes. In ROLL routing requirement documents, it 209 appears that most nodes are expected to be routers. 211 Default Router: the router to turn to when a node has no information 212 on where to forward a packet. 214 1.2. Needs 216 The ROLL working group has identified typical scenarios and their 217 related requirements for LLN routing. The main requirements on any 218 fundamental mechanisms used for achieving the ROLL protocol can be 219 summarized as follows: 221 o Support for operation in both full IPv6 [RFC2460] and minimal 222 6LoWPAN [RFC4944] networks. 224 o Optimized for traffic directed between nodes and LBRs. 226 o The discovery of multiple disjoint routing paths to increase 227 reliability. 229 o Support for multiple LBRs out of the LLN. 231 o Minimal network state needed by routers, with a hard bound better 232 than O(D), D being the number of destinations. 234 o Support for complex unicast, anycast and multicast flows. 236 o Localized response upon link failures without requiring global 237 updates. 239 o Minimal control overhead scaling within O(log(L)) of the data 240 rate. 242 o Support for link and node costs along routes. 244 2. Tree Discovery 246 A tree is the simplest and most basic acyclic graph structure. Even 247 if it is not sufficient to ensure by itself the multipath forwarding 248 proposed below, a tree provides the ideal structure for best path 249 routing between source and sink in a convergecast. 251 In many occasions, LLNs do not have a clear and stable physical 252 structure and it becomes necessary to overlay a logical 253 representation to define links and enable IPv6 operations. LLN Tree 254 Discovery is the component of the LLN fundamentals that builds and 255 maintains logical tree structures over the LLN. 257 The nodes in an LLN discovery tree are Routers; the root is an 258 arbitrary elected Router if the tree is Floating; it is a LLN Border 259 Router (LBR) if the tree is Grounded, that is the root is connected 260 to the infrastructure via a backhaul link or a federating backbone. 262 A federating backbone such as an extended LoWPAN backbone is the 263 virtual root of the federated tree. In that case, the LBRs are 264 attached at a depth of one and are in charge of performing the root 265 operations on behalf of that virtual root. 267 A tree is identified by a Tree ID which can take the form of an IPv6 268 address: in the case of a LoWPAN configuration with a federating 269 backbone, the LoWPAN prefix is used as the Tree ID. If there is no 270 backbone, the tree ID will be an address of the root or a prefix 271 owned by the root. A router attaching to a tree sets a route to the 272 treeID via its parent in the tree. 274 A router may attach to and may advertise more than one tree, but it 275 uses and advertises at most one tree as Default tree. A router sets 276 up its default route via its parent in its Default tree. 278 This section describes 280 1. a minimum extension to IPv6 Neighbor Discovery Router 281 Advertisements in order to ensure that LLN Routers organize in a 282 tree structure, and 284 2. a minimum common algorithmic part that all LLN Routers are 285 required to implement in order to ensure that, whatever the 286 individual routing decisions, routing loops between LLN Routers 287 are avoided and basic optimization is achieved. 289 LLN Discovery is based on an autonomous decision by each Router with 290 no global state convergence such as traditionally found in IGPs. In 291 order to enable backward compatibility and interoperability, LLN 292 Discovery allows Routers to make different decisions from identical 293 inputs, based on their own configuration and their own algorithms, 294 though it is highly preferable that the decision algorithm be 295 consistent in a given deployment to achieve the specific goals of 296 that deployment. 298 The signalling mechanism that is used to form the trees is an 299 extension to the ICMP Router Advertisement (RA) message, namely the 300 Tree Information Option (TIO). The TIO allows LLN Routers to 301 advertise the tree they belong to, and to select and move to the best 302 location within the available trees. LLN Routers propagate the TIO 303 in RA messages down the tree, updating some metrics such as the Tree 304 Depth while leaving other information such as the Tree ID unchanged. 305 This is compatible with RA period reduction techniques such as the 306 use of Trickle. 308 2.1. Overview 310 LLN Tree Discovery is a form of distance vector protocol for use in 311 wireless meshed networks. Tree Discovery locates the nearest exit 312 and forms Directed Graphs towards that exit, composed of a best path 313 tree and alternate forwarding options. 315 By introducing the concept of routing plug-ins, LLN Tree Discovery 316 enables LLN Routers to implement different policies for selecting 317 their preferred parent in the Tree. Tree Discovery does not specify 318 the plug-in operation, but rather specifies a set of rules to be 319 implemented by all plug-ins to ensure interoperability. 321 The Tree Depth is the underlying criterion that garantees loop-free 322 operations even if plug-ins implement different policies, and even if 323 these policies do not use Depth as a routing metric. 325 In order to organize and maintain a loopfree structure, the parent 326 selection plug-ins in the LLN Routers MUST obey the following rules 327 and definitions: 329 1. The root of a tree exposes the tree in the Router Advertisement 330 (RA) Tree Information Option (TIO) and LLN Routers propagate the 331 TIO down. 333 2. An LLN Border Router that is attached to a federating backbone 334 acts as root and advertises a depth of one. An LBR that is not 335 attached to a federating backbone is a root and exposes a depth 336 of zero. 338 3. An LLN Router that is not a Border Router may be the root of its 339 own Floating tree. Its depth is zero in that tree. An LLN 340 Router that loses its current parent and has no alternate parent 341 is back to that same state, but it needs to remember the Tree ID 342 and the sequence counter in the TIO of the lost parent for a 343 period of time which covers multiple TIOs. 345 4. An LLN Router announces its tree as Default in a TIO unless it 346 also announces its participation to another tree that it uses as 347 Default. An LBR announces its tree as Default and sets up its 348 default route over the backhaul or the backbone. An LLN router 349 that attaches to a tree that is announced as Default may select 350 that tree as Default in which case it will propagate the Default 351 information in the TIO for that tree and set up a default route 352 via its parent in that tree. If the route attaches to other 353 trees that are also announced as Default, it will reset the 354 Default for the corresponding TIOs. 356 5. A router sending an RA without TIO is considered a Grounded 357 Default Router at depth 0. 359 6. An LLN Router that is already part of a tree MAY move at any 360 time and with no delay in order to get closer to the root of its 361 current tree, i.e. in order to reduce its own tree depth. But 362 an LLN Router MUST NOT move down the tree that it is attached to 363 unless the potential parent advertises a Sequence Number that is 364 newer than the last Sequence Number known for that tree, 365 indicating that the potential parent is not within this router 366 subtree. 368 7. A LLN Router may move from its current default tree into any 369 different default tree at any time and whatever the depth it 370 reaches in the new tree but, before it can do so, it may have to 371 wait for a Tree Hop Timer to elapse. If the router was root of 372 its own floating tree, it may join its previous tree (identified 373 by the last parent Tree ID) only if the sequence number in the 374 TIO was incrememented since the LLN Router left that tree, 375 indicating that the candidate parent was not attached behind 376 this LLN Router and kept getting subsequent TIOs from the same 377 tree. The LLN Router will join that other tree if it is 378 preferable for reasons of connectivity, configured preference, 379 available medium time, size, security, bandwidth, tree depth, or 380 whatever metrics the LLN Router cares to use. 382 8. If an LLN Router has selected a new parent router but has not 383 moved yet (because it is waiting for Tree Hop Timer to elapse), 384 it is said to be unstable and refrains from sending Router 385 Advertisement - Tree Information Options. 387 9. When a LLN Router joins a tree, moves within its own tree or 388 receives a modified TIO from its current parent router, it sends 389 out an unsolicited Router Advertisement message with TIO that 390 propagates the new tree information. 392 10. This allows the new higher parts of the tree to be updated 393 first, eventually dragging their sub-tree with them, and 394 allowing stepped sub-tree reconfigurations, limiting relative 395 movements. 397 2.2. Discovery Information 399 The Tree Information Option carries a number of metrics and other 400 information that allows an LLN Router to discover a tree and select 401 its parent while avoiding loop generation. 403 TIO Base option 405 The Tree Information Option is a container option, which might 406 contain a number of suboptions. The base option regroups the 407 minimum information set that is mandatory to operate the LLN 408 Discovery Algorithm. 410 Default (D): The Default (D) flag is set when the tree is used to 411 set up the default route. A router that participates to 412 multiple trees (including self-rooted) announces at most one 413 tree as Default. 415 Grounded (G): The Grounded (G) flag is set when the tree is 416 attached to a fixed network infrastructure (such as the 417 Internet). 419 Sequence Number: An integer that is incremented by the root for 420 each TIO sent on a link. It is propagated unchanged down the 421 tree. 423 Tree Depth: If the root is attached to a federating backbone, its 424 Tree Depth is 1, otherwise it is 0. The Tree Depth of an LLN 425 Router is the depth of its parent as received in a TIO, 426 incremented by at least one. All the nodes in the tree 427 advertise their Tree Depth in the Tree Information Options that 428 they append to the RA messages as part of the propagation 429 process. 431 Tree ID: An IPv6 address which uniquely identifies a tree. This 432 value is set by the root to one of its ULA or global addresses 433 or prefixes. 435 Uniform Path Metric: A scalar measure for the quality of the bi- 436 directional path between the LLN Router and the root. 438 The following values MUST not change during the propagation of the 439 TIO down the tree: G, Sequence Number, Tree Delay and Tree ID. 440 The Default flag MAY only be reset. All other fields are updated 441 at each hop of the propagation. 443 In addition to the minimum set of information required, a number 444 of options can are used, e.g. for bandwidth, stability, preference 445 etc. 447 2.3. Stability 449 An LLN Router is instable when it is prepared to move shortly to 450 another parent Router. This happens typically when the LLN Router 451 has selected a more preferred candidate parent Router and has to wait 452 for the Tree Hop Timer to elapse before roaming. Instability may 453 also occur when the current parent Router is lost and the next best 454 one is still held up. Instability is resolved when the Tree Hop 455 Timer of all the parent Router(s) causing instability elapse. 457 Instability is transient (on the order of Tree Hop Timers). When an 458 LLN Router is unstable, it MUST NOT send RAs with TIO. This reduces 459 the likelyhood of loops when LLN Router A wishes to attach to LLN 460 Router B and LLN Router B wishes to attach to LLN Router A. Unless 461 RAs crisscross, a LLN Router only receives TIO from stable parent 462 Routers, which do not plan to attach to it, so it can safely attach 463 to one of them. 465 3. Route Dissemination 467 3.1. Overview 469 Route Dissemination is the second component of the LLN fundamental 470 mechanisms. As explained previously, the first component, LLN Tree 471 Discovery, establishes a logical tree structure over the LLN and sets 472 up default routes towards the root of its Default Tree. To establish 473 the routing states towards the nodes in the LLN and enable complete 474 reachability along the tree, it suffices for Route Dissemination to 475 advertise up the tree the host ID, prefix and multicast routes. 477 As a result, the Default Router for an LLN Router is its parent up in 478 the Default tree (upstream); and the more specific routes are always 479 oriented down the tree (downstream). 481 LLN Tree Discovery does not only provide loop avoidance for the Route 482 Dissemination protocol; LLN Tree Discovery also triggers Route 483 Dissemination each time a topological change occurs. The loopfree 484 structure must be restored before Route Dissemination can operate 485 again and repaint the tree with prefixes, addresses and group 486 membership. 488 Each logical tree that LLN Tree Discovery forms is considered a 489 separate routing topology. If an LLN Router belongs to multiple of 490 such topologies, then it is expected that both the Route 491 Dissemination signaling and the data packets are flagged to follow 492 the topology for which the packet was introduced in the network. 494 The ROLL Route Dissemination protocol defines a new information 495 vector called the Route Information Option (RIO) to disseminate 496 atomic routing information towards the root of the tree. 498 A parent maintains a state for each information it learns from Route 499 Dissemination. Advertisements are sequenced and the last sequence 500 number is kept. An out-of-sequence RIO must be disregarded. If the 501 RIO information appears valid, it is forwarded to the parent's parent 502 in the next burst, carried by a RIO, together with the parent's own 503 information. 505 3.2. Disseminated Information 507 Route Dissemination extends RFC4861 and RFC4191 to allow a node to 508 include a new Route Information Option in ND messages such as 509 Neighbor Advertisements (NAs). 511 In order to track the freshness of an advertisement, the RIO includes 512 a sequence counter that is incremented each time the advertisement is 513 reissued. 515 An NA is also sent to the new parent once it has been selected after 516 a movement, or when the list of advertised information has changed. 518 Route Dissemination may advertise positive (prefix is present) or 519 negative (removed) RIOs. 521 The RIO base option carries sequenced route information for unicast 522 and multicast; it contains: 524 Resource type: Prefix, host, or multicast group 526 Prefix Length: Number of valid leading bits in the IPv6 Prefix. 528 RIO Lifetime: The length of time in seconds (relative to the time 529 the packet is sent) that the prefix is valid for route 530 determination. 532 RIO Depth: Set to 0 by the router that owns the resource and issues 533 the RIO. Incremented by all routers that propagate the RIO 534 towards the root. 536 RIO Sequence: Incremented by the router that owns the resource for 537 each new RIO for that prefix. Left unchanged by all routers that 538 propagate the RIO. 540 Prefix: Variable-length field containing a prefix, an IPv6 address 541 or a multicast group id. 543 3.3. LLN Router Operation 545 Route Dissemination information can be redistributed in another 546 routing protocol, e.g. MANET or IGP. But the MANET or the IGP route 547 information SHOULD NOT be redistributed into Route Dissemination. 548 This creates a hierarchy of routing protocols where Route 549 Dissemination routes stand somewhere between connected and IGP 550 routes. See Section Section 6.1 for more discussion on integration 551 with other routing protocols. 553 As a result: 555 o LLN Tree Discovery establishes a tree using extended Neighbor 556 Discovery RS/RA flows. 558 o A routing algorithm exploits the tree to optimally move upstream 559 traffic out of the LLN (default route). 561 o Route Dissemination extends Neighbor Discovery in order to quickly 562 establish hop-by-hop routes down the tree. 564 o Source Routing can be used to provide additional routes towards 565 nodes in the LLN. When and where there exists hop-by-hop state in 566 routers, the source routing information can be made sparse. 568 Route Dissemination maintains abstract lists of known information. 569 An entry contains the following abstract information: 571 o A reference to the adjacency that was created for that prefix. 573 o The IPv6 address of the advertising Neighbor. 575 o The logical equivalent of the full Route Dissemination 576 information. 578 o A 'reported' Boolean to keep track whether this prefix was already 579 reported to the parent's parent. 581 o A counter of retries to count how many TIOs were sent to the 582 neighbor without reachability confirmation for the prefix. 584 Route Dissemination stores the entries in either one of 3 abstract 585 lists; the Connected, the Reachable and the Unreachable lists. In 586 practice all are part of a route table. 588 The Connected list corresponds to the resources owned by the LLN 589 Router. 591 As long as a router keeps receiving timely RIOs for a given 592 information, its entry is listed in the Reachable list. 594 Once scheduled to be destroyed, an entry is moved to the Unreachable 595 list if the router has a parent to which it sends RIOs, otherwise the 596 entry is cleaned up right away. The entry is removed from the 597 Unreachable list when the parent changes or after a no-RIO has been 598 sent to the parent indicating the loss of the prefix. 600 RIO Processing 602 When ND sends an NA to the parent, Route Dissemination extends the 603 message with RIO options for: 605 * All entries that are not deleted. 607 * All entries in the removed list, using a no-RIO. 609 * All entries in the advertised list that are 'not reported yet'. 610 The entries are then set to 'reported'. 612 If an information is advertised as a no-RIO, the associated route 613 is removed, and the entry is transferred to the removed list. 614 Otherwise, the proper routing table is looked up: 616 * If a preferred route to that source from another protocol 617 already exists, the RIO is ignored. 619 * If a new route can be created, a new entry is allocated to 620 track it, as CONFIRMED, but not reported. 622 * If a Route Dissemination route existed already via the same 623 Neighbor, it is CONFIRMED. 625 * If an older unicast route existed via a different Neighbor, 626 this is equivalent to a no-RIO for the previous entry followed 627 by a new RIO for the new entry. So the old entry is scheduled 628 to be destroyed, whereas the new one is installed. 630 Unicast Route Dissemination messages from child to parent 632 When sending Route Dissemination to its parent, a router includes 633 the RIOs about not already reported entries in the Reachable and 634 Connected lists, as well as no-RIOs for all the entries in the 635 Unreachable list. 637 The TIO from the root is used to synchronize the whole tree. Its 638 period is expected to range from 500ms to hours, depending on the 639 stability of the configuration and the bandwidth available. 641 The design choice behind this is NOT TO synchronize the parent and 642 children databases, but instead to update them regularly to cover 643 from the loss of packets. The rationale for that choice is 644 network dynamicity. If the topology can be expected to change 645 frequently, synchronization might be an excessive goal in terms of 646 exchanges and protocol complexity. This results in a simple 647 protocol with no real peering. 649 4. Forwarding 651 The fundamental mechanisms described in this draft build a DAG to 652 enable communication from the LLN Router nodes to the LLN Border 653 Routers (upstream); a second mechanism informs LLN Routers about 654 their children in the tree, hence enabling LLN Boarder Router to LLN 655 Router communication (downstream) and node-to-node routing along the 656 tree. While the previous sections focus on how routing information 657 is disseminated throughout the LLN and used for routing, this section 658 focuses on the forwarding policies used by LLN Routers. 660 Reliability is increased by allowing a node to try several potential 661 next-hop nodes in upstream traffic; downstream traffic is sent along 662 the tree formed by route dissemination. 664 4.1. Upstream Forwarding 666 Forwarding in a LLN needs to account for requirements that are 667 unusual in the IP world: 669 perfect loop freedom is a non-goal 671 the specification allows for the 'wheel model' where a packet 672 circulates a bit around the destination till it finally makes it. 674 transient forwarding failure are commonplace 676 This specification introduces the capability for the layer 2 to 677 give a packet back to layer 3 in order to try another adjacency. 679 Using the LLN Tree Discovery procedure, LLN Routers expose their path 680 metrics using the Uniform Path Metric field in the TIO. Neighbor LLN 681 Routers with a lesser depth in the tree then self are forwarding 682 parents. Neighbor LLN Routers with a same depth in the tree are 683 siblings. Forwarding via parents ensures a loop free operation 684 whereas forwarding via siblings may not be loopfree unless additional 685 measures are taken. 687 The approach taken in this specification is to favor forwarding via 688 parents but still enable forwarding via siblings as a backup option. 689 Preferring the parents enables a forwarding gradient towards the LBR 690 that limits the chances of multiple consecutive hops over siblings. 691 This specification also prevents from returning a packet back to the 692 neighbor that just passed it. This simple rule coupled with the 693 forwarding gradient protect against loops for a vast majority of 694 cases, and the specification relies on a appropriate setting of the 695 TTL in a given deployment to protect against meltdowns. 697 In more details: 699 o A LLN router MUST send upstream data to its forwarding parent with 700 smallest metric. Note that, depending on the way the routing 701 protocol determines this metric, and the dynamics of the tree, the 702 best forwarding parent at a given point of time is not necessarily 703 the parent with the smallest depth or the parent in the logical 704 tree defined by the Tree Discovery procedure. 706 o If the transmission of an upstream packet to that preferred parent 707 fails (due to a node or link failure, or mobility), the LLN router 708 MAY attempt to forward the packet again via other parents, as 709 ordered by best metric. 711 o If the transmission to both primary and secondary forwarding 712 parents fails, the LLN Router MAY forward the packet via siblings, 713 as ordered by best metric. 715 o When the transmission fails and the packet is retried via a 716 different neighbor, the router MUST decrease the TTL by one. 718 In order to enable these rules, a LLN router maintains a blacklist 719 per packet being forwarded that contains: 721 o the neighbor that forwarded the packet to self 723 o neighbors to which forwarding of this packet failed 725 These rules are illustrated in the following figure which represents 726 a subset of an LLN. 728 D,1,3 B,1,7 729 | / 730 | / 731 | / 732 C,2,9--- A,2,8 734 An LLN Router is identified by . LLN Router A has 735 three neighbors B,C,D. D is A's primary forwarding parent as it is 736 the neighbor with the smallest Metric amoung neighbors with smaller 737 depth. If transmission to D fails, A sends the packet to B, which is 738 of smaller depth. If transmission to B fails, A transmits to C. 739 Because C is at the same depth as A, a blacklisting policy is used to 740 avoid that C retransmits to A. 742 4.2. Downstream Forwarding 744 Downstream routing using LLN fundamental mechanisms can occur using 745 either hop-by-hop state, source routing or a combination thereof 746 (loose source route). By default, the LLN Route Dissemination 747 mechanism builds up hop-by-hop distance-vector routing information in 748 each of the routers along the tree up to the root for each address, 749 prefix or group ID. 751 Source routing can optionally be supported by either requesting a 752 route record header from a node, or by having nodes send periodic 753 route record headers up to the root. If a Route Dissemination route 754 exists to the first entry in the Record Route header via the source 755 of the packet, then the router can override the source of the packet 756 with its address without adding the original source to the Record 757 Route. At that point, the routing header operation becomes loose, in 758 other words an hybrid between transparent hop-by-hop (stateful) and 759 source routing. 761 Therefore three different downstream techniques are supported: 763 o Hop-by-hop forwarding. When only partial route dissemination data 764 reaches a LLN Border Router, it only knows the next-hop to a given 765 LLN Router in the network. In this case, each LLN Router relaying 766 downstream data will select the next-hop according to the 767 information it receives during route dissemination. 769 o Full source routing. When all the route dissemination data 770 reaches a LLN Border Router, it one can choose to specify the full 771 list of LLN Routers to be traversed in each downstream data 772 packet. 774 o Loose source routing. When the source route information is 775 compressed because of existing state in the routers along the 776 path. 778 5. Multicast Support 780 5.1. Overview 782 Wherever we mention , one can read MLDv2,3 for IPv6. Doing IGMP 783 over the LLN involves: 785 o LLN Border Router acting as a local Rendez-vous Point (RP) for the 786 LLN and as source towards the Internet for all multicast flows 787 started in the LLN. 789 o transporting in Route Dissemination and recursive 790 coalescence of the multicast requests. 792 5.2. Receiver Flow 794 The LBR is considered as a Rendezvous Point (RP) for all multicast 795 flows issued from inside the LLN. Multicast packets are passed up 796 the tree to the LBR. 798 Nodes talk to their parent router. The parent router forward 799 the registration and inject their own as a special type of RIO for 800 multicast groups, towards the LBR. The LBR MAY participate to 801 multicast in the infrastructure it is connected to and forward all 802 the packets coming from the LLN. 804 Between the parent router and the LBR, requests are transported 805 in the RIO; each hop aggregates the requests in a fashion that is 806 similar to proxy IGMP, but this happens recursively between child 807 node to parent router up to the LBR. On the way, multicast routing 808 states are installed in each router from the receiver to the root, 809 enabling multicast routing down the LLN tree. 811 5.3. Source flow 813 As a Node, the source is unaware of the ROLL protocol, and it uses 814 standard protocols with the router (say in IPv6: Neighbor Discovery, 815 etc...). So when it has a multicast packet to send, the source 816 just forwards it to its default router, which is the expected 817 standard behavior. Routers on the way recursively forward to their 818 parent. At each hop, if a multicast route indicates that a listener 819 is reachable via another child (different from that through which the 820 packet was received) then the packet is duplicated and forwarded to 821 that child down the tree. 823 If the LLN Border Router is configured to do so, it will source the 824 packet to a real RP in the Internet. 826 6. Advanced Features 828 The fundamental mechanisms described in this document are sufficient 829 to allow for upstream and downstream communication inside the LLN. 830 They form a common basis upon which future LLN routing protocols can 831 be designed. This section indicates some possible advanced features 832 which can be integrated to increase efficiency for a particular usage 833 scenarios. 835 6.1. Interaction with other routing protocols 837 While network design and specific use cases are out of scope for this 838 document, it must be noted that the LLN fundamental mechanisms 839 described herein might be used in conjunction with other routing 840 protocols in order to fulfill the requirements of a particular 841 deployment. Here follows a non exhaustive series of examples 842 illustrating such interactions. 844 6.1.1. AODV/DYMO 846 In the example of a closed loop between a sensor and a switch, a 847 constrained optimized route must be installed between the 2 devices. 849 Defining such a specific route is costly and should be performed on- 850 demand when the bulk of the traffic is buffered data from source to 851 sink. 853 A reactive MANET protocol such as AODV [RFC3561], DSR [RFC4728] or 854 DYMO [I-D.ietf-manet-dymo] can be deployed to enable such routing, 855 though the QoS-constrained approach for AODV is stalled as a draft 856 ([I-D.perkins-manet-aodvqos]). 858 6.1.2. OSPF/OLSR 860 A federating backbone is the virtual root of a collection of trees 861 that forms a single routing topology. If that topology shares a same 862 prefix, a sensor device can move freely within the topology without 863 renumbering. The 6LoWPAN backbone link is an example of such a 864 federating backbone and in that case, the protocol that enables any 865 to any reachability is simply IPv6 Neighbor Discovery [RFC4861]. 867 In a generalized case with routing and multiple subnets, a 868 traditional IGP such as OSPF [RFC2740] or a MANET protocol such as 869 OLSR [RFC3626] can be deployed within the federating backbone between 870 the LBR to advertise the routes learnt from the LLN fundamentals 871 dissemination protocol through the redistribution of route 872 information. 874 In turn, the routed federating backbone is just the instantiation at 875 Depth 0 of the more general concept of beltlines. A beltline is a 876 set of routers of a same depth in a same tree that form a subarea 877 where an IGP is run and route information from the LLN Route 878 Dissemination protocol is redistributed. This creates routes around 879 the root and reduces the load that routing along the tree imposes on 880 the lower depth of the tree. 882 Note that in turn, beltline routes ARE NOT redistributed into LLN 883 Route Dissemination information. As a result, the beltlines routes 884 are orthogonal to the route dissemination routes, and they should 885 never collide, which optimizes the value of the control plane of the 886 combination. 888 Beltline routes should be used with caution in order to maintain 889 stability and optimize the resulting routes: 891 o beltline routes should only be used when a certain topological 892 stability was asserted 894 o using beltline routes discourages the reorganization of the tree, 895 mostly when that causes a router to change its depth 897 o a divide and conquer approach to limit the size of a beltline 898 enables to manage the cost of the control plane 900 o a beltline of depth 2 or more should be an arc as opposed to full 901 circle.In the example of a closed loop between a sensor and a 902 switch, a constrained optimized route must be installed between 903 the 2 devices. 905 6.1.3. MIP6/NEMO 907 MIP6 [RFC3775] and NEMO [RFC3963] enable a subtree to move away from 908 the tree and maintain reachability as if the nodes in the subtree 909 were still located in their topologically correct position. This can 910 be useful when a RIO aggregation is performed (see Section 6.6) to 911 enable reachability of a stray device. MIP6 be also be useful to 912 enable a mobile display device such as a PDA to keep accessing a 913 sensor network remotely without injecting the sensor network prefix 914 into the infrastructure for security reasons. 916 6.2. Route Optimization 918 Whereas upstream and downstream communication is made possible by the 919 fundamental mechanisms described in this document, applications may 920 require more require traffic engineering, which may include: 922 6.2.1. Node-to-node routing 924 Node-to-node routing is ensured along the tree by the Route 925 Dissemination protocol, and the packets flow via the first common 926 parent. This can be optimized if the LLN Border Router has a clear 927 view of the topology (see 'Offline Path Computation' section). In 928 this case, the LLN Border Router can indicate the direct path between 929 both LLN Routers, calculated offline, to the source, the destination, 930 or both. This technique induces a trade-off between multi-hop route 931 efficiency and signaling overhead to setup this direct node-to-node 932 path for instance as suggested in Section 6.1.1. 934 6.2.2. Offline Path Computation 936 Whereas nodes might not have the capacity to store and manage enough 937 information to perform constrained routing, it is possible for nodes 938 to report their neighborhood information to the LLN Border routers. 939 LLN Border routers can then share their partial topology databases 940 and get a full picture of the network. 942 From there, it is possible to get LLN Border routers to compute 943 shorter or constrained paths and either distribute them (e.g. LDP) 944 or pass the source route information to the end nodes. 946 An OSPF example of that goes like this. Nodes run HELLO or similar, 947 and send their LSA in unicast to their LLN Border routers. The LLN 948 Border routers act as proxy for the nodes and share those LSAs with 949 other LLN Border routers over the backbone. At some point they 950 converge and an LLN Border router will run SPF on behalf of all its 951 registered nodes, one at a time. The SPF computation should end at a 952 certain distance from the node for which it makes more sense to go 953 through the backbone anyway. Then the LLN Border router sends the 954 set of routes to the node as an new topology that can be used in a 955 MTR fashion. 957 6.2.3. Graph forwarding 959 Distance Vector and Link State routing protocols are traditionally 960 designed in terms of: 962 Links -> Metrics -> Routes -> network runtime 964 Unless traffic engineering kicks in, either the routes are 965 established over the shortest path and the alternate links are wasted 966 or the traffic is load balanced in a fashion that represents the 967 ratio of costs as opposed to the ratio of capacity of the paths. 969 Also, the runtime of the network is opaque to the forwarding plane, 970 so the only way to guarantee some end-to-end bandwidth for a class of 971 traffic is to blindly reserve it, leading to even more waste of 972 bandwidth when the reservation is not fully utilized. 974 In order to optimize the network utilization, it would be beneficial 975 to detect the saturation of the shortest path and load balance the 976 extra traffic over alternate routes. In the case of ROLL, it is also 977 critical to be able to make a reroute decision on a per packet basis 978 when hop by hop retries are exhausted. Arpanet introduced a feedback 979 loop into the routing protocol by making the metrics dynamic: 981 Links -> Metrics -> Routes -> network runtime 982 ^ | 983 |__________________________________| 985 But this approach was unsuccessful, causing instabilities and 986 disrupting the network. With dynamic metrics, the duration of the 987 convergence time - or frozen time -,increases with the number of 988 links and the frequency of the metric updates. During that time, the 989 response of the network is undefined and temporary loops occur. 991 An approach to solve this problem is having 2 independent sets of 992 metrics: on the one hand, the topological metrics that are rather 993 static and mostly administratively set; and on the other hand, the 994 volatile metrics that are based on dynamic measurements of the 995 network characteristics. 997 The topological metrics are used by the LLN routing protocol to 998 initially build the tree as described in this specification. The 999 volatile metrics are then used by a forwarding protocol to balance 1000 the traffic for that destination over the upstream links, thus 1001 modifying the way the graph is being used in runtime, without 1002 changing its structure. 1004 To get there, the control plane operates in 2 phases, in a lollipop 1005 fashion: 1007 Links->Metrics->Routes->netw. runtime->runtime metrics->forwarding 1008 ^ | 1009 |________________________________| 1010 <--------------------------> <-----------------------------------> 1011 ROLL routing protocol ROLL forwarding protocol 1013 The LLN fundamentals proposal builds shortest path trees to the exits 1014 but adds the capability to forward over another branch if sending a 1015 packet to a parent fails, either via any alternate parent or a 1016 sibbling. So the paths that we really want to monitor are along the 1017 tree itself and one hop away from the tree. To get there, the root 1018 emits a beacon that is multicasted down the tree and heard one hop 1019 away. That beacon gathers the metrics that will be used for 1020 alternate parents and sibblings selection and nodes keep track of the 1021 beacon they hear for all the parents and sibblings they want to 1022 track. From the beacon, they can infer the quality of the path 1023 through all the alternates and compare them. 1025 6.3. Density 1027 In a dense environment, it is useless that all routers that can 1028 provide backhauling service actually do so; in practice, limiting the 1029 number of routers that accept attached nodes saves memory in the 1030 attached nodes and reduces the cost of signalling. Also, limiting 1031 the number of forwarding LLN Routers in the tree improves the 1032 multicast operations. 1034 Algorithms such a Trickle could be used by a LLN Router to decide to 1035 stop providing its access services for attached nodes if there are a 1036 number of neighboring routers that provide similar services. The 1037 simplest abstraction of such similarity is that a multiple routers 1038 advertising a same depth, though such a simple similarity does not 1039 address the specifics of a router selection in the plugins. In a 1040 more general fashion, a LLN Router can associate the concept of 1041 similarity with the characteristics of its own parent router 1042 selection plug in. 1044 6.4. Digraph Dissemination 1046 The fundamental techniques described in this draft overlay a tree for 1047 source/sink traffic over the physical topology. This tree could be 1048 converted into a (bi)graph with additional overhead. A LLN Router 1049 would therefore send route dissemination data to both its primary and 1050 secondary forwarding parents, hence informing an LLN Border Router of 1051 disjoint paths. This makes sense in applications where the gains in 1052 increase downstream reliability outweigh the additional signaling 1053 overhead. 1055 6.5. Multiple LBRs and Trees 1057 The LLN Tree Discovery technique propagates increasing depths and 1058 metrics throughout the network; upstream messages travel on a 1059 decreasing metric path back to the LLN Border Router. When the LLN 1060 features multiple LBRs, the following options appear: 1062 o If the different LBRs share the same TreeID, an LLN Router 1063 implicitly sends its upstream data to the LBR which is closest in 1064 terms of aggregated metric. This should be used whenever LBRs 1065 play the same role. 1067 o Different LBRs may choose to use different TreeIDs. In this case, 1068 a LLN Router is part of multiple trees, one for eachTreeID. When 1069 sending an upstream message, a LLN Router chooses on which TreeID 1070 it wishes to send, i.e. to which LBR. 1072 o A hybrid case can exist in which some LBRs share the same TreeID 1073 while others have their dedicated Tree ID. 1075 An alternative when having multiple LBRs is to construct multiple 1076 trees (e.g. one for each LBR) and choose a default tree for 1077 forwarding data. Using an alternate tree is possible only when 1078 labeling the data packet accordingly; an unlabeled packet is 1079 forwarded on the default tree. 1081 6.6. Aggregation for Route Dissemination 1083 Aggregation of prefixes on a same router 1085 When deploying a router with multiple interfaces, it makes sense 1086 to assign an aggregation prefix (shorter than /64) to the router 1087 and partition it as /64 prefixes over the router interfaces. A 1088 router that owns a contiguous set of prefixes should only report 1089 the aggregation of these prefixes through Route Dissemination. 1091 Aggregation of prefixes by a parent acting as ROLL Home 1093 There are also a number of cases where a ROLL aggregation is 1094 shared within a platoon of LLN Routers. In that case, it is still 1095 possible to use aggregation techniques with Route Dissemination 1096 and improve its scalability. In that case, the parent is 1097 configured as the Route Dissemination aggregator for the group 1098 prefix. At run time, it absorbs the individual RIO information it 1099 receives from the platoon members down its subtree and only 1100 reports the aggregation up the TD tree. This works fine when the 1101 whole platoon is attached within the parent's subtree. 1103 But other cases might occur for which additional support is 1104 required: 1106 1. the aggregator is attached within the subtree of one of its 1107 platoon members. 1109 2. a platoon member is somewhere else within the TD tree. 1111 3. a platoon member is somewhere else in the Internet. 1113 In all those cases, a node situated above the aggregator in the TD 1114 tree but not above the platoon member will see the advertisements 1115 for the aggregation owned by the aggregator but not that of the 1116 individual platoon member prefix. So it will route all the 1117 packets for the platoon member towards the aggregator, but the 1118 aggregator will have no route to the platoon and will fail to 1119 forward. 1121 6.7. Advanced Forwarding 1123 A blacklisting policy can be used to avoid routing loops when an 1124 upstream data packet is sent between neighbor LLN Routers of the same 1125 depth. Alternatively, more general techniques can be used to avoid 1126 loops. One is to record the sequence of already traversed nodes in 1127 the data packet as it travels along a multi-hop path. When receiving 1128 a packet, a LLN Router may know whether it has already relayed that 1129 packet; if yes, it can know from which neighbors it had received it 1130 and to which it had sent. A distributed version of depth first 1131 search can then be used to avoid routing loops. This extension 1132 enables upstream packets to be sent to neighbors with a larger depth. 1134 7. Security Considerations 1136 As this draft suggests the use of new options carried in ICMP ND 1137 messages; the same security considerations as in [RFC4861] apply, in 1138 particular with regards to the use of Secure ND [RFC3971] to protect 1139 against address theft. Additionally link-layer security should be 1140 applied in the case of 6LoWPAN where SeND is not typically possible. 1142 8. IANA Considerations 1144 This draft would require two new ICMP options for use with ND: the 1145 Tree Information Option (TIO) and the Route Information Option (RIO). 1147 9. Acknowledgments 1149 The authors would like to thank Richard Kelsey, Robert Assimiti, Kris 1150 Pister, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, 1151 Patrick Wetterwald, Bryan Mclaughlin and Carlos J. Bernardos for 1152 useful design considerations and reviews. 1154 10. References 1156 10.1. Normative References 1158 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1159 (IPv6) Specification", RFC 2460, December 1998. 1161 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1162 "Transmission of IPv6 Packets over IEEE 802.15.4 1163 Networks", RFC 4944, September 2007. 1165 10.2. Informative References 1167 [I-D.ietf-manet-dymo] 1168 Chakeres, I. and C. Perkins, "Dynamic MANET On-demand 1169 (DYMO) Routing", draft-ietf-manet-dymo-17 (work in 1170 progress), March 2009. 1172 [I-D.ietf-roll-building-routing-reqs] 1173 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 1174 "Building Automation Routing Requirements in Low Power and 1175 Lossy Networks", draft-ietf-roll-building-routing-reqs-05 1176 (work in progress), February 2009. 1178 [I-D.ietf-roll-home-routing-reqs] 1179 Porcu, G., "Home Automation Routing Requirements in Low 1180 Power and Lossy Networks", 1181 draft-ietf-roll-home-routing-reqs-06 (work in progress), 1182 November 2008. 1184 [I-D.ietf-roll-indus-routing-reqs] 1185 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 1186 "Industrial Routing Requirements in Low Power and Lossy 1187 Networks", draft-ietf-roll-indus-routing-reqs-04 (work in 1188 progress), January 2009. 1190 [I-D.ietf-roll-terminology] 1191 Vasseur, J., "Terminology in Low power And Lossy 1192 Networks", draft-ietf-roll-terminology-00 (work in 1193 progress), October 2008. 1195 [I-D.ietf-roll-urban-routing-reqs] 1196 Dohler, M., Watteyne, T., Winter, T., Barthel, D., 1197 Jacquenet, C., Madhusudan, G., and G. Chegaray, "Urban 1198 WSNs Routing Requirements in Low Power and Lossy 1199 Networks", draft-ietf-roll-urban-routing-reqs-05 (work in 1200 progress), March 2009. 1202 [I-D.perkins-manet-aodvqos] 1203 Perkins, C. and E. Belding-Royer, "Quality of Service for 1204 Ad hoc On-Demand Distance Vector Routing", 1205 draft-perkins-manet-aodvqos-01 (work in progress), 1206 November 2001. 1208 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1209 RFC 2740, December 1999. 1211 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1212 Demand Distance Vector (AODV) Routing", RFC 3561, 1213 July 2003. 1215 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 1216 Protocol (OLSR)", RFC 3626, October 2003. 1218 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1219 in IPv6", RFC 3775, June 2004. 1221 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1222 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1223 RFC 3963, January 2005. 1225 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1226 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1228 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 1229 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 1230 IPv4", RFC 4728, February 2007. 1232 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1233 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1234 September 2007. 1236 Authors' Addresses 1238 Pascal Thubert 1239 Cisco Systems 1240 Village d'Entreprises Green Side 1241 400, Avenue de Roumanille 1242 Batiment T3 1243 Biot - Sophia Antipolis 06410 1244 FRANCE 1246 Phone: +33 4 97 23 26 34 1247 Email: pthubert@cisco.com 1249 Thomas Watteyne 1250 UC Berkeley 1251 497 Cory Hall #1774 1252 Berkeley Sensor & Actuator Center 1253 Berkeley, California 94720-1774 1254 USA 1256 Phone: +1 (510) 333-4437 1257 Email: watteyne@eecs.berkeley.edu 1259 Zach Shelby 1260 Sensinode 1261 Kidekuja 2 1262 Vuokatti 88600 1263 FINLAND 1265 Phone: +358407796297 1266 Email: zach@sensinode.com 1267 Dominique Barthel 1268 Orange Labs 1269 28 chemin du Vieux Chene, BP98 1270 BP98 1271 Meylan 38243 1272 FRANCE 1274 Phone: +33476764522 1275 Email: dominique.barthel@orange-ftgroup.com