idnits 2.17.1 draft-toutain-6lowpan-ra-suppression-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2010) is 5047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-07 == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-09 == Outdated reference: A later version (-03) exists of draft-thubert-6lowpan-backbone-router-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Toutain 3 Internet-Draft N. Montavont 4 Intended status: Informational Institut TELECOM ; TELECOM 5 Expires: January 1, 2011 Bretagne 6 D. Barthel 7 France Telecom R&D 8 June 30, 2010 10 Neighbor Discovery Suppression 11 draft-toutain-6lowpan-ra-suppression-01.txt 13 Abstract 15 We propose to strongly reduce the usage of Neighbor Discovery in WSN 16 by ignoring the global IPv6 prefix inside the WSN. The IPv6 prefix 17 will be added (resp. removed) by the Border Router during the header 18 decompression (resp. compression). This proposal has three main 19 advantages: (i) reduce the number of exchanges inside the WSN, (ii) 20 reduce the time needed by a sensor node to join the WSN (this is 21 important when sensors are moving inside the WSN) and finally (iii) 22 simplify multi-homing management. This document also studies the 23 impact of this proposal on different architectures (star, mesh, route 24 over) with LOWPAN_IPHC Encoding Format. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Existing protocols for LoWPAN . . . . . . . . . . . . . . . . 3 62 2.1. Neighbor Discovery in LoWPAN . . . . . . . . . . . . . . . 3 63 2.2. Header compression . . . . . . . . . . . . . . . . . . . . 5 64 3. Suppression of solicited RA . . . . . . . . . . . . . . . . . 5 65 3.1. Star Topology Packet Format . . . . . . . . . . . . . . . 6 66 3.2. Mesh Topology Packet Format . . . . . . . . . . . . . . . 7 67 3.3. Routed Topology Packet Format . . . . . . . . . . . . . . 9 68 4. ULP checksum adaptation . . . . . . . . . . . . . . . . . . . 9 69 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 6LoWPAN WG aims to adapt IPv6 and associated protocols to sensor 78 network environment. This leads to two categories of standards: 79 those to transport IPv6 packets on LoWPAN links and those used to 80 adapt associated protocols such as Neighbor Discovery Protocol (NDP) 81 to 6LoWPAN environment. In this document, we propose a new approach 82 to the address management, compatible with the ones already defined 83 and that can be used to avoid running NDP on LoWPAN. We discuss the 84 validity of this proposal in different topologies cases (star, mesh 85 under and route over) and the implication of its use on the 6LoWPAN 86 header compression mechanisms. 88 2. Existing protocols for LoWPAN 90 2.1. Neighbor Discovery in LoWPAN 92 While some solutions have been proposed to optimize the encapsulation 93 of NDP messages, the load imposed by this protocol is still almost 94 equivalent in WSN and in Ethernet-based networks. 95 [I-D.ietf-6lowpan-nd] lists the differences between NDP defines in 96 [RFC4861] and the adaptation for LoWPAN. 98 In the past, some proposals have suggested limiting the use of 99 broadcast because of energy constraint, by maintaining stateful 100 information in the LoWPAN Border Router (LBR). 101 [I-D.chakrabarti-6lowpan-ipv6-nd] proposes some optimizations to 102 minimize the number of messages generated by NDP and to limit the use 103 of broadcasts in the network. NDP functionalities are concentrated 104 in the LBR instead of being distributed in the network. Duplicate 105 Address Detection (DAD) and Neighbor Solicitation (NS) are performed 106 with point-to-point requests from the sensors to the LBR rather than 107 with multicast packets spanning the whole WSN. Furthermore, nodes 108 intercept initial multicast Router Solicitation (RS) messages and 109 forward them directly to the PC instead of broadcasting them to the 110 whole network. 112 [I-D.thubert-6lowpan-backbone-router] extends the above proposal by 113 allowing multiple routers in a WSN to share the same prefix. LBR 114 only have a partial view of the addresses allocated on the WSN. They 115 use a transit link to proxy NS for DAD and address resolution 116 procedures. In addition, backbone routers have an L2 anycast address 117 allowing sensors to easily contact the closest router. 119 These solutions have evolved to a consensus among 6LoWPAN WG, 120 described in [I-D.ietf-6lowpan-nd] which releases some constraints 121 imposed by [RFC4861]. DAD is no more mandatory for IID built on 122 well-known unique values (such as EUI-64 or DHCP allocated 123 addresses). If DAD is needed, the query is sent to the LBR which 124 will check the uniqueness of the address. Periodic Router 125 Advertisements are disabled and nodes have to explicitly request RA 126 through RS. Some options are added in RA to maintain a mapping 127 between well known prefixes and a context value. 129 One major question is what is the need for source prefixes inside the 130 WSN. In fact, prefix allocation requires a protocol which is 131 difficult to deploy in a WSN environment and, once allocated, 132 prefixes may require a more complex management of the network. For 133 instance, none of these proposals touches on multi-homing or 134 interaction with routing protocol such as RPL. Figure 1 shows a very 135 simple network with two LBR announcing different prefixes in the 136 LoWPAN. 138 +----+ +----+ 139 /-----| R1 |---------------| R2 |-----\ 140 | +----+ +----+ | 141 | o o o | 142 | o O | 143 | A o | 144 \-------------------------------------/ 146 Figure 1: Address compression with RFC 4944 148 This is a very classical multi-homing problem in IPv6. Node A 149 selects a prefix announced by router R2, but packets are routed 150 through R1. R1's ISP may reject the packet since the prefix of the 151 source address ? was not allocated by this ISP. 153 Our motivation is to avoid announcing the IPv6 prefix to sensors that 154 do not need to know their global IPv6 address, while still 155 guaranteeing end-to-end communication between any equipment in the 156 Internet and these sensors. Indeed, some categories of sensors do 157 not require the knowledge of the prefix used in the network, i.e., 158 their source address, as long as gateways are able to add and remove 159 this information. For instance: 160 o a mobile sensor unidirectionally reporting periodic values to a 161 central database located outside the WSN does not need to know its 162 IPv6 address; 163 o a fixed sensor may have its address stored in the DNS database and 164 can therefore be contacted from outside the WSN without having to 165 know its own global address. 167 Our proposal does not require any change to the 6LoWPAN header 168 compression scheme [I-D.ietf-6lowpan-hc] that suppresses the source 169 network prefix in compressed IPv6 headers. 171 2.2. Header compression 173 6LoWPAN defines in [I-D.ietf-6lowpan-hc] a header compression scheme 174 that divides the IPv6 address into the two distinct parts, the prefix 175 and the interface identifier. The source address is compressed using 176 the following algorithm. A first bit (SAC) in the compressed header 177 tells if the source address is link-local or global, then two bits 178 (SAM) indicate the length of the elided part: 179 o 00: the address is sent in extenso, 180 o 01: only the 64 bits of the IID are sent, 181 o 10: 16 last bits of the IID are sent inline, 182 o 11: the whole source address is elided and the IID will be 183 reconstructed using the Layer 2 source address. 184 Except when SAM value is 00, the source prefix is not sent nor 185 received by the Sensor Node. When a context is specified (CID=1), up 186 to 16 prefix can be compressed. The relationship between the context 187 value and the prefix can be carried in modified RA messages as 188 described in [I-D.ietf-6lowpan-nd]. We propose to reserve value 15 189 for prefix not announced through RA. The compression method for the 190 destination address is almost the same based on the DAC and DAM bits. 192 3. Suppression of solicited RA 194 We propose not to distribute the IPv6 prefix inside the LoWPAN, which 195 totally avoids the need for sending RS / RA exchange. Suppressing 196 the initial RS/RA exchange requires the following changes in sensor 197 nodes' behavior: 198 o Sensor nodes do not learn the source prefix(es). With 6LoWPAN 199 header compression, using the source address prefix can be avoided 200 on the link, since a context value may be carried in the 201 compressed header. 202 o sensor nodes do not know their default router's address. In 203 Route-Over, the IPv6 address of the default LBR can be learned 204 from the routing protocol. For other topologies (star and mesh- 205 under), we propose to use a predefined Layer 2 anycast address to 206 identify default routers. (see sections Section 3.1 and 207 Section 3.2) 209 We reserve a context value (e.g., 0xF) to indicate that the prefix is 210 not carried in LoWPAN. The value OxF may be chosen in order to be 211 compatible with current implementations. In the following we discuss 212 the three different topologies star, mesh-under and route-over. We 213 finish the section by given sensor nodes and LBR behavior. 215 3.1. Star Topology Packet Format 217 In a Star topology (i.e. all the Sensor nodes are directly connected 218 to the LBR), the source address of a packet generated by a sensor 219 node can be totally elided (SAM=11) and the LBR may use the L2 220 information in the frame to reconstruct the IID. The destination 221 address field should be the default router L2 address, which is 222 usually learned from RA messages. If no RA is sent, the sensor node 223 does not know the L2 address of the default router. To solve this 224 issue, sensors may be configured with a predefined L2 anycast address 225 that will be used when no L2 unicast address is known. The context 226 value of the compression header must be 0xF for the source address 227 prefix (i.e. the LBR must add the prefix and recompute L4 checksum). 228 On the reverse path (from the LBR to the sensor node), 0xF indicates 229 that the gateway has removed the prefix and has adapted the L4 230 checksum (see section Section 4). 232 From Sensor Node to LBR: 233 +-----------L2---------+----------6LP---------------------+--- 234 |DA=L2Anycast SA=SN | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP 235 +----------------------+----------------------------------+--- 237 Form LBR to Sensor Node: 238 +-----------L2---------+----------6LP----------------------+--- 239 |DA=SN SA=LBR | CID=1 DAC=1 DAM=11 | ... 0xxF ... | ULP 240 +----------------------+-----------------------------------+--- 242 Figure 2: Packet Header in Star Toplogy 244 Consider Figure Figure 3 where a star topology with a sensor node 245 located in an area reachable by two LBRs is represented. The use of 246 an anycast address could make the two LBR to both forward packets 247 from the sensor node (to an outside network, e.g., the Internet) with 248 several (two in the case of Figure Figure 3) different source 249 addresses, composed of the (different) prefixes associated with each 250 LBR and the same interface ID. 252 To avoid this, the anycast address should only be used with the first 253 frames when the LBR address is unknown; when a Sensor Node receives a 254 reply from a LBR, it uses this address as unicast instead of the L2 255 anycast address. 257 ---------+-----------+------- 258 | | 259 +--+--+ +--+--+ 260 | LBR | _| LBR | 261 ,'| |`.,' | |. 262 ` +-----+ `` +-----+ ` 263 / / \ \ 264 | | | | 265 | |(S) | | 266 | | | | 267 \ \ / / 268 . PANid1 \/ PANid2 / 269 ',pref1 ,'',pref2 , 270 `''-''` `''-''` 272 Figure 3: Star Topology 274 3.2. Mesh Topology Packet Format 276 In a Mesh topology, "routing" is done at layer 2. [RFC4944] provides 277 a mesh header to carry the source and destination addresses. The 278 Layer 2 header carries hop-by-hop source and destination addresses. 280 From Sensor Node to LBR: 281 +--------L2----+----mesh----+----------HC----------------------+--- 282 |DA=hop SA=hop | SN Anycast | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP 283 +--------------+------------+----------------------------------+--- 285 Form LBR to Sensor Node: 286 +--------L2----+----mesh----+----------HC----------------------+--- 287 |DA=hop SA=hop | LBR SN | CID=1 SAC=1 SAM=11 | ... 0xFx ...| ULP 288 +--------------+------------+----------------------------------+--- 290 Figure 4: Packet Header in Star Toplogy 292 Figure 5 represents a mesh topology; a routing protocol at layer 2 293 allows establishing the routes in the sensors network, especially 294 from the sensor nodes to the LBR(s). Just as in the star topology, 295 L2 anycast address can be used by the sensor nodes to reach a LBR 296 (the L2 anycast address can be viewed as an identifier of a virtual 297 equipment). LBR must inject routes to this L2 anycast address, so 298 every nodes can forward packets to the closest LBR. A layer-2 299 anycast address is used in the mesh header only when a sensor node 300 sends a packet and can only be used as the destination address. The 301 next hop is obtained from the mesh routing table. In Figure 5 S 302 sends a packet toward the gateway. The route goes through R which is 303 in reach of two gateways. Since R has to select a Next Hop only one 304 LBR will receive the packet even if several LBRs share the same 305 PANid. 307 Anycast addresses should not be used as source addresses. Therefore, 308 when a gateway forwards a packet to a sensor node, it sets the 309 latter's physical address in the mesh header. 311 One drawback of this approach appears when messages sent by the 312 sensor have to be fragmented: if the routes are unstable within the 313 sensor network, some fragments may reach one default router and other 314 fragments another router, making reassembly impossible. However, 315 such situation is expected to be very uncommon and the sensors may 316 use the LBR address received in the mesh header to increase 317 stability. A trade-off is required between the sensors' mobility and 318 the stability of the default router location. 320 The use of anycast addresses is also a solution for the issue of dead 321 router detection. When a LBR fails, the routing protocol 322 automatically forwards the frame to another active LBR. 324 -------+----------------------------+-------------- 325 | | 326 +-+--+ +--+-+ 327 /---| |----------------------| |------\ 328 | | PC1|X------\ /-------->| PC2| | 329 | +----+ \ / +----+ | 330 | |L2 Anycast \/ |L2 Anycast 331 | L2 Anycast / MAC R->pC2 | 332 | / Mesh S->Anycast | 333 | (R) | 334 | ^ | 335 | | MAC: S -> R | 336 | | Mesh: S -> Anycast | 337 | (S) | 338 | | 339 | | 340 \-------------------------------------------/ 342 Figure 5: Mesh Topology 344 3.3. Routed Topology Packet Format 346 In a route-over network, packets are routed at layer 3. Since the 347 Layer 2 addresses contained in the frame are generally that of 348 intermediate nodes, IPHC compression of source or destination address 349 cannot be as good as in mesh-under. We find similar information in 350 the routing header to that contained in a mesh header, except it is 351 stored after the HC field. Figure 5 represents a case where IID is 352 fully sent after the HC field, but other SAM values such as 00 (with 353 SAC/DAC equal to 0) and 01 can also be used. 355 From Sensor Node to LBR: 356 +-L2-+----------HC--------------------------+--- 357 | | CID=1 SAC=1 SAM=10 | ... 0xFx IID ...| ULP 358 +----+--------------------------------------+--- 360 Form LBR to Sensor Node: 361 +-L2-+----------HC--------------------------+--- 362 | | CID=1 DAC=1 DAM=10 | ... 0xxF IID ...| ULP 363 +----+--------------------------------------+--- 365 Figure 6: Packet Header in Route-Over Topology 367 The routing toward the LBR is done by the default route installed in 368 the FIB of Sensor Nodes acting as routers in the WSN. A L2 anycast 369 address is not necessary to identify the gateway. 371 4. ULP checksum adaptation 373 Sensor nodes may use their own layer-4 protocol (ULP: Upper Layer 374 Protocol) however, regarding 6LoWPAN layer-4 compression values, UDP, 375 TCP or ICMP are expected. IPv6 mandates the use of an L4 checksum 376 for these protocols. The L4 checksum covers the data field and also 377 a pseudo- header including IPv6 source and destination addresses. 379 The checksum algorithm is based on a sum of all the 16 bits words of 380 the message. In our scheme, when a sensor node sends a packet to the 381 outside world, it does not know its own global IPv6 address and 382 cannot fill the source address field. Therefore, it has to compute 383 an incomplete L4 checksum, setting the prefix part of the source 384 address to zero. When receiving such a packet, the LBR can verify 385 the validity of the checksum and fix its value by adding the prefix 386 checksum computed using the same algorithm. When receiving a packet 387 from the outside world, the LBR can also adapt the L4 checksum by 388 subtracting the corresponding value. When a LBR receives an IPv6 389 packet from the Internet, it may be the case that it does not know if 390 the Sensor Node supports RA suppression. In this situation, it must 391 send the packet with the destination address uncompressed. The LBR 392 may maintain a cache of addresses of Sensor Nodes that have 393 previously sent packets using context 15. If the destination is in 394 the cache, the LBR may adapt the checksum and use prefix compression. 396 5. Conclusion 398 Although this proposal suppresses the first Neighbor Discovery 399 exchanges to allow very resource-constrained equipments to 400 communicate with any IPv6 hosts, the current IPv6 model is not 401 broken. These optimizations may be applied to some classes of the 402 sensors which do not require the knowledge of their own global IPv6 403 address. These optimizations enhance the performance of the network 404 by limiting the number of packets sent, especially broadcast, and by 405 reducing the time required for a node to enter the network. These 406 optimizations are not mandatory and are fully compatible with the 407 current behavior of the 6LoWPAN network. 409 6. Acknowledgement 411 This work is supported by the French Ministry of Foreign Affair 412 within the Tiny6 project, by NIA (National Information Society 413 Agency) of Korea with the MoMo project and the by the French National 414 Research Agency via the ARESA2 project. A special thank to Dominique 415 Barthel, Ratnajit Bhattacharjee, Claude Chaudet, Guillaume Chelius, 416 Younghee Lee, Neelesh Srivastava, Bruno Stevant Sarah Tarrapey and 417 Deepanshu Vasal. 419 7. Security Considerations 421 8. Normative References 423 [I-D.chakrabarti-6lowpan-ipv6-nd] 424 Chakrabarti, S. and E. Nordmark, "LowPan Neighbor 425 Discovery Extensions", 426 draft-chakrabarti-6lowpan-ipv6-nd-05 (work in progress), 427 July 2008. 429 [I-D.ietf-6lowpan-hc] 430 Hui, J. and P. Thubert, "Compression Format for IPv6 431 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-07 432 (work in progress), April 2010. 434 [I-D.ietf-6lowpan-nd] 435 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 436 Discovery Optimization for Low-power and Lossy Networks", 437 draft-ietf-6lowpan-nd-09 (work in progress), April 2010. 439 [I-D.thubert-6lowpan-backbone-router] 440 Thubert, P., "6LoWPAN Backbone Router", 441 draft-thubert-6lowpan-backbone-router-01 (work in 442 progress), July 2008. 444 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 445 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 446 September 2007. 448 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 449 "Transmission of IPv6 Packets over IEEE 802.15.4 450 Networks", RFC 4944, September 2007. 452 Authors' Addresses 454 Laurent Toutain 455 Institut TELECOM ; TELECOM Bretagne 456 2 rue de la Chataigneraie 457 CS 17607 458 35576 Cesson-Sevigne Cedex 459 France 461 Email: Laurent.Toutain@telecom-bretagne.eu 463 Nicolas Montavont 464 Institut TELECOM ; TELECOM Bretagne 465 2 rue de la Chataigneraie 466 CS 17607 467 35576 Cesson-Sevigne Cedex 468 France 470 Email: Nicolas.Montavont@telecom-bretagne.eu 471 Dominique Barthel 472 France Telecom R&D 473 28 Chemin du Vieux Chene 474 38243 Meylan Cedex 475 France 477 Email: dominique.barthel@orange-ftgroup.com