idnits 2.17.1 draft-daniel-6lowpan-hilow-hierarchical-routing-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 51 has weird spacing: '...ssigned short...' == Line 326 has weird spacing: '...op node is AA...' == Line 328 has weird spacing: '...op node is AA...' == Line 330 has weird spacing: '...op node is AA...' == Line 344 has weird spacing: '...le) is not r...' -- 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 17, 2007) is 6157 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) == Missing Reference: 'ieee802.15.4' is mentioned on line 78, but not defined == Unused Reference: 'RFC2434' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'IEEE802.15.4' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 396, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kim, Ed. 3 Internet-Draft picosNet Corp/Ajou Univ. 4 Intended status: Standards Track S. Yoo 5 Expires: December 19, 2007 Ajou University 6 S. Daniel Park, Ed. 7 SAMSUNG Electronics 8 J. Lee 9 NIA 10 G. Mulligan 11 June 17, 2007 13 Hierarchical Routing over 6LoWPAN (HiLow) 14 draft-daniel-6lowpan-hilow-hierarchical-routing-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 19, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 The EUI-64 identifier of a 6LoWPAN device can be used as the 48 interface identifier of the IPv6 address, which can be used for for 49 on-demand multi-hop routing in 6LoWPAN. One of the distinctive 50 feature of 6LoWPAN is the capability of the dynamic assignment of 16- 51 bit short addresses. By utilizing this dynamically assigned short 52 address, a hierarchical routing which is very scalable can be 53 employed. This This document defines a dynamic address assignment 54 scheme and hierarchical routing HiLow) based on the assignment. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 61 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1 Neighbor Table Entry . . . . . . . . . . . . . . . . . . . 5 63 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Dynamic Address Assignment for Hierarchical Routing . . . . . 6 65 6. Routing Operations . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Route Maintenance . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 69 10. Security Considerations . . . . . . . . . . . . . . . . . . 9 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 73 Intellectual Property and Copyright Statements . . . . . . . . 10 75 1. Introduction 77 6LowPAN is a low-power wireless personal area network(LoWPAN) which 78 is comprised of the IEEE 802.15.4-2003 standard[ieee802.15.4] 79 devices. In [I-D.ietf-6lowpan-format], the interface 80 identifier [RFC4291] for a 6LoWPAN device is based on the EUI-64 81 [EUI64] address. The interface identifier can be used for 82 constructing routing tables for multi-hop routing in 6LoWPAN. 83 However, considering the limited capabilities (low power, limited 84 memory space, and small packet size) of 6LoWPAN devices and the large 85 number of devices which is expected to be deployed in 6LoWPAN, the 86 on-demand multi-hop routing with the use of the routing table and the 87 EUI-64 identifier may have limitations of the scalability. 89 One of the distinctive feature of 6LoWPAN is the capability of the 90 dynamic assignment of 16-bit short addresses. By utilizing this 91 short address, hierarchical routing can be employed. Even though 92 hierarchical routing produces a sub-optimal routing path, it can 93 significantly reduce the overhead of maintaining routing tables. 95 This document defines a dynamic address assignment scheme and 96 Hierarchical routing for 6LoWPAN (HiLow) based on the assignment. 98 2. Terminology 100 Association 101 A IEEE 802.15.4 device can be assigned a dynamic 16 bit short 102 address during an association operation with a neighbor device 103 (or router) which is also called a parent. After getting the 104 short address, a device can communicate with its parent or 105 child by using only the assigned short address. 107 Coordinator 108 A full-function device (FFD) which is the principal controller 109 of a 6LoWPAN. It is also called as PAN coordinator. It MAY 110 initiate the synchronization of the entire 6LoWPAN by 111 transmitting beacons. 113 Current Node 114 When a node, a IEEE 802.15.4 device in a 6LoWPAN, receives a 115 IPv6 packet, the node is called the current node in this 116 document. 118 Depth (D) 119 The hop distance from the coordinator of a 6LoWPAN to the 120 device. The depth of the coordinator is 0. 122 Disassociation 123 The disassociation operation removes an existing association 124 with its neighbor device. 126 End Device 127 RFD or FFD in a 6LoWPAN, which is neither the coordinator nor a 128 router. 130 Full Function Device (FFD) 131 A device implementing the complete protocol set of IEEE 132 802.15.4. It is capable of operating as a router (multi-hop 133 packet forwarding) for its associated neighbors. 135 Maximum Number of Children (MC) 136 The maximum number of children which a parent can have. 138 Neighbor Table 139 A node maintains the neighbor table which has the information 140 of neighbor devices in its personal operating space. 142 PAN Id 143 The 16 bit 6LoWPAN identifier which is administratively 144 assigned to a 6LoWPAN. 146 Personal Operating Space (POS) 147 The area within the reception range of the wireless 148 transmission of a IEEE 802.15.4 packet. 150 Reduced Function Device (RFD) 151 The IEEE 802.15.4 device of 6LoWPAN which does not have enough 152 power and memory space for maintaining a routing table. 154 Router 155 a FFD which has the capability of routing packets to the next 156 hop device in 6LoWPAN. 158 (Short) Address 159 A 16 bit address dynamically assigned to a device from its 160 parent. The short address is assumed if only 'address' is used 161 in this document. 163 2.1 Requirements notation 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 3. Data Structures 171 3.1 Neighbor Table Entry 173 The neighbor table includes the following entries: 175 o PANId (16 bits) 177 o Neighbor.16 bit short address (16 bits) 179 o Neighbor.IEEE EUI 64 bit address (64 bits) 181 o Neighbor.Device type (2 bits) 182 00 : Coordinator 183 01 : Router 184 10 : End device 185 11 : Reserved 187 o Neighbor.Relationship (2 bits) 188 00 : Parent 189 01 : Child 190 10-11 : Reserved 192 o Neighbor.Depth (8 bits) 194 4. Message Formats 196 This document assumes that the multi-hop routing occurs in the 197 adaptation layer by following the message format of 198 [I-D.ietf-6lowpan-format]. The following shows the message format 199 used for the hierarchical routing. 201 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |1 0|O|F|HopsLft| originator address, final address 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 1: Mesh Addressing Type and Header 209 Field definitions are as follows: 211 O: This 1-bit field SHALL be zero if the Originator Address is an 212 IEEE extended 64 bit address (EUI-64), or 1 if it is a short 16- 213 bit addresses. 215 F: This 1-bit field SHALL be zero if the Final Destination Address is 216 an IEEE extended 64 bit address (EUI-64), or 1 if it is a short 217 16-bit addresses. 219 Hops Left: This 4-bit field SHALL be decremented by each forwarding 220 node before sending this packet towards its next hop. The packet 221 is not forwarded any further if Hops Left is decremented to 0. 222 The value 0xF is reserved and signifies an 8-bit Deep Hops Left 223 field immediately following, and allows a source node to specify a 224 hop limit greater than 14 hops. 226 Originator Address: This is the link-layer address of the 227 Originator. 229 Final Destination Address: This is the link-layer address of the 230 Final Destination. 232 5. Dynamic Address Assignment for Hierarchical Routing 234 One of the distinct features of 6LoWPAN is allowing dynamic 235 configuration of the 16 bit short address in the MAC layer. In 236 addition to the EUI-64 address, a IEEE 802.15.4 device can be 237 assigned a 16-bit short address after completing the association 238 operation with its parent (or router). This section describes the 239 assignment of the dynamic address for the hierarchical routing which 240 is specified in the next section. 242 When a IEEE 802.15.4 device (or child) want to join a 6LoWPAN, it 243 first tries to discover an existing 6LoWPAN. IEEE 802.15.4 specifies 244 active and passive scanning procedures for this discovery operation. 245 By following either one of the scanning procedures, the child device 246 determines whether there is a 6LoWPAN in its POS. If there is no 247 6LoWPAN in its POS, the child device becomes the initiator (or 248 coordinator ) of a new 6LoWPAN and assigns it's short address by 0. 249 Otherwise, the child device can find an existing neighbor device (or 250 parent) which is already a member of the 6LoWPAN. After finding a 251 parent, the child tries to associate with the parent at the IEEE 252 802.15.4 MAC layer, and receives a 16 bit short address from the 253 parent if the association is successful. 255 A parent assigns a 16 bit short address to a child by the assignment 256 scheme described in Fig. 2. The scheme requires one parameter, MC, 257 the maximum number of children a parent can have. If the parent does 258 not have any child before this association, the new child becomes the 259 first child and receives a short address by the following fomular: 261 FC = MC * AP + 1 263 , where FC is the first child address, and AP is the address of the 264 parent. 266 If the new child is not the first child of the parent, it receives 267 the maximum address of the existing children of the parent plus one. 268 For this assignment a router SHOULD maintain a neighbor table which 269 has the information about it's children and parent. 271 MC = 4 273 (0) <= Coordinator 274 // \\ 275 / | | \ 276 / / \ \ 277 (1) (2) (3) (4) <= Routers 278 // \\ ......... // \\ 279 / / \ \ / / \ \ 280 (5) (6) (7)(8)..(17)(18)(19)(20) 281 // \\ 282 / / \ \ 283 ...........(69) (70)(71) (72)........ 285 287 By the nature of the scheme, it has no depth limitation and is 288 efficient for gradually incremental networks. The only parameter, 289 MC, specifies the maximum number of children a router can have. This 290 scheme conforms well to the homogeneous 6LoWPAN in which the density 291 of the devices is almost constant in the entire network. The future 292 revision of this draft will include the enhancement of adapting to 293 the heterogeneous 6LoWPAN which has some high density areas and some 294 low density areas in the network by relaxing NC. 296 6. Routing Operations 298 For the routing operation, the following symbols are defined. 300 D : the destination 301 C : the current node 302 AC : the address of the current node 303 AP : the address of the parent of the current node 304 SA : the set of the ascendant nodes of the destination 305 SD : the set of the descendant nodes of the destination 306 AA (D, k) : the address of the ascendant node of depth D of the node 307 k 308 DD : the depth of the destination 309 DC : the depth of the current node 310 First of all, it is assumed that every node knows it's own depth. 311 When a node receives an IPv6 packet, it is called the current node as 312 described in the teminology section. The address of the parent of 313 the current node, AP, can be calculated as follows: 315 AP = [(AC - 1) / MC] 317 , where [ ] is the symbol of the floor operation. (For instance, 318 [8.3] becomes 8.) 320 The current node determines first whether it is either the ascendant 321 or decendant nodes of the destination by using this fomular. When 322 the current node receives a packet, the next hop node to forward the 323 packet can be calculated by the following three cases. 325 If C is the member of SA: 326 The next hop node is AA(DC+1, D). 327 If C is the member of SD: 328 The next hop node is AA(DC-1, C). 329 Otherwise: 330 The next hop node is AA(DC-1, C). 332 7. Route Maintenance 334 The neighbor table of a node maintains the information of the parent 335 and the children. When a node loses the association from its parent, 336 it SHOULD try to re-associate with its previous parent by utilizing 337 the information in its neighbor table. To identify the loss of the 338 association, a node MAY use the periodical reception of beacons if 339 the 6LoWPAN in the beacon-enabled mode. Sometimes, the association 340 cannot be recovered by the following reasons: drained battery, node's 342 When the current node tries to forward a packet by using the 343 hierarchical routing, and the next-hop node (one of the nodes in the 344 neighbor table) is not reachable for some reason, it SHALL try to 345 recover the path or to report this forwarding error to the source of 346 the packet. The detailed operation is TBD. 348 8. Interoperability 350 The interoperability issues with the external IPv6 networks is out of 351 scope of this document. The use of the short address for mapping 352 into the IPv6 128 bit address is TBD. The interworking with the on- 353 demand routing in the mesh network is TBD. 355 9. IANA Consideration 357 The proto_type in the message formats of Section 4 is already shown 358 in [I-D.ietf-6lowpan-format] and the same value is used to this 359 document. So, there is no IANA consideration. 361 10. Security Considerations 363 TBD. 365 11. Acknowledgments 367 Thanks to Chae-sung Lim, Waleed Mansoor, Prof. Byeong-Hee Roh, and 368 for their useful discussions and supports for writing this document. 370 12. References 372 12.1. Normative References 374 [EUI64] 802.15.4-2003, IEEE Standard., 375 "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER 376 (EUI-64) REGISTRATION AUTHORITY". 378 [I-D.ietf-6lowpan-format] N., Kushalnagar., Montenegro, G., Hui, 379 J., and D. Culler, "6LoWPAN: 380 Transmission of IPv6 Packets over IEEE 381 802.15.4 Networks", February 2007. 383 [RFC2434] Narten, T. and H. Alvestrand, 384 "Guidelines for Writing an IANA 385 Considerations Section in RFCs", BCP 26, 387 [IEEE802.15.4] 802.15.4-2003, IEEE Standard., "Wireless 388 medium access control and physical layer 389 specifications for low-rate wireless 390 personal area networks.", May 2003. 392 [RFC2119] Bradner, S., "Key words for use in RFCs 393 to Indicate Requirement Levels", BCP 14, 394 RFC 2119, March 1997. 396 [RFC2461] Narten, T., Nordmark, E., W. Simpson, 397 "Neighbor Discovery for IP Version 6 398 (IPv6)", RFC 2461, December 1998. 400 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 401 Addressing Architecture", RFC 4291, 402 February 2006. 404 Authors' Addresses 406 Kim, Ki Hyung (editor) 407 picosNet Corp/Ajou Univ. 408 San 5 Wonchun-dong, Yeongtong-gu 409 Suwon-si, Gyeonggi-do 442-749 410 KOREA 412 Phone: +82 31 219 2433 413 EMail: kkim86@picosnet.com 415 Seung Wha Yoo 416 Ajou University 417 San 5 Wonchun-dong, Yeongtong-gu 418 Suwon-si, Gyeonggi-do 442-749 419 KOREA 421 Phone: +82 31 219 1603 422 Email: swyoo@ajou.ac.kr 424 Soohong Daniel Park, Editor 425 Mobile Platform Laboratory, SAMSUNG Electronics 426 416 Maetan-3dong, Yeongtong-gu 427 Suwon-si, Gyeonggi-do 442-742 428 KOREA 430 Phone: +82 31 200 4508 431 Email: soohong.park@samsung.com 433 Jae Ho Lee 434 National Information Society Agency 435 NCA Bldg, 77, Mugyo-dong, Chung-ku 436 Seoul, 100-775 437 KOREA 439 Phone: +82 2 2131 0250 440 Email: ljh@nia.or.kr 442 Geoff Mulligan 443 Email: geoff@mulligan.com 445 Full Copyright Statement 447 Copyright (C) The IETF Trust (2007). 449 This document is subject to the rights, licenses and restrictions 450 contained in BCP 78, and except as set forth therein, the authors 451 retain all their rights. 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 457 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Intellectual Property 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Acknowledgement 487 Funding for the RFC Editor function is provided by the IETF 488 Administrative Support Activity (IASA).