idnits 2.17.00 (12 Aug 2021) /tmp/idnits37360/draft-thubert-tree-discovery-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1155. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 388: '...following values MUST not change durin...' RFC 2119 keyword, line 411: '... receiver MUST silently ignore an...' RFC 2119 keyword, line 424: '... Implementations MUST silently ignore ...' RFC 2119 keyword, line 472: '... MUST be ignored by the receiver....' RFC 2119 keyword, line 651: '...e Mobile Routers MUST obey to the foll...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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: Type, Length, G, H, TreePreference, TreeDelay and TreeID. All other fields of the TIO are updated at each hop of the propagation. -- 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 (August 1, 2008) is 5041 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 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group P. Thubert 3 Internet-Draft Cisco 4 Expires: February 2, 2009 C. Bontoux 5 Fortinet 6 N. Montavont 7 LSIIT - ULP 8 B. McCarthy 9 Lancaster 10 August 1, 2008 12 Nested Nemo Tree Discovery 13 draft-thubert-tree-discovery-07.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 2, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This paper describes a simple distance vector protocol that exposes 47 only a default route towards the infrastructure in a nested NEMO 48 configuration. The draft extends the Neighbor Discovery Protocol [1] 49 in order to carry information and metrics which will help a Mobile 50 Router select its Attachment Router(s) in an autonomous fashion and 51 provides generic rules which guarantee that the interaction of 52 different selection processes will not create loops. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 60 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Multi-Homed nested mobile network . . . . . . . . . . . . 6 62 3.2. Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 7 64 4. Tree Information Option . . . . . . . . . . . . . . . . . . . 9 65 4.1. TIO base option . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. TIO suboptions . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.2.4. Bandwidth Suboption . . . . . . . . . . . . . . . . . 13 71 4.2.5. Stable time Suboption . . . . . . . . . . . . . . . . 14 72 4.2.6. Tree Group ID Suboption . . . . . . . . . . . . . . . 15 73 4.2.7. Path Free Medium Time Suboption . . . . . . . . . . . 15 74 4.2.8. Uniform Path Metric Suboption . . . . . . . . . . . . 16 76 5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 77 5.1. tree selection . . . . . . . . . . . . . . . . . . . . . . 18 78 5.2. Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 19 79 5.3. Administrative depth . . . . . . . . . . . . . . . . . . . 20 80 5.4. DRL entries states and stability . . . . . . . . . . . . . 20 81 5.4.1. Held-Up . . . . . . . . . . . . . . . . . . . . . . . 20 82 5.4.2. Held-Down . . . . . . . . . . . . . . . . . . . . . . 21 83 5.4.3. Collision . . . . . . . . . . . . . . . . . . . . . . 21 84 5.4.4. Instability . . . . . . . . . . . . . . . . . . . . . 22 85 5.4.5. Density . . . . . . . . . . . . . . . . . . . . . . . 23 86 5.5. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 23 88 6. Directed Acyclic Graph Discovery . . . . . . . . . . . . . . . 23 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 9.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 24 96 9.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 24 97 9.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 24 98 9.4. Changes from version 03 to 04 . . . . . . . . . . . . . . 25 99 9.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 25 100 9.6. Changes from version 05 to 06 . . . . . . . . . . . . . . 25 102 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 26 106 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 109 Intellectual Property and Copyright Statements . . . . . . . . . . 28 111 1. Introduction 113 As per Nemo Basic support [3], a Mobile Router autoconfigures a 114 single Care of Address (CoA) to register to its Home Agent and 115 terminate its Mobile Router-Home Agent tunnel. That Care of Address 116 is the Mobile Router point of attachment to the nested Nemo. 118 Consequently, if loops are avoided, the nested Nemo assumes the shape 119 of a tree. The nodes of the tree are Mobile Routers, the root is 120 either a fixed or a Mobile Router, called in the latter case the root 121 Mobile Router in NEMO terminology [4]. The leaves are mobile or 122 fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and 123 Visiting Mobile Nodes in the NEMO terminology. 125 This paper provides (1) a minimum extension to IPv6 Neighbor 126 Discovery Router Advertisements in order to ensure that Mobile 127 Routers attaching to one another actually avoid loops and end up 128 forming a tree, and (2) the minimum common part of all Mobile Router 129 algorithms that is required to ensure that whatever their specific 130 decisions, loops between Mobile Routers will be avoided. 132 The method is based on an autonomous decision by each Mobile Router 133 with no global state convergence such as a MANET proactive routing 134 protocol. In fact, Mobile Routers may make different decisions from 135 a same input, based on their own configuration and their own 136 algorithms. 138 In order to build trees of Mobile Routers, we propose an extension to 139 the ICMP Router Advertisement (RA) message, the Tree Information 140 Option (TIO). The TIO allows Mobile Routers to advertise the tree 141 they belong to, and to select and move to the best location within 142 the available trees. Mobile Routers propagate the TIO in RA down the 143 tree, updating some metrics such as the tree depth, leaving alone 144 root information such as the tree identifier, and sending the result 145 in RAs over the ingress interfaces. 147 2. Terms and Abbreviations 149 This document assumes that the reader is familiar with Mobile IPv6 as 150 defined in [2] and with the concept of Mobile Router defined in the 151 Nemo terminology document [4]. 153 For the needs of this paper, the following new definitions are 154 introduced: 156 Nemo clusterhead: The root of a tree of mobile routers. When the 157 tree of Mobile Routers is attached to the infrastructure, the 158 fixed Access Router may act as cluster head if it supports the 159 Tree Information Option described in this document. If it does 160 not, then the clusterhead coincides with the root Mobile Router in 161 NEMO terminology. A clusterhead is elected even when the tree is 162 not attached to the infrastructure. A stand-alone Mobile Router 163 is a clusterhead. 165 Floating Tree: A Nested Nemo which clusterhead is a Mobile Router 166 that is not attached to an Access Router. 168 Grounded Tree: A Nested Nemo whose clusterhead is attached to the 169 infrastructure. In other words, the clusterhead is either a fixed 170 router that supports Router Advertisement - Tree Information 171 Option or is a Mobile Router which attachment router is a fixed 172 router that does not support Router Advertisement - Tree 173 Information Option. 175 Mobile Access Router: A Mobile Router that provides Access Router 176 services to other Mobile Routers. 178 Attachment Router: The Router that is selected as Access Router by a 179 Mobile Router, making it its parent in the nested NEMO tree. 181 Propagation: The action by a Mobile Router that consists in 182 receiving a Router Advertisement Tree Information Option from its 183 Attachment Router, recomputing a few specific fields, removing 184 unknown suboptions, and appending the resulting TIO to RAs sent 185 over the ingress interfaces. 187 Uniform Path Metric: A multihop metric that can be used by Tree 188 Discovery plug-ins to select feasible successors and specifically 189 an Attachment Router. 191 3. Motivations 193 3.1. Multi-Homed nested mobile network 195 A nested mobile network that is made of multiple Mobile Routers 196 having a direct connection to the Internet is said to be multi-homed. 197 Multihoming in Nemo offers useful properties to Mobile Network Nodes. 198 The NEMO multihoming issues [7] draft lists potential multi-homed 199 configurations for Nemo and explains the different problems and 200 advantages that some configurations may introduce. Multihoming 201 offers three main abilities to the Nemo: it allows route recovery on 202 failure, redundancy and load-sharing between Mobile Routers (or 203 between interfaces of a given Mobile Router). However, for the 204 moment, there is no requirements nor protocol that would define in 205 interaction between several egress interfaces inside a Nemo. 207 In a nested Nemo, the hierarchy of Mobile Routers increases the 208 complexity of the route and/or router selection for Mobile Network 209 Nodes. Each level of a Nemo implies the usage of a new tunnel 210 between the Mobile Router and its home agent. Thus if a Mobile 211 Network Node connects to a sub-Nemo which is also a sub-Nemo, packets 212 from the Mobile Network Node will be encapsulated three times. 214 When the Nemo where the MN is connected to is multi-homed, the MN may 215 have the choice between several Attachment Router to be its default 216 router. Reference [5] introduces new options in Router Advertisement 217 to allow any node on a link to choose between several routers. This 218 option mainly consists of a 2-bits flag that indicates the preference 219 of the router (low, medium or high). Furthermore, the same flag can 220 be set in the Route Information option indicating the preference of a 221 specific prefix. Therefore, any node can determine its best default 222 router(s) according to a given destination and its best router for 223 default, which will be used by default. 225 However this preference is only useful in a flat topology; It gives a 226 way to the node to choose between different attachment routers 227 advertising prefixes on the node link. But if the node is inside a 228 hierarchical topology the node can not learn the depth of each 229 attachment router, and might not select the most efficient path. In 230 particular, there is a need for Uniform Path Metric that accounts for 231 a multihop wireless path. 233 One of the usage of the new option introduced in this document is to 234 distribute information on the hierarchy of Mobile Routers. This 235 information can be distributed to Attachment Routers, Mobile Routers 236 and Mobile Network Nodes as well in order to allow better route 237 selection and to increase the knowledge of the Nemo topology on each 238 node. 240 3.2. Loops in nested Nemo 242 When several Mobile Routers attach to each other to form a nested 243 Nemo, loops can be created if they are not explicitly avoided. In 244 the simplest case, when egress and ingress interfaces of A Mobile 245 Router are all wireless, a mobile router may be listening to Router 246 Advertisement from its own ingress interface, creating a confliction 247 problem. In the general case, arbitrary attachment of Mobile Routers 248 will form graphs that are not exempt of loops. For instance: Assume 249 a nested Nemo where Mobile Router1 is connected to the 250 infrastructure, and Mobile Router3 is attached to Mobile Router2. 252 Say that Mobile Router2 can hear both Mobile Router3 and Mobile 253 Router1 over its wireless egress interface. If Mobile Router2 select 254 Mobile Router1, the connectivity to the infrastructure is provided 255 for all. But if Mobile Router2 selects Mobile Router3, Mobile 256 Router2 and Mobile Router3 end up forming a loop and are disconnected 257 from their Home Agents. 259 With Nemo basic support, a Mobile Router uses a single primary Care 260 Of Address to attach to the nested structure. As a result, if loops 261 are avoided, the nested NEMO end up forming a tree. It is beneficial 262 to be able to form that tree in an optimum fashion for a given set of 263 metrics such as tree depth. 265 The shape of a nested Nemo may change rapidly due to Mobile Routers 266 movement. It is thus impractical to expect each Mobile Router to be 267 able to maintain states about the whole tree structure in a link 268 state fashion. On the contrary, it is also beneficial to allow each 269 Mobile Router to make its own independent selection based on a 270 minimum information about its immediate neighbors, in order to 271 reestablish the tree quickly upon erratic movements. 273 Each Mobile Router should be able to make its own attachment router 274 selection based on its own condition (eg battery level), its own set 275 of constraints that may not apply to other Mobile Routers in the 276 tree, and in general its own algorithm. As a result, the 277 standardization effort should concentrate on a common minimum set of 278 rules that must be common to all Mobile Routers in order to prevent 279 routing loops in the nested NEMO while leaving Mobile Routers 280 independent in their Attachment Router selection algorithms. 282 4. Tree Information Option 284 The Tree Information Option carries a number of metrics and other 285 information that allows a Mobile Router to discover a tree and select 286 its point of attachment while avoiding loop generation. 288 4.1. TIO base option 290 The Tree Information Option is a container option, which might 291 contain a number of suboptions. The base option regroups the minimum 292 information set that is mandatory in all cases. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length |G|H|B| Reserved| Sequence | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | TreePref. | BootTimeRandom | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | MR Preference | TreeDepth | TreeDelay | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | PathDigest | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 + + 307 | TreeID | 308 + + 309 | | 310 + + 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | sub-option(s)... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 1: TIO base option 318 Type: 8-bit unsigned integer set to 10 by the clusterhead. Value is 319 "TBD". 321 Length: 8-bit unsigned integer set to 4 when there is no suboption. 322 The length of the option (including the type and length fields and 323 the suboptions) in units of 8 octets. 325 Grounded (G): The Grounded (G) flag is set when the clusterhead is 326 attached to a fixed network infrastructure (such as the Internet). 328 Home (H): The Home (H) flag is set when the Mobile Router is bound 329 to its home network over NEMO. With NEMO Basic Support,a MR that 330 is not bound Home cuts off its visitors from the Internet as well. 331 This can be solved by techniques such as Reverse Routing Header 332 [8]. 334 Battery (B): The Battery (B) flag is indicates that a parent in the 335 tree operates on batteries, an indication of a costly operation. 336 It is set by a mobile router which operates on battery and when 337 set, it is left set as it is propagated down the tree. 339 Reserved: 5-bit unsigned integer set to 0 by the clusterhead. 341 Sequence Number: 8-bit unsigned integer set by the clusterhead and 342 incremented with each new TIO it sends on a link and propagated 343 with no change down the tree. 345 TreePreference: 8-bit unsigned integer set by the clusterhead to its 346 preference and unchanged at propagation. Default is 0 (lowest 347 preference). The tree preference provides a mechanism to engineer 348 the mesh of mobile routers, for instance indicating the most 349 preferred home gateway or the communication ship in a fleet at 350 sea. 352 BootTimeRandom: A random value computed at boot time and recomputed 353 in case of a duplication with another Attachment Router. The 354 concatenation of the Preference and the BootTimeRandom is a 32-bit 355 extended preference that is used to resolve collisions. It is set 356 by each Mobile Router at propagation time. 358 Preference: The administrative preference of that (mobile) Access 359 Router. Default is 0. 255 is the highest possible preference. 360 Set by each Mobile Router at propagation time. 362 TreeDepth: 8-bit unsigned integer. The tree depth of the 363 clusterhead is 0 if it is a fixed router and 1 if it is a Mobile 364 Router. The tree Depth of a tree Node is the depth of its 365 attachment router as received in a TIO, incremented by at least 366 one. All nodes in the tree advertise their tree depth in the Tree 367 Information Options that they append to the RA messages over their 368 ingress interfaces as part of the propagation process. 370 TreeDelay: 16-bit unsigned integer set by the clusterhead indicating 371 the delay before changing the tree configuration, in milliseconds. 372 A default value is 128ms. It is expected to be an order of 373 magnitude smaller than the RA-interval so if the clusterhead has a 374 sub-second RA-interval, the Tree delay may be shorter than 100ms. 375 It is also expected to be an order of magnitude longer than the 376 typical propagation delay inside the nested Nemo. 378 PathDigest: 32-bit unsigned integer CRC, updated by each Mobile 379 Router. This is the result of a CRC-32c computation on a bit 380 string obtained by appending the received value and the Mobile 381 Router Care of Address. clusterheads use a 'previous value' of 382 zeroes to initially set the PathDigest. 384 TreeID: 128-bit unsigned integer which uniquely identify a tree. 385 This value is set by the clusterhead. The global IPv6 home 386 address of the clusterhead can be used. 388 The following values MUST not change during the propagation of the 389 TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and 390 TreeID. All other fields of the TIO are updated at each hop of the 391 propagation. 393 4.2. TIO suboptions 395 In addition to the minimum options presented in the base option, a 396 number of suboptions are defined for the TIO: 398 4.2.1. Format 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Subopt. Type | Subopt Length | Suboption Data... 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 2: TIO suboption generic format 408 Suboption Type: 8-bit identifier of the type of mobility option. 409 When processing a TIO containing a suboption for which the 410 suboption Type value is not recognized by the receiver, the 411 receiver MUST silently ignore and skip over the suboption, 412 correctly handling any remaining options in the message. 414 Suboption Length: 8-bit unsigned integer, representing the length in 415 octets of the suboption, not including the suboption Type and 416 Length fields. 418 Suboption Data: A variable length field that contains data specific 419 to the option. 421 The following subsections specify the TIO suboptions which are 422 currently defined for use in the Mobility Header. 424 Implementations MUST silently ignore any TIO suboptions options that 425 they do not understand. 427 TIO suboptions may have alignment requirements. Following the 428 convention in IPv6, these options are aligned in a packet so that 429 multi-octet values within the Option Data field of each option fall 430 on natural boundaries (i.e., fields of width n octets are placed at 431 an integer multiple of n octets from the start of the header, for n = 432 1, 2, 4, or 8). 434 4.2.2. Pad1 436 The Pad1 suboption does not have any alignment requirements. Its 437 format is as follows: 439 0 440 0 1 2 3 4 5 6 7 441 +-+-+-+-+-+-+-+-+ 442 | Type = 0 | 443 +-+-+-+-+-+-+-+-+ 445 Figure 3: Pad 1 447 NOTE! the format of the Pad1 option is a special case - it has 448 neither Option Length nor Option Data fields. 450 The Pad1 option is used to insert one octet of padding in the TIO to 451 enable suboptions alignment. If more than one octet of padding is 452 required, the PadN option, described next, should be used rather than 453 multiple Pad1 options. 455 4.2.3. PadN 457 The PadN option does not have any alignment requirements. Its format 458 is as follows: 460 0 1 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 463 | Type = 1 | Subopt Length | Subopt Data 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 466 Figure 4: Pad N 468 The PadN option is used to insert two or more octets of padding in 469 the TIO to enable suboptions alignment. For N (N > 1) octets of 470 padding, the Option Length field contains the value N-2, and the 471 Option Data consists of N-2 zero-valued octets. PadN Option data 472 MUST be ignored by the receiver. 474 4.2.4. Bandwidth Suboption 476 This suboption carries the maximum bandwidth available up the tree 477 via a specific parent. It is the lowest speed of the links on the 478 way and does not reflect the actual use of those links in run time. 479 The value is expressed in the log base 2 of the speed, expressed in 480 bps. The Bandwidth suboption does not have any alignment 481 requirements. Its format is as follows: 483 0 1 2 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 486 | Type = 2 | Length = 1 | Bandwidth | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 489 Figure 5: Bandwidth Suboption 491 Type: Set to 2 for the Bandwidth suboption. 493 Length: Set to 1 for the Bandwidth suboption. 495 Bandwidth: 8-bit unsigned integer. The Log2 of the speed of the 496 path expressed in bps. The clusterhead initializes that field 497 using the speed of the link to the Access Router to which it is 498 attached or 0xFF if it is floating. An attached MR propagates it 499 as the minimum of the Bandwidth as received in the TIO from the 500 parent and the access speed between the MR and the parent. As a 501 result, the value received from a candidate AR is that of the 502 bottleneck between that AR and the wire access. 504 4.2.5. Stable time Suboption 506 This suboption carries an indicator of the stability of a network. 507 This indicator is the time since the branch to which the MR is 508 attached has remained unchanged. The value is expressed in the log 509 base 2 of that duration, expressed in milliseconds. The Stable time 510 suboption does not have any alignment requirements. Its format is as 511 follows: 513 0 1 2 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 516 | Type = 3 | Length = 1 | Stable time | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 519 Figure 6: Stable time 521 Type: Set to 3 for the Stable time suboption. 523 Length: Set to 1 for the Stable time suboption. 525 Stable time: 8-bit unsigned integer. The Log2 of the time since the 526 last change in the attachment branch, expressed in milliseconds. 527 This is set by the MR as it propagates the TIO down the tree, 528 indicating for how long the PathDigest in the TIO from its parent 529 has remained unchanged. 531 4.2.6. Tree Group ID Suboption 533 This suboption carries the Group ID for the tree. It is set by the 534 clusterhead and is left unchanged by the MR that propagates the TIO 535 down the tree. The Tree Group ID Suboption has an alignment 536 requirement of 8n+6. Its format is as follows: 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type = 4 | Length = 16 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 + + 545 | Tree | 546 + Group ID + 547 | | 548 + + 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 7: Tree Group ID Suboption 554 Type: 8-bit unsigned integer. Its value is 4 for the Tree Group ID 555 suboption. 557 Length: 8-bit unsigned integer. Its value is 16 for the Tree Group 558 ID suboption. 560 Tree Group ID: 128-bit unsigned integer which identify a group for a 561 tree. This value is set by the clusterhead. It can be set 562 administratively, for instance to an IPv6 multicast group. 564 4.2.7. Path Free Medium Time Suboption 566 This suboption carries the Free Medium Time available up the tree via 567 a specific parent at a given point of time. It is an indication of 568 whether bandwidth is available to place VoIP calls for instance. As 569 defined by the Quality of Service (QoS) Task Group of the Wi-Fi 570 Alliance, the Medium Time describes the amount of time admitted to 571 access the medium, in units of 32 microsecond periods per second. 573 The Free Medium Time is the amount of time left the medium, in other 574 words ((1000000/32) - SIGMA(MT)). The Path Free Medium Time is the 575 lowest available Free Medium Time along the way and it reflects the 576 actual use of those links in run time. The Path Free Medium Time 577 suboption does not have any alignment requirements. Its format is as 578 follows: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type = 5 | Length = 2 | Path Free Medium Time | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 8: Path Free Medium Time Suboption 588 Type: Set to 5 for the Path Free Medium Time Suboption. 590 Length: Set to 2 for the Path Free Medium Time Suboption. 592 Path Free MT: 16-bit unsigned integer. The amount of Medium Time 593 that is available along the path to the clusterhead in units of 32 594 microsecond periods per second. The clusterhead initializes that 595 field to the Free MT on the link where the TIO is issued. An 596 attached MR propagates it as the minimum of the Path Free MT as 597 received in the TIO from the parent and the Path Free MT on the 598 link on which the TIO is propagated. As a result, the value 599 received from a candidate AR is that of the bottleneck between 600 that AR and the clusterhead. 602 4.2.8. Uniform Path Metric Suboption 604 This suboption carries the Uniform Path Metric (UPM) for the path 605 along the tree. It is set to zero by the clusterhead and incremented 606 as the TIO is propagated down the tree. The Uniform Path Metric 607 Suboption has an alignment requirement of 4n+2. Its format is as 608 follows: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type = 6 | Length = 4 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Uniform Path Metric | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 9: Uniform Path Metric Suboption 620 Type: 8-bit unsigned integer. Its value is 6 for this suboption. 622 Length: 8-bit unsigned integer. Its value is 4 for this suboption. 624 Uniform Path Metric: 32-bit unsigned integer aggregating the cost of 625 radio hops. 627 5. Tree Discovery 629 Tree Discovery is a form of distance vector protocol for use in 630 wireless mesh networks. TD locates the nearest exit and forms a 631 Directed Acyclic Graphs towards that exit, usually a tree. TD 632 enables Mobile Routers to implement different policies for selecting 633 their preferred parent in the Tree by introducing the concept of 634 plug-in, and does not specify the plug-in operation. Rather, TD 635 specifies a set of rules to be implemented by all plug-ins to ensure 636 interoperation. TD also standardizes the format that is used to 637 advertize the most common information that is used by the plug-ins in 638 order to perform the parent selection. 640 One of these information, the tree depth, is used by Tree Discovery 641 to provide loop avoidance between plug-ins even if they implement 642 different policies, and even if these policies do not use the depth 643 as a routing metric. For instance, a MR might use the Uniform Path 644 Metric to select the nearest exit and the best parent from the 645 standpoint of that metric. Once attached to that parent, the MR 646 exposes a depth which is incremented from the parent's depth, and 647 that depth provides a comparable basis with routers which would not 648 use UPM at all. 650 In order organize and maintain loopless structure, the selection 651 plug-ins in the Mobile Routers MUST obey to the following rules and 652 definitions: 654 1. A Mobile Router that is not attached to an Attachment Router is 655 the Nemo clusterhead of its own floating tree. It's depth is 1. 656 A Mobile Router will end up in that situation when it looses its 657 current parent and there is no alternate parent that it can 658 attach to. In that case, the MR remembers the treeID and the 659 sequence counter in the TIO of the lost parent for a period of 660 time which covers multiple TIO. 662 2. A Mobile Router that is attached to an Attachment Router that 663 does not support TIO, is the clusterhead of its own grounded 664 tree. It's depth is 1. 666 3. A router sending a RA without TIO is considered a grounded 667 Attachment Router at depth 0. 669 4. The Nemo clusterhead of a tree exposes the tree in the Router 670 Advertisement Tree Information Option and Mobile Routers 671 propagate the TIO down the tree with the RAs that they forward 672 over their ingress links. 674 5. A Mobile Router that is already part of a tree MAY move at any 675 time and with no delay in order to get closer to the clusterhead 676 of its current tree - i.e. in order to reduce its own tree depth. 677 But A Mobile Router MUST NOT move down the tree that it is 678 attached to. Mobile Routers MUST ignore RAs that are received 679 from other routers located deeper within the same tree. 681 6. A Mobile Router may move from its current tree into any different 682 tree at any time and whatever the depth it reaches in the new 683 tree, but it may have to wait for a Tree Hop timer to elapse in 684 order to do so. If the MR was clusterhead of its own floating 685 tree, it may not join its previous tree (identified by the last 686 parent treeID) unless the sequence number is the TIO was 687 incrememented since the MR left that tree, indicating that the 688 candidate parent was not attached behind this MR and kept getting 689 subsequent TIOs from the same tree. The Mobile Router will join 690 that other tree if it is more preferable for reasons of 691 connectivity, configured preference, free Medium Time, size, 692 security, bandwidth, tree depth, or whatever metrics the Mobile 693 Router cares to use. 695 7. If a Mobile Router has selected a new attachment router but has 696 not moved yet (because it is waiting for Tree Hop timer to 697 elapse), the Mobile Router is unstable and refrains from sending 698 Router Advertisement - Tree Information Options. 700 8. When A Mobile Router joins a tree, moves within its tree, or when 701 it receives a modified TIO from its current attachment router, 702 the Mobile Router sends an unsolicited Router Advertisement 703 message on all its mobile networks (i.e. all its ingress 704 interfaces). The RA contains a TIO that propagates the new tree 705 information. At the same time, the Mobile Router MAY send a 706 Binding Update to its home agent or a local proxy of some sort, 707 because the tree it is attached to has changed. If the Mobile 708 Router fails to reach its Home Agent, it MAY attempt to roll back 709 the movement or to retry the Home Agent discovery procedure. 711 9. This allows the new higher parts of the tree to take place first 712 eventually dragging their sub-tree with them, and allowing 713 stepped sub-tree reconfigurations, limiting relative movements. 715 5.1. tree selection 717 The tree selection is implementation and algorithm dependent. In 718 order to limit erratic movements, and all metrics being equal, Mobile 719 Routers SHOULD stick to their previous selection. Also, Mobile 720 Routers SHOULD provide a mean to filter out candidate Attachment 721 Routers whose availability is detected as fluctuating, at least when 722 more stable choices are available. For instance, the Mobile Router 723 MAY place the failed Attachment Router in a Hold Down mode that 724 ensures that the Attachment Router will not be reused for a given 725 period of time. 727 The known trees are associated with the Attachment Router that 728 advertises them and kept in a list by extending the Default Router 729 List. DRL entries are extended to store the information received 730 from the last TIO. These entries are managed by states and timers 731 described in the next section. 733 When connection to a fixed network is not possible or preferable for 734 security or other reasons, scattered trees should aggregate as much 735 as possible into larger trees in order to allow inner connectivity. 736 How to balance these trees is implementation dependent, and MAY use a 737 specific visitor-counter suboption in the TIO. 739 A Mobile Router SHOULD verify that bidirectional connectivity is 740 available with a candidate Attachment Router before it attaches to 741 that candidate. Some layer 2 such as 802.11 infrastructure mode will 742 provide for this, while others such as 802.11 adhoc mode will not. 743 If the layer 2 does not guarantee the bidirectional connectivity, 744 then the MR needs to make sure that it can reach the AR. This can be 745 achieved using Neighbor Sollicitation and refraining from attaching 746 to an AR for which no neighbor cache exists, or the state is still 747 INCOMPLETE. 749 5.2. Sub-tree mobility 751 It might be perceived as beneficial for a sub-tree to move as a 752 whole. The way it would work is for a Mobile Router to stay 753 clusterhead even if itself is attached into a parent tree. But the 754 loop avoidance is based on the knowledge of the tree that the Mobile 755 Router visit, preventing a Mobile Router to move down a same tree. 756 So without additional support, tree-level loops could form. 758 To avoid this, it is possible to add a path vector suboption to the 759 TIO that reflects the nesting of trees. If a root-Mobile Router 760 joins a parent tree, then it needs to add its treeID to the path 761 vector, but it can not join if the treeID is already listed. 763 A specific case is the root-Mobile Router of a tree that attaches to 764 a fixed Access Router. That root-Mobile Router might omit to 765 consider a TIO that comes from the new Attachment Router and decide 766 to stay root, in order to keep the tree consistency from the nested 767 Mobile Routers standpoint. This does not create loops, even if the 768 path vector is not present 770 5.3. Administrative depth 772 When the tree is formed under a common administration, or when a 773 Mobile Router performs a certain role within a community, it might be 774 beneficial to associate a range of acceptable depth with that MR. 775 For instance, a MR that has limited battery should be a leaf unless 776 there is no other choice, and thus expose an exagerated depth. On 777 the other hane, a MR that is designed for backhaul should operate in 778 a low range of depth. 780 With Tree Discovery, a MR has to expose a depth that is incremented 781 from its parent's depth as receive in the TIO. In particular, a MR 782 might expose a depth which is incremented by more than one from its 783 parent's depth, in order to fit in its own administrative range. So 784 a depth of N does not mean that there is precisely N Mobile Routers 785 on the way, but at most N. 787 5.4. DRL entries states and stability 789 Attachment routers in the DRL may or may not be usable for roaming 790 depending on runtime conditions. The following states are defined: 792 Current This Attachment Router is used for roaming 794 Candidate This Attachment Router can be used for roaming. 796 Held-Up This Attachment Router can not be used till tree hop timer 797 elapses. This does not occur for a fixed Attachment Router that 798 does not send a TIO since the tree delay is null in that case. 800 Held-Down This Attachment Router can not be used till hold down 801 timer elapses. At the end of the hold-down period, the router is 802 removed from the DRL, and will be reinserted if it appears again 803 with a RA. 805 Collision This Attachment Router can not be used till its next RA. 807 5.4.1. Held-Up 809 This state is managed by the tree Hop timer, it serves 2 purposes: 811 Delay the reattachment of a sub-tree that has been forced to 812 detach. This allows to make sure that when a sub-tree has 813 detached, the Router Advertisement - Tree Information Option that 814 is initiated by the new clusterhead has spread down the sub-tree 815 so that two different trees have formed. 817 Limit Router Advertisement - Tree Information Option storms when 818 two trees collide. The idea is that between the nodes from tree A 819 that wish to move to tree B, those that see the highest place in 820 tree B will move first and advertise their new locations before 821 other nodes from tree A actually move. 823 A new tree is discovered upon a router advertisement message with or 824 without a Router Advertisement - Tree Information Option. The Mobile 825 Router joins the tree by selecting the source of the RA message as 826 its attachment router (default gateway) and propagating the TIO 827 accordingly. 829 When a new tree is discovered, the candidate Attachment Router that 830 advertises the new tree is placed in a held up state for the duration 831 of a Tree Hop timer. If the new Attachment Router is more preferable 832 than the current one, the Mobile Router expects to jump and becomes 833 unstable. 835 A Mobile Router that is unstable may discover other Attachment 836 Routers from the same new tree during the instability phase. It 837 needs to start a new Tree Hop timer for all these. The first timer 838 that elapses for a given new tree clears them all for that tree, 839 allowing the Mobile Router to jump to the highest position available 840 in the new tree. 842 The duration of the Tree Hop timer depends on the tree delay of the 843 new tree and on the depth of Attachment Router that triggers it: 845 (AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It 846 is randomized in order to limit collisions and synchronizations. 848 5.4.2. Held-Down 850 When a router is 'removed' from the Default Router List, it is 851 actually held down for a hold down timer period, in order to prevent 852 flapping. This happens when an Attachment Router disappears (upon 853 expiration timer), and when an Attachment Router is tried but can not 854 reach the Home Agent (upon expiration of another Attachment Router, 855 or upon tree hop for that Attachment Router). 857 An Attachment Router that is held down is not considered for the 858 purpose of roaming. When the hold down timer elapses, the Attachment 859 Router is removed from the DRL. 861 5.4.3. Collision 863 A race condition occurs if 2 Mobile Routers send Router Advertisement 864 - Tree Information Option at the same time and wish to join each 865 other. This might happen between routers at a same depth, or routers 866 which act as clusterhead of their own tree. In order to detect the 867 situation, Mobile Routers time stamp the sending of Router 868 Advertisement - Tree Information Option. Any Router Advertisement - 869 Tree Information Option received within a short media-dependant 870 period introduces a risk. To divide the risk, A 32bits extended 871 preference is added in the TIO. The first byte is the clusterhead 872 (tree) preference, the remaining 24 bits is a boot time computed 873 random. 875 A Mobile Router that decides to join an Attachment Router will do so 876 between (Attachment Router depth) and (Attachment Router depth + 1) 877 times the Attachment Router tree delay. But since a Mobile Router is 878 unstable as soon as it receives the Router Advertisement - Tree 879 Information Option from the preferred Attachment Router, it will 880 restrain from sending a Router Advertisement - Tree Information 881 Option between the time it receives the RA and the time it actually 882 jumps. So the crossing of RA may only happen during the propagation 883 time between the Attachment Router and the Mobile Router, plus some 884 internal queuing and processing time within each machine. It is 885 expected that one tree delay normally covers that interval, but 886 ultimately it is up to the implementation and the configuration of 887 the Attachment Router to define the duration of risk window. 889 There is risk of a collision when a Mobile Router receives an RA, for 890 an other mobile router that is more preferable than the current 891 Attachment Router, within the risk window. In the face of a 892 potential collision, the Mobile Router with the lowest extended 893 preference processes the Router Advertisement - Tree Information 894 Option normally, while the router with the highest preference places 895 the other in collision state, does not start the tree hop timer, and 896 does not become instable. It is expected that next RAs between the 897 two will not cross anyway. 899 5.4.4. Instability 901 A Mobile Router is instable when it is prepared to move shortly to 902 another Attachment Router. This happens typically when the Mobile 903 Router has selected a more preferred candidate Attachment Router and 904 has to wait for the tree hop timer to elapse before roaming. 905 Instability may also occur when the current Attachment Router is lost 906 and the next best is still held up. Instability is resolved when the 907 tree hop timer of all the Attachment Router (s) causing instability 908 elapse. Such Attachment Router is changes state to Current or Held- 909 Down. 911 Instability is transient (in the order of tree hop timers). When a 912 Mobile Router is unstable, it MUST NOT send RAs with TIO. This 913 avoids loops when Mobile Router A wishes to attach to Mobile Router B 914 and Mobile Router B wishes to attach to Mobile Router A. Unless RA 915 cross (see Collision section), a Mobile Router receives TIO from 916 stable Attachment Routers, which do not plan to attach to itself, so 917 the Mobile Router can safely attach to them. 919 5.4.5. Density 921 In a dense environment, it is useless that all routers that can 922 provide backhauling service actually do so; in practice, limiting the 923 number of routers that accept visitors saves memory in the visitors 924 and reduces the cost of signalling. Also, limiting the number of 925 nodes (mobile routers that is) in the tree improves the multicast 926 operations. 928 Algorithms such a Trickle could be used by a Mobile Router to decide 929 to stop providing its access services for visitors if there are a 930 number of neighboring routers that provide similar services. The 931 simplest abstraction of such similarity is that a multiple routers 932 advertising a same depth, though such a simple similarity does not 933 address the specifics of a router selection in the plugins. In a 934 more general fashion, a Mobile Router can associate the concept of 935 similarity with the characteristics of its own attachment router 936 selection plug in. 938 5.5. Legacy Routers 940 A legacy router sends its Router Advertisements without a TIO. 941 Consequently, a legacy router can be mistaken for a fixed Access 942 Router when it is placed within a nested NEMO structure, and defeat 943 the loop avoidance mechanism. Consequently, it is important for the 944 administrator to prevent address autoconfiguration by visiting Mobile 945 Routers from such a legacy router. 947 6. Directed Acyclic Graph Discovery 949 Tree Discovery builds trees, which are a specific form of a Directed 950 Acyclic Graph (DAG). In a more general Fashion, TD can be adapted to 951 form DAGs, oriented towards the clusterhead. This is DAG Discovery. 953 In Section 5.3, TD enables a given MR to expose a depth that is 954 incremented by more than one with regards to its parent. When it 955 does so, a MR can elect a number of alternate parents as feasible 956 successors. A feasible successor belongs to the same tree as the MR 957 parent, and has a depth that is less than that of the MR. 959 The links MR to feasible successors complete the tree as built by TD 960 into a DAG towards the clusterhead. The DAG enables alternate exit 961 paths for a multihomed Mobile Router. 963 7. IANA Considerations 965 Section 4.1. requires the definition of a new option to Neighbor 966 discovery [1] messages, the Router Advertisement - Tree Information 967 Option (RA-TIO). The Router Advertisement - Tree Information Option 968 has been assigned the value TBD within the numbering space for IPv6 969 Neighbor Discovery Option Formats. 971 8. Security Considerations 973 At the current level of this draft, the TIO bears the security level 974 of the RA and the link. Nothing is added to it. A deeper threat 975 analysis would be required to eventually propose additional security. 977 9. Changes 979 9.1. Changes from version 00 to 01 981 Added text on sub-tree mobility from the discussion with Marcelo. 983 Added text on nested legacy routers from the discussion with 984 Marcelo. 986 9.2. Changes from version 01 to 02 988 Improved text on instability 990 Changed the formula for the 4 bytes number used in collision 991 avoidance 993 9.3. Changes from version 02 to 03 995 Added suboptions for tree group, stable time and bandwidth. 997 Added administrative depth and increment by more than 1. 999 Added words on bidirectional check using ND. 1001 Added DAG discovery. 1003 9.4. Changes from version 03 to 04 1005 Added suboptions for Path Free Medium Time. 1007 9.5. Changes from version 04 to 05 1009 Added a sequence counter which provides additional loop protection 1010 based on a comment by Christipher Dearlove. For the sake of the 1011 discussion, note that if a loop were to occur, the count to 1012 infinity would actually cause the MR taht reaches the max depth to 1013 detach and that would resolve the issue anyway. 1015 9.6. Changes from version 05 to 06 1017 Added the Uniform Path Metric. Removed the N bit in RA and 1018 changed the semantics of the H bit in TIO. Added some test at teh 1019 beginning of the Tree Discovery section to explain the role of the 1020 depth vs. the plug-ins. 1022 10. Acknowledgments 1024 The authors wish to thank Marco Molteni and Patrick Wetterwald 1025 (cisco) for their participation to this design and the review of the 1026 document, Massimo Villari (university of Messina), for his early work 1027 on simulation and research on the subject and Julien Abeille for his 1028 advanced participation in simulation and real testing. Also the 1029 authors wish to thank Christopher Dearlove for his suggestion for 1030 additional protection against loops in TD, and Philip Levis, David 1031 Cueller and Jonathan Hui for the suggestions about Trickle. This 1032 work is also based on prior publications, in particular HMRA [6] by 1033 Hosik Cho and Eun-Kyoung Paik from Seoul National University and 1034 other non IETF publications coauthored with Thierry Ernst and Thomas 1035 Noel. Finally, the authors heartily thank Marcelo Bagnulo Braun and 1036 Teco Boot for their very constructive reviews. 1038 11. References 1040 11.1. Normative Reference 1042 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1043 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1045 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1046 IPv6", RFC 3775, June 2004. 1048 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1049 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1050 January 2005. 1052 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1053 draft-ietf-nemo-terminology-06 (work in progress), 1054 November 2006. 1056 [5] Draves, R. and D. Thaler, "Default Router Preferences and More- 1057 Specific Routes", RFC 4191, November 2005. 1059 11.2. Informative Reference 1061 [6] Cho, H., "Hierarchical Mobile Router Advertisement for nested 1062 mobile networks", draft-cho-nemo-hmra-00 (work in progress), 1063 January 2004. 1065 [7] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1066 draft-ietf-nemo-multihoming-issues-07 (work in progress), 1067 February 2007. 1069 [8] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its 1070 application to Mobile Networks", 1071 draft-thubert-nemo-reverse-routing-header-07 (work in progress), 1072 February 2007. 1074 Authors' Addresses 1076 Pascal Thubert 1077 Cisco Systems 1078 Village d'Entreprises Green Side 1079 400, Avenue de Roumanille 1080 Batiment T3 1081 Biot - Sophia Antipolis 06410 1082 FRANCE 1084 Phone: +33 4 97 23 26 34 1085 Email: pthubert@cisco.com 1087 Caroline Bontoux 1088 Fortinet 1089 Sophia Antipolis 1090 Biot 06410 1091 FRANCE 1093 Email: cbontoux@fortinet.com 1095 Nicolas Montavont 1096 LSIIT - Univerity Louis Pasteur 1097 Pole API, bureau C444 1098 Boulevard Sebastien Brant 1099 Illkirch 67400 1100 FRANCE 1102 Phone: (33) 3 90 24 45 87 1103 Email: montavont@dpt-info.u-strasbg.fr 1104 URI: http://www-r2.u-strasbg.fr/~montavont/ 1106 Ben McCarthy 1107 Lancaster University 1108 Computing Department 1109 Infolab21, South Drive 1110 Lancaster University 1111 Lancaster LA1 4WA 1112 UK 1114 Phone: +44 1524 510 383 1115 Email: b.mccarthy@lancaster.ac.uk 1117 Full Copyright Statement 1119 Copyright (C) The IETF Trust (2008). 1121 This document is subject to the rights, licenses and restrictions 1122 contained in BCP 78, and except as set forth therein, the authors 1123 retain all their rights. 1125 This document and the information contained herein are provided on an 1126 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1127 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1128 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1129 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1130 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1131 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1133 Intellectual Property 1135 The IETF takes no position regarding the validity or scope of any 1136 Intellectual Property Rights or other rights that might be claimed to 1137 pertain to the implementation or use of the technology described in 1138 this document or the extent to which any license under such rights 1139 might or might not be available; nor does it represent that it has 1140 made any independent effort to identify any such rights. Information 1141 on the procedures with respect to rights in RFC documents can be 1142 found in BCP 78 and BCP 79. 1144 Copies of IPR disclosures made to the IETF Secretariat and any 1145 assurances of licenses to be made available, or the result of an 1146 attempt made to obtain a general license or permission for the use of 1147 such proprietary rights by implementers or users of this 1148 specification can be obtained from the IETF on-line IPR repository at 1149 http://www.ietf.org/ipr. 1151 The IETF invites any interested party to bring to its attention any 1152 copyrights, patents or patent applications, or other proprietary 1153 rights that may cover technology that may be required to implement 1154 this standard. Please address the information to the IETF at 1155 ietf-ipr@ietf.org. 1157 Acknowledgment 1159 Funding for the RFC Editor function is provided by the IETF 1160 Administrative Support Activity (IASA).