CTTC

Parc Mediterrani de la Tecnologia Av. Canal Olimpic S/N 08860 Castelldefels, Barcelona Spain mischa.dohler@cttc.es

CITI-Lab, INSA-Lyon, INRIA A4RES

21 avenue Jean Capelle 69621 Lyon France thomas.watteyne@ieee.org

Eka Systems

20201 Century Blvd. Suite 250 Germantown 20874 MD USA wintert@acm.org

France Telecom R&D

28 Chemin du Vieux Chene 38243 Meylan Cedex France Dominique.Barthel@orange-ftgroup.com

Routing Area 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 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 are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), 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.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.

This document details application-specific IPv6 routing requirements for Urban Low-Power and Lossy Networks (U-LLNs). Note that this document details the set of IPv6 routing requirements for U-LLNs in strict compliance with the layered IP architecture. U-LLN use cases and associated routing protocol requirements will be described. defines terminology useful in describing U-LLNs. provides an overview of U-LLN applications. describes a few typical use cases for U-LLN applications exemplifying deployment problems and related routing issues. describes traffic flows that will be typical for U-LLN applications. discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may overlap with or be derived from other application-specific requirements documents . provides an overview of routing security considerations of U-LLN implementations.

The terminology used in this document is consistent with and incorporates that described in "Terminology in Low power And Lossy Networks" . This terminology is extended in this document as follows: Addressing and Routing scheme for forwarding packets to at least one of the "nearest" interfaces from a group, as described in RFC4291 and RFC1546 . Refers to the ability of a routing protocol to independently function without requiring any external influence or guidance. Includes self-configuration and self-organization capabilities. Denial of Service, a class of attack that attempts to cause resource exhaustion to the detriment of a node or network. Industrial, Scientific, and Medical band. This is a region of radio spectrum where low-power, unlicensed devices may generally be used, with specific guidance from an applicable local radio spectrum authority. Urban Low-Power and Lossy Network. Wireless Local Area Network.

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.

A U-LLN is understood to be a network composed of three key elements, i.e., sensors, actuators, and routers that communicate wirelessly. The aim of the following sections (, , and ) is to illustrate the functional nature of a sensor, actuator, and router in this context. That said, it must be understood that these functionalities are not exclusive. A particular device may act as a simple router or may alternatively be a router equipped with a sensing functionality, in which case it will be seen as a "regular" router as far as routing is concerned.

Sensing nodes measure a wide gamut of physical data, including but not limited to: municipal consumption data, such as smart-metering of gas, water, electricity, waste, etc.; meteorological data, such as temperature, pressure, humidity, UV index, strength and direction of wind, etc.; pollution data, such as gases (sulfur dioxide (SO2), nitrogen oxide (NOx), carbon monoxide (CO), ozone), heavy metals (e.g., mercury), pH, radioactivity, etc.; ambient data, such as levels of allergens (pollen, dust), electromagnetic pollution, noise, etc. Sensor nodes run applications that typically gather the measurement data and send it to data collection and processing application(s) on other node(s) (often outside the U-LLN). Sensor nodes are capable of forwarding data. Sensor nodes are generally not mobile in the majority of near-future roll-outs. In many anticipated roll-outs, sensor nodes may suffer from long-term resource constraints. A prominent example is a "smart grid" application that 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 the quality of electrical service provided to a customer, providing granular interval data, or automating the detection of alarm conditions. In addition, they may be capable of advanced interactive functionalities, which may invoke an actuator component, 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 that 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).

Actuator nodes are capable of controlling urban devices; examples are street or traffic lights. They run applications that receive instructions from control applications on other nodes (possibly outside the U-LLN). 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 of forwarding data. Actuators are not likely to be mobile in the majority of near-future roll-outs. Actuator nodes may also suffer from long-term resource constraints, e.g., in the case where they are battery powered.

