Networking Working Group M. Dohler, Ed. Internet-Draft CTTC Intended status: Informational T. Watteyne, Ed. Expires:
September 15,December 3, 2008 France Telecom R&D April 16,T. Winter, Ed. Eka Systems June 30, 2008 Urban WSNs Routing Requirements in Low Power and Lossy Networks draft-ietf-roll-urban-routing-reqs-00draft-ietf-roll-urban-routing-reqs-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15,December 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2008).Abstract The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly which - given the limited radio range and the large number of nodes - requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc)etc.) and the particularities of the outdoors urban application scenario.scenarios. As such, for a wireless ROLL solution to be competitive with other incumbent and emerging solutions,useful, the protocol(s) ought to be energy-efficient, scalablescalable, and autonomous. This documents aims to specify a set of requirements reflecting these and further U-LLNs tailored characteristics. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 64 3. Overview of Urban LLN application scenarios.Low Power Lossy Networks . . . . . . . . . . 5 3.1. Canonical Network Elements . . . . . 7 3.1. Deployment of nodes.. . . . . . . . . . . 5 3.1.1. Access Points . . . . . . . . 7 3.2. Association and disassociation/disappearance of nodes.. . 8 3.3. Regular measurement reporting.. . . . . . . . . . 5 3.1.2. Repeaters . . . . 8 3.4. Queried measurement reporting.. . . . . . . . . . . . . . 9 3.5. Alert reporting.. . . . 6 3.1.3. Actuators . . . . . . . . . . . . . . . . . 9 4. Requirements of urban LLN applications. . . . . 6 3.1.4. Sensors . . . . . . . 10 4.1. Scalability... . . . . . . . . . . . . . . . 6 3.2. Topology . . . . . . 10 4.2. Parameter constrained routing. . . . . . . . . . . . . . 10 4.3. Support of autonomous and alien configuration. . . . . 7 3.3. Resource Constraints . 10 4.4. Support of highly directed information flows.. . . . . . 11 4.5. Support of heterogeneous field devices.. . . . . . . . . 11 4.6. Support. . . 7 3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8 4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9 4.1. Deployment of multicastNodes . . . . . . . . . . . . . . . . . . . 9 4.2. Association and implementationDisassociation/Disappearance of groupcast.Nodes . . 11 4.7. Network dynamicity.10 4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 11 4.4. Queried Measurement Reporting . . . . . . 12 4.8. Latency.. . . . . . . . 11 4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . .1212 5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . .1312 6. Security ConsiderationsRequirements of Urban LLN Applications . . . . . . . . . . . . 14 6.1. Scalability . . . . . . . .13 7. Open Issues. . . . . . . . . . . . . . . . 14 6.2. Parameter Constrained Routing . . . . . . . . . .13 8. IANA Considerations. . . . . 14 6.3. Support of Autonomous and Alien Configuration . . . . . . 15 6.4. Support of Highly Directed Information Flows . . . . . . . 15 6.5. Support of Heterogeneous Field Devices . . . .14 9. Acknowledgements.. . . . . . . 15 6.6. Support of Multicast, Anycast, and Implementation of Groupcast . . . . . . . . . . . . . . . .14 10. References.. . . . . . . . . 16 6.7. Network Dynamicity . . . . . . . . . . . . . . . . 14 10.1 Normative References.. . . . 16 6.8. Latency . . . . . . . . . . . . . . 14 10.2 Informative References.. . . . . . . . . . . 16 7. Security Considerations . . . . . . 14 Authors' Addresses.. . . . . . . . . . . . . 17 8. Open Issues . . . . . . . . . . . . 14 Full Copyright Statement.. . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . 15 1. Introduction We detail here some application specific routing requirements for Urban Low Power and Lossy. . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction This document details application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs). U-LLN use cases and associated routing protocol requirements will be described. Section 2 defines terminology useful in describing U-LLNs. Section 3 provides an overview of U-LLN applications. Section 4 describes a few typical use cases for U-LLN applications exemplifying deployment problems and related routing issues. Section 5 describes traffic flows that will be typical for U-LLN applications. Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may be overlapping requirements derived from other application- specific requirements documents or as listed in [I-D.culler-rl2n-routing-reqs]. Section 7 provides an overview of security considerations of U-LLN implementations. 2. Terminology Access Point: The access point is an infrastructure device that connects the low power and lossy network system to a backbone network. Actuator: a field device that moves or controls equipment AMI: Advanced Metering Infrastructure, part of Smart Grid. Encompasses smart-metering applications. DA: Distribution Automation, part of Smart Grid. Encompasses technologies for maintenance and management of electrical distribution systems. Field Device: physical device placed in the urban operating environment. Field devices include sensors, actuators and repeaters. LLN: Low power and Lossy Network ROLL: Routing over Low power and Lossy networks Smart Grid: a broad class of applications to network and automate utility infrastructure. Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. U-LLN: Urban LLN 3. Overview of Urban Low Power Lossy Networks (U-LLNs).3.1. Canonical Network Elements A U-LLN is understood to be a network composed of four key elements, i.e. 1) sensors, 2) actuators, 3) repeaters, and 4)1. access points, 2. repeaters, 3. actuators, and 4. sensors which communicate wirelessly. 3.1.1. Access Points The access point can be used as: 1)1. router to a wider infrastructure (e.g. Internet), 2)2. data sink (e.g. data collection & processing from sensors), and 3)3. data source (e.g. instructions towards actuators).actuators) There can be several access points connected to the same U-LLN; however, the number of access points is well below the amount of sensing nodes. The access points are mainly static, i.e. fixed to a random or pre- planned location, but can be nomadic, i.e. in form of a walking supervisor. Access points may but generally do not suffer from any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap. 3.1.2. Repeaters Repeaters generally act as relays with the aim to close coverage and routing gaps; examples of their use are: 1)1. prolong the U-LLN's lifetime, 2)2. balance nodes' energy depletion, 3)3. build advanced sensing infrastructures. There can be several repeaters supporting the same U-LLN; however, the number of repeaters is well below the amount of sensing nodes. The repeaters are mainly static, i.e. fixed to a random or pre-plannedpre- planned location. Repeaters may but generally do not suffer from any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap. Repeaters differ from access points in that they neitherdo not act as a router nor as adata sink/source. They differ from actuator and sensing nodes in that they neither control nor sense. 3.1.3. Actuators Actuator nodes control urban devices upon being instructed by signaling arriving from or being forwarded by the access point(s); examples are street or traffic lights. The amount of actuator points is well below the number of sensing nodes. Some sensing nodes may include an actuator component, e.g. an electric meter node with integrated support for remote service disconnect. Actuators are capable to forward data. Actuators may generally be mobile but are likely to be static in the majority of near-future roll-outs. Similar to the access points, actuator nodes do not suffer from any long-term resource constraints. 3.1.4. Sensors Sensing nodes measure a wide gamut of physical data, including but not limited to: 1)1. municipal consumption data, such as thesmart-metering of gas, water, electricity, waste, etc; 2)2. meteorological data, such as temperature, pressure, humidity, sun index, strength and direction of wind, etc; 3)3. pollution data, such as polluting gases (SO2, NOx, CO, Ozone), heavy metals (e.g. Mercury), pH, radioactivity, etc; 4)4. ambient data, such as allergic elements (pollen, dust), electromagnetic pollution, noise levels, etc. A prominent example is a Smart Grid application which consists of a city-wide network of smart meters and distribution monitoring sensors. Smart meters in an urban Smart Grid application will include electric, gas, and/or water meters typically administered by one or multiple utility companies. These meters will be capable of advanced sensing functionalities such as measuring quality of service, providing granular interval data, or automating the detection of alarm conditions. In addition they may be capable of advanced interactive functionalities such as remote service disconnect or remote demand reset. More advanced scenarios include demand response systems for managing peak load, and distribution automation systems to monitor the infrastructure which delivers energy throughout the urban environment. Sensor nodes capable of providing this type of functionality may sometimes be referred to as Advanced Metering Infrastructure (AMI). 3.2. Topology Whilst millions of sensing nodes may very well be deployed in an urban area, they are likely to be associated to more than one network where these networks may or may not communicate between eachone other. The number of sensing nodes connected to a single networkdeployed in the urban environment in support of some applications is expected to be in the order of 10^2-10^4;10^2- 10^7; this is still very large and unprecedented in current roll-outs.roll- outs. The network MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each. Deployment of nodes is likely to happen in batches, i.e. a boxe.g. boxes of hundreds to thousands of nodes arrivesarrive and are deployed. The location of the nodes is random within given topological constraints, e.g. placement along a roadroad, river, or river.at individual residences. 3.3. Resource Constraints The nodes are highly resource constrained, i.e. cheap hardware, low memory and no infinite energy source. Different node powering mechanisms are available, such as: 1)1. non-rechargeable battery; 2)2. rechargeable battery with regular recharging (e.g. sunlight); 3)3. rechargeable battery with irregular recharging (e.g. opportunistic energy scavenging); 4)4. capacitive/inductive energy provision (e.g. active RFID). TheRFID); 5. always on (e.g. powered electricity meter). In the case of a battery powered sensing node, the battery life-time is usually in the orderorder of 10-15 years, rendering network lifetime maximization with battery-powered nodes beyond this lifespan useless. The physical and electromagnetic distances between the four key elements, i.e. sensors, actuators, repeaters and access points, can generally be very large, i.e. from several hundreds of meters to one kilometer. Not every field node is likely to reach the access point in a single hop, thereby requiring suitable routing protocols which manage the information flow in an energy-efficient manner. Sensor nodes are capable of forwarding data. 3.4. Link Reliability The links between the network elements are volatile due to the following set of non-exclusive effects: 1. packet errors due to wireless channel effects; 2. packet errors due to medium access control; 3. packet errors due to interference from other systems; 4. link unavailability due to network dynamicity; etc. The wireless channel causes the received power to drop below a given threshold in a random fashion, thereby causing detection errors in the receiving node. The underlying effects are path loss, shadowing and fading. Since the wireless medium is broadcast in nature, nodes in their communication radios require suitable medium access control protocols which are capable of resolving any arising contention. Some available protocols may cause packets of neighbouring nodes to collide and hence cause a link outage. Furthermore, the outdoors deployment of U-LLNs also has implications for the interference temperature and hence link reliability and range if ISM bands are to be used. For instance, if the 2.4GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the functioning of 10-15 years, rendering network lifetime maximization with battery-poweredthe U-LLN. Finally, nodes beyond this lifespan useless. The physicalappearing and electromagnetic distances betweendisappearing causes dynamics in the four key elements, i.e. sensors, actuators, repeaters and access points,network which can generally be very large, i.e. from several hundredsyield link outages and changes of meterstopologies. 4. Urban LLN Application Scenarios Urban applications represent a special segment of LLNs with its unique set of requirements. To facilitate the requirements discussion in Section 4, this section lists a few typical but not exhaustive deployment problems and usage cases of U-LLN. 4.1. Deployment of Nodes Contrary to one kilometer. Not every field nodeother LLN applications, deployment of nodes is likely to reach the access pointhappen in batches out of a single hop, thereby requiring suitable routing protocols which manage the information flow in an energy-efficient manner. Sensorbox. Typically, hundreds to thousands of nodes are capable to forward data. Unlike traditional ad hoc networks,being shipped by the information flow in U-LLNs is highly directional. Theremanufacturer with pre-programmed functionalities which are three main flows to be distinguished: 1) sensed information from the sensing nodes towards one orthen rolled-out by a subset of the access point(s); 2) query requests from the access point(s) towards the sensing nodes; 3) control information from the access point(s) towards the actuators. Some ofservice provider or subcontracted entities. Prior or after roll-out, the flowsnetwork needs to be ramped-up. This initialization phase may need the reverse route for delivering acknowledgements. Finally,include, among others, allocation of addresses, (possibly hierarchical) roles in the future, some direct information flows between field devices without access points may also occur. Sensed datanetwork, synchronization, determination of schedules, etc. If initialization is performed prior to roll-out, all nodes are likely to be highly correlatedin space, timeone another's 1-hop radio neighborhood. Pre- programmed MAC and observed events; an examplerouting protocols may hence fail to function properly, thereby wasting a large amount of energy. Whilst the latter is when temperature and humidity increase as the day commences. Data maymajor burden will be sensedon resolving MAC conflicts, any proposed U-LLN routing protocol needs to cater for such a case. For instance, 0-configuration and delivered at different rates with both rates being typically fairly low, i.e. innetwork address allocation needs to be properly supported, etc. After roll-out, nodes will have a finite set of one-hop neighbors, likely of low cardinality (in the rangeorder of hours, days, etc. Data5- 10). However, some nodes may be delivered regularly according to a schedule or a regular query; itdeployed in areas where there are hundreds of neighboring devices. In the resulting topology there may alsobe delivered irregularly after an externally triggered query; itregions where many (redundant) paths are possible through the network. Other regions may also be triggered after a sudden network-internal event or alert. The network hence needs tobe able to adjustdependant on critical links to achieve connectivity with the varying activity duty cycles, as well asrest of the network. Any proposed LLN routing protocol ought to periodsupport the autonomous organization and aperiodic traffic. Also, sensed data oughtconfiguration of the network at lowest possible energy cost [Lu2007], where autonomy is understood to be secured and locatable. Finally,the outdoors deploymentability of U-LLNs has also implications forthe interference temperature and hence link reliability and range if ISM bands arenetwork to be used.operate without external influence. For instance, if the 2.4GHz ISM band is usedexample, nodes in urban sensor nodes SHOULD be able to: o Dynamically adapt to facilitateever-changing conditions of communication between U-LLN nodes, then heavily loaded WLAN hot-spots become a detrimental performance factor jeopardizing the reliability(possible degradation of QoS, variable nature of the U-LLN. Section 3 describestraffic (real time vs. non real time, sensed data vs. alerts, node mobility, a few typical use cases for urban LLN applications exemplifying deployment problems and related routing issues. Section 4 discussescombination thereof, etc.), o Dynamically provision the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may be overlapping requirements derived from other application-specific requirements documents or as listed in [I-D.culler-roll-routing-reqs]. 2. Terminology Access Point: The access point is an infrastructure deviceservice-specific (if not traffic- specific) resources that connectswill comply with the low powerQoS and lossy network system to a backbone network. Actuator: a field devicesecurity requirements of the service, o Dynamically compute, select and possibly optimize the (multiple) path(s) that moves or controls equipment. Field Device: physical device placed inwill be used by the urban operating environment. Fieldparticipating devices include sensors,to forward the traffic towards the actuators and/or the access point according to the service-specific and repeaters. LLN: Low power and Lossy Network ROLL: Routing over Low powertraffic-specific QoS, traffic engineering and Lossy networks Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. Timeslot: A fixed time intervalsecurity policies that maywill have to be used forenforced at the transmission or receptionscale of a packet between two field devices. A timeslot used for communications is associated with a slotted-link. U-LLN: Urban LLN 3. Urban LLN application scenarios Urban applications representrouting domain (that is, a special segmentset of LLNs with itsnetworking devices administered by a globally unique setentity), or a region of requirements. To facilitate the requirements discussion in Section 4, this section listssuch domain (e.g. a few typical but not exhaustive deployment problems and usage casesmetropolitan area composed of U-LLN. 3.1. Deploymentclusters of nodes Contrary to other LLN applications, deploymentsensors). The result of such organization SHOULD be that each node or set of nodes is likelyuniquely addressable so as to happen in batches outfacilitate the set up of a box. Typically, hundredsschedules, etc. The U-LLN routing protocol(s) MUST accommodate both unicast and multicast forwarding schemes. The U-LLN routing protocol(s) SHOULD support anycast forwarding schemes. Unless exceptionally needed, broadcast forwarding schemes are not advised in urban sensor networking environments. 4.2. Association and Disassociation/Disappearance of Nodes After the initialization phase and possibly some operational time, new nodes are being shipped bymay be injected into the manufacturer with pre-programmed functionalities whichnetwork as well as existing nodes removed from the network. The former might be because a removed node is replaced or denser readings/actuations are then rolled-out byneeded or routing protocols report connectivity problems. The latter might be because a service providernode's battery is depleted, the node is removed for maintenance, the node is stolen or subcontracted entities. Prioraccidentally destroyed, etc. Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or after roll-out,node-initiated disassociation ("phased-out"), where the network needsnode has enough time to be ramped-up. This initialization phase may include, among others, allocationinform the network about its removal. The protocol(s) hence SHOULD support the pinpointing of addresses, (possibly hierarchical) rolesproblematic routing areas as well as an organization of the network which facilitates reconfiguration in the network, synchronization, determinationcase of association and disassociation/disappearance of nodes at lowest possible energy and delay. The latter may include the change of hierarchies, routing paths, packet forwarding schedules, etc. If initialization is performed priorFurthermore, to roll-out, allinform the access point(s) of the node's arrival and association with the network as well as freshly associated nodes are likely toabout packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms SHOULD be in each others 1-hop radio neighborhood. Pre-programmed MAC and routing protocols may hence fail to function properly, thereby wasting a large amountsupported. 4.3. Regular Measurement Reporting The majority of energy. Whilst the major burdensensing nodes will be on resolving MAC conflicts, any proposed U-LLN routing protocol needsconfigured to cater for suchreport their readings on a case. For instance, 0-configurationregular basis. The frequency of data sensing and network address allocation needs toreporting may be properly supported, etc. If initializationdifferent but is performed after roll-out, nodes will have a finite set of one-hop neighbors, likely of low cardinality (ingenerally expected to be fairly low, i.e. in the orderrange of 5- 10). Any proposed LLN routing protocol ought to supportonce per hour, per day, etc. The ratio between data sensing and reporting frequencies will determine the autonomous organizationmemory and configurationdata aggregation capabilities of the network at lowest possible energy cost [Lu2007], where autonomy is understood to be the abilitynodes. Latency of the network to operate without external impact. The resultan end-to-end delivery and acknowledgements of such organization ought toa successful data delivery may not be that each nodevital as sensing outages can be observed at the access point(s) - when, for instance, there is no reading arriving from a given sensor or setscluster of nodes are uniquely addressable so assensors within a day. In this case, a query can be launched to facilitatecheck upon the set upstate and availability of schedules, etc.a sensing node or sensing cluster. The U-LLN routingprotocol(s) hence MUST accommodate both unicast and multicast forwarding schemes. Broadcast forwarding schemes are NOT adviced in urban sensor networking environments. 3.2. Association and disassociation/disappearancesupport a large number of highly directional unicast flows from the sensing nodes Afteror sensing clusters towards the access point or highly directed multicast or anycast flows from the initialization phase and possibly some operational time, newnodes towards multiple access points. Route computation and selection may be injected intodepend on the network as well as existing nodes removed fromtransmitted information, the network. The former mightfrequency of reporting, the amount of energy remaining in the nodes, the recharging pattern of energy-scavenged nodes, etc. For instance, temperature readings could be because a removed node is replaced or denser readings/actuationsreported every hour via one set of battery-powered nodes, whereas air quality indicators are needed orreported only during daytime via nodes powered by solar energy. More generally, entire routing protocols report connectivity problems. The latter mightareas may be because a node's battery is depleted, the node is removed for maintenance,avoided at e.g. night but heavily used during the node is stolen or accidentally destroyed, etc. Differentiation shouldday when nodes are scavenging from sunlight. 4.4. Queried Measurement Reporting Occasionally, network external data queries can be made between node disappearance, where the node disappears without prior notification, and user or node-initiated disassociation ("phased-out"), where the node has enough timelaunched by one or several access points. For instance, it is desirable to informknow the network about its removal.level of pollution at a specific point or along a given road in the urban environment. The protocol(s) hence oughtqueries' rates of occurrence are not regular but rather random, where heavy-tail distributions seem appropriate to model their behavior. Queries do not necessarily need to be reported back to supportthe pinpointingsame access point from where the query was launched. Round-trip times, i.e. from the launch of problematic routing areas as well asa query from an organizationaccess point towards the delivery of the network which facilitates reconfigurationmeasured data to an access point, are of importance. However, they are not very stringent where latencies SHOULD simply be sufficiently smaller than typical reporting intervals; for instance, in the case of association and disassociation/disappearanceorder of nodes at lowest possible energyseconds or minute. To facilitate the query process, U-LLN network devices SHOULD support unicast and delay.multicast routing capabilities. The latter may include the changesame approach is also applicable for schedule update, provisioning of hierarchies, routing paths, packet forwarding schedules,patches and upgrades, etc. Furthermore, to informIn this case, however, the access point(s)provision of acknowledgements and the node's arrivalsupport of unicast, multicast, and association withanycast are of importance. 4.5. Alert Reporting Rarely, the network as well as freshly associatedsensing nodes about packet forwarding schedules, roles, etc, appropriate (link state) updating mechanisms oughtwill measure an event which classifies as alarm where such a classification is typically done locally within each node by means of a pre-programmed or prior diffused threshold. Note that on approaching the alert threshold level, nodes may wish to be supported. 3.3. Regular measurementchange their sensing and reporting The majoritycycles. An alarm is likely being registered by a plurality of sensing nodes will be configured to report their readings onwhere the delivery of a regular basis. The frequencysingle alert message with its location of data sensing andorigin suffices in most cases. One example of alert reporting may be different butis generally expected to be fairly low, i.e. inif the rangelevel of once per hour, per day, etc. The ratio between datatoxic gases rises above a threshold, thereupon the sensing and reporting frequencies will determinenodes in the memory and data aggregation capabilitiesvicinity of this event report the nodes. Latency of an end-to-end delivery and acknowledgementsdanger. Another example of alert reporting is when a successful data delivery are not vital as sensing outages can be observed at the access point(s)recycling glass container - when, for instance, there is no reading arriving fromequipped with a givensensor or clustermeasuring its level of sensors within a day. In this case, a query can be launched to check uponoccupancy - reports that the statecontainer is full and availability of a sensing node or sensing cluster. The protocol(s)hence oughtneeds to support a large number of highly directional unicast flows frombe emptied. Routing within urban sensor networks SHOULD require the sensingU-LLN nodes or sensing clustersto dynamically compute, select and install different paths towards a same destination, depending on the access point or highly directed multicast or anycast flows fromnature of the traffic. From this perspective, such nodes towards multiple access points. Route computation and selection may depend on the transmitted information,SHOULD inspect the frequencycontents of reporting,traffic payload for making routing and forwarding decisions: for example, the amountanalysis of energy remaining inthe nodes,traffic payload SHOULD be derived into aggregation capabilities for the recharging patternsake of energy-scavenged nodes, etc. For instance, temperature readings couldforwarding efficiency. Routes clearly need to be reported every hour viaunicast (towards one setaccess point) or multicast (towards multiple access points). Delays and latencies are important; however, again, deliveries within seconds SHOULD suffice in most of battery-powered nodes, whereas air quality indicatorsthe cases. 5. Traffic Pattern Unlike traditional ad hoc networks, the information flow in U-LLNs is highly directional. There are reported only during daytime via nodes powered by solar energy. More generally, entire routing areas maythree main flows to be avoided at e.g. night but heavily used duringdistinguished: 1. sensed information from the day whensensing nodes are scavenging from sunlight. 3.4. Queried measurement reporting Occasionally, network external data queries can be launched bytowards one or several access points. For instance, it is desirable to know the level of pollution at a specific point or alonga given road in the urban environment. The queries' ratessubset of occurrence are not regular but rather random, where heavy-tail distributions seem appropriate to model their behavior. Queries do not necessarily need to be reported back tothe sameaccess point from where thepoint(s); 2. query was launched. Round-trip times, i.e.requests from the launch of a queryaccess point(s) towards the sensing nodes; 3. control information from anthe access pointpoint(s) towards the deliveryactuators. Some of the measuredflows may need the reverse route for delivering acknowledgements. Finally, in the future, some direct information flows between field devices without access points may also occur. Sensed data is likely to an access point, are of importance. However, they are not very stringent where latencies should simplybe sufficiently smaller than typical reporting intervals; for instance,highly correlated in the orderspace, time and observed events; an example of seconds or minute. To facilitatethe query process, U-LLN network devices should support unicast and multicast routing capabilities. The same approachlatter is also applicable for schedule update, provisioning of patcheswhen temperature increase and upgrades, etc. In this case, however,humidity decrease as the provision of acknowledgementsday commences. Data may be sensed and delivered at different rates with both rates being typically fairly low, i.e. in the supportrange of broadcast (in additionminutes, hours, days, etc. Data may be delivered regularly according to unicast and multicast) are of importance. 3.5. Alert reporting Rarely, the sensing nodes will measurea schedule or a regular query; it may also be delivered irregularly after an externally triggered query; it may also be triggered after a sudden network- internal event which classifiesor alert. Data delivery may trigger acknowledgements or maintenance traffic in the reverse direction. The network hence needs to be able to adjust to the varying activity duty cycles, as alarm wherewell as to periodic and sporadic traffic. Also, sensed data ought to be secured and locatable. Some data delivery may have tight latency requirements, for example in a case such as a classification is typically done locally within each node by means oflive meter reading for customer service in a pre-programmedsmart-metering application, or prior diffused threshold. Notein a case where a sensor reading response must arrive within a certain time in order to be useful. The network SHOULD take into consideration that on approachingdifferent application traffic may require different priorities when traversing the alert threshold level, nodesnetwork, and that some traffic may wishbe more sensitive to change their sensing and reporting cycles.latency. An alarm is likely being registered by a plurality ofU-LLN SHOULD support occasional large scale traffic flows from sensing nodes whereto access points, such as system-wide alerts. In the deliveryexample of an AMI U-LLN this could be in response to events such as a single alert message with its location of origin sufficescity wide power outage. In this scenario all powered devices in most cases. One examplea large segment of alert reporting is ifthe levelnetwork may have lost power and are running off of toxic gases rises abovea threshold, thereupontemporary `last gasp' source such as a capacitor or small battery. A node MUST be able to send its own alerts toward an access point while continuing to forward traffic on behalf of other devices who are also experiencing an alert condition. The network MUST be able to manage this sudden large traffic flow. It may be useful for the sensing nodesrouting layer to collaborate with the application layer to perform data aggregation, in order to reduce the vicinitytotal volume of a large traffic flow, and make more efficient use of this event reportthe danger. Another examplelimited energy available. An U-LLN may also need to support efficient large scale messaging to groups of alert reporting is whenactuators. For example, an AMI U-LLN supporting a glass container - equipped withcity- wide demand response system will need to efficiently broadcast demand response control information to a sensor measuring its levellarge subset of occupancy - reports thatactuators in the container is fullsystem. Some scenarios will require internetworking between the U-LLN and hence needs to be emptied. Routes clearlyanother network, such as a home network. For example, an AMI application that implements a demand-response system may need to forward traffic from a utility, across the U-LLN, into a home automation network. A typical use case would be unicast (towards one access point)to inform a customer of incentives to reduce demand during peaks, or multicast (towards multiple access points). Delays and latencies are important; however, again, deliveries within seconds should suffice in mostto automatically adjust the thermostat of customers who have enrolled in such a demand management program. Subsequent traffic may be triggered to flow back through the cases. 4.U-LLN to the utility. The network SHOULD support internetworking, while giving attention to security implications of interfacing, for example, a home network with a utility U-LLN. 6. Requirements of urbanUrban LLN applicationsApplications Urban low power and lossy network applications have a number of specific requirements related to the set of operating conditions, as exemplified in the previous section. 18.104.22.168. Scalability The large and diverse measurement space of U-LLN nodes - coupled with the typically large urban areas - will yield extremely large network sizes. Current urban roll-outs are composed of sometimes more than a hundred nodes; future roll-outs, however, may easily reach numbers in the tens of thousands.thousands to millions. One of the utmost important LLN routing protocol design criteria is hence scalability. The routing protocol(s) MUST be scalable so as to accommodate a very large and increasing number of nodes without deteriorating to-be- specified performance parameters below to-be-specified thresholds. 4.2. Parameter constrainedThe routing protocols(s) SHOULD support the organization of a large number of nodes into regions of to-be-specified size. 6.2. Parameter Constrained Routing Batteries in some nodes may deplete quicker than in others; the existence of one node for the maintenance of a routing path may not be as important as of another node; the battery scavenging methods may recharge the battery at regular or irregular intervals; some nodes may have a constant power source; some nodes may have a larger memory and are hence be able to store more neighborhood information; some nodes may have a stronger CPU and are hence able to perform more sophisticated data aggregation methods; etc. To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph. 22.214.171.124. Support of autonomousAutonomous and alien configurationAlien Configuration With the large number of nodes, manually configuring and troubleshooting each node is not possible.efficient. The scale and the large number of possible topologies that may be encountered in the U-LLN encourages the development of automated management capabilities that may (partly) rely upon self-organizing techniques. The network is expected to self-organize and self-configure according to some prior defined rules and protocols, as well as to support externally triggered configurations (for instance through a commissioning tool which may facilitate the organization of the network at a minimum energy cost). To this end, the routing protocol(s) MUST provide a set of features including 0-configuration at network ramp-up, (network-internal) self- organization and configuration due to topological changes, ability to support (network-external) patches and configuration updates. For the latter, the protocol(s) MUST support multi- and broad-castany-cast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network. 126.96.36.199. Support of highly directed information flowsHighly Directed Information Flows The reporting of the data readings by a large amount of spatially dispersed nodes towards a few access points will lead to highly directed information flows. For instance, a suitable addressing scheme can be devised which facilitates the data flow. Also, as one gets closer to the access point, the traffic concentration increases which may lead to high load imbalances in node usage. To this end, the routing protocol(s) SHOULD support and utilize the fact of highly directed traffic flow to facilitate scalability and parameter constrained routing. 188.8.131.52. Support of heterogeneous field devicesHeterogeneous Field Devices The sheer amount of different field devices will unlikely be provided by a single manufacturer. A heterogeneous roll-out with nodes using different physical and medium access control layers is hence likely. To mandate fully interoperable implementations, the routing protocol(s) proposed in U-LLN MUST support different devices and underlying technologies without compromising the operability and energy efficiency of the network. 184.108.40.206. Support of multicastMulticast, Anycast, and implementationImplementation of groupcastGroupcast Some urban sensing systems require low-level addressing of a group of nodes inof a group of nodes in the same subnet, or for a node representative of a group of nodes, without any prior creation of multicast groups, simply carrying a list of recipients in the subnet [I-D.brandt-roll-home-routing-reqs]. Routing protocols activated in urban sensor networks MUST support unicast (traffic is sent to a single field device), multicast (traffic is sent to a set of devices that are subscribed to the same multicast group), and anycast (where multiple field devices are configured to accept traffic sent on a single IP anycast address) transmission schemes [RFC4291] [RFC1546]. Routing protocols activated in urban sensor networks SHOULD accommodate "groupcast" forwarding schemes, where traffic is sent to a set of devices that implicitly belong to the same group/cast. The support of unicast, groupcast, multicast, and anycast also has an implication on the addressing scheme but is beyond the same subnet without any prior creation of multicast groups, simply carrying a listscope of recipients in the subnet [draft-brandt-roll- home-routing-reqs-01]. Tothis end,document that focuses on the routing protocol(s) MUST supportrequirements aspects. Note: with IP multicast, wheresignaling mechanisms are used by a receiver to join a group and the routing protocol(s) MUST providesender does not know the receivers of the group. What is required is the ability to forward a packet towards a single field device (unicast) oraddress a setgroup of devices explicitly belongingreceivers known by the sender even if the receivers do not need to know that they have been grouped by the same group/cast (multicast). Routing protocols activatedsender (since requesting each individual node to join a multicast group would be very energy- consuming). 6.7. Network Dynamicity Although mobility is assumed to be low in urban sensor networks must be ableLLNs, network dynamicity due to support unicast (trafficnode association, disassociation and disappearance, as well as long-term link perturbations is sentnot negligible. This in turn impacts re-organization and re-configuration convergence as well as routing protocol convergence. To this end, local network dynamics SHOULD NOT impact the entire network to a single field device)be re-organized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. Convergence and route establishment times SHOULD be significantly lower than the smallest reporting interval. 6.8. Latency With the exception of alert reporting solutions and multicast (traffic is sentto a setcertain extent queried reporting, U-LLN are delay tolerant as long as the information arrives within a fraction of devices that belong tothe same group/cast) forwarding schemes. Routing protocols activated in urban sensor networkssmallest reporting interval, e.g. a few seconds if reporting is done every 4 hours. To this end, the routing protocol(s) SHOULD accommodate "groupcast" forwarding schemes, where traffic is sent tosupport minimum latency for alert reporting and time-critical data queries. For regular data reporting, it SHOULD support latencies not exceeding a setfraction of devices that implicitly belongthe smallest reporting interval. Due to the same group/cast. Thedifferent latency requirements, the routing protocol(s) SHOULD support the ability of unicast, groupcast and multicastdealing with different latency requirements. The routing protocol(s) SHOULD also has an implication on the addressing scheme but is beyondsupport the scopeability to route according to different metrics (one of this document that focuses on the routing requirements aspects. Note: with IP multicast, signaling mechanismswhich could e.g. be latency). 7. Security Considerations As every network, U-LLNs are used by a receiverexposed to join a groupsecurity threats that MUST be addressed. The wireless and distributed nature of these networks increases the sender does not knowspectrum of potential security threats. This is further amplified by the receiversresource constraints of the group. What is required isnodes, thereby preventing resource intensive security approaches from being deployed. A viable security approach SHOULD be sufficiently lightweight that it may be implemented across all nodes in a U-LLN. These issues require special attention during the abilitydesign process, so as to addressfacilitate a groupcommercially attractive deployment. A secure communication in a wireless network encompasses three main elements, i.e. confidentiality (encryption of receivers known by the sender even if the receivers do not needdata), integrity (correctness of data), and authentication (legitimacy of data). U-LLN networks SHOULD support mechanisms to knowpreserve the confidentiality of the traffic that they have been grouped by the sender (since requesting each individual node to join a multicast group wouldforward. The U-LLN network SHOULD NOT prevent an application from employing additional confidentiality mechanisms. Authentication can e.g. be very energy-consuming). 4.7. Network dynamicity Although mobility is assumed toviolated if external sources insert incorrect data packets; integrity can e.g. be low in urban LLNs, network dynamicity dueviolated if nodes start to node association, disassociationbreak down and disappearance is not negligible. This in turn impacts re-organizationhence commence measuring and re-configuration convergencerelaying data incorrectly. Nonetheless, some sensor readings as well as routing protocol convergence. To this end, local network dynamics SHOULD NOT impactthe entireactuator control signals need to be confidential. The U-LLN network MUST deny all routing services to any node who has not been authenticated to the U-LLN and authorized for the use of routing services. The U-LLN MUST be protected against attempts to inject false or modified packets. For example, an attacker SHOULD be re-organizedprevented from manipulating or re-reconfigured; however,disabling the networkrouting function by compromising routing update messages. Moreover, it SHOULD NOT be locally optimizedpossible to cater forcoerce the encountered changes. Convergence and route establishment times SHOULD be significantly lower thannetwork into routing packets which have been modified in transit. To this end the routing protocol(s) MUST support message integrity. Further example security issues which may arise are the inverseabnormal behavior of nodes which exhibit an egoistic conduct, such as not obeying network rules, or forwarding no or false packets. Other important issues may arise in the smallest reporting cycle. 4.8. Latency Withcontext of Denial of Service (DoS) attacks, malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, external attacks aimed at injecting dummy traffic to drain the exceptionnetwork power, etc. The properties of alert reporting solutionsself-configuration and to a certain extent queried reporting, U-LLNself-organization which are delay tolerant as long as the information arrives withindesirable in a fractionU-LLN introduce additional security considerations. Mechanisms MUST be in place to deny any rogue node which attempts to take advantage of self-configuration and self-organization procedures. Such attacks may attempt, for example, to cause denial of service, drain the inverseenergy of power constrained devices, or to hijack the respective reporting cycle, e.g.routing mechanism. A node MUST authenticate itself to a few seconds if reportingtrusted node that is done every 4 hours. To this end,already associated with the routing protocol(s) SHOULD support minimum latency for alert reportingU-LLN before any self-configuration or self-organization is allowed to proceed. A node that has already authenticated and time-critical data queries. For regular data reporting, it SHOULD support latencies not exceeding a fraction of the inverse ofassociated with the respective reporting cycle. DueU-LLN MUST deny, to the different latency requirements, the routing protocol(s) SHOULD supportmaximum extent possible, the abilityallocation of dealing with different latency requirements.resources to any unauthenticated peer. The routing protocol(s) SHOULD also support the ability to route accordingMUST deny service to different metrics (one ofany node which could e.g. be latency). 5. Traffic Pattern tbd 6. Security Considerations As every network, U-LLNs are exposed to security threats which, ifhas not properly addressed, exclude them to be deployed in the envisaged scenarios. The wireless and distributed nature of these networks drastically increases the spectrum of potential security threats; this is further amplified byclearly established trust with the serious constraints in node battery power, thereby preventing previously known security approaches toU-LLN. Consideration SHOULD be deployed. Above mentioned issues require special attention duringgiven to cases where the design process, soU-LLN may interface with other networks such as to facilitate a commercially attractive deployment. A secure communication ina wireless network encompasses three main elements, i.e. confidentiality (encryption of data), integrity (correctness of data), and authentication (legitimacyhome network. The U-LLN SHOULD NOT interface with any external network which has not established trust. The U-LLN SHOULD be capable of data). Sincelimiting the majority of measured dataresources granted in U-LLNs is publicly available, the main emphasis is on integrity and authenticitysupport of data reports. Authentication can e.g. be violated ifan external sources insert incorrect data packets; integrity can e.g.network so as not to be violated if nodes startvulnerable to break downdenial of service. With low computation power and hence commence measuringscarce energy resources, U-LLNs nodes may not be able to resist any attack from high-power malicious nodes (e.g. laptops and relaying data incorrectly. Nonetheless, some sensor readings as well asstrong radios). However, the actuator control signals needamount of damage generated to the whole network SHOULD be confidential. Further example security issues which may arise arecommensurate with the abnormal behaviornumber of nodes which exhibitphysically compromised. For example, an egoistic conduct, such asintruder taking control over a single node SHOULD not obeying network rules, or forwarding nohave total access to, or false packets. Other important issues may arise inbe able to completely deny service to the context of Denial of Service (DoS) attacks, malicious address space allocations, advertisementwhole network. In general, the routing protocol(s) SHOULD support the implementation of variable addresses, a wrong neighborhood, external attacks aimed at injecting dummy traffic to drainsecurity best practices across the network power, etc.U-LLN. Such an implementation ought to include defense against, for example, eavesdropping, replay, message insertion, modification, and man-in-the-middle attacks. The choice of the security solutions will have an impact onto routing protocol(s). To this end, routing protocol(s) proposed in the context of U-LLNs MUST support integrity measures and SHOULD support confidentiality (security) measures. 7.8. Open Issues Other items to be addressed in further revisions of this document include: *o node mobility; and * traffic patterns. 8.mobility 9. IANA Considerations This document includesmakes no request toof IANA. 9.10. Acknowledgements The in-depth feedback of JP Vasseur, Cisco, and Jonathan Hui, Arch Rock, is greatly appreciated. 10.11. References 10.111.1. Normative References [RFC2119] S.Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.211.2. Informative References [I-D.culler-roll-routing-reqs] J.P. Vasseur[I-D.brandt-roll-home-routing-reqs] Brandt, A., "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-brandt-roll-home-routing-reqs-01 (work in progress), May 2008. [I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Culler,Cullerot, "Routing Requirements for Low-Power WirelessLow Power And Lossy Networks", draft-culler-roll-routing-reqs-00draft-culler-rl2n-routing-reqs-01 (work in progress), July 2007. [Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully Integrated Scheme of Self-Configuration and Self-OrganizationSelf- Organization for WSN,"WSN", IEEE WCNC 2007, Hong Kong, China, 11-15 March 2007, pp. 3370-3375. [draft-brandt-roll-home-routing-reqs-01] A. Brand and J.P. Vasseur, "Home Automation Routing Requirement in Low Power[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC4291] Hinden, R. and Lossy Networks," draft-brandt-roll-home-routing-reqs-01 (work in progress), July 2007.S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Authors' Addresses Mischa Dohler (editor) CTTC Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 08860 Castelldefels, Barcelona Spain Email: email@example.com Thomas Watteyne (editor) France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France Email: firstname.lastname@example.org Tim Winter (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, MD 20874 USA Email: email@example.com Christian Jacquenet France Telecom R&D 4 rue du Clos Courtel BP 91226 35512 Cesson Sevigne France Email: firstname.lastname@example.org Giyyarpuram Madhusudan France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France Email: email@example.com Gabriel Chegaray France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France Email: firstname.lastname@example.org Dominique Barthel France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France Email: Dominique.Barthel@orange-ftgroup.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).