idnits 2.17.1 draft-ietf-roll-routing-metrics-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2010) is 4909 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 187, but not defined == Unused Reference: 'RFC3471' is defined on line 1255, 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-12 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track M. Kim, Ed. 4 Expires: April 22, 2011 Corporate Technology Group, KT 5 K. Pister 6 Dust Networks 7 N. Dejean 8 Coronis SAS 9 D. Barthel 10 France Telecom Orange 11 October 19, 2010 13 Routing Metrics used for Path Calculation in Low Power and Lossy 14 Networks 15 draft-ietf-roll-routing-metrics-10 17 Abstract 19 Low power and Lossy Networks (LLNs) have unique characteristics 20 compared with traditional wired and ad-hoc networks that require the 21 specification of new routing metrics and constraints. By contrast 22 with typical Interior Gateway Protocol (IGP) routing metrics using 23 hop counts or link metrics, this document specifies a set of link and 24 node routing metrics and constraints suitable to LLNs to be used by 25 the Routing for Low Power and lossy networks (RPL) routing protocol. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 22, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1. DAG Metric Container format . . . . . . . . . . . . . . . 7 69 2.2. Use of multiple DAG Metric Containers . . . . . . . . . . 10 70 2.3. Metric usage . . . . . . . . . . . . . . . . . . . . . . . 10 71 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 11 72 3.1. Node State and Attributes object . . . . . . . . . . . . . 11 73 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 13 74 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 16 75 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 17 76 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17 77 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 19 79 4.3.1. The Link Quality Level reliability metric . . . . . . 20 80 4.3.2. The Expected Transmission Count (ETX) reliability 81 object . . . . . . . . . . . . . . . . . . . . . . . . 22 82 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 23 83 4.4.1. Link Color object description . . . . . . . . . . . . 23 84 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 25 85 5. Computation of dynamic metrics and attributes . . . . . . . . 25 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 6.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 88 6.2. Routing Metric/Constraint common header . . . . . . . . . 26 89 6.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 90 6.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28 91 7. Security considerations . . . . . . . . . . . . . . . . . . . 28 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 9.1. Normative references . . . . . . . . . . . . . . . . . . . 29 95 9.2. Informative references . . . . . . . . . . . . . . . . . . 29 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 98 1. Introduction 100 This document makes use of the terminology defined in 101 [I-D.ietf-roll-terminology]. 103 Low power and Lossy Networks (LLNs) have specific routing 104 characteristics compared with traditional wired or ad-hoc networks 105 that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and 106 [RFC5867]. 108 Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have 109 used quantitative static link metrics. Other mechanisms such as 110 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see 111 [RFC2702] and [RFC3209]) make use of other link attributes such as 112 the available reserved bandwidth (dynamic) or link affinities (most 113 of the time static) to compute constrained shortest paths for Traffic 114 Engineering Label Switched Paths (TE LSPs). 116 This document specifies routing metrics and constraints to be used in 117 path calculation by the Routing Protocol for Low Power and Lossy 118 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 120 One of the prime objectives of this document is to propose a flexible 121 mechanism for the advertisement of routing metrics and constraints 122 used by RPL. Some RPL implementations may elect to adopt an 123 extremely simple approach based on the use of a single metric with no 124 constraint whereas other implementations may use a larger set of link 125 and node routing metrics and constraints. This specification 126 provides a high degree of flexibility and a set of routing metrics 127 and constraints. New routing metrics and constraints could be 128 defined in the future, as needed. 130 RPL is a distance vector routing protocol that builds Directed 131 Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG 132 formation rules are defined in [I-D.ietf-roll-rpl]: 134 o The DAG root may advertise a routing constraint used as a "filter" 135 to prune links and nodes that do not satisfy specific properties. 136 For example, it may be required for the path to only traverse 137 nodes that are mains powered or links that have at least a minimum 138 reliability or a specific "color" reflecting a user defined link 139 characteristic (e.g the link layer supports encryption). 141 o A routing metric is a quantitative value that is used to evaluate 142 the path cost. Link and node metrics are usually (but not always) 143 additive. 145 The best path is the path with the lowest cost with respect to some 146 metrics that satisfies all constraints (if any). It is also called 147 the shortest constrained path (in the presence of constraints). 149 Routing metrics can be classified according to the following set of 150 characteristics: 152 o Link versus Node metrics 154 o Qualitative versus quantitative 156 o Dynamic versus static 158 As pointed out in various routing requirements documents (see 159 [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to 160 take into account a variety of node constraints/metrics during path 161 computation. 163 Some link or node characteristics (e.g. link reliability flag, 164 remaining energy on the node) may either be used by RPL as routing 165 constraints or metrics. For example, the path may be computed to 166 avoid links that do not provide a sufficient level of reliability 167 (use as a constraint) or as the path offering most links with a 168 specified reliability level (use as a metric). The document provides 169 the flexibility to use link and node characterisics either as 170 constraints and/or metrics. 172 The use of link and node routing metrics and constraints is not 173 exclusive. 175 It is also worth mentioning that it is fairly common for links in 176 LLNs to have fast changing node and link characteristics, which must 177 be taken into account when specifying routing metrics. For instance, 178 in addition to the dynamic nature of some links (e.g. wireless but 179 also Powerline Communication (PLC) links), nodes' resources such as 180 residual energy and other link's characteristics such as the 181 throughput are changing continuously and may have to be taken into 182 account during the path computation. Similarly, link attributes 183 including throughput and reliability may drastically change over time 184 due to multi-path interference. 186 It must be noted that the use of dynamic metrics is not new and has 187 been experimented in ARPANET 2 [Khanna1989], with moderate success. 188 The use of dynamic metrics is not trivial and great care must be 189 given to the use of dynamic metrics since it may lead to potential 190 routing instabilities. it must be noted that the use of dynamic 191 metrics has been largely experimented and deployed in a number of 192 (non IP) networks in the past decade. 194 Very careful attention must be given when using dynamic metrics and 195 attributes that affect routing decisions in order to preserve routing 196 stability. Routing metrics and constraints may either be static or 197 dynamic. When dynamic, a RPL implementation SHOULD make use of a 198 multi-threshold scheme rather than fine granular metric updates so as 199 to avoid constant routing changes. 201 Furthermore, it is a time and energy consuming process to update 202 dynamic metrics and recompute the routing tables on a frequent basis. 203 Therefore, it may be desirable to use a set of discrete values to 204 reduce computational overhead and bandwidth utilization. Of course, 205 this comes with a cost, namely, reduced metric accuracy. In other 206 cases, a set of flags may be defined to reflect a node state without 207 having to define discrete values. 209 The requirements on reporting frequency may differ among metrics, 210 thus different reporting rates may be used for each category and are 211 consequently implementation-specific. 213 The set of routing metrics and constraints used by an RPL 214 implementation is signaled along the Directed Acyclic Graph (DAG) 215 that is built according to the Objective Function (rules governing 216 how to build a DAG) and the routing metrics and constraints are 217 advertised in the DAG Information Option (DIO) message specified in 218 [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different 219 characteristics. For example, it may be desirable to build a DAG 220 with the goal to maximize reliability by using the link reliability 221 metric to compute the "best" path. Another example might be to use 222 the energy node characteristic (e.g. mains powered versus battery 223 operated) as a node constraint when building the DAG so as to avoid 224 battery powered nodes in the DAG while optimizing the link 225 throughput. 227 The specification of objective functions used to compute the DAG 228 built by RPL is out of the scope of this document. Routing metrics 229 and constraints are decoupled from the objective function. So a 230 generic objective function could for example specify the rules to 231 select the best parents in the DAG, the number of backup parents, 232 etc. Such objective function can be used with any routing metrics 233 and/or constraints such as the ones specified in this document. 235 Some metrics are either aggregated or recorded. In the former case, 236 the metric is adjusted as the DIO message travels along the DAG. For 237 example, if the metric is the link latency, each node updates the 238 latency metric along the DAG. By contrast, a metric may be recorded 239 in which case each node adds a sub-object reflecting the local 240 metric. For example, it might be desirable to record the link 241 quality level along the path. In this case, each visited node adds a 242 sub-object reporting the local link quality level. In order to limit 243 the number of sub-objects, the use of a counter may be desirable 244 (e.g. record the number of links with a certain link quality level), 245 thus compressing the information to reduce the message length. Upon 246 receiving the DIO message from a set of parents, a node can decide 247 according to the OF and local policy which node to choose as a parent 248 based on the maximum number of links with a specific link reliability 249 level, for example. 251 Note that the routing metrics and constraints specified in this 252 document are not specific to any link layer. An internal API between 253 the MAC layer and RPL may be used to accurately reflect the metrics 254 values of the link (wireless, wired, PLC). 256 Since a set of metrics and constraints will be used for links and 257 nodes in LLN, it is particularly critical to ensure the use of 258 consistent metric calculation mechanisms for all links and nodes in 259 the network, similarly to the case of inter-domain IP routing. 261 2. Object formats 263 2.1. DAG Metric Container format 265 Routing metrics and constraints are carried within the DAG Metric 266 Container object defined in [I-D.ietf-roll-rpl]. Should multiple 267 metrics and/or constraints be present in the DAG Metric Container, 268 their use to determine the "best" path can be defined by an Objective 269 Function or a new TLV to be defined in future documents. 271 0 1 2 3 4 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 274 | Type=2 | Option Len | Routing Metric/Constraint objects 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 277 Figure 1: DAG Metric Container format 279 The Routing Metric/Constraint objects have a common format consisting 280 of one or more 8-bit words with a common header: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 // (object body) // 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 2: Routing Metric/Constraint object generic format 294 The object body carries one or more sub-objects. 296 Note that the Routing Metric/Constraint objects defined in this 297 document can appear in any order in the DAG Metric Container. 299 Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the 300 Routing Metric/Constraint Type field uniquely identifies each Routing 301 Metric/Constraint object and is managed by IANA. 303 Length: this field defines the length of the object body, in bytes. 305 The Flag field of the Routing Metric/Constraint object is managed by 306 IANA. Unassigned bits are considered as reserved. They MUST be set 307 to zero on transmission and MUST be ignored on receipt. 309 o C Flag. When set, this indicates that the Routing Metric/ 310 Constraint object refers to a routing constraint. When cleared, 311 the routing object refers to a routing metric. 313 o O Flag: The O flag is used exclusively for routing constraints (C 314 flag is set). When set, this indicates that the constraint is 315 optional. When cleared, the constraint is mandatory. If the C 316 flag is zero, the O flag MUST be set to zero on transmission and 317 ignored on reception. 319 o R Flag: The R Flag is only relevant for routing metric (C=0) and 320 MUST be cleared for C=1. When set, this indicates that the 321 routing metric is recorded along the path. Conversely, when 322 cleared, the routing metric is aggregated. 324 o A Field: The A field is used to indicate whether an aggregated 325 routing metric is additive, multiplicative, reports a maximum or a 326 minimum. 328 * A=0x00: The routing metric is additive 329 * A=0x01: The routing metric reports a maximum 331 * A=0x02: The routing metric reports a minimum 333 * A=0x03: The routing metric is multiplicative 335 The A field has no meaning when the C Flag is set (i.e. when the 336 Routing Metric/Constraint object refers to a routing constraint) 337 and MUST be written to 0x00. 339 o Prec field: The Prec field indicates the precedence of this 340 Routing Metric/Constraint object. This is useful when a DAG 341 Metric Container contains several Routing Metric objects. The 342 value 0 means the highest precedence. 344 o P field: the P field is only used for recorded metrics. When 345 cleared, all nodes along the path successfully recorded the 346 corresponding metric. When set, this indicates than one or 347 several nodes along the path could not record the metric of 348 interest (either because of lack of knowledge or because this was 349 prevented by policy). 351 Example 1: A DAG formed by RPL where all nodes must be mains-powered 352 and the best path is the one with lower aggregated ETX. In this case 353 the DAG Metric container carries two Routing Metric/Constraint 354 objects: one is an ETX metric object with header (C=0, O=0, A=00, 355 R=0) and the second one is a Node Energy constraint object with 356 header (C=1, O=0, A=00, R=0). Note that a RPL instance may use the 357 metric object to report a maximum (A=0x01) or a minimum (A=0x02). 358 If, for example, the best path is characterized by the path avoiding 359 low quality links, then the path metric reports a maximum (A=0x01) 360 (note that higher values mean lower link quality): when the link 361 quality metric (ETX) is processed along a path, each node updates the 362 value carried in the metric object by replacing it with its local 363 link ETX value if and only if the latter is higher. 365 Example 2: A DAG formed by RPL where the link metric is the link 366 quality level and link quality levels must be recorded along the 367 path. In this case, the DAG Metric Container carries a Routing 368 Metric/Constraint object: link quality level metric (C=0, O=0, A=00, 369 R=1) containing multiple sub-objects. 371 A Routing Metric/Constraint object may also include one or more 372 type-length-value (TLV) encoded data sets. Each Routing Metric/ 373 Constraint TLV has the same structure: 375 Type: 1 byte 376 Length: 1 byte 377 Value: variable 379 A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 380 1 byte specifying the TLV length, and a value field. The TLV length 381 field defines the length of the value field in bytes. 383 Unrecognized TLVs MUST be ignored. 385 IANA management of the Routing Metric/Constraint objects identifier 386 codespace is described in Section 6. 388 2.2. Use of multiple DAG Metric Containers 390 Since the length of RPL options is encoded using 1 octet, they cannot 391 exceed 256 bytes, which also applies to the DAG Metric Container. In 392 the vast majority of cases, the advertised routing metrics and 393 constraints will not require that much space. However, there might 394 be circumstances where larger space is required, should for example a 395 set of routing metrics be recorded along a long path. In this case, 396 as specified in [I-D.ietf-roll-rpl], routing metrics will be carried 397 using multiple DAG Metric Containers. 399 In the rest of this document, this use of multiple DAG Metric 400 Containers will be considered as if they were actually just one long 401 DAG Metric Container. 403 2.3. Metric usage 405 This section describes how metrics carried in the DAG Metric 406 Container shall be used. 408 When the DAG Metric Container contains a single aggregated metric 409 (scalar value), the order relation to select the best path is 410 implicitly derived from the metric type. For example, lower is 411 better for Hop Count, Link Latency and ETX. Conversely, for Node 412 Energy or Throughput, higher is better. 414 An example of using such a single aggregated metric is optimizing 415 routing for node energy. The Node Energy metric (E-E field) is 416 aggregated along paths with an explicit min function (A field), and 417 the best path is selected through an implied Max function because the 418 metric is Energy. 420 When the DAG Metric Container contains several aggregated metrics, 421 they are to be used as tie-breakers according to their precedence 422 defined by their Prec field values. 424 An example of such use of multiple aggregated metrics is the 425 following: Hop-Count as the primary criterion, LQL as the secondary 426 criterion and Node Energy as the ultimate tie-breaker. In such a 427 case, the Hop-Count, LQL and Node Energy metric objects' Prec fields 428 should bear strictly increasing values such as 0, 1 and 2, 429 respectively. 431 If several aggregated metrics happen to bear the same Prec value, the 432 behavior is implementation-dependant. 434 3. Node Metric/Constraint objects 436 It is fairly common for LLNs to be made of nodes with heterogeneous 437 attributes and capabilities (e.g. nodes being battery operated or 438 not, amount of memory, etc). More capable and stable nodes may 439 assist the most constrained ones for routing packets, which results 440 in extension of network lifetime and efficient network operations. 441 This is a typical (but non-exclusive) use of constraint-based 442 routing, where the computed path may not be the shortest path 443 according to some specified metrics. Another use is to find the 444 shortest path according to a pre-defined metric while avoiding links 445 with a specific color (for example "non-secured link"). 447 3.1. Node State and Attributes object 449 The Node State and Attribute (NSA) object is used to provide 450 information on the nodes characteristics. 452 The NSA object MAY be present in the DAG Metric Container. There 453 MUST be no more than one NSA object as a constraint per DAG Metric 454 Container, and no more than one NSA object as a metric per DAG Metric 455 Container. 457 The NSA object may also contain a set of TLVs used to convey various 458 node characteristics. No TLV is currently defined. 460 The NSA Routing Metric/Constraint Type is to be assigned by IANA 461 (recommended value=1). 463 The format of the NSA object body is as follows: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 468 | Res | Flags |A|O| Optional TLVs 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 471 Figure 3: NSA object format 473 Node workload may be hard to determine and express in some scalar 474 form. However, node workload could be a useful metric to consider 475 during path calculation, in particular when queuing delays must be 476 minimized for highly sensitive traffic considering Medium Access 477 Control (MAC) layer delay. Node workload MAY be set upon CPU 478 overload, lack of memory or any other node related conditions. Using 479 a simple 1-bit flag to characterize the node workload provides a 480 sufficient level of granularity, similarly to the "overload" bit used 481 in routing protocols such as IS-IS. Algorithms used to set the 482 overload bit and to compute paths to potentially avoid nodes with 483 their overload bit set are outside the scope of this document, but it 484 is RECOMMENDED to avoid frequent changes of this bit to avoid routing 485 oscillations. 487 Data Aggregation Attribute: data fusion involves more complicated 488 processing to improve the accuracy of the output data, while data 489 aggregation mostly aims at reducing the amount of data. This is 490 listed as a requirement in Section 6.2 of [RFC5548]. Some 491 applications may make use of the aggregation node attribute in their 492 routing decision so as to minimize the amount of traffic on the 493 network, thus potentially increasing its lifetime in battery operated 494 environments. Applications where highly directional data flow is 495 expected on a regular basis may take advantage of data aggregation 496 supported routing. 498 The following two bits of the NSA object are currently defined: 500 o A Flag: When set, this indicates that the node can act as a 501 traffic aggregator. An implementation MAY decide to add optional 502 TLVs (not currently defined) to further describe the node traffic 503 aggregator functionality. 505 o O Flag: When set, this indicates that the node is overloaded and 506 may not be able to process traffic. 508 The Flag field of the NSA Routing Metric/Constraint object is managed 509 by IANA. Unassigned bits are considered as reserved. They MUST be 510 set to zero on transmission and MUST be ignored on receipt. 512 3.2. Node Energy object 514 Whenever possible, a node with low residual energy should not be 515 selected as a router, thus the support for constraint-based routing 516 is needed. In such cases, the routing protocol engine may compute a 517 longer path (constraint based) for some traffic in order to increase 518 the network life duration. 520 The routing engine may prefer a "longer" path that traverses mains- 521 powered nodes (in particular for routine traffic) or nodes equipped 522 with energy scavenging, rather than a "shorter" path through battery 523 operated nodes. 525 Power and energy are clearly critical resources in most LLNs. As yet 526 there is no simple abstraction which adequately covers the broad 527 range of power sources and energy storage devices used in existing 528 LLN nodes. These include mains-powered, primary batteries, energy 529 scavengers, and a variety of secondary storage mechanisms. 530 Scavengers may provide a reliable low level of power, such as might 531 be available from a 4-20mA loop; a reliable but periodic stream of 532 power, such as provided by a well-positioned solar cell; or 533 unpredictable power, such as might be provided by a vibrational 534 energy scavenger on an intermittently powered pump. Routes which are 535 viable when the sun is shining may disappear at night. A pump 536 turning on may connect two previously disconnected sections of a 537 network. 539 Storage systems like rechargeable batteries often suffer substantial 540 degradation if regularly used to full discharge, leading to different 541 residual energy numbers for regular versus emergency operation. A 542 route for emergency traffic may have a different optimum than one for 543 regular reporting. 545 Batteries used in LLNs often degrade substantially if their average 546 current consumption exceeds a small fraction of the peak current that 547 they can deliver. It is not uncommon for self-supporting nodes to 548 have a combination of primary storage, energy scavenging, and 549 secondary storage, leading to three different values for acceptable 550 average current depending on the time frame being considered, e.g. 551 milliseconds, seconds, and hours/years. 553 Raw power and energy values are meaningless without knowledge of the 554 energy cost of sending and receiving packets, and lifetime estimates 555 have no value without some higher-level constraint on the lifetime 556 required of a device. In some cases the path that exhausts the 557 battery of a node on the bed table in a month may be preferable to a 558 route that reduces the lifetime of a node in the wall to a decade. 560 Given the complexity of trying to address such a broad collection of 561 constraints, this document defines three levels of fidelity in the 562 solution. 564 The simplest solution relies on a 2-bit field encoding three types of 565 power sources: "powered", "battery", "scavenger". This simple 566 approach may be sufficient for many applications. 568 The mid-complexity solution is a single parameter that can be used to 569 encode the energetic happiness of both battery powered and scavenging 570 nodes. For scavenging nodes, the 8 bit quantity is the power 571 provided by the scavenger divided by the power consumed by the 572 application, H=P_in/P_out, in units of percent. Nodes which are 573 scavenging more power than they are consuming will register above 574 100. A good time period for averaging power in this calculation may 575 be related to the discharge time of the energy storage device on the 576 node, but specifying this is out of the scope of this document. For 577 battery powered devices, H is the current expected lifetime divided 578 by the desired minimum lifetime. The estimation of remaining battery 579 energy and actual power consumption can be difficult, and the 580 specifics of this calculation are out of scope of this document, but 581 two examples are presented. If the node can measure its average 582 power consumption, then H can be calculated as the ratio of desired 583 max power (initial energy E_0 divided by desired lifetime T) to 584 actual power, H=P_max/P_now. Alternatively, if the energy in the 585 battery E_bat can be estimated, and the total elapsed lifetime, t, is 586 available, then H can be calculated as the total stored energy 587 remaining versus the target energy remaining: H= E_bat / [E_0 588 (T-t)/T]. 590 An example of optimized route is max(min(H)) for all battery operated 591 nodes along the route, subject to the constraint that H>=100 for all 592 scavengers along the route. 594 Note that the estimated percentage of remaining energy indicated in 595 the E-E field may not be useful in the presence of nodes powered by 596 battery or energy scavengers when the amount of energy accumulated by 597 the device significantly differ. Indeed, X% of remaining energy on a 598 node that can store a large amount of energy cannot be easily 599 compared to the same percentage of remaining energy on a node powered 600 by a tiny source of energy. That being said, in networks where nodes 601 have relatively close energy storage, such a percentage of remaining 602 energy is useful. Other documents may define more complex/detailed 603 mechanisms to represent these metric. 605 The Node Energy (NE) object is used to provide information related to 606 node energy and may be used as a metric or as constraint. 608 The NE object MAY be present in the DAG Metric Container. There MUST 609 be no more than one NE object as a constraint per DAG Metric 610 Container, and no more than one NE object as a metric per DAG Metric 611 Container. 613 The NE object Type is to be assigned by IANA (recommended value=2). 615 The format of the NE object body is as follows: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 620 | NE Sub-objects 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 623 Figure 4: NE object format 625 The format of the NE sub-object body is as follows: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 630 | Flags |I| T |E| E-E | Optional TLVs 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 633 Figure 5: NE sub-object format 635 The NE sub-object may also contain a set of TLVs used to convey 636 various nodes' characteristics. 638 The following flags are currently defined: 640 o I (Included): the I bit is only relevant when the node type is 641 used as a constraint. For example, the path must only traverse 642 mains-powered nodes. Conversely, battery operated nodes must be 643 excluded. The I bit is used to stipulate inclusion versus 644 exclusion. When set, this indicates that nodes of the type 645 specified in the node type field MUST be included. Conversely, 646 when cleared, this indicates that nodes of type specified in the 647 node type field MUST be excluded. 649 o T (node Type): 2-bit field indicating the node type. E=0x00 650 designates a mains-powered node, E=0x01 a battery-powered node and 651 E=0x02 a node powered by an energy scavenger. 653 o E (Estimation): when the E bit is set for a metric, the estimated 654 percentage of remaining energy on the node is indicated in the E-E 655 8-bit field. When cleared, the estimated percentage of remaining 656 energy is not provided. When the E bit is set for a constraint, 657 the E-E field defines a threshold for the inclusion/exclusion: if 658 an inclusion, nodes with values higher than the threshold are to 659 be included; if an exclusion, nodes with values lower than the 660 threshold are to be excluded. 662 E-E (Estimated-Energy): 8-bit unsigned integer field indicating an 663 estimated percentage of remaining energy. The E-E field is only 664 relevant when the E flag is set, and MUST be set to 0 when the E flag 665 is cleared. 667 If the NE object comprises several sub-objects when used as a 668 constraint, each sub-object adds or subtracts node subsets as the 669 sub-objects are parsed in order. The initial set (full or empty) is 670 defined by the I bit of the first sub-object: full if that I bit is 671 an exclusion, empty is that I bit is an inclusion. 673 No TLV is currently defined. 675 Future addenda to this document may include more complex solutions 676 involving a half dozen TLV parameters representing energy storage, 677 consumption, and generation capabilities of the node, as well as 678 desired lifetime. 680 3.3. Hop-Count object 682 The HoP-Count (HP) object is used to report the number of traversed 683 nodes along the path. 685 The HP object MAY be present in the DAG Metric Container. There MUST 686 be no more than one HP object as a constraint per DAG Metric 687 Container, and no more than one HP object as a metric per DAG Metric 688 Container. 690 The HP object may also contain a set of TLVs used to convey various 691 node characteristics. No TLV is currently defined. 693 The HP routing metric object Type is to be assigned by IANA 694 (recommended value=3) 695 The format of the Hop Count object body is as follows: 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 700 | Res | Flags | Hop Count | Optional TLVs 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 703 Figure 6: Hop Count object format 705 No Flag is currently defined. 707 The HP object may be used as a constraint or a metric. When used as 708 a constraint, the DAG root indicates the maximum number of hops that 709 a path may traverse. When that number is reached, no other node can 710 join that path. When used as a metric, each visited node simply 711 increments the Hop Count field. 713 4. Link Metric/Constraint objects 715 4.1. Throughput 717 Many LLNs support a wide range of throughputs. For some links, this 718 may be due to variable coding. For the deeply duty-cycled links 719 found in many LLNs, the variability comes as a result of trading 720 power consumption for bit rate. There are several MAC layer 721 protocols which allow for the effective bit rate and power 722 consumption of a link to vary over more than three orders of 723 magnitude, with a corresponding change in power consumption. For 724 efficient operation, it may be desirable for nodes to report the 725 range of throughput that their links can handle in addition to the 726 currently available throughput. 728 The Throughput object MAY be present in the DAG Metric Container. 729 There MUST be no more than one Throughput object as a constraint per 730 DAG Metric Container, and no more than one Throughput object as a 731 metric per DAG Metric Container. 733 The Throughput object is made of throughput sub-objects and MUST at 734 least comprise one Throughput sub-object. The first Throughput sub- 735 object MUST be the most recently estimated actual throughput. The 736 actual estimation of the throughput is outside the scope of this 737 document. 739 Each Throughput sub-object has a fixed length of 4 bytes. 741 The Throughput object does not contain any additional TLV. 743 The Throughput object Type is to be assigned by IANA (recommended 744 value=4) 746 The format of the Throughput object body is as follows: 748 0 1 749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | (sub-object) ..... 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 8: Throughput object body format 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Throughput | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Figure 9: Throughput sub-object format 764 Throughput: 32 bits. The Throughput is encoded in 32 bits in 765 unsigned integer format, expressed in bytes per second. 767 4.2. Latency 769 Similarly to throughput, the latency of many LLN MAC sub-layers can 770 vary over many orders of magnitude, again with a corresponding change 771 in current consumption. Some LLN MAC link layers will allow the 772 latency to be adjusted globally on the subnet, on a link-by-link 773 basis, or not at all. Some will insist that it be fixed for a given 774 link, but allow it to be variable from link to link. 776 The Latency object MAY be present in the DAG Metric Container. There 777 MUST be no more than one Latency object as a constraint per DAG 778 Metric Container, and no more than one Latency object as a metric per 779 DAG Metric Container. 781 The Latency object is made of Latency sub-objects and MUST at least 782 comprise one Latency sub-object. Each Latency sub-object has a fixed 783 length of 4 bytes. 785 The Latency object does not contain any additional TLV. 787 The Latency object Type is to be assigned by IANA (recommended 788 value=5) 789 The Latency object is a metric or constraint. 791 The format of the Latency object body is as follows: 793 0 1 794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | (sub-object) ..... 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Figure 10: Latency object body format 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Latency | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Figure 11: Latency sub-object format 809 Latency: 32 bits. The Latency is encoded in 32 bits in unsigned 810 integer format, expressed in microseconds. 812 The Latency object may be used as a constraint or a path metric. For 813 example, one may want the latency not to exceed some value. In this 814 case, the Latency object common header indicates that the provided 815 value relates to a constraint. In another example, the Latency 816 object may be used as an aggregated additive metric where the value 817 is updated along the path to reflect the path latency. 819 4.3. Link reliability 821 In LLNs, link reliability is degraded by external interference and 822 multi-path interference (wireless links). Multipath typically 823 affects both directions on the link equally, whereas external 824 interference is sometimes unidirectional. Time scales vary from 825 milliseconds to days, and are often periodic and linked to human 826 activity. Packet error rates can generally be measured directly, and 827 other metrics (e.g. bit error rate, mean time between failures) are 828 typically derived from that. Note that such variability is not 829 specific to wireless link but also applies to PLC links. 831 A change in link quality can affect network connectivity, thus, link 832 quality may be taken into account as a critical routing metric. 834 A number of link reliability metrics could be defined reflecting 835 several reliability aspects. Two link reliability metrics are 836 defined in this document: the Link Quality Level (LQL) and the 837 Expected Transmission count Metric (ETX). 839 Note that an RPL implementation MAY either use the LQL, the ETX or 840 both. 842 4.3.1. The Link Quality Level reliability metric 844 The Link Quality Level (LQL) object is used to quantify the link 845 reliability using a discrete value, from 0 to 7 where 0 indicates 846 that the link quality level is unknown and 1 reports the highest link 847 quality level. The mechanisms and algorithms used to compute the LQL 848 are implementation specific and outside of the scope of this 849 document. 851 The LQL can either be used as a metric or a constraint. When used as 852 a metric, the LQL metric can be recorded or aggregated. For example, 853 the DAG Metric object may request all traversed nodes to record the 854 LQL of their incoming link into the LQL object. Each node can then 855 use the LQL record to select its parent based on some user defined 856 rules (e.g. something like "select the path with most links reporting 857 a LQL value of 3 or less"). By contrast, the LQL link metric may be 858 aggregated, in which case the sum of all LQLs may be reported 859 (additive metric) or the minimum value may be reported along the 860 path. 862 When used as a recorded metric, counters are used to compress the 863 information: for each encountered LQL value, only the number of 864 matching links is reported. 866 The LQL object MAY be present in the DAG Metric Container. There 867 MUST be no more than one LQL object as a constraint per DAG Metric 868 Container, and no more than one LQL object as a metric per DAG Metric 869 Container. 871 The LQL object MUST contain one or more sub-object used to report the 872 number of links along with their LQL. 874 The LQL object Type is to be assigned by IANA (recommended value=6) 875 The format of the LQL object body is as follows: 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 880 | Res | LQL sub-object 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 883 Figure 12: LQL object format 885 When the LQL metric is recorded, the LQL object body comprises one or 886 more LQL Type 1 sub-object. 888 The format of the LQL Type 1 sub-object is as follows 890 0 891 0 1 2 3 4 5 6 7 892 +-+-+-+-+-+-+-+-+ 893 | Val | Counter | 894 +-+-+-+-+-+-+-+-+ 896 Figure 13: LQL Type 1 sub-object format 898 Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates 899 the highest link quality. 901 Counter: number of links with that value. 903 When the LQL metric is aggregated, the LQL object body comprises one 904 LQL Type 2 sub-object: 906 The format of the LQL Type 2 sub-object is as follows 908 0 1 909 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Aggregated LQL Value | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 14: LQL Type 2 sub-object format 916 Aggregated LQL Value: when used as an additive metric (A=0x00), the 917 aggregated LQL value reports the sum of all the LQL values for all 918 links along the path. When used to report a minimum (A=0x02), the 919 field reports the minimum LQL value of all links along the path, 920 ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to 921 report a maximum (A=0x01), the field reports the maximum LQL value of 922 all links along the path. When used to report a multiplication 923 (A=0x03), and the LQL field of one of the links along the path is 924 undetermined (LQL=0), the undetermined LQL will be ignored and not be 925 aggregated (i.e. no reset to Aggregated LQL Value field). 927 4.3.2. The Expected Transmission Count (ETX) reliability object 929 The Expected Transmission Count (ETX) metric is the number of 930 transmissions a node expects to make to a destination in order to 931 successfully deliver a packet. 933 For example, an implementation may use the following formula: ETX= 1 934 / (Df * Dr) where Df is the measured probability that a packet is 935 received by the neighbor and Dr is the measured probability that the 936 acknowledgment packet is successfully received. This document does 937 not mandate the use of a specific formula to compute the ETX value. 939 The ETX object MAY be present in the DAG Metric Container. There 940 MUST be no more than one ETX object as a constraint per DAG Metric 941 Container, and no more than one ETX object as a metric per DAG Metric 942 Container. 944 The ETX object is made of ETX sub-objects and MUST at least comprise 945 one ETX sub-object. Each ETX sub-object has a fixed length of 8 946 bits. 948 The ETX object does not contain any additional TLV. 950 The ETX object Type is to be assigned by IANA (recommended value=7) 951 The format of the ETX object body is as follows: 953 0 1 954 0 1 2 3 4 5 6 7 8 9 0 1 2 3 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | (sub-object) ..... 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Figure 15: ETX object body format 961 0 1 962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | ETX | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 16: ETX sub-object format 969 ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned 970 integer format, rounded off to the nearest whole number. For 971 example, if ETX = 3.569, the object value will be 457. If ETX > 972 511.9921875, the object value will be the maximum which is 65535. 974 The ETX object may be used as a constraint or a path metric. For 975 example, it may be required that the ETX must not exceed some 976 specified value. In this case, the ETX object common header 977 indicates that the value relates to a constraint. In another 978 example, the ETX object may be used as an aggregated additive metric 979 where the value is updated along the path to reflect the path 980 quality. 982 4.4. Link Color object 984 4.4.1. Link Color object description 986 The Link Color (LC) object is an administrative 10-bit link 987 constraint (which may either be static or dynamically adjusted) used 988 to avoid or attract specific links for specific traffic types. 990 The LC object can either be used as a metric or as a constraint. 991 When used as a metric, the LC metric can only be recorded. For 992 example, the DAG may require recording the link colors for all 993 traversed links. Each node can then use the LC to select the parent 994 based on user defined rules (e.g. "select the path with the maximum 995 number of links having their first bit set 1 (e.g. encrypted 996 links)"). The LC object may also be used as a constraint. 998 When used as a recorded metric, a counter is used to compress the 999 information where the number of links for each Link Color is 1000 reported. 1002 The Link Color (LC) object MAY be present in the DAG Metric 1003 Container. There MUST be no more than one LC object as a constraint 1004 per DAG Metric Container, and no more than one LC object as a metric 1005 per DAG Metric Container. 1007 There MUST be a at least one LC sub-object per LC object. 1009 The LC object does not contain any additional TLV. 1011 The LC object Type is to be assigned by IANA (recommended value=8) 1013 The format of the LC object body is as follows: 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1018 | Res | LC sub-objects 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1021 Figure 17: LC object format 1023 When the LC object is used as a recorded metric, the LC object body 1024 comprises one or more LC Type 1 sub-objects. 1026 The format of the LC Type 1 sub-object body is as follows: 1028 0 1 1029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Link Color | Counter | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure 18: LC Type 1 sub-object format 1036 When the LC object is used as a constraint, the LC object body 1037 comprises one or more LC Type 2 sub-objects. 1039 The format of the LC Type 2 sub-object body is as follows: 1041 0 1 1042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Link Color |I| 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Figure 19: LC Type 2 sub-object format 1049 I Bit: The I bit is only relevant when the Link Color is used as a 1050 constraint. When cleared, this indicates that links with the 1051 specified color must be included. When set, this indicates that 1052 links with the specified color must be excluded. 1054 The use of the LC object is outside the scope of this document. 1056 4.4.2. Mode of operation 1058 The link color may be used as a constraint or a metric. 1060 o When used as constraint, the LC object may be inserted in the DAG 1061 Metric Container to indicate that links with a specific color 1062 should be included or excluded from the computed path. 1064 o When used as recorded metric, each node along the path may insert 1065 a LC object in the DAG Metric Container to report the color of the 1066 local link. If there is already a LC object reporting a similar 1067 color, the node MUST NOT add another identical LC sub-object and 1068 MUST increment the counter field. 1070 5. Computation of dynamic metrics and attributes 1072 As already pointed out, dynamically calculated metrics are of the 1073 utmost importance in many circumstances in LLNs. This is mainly 1074 because a variety of metrics change on a frequent basis, thus 1075 implying the need to adapt the routing decisions. That being said, 1076 care must be given to the pace at which changes are reported in the 1077 network. The attributes will change according to their own time 1078 scales. RPL controls the reporting rate. 1080 To minimize metric updates, multi-threshold algorithms MAY be used to 1081 determine when updates should be sent. When practical, low-pass 1082 filtering and/or hysteresis should be used to avoid rapid 1083 fluctuations of these values. Finally, although the specification of 1084 path computation algorithms using dynamic metrics are out the scope 1085 of this document, it is RECOMMENDED to carefully design the route 1086 optimization algorithm to avoid too frequent computation of new 1087 routes upon metric values changes. 1089 Controlled adaptation of the routing metrics and rate at which paths 1090 are computed are critical to avoid undesirable routing instabilities 1091 resulting in increased latencies and packet loss because of temporary 1092 micro-loops. Furthermore, excessive route changes will adversely 1093 impact the traffic and power consumption in the network, thus 1094 potentially impacting its scalability. 1096 6. IANA Considerations 1098 IANA is requested to establish a new top-level registry to contain 1099 all Routing Metric/Constraint objects codepoints and sub-registries. 1101 The allocation policy for each new registry is by IETF Consensus: new 1102 values are assigned through the IETF consensus process (see 1103 [RFC5226]). Specifically, new assignments are made via RFCs approved 1104 by the IESG. Typically, the IESG will seek input on prospective 1105 assignments from appropriate persons (e.g., a relevant Working Group 1106 if one exists). 1108 6.1. Routing Metric/Constraint type 1110 IANA is requested to create a registry for Routing Metric/Constraint 1111 objects. Each Routing Metric/Constraint object has a type value. 1113 Value Meaning Reference 1114 1 Node State and Attribute This document 1115 2 Node Energy This document 1116 3 Hop Count This document 1117 4 Link Throughput This document 1118 5 Link Latency This document 1119 6 Link Quality Level This document 1120 7 Link ETX This document 1121 8 Link Color This document 1123 6.2. Routing Metric/Constraint common header 1125 IANA is requested to create a registry to manage the codespace of the 1126 A field of the Routing Metric/Constraint common header. 1128 Codespace of the A field (Routing Metric/Constraint common header) 1129 Value Meaning Reference 1131 0 Routing metric is additive This document 1132 1 Routing metric reports a maximum This document 1133 2 Routing metric reports a minimum This document 1134 3 Routing metric is multiplicative This document 1136 IANA is requested to create a registry to manage the Flag field of 1137 the Routing Metric/Constraint common header. 1139 New bit numbers may be allocated only by an IETF Consensus action. 1140 Each bit should be tracked with the following qualities: 1142 o Bit number 1144 o Capability Description 1146 o Defining RFC 1148 Several bits are defined for the Routing Metric/Constraint common 1149 header in this document. The following values have been assigned: 1151 Codespace of the Flag field (Routing Metric/Constraint common header) 1152 Bit Description Reference 1154 12-15 Precedence This document 1155 9-11 Additive/Max/Min/Multi This document 1156 8 Recorded/Aggregated This document 1157 7 Optional Constraint This document 1158 6 Constraint/Metric This document 1159 5 P (Partial) This document 1161 6.3. NSA object 1163 IANA is requested to create a registry to manage the codespace of the 1164 Flag field of the NSA object. 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 NSA object flag field in this 1176 document. The following values have been assigned: 1178 Codespace of the Flag field (NSA object) 1179 Bit Description Reference 1181 14 Aggregator This document 1182 15 Overloaded This document 1184 6.4. Hop-Count object 1186 IANA is requested to create a registry to manage the codespace of the 1187 Flag field of the Hop-count object. 1189 New bit numbers may be allocated only by an IETF Consensus action. 1190 Each bit should be tracked with the following qualities: 1192 o Bit number 1194 o Capability Description 1196 o Defining RFC 1198 No Flag is currently defined. 1200 7. Security considerations 1202 Routing metrics should be handled in a secure and trustful manner. 1203 For instance, RPL should not allow a malicious node to falsely 1204 advertise that it has good metrics for routing, be added as a router 1205 for other nodes' traffic and intercept packets. Since the routing 1206 metrics/constraints are carried within RPL message, the security 1207 routing mechanisms defined in [I-D.ietf-roll-rpl] applies here. 1209 8. Acknowledgements 1211 The authors would like to acknowledge the contributions of Young Jae 1212 Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip 1213 Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru 1214 Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, 1215 Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads 1216 Westergreen and Mukul Goyal for their review and valuable comments. 1218 9. References 1219 9.1. Normative references 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1225 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1226 May 2008. 1228 9.2. Informative references 1230 [I-D.ietf-roll-rpl] 1231 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1232 Kelsey, R., Levis, P., Networks, D., Struik, R., and J. 1233 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1234 Lossy Networks", draft-ietf-roll-rpl-12 (work in 1235 progress), October 2010. 1237 [I-D.ietf-roll-terminology] 1238 Vasseur, J., "Terminology in Low power And Lossy 1239 Networks", draft-ietf-roll-terminology-04 (work in 1240 progress), September 2010. 1242 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1243 dual environments", RFC 1195, December 1990. 1245 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1247 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1248 McManus, "Requirements for Traffic Engineering Over MPLS", 1249 RFC 2702, September 1999. 1251 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1252 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1253 Tunnels", RFC 3209, December 2001. 1255 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1256 (GMPLS) Signaling Functional Description", RFC 3471, 1257 January 2003. 1259 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1260 "Routing Requirements for Urban Low-Power and Lossy 1261 Networks", RFC 5548, May 2009. 1263 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1264 "Industrial Routing Requirements in Low-Power and Lossy 1265 Networks", RFC 5673, October 2009. 1267 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1268 Routing Requirements in Low-Power and Lossy Networks", 1269 RFC 5826, April 2010. 1271 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1272 "Building Automation Routing Requirements in Low-Power and 1273 Lossy Networks", RFC 5867, June 2010. 1275 Authors' Addresses 1277 JP Vasseur (editor) 1278 Cisco Systems, Inc 1279 11, Rue Camille Desmoulins 1280 Issy Les Moulineaux, 92782 1281 France 1283 Email: jpv@cisco.com 1285 Mijeom Kim (editor) 1286 Corporate Technology Group, KT 1287 17 Woomyeon-dong, Seocho-gu 1288 Seoul, 137-792 1289 Korea 1291 Email: mjkim@kt.com 1293 Kris Pister 1294 Dust Networks 1295 30695 Huntwood Ave. 1296 Hayward, CA 95544 1297 USA 1299 Email: kpister@dustnetworks.com 1301 Nicolas Dejean 1302 Coronis SAS 1303 Espace Concorde, 120 impasse JB Say 1304 Perols, 34470 1305 France 1307 Email: nicolas.dejean@coronis.com 1308 Dominique Barthel 1309 France Telecom Orange 1310 28 chemin du Vieux Chene, BP 98 1311 Meylan, 38243 1312 France 1314 Email: dominique.barthel@orange-ftgroup.com