idnits 2.17.1 draft-kushalnagar-lowpan-goals-assumptions-00.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 474. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 147 has weird spacing: '...ing the assum...' == Line 191 has weird spacing: '...ittedly non-t...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 14, 2005) is 7011 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) == Unused Reference: 'I-D.ietf-ipv6-2461bis' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 431, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-01 == Outdated reference: A later version (-08) exists of draft-ietf-ipv6-rfc2462bis-07 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group N. Kushalnagar 2 Internet-Draft Intel Corp 3 Expires: August 15, 2005 G. Montenegro 4 Sun Microsystems, Inc. 5 February 14, 2005 7 6LoWPAN: Overview, Assumptions, Problem Statement and Goals 8 draft-kushalnagar-lowpan-goals-assumptions-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 15, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the assumptions, problem statement and goals 44 for transmitting IP over IEEE 802.15.4 networks. The set of goals 45 enumerated in this document form an initial set only. Additional 46 goals may be found necessary over time and may be added to this 47 document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1 IP Connectivity . . . . . . . . . . . . . . . . . . . . . 5 57 4.2 Topologies . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3 Limited Packet Size . . . . . . . . . . . . . . . . . . . 6 59 4.4 Limited configuration and management . . . . . . . . . . . 6 60 4.5 Service discovery . . . . . . . . . . . . . . . . . . . . 7 61 4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 68 9.2 Informative References . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 70 Intellectual Property and Copyright Statements . . . . . . . . 11 72 1. Introduction 74 Low-power wireless personal area networks (LoWPAN) comprise of 75 devices that conform to the IEEE 802.15.4-2003 standard by the IEEE 76 [ieee802.15.4]. The IEEE 802.15.4 devices are characterized by short 77 range, low bit rate, low power and low cost. 79 This document gives an overview of LoWPANs and describes how IP and 80 IPv6 networking benefits LoWPANs. It describes the requirements of 81 LoWPANs with regards to IP layer and above. It spells out the 82 underlying assumptions of IP for LoWPANs. Finally, it describes 83 problems associated with enabling IP communication between LoWPAN 84 devices, and defines goals to address these in a prioritized manner. 85 Admittedly, not all items on this list are necessarily appropriate 86 tasks for the IETF. Nevertheless, they are documented here to give a 87 general overview of the larger problem. This is useful both to 88 structure work within the IETF as well as to understand better how to 89 coordinate with external organizations. 91 1.1 Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Overview 99 A LoWPAN is a simple low cost communication network that allows 100 wireless connectivity in applications with limited power and relaxed 101 throughput requirements. LoWPAN typically comprises of devices that 102 work together to connect the physical environment to real world 103 applications, e.g., wireless sensors. It may also comprise point to 104 point wireless controls. LoWPAN devices conform to the IEEE 105 802.15.4-2003 standard by the IEEE [ieee802.15.4]. 107 Some of the characteristics of LoWPANs are: 109 1. Small packet size. Given that the maximum physical layer packet 110 is 127 bytes, the resulting maximum frame size at the media 111 access control layer is 102 octets. Link-layer security imposes 112 further overhead, which in the maximum case (21 octets of 113 overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 114 and AES-CCM-64, respectively) leaves 81 octets for data packets. 116 2. Support for both 16-bit short or IEEE 64-bit extended media 117 access control addresses. 119 3. Low bandwidth. Data rates of 250 kbps, 40 kbps and 20 kbps for 120 each of the currently defined physical layers (2.4 GHz, 915 MHz 121 and 868 MHz, respectively). 123 4. Topologies include star and mesh operation. 125 5. Low power, typically battery operated. 127 6. Relatively low cost, typically associated with sensors, switches, 128 etc. These drive some of the other characteristics such as low 129 processing, low memory, etc. Numerical values for "low" have not 130 been explicitly mentioned here as historically the costs tend to 131 change over time. 133 7. Large number of devices expected to be deployed during the 134 life-time of the technology. This number is expected to dwarf 135 the number of deployed personal computers, for example. 137 8. Location of the devices are typically not predefined, thus these 138 devices are deployed in an adhoc fashion. Furthermore, sometimes 139 the location of these devices may not be easily accessible. 141 9. Devices within LoWPANs have a higher possibility of being 142 unreliable due to variety of reasons: uncertain radio 143 connectivity, battery drain, device lockups, physical tampering, 144 etc. 146 The following sections take into account these characteristics in 147 describing the assumptions, problems statement and goals for 148 LoWPANs. 150 3. Assumptions 152 Given the small packet size of LoWPANs, this document presumes 153 applications typically send small amounts of data. However, the 154 protocols themselves do not restrict bulk data transfers. 156 LoWPAN networks described in this document is based on IEEE 157 802.15.4-2003. It is possible that the specification may undergo 158 changes in the future and may change some of the above mentioned 159 requirements. 161 Some of these assumptions are based on the limited capabilities of 162 devices within LoWPANs. As devices become more powerful, and consume 163 less power, additional functionalities may be supported within 164 LoWPAN, somewhat relaxing some of the requirements mentioned above. 166 Nevertheless, not all devices in a LoWPAN network are expected to be 167 extremely limited. This is true of so-called "Reduced Function 168 Devices" (RFDs), but not necessarily of "Full Function Devices" 169 (FFDs). These will also be present albeit in much smaller numbers, 170 and will typically have more resources and be mains powered. 171 Accordingly, FFDs will aid RFDs by providing functions such as 172 network coordination, packet forwarding, interfacing with other 173 (non-LoWPAN) networks, etc. 175 4. Problems 177 Based on the characteristics defined in the overview section, the 178 following sections elaborate on the main problems with IP for LoWPANs 179 Note that a common underlying goal is to reduce packet overhead, 180 bandwidth consumption, and processing requirements. 182 4.1 IP Connectivity 184 The requirement for having IP connectivity within LoWPAN is driven by 185 the following: 187 1. The pervasive nature of IP networks allows use of existing 188 infrastructure. 189 2. IP based technologies already exist, are well known and proven to 190 be working. 191 3. An admittedly non-technical but important consideration is that 192 intellectual property conditions for IP networking technology are 193 either more favorable or at least better understood than 194 proprietary and newer solutions. 196 Furthermore, the requirement for having IPv6 connectivity within 197 LoWPAN is driven by the following: 199 1. Such devices make network autoconfiguration and statelessness 200 highly desirable. And for this, IPv6 has ready solutions. 201 2. The large number of devices poses the need for a large address 202 space, well met by IPv6. 203 3. Given the limited packet size of LoWPANs, the IPv6 address format 204 allows subsuming of IEEE 802.15.4 addresses if so desired. 206 However, given the limited packet size, headers for IPv6 and above 207 layers must be compressed whenever possible. 209 4.2 Topologies 211 LoWPANs must support various topologies including mesh and star. 213 Mesh topologies imply multi-hop routing. to a desired destination. 215 In this case, intermediate devices act as packet forwarders at the 216 link layer (akin to routers at the network layer). Typically these 217 are "full function devices" that have more capabilities in terms of 218 power, computation, etc. The requirements that apply on the chosen 219 routing protocol are: 221 1. Given the minimal packet size of LoWPANs, the routing protocol 222 must impose low (or no) overhead on data packets, hopefully 223 independently of the number of hops. 224 2. The routing protocols should have low routing overhead (less 225 chatty) balanced with topology changes and power conservation. 226 3. The computation and memory requirements in the routing protocol 227 should be minimal to satisfy low cost and low power 228 characteristics. Thus storage and maintaining of large routing 229 tables may be detrimental. 231 As with mesh topologies, star topologies include provisioning a 232 subset of devices with packet forwarding functionality. If these 233 devices use the same IEEE 802.15.4 radio, then the requirement 234 specified in the mesh topology must exist. If these devices use 235 different kinds of network interfaces such as ethernet, IEEE 802.11, 236 etc., the goal is for seamless integration with networks built over 237 those technologies. This, or course, is a primary motivation to use 238 IP to begin with. 240 4.3 Limited Packet Size 242 Applications within LoWPANs are expected to originate small packets. 243 Adding all layers for IP connectivity should still allow transmission 244 in one frame without incurring excessive fragmentation and 245 reassembly. Furthermore, protocols must be designed or chosen so 246 that the individual "control/protocol packets" fit within a single 247 802.15.4 frame. 249 4.4 Limited configuration and management 251 As alluded to above, LoWPAN devices are expected to be deployed in 252 exceedingly large numbers. Additionally, LoWPAN devices are expected 253 to have limited display and input capabilities. Furthermore, the 254 location of some of these devices may be hard to access. As such, 255 protocols designed for LoWPANs should have minimal configuration, 256 preferably work "out of the box", provide easy bootstrapping, and 257 should be able to self heal given the inherent unreliable 258 characteristic of these devices. The network management should have 259 less overhead yet be powerful to control dense deployment of devices. 261 4.5 Service discovery 263 LoWPAN require simple service discovery network protocols to 264 discover, control and maintain services provided by devices. In some 265 cases, especially in dense deployments, abstraction of several nodes 266 to provide a service may be beneficial. In order to enable such 267 features, new protocols may have to be designed. 269 4.6 Security 271 Although IEEE 802.15.4 provides AES link layer security, a complete 272 end-to-end security is needed. 274 5. Goals 276 Goals mentioned here may point at relevant work that can be done 277 within the IETF (e.g., specification required to transmit IP, profile 278 of best practices for transmitting IP packets, and associated upper 279 level protocols, etc). It may also point at work to be done in other 280 standards bodies that exist or may exist in the future (e.g., 281 desirable changes or profiles relevant to IEEE 802.15.4, W3C, etc). 282 When the goals fall under the IETF's purview, they serve to point out 283 what those efforts should strive to accomplish. Regardless of 284 whether they are pursued within one (or more) new (or existing) 285 working groups. When the goals do not fall under the purview of the 286 IETF, documenting them here serves as input to those other 287 organizations [liaison]. 289 The following are the goals according to priority for LoWPAN: 291 1. As mentioned in the overview, the protocol data units may be as 292 small 81 bytes. This is obviously far below the minimum IPv6 293 packet size of 1280 octets, and in keeping with section 5 of the 294 IPv6 specification [RFC2460], a fragmentation and reassembly 295 adaptation layer must be provided at the layer below IP. 297 2. Given that in the worst case the maximum size available for 298 transmitting IP packets over IEEE 802.15.4 frame is 81 octets, 299 and that the IPv6 header is 40 octets long, (without optional 300 headers), this leaves only 41 octets for upper-layer protocols, 301 like UDP and TCP. UDP uses 8 octets in the header and TCP uses 302 20 octets. This leaves 33 octets for data over UDP and 21 octets 303 for data over TCP. Additionally, as pointed above, there is also 304 a need for a fragmentation and reassembly layer, which will use 305 even more octets leaving very few octets for data. Thus if one 306 were to use the protocols as is, it would lead to excessive 307 fragmentation and reassembly even when data packets are just 10s 308 of octets long. This points at the need for header compression 309 As there is much published and in-progress standardization work 310 on header compression, this goal needs to investigate using 311 existing header compression techniques and if necessary specify 312 new ones. 314 3. [I-D.ietf-ipv6-rfc2462bis] specify methods for creating IPv6 315 stateless address autoconfiguration. Stateless auto 316 configuration has an advantage over stateful by having less 317 configuration overhead on the hosts suitable for LoWPANs. The 318 goal should specify a method to generate an "interface 319 identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 320 device. 322 4. A routing protocol to support a multi-hop mesh network is 323 necessary. There is much published work on adhoc multi hop 324 routing for devices. Some examples include [RFC3561], [RFC3626], 325 [RFC3684], all experimental. Also, these protocols are designed 326 to use IP based addresses that have large overheads. For 327 example, the AODV [RFC3561] routing protocol uses 48 octets for a 328 route request based on IPv6 addressing. Given the packet size 329 constraints, transmitting this packet without fragmentation and 330 reassembly may be difficult. Thus care should be taken when 331 using existing protocols or designing new protocols for routing 332 so that the routing packets fit within a single IEEE 802.15.4 333 frame. 335 5. One of the points of transmitting IPv6 packets, is to reuse 336 existing protocols as much as possible. Network management 337 functionality is critical for LoWPANs. [RFC3411] specifies 338 SNMPv3 protocol operations. SNMP functionality may be translated 339 "as is" to LoWPANs. However, further investigation is required. 340 SNMPv3 may not be the best protocol for this task. Or it may be 341 only after adapting it appropriately. 343 6. It may be the case that transmitting IP over IEEE 802.15.4 would 344 become more beneficial if implemented in a "certain" way. 345 Accordingly, implementation considerations are to be documented. 347 7. As header compression becomes more prevalent, overall performance 348 will depend even more on efficiency of application protocols. 349 Heavyweight protocols based on XML such as SOAP [SOAP], may not 350 be suitable for LoWPANs. As such, more compact encodings (and 351 perhaps protocols) may become necessary. The goal here is to 352 specify or suggest modifications to existing protocols so that it 353 is suitable for LoWPANs. Furthermore, application level 354 interoperability specifications may also become necessary in the 355 future and may thus be specified. 357 8. Security threats at different layers must be clearly understood 358 and documented. Bootstrapping of devices into a secure network 359 could also be considered given the location, limited display, 360 high density and ad hoc deployment of devices. 362 6. IANA Considerations 364 TBD 366 7. Security Considerations 368 TBD 370 8. Acknowledgements 372 Thanks to : 374 Geoff Mulligan 376 Soohong Daniel Park 378 Samita Chakrabarti 380 Brijesh Kumar 382 for their comments and help shaping this document. 384 9. References 386 9.1 Normative References 388 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 389 REGISTRATION AUTHORITY", IEEE 390 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 391 . 393 [I-D.ietf-ipv6-2461bis] 394 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 395 draft-ietf-ipv6-2461bis-01 (work in progress), October 396 2004. 398 [I-D.ietf-ipv6-rfc2462bis] 399 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 400 draft-ietf-ipv6-rfc2462bis-07 (work in progress), December 401 2004. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 407 (IPv6) Specification", RFC 2460, December 1998. 409 [ieee802.15.4] 410 IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 411 2003. 413 9.2 Informative References 415 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An 416 Architecture for Describing Simple Network Management 417 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 418 December 2002. 420 [RFC3561] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc 421 On-Demand Distance Vector (AODV) Routing", RFC 3561, July 422 2003. 424 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 425 Protocol (OLSR)", RFC 3626, October 2003. 427 [RFC3684] Ogier, R., Templin, F. and M. Lewis, "Topology 428 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 429 RFC 3684, February 2004. 431 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 432 Discovery (ND) Trust Models and Threats", RFC 3756, May 433 2004. 435 [SOAP] "SOAP", W3C http://www.w3c.org/2000/xp/Group/. 437 [liaison] "LIASONS", IETF 438 http://www.ietf.org/liaisonActivities.html. 440 Authors' Addresses 442 Nandakishore Kushalnagar 443 Intel Corp 445 EMail: nandakishore.kushalnagar@intel.com 447 Gabriel Montenegro 448 Sun Microsystems, Inc. 450 EMail: gab@sun.com 452 Intellectual Property Statement 454 The IETF takes no position regarding the validity or scope of any 455 Intellectual Property Rights or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; nor does it represent that it has 459 made any independent effort to identify any such rights. Information 460 on the procedures with respect to rights in RFC documents can be 461 found in BCP 78 and BCP 79. 463 Copies of IPR disclosures made to the IETF Secretariat and any 464 assurances of licenses to be made available, or the result of an 465 attempt made to obtain a general license or permission for the use of 466 such proprietary rights by implementers or users of this 467 specification can be obtained from the IETF on-line IPR repository at 468 http://www.ietf.org/ipr. 470 The IETF invites any interested party to bring to its attention any 471 copyrights, patents or patent applications, or other proprietary 472 rights that may cover technology that may be required to implement 473 this standard. Please address the information to the IETF at 474 ietf-ipr@ietf.org. 476 Disclaimer of Validity 478 This document and the information contained herein are provided on an 479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 481 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 482 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 483 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Copyright Statement 488 Copyright (C) The Internet Society (2005). This document is subject 489 to the rights, licenses and restrictions contained in BCP 78, and 490 except as set forth therein, the authors retain all their rights. 492 Acknowledgment 494 Funding for the RFC Editor function is currently provided by the 495 Internet Society.