idnits 2.17.1 draft-dohler-rl2n-urban-routing-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (December 5, 2007) is 5987 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.culler-rl2n-routing-reqs' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-culler-rl2n-routing-reqs-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group M. Dohler 2 Internet-Draft G. Madhusudan 3 Intended status: Informational G. Chegaray 4 Expires: June 4, 2008 T. Watteyne 5 C. Jacquenet 6 France Telecom R&D 8 December 5, 2007 10 Urban WSNs Routing Requirements in Low Power and Lossy Networks 11 draft-dohler-rl2n-urban-routing-reqs-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 4, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The application specific routing requirements for Urban Low Power and 45 Lossy Networks (U-L2Ns) are presented in this document. In the near 46 future, sensing and actuating nodes will be placed outdoors in urban 47 environments so as to improve the citizens' living conditions as well 48 as to monitor compliance with increasingly strict environmental laws. 49 These field nodes are expected to measure and report a wide gamut of 50 data, such as required in smart metering, waste disposal, 51 meteorological, pollution and allergy reporting applications. The 52 majority of these nodes is expected to communicate wirelessly which 53 - given the limited radio range - requires the use of suitable 54 multi-hop routing protocols. The design of such protocols will be 55 mainly impacted by the limited resources of the nodes (memory, 56 processing power, battery, etc) and the particularities of the 57 outdoors urban application scenario. As such, for a wireless RL2N 58 solution to be competitive with other incumbent and emerging 59 solutions, the protocol ought to be energy-efficient, scalable and 60 autonomous. This documents aims to specify a set of requirements 61 reflecting these and further U-L2Ns tailored characteristics. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Urban L2N application scenarios. . . . . . . . . . . . . . . . 7 74 3.1. Deployment of nodes. . . . . . . . . . . . . . . . . . . . 7 75 3.2. Association and disassociation/disappearance of nodes. . . 7 76 3.3. Regular measurement reporting. . . . . . . . . . . . . . . 8 77 3.4. Queried measurement reporting. . . . . . . . . . . . . . . 9 78 3.5. Alert reporting. . . . . . . . . . . . . . . . . . . . . . 9 79 4. Unique requirements of urban L2N applications. . . . . . . . . 10 80 4.1. Scalability.. . . . . . . . . . . . . . . . . . . . . . . 10 81 4.2. Parameter constrained routing . . . . . . . . . . . . . . 10 82 4.3. Support of autonomous and alien configuration . . . . . . 10 83 4.4. Support of highly directed information flows. . . . . . . 11 84 4.5. Support of heterogeneous field devices. . . . . . . . . . 11 85 4.6. Support of multi and groupcast. . . . . . . . . . . . . . 11 86 4.7. Network dynamicity. . . . . . . . . . . . . . . . . . . . 12 87 4.8. Latency. . . . . . . . . . . . . . . . . . . . . . . . . .12 88 5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . .12 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . .12 90 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .13 92 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .13 93 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 10.1 Normative References. . . . . . . . . . . . . . . . . . . 13 95 10.2 Informative References. . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Terminology 100 Access Point: The access point is an infrastructure device that 101 connects the low power and lossy network system to a backbone 102 network. 104 Actuator: a field device that moves or controls equipment. 106 Field Device: physical device placed in the urban operating 107 environment. Field devices include sensors, actuators and repeaters. 109 L2N: Low Power and Lossy Network 111 Schedule: An agreed execution, wake-up, transmission, reception, etc, 112 time-table between two or more field devices. 114 Timeslot: A fixed time interval that may be used for the transmission 115 or reception of a packet between two field devices. A timeslot used 116 for communications is associated with a slotted-link. 118 RL2N: Routing in Low power and Lossy Networks 120 2. Introduction 122 We detail here some application specific routing requirements for 123 Urban Low Power and Lossy Networks (U-L2Ns). A U-L2N is understood to 124 be a network composed of four key elements, i.e. 125 1) sensors, 126 2) actuators, 127 3) repeaters, and 128 4) access points, 129 which communicate wirelessly. 131 The access point can be used as: 132 1) gateway to a wider infrastructure (e.g. Internet), 133 2) data sink (e.g. data collection & processing from sensors), and 134 3) data source (e.g. instructions towards actuators). 135 There can be several access points connected to the same U-L2N; however, 136 the number of access points is well below the amount of sensing nodes. 137 The access points are mainly static, i.e. fixed to a random or pre- 138 planned location, but can be nomadic, i.e. in form of a walking 139 supervisor. Access points may but generally do not suffer from any form 140 of (long-term) resource constraint, except that they need to be small 141 and sufficiently cheap. 143 Repeaters generally act as relays with the aim to close coverage and 144 routing gaps; examples of their use are: 145 1) prolong the U-L2N's lifetime, 146 2) balance nodes' energy depletion, 147 3) build advanced sensing infrastructures. 148 There can be several repeaters supporting the same U-L2N; however, the 149 number of repeaters is well below the amount of sensing nodes. The 150 repeaters are mainly static, i.e. fixed to a random or pre-planned 151 location. Repeaters may but generally do not suffer from any form of 152 (long-term) resource constraint, except that they need to be small and 153 sufficiently cheap. 155 Actuator nodes control urban devices upon being instructed by signaling 156 arriving from access point(s); examples are street or traffic lights. 157 The amount of actuator points is well below the number of sensing nodes. 158 Actuators are capable to relay, i.e. route data. Actuators may generally 159 be mobile but are likely to be static in the majority of near-future 160 roll-outs. Similar to the access points, actuator nodes do not suffer 161 from any long-term resource constraints. 163 Sensing nodes measure a wide gamut of physical data, including but not 164 limited to: 165 1) municipal consumption data, such as the smart-metering of gas, 166 water, electricity, waste, etc; 167 2) meteorological data, such as temperature, pressure, humidity, sun 168 index, strength and direction of wind, etc; 169 3) pollution data, such as polluting gases (SO2, NOx, CO, Ozone), 170 heavy metals (e.g. Mercury), pH, radioactivity, etc; 171 4) ambient data, such as allergic elements (pollen, dust), EM 172 pollution, noise levels, etc. 173 Whilst million of sensing nodes may very well be deployed in an urban 174 area, they are likely to be associated to more than one network where 175 these networks may or may not communicate between each other. The number 176 of sensing nodes connected to a single network is expected to be in the 177 order of 10^2-10^4; this is still very large and unprecedented in 178 current roll-outs. Deployment of nodes is likely to happen in batches, 179 i.e. a box of hundreds of nodes arrives and is deployed. The location of 180 the nodes is random within given topological constraints, e.g. placement 181 along a road or river. The nodes are highly resource constraint, i.e. 182 cheap hardware, low memory and no infinite energy source. Different node 183 powering mechanisms are available, such as: 184 1) non-rechargeable battery; 185 2) rechargeable battery with regular recharging (e.g. sunlight); 186 3) rechargeable battery with irregular recharging (e.g. opportunistic 187 energy scavenging); 188 4) capacitive/inductive energy provision (e.g. active RFID). 189 The battery life-time is usually in the order of 10-15 years, rendering 190 network lifetime maximization with battery-powered nodes beyond this 191 lifespan useless. 193 The physical and electromagnetic distances between the four keyelements, 194 i.e. sensors, actuators, repeaters and access points, can generally be 195 very large, i.e. from several hundreds of meters to one kilometer. Not 196 every field node is likely to reach the access point in a single hop, 197 thereby requiring suitable multi-hop routing protocols which manage the 198 information flow in an energy-efficient manner. Sensor nodes are capable 199 to relay, i.e. route data. 201 Unlike traditional ad hoc networks, the information flow in U-L2Ns is 202 highly directed. There are three main flows to be distinguished: 203 1) sensed information from the sensing nodes towards the access 204 point(s); 205 2) query requests from the access point(s) to the sensing nodes; 206 and 207 3) control information from the access point(s) to the actuators. 208 Some of the flows may need the reverse route for delivering 209 acknowledgements. 211 Sensed data is likely to be highly correlated in space, time and 212 observed events; an example of the latter is when temperature and 213 humidity increase as the day commences. Data may be sensed and delivered 214 at different rates with both rates being typically fairly low, i.e. in 215 the range of hours, days, etc. Data may be delivered regularly according 216 to a schedule or a regular query; it may also be delivered irregularly 217 after an externally triggered query; it may also be triggered after a 218 sudden network-internal event or alert. The network hence needs to be 219 able to adjust to the varying activity duty cycles, as well as to period 220 and aperiodic traffic. Also, sensed data ought to be secured and 221 locatable. 223 Finally, the outdoors deployment of U-L2Ns has also implications for the 224 interference temperature and hence link reliability and range if ISM 225 bands are to be used. For instance, if the 2.4GHz ISM band is used to 226 facilitate communication between U-L2N nodes, then heavily loaded WLAN 227 hot-spots become a detrimental performance factor jeopardizing the 228 reliability of the U-L2N. 230 Section 3 describes a few typical use cases for the urban L2N 231 applications. Section 4 discusses the routing requirements for networks 232 comprising such constrained devices in a U-L2N environment. These 233 requirements may be overlapping requirements derived from other 234 application-specific requirements documents or as listed in [I-D.culler- 235 rl2n-routing-reqs]. 237 3. Urban L2N application scenarios 239 Urban applications represent a special segment of L2Ns with its unique 240 set of requirements. To facilitate the requirements discussion in 241 Section 4, this section lists a few typical but not exhaustive 242 deployment problems and usage cases of U-L2N. 244 3.1. Deployment of nodes 246 Contrary to other L2N applications, deployment of nodes is likely to 247 happen in batches out of a box. Typically, hundreds of nodes are being 248 shipped by the manufacturer with pre-programmed functionalities which 249 are then rolled-out by a service provider or subcontracted entities. 250 Prior or after roll-out, the network needs to be ramped-up. This 251 initialization phase may include, among others, allocation of addresses, 252 (hierarchical) roles in the network, synchronization, determination of 253 schedules, etc. 255 If initialization is performed prior to roll-out, all nodes are likely 256 to be in each others 1-hop radio neighborhood. Pre-programmed MAC and 257 routing protocols may hence fail to function properly, thereby wasting a 258 large amount of energy. Whilst the major burden will be on resolving MAC 259 conflicts, any proposed U-L2N routing protocol needs to cater for such a 260 case. 262 If initialization is performed after roll-out, nodes will have a finite 263 set of one-hop neighbors, likely of low cardinality. Any proposed L2N 264 routing protocol ought to support the autonomous organization and 265 configuration of the network at lowest possible energy cost [Lu2007]. 266 The result of such organization ought to be that each node or sets of 267 nodes are uniquely addressable so as to facilitate the set up of 268 schedules, etc. The L2N protocol hence ought to support unicast and 269 multicast transmission schemes, among others. Solutions should refrain 270 from broadcasting. 272 3.2. Association and disassociation/disappearance of nodes 274 After the initialization phase and possibly some operational time, new 275 nodes may be injected into the network as well as existing nodes removed 276 from the network. The former may be because a removed node is replaced, 277 denser readings/actuations are needed or the protocol reports 278 connectivity problems. The latter might be because a node's battery is 279 depleted, the node is removed for maintenance, the node is stolen or 280 accidentally destroyed, etc. Differentiation should be made between node 281 disassociation, where the node has enough time to inform the network 282 about its removal, and disappearance, where the node simply disappears 283 without prior notification. 285 The protocol hence ought to support the pinpointing of problematic 286 routing areas as well as an organization of the network which 287 facilitates reconfiguration in the case of association and 288 disassociation/disappearance of nodes at lowest possible energy and 289 delay. The latter may include the change of hierarchies, routing paths, 290 schedules, etc. Furthermore, to inform the access point(s) of the node's 291 arrival and association with the network, unicast and multicast should 292 be supported. To inform freshly associated nodes about schedules, roles, 293 etc, unicast ought to be supported. 295 3.3. Regular measurement reporting 297 The majority of sensing nodes will be configured to report their 298 readings on a regular basis. The frequency of data sensing and reporting 299 may be different but is generally expected to be fairly low, i.e. in the 300 range of once per hour, per day, etc. The ratio between data sensing and 301 reporting frequencies will determine the memory and data aggregation 302 capabilities of the nodes. Latency of an end-to-end delivery and 303 acknowledgements of a successful data delivery are not vital as sensing 304 outages can be observed at the access point(s) - when, for instance, 305 there is no reading arriving from a given sensor or cluster of sensors 306 within a day. In this case, a query can be launched to check upon the 307 state and availability of a sensing node or sensing cluster. 309 The protocol hence ought to support a large number of highly directed 310 unicast flows from the sensing nodes or sensing clusters towards the 311 access point or highly directed multicast or anycast flows from the 312 nodes towards multiple access points. Routing paths may depend on the 313 transmitted information, the frequency of reporting, the amount of 314 energy remaining in the routing nodes, the recharging pattern of energy- 315 scavenged nodes, etc. For instance, temperature readings are reported 316 every hour via one set of routing paths, whereas air quality indicators 317 are reported every quarter of an hour via different paths. Or, certain 318 routing areas are avoided at night but heavily used during the day when 319 nodes are scavenging from sunlight. 321 3.4. Queried measurement reporting 323 Occasionally, network external data queries can be launched by one or 324 several access points. For instance, it is desirable to know the level 325 of pollution at a specific point or along a given road in the urban 326 environment. The queries' rates of occurrence are not regular but rather 327 random, where heavy-tail distributions seem appropriate to model their 328 behavior. Queries do not necessarily need to be reported back to the 329 same access point from where the query was launched. Round-trip times, 330 i.e. from the launch of a query from an access point towards the 331 delivery of the measured data to an access point, are of importance. 332 However, they are not very stringent where latencies should simply be 333 sufficiently smaller than typical reporting intervals; for instance, in 334 the order of seconds or minute. To facilitate the query process, U-L2N 335 network devices should support unicast and multicast routing 336 capabilities. 338 The same approach is also applicable for schedule update, provisioning 339 of patches and upgrades, etc. In this case, however, the provision of 340 acknowledgements and the support of broadcast (in addition to unicast 341 and multicast) are of importance. 343 3.5. Alert reporting 345 Rarely, the sensing nodes will measure an event which classifies as 346 alarm where such a classification is typically done locally within each 347 node by means of a pre-programmed or prior diffused threshold. Note that 348 on approaching the alert threshold level, nodes may wish to change their 349 sensing and reporting cycles. An alarm is likely being registered by a 350 plurality of sensing nodes where the delivery of a single alert message 351 with its location of origin suffices in most cases. One example of alert 352 reporting is if the level of toxic gases rises above a threshold, 353 thereupon the sensing nodes in the vicinity of this event report the 354 danger. Another example of alert reporting is when a glass container - 355 equipped with a sensor measuring its level of occupancy - reports that 356 the container is full and hence needs to be emptied. 358 Routes clearly need to be unicast (towards one access point) or 359 multicast (towards multiple access points). Delays and latencies are 360 important; however, again, deliveries within seconds should suffice in 361 most of the cases. 363 4. Unique requirements of urban L2N applications 365 Urban low power and lossy network applications have a number of specific 366 requirements related to the set of operating conditions, as exemplified 367 in the previous section. 369 4.1. Scalability 371 The large and diverse measurement space of U-L2N nodes - coupled with 372 the typically large urban areas - will yield extremely large network 373 sizes. Current urban roll-outs are composed of sometimes more than 374 hundred nodes; future roll-outs, however, may easily reach numbers in 375 the tenth of thousands. One of the utmost important L2N routing protocol 376 design criteria is hence scalability. 378 The routing protocol MUST be scalable to be able to accommodate a very 379 large and increasing number of nodes without deteriorating to-be- 380 specified performance parameters below to-be-specified thresholds. 382 4.2. Parameter constrained routing 384 Batteries in some nodes may deplete quicker than in others; the 385 existence of one node for the maintenance of a routing path may not be 386 as important as of another node; the battery scavenging methods may 387 recharge the battery at regular or irregular intervals; some nodes may 388 have a larger memory and are hence be able to store more neighborhood 389 information; some nodes may have a stronger CPU and are hence able to 390 perform more sophisticated data aggregation methods; etc. 392 To this end, the routing protocol MUST support parameter constrained 393 routing, where examples of such parameters have been given in the 394 previous paragraph. 396 4.3. Support of autonomous and alien configuration 398 With the large number of nodes, manually configuring and troubleshooting 399 each node is not possible. The network is expected to self-organize and 400 self-configure according to some prior defined rules and protocols, as 401 well as to support externally triggered configurations (for instance 402 through a commissioning tool which may facilitate the organization of 403 the network at a minimum energy cost). 405 To this end, the routing protocol MUST provide a set of features 406 including 0-configuration at network ramp-up, (network-internal) self- 407 organization and configuration due to topological changes, ability to 408 support (network-external) patches and configuration updates. For the 409 latter, the protocol SHOULD support multicast and broadcast addressing. 410 The protocol SHOULD also support the formation and identification of 411 groups of field devices in the network. 413 4.4. Support of highly directed information flows 415 The reporting of the data readings by a large amount of spatially 416 dispersed nodes towards a few access points will lead to highly directed 417 information flows. 419 To this end, the routing protocol SHOULD support and utilize this fact 420 to facilitate scalability and parameter constrained routing. 422 4.5. Support of heterogeneous field devices 424 The sheer amount of different field devices will unlikely be provided by 425 a single manufacturer. A heterogeneous roll-out with nodes using 426 different physical and medium access control layers is hence likely. 428 To this end, the routing protocols proposed in U-L2N SHOULD support a 429 variety of different devices without compromising the operability and 430 energy efficiency of the network. 432 4.6. Support of multi and groupcast 434 Some urban sensing systems require low-level addressing of a group of 435 nodes in the same subnet without any prior creation of multicast groups, 436 simply carrying a list of recipients in the subnet [draft-brandt-rl2n- 437 home-routing-reqs-01]. 439 To this end, the routing protocol MUST support multicast, where the 440 routing protocol MUST provide the ability to route a packet towards a 441 single field device (unicast) or a set of devices, which explicitly 442 (multicast) or implicitly (groupcast) belong to the same group/cast. 443 Note that if groups correspond to a geographical area, groupcast is 444 synonymous to geocast. 446 The support of unicast, groupcast and multicast also has an implication 447 on the addressing scheme but is beyond the scope of this document that 448 focuses on the routing requirements aspects. 450 Note: with IP multicast, signaling mechanisms are used by a receiver to 451 join a group and the sender does not necessarily know the receivers of 452 the group. What is required is the ability to address a group of 453 receivers known by the sender even if the receivers do not need to know 454 that they have been grouped by the sender (since requesting each 455 individual node to join a multicast group would be very energy- 456 consuming). 458 4.7. Network dynamicity 460 Although mobility is assumed to be low in urban L2Ns, network dynamicity 461 due to node association, disassociation and disappearance is not 462 negligible. This in turn impacts re-organization and re-configuration 463 convergence as well as route establishment times. 465 To this end, local network dynamics SHOULD NOT impact the entire network 466 to be re-organized or re-reconfigured; however, the network SHOULD be 467 locally optimized to cater for the encountered changes. Convergence and 468 route establishment times SHOULD be significantly lower than the inverse 469 of the smallest reporting cycle. 471 4.8. Latency 473 With the exception of alert reporting solutions and to a certain extent 474 queried reporting, U-L2N are delay tolerant as long as the information 475 arrives within a fraction of the inverse of the respective reporting 476 cycle. 478 To this end, the routing protocol is RECOMMENDED to support minimum 479 latency for alert reporting and time-critical data queries. For regular 480 data reporting, it SHOULD support latencies not exceeding a fraction of 481 the inverse of the respective reporting cycle. 483 5. Traffic Pattern 485 tbd 487 6. Security Considerations 489 As every network, also U-L2Ns are exposed to security threats which, if 490 not properly addressed, exclude them to be deployed in the envisaged 491 scenarios. The wireless and distributed nature of these networks 492 drastically increases the spectrum of potential security threats; this 493 is further amplified by the serious constraints in node battery power, 494 thereby preventing previously known security approaches to be deployed. 495 Above mentioned issues require special attention during the design 496 process, so as to facilitate a commercially attractive deployment. 498 A secure communication in a wireless network encompasses three main 499 elements, i.e. confidentiality (encryption of data), integrity 500 (correctness of data), and authentication (legitimacy of data). Since 501 the majority of measured date in U-L2Ns is publicly available, the main 502 emphasis is on integrity and authenticity of data reportings. 503 Authentication can e.g. be violated if external sources insert incorrect 504 data packets; integrity can e.g. be violated if nodes start to break 505 down and hence commence measuring and relaying data incorrectly. 506 Nonetheless, some sensor readings as well as the actuator control 507 signals need to be confidential. 509 Further example security issues which may arise are the abnormal 510 behavior of nodes which exhibit an egoistic conduct, such as not obeying 511 network rules, or forwarding no or false packets. Other important issues 512 may arise in the context of Denial of Service (DoS) attacks, malicious 513 address space allocations, advertisement of variable addresses, a wrong 514 neighborhood, external attacks aimed at injecting dummy traffic to drain 515 the network power, etc. 517 The choice of the security solutions will have an impact onto routing 518 protocols. To this end, routing protocols proposed in the context of U- 519 L2Ns MUST support integrity measures and SHOULD support confidentiality 520 (security) measures. 522 7. Open Issues 524 Other items to be addressed in further revisions of this document 525 include: 526 * node mobility; and 527 * traffic patterns. 529 8. IANA Considerations 531 This document includes no request to IANA. 533 9. Acknowledgements 535 10. References 537 10.1 Normative References 539 [RFC2119] 540 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", 541 BCP 14, RFC 2119, March 1997. 543 10.2 Informative References 545 [I-D.culler-rl2n-routing-reqs] 546 J.P. Vasseur and D. Culler, "Routing Requirements for Low-Power Wireless 547 Networks", draft-culler-rl2n-routing-reqs-00 (work in progress), July 548 2007. 550 [Lu2007] 551 J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully Integrated 552 Scheme of Self-Configuration and Self-Organization for WSN," IEEE WCNC 553 2007, Hong Kong, China, 11-15 March 2007, pp. 3370-3375. 555 [draft-brandt-rl2n-home-routing-reqs-01] 556 A. Brand and J.P. Vasseur, "Home Automation Routing Requirement in Low 557 Power and Lossy Networks," draft-brandt-rl2n-home-routing-reqs-01 (work 558 in progress), July 2007. 560 Authors' Addresses 562 Mischa Dohler 563 France Telecom R&D 564 28 Chemin du Vieux Chene 565 38243 Meylan Cedex 566 France 567 Email: mischa.dohler@orange-ftgroup.com 569 Giyyarpuram Madhusudan 570 France Telecom R&D 571 28 Chemin du Vieux Chene 572 38243 Meylan Cedex 573 France 574 Email: giyyarpuram.madhusudan@orange-ftgroup.com 576 Gabriel Chegaray 577 France Telecom R&D 578 28 Chemin du Vieux Chene 579 38243 Meylan Cedex 580 France 581 Email: gabriel.chegaray@orange-ftgroup.com 583 Thomas Watteyne 584 France Telecom R&D 585 28 Chemin du Vieux Chene 586 38243 Meylan Cedex 587 France 588 Email: thomas.watteyne@orange-ftgroup.com 589 Christian Jacquenet 590 France Telecom R&D 591 4 rue du Clos Courtel BP 91226 592 35512 Cesson Sevigne 593 France 594 Email: christian.jacquenet@orange-ftgroup.com 595 Full Copyright Statement 597 Copyright (C) The IETF Trust (2007). 599 This document is subject to the rights, licenses and restrictions 600 contained in BCP 78, and except as set forth therein, the authors 601 retain all their rights. 603 This document and the information contained herein are provided on an 604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 606 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 607 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 608 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 611 Intellectual Property 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Acknowledgment 637 Funding for the RFC Editor function is provided by the IETF 638 Administrative Support Activity (IASA).