Routers generally act to close coverage and routing gaps within the interior of the U-LLN; examples of their use are: prolong the U-LLN's lifetime, balance nodes' energy depletion, and build advanced sensing infrastructures. There can be several routers supporting the same U-LLN; however, the number of routers is well below the amount of sensing nodes. The routers are generally not mobile, i.e., fixed to a random or pre-planned location. Routers may, but generally do not, suffer from any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap. Routers differ from actuator and sensing nodes in that they neither control nor sense. That being said, a sensing node or actuator may also be a router within the U-LLN. Some routers provide access to wider infrastructures, such as the Internet, and are named Low-Power and Lossy Network Border Routers (LBRs) in that context. LBR nodes in particular may also run applications that communicate with sensor and actuator nodes (e.g., collecting and processing data from sensor applications, or sending instructions to actuator applications).

Whilst millions of sensing nodes may very well be deployed in an urban area, they are likely to be associated with more than one network. These networks may or may not communicate between one another. The number of sensing nodes deployed in the urban environment in support of some applications is expected to be in the order of 10^2 to 10^7; this is still very large and unprecedented in current roll-outs. Deployment of nodes is likely to happen in batches, e.g., boxes of hundreds to thousands of nodes arrive and are deployed. The location of the nodes is random within given topological constraints, e.g., placement along a road, river, or at individual residences.

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: non-rechargeable battery; rechargeable battery with regular recharging (e.g., sunlight); rechargeable battery with irregular recharging (e.g., opportunistic energy scavenging); capacitive/inductive energy provision (e.g., passive Radio Frequency IDentification (RFID)); always on (e.g., powered electricity meter). In the case of a battery-powered sensing node, the battery shelf life is usually in the order of 10 to 15 years, rendering network lifetime maximization with battery-powered nodes beyond this lifespan useless. The physical and electromagnetic distances between the three key elements, i.e., sensors, actuators, and routers, can generally be very large, i.e., from several hundreds of meters to one kilometer. Not every field node is likely to reach the LBR in a single hop, thereby requiring suitable routing protocols that manage the information flow in an energy-efficient manner.

The links between the network elements are volatile due to the following set of non-exclusive effects: packet errors due to wireless channel effects; packet errors due to MAC (Medium Access Control) (e.g., collision); packet errors due to interference from other systems; 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 that are capable of resolving any arising contention. Some available protocols may not be able to prevent packets of neighboring nodes from colliding, possibly leading to a high Packet Error Rate (PER) and causing a link outage. Furthermore, the outdoor deployment of U-LLNs also has implications for the interference temperature and hence link reliability and range if Industrial, Scientific, and Medical (ISM) bands are to be used. For instance, if the 2.4 GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded Wireless Local Area Network (WLAN) hot-spots may become a detrimental performance factor, leading to high PER and jeopardizing the functioning of the U-LLN. Finally, nodes appearing and disappearing causes dynamics in the network that can yield link outages and changes of topologies.

Urban applications represent a special segment of LLNs with its unique set of requirements. To facilitate the requirements discussion in , this section lists a few typical but not exhaustive deployment problems and usage cases of U-LLN.

Contrary to other LLN applications, deployment of nodes is likely to happen in batches out of a box. Typically, hundreds to thousands of nodes are being shipped by the manufacturer with pre-programmed functionalities which are then rolled-out by a service provider or subcontracted entities. Prior to or after roll-out, the network needs to be ramped-up. This initialization phase may include, among others, allocation of addresses, (possibly hierarchical) roles in the network, synchronization, determination of schedules, etc. If initialization is performed prior to roll-out, all nodes are likely to be in one another's one-hop radio neighborhood. Pre-programmed Media Access Control (MAC) and routing protocols may hence fail to function properly, thereby wasting a large amount of energy. Whilst the major burden will be on resolving MAC conflicts, any proposed U-LLN routing protocol needs to cater for such a case. For instance, zero-configuration and network 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 order of 5 to 10). However, some nodes may be deployed in areas where there are hundreds of neighboring devices. In the resulting topology, there may be regions where many (redundant) paths are possible through the network. Other regions may be dependent on critical links to achieve connectivity with the rest of the network. Any proposed LLN routing protocol ought to support the autonomous self-organization and self-configuration of the network at lowest possible energy cost , where autonomy is understood to be the ability of the network to operate without external influence. The result of such organization should be that each node or set of nodes is uniquely addressable so as to facilitate the set up of schedules, etc. Unless exceptionally needed, broadcast forwarding schemes are not advised in urban sensor networking environments.

