idnits 2.17.1 draft-ietf-roll-urban-routing-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 12, 2009) is 5549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-roll-building-routing-reqs-05 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-06 == Outdated reference: A later version (-06) exists of draft-ietf-roll-indus-routing-reqs-04 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group M. Dohler, Ed. 3 Internet-Draft CTTC 4 Intended status: Informational T. Watteyne, Ed. 5 Expires: August 16, 2009 CITI-Lab, INRIA A4RES 6 T. Winter, Ed. 7 Eka Systems 8 D. Barthel, Ed. 9 France Telecom R&D 10 February 12, 2009 12 Urban WSNs Routing Requirements in Low Power and Lossy Networks 13 draft-ietf-roll-urban-routing-reqs-04 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and 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 any 27 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 August 16, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 The application-specific routing requirements for Urban Low Power and 53 Lossy Networks (U-LLNs) are presented in this document. In the near 54 future, sensing and actuating nodes will be placed outdoors in urban 55 environments so as to improve the people's living conditions as well 56 as to monitor compliance with increasingly strict environmental laws. 57 These field nodes are expected to measure and report a wide gamut of 58 data, such as required in smart metering, waste disposal, 59 meteorological, pollution and allergy reporting applications. The 60 majority of these nodes is expected to communicate wirelessly over a 61 variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE 62 802.15.1 (Bluetooth), which given the limited radio range and the 63 large number of nodes requires the use of suitable routing protocols. 64 The design of such protocols will be mainly impacted by the limited 65 resources of the nodes (memory, processing power, battery, etc.) and 66 the particularities of the outdoor urban application scenarios. As 67 such, for a wireless Routing Over Low power and Lossy networks (ROLL) 68 solution to be useful, the protocol(s) ought to be energy-efficient, 69 scalable, and autonomous. This documents aims to specify a set of 70 IPv6 routing requirements reflecting these and further U-LLNs 71 tailored characteristics. 73 Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 3. Overview of Urban Low Power Lossy Networks . . . . . . . . . . 5 84 3.1. Canonical Network Elements . . . . . . . . . . . . . . . . 5 85 3.1.1. Sensors . . . . . . . . . . . . . . . . . . . . . . . 5 86 3.1.2. Actuators . . . . . . . . . . . . . . . . . . . . . . 6 87 3.1.3. Routers . . . . . . . . . . . . . . . . . . . . . . . 6 88 3.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.3. Resource Constraints . . . . . . . . . . . . . . . . . . . 7 90 3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8 91 4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9 92 4.1. Deployment of Nodes . . . . . . . . . . . . . . . . . . . 9 93 4.2. Association and Disassociation/Disappearance of Nodes . . 10 94 4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 10 95 4.4. Queried Measurement Reporting . . . . . . . . . . . . . . 11 96 4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 11 97 5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . 12 98 6. Requirements of Urban LLN Applications . . . . . . . . . . . . 13 99 6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 100 6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 14 101 6.3. Support of Autonomous and Alien Configuration . . . . . . 15 102 6.4. Support of Highly Directed Information Flows . . . . . . . 15 103 6.5. Support of Multicast and Anycast . . . . . . . . . . . . . 16 104 6.6. Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16 105 6.7. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 114 1. Introduction 116 This document details application-specific IPv6 routing requirements 117 for Urban Low Power and Lossy Networks (U-LLNs). Note that this 118 document details the set of IPv6 routing requirements for U-LLNs in 119 strict compliance with the layered IP architecture. U-LLN use cases 120 and associated routing protocol requirements will be described. 122 Section 2 defines terminology useful in describing U-LLNs. 124 Section 3 provides an overview of U-LLN applications. 126 Section 4 describes a few typical use cases for U-LLN applications 127 exemplifying deployment problems and related routing issues. 129 Section 5 describes traffic flows that will be typical for U-LLN 130 applications. 132 Section 6 discusses the routing requirements for networks comprising 133 such constrained devices in a U-LLN environment. These requirements 134 may be overlapping requirements derived from other application- 135 specific requirements documents [I-D.ietf-roll-home-routing-reqs] 136 [I-D.ietf-roll-indus-routing-reqs] 137 [I-D.ietf-roll-building-routing-reqs]. 139 Section 7 provides an overview of routing security considerations of 140 U-LLN implementations. 142 2. Terminology 144 The terminology used in this document is consistent with and 145 incorporates that described in `Terminology in Low power And Lossy 146 Networks' [I-D.ietf-roll-terminology]. This terminology is extended 147 in this document as follows: 149 Anycast: Addressing and Routing scheme for forwarding packets to at 150 least one of the "nearest" interfaces from a group, as 151 described in RFC4291 [RFC4291] and RFC1546 [RFC1546]. 153 Autonomous: Refers to the ability of a routing protocol to 154 independently function without requiring any external influence 155 or guidance. Includes self-configuration and self-organization 156 capabilities. 158 DoS: Denial of Service, a class of attack that attempts to cause 159 resource exhaustion to the detriment of a node or network. 161 ISM band: Industrial, Scientific and Medical band. This is a region 162 of radio spectrum where low power unlicensed devices may 163 generally be used, with specific guidance from an applicable 164 local radio spectrum authority. 166 U-LLN: Urban Low Power and Lossy network. 168 WLAN: Wireless Local Area Network. 170 3. Overview of Urban Low Power Lossy Networks 172 3.1. Canonical Network Elements 174 A U-LLN is understood to be a network composed of three key elements, 175 i.e. 177 1. sensors, 179 2. actuators, and 181 3. routers. 183 which communicate wirelessly. The aim of the following sections 184 (Section 3.1.1, Section 3.1.2, and Section 3.1.3) is to illustrate 185 the functional nature of a sensor, actuator and a router in this 186 context. That said, it must be understood that these functionalities 187 are not exclusive. A particular device may act as a simple router or 188 may alternatively be a router equipped with a sensing functionality, 189 in which case it will be seen as a "regular" router as far as routing 190 is concerned. 192 3.1.1. Sensors 194 Sensing nodes measure a wide gamut of physical data, including but 195 not limited to: 197 1. municipal consumption data, such as smart-metering of gas, water, 198 electricity, waste, etc; 200 2. meteorological data, such as temperature, pressure, humidity, UV 201 index, strength and direction of wind, etc; 203 3. pollution data, such as gases (SO2, NOx, CO, Ozone), heavy metals 204 (e.g. Mercury), pH, radioactivity, etc; 206 4. ambient data, such as allergic elements (pollen, dust), 207 electromagnetic pollution, noise levels, etc. 209 Sensor nodes run applications that typically gather the measurement 210 data and send it to data collection and processing application(s) on 211 other node(s) (often outside the U-LLN). 213 Sensor nodes are capable of forwarding data. Sensor nodes are 214 generally not mobile in the majority of near-future roll-outs. In 215 many anticipated roll-outs, sensor nodes may suffer from long-term 216 resource constraints. 218 A prominent example is a Smart Grid application which consists of a 219 city-wide network of smart meters and distribution monitoring 220 sensors. Smart meters in an urban Smart Grid application will 221 include electric, gas, and/or water meters typically administered by 222 one or multiple utility companies. These meters will be capable of 223 advanced sensing functionalities such as measuring the quality of 224 electrical service provided to a customer, providing granular 225 interval data, or automating the detection of alarm conditions. In 226 addition they may be capable of advanced interactive functionalities, 227 which may invoke an Actuator component, such as remote service 228 disconnect or remote demand reset. More advanced scenarios include 229 demand response systems for managing peak load, and distribution 230 automation systems to monitor the infrastructure which delivers 231 energy throughout the urban environment. Sensor nodes capable of 232 providing this type of functionality may sometimes be referred to as 233 Advanced Metering Infrastructure (AMI). 235 3.1.2. Actuators 237 Actuator nodes are capable of controlling urban devices; examples are 238 street or traffic lights. They run applications that receive 239 instructions from control applications on other nodes (possibly 240 outside the U-LLN). The amount of actuator points is well below the 241 number of sensing nodes. Some sensing nodes may include an actuator 242 component, e.g. an electric meter node with integrated support for 243 remote service disconnect. Actuators are capable of forwarding data. 244 Actuators are not likely to be mobile in the majority of near-future 245 roll-outs. Actuator nodes may also suffer from long-term resource 246 constraints, e.g. in the case where they are battery powered. 248 3.1.3. Routers 250 Routers generally act to close coverage and routing gaps within the 251 interior of the U-LLN; examples of their use are: 253 1. prolong the U-LLN's lifetime, 255 2. balance nodes' energy depletion, 257 3. build advanced sensing infrastructures. 259 There can be several routers supporting the same U-LLN; however, the 260 number of routers is well below the amount of sensing nodes. The 261 routers are generally not mobile, i.e. fixed to a random or pre- 262 planned location. Routers may but generally do not suffer from any 263 form of (long-term) resource constraint, except that they need to be 264 small and sufficiently cheap. Routers differ from actuator and 265 sensing nodes in that they neither control nor sense. That being 266 said, a sensing node or actuator may also be a router within the 267 U-LLN. 269 Some routers provide access to wider infrastructures, such as the 270 Internet, and are named Low power and lossy network Border Routers 271 (LBRs) in that context. 273 LBR nodes in particular may also run applications that communicate 274 with sensor and actuator nodes (e.g. collecting and processing data 275 from sensor applications, or sending instructions to actuator 276 applications). 278 3.2. Topology 280 Whilst millions of sensing nodes may very well be deployed in an 281 urban area, they are likely to be associated with more than one 282 network. These networks may or may not communicate between one 283 another. The number of sensing nodes deployed in the urban 284 environment in support of some applications is expected to be in the 285 order of 10^2 to 10^7; this is still very large and unprecedented in 286 current roll-outs. 288 Deployment of nodes is likely to happen in batches, e.g. boxes of 289 hundreds to thousands of nodes arrive and are deployed. The location 290 of the nodes is random within given topological constraints, e.g. 291 placement along a road, river, or at individual residences. 293 3.3. Resource Constraints 295 The nodes are highly resource constrained, i.e. cheap hardware, low 296 memory and no infinite energy source. Different node powering 297 mechanisms are available, such as: 299 1. non-rechargeable battery; 301 2. rechargeable battery with regular recharging (e.g. sunlight); 303 3. rechargeable battery with irregular recharging (e.g. 304 opportunistic energy scavenging); 306 4. capacitive/inductive energy provision (e.g. passive Radio 307 Frequency IDentification (RFID)); 309 5. always on (e.g. powered electricity meter). 311 In the case of a battery powered sensing node, the battery shelf life 312 is usually in the order of 10 to 15 years, rendering network lifetime 313 maximization with battery powered nodes beyond this lifespan useless. 315 The physical and electromagnetic distances between the three key 316 elements, i.e. sensors, actuators, and routers, can generally be very 317 large, i.e. from several hundreds of meters to one kilometer. Not 318 every field node is likely to reach the LBR in a single hop, thereby 319 requiring suitable routing protocols which manage the information 320 flow in an energy-efficient manner. 322 3.4. Link Reliability 324 The links between the network elements are volatile due to the 325 following set of non-exclusive effects: 327 1. packet errors due to wireless channel effects; 329 2. packet errors due to MAC (Medium Access Control) (e.g. 330 collision); 332 3. packet errors due to interference from other systems; 334 4. link unavailability due to network dynamicity; etc. 336 The wireless channel causes the received power to drop below a given 337 threshold in a random fashion, thereby causing detection errors in 338 the receiving node. The underlying effects are path loss, shadowing 339 and fading. 341 Since the wireless medium is broadcast in nature, nodes in their 342 communication radios require suitable medium access control protocols 343 which are capable of resolving any arising contention. Some 344 available protocols may not be able to prevent packets of neighboring 345 nodes from colliding, possibly leading to a high Packet Error Rate 346 (PER) and causing a link outage. 348 Furthermore, the outdoor deployment of U-LLNs also has implications 349 for the interference temperature and hence link reliability and range 350 if Industrial, Scientific and Medical (ISM) bands are to be used. 351 For instance, if the 2.4GHz ISM band is used to facilitate 352 communication between U-LLN nodes, then heavily loaded Wireless Local 353 Area Network (WLAN) hot-spots may become a detrimental performance 354 factor, leading to high PER and jeopardizing the functioning of the 355 U-LLN. 357 Finally, nodes appearing and disappearing causes dynamics in the 358 network which can yield link outages and changes of topologies. 360 4. Urban LLN Application Scenarios 362 Urban applications represent a special segment of LLNs with its 363 unique set of requirements. To facilitate the requirements 364 discussion in Section 6, this section lists a few typical but not 365 exhaustive deployment problems and usage cases of U-LLN. 367 4.1. Deployment of Nodes 369 Contrary to other LLN applications, deployment of nodes is likely to 370 happen in batches out of a box. Typically, hundreds to thousands of 371 nodes are being shipped by the manufacturer with pre-programmed 372 functionalities which are then rolled-out by a service provider or 373 subcontracted entities. Prior or after roll-out, the network needs 374 to be ramped-up. This initialization phase may include, among 375 others, allocation of addresses, (possibly hierarchical) roles in the 376 network, synchronization, determination of schedules, etc. 378 If initialization is performed prior to roll-out, all nodes are 379 likely to be in one another's 1-hop radio neighborhood. Pre- 380 programmed Media Access Control (MAC) and routing protocols may hence 381 fail to function properly, thereby wasting a large amount of energy. 382 Whilst the major burden will be on resolving MAC conflicts, any 383 proposed U-LLN routing protocol needs to cater for such a case. For 384 instance, 0-configuration and network address allocation needs to be 385 properly supported, etc. 387 After roll-out, nodes will have a finite set of one-hop neighbors, 388 likely of low cardinality (in the order of 5 to 10). However, some 389 nodes may be deployed in areas where there are hundreds of 390 neighboring devices. In the resulting topology there may be regions 391 where many (redundant) paths are possible through the network. Other 392 regions may be dependent on critical links to achieve connectivity 393 with the rest of the network. Any proposed LLN routing protocol 394 ought to support the autonomous self-organization and self- 395 configuration of the network at lowest possible energy cost [Lu2007], 396 where autonomy is understood to be the ability of the network to 397 operate without external influence. The result of such organization 398 should be that each node or set of nodes is uniquely addressable so 399 as to facilitate the set up of schedules, etc. 401 Unless exceptionally needed, broadcast forwarding schemes are not 402 advised in urban sensor networking environments. 404 4.2. Association and Disassociation/Disappearance of Nodes 406 After the initialization phase and possibly some operational time, 407 new nodes may be injected into the network as well as existing nodes 408 removed from the network. The former might be because a removed node 409 is replaced as part of maintenance, or new nodes are added because 410 more sensors for denser readings/actuations are needed, or because 411 routing protocols report connectivity problems. The latter might be 412 because a node's battery is depleted, the node is removed for 413 maintenance, the node is stolen or accidentally destroyed, etc. 415 The protocol(s) hence should be able to convey information about 416 malfunctioning nodes which may affect or jeopardize the overall 417 routing efficiency, so that self-organization and self-configuration 418 capabilities of the sensor network might be solicited to facilitate 419 the appropriate reconfiguration. This information may e.g. include 420 exact or relative geographical position, etc. The reconfiguration 421 may include the change of hierarchies, routing paths, packet 422 forwarding schedules, etc. Furthermore, to inform the LBR(s) of the 423 node's arrival and association with the network as well as freshly 424 associated nodes about packet forwarding schedules, roles, etc, 425 appropriate updating mechanisms should be supported. 427 4.3. Regular Measurement Reporting 429 The majority of sensing nodes will be configured to report their 430 readings on a regular basis. The frequency of data sensing and 431 reporting may be different but is generally expected to be fairly 432 low, i.e. in the range of once per hour, per day, etc. The ratio 433 between data sensing and reporting frequencies will determine the 434 memory and data aggregation capabilities of the nodes. Latency of an 435 end-to-end delivery and acknowledgements of a successful data 436 delivery may not be vital as sensing outages can be observed at data 437 collection applications - when, for instance, there is no reading 438 arriving from a given sensor or cluster of sensors within a day. In 439 this case, a query can be launched to check upon the state and 440 availability of a sensing node or sensing cluster. 442 It is not uncommon to gather data on a few servers located outside of 443 the U-LLN. In such cases, a large number of highly directional 444 unicast flows from the sensing nodes or sensing clusters are likely 445 to transit through a LBR. Thus, the protocol(s) should be optimized 446 to support a large number of unicast flows from the sensing nodes or 447 sensing clusters towards a LBR, or highly directed multicast or 448 anycast flows from the nodes towards multiple LBRs. 450 Route computation and selection may depend on the transmitted 451 information, the frequency of reporting, the amount of energy 452 remaining in the nodes, the recharging pattern of energy-scavenged 453 nodes, etc. For instance, temperature readings could be reported 454 every hour via one set of battery powered nodes, whereas air quality 455 indicators are reported only during daytime via nodes powered by 456 solar energy. More generally, entire routing areas may be avoided 457 (e.g. at night) but heavily used during the day when nodes are 458 scavenging from sunlight. 460 4.4. Queried Measurement Reporting 462 Occasionally, network external data queries can be launched by one or 463 several applications. For instance, it is desirable to know the 464 level of pollution at a specific point or along a given road in the 465 urban environment. The queries' rates of occurrence are not regular 466 but rather random, where heavy-tail distributions seem appropriate to 467 model their behavior. Queries do not necessarily need to be reported 468 back to the same node from where the query was launched. Round-trip 469 times, i.e. from the launch of a query from a node until the delivery 470 of the measured data to a node, are of importance. However, they are 471 not very stringent where latencies should simply be sufficiently 472 smaller than typical reporting intervals; for instance, in the order 473 of seconds or minute. The routing protocol(s) should consider the 474 selection of paths with appropriate (e.g. latency) metrics to support 475 queried measurement reporting. To facilitate the query process, 476 U-LLN network devices should support unicast and multicast routing 477 capabilities. 479 The same approach is also applicable for schedule update, 480 provisioning of patches and upgrades, etc. In this case, however, 481 the provision of acknowledgements and the support of unicast, 482 multicast, and anycast are of importance. 484 4.5. Alert Reporting 486 Rarely, the sensing nodes will measure an event which classifies as 487 alarm where such a classification is typically done locally within 488 each node by means of a pre-programmed or prior diffused threshold. 489 Note that on approaching the alert threshold level, nodes may wish to 490 change their sensing and reporting cycles. An alarm is likely being 491 registered by a plurality of sensing nodes where the delivery of a 492 single alert message with its location of origin suffices in most, 493 but not all, cases. One example of alert reporting is if the level 494 of toxic gases rises above a threshold, thereupon the sensing nodes 495 in the vicinity of this event report the danger. Another example of 496 alert reporting is when a recycling glass container - equipped with a 497 sensor measuring its level of occupancy - reports that the container 498 is full and hence needs to be emptied. 500 Routes clearly need to be unicast (towards one LBR) or multicast 501 (towards multiple LBRs). Delays and latencies are important; 502 however, for a U-LLN deployed in support of a typical application, 503 deliveries within seconds should suffice in most of the cases. 505 5. Traffic Pattern 507 Unlike traditional ad hoc networks, the information flow in U-LLNs is 508 highly directional. There are three main flows to be distinguished: 510 1. sensed information from the sensing nodes to applications outside 511 the U-LLN, going through one or a subset of the LBR(s); 513 2. query requests from applications outside the U-LLN, going through 514 the LBR(s) towards the sensing nodes; 516 3. control information from applications outside the U-LLN, going 517 through the LBR(s) towards the actuators. 519 Some of the flows may need the reverse route for delivering 520 acknowledgements. Finally, in the future, some direct information 521 flows between field devices without LBRs may also occur. 523 Sensed data is likely to be highly correlated in space, time and 524 observed events; an example of the latter is when temperature 525 increase and humidity decrease as the day commences. Data may be 526 sensed and delivered at different rates with both rates being 527 typically fairly low, i.e. in the range of minutes, hours, days, etc. 528 Data may be delivered regularly according to a schedule or a regular 529 query; it may also be delivered irregularly after an externally 530 triggered query; it may also be triggered after a sudden network- 531 internal event or alert. Schedules may be driven by, for example, a 532 smart-metering application where data is expected to be delivered 533 every hour, or an environmental monitoring application where a 534 battery powered node is expected to report its status at a specific 535 time once a day. Data delivery may trigger acknowledgements or 536 maintenance traffic in the reverse direction. The network hence 537 needs to be able to adjust to the varying activity duty cycles, as 538 well as to periodic and sporadic traffic. Also, sensed data ought to 539 be secured and locatable. 541 Some data delivery may have tight latency requirements, for example 542 in a case such as a live meter reading for customer service in a 543 smart-metering application, or in a case where a sensor reading 544 response must arrive within a certain time in order to be useful. 545 The network should take into consideration that different application 546 traffic may require different priorities in the selection of a route 547 when traversing the network, and that some traffic may be more 548 sensitive to latency. 550 An U-LLN should support occasional large scale traffic flows from 551 sensing nodes through LBRs (to nodes outside the U-LLN), such as 552 system-wide alerts. In the example of an AMI U-LLN this could be in 553 response to events such as a city wide power outage. In this 554 scenario all powered devices in a large segment of the network may 555 have lost power and are running off of a temporary `last gasp' source 556 such as a capacitor or small battery. A node must be able to send 557 its own alerts toward an LBR while continuing to forward traffic on 558 behalf of other devices who are also experiencing an alert condition. 559 The network needs to be able to manage this sudden large traffic 560 flow. 562 An U-LLN may also need to support efficient large scale messaging to 563 groups of actuators. For example, an AMI U-LLN supporting a city- 564 wide demand response system will need to efficiently broadcast demand 565 response control information to a large subset of actuators in the 566 system. 568 Some scenarios will require internetworking between the U-LLN and 569 another network, such as a home network. For example, an AMI 570 application that implements a demand-response system may need to 571 forward traffic from a utility, across the U-LLN, into a home 572 automation network. A typical use case would be to inform a customer 573 of incentives to reduce demand during peaks, or to automatically 574 adjust the thermostat of customers who have enrolled in such a demand 575 management program. Subsequent traffic may be triggered to flow back 576 through the U-LLN to the utility. 578 6. Requirements of Urban LLN Applications 580 Urban low power and lossy network applications have a number of 581 specific requirements related to the set of operating conditions, as 582 exemplified in the previous sections. 584 6.1. Scalability 586 The large and diverse measurement space of U-LLN nodes - coupled with 587 the typically large urban areas - will yield extremely large network 588 sizes. Current urban roll-outs are composed of sometimes more than 589 one hundred nodes; future roll-outs, however, may easily reach 590 numbers in the tens of thousands to millions. One of the utmost 591 important LLN routing protocol design criteria is hence scalability. 593 The routing protocol(s) MUST be capable of supporting the 594 organization of a large number of sensing nodes into regions 595 containing on the order of 10^2 to 10^4 sensing nodes each. 597 The routing protocol(s) MUST be scalable so as to accommodate a very 598 large and increasing number of nodes without deteriorating selected 599 performance parameters below configurable thresholds. The routing 600 protocols(s) SHOULD support the organization of a large number of 601 nodes into regions of configurable size. 603 6.2. Parameter Constrained Routing 605 Batteries in some nodes may deplete quicker than in others; the 606 existence of one node for the maintenance of a routing path may not 607 be as important as of another node; the battery scavenging methods 608 may recharge the battery at regular or irregular intervals; some 609 nodes may have a constant power source; some nodes may have a larger 610 memory and are hence be able to store more neighborhood information; 611 some nodes may have a stronger CPU and are hence able to perform more 612 sophisticated data aggregation methods; etc. 614 To this end, the routing protocol(s) MUST support parameter 615 constrained routing, where examples of such parameters (CPU, memory 616 size, battery level, etc.) have been given in the previous paragraph. 618 Routing within urban sensor networks SHOULD require the U-LLN nodes 619 to dynamically compute, select and install different paths towards a 620 same destination, depending on the nature of the traffic. Such 621 functionality in support of, for example, data aggregation, may imply 622 to use some mechanisms to mark/tag the traffic for appropriate 623 routing decision using the IPv6 packet format (e.g. use of DSCP, Flow 624 Label) based on an upper layer marking decision. From this 625 perspective, such nodes MAY use node capabilities (e.g. to act as an 626 aggregator) in conjunction with the anycast endpoints and packet 627 marking to route the traffic. 629 6.3. Support of Autonomous and Alien Configuration 631 With the large number of nodes, manually configuring and 632 troubleshooting each node is not efficient. The scale and the large 633 number of possible topologies that may be encountered in the U-LLN 634 encourages the development of automated management capabilities that 635 may (partly) rely upon self-organizing techniques. The network is 636 expected to self-organize and self-configure according to some prior 637 defined rules and protocols, as well as to support externally 638 triggered configurations (for instance through a commissioning tool 639 which may facilitate the organization of the network at a minimum 640 energy cost). 642 To this end, the routing protocol(s) MUST provide a set of features 643 including 0-configuration at network ramp-up, (network-internal) 644 self- organization and configuration due to topological changes, and 645 the ability to support (network-external) patches and configuration 646 updates. For the latter, the protocol(s) MUST support multi- and 647 any-cast addressing. The protocol(s) SHOULD also support the 648 formation and identification of groups of field devices in the 649 network. 651 The routing protocol(s) SHOULD be able to dynamically adapt, e.g. 652 through the application of appropriate routing metrics, to ever- 653 changing conditions of communication (possible degradation of QoS, 654 variable nature of the traffic (real time vs. non real time, sensed 655 data vs. alerts), node mobility, a combination thereof, etc.) 657 The routing protocol(s) SHOULD be able to dynamically compute, select 658 and possibly optimize the (multiple) path(s) that will be used by the 659 participating devices to forward the traffic towards the actuators 660 and/or a LBR according to the service-specific and traffic-specific 661 QoS, traffic engineering and routing security policies that will have 662 to be enforced at the scale of a routing domain (that is, a set of 663 networking devices administered by a globally unique entity), or a 664 region of such domain (e.g. a metropolitan area composed of clusters 665 of sensors). 667 6.4. Support of Highly Directed Information Flows 669 As pointed out in section Section 4.3, it is not uncommon to gather 670 data on a few servers located outside of the U-LLN. In this case, 671 the reporting of the data readings by a large amount of spatially 672 dispersed nodes towards a few LBRs will lead to highly directed 673 information flows. For instance, a suitable addressing scheme can be 674 devised which facilitates the data flow. Also, as one gets closer to 675 the LBR, the traffic concentration increases which may lead to high 676 load imbalances in node usage. 678 To this end, the routing protocol(s) SHOULD support and utilize the 679 fact of a large number of highly directed traffic flows to facilitate 680 scalability and parameter constrained routing. 682 The routing protocol MUST be able to accommodate traffic bursts by 683 dynamically computing and selecting multiple paths towards the same 684 destination. 686 6.5. Support of Multicast and Anycast 688 Routing protocols activated in urban sensor networks MUST support 689 unicast (traffic is sent to a single field device), multicast 690 (traffic is sent to a set of devices that are subscribed to the same 691 multicast group), and anycast (where multiple field devices are 692 configured to accept traffic sent on a single IP anycast address) 693 transmission schemes. 695 The support of unicast, multicast, and anycast also has an 696 implication on the addressing scheme but is beyond the scope of this 697 document that focuses on the routing requirements aspects. 699 Some urban sensing systems may require low-level addressing of a 700 group of nodes in the same subnet, or for a node representative of a 701 group of nodes, without any prior creation of multicast groups. Such 702 addressing schemes, where a sender can form an addressable group 703 receivers, are not currently supported by IPv6, and not further 704 discussed in this specification [I-D.ietf-roll-home-routing-reqs]. 706 The network SHOULD support internetworking when identical protocols 707 are used, while giving attention to routing security implications of 708 interfacing, for example, a home network with a utility U-LLN. The 709 network may support the ability to interact with another network 710 using a different protocol, for example by supporting route 711 redistribution. 713 6.6. Network Dynamicity 715 Although mobility is assumed to be low in urban LLNs, network 716 dynamicity due to node association, disassociation and disappearance, 717 as well as long-term link perturbations is not negligible. This in 718 turn impacts reorganization and reconfiguration convergence as well 719 as routing protocol convergence. 721 To this end, local network dynamics SHOULD NOT impact the entire 722 network to be re-organized or re-reconfigured; however, the network 723 SHOULD be locally optimized to cater for the encountered changes. 724 The routing protocol(s) SHOULD support appropriate mechanisms in 725 order to be informed of the association, disassociation, and 726 disappearance of nodes. The routing protocol(s) SHOULD support 727 appropriate updating mechanisms in order to be informed of changes in 728 connectivity. The routing protocol(s) SHOULD use this information to 729 initiate protocol specific mechanisms for reorganization and 730 reconfiguration as necessary to maintain overall routing efficiency. 731 Convergence and route establishment times SHOULD be significantly 732 lower than the smallest reporting interval. 734 Differentiation SHOULD be made between node disappearance, where the 735 node disappears without prior notification, and user or node- 736 initiated disassociation ("phased-out"), where the node has enough 737 time to inform the network about its pending removal. 739 6.7. Latency 741 With the exception of alert reporting solutions and to a certain 742 extent queried reporting, U-LLNs are delay tolerant as long as the 743 information arrives within a fraction of the smallest reporting 744 interval, e.g. a few seconds if reporting is done every 4 hours. 746 The routing protocol(s) SHOULD also support the ability to route 747 according to different metrics (one of which could e.g. be latency). 749 7. Security Considerations 751 As every network, U-LLNs are exposed to routing security threats that 752 need to be addressed. The wireless and distributed nature of these 753 networks increases the spectrum of potential routing security 754 threats. This is further amplified by the resource constraints of 755 the nodes, thereby preventing resource intensive routing security 756 approaches from being deployed. A viable routing security approach 757 SHOULD be sufficiently lightweight that it may be implemented across 758 all nodes in a U-LLN. These issues require special attention during 759 the design process, so as to facilitate a commercially attractive 760 deployment. 762 The U-LLN network MUST deny any node who has not been authenticated 763 to the U-LLN and authorized to participate to the routing decision 764 process. 766 An attacker SHOULD be prevented from manipulating or disabling the 767 routing function, for example by compromising routing control 768 messages. To this end the routing protocol(s) MUST support message 769 integrity. 771 Further example routing security issues which may arise are the 772 abnormal behavior of nodes which exhibit an egoistic conduct, such as 773 not obeying network rules, or forwarding no or false packets. Other 774 important issues may arise in the context of Denial of Service (DoS) 775 attacks, malicious address space allocations, advertisement of 776 variable addresses, a wrong neighborhood, etc. The routing 777 protocol(s) SHOULD support defense against DoS attacks and other 778 attempts to maliciously or inadvertently cause the routing 779 protocol(s) mechanisms to over consume the limited resources of LLN 780 nodes, e.g. by constructing forwarding loops or causing excessive 781 routing protocol overhead traffic, etc. 783 The properties of self-configuration and self-organization which are 784 desirable in a U-LLN introduce additional routing security 785 considerations. Mechanisms MUST be in place to deny any node which 786 attempts to take malicious advantage of self-configuration and self- 787 organization procedures. Such attacks may attempt, for example, to 788 cause DoS, drain the energy of power constrained devices, or to 789 hijack the routing mechanism. A node MUST authenticate itself to a 790 trusted node that is already associated with the U-LLN before the 791 former can take part in self-configuration or self-organization. A 792 node that has already authenticated and associated with the U-LLN 793 MUST deny, to the maximum extent possible, the allocation of 794 resources to any unauthenticated peer. The routing protocol(s) MUST 795 deny service to any node which has not clearly established trust with 796 the U-LLN. 798 Consideration SHOULD be given to cases where the U-LLN may interface 799 with other networks such as a home network. The U-LLN SHOULD NOT 800 interface with any external network which has not established trust. 801 The U-LLN SHOULD be capable of limiting the resources granted in 802 support of an external network so as not to be vulnerable to DoS. 804 With low computation power and scarce energy resources, U-LLNs nodes 805 may not be able to resist any attack from high-power malicious nodes 806 (e.g. laptops and strong radios). However, the amount of damage 807 generated to the whole network SHOULD be commensurate with the number 808 of nodes physically compromised. For example, an intruder taking 809 control over a single node SHOULD NOT be able to completely deny 810 service to the whole network. 812 In general, the routing protocol(s) SHOULD support the implementation 813 of routing security best practices across the U-LLN. Such an 814 implementation ought to include defense against, for example, 815 eavesdropping, replay, message insertion, modification, and man-in- 816 the-middle attacks. 818 The choice of the routing security solutions will have an impact onto 819 routing protocol(s). To this end, routing protocol(s) proposed in 820 the context of U-LLNs MUST support authentication and integrity 821 measures and SHOULD support confidentiality (routing security) 822 measures. 824 8. IANA Considerations 826 This document makes no request of IANA. 828 9. Acknowledgements 830 The in-depth feedback of JP Vasseur, Jonathan Hui, and Iain Calder is 831 greatly appreciated. 833 10. References 835 10.1. Normative References 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, March 1997. 840 10.2. Informative References 842 [I-D.ietf-roll-building-routing-reqs] 843 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 844 "Building Automation Routing Requirements in Low Power and 845 Lossy Networks", draft-ietf-roll-building-routing-reqs-05 846 (work in progress), February 2009. 848 [I-D.ietf-roll-home-routing-reqs] 849 Brandt, A., Buron, J., and G. Porcu, "Home Automation 850 Routing Requirements in Low Power and Lossy Networks", 851 draft-ietf-roll-home-routing-reqs-06 (work in progress), 852 November 2008. 854 [I-D.ietf-roll-indus-routing-reqs] 855 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 856 "Industrial Routing Requirements in Low Power and Lossy 857 Networks", draft-ietf-roll-indus-routing-reqs-04 (work in 858 progress), January 2009. 860 [I-D.ietf-roll-terminology] 861 Vasseur, J., "Terminology in Low power And Lossy 862 Networks", draft-ietf-roll-terminology-00 (work in 863 progress), October 2008. 865 [Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully 866 Integrated Scheme of Self-Configuration and Self- 867 Organization for WSN", IEEE WCNC 2007, Hong Kong, China, 868 11-15 March 2007, pp. 3370-3375. 870 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 871 Anycasting Service", RFC 1546, November 1993. 873 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 874 Architecture", RFC 4291, February 2006. 876 Authors' Addresses 878 Mischa Dohler (editor) 879 CTTC 880 Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 881 08860 Castelldefels, Barcelona 882 Spain 884 Email: mischa.dohler@cttc.es 886 Thomas Watteyne (editor) 887 CITI-Lab, INSA-Lyon, INRIA A4RES 888 21 avenue Jean Capelle 889 69621 Lyon 890 France 892 Email: thomas.watteyne@ieee.org 894 Tim Winter (editor) 895 Eka Systems 896 20201 Century Blvd. Suite 250 897 Germantown, MD 20874 898 USA 900 Email: tim.winter@ekasystems.com 902 Dominique Barthel (editor) 903 France Telecom R&D 904 28 Chemin du Vieux Chene 905 38243 Meylan Cedex 906 France 908 Email: Dominique.Barthel@orange-ftgroup.com 909 Christian Jacquenet 910 France Telecom R&D 911 4 rue du Clos Courtel BP 91226 912 35512 Cesson Sevigne 913 France 915 Email: christian.jacquenet@orange-ftgroup.com 917 Giyyarpuram Madhusudan 918 France Telecom R&D 919 28 Chemin du Vieux Chene 920 38243 Meylan Cedex 921 France 923 Email: giyyarpuram.madhusudan@orange-ftgroup.com 925 Gabriel Chegaray 926 France Telecom R&D 927 28 Chemin du Vieux Chene 928 38243 Meylan Cedex 929 France 931 Email: gabriel.chegaray@orange-ftgroup.com