idnits 2.17.00 (12 Aug 2021) /tmp/idnits7308/draft-dokaspar-6lowpan-routreq-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1092. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: [R03] 6LoWPAN routing protocol control messages SHOULD not create fragmentation of physical layer (PHY) frames. -- 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 (November 17, 2008) is 4926 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) -- Looks like a reference, but probably isn't: 'Note' on line 158 -- Looks like a reference, but probably isn't: 'A' on line 252 -- Looks like a reference, but probably isn't: 'B' on line 253 -- Looks like a reference, but probably isn't: 'R01' on line 501 -- Looks like a reference, but probably isn't: 'R02' on line 532 -- Looks like a reference, but probably isn't: 'R03' on line 569 -- Looks like a reference, but probably isn't: 'R04' on line 646 -- Looks like a reference, but probably isn't: 'R05' on line 646 -- Looks like a reference, but probably isn't: 'R06' on line 648 -- Looks like a reference, but probably isn't: 'R07' on line 673 -- Looks like a reference, but probably isn't: 'R08' on line 690 -- Looks like a reference, but probably isn't: 'R09' on line 714 -- Looks like a reference, but probably isn't: 'R10' on line 781 -- Looks like a reference, but probably isn't: 'R11' on line 799 -- Looks like a reference, but probably isn't: 'R12' on line 811 -- Looks like a reference, but probably isn't: 'R13' on line 851 -- Looks like a reference, but probably isn't: 'R14' on line 874 -- Looks like a reference, but probably isn't: 'R15' on line 901 -- Looks like a reference, but probably isn't: 'R16' on line 905 -- Looks like a reference, but probably isn't: 'R17' on line 913 -- Looks like a reference, but probably isn't: 'R18' on line 917 == Unused Reference: '1' is defined on line 939, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-01) exists of draft-shelby-6lowpan-nd-00 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: draft-ietf-roll-indus-routing-reqs has been published as RFC 5673 == Outdated reference: draft-ietf-roll-urban-routing-reqs has been published as RFC 5548 == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: A later version (-07) exists of draft-ietf-roll-protocols-survey-02 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 29 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 Expires: May 21, 2009 D. Kaspar 5 Simula Research Laboratory 6 C. Gomez 7 Tech. Univ. of Catalonia/i2CAT 8 C. Bormann 9 Universitaet Bremen TZI 10 November 17, 2008 12 Problem Statement and Requirements for 6LoWPAN Routing 13 draft-dokaspar-6lowpan-routreq-08 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 21, 2009. 40 Abstract 42 This document provides the problem statement for 6LoWPAN routing. It 43 also defines the requirements for 6LoWPAN routing considering IEEE 44 802.15.4 specificities and the low-power characteristics of the 45 network and its devices. 47 Table of Contents 49 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Design Space . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3. Scenario Considerations and Parameters for 6LoWPAN Routing . . 8 52 4. 6LoWPAN Routing Requirements . . . . . . . . . . . . . . . . . 13 53 4.1. Support of 6LoWPAN Device Properties . . . . . . . . . . . 13 54 4.2. Support of 6LoWPAN Link Properties . . . . . . . . . . . . 15 55 4.3. Support of 6LoWPAN Network Characteristics . . . . . . . . 17 56 4.4. Support of Security . . . . . . . . . . . . . . . . . . . 21 57 4.5. Support of Mesh-under Forwarding . . . . . . . . . . . . . 22 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 64 Intellectual Property and Copyright Statements . . . . . . . . . . 28 66 1. Problem Statement 68 In the context of this document, low-power wireless personal area 69 networks (LoWPANs) are formed by devices that are compatible with the 70 IEEE 802.15.4 standard [6]. Most of the LoWPAN devices are 71 distinguished by their low bandwidth, short range, scarce memory 72 capacity, limited processing capability and other attributes of 73 inexpensive hardware. In this document, the characteristics of nodes 74 participating in LoWPANs are assumed to be those described in RFC 75 4919 [3]. 77 IEEE 802.15.4 networks support star and mesh topologies and consist 78 of two different device types: reduced-function devices (RFDs) and 79 full-function devices (FFDs). RFDs have the most limited 80 capabilities and are intended to perform only simple and basic tasks, 81 such as reporting sensed data. RFDs may only associate with a single 82 FFD at a time, but FFDs may form arbitrary topologies and implement 83 more advanced functions, such as multi-hop routing. 85 However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format 86 specification ("IPv6 over IEEE 802.15.4" [4]) define how mesh 87 topologies could be obtained and maintained. Thus, the 6LoWPAN 88 formation and multi-hop routing should be supported by higher layers, 89 either the 6LoWPAN adaptation layer or the IP layer. A number of IP 90 layer routing protocols have been developed in various IETF working 91 groups. However, these existing routing protocols may not satisfy 92 the requirements of mesh routing in LoWPANs, for the following 93 reasons: 95 o 6LoWPAN nodes have special types and roles, such as primary 96 battery-operated RFDs, battery-operated and mains-powered FFDs, 97 possibly various levels of RFDs and FFDs, mains-powered and high- 98 performance gateways, data aggregators, etc. 6LoWPAN routing 99 protocols should support multiple device types and roles. 101 o The more stringent requirements that apply to 6LoWPANs, as opposed 102 to higher performance or non-battery-operated networks, may not 103 suffice. 6LoWPAN nodes are characterized by small memory sizes, 104 low processing power, and are running on very limited power 105 supplied by primary non-rechargeable batteries (a few KBytes of 106 RAM, a few dozens of KBytes of ROM/flash memory, and a few MHz of 107 CPU is typical). A node's lifetime is usually defined by the 108 lifetime of its battery. 110 o Handling sleeping nodes is very critical in 6LoWPANs, more than in 111 traditional ad-hoc networks. 6LoWPAN nodes might stay in sleep- 112 mode for most of the time. Time synchronization is important for 113 efficient forwarding of packets. 115 o Routing in LoWPANs might possibly translate to a simpler problem 116 than routing in higher-performance networks. 6LoWPANs might be 117 either transit networks or stub networks. Under the assumption 118 that 6LoWPANs are never transit networks (as implied by [4] and 119 [8]), routing protocols may be drastically simplified. This 120 document will primarily focus on stub networks. Based on the 121 necessity, this document may be extended with 6LoWPAN network 122 configurations that include transit networks. 124 o Routing in 6LoWPANs might possibly translate to a harder problem 125 than routing in higher-performance networks. Routing in 6LoWPANs 126 requires power-optimization, stable operation in harsh 127 environments, data-aware routing, etc. These requirements are not 128 easily satisfiable all at once. 130 This creates new challenges on obtaining robust and reliable routing 131 within LoWPANs. 133 The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" 134 [3]) briefly mentions four requirements on routing protocols; 136 (a) low overhead on data packets 138 (b) low routing overhead 140 (c) minimal memory and computation requirements 142 (d) support for sleeping nodes considering battery saving 144 These four high-level requirements only describe the need for low 145 overhead and power saving. But, based on the fundamental features of 146 LoWPAN, more detailed routing requirements are presented in this 147 document, which can lead to further analysis and protocol design. 149 Using the 6LoWPAN header format [4], there are two layers routing 150 protocols can be defined at, commonly referred to as "mesh-under" and 151 "route-over". The mesh-under approach supports routing under the IP 152 link and is directly based on the link-layer IEEE 802.15.4 standard, 153 therefore using (64-bit or 16-bit short) MAC addresses. On the other 154 hand, the route-over approach relies on IP routing and therefore 155 supports routing over possibly various types of interconnected links 156 (see also Figure 1). Most statements in this document consider both 157 the mesh-under and route-over cases. 158 [Note] The ROLL WG is now working on the protocol survey for Low 159 power and Lossy Networks (LLNs), not specifically for 6LoWPAN. After 160 that survey, it will be decided whether new solutions will be 161 developed or not. This document is focused on 6LoWPAN specific 162 requirements, in alignment with the ROLL WG. 164 Considering the problems above, detailed 6LoWPAN routing requirements 165 must be defined. Application-specific features affect the design of 166 6LoWPAN routing requirements and the corresponding solutions. 167 However, various applications can be profiled by similar technical 168 characteristics, although the related detailed requirements might 169 differ (e.g., a few dozens of nodes for home lighting system need 170 appropriate scalability for the applications, while billions of nodes 171 for a highway infrastructure system also needs appropriate 172 scalability). This document states the routing requirements of 173 6LoWPAN applications in general, while trying to give examples for 174 different cases of routing. This routing requirement document does 175 not imply that a single routing solution may be the best one for all 176 6LoWPAN applications. 178 2. Design Space 180 Apart from a wide variety of routing algorithms possible for 6LoWPAN, 181 the question remains as to whether routing should be performed mesh- 182 under (in the adaptation layer defined by the 6lowpan format document 183 [4]), or by the IP-layer using a route-over approach. The most 184 significant consequence of mesh-under routing is that routing would 185 be directly based on the IEEE 802.15.4 standard, therefore using (64- 186 bit or 16-bit short) MAC addresses instead of IP addresses, and a 187 LoWPAN would be seen as a single IP link. In case a route-over 188 mechanism is to be applied to a LoWPAN it must also support 6LoWPAN's 189 unique properties using global IPv6 addressing. One radio hop would 190 be seen as a single IP link [8]. In case a route-over mechanism is 191 to be applied to a LoWPAN it must also support 6LoWPAN's unique 192 properties of global IPv6 addressing. 194 Figure 1 shows the place of 6LoWPAN routing in the entire network 195 stack. 197 +-----------------------------+ +-----------------------------+ 198 | Application Layer | | Application Layer | 199 +-----------------------------+ +-----------------------------+ 200 | Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) | 201 +-----------------------------+ +-----------------------------+ 202 | Network Layer (IPv6) | | Network +---------+ | 203 +-----------------------------+ | Layer | Routing | | 204 | 6LoWPAN +---------+ | | (IPv6) +---------+ | 205 | Adaptation | Routing | | +-----------------------------+ 206 | Layer +---------+ | | 6LoWPAN Adaptation Layer | 207 +-----------------------------+ +-----------------------------+ 208 | IEEE 802.15.4 (MAC) | | IEEE 802.15.4 (MAC) | 209 +-----------------------------+ +-----------------------------+ 210 | IEEE 802.15.4 (PHY) | | IEEE 802.15.4 (PHY) | 211 +-----------------------------+ +-----------------------------+ 213 Figure 1: Mesh-under (left) and route-over routing (right) 215 In order to avoid packet fragmentation and the overhead for 216 reassembly, routing packets should fit into a single IEEE 802.15.4 217 physical frame and application data should not be expanded to an 218 extent that they no longer fit. 220 If a mesh-under routing protocol is built for operation in 6LoWPAN's 221 adaptation layer, routing control packets are placed after the 222 6LoWPAN Dispatch, unless a new code type is assigned for mesh-under 223 routing. Multiple routing protocols can be supported by the usage of 224 different Dispatch bit sequences. In use cases where predefined 225 layer two forwarding is appropriate, the mesh-header defined in RFC 226 4944 [4] is sufficient. When a route-over protocol is built in the 227 IPv6 layer, the Dispatch value can be chosen as one of the Dispatch 228 patterns for 6LoWPAN, compressed or uncompressed IPv6, followed by 229 the IPv6 header. 231 As described in RFC 4944 [4], if a 6LoWPAN is formed, the Edge Router 232 (ER) is the only IPv6 router in the LoWPAN (see Figure 2). A mesh- 233 under routing mechanism MUST be provided to forward packets which 234 require multi-hop forwarding. 236 If route-over routing is used in the stub-network, not only the ER 237 but also other intermediate nodes become LoWPAN router and set up 238 IPv6 paths for multi-hop transmission. 240 O X 241 / | ER: Edge Router 242 ER --- O --- O --- X O: Intermediate node (FFD) 243 / \ X: End host (FFD or RFD) 244 X O --- X 245 | 246 / \ 247 O - O -- X 249 Figure 2: An example of a 6LoWPAN 251 If multiple 6LoPWANs are formed with globally unique IPv6 addresses 252 in the 6LoWPANs, and node (a) of 6LoWPAN [A] wants to communicate 253 with node (b) of 6LoWPAN [B], the normal IPv6 mechanisms can be 254 employed. For mesh-under, one way is to configure the ER as the 255 default router for the outgoing packets of the 6LoWPAN. This, of 256 course, assumes the existence of a mesh-under routing protocol in 257 order to reach the ER. For route-over, a default route to the ER 258 could be inserted into the routing system. 260 3. Scenario Considerations and Parameters for 6LoWPAN Routing 262 IP-based low-power WPAN technology is still in its early stage of 263 development, but the range of conceivable usage scenarios is 264 tremendous. The numerous possible applications of sensor networks 265 make it obvious that mesh topologies will be prevalent in LoWPAN 266 environments and robust routing will be a necessity for expedient 267 communication. Research efforts in the area of sensor networking 268 have put forth a large variety of multi-hop routing algorithms [7]. 269 Most related work focuses on optimizing routing for specific 270 application scenarios, which can largely be categorized into several 271 models of communication, including the following ones: 273 o Flooding (in very small networks) 275 o Data-aware routing (dissemination vs. gathering) 277 o Event-driven vs. query-based routing 279 o Geographic routing 281 o Probabilistic routing 283 o Hierarchical routing 285 Depending on the topology of a 6LoWPAN and the application(s) running 286 over it, different types of routing may be used. However, this 287 document abstracts from application-specific communication and 288 describes general routing requirements valid for overall routing in 289 6LoWPANs. 291 The following parameters can be used to describe specific scenarios 292 in which the candidate routing protocols could be evaluated. 294 a. Network Properties: 296 * Number of Devices, Density and Network Diameter: 297 These parameters usually affect the routing state directly 298 (e.g. the number of entries in a routing table or neighbor 299 list). Especially in large and dense networks, policies must 300 be applied for discarding "low-quality" and stale routing 301 entries in order to prevent memory overflow. 303 * Connectivity: 304 Due to external factors or programmed disconnections, a 305 6LoWPAN can be in several states of connectivity; anything in 306 the range from "always connected" to "rarely connected". This 307 poses great challenges to the dynamic discovery of routes 308 across a LoWPAN. 310 * Dynamicity (including mobility): 311 Location changes can be induced by unpredictable external 312 factors or by controlled motion, which may in turn cause route 313 changes. Also, nodes may dynamically be introduced into a 314 LoWPAN and removed from it later. The routing state and the 315 volume of control messages may heavily dependent on the number 316 of moving nodes in a LoWPAN and their speed. 318 * Deployment: 319 In a LoWPAN, it is possible for nodes to be scattered randomly 320 or to be deployed in an organized manner. The deployment can 321 occur at once, or as an iterative process, which may also 322 affect the routing state. 324 * Spatial Distribution of Nodes and Gateways: 325 Network connectivity depends on the spatial distribution of 326 the nodes, and on other factors like device number, density 327 and transmission range. For instance, nodes can be placed on 328 a grid, or can be randomly placed in an area (bidimensional 329 Poisson distribution), etc. In addition, if the LoWPAN is 330 connected to other networks through infrastructure nodes 331 called gateways, the number and spatial distribution of 332 gateways affects network congestion and available bandwidth, 333 among others. 335 * Traffic Patterns, Topology and Applications: 336 The design of a LoWPAN and the requirements on its application 337 have a big impact on the network topology and the most 338 efficient routing type to be used. For different traffic 339 patterns (point-to-point, multipoint-to-point, point-to- 340 multipoint) and network architectures, various routing 341 mechanisms have been introduced, such as data-aware, event- 342 driven, address-centric, and geographic routing. 344 * Classes of Service: 345 For mission-critical applications, support of multiple classes 346 of service may be required in resource-constrained LoWPANs and 347 may require a certain degree of routing protocol overhead. 349 * Security: 350 LoWPANs may carry sensitive information and require a high 351 level of security support where the availability, integrity, 352 and confidentiality of data are primordial. Secured messages 353 cause overhead and affect the power consumption of LoWPAN 354 routing protocols. 356 b. Node Parameters: 358 * Processing Speed and Memory Size: 359 These basic parameters define the maximum size of the routing 360 state. LoWPAN nodes may have different performance 361 characteristics beyond the common RFD/FFD distinction. 363 * Power Consumption and Power Source: 364 The number and topology of battery- and mains-powered nodes in 365 a LoWPAN affect routing protocols in their selection of 366 optimal paths for network lifetime maximization. 368 * Transmission Range: 369 This parameter affects routing. For example, a high 370 transmission range may cause a dense network, which in turn 371 results in more direct neighbors of a node, higher 372 connectivity and a larger routing state. 374 * Traffic Pattern: This parameter affects routing since high- 375 loaded nodes (either because they are the source of packets to 376 be transmitted or due to forwarding) may incur a greater 377 contribution to delivery delays and may consume more energy 378 than lightly loaded nodes. This applies to both data packets 379 and routing control messages. 381 c. Link Parameters: 382 This section discusses link parameters that apply to IEEE 383 802.15.4 legacy mode (i.e. not making use of improved modulation 384 schemes). 386 * Throughput: 387 The maximum user data throughput of a bulk data transmission 388 between a single sender and a single receiver through an 389 unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is 390 as follows [19]: 392 + 16-bit MAC addresses, unreliable mode: 151.6 kbps 394 + 16-bit MAC addresses, reliable mode: 139.0 kbps 396 + 64-bit MAC addresses, unreliable mode: 135.6 kbps 398 + 64-bit MAC addresses, reliable mode: 124.4 kbps 400 In the case of 915 MHz band: 402 + 16-bit MAC addresses, unreliable mode: 31.1 kbps 403 + 16-bit MAC addresses, reliable mode: 28.6 kbps 405 + 64-bit MAC addresses, unreliable mode: 27.8 kbps 407 + 64-bit MAC addresses, reliable mode: 25.6 kbps 409 In the case of 868 MHz band: 411 + 16-bit MAC addresses, unreliable mode: 15.5 kbps 413 + 16-bit MAC addresses, reliable mode: 14.3 kbps 415 + 64-bit MAC addresses, unreliable mode: 13.9 kbps 417 + 64-bit MAC addresses, reliable mode: 12.8 kbps 419 * Latency: 420 The range of latencies of a frame transmission between a 421 single sender and a single receiver through an unslotted IEEE 422 802.15.4 2.4 GHz channel in ideal conditions are as shown next 423 [19]. For unreliable mode, the actual latency is provided. 424 For reliable mode, the round-trip-time including transmission 425 of a layer two acknowledgment is provided: 427 + 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms] 429 + 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms] 431 + 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms] 433 + 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms] 435 In the case of 915 MHz band: 437 + 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms] 439 + 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms] 441 + 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms] 443 + 64-bit MAC addresses, reliable mode: [11.45 ms, 31.85 ms] 445 In the case of 868 MHz band: 447 + 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms] 449 + 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms] 450 + 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms] 452 + 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms] 454 4. 6LoWPAN Routing Requirements 456 This section defines a list of requirements for 6LoWPAN routing. The 457 most important design property unique to low-power networks is that 458 6LoWPANs have to support multiple device types and roles, for 459 example: 461 o primarily battery-operated host nodes (called "power-constrained 462 nodes" in the following) 464 o mains-powered host nodes (an example for what we call "power- 465 affluent nodes") 467 o power-affluent (but not necessarily mains-powered) high- 468 performance gateway(s) 470 o possibly various levels of nodes (data aggregators, relayers, 471 etc.) 473 Due to these unique device types and roles 6LoWPANs need to consider 474 the following two primary attributes: 476 o Power conservation: some devices are mains-powered, but most are 477 battery-operated and need to last several months to a few years 478 with a single AA battery. Many devices are mains-powered most of 479 the time, but still need to function for possibly extended periods 480 from batteries (e.g. on a construction site before building power 481 is switched on for the first time). 483 o Low performance: tiny devices, small memory sizes, low-performance 484 processors, low bandwidth, high loss rates, etc. 486 These fundamental attributes of LoWPANs affect the design of routing 487 solutions, so that existing routing specifications should be 488 simplified and modified to the smallest extent possible when there 489 are appropriate solutions to adapt, otherwise, new solutions should 490 be introduced in order to fit the low-power requirements of LoWPANs, 491 meeting the requirements described in the following. 493 4.1. Support of 6LoWPAN Device Properties 495 The general objectives listed in this section should be followed by 496 6LoWPAN routing protocols. The importance of each requirement is 497 dependent on what device type the protocol is running on and what the 498 role of the device is. The following requirements are based on 499 battery-powered LoWPAN devices. 501 [R01] 6LoWPAN routing protocols SHOULD allow to be implemented with 502 small code size and require low routing state to fit the typical 503 6LoWPAN node capacity (e.g., code size considering its typical flash 504 memory size, and routing table less than 32 entries). 506 A LoWPAN routing protocol solution should consider the limited 507 memory size typically starting at 4KB. RAM size of 6LoWPAN nodes 508 often ranges between 2KB and 10KB, and program flash memory 509 normally consists of 48KB to 128KB. (e.g., in the current market, 510 MICAz has 128KB program flash, 4KB EEPROM, 512KB external flash 511 ROM; TIP700CM has 48KB program flash, 10KB RAM, 1MB external flash 512 ROM). 514 Due to these hardware restrictions, code length should be 515 considered to fit within a small memory size; no more than 48KB to 516 128KB of flash memory including at least a few tens of KB of 517 application code size. A routing protocol of low complexity helps 518 to achieve the goal of reducing power consumption, improves 519 robustness, requires lower routing state, is easier to analyze, 520 and may be implicitly less prone to security attacks. 522 In addition, operation with low routing state (such as routing 523 tables and neighbor lists) SHOULD be maintained since some typical 524 memory sizes preclude to store state of a large number of nodes. 525 For instance, industrial monitoring applications need to support 526 at maximum 20 hops [15]. Small networks can be designed to 527 support a smaller number of hops. It is highly dependent on the 528 network architecture, but considering the 6LoWPAN device 529 properties, there should be at least one mode of operation that 530 can function with 32 forwarding entries or less. 532 [R02] 6LoWPAN routing protocols SHOULD cause minimal power 533 consumption by the efficient use of control packets (e.g., minimize 534 expensive multicast which cause broadcast to the entire LoWPAN) and 535 by the efficient routing of data packets. 537 One way of battery lifetime optimization is by achieving a minimal 538 control message overhead. Compared to functions such as in many 539 devices, computational operations or taking sensor samples, radio 540 communications is by far the dominant factor of power consumption 541 [9]. Power consumption of transmission and/or reception depends 542 linearly on the length of data units and on the frequency of 543 transmission and reception of the data units [12]. 545 The energy consumption of two example RF controllers for low-power 546 nodes is shown in [10]. The TR1000 radio consumes 21mW when 547 transmitting at 0.75mW, and 15mW on reception (with a receiver 548 sensitivity of -85dBm). The CC1000 consumes 31.6mW when 549 transmitting 0.75mW, and 20mW for receiving (with a receiver 550 sensitivity of -105dBm). The power continuation under the concept 551 of an idealized power source is explained in [10]. Based on the 552 energy of an idealized AA battery, the CC1000 can transmit for 553 approximately 4 days straight or receive for 9 consecutive days. 554 Note that availability for reception consumes power as well. 556 One multicast packet causes reception of the entire nodes in the 557 LoWPAN, while only the nodes in the path use the reception energy 558 at unicast. Thus, 6LoWPAN routing protocol SHOULD minimize the 559 control cost by the routing packets. Another document discusses 560 control cost of routing protocols in low power and lossy networks 561 [18]. 563 4.2. Support of 6LoWPAN Link Properties 565 6LoWPAN links have the characteristics of low bandwidth and possibliy 566 high loss rates. The routing requirements described in this section 567 are derived from the link properties. 569 [R03] 6LoWPAN routing protocol control messages SHOULD not create 570 fragmentation of physical layer (PHY) frames. 572 In order to save energy, routing overhead should be minimized to 573 prevent fragmentation of frames on the physical layer (PHY). 574 Therefore, 6LoWPAN routing should not cause packets to exceed the 575 IEEE 802.15.4 frame size. This reduces the energy required for 576 transmission, avoids unnecessary waste of bandwidth, and prevents 577 the need for packet reassembly. As calculated in RFC4944 [4], the 578 maximum size of a 6LoWPAN frame, in order not to cause 579 fragmentation on the PHY layer, is 81 octets. This may imply the 580 use of semantic fragmentation and/or algorithms that can work on 581 small increments of routing information. 583 [R04] The design of routing protocols for 6LoWPANs must consider the 584 fact that packets are to be delivered with sufficient probability 585 according to application requirements. 587 Requirements on successful end-to-end packet delivery ratio (where 588 delivery may be bounded within certain latency) vary depending on 589 applications. In industrial applications, some non-critical 590 monitoring applications may tolerate successful delivery ratio of 591 less than 90% with hours of latency; in some other cases, a 592 delivery ratio of 99.9% is required [15]. In building automation 593 applications, application layer errors must be below 0.01% [17]. 595 Successful end-to-end delivery of packets in a IEEE 802.15.4 mesh 596 depends on the quality of the path selected by the routing 597 protocol and on the ability of the routing protocol to cope with 598 short-term and long-term quality variation. The metric of the 599 routing protocol strongly influences performance of the routing 600 protocol in terms of delivery ratio. 602 The quality of a given path depends on the individual qualities of 603 the links (including the devices) that compose that path. IEEE 604 802.15.4 settings affect the quality perceived at upper layers. 605 In particular, in IEEE 802.15.4 reliable mode, if an 606 acknowledgment frame is not received after a given period, the 607 originator retries frame transmission up to a maximum number of 608 times. If an acknowledgment frame is still not received by the 609 sender after performing the maximum number of transmission 610 attempts, the MAC sub-layer assumes the transmission has failed 611 and notifies the next higher layer of the failure. Note that 612 excessive retransmission may be detrimental, see RFC 3819 [5]. 614 [R05] The design of routing protocols for 6LoWPANs must consider the 615 end-to-end latency requirements of applications and IEEE 802.15.4 616 link latency characteristics. 618 Latency requirements may differ from a few hundreds milliseconds 619 to minutes, depending on the type of application. Real-time 620 building automation applications usually need response times below 621 500 ms between egress and ingress, while forced entry security 622 alerts must be routed to one or more fixed or mobile user devices 623 within 5 seconds [17]. Non-critical closed loop applications for 624 industrial automation have latency requirements that can be as low 625 as 100 ms but many control loops are tolerant of latencies above 626 1s [15]. In contrast to this, urban monitoring applications allow 627 latencies smaller than the typical intervals used for reporting 628 sensed information; for instance, in the order of seconds to 629 minutes [16]. 631 The range of latencies of a frame transmission between a single 632 sender and a single receiver through an ideal unslotted IEEE 633 802.15.4 2.4 GHz channel is between 2.46ms and 6.02ms in 64 bit 634 MAC address unreliable mode and 2.20 ms to 6.56ms in 64 bit 635 address reliable mode. The range of latencies of 868 MHz band is 636 from 11.7 ms to 63.7 ms, depending on the address type and 637 reliable/unreliable mode used. Note that the latencies may be 638 larger than that depending on channel load, MAC sublayer settings 639 that regulate medium access procedure, reliable/unreliable mode 640 choice and nodes sleeping. 642 Some routing protocols are aware of the hop count of a path. This 643 parameter may be used as an input to select paths on an end-to-end 644 latency basis if necessary. 646 Note that a tradeoff exists between [R05] and [R04]. 648 [R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss 649 caused by link failure or device unavailability either in short-term 650 (e.g. due to RSSI variation, interference variation, noise and 651 asynchrony) or in long-term (e.g. due to a depleted power source, 652 hardware breakdown, operating system misbehavior, etc). 654 An important trait of 6LoWPAN devices is their unreliability due 655 to limited system capabilities, and also because they might be 656 closely coupled to the physical world with all its unpredictable 657 variation. In harsh environments, LoWPANs easily suffer from link 658 failure. Collision or link failure easily increases Send Queue/ 659 Receive Queue (SQ/RQ) and it can lead to queue overflow and packet 660 losses. 662 For home applications, where users expect feedback after carrying 663 out actions (such as handling a remote control while moving 664 around), routing protocols must converge within 2 seconds if the 665 destination node of the packet has moved and must converge within 666 0.5 seconds if only the sender has moved [14]. The tolerance of 667 the recovery time can vary depending on the application, however, 668 the routing protocol must provide the detection of short-term 669 unavailability and long-term disappearance. The routing protocol 670 has to exploit network resources (e.g. path redundancy) to offer 671 good network behavior despite of node failure. 673 [R07] 6LoWPAN routing protocols SHOULD be designed to correctly 674 operate in the presence of link asymmetry. 676 Link asymmetry occurs when the probability of successful 677 transmission between two nodes is significantly higher in one 678 direction than in the other one. This phenomenon has been 679 reported in a large number of experimental studies and it is 680 expected that 6LoWPANs will exhibit link asymmetry. 682 4.3. Support of 6LoWPAN Network Characteristics 684 6LoWPANs can be deployed in different sizes and topologies, adhere to 685 various models of mobility, tolerate various levels of interference, 686 etc. In any case, 6LoWPANs must maintain low energy consumption. 687 The requirements described in the following subsection are derived 688 from the network attributes of 6LoWPANs. 690 [R08] 6LoWPAN routing protocols SHOULD be reliable despite 691 unresponsive nodes due to periodic hibernation. 693 Many nodes in 6LoWPAN environments might periodically hibernate 694 (i.e. disable their transceiver activity) in order to save energy. 695 Therefore, routing protocols must ensure robust packet delivery 696 despite nodes frequently shutting off their radio transmission 697 interface. Feedback from the lower IEEE 802.15.4 layer may be 698 considered to enhance the power-awareness of 6LoWPAN routing 699 protocols. 701 CC1000-based nodes must operate at a duty cycle of approximately 702 2% to survive for one year from idealized AA battery power source 703 [10]. For home automation purposes, it is suggested that that the 704 devices have to maximize the sleep phase with a duty cycle lower 705 than 1% [14], while in building automation applications, batteries 706 must be operational for at least 5 years when the sensing devices 707 are transmitting data (e.g. 64 bytes) once per minute [17]. 709 Dependent on the application in use, packet rates differ from 710 1/sec to 1/day. Routing protocols need to know the cycle of the 711 packet transmission and utilize the information to calculate 712 routing paths. 714 [R09] The metric used by 6LoWPAN routing protocols MAY utilize a 715 combination of the inputs provided by the MAC layer and other 716 measures to obtain the optimal path considering energy balance and 717 link quality. 719 In homes, buildings, or infrastructure, some nodes will be 720 installed with mains power. Such power-installed nodes MUST be 721 considered as a relay points for more roles in packet delivery. 722 6LoWPAN routing protocols MUST know the power constraints of the 723 nodes. 725 Simple hop-count-only mechanisms may be inefficient in 6LoWPANs. 726 There is a Link Quality Indicator (LQI), Link Delivery Ratio 727 (LDR), or/and RSSI from IEEE 802.15.4 that may be taken into 728 account for better metrics. The metric to be used (and its goal) 729 may depend on application and requirements. 731 The numbers in Figure 3 represent the Link Delivery Ratio (LDR) of 732 each pair of nodes. There are studies that show a piecewise 733 linear dependence between LQI and LDR [13]. 735 0.6 736 A-------C 737 \ / 738 0.9 \ / 0.9 739 \ / 740 B 742 Figure 3: An example network 744 In this simple example, there are two options in routing from node 745 A to node C, with the following features: 747 A. Path AC: 749 + (1/0.6) = 1.67 avg. transmissions needed for each packet 751 + one-hop path 753 + good in energy consumption and end-to-end latency of data 754 packets, bad in delivery ratio (0.6) 756 + bad in probability of route reconfigurations 758 B. Path ABC 760 + 2*(1/0.81) = 2.47 avg. transmissions needed for each packet 762 + two-hop path 764 + bad in energy consumption and end-to-end latency of data 765 packets, good in delivery ratio (0.81) 767 If energy consumption of the network must be minimized, path AC is 768 the best (this path would be chosen based on a hop count metric). 769 However, if the delivery ratio in that case is not sufficient, the 770 best path is ABC (it would be chosen by an LQI based metric). 771 Combinations of both metrics can be used. 773 The metric also affects the probability of route reconfiguration. 774 Route reconfiguration, which may be triggered by packet losses, 775 may require transmission of routing protocol messages. It is 776 possible to use a metric aimed at selecting the path with low 777 route reconfiguration rate by using LQI as an input to the metric. 778 Such a path has good properties, including stability and low 779 control message overhead. 781 [R10] 6LoWPAN routing protocols SHOULD be designed to achieve both 782 scalability from a few nodes to millions of nodes and minimality in 783 terms of used system resources. 785 A 6LoWPAN may consist of just a couple of nodes (for instance in a 786 body-area network), but may expand to much higher numbers of 787 devices (e.g. monitoring of a city infrastructure or a highway). 788 For home automation applications it is envisioned that the routing 789 protocol must support 250 devices in the network [14], while 790 routing protocols for metropolitan-scale sensor networks must be 791 capable of clustering a large number of sensing nodes into regions 792 containing on the order of 10^2 to 10^4 sensing nodes each [16]. 793 It is therefore necessary that routing mechanisms are designed to 794 be scalable for operation in various network sizes. However, due 795 to a lack of memory size and computational power, 6LoWPAN routing 796 might limit forwarding entries to a small number, such as at 797 maximum 32 routing table entries. 799 [R11] The procedure of route repair and related control messages 800 should not harm overall energy consumption from the routing 801 protocols. 803 Local repair improves throughput and end-to-end latency, 804 especially in large networks. Since routes are repaired quickly, 805 fewer data packets are dropped, and a smaller number of routing 806 protocol packet transmissions are needed since routes can be 807 repaired without source initiated Route Discovery [11]. One 808 important consideration here may be to avoid premature depletion, 809 even in case that impairs other requirements. 811 [R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive 812 topologies and mobile nodes. When supporting dynamic topologies and 813 mobile nodes, route maintenance should should keep in mind the goal 814 of a minimal routing state and routing protocol message overhead. 816 Building monitoring applications, for instance, require that the 817 mobile devices SHOULD be capable of leaving (handing-off) from an 818 old network joining onto a new network within 15 seconds [17]. 819 More interactive applications such as used in home automation 820 systems, where users are giving input and expect instant feedback, 821 mobility requirements are also stricter and a convergence time 822 below 0.5 seconds is commonly required [14]. In industrial 823 environments, where mobile equipment such as cranes move around, 824 the support of vehicular speeds of up to 35 km/ph are required to 825 be supported by the routing protocol [15]. Currently, 6LoWPANs 826 are not being used for such a fast mobility, but dynamic 827 association and disassociation MUST be supported in 6LoWPAN. 829 There are several challenges that should be addressed by a 6LoWPAN 830 routing protocol in order to create robust routing in dynamic 831 environments: 833 * Mobile nodes changing their location inside a 6LoWPAN: 834 If the nodes' movement pattern is unknown, mobility cannot 835 easily be detected or distinguished by the routing protocols. 836 Mobile nodes can be treated as nodes that disappear and re- 837 appear in another place. Movement pattern tracking increases 838 complexity and can be avoided by handling moving nodes using 839 reactive route updates. 841 * Movement of a 6LoWPAN with respect to other (inter)connected 842 6LoWPANs: 843 Within stub networks, more powerful gateway nodes need to be 844 configured to handle moving 6LoWPANs. 846 * Nodes permanently joining or leaving the 6LoWPAN: 847 In order to ease routing table updates and reduce error control 848 messages, it would be helpful if nodes leaving the network 849 inform their coordinator about their intention to disassociate. 851 [R13] 6LoWPAN routing protocol SHOULD support various traffic 852 patterns; point-to-point, point-to-multipoint, and multipoint-to- 853 point, while avoid excessive multicast traffic (broadcast in link 854 layer) in 6LoWPAN. 856 6LoWPANs often have point-to-multipoint or multipoint-to-point 857 traffic patterns. Many emerging applications include point-to- 858 point communication as well. 6LoWPAN routing protocols should be 859 designed with the consideration of forwarding packets from/to 860 multiple sources/destinations. Current WG drafts in the ROLL 861 working group explain that the workload or traffic pattern of use 862 cases for 6LoWPANs tend to be highly structured, unlike the any- 863 to-any data transfers that dominate typical client and server 864 workloads. In many cases, exploiting such structure may simplify 865 difficult problems arising from resource constraints or variation 866 in connectivity. 868 4.4. Support of Security 870 The routing requirement described in this subsection allows secure 871 transmission of routing messages. Solutions may take into account 872 the specific features of IEEE 802.15.4 MAC layers. 874 [R14] 6LoWPAN protocols SHOULD support secure delivery of control 875 messages. A minimal security level can be achieved by utilizing AES- 876 based mechanism provided by IEEE 802.15.4. 878 Security threats within LoWPANs may be different from existing 879 threat models in ad-hoc network environments. Neighbor Discovery 880 in IEEE 802.15.4 links may be susceptible to threats as listed in 881 RFC3756 [2]. Bootstrapping may also impose additional threats. 882 Security is also very important for designing robust routing 883 protocols, but it should not cause significant transmission 884 overhead. While there are applications which require very high 885 security, such as in traffic control, other applications are less 886 easily harmed by wrong node behavior, such as a home entertainment 887 system. 889 The IEEE 802.15.4 MAC provides an AES-based security mechanism. 890 Routing protocols need to define how this mechanism can be used to 891 obtain the intended security. Byte overhead of the mechanism, 892 which depends on the security services selected, must be 893 considered. In the worst case in terms of overhead, the mechanism 894 consumes 21 bytes of MAC payload. 896 4.5. Support of Mesh-under Forwarding 898 Reception of an acknowledgement after a frame transmission may render 899 unnecessary the transmission of explicit Hello messages, for example. 901 [R15] In case a routing protocol operates in 6LoWPAN's adaptation 902 layer, then routing tables and neighbor lists MUST support 16-bit 903 short and 64-bit extended addresses. 905 [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending 906 "Hello" messages. Instead, link-layer mechanisms (such as 907 acknowledgments) MAY be utilized to keep track of active neighbors. 909 Reception of an acknowledgement after a frame transmission may 910 render unnecessary the transmission of explicit Hello messages, 911 for example. 913 [R17] In case there are one or more nodes allocated to coordinator 914 roles, the coordinators MAY take the role of keeping track of node 915 association and de-association within the LoWPAN. 917 [R18] If the routing protocol functionality includes enabling IP 918 multicast, then it may want to employ coordinator roles, if any, as 919 relay points of group-targeting messages instead of using link-layer 920 multicast (broadcast). 922 5. Security Considerations 924 Security issues are described in Section 4.4. Security 925 considerations of RFC 4919 [3] and RFC 4944 [4] apply as well. More 926 security considerations will result from the 6LoWPAN security 927 analysis work. 929 6. Acknowledgements 931 The authors thank Myung-Ki Shin for giving the idea of writing this 932 draft. The authors also thank to S. Chakrabarti who gave valuable 933 comments for mesh-under requirements. 935 7. References 937 7.1. Normative References 939 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 940 Levels", BCP 14, RFC 2119, March 1997. 942 [2] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 943 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 945 [3] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over 946 Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 947 Assumptions, Problem Statement, and Goals", RFC 4919, 948 August 2007. 950 [4] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 951 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 952 RFC 4944, September 2007. 954 [5] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., 955 Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice 956 for Internet Subnetwork Designers", BCP 89, RFC 3819, 957 July 2004. 959 [6] IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as amended)", 960 2007. 962 7.2. Informative References 964 [7] Bulusu, N. and S. Jha, "Wireless Sensor Networks", July 2005. 966 [8] Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. 967 Nordmark, "LoWPAN Neighbor Discovery Extensions, 968 draft-shelby-6lowpan-nd-00 (work in progress)", October 2008. 970 [9] Pister, K. and B. Boser, "Smart Dust: Wireless Networks of 971 Millimeter-Scale Sensor Nodes". 973 [10] Hill, J., "System Architecture for Wireless Sensor Networks". 975 [11] Lee, S., Belding-Royer, E., and C. Perkins, "Scalability Study 976 of the Ad Hoc On-Demand Distance-Vector Routing Protocol", 977 March 2003. 979 [12] Shih, E., "Physical Layer Driven Protocols and Algorithm Design 980 for Energy-Efficient Wireless Sensor Networks", July 2001. 982 [13] Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc Multicast 983 Routing on Resource-Limited Sensor Nodes", 2006. 985 [14] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing 986 Requirement in Low Power and Lossy Networks, 987 draft-ietf-roll-home-routing-reqs-04 (work in progress)", 988 October 2008. 990 [15] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial 991 Routing Requirements in Low Power and Lossy Networks, 992 draft-ietf-roll-indus-routing-reqs-01 (work in progress)", 993 July 2008. 995 [16] Dohler, M., Watteyne, T., Winter, T., Barthel, D., and C. 996 Jacquenet, "Urban WSNs Routing Requirements in Low Power and 997 Lossy Networks, draft-ietf-roll-urban-routing-reqs-02 (work in 998 progress)", October 2008. 1000 [17] Martocci, J., De Mil, P., Vermeylen, W., and N. Riou, "Building 1001 Automation Routing Requirements in Low Power and Lossy 1002 Networks, draft-ietf-roll-building-routing-reqs-01 (work in 1003 progress)". 1005 [18] Levis, P., Tavakoli, A., and S. Dawson-Haggerty, "Overview of 1006 Existing Routing Protocols for Low Power and Lossy Networks , 1007 draft-ietf-roll-protocols-survey-02 (work in progress)". 1009 [19] Latre, M., De Mil, P., Moerman, I., Dhoedt, B., and P. 1010 Demeester, "Throughput and Delay Analysis of Unslotted IEEE 1011 802.15.4", May 2006. 1013 Authors' Addresses 1015 Eunsook Eunah Kim 1016 ETRI 1017 161 Gajeong-dong 1018 Yuseong-gu 1019 Daejeon 305-700 1020 Korea 1022 Phone: +82-42-860-6124 1023 Email: eunah.ietf@gmail.com 1025 Dominik Kaspar 1026 Simula Research Laboratory 1027 Martin Linges v 17 1028 Snaroya 1367 1029 Norway 1031 Phone: +47-6782-8223 1032 Email: dokaspar.ietf@gmail.com 1034 Carles Gomez 1035 Tech. Univ. of Catalonia/i2CAT 1036 Escola Politecnica Superior de Castelldefels 1037 Avda. del Canal Olimpic, 15 1038 Castelldefels 08860 1039 Spain 1041 Phone: +34-93-413-7206 1042 Email: carlesgo@entel.upc.edu 1044 Carsten Bormann 1045 Universitaet Bremen TZI 1046 Postfach 330440 1047 Bremen D-28359 1048 Germany 1050 Phone: +49-421-218-63921 1051 Fax: +49-421-218-7000 1052 Email: cabo@tzi.org 1054 Full Copyright Statement 1056 Copyright (C) The IETF Trust (2008). 1058 This document is subject to the rights, licenses and restrictions 1059 contained in BCP 78, and except as set forth therein, the authors 1060 retain all their rights. 1062 This document and the information contained herein are provided on an 1063 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1064 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1065 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1066 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1067 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1070 Intellectual Property 1072 The IETF takes no position regarding the validity or scope of any 1073 Intellectual Property Rights or other rights that might be claimed to 1074 pertain to the implementation or use of the technology described in 1075 this document or the extent to which any license under such rights 1076 might or might not be available; nor does it represent that it has 1077 made any independent effort to identify any such rights. Information 1078 on the procedures with respect to rights in RFC documents can be 1079 found in BCP 78 and BCP 79. 1081 Copies of IPR disclosures made to the IETF Secretariat and any 1082 assurances of licenses to be made available, or the result of an 1083 attempt made to obtain a general license or permission for the use of 1084 such proprietary rights by implementers or users of this 1085 specification can be obtained from the IETF on-line IPR repository at 1086 http://www.ietf.org/ipr. 1088 The IETF invites any interested party to bring to its attention any 1089 copyrights, patents or patent applications, or other proprietary 1090 rights that may cover technology that may be required to implement 1091 this standard. Please address the information to the IETF at 1092 ietf-ipr@ietf.org.