After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network. The former might be because a removed node is replaced as part of maintenance, or new nodes are added because more sensors for denser readings/actuations are needed, or because routing protocols report connectivity problems. The latter might be because a node's battery is depleted, the node is removed for maintenance, the node is stolen or accidentally destroyed, etc. The protocol(s) hence should be able to convey information about malfunctioning nodes that may affect or jeopardize the overall routing efficiency, so that self-organization and self-configuration capabilities of the sensor network might be solicited to facilitate the appropriate reconfiguration. This information may include, e.g., exact or relative geographical position, etc. The reconfiguration may include the change of hierarchies, routing paths, packet forwarding schedules, etc. Furthermore, to inform the LBR(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc., appropriate updating mechanisms should be supported.

The majority of sensing nodes will be configured to report their readings on a regular basis. The frequency of data sensing and reporting may be different but is generally expected to be fairly low, i.e., in the range of once per hour, per day, etc. The ratio between data sensing and reporting frequencies will determine the memory and data aggregation capabilities of the nodes. Latency of an end-to-end delivery and acknowledgements of a successful data delivery may not be vital as sensing outages can be observed at data collection applications -- when, for instance, there is no reading arriving from a given sensor or cluster of sensors within a day. In this case, a query can be launched to check upon the state and availability of a sensing node or sensing cluster. It is not uncommon to gather data on a few servers located outside of the U-LLN. In such cases, a large number of highly directional unicast flows from the sensing nodes or sensing clusters are likely to transit through a LBR. Thus, the protocol(s) should be optimized to support a large number of unicast flows from the sensing nodes or sensing clusters towards a LBR, or highly directed multicast or anycast flows from the nodes towards multiple LBRs. Route computation and selection may depend on the transmitted information, the frequency of reporting, the amount of energy remaining in the nodes, the recharging pattern of energy-scavenged nodes, etc. For instance, temperature readings could be reported every hour via one set of battery-powered nodes, whereas air quality indicators are reported only during the daytime via nodes powered by solar energy. More generally, entire routing areas may be avoided (e.g., at night) but heavily used during the day when nodes are scavenging from sunlight.

Occasionally, network-external data queries can be launched by one or several applications. For instance, it is desirable to know the level of pollution at a specific point or along a given road in the urban environment. The queries' 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 the same node from where the query was launched. Round-trip times, i.e., from the launch of a query from a node until the delivery of the measured data to a node, are of importance. However, they are not very stringent where latencies should simply be sufficiently smaller than typical reporting intervals; for instance, in the order of seconds or minutes. The routing protocol(s) should consider the selection of paths with appropriate (e.g., latency) metrics to support queried measurement reporting. To facilitate the query process, U-LLN devices should support unicast and multicast routing capabilities. The same approach is also applicable for schedule update, provisioning of patches and upgrades, etc. In this case, however, the provision of acknowledgements and the support of unicast, multicast, and anycast are of importance.

Rarely, the sensing nodes will measure an event that classifies as an 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 change their sensing and reporting cycles. An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most, but not all, cases. One example of alert reporting is if the level of toxic gases rises above a threshold; thereupon, the sensing nodes in the vicinity of this event report the danger. Another example of alert reporting is when a recycling glass container -- equipped with a sensor measuring its level of occupancy -- reports that the container is full and hence needs to be emptied. Routes clearly need to be unicast (towards one LBR) or multicast (towards multiple LBRs). Delays and latencies are important; however, for a U-LLN deployed in support of a typical application, deliveries within seconds should suffice in most of the cases.

