RFC 5548
Routing Requirements for Urban Low-Power and Lossy Networks
RFC 5548: Routing Requirements for Urban Low-Power and Lossy Networks 🌸
okay bestie, this is RFC 5548 🎀 and it's an Informational doc (so, a "here's what we learned" doc, not a standard) from the Network Working Group, dated May 2009. the editors are M. Dohler (CTTC), T. Watteyne (BSAC, UC Berkeley), T. Winter (Eka Systems) and D. Barthel (France Telecom R&D) 💅 it doesn't obsolete or update any other RFC, since the header doesn't list any.
Here's the full thing, with the Table of Contents first:
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 2009Status of This Memo 🍓
this memo is just info for the Internet community. it doesn't specify an Internet standard of any kind, and you're free to distribute it as much as you want 🦋
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 read those carefully, because they spell out your rights and restrictions for this doc 🫶
Abstract ✨
okay so the big idea is this: we're putting application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) on paper 🏙️ in the near future, sensing and actuating nodes are going to live outdoors in cities. the goal is to improve people's living conditions and to monitor compliance with increasingly strict environmental laws 🌈
these field nodes are expected to measure and report a wide gamut of data. think the stuff needed for smart-metering apps, or apps that track meteorological, pollution, and allergy conditions 🌸 most of these nodes will talk wirelessly over links like IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth). the radio range is limited and there are tons of nodes, so you NEED suitable routing protocols, and that's the main headache here 😭
the design is mainly shaped by how little the nodes have (memory, processing power, battery, etc.) and by the particular vibes of outdoor urban scenarios 🌆 so for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocols ought to be energy-efficient, scalable, and autonomous ⚡ this document aims to specify a set of IPv6 routing requirements that reflect all of that and the other tailored characteristics of U-LLNs 💜
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 .........................................201. Introduction 🎀
this doc details application-specific IPv6 routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) 🏙️ quick note: it sticks to strict compliance with the layered IP architecture, which is very much the vibe we want. we'll go through the U-LLN use cases and the routing protocol requirements that go with them 💅
here's the roadmap:
Section 2 defines terminology useful for describing U-LLNs 📚
Section 3 gives you an overview of U-LLN applications ✨
Section 4 covers a few typical use cases for U-LLN applications, showing deployment problems and the related routing issues 🔍
Section 5 describes the traffic flows that will be typical for U-LLN applications 🌊
Section 6 talks about the routing requirements for networks made of 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 gives an overview of routing security considerations for U-LLN implementations 🔐
2. Terminology 📚
the terminology here is consistent with, and builds on, what's in "Terminology in Low power And Lossy Networks" [ROLL-TERM] 🧠 this doc extends it with the following terms:
- Anycast: an 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 a routing protocol's ability to function independently without needing any external influence or guidance. it includes self-configuration and self-organization capabilities 🤖
- DoS: Denial of Service, a class of attack that tries to cause resource exhaustion to the detriment of a node or network 💀
- ISM band: Industrial, Scientific, and Medical band. it's 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 💅
okay so here's the important bit about the key words. 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] 📖 bestie, read those carefully, they're literally the rules of the game 👑
3. Overview of Urban Low-Power and Lossy Networks 🌆
3.1. Canonical Network Elements 🧚♀️
a U-LLN is understood to be a network made of three key elements, i.e.,
- sensors,
- actuators, and
- routers
and they all talk wirelessly 📶 the next sections (3.1.1, 3.1.2, and 3.1.3) are there to show the functional nature of a sensor, an actuator, and a router in this context. that said, these functionalities are not exclusive! a single device can act as a simple router, or it can be a router with a sensing functionality too. in that second case, it'll be treated 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:
- 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, nitrogen oxide, carbon monoxide, 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 apps that usually gather the measurement data and send it to data collection and processing apps on other node(s), often outside the U-LLN 📊
sensor nodes are capable of forwarding data 🔁 they're generally not mobile in the majority of near-future roll-outs 🧘 and in lots of anticipated roll-outs, they may suffer from long-term resource constraints 🪫
the main example is a "smart grid" app: a city-wide network of smart meters and distribution monitoring sensors ⚡ smart meters in an urban "smart grid" app will include electric, gas, and/or water meters, usually run by one or several utility companies 🏢 these meters can do advanced sensing, like measuring the quality of the electrical service a customer gets, providing granular interval data, or automating the detection of alarm conditions 🚨 they may also do advanced interactive stuff that calls on an actuator component, like remote service disconnect or remote demand reset 🔌 more advanced scenarios include demand response systems for managing peak load, and distribution automation systems that monitor the infrastructure delivering energy around the city 🌃 sensor nodes that can provide this kind of functionality may sometimes be called Advanced Metering Infrastructure (AMI) 🧾
3.1.2. Actuators 🚦
actuator nodes are capable of controlling urban devices, like street or traffic lights 🚥 they run apps that receive instructions from control apps on other nodes (possibly outside the U-LLN) 🎛️ the number of actuator points is well below the number of sensing nodes 📉 some sensing nodes may include an actuator component too, like an electric meter node with integrated support for remote service disconnect 🔧 actuators are capable of forwarding data 🔁 they're not likely to be mobile in the majority of near-future roll-outs 🪑 and actuator nodes may also suffer from long-term resource constraints, for example when they're battery powered 🔋
3.1.3. Routers 🌸
okay so routers are the ones quietly closing the coverage and routing gaps inside the U-LLN 🫶. Their main jobs 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, but the number of routers is way below the amount of sensing nodes 💅. Routers are generally not mobile, i.e., they're fixed to a random or pre-planned location 📍. Routers may, but generally do not, have any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap 💖. Routers are different from actuator and sensing nodes because they neither control nor sense 🙈. That being said, a sensing node or actuator can also be a router within the U-LLN ✨.
Some routers provide access to wider infrastructures, like the Internet, and in that context they're named Low-Power and Lossy Network Border Routers (LBRs) 🌈.
LBR nodes in particular may also run applications that talk to 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're likely to be associated with more than one network 🤯. These networks may or may not communicate with one another. The number of sensing nodes deployed in the urban environment to support some applications is expected to be in the order of 10^2 to 10^7. That's still huge and unprecedented in current roll-outs 😭.
Deployment is likely to happen in batches, e.g., boxes of hundreds to thousands of nodes arrive and get deployed 📦. The location of the nodes is random within given topological constraints, e.g., placement along a road, a river, or 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:
- 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).
For a battery-powered sensing node, the battery shelf life is usually in the order of 10 to 15 years. So trying to maximize network lifetime with battery-powered nodes beyond that lifespan is useless 🪫.
The physical and electromagnetic distances between the three key elements, i.e., sensors, actuators, and routers, can generally be very large, from several hundreds of meters to one kilometer 📏. Not every field node is likely to reach the LBR in a single hop, so suitable routing protocols are required to 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:
- 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, which causes 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 need suitable medium access control protocols that can resolve any arising contention 📻. Some available protocols may not be able to stop packets of neighboring nodes from colliding, which can lead to a high Packet Error Rate (PER) and cause a link outage 💀.
The outdoor deployment of U-LLNs also has implications for the interference temperature, and therefore link reliability and range, if Industrial, Scientific, and Medical (ISM) bands are going to be used 🌡️. For instance, if the 2.4 GHz ISM band is used for communication between U-LLN nodes, then heavily loaded Wireless Local Area Network (WLAN) hot-spots may become a detrimental performance factor. That can lead to a high PER and jeopardize the functioning of the U-LLN 🚨.
Finally, nodes appearing and disappearing cause 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 own 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 📦
Unlike other LLN applications, deployment of nodes is likely to happen in batches straight out of a box 🎁. Typically, hundreds to thousands of nodes are shipped by the manufacturer with pre-programmed functionalities, and then rolled out by a service provider or subcontracted entities 🚚. Before 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 before roll-out, all nodes are likely to be in one another's one-hop radio neighborhood. So pre-programmed Media Access Control (MAC) and routing protocols may fail to function properly, which wastes 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 need 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 with hundreds of neighboring devices 🐝. In the resulting topology, there may be regions where many (redundant) paths are possible through the network. Other regions may depend on critical links to stay connected to the rest of the network 🧵. Any proposed LLN routing protocol ought to support the autonomous self-organization and self-configuration of the network at the 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, and existing nodes may be removed from it 🚪. The former might happen because a removed node is replaced as part of maintenance, or because new nodes are added since more sensors for denser readings/actuations are needed, or because routing protocols report connectivity problems. The latter might happen because a node's battery is depleted, the node is removed for maintenance, the node is stolen or accidentally destroyed, etc. 😱
The protocol(s) should therefore be able to convey information about malfunctioning nodes that may affect or jeopardize the overall routing efficiency, so that the self-organization and self-configuration capabilities of the sensor network might be called on to facilitate the appropriate reconfiguration 🔧. This information may include, e.g., exact or relative geographical position, etc. The reconfiguration may include changes of hierarchies, routing paths, packet forwarding schedules, etc. 🗂️ Furthermore, to inform the LBR(s) of a node's arrival and association with the network, as well as to tell 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 differ, 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, since sensing outages can be observed at data collection applications. For instance, when there's no reading arriving from a given sensor or cluster of sensors within a day 👀. In this case, a query can be launched to check on the state and availability of a sensing node or sensing cluster 🔍.
It's 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 an LBR 🚦. Thus, the protocol(s) should be optimized to support a large number of unicast flows from the sensing nodes or sensing clusters towards an 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 may be 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, and heavy-tail distributions seem appropriate for modeling their behavior 📈. Queries do not necessarily need to be reported back to the same node that the query was launched from 🔁. 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're not very stringent: 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 selecting 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 also applies to schedule updates, 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 💅✨.
4.5. Alert Reporting ✨
Okay so every once in a while 🚨 the sensing nodes measure something that counts as an alarm. Each node usually decides that locally, using a threshold that was pre-programmed or handed out ahead of time. Note that as a node gets close to the alert threshold, it may want to change its sensing and reporting cycles 👀. An alarm is usually picked up by a bunch of sensing nodes at once, so sending a single alert message along with where it started is enough in most cases, but not all 🙈. For example, if the level of toxic gases goes above a threshold, the sensing nodes nearby all report the danger. Another example: a recycling glass container with a sensor that measures how full it is reports that it's full and needs emptying 🍾.
Routes clearly need to be unicast (towards one LBR) or multicast (towards multiple LBRs) 🛣️. Delays and latencies matter, but for a U-LLN supporting a typical application, deliveries within seconds should suffice in most cases 💅.
5. Traffic Pattern 🦋
Unlike traditional ad hoc networks, information in U-LLNs flows in one super clear direction 💖. There are three main flows you need to know about:
- 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 to deliver acknowledgements. And eventually, some direct information flows between field devices without LBRs may happen too ✨.
Sensed data is usually super correlated in space, time, and observed events. An example of the last one is when temperature goes up and humidity goes down as the day starts ☀️. Data may be sensed and delivered at different rates, and both rates are usually pretty low, like minutes, hours, days, etc. Data may be delivered on a schedule or a regular query. It may also come in irregularly after an externally triggered query, or get triggered by a sudden network-internal event or alert 🔔. Schedules could be driven by, for example, a smart-metering app where data is expected every hour, or an environmental monitoring app where a battery-powered node reports its status at a specific time once a day 🔋. Data delivery may trigger acknowledgements or maintenance traffic going the other way. So the network needs to be able to adjust to varying activity duty cycles, as well as periodic and sporadic traffic 💫. Also, sensed data ought to be secured and locatable 🔐.
Some data delivery has tight latency requirements. Think of a live meter reading for customer service in a smart-metering app, or a case where a sensor reading response has to arrive within a certain time to be useful ⏱️. The network should take into consideration that different application traffic may require different priorities when choosing a route through 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), like system-wide alerts. In the example of an AMI U-LLN, that could happen in response to something like a city-wide power outage ⚡. Then all powered devices in a large segment of the network may have lost power and be running off a temporary "last gasp" source, like a capacitor or small battery 😱. A node must be able to send its own alerts toward an LBR while still forwarding traffic for other devices that are also in 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, like a home network. For example, an AMI app that runs 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 telling a customer about incentives to reduce demand during peaks, or automatically adjusting the thermostat of customers who signed up for such a demand management program 🌡️. Later traffic may flow back through the U-LLN to the utility 🔄.
6. Requirements of Urban-LLN Applications 💼
Urban Low-Power and Lossy Network apps have a bunch of specific requirements related to their operating conditions, as we've seen in the previous sections 🧠.
6.1. Scalability 📈
The large and diverse measurement space of U-LLN nodes, coupled with typically huge urban areas, is going to yield extremely large network sizes 🏙️. Current urban roll-outs sometimes have more than one hundred nodes. Future roll-outs, however, may easily reach numbers in the tens of thousands to millions. One of the most important LLN routing protocol design criteria is therefore 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 maintaining a routing path may not be as important as another node's. Energy-scavenging methods may recharge the battery at regular or irregular intervals. Some nodes may have a constant power source. Some nodes may have larger memory and are hence 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.) were 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 decisions. For the sake of example, such a capability could be related to the node capability itself (e.g., remaining power) or to 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 things like data aggregation, may imply some mechanisms to mark or tag the traffic for the 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) together with the anycast endpoints and packet marking to route the traffic 🍓.
6.3. Support of Autonomous and Alien Configuration 🤖
With a large number of nodes, manually configuring and troubleshooting each node is not efficient at all 🙃. The scale and the large number of possible topologies that may show up in the U-LLN encourage automated management capabilities that may (partly) rely on self-organizing techniques. The network is expected to self-organize and self-configure according to prior defined rules and protocols, and to support externally triggered configurations (for instance, through a commissioning tool that may help organize 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 an LBR. This follows 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 a 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 💖
Okay bestie, so routing protocols running in urban sensor networks MUST support three delivery styles 🦋. Unicast is one message to one field device, very personal. Multicast sends traffic to a whole squad of devices that all signed up for the same multicast group. Anycast is where several field devices are set up to accept traffic sent to a single IP anycast address 🧚.
Supporting unicast, multicast, and anycast also has implications for the addressing scheme 🙈. That's a whole other tea, though, and this doc is focused on routing requirements, so we're leaving it there 💅.
Some urban sensing setups might want to address a group of nodes on the same subnet without making a multicast group first, or have one node stand in for a whole group 🫠. These schemes, where a sender builds an addressable group of receivers, are not currently supported by IPv6, and this spec won't go further into them [ROLL-HOME].
The network SHOULD support internetworking when identical protocols are used 🌸. While it's doing that, it has to give real attention to routing security implications, like when a home network links up with a utility U-LLN 🏠. The network may also support talking to another network that uses a different protocol, for example by supporting route redistribution ✨.
6.6. Network Dynamicity 🌈
Mobility is assumed to be low in urban LLNs, but network dynamicity is still not negligible 👀. That comes from nodes associating, disassociating, and disappearing, plus long-term link perturbations. All of this affects how quickly reorganization and reconfiguration converge, and how quickly routing protocol convergence happens too.
So here's the vibe: local network dynamics SHOULD NOT impact the entire network, meaning it shouldn't have to be reorganized or re-reconfigured 🙅♀️. Instead, the network SHOULD be locally optimized to deal with the changes it runs into 🧩. The routing protocol(s) SHOULD support appropriate mechanisms to be informed of the association, disassociation, and disappearance of nodes 📣. They SHOULD also support appropriate updating mechanisms so they hear about changes in connectivity 🔔. And they SHOULD use that info to kick off protocol-specific mechanisms for reorganization and reconfiguration as necessary, so overall routing efficiency stays strong 💪. Convergence and route establishment times SHOULD be significantly lower than the smallest reporting interval ⏱️.
Differentiation SHOULD be made between node disappearance 👻, where the node vanishes without any prior notification, and user- or node-initiated disassociation (aka "phased-out") 🌅, where the node has enough time to tell the network about its pending removal. Those are two very different plot twists, bestie 📖.
6.7. Latency ⏳
With the exception of alert-reporting solutions and, to a certain extent, queried reporting, U-LLNs are delay tolerant 🐢. That's as long as the information arrives within a fraction of the smallest reporting interval. For example, a few seconds is fine if reporting happens every 4 hours 🕓.
The routing protocol(s) SHOULD also support the ability to route according to different metrics, and latency could be one of those metrics 🏎️.
7. Security Considerations 🔒😱
Okay, this section is serious, so buckle up 🎢. Like every network, U-LLNs are exposed to routing security threats that need to be addressed 🚨. The wireless and distributed nature of these networks widens the range of potential routing security threats. It gets worse because the nodes are resource constrained, which keeps resource-intensive routing security approaches from being deployed 🥲. A viable routing security approach SHOULD be sufficiently lightweight that it can be implemented across all nodes in a U-LLN 🪶. These issues need special attention during the design process so the deployment stays commercially attractive 💸.
The U-LLN MUST deny any node that has not been authenticated to the U-LLN and authorized to take part in the routing decision process 🚫. No mystery guests allowed 🙅♀️.
An attacker SHOULD be prevented from manipulating or disabling the routing function, for example by compromising routing control messages 🕵️♀️. To stop that, the routing protocol(s) MUST support message integrity 🔐.
There are more routing security issues to watch out for too 😬. Some nodes might act egoistic, like not obeying network rules or forwarding no packets or false ones. Denial-of-service (DoS) attacks are another big worry, along with malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, and more. The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently make the routing protocol mechanisms over-consume the limited resources of LLN nodes 🫠. That includes things like constructing forwarding loops or causing excessive routing protocol overhead traffic 🌀.
Self-configuration and self-organization are super desirable in a U-LLN, but they bring extra routing security considerations 🤯. Mechanisms MUST be in place to deny any node that tries to take malicious advantage of those procedures 🚷. Attacks might try to cause DoS, drain the energy of power-constrained devices, or hijack the routing mechanism 🔋💀. A node MUST authenticate itself to a trusted node that is already associated with the U-LLN before it can take part in self-configuration or self-organization 🪪. And 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 it isn't vulnerable to DoS 🧯.
U-LLN nodes have low computation power and scarce energy, so they may not be able to resist every attack from high-power malicious nodes, like laptops and strong radios 💻📡. Even so, the amount of damage done to the whole network SHOULD be commensurate with the number of nodes physically compromised 📏. For example, an intruder who takes control of 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 💅. That implementation ought to include defense against things like eavesdropping, replay, message insertion, modification, and man-in-the-middle attacks 👀.
The routing security solutions you pick will affect the routing protocol(s) 🧠. So routing protocol(s) proposed for 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.
[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.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.comAuthors' 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📦 where this page comes from
- ietf: rfc5548 2009-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms