idnits 2.17.1 draft-thubert-tree-discovery-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1092. 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 320: '... Router MUST set the N flag of its o...' RFC 2119 keyword, line 414: '...following values MUST not change durin...' RFC 2119 keyword, line 437: '... receiver MUST silently ignore an...' RFC 2119 keyword, line 450: '... Implementations MUST silently ignore ...' RFC 2119 keyword, line 498: '... MUST be ignored by the receiver....' (12 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 (April 5, 2007) is 6224 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) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 Summary: 6 errors (**), 0 flaws (~~), 4 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: October 7, 2007 C. Bontoux 5 Fortinet 6 N. Montavont 7 LSIIT - ULP 8 April 5, 2007 10 Nested Nemo Tree Discovery 11 draft-thubert-tree-discovery-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 7, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This paper describes a simple distance vector protocol that exposes 45 only a default route towards the infrastructure in a nested NEMO 46 configuration. The draft extends the Neighbor Discovery Protocol [1] 47 in order to carry information and metrics which will help a Mobile 48 Router select its Attachment Router(s) in an autonomous fashion and 49 provides generic rules which guarantee that the interaction of 50 different selection processes will not create loops. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 58 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Multi-Homed nested mobile network . . . . . . . . . . . . 5 60 3.2. Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 6 62 4. Router Advertisement extensions . . . . . . . . . . . . . . . 8 63 4.1. Router Advertisement message . . . . . . . . . . . . . . . 8 64 4.2. Tree Information Option . . . . . . . . . . . . . . . . . 8 65 4.3. TIO suboption . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.3.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.4. Bandwidth Suboption . . . . . . . . . . . . . . . . . 12 70 4.3.5. Stable time Suboption . . . . . . . . . . . . . . . . 13 71 4.3.6. Tree Group ID Suboption . . . . . . . . . . . . . . . 14 72 4.3.7. Path Free Medium Time Suboption . . . . . . . . . . . 14 74 5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.1. tree selection . . . . . . . . . . . . . . . . . . . . . . 17 76 5.2. Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 18 77 5.3. Administrative depth . . . . . . . . . . . . . . . . . . . 18 78 5.4. DRL entries states and stability . . . . . . . . . . . . . 18 79 5.4.1. Held-Up . . . . . . . . . . . . . . . . . . . . . . . 19 80 5.4.2. Held-Down . . . . . . . . . . . . . . . . . . . . . . 20 81 5.4.3. Collision . . . . . . . . . . . . . . . . . . . . . . 20 82 5.4.4. Instability . . . . . . . . . . . . . . . . . . . . . 21 83 5.5. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 21 85 6. Directed Acyclic Graph Discovery . . . . . . . . . . . . . . . 21 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 9.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 22 93 9.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 22 94 9.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 22 95 9.4. Changes from version 03 to 04 . . . . . . . . . . . . . . 23 96 9.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 23 98 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 24 102 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 105 Intellectual Property and Copyright Statements . . . . . . . . . . 26 107 1. Introduction 109 As per Nemo Basic support [3], a Mobile Router autoconfigures a 110 single Care of Address (CoA) to register to its Home Agent and 111 terminate its Mobile Router-Home Agent tunnel. That Care of Address 112 is the Mobile Router point of attachment to the nested Nemo. 114 Consequently, if loops are avoided, the nested Nemo assumes the shape 115 of a tree. The nodes of the tree are Mobile Routers, the root is 116 either a fixed or a Mobile Router, called in the latter case the root 117 Mobile Router in NEMO terminology [4]. The leaves are mobile or 118 fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and 119 Visiting Mobile Nodes in the NEMO terminology. 121 This paper provides (1) a minimum extension to IPv6 Neighbor 122 Discovery Router Advertisements in order to ensure that Mobile 123 Routers attaching to one another actually avoid loops and end up 124 forming a tree, and (2) the minimum common part of all Mobile Router 125 algorithms that is required to ensure that whatever their specific 126 decisions, loops between Mobile Routers will be avoided. 128 The method is based on an autonomous decision by each Mobile Router 129 with no global state convergence such as a MANET proactive routing 130 protocol. In fact, Mobile Routers may make different decisions from 131 a same input, based on their own configuration and their own 132 algorithms. 134 In order to build trees of Mobile Routers, we propose an extension to 135 the ICMP Router Advertisement (RA) message, the Tree Information 136 Option (TIO). The TIO allows Mobile Routers to advertise the tree 137 they belong to, and to select and move to the best location within 138 the available trees. Mobile Routers propagate the TIO in RA down the 139 tree, updating some metrics such as the tree depth, leaving alone 140 root information such as the tree identifier, and sending the result 141 in RAs over the ingress interfaces. 143 2. Terms and Abbreviations 145 This document assumes that the reader is familiar with Mobile IPv6 as 146 defined in [2] and with the concept of Mobile Router defined in the 147 Nemo terminology document [4]. 149 For the needs of this paper, the following new definitions are 150 introduced: 152 Nemo clusterhead: The root of a tree of mobile routers. When the 153 tree of Mobile Routers is attached to the infrastructure, the 154 fixed Access Router may act as cluster head if it supports the 155 Tree Information Option described in this document. If it does 156 not, then the clusterhead coincides with the root Mobile Router in 157 NEMO terminology. A clusterhead is elected even when the tree is 158 not attached to the infrastructure. A stand-alone Mobile Router 159 is a clusterhead. 161 Floating Tree: A Nested Nemo which clusterhead is a Mobile Router 162 that is not attached to an Access Router. 164 Grounded Tree: A Nested Nemo whose clusterhead is attached to the 165 infrastructure. In other words, the clusterhead is either a fixed 166 router that supports Router Advertisement - Tree Information 167 Option or is a Mobile Router which attachment router is a fixed 168 router that does not support Router Advertisement - Tree 169 Information Option. 171 Mobile Access Router: A Mobile Router that provides Access Router 172 services to other Mobile Routers. 174 Attachment Router: The Router that is selected as Access Router by a 175 Mobile Router, making it its parent in the nested NEMO tree. 177 Propagation: The action by a Mobile Router that consists in 178 receiving a Router Advertisement Tree Information Option from its 179 Attachment Router, recomputing a few specific fields, removing 180 unknown suboptions, and appending the resulting TIO to RAs sent 181 over the ingress interfaces. 183 3. Motivations 185 3.1. Multi-Homed nested mobile network 187 A nested mobile network that is made of multiple Mobile Routers 188 having a direct connection to the Internet is said to be multi-homed. 189 Multihoming in Nemo offers useful properties to Mobile Network Nodes. 190 The NEMO multihoming issues [7] draft lists potential multi-homed 191 configurations for Nemo and explains the different problems and 192 advantages that some configurations may introduce. Multihoming 193 offers three main abilities to the Nemo: it allows route recovery on 194 failure, redundancy and load-sharing between Mobile Routers (or 195 between interfaces of a given Mobile Router). However, for the 196 moment, there is no requirements nor protocol that would define in 197 interaction between several egress interfaces inside a Nemo. 199 In a nested Nemo, the hierarchy of Mobile Routers increases the 200 complexity of the route and/or router selection for Mobile Network 201 Nodes. Each level of a Nemo implies the usage of a new tunnel 202 between the Mobile Router and its home agent. Thus if a Mobile 203 Network Node connects to a sub-Nemo which is also a sub-Nemo, packets 204 from the Mobile Network Node will be encapsulated three times. 206 When the Nemo where the MN is connected to is multi-homed, the MN may 207 have the choice between several Attachment Router to be its default 208 router. Reference [5] introduces new options in Router Advertisement 209 to allow any node on a link to choose between several routers. This 210 option mainly consists of a 2-bits flag that indicates the preference 211 of the router (low, medium or high). Furthermore, the same flag can 212 be set in the Route Information option indicating the preference of a 213 specific prefix. Therefore, any node can determine its best default 214 router(s) according to a given destination and its best router for 215 default, which will be used by default. 217 However this preference is only useful in a flat topology; It gives a 218 way to the node to choose between different attachment routers 219 advertising prefixes on the node link. But if the node is inside a 220 hierarchical topology the node can not learn the depth of each 221 attachment router, and might not select the most efficient path. 223 One of the usage of the new option introduced in this document is to 224 distribute information on the hierarchy of Mobile Routers. This 225 information can be distributed to Attachment Routers, Mobile Routers 226 and Mobile Network Nodes as well in order to allow better route 227 selection and to increase the knowledge of the Nemo topology on each 228 node. 230 3.2. Loops in nested Nemo 232 When several Mobile Routers attach to each other to form a nested 233 Nemo, loops can be created if they are not explicitly avoided. In 234 the simplest case, when egress and ingress interfaces of A Mobile 235 Router are all wireless, a mobile router may be listening to Router 236 Advertisement from its own ingress interface, creating a confliction 237 problem. In the general case, arbitrary attachment of Mobile Routers 238 will form graphs that are not exempt of loops. For instance: Assume 239 a nested Nemo where Mobile Router1 is connected to the 240 infrastructure, and Mobile Router3 is attached to Mobile Router2. 241 Say that Mobile Router2 can hear both Mobile Router3 and Mobile 242 Router1 over its wireless egress interface. If Mobile Router2 select 243 Mobile Router1, the connectivity to the infrastructure is provided 244 for all. But if Mobile Router2 selects Mobile Router3, Mobile 245 Router2 and Mobile Router3 end up forming a loop and are disconnected 246 from their Home Agents. 248 With Nemo basic support, a Mobile Router uses a single primary Care 249 Of Address to attach to the nested structure. As a result, if loops 250 are avoided, the nested NEMO end up forming a tree. It is beneficial 251 to be able to form that tree in an optimum fashion for a given set of 252 metrics such as tree depth. 254 The shape of a nested Nemo may change rapidly due to Mobile Routers 255 movement. It is thus impractical to expect each Mobile Router to be 256 able to maintain states about the whole tree structure in a link 257 state fashion. On the contrary, it is also beneficial to allow each 258 Mobile Router to make its own independent selection based on a 259 minimum information about its immediate neighbors, in order to 260 reestablish the tree quickly upon erratic movements. 262 Each Mobile Router should be able to make its own attachment router 263 selection based on its own condition (eg battery level), its own set 264 of constraints that may not apply to other Mobile Routers in the 265 tree, and in general its own algorithm. As a result, the 266 standardization effort should concentrate on a common minimum set of 267 rules that must be common to all Mobile Routers in order to prevent 268 routing loops in the nested NEMO while leaving Mobile Routers 269 independent in their Attachment Router selection algorithms. 271 4. Router Advertisement extensions 273 New extensions of Router Advertisement are proposed to distribute the 274 knowledge of the Mobile Router hierarchy inside a nested Nemo. These 275 extensions are defined in different options/sub-options: a flag bit 276 from the reserved flag field of Router Advertisement message is used 277 to indicate whether the sending router is a Mobile Router or not; a 278 new option is defined to transport minimum information on the tree to 279 avoid loops generation; 281 4.1. Router Advertisement message 283 We propose to use a reserved flag of the Router Advertisement message 284 to inform whether the sending router is a Mobile Router or not. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Code | Checksum | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Reachable Time | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Retrans Timer | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Options ... 298 +-+-+-+-+-+-+-+-+-+-+-+- 300 Figure 1: Router Advertisement 302 Nemo enabled router (N) 304 The Nemo enabled router (N) bit is set when the sending router is a 305 Mobile Router. 307 4.2. Tree Information Option 309 The Tree Information Option carries a number of metrics and other 310 information that allows a Mobile Router to discover a tree and select 311 its point of attachment while avoiding loop generation. 313 The option is a container option, which might contain a number of 314 suboptions. The base option regroups the minimum information set 315 that is mandatory in all cases. 317 A TIO can also be used by Mobile Network Nodes to select their best 318 default router. If the default router of a non-Mobile Router sends 319 Router Advertisements with a Tree Information Option, the non-Mobile 320 Router MUST set the N flag of its own Router Advertisement to 0 and 321 copy the Tree Discovery Option in its own Router Advertisement. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length |G|H|B| Reserved| Sequence | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | TreePref. | BootTimeRandom | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | MR Preference | TreeDepth | TreeDelay | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | PathDigest | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 + + 336 | TreeID | 337 + + 338 | | 339 + + 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | sub-option(s)... 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 2: RA Tree Information Option 347 Type: 8-bit unsigned integer set to 10 by the clusterhead. Value is 348 "TBD". 350 Length: 8-bit unsigned integer set to 4 when there is no suboption. 351 The length of the option (including the type and length fields and 352 the suboptions) in units of 8 octets. 354 Grounded (G): The Grounded (G) flag is set when the clusterhead is 355 attached to a fixed network infrastructure (such as the Internet). 357 Home (H): The Home (H) flag is set when the clusterhead is attached 358 to its home network. 360 Battery (B): The Battery (B) flag is indicates that a parent in the 361 tree operates on batteries, an indication of a costly operation. 362 It is set by a mobile router which operates on battery and when 363 set, it is left set as it is propagated down the tree. 365 Reserved: 13-bit unsigned integer set to 0 by the clusterhead. 367 Sequence Number: 8-bit unsigned integer set by the clusterhead and 368 incremented with each new TIO it sends on a link and propagated 369 with no change down the tree. 371 TreePreference: 8-bit unsigned integer set by the clusterhead to its 372 preference and unchanged at propagation. Default is 0 (lowest 373 preference). The tree preference provides a mechanism to engineer 374 the mesh of mobile routers, for instance indicating the most 375 preferred home gateway or the communication ship in a fleet at 376 sea. 378 BootTimeRandom: A random value computed at boot time and recomputed 379 in case of a duplication with another Attachment Router. The 380 concatenation of the Preference and the BootTimeRandom is a 32-bit 381 extended preference that is used to resolve collisions. It is set 382 by each Mobile Router at propagation time. 384 Preference: The administrative preference of that (mobile) Access 385 Router. Default is 0. 255 is the highest possible preference. 386 Set by each Mobile Router at propagation time. 388 TreeDepth: 8-bit unsigned integer. The tree depth of the 389 clusterhead is 0 if it is a fixed router and 1 if it is a Mobile 390 Router. The tree Depth of a tree Node is the depth of its 391 attachment router as received in a TIO, incremented by at least 392 one. All nodes in the tree advertise their tree depth in the Tree 393 Information Options that they append to the RA messages over their 394 ingress interfaces as part of the propagation process. 396 TreeDelay: 16-bit unsigned integer set by the clusterhead indicating 397 the delay before changing the tree configuration, in milliseconds. 398 A default value is 128ms. It is expected to be an order of 399 magnitude smaller than the RA-interval so if the clusterhead has a 400 sub-second RA-interval, the Tree delay may be shorter than 100ms. 401 It is also expected to be an order of magnitude longer than the 402 typical propagation delay inside the nested Nemo. 404 PathDigest: 32-bit unsigned integer CRC, updated by each Mobile 405 Router. This is the result of a CRC-32c computation on a bit 406 string obtained by appending the received value and the Mobile 407 Router Care of Address. clusterheads use a 'previous value' of 408 zeroes to initially set the PathDigest. 410 TreeID: 128-bit unsigned integer which uniquely identify a tree. 411 This value is set by the clusterhead. The global IPv6 home 412 address of the clusterhead can be used. 414 The following values MUST not change during the propagation of the 415 TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and 416 TreeID. All other fields of the TIO are updated at each hop of the 417 propagation. 419 4.3. TIO suboption 421 In addition to the minimum options presented in the base option, a 422 number of suboptions are defined for the TIO: 424 4.3.1. Format 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Subopt. Type | Subopt Length | Suboption Data... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3: TIO suboption generic format 434 Suboption Type: 8-bit identifier of the type of mobility option. 435 When processing a TIO containing a suboption for which the 436 suboption Type value is not recognized by the receiver, the 437 receiver MUST silently ignore and skip over the suboption, 438 correctly handling any remaining options in the message. 440 Suboption Length: 8-bit unsigned integer, representing the length in 441 octets of the suboption, not including the suboption Type and 442 Length fields. 444 Suboption Data: A variable length field that contains data specific 445 to the option. 447 The following subsections specify the TIO suboptions which are 448 currently defined for use in the Mobility Header. 450 Implementations MUST silently ignore any TIO suboptions options that 451 they do not understand. 453 TIO suboptions may have alignment requirements. Following the 454 convention in IPv6, these options are aligned in a packet so that 455 multi-octet values within the Option Data field of each option fall 456 on natural boundaries (i.e., fields of width n octets are placed at 457 an integer multiple of n octets from the start of the header, for n = 458 1, 2, 4, or 8). 460 4.3.2. Pad1 462 The Pad1 suboption does not have any alignment requirements. Its 463 format is as follows: 465 0 466 0 1 2 3 4 5 6 7 467 +-+-+-+-+-+-+-+-+ 468 | Type = 0 | 469 +-+-+-+-+-+-+-+-+ 471 Figure 4: Pad 1 473 NOTE! the format of the Pad1 option is a special case - it has 474 neither Option Length nor Option Data fields. 476 The Pad1 option is used to insert one octet of padding in the TIO to 477 enable suboptions alignment. If more than one octet of padding is 478 required, the PadN option, described next, should be used rather than 479 multiple Pad1 options. 481 4.3.3. PadN 483 The PadN option does not have any alignment requirements. Its format 484 is as follows: 486 0 1 487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 489 | Type = 1 | Subopt Length | Subopt Data 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 492 Figure 5: Pad N 494 The PadN option is used to insert two or more octets of padding in 495 the TIO to enable suboptions alignment. For N (N > 1) octets of 496 padding, the Option Length field contains the value N-2, and the 497 Option Data consists of N-2 zero-valued octets. PadN Option data 498 MUST be ignored by the receiver. 500 4.3.4. Bandwidth Suboption 502 This suboption carries the maximum bandwidth available up the tree 503 via a specific parent. It is the lowest speed of the links on the 504 way and does not reflect the actual use of those links in run time. 505 The value is expressed in the log base 2 of the speed, expressed in 506 bps. The Bandwidth suboption does not have any alignment 507 requirements. Its format is as follows: 509 0 1 2 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 512 | Type = 2 | Length = 1 | Bandwidth | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 515 Figure 6: Bandwidth Suboption 517 Type: Set to 2 for the Bandwidth suboption. 519 Length: Set to 1 for the Bandwidth suboption. 521 Bandwidth: 8-bit unsigned integer. The Log2 of the speed of the 522 path expressed in bps. The clusterhead initializes that field 523 using the speed of the link to the Access Router to which it is 524 attached or 0xFF if it is floating. An attached MR propagates it 525 as the minimum of the Bandwidth as received in the TIO from the 526 parent and the access speed between the MR and the parent. As a 527 result, the value received from a candidate AR is that of the 528 bottleneck between that AR and the wire access. 530 4.3.5. Stable time Suboption 532 This suboption carries an indicator of the stability of a network. 533 This indicator is the time since the branch to which the MR is 534 attached has remained unchanged. The value is expressed in the log 535 base 2 of that duration, expressed in milliseconds. The Stable time 536 suboption does not have any alignment requirements. Its format is as 537 follows: 539 0 1 2 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 542 | Type = 3 | Length = 1 | Stable time | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 545 Figure 7: Stable time 547 Type: Set to 3 for the Stable time suboption. 549 Length: Set to 1 for the Stable time suboption. 551 Stable time: 8-bit unsigned integer. The Log2 of the time since the 552 last change in the attachment branch, expressed in milliseconds. 553 This is set by the MR as it propagates the TIO down the tree, 554 indicating for how long the PathDigest in the TIO from its parent 555 has remained unchanged. 557 4.3.6. Tree Group ID Suboption 559 This suboption carries the Group ID for the tree. It is set by the 560 clusterhead and is left unchanged by the MR that propagates the TIO 561 down the tree. The Tree Group ID Suboption has an alignment 562 requirement of 8n+6. Its format is as follows: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type = 4 | Length = 16 | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 + + 571 | Tree | 572 + Group ID + 573 | | 574 + + 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 8: Tree Group ID Suboption 580 Type: 8-bit unsigned integer. Its value is 4 for the Tree Group ID 581 suboption. 583 Length: 8-bit unsigned integer. Its value is 16 for the Tree Group 584 ID suboption. 586 Tree Group ID: 128-bit unsigned integer which identify a group for a 587 tree. This value is set by the clusterhead. It can be set 588 administratively, for instance to an IPv6 multicast group. 590 4.3.7. Path Free Medium Time Suboption 592 This suboption carries the Free Medium Time available up the tree via 593 a specific parent at a given point of time. It is an indication of 594 whether bandwidth is available to place VoIP calls for instance. As 595 defined by the Quality of Service (QoS) Task Group of the Wi-Fi 596 Alliance, the Medium Time describes the amount of time admitted to 597 access the medium, in units of 32 microsecond periods per second. 599 The Free Medium Time is the amount of time left the medium, in other 600 words ((1000000/32) - SIGMA(MT)). The Path Free Medium Time is the 601 lowest available Free Medium Time along the way and it reflects the 602 actual use of those links in run time. 604 The Path Free Medium Time suboption does not have any alignment 605 requirements. Its format is as follows: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type = 5 | Length = 2 | Path Free Medium Time | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 9: Path Free Medium Time Suboption 615 Type: Set to 5 for the Path Free Medium Time Suboption. 617 Length: Set to 2 for the Path Free Medium Time Suboption. 619 Path Free MT: 16-bit unsigned integer. The amount of Medium Time 620 that is available along the path to the clusterhead in units of 32 621 microsecond periods per second. The clusterhead initializes that 622 field to the Free MT on the link where the TIO is issued. An 623 attached MR propagates it as the minimum of the Path Free MT as 624 received in the TIO from the parent and the Path Free MT on the 625 link on which the TIO is propagated. As a result, the value 626 received from a candidate AR is that of the bottleneck between 627 that AR and the clusterhead. 629 5. Tree Discovery 631 Here follows a set of rules and definitions that MUST be followed by 632 all Mobile Routers: 634 1. A Mobile Router that is not attached to an Attachment Router is 635 the Nemo clusterhead of its own floating tree. It's depth is 1. 636 A Mobile Router will end up in that situation when it looses its 637 current parent and there is no alternate parent that it can 638 attach to. In that case, the MR remembers the treeID and the 639 sequence counter in the TIO of the lost parent for a period of 640 time which covers multiple TIO. 642 2. A Mobile Router that is attached to an Attachment Router that 643 does not support TIO, is the clusterhead of its own grounded 644 tree. It's depth is 1. 646 3. A router sending a RA without TIO is considered a grounded 647 Attachment Router at depth 0. 649 4. The Nemo clusterhead of a tree exposes the tree in the Router 650 Advertisement Tree Information Option and Mobile Routers 651 propagate the TIO down the tree with the RAs that they forward 652 over their ingress links. 654 5. A Mobile Router that is already part of a tree MAY move at any 655 time and with no delay in order to get closer to the clusterhead 656 of its current tree - i.e. in order to reduce its own tree depth. 657 But A Mobile Router MUST NOT move down the tree that it is 658 attached to. Mobile Routers MUST ignore RAs that are received 659 from other routers located deeper within the same tree. 661 6. A Mobile Router may move from its current tree into any different 662 tree at any time and whatever the depth it reaches in the new 663 tree, but it may have to wait for a Tree Hop timer to elapse in 664 order to do so. If the MR was clusterhead of its own floating 665 tree, it may not join its previous identified by the last parent 666 treeID tree unless the sequence number is the TIO was 667 incrememented since the MR left that tree, indicating that the 668 candidate parent was not attached behind this MR and kept getting 669 subsequent TIOs from the same tree. The Mobile Router will join 670 that other tree if it is more preferable for reasons of 671 connectivity, configured preference, free Medium Time, size, 672 security, bandwidth, tree depth, or whatever metrics the Mobile 673 Router cares to use. 675 7. If a Mobile Router has selected a new attachment router but has 676 not moved yet (because it is waiting for Tree Hop timer to 677 elapse), the Mobile Router is unstable and refrains from sending 678 Router Advertisement - Tree Information Options. 680 8. When A Mobile Router joins a tree, moves within its tree, or when 681 it receives a modified TIO from its current attachment router, 682 the Mobile Router sends an unsolicited Router Advertisement 683 message on all its mobile networks (i.e. all its ingress 684 interfaces). The RA contains a TIO that propagates the new tree 685 information. At the same time, the Mobile Router MAY send a 686 Binding Update to its home agent or a local proxy of some sort, 687 because the tree it is attached to has changed. If the Mobile 688 Router fails to reach its Home Agent, it MAY attempt to roll back 689 the movement or to retry the Home Agent discovery procedure. 691 9. This allows the new higher parts of the tree to take place first 692 eventually dragging their sub-tree with them, and allowing 693 stepped sub-tree reconfigurations, limiting relative movements. 695 5.1. tree selection 697 The tree selection is implementation and algorithm dependent. In 698 order to limit erratic movements, and all metrics being equal, Mobile 699 Routers SHOULD stick to their previous selection. Also, Mobile 700 Routers SHOULD provide a mean to filter out candidate Attachment 701 Routers whose availability is detected as fluctuating, at least when 702 more stable choices are available. For instance, the Mobile Router 703 MAY place the failed Attachment Router in a Hold Down mode that 704 ensures that the Attachment Router will not be reused for a given 705 period of time. 707 The known trees are associated with the Attachment Router that 708 advertises them and kept in a list by extending the Default Router 709 List. DRL entries are extended to store the information received 710 from the last TIO. These entries are managed by states and timers 711 described in the next section. 713 When connection to a fixed network is not possible or preferable for 714 security or other reasons, scattered trees should aggregate as much 715 as possible into larger trees in order to allow inner connectivity. 716 How to balance these trees is implementation dependent, and MAY use a 717 specific visitor-counter suboption in the TIO. 719 A Mobile Router SHOULD verify that bidirectional connectivity is 720 available with a candidate Attachment Router before it attaches to 721 that candidate. Some layer 2 such as 802.11 infrastructure mode will 722 provide for this, while others such as 802.11 adhoc mode will not. 723 If the layer 2 does not guarantee the bidirectional connectivity, 724 then the MR needs to make sure that it can reach the AR. This can be 725 achieved using Neighbor Sollicitation and refraining from attaching 726 to an AR for which no neighbor cache exists, or the state is still 727 INCOMPLETE. 729 5.2. Sub-tree mobility 731 It might be perceived as beneficial for a sub-tree to move as a 732 whole. The way it would work is for a Mobile Router to stay 733 clusterhead even if itself is attached into a parent tree. But the 734 loop avoidance is based on the knowledge of the tree that the Mobile 735 Router visit, preventing a Mobile Router to move down a same tree. 736 So without additional support, tree-level loops could form. 738 To avoid this, it is possible to add a path vector suboption to the 739 TIO that reflects the nesting of trees. If a root-Mobile Router 740 joins a parent tree, then it needs to add its treeID to the path 741 vector, but it can not join if the treeID is already listed. 743 A specific case is the root-Mobile Router of a tree that attaches to 744 a fixed Access Router. That root-Mobile Router might omit to 745 consider a TIO that comes from the new Attachment Router and decide 746 to stay root, in order to keep the tree consistency from the nested 747 Mobile Routers standpoint. This does not create loops, even if the 748 path vector is not present 750 5.3. Administrative depth 752 When the tree is formed under a common administration, or when a 753 Mobile Router performs a certain role within a community, it might be 754 beneficial to associate a range of acceptable depth with that MR. 755 For instance, a MR that has limited battery should be a leaf unless 756 there is no other choice, and thus expose an exagerated depth. On 757 the other hane, a MR that is designed for backhaul should operate in 758 a low range of depth. 760 With Tree Discovery, a MR has to expose a depth that is incremented 761 from its parent's depth as receive in the TIO. In particular, a MR 762 might expose a depth which is incremented by more than one from its 763 parent's depth, in order to fit in its own administrative range. So 764 a depth of N does not mean that there is precisely N Mobile Routers 765 on the way, but at most N. 767 5.4. DRL entries states and stability 769 Attachment routers in the DRL may or may not be usable for roaming 770 depending on runtime conditions. The following states are defined: 772 Current This Attachment Router is used for roaming 774 Candidate This Attachment Router can be used for roaming. 776 Held-Up This Attachment Router can not be used till tree hop timer 777 elapses. This does not occur for a fixed Attachment Router that 778 does not send a TIO since the tree delay is null in that case. 780 Held-Down This Attachment Router can not be used till hold down 781 timer elapses. At the end of the hold-down period, the router is 782 removed from the DRL, and will be reinserted if it appears again 783 with a RA. 785 Collision This Attachment Router can not be used till its next RA. 787 5.4.1. Held-Up 789 This state is managed by the tree Hop timer, it serves 2 purposes: 791 Delay the reattachment of a sub-tree that has been forced to 792 detach. This allows to make sure that when a sub-tree has 793 detached, the Router Advertisement - Tree Information Option that 794 is initiated by the new clusterhead has spread down the sub-tree 795 so that two different trees have formed. 797 Limit Router Advertisement - Tree Information Option storms when 798 two trees collide. The idea is that between the nodes from tree A 799 that wish to move to tree B, those that see the highest place in 800 tree B will move first and advertise their new locations before 801 other nodes from tree A actually move. 803 A new tree is discovered upon a router advertisement message with or 804 without a Router Advertisement - Tree Information Option. The Mobile 805 Router joins the tree by selecting the source of the RA message as 806 its attachment router (default gateway) and propagating the TIO 807 accordingly. 809 When a new tree is discovered, the candidate Attachment Router that 810 advertises the new tree is placed in a held up state for the duration 811 of a Tree Hop timer. If the new Attachment Router is more preferable 812 than the current one, the Mobile Router expects to jump and becomes 813 unstable. 815 A Mobile Router that is unstable may discover other Attachment 816 Routers from the same new tree during the instability phase. It 817 needs to start a new Tree Hop timer for all these. The first timer 818 that elapses for a given new tree clears them all for that tree, 819 allowing the Mobile Router to jump to the highest position available 820 in the new tree. 822 The duration of the Tree Hop timer depends on the tree delay of the 823 new tree and on the depth of Attachment Router that triggers it: 825 (AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It 826 is randomized in order to limit collisions and synchronizations. 828 5.4.2. Held-Down 830 When a router is 'removed' from the Default Router List, it is 831 actually held down for a hold down timer period, in order to prevent 832 flapping. This happens when an Attachment Router disappears (upon 833 expiration timer), and when an Attachment Router is tried but can not 834 reach the Home Agent (upon expiration of another Attachment Router, 835 or upon tree hop for that Attachment Router). 837 An Attachment Router that is held down is not considered for the 838 purpose of roaming. When the hold down timer elapses, the Attachment 839 Router is removed from the DRL. 841 5.4.3. Collision 843 A race condition occurs if 2 Mobile Routers send Router Advertisement 844 - Tree Information Option at the same time and wish to join each 845 other. This might happen between routers at a same depth, or routers 846 which act as clusterhead of their own tree. In order to detect the 847 situation, Mobile Routers time stamp the sending of Router 848 Advertisement - Tree Information Option. Any Router Advertisement - 849 Tree Information Option received within a short media-dependant 850 period introduces a risk. To divide the risk, A 32bits extended 851 preference is added in the TIO. The first byte is the clusterhead 852 (tree) preference, the remaining 24 bits is a boot time computed 853 random. 855 A Mobile Router that decides to join an Attachment Router will do so 856 between (Attachment Router depth) and (Attachment Router depth + 1) 857 times the Attachment Router tree delay. But since a Mobile Router is 858 unstable as soon as it receives the Router Advertisement - Tree 859 Information Option from the preferred Attachment Router, it will 860 restrain from sending a Router Advertisement - Tree Information 861 Option between the time it receives the RA and the time it actually 862 jumps. So the crossing of RA may only happen during the propagation 863 time between the Attachment Router and the Mobile Router, plus some 864 internal queuing and processing time within each machine. It is 865 expected that one tree delay normally covers that interval, but 866 ultimately it is up to the implementation and the configuration of 867 the Attachment Router to define the duration of risk window. 869 There is risk of a collision when a Mobile Router receives an RA, for 870 an other mobile router that is more preferable than the current 871 Attachment Router, within the risk window. In the face of a 872 potential collision, the Mobile Router with the lowest extended 873 preference processes the Router Advertisement - Tree Information 874 Option normally, while the router with the highest preference places 875 the other in collision state, does not start the tree hop timer, and 876 does not become instable. It is expected that next RAs between the 877 two will not cross anyway. 879 5.4.4. Instability 881 A Mobile Router is instable when it is prepared to move shortly to 882 another Attachment Router. This happens typically when the Mobile 883 Router has selected a more preferred candidate Attachment Router and 884 has to wait for the tree hop timer to elapse before roaming. 885 Instability may also occur when the current Attachment Router is lost 886 and the next best is still held up. Instability is resolved when the 887 tree hop timer of all the Attachment Router (s) causing instability 888 elapse. Such Attachment Router is changes state to Current or Held- 889 Down. 891 Instability is transient (in the order of tree hop timers). When a 892 Mobile Router is unstable, it MUST NOT send RAs with TIO. This 893 avoids loops when Mobile Router A wishes to attach to Mobile Router B 894 and Mobile Router B wishes to attach to Mobile Router A. Unless RA 895 cross (see Collision section), a Mobile Router receives TIO from 896 stable Attachment Routers, which do not plan to attach to itself, so 897 the Mobile Router can safely attach to them. 899 5.5. Legacy Routers 901 A legacy router sends its Router Advertisements without a TIO. 902 Consequently, a legacy router can be mistaken for a fixed Access 903 Router when it is placed within a nested NEMO structure, and defeat 904 the loop avoidance mechanism. Consequently, it is important for the 905 administrator to prevent address autoconfiguration by visiting Mobile 906 Routers from such a legacy router. 908 6. Directed Acyclic Graph Discovery 910 Tree Discovery builds trees, which are a specific form of a Directed 911 Acyclic Graph (DAG). In a more general Fashion, TD can be adapted to 912 form DAGs, oriented towards the clusterhead. This is DAG Discovery. 914 In Section 5.3, TD enables a given MR to expose a depth that is 915 incremented by more than one with regards to its parent. When it 916 does so, a MR can elect a number of alternate parents as feasible 917 successors. A feasible successor belongs to the same tree as the MR 918 parent, and has a depth that is less than that of the MR. 920 The links MR to feasible successors complete the tree as built by TD 921 into a DAG towards the clusterhead. The DAG enables alternate exit 922 paths for a multihomed Mobile Router. 924 7. IANA Considerations 926 Section 4.2. requires the definition of a new option to Neighbor 927 discovery [1] messages, the Router Advertisement - Tree Information 928 Option (RA-TIO). The Router Advertisement - Tree Information Option 929 has been assigned the value TBD within the numbering space for IPv6 930 Neighbor Discovery Option Formats. 932 8. Security Considerations 934 At the current level of this draft, the TIO bears the security level 935 of the RA and the link. Nothing is added to it. A deeper threat 936 analysis would be required to eventually propose additional security. 938 9. Changes 940 9.1. Changes from version 00 to 01 942 Added text on sub-tree mobility from the discussion with Marcelo. 944 Added text on nested legacy routers from the discussion with 945 Marcelo. 947 9.2. Changes from version 01 to 02 949 Improved text on instability 951 Changed the formula for the 4 bytes number used in collision 952 avoidance 954 9.3. Changes from version 02 to 03 956 Added suboptions for tree group, stable time and bandwidth. 958 Added administrative depth and increment by more than 1. 960 Added words on bidirectional check using ND. 962 Added DAG discovery. 964 9.4. Changes from version 03 to 04 966 Added suboptions for Path Free Medium Time. 968 9.5. Changes from version 04 to 05 970 Added a sequence counter which provides additional loop protection 971 based on a comment by Christipher Dearlove. For the sake of the 972 discussion, note that if a loop were to occur, the count to 973 infinity would actually cause the MR taht reaches the max depth to 974 detach and that would resolve the issue anyway. 976 10. Acknowledgments 978 The authors wish to thank Marco Molteni and Patrick Wetterwald 979 (cisco) for their participation to this design and the review of the 980 document, Massimo Villari (university of Messina), for his early work 981 on simulation and research on the subject and Julien Abeille for his 982 advanced participation in simulation and real testing. Also the 983 authors wish to thank Christopher Dearlove for his suggestion to add 984 a sequence counter which provides additional protection against loop 985 formation. This work is also based on prior publications, in 986 particular HMRA [6] by Hosik Cho and Eun-Kyoung Paik from Seoul 987 National University and other non IETF publications coauthored with 988 Thierry Ernst and Thomas Noel. Finally, thanks to Marcelo Bagnulo 989 Braun for his constructive review. 991 11. References 993 11.1. Normative Reference 995 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 996 for IP Version 6 (IPv6)", RFC 2461, December 1998. 998 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 999 IPv6", RFC 3775, June 2004. 1001 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1002 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1003 January 2005. 1005 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1006 draft-ietf-nemo-terminology-06 (work in progress), 1007 November 2006. 1009 [5] Draves, R. and D. Thaler, "Default Router Preferences and More- 1010 Specific Routes", RFC 4191, November 2005. 1012 11.2. Informative Reference 1014 [6] Cho, H., "Hierarchical Mobile Router Advertisement for nested 1015 mobile networks", draft-cho-nemo-hmra-00 (work in progress), 1016 January 2004. 1018 [7] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1019 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1020 June 2006. 1022 Authors' Addresses 1024 Pascal Thubert 1025 Cisco Systems 1026 Village d'Entreprises Green Side 1027 400, Avenue de Roumanille 1028 Batiment T3 1029 Biot - Sophia Antipolis 06410 1030 FRANCE 1032 Phone: +33 4 97 23 26 34 1033 Email: pthubert@cisco.com 1035 Caroline Bontoux 1036 Fortinet 1037 Sophia Antipolis 1038 Biot 06410 1039 FRANCE 1041 Email: cbontoux@fortinet.com 1043 Nicolas Montavont 1044 LSIIT - Univerity Louis Pasteur 1045 Pole API, bureau C444 1046 Boulevard Sebastien Brant 1047 Illkirch 67400 1048 FRANCE 1050 Phone: (33) 3 90 24 45 87 1051 Email: montavont@dpt-info.u-strasbg.fr 1052 URI: http://www-r2.u-strasbg.fr/~montavont/ 1054 Full Copyright Statement 1056 Copyright (C) The IETF Trust (2007). 1058 This document is subject to the rights, licenses and restrictions 1059 contained in BCP 78, and except as set forth therein, the authors 1060 retain all their rights. 1062 This document and the information contained herein are provided on an 1063 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1064 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1065 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1066 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1067 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1070 Intellectual Property 1072 The IETF takes no position regarding the validity or scope of any 1073 Intellectual Property Rights or other rights that might be claimed to 1074 pertain to the implementation or use of the technology described in 1075 this document or the extent to which any license under such rights 1076 might or might not be available; nor does it represent that it has 1077 made any independent effort to identify any such rights. Information 1078 on the procedures with respect to rights in RFC documents can be 1079 found in BCP 78 and BCP 79. 1081 Copies of IPR disclosures made to the IETF Secretariat and any 1082 assurances of licenses to be made available, or the result of an 1083 attempt made to obtain a general license or permission for the use of 1084 such proprietary rights by implementers or users of this 1085 specification can be obtained from the IETF on-line IPR repository at 1086 http://www.ietf.org/ipr. 1088 The IETF invites any interested party to bring to its attention any 1089 copyrights, patents or patent applications, or other proprietary 1090 rights that may cover technology that may be required to implement 1091 this standard. Please address the information to the IETF at 1092 ietf-ipr@ietf.org. 1094 Acknowledgment 1096 Funding for the RFC Editor function is provided by the IETF 1097 Administrative Support Activity (IASA).