idnits 2.17.1 draft-ietf-roll-routing-metrics-13.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 29) being 59 lines 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 (December 6, 2010) is 4884 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) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-15 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 Summary: 1 error (**), 0 flaws (~~), 4 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: June 5, 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 December 6, 2010 13 Routing Metrics used for Path Calculation in Low Power and Lossy 14 Networks 15 draft-ietf-roll-routing-metrics-13 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 June 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 25 87 6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 26 88 6.2. Routing Metric/Constraint TLV . . . . . . . . . . . . . . 26 89 6.3. Routing Metric/Constraint Common Header . . . . . . . . . 26 90 6.4. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 27 91 6.5. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 27 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 96 9.2. Informative references . . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 This document makes use of the terminology defined in 102 [I-D.ietf-roll-terminology]. 104 Low power and Lossy Networks (LLNs) have specific routing 105 characteristics compared with traditional wired or ad-hoc networks 106 that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and 107 [RFC5867]. 109 Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have 110 used quantitative static link metrics. Other mechanisms such as 111 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see 112 [RFC2702] and [RFC3209]) make use of other link attributes such as 113 the available reserved bandwidth (dynamic) or link affinities (most 114 of the time static) to compute constrained shortest paths for Traffic 115 Engineering Label Switched Paths (TE LSPs). 117 This document specifies routing metrics and constraints to be used in 118 path calculation by the Routing Protocol for Low Power and Lossy 119 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 121 One of the prime objectives of this document is to define a flexible 122 mechanism for the advertisement of routing metrics and constraints 123 used by RPL. Some RPL implementations may elect to adopt an 124 extremely simple approach based on the use of a single metric with no 125 constraint whereas other implementations may use a larger set of link 126 and node routing metrics and constraints. This specification 127 provides a high degree of flexibility and a set of routing metrics 128 and constraints. New routing metrics and constraints could be 129 defined in the future, as needed. 131 RPL is a distance vector routing protocol variant that builds 132 Directed Acyclic Graphs (DAGs) based on routing metrics and 133 constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: 135 o The Destination Oriented Directed Acyclic Graph (DODAG) root as 136 defined in [I-D.ietf-roll-rpl] may advertise a routing constraint 137 used as a "filter" to prune links and nodes that do not satisfy 138 specific properties. For example, it may be required for the path 139 to only traverse nodes that are mains powered or links that have 140 at least a minimum reliability or a specific "color" reflecting a 141 user defined link characteristic (e.g the link layer supports 142 encryption). 144 o A routing metric is a quantitative value that is used to evaluate 145 the path cost. Link and node metrics are usually (but not always) 146 additive. 148 The best path is the path that satisfies all supplied constraints (if 149 any) and that has the lowest cost with respect to some specified 150 metrics. It is also called the shortest constrained path (in the 151 presence of constraints). 153 Routing metrics may be categorized according to the following 154 characteristics: 156 o Link versus Node metrics 158 o Qualitative versus quantitative 160 o Dynamic versus static 162 Routing requirements documents (see [RFC5673], [RFC5826] [RFC5548] 163 and [RFC5867]) observe that it must be possible to take into account 164 a variety of node constraints/metrics during path computation. 166 Some link or node characteristics (e.g. link reliability, remaining 167 energy on the node) may be used by RPL either as routing constraints 168 or as metrics. For example, the path may be computed to avoid links 169 that do not provide a sufficient level of reliability (use as a 170 constraint) or as the path offering most links with a specified 171 reliability level (use as a metric). This document provides the 172 flexibility to use link and node characterisics either as constraints 173 and/or metrics. 175 The use of link and node routing metrics and constraints is not 176 exclusive (e.g. it is possible to advertise a "hop count" both as a 177 metric to optimize the computed path and as a constraint (e.g. "Path 178 should not exceed n hops")). 180 Links in LLN commonly have rapidly changing node and link 181 characteristics: thus routing metrics must be dynamic and techniques 182 must be used to smooth out the dynamicity of these metrics so as to 183 avoid routing oscillations. For instance, in addition to the dynamic 184 nature of some links (e.g. wireless but also Powerline Communication 185 (PLC) links), nodes' resources such as residual energy are changing 186 continuously and may have to be taken into account during the path 187 computation. 189 It must be noted that the use of dynamic metrics is not new and has 190 been experimented in ARPANET 2 (see [[Khanna1989J]). The use of 191 dynamic metrics is not trivial and great care must be given to the 192 use of dynamic metrics since it may lead to potential routing 193 instabilities. That being said, lots of experience has been gained 194 over the years on the use of dynamic routing metrics, which have been 195 deployed in a number of (non IP) networks. 197 Very careful attention must be given to the pace at which routing 198 metrics and attributes values change in order to preserve routing 199 stability. When using a dynamic routing metric, a RPL implementation 200 should make use of a multi-threshold scheme rather than fine granular 201 metric updates reflecting each individual change to avoid spurious 202 and unneccessary routing changes. 204 The requirements on reporting frequency may differ among metrics, 205 thus different reporting rates may be used for each metric. 207 The set of routing metrics and constraints used by an RPL deployment 208 is signaled along the DAG that is built according to the Objective 209 Function (rules governing how to build a DAG) and the routing metrics 210 and constraints are advertised in the DAG Information Option (DIO) 211 message specified in [I-D.ietf-roll-rpl]. RPL may be used to build 212 DAGs with different characteristics. For example, it may be 213 desirable to build a DAG with the goal to maximize reliability by 214 using the link reliability metric to compute the "best" path. 215 Another example might be to use the energy node characteristic (e.g. 216 mains powered versus battery operated) as a node constraint when 217 building the DAG so as to avoid battery powered nodes in the DAG 218 while optimizing the link throughput. 220 The specification of objective functions used to compute the DAG 221 built by RPL is out of the scope of this document. This document 222 defines routing metrics and constraints that are decoupled from the 223 objective function. So a generic objective function could for 224 example specify the rules to select the best parents in the DAG, the 225 number of backup parents, etc and could be used with any routing 226 metrics and/or constraints such as the ones specified in this 227 document. 229 Some metrics are either aggregated or recorded. An aggregated metric 230 is adjusted as the DIO message travels along the DAG. For example, 231 if the metric is the number of hops, each node updates the path cost 232 that reflects the number of traversed hops along the DAG. By 233 contrast, for a recorded metric, each node adds a sub-object 234 reflecting the local valuation of the metric. For example, it might 235 be desirable to record the link quality level along a path. In this 236 case, each visited node adds a sub-object recording the local link 237 quality level. In order to limit the number of sub-objects, the use 238 of a counter may be desirable (e.g. record the number of links with a 239 certain link quality level), thus compressing the information to 240 reduce the message length. Upon receiving the DIO message from a set 241 of parents, a node might decide according to the OF and local policy 242 which node to choose as a parent based on the maximum number of links 243 with a specific link reliability level, for example. 245 Note that the routing metrics and constraints specified in this 246 document are not specific to any particular link layer. An internal 247 API between the MAC layer and RPL may be used to accurately reflect 248 the metrics values of the link (wireless, wired, PLC). 250 Since a set of metrics and constraints will be used for links and 251 nodes in LLN, it is critical to ensure the use of consistent metric 252 calculation mechanisms for all links and nodes in the network, 253 similarly to the case of inter-domain IP routing. 255 2. Object Formats 257 2.1. DAG Metric Container Format 259 Routing metrics and constraints are carried within the DAG Metric 260 Container object defined in [I-D.ietf-roll-rpl]. Should multiple 261 metrics and/or constraints be present in the DAG Metric Container, 262 their use to determine the "best" path can be defined by an Objective 263 Function. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 268 | Type=2 | Option Len |Routing Metric/Constraint objects 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 271 Figure 1: DAG Metric Container format 273 The Routing Metric/Constraint objects represent a metric or a 274 constraint of a particular type. They may appear in any order in the 275 DAG Metric Container. They have a common format consisting of one or 276 more bytes with a common header: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 // (object body) // 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: Routing Metric/Constraint object generic format 290 The object body carries one or more sub-objects defined later in this 291 document. Note that an object may carry TLV, which may itself 292 comprise other TLVs. A TLV carried within a TLV is called a TLV in 293 this specification. 295 Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the 296 Routing Metric/Constraint Type field uniquely identifies each Routing 297 Metric/Constraint object and is managed by IANA. 299 Length: this field defines the length of the object body, in bytes. 301 Flag field of the Routing Metric/Constraint object: 303 o P flag: the P field is only used for recorded metrics. When 304 cleared, all nodes along the path successfully recorded the 305 corresponding metric. When set, this indicates than one or 306 several nodes along the path could not record the metric of 307 interest (either because of lack of knowledge or because this was 308 prevented by policy). 310 o C Flag. When set, this indicates that the Routing Metric/ 311 Constraint object refers to a routing constraint. When cleared, 312 the routing object refers to a routing metric. 314 o O Flag: The O flag is used exclusively for routing constraints (C 315 flag is set). When set, this indicates that the constraint 316 specified in the body of the object is optional. When cleared, 317 the constraint is mandatory. If the C flag is zero, the O flag 318 MUST be set to zero on transmission and ignored on reception. 320 o R Flag: The R Flag is only relevant for routing metric (C=0) and 321 MUST be cleared for C=1. When set, this indicates that the 322 routing metric is recorded along the path. Conversely, when 323 cleared, the routing metric is aggregated. 325 The Flag field of the Routing Metric/Constraint object is managed by 326 IANA. Unassigned bits are considered as reserved. They MUST be set 327 to zero on transmission and MUST be ignored on receipt. 329 A Field: The A field is only relevant for metrics and is used to 330 indicate whether the aggregated routing metric is additive, 331 multiplicative, reports a maximum or a minimum. 333 o A=0x00: The routing metric is additive 335 o A=0x01: The routing metric reports a maximum 337 o A=0x02: The routing metric reports a minimum 339 o A=0x03: The routing metric is multiplicative 341 The A field has no meaning when the C Flag is set (i.e. when the 342 Routing Metric/Constraint object refers to a routing constraint) and 343 he only valid when the R bit is cleared. Otherwise, the A field MUST 344 be set to 0x00 and MUST be ignored on receipt. 346 Prec field: The Prec field indicates the precedence of this Routing 347 Metric/Constraint object relative to other objects in the container. 348 This is useful when a DAG Metric Container contains several Routing 349 Metric objects. The value 0 means the highest precedence. 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 (the higher is the ETX the lower link quality is): when the DIO 361 message reporting link quality metric (ETX) is processed by a node, 362 each node selecting the advertising node as a parent updates the 363 value carried in the metric object by replacing it with its local 364 link ETX value if and only if the latter is higher. As far as the 365 constraint is concerned, if the constraint signalled in the DIO 366 message is not satisfied, the advertising node is just not selected 367 as a parent by the node that processes the DIO message. 369 Example 2: A DAG formed by RPL where the link metric is the link 370 quality level (defined in Section 4) and link quality levels must be 371 recorded along the path. In this case, the DAG Metric Container 372 carries a Routing Metric/Constraint object: link quality level metric 373 (C=0, O=0, A=00, R=1) containing multiple sub-objects. 375 A Routing Metric/Constraint object may also include one or more 376 additional type-length-value (TLV) encoded data sets. Each Routing 377 Metric/Constraint TLV has the same structure: 379 Type: 1 byte 380 Length: 1 byte 381 Value: variable 383 A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 384 1 byte specifying the TLV length, and a value field. The TLV length 385 field defines the length of the value field in bytes. 387 Unrecognized TLVs MUST be silently ignored while still being 388 propagated in DIO generated by receiving node. 390 IANA manages the codepoints for all TLV carried in routing 391 constraint/metric objects. 393 IANA management of the Routing Metric/Constraint objects identifier 394 codespace is described in Section 6. 396 2.2. Use of Multiple DAG Metric Containers 398 Since the length of RPL options is encoded using 1 octet, they cannot 399 exceed 255 bytes, which also applies to the DAG Metric Container. In 400 the vast majority of cases, the advertised routing metrics and 401 constraints will not require that much space. However, there might 402 be circumstances where larger space is required, should for example a 403 set of routing metrics be recorded along a long path. In this case, 404 in order to avoid overflow, as specified in [I-D.ietf-roll-rpl], 405 routing metrics will be carried using multiple DAG Metric Containers 406 objects. 408 In the rest of this document, this use of multiple DAG Metric 409 Containers objects will be considered as if they were actually just 410 one long DAG Metric Container object. 412 2.3. Metric Usage 414 When the DAG Metric Container contains a single aggregated metric 415 (scalar value), the order relation to select the best path is 416 implicitly derived from the metric type. For example, lower is 417 better for Hop Count, Link Latency and ETX. Conversely, for Node 418 Energy or Throughput, higher is better. 420 An example of using such a single aggregated metric is optimizing 421 routing for node energy. The Node Energy metric (E-E field) defined 422 in Section 3.2 is aggregated along paths with an explicit min 423 function (A field), and the best path is selected through an implied 424 Max function because the metric is Energy. 426 When the DAG Metric Container contains several aggregated metrics, 427 they are to be used as tie-breakers according to their precedence 428 defined by their Prec field values. 430 An example of such use of multiple aggregated metrics is the 431 following: Hop-Count as the primary criterion, LQL as the secondary 432 criterion and Node Energy as the ultimate tie-breaker. In such a 433 case, the Hop-Count, LQL and Node Energy metric objects' Prec fields 434 should bear strictly increasing values such as 0, 1 and 2, 435 respectively. 437 If several aggregated metrics happen to bear the same Prec value, the 438 behavior is implementation-dependant. 440 3. Node Metric/Constraint Objects 442 The sections 3. and 4. specify several link and node metric/ 443 constraint objects. In some cases it is stated that there must not 444 be more than one object of a specific type. In that case, if an RPL 445 implementation receives more than one objet of that type, the second 446 objet MUST silently be ignored. 448 3.1. Node State and Attributes Object 450 The Node State and Attribute (NSA) object is used to provide 451 information on node characteristics. 453 The NSA object MAY be present in the DAG Metric Container. There 454 MUST NOT be more than one NSA object as a constraint per DAG Metric 455 Container, and there MUST NOT be more than one NSA object as a metric 456 per DAG Metric Container. 458 The NSA object may also contain a set of TLVs used to convey various 459 node characteristics. No TLV is currently defined. 461 The NSA Routing Metric/Constraint Type is to be assigned by IANA 462 (recommended value=1). 464 The format of the NSA object body is as follows: 466 0 1 2 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 469 | Res | Flags |A|O| Optional TLVs 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 472 Figure 3: NSA object body format 474 Res flags (8 bits): Reserved field. This field MUST be set to zero 475 on transmission and MUST be ignored on receipt. 477 The following two bits of the NSA object are currently defined: 479 o A Flag: data Aggregation Attribute. Data fusion involves more 480 complicated processing to improve the accuracy of the output data, 481 while data aggregation mostly aims at reducing the amount of data. 482 This is listed as a requirement in Section 6.2 of [RFC5548]. Some 483 applications may make use of the aggregation node attribute in 484 their routing decision so as to minimize the amount of traffic on 485 the network, thus potentially increasing its lifetime in battery 486 operated environments. Applications where highly directional data 487 flow is expected on a regular basis may take advantage of data 488 aggregation supported routing. When set, this indicates that the 489 node can act as a traffic aggregator. An implementation MAY 490 decide to add optional TLVs (not currently defined) to further 491 describe the node traffic aggregator functionality. 493 o O Flag: node workload may be hard to determine and express in some 494 scalar form. However, node workload could be a useful metric to 495 consider during path calculation, in particular when queuing 496 delays must be minimized for highly sensitive traffic considering 497 Medium Access Control (MAC) layer delay. Node workload MAY be set 498 upon CPU overload, lack of memory or any other node related 499 conditions. Using a simple 1-bit flag to characterize the node 500 workload provides a sufficient level of granularity, similarly to 501 the "overload" bit used in routing protocols such as IS-IS. 502 Algorithms used to set the overload bit and to compute paths to 503 potentially avoid nodes with their overload bit set are outside 504 the scope of this document, but it is RECOMMENDED to avoid 505 frequent changes of this bit to avoid routing oscillations. When 506 set, this indicates that the node is overloaded and may not be 507 able to process traffic. 509 They MUST be set to zero on transmission and MUST be ignored on 510 receipt. 512 The Flag field of the NSA Routing Metric/Constraint object is managed 513 by IANA. Unassigned bits are considered as reserved. 515 3.2. Node Energy Object 517 It may sometimes be desirable to avoid selecting a node with low 518 residual energy as a router, thus the support for constraint-based 519 routing is needed. In such cases, the routing protocol engine may 520 compute a longer path (constraint based) for some traffic in order to 521 increase the network life duration. 523 Power and energy are clearly critical resources in most LLNs. As yet 524 there is no simple abstraction which adequately covers the broad 525 range of power sources and energy storage devices used in existing 526 LLN nodes. These include mains-powered, primary batteries, energy 527 scavengers, and a variety of secondary storage mechanisms. 528 Scavengers may provide a reliable low level of power, such as might 529 be available from a 4-20mA loop; a reliable but periodic stream of 530 power, such as provided by a well-positioned solar cell; or 531 unpredictable power, such as might be provided by a vibrational 532 energy scavenger on an intermittently powered pump. Routes which are 533 viable when the sun is shining may disappear at night. A pump 534 turning on may connect two previously disconnected sections of a 535 network. 537 Storage systems like rechargeable batteries often suffer substantial 538 degradation if regularly used to full discharge, leading to different 539 residual energy numbers for regular versus emergency operation. A 540 route for emergency traffic may have a different optimum than one for 541 regular reporting. 543 Batteries used in LLNs often degrade substantially if their average 544 current consumption exceeds a small fraction of the peak current that 545 they can deliver. It is not uncommon for self-supporting nodes to 546 have a combination of primary storage, energy scavenging, and 547 secondary storage, leading to three different values for acceptable 548 average current depending on the time frame being considered, e.g. 549 milliseconds, seconds, and hours/years. 551 Raw power and energy values are meaningless without knowledge of the 552 energy cost of sending and receiving packets, and lifetime estimates 553 have no value without some higher-level constraint on the lifetime 554 required of a device. In some cases the path that exhausts the 555 battery of a node on the bed table in a month may be preferable to a 556 route that reduces the lifetime of a node in the wall to a decade. 558 Given the complexity of trying to address such a broad collection of 559 constraints, this document defines two levels of fidelity in the 560 solution. 562 The simplest solution relies on a 2-bit field encoding three types of 563 power sources: "powered", "battery", "scavenger". This simple 564 approach may be sufficient for many applications. 566 The mid-complexity solution is a single parameter that can be used to 567 encode the energetic happiness of both battery powered and scavenging 568 nodes. For scavenging nodes, the 8 bit quantity is the power 569 provided by the scavenger divided by the power consumed by the 570 application, E-E=P_in/P_out, in units of percent. Nodes which are 571 scavenging more power than they are consuming will register above 572 100. A good time period for averaging power in this calculation may 573 be related to the discharge time of the energy storage device on the 574 node, but specifying this is out of the scope of this document. For 575 battery powered devices, E-E is the current expected lifetime divided 576 by the desired minimum lifetime, in units of percent. The estimation 577 of remaining battery energy and actual power consumption can be 578 difficult, and the specifics of this calculation are out of scope of 579 this document, but two examples are presented. If the node can 580 measure its average power consumption, then H can be calculated as 581 the ratio of desired max power (initial energy E_0 divided by desired 582 lifetime T) to actual power, E-E=P_max/P_now. Alternatively, if the 583 energy in the battery E_bat can be estimated, and the total elapsed 584 lifetime, t, is available, then H can be calculated as the total 585 stored energy remaining versus the target energy remaining: E-E= 586 E_bat / [E_0 (T-t)/T]. 588 An example of optimized route is max(min(H)) for all battery operated 589 nodes along the route, subject to the constraint that E-E>=100 for 590 all scavengers along the route. 592 Note that the estimated percentage of remaining energy indicated in 593 the E-E field may not be useful in the presence of nodes powered by 594 battery or energy scavengers when the amount of energy accumulated by 595 the device significantly differ. Indeed, X% of remaining energy on a 596 node that can store a large amount of energy cannot be easily 597 compared to the same percentage of remaining energy on a node powered 598 by a tiny source of energy. That being said, in networks where nodes 599 have relatively close energy storage, such a percentage of remaining 600 energy is useful. 602 The Node Energy (NE) object is used to provide information related to 603 node energy and may be used as a metric or as constraint. 605 The NE object MAY be present in the DAG Metric Container. There MUST 606 NOT be more than one NE object as a constraint per DAG Metric 607 Container, and there MUST NOT be more than one NE object as a metric 608 per DAG Metric Container. 610 The NE object Type is to be assigned by IANA (recommended value=2). 612 The format of the NE object body is as follows: 614 0 1 2 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 617 | NE Sub-objects 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 620 Figure 4: NE sub-object format 622 The format of the NE sub-object body is as follows: 624 0 1 2 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 627 | Flags |I| T |E| E-E | Optional TLVs 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 630 Figure 5: NE sub-object format 632 The NE sub-object may also contain a set of TLVs used to convey 633 various nodes' characteristics. 635 The following flags are currently defined: 637 o I (Included): the I bit is only relevant when the node type is 638 used as a constraint. For example, the path must only traverse 639 mains-powered nodes. Conversely, battery operated nodes must be 640 excluded. The I bit is used to stipulate inclusion versus 641 exclusion. When set, this indicates that nodes of the type 642 specified in the node type field MUST be included. Conversely, 643 when cleared, this indicates that nodes of type specified in the 644 node type field MUST be excluded. 646 o T (node Type): 2-bit field indicating the node type. T=0x00 647 designates a mains-powered node, T=0x01 a battery-powered node and 648 T=0x02 a node powered by an energy scavenger. 650 o E (Estimation): when the E bit is set for a metric, the estimated 651 percentage of remaining energy on the node is indicated in the E-E 652 8-bit field. When cleared, the estimated percentage of remaining 653 energy is not provided. When the E bit is set for a constraint, 654 the E-E field defines a threshold for the inclusion/exclusion: if 655 an inclusion, nodes with values higher than the threshold are to 656 be included; if an exclusion, nodes with values lower than the 657 threshold are to be excluded. 659 E-E (Estimated-Energy): 8-bit unsigned integer field indicating an 660 estimated percentage of remaining energy. The E-E field is only 661 relevant when the E flag is set, and MUST be set to 0 when the E flag 662 is cleared. 664 If the NE object comprises several sub-objects when used as a 665 constraint, each sub-object adds or subtracts node subsets as the 666 sub-objects are parsed in order. The initial set (full or empty) is 667 defined by the I bit of the first sub-object: full if that I bit is 668 an exclusion, empty if that I bit is an inclusion. 670 No TLV is currently defined. 672 Future documents may define more complex solutions involving TLV 673 parameters representing energy storage, consumption, and generation 674 capabilities of the node, as well as desired lifetime. 676 3.3. Hop-Count Object 678 The HoP-Count (HP) object is used to report the number of traversed 679 nodes along the path. 681 The HP object MAY be present in the DAG Metric Container. There MUST 682 NOT be more than one HP object as a constraint per DAG Metric 683 Container, and there MUST NOT be more than one HP object as a metric 684 per DAG Metric Container. 686 The HP object may also contain a set of TLVs used to convey various 687 node characteristics. No TLV is currently defined. 689 The HP routing metric object Type is to be assigned by IANA 690 (recommended value=3) 692 The format of the Hop Count object body is as follows: 694 0 1 2 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 697 | Res | Flags | Hop Count | Optional TLVs 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 700 Figure 6: Hop Count object body format 702 Res flags (4 bits): Reserved field. This field MUST be set to zero 703 on transmission and MUST be ignored on receipt. 705 No Flag is currently defined. Unassigned bits are considered as 706 reserved. They MUST be set to zero on transmission and MUST be 707 ignored on receipt. 709 The HP object may be used as a constraint or a metric. When used as 710 a constraint, the DAG root indicates the maximum number of hops that 711 a path may traverse. When that number is reached, no other node can 712 join that path. When used as a metric, each visited node simply 713 increments the Hop Count field. 715 Note that the first node along a path inserting a Hop-count object 716 MUST set the Hop Count field value to 1. 718 4. Link Metric/Constraint Objects 720 4.1. Throughput 722 Many LLNs support a wide range of throughputs. For some links, this 723 may be due to variable coding. For the deeply duty-cycled links 724 found in many LLNs, the variability comes as a result of trading 725 power consumption for bit rate. There are several MAC layer 726 protocols which allow for the effective bit rate of a link to vary 727 over more than three orders of magnitude with a corresponding change 728 in power consumption. For efficient operation, it may be desirable 729 for nodes to report the range of throughput that their links can 730 handle in addition to the currently available throughput. 732 The Throughput object MAY be present in the DAG Metric Container. 733 There MUST NOT be more than one Throughput object as a constraint per 734 DAG Metric Container, and there MUST NOT be more than one Throughput 735 object as a metric per DAG Metric Container. 737 The Throughput object is made of throughput sub-objects and MUST at 738 least comprise one Throughput sub-object. The first Throughput sub- 739 object MUST be the most recently estimated actual throughput. The 740 actual estimation of the throughput is outside the scope of this 741 document. 743 Each Throughput sub-object has a fixed length of 4 bytes. 745 The Throughput object does not contain any additional TLV. 747 The Throughput object Type is to be assigned by IANA (recommended 748 value=4) 749 The format of the Throughput object body is as follows: 751 0 1 752 0 1 2 3 4 5 6 7 8 9 0 1 2 3 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | (sub-object) ..... 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 Figure 8: Throughput object body format 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Throughput | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Figure 9: Throughput sub-object format 767 Throughput: 32 bits. The Throughput is encoded in 32 bits in 768 unsigned integer format, expressed in bytes per second. 770 4.2. Latency 772 Similarly to throughput, the latency of many LLN MAC sub-layers can 773 vary over many orders of magnitude, again with a corresponding change 774 in power consumption. Some LLN MAC link layers will allow the 775 latency to be adjusted globally on the subnet, on a link-by-link 776 basis, or not at all. Some will insist that it be fixed for a given 777 link, but allow it to be variable from link to link. 779 The Latency object MAY be present in the DAG Metric Container. There 780 MUST NOT be more than one Latency object as a constraint per DAG 781 Metric Container, and there MUST NOT be more than one Latency object 782 as a metric per DAG Metric Container. 784 The Latency object is made of Latency sub-objects and MUST at least 785 comprise one Latency sub-object. Each Latency sub-object has a fixed 786 length of 4 bytes. 788 The Latency object does not contain any additional TLV. 790 The Latency object Type is to be assigned by IANA (recommended 791 value=5) 793 The Latency object is a metric or constraint. 795 The format of the Latency object body is as follows: 797 0 1 798 0 1 2 3 4 5 6 7 8 9 0 1 2 3 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | (sub-object) ..... 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Figure 10: Latency object body format 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Latency | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Figure 11: Latency sub-object format 813 Latency: 32 bits. The Latency is encoded in 32 bits in unsigned 814 integer format, expressed in microseconds. 816 The Latency object may be used as a constraint or a path metric. For 817 example, one may want the latency not to exceed some value. In this 818 case, the Latency object common header indicates that the provided 819 value relates to a constraint. In another example, the Latency 820 object may be used as an aggregated additive metric where the value 821 is updated along the path to reflect the path latency. 823 4.3. Link Reliability 825 In LLNs, link reliability is degraded by external interference and 826 multi-path interference (wireless links). Multipath typically 827 affects both directions on the link equally, whereas external 828 interference is sometimes unidirectional. Time scales vary from 829 milliseconds to days, and are often periodic and linked to human 830 activity. Packet error rates can generally be measured directly, and 831 other metrics (e.g. bit error rate, mean time between failures) are 832 typically derived from that. Note that such variability is not 833 specific to wireless link but also applies to PLC links. 835 A change in link quality can affect network connectivity, thus, link 836 quality may be taken into account as a critical routing metric. 838 A number of link reliability metrics could be defined reflecting 839 several reliability aspects. Two link reliability metrics are 840 defined in this document: the Link Quality Level (LQL) and the 841 Expected Transmission count Metric (ETX). 843 Note that an RPL implementation MAY either use the LQL, the ETX or 844 both. 846 4.3.1. The Link Quality Level Reliability Metric 848 The Link Quality Level (LQL) object is used to quantify the link 849 reliability using a discrete value, from 0 to 7 where 0 indicates 850 that the link quality level is unknown and 1 reports the highest link 851 quality level. The mechanisms and algorithms used to compute the LQL 852 are implementation specific and outside of the scope of this 853 document. 855 The LQL can either be used as a metric or a constraint. When used as 856 a metric, the LQL metric can be recorded or aggregated. For example, 857 the DAG Metric object may request all traversed nodes to record the 858 LQL of their incoming link into the LQL object. Each node can then 859 use the LQL record to select its parent based on some user defined 860 rules (e.g. something like "select the path with most links reporting 861 a LQL value of 3 or less"). By contrast, the LQL link metric may be 862 aggregated, in which case the sum of all LQLs may be reported 863 (additive metric) or the minimum value may be reported along the 864 path. 866 When used as a recorded metric, counters are used to compress the 867 information: for each encountered LQL value, only the number of 868 matching links is reported. 870 The LQL object MAY be present in the DAG Metric Container. There 871 MUST NOT be more than one LQL object as a constraint per DAG Metric 872 Container, and there MUST NOT be more than one LQL object as a metric 873 per DAG Metric Container. 875 The LQL object MUST contain one or more sub-object used to report the 876 number of links along with their LQL. 878 The LQL object Type is to be assigned by IANA (recommended value=6) 880 The format of the LQL object body is as follows: 882 0 1 2 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 885 | Res | LQL sub-object 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 888 Figure 12: LQL object body format 890 Res flags (8 bits): Reserved field. This field MUST be set to zero 891 on transmission and MUST be ignored on receipt. 893 When the LQL metric is recorded, the LQL object body comprises one or 894 more LQL Type 1 sub-object. 896 The format of the LQL Type 1 sub-object is as follows 898 0 899 0 1 2 3 4 5 6 7 900 +-+-+-+-+-+-+-+-+ 901 | Val | Counter | 902 +-+-+-+-+-+-+-+-+ 904 Figure 13: LQL Type 1 sub-object format 906 Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates 907 the highest link quality. 909 Counter: number of links with that value. 911 When the LQL metric is aggregated, the LQL object body comprises one 912 LQL Type 2 sub-object: 914 The format of the LQL Type 2 sub-object is as follows 916 0 1 917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Aggregated LQL Value | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 14: LQL Type 2 sub-object format 924 Aggregated LQL Value: when used as an additive metric (A=0x00), the 925 aggregated LQL value reports the sum of all the LQL values for all 926 links along the path. When used to report a minimum (A=0x02), the 927 field reports the minimum LQL value of all links along the path, 928 ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to 929 report a maximum (A=0x01), the field reports the maximum LQL value of 930 all links along the path. When used to report a multiplication 931 (A=0x03), and the LQL field of one of the links along the path is 932 undetermined (LQL=0), the undetermined LQL will be ignored and not be 933 aggregated (i.e. no reset to Aggregated LQL Value field). 935 4.3.2. The Expected Transmission Count (ETX) reliability object 937 The Expected Transmission Count (ETX) metric is the number of 938 transmissions a node expects to make to a destination in order to 939 successfully deliver a packet. In contrast with the LQL routing 940 metric, the ETX provides a discrete value (wich may not be an 941 integer) computed according to a specific formula: for example, an 942 implementation may use the following formula: ETX= 1 / (Df * Dr) 943 where Df is the measured probability that a packet is received by the 944 neighbor and Dr is the measured probability that the acknowledgment 945 packet is successfully received. This document does not mandate the 946 use of a specific formula to compute the ETX value. 948 The ETX object MAY be present in the DAG Metric Container. There 949 MUST NOT be more than one ETX object as a constraint per DAG Metric 950 Container, and there MUST NOT be more than one ETX object as a metric 951 per DAG Metric Container. 953 The ETX object is made of ETX sub-objects and MUST at least comprise 954 one ETX sub-object. Each ETX sub-object has a fixed length of 8 955 bits. 957 The ETX object does not contain any additional TLV. 959 The ETX object Type is to be assigned by IANA (recommended value=7) 961 The format of the ETX object body is as follows: 963 0 1 964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | (sub-object) ..... 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Figure 15: ETX object body format 971 0 1 972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | ETX | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Figure 16: ETX sub-object format 979 ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned 980 integer format, rounded off to the nearest whole number. For 981 example, if ETX = 3.569, the object value will be 457. If ETX > 982 511.9921875, the object value will be the maximum which is 65535. 984 The ETX object may be used as a constraint or a path metric. For 985 example, it may be required that the ETX must not exceed some 986 specified value. In this case, the ETX object common header 987 indicates that the value relates to a constraint. In another 988 example, the ETX object may be used as an aggregated additive metric 989 where the value is updated along the path to reflect the path 990 quality: when a node receives the aggregated additive ETX value of 991 the path (cummulative path ETX calculated as the sum of the link ETX 992 of all of the traversed links from the advertising node to the DAG 993 root), if it selects that node as its preferred parent, the node 994 updates the path ETX by adding the ETX of the local link between 995 itself and the preferred parent to the received path cost (path ETX) 996 before potentially advertising itself the new path ETX. 998 4.4. Link Color Object 1000 4.4.1. Link Color Object Description 1002 The Link Color (LC) object is an administrative 10-bit link 1003 constraint (which may either be static or dynamically adjusted) used 1004 to avoid or attract specific links for specific traffic types. 1006 The LC object can either be used as a metric or as a constraint. 1007 When used as a metric, the LC metric can only be recorded. For 1008 example, the DAG may require recording the link colors for all 1009 traversed links. A color is defined as a specific set of bit values: 1010 in other words, that 10-bit field is a flag field, and not a scalar 1011 value. Each node can then use the LC to select the parent based on 1012 user defined rules (e.g. "select the path with the maximum number of 1013 links having their first bit set 1 (e.g. encrypted links)"). The LC 1014 object may also be used as a constraint. 1016 When used as a recorded metric, a counter is used to compress the 1017 information where the number of links for each Link Color is 1018 reported. 1020 The Link Color (LC) object MAY be present in the DAG Metric 1021 Container. There MUST NOT be more than one LC object as a constraint 1022 per DAG Metric Container, and there MUST NOT be more than one LC 1023 object as a metric per DAG Metric Container. 1025 There MUST be a at least one LC sub-object per LC object. 1027 The LC object does not contain any additional TLV. 1029 The LC object Type is to be assigned by IANA (recommended value=8) 1030 The format of the LC object body is as follows: 1032 0 1 2 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1035 | Res | LC sub-objects 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1038 Figure 17: LC object format 1040 Res flags (8 bits): Reserved field. This field MUST be set to zero 1041 on transmission and MUST be ignored on receipt. 1043 When the LC object is used as a recorded metric, the LC object body 1044 comprises one or more LC Type 1 sub-objects. 1046 The format of the LC Type 1 sub-object body is as follows: 1048 0 1 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Link Color | Counter | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Figure 18: LC Type 1 sub-object format 1056 When the LC object is used as a constraint, the LC object body 1057 comprises one or more LC Type 2 sub-objects. 1059 The format of the LC Type 2 sub-object body is as follows: 1061 0 1 1062 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Link Color |Reserved |I| 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Figure 19: LC Type 2 sub-object format 1069 Res flags (7 bits): Reserved field. This field MUST be set to zero 1070 on transmission and MUST be ignored on receipt. 1072 I Bit: The I bit is only relevant when the Link Color is used as a 1073 constraint. When cleared, this indicates that links with the 1074 specified color must be included. When set, this indicates that 1075 links with the specified color must be excluded. 1077 It is left to the implementer to define the meaning of each bit of 1078 the 10-bit Link Color Flag field. 1080 4.4.2. Mode of operation 1082 The link color may be used as a constraint or a metric. 1084 o When used as constraint, the LC object may be inserted in the DAG 1085 Metric Container to indicate that links with a specific color 1086 should be included or excluded from the computed path. 1088 o When used as recorded metric, each node along the path may insert 1089 a LC object in the DAG Metric Container to report the color of the 1090 local link. If there is already a LC object reporting a similar 1091 color, the node MUST NOT add another identical LC sub-object and 1092 MUST increment the counter field. 1094 5. Computation of Dynamic Metrics and Attributes 1096 As already pointed out, dynamically calculated metrics are of the 1097 utmost importance in many circumstances in LLNs. This is mainly 1098 because a variety of metrics change on a frequent basis, thus 1099 implying the need to adapt the routing decisions. That being said, 1100 care must be given to the pace at which changes are reported in the 1101 network. The attributes will change according to their own time 1102 scales. RPL controls the reporting rate. 1104 To minimize metric updates, multi-threshold algorithms MAY be used to 1105 determine when updates should be sent. When practical, low-pass 1106 filtering and/or hysteresis should be used to avoid rapid 1107 fluctuations of these values. Finally, although the specification of 1108 path computation algorithms using dynamic metrics are out the scope 1109 of this document, it is RECOMMENDED to carefully design the route 1110 optimization algorithm to avoid too frequent computation of new 1111 routes upon metric values changes. 1113 Controlled adaptation of the routing metrics and rate at which paths 1114 are computed are critical to avoid undesirable routing instabilities 1115 resulting in increased latencies and packet loss because of temporary 1116 micro-loops. Furthermore, excessive route changes will adversely 1117 impact the traffic and power consumption in the network, thus 1118 potentially impacting its scalability. 1120 6. IANA Considerations 1122 IANA is requested to establish a new top-level registry to contain 1123 all Routing Metric/Constraint objects codepoints and sub-registries. 1125 The allocation policy for each new registry is by IETF Consensus: new 1126 values are assigned through the IETF consensus process (see 1127 [RFC5226]). Specifically, new assignments are made via RFCs approved 1128 by the IESG. Typically, the IESG will seek input on prospective 1129 assignments from appropriate persons (e.g., a relevant Working Group 1130 if one exists). 1132 6.1. Routing Metric/Constraint Type 1134 IANA is requested to create a registry for Routing Metric/Constraint 1135 objects. Each Routing Metric/Constraint object has a type value. 1137 Value Meaning Reference 1138 1 Node State and Attribute This document 1139 2 Node Energy This document 1140 3 Hop Count This document 1141 4 Link Throughput This document 1142 5 Link Latency This document 1143 6 Link Quality Level This document 1144 7 Link ETX This document 1145 8 Link Color This document 1147 6.2. Routing Metric/Constraint TLV 1149 IANA is requested to create a registry used for all TLVs carried 1150 within Routing Metric/Constraint objects. 1152 6.3. Routing Metric/Constraint Common Header 1154 IANA is requested to create a registry to manage the codespace of the 1155 A field of the Routing Metric/Constraint common header. 1157 Codespace of the A field (Routing Metric/Constraint common header) 1158 Value Meaning Reference 1160 0 Routing metric is additive This document 1161 1 Routing metric reports a maximum This document 1162 2 Routing metric reports a minimum This document 1163 3 Routing metric is multiplicative This document 1165 IANA is requested to create a registry to manage the Flag field of 1166 the Routing Metric/Constraint common header. 1168 New bit numbers may be allocated only by an IETF Consensus action. 1169 Each bit should be tracked with the following qualities: 1171 o Bit number 1172 o Capability Description 1174 o Defining RFC 1176 Several bits are defined for the Routing Metric/Constraint common 1177 header in this document. The following values have been assigned: 1179 Codespace of the Flag field (Routing Metric/Constraint common header) 1180 Bit Description Reference 1182 12-15 Precedence This document 1183 9-11 Additive/Max/Min/Multi This document 1184 8 Recorded/Aggregated This document 1185 7 Optional Constraint This document 1186 6 Constraint/Metric This document 1187 5 P (Partial) This document 1189 6.4. NSA Object 1191 IANA is requested to create a registry to manage the codespace of the 1192 Flag field of the NSA object. 1194 New bit numbers may be allocated only by an IETF Consensus action. 1195 Each bit should be tracked with the following qualities: 1197 o Bit number 1199 o Capability Description 1201 o Defining RFC 1203 Several bits are defined for the NSA object flag field in this 1204 document. The following values have been assigned: 1206 Codespace of the Flag field (NSA object) 1207 Bit Description Reference 1209 14 Aggregator This document 1210 15 Overloaded This document 1212 6.5. Hop-Count Object 1214 IANA is requested to create a registry to manage the codespace of the 1215 Flag field of the Hop-count object. 1217 New bit numbers may be allocated only by an IETF Consensus action. 1218 Each bit should be tracked with the following qualities: 1220 o Bit number 1222 o Capability Description 1224 o Defining RFC 1226 No Flag is currently defined. 1228 7. Security Considerations 1230 Routing metrics should be handled in a secure and trustful manner. 1231 For instance, RPL should not allow a malicious node to falsely 1232 advertise that it has good metrics for routing, be added as a router 1233 for other nodes' traffic and intercept packets. Another attack may 1234 consist of making intermitment attacks on a link in an attempt to 1235 constantly modify the link quality and consequently the associated 1236 routing metric, thus leading to potential fluctuation in the DAG. It 1237 is thus RECOMMENDED for a RPL implementation to put in place 1238 mechanism so as to stop advertising routing metrics for highly 1239 unstable links that may be subject to attacks. 1241 Since the routing metrics/constraints are carried within RPL message, 1242 the security routing mechanisms defined in [I-D.ietf-roll-rpl] 1243 applies here. 1245 8. Acknowledgements 1247 The authors would like to acknowledge the contributions of Young Jae 1248 Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip 1249 Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru 1250 Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, 1251 Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads 1252 Westergreen, Mukul Goyal and David Culler for their review and 1253 valuable comments. Special thank to Adrian Farrel for his thourough 1254 review. 1256 9. References 1258 9.1. Normative references 1260 [I-D.ietf-roll-rpl] 1261 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1262 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1263 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1264 Lossy Networks", draft-ietf-roll-rpl-15 (work in 1265 progress), November 2010. 1267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, March 1997. 1270 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1271 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1272 May 2008. 1274 9.2. Informative references 1276 [I-D.ietf-roll-terminology] 1277 Vasseur, J., "Terminology in Low power And Lossy 1278 Networks", draft-ietf-roll-terminology-04 (work in 1279 progress), September 2010. 1281 [Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of 1282 the Revised Routing Metric for ARPANET and MILNET. 1283 Submitted to MILCOM 89, March 1989 1285 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1286 dual environments", RFC 1195, December 1990. 1288 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1290 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1291 McManus, "Requirements for Traffic Engineering Over MPLS", 1292 RFC 2702, September 1999. 1294 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1295 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1296 Tunnels", RFC 3209, December 2001. 1298 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1299 "Routing Requirements for Urban Low-Power and Lossy 1300 Networks", RFC 5548, May 2009. 1302 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1303 "Industrial Routing Requirements in Low-Power and Lossy 1304 Networks", RFC 5673, October 2009. 1306 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1307 Routing Requirements in Low-Power and Lossy Networks", 1308 RFC 5826, April 2010. 1310 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1311 "Building Automation Routing Requirements in Low-Power and 1312 Lossy Networks", RFC 5867, June 2010. 1314 Authors' Addresses 1316 JP Vasseur (editor) 1317 Cisco Systems, Inc 1318 11, Rue Camille Desmoulins 1319 Issy Les Moulineaux, 92782 1320 France 1322 Email: jpv@cisco.com 1324 Mijeom Kim (editor) 1325 Corporate Technology Group, KT 1326 17 Woomyeon-dong, Seocho-gu 1327 Seoul, 137-792 1328 Korea 1330 Email: mjkim@kt.com 1332 Kris Pister 1333 Dust Networks 1334 30695 Huntwood Ave. 1335 Hayward, CA 95544 1336 USA 1338 Email: kpister@dustnetworks.com 1340 Nicolas Dejean 1341 Coronis SAS 1342 Espace Concorde, 120 impasse JB Say 1343 Perols, 34470 1344 France 1346 Email: nicolas.dejean@coronis.com 1348 Dominique Barthel 1349 France Telecom Orange 1350 28 chemin du Vieux Chene, BP 98 1351 Meylan, 38243 1352 France 1354 Email: dominique.barthel@orange-ftgroup.com