idnits 2.17.1 draft-ietf-6lowpan-routing-requirements-10.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 Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2011) is 4540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'A' is mentioned on line 315, but not defined == Missing Reference: 'B' is mentioned on line 311, but not defined == Missing Reference: 'R01' is mentioned on line 877, but not defined == Missing Reference: 'R02' is mentioned on line 605, but not defined == Missing Reference: 'R03' is mentioned on line 644, but not defined == Missing Reference: 'R04' is mentioned on line 724, but not defined == Missing Reference: 'R05' is mentioned on line 724, but not defined == Missing Reference: 'R08' is mentioned on line 772, but not defined == Missing Reference: 'R06' is mentioned on line 726, but not defined == Missing Reference: 'R07' is mentioned on line 755, but not defined == Missing Reference: 'R09' is mentioned on line 877, but not defined == Missing Reference: 'R10' is mentioned on line 879, but not defined == Missing Reference: 'R11' is mentioned on line 899, but not defined == Missing Reference: 'R12' is mentioned on line 911, but not defined == Missing Reference: 'R13' is mentioned on line 967, but not defined == Missing Reference: 'R14' is mentioned on line 997, but not defined == Missing Reference: 'R16' is mentioned on line 1112, but not defined == Missing Reference: 'R15' is mentioned on line 1108, but not defined == Missing Reference: 'R17' is mentioned on line 1124, but not defined == Missing Reference: 'R18' is mentioned on line 1135, but not defined == Missing Reference: 'RFC1958' is mentioned on line 1147, but not defined == Unused Reference: 'RFC6282' is defined on line 1300, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-18 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-01 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group E. Kim 3 Internet-Draft ETRI 4 Intended status: Informational D. Kaspar 5 Expires: May 23, 2012 Simula Research Laboratory 6 C. Gomez 7 Universitat Politecnica de 8 Catalunya/i2CAT 9 C. Bormann 10 Universitaet Bremen TZI 11 November 20, 2011 13 Problem Statement and Requirements for 6LoWPAN Routing 14 draft-ietf-6lowpan-routing-requirements-10 16 Abstract 18 6LoWPANs are formed by devices that are compatible with the IEEE 19 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor 20 the 6LoWPAN format specification define how mesh topologies could be 21 obtained and maintained. Thus, it should be considered how 6LoWPAN 22 formation and multi-hop routing could be supported. 23 This document provides the problem statement and design space for 24 6LoWPAN routing. It defines the routing requirements for 6LoWPAN 25 networks, considering the low-power and other particular 26 characteristics of the devices and links. The purpose of this 27 document is not to recommend specific solutions, but to provide 28 general, layer-agnostic guidelines about the design of 6LoWPAN 29 routing, which can lead to further analysis and protocol design. 30 This document is intended as input to groups working on routing 31 protocols relevant to 6LoWPAN, such as the IETF ROLL WG. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 23, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Reference Network Model . . . . . . . . . . . . . . . . . 8 71 4. Scenario Considerations and Parameters for 6LoWPAN Routing . . 10 72 5. 6LoWPAN Routing Requirements . . . . . . . . . . . . . . . . . 15 73 5.1. Support of 6LoWPAN Device Properties . . . . . . . . . . . 15 74 5.2. Support of 6LoWPAN Link Properties . . . . . . . . . . . . 17 75 5.3. Support of 6LoWPAN Network Characteristics . . . . . . . . 20 76 5.4. Support of Security . . . . . . . . . . . . . . . . . . . 24 77 5.5. Support of Mesh Under Forwarding . . . . . . . . . . . . . 27 78 5.6. Support of Management . . . . . . . . . . . . . . . . . . 27 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 87 1. Problem Statement 89 6LoWPANs are formed by devices that are compatible with the IEEE 90 802.15.4 standard [IEEE802.15.4]. Most of the LoWPAN devices are 91 distinguished by their low bandwidth, short range, scarce memory 92 capacity, limited processing capability and other attributes of 93 inexpensive hardware. The characteristics of nodes participating in 94 LoWPANs are assumed to be those described in the 6LoWPAN problem 95 statement [RFC4919], and the IPv6 over IEEE 802.15.4 [RFC4944] 96 document which has specified how to carry IPv6 packets over IEEE 97 802.15.4 and similar networks. Whereas IEEE 802.15.4 distinguishes 98 two types of devices called full-function devices (FFD) and reduced- 99 function devices (RFDs), this distinction is based on some MAC layer 100 features that are not always in use. Hence, the distinction is not 101 made in this document. Nevertheless, some 6LoWPAN nodes may limit 102 themselves to the role of hosts only, whereas other 6LoWPAN nodes may 103 take part in routing. This host/router distinction can correlate 104 with the processing and storage capabilities of the device and power 105 available in a similar way to the idea of RFDs and FFDs. 107 IEEE 802.15.4 networks support star and mesh topologies. However, 108 neither the IEEE 802.15.4 standard nor the 6LoWPAN format 109 specification ([RFC4944]) define how mesh topologies could be 110 obtained and maintained. Thus, 6LoWPAN formation and multi-hop 111 routing can be supported either below the IP layer (the adaptation 112 layer or LLC) or the IP layer. (Note that in the IETF, the term 113 "routing" usually, but not always [RFC5556], refers exclusively to 114 the formation of paths and the forwarding at the IP layer. In this 115 document we distinguish the layer at which these services are 116 performed by the terms "Route Over" and "Mesh Under". See Section 2 117 and Section 3.) A number of IP routing protocols have been developed 118 in various IETF working groups. However, these existing routing 119 protocols may not satisfy the requirements of multi-hop routing in 120 6LoWPANs, for the following reasons: 122 o 6LoWPAN nodes have special types and roles, such as nodes drawing 123 their power from primary batteries, power-affluent nodes, mains- 124 powered and high-performance gateways, data aggregators, etc. 125 6LoWPAN routing protocols should support multiple device types and 126 roles. 128 o More stringent requirements apply to LoWPANs, as opposed to higher 129 performance or non-battery-operated networks. 6LoWPAN nodes are 130 characterized by small memory sizes, low processing power, and are 131 running on very limited power supplied by primary non-rechargeable 132 batteries (a few kBytes of RAM, a few dozens of kBytes of ROM/ 133 flash memory, and a few MHz of CPU is typical). A node's lifetime 134 is usually defined by the lifetime of its battery. 136 o Handling sleeping nodes is very critical in LoWPANs, more than in 137 traditional ad-hoc networks. LoWPAN nodes might stay in sleep 138 mode for most of the time. Taking advantage of appropriate times 139 for transmissions is important for efficient packet forwarding. 141 o Routing in 6LoWPANs might possibly translate to a simpler problem 142 than routing in higher-performance networks. LoWPANs might be 143 either transit networks or stub networks. Under the assumption 144 that LoWPANs are never transit networks (as implied by [RFC4944]), 145 routing protocols may be drastically simplified. This document 146 will focus on the requirements for stub networks. Additional 147 requirements may apply to transit networks. 149 o Routing in LoWPANs might possibly translate to a harder problem 150 than routing in higher-performance networks. Routing in LoWPANs 151 requires power optimization, stable operation in lossy 152 environments, etc. These requirements are not easily satisfiable 153 all at once [I-D.ietf-roll-protocols-survey]. 155 These properties create new challenges on design of routing within 156 LoWPANs. 158 The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" 159 [RFC4919]) briefly mentions four requirements on routing protocols: 161 (a) low overhead on data packets 163 (b) low routing overhead 165 (c) minimal memory and computation requirements 167 (d) support for sleeping nodes considering battery saving 169 These four high-level requirements describe the basic requirements 170 for 6LoWPAN routing. Based on the fundamental features of 6LoWPAN, 171 more detailed routing requirements are presented in this document, 172 which can lead to further analysis and protocol design. 174 Considering the problems above, detailed 6LoWPAN routing requirements 175 must be defined. Application-specific features affect the design of 176 6LoWPAN routing requirements and the corresponding solutions. 177 However, various applications can be profiled by similar technical 178 characteristics, although the related detailed requirements might 179 differ (e.g., a few dozens of nodes in a home lighting system need 180 appropriate scalability for its applications, while millions of nodes 181 for a highway infrastructure system also need appropriate 182 scalability). 184 This routing requirements document states the routing requirements of 185 6LoWPAN applications in general, providing examples for different 186 cases of routing. It does not imply a single routing solution to be 187 favorable for all 6LoWPAN applications and there is no requirement of 188 different routing protocols to run simultaneously. 190 2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 Readers are expected to be familiar with all the terms and concepts 197 that are discussed in "IPv6 over Low-Power Wireless Personal Area 198 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 199 Goals" [RFC4919], and "Transmission of IPv6 Packets over IEEE 200 802.15.4 Networks" [RFC4944]. 202 This specification makes use of the terminology defined in the 203 "Neighbor Discovery for 6LoWPAN" [I-D.ietf-6lowpan-nd]. 205 3. Design Space 207 Apart from a wide variety of conceivable routing algorithms for 208 6LoWPAN, it is possible to perform routing in the IP layer, using a 209 Route Over approach or below IP, as defined by the 6LoWPAN format 210 document [RFC4944], using the Mesh Under approach (see Figure 1). 212 The Route Over approach relies on IP routing and therefore supports 213 routing over possibly various types of interconnected links. 214 Note: The ROLL WG is now working on Route Over approaches for Low 215 power and Lossy Networks (LLNs), not specifically for 6LoWPAN. This 216 document focuses on 6LoWPAN-specific requirements; it may be used in 217 conjunction with the more application-oriented requirements defined 218 by the ROLL WG. 220 The Mesh Under approach performs the multi-hop communication below 221 the IP link. The most significant consequence of Mesh Under 222 mechanism is that the characteristics of IEEE 802.15.4 directly 223 affect the 6LoWPAN routing mechanisms, including the use of 64-bit 224 (or 16-bit short) link layer addresses instead of IP addresses. A 225 6LoWPAN would therefore be seen as a single IP link. 227 Most statements in this document consider both the Route Over and 228 Mesh Under cases. 230 Figure 1 shows the place of 6LoWPAN routing in the entire network 231 stack. 233 +---------------------------+ +-----------------------------+ 234 | Application Layer | | Application Layer | 235 +---------------------------+ +-----------------------------+ 236 | Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) | 237 +---------------------------+ +-----------------------------+ 238 | Network Layer (IPv6) | | Network +---------+ | 239 +---------------------------+ | Layer | Routing | | 240 | 6LoWPAN | | (IPv6) +---------+ | 241 | Adaptation | +-----------------------------+ 242 | Layer +----------+ | | 6LoWPAN Adaptation Layer | 243 +--------------| Routing* |-+ +-----------------------------+ 244 | 802.15.4 MAC +----------+ | | 802.15.4 MAC | 245 +---------------------------+ +-----------------------------+ 246 | 802.15.4 PHY | | 802.15.4 PHY | 247 +---------------------------+ +-----------------------------+ 248 * Here, 'Routing' is not equivalent to IP routing, 249 but includes the functionalities of path computation and 250 forwarding under the IP layer. 251 The term 'Routing' is used in the figure in order to 252 illustrate which layer handles path computation and 253 packet forwarding in Mesh Under compared to Route Over. 255 Figure 1: Mesh Under (left) and Route Over routing (right) 257 In order to avoid packet fragmentation and the overhead for 258 reassembly, routing packets should fit into a single IEEE 802.15.4 259 physical frame and application data should not be expanded to an 260 extent that they no longer fit. 262 3.1. Reference Network Model 264 For multi-hop communication in 6LoWPAN, when a Route Over mechanism 265 is in use, all routers (i.e. 6LoWPAN Border Routers (6LBRs) and 266 6LoWPAN Routers (6LRs)) perform IP routing within the stub network 267 (see Figure 2). In this case, the link-local scope covers the set of 268 nodes within symmetric radio range of a node. 270 When a LoWPAN follows the Mesh Under configuration, the 6LBR is the 271 only IPv6 router in the LoWPAN (see Figure 3). This means that the 272 IPv6 link-local scope includes all nodes in the LoWPAN. For this, a 273 Mesh Under mechanism MUST be provided to support multi-hop 274 transmission. 276 h h 277 / | 6LBR: 6LoWPAN Border Router 278 6LBR -- 6LR --- 6LR --- h 6LR: 6LoWPAN Router 279 / \ h: Host 280 h 6LR --- h 281 | 282 / \ 283 6LR - 6LR -- h 285 Figure 2: An example of a Route Over LoWPAN 287 h h 288 / | 6LBR: 6LoWPAN Border Router 289 6LBR --- m --- m --- h m: mesh under forwarder 290 / \ h: Host 291 h m --- h 292 | 293 / \ 294 m - m -- h 296 Figure 3: An example of a Mesh Under LoWPAN 298 Note than in both Mesh Under and Route Over networks, there is no 299 expectation of topologically based address assignment in the 6LoWPAN. 300 Instead, addresses are typically assigned based on the EUI-64 301 addresses assigned at manufacturing time to nodes, or based on a 302 (from a topological point of view) more or less random process 303 assigning 16-bit MAC addresses to individual nodes. Within a 304 6LoWPAN, there is therefore no opportunity for aggregation or 305 summarization of IPv6 addresses beyond the sharing of (one or more) 306 common prefixes. 308 Not all devices that are in radio range of each other need to be part 309 of the same LoWPAN. When multiple LoWPANs are formed with globally 310 unique IPv6 addresses in the 6LoWPANs, and device (a) of LoWPAN [A] 311 wants to communicate with device (b) of LoWPAN [B], the normal IPv6 312 mechanisms will be employed. For Route Over, the IPv6 address of (b) 313 is set as the destination of the packets, and the devices perform IP 314 routing to the 6LBR for these outgoing packets. For Mesh Under, 315 there is one IP hop from a device (a) to the 6LBR of [A], no matter 316 how many radio hops they are apart from each other. This, of course, 317 assumes the existence of a Mesh Under routing protocol in order to 318 reach the 6LBR. Note that a default route to the 6LBR could be 319 inserted into the 6LoWPAN routing system for both Route Over and Mesh 320 Under. 322 4. Scenario Considerations and Parameters for 6LoWPAN Routing 324 IP-based LoWPAN technology is still in its early stage of 325 development, but the range of conceivable usage scenarios is 326 tremendous. The numerous possible applications of sensor networks 327 make it obvious that mesh topologies will be prevalent in LoWPAN 328 environments and robust routing will be a necessity for expedient 329 communication. Research efforts in the area of sensor networking 330 have put forth a large variety of multi-hop routing algorithms 331 [refs.bulusu]. Most related work focuses on optimizing routing for 332 specific application scenarios, which can be realized using several 333 models of communication, including the following ones [refs.cctc]: 335 o Flooding (in very small networks) 337 o Hierarchical routing 339 o Geographic routing 341 o Self-organizing coordinate routing 343 Depending on the topology of a LoWPAN and the application(s) running 344 over it, different types of routing may be used. However, this 345 document abstracts from application-specific communication and 346 describes general routing requirements valid for overall routing in 347 LoWPANs. 349 The following parameters can be used to describe specific scenarios 350 in which the candidate routing protocols could be evaluated. 352 a. Network Properties: 354 * Number of Devices, Density and Network Diameter: 355 These parameters usually affect the routing state directly 356 (e.g. the number of entries in a routing table or neighbor 357 list). Especially in large and dense networks, policies must 358 be applied for discarding "low-quality" and stale routing 359 entries in order to prevent memory overflow. 361 * Connectivity: 362 Due to external factors or programmed disconnections, a LoWPAN 363 can be in several states of connectivity; anything in the 364 range from "always connected" to "rarely connected". This 365 poses great challenges to the dynamic discovery of routes 366 across a LoWPAN. 368 * Dynamicity (including mobility): 369 Location changes can be induced by unpredictable external 370 factors or by controlled motion, which may in turn cause route 371 changes. Also, nodes may dynamically be introduced into a 372 LoWPAN and removed from it later. The routing state and the 373 volume of control messages may heavily depend on the number of 374 moving nodes in a LoWPAN and their speed, as well as how 375 quickly and frequently environmental characteristics 376 influencing radio propagation change. 378 * Deployment: 379 In a LoWPAN, it is possible for nodes to be scattered randomly 380 or to be deployed in an organized manner. The deployment can 381 occur at once, or as an iterative process, which may also 382 affect the routing state. 384 * Spatial Distribution of Nodes and Gateways: 385 Network connectivity depends on the spatial distribution of 386 the nodes and on other factors, such as device number, density 387 and transmission range. For instance, nodes can be placed on 388 a grid, or randomly located in an area (as can be modeled by a 389 bidimensional Poisson distribution), etc. Assuming a random 390 spatial distribution, an average of 7 neighbors per node are 391 required for approximately 95% network connectivity (10 392 neighbors per node are needed for 99% 393 connectivity)[refs.Kuhn]. In addition, if the LoWPAN is 394 connected to other networks through infrastructure nodes 395 called gateways, the number and spatial distribution of 396 gateways affects network congestion and available data rate, 397 among others. 399 * Traffic Patterns, Topology and Applications: 400 The design of a LoWPAN and the requirements on its application 401 have a big impact on the network topology and the most 402 efficient routing type to be used. For different traffic 403 patterns (point-to-point, multipoint-to-point, point-to- 404 multipoint) and network architectures, various routing 405 mechanisms have been developed, such as data-centric, event- 406 driven, address-centric, and geographic routing. 408 * Classes of Service: 409 For mixing applications of different criticality on one 410 LoWPAN, support of multiple classes of service may be required 411 in resource-constrained LoWPANs and may require a new routing 412 protocol functionality. 414 * Security: 415 LoWPANs may carry sensitive information and require a high 416 level of security support where the availability, integrity, 417 and confidentiality of data are of prime relevance. Secured 418 messages cause overhead and affect the power consumption of 419 LoWPAN routing protocols. 421 b. Node Parameters: 423 * Processing Speed and Memory Size: 424 These basic parameters define the maximum size of the routing 425 state and the maximum complexity of its processing. LoWPAN 426 nodes may have different performance characteristics, queuing 427 strategies and queue buffer sizes. 429 * Power Consumption and Power Source: 430 The number of battery- and mains-powered nodes and their 431 positions in the topology created by them in a LoWPAN affect 432 routing protocols in their selection of paths that optimize 433 network lifetime. 435 * Transmission Range: 436 This parameter affects routing. For example, a high 437 transmission range may cause a dense network, which in turn 438 results in more direct neighbors of a node, higher 439 connectivity and a larger routing state. 441 * Traffic Pattern: 442 This parameter affects routing since highly loaded nodes 443 (either because they are the source of packets to be 444 transmitted or due to forwarding) may contribute to higher 445 delivery delays and may consume more energy than lightly 446 loaded nodes. This applies to both data packets and routing 447 control messages. 449 c. Link Parameters: 450 This section discusses link parameters that apply to IEEE 451 802.15.4 legacy mode (i.e. not making use of improved modulation 452 schemes). 454 * Throughput: 455 The maximum user data throughput of a bulk data transmission 456 between a single sender and a single receiver through an 457 unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is 458 as follows [refs.Latre]: 460 + 16-bit MAC addresses, unreliable mode: 151.6 kbit/s 462 + 16-bit MAC addresses, reliable mode: 139.0 kbit/s 464 + 64-bit MAC addresses, unreliable mode: 135.6 kbit/s 465 + 64-bit MAC addresses, reliable mode: 124.4 kbit/s 467 In the case of 915 MHz band: 469 + 16-bit MAC addresses, unreliable mode: 31.1 kbit/s 471 + 16-bit MAC addresses, reliable mode: 28.6 kbit/s 473 + 64-bit MAC addresses, unreliable mode: 27.8 kbit/s 475 + 64-bit MAC addresses, reliable mode: 25.6 kbit/s 477 In the case of 868 MHz band: 479 + 16-bit MAC addresses, unreliable mode: 15.5 kbit/s 481 + 16-bit MAC addresses, reliable mode: 14.3 kbit/s 483 + 64-bit MAC addresses, unreliable mode: 13.9 kbit/s 485 + 64-bit MAC addresses, reliable mode: 12.8 kbit/s 487 * Latency: 488 The range of latencies, depending on payload size, of a frame 489 transmission between a single sender and a single receiver 490 through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal 491 conditions are as shown next [refs.Latre]. For unreliable 492 mode, the actual latency is provided. For reliable mode, the 493 round-trip-time including transmission of a layer two 494 acknowledgment is provided: 496 + 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms] 498 + 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms] 500 + 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms] 502 + 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms] 504 For the 915 MHz band: 506 + 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms] 508 + 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms] 510 + 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms] 511 + 64-bit MAC addresses, reliable mode: [11.45 ms, 31.85 ms] 513 For the 868 MHz band: 515 + 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms] 517 + 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms] 519 + 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms] 521 + 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms] 523 Note that some of the parameters presented in this section may be 524 used as link or node evaluation metrics. However, multi-criteria 525 routing may be too expensive for 6LoWPAN nodes. Rather, various 526 single-criteria metrics are available and can be selected to suit the 527 environment or application. 529 5. 6LoWPAN Routing Requirements 531 This section defines a list of requirements for 6LoWPAN routing. An 532 important design property specific to low-power networks is that 533 LoWPANs have to support multiple device types and roles, such as: 535 o host nodes drawing their power from primary batteries or using 536 energy harvesting (both called "power-constrained nodes" in the 537 following) 539 o mains-powered host nodes (an example for what we call "power- 540 affluent nodes") 542 o power-affluent (but not necessarily mains-powered) high- 543 performance gateway(s) 545 o nodes with various functionality (data aggregators, relays, local 546 manager/coordinators, etc.) 548 Due to these different device types and roles LoWPANs need to 549 consider the following two primary attributes: 551 o Power conservation: some devices are mains-powered, but many are 552 battery-operated and need to last several months to a few years 553 with a single AA battery. Many devices are mains-powered most of 554 the time, but still need to function for possibly extended periods 555 from batteries (e.g. on a construction site before building power 556 is switched on for the first time). 558 o Low performance: tiny devices, small memory sizes, low-performance 559 processors, low bandwidth, high loss rates, etc. 561 These fundamental attributes of LoWPANs affect the design of routing 562 solutions. Whether existing routing specifications are simplified 563 and modified, or new solutions are introduced in order to fit the 564 low-power requirements of LoWPANs, they need to meet the requirements 565 described in the following. 567 5.1. Support of 6LoWPAN Device Properties 569 The general objectives listed in this section should be met by 570 6LoWPAN routing protocols. The importance of each requirement is 571 dependent on what node type the protocol is running on and what the 572 role of the node is. The following requirements consider the 573 presence of battery-powered nodes in LoWPANs. 575 [R01] 6LoWPAN routing protocols SHOULD allow implementation with 576 small code size and require low routing state to fit the typical 577 6LoWPAN node capacity. Generally speaking, the code size is bounded 578 by available flash memory size, and the routing table is bounded by 579 RAM size, possibly limiting it to less than 32 entries. 581 The RAM size of LoWPAN nodes often ranges between 4 kB (2 kB 582 minimum) and 10 kB, and program flash memory normally consists of 583 48 kB to 128 kB. (e.g., in the current market, MICAz has 128 kB 584 program flash, 4 kB EEPROM, 512 kB external flash ROM; TIP700CM 585 has 48 kB program flash, 10 kB RAM, 1 MB external flash ROM). 587 Due to these hardware restrictions, code SHOULD fit within a small 588 memory size; no more than 48 kB to 128 kB of flash memory 589 including at least a few tens of KB of application code size. (As 590 a general observation, a routing protocol of low complexity may 591 help achieving the goal of reducing power consumption, improves 592 robustness, requires lower routing state, is easier to analyze, 593 and may be less prone to security attacks.) 595 In addition, operation with limited amounts of routing state (such 596 as routing tables and neighbor lists) SHOULD be maintained since 597 some typical memory sizes preclude storing state of a large number 598 of nodes. For instance, industrial monitoring applications may 599 need to support at maximum 20 hops [RFC5673]. Small networks can 600 be designed to support a smaller number of hops. While the need 601 for this is highly dependent on the network architecture, there 602 should be at least one mode of operation that can function with 32 603 forwarding entries or less. 605 [R02] 6LoWPAN routing protocols SHOULD cause minimal power 606 consumption by the efficient use of control packets (e.g., minimize 607 expensive IP multicast which causes link broadcast to the entire 608 LoWPAN) and by the efficient routing of data packets. 610 One way of battery lifetime optimization is by achieving a minimal 611 control message overhead. Compared to functions such as 612 computational operations or taking sensor samples, radio 613 communications is by far the dominant factor of power consumption 614 [refs.SmartDust]. Power consumption of transmission and/or 615 reception depends linearly on the length of data units and on the 616 frequency of transmission and reception of the data units 617 [refs.Shih]. 619 The energy consumption of two example RF controllers for low-power 620 nodes is shown in [refs.Hill]. The TR1000 radio consumes 21 mW 621 when transmitting at 0.75 mW, and 15 mW on reception (with a 622 receiver sensitivity of -85 dBm). The CC1000 consumes 31.6 mW 623 when transmitting 0.75 mW, and 20 mW for receiving (with a 624 receiver sensitivity of -105 dBm). The power endurance under the 625 concept of an idealized power source is explained in [refs.Hill]. 626 Based on the energy of an idealized AA battery, the CC1000 can 627 transmit for approximately 4 days straight or receive for 9 628 consecutive days. Note that availability for reception consumes 629 power as well. 631 As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing 632 protocol SHOULD minimize the control cost by multicasting routing 633 packets. 635 Control cost of routing protocols in low power and lossy networks 636 is discussed in more detail in [I-D.ietf-roll-protocols-survey]. 638 5.2. Support of 6LoWPAN Link Properties 640 6LoWPAN links have the characteristics of low data rate and possibly 641 high loss rates. The routing requirements described in this section 642 are derived from the link properties. 644 [R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a 645 single IEEE 802.15.4 frame size in order to avoid packet 646 fragmentation and the overhead for reassembly. 648 In order to save energy, routing overhead should be minimized to 649 prevent fragmentation of frames. Therefore, 6LoWPAN routing 650 should not cause packets to exceed the IEEE 802.15.4 frame size. 651 This reduces the energy required for transmission, avoids 652 unnecessary waste of bandwidth, and prevents the need for packet 653 reassembly. As calculated in RFC4944 [RFC4944], the maximum size 654 of a 6LoWPAN frame, in order not to cause fragmentation, is 81 655 octets. This may imply the use of semantic fragmentation and/or 656 algorithms that can work on small increments of routing 657 information. 659 [R04] The design of routing protocols for LoWPANs must consider the 660 fact that packets are to be delivered with sufficient probability 661 according to application requirements. 663 Requirements on successful end-to-end packet delivery ratio (where 664 delivery may be bounded within certain latency) vary depending on 665 applications. In industrial applications, some non-critical 666 monitoring applications may tolerate successful delivery ratio of 667 less than 90% with hours of latency; in some other cases, a 668 delivery ratio of 99.9% is required [RFC5673]. In building 669 automation applications, application layer errors must be below 670 0.01% [RFC5867]. 672 Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh 673 depends on the quality of the path selected by the routing 674 protocol and on the ability of the routing protocol to cope with 675 short-term and long-term quality variation. The metric of the 676 routing protocol strongly influences performance of the routing 677 protocol in terms of delivery ratio. 679 The quality of a given path depends on the individual qualities of 680 the links (including the devices) that compose that path. IEEE 681 802.15.4 settings affect the quality perceived at upper layers. 682 In particular, in IEEE 802.15.4 reliable mode, if an 683 acknowledgment frame is not received after a given period, the 684 originator retries frame transmission up to a maximum number of 685 times. If an acknowledgment frame is still not received by the 686 sender after performing the maximum number of transmission 687 attempts, the MAC layer assumes the transmission has failed and 688 notifies the next higher layer of the failure. Note that 689 excessive retransmission may be detrimental, see RFC 3819 690 [RFC3819]. 692 [R05] The design of routing protocols for LoWPANs must consider the 693 latency requirements of applications and IEEE 802.15.4 link latency 694 characteristics. 696 Latency requirements may differ from a few hundreds milliseconds 697 to minutes, depending on the type of application. Real-time 698 building automation applications usually need response times below 699 500 ms between egress and ingress, while forced entry security 700 alerts must be routed to one or more fixed or mobile user devices 701 within 5 s [RFC5867]. Non-critical closed loop applications for 702 industrial automation have latency requirements that can be as low 703 as 100 ms but many control loops are tolerant of latencies above 704 1 s [RFC5673]. In contrast to this, urban monitoring applications 705 allow latencies smaller than the typical intervals used for 706 reporting sensed information; for instance, in the order of 707 seconds to minutes [RFC5548]. 709 The range of latencies of a frame transmission between a single 710 sender and a single receiver through an ideal unslotted IEEE 711 802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms in 64 bit 712 MAC address unreliable mode and 2.20 ms to 6.56 ms in 64 bit 713 address reliable mode. The range of latencies of 868 MHz band is 714 from 11.7 ms to 63.7 ms, depending on the address type and 715 reliable/unreliable mode used. Note that the latencies may be 716 larger than that depending on channel load, MAC layer settings 717 procedure, and reliable/unreliable mode choice. Note that other 718 MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA). 719 Duty cycling may further affect latency (see [R08]). Depending on 720 the routing path chosen and the network diameter, multiple of 721 these hops may contribute to the end-to-end latency that 722 application experience. 724 Note that a tradeoff exists between [R05] and [R04]. 726 [R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss 727 caused by link failure or device unavailability either in the short 728 term (ca. 30 ms), due to RSSI variation, interference variation, 729 noise and asynchrony, or in the long term, due to a depleted power 730 source, hardware breakdown, operating system misbehavior, etc. 732 An important trait of 6LoWPAN devices is their unreliability due 733 to limited system capabilities, and also because they might be 734 closely coupled to the physical world with all its unpredictable 735 variation. In harsh environments, LoWPANs easily suffer from link 736 failure. Collision or link failure easily increases send and 737 receive queues and can lead to queue overflow and packet losses. 739 For home applications, where users expect feedback after carrying 740 out actions (such as handling a remote control while moving 741 around), routing protocols must converge within 2 seconds if the 742 destination node of the packet has moved and must converge within 743 0.5 seconds if only the sender has moved [RFC5826]. The tolerance 744 of the recovery time can vary depending on the application, 745 however, the routing protocol must provide the detection of short- 746 term unavailability and long-term disappearance. The routing 747 protocol has to exploit network resources (e.g. path redundancy) 748 to offer good network behavior despite of node failure. 750 Different routing protocols may exhibit different scaling 751 characteristics with respect to the recovery/convergence time and 752 the computational resources to achieve recovery after a 753 convergence, hence see also R01/R10. 755 [R07] 6LoWPAN routing protocols SHOULD be designed to correctly 756 operate in the presence of link asymmetry. 758 Link asymmetry occurs when the probability of successful 759 transmission between two nodes is significantly higher in one 760 direction than in the other one. This phenomenon has been 761 reported in a large number of experimental studies and it is 762 expected that 6LoWPANs will exhibit link asymmetry. 764 5.3. Support of 6LoWPAN Network Characteristics 766 6LoWPANs can be deployed in different sizes and topologies, adhere to 767 various models of mobility, be exposed to various levels of 768 interference, etc. In any case, LoWPANs must maintain low energy 769 consumption. The requirements described in the following subsection 770 are derived from the network attributes of 6LoWPANs. 772 [R08] The design of 6LoWPAN routing protocols SHOULD take into 773 account that some nodes may be unresponsive during certain time 774 intervals due to periodic hibernation. 776 Many nodes in LoWPAN environments might periodically hibernate 777 (i.e. disable their transceiver activity) in order to save energy. 778 Therefore, routing protocols must ensure robust packet delivery 779 despite nodes frequently shutting off their radio transmission 780 interface. Feedback from the lower IEEE 802.15.4 layer may be 781 considered to enhance the power-awareness of 6LoWPAN routing 782 protocols. 784 CC1000-based nodes must operate at a duty cycle of approximately 785 2% to survive for one year from idealized AA battery power source 786 [refs.Hill]. For home automation purposes, it is suggested that 787 the devices have to maximize the sleep phase with a duty cycle 788 lower than 1% [RFC5826], while in building automation 789 applications, batteries must be operational for at least 5 years 790 when the sensing devices are transmitting data (e.g. 64 bytes) 791 once per minute [RFC5867]. 793 Dependent on the application in use, packet rates may range from 794 one per second to one per day or beyond. Routing protocols may 795 take advantage of knowledge about the packet transmission rate and 796 utilize this information in calculating routing paths. In many 797 IEEE 802.15.4 deployments, and in other wireless low-power 798 technologies, forwarders are mains-powered devices (and hence do 799 not need to sleep). However, it cannot be assumed that all 800 forwarders are mains-powered. A routing protocol that addresses 801 this case SHOULD provide a mode in which power consumption is a 802 metric. In addition, using nodes in power-saving modes for 803 forwarding may increase delay and reduce packet delivery 804 probability, which in this case also should be available as an 805 input into the path computation. 807 [R09] The metric used by 6LoWPAN routing protocols SHOULD provide 808 some flexibility with respect to the inputs provided by the lower 809 layers and other measures to optimize path selection considering 810 energy balance and link qualities. 812 In homes, buildings, or infrastructure, some nodes will be 813 installed with mains power. Such power-installed nodes MUST be 814 considered as relay points for a prominent role in packet 815 delivery. 6LoWPAN routing protocols MUST know the power 816 constraints of the nodes. 818 Simple hop-count-only mechanisms may be inefficient in 6LoWPANs. 819 There is a Link Quality Indication (LQI), or/and RSSI from IEEE 820 802.15.4 that may be taken into account for better metrics. The 821 metric to be used (and its goal) may depend on applications and 822 requirements. 824 The numbers in Figure 4 represent the Link Delivery Ratio (LDR) of 825 each pair of nodes. There are studies that show a piecewise 826 linear dependence between LQI and LDR [refs.Chen]. 828 0.6 829 A-------C 830 \ / 831 0.9 \ / 0.9 832 \ / 833 B 835 Figure 4: An example network 837 In this simple example, there are two options in routing from node 838 A to node C, with the following features: 840 A. Path AC: 842 + (1/0.6) = 1.67 avg. transmissions needed for each packet 843 (confirmed link layer delivery with retransmissions and 844 negligible ACK loss have been assumed) 846 + one-hop path 848 + good in energy consumption and end-to-end latency of data 849 packets, bad in delivery ratio (0.6) 851 + bad in probability of route reconfigurations 853 B. Path ABC: 855 + (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each 856 packet (under the same assumptions as above) 858 + two-hop path 860 + bad in energy consumption and end-to-end latency of data 861 packets, good in delivery ratio (0.81) 863 If energy consumption of the network must be minimized, path AC is 864 the best (this path would be chosen based on a hop count metric). 865 However, if the delivery ratio in that case is not sufficient, the 866 best path is ABC (it would be chosen by an LQI based metric). 867 Combinations of both metrics can be used. 869 The metric also affects the probability of route reconfiguration. 870 Route reconfiguration, which may be triggered by packet losses, 871 may require transmission of routing protocol messages. It is 872 possible to use a metric aimed at selecting the path with low 873 route reconfiguration rate by using LQI as an input to the metric. 874 Such a path has good properties, including stability and low 875 control message overhead. 877 Note that a tradeoff exists between [R09] and [R01]. 879 [R10] 6LoWPAN routing protocols SHOULD be designed to achieve both 880 scalability from a few nodes to maybe millions of nodes and 881 minimality in terms of used system resources. 883 A LoWPAN may consist of just a couple of nodes (for instance in a 884 body-area network), but may also contain much higher numbers of 885 devices (e.g. monitoring of a city infrastructure or a highway). 886 For home automation applications it is envisioned that the routing 887 protocol must support 250 devices in the network [RFC5826], while 888 routing protocols for metropolitan-scale sensor networks must be 889 capable of clustering a large number of sensing nodes into regions 890 containing on the order of 10^2 to 10^4 sensing nodes each 891 [RFC5548]. It is therefore necessary that routing mechanisms are 892 designed to be scalable for operation in various network sizes. 893 However, due to a lack of memory size and computational power, 894 6LoWPAN routing might limit forwarding entries to a small number, 895 such as at maximum 32 routing table entries. Specially in large 896 networks, the routing mechanism MUST be designed in such a way 897 that the number of routers be smaller than the number of hosts. 899 [R11] The procedure of route repair and related control messages 900 SHOULD NOT harm overall energy consumption from the routing 901 protocols. 903 Local repair improves throughput and end-to-end latency, 904 especially in large networks. Since routes are repaired quickly, 905 fewer data packets are dropped, and a smaller number of routing 906 protocol packet transmissions are needed since routes can be 907 repaired without source initiated Route Discovery [refs.Lee]. One 908 important consideration here may be to avoid premature energy 909 depletion, even in case that impairs other requirements. 911 [R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive 912 topologies and mobile nodes. When supporting dynamic topologies and 913 mobile nodes, route maintenance should keep in mind the goal of a 914 minimal routing state and routing protocol message overhead. 916 Topological node mobility may be the result of physical movement 917 and/or of a changing radio environment; making it very likely that 918 mobility needs to be handled even in a network with physically 919 static nodes. 6LoWPAN does not make use of a separate protocol to 920 maintain connectivity to moving nodes but expects the routing 921 protocol to handle it. 923 In addition, some nodes may move from one 6LoWPAN to another and 924 are expected to become functional members of the latter 6LoWPAN in 925 a limited amount of time. 927 Building monitoring applications, for instance, have a number of 928 requirements with respect to recovery and settling time for 929 mobility that range between 5 and 20 seconds (section 5.3.1 of 930 [RFC5867]). For more interactive applications such as used in 931 home automation systems, where users are giving input and expect 932 instant feedback, mobility requirements are also stricter and, for 933 moves within a network, a convergence time below 0.5 seconds is 934 commonly required (section 3.2 of [RFC5826]). In industrial 935 environments, where mobile equipment such as cranes move around, 936 the support of vehicular speeds of up to 35 km/h are required to 937 be supported by the routing protocol [RFC5673]. Currently, 938 6LoWPANs are not normally being used for such a fast mobility, but 939 dynamic association and disassociation MUST be supported in 940 6LoWPAN. 942 There are several challenges that should be addressed by a 6LoWPAN 943 routing protocol in order to create robust routing in dynamic 944 environments: 946 * Mobile nodes changing their location inside a LoWPAN: 947 If the nodes' movement pattern is unknown, mobility cannot 948 easily be detected or distinguished by the routing protocols. 949 Mobile nodes can be treated as nodes that disappear and re- 950 appear in another place. Movement pattern tracking increases 951 complexity and can be avoided by handling moving nodes using 952 reactive route updates. 954 * Movement of a LoWPAN with respect to other (inter)connected 955 LoWPANs: 956 Within each stub network, (one or more) relatively powerful 957 gateway nodes (6LBRs) need to be configured to handle moving 958 LoWPANs. 960 * Nodes permanently joining or leaving the LoWPAN: 961 In order to ease routing table updates, reduce their size, and 962 minimize error control messages, nodes leaving the network may 963 announce their disassociation to the closest edge router or, if 964 any, to a specific node that takes charge of local association 965 and disassociation. 967 [R13] A 6LoWPAN routing protocol SHOULD support various traffic 968 patterns: point-to-point, point-to-multipoint, and multipoint-to- 969 point, while avoiding excessive multicast traffic in a LoWPAN. 971 6LoWPANs often have point-to-multipoint or multipoint-to-point 972 traffic patterns. Many emerging applications include point-to- 973 point communication as well. 6LoWPAN routing protocols should be 974 designed with the consideration of forwarding packets from/to 975 multiple sources/destinations. Current documents of the ROLL 976 working group explain that the workload or traffic pattern of use 977 cases for LoWPANs tends to be highly structured, unlike the any- 978 to-any data transfers that dominate typical client and server 979 workloads. In many cases, exploiting such structure may simplify 980 difficult problems arising from resource constraints or variation 981 in connectivity. 983 5.4. Support of Security 985 The routing requirement described in this subsection allows secure 986 transmission of routing messages. As in traditional networks, 987 routing mechanisms in 6lowpan present another window from which, an 988 attacker might disrupt and significantly degrade the 6lowpan overall 989 performance. Attacks against unsecure routing aim mainly to 990 contaminate WPAN networks with false routing information resulting in 991 routing inconsistencies. A malicious node can also snoop packets and 992 then launch replay attacks on the 6lowpan nodes. These attacks can 993 cause harm especially when the attacker is a high-power device, such 994 as laptop. It can also easily drain 6lowpan devices batteries by 995 sending broadcast messages, redirecting routes etc. 997 [R14] 6LoWPAN routing protocols MUST support confidentiality, 998 authentication and integrity services as required for secure delivery 999 of control messages. 1001 A general set of requirements that may apply to these services can 1002 be found in [I-D.ietf-karp-threats-reqs]. 1004 Security is very important for designing robust routing protocols, 1005 but it should not cause significant transmission overhead. The 1006 security aspect, however, seems a bit tradeoff in the 6lowpan 1007 since security is always a costly function. 6lowpan poses unique 1008 challenges to which, traditional security techniques cannot be 1009 applied directly. For example, public key cryptography primitives 1010 are typically avoided (as being too expensive) as are relatively 1011 heavyweight conventional encryption methods. 1013 Consequently, it becomes questionable whether the 6lowpan devices 1014 can support IPsec as it is. While IPsec is mandatory with IPv6, 1015 considering the power constraints and limited processing 1016 capabilities of IEEE 802.15.4 capable devices, IPsec is 1017 computationally expensive; Internet key exchange (IKEv2) messaging 1018 described in RFC5996 [RFC5996] will not work well in 6lowpans as 1019 we want to minimize the amount of signaling in these networks. 1020 IPsec supports AH for authenticating the IP header and ESP for 1021 authenticating and encrypting the payload. The main issues of 1022 using IPsec are two-fold: (1) processing power and (2) key 1023 management. Since these tiny 6lowpan devices do not process huge 1024 number of data or communicate with many different nodes, it is not 1025 well understood if complete implementation of SADB, policy- 1026 database and dynamic key-management protocol are appropriate for 1027 these small battery powered devices. 1029 Bandwidth is a very scarce resource in 6lowpan environments. The 1030 fact that IPsec additionally requires another header (AH or ESP) 1031 in every packet makes its use problematic in 6lowpan environments. 1032 IPsec requires two communicating peers to share a secret key that 1033 is typically established dynamically with the Internet Key 1034 Exchange (IKEv2) protocol. Thus, it has an additional packet 1035 overhead incurred by IKEv2 packets exchange. 1037 Given existing constraints in 6lowpan environments, IPsec may not 1038 be suitable to use in such environments, especially that 6lowpan 1039 node may not be able to operate all IPsec algorithms on its own 1040 capability. Thus, 6lowpan may need to define its own keying 1041 management method(s) that requires minimum overhead in packet-size 1042 and in number of signaling messages exchange. IPsec will provide 1043 authentication and confidentiality between end-nodes and across 1044 multiple lowpan- links, and may be useful only when two nodes want 1045 to apply security to all exchanged messages. However, in most 1046 cases, the security may be requested at the application layer as 1047 needed, while other messages can flow in the network without 1048 security overhead. 1050 Security threats within LoWPANs may be different from existing 1051 threat models in ad-hoc network environments. If IEEE 802.15.4 1052 security is not used, Neighbor Discovery (ND) in IEEE 802.15.4 1053 links is susceptible to threats. These include NS/NA spoofing, 1054 malicious router, default router killed, good router goes bad, 1055 spoofed redirect, replay attacks and remote ND DoS [RFC3756]. 1056 However, if IEEE 802.15.4 security is used, no other protection is 1057 needed for ND, as long as none of the nodes becomes compromised, 1058 because the Corporate Intranet Model of RFC 3756 can be assumed 1059 [I-D.ietf-6lowpan-nd]. 1061 Bootstrapping may also impose additional threats. For example, a 1062 malicious node can obtain initial configuration information in 1063 order to appear as a legitimate node and then carry out various 1064 types of attacks. Such a node can also keep legitimate nodes busy 1065 by broadcasting authentication/join requests. One option for 1066 mitigating such threats is the use of mutual authentication 1067 schemes based on the use of pre-shared keys [refs.Ikram]. 1069 The IEEE 802.15.4 MAC provides an AES-based security mechanism. 1070 Routing protocols may define how this mechanism (in conjunction 1071 with IP security whenever available) can be used to obtain the 1072 intended security, either for the routing protocol alone or in 1073 conjunction with the security used for the data. Byte overhead of 1074 the mechanism, which depends on the security services selected, 1075 must be considered. In the worst case in terms of overhead, the 1076 mechanism consumes 21 bytes of MAC payload. 1078 The IEEE 802.15.4 MAC security is typically supported by crypto 1079 hardware even in very simple chips that will be used in a 6LoWPAN. 1080 Even if the IEEE 802.15.4 MAC security mechanisms are not used, 1081 this crypto hardware is usually available for use by application 1082 code running on these chips. A security protocol outside IEEE 1083 802.15.4 MAC security SHOULD therefore provide a mode of operation 1084 that is covered by this crypto hardware. 1086 IEEE 802.15.4 does not specify protection for acknowledgement 1087 frames. Since the sequence numbers of data frames are sent in the 1088 clear, an adversary can forge an acknowledgement for each data 1089 frame. This weakness can be combined with targeted jamming to 1090 prevent delivery of selected packets. In consequence, IEEE 1091 802.15.4 acknowledgements cannot be relied upon. In applications 1092 that require high security, the routing protocol must not exploit 1093 feedback from acknowledgements (e.g. to keep track of neighbor 1094 connectivity, see [R16]). 1096 5.5. Support of Mesh Under Forwarding 1098 One LoWPAN may be built as one IPv6 link. In this case, Mesh Under 1099 forwarding mechanisms must be supported. While this document 1100 provides general, layer-agnostic guidelines about the design of 1101 6LoWPAN routing , the requirements in this section are specifically 1102 related to L2 layer. These requirements are directed to bodies that 1103 might consider working on Mesh Under routing, such as IEEE. The 1104 requirements described in this subsection allow optimization and 1105 correct operation of routing solutions taking into account the 1106 specific features of the Mesh Under configuration. 1108 [R15] Mesh Under requires the development of a routing protocol 1109 operating below IP. This protocol MUST support 16-bit short and 64- 1110 bit extended MAC addresses. 1112 [R16] In order to perform discovery and maintenance of neighbors 1113 (i.e., neighborhood discovery as opposed to ND-style neighbor 1114 discovery), LoWPAN Nodes SHOULD avoid sending separate "Hello" 1115 messages. Instead, link-layer mechanisms (such as acknowledgments) 1116 MAY be utilized to keep track of active neighbors. 1118 Reception of an acknowledgement after a frame transmission may 1119 render unnecessary the transmission of explicit Hello messages, 1120 for example. In a more general view, any frame received by a node 1121 may be used as an input to evaluate the connectivity between the 1122 sender and receiver of that frame. 1124 [R17] If the routing protocol functionality includes enabling IP 1125 multicast, then it MAY employ structure in the network for efficient 1126 distribution in order to minimize link layer broadcast. 1128 5.6. Support of Management 1130 When a new protocol is designed, the operational environment and 1131 manageability of the protocol should be considered from the start 1132 [RFC5706]. This subsection provides a requirement on the 1133 manageability of 6LoWPAN routing protocols. 1135 [R18] A 6LoWPAN routing protocol SHOULD be designed according to the 1136 guidelines for operations and management stated in [RFC5706]. 1138 The management operations that a 6LoWPAN routing protocol 1139 implementation can support depend on the memory and processing 1140 capabilities of the 6LoWPAN devices used, which are typically 1141 constrained. However, 6LoWPAN networks may benefit significantly 1142 from supporting 6LoWPAN routing protocol management operations 1143 such as configuration and performance monitoring. 1145 The design of 6LoWPAN routing protocols should take into account 1146 that, according to the Architectural Principles of the Internet 1147 [RFC1958], "options and parameters should be configured or 1148 negotiated dynamically rather than manually". This is especially 1149 important for 6LoWPAN networks, which can be composed of a large 1150 number of devices (and, in addition, these devices may not have an 1151 appropriate user interface). Therefore, parameter 1152 autoconfiguration is a desirable property for a 6LoWPAN routing 1153 protocol, although some subset of routing protocol parameters may 1154 allow other forms of configuration as well. 1156 In order to verify the correct operation of the 6LoWPAN routing 1157 protocol and the network itself, a 6LoWPAN routing protocol should 1158 allow monitoring the status and/or value of 6LoWPAN routing 1159 protocol parameters and data structures such as routing table 1160 entries. In order to enable fault management, further monitoring 1161 of the 6LoWPAN routing protocol operation is needed. For this, 1162 faults can be reported via error log messages. These messages may 1163 contain information such as number of times a packet could not be 1164 sent to a valid next hop, duration of each period without 1165 connectivity, memory overflow and its reasons, etc. 1167 [RFC5706], and in particular section 3 of this document, provides 1168 a comprehensive guide in order to properly design the management 1169 solution for a 6LoWPAN routing protocol. 1171 6. Security Considerations 1173 Security issues are described in Section 5.4. The security 1174 considerations in RFC 4919 [RFC4919], RFC 4944 [RFC4944] and RFC 4593 1175 [RFC4593] apply as well. 1177 The use of wireless links renders a 6LoWPAN susceptible to attacks 1178 like any other wireless network. In outdoor 6LoWPANs, the physical 1179 exposure of the nodes allows an adversary to capture, clone or tamper 1180 with these devices. In ad-hoc 6LoWPANs that are dynamic in both 1181 their topology and node memberships, a static security configuration 1182 does not suffice. Spoofed, altered, or replayed routing information 1183 might occur while multihopping could delay the detection and 1184 treatment of attacks. 1186 This specification expects that the link layer is sufficiently 1187 protected, either by means of physical or IP security for the 1188 backbone link or with MAC sublayer cryptography. However, link-layer 1189 encryption and authentication may not be sufficient to provide 1190 confidentiality, authentication, integrity, and freshness to both 1191 data and routing protocol packets. Time synchronization, self- 1192 organization and secure localization for multi-hop routing are also 1193 critical to support. 1195 For secure routing protocol operation, it may be necessary to 1196 consider authenticated broadcast (and multicast) and bidirectional 1197 link verification. On the other hand, secure end-to-end data 1198 delivery can be assisted by the routing protocol. For example, 1199 multi-path routing could be considered for increasing security to 1200 prevent selective forwarding. However, the challenge is that 1201 6LoWPANs already have high resource constraints, so that 6LBR and 1202 LoWPAN nodes may require different security solutions. 1204 7. IANA Considerations 1206 This document contains no actions for IANA. 1208 8. Acknowledgements 1210 The authors highly appreciate the authors of "6LoWPAN security 1211 analysis" document (draft-daniel-6lowpan-security-analysis-04). 1212 Although their security analysis work is not continuous at this 1213 moment, the valuable information and text of the docuement is used in 1214 Section 5.4 in this docuement, by advice during IESG review 1215 procedures. Thanks to the work, the Section 5.4 is well improved. 1216 The authors also thank S. Chakrabarti who gave valuable comments for 1217 mesh-under requirements and A. Petrescu for significant review. 1219 9. References 1221 9.1. Normative References 1223 [IEEE802.15.4] 1224 IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as 1225 amended)", 2007. 1227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1228 Requirement Levels", BCP 14, RFC 2119, March 1997. 1230 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1231 Discovery (ND) Trust Models and Threats", RFC 3756, 1232 May 2004. 1234 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1235 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1236 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1237 RFC 3819, July 2004. 1239 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1240 Routing Protocols", RFC 4593, October 2006. 1242 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1243 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1244 Overview, Assumptions, Problem Statement, and Goals", 1245 RFC 4919, August 2007. 1247 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1248 "Transmission of IPv6 Packets over IEEE 802.15.4 1249 Networks", RFC 4944, September 2007. 1251 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1252 "Routing Requirements for Urban Low-Power and Lossy 1253 Networks", RFC 5548, May 2009. 1255 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1256 "Industrial Routing Requirements in Low-Power and Lossy 1257 Networks", RFC 5673, October 2009. 1259 9.2. Informative References 1261 [I-D.ietf-6lowpan-nd] 1262 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 1263 Discovery Optimization for Low Power and Lossy Networks 1264 (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), 1265 October 2011. 1267 [I-D.ietf-karp-threats-reqs] 1268 Lebovitz, G., Bhatia, M., and R. White, "The Threat 1269 Analysis and Requirements for Cryptographic Authentication 1270 of Routing Protocols' Transports", 1271 draft-ietf-karp-threats-reqs-01 (work in progress), 1272 October 2010. 1274 [I-D.ietf-roll-protocols-survey] 1275 Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview 1276 of Existing Routing Protocols for Low Power and Lossy 1277 Networks", draft-ietf-roll-protocols-survey-07 (work in 1278 progress), April 2009. 1280 [RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of 1281 Lots of Links (TRILL): Problem and Applicability 1282 Statement", RFC 5556, May 2009. 1284 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1285 Management of New Protocols and Protocol Extensions", 1286 RFC 5706, November 2009. 1288 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1289 Routing Requirements in Low-Power and Lossy Networks", 1290 RFC 5826, April 2010. 1292 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1293 "Building Automation Routing Requirements in Low-Power and 1294 Lossy Networks", RFC 5867, June 2010. 1296 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1297 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1298 RFC 5996, September 2010. 1300 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1301 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1302 September 2011. 1304 [refs.Chen] 1305 Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc 1306 Multicast Routing on Resource-Limited Sensor Nodes", 2006. 1308 [refs.Hill] 1309 Hill, J., "System Architecture for Wireless Sensor 1310 Networks". 1312 [refs.Ikram] 1313 Ikram, M., "A Simple Lightweight Authentic Bootstrapping 1314 Protocol for IPv6-based Low Rate Wireless Personal Area 1315 Networks (6LoWPANs)", June 2009. 1317 [refs.Kuhn] 1318 Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case 1319 Optimal and Average-Case Efficient Ad-Hoc Geometric 1320 Routing", 2003. 1322 [refs.Latre] 1323 Latre, M., De Mil, P., Moerman, I., Dhoedt, B., and P. 1324 Demeester, "Throughput and Delay Analysis of Unslotted 1325 IEEE 802.15.4", May 2006. 1327 [refs.Lee] 1328 Lee, S., Belding-Royer, E., and C. Perkins, "Scalability 1329 Study of the Ad Hoc On-Demand Distance-Vector Routing 1330 Protocol", March 2003. 1332 [refs.Shih] 1333 Shih, E., "Physical Layer Driven Protocols and Algorithm 1334 Design for Energy-Efficient Wireless Sensor Networks", 1335 July 2001. 1337 [refs.SmartDust] 1338 Pister, K. and B. Boser, "Smart Dust: Wireless Networks of 1339 Millimeter-Scale Sensor Nodes". 1341 [refs.bulusu] 1342 Bulusu, N. and S. Jha, "Wireless Sensor Networks", 1343 July 2005. 1345 [refs.cctc] 1346 Lu, J., Valois, F., Dohler, M., and D. Barthel, 1347 "Quantifying Organization by Means of Entropy", 2008. 1349 Authors' Addresses 1351 Eunsook Eunah Kim 1352 ETRI 1353 161 Gajeong-dong 1354 Yuseong-gu 1355 Daejeon 305-700 1356 Korea 1358 Phone: +82-42-860-6124 1359 Email: eunah.ietf@gmail.com 1361 Dominik Kaspar 1362 Simula Research Laboratory 1363 Martin Linges v 17 1364 Fornebu 1364 1365 Norway 1367 Phone: +47-6782-8223 1368 Email: dokaspar.ietf@gmail.com 1370 Carles Gomez 1371 Universitat Politecnica de Catalunya/i2CAT 1372 Escola Politecnica Superior de Castelldefels 1373 C/Esteve Terradas, 7 1374 Castelldefels 08860 1375 Spain 1377 Phone: +34-93-413-7206 1378 Email: carlesgo@entel.upc.edu 1380 Carsten Bormann 1381 Universitaet Bremen TZI 1382 Postfach 330440 1383 Bremen D-28359 1384 Germany 1386 Phone: +49-421-218-63921 1387 Fax: +49-421-218-7000 1388 Email: cabo@tzi.org