Unlike traditional ad hoc networks, the information flow in U-LLNs is highly directional. There are three main flows to be distinguished: sensed information from the sensing nodes to applications outside the U-LLN, going through one or a subset of the LBR(s); query requests from applications outside the U-LLN, going through the LBR(s) towards the sensing nodes; control information from applications outside the U-LLN, going through the LBR(s) towards the actuators. Some of the flows may need the reverse route for delivering acknowledgements. Finally, in the future, some direct information flows between field devices without LBRs may also occur. Sensed data is likely to be highly correlated in space, time, and observed events; an example of the latter is when temperature increase and humidity decrease as the day commences. Data may be sensed and delivered at different rates with both rates being typically fairly low, i.e., in the range of minutes, hours, days, etc. Data may be delivered regularly according to a 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 or alert. Schedules may be driven by, for example, a smart-metering application where data is expected to be delivered every hour, or an environmental monitoring application where a battery-powered node is expected to report its status at a specific time once a day. 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 well 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 live meter reading for customer service in a smart-metering application, or in 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 different application traffic may require different priorities in the selection of a route when traversing the network, and that some traffic may be more sensitive to latency. A U-LLN should support occasional large-scale traffic flows from sensing nodes through LBRs (to nodes outside the U-LLN), such as system-wide alerts. In the example of an AMI U-LLN, this could be in response to events such as a city-wide power outage. In this scenario, all powered devices in a large segment of the network may have lost power and be running off of a temporary "last gasp" source such as a capacitor or small battery. A node must be able to send its own alerts toward an LBR while continuing to forward traffic on behalf of other devices that are also experiencing an alert condition. The network needs to be able to manage this sudden large traffic flow. A U-LLN may also need to support efficient large-scale messaging to groups of actuators. For example, an AMI U-LLN supporting a city-wide demand response system will need to efficiently broadcast demand-response control information to a large subset of actuators in the system. Some scenarios will require internetworking between the U-LLN and another 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 to inform a customer of incentives to reduce demand during peaks, or to 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 U-LLN to the utility.

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 sections.

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 one hundred nodes; future roll-outs, however, may easily reach numbers in the tens of thousands to millions. One of the utmost important LLN routing protocol design criteria is hence scalability. The routing protocol(s) 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. The routing protocol(s) MUST be scalable so as to accommodate a very large and increasing number of nodes without deteriorating selected performance parameters below configurable thresholds. The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of configurable size.

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. In other words, the routing protocol MUST be able to advertise node capabilities that will be exclusively used by the routing protocol engine for routing decision. For the sake of example, such a capability could be related to the node capability itself (e.g., remaining power) or some application that could influence routing (e.g., capability to aggregate data). Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select, and install different paths towards the same destination, depending on the nature of the traffic. Such functionality in support of, for example, data aggregation, may imply use of some mechanisms to mark/tag the traffic for appropriate routing decision using the IPv6 packet format (e.g., use of Diffserv Code Point (DSCP), Flow Label) based on an upper-layer marking decision. From this perspective, such nodes MAY use node capabilities (e.g., to act as an aggregator) in conjunction with the anycast endpoints and packet marking to route the traffic.

With the large number of nodes, manually configuring and troubleshooting each node is not 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 that 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 zero-configuration at network ramp-up, (network-internal) self-organization and configuration due to topological changes, and the ability to support (network-external) patches and configuration updates. For the latter, the protocol(s) MUST support multicast and anycast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network. The routing protocol(s) SHOULD be able to dynamically adapt, e.g., through the application of appropriate routing metrics, to ever-changing conditions of communication (possible degradation of quality of service (QoS), variable nature of the traffic (real-time versus non-real-time, sensed data versus alerts), node mobility, a combination thereof, etc.). The routing protocol(s) SHOULD be able to dynamically compute, select, and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or a LBR according to the service-specific and traffic-specific QoS, traffic engineering, and routing security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g., a metropolitan area composed of clusters of sensors).

As pointed out in , it is not uncommon to gather data on a few servers located outside of the U-LLN. In this case, the reporting of the data readings by a large amount of spatially dispersed nodes towards a few LBRs will lead to highly directed information flows. For instance, a suitable addressing scheme can be devised that facilitates the data flow. Also, as one gets closer to the LBR, 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 a large number of highly directed traffic flows to facilitate scalability and parameter-constrained routing. The routing protocol MUST be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination.

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. The support of unicast, multicast, and anycast also has an implication on the addressing scheme, but it is beyond the scope of this document that focuses on the routing requirements. Some urban sensing systems may require low-level addressing of 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. Such addressing schemes, where a sender can form an addressable group of receivers, are not currently supported by IPv6, and not further discussed in this specification . The network SHOULD support internetworking when identical protocols are used, while giving attention to routing security implications of interfacing, for example, a home network with a utility U-LLN. The network may support the ability to interact with another network using a different protocol, for example, by supporting route redistribution.

