RFC 6551
Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
RFC 6551 💖 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks ✨
okay bestie, this one is the RFC that gives RPL its routing metrics, so the way routers pick paths in those tiny, battery-powered, flaky LLN networks 🧚 It's a Standards Track doc from March 2012, ISSN 2070-1721 🔥
The authors are JP. Vasseur, Ed. (Cisco Systems), M. Kim, Ed. (Corporate Technology Group, KT), K. Pister (Dust Networks), N. Dejean (Elster SAS), and D. Barthel (France Telecom Orange). The "Ed." means they're the editors who pulled the whole thing together 💅
Abstract ✨
LLNs are not like regular wired networks or ad hoc networks, so they need brand new routing metrics and constraints 🌈 Typical IGP metrics just count hops or look at link metrics, which is not enough for LLNs. This doc lays out a set of link and node routing metrics and constraints built for LLNs, meant to be used by RPL (the Routing Protocol for Low-Power and Lossy Networks) 🦋
Status of This Memo 📜
This is an Internet Standards Track document 💜
It's a product of the Internet Engineering Task Force (IETF) 🌸 It represents the consensus of the IETF community, it got public review, and it was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 🫶
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6551 🎀
Copyright Notice 🌸
Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents carefully, because they describe your rights and restrictions for this document 👀
Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They are provided without warranty, as described in the Simplified BSD License. 💀
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Requirements Language ......................................6
2. Object Formats ..................................................7
2.1. DAG Metric Container Format ................................7
2.2. Use of Multiple DAG Metric Containers .....................10
2.3. Metric Usage ..............................................10
3. Node Metric/Constraint Objects .................................11
3.1. Node State and Attribute Object ...........................11
3.2. Node Energy Object ........................................12
3.3. Hop Count Object ..........................................16
4. Link Metric/Constraint Objects .................................17
4.1. Throughput ................................................17
4.2. Latency ...................................................18
4.3. Link Reliability ..........................................19
4.3.1. The Link Quality Level Reliability Metric ..........19
4.3.2. The ETX Reliability Object .........................21
4.4. Link Color Object .........................................22
4.4.1. Link Color Object Description ......................22
4.4.2. Mode of Operation ..................................24
5. Computation of Dynamic Metrics and Attributes ..................24
6. IANA Considerations ............................................25
6.1. Routing Metric/Constraint Type ............................25
6.2. Routing Metric/Constraint TLVs ............................25
6.3. Routing Metric/Constraint Common Header Flag Field ........26
6.4. Routing Metric/Constraint Common Header A Field ...........26
6.5. NSA Object Flags Field ....................................26
6.6. Hop-Count Object Flags Field ..............................27
6.7. Node Type Field ...........................................27
7. Security Considerations ........................................27
8. Acknowledgements ...............................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................281. Introduction 🧚✨
okay so bestie, this doc is using the terminology from [ROLL-TERMS] 📖 no cap, so if a word feels new, check there first 💅
Low-power and Lossy Networks (LLNs) have their own routing vibe compared to regular wired or ad hoc networks. Those differences are spelled out in [RFC5548], [RFC5673], [RFC5826], and [RFC5867] 🦋
Historically, IGPs like OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics 🌸 Other stuff, like Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]), uses other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). It's giving "pick the best route while following the rules" energy 👑
This document specifies routing metrics and constraints that get used in path calculation by the Routing Protocol for Low-Power and Lossy Networks (RPL) from [RFC6550] 🎀
One of the prime objectives here is to make a flexible way to advertise the routing metrics and constraints RPL uses ✨ Some RPL implementations might go super simple with a single metric and no constraint, while others might use a bigger set of link and node routing metrics and constraints 💖 This spec gives you a lot of flexibility plus a set of routing metrics and constraints. New ones could be defined in the future, as needed 🌈
The metrics and constraints in this document are carried in objects that are OPTIONAL from the point of view of a RPL implementation. So implementations are free to include different subsets of the functions (metric, constraint) defined here 🫶 Specific sets of metrics and constraints, plus other optional RPL parameters for key environments, will be specified as compliance profiles in applicability profile documents from the ROLL working group 🍓 Also, RPL can even run with no metric at all, like using the Objective Function from [RFC6552] 💅
RPL is a distance vector routing protocol variant that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints 🦋 The DAG formation rules are defined in [RFC6550]:
- The Destination-Oriented Directed Acyclic Graph (DODAG) root, as defined in [RFC6550], may advertise a routing constraint that's used as a "filter" to prune links and nodes that don't meet specific properties 🚫 For example, a path might be required to only go through nodes that are mains-powered, or links with at least a minimum reliability, or a specific "color" reflecting a user-defined link characteristic (e.g., the link layer supports encryption) 🔐
- A routing metric is a quantitative value used to evaluate the path cost. Link and node metrics are usually (but not always) additive 🧮
The best path is the one that satisfies all supplied constraints (if any) and has the lowest cost with respect to some specified metrics 👑 It's also called the shortest constrained path (in the presence of constraints) 🛤️
Routing metrics can be categorized by these characteristics:
- Link versus node metrics
- Qualitative versus quantitative
- Dynamic versus static
The routing requirements documents (see [RFC5673], [RFC5826], [RFC5548], and [RFC5867]) observe that it must be possible to take into account a variety of node constraints/metrics during path computation 🙌
Some link or node characteristics (e.g., link reliability, remaining energy on the node) may be used by RPL either as routing constraints or as metrics (or sometimes both) ✨ For example, the path might be computed to avoid links that don't provide a sufficient level of reliability (use as a constraint), or it might be computed as the path offering the most links with a specified reliability level (use as a metric) 🔋 This document gives you the flexibility to use link and node characteristics as constraints and/or metrics 💜
Using link and node routing metrics and constraints isn't exclusive, so it's possible to advertise a "hop count" both as a metric to optimize the computed path and as a constraint (e.g., "Path should not exceed n hops") 🧠
Links in an LLN commonly have rapidly changing node and link characteristics, so routing metrics must be dynamic 😭 Techniques must also be used to smooth out the dynamicity of these metrics so routing oscillations get avoided 🌊 For instance, on top of the dynamic nature of some links (e.g., wireless but also Power Line Communication (PLC) links), nodes' resources like residual energy are changing continuously and may have to be taken into account during path computation ⚡
It must be noted that dynamic metrics aren't new 🕰️ They were experimented with in ARPANET 2 (see [Zinky1989]). Using dynamic metrics isn't trivial, so great care must be given to them, since they may lead to potential routing instabilities 🙈 That being said, a lot of experience has been gained over the years with dynamic routing metrics, which have been deployed in a number of (non-IP) networks 🧡
Very careful attention must be given to the pace at which routing metrics and attribute values change, so routing stability is preserved 🫧 When using a dynamic routing metric, a RPL implementation should use a multi-threshold scheme rather than fine granular metric updates that reflect each individual change, so spurious and unnecessary routing changes get avoided 🎯
The requirements on reporting frequency may differ among metrics, so different reporting rates may be used for each metric ⏱️
The set of routing metrics and constraints used by a RPL deployment is signaled along the DAG that's built according to the Objective Function (rules governing how to build a DAG) 🌳 The routing metrics and constraints are advertised in the DODAG Information Object (DIO) message specified in [RFC6550] 📣 RPL may be used to build DAGs with different characteristics 🌟 For example, it might be desirable to build a DAG with the goal of maximizing reliability by using the link reliability metric to compute the "best" path 🛡️ Another example is using the energy node characteristic (e.g., mains-powered versus battery-operated) as a node constraint when building the DAG, so battery-powered nodes get avoided in the DAG while the link throughput gets optimized 🔌
The specification of Objective Functions used to compute the DAG built by RPL is out of scope for this document 🙅♀️ This document defines routing metrics and constraints that are decoupled from the Objective Function. So a generic Objective Function could, for example, specify the rules to select the best parents in the DAG, the number of backup parents, and so on, and it could be used with any routing metrics and/or constraints like the ones specified in this document 🧩
Some metrics are either aggregated or recorded 📊 An aggregated metric gets adjusted as the DIO message travels along the DAG. For example, if the metric is the number of hops, each node updates the path cost to reflect the number of hops traversed along the DAG 🐾 A recorded metric is different: each node adds a sub-object reflecting its local valuation of the metric 📝 For example, it might be desirable to record the link quality level along a path, so each visited node adds a sub-object recording its local link quality level 🔗 To limit the number of sub-objects, a counter may be desirable (e.g., record the number of links with a certain link quality level), which compresses the information to reduce the message length 🗜️ Upon receiving the DIO message from a set of parents, a node might decide, according to the OF and local policy, which node to choose as a parent, based on the maximum number of links with a specific link reliability level for example 🏆
The routing metrics and constraints specified in this document aren't specific to any particular link layer 🌐 An internal API between the Medium Access Control (MAC) layer and RPL may be used to accurately reflect the metric values of the link (wireless, wired, PLC) 📡
Since a set of metrics and constraints will be used for links and nodes in an LLN, it is critical to ensure consistent metric calculation mechanisms are used for all links and nodes in the network, similar to the case of inter-domain IP routing 🚨
There are many different permutations of options that may be appropriate in different deployments 🎀 Implementations must clearly state which options they include, and they must state which are default and which are configurable as options within the implementation 📋 Applicability statements will be developed within the ROLL working group to clarify which options are applicable to the specific deployment scenarios indicated by [RFC5673], [RFC5826], [RFC5548], and [RFC5867] 🗺️
1.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] 🫶
2. Object Formats ✨
2.1. DAG Metric Container Format ✨
okay so routing metrics and constraints ride along inside the DAG Metric Container object from [RFC6550] 💅 and if there are multiple metrics and/or constraints in there, an Objective Function is what decides how they get used to pick the "best" path 🧚
the Routing Metric/Constraint objects are each one metric or one constraint of a specific type 🦋 they can show up in any order in the DAG Metric Container (that part's specified in [RFC6550]) and they all share the same vibe: one or more bytes that start with a common header 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Routing Metric/Constraint Object Generic Format
the object body carries one or more sub-objects that we'll get to later in this doc 🌸 and an object is allowed to carry a TLV, which can itself hold other TLVs. a TLV sitting inside a TLV gets called a TLV in this specification, which is a very "it's TLVs all the way down" moment 😭
Routing-MC-Type(Routing Metric/Constraint Type - 8 bits): this uniquely identifies each Routing Metric/Constraint object, and IANA is the one managing it 👑Length(8 bits): this tells you the length of the object body, in bytes. it goes from 0 to 255 💜
Res Flags field (16 bits): the Flag field of the Routing Metric/Constraint object is managed by IANA. any unassigned bits count as reserved, and they MUST be set to zero on transmission and MUST be ignored on receipt 🫶
these are the bits of the Routing Metric/Constraint Flag field that are currently defined, and they are giving main character energy 🔥
'P'flag: the P field is only used for recorded metrics. when it's cleared, every node along the path successfully recorded the metric 🍓 when it's set, that means one or several nodes along the path couldn't record the metric of interest (either because they didn't know it, or because policy said nope) 💀'C'flag: when it's set, the object is talking about a routing constraint. when it's cleared, the object is talking about a routing metric ✨'O'flag: the O flag is used exclusively for routing constraints (the 'C' flag is set). when it's set, the constraint in the body is optional. when it's cleared, the constraint is mandatory. if the 'C' flag is zero, the 'O' flag MUST be set to zero on transmission and ignored on reception 🙈'R'flag: the R flag only matters for a routing metric (C=0), and it MUST be cleared for C=1. when it's set, the routing metric is recorded along the path. when it's cleared, the routing metric is aggregated instead 🌈
A field (3 bits): the A field only matters for metrics, and it tells you whether the aggregated routing metric is additive, multiplicative, reports a maximum, or reports a minimum 🦋
- A=0: the routing metric is additive
- A=1: the routing metric reports a maximum
- A=2: the routing metric reports a minimum
- A=3: the routing metric is multiplicative
the A field has zero meaning when the 'C' flag is set (aka when the object is a routing constraint), and it's only valid when the 'R' bit is cleared. otherwise, the A field MUST be set to 0 and MUST be ignored on receipt. not me being picky, but this is a rule 🥹
Prec field (4 bits): the Prec field tells you how important this Routing Metric/Constraint object is compared to the others in the container 💖 this is super useful when a DAG Metric Container has several Routing Metric objects. the value goes from 0 to 15, and 0 means the highest precedence 👑
Example 1: a DAG formed by RPL where all nodes must be mains-powered and the best path is the one with the lower aggregated expected transmission count (ETX). the DAG Metric Container carries two Routing Metric/Constraint objects. the first is an ETX metric object with the header(C=0, O=0, A=00, R=0), and the second is a Node Energy constraint object with the header(C=1, O=0, A=00, R=0). a RPL Instance may use the metric object to report a maximum (A=1) or a minimum (A=2) 🫠 say the best path is the one that avoids low quality links. then the path metric reports a maximum (A=1), since the higher the ETX, the lower the link quality. when a node processes the DIO message that reports the link quality metric (ETX), each node that picks the advertising node as a parent updates the value in the metric object by swapping in its local link ETX value if and only if that local value is higher 🔥 as for the constraint, the object body carries a Node Energy constraint object (defined in Section 3.1) saying nodes must be mains-powered. if the constraint signaled in the DIO message isn't satisfied, the advertising node simply doesn't get picked as a parent by the node processing the DIO message 🙅♀️
Example 2: a DAG formed by RPL where the link metric is the link quality level (defined in Section 4), and link quality levels must be recorded along the path. the DAG Metric Container carries one Routing Metric/Constraint object, the link quality level metric (C=0, O=0, A=00, R=1), which contains multiple sub-objects 🧚
a Routing Metric/Constraint object may also include one or more additional type-length-value (TLV) encoded data sets. every Routing Metric/Constraint TLV has the same structure:
Type: 1 byte
Length: 1 byte
Value: variableso a Routing Metric/Constraint TLV is 1 byte for the type, 1 byte for the TLV length, and then a value field. the TLV length tells you how long the value field is, in bytes (0 to 255) 🎀
unrecognized TLVs MUST be silently ignored, but they still get propagated in DIOs generated by the receiving node. that's a very mature energy 🫶
IANA manages the codepoints for all TLVs carried in routing constraint/metric objects 👑 and the IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 6 💅
2.2. Use of Multiple DAG Metric Containers ✨
okay so the length of RPL options is encoded using 1 octet, which means they can't go past 255 bytes, and that goes for the DAG Metric Container too 😭 for the vast majority of cases, the advertised routing metrics and constraints won't need that much room 🌸 but there could be situations where more space is needed, like if a bunch of routing metrics get recorded along a really long path. so to avoid overflow, as specified in [RFC6550], the routing metrics get carried in multiple DAG Metric Container objects 🦋
for the rest of this document, multiple DAG Metric Container objects get treated as if they were just one long DAG Metric Container object. iconic, honestly 💖
2.3. Metric Usage ✨
when the DAG Metric Container has a single aggregated metric (a scalar value), the order relation for picking the best path is implied by the metric type. for example, lower is better for Hop Count, Link Latency, and ETX 🍓 but for Node Energy or Throughput, higher is better 🌈
here's an example of optimizing routing for node energy: the Node Energy metric (E_E field, defined in Section 3.2) gets aggregated along paths with an explicit min function (A field), and the best path is picked through an implied Max function because the metric is Energy. it's giving logic, bestie 🧠
when the DAG Metric Container has several aggregated metrics, they get used as tiebreakers according to their precedence, which is set by their Prec field values 👑
an example of that is: Hop Count as the primary criterion, Link Quality Level (LQL) as the secondary criterion, and Node Energy as the ultimate tiebreaker. in that case, the Prec fields of the Hop Count, LQL, and Node Energy metric objects should have strictly increasing values, like 0, 1, and 2 respectively 🫶
if several aggregated metrics happen to have the same Prec value, the behavior is implementation dependent. so that's on whoever built it 🙈
3. Node Metric/Constraint Objects 🧚
okay so Sections 3 and 4 specify several link and node metric/constraint objects 🌸 in some cases it's stated that there must not be more than one object of a specific type. in that case, if a RPL implementation receives more than one object of that type, the second object MUST silently be ignored 💀
in the presence of a constraint, a node MUST include a metric of the same type 💅 that metric is what gets used to check whether or not the constraint is met. and in all cases, a node MUST not change the content of the constraint 🔒
3.1. Node State and Attribute Object ✨
Okay so the Node State and Attribute (NSA) object is how we tell the network about a node's characteristics 🦋
The NSA object MAY be present in the DAG Metric Container. There MUST NOT be more than one NSA object as a constraint per DAG Metric Container, and there MUST NOT be more than one NSA object as a metric per DAG Metric Container. Keep it to one of each, bestie 💅
The NSA object can also carry a set of TLVs for describing various node characteristics. No TLV is currently defined, so that's a blank canvas for the future 🎀
IANA has assigned the NSA Routing Metric/Constraint Type the value 1 🔢
Here's what the NSA object body looks like:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 2: NSA Object Body FormatThe Res field (8 bits) is reserved, so it MUST be set to zero on transmission and MUST be ignored on receipt. Don't touch it, no cap 🙅♀️
Now the Flags field (8 bits) 🚩 Only two bits are defined right now:
- 'A' flag, data Aggregation Attribute 🌊: Data aggregation is listed as a requirement in Section 6.2 of [RFC5548]. Some apps may use the aggregation node attribute in their routing decisions to cut down on network traffic, which can stretch out the lifetime of battery-operated environments. Apps where highly directional data flow shows up regularly can make good use of data aggregation supported routing. When this bit is set, it means the node can act as a traffic aggregator. Further documents MAY define optional TLVs to describe the node traffic aggregator functionality.
- 'O' flag, overload 🥵: Node workload can be hard to pin down and express as a scalar, but it's still a super useful metric during path calculation, especially when queuing delays need to be minimized for really sensitive traffic, considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory, or any other node-related conditions. A simple 1-bit flag gives you enough granularity, kind of like the "overload" bit in routing protocols such as IS-IS. The algorithms for setting the overload bit and for computing paths that avoid overloaded nodes are outside the scope of this document, but it is RECOMMENDED to avoid frequent changes of this bit to avoid routing oscillations. When set, it means the node is overloaded and may not be able to process traffic 😩
Any unspecified flag fields MUST be set to zero on transmission and MUST be ignored on receipt. Basically: zeros going out, ignore on the way in 🫶
The Flags field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered reserved 🔒
3.2. Node Energy Object
Sometimes you really don't want to pick a node with low residual energy as a router, so constraint-based routing is needed 🔋 In those cases, the routing protocol engine may compute a longer path (constraint based) for some traffic so the network lasts longer. It's giving patience 🐢
Power and energy are seriously the critical resources in most LLNs, and there's still no simple abstraction that fully covers the huge range of power sources and energy storage devices in existing LLN nodes 😭 We're talking mains-powered, primary batteries, energy scavengers, and a whole mix of secondary storage. Scavengers can be unreliable but steady low-level power, like what you get from a 4-20 mA loop 🌱. They can be reliable but periodic, like a well-positioned solar cell ☀️. Or they can be totally unpredictable, like a vibrational energy scavenger on an intermittently powered pump 🫠 Routes that are viable when the sun is shining may disappear at night 🌙, and a pump turning on may connect two sections of a network that were previously disconnected 💧
Storage systems like rechargeable batteries often take real damage if they're regularly run down to full discharge. That means the residual energy numbers can differ between regular operation and emergency operation 🚨 A route for emergency traffic may have a different optimum than one for regular reporting.
Batteries used in LLNs often degrade a lot if their average current consumption goes over a small fraction of the peak current they can deliver ⚡ Self-supporting nodes often mix primary storage, energy scavenging, and secondary storage, which gives you three different acceptable average current values depending on the timeframe you're looking at: milliseconds, seconds, and hours/years ⏱️
Raw power and energy values are meaningless without knowing the energy cost of sending and receiving packets. Lifetime estimates are also pointless without some higher-level constraint on how long a device is required to last 🙄 For example, the path that drains the battery of a node on the bed table in a month could be preferable to a route that cuts the lifetime of a node in the wall down to a decade 🛏️🧱
Trying to cover such a broad set of constraints is a lot, so this document defines two levels of fidelity for the solution 🧩
The simplest solution uses a 2-bit field to encode three types of power sources: "powered", "battery", and "scavenger". This simple approach may be enough for lots of applications 🍓
The mid-complexity solution is a single parameter that encodes the energetic happiness of both battery-powered and scavenging nodes 💜 For scavenging nodes, the 8-bit quantity is the power provided by the scavenger divided by the power consumed by the application, E_E=P_in/P_out, in units of percent. Nodes that are scavenging more power than they consume will register above 100 ✨. A good averaging period for this calculation may be related to the discharge time of the energy storage device on the node, but specifying that is out of the scope of this document. For battery-powered devices, E_E is the current expected lifetime divided by the desired minimum lifetime, in units of percent. Estimating remaining battery energy and actual power consumption can be tricky, and the specifics of this calculation are out of scope here, but two examples are shown. If the node can measure its average power consumption, E_E can be calculated as the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power: E_E=P_max/P_now. Alternatively, if the energy in the battery E_bat can be estimated and the total elapsed lifetime, t, is available, then E_E can be calculated as the total stored energy remaining versus the target energy remaining: E_E= E_bat / [E_0 (T-t)/T].
An example of an optimized route is max(min(E_E)) for all battery-operated nodes along the route, subject to the constraint that E_E>=100 for all scavengers along the route 🏆
Heads up, bestie: the estimated percentage of remaining energy in the E_E field may not be very useful when battery-powered and energy-scavenging nodes store very different amounts of energy. X% of remaining energy on a node that can store a huge amount can't easily be compared to the same X% on a node running off a tiny source of energy 🤏 That being said, in networks where nodes have similar energy storage, the percentage of remaining energy is totally useful.
The Node Energy (NE) object is used to provide information related to node energy, and it can be used as a metric or as a constraint 💖
The NE object MAY be present in the DAG Metric Container. There MUST NOT be more than one NE object as a constraint per DAG Metric Container, and there MUST NOT be more than one NE object as a metric per DAG Metric Container.
IANA has assigned the NE object Type the value 2 🎉
The NE object body looks like this:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 3: NE Sub-Object FormatAnd the NE sub-object body looks like this:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E| E_E | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 4: NE Sub-Object FormatThe NE sub-object can also carry a set of TLVs for conveying various nodes' characteristics 🧃
The Flags field (8 bits) has these flags currently defined 🚩
- I (Included) 🚪: The 'I' bit only matters when the node type is used as a constraint. For example, the path must only traverse mains-powered nodes, or battery-operated nodes must be excluded. The 'I' bit is what says inclusion versus exclusion. When set, nodes of the type specified in the node type field MUST be included. When cleared, nodes of the type specified in the node type field MUST be excluded.
- T (node Type) 🏷️: This is a 2-bit field for the node type.
T=0is a mains-powered node,T=1is a battery-powered node, andT=2is a node powered by an energy scavenger. - E (Estimation) 📊: When the 'E' bit is set for a metric, the estimated percentage of remaining energy on the node is in the E_E 8-bit field. When cleared, that percentage is not provided. When the 'E' bit is set for a constraint, the E_E field defines a threshold for inclusion or exclusion. For an inclusion, nodes with values higher than the threshold are included. For an exclusion, nodes with values lower than the threshold are excluded.
E_E (Estimated-Energy) is an 8-bit unsigned integer field giving an estimated percentage of remaining energy. The E_E field is only relevant when the 'E' flag is set, and it MUST be set to 0 when the 'E' flag is cleared 🧮
When the NE object has several sub-objects used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is decided by the 'I' bit of the first sub-object: the set starts full if that 'I' bit is an exclusion, and empty if that 'I' bit is an inclusion 🧠
No TLV is currently defined here either 🌸
Future documents may define more complex solutions with TLV parameters representing the energy storage, consumption, and generation capabilities of the node, plus the desired lifetime 🔮✨
3.3. Hop Count Object ✨
okay so the Hop Count (HP) object is the one that keeps count of how many nodes a path has gone through 🧚 bestie it's giving precise
The HP object MAY be present in the DAG Metric Container. There MUST NOT be more than one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container. 💅
The HP object may also carry a set of TLVs to share various node characteristics. No TLV is currently defined, so it's empty for now 🫶
The HP routing metric object Type has been assigned value 3 by IANA. 🎀
Here's how the Hop Count object body is laid out 👇
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Figure 5: Hop Count Object Body Format
Res flags (4 bits) are the reserved field, so this field MUST be set to zero on transmission and MUST be ignored on receipt. Reserved means hands off 🙈
No Flag is currently defined. Unassigned bits count as reserved too, so they MUST be set to zero on transmission and MUST be ignored on receipt. 🌸
The HP object can be used as a constraint or a metric, and it's giving two different vibes 🌈 As a constraint, the DAG root sets the maximum number of hops a path may traverse. Once that number is reached, no other node can join that path, so it's a hard stop 🛑 As a metric, every visited node just bumps the Hop Count field up by one ⭐
Main character rule: the first node along a path that inserts a Hop Count metric object MUST set the Hop Count field value to 1. No skipping the count, no cap 👑
4. Link Metric/Constraint Objects 🦋
4.1. Throughput 💖
Okay so many LLNs can support a huge range of throughputs 😭 For some links, this comes from variable coding. For the deeply duty-cycled links you find in lots of LLNs, the variation is basically a trade: more power consumption for a higher bit rate, or less power for a lower one. There are several MAC layer protocols where the effective bit rate of a link can swing over more than three orders of magnitude, with a matching change in power consumption. 🔥 For efficient operation, it may be a good idea for nodes to report the range of throughput their links can handle, plus the throughput that's available right now ✨
The Throughput object MAY be present in the DAG Metric Container. There MUST NOT be more than one Throughput object as a constraint per DAG Metric Container, and there MUST NOT be more than one Throughput object as a metric per DAG Metric Container. 🍓
The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub-object MUST be the most recently estimated actual throughput. How that estimate gets calculated is outside the scope of this document, so we're not going there today 🙈
Each Throughput sub-object has a fixed length of 4 bytes. 💜
The Throughput object does not contain any additional TLVs. 🎀
The Throughput object Type has been assigned value 4 by IANA. 🌷
Here's the Throughput object body 👇
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Throughput Object Body Format
And the Throughput sub-object 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Throughput Sub-Object Format
Throughput: 32 bits. It's encoded as an unsigned integer in 32 bits, and the unit is bytes per second 💅
4.2. Latency ⏱️
Similar to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a matching change in power consumption 😩 Some LLN MAC link layers let you adjust the latency globally across the subnet, link by link, or not at all. Some insist it stays fixed for a given link but let it differ from link to link 🤷♀️
The Latency object MAY be present in the DAG Metric Container. There MUST NOT be more than one Latency object as a constraint per DAG Metric Container, and there MUST NOT be more than one Latency object as a metric per DAG Metric Container. ✨
The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes. 🫧
The Latency object does not contain any additional TLVs. 💖
The Latency object Type has been assigned value 5 by IANA. 🦋
The Latency object is a metric or constraint. 🌈
Here's the Latency object body 👇
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Latency Object Body Format
And the Latency sub-object 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Latency Sub-Object Format
Latency: 32 bits. It's encoded as an unsigned integer in 32 bits, expressed in microseconds ⚡
The Latency object may be used as a constraint or a path metric. Say you want the latency to never go above some value: then the Latency object's common header marks the value as a constraint 🙅♀️ Or the Latency object can be an aggregated additive metric, where the value gets updated along the path to reflect the path's total latency 📈
4.3. Link Reliability 🛡️
In LLNs, link reliability can get worse for a bunch of reasons, like signal attenuation and interference of various kinds 📡 The timescales run from milliseconds all the way to days, and they're often periodic and tied to human activity 🕰️ Packet error rates can usually be measured directly, and other metrics (like bit error rate or mean time between failures) are typically derived from that 🧮 This variability isn't specific to wireless links either, it applies to PLC links too ⚡
A change in link quality can affect network connectivity, so link quality may be taken into account as a critical routing metric. Big deal 👑
A bunch of link reliability metrics could be defined to reflect different reliability aspects. This document defines two of them: the Link Quality Level (LQL) and the ETX Metric 💜
Note that a RPL deployment MAY use the LQL, the ETX, or both. 🌸
4.3.1. The Link Quality Level Reliability Metric 💎
The Link Quality Level (LQL) object quantifies link reliability with a discrete value from 0 to 7. 0 means the link quality level is unknown, and 1 reports the highest link quality level 🌟 The mechanisms and algorithms used to compute the LQL are implementation specific and outside the scope of this document, so that's a you-problem 😌
The LQL can be used as either a metric or a constraint. When it's used as a metric, the LQL metric can only be recorded. For example, the DAG Metric object may ask all traversed nodes to record the LQL of their incoming link into the LQL object. Each node can then use the LQL record to pick its parent based on some user-defined rules, like "select the path with most links reporting a LQL value of 3 or less" 🧠
Counters are used to compress the info: for each LQL value that shows up, only the number of matching links gets reported 📦
The LQL object MAY be present in the DAG Metric Container. There MUST NOT be more than one LQL object as a constraint per DAG Metric Container, and there MUST NOT be more than one LQL object as a metric per DAG Metric Container. 🎀
The LQL object MUST contain one or more sub-objects used to report the number of links along with their LQL. 💖
The LQL object Type has been assigned value 6 by IANA. 🦋
Here's the LQL object body 👇
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Figure 10: LQL Object Body Format
Res flags (8 bits) are the reserved field, so this field MUST be set to zero on transmission and MUST be ignored on receipt. 🙈
When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-objects. ✨
The LQL Type 1 sub-object is laid out like this 👇
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+Figure 11: LQL Type 1 Sub-Object Format
Val: the LQL value, from 0 to 7, where 0 means undetermined and 1 indicates the highest link quality 💜
Counter: the number of links with that value 🫶
4.3.2. The ETX Reliability Object
okay so ETX is the number of transmissions a node expects to make to a destination to successfully deliver one packet 📦✨ Unlike the LQL routing metric, ETX gives you a discrete value (which may not be an integer) computed with a specific formula. For example, an implementation may use ETX= 1 / (Df * Dr), where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value 🤷♀️💅
The ETX object MAY be present in the DAG Metric Container 🎀 There MUST NOT be more than one ETX object as a constraint per DAG Metric Container, and there MUST NOT be more than one ETX object as a metric per DAG Metric Container. Rules are rules, bestie 🙈
The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 16 bits 🧚
The ETX object does not contain any additional TLVs 🌸
The ETX object Type has been assigned value 7 by IANA 💜
Here's the format of the ETX object body 👀
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: ETX Object Body Format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: ETX Sub-Object Format
ETX is 16 bits 🔢 The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX = 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum, which is 65535. Math with main character energy 💖
The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some specified value. In this case, the ETX object common header indicates that the value relates to a constraint 🚧 In another example, the ETX object may be used as an aggregated additive metric where the value is updated along the path to reflect the path quality. When a node receives the aggregated additive ETX value of the path (cumulative path ETX calculated as the sum of the link ETX of all of the traversed links from the advertising node to the DAG root), and it selects that node as its preferred parent, the node updates the path ETX by adding the ETX of the local link between itself and the preferred parent to the received path cost (path ETX), before potentially advertising itself the new path ETX 🦋🔥
4.4. Link Color Object
4.4.1. Link Color Object Description
The Link Color (LC) object is an administrative 10-bit link constraint (which may be either static or dynamically adjusted) used to avoid or attract specific links for specific traffic types 🌈💅
The LC object can be used either as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. A color is defined as a specific set of bit values. In other words, that 10-bit field is a flag field, and not a scalar value 🚩 Each node can then use the LC to select the parent based on user defined rules (e.g., "select the path with the maximum number of links having their first bit set 1 (e.g., encrypted links)"). The LC object may also be used as a constraint 🔐
When used as a recorded metric, a counter is used to compress the information, where the number of links for each Link Color is reported 🧮
The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST NOT be more than one LC object as a constraint per DAG Metric Container, and there MUST NOT be more than one LC object as a metric per DAG Metric Container. There MUST be a at least one LC sub-object per LC object 🫶
The LC object does not contain any additional TLVs ✨
The LC object Type has been assigned value 8 by IANA 💜
The format of the LC object body is as follows:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Figure 14: LC Object Format
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt 🧸
When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects 📝
The format of the LC Type 1 sub-object body is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: LC Type 1 Sub-Object Format
When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects 🚦
The format of the LC Type 2 sub-object body is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: LC Type 2 Sub-Object Format
Reserved (5 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt 🫧
'I' Bit: The 'I' bit is only relevant when the Link Color is used as a constraint. When set, this indicates that links with the specified color must be included. When cleared, this indicates that links with the specified color must be excluded 🎯
It is left to the implementer to define the meaning of each bit of the 10-bit Link Color Flag field 🛠️
4.4.2. Mode of Operation
The link color may be used as a constraint or a metric 🌷
- When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path 🙅♀️
- When used as recorded metric, each node along the path may insert an LC object in the DAG Metric Container to report the color of the local link. If there is already an LC object reporting a similar color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field 🔢💖
5. Computation of Dynamic Metrics and Attributes ⏱️
As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales, and RPL controls the reporting rate 🐢
To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics is out of the scope of this document, it is RECOMMENDED to carefully design the route optimization algorithm to avoid too frequent computation of new routes upon metric value changes 🧠✨
Controlled adaptation of the routing metrics and the rate at which paths are computed are critical to avoid undesirable routing instabilities, which can result in increased latencies and packet loss because of temporary micro-loops 🌀😭 Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus potentially impacting its scalability 🔋
6. IANA Considerations 🗂️
IANA has established a new top-level registry, called "RPL Routing Metric/Constraint", to contain all Routing Metric/Constraint objects codepoints and sub-registries 🌟
The allocation policy for each new registry is by IETF review: new values are assigned through the IETF review process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant working group if one exists) 🤝
New bit numbers may be allocated only by an IETF Review action. Each bit should be tracked with the following qualities:
- Bit number
- Capability Description
- Defining RFC
6.1. Routing Metric/Constraint Type
IANA has created a sub-registry, called "Routing Metric/Constraint Type", for Routing Metric/Constraint object types, which range from 0 to 255. Value 0 is unassigned 🔢
Value Meaning Reference
1 Node State and Attribute This document
2 Node Energy This document
3 Hop Count This document
4 Link Throughput This document
5 Link Latency This document
6 Link Quality Level This document
7 Link ETX This document
8 Link Color This document6.2. Routing Metric/Constraint TLVs
IANA has created a sub-registry, called "Routing Metric/Constraint TLVs", used for all TLVs carried within Routing Metric/Constraint objects. The Type field is an 8-bit field whose value is comprised between 0 and 255. Value 0 is unassigned. The Length field is an 8-bit field whose value ranges from 0 to 255. The Value field has value ranges depending on the Type; therefore, they are not defined here, since no Type is registered at this time 🎀
6.3. Routing Metric/Constraint Common Header Flag Field
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header Flag field", to manage the 9-bit Flag field of the Routing Metric/Constraint common header 🚩
Several bits are defined for the Routing Metric/Constraint common header Flag field in this document. The following values have been assigned:
Codespace of the Flag field (Routing Metric/Constraint common header)
Bit Description Reference
8 Recorded/Aggregated This document
7 Optional Constraint This document
6 Constraint/Metric This document
5 P (Partial) This documentBits 0-4 are currently reserved 🌸
6.4. Routing Metric/Constraint Common Header A Field
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header A field", to manage the codespace of the A field of the Routing Metric/Constraint common header 💅
The A field is 3 bits in length, and it has values ranging from 0 to 7.
Codespace of the A field (Routing Metric/Constraint common header)
Value Meaning Reference
0 Routing metric is additive This document
1 Routing metric reports a maximum This document
2 Routing metric reports a minimum This document
3 Routing metric is multiplicative This document6.5. NSA Object Flags Field
okay so IANA made a sub-registry called "NSA Object Flag field" 🗂️ to manage the codespace of the 8-bit Flag field of the NSA object. it's giving organized ✨
This document defines a few bits for the NSA Object Flag field. Here's what's been assigned 💖
Codespace of the Flag field (NSA object)
Bit Description Reference
6 Aggregator This document
7 Overloaded This documentBits 0-5 are reserved 🔒 hands off, bestie 🙅♀️
6.6. Hop-Count Object Flags Field
IANA made another sub-registry, this one called "Hop-Count Object Flag field" 🧚, to manage the codespace of the 4-bit Flag field of the Hop Count object.
No Flag is currently defined 🫧 the shelf is empty for now, but it's ready for later!
6.7. Node Type Field
IANA made a sub-registry called "Node Type Field" 🔋 to manage the codespace of the field in the Routing Metric/Constraint common header.
The T field is 2 bits long, so its values run from 0 to 3 🎀
Codespace of the T field (Routing Metric/Constraint common header)
Value Description Reference
0 a mains-powered node This document
1 a battery-powered node This document
2 a node powered by an energy scavenger This document7. Security Considerations 🔐💀
okay this part is SERIOUS, bestie 😭 routing metrics have to be handled in a secure and trustful manner, no cap.
For example, RPL should not let a malicious node falsely advertise that it has good metrics for routing 🙈 so that it gets picked as the preferred next-hop router for other nodes' traffic and then intercepts their packets. Like, the villain arc is real 😤
Another attack could be making intermittent attacks on a link, trying to keep changing the link quality and, with it, the routing metric. That can cause potential fluctuation in the DODAG 🌀 which is chaotic. So it is RECOMMENDED for a RPL implementation to put mechanisms in place to stop advertising routing metrics for highly unstable links that may be subject to attacks. Protect the vibes, protect the tree 🌳
Some routing metrics can also reveal weak spots in the network, like a highly unreliable link or a node running low on energy 🪫. That information could be used by a potential attacker 👀 So it is RECOMMENDED to think carefully about which metrics RPL should use and how much visibility they give into the network state. Or use the appropriate security measures specified in [RFC6550] to protect that information 🔒
Since the routing metrics/constraints are carried within RPL messages, the security routing mechanisms defined in [RFC6550] apply here 💜
8. Acknowledgements 🫶
the authors want to give a huge shoutout to Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey (yes, twice, we see you 👀), Mathilde Durvy, Phoebus Chen, Tim Winter, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal, Joseph Saloway, David Culler, and Jari Arkko 🌸 for their review and valuable comments. Special thanks to Adrian Farrel for his thorough review 👑
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
9.2. Informative References
- [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
- [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
- [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
- [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
- [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
- [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
- [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
- [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
- [ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
- [Zinky1989] Zinky, J., Vichniac, G., and A. Khanna, "Performance of the Revised Routing Metric for ARPANET and MILNET", Military Communications Conference, MILCOM '89, March 1989.
Authors' Addresses 🖋️
JP. Vasseur (editor)
Cisco Systems
11, Rue Camille Desmoulins
Issy Les Moulineaux 92782
France
EMail: jpv@cisco.com
Mijeom Kim (editor)
Corporate Technology Group, KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
EMail: mjkim@kt.com
Kris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, CA 95544
USA
EMail: kpister@dustnetworks.com
Nicolas Dejean
Elster SAS
Espace Concorde, 120 impasse JB Say
Perols 34470
France
EMail: nicolas.dejean@coronis.com
Dominique Barthel
France Telecom Orange
28 chemin du Vieux Chene, BP 98
Meylan 38243
France
EMail: dominique.barthel@orange.com📦 where this page comes from
- ietf: rfc6551 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms