diff options
Diffstat (limited to 'doc/rfc/rfc5548.txt')
| -rw-r--r-- | doc/rfc/rfc5548.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc5548.txt b/doc/rfc/rfc5548.txt new file mode 100644 index 0000000..5f5855c --- /dev/null +++ b/doc/rfc/rfc5548.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group M. Dohler, Ed. +Request for Comments: 5548 CTTC +Category: Informational T. Watteyne, Ed. + BSAC, UC Berkeley + T. Winter, Ed. + Eka Systems + D. Barthel, Ed. + France Telecom R&D + May 2009 + + + Routing Requirements for Urban Low-Power and Lossy Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +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 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 (for example, the data required by applications that perform + smart-metering or that monitor meteorological, pollution, and allergy + conditions). 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 + + + +Dohler, et al. Informational [Page 1] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 2.1. Requirements Language ......................................4 + 3. Overview of Urban Low-Power and Lossy Networks ..................4 + 3.1. Canonical Network Elements .................................4 + 3.1.1. Sensors .............................................4 + 3.1.2. Actuators ...........................................5 + 3.1.3. Routers .............................................6 + 3.2. Topology ...................................................6 + 3.3. Resource Constraints .......................................7 + 3.4. Link Reliability ...........................................7 + 4. Urban LLN Application Scenarios .................................8 + 4.1. Deployment of Nodes ........................................8 + 4.2. Association and Disassociation/Disappearance of Nodes ......9 + 4.3. Regular Measurement Reporting ..............................9 + 4.4. Queried Measurement Reporting .............................10 + 4.5. Alert Reporting ...........................................11 + 5. Traffic Pattern ................................................11 + 6. Requirements of Urban-LLN Applications .........................13 + 6.1. Scalability ...............................................13 + 6.2. Parameter-Constrained Routing .............................13 + 6.3. Support of Autonomous and Alien Configuration .............14 + 6.4. Support of Highly Directed Information Flows ..............15 + 6.5. Support of Multicast and Anycast ..........................15 + 6.6. Network Dynamicity ........................................16 + 6.7. Latency ...................................................16 + 7. Security Considerations ........................................16 + 8. References .....................................................18 + 8.1. Normative References ......................................18 + 8.2. Informative References ....................................18 + Appendix A. Acknowledgements .....................................20 + Appendix B. Contributors .........................................20 + + + + + + + + + + + +Dohler, et al. Informational [Page 2] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +1. Introduction + + 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. + + 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 overlap with or be derived from other application-specific + requirements documents [ROLL-HOME] [ROLL-INDUS] [ROLL-BUILD]. + + Section 7 provides an overview of routing security considerations of + U-LLN implementations. + +2. Terminology + + The terminology used in this document is consistent with and + incorporates that described in "Terminology in Low power And Lossy + Networks" [ROLL-TERM]. This terminology is extended in this document + as follows: + + Anycast: Addressing and Routing scheme for forwarding packets to at + least one of the "nearest" interfaces from a group, as + described in RFC4291 [RFC4291] and RFC1546 [RFC1546]. + + Autonomous: 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. + + DoS: Denial of Service, a class of attack that attempts to cause + resource exhaustion to the detriment of a node or network. + + + + + + + +Dohler, et al. Informational [Page 3] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + ISM band: 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. + + U-LLN: Urban Low-Power and Lossy Network. + + WLAN: Wireless Local Area Network. + +2.1. 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]. + +3. Overview of Urban Low-Power and Lossy Networks + +3.1. Canonical Network Elements + + A U-LLN is understood to be a network composed of three key elements, + i.e., + + 1. sensors, + + 2. actuators, and + + 3. routers + + that communicate wirelessly. The aim of the following sections + (3.1.1, 3.1.2, and 3.1.3) 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. + +3.1.1. Sensors + + Sensing nodes measure a wide gamut of physical data, including but + not limited to: + + 1. municipal consumption data, such as smart-metering of gas, water, + electricity, waste, etc.; + + 2. meteorological data, such as temperature, pressure, humidity, UV + index, strength and direction of wind, etc.; + + + + + +Dohler, et al. Informational [Page 4] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 3. pollution data, such as gases (sulfur dioxide, nitrogen oxide, + carbon monoxide, ozone), heavy metals (e.g., mercury), pH, + radioactivity, etc.; + + 4. 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). + +3.1.2. Actuators + + 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. + + + + + + +Dohler, et al. Informational [Page 5] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +3.1.3. Routers + + Routers generally act to close coverage and routing gaps within the + interior of the U-LLN; examples of their use are: + + 1. prolong the U-LLN's lifetime, + + 2. balance nodes' energy depletion, and + + 3. 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). + +3.2. Topology + + 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. + + + + + + + +Dohler, et al. Informational [Page 6] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +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. non-rechargeable battery; + + 2. rechargeable battery with regular recharging (e.g., sunlight); + + 3. rechargeable battery with irregular recharging (e.g., + opportunistic energy scavenging); + + 4. capacitive/inductive energy provision (e.g., passive Radio + Frequency IDentification (RFID)); + + 5. 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. + +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 MAC (Medium Access Control) (e.g., + collision); + + 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. + + + + +Dohler, et al. Informational [Page 7] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + +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 6, this section lists a few typical but not + exhaustive deployment problems and usage cases of U-LLN. + +4.1. Deployment of Nodes + + 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. + + + + + + +Dohler, et al. Informational [Page 8] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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 [Lu2007], + 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. + +4.2. Association and Disassociation/Disappearance of Nodes + + 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. + +4.3. Regular Measurement Reporting + + 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 + + + +Dohler, et al. Informational [Page 9] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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 energy from sunlight. + +4.4. Queried Measurement Reporting + + 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. + + + +Dohler, et al. Informational [Page 10] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +4.5. Alert Reporting + + 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. + +5. Traffic Pattern + + Unlike traditional ad hoc networks, the information flow in U-LLNs is + highly directional. There are three main flows to be distinguished: + + 1. sensed information from the sensing nodes to applications outside + the U-LLN, going through one or a subset of the LBR(s); + + 2. query requests from applications outside the U-LLN, going through + the LBR(s) towards the sensing nodes; + + 3. 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 + + + +Dohler, et al. Informational [Page 11] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + + + + + + +Dohler, et al. Informational [Page 12] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +6. Requirements of Urban-LLN Applications + + 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. + +6.1. 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 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. + +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 energy-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). + + + + + +Dohler, et al. Informational [Page 13] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + +6.3. Support of Autonomous and Alien Configuration + + 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 + + + + + + +Dohler, et al. Informational [Page 14] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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). + +6.4. Support of Highly Directed Information Flows + + As pointed out in Section 4.3, 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 + 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. + +6.5. Support of Multicast and Anycast + + 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 [ROLL-HOME]. + + 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 + + + + +Dohler, et al. Informational [Page 15] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + network may support the ability to interact with another network + using a different protocol, for example, by supporting route + redistribution. + +6.6. Network Dynamicity + + 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. + +6.7. Latency + + 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). + +7. Security Considerations + + 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 + + + +Dohler, et al. Informational [Page 16] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + + + + + +Dohler, et al. Informational [Page 17] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + 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. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +8.2. Informative References + + [Lu2007] Lu, JL., Valois, F., Barthel, D., and M. Dohler, + "FISCO: A Fully Integrated Scheme of Self-Configuration + and Self-Organization for WSN", 11-15 March 2007, + pp. 3370-3375, IEEE WCNC 2007, Hong Kong, China. + + [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host + Anycasting Service", RFC 1546, November 1993. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [ROLL-BUILD] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N. + Riou, "Building Automation Routing Requirements in Low + Power and Lossy Networks", Work in Progress, + February 2009. + + [ROLL-HOME] Brandt, A. and G. Porcu, "Home Automation Routing + Requirements in Low Power and Lossy Networks", Work + in Progress, November 2008. + + + +Dohler, et al. Informational [Page 18] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + + [ROLL-INDUS] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. + Phinney, "Industrial Routing Requirements in Low Power + and Lossy Networks", Work in Progress, April 2009. + + [ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy + Networks", Work in Progress, October 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dohler, et al. Informational [Page 19] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +Appendix A. Acknowledgements + + The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and + Pasi Eronen is greatly appreciated. + +Appendix B. Contributors + + 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 + + + + + + + + + + + + + + + + + + + +Dohler, et al. Informational [Page 20] + +RFC 5548 Routing Requirements for U-LLNs May 2009 + + +Authors' Addresses + + Mischa Dohler (editor) + CTTC + Parc Mediterrani de la Tecnologia + Av. Canal Olimpic S/N + 08860 Castelldefels, Barcelona + Spain + + EMail: mischa.dohler@cttc.es + + + Thomas Watteyne (editor) + Berkeley Sensor & Actuator Center, University of California, Berkeley + 497 Cory Hall #1774 + Berkeley, CA 94720-1774 + USA + + EMail: watteyne@eecs.berkeley.edu + + + Tim Winter (editor) + Eka Systems + 20201 Century Blvd. Suite 250 + Germantown, MD 20874 + USA + + EMail: wintert@acm.org + + + Dominique Barthel (editor) + France Telecom R&D + 28 Chemin du Vieux Chene + 38243 Meylan Cedex + France + + EMail: Dominique.Barthel@orange-ftgroup.com + + + + + + + + + + + + + + +Dohler, et al. Informational [Page 21] + |