Although mobility is assumed to be low in urban LLNs, network dynamicity due to node association, disassociation, and disappearance, as well as long-term link perturbations is not negligible. This in turn impacts reorganization and reconfiguration convergence as well as routing protocol convergence. To this end, local network dynamics SHOULD NOT impact the entire network to be reorganized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. The routing protocol(s) SHOULD support appropriate mechanisms in order to be informed of the association, disassociation, and disappearance of nodes. The routing protocol(s) SHOULD support appropriate updating mechanisms in order to be informed of changes in connectivity. The routing protocol(s) SHOULD use this information to initiate protocol-specific mechanisms for reorganization and reconfiguration as necessary to maintain overall routing efficiency. Convergence and route establishment times SHOULD be significantly lower than the smallest reporting interval. Differentiation SHOULD 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 time to inform the network about its pending removal.

With the exception of alert-reporting solutions and (to a certain extent) queried reporting, U-LLNs are delay tolerant as long as the information arrives within a fraction of the smallest reporting interval, e.g., a few seconds if reporting is done every 4 hours. The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could, e.g., be latency).

As every network, U-LLNs are exposed to routing security threats that need to be addressed. The wireless and distributed nature of these networks increases the spectrum of potential routing security threats. This is further amplified by the resource constraints of the nodes, thereby preventing resource-intensive routing security approaches from being deployed. A viable routing 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 design process, so as to facilitate a commercially attractive deployment. The U-LLN MUST deny any node that has not been authenticated to the U-LLN and authorized to participate to the routing decision process. An attacker SHOULD be prevented from manipulating or disabling the routing function, for example, by compromising routing control messages. To this end, the routing protocol(s) MUST support message integrity. Further examples of routing security issues that may arise are the abnormal behavior of nodes that exhibit an egoistic conduct, such as not obeying network rules or forwarding no or false packets. Other important issues may arise in the context of denial-of-service (DoS) attacks, malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, etc. The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently cause the mechanisms of the routing protocol(s) to over-consume the limited resources of LLN nodes, e.g., by constructing forwarding loops or causing excessive routing protocol overhead traffic, etc. The properties of self-configuration and self-organization that are desirable in a U-LLN introduce additional routing security considerations. Mechanisms MUST be in place to deny any node that attempts to take malicious advantage of self-configuration and self-organization procedures. Such attacks may attempt, for example, to cause DoS, drain the energy of power-constrained devices, or to hijack the routing mechanism. A node MUST authenticate itself to a trusted node that is already associated with the U-LLN before the former can take part in self-configuration or self-organization. A node that has already authenticated and associated with the U-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer. The routing protocol(s) MUST deny service to any node that has not clearly established trust with the U-LLN. Consideration SHOULD be given to cases where the U-LLN may interface with other networks such as a home network. The U-LLN SHOULD NOT interface with any external network that has not established trust. The U-LLN SHOULD be capable of limiting the resources granted in support of an external network so as not to be vulnerable to DoS. With low computation power and scarce energy resources, U-LLNs' nodes may not be able to resist any attack from high-power malicious nodes (e.g., laptops and strong radios). However, the amount of damage generated to the whole network SHOULD be commensurate with the number of nodes physically compromised. For example, an intruder taking control over a single node SHOULD NOT be able to completely deny service to the whole network. In general, the routing protocol(s) SHOULD support the implementation of routing security best practices across the 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 routing security solutions will have an impact on the routing protocol(s). To this end, routing protocol(s) proposed in the context of U-LLNs MUST support authentication and integrity measures and SHOULD support confidentiality (routing security) measures.

The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and Pasi Eronen is greatly appreciated.

Christian Jacquenet France Telecom R&D 4 rue du Clos Courtel BP 91226 35512 Cesson Sevigne France EMail: christian.jacquenet@orange-ftgroup.com Giyyarpuram Madhusudan France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France EMail: giyyarpuram.madhusudan@orange-ftgroup.com Gabriel Chegaray France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France EMail: gabriel.chegaray@orange-ftgroup.com