idnits 2.17.1 draft-ietf-roll-routing-metrics-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2010) is 4953 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Khanna1989' is mentioned on line 161, but not defined == Unused Reference: 'RFC3471' is defined on line 1280, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-11 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group JP. Vasseur, Ed. 3 Internet-Draft Cisco Systems, Inc 4 Intended status: Standards Track M. Kim, Ed. 5 Expires: March 9, 2011 Corporate Technology Group, KT 6 K. Pister 7 Dust Networks 8 N. Dejean 9 Coronis SAS 10 D. Barthel 11 France Telecom Orange 12 September 5, 2010 14 Routing Metrics used for Path Calculation in Low Power and Lossy 15 Networks 16 draft-ietf-roll-routing-metrics-09 18 Abstract 20 Low power and Lossy Networks (LLNs) have unique characteristics 21 compared with traditional wired and ad-hoc networks that require the 22 specification of new routing metrics and constraints. By contrast 23 with typical Interior Gateway Protocol (IGP) routing metrics using 24 hop counts or link metrics, this document specifies a set of link and 25 node routing metrics and constraints suitable to LLNs to be used by 26 the Routing for Low Power and lossy networks (RPL) routing protocol. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 9, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 9 70 3.1. Node State and Attributes object . . . . . . . . . . . . . 10 71 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 11 72 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 14 73 3.4. Node Fanout Ratio object . . . . . . . . . . . . . . . . . 15 74 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16 75 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 18 78 4.3.1. The Link Quality Level reliability metric . . . . . . 19 79 4.3.2. The Expected Transmission Count (ETX) reliability 80 object . . . . . . . . . . . . . . . . . . . . . . . . 21 81 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 22 82 4.4.1. Link Color object description . . . . . . . . . . . . 22 83 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24 84 5. Computation of dynamic metrics and attributes . . . . . . . . 24 85 6. Use of multiple DAG Metric Container . . . . . . . . . . . . . 25 86 7. Metric consistency . . . . . . . . . . . . . . . . . . . . . . 25 87 8. Metric usage . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 9.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 90 9.2. Routing Metric/Constraint common header . . . . . . . . . 27 91 9.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28 93 10. Security considerations . . . . . . . . . . . . . . . . . . . 28 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 12.1. Normative references . . . . . . . . . . . . . . . . . . . 29 97 12.2. Informative references . . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 This document makes use of the terminology defined in 103 [I-D.ietf-roll-terminology]. 105 Low power and Lossy Networks (LLNs) have specific routing 106 characteristics compared with traditional wired or ad-hoc networks 107 that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and 108 [RFC5867]. 110 Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have 111 used quantitative static link metrics. Other mechanisms such as 112 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see 113 [RFC2702] and [RFC3209]) make use of other link attributes such as 114 the available reserved bandwidth (dynamic) or link affinities (most 115 of the time static) to compute constrained shortest paths for Traffic 116 Engineering Label Switched Paths (TE LSPs). 118 This document specifies routing metrics and constraints to be used in 119 path calculation by the Routing Protocol for Low Power and Lossy 120 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 122 One of the prime objectives of this document is to propose a flexible 123 mechanism for the advertisement of routing metrics and constraints 124 used by RPL. Some RPL implementations may elect to adopt an 125 extremely simple approach based on the use of a single metric with no 126 constraint whereas other implementations may use a larger set of link 127 and node routing metrics and constraints. This specification 128 provides a high degree of flexibility and a set of routing metrics 129 and constraints. New routing metrics and constraints could be 130 defined in the future, as needed. 132 RPL is a distance vector routing protocol that builds Directed 133 Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG 134 formation rules are defined in [I-D.ietf-roll-rpl]: 136 o The DAG root may advertise a routing constraint used as a "filter" 137 to prune links and nodes that do not satisfy specific properties. 138 For example, it may be required for the path to only traverse 139 nodes that are mains powered or links that have at least a minimum 140 reliability or a specific "color" reflecting a user defined link 141 characteristic (e.g the link layer supports encryption). 143 o A routing metric is a quantitative value that is used to evaluate 144 the path cost. Link and nodes metrics are usually (but not 145 always) additive. 147 The best path is the path with the lowest cost with respect to some 148 metrics that satisfies all constraints (if any) and is also called 149 the shortest constrained path (in the presence of constraints). 151 Routing metrics can be classified according to the following set of 152 characteristics: 154 o Link versus Node metrics 156 o Qualitative versus quantitative 158 o Dynamic versus static 160 It must be noted that the use of dynamic metrics is not new and has 161 been experimented in ARPANET 2 [Khanna1989], with moderate success. 162 The use of dynamic metrics is not trivial and great care must be 163 given to the use of dynamic metrics since it may lead to potential 164 routing instabilities. it must be noted that the use of dynamic 165 metrics has been largely experimented and deployed in a number of 166 (non IP) networks in the past decade. 168 As pointed out in various routing requirements documents (see 169 [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to 170 take into account a variety of node constraints/metrics during path 171 computation. 173 It is also worth mentioning that it is fairly common for links in 174 LLNs to have fast changing node and link characteristics, which must 175 be taken into account when specifying routing metrics. For instance, 176 in addition to the dynamic nature of some links (e.g. wireless but 177 also Poweline Communication (PLC) links, nodes' resources such as 178 residual energy and other link's charatacteristics such as the 179 throughput are changing continuously and may have to be taken into 180 account during the path computation. Similarly, link attributes 181 including throughput and reliability may drastically change over time 182 due to multi-path interference. 184 Very careful attention must be given when using dynamic metrics and 185 attributes that affect routing decisions in order to preserve routing 186 stability. Routing metrics and constraints may either be static or 187 dynamic. When dynamic, a RPL implementation SHOULD make use of a 188 multi-threshold scheme rather than fine granular metric updates so as 189 to avoid constant routing changes. 191 Furthermore, it is a time and energy consuming process to update 192 dynamic metrics and recompute the routing tables on a frequent basis. 193 Therefore, it may be desirable to use a set of discrete values to 194 reduce computational overhead and bandwidth utilization. Of course, 195 this comes with a cost, namely, reduced metric accuracy. In other 196 cases, a set of flags may be defined to reflect a node state without 197 having to define discrete values. 199 Some link or node characteristics (e.g. link reliability flag, 200 remaining energy on the node) may either be used by RPL as routing 201 constraints or metric. For example, the path may be computed to 202 avoid links that do not provide a sufficient level of reliability 203 (use as a constraint) or as the path offering the maximum number of 204 links with a specified reliability level (use as a metric). The 205 document provides the flexibility to use link and node charaterisics 206 either as constraints and/or metrics. 208 The set of routing metrics and constraints used by an RPL 209 implementation is signalled along the Directed Acyclic Graph (DAG) 210 that is built according to the Objective Function (rules governing 211 how to build a DAG) and the routing metrics and constraints are 212 advertised in the DAG Information Option (DIO) message specified in 213 [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different 214 characteristics. For example, it may be desirable to build a DAG 215 with the goal to maximize reliability by using the link reliability 216 metric to compute the "best" path. Another example might be to use 217 the energy node characteristic (e.g. mains powered versus battery 218 operated) as a node constraint when building the DAG so as to avoid 219 battery powered nodes in the DAG while optimizing the link 220 throughput. 222 Links and nodes routing metrics and constraints are not exclusive. 224 The requirements on reporting frequency may differ among metrics, 225 thus different reporting rates may be used for each category and are 226 consequently implementatin-specific. 228 The specification of objective functions used to compute the DAG 229 built by RPL is out of the scope of this document. Routing metrics 230 and constraints are decoupled from the objective function. So a 231 generic objective function could for example specify the rules to 232 select the best parents in the DAG, the number of backup parents, 233 etc. Such objective function can be used with any routing metrics 234 and/or contraints such as the ones specified in this document. 236 Some metrics are either aggregated or recorded. In the former case, 237 the metric is adjusted as the DIO message travels along the DAG. For 238 example, if the metric is the link latency, each node updates the 239 latency metric along the DAG. By contrast, a metric may be recorded 240 in which case each node adds a sub-object reflecting the local 241 metric. For example, it might be desirable to record the link 242 quality level along the path. In this case, each visited node adds a 243 sub-object reporting the local link quality level. In order to limit 244 the number of sub-objects, the use of a counter may be desirable 245 (e.g. record the number of links with a certain link quality level), 246 thus compressing the information to reduce the message lenght. Upon 247 receiving the DIO message from a set of parents, a node can decide 248 accoding to the OF and local policy which node to choose as a parent 249 based on the maximum number of links with a specific link reliability 250 level for example. 252 Note that the routing metrics are constrained specified in this 253 document are not specific to any link layer. Internal API between 254 the MAC layer and RPL may advantageously be used to accurately 255 reflect the metrics values of the link (wireless, wired, PLC). 257 2. Object formats 259 Routing metrics and constraints are carried within the DAG Metric 260 Container object defined in [I-D.ietf-roll-rpl]. 262 0 1 2 3 263 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 2 3 4 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 265 | Type=2 | Option Len | Routing Metric/Constraint objects 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 268 Figure 1: DAG Metric Container format 270 The Routing Metric/Contraints objects have a common format consisting 271 of one or more 8-bit words with a common header: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |Routing-MC-Type| Flags |P|C|0|R| A | Prec | Length (bytes)| 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 // (object body) // 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: Routing Metric/Constraint object generic format 285 The object body carries one or more sub-objects. 287 Note that the Routing Metric/Constraint objects defined in this 288 document can appear in any order in the DAG Metric Container. 290 Routing-MC-Type (Routing Metric/Contraint Type - 8 bits): the Routing 291 Metric/Constraint Type field uniquely identifies each Routing Metric/ 292 Constraint object and is managed by IANA. 294 Length: this field defines the length of the object body, in bytes. 296 The Flag field of the Routing Metric/Constraint object is managed by 297 IANA. Unassigned bits are considered as reserved. They MUST be set 298 to zero on transmission and MUST be ignored on receipt. 300 o C Flag. When set, this indicates that the Routing Metric/ 301 Constraint object refers to a routing constraint. When cleared, 302 the routing object refers to a routing metric. 304 o O Flag: The O flag is used exclusively for routing constraints (C 305 flag is set). When set, this indicates that the constraint is 306 optional. When cleared, the constraint is mandatory. If the C 307 flag is zero, the O flag MUST be set to zero on transmission and 308 ignored on reception. 310 o R Flag: The R Flag is only relevant for routing metric (C=0) and 311 MUST be cleared for C=1. When set, this indicates that the 312 routing metric is recorded along the path. Conversely, when 313 cleared, the routing metric is aggregated. 315 o A Field: The A field is used to indicate whether an aggregated 316 routing metric is additive, multiplicative, reports a maximum or a 317 minimum. 319 * A=0x00: The routing metric is additive 321 * A=0x01: The routing metric reports a maximum 323 * A=0x02: The routing metric reports a minimum 325 * A=0x03: The routing metric is multiplicative 327 The A field has no meaning when the C Flag is set (i.e. when the 328 Routing Metric/Constraint object refers to a routing constraint) 329 and MUST be written to 0x00. 331 o Prec field: The P field indicates the precedence of this Routing 332 Metric/Constraint object. This is useful when a DAG Metric 333 Container contains several Routing Metric objects. The value 0 334 means the highest precedence. The precedence field can be used as 335 a tie-breaker in the presence of the multiple metrics advertising 336 the same value. 338 o P field: the P field is only used for recorded metric. When 339 cleared, all nodes along the path managed to recorded the 340 corresponding link metric. When set, this indicates than one of 341 more nodes along the path could not record the metric of interest 342 (either because of lack of knowledge or because this was prevented 343 by policy). 345 Example 1: A DAG formed by RPL where all nodes must be main-powered 346 and the best path is the one with lower aggregated ETX. In this case 347 the DAG Metric container carries two Routing Metric/Constraint 348 objects: one is an ETX metric object with header (C=0, O=0, A=00, 349 R=0) and the second one is a Node Energy constraint with header (C=1, 350 O=0, A=00, R=0). Note that a RPL instance may use the metric object 351 to report a maximum (A=0x01) or a minimum (A=0x02). If the best path 352 is characterized by the path avoiding low quality links for example, 353 then the path metric reports a maximum (A=0x01) (note that higher 354 values mean lower link quality): when the link quality metric (ETX) 355 is processed along a path, each node updates its value if the current 356 link ETX value is higher than the value carried by the metric object. 358 Example 2: A DAG formed by RPL where the link metric is the link 359 quality level and link quality levels must be recorded along the 360 path. In this case, the DAG Metric Container carries a Routing 361 Metric/Constraint object: link quality level metric (C=0, O=0, A=00, 362 R=1) containing multiple sub-objects. 364 A Routing Metric/Constraint object may also include one or more type- 365 length-value (TLV) encoded data sets. Each Routing Metric/Constraint 366 TLV has the same structure: 368 Type: 1 byte 369 Length: 1 byte 370 Value: variable 372 A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 373 1 byte specifying the TLV length, and a value field. The TLV length 374 field defines the length of the value field in bytes. 376 Unrecognized TLVs MUST be ignored. 378 IANA management of the Routing Metric/Constraint objects identifier 379 codespace is described in Section 9. 381 3. Node Metric/Constraint objects 383 It is fairly common for LLNs to be made of nodes with heterogeneous 384 attributes and capabilities (e.g. nodes being battery operated or 385 not, amount of memory, etc). More capable and stable nodes may 386 assist the most constrained ones for routing packets, which results 387 in extension of network lifetime and efficient network operations. 388 This is a typical (but non exclusive) use of constraint-based routing 389 where the computed path may not be the shortest path according to 390 some specified metrics. Another use is to find the shortest path 391 according to a pre-defined metric while avoiding link with a specific 392 color (for example "non secured link"). 394 3.1. Node State and Attributes object 396 The Node State and Attribute (NSA) object is used to provide 397 information on the nodes characteristics. 399 The NSA object MAY be present in the DAG Metric Container. There 400 MUST be no more than one NSA object as a constraint per DAG Metric 401 Container, and no more than one NSA object as a metric per DAG Metric 402 Container. 404 The NSA object may also contain a set of TLVs used to convey various 405 node characteristics. No TLV is currently defined. 407 The NSA Routing Metric/Constraint Type is to be assigned by IANA 408 (recommended value=1). 410 The format of the NSA object body is as follows: 412 0 1 2 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 415 | Res | Flags |A|O| Optional TLVs 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 418 Figure 3: NSA object format 420 Node workload may be hard to determine and expressed in some scalar 421 form. However, node workload could be a useful metric to consider 422 during path calculation, in particular when queuing delays must be 423 minimized for highly sensitive traffic considering Medium Access 424 Control (MAC) layer delay. Node workload MAY be set upon CPU 425 overload, lack of memory or any other node related conditions. Using 426 a simple 1-bit flag to characterize the node workload provides a 427 sufficient level of granularity, similarly to the "overload" bit used 428 in routing protocols such as IS-IS. Algorithms used to set the 429 overload bit and to compute path to potentially avoid node with their 430 overload bit set are outside the scope of this document but it is 431 RECOMMENDED to avoid too frequent changes of that bit to avoid 432 routing oscillations. 434 Data Aggregation Attribute: data fusion involves more complicated 435 processing to improve accuracy of the output data while data 436 aggregation mostly aims at reducing the amount of data. This is 437 listed as a requirement in Section 6.2 of [RFC5548]. Some 438 applications may make use of the aggregation node attribute in their 439 routing decision so as to minimize the amount of traffic on the 440 network, thus potentially increasing its life time in battery 441 operated environments. Applications where high directional data flow 442 is expected on a regular basis may take advantage of data aggregation 443 supported routing. 445 The following two bits of the NSA object are currently defined: 447 o O Flag: When set, this indicates that the node is overloaded and 448 may not be able to process traffic. 450 o A Flag: When set, this indicates that the node can act as a 451 traffic aggregator. An implementation MAY decide to add optional 452 TLVs (not currently defined) to further describe the node traffic 453 aggregator functionality. 455 The Flag field of the NSA Routing Metric/Constraint object is managed 456 by IANA. Unassigned bits are considered as reserved. They MUST be 457 set to zero on transmission and MUST be ignored on receipt. 459 3.2. Node Energy object 461 Whenever possible, a node with low residual energy should not be 462 selected as a router, thus the support for constraint-based routing 463 is needed. In such cases, the routing protocol engine may compute a 464 longer path (constraint based) for some traffic in order to increase 465 the network life duration. 467 The routing engine may prefer a "longer" path that traverses mains- 468 powered nodes in particular for low-critical traffic or nodes 469 equipped with energy scavenging, rather than a "shorter" path through 470 battery operated nodes. 472 Power and energy are clearly critical resources in most LLNs. As yet 473 there is no simple abstraction which adequately covers the broad 474 range of power sources and energy storage devices used in existing 475 LLN nodes. These include main-powered, primary batteries, energy- 476 scavengers, and a variety of secondary storage mechanisms. 477 Scavengers may provide a reliable low level of power, such as might 478 be available from a 4-20mA loop; a reliable but periodic stream of 479 power, such as provided by a well-positioned solar cell; or 480 unpredictable power, such as might be provided by a vibrational 481 energy scavenger on an intermittently powered pump. Routes which are 482 viable when the sun is shining may disappear at night. A pump 483 turning on may connect two previously disconnected sections of a 484 network. 486 Storage systems like rechargeable batteries often suffer substantial 487 degradation if regularly used to full discharge, leading to different 488 residual energy numbers for regular versus emergency operation. A 489 route for emergency traffic may have a different optimum than one for 490 regular reporting. 492 Batteries used in LLNs often degrade substantially if their average 493 current consumption exceeds a small fraction of the peak current that 494 they can deliver. It is not uncommon for battery-operated nodes to 495 have a combination of primary storage, energy scavenging, and 496 secondary storage, leading to three different values for acceptable 497 average current depending on the time frame being considered, e.g. 498 milliseconds, seconds, and hours/years. 500 Raw power and energy values are meaningless without knowledge of the 501 energy cost of sending and receiving packets, and lifetime estimates 502 have no value without some higher-level constraint on the lifetime 503 required of a device. In some cases the path that exhausts the 504 battery of a node on the bed table in a month may be preferable to a 505 route that reduces the lifetime of a node in the wall to a decade. 507 Given the complexity of trying to address such a broad collection of 508 constraints, this document defines three levels of fidelity in the 509 solution. 511 The simplest solution relies on a 2-bit field encoding three types of 512 power sources: "powered", "battery", "scavenger". This simple 513 approach may be sufficient for many applications. 515 The mid-complexity solution is a single parameter that can be used to 516 encode the energetic happiness of both battery powered and scavenging 517 nodes. For scavenging nodes, the 8 bit quantity is the power 518 provided by the scavenger divided by the power consumed by the 519 application, H=P_in/P_out, in units of percent. Nodes which are 520 scavenging more power than they are consuming will register above 521 100. The time period for averaging power in this calculation is out 522 of the scope of this document but something related to the discharge 523 time of the energy storage device on the node is probably 524 appropriate. For battery powered devices, H is the current expected 525 lifetime divided by the desired minimum lifetime. The estimation of 526 remaining battery energy and actual power consumption can be 527 difficult, and the specifics of this calculation are out of scope of 528 this document, but two examples are presented. If the node can 529 measure its average power consumption, then H can be calculated as 530 the ratio of desired max power (initial energy E_0 divided by desired 531 lifetime T) to actual power H=P_max/P_now. Alternatively, if the 532 energy in the battery E_bat can be estimated, and the total elapsed 533 lifetime, t, is available, then H can be calculated as the total 534 stored energy remaining versus the target energy remaining: H= E_bat 535 / [E_0 (T-t)/T]. 537 An example of optimized route is max(min(H)) for all battery operated 538 nodes along the route, subject to the constraint that H>=100 for all 539 scavengers along the route. 541 The Node Energy (NE) object is used to provide information related to 542 node energy and may be used as a metric or as constraint. 544 The NE object MAY be present in the DAG Metric Container. There MUST 545 be no more than one NE object as a constraint per DAG Metric 546 Container, and no more than one NE object as a metric per DAG Metric 547 Container. 549 The NE object Type is to be assigned by IANA (recommended value=2). 551 The format of the NE object body is as follows: 553 0 1 2 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 556 | NE Sub-objects 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 559 Figure 4: NE object format 561 The format of the NE sub-object body is as follows: 563 0 1 2 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 566 | Flags |I| T |E| E-E | Optional TLVs 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 569 Figure 5: NE sub-object format 571 The NE sub-object may also contain a set of TLVs used to convey 572 various nodes' characteristics. 574 The following flags are currently defined: 576 o T (node Type): 2-bit field indicating the node type. When E=0x00, 577 the node is mains powered. When E=0x01 is battery powered. When 578 E=0x02 the node is powered by a scavenger. 580 o I (Included): the I bit is only relevant when the node type is 581 used as a constraint. For example, the path must only traverse 582 mains powered node. Conversely, battery operated node must be 583 excluded. The I bit is used to stipulate inclusion versus 584 exclusion. When set, this indicates that nodes of type specified 585 in the node type field MUST be included. Conversely, when 586 cleared, this indicates that nodes of type specified in the node 587 type field MUST be excluded. 589 o E (Estimation): when the E bit is set for a metric, the estimated 590 percentage of remaining energy on the node is indicated in the E-E 591 8-bit field. When cleared, the estimated percentage of remaining 592 energy is not provided. When the E bit is set for a constraint, 593 the E-E field defines a threshold for the inclusion/exclusion: if 594 an inclusion, nodes with values higher than the threshold are to 595 be included; if an exclusion, nodes with values lower than the 596 threshold are to be excluded. 598 E-E (Estimated-Energy): 8-bit unsigned integer field indicating an 599 estimated percentage of remaining energy. The E-E field is only 600 relevant when the E flag is set, and MUST be set to 0 when the E flag 601 is cleared. 603 If the NE object comprises several sub-objects when used as a 604 constraint, each sub-object adds or subtracts node subsets as the 605 sub-objects are parsed in order. The initial set (full or empty) is 606 defined by the I bit of the first sub-object: full if that I bit is 607 an exclusion, empty is that I bit is an inclusion. 609 No TLV is currently defined. 611 The most complex solution involves a half dozen TLV parameters 612 representing energy storage, consumption, and generation capabilities 613 of the node, as well as desired lifetime, and will appear in a future 614 version of this document. 616 3.3. Hop-Count object 618 The HoP-Count (HP) object is used to report the number of traversed 619 nodes along the path. 621 The HP object MAY be present in the DAG Metric Container. There MUST 622 be no more than one HP object as a constraint per DAG Metric 623 Container, and no more than one HP object as a metric per DAG Metric 624 Container. 626 The HP object may also contain a set of TLVs used to convey various 627 node characteristics. No TLV is currently defined. 629 The HP routing metric object Type is to be assigned by IANA 630 (recommended value=3) 632 The format of the Hop Count object body is as follows: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 637 | Res | Flags | Hop Count | Optional TLVs 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 640 Figure 6: Hop Count object format 642 No Flag is currently defined. 644 The HP object may be used as a constraint or a metric. When used as 645 a constraint, the DAG root indicates the maximum number of hops that 646 a path may traverse. When that number is reached, no other node can 647 join that path. When used as a metric each visited node simply 648 increments the Hop Count field. 650 3.4. Node Fanout Ratio object 652 The Node Fanout Ratio (NFR) object is used to provide information on 653 the nodes current forwarding load. 655 The NFR object MAY be present in the DAG Metric Container. There 656 MUST be no more than one NFR object as a constraint per DAG Metric 657 Container, and no more than one NFR object as a metric per DAG Metric 658 Container. 660 The NFR object may also contain a set of TLVs used to convey various 661 forwarding load characteristics. No TLV is currently defined. 663 The NFR object Type is to be assigned by IANA (recommended value=9). 665 The format of the NFR object body is as follows: 667 0 1 2 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 670 | Flags | F R | Optional TLVs 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 673 Figure 7: NFR object format 675 When the data traffic of the application supported by the network is 676 known a priori, energy depletion in the network can be equalized 677 simply by controlling the fanout ratio of router nodes. 679 Algorithms describing how to compute the FR value and how to use it 680 are outside the scope of this document. 682 The following field of the NFR object is defined: 684 o FR Field: a 4-bit unsigned integer that indicates a relative 685 fanout of the node. A value of 15 indicates a node that is very 686 close to, or at its maximum supported fanout capability. A value 687 of 0 indicates a very small fanout. 689 Unassigned bits are considered as reserved. They MUST be set to zero 690 on transmission and MUST be ignored on receipt. 692 4. Link Metric/Constraint objects 694 4.1. Throughput 696 Many LLNs support a wide range of throughputs. For some links, this 697 may be due to variable coding. For the deeply duty-cycled links 698 found in many LLNs, the variability comes as a result of trading 699 power consumption for bit rate. There are several MAC layer 700 protocols which allow for the effective bit rate and power 701 consumption of a link to vary over more than three orders of 702 magnitude, with a corresponding change in power consumption. For 703 efficient operation, it may be desirable for nodes to report the 704 range of throughput that their links can handle in addition to the 705 currently available throughput. 707 The Throughput object MAY be present in the DAG Metric Container. 708 There MUST be no more than one Throughput object as a constraint per 709 DAG Metric Container, and no more than one Throughput object as a 710 metric per DAG Metric Container. 712 The Throughput object is made of throughput sub-objects and MUST at 713 least comprise one Throughput sub-object. The first Throughput sub- 714 object MUST be the most recently estimated actual throughput. The 715 actual evaluation of the throughput is outside of this document. 717 Each Throughput sub-object has a fixed length of 4 bytes. 719 The Throughput object does not contain any additional TLV. 721 The Throughput object Type is to be assigned by IANA (recommended 722 value=4) 724 The format of the Throughput object body is as follows: 726 0 1 727 0 1 2 3 4 5 6 7 8 9 0 1 2 3 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | (sub-object) ..... 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Figure 8: Throughput object body format 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Throughput | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 9: Throughput sub-object format 742 Throughput: 32 bits. The Throughput is encoded in 32 bits in 743 unsigned integer format, expressed in bytes per second. 745 4.2. Latency 747 Similarly to throughput, the latency of many LLN MAC sub-layers can 748 vary over many orders of magnitude, again with a corresponding change 749 in current consumption. Some LLN MAC link layers will allow the 750 latency to be adjusted globally on the subnet, or on a link-by-link 751 basis, or not at all. Some will insist that it be fixed for a given 752 link, but allow it to be variable from link to link. 754 The Latency object MAY be present in the DAG Metric Container. There 755 MUST be no more than one Latency object as a constraint per DAG 756 Metric Container, and no more than one Latency object as a metric per 757 DAG Metric Container. 759 The Latency object is made of Latency sub-objects and MUST at least 760 comprise one Latency sub-object. Each Latency sub-object has a fixed 761 length of 4 bytes. 763 The Latency object does not contain any additional TLV. 765 The Latency object Type is to be assigned by IANA (recommended 766 value=5) 768 The Latency object is a metric or constraint. 770 The format of the Latency object body is as follows: 772 0 1 773 0 1 2 3 4 5 6 7 8 9 0 1 2 3 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | (sub-object) ..... 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 10: Latency object body format 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Latency | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Figure 11: Latency sub-object format 788 Latency: 32 bits. The Latency is encoded in 32 bits in unsigned 789 integer format, expressed in microseconds. 791 The Latency object may be used as a constraint or a path metric. For 792 example, one may want the latency not to exceed some value. In this 793 case, the Latency object common header indicates that the provided 794 value relates to a constraint. In another example, the Latency 795 object may be used as an aggregated additive metric where the value 796 is updated along the path to reflect the path latency. 798 4.3. Link reliability 800 In LLNs, link reliability is degraded by external interference and 801 multi-path interference (wireless links). Multipath typically 802 affects both directions on the link equally, whereas external 803 interference is sometimes uni-directional. Time scales vary from 804 milliseconds to days, and are often periodic and linked to human 805 activity. Packet error rates can generally be measured directly, and 806 other metrics (e.g. bit error rate, mean time between failures) are 807 typically derived from that. Note that such variability is not 808 specific to wireless link but also applies to PLC links. 810 A change in link quality can affect network connectivity, thus, link 811 quality may be taken into account as a critical routing metric. Link 812 quality metric should be applied to each directional link unless bi- 813 directionality is one of routing metrics. 815 A number of link reliability metrics could be defined reflecting 816 several reliability aspects. Two link reliability metrics are 817 defined in this document: the Link Quality Level (LQL) and the 818 Expected Transmission count Metric (ETX). 820 Note that an RPL implementation MAY either use the LQL, the ETX or 821 both. 823 4.3.1. The Link Quality Level reliability metric 825 The Link Quality Level (LQL) object is used to quantify the link 826 reliability using a discrete value, from 0 to 7 where 0 indicates 827 that the link quality level is unknown and 1 reports the highest link 828 quality level. The mechanisms and algorithms used to compute the LQL 829 is implementation specific and outside of the scope of this document. 831 The LQL can either be used as a metric or a constraint. When used as 832 a metric, the LQL metric can be recorded or aggregated. For example, 833 the DAG may require to record the LQL for all traversed links. Each 834 node can then use the LQL to select the parent based on user defined 835 rules (e.g. "select the path with the maximum number of links 836 reporting a LQL value of 3 or less"). By contrast the LQL link 837 metric may be aggregated, in which case the sum of all LQLs may be 838 reported (additive metric) or the minimum value may be reported along 839 the path. 841 When used as a recorded metric, a counter is used to compress the 842 information where the number of links for each LQL is reported. 844 The LQL object MAY be present in the DAG Metric Container. There 845 MUST be no more than one LQL object as a constraint per DAG Metric 846 Container, and no more than one LQL object as a metric per DAG Metric 847 Container. 849 The LQL object MUST contain one or more sub-object used to report the 850 number of links along with their LQL. 852 The LQL object Type is to be assigned by IANA (recommended value=6) 853 The format of the LQL object body is as follows: 855 0 1 2 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 858 | Res | LQL sub-object 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 861 Figure 12: LQL object format 863 When the LQL metric is recorded, the LQL object body comprises one or 864 more LQL Type 1 sub-object. 866 The format of the LQL Type 1 sub-object is as follows 868 0 1 2 3 4 5 6 7 869 +-+-+-+-+-+-+-+-+ 870 | Val | Counter | 871 +-+-+-+-+-+-+-+-+ 873 Figure 13: LQL Type 1 sub-object format 875 Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates 876 the highest link quality. 878 Counter: number of links with that value. 880 When the LQL metric is aggregated, the LQL object body comprises one 881 LQL Type 2 sub-object: 883 The format of the LQL Type 2 sub-object is as follows 885 0 1 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Aggregated LQL Value | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Figure 14: LQL Type 2 sub-object format 893 Aggregated LQL Value: when used as an additive metric (A=0x00), the 894 aggregated LQL value reports the sum of all the LQL values for all 895 links along the path. When used to report a minimum (A=0x02), the 896 field reports the minimum LQL value of all links along the path 897 ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to 898 report a maximum (A=0x01), the field reports the maximum LQL value of 899 all links along the path. When used to report a multiplication 900 (A=0x03), and the LQL field of one of the links along the path is 901 undetermined (LQL=0), the undetermined LQL will be ignored and not be 902 aggregated (i.e. no reset to Aggregated LQL Value field). 904 4.3.2. The Expected Transmission Count (ETX) reliability object 906 The Expected Transmission Count (ETX) metric is the number of 907 transmissions a node expects to make to a destination in order to 908 successfully deliver a packet. 910 For example, an implementation may use the following formula: ETX= 1 911 / (Df * Dr) where Df is the measured probability that a packet is 912 received by the neighbor and Dr is the measured probability that the 913 acknowledgment packet is successfully received. This document does 914 not mandate the use of a specific formula to compute the ETX value. 916 The ETX object MAY be present in the DAG Metric Container. There 917 MUST be no more than one ETX object as a constraint per DAG Metric 918 Container, and no more than one ETX object as a metric per DAG Metric 919 Container. 921 The ETX object is made of ETX sub-objects and MUST at least comprise 922 one ETX sub-object. Each ETX sub-object has a fixed length of 8 923 bits. 925 The ETX object does not contain any additional TLV. 927 The ETX object Type is to be assigned by IANA (recommended value=7) 928 The format of the ETX object body is as follows: 930 0 1 931 0 1 2 3 4 5 6 7 8 9 0 1 2 3 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | (sub-object) ..... 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Figure 15: ETX object body format 938 0 1 939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | ETX | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 16: ETX sub-object format 946 ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned 947 integer format, rounded off to the nearest whole number. For 948 example, if ETX = 3.569, the object value will be 457. If ETX > 949 511.9921875, the object value will be the maximum which is 65535. 951 The ETX object may be used as a constraint or a path metric. For 952 example, it may be required that the ETX must not exceed some 953 specified value. In this case, the ETX object common header 954 indicates that the value relates to a constraint . In another 955 example, the ETX object may be used as an aggregated additive metric 956 where the value is updated along the path to reflect to path quality. 958 4.4. Link Color object 960 4.4.1. Link Color object description 962 The Link Color (LC) object is an administrative 10-bit link 963 constraint (which may either be static or dynamically adjusted) used 964 to avoid or attract specific links for specific traffic types. 966 The LC object can either be used as a metric or as a constraint. 967 When used as a metric, the LC metric can only be recorded. For 968 example, the DAG may require recording the link colors for all 969 traversed links. Each node can then use the LC to select the parent 970 based on user defined rules (e.g. "select the path with the maximum 971 number of links having their first bit set 1 (e.g. encrypted 972 links)"). The LC object may also be used as a constraint. 974 When used as a recorded metric, a counter is used to compress the 975 information where the number of links for each Link Color is 976 reported. 978 The Link Color (LC) object MAY be present in the DAG Metric 979 Container. There MUST be no more than one LC object as a constraint 980 per DAG Metric Container, and no more than one LC object as a metric 981 per DAG Metric Container. 983 There MUST be a at least one LC sub-object per LC object. 985 The LC object does not contain any additional TLV. 987 The LC object Type is to be assigned by IANA (recommended value=8) 989 The format of the LC object body is as follows: 991 0 1 2 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 994 | Res | LC sub-objects 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 997 Figure 17: LC object format 999 When the LC object is used as a recorded metric, the LC object body 1000 comprises one or more LC Type 1 sub-objects. 1002 The format of the LC Type 1 sub-object body is as follows: 1004 0 1 1005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Link Color | Counter | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 Figure 18: LC Type 1 sub-object format 1012 When the LC object is used as a constraint, the LC object body 1013 comprises one or more LC Type 2 sub-objects. 1015 The format of the LC Type 2 sub-object body is as follows: 1017 0 1 1018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Link Color |I| 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 19: LC Type 2 sub-object format 1025 I Bit: The I bits is only relevant when the Link Color is used as a 1026 constraint. When cleared, this indicates that links with the 1027 specified color must be included. When set, this indicates that 1028 links with the specified color must be excluded. 1030 The use of the LC object is outside the scope of this document. 1032 4.4.2. Mode of operation 1034 The link color may be used as a constraint or a metric. 1036 o When used as constraint, the LC object may be inserted in the DAG 1037 Metric Container to indicate that links with a specific color 1038 should be included or excluded from the computed path. 1040 o When used as recorded metric, each node along the path may insert 1041 a LC object in the DAG Metric Container to report the color of the 1042 local link. If there is already a LC object reported a similar 1043 color, the node MUST NOT add another identical LC sub-object and 1044 MUST increment the counter field. 1046 5. Computation of dynamic metrics and attributes 1048 As already pointed out, dynamically calculated metrics are of the 1049 utmost importance in many circumstances in LLNs. This is mainly 1050 because a variety of metrics change on a frequent basis, thus 1051 implying the need to adapt the routing decisions. That being said, 1052 care must be given to the pace at which changes are reported in the 1053 network. The attributes will change according to their own time 1054 scales. RPL controls the reporting rate. 1056 To minimize metric updates, multi-threshold algorithms MAY be used to 1057 determine when updates should be sent. When practical, low-pass 1058 filtering and/or hysteresis should be used to avoid rapid 1059 fluctuations of these values. Finally, although the specification of 1060 path computation algorithms using dynamic metrics are out the scope 1061 of this document, it is RECOMMENDED to carefully design the route 1062 optimization algorithm to avoid too frequent computation of new 1063 routes upon metric values changes. 1065 Controlled adaptation of the routing metrics and rate at which paths 1066 are computed are critical to avoid undesirable routing instabilities 1067 resulting in increased latencies and packet loss because of temporary 1068 micro-loops. Furthermore, excessive route changes will adversely 1069 impact the traffic and power consumption in the network, thus 1070 potentially impacting its scalability. 1072 6. Use of multiple DAG Metric Container 1074 Since RPL options length are coded using 1 octet, their length cannot 1075 exceed 256 bytes, which also applies to the DAG Metric Container. 1076 Although in the vast majority of cases, the advertised routing 1077 metrics and constraints will not require that much space, there might 1078 be circumstances where larger space will be required, should for 1079 example a set of routing metrics be recorded along a long path. In 1080 this case, as specified in [I-D.ietf-roll-rpl], routing metrics will 1081 be carried using multiple DAG Metric Containers. 1083 In the rest of this document, this use of multiple DAG Metric 1084 Containers will be considered as if they were actually just one long 1085 DAG Metric Container. 1087 7. Metric consistency 1089 Since a set of metrics and constraints will be used for links and 1090 nodes in LLN, it is particularly critical to ensure the use of 1091 consistent metric calculation mechanisms for all links and nodes in 1092 the network, similarly to the case of inter-domain IP routing. 1094 8. Metric usage 1096 This section describes how metrics carried in the DAG Metric 1097 Container shall be used. 1099 When the DAG Metric Container contains a single aggregated metric 1100 (scalar value), the order relation to select the best path is 1101 implicitly derived from the metric type. For example, lower is 1102 better for Hop Count, Link Latency, ETX and Fanout Ratio. For Node 1103 Energy or Throughput, higher is better. 1105 An example of using such a single aggregated metric is optimizing 1106 routing for node energy. The Node Energy metric (E-E field) is 1107 aggregated along paths with an explicit min function (A field), and 1108 the best path is selected through an implied Max function because the 1109 metric is Energy. 1111 When the DAG Metric Container contains several aggregated metrics, 1112 they are to be used as tie-breakers according to their precedence 1113 defined by their Prec field values. 1115 An example of such use of multiple aggregated metrics is the 1116 following: Hop-Count as the primary criteria, LQL as the secondary 1117 criteria and Fanout Ratio as the ultimate tie-breaker. In such a 1118 case, the Hop-Count, LQL and Fanout Ratio metric objects' Prec fields 1119 should bear strictly increasing values such as 0, 1 and 2, 1120 respectively. 1122 9. IANA Considerations 1124 IANA is requested to establish a new top-level registry to contain 1125 all Routing Metric/Constraint objects codepoints and sub-registries. 1127 The allocation policy for each new registry is by IETF Consensus: new 1128 values are assigned through the IETF consensus process (see 1129 [RFC5226]). Specifically, new assignments are made via RFCs approved 1130 by the IESG. Typically, the IESG will seek input on prospective 1131 assignments from appropriate persons (e.g., a relevant Working Group 1132 if one exists). 1134 9.1. Routing Metric/Constraint type 1136 IANA is requested to create a registry for Routing Metric/Constraint 1137 objects. Each Routing Metric/Constraint object has a type value. 1139 Value Meaning Reference 1140 1 Node State and Attribute This document 1141 2 Node Energy This document 1142 3 Hop Count This document 1143 4 Link Throughput This document 1144 5 Link Latency This document 1145 6 Link Quality Level This document 1146 7 Link ETX This document 1147 8 Link Color This document 1148 9 Node Fanout Ratio This document 1150 9.2. Routing Metric/Constraint common header 1152 IANA is requested to create a registry to manage the codespace of A 1153 field of the Routing Metric/Constraint common header. 1155 Codespace of the A field (Routing Metric/Constraint common header) 1156 Value Meaning Reference 1158 0 Routing metric is additive This document 1159 1 Routing metric reports a maximum This document 1160 2 Routing metric reports a minimum This document 1161 3 Routing metric is multiplicative This document 1163 IANA is requested to create a registry to manage the Flag field of 1164 the Routing Metric/Constraint common header. 1166 New bit numbers may be allocated only by an IETF Consensus action. 1167 Each bit should be tracked with the following qualities: 1169 o Bit number 1171 o Capability Description 1173 o Defining RFC 1175 Several bits are defined for the Routing Metric/Constraint common 1176 header in this document. The following values have been assigned: 1178 Codespace of the Flag field (Routing Metric/Constraint common header) 1179 Bit Description Reference 1181 12-15 Precedence This document 1182 10-11 Additive/Max/Min/Multi This document 1183 9 Recorded/Aggregated This document 1184 8 Optional Constraint This document 1185 7 Constraint/metric This document 1186 6 P (Partial) This document 1188 9.3. NSA object 1190 IANA is requested to create a registry to manage the codespace of the 1191 Flag field of the NSA object. 1193 New bit numbers may be allocated only by an IETF Consensus action. 1194 Each bit should be tracked with the following qualities: 1196 o Bit number 1197 o Capability Description 1199 o Defining RFC 1201 Several bits are defined for the NSA object flag field in this 1202 document. The following values have been assigned: 1204 Codespace of the Flag field (NSA object) 1205 Bit Description Reference 1207 14 Aggregator This document 1208 15 Overloaded This document 1210 9.4. Hop-Count object 1212 IANA is requested to create a registry to manage the codespace of the 1213 Flag field of the Hop-count object. 1215 New bit numbers may be allocated only by an IETF Consensus action. 1216 Each bit should be tracked with the following qualities: 1218 o Bit number 1220 o Capability Description 1222 o Defining RFC 1224 No Flag is currently defined. 1226 10. Security considerations 1228 Routing metrics should be handled in a secure and trustful manner. 1229 For instance, a malicious node can not advertise falsely that it has 1230 good metrics for routing and belong to the established path to have a 1231 chance to intercept packets. Since the routing metrics/constraints 1232 are carried within RPL message, the security routing mechanisms 1233 defined in [I-D.ietf-roll-rpl] applies here. 1235 11. Acknowledgements 1237 The authors would like to acknowledge the contributions of Young Jae 1238 Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip 1239 Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru 1240 Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, 1241 Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads 1242 Westergreen and Mukul Goyal for their review and valuable comments. 1244 12. References 1246 12.1. Normative references 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, March 1997. 1251 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1252 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1253 May 2008. 1255 12.2. Informative references 1257 [I-D.ietf-roll-rpl] 1258 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 1259 Protocol for Low power and Lossy Networks", 1260 draft-ietf-roll-rpl-11 (work in progress), July 2010. 1262 [I-D.ietf-roll-terminology] 1263 Vasseur, J., "Terminology in Low power And Lossy 1264 Networks", draft-ietf-roll-terminology-03 (work in 1265 progress), March 2010. 1267 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1268 dual environments", RFC 1195, December 1990. 1270 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1272 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1273 McManus, "Requirements for Traffic Engineering Over MPLS", 1274 RFC 2702, September 1999. 1276 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1277 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1278 Tunnels", RFC 3209, December 2001. 1280 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1281 (GMPLS) Signaling Functional Description", RFC 3471, 1282 January 2003. 1284 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1285 "Routing Requirements for Urban Low-Power and Lossy 1286 Networks", RFC 5548, May 2009. 1288 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1289 "Industrial Routing Requirements in Low-Power and Lossy 1290 Networks", RFC 5673, October 2009. 1292 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1293 Routing Requirements in Low-Power and Lossy Networks", 1294 RFC 5826, April 2010. 1296 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1297 "Building Automation Routing Requirements in Low-Power and 1298 Lossy Networks", RFC 5867, June 2010. 1300 Authors' Addresses 1302 JP Vasseur (editor) 1303 Cisco Systems, Inc 1304 11, Rue Camille Desmoulins 1305 Issy Les Moulineaux, 92782 1306 France 1308 Email: jpv@cisco.com 1310 Mijeom Kim (editor) 1311 Corporate Technology Group, KT 1312 17 Woomyeon-dong, Seocho-gu 1313 Seoul, 137-792 1314 Korea 1316 Email: mjkim@kt.com 1318 Kris Pister 1319 Dust Networks 1320 30695 Huntwood Ave. 1321 Hayward, CA 95544 1322 USA 1324 Email: kpister@dustnetworks.com 1326 Nicolas Dejean 1327 Coronis SAS 1328 Espace Concorde, 120 impasse JB Say 1329 Perols, 34470 1330 France 1332 Email: nicolas.dejean@coronis.com 1333 Dominique Barthel 1334 France Telecom Orange 1335 28 chemin du Vieux Chene, BP 98 1336 Meylan, 38243 1337 France 1339 Email: dominique.barthel@orange-ftgroup.com