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