idnits 2.17.1 draft-ietf-roll-routing-metrics-19.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 (March 1, 2011) is 4804 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-18 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-20) exists of draft-ietf-roll-of0-05 == 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: September 2, 2011 Corporate Technology Group, KT 5 K. Pister 6 Dust Networks 7 N. Dejean 8 Elster SAS 9 D. Barthel 10 France Telecom Orange 11 March 1, 2011 13 Routing Metrics used for Path Calculation in Low Power and Lossy 14 Networks 15 draft-ietf-roll-routing-metrics-19 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 September 2, 2011. 49 Copyright Notice 51 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 24 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 TLVs . . . . . . . . . . . . . . 26 89 6.3. Routing Metric/Constraint Common Header Flag field . . . . 26 90 6.4. Routing Metric/Constraint Common Header A field . . . . . 27 91 6.5. NSA Object Flag field . . . . . . . . . . . . . . . . . . 27 92 6.6. Hop-Count Object Flag field . . . . . . . . . . . . . . . 27 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 97 9.2. Informative references . . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 This document makes use of the terminology defined in 103 [I-D.ietf-roll-terminology]. 105 Low power and Lossy Networks (LLNs) have specific routing 106 characteristics compared with traditional wired or ad-hoc networks 107 that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and 108 [RFC5867]. 110 Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have 111 used quantitative static link metrics. Other mechanisms such as 112 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see 113 [RFC2702] and [RFC3209]) make use of other link attributes such as 114 the available reserved bandwidth (dynamic) or link affinities (most 115 of the time static) to compute constrained shortest paths for Traffic 116 Engineering Label Switched Paths (TE LSPs). 118 This document specifies routing metrics and constraints to be used in 119 path calculation by the Routing Protocol for Low Power and Lossy 120 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 122 One of the prime objectives of this document is to define a flexible 123 mechanism for the advertisement of routing metrics and constraints 124 used by RPL. Some RPL implementations may elect to adopt an 125 extremely simple approach based on the use of a single metric with no 126 constraint whereas other implementations may use a larger set of link 127 and node routing metrics and constraints. This specification 128 provides a high degree of flexibility and a set of routing metrics 129 and constraints. New routing metrics and constraints could be 130 defined in the future, as needed. 132 The metrics and constraints defined in this document are carried in 133 objects that are OPTIONAL from the point of view of a RPL 134 implementation. This means that implementations are free to include 135 different subsets of the functions (metric, constraint) defined in 136 this document. Specific sets of metrics/constraints and other 137 optional RPL parameters for use in key environments will be specified 138 as compliance profiles in applicability profile documents produced by 139 the ROLL working group. Note that RPL can even make use of no 140 metric, for example using the objective function defined in 141 [I-D.ietf-roll-of0]. 143 RPL is a distance vector routing protocol variant that builds 144 Directed Acyclic Graphs (DAGs) based on routing metrics and 145 constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: 147 o The Destination Oriented Directed Acyclic Graph (DODAG) root as 148 defined in [I-D.ietf-roll-rpl] may advertise a routing constraint 149 used as a "filter" to prune links and nodes that do not satisfy 150 specific properties. For example, it may be required for the path 151 to only traverse nodes that are mains powered or links that have 152 at least a minimum reliability or a specific "color" reflecting a 153 user defined link characteristic (e.g the link layer supports 154 encryption). 156 o A routing metric is a quantitative value that is used to evaluate 157 the path cost. Link and node metrics are usually (but not always) 158 additive. 160 The best path is the path that satisfies all supplied constraints (if 161 any) and that has the lowest cost with respect to some specified 162 metrics. It is also called the shortest constrained path (in the 163 presence of constraints). 165 Routing metrics may be categorized according to the following 166 characteristics: 168 o Link versus Node metrics 170 o Qualitative versus quantitative 172 o Dynamic versus static 174 Routing requirements documents (see [RFC5673], [RFC5826] [RFC5548] 175 and [RFC5867]) observe that it must be possible to take into account 176 a variety of node constraints/metrics during path computation. 178 Some link or node characteristics (e.g. link reliability, remaining 179 energy on the node) may be used by RPL either as routing constraints 180 or as metrics. For example, the path may be computed to avoid links 181 that do not provide a sufficient level of reliability (use as a 182 constraint) or as the path offering most links with a specified 183 reliability level (use as a metric). This document provides the 184 flexibility to use link and node characterisics either as constraints 185 and/or metrics. 187 The use of link and node routing metrics and constraints is not 188 exclusive (e.g. it is possible to advertise a "hop count" both as a 189 metric to optimize the computed path and as a constraint (e.g. "Path 190 should not exceed n hops")). 192 Links in LLN commonly have rapidly changing node and link 193 characteristics: thus routing metrics must be dynamic and techniques 194 must be used to smooth out the dynamicity of these metrics so as to 195 avoid routing oscillations. For instance, in addition to the dynamic 196 nature of some links (e.g. wireless but also Powerline Communication 197 (PLC) links), nodes' resources such as residual energy are changing 198 continuously and may have to be taken into account during the path 199 computation. 201 It must be noted that the use of dynamic metrics is not new and has 202 been experimented in ARPANET 2 (see [Zinky1989]). The use of dynamic 203 metrics is not trivial and great care must be given to the use of 204 dynamic metrics since it may lead to potential routing instabilities. 205 That being said, lots of experience has been gained over the years on 206 the use of dynamic routing metrics, which have been deployed in a 207 number of (non IP) networks. 209 Very careful attention must be given to the pace at which routing 210 metrics and attributes values change in order to preserve routing 211 stability. When using a dynamic routing metric, a RPL implementation 212 should make use of a multi-threshold scheme rather than fine granular 213 metric updates reflecting each individual change to avoid spurious 214 and unneccessary routing changes. 216 The requirements on reporting frequency may differ among metrics, 217 thus different reporting rates may be used for each metric. 219 The set of routing metrics and constraints used by an RPL deployment 220 is signaled along the DAG that is built according to the Objective 221 Function (rules governing how to build a DAG) and the routing metrics 222 and constraints are advertised in the DAG Information Option (DIO) 223 message specified in [I-D.ietf-roll-rpl]. RPL may be used to build 224 DAGs with different characteristics. For example, it may be 225 desirable to build a DAG with the goal to maximize reliability by 226 using the link reliability metric to compute the "best" path. 227 Another example might be to use the energy node characteristic (e.g. 228 mains powered versus battery operated) as a node constraint when 229 building the DAG so as to avoid battery powered nodes in the DAG 230 while optimizing the link throughput. 232 The specification of objective functions used to compute the DAG 233 built by RPL is out of the scope of this document. This document 234 defines routing metrics and constraints that are decoupled from the 235 objective function. So a generic objective function could for 236 example specify the rules to select the best parents in the DAG, the 237 number of backup parents, etc and could be used with any routing 238 metrics and/or constraints such as the ones specified in this 239 document. 241 Some metrics are either aggregated or recorded. An aggregated metric 242 is adjusted as the DIO message travels along the DAG. For example, 243 if the metric is the number of hops, each node updates the path cost 244 that reflects the number of traversed hops along the DAG. By 245 contrast, for a recorded metric, each node adds a sub-object 246 reflecting the local valuation of the metric. For example, it might 247 be desirable to record the link quality level along a path. In this 248 case, each visited node adds a sub-object recording the local link 249 quality level. In order to limit the number of sub-objects, the use 250 of a counter may be desirable (e.g. record the number of links with a 251 certain link quality level), thus compressing the information to 252 reduce the message length. Upon receiving the DIO message from a set 253 of parents, a node might decide according to the OF and local policy 254 which node to choose as a parent based on the maximum number of links 255 with a specific link reliability level, for example. 257 Note that the routing metrics and constraints specified in this 258 document are not specific to any particular link layer. An internal 259 API between the MAC layer and RPL may be used to accurately reflect 260 the metrics values of the link (wireless, wired, PLC). 262 Since a set of metrics and constraints will be used for links and 263 nodes in LLN, it is critical to ensure the use of consistent metric 264 calculation mechanisms for all links and nodes in the network, 265 similarly to the case of inter-domain IP routing. 267 There are many different permutations of options that may be 268 appropriate in different deployments. Implementations must clearly 269 state which options they include, and must state which are default 270 and which are configurable as options within the implementation. 271 Applicability statements will be developed within the ROLL working 272 group to clarify which options are applicable to the specific 273 deployment scenarios indicated by [RFC5673], [RFC5826] [RFC5548] and 274 [RFC5867]. 276 2. Object Formats 278 2.1. DAG Metric Container Format 280 Routing metrics and constraints are carried within the DAG Metric 281 Container object defined in [I-D.ietf-roll-rpl]. Should multiple 282 metrics and/or constraints be present in the DAG Metric Container, 283 their use to determine the "best" path can be defined by an Objective 284 Function. 286 The Routing Metric/Constraint objects represent a metric or a 287 constraint of a particular type. They may appear in any order in the 288 DAG Metric Container (specified in [I-D.ietf-roll-rpl]). They have a 289 common format consisting of one or more bytes with a common header: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 // (object body) // 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 1: Routing Metric/Constraint object generic format 303 The object body carries one or more sub-objects defined later in this 304 document. Note that an object may carry TLV, which may itself 305 comprise other TLVs. A TLV carried within a TLV is called a TLV in 306 this specification. 308 Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the 309 Routing Metric/Constraint Type field uniquely identifies each Routing 310 Metric/Constraint object and is managed by IANA. 312 Length (8 bits): this field defines the length of the object body, 313 expressed in bytes. It ranges from 0 to 255. 315 Flag field (16 bits). The Flag field of the Routing Metric/ 316 Constraint object is managed by IANA. Unassigned bits are considered 317 as reserved. They MUST be set to zero on transmission and MUST be 318 ignored on receipt. 320 The following bits of the Routing Metric/Constraint Flag field object 321 are currently defined: 323 o P flag: the P field is only used for recorded metrics. When 324 cleared, all nodes along the path successfully recorded the 325 corresponding metric. When set, this indicates than one or 326 several nodes along the path could not record the metric of 327 interest (either because of lack of knowledge or because this was 328 prevented by policy). 330 o C Flag. When set, this indicates that the Routing Metric/ 331 Constraint object refers to a routing constraint. When cleared, 332 the routing object refers to a routing metric. 334 o O Flag: The O flag is used exclusively for routing constraints (C 335 flag is set). When set, this indicates that the constraint 336 specified in the body of the object is optional. When cleared, 337 the constraint is mandatory. If the C flag is zero, the O flag 338 MUST be set to zero on transmission and ignored on reception. 340 o R Flag: The R Flag is only relevant for routing metric (C=0) and 341 MUST be cleared for C=1. When set, this indicates that the 342 routing metric is recorded along the path. Conversely, when 343 cleared, the routing metric is aggregated. 345 A Field (3 bits): The A field is only relevant for metrics and is 346 used to indicate whether the aggregated routing metric is additive, 347 multiplicative, reports a maximum or a minimum. 349 o A=0x00: The routing metric is additive 351 o A=0x01: The routing metric reports a maximum 353 o A=0x02: The routing metric reports a minimum 355 o A=0x03: The routing metric is multiplicative 357 The A field has no meaning when the C Flag is set (i.e. when the 358 Routing Metric/Constraint object refers to a routing constraint) and 359 is only valid when the R bit is cleared. Otherwise, the A field MUST 360 be set to 0x00 and MUST be ignored on receipt. 362 Prec field (4 bits): The Prec field indicates the precedence of this 363 Routing Metric/Constraint object relative to other objects in the 364 container. This is useful when a DAG Metric Container contains 365 several Routing Metric objects. Its value ranges from 0 to 15. The 366 value 0 means the highest precedence. 368 Example 1: A DAG formed by RPL where all nodes must be mains-powered 369 and the best path is the one with lower aggregated ETX. In this case 370 the DAG Metric container carries two Routing Metric/Constraint 371 objects: one is an ETX metric object with header (C=0, O=0, A=00, 372 R=0) and the second one is a Node Energy constraint object with 373 header (C=1, O=0, A=00, R=0). Note that a RPL instance may use the 374 metric object to report a maximum (A=0x01) or a minimum (A=0x02). 375 If, for example, the best path is characterized by the path avoiding 376 low quality links, then the path metric reports a maximum (A=0x01) 377 (the higher the ETX, the lower the link quality): when the DIO 378 message reporting link quality metric (ETX) is processed by a node, 379 each node selecting the advertising node as a parent updates the 380 value carried in the metric object by replacing it with its local 381 link ETX value if and only if the latter is higher. As far as the 382 constraint is concerned, the object body will carry a node energy 383 constraint object defined in Section 3.1 indicating that nodes must 384 be mains-powered: if the constraint signalled in the DIO message is 385 not satisfied, the advertising node is just not selected as a parent 386 by the node that processes the DIO message. 388 Example 2: A DAG formed by RPL where the link metric is the link 389 quality level (defined in Section 4) and link quality levels must be 390 recorded along the path. In this case, the DAG Metric Container 391 carries a Routing Metric/Constraint object: link quality level metric 392 (C=0, O=0, A=00, R=1) containing multiple sub-objects. 394 A Routing Metric/Constraint object may also include one or more 395 additional type-length-value (TLV) encoded data sets. Each Routing 396 Metric/Constraint TLV has the same structure: 398 Type: 1 byte 399 Length: 1 byte 400 Value: variable 402 A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 403 1 byte specifying the TLV length, and a value field. The TLV length 404 field defines the length of the value field in bytes (from 0 to 255). 406 Unrecognized TLVs MUST be silently ignored while still being 407 propagated in DIOs generated by the receiving node. 409 IANA manages the codepoints for all TLVs carried in routing 410 constraint/metric objects. 412 IANA management of the Routing Metric/Constraint objects identifier 413 codespace is described in Section 6. 415 2.2. Use of Multiple DAG Metric Containers 417 Since the length of RPL options is encoded using 1 octet, they cannot 418 exceed 255 bytes, which also applies to the DAG Metric Container. In 419 the vast majority of cases, the advertised routing metrics and 420 constraints will not require that much space. However, there might 421 be circumstances where larger space is required, should for example a 422 set of routing metrics be recorded along a long path. In this case, 423 in order to avoid overflow, as specified in [I-D.ietf-roll-rpl], 424 routing metrics will be carried using multiple DAG Metric Containers 425 objects. 427 In the rest of this document, this use of multiple DAG Metric 428 Containers objects will be considered as if they were actually just 429 one long DAG Metric Container object. 431 2.3. Metric Usage 433 When the DAG Metric Container contains a single aggregated metric 434 (scalar value), the order relation to select the best path is 435 implicitly derived from the metric type. For example, lower is 436 better for Hop Count, Link Latency and ETX. Conversely, for Node 437 Energy or Throughput, higher is better. 439 An example of using such a single aggregated metric is optimizing 440 routing for node energy. The Node Energy metric (E-E field) defined 441 in Section 3.2 is aggregated along paths with an explicit min 442 function (A field), and the best path is selected through an implied 443 Max function because the metric is Energy. 445 When the DAG Metric Container contains several aggregated metrics, 446 they are to be used as tie-breakers according to their precedence 447 defined by their Prec field values. 449 An example of such use of multiple aggregated metrics is the 450 following: Hop-Count as the primary criterion, LQL as the secondary 451 criterion and Node Energy as the ultimate tie-breaker. In such a 452 case, the Hop-Count, LQL and Node Energy metric objects' Prec fields 453 should bear strictly increasing values such as 0, 1 and 2, 454 respectively. 456 If several aggregated metrics happen to bear the same Prec value, the 457 behavior is implementation-dependant. 459 3. Node Metric/Constraint Objects 461 The sections 3. and 4. specify several link and node metric/ 462 constraint objects. In some cases, it is stated that there must not 463 be more than one object of a specific type. In that case, if an RPL 464 implementation receives more than one object of that type, the second 465 objet MUST silently be ignored. 467 In the presence of a constraint and a metric (which may or may not be 468 of the same type), a node MUST update the constraint before 469 advertising the updated metric and constraints. For example, if the 470 constraint is the number of hops (e.g. the maximum number of hops is 471 n) and the path is optimized against the delay: if a node selects a 472 parent advertising a maximum number of hops of n (constraint), it 473 must advertise DIO messages containing a hop count metrics constraint 474 with a field value equal of (n-1) and the newly computed path metric. 475 This applies to the following constraints defined below: hop-count, 476 latency and path ETX. 478 3.1. Node State and Attributes Object 480 The Node State and Attribute (NSA) object is used to provide 481 information on node characteristics. 483 The NSA object MAY be present in the DAG Metric Container. There 484 MUST NOT be more than one NSA object as a constraint per DAG Metric 485 Container, and there MUST NOT be more than one NSA object as a metric 486 per DAG Metric Container. 488 The NSA object may also contain a set of TLVs used to convey various 489 node characteristics. No TLV is currently defined. 491 The NSA Routing Metric/Constraint Type is to be assigned by IANA 492 (recommended value=1). 494 The format of the NSA object body is as follows: 496 0 1 2 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 499 | Res | Flags |A|O| Optional TLVs 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 502 Figure 2: NSA object body format 504 Res flags (8 bits): Reserved field. This field MUST be set to zero 505 on transmission and MUST be ignored on receipt. 507 Flags field (8 bits). The following two bits of the NSA object are 508 currently defined: 510 o A Flag: data Aggregation Attribute. Data aggregation is listed as 511 a requirement in Section 6.2 of [RFC5548]. Some applications may 512 make use of the aggregation node attribute in their routing 513 decision so as to minimize the amount of traffic on the network, 514 thus potentially increasing its lifetime in battery operated 515 environments. Applications where highly directional data flow is 516 expected on a regular basis may take advantage of data aggregation 517 supported routing. When set, this indicates that the node can act 518 as a traffic aggregator. Further documents MAY define optional 519 TLVs to describe the node traffic aggregator functionality. 521 o O Flag: node workload may be hard to determine and express in some 522 scalar form. However, node workload could be a useful metric to 523 consider during path calculation, in particular when queuing 524 delays must be minimized for highly sensitive traffic considering 525 Medium Access Control (MAC) layer delay. Node workload MAY be set 526 upon CPU overload, lack of memory or any other node related 527 conditions. Using a simple 1-bit flag to characterize the node 528 workload provides a sufficient level of granularity, similarly to 529 the "overload" bit used in routing protocols such as IS-IS. 530 Algorithms used to set the overload bit and to compute paths to 531 potentially avoid nodes with their overload bit set are outside 532 the scope of this document, but it is RECOMMENDED to avoid 533 frequent changes of this bit to avoid routing oscillations. When 534 set, this indicates that the node is overloaded and may not be 535 able to process traffic. 537 They MUST be set to zero on transmission and MUST be ignored on 538 receipt. 540 The Flag field of the NSA Routing Metric/Constraint object is managed 541 by IANA. Unassigned bits are considered as reserved. 543 3.2. Node Energy Object 545 It may sometimes be desirable to avoid selecting a node with low 546 residual energy as a router, thus the support for constraint-based 547 routing is needed. In such cases, the routing protocol engine may 548 compute a longer path (constraint based) for some traffic in order to 549 increase the network life duration. 551 Power and energy are clearly critical resources in most LLNs. As yet 552 there is no simple abstraction which adequately covers the broad 553 range of power sources and energy storage devices used in existing 554 LLN nodes. These include mains-powered, primary batteries, energy 555 scavengers, and a variety of secondary storage mechanisms. 556 Scavengers may provide a reliable low level of power, such as might 557 be available from a 4-20mA loop; a reliable but periodic stream of 558 power, such as provided by a well-positioned solar cell; or 559 unpredictable power, such as might be provided by a vibrational 560 energy scavenger on an intermittently powered pump. Routes which are 561 viable when the sun is shining may disappear at night. A pump 562 turning on may connect two previously disconnected sections of a 563 network. 565 Storage systems like rechargeable batteries often suffer substantial 566 degradation if regularly used to full discharge, leading to different 567 residual energy numbers for regular versus emergency operation. A 568 route for emergency traffic may have a different optimum than one for 569 regular reporting. 571 Batteries used in LLNs often degrade substantially if their average 572 current consumption exceeds a small fraction of the peak current that 573 they can deliver. It is not uncommon for self-supporting nodes to 574 have a combination of primary storage, energy scavenging, and 575 secondary storage, leading to three different values for acceptable 576 average current depending on the time frame being considered, e.g. 577 milliseconds, seconds, and hours/years. 579 Raw power and energy values are meaningless without knowledge of the 580 energy cost of sending and receiving packets, and lifetime estimates 581 have no value without some higher-level constraint on the lifetime 582 required of a device. In some cases the path that exhausts the 583 battery of a node on the bed table in a month may be preferable to a 584 route that reduces the lifetime of a node in the wall to a decade. 586 Given the complexity of trying to address such a broad collection of 587 constraints, this document defines two levels of fidelity in the 588 solution. 590 The simplest solution relies on a 2-bit field encoding three types of 591 power sources: "powered", "battery", "scavenger". This simple 592 approach may be sufficient for many applications. 594 The mid-complexity solution is a single parameter that can be used to 595 encode the energetic happiness of both battery powered and scavenging 596 nodes. For scavenging nodes, the 8 bit quantity is the power 597 provided by the scavenger divided by the power consumed by the 598 application, E-E=P_in/P_out, in units of percent. Nodes which are 599 scavenging more power than they are consuming will register above 600 100. A good time period for averaging power in this calculation may 601 be related to the discharge time of the energy storage device on the 602 node, but specifying this is out of the scope of this document. For 603 battery powered devices, E-E is the current expected lifetime divided 604 by the desired minimum lifetime, in units of percent. The estimation 605 of remaining battery energy and actual power consumption can be 606 difficult, and the specifics of this calculation are out of scope of 607 this document, but two examples are presented. If the node can 608 measure its average power consumption, then E-E can be calculated as 609 the ratio of desired max power (initial energy E_0 divided by desired 610 lifetime T) to actual power, E-E=P_max/P_now. Alternatively, if the 611 energy in the battery E_bat can be estimated, and the total elapsed 612 lifetime, t, is available, then E-E can be calculated as the total 613 stored energy remaining versus the target energy remaining: E-E= 614 E_bat / [E_0 (T-t)/T]. 616 An example of optimized route is max(min(H)) for all battery operated 617 nodes along the route, subject to the constraint that E-E>=100 for 618 all scavengers along the route. 620 Note that the estimated percentage of remaining energy indicated in 621 the E-E field may not be useful in the presence of nodes powered by 622 battery or energy scavengers when the amount of energy accumulated by 623 the device significantly differ. Indeed, X% of remaining energy on a 624 node that can store a large amount of energy cannot be easily 625 compared to the same percentage of remaining energy on a node powered 626 by a tiny source of energy. That being said, in networks where nodes 627 have similar energy storage, such a percentage of remaining energy is 628 useful. 630 The Node Energy (NE) object is used to provide information related to 631 node energy and may be used as a metric or as constraint. 633 The NE object MAY be present in the DAG Metric Container. There MUST 634 NOT be more than one NE object as a constraint per DAG Metric 635 Container, and there MUST NOT be more than one NE object as a metric 636 per DAG Metric Container. 638 The NE object Type is to be assigned by IANA (recommended value=2). 640 The format of the NE object body is as follows: 642 0 1 2 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 645 | NE Sub-objects 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 648 Figure 3: NE sub-object format 650 The format of the NE sub-object body is as follows: 652 0 1 2 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 655 | Flags |I| T |E| E-E | Optional TLVs 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 658 Figure 4: NE sub-object format 660 The NE sub-object may also contain a set of TLVs used to convey 661 various nodes' characteristics. 663 Flags field (8 bits). The following flags are currently defined: 665 o I (Included): the I bit is only relevant when the node type is 666 used as a constraint. For example, the path must only traverse 667 mains-powered nodes. Conversely, battery operated nodes must be 668 excluded. The I bit is used to stipulate inclusion versus 669 exclusion. When set, this indicates that nodes of the type 670 specified in the node type field MUST be included. Conversely, 671 when cleared, this indicates that nodes of type specified in the 672 node type field MUST be excluded. 674 o T (node Type): 2-bit field indicating the node type. T=0x00 675 designates a mains-powered node, T=0x01 a battery-powered node and 676 T=0x02 a node powered by an energy scavenger. 678 o E (Estimation): when the E bit is set for a metric, the estimated 679 percentage of remaining energy on the node is indicated in the E-E 680 8-bit field. When cleared, the estimated percentage of remaining 681 energy is not provided. When the E bit is set for a constraint, 682 the E-E field defines a threshold for the inclusion/exclusion: if 683 an inclusion, nodes with values higher than the threshold are to 684 be included; if an exclusion, nodes with values lower than the 685 threshold are to be excluded. 687 E-E (Estimated-Energy): 8-bit unsigned integer field indicating an 688 estimated percentage of remaining energy. The E-E field is only 689 relevant when the E flag is set, and MUST be set to 0 when the E flag 690 is cleared. 692 If the NE object comprises several sub-objects when used as a 693 constraint, each sub-object adds or subtracts node subsets as the 694 sub-objects are parsed in order. The initial set (full or empty) is 695 defined by the I bit of the first sub-object: full if that I bit is 696 an exclusion, empty if that I bit is an inclusion. 698 No TLV is currently defined. 700 Future documents may define more complex solutions involving TLV 701 parameters representing energy storage, consumption, and generation 702 capabilities of the node, as well as desired lifetime. 704 3.3. Hop-Count Object 706 The HoP-Count (HP) object is used to report the number of traversed 707 nodes along the path. 709 The HP object MAY be present in the DAG Metric Container. There MUST 710 NOT be more than one HP object as a constraint per DAG Metric 711 Container, and there MUST NOT be more than one HP object as a metric 712 per DAG Metric Container. 714 The HP object may also contain a set of TLVs used to convey various 715 node characteristics. No TLV is currently defined. 717 The HP routing metric object Type is to be assigned by IANA 718 (recommended value=3) 719 The format of the Hop Count object body is as follows: 721 0 1 2 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 724 | Res | Flags | Hop Count | Optional TLVs 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 727 Figure 5: Hop Count object body format 729 Res flags (4 bits): Reserved field. This field MUST be set to zero 730 on transmission and MUST be ignored on receipt. 732 No Flag is currently defined. Unassigned bits are considered as 733 reserved. They MUST be set to zero on transmission and MUST be 734 ignored on receipt. 736 The HP object may be used as a constraint or a metric. When used as 737 a constraint, the DAG root indicates the maximum number of hops that 738 a path may traverse. When that number is reached, no other node can 739 join that path. When used as a metric, each visited node simply 740 increments the Hop Count field. 742 Note that the first node along a path inserting a Hop-count Metric 743 object MUST set the Hop Count field value to 1. 745 4. Link Metric/Constraint Objects 747 4.1. Throughput 749 Many LLNs support a wide range of throughputs. For some links, this 750 may be due to variable coding. For the deeply duty-cycled links 751 found in many LLNs, the variability comes as a result of trading 752 power consumption for bit rate. There are several MAC layer 753 protocols which allow for the effective bit rate of a link to vary 754 over more than three orders of magnitude with a corresponding change 755 in power consumption. For efficient operation, it may be desirable 756 for nodes to report the range of throughput that their links can 757 handle in addition to the currently available throughput. 759 The Throughput object MAY be present in the DAG Metric Container. 760 There MUST NOT be more than one Throughput object as a constraint per 761 DAG Metric Container, and there MUST NOT be more than one Throughput 762 object as a metric per DAG Metric Container. 764 The Throughput object is made of throughput sub-objects and MUST at 765 least comprise one Throughput sub-object. The first Throughput sub- 766 object MUST be the most recently estimated actual throughput. The 767 actual estimation of the throughput is outside the scope of this 768 document. 770 Each Throughput sub-object has a fixed length of 4 bytes. 772 The Throughput object does not contain any additional TLV. 774 The Throughput object Type is to be assigned by IANA (recommended 775 value=4) 777 The format of the Throughput object body is as follows: 779 0 1 780 0 1 2 3 4 5 6 7 8 9 0 1 2 3 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | (sub-object) ..... 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 Figure 6: Throughput object body format 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Throughput | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Figure 7: Throughput sub-object format 795 Throughput: 32 bits. The Throughput is encoded in 32 bits in 796 unsigned integer format, expressed in bytes per second. 798 4.2. Latency 800 Similarly to throughput, the latency of many LLN MAC sub-layers can 801 vary over many orders of magnitude, again with a corresponding change 802 in power consumption. Some LLN MAC link layers will allow the 803 latency to be adjusted globally on the subnet, on a link-by-link 804 basis, or not at all. Some will insist that it be fixed for a given 805 link, but allow it to be variable from link to link. 807 The Latency object MAY be present in the DAG Metric Container. There 808 MUST NOT be more than one Latency object as a constraint per DAG 809 Metric Container, and there MUST NOT be more than one Latency object 810 as a metric per DAG Metric Container. 812 The Latency object is made of Latency sub-objects and MUST at least 813 comprise one Latency sub-object. Each Latency sub-object has a fixed 814 length of 4 bytes. 816 The Latency object does not contain any additional TLV. 818 The Latency object Type is to be assigned by IANA (recommended 819 value=5) 821 The Latency object is a metric or constraint. 823 The format of the Latency object body is as follows: 825 0 1 826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | (sub-object) ..... 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Figure 8: Latency object body format 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Latency | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 9: Latency sub-object format 841 Latency: 32 bits. The Latency is encoded in 32 bits in unsigned 842 integer format, expressed in microseconds. 844 The Latency object may be used as a constraint or a path metric. For 845 example, one may want the latency not to exceed some value. In this 846 case, the Latency object common header indicates that the provided 847 value relates to a constraint. In another example, the Latency 848 object may be used as an aggregated additive metric where the value 849 is updated along the path to reflect the path latency. 851 4.3. Link Reliability 853 In LLNs, link reliability could be degraded for a number of reasons: 854 signal attenuation, interferences of various forms, etc ... Time 855 scales vary from milliseconds to days, and are often periodic and 856 linked to human activity. Packet error rates can generally be 857 measured directly, and other metrics (e.g. bit error rate, mean time 858 between failures) are typically derived from that. Note that such 859 variability is not specific to wireless link but also applies to PLC 860 links. 862 A change in link quality can affect network connectivity, thus, link 863 quality may be taken into account as a critical routing metric. 865 A number of link reliability metrics could be defined reflecting 866 several reliability aspects. Two link reliability metrics are 867 defined in this document: the Link Quality Level (LQL) and the 868 Expected Transmission count Metric (ETX). 870 Note that an RPL deployment MAY either use the LQL, the ETX or both. 872 4.3.1. The Link Quality Level Reliability Metric 874 The Link Quality Level (LQL) object is used to quantify the link 875 reliability using a discrete value, from 0 to 7 where 0 indicates 876 that the link quality level is unknown and 1 reports the highest link 877 quality level. The mechanisms and algorithms used to compute the LQL 878 are implementation specific and outside of the scope of this 879 document. 881 The LQL can either be used as a metric or a constraint. When used as 882 a metric, the LQL metric can only be recorded. For example, the DAG 883 Metric object may request all traversed nodes to record the LQL of 884 their incoming link into the LQL object. Each node can then use the 885 LQL record to select its parent based on some user defined rules 886 (e.g. something like "select the path with most links reporting a LQL 887 value of 3 or less"). 889 Counters are used to compress the information: for each encountered 890 LQL value, only the number of matching links is reported. 892 The LQL object MAY be present in the DAG Metric Container. There 893 MUST NOT be more than one LQL object as a constraint per DAG Metric 894 Container, and there MUST NOT be more than one LQL object as a metric 895 per DAG Metric Container. 897 The LQL object MUST contain one or more sub-object used to report the 898 number of links along with their LQL. 900 The LQL object Type is to be assigned by IANA (recommended value=6) 901 The format of the LQL object body is as follows: 903 0 1 2 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 906 | Res | LQL sub-object 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 909 Figure 10: LQL object body format 911 Res flags (8 bits): Reserved field. This field MUST be set to zero 912 on transmission and MUST be ignored on receipt. 914 When the LQL metric is recorded, the LQL object body comprises one or 915 more LQL Type 1 sub-object. 917 The format of the LQL Type 1 sub-object is as follows 919 0 920 0 1 2 3 4 5 6 7 921 +-+-+-+-+-+-+-+-+ 922 | Val | Counter | 923 +-+-+-+-+-+-+-+-+ 925 Figure 11: LQL Type 1 sub-object format 927 Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates 928 the highest link quality. 930 Counter: number of links with that value. 932 4.3.2. The Expected Transmission Count (ETX) reliability object 934 The Expected Transmission Count (ETX) metric is the number of 935 transmissions a node expects to make to a destination in order to 936 successfully deliver a packet. In contrast with the LQL routing 937 metric, the ETX provides a discrete value (which may not be an 938 integer) computed according to a specific formula: for example, an 939 implementation may use the following formula: ETX= 1 / (Df * Dr) 940 where Df is the measured probability that a packet is received by the 941 neighbor and Dr is the measured probability that the acknowledgment 942 packet is successfully received. This document does not mandate the 943 use of a specific formula to compute the ETX value. 945 The ETX object MAY be present in the DAG Metric Container. There 946 MUST NOT be more than one ETX object as a constraint per DAG Metric 947 Container, and there MUST NOT be more than one ETX object as a metric 948 per DAG Metric Container. 950 The ETX object is made of ETX sub-objects and MUST at least comprise 951 one ETX sub-object. Each ETX sub-object has a fixed length of 16 952 bits. 954 The ETX object does not contain any additional TLV. 956 The ETX object Type is to be assigned by IANA (recommended value=7) 958 The format of the ETX object body is as follows: 960 0 1 961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | (sub-object) ..... 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Figure 12: ETX object body format 968 0 1 969 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | ETX | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 Figure 13: ETX sub-object format 976 ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned 977 integer format, rounded off to the nearest whole number. For 978 example, if ETX = 3.569, the object value will be 457. If ETX > 979 511.9921875, the object value will be the maximum which is 65535. 981 The ETX object may be used as a constraint or a path metric. For 982 example, it may be required that the ETX must not exceed some 983 specified value. In this case, the ETX object common header 984 indicates that the value relates to a constraint. In another 985 example, the ETX object may be used as an aggregated additive metric 986 where the value is updated along the path to reflect the path 987 quality: when a node receives the aggregated additive ETX value of 988 the path (cummulative path ETX calculated as the sum of the link ETX 989 of all of the traversed links from the advertising node to the DAG 990 root), if it selects that node as its preferred parent, the node 991 updates the path ETX by adding the ETX of the local link between 992 itself and the preferred parent to the received path cost (path ETX) 993 before potentially advertising itself the new path ETX. 995 4.4. Link Color Object 997 4.4.1. Link Color Object Description 999 The Link Color (LC) object is an administrative 10-bit link 1000 constraint (which may either be static or dynamically adjusted) used 1001 to avoid or attract specific links for specific traffic types. 1003 The LC object can either be used as a metric or as a constraint. 1004 When used as a metric, the LC metric can only be recorded. For 1005 example, the DAG may require recording the link colors for all 1006 traversed links. A color is defined as a specific set of bit values: 1007 in other words, that 10-bit field is a flag field, and not a scalar 1008 value. Each node can then use the LC to select the parent based on 1009 user defined rules (e.g. "select the path with the maximum number of 1010 links having their first bit set 1 (e.g. encrypted links)"). The LC 1011 object may also be used as a constraint. 1013 When used as a recorded metric, a counter is used to compress the 1014 information where the number of links for each Link Color is 1015 reported. 1017 The Link Color (LC) object MAY be present in the DAG Metric 1018 Container. There MUST NOT be more than one LC object as a constraint 1019 per DAG Metric Container, and there MUST NOT be more than one LC 1020 object as a metric per DAG Metric Container. 1022 There MUST be a at least one LC sub-object per LC object. 1024 The LC object does not contain any additional TLV. 1026 The LC object Type is to be assigned by IANA (recommended value=8) 1028 The format of the LC object body is as follows: 1030 0 1 2 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1033 | Res | LC sub-objects 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1036 Figure 14: LC object format 1038 Res flags (8 bits): Reserved field. This field MUST be set to zero 1039 on transmission and MUST be ignored on receipt. 1041 When the LC object is used as a recorded metric, the LC object body 1042 comprises one or more LC Type 1 sub-objects. 1044 The format of the LC Type 1 sub-object body is as follows: 1046 0 1 1047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Link Color | Counter | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 Figure 15: LC Type 1 sub-object format 1054 When the LC object is used as a constraint, the LC object body 1055 comprises one or more LC Type 2 sub-objects. 1057 The format of the LC Type 2 sub-object body is as follows: 1059 0 1 1060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Link Color |Reserved |I| 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 16: LC Type 2 sub-object format 1067 Res flags (7 bits): Reserved field. This field MUST be set to zero 1068 on transmission and MUST be ignored on receipt. 1070 I Bit: The I bit is only relevant when the Link Color is used as a 1071 constraint. When cleared, this indicates that links with the 1072 specified color must be included. When set, this indicates that 1073 links with the specified color must be excluded. 1075 It is left to the implementer to define the meaning of each bit of 1076 the 10-bit Link Color Flag field. 1078 4.4.2. Mode of operation 1080 The link color may be used as a constraint or a metric. 1082 o When used as constraint, the LC object may be inserted in the DAG 1083 Metric Container to indicate that links with a specific color 1084 should be included or excluded from the computed path. 1086 o When used as recorded metric, each node along the path may insert 1087 a LC object in the DAG Metric Container to report the color of the 1088 local link. If there is already a LC object reporting a similar 1089 color, the node MUST NOT add another identical LC sub-object and 1090 MUST increment the counter field. 1092 5. Computation of Dynamic Metrics and Attributes 1094 As already pointed out, dynamically calculated metrics are of the 1095 utmost importance in many circumstances in LLNs. This is mainly 1096 because a variety of metrics change on a frequent basis, thus 1097 implying the need to adapt the routing decisions. That being said, 1098 care must be given to the pace at which changes are reported in the 1099 network. The attributes will change according to their own time 1100 scales. RPL controls the reporting rate. 1102 To minimize metric updates, multi-threshold algorithms MAY be used to 1103 determine when updates should be sent. When practical, low-pass 1104 filtering and/or hysteresis should be used to avoid rapid 1105 fluctuations of these values. Finally, although the specification of 1106 path computation algorithms using dynamic metrics are out the scope 1107 of this document, it is RECOMMENDED to carefully design the route 1108 optimization algorithm to avoid too frequent computation of new 1109 routes upon metric values changes. 1111 Controlled adaptation of the routing metrics and rate at which paths 1112 are computed are critical to avoid undesirable routing instabilities 1113 resulting in increased latencies and packet loss because of temporary 1114 micro-loops. Furthermore, excessive route changes will adversely 1115 impact the traffic and power consumption in the network, thus 1116 potentially impacting its scalability. 1118 6. IANA Considerations 1120 IANA is requested to establish a new top-level registry, called "RPL 1121 Routing Metric/Constraint", to contain all Routing Metric/Constraint 1122 objects codepoints and sub-registries. 1124 The allocation policy for each new registry is by IETF review: new 1125 values are assigned through the IETF review process (see [RFC5226]). 1126 Specifically, new assignments are made via RFCs approved by the IESG. 1127 Typically, the IESG will seek input on prospective assignments from 1128 appropriate persons (e.g., a relevant Working Group if one exists). 1130 New bit numbers may be allocated only by an IETF Review action. Each 1131 bit should be tracked with the following qualities: 1133 o Bit number 1135 o Capability Description 1137 o Defining RFC 1139 6.1. Routing Metric/Constraint Type 1141 IANA is requested to create a subregistry, called "Routing Metric/ 1142 Constraint Type", for Routing Metric/Constraint object types, which 1143 range from 0 to 255. Value 0 is undefined. 1145 Value Meaning Reference 1146 1 Node State and Attribute This document 1147 2 Node Energy This document 1148 3 Hop Count This document 1149 4 Link Throughput This document 1150 5 Link Latency This document 1151 6 Link Quality Level This document 1152 7 Link ETX This document 1153 8 Link Color This document 1155 6.2. Routing Metric/Constraint TLVs 1157 IANA is requested to create a subregistry, called "Routing Metric/ 1158 Constraint TLVs", used for all TLVs carried within Routing Metric/ 1159 Constraint objects. The Type field is an 8-bit field whose value is 1160 comprised between 0 and 255. Value 0 is undefined. The Length file 1161 is an 8-bit field whose value ranges from 0 to 255. The Value field 1162 has value ranges depending on the Type, therefore are not defined 1163 here, since no Type is registered at this time. 1165 6.3. Routing Metric/Constraint Common Header Flag field 1167 IANA is requested to create a subregistry, called "Routing Metric/ 1168 Constraint Common Header Flag field", to manage the 9-bit Flag field 1169 of the Routing Metric/Constraint common header. 1171 Several bits are defined for the Routing Metric/Constraint common 1172 header Flag field in this document. The following values have been 1173 assigned: 1175 Codespace of the Flag field (Routing Metric/Constraint common header) 1176 Bit Description Reference 1178 8 Recorded/Aggregated This document 1179 7 Optional Constraint This document 1180 6 Constraint/Metric This document 1181 5 P (Partial) This document 1183 Bits 0-4 are currently reserved. 1185 6.4. Routing Metric/Constraint Common Header A field 1187 IANA is requested to create a subregistry, called "Routing Metric/ 1188 Constraint Common Header A field", to manage the codespace of the A 1189 field of the Routing Metric/Constraint common header. 1191 The A field is 3 bits in length, and has values ranging from 0 to 7. 1193 Codespace of the A field (Routing Metric/Constraint common header) 1194 Value Meaning Reference 1196 0 Routing metric is additive This document 1197 1 Routing metric reports a maximum This document 1198 2 Routing metric reports a minimum This document 1199 3 Routing metric is multiplicative This document 1201 6.5. NSA Object Flag field 1203 IANA is requested to create a subregistry, called "NSA Object Flag 1204 field", to manage the codespace of the 8-bit Flag field of the NSA 1205 object. 1207 Several bits are defined for the NSA object flag field in this 1208 document. The following values have been assigned: 1210 Codespace of the Flag field (NSA object) 1211 Bit Description Reference 1213 6 Aggregator This document 1214 7 Overloaded This document 1216 Bits 0-5 are reserved. 1218 6.6. Hop-Count Object Flag field 1220 IANA is requested to create a subregistry, called "Hop-Count Object 1221 Flag field", to manage the codespace of the 4-bit Flag field of the 1222 Hop-count object. 1224 No Flag is currently defined. 1226 7. Security Considerations 1228 Routing metrics should be handled in a secure and trustful manner. 1229 For instance, RPL should not allow a malicious node to falsely 1230 advertise that it has good metrics for routing, be added as a router 1231 for other nodes' traffic and intercept packets. Another attack may 1232 consist of making intermittent attacks on a link in an attempt to 1233 constantly modify the link quality and consequently the associated 1234 routing metric, thus leading to potential fluctuation in the DODAG. 1235 It is thus RECOMMENDED for a RPL implementation to put in place 1236 mechanisms so as to stop advertising routing metrics for highly 1237 unstable links that may be subject to attacks. 1239 Some routing metrics may also be used to identify some areas of 1240 weaknesses in the network (a highly unreliable link, a node running 1241 low in terms of energy, etc.). Such information may be used by a 1242 potential attacker. Thus, it is RECOMMENDED to carefully consider 1243 which metrics should be used by RPL and the level of visibility that 1244 they provide about the network state or to use appropriate the 1245 security measures as specified in [I-D.ietf-roll-rpl] to protect that 1246 information. 1248 Since the routing metrics/constraints are carried within RPL message, 1249 the security routing mechanisms defined in [I-D.ietf-roll-rpl] 1250 applies here. 1252 8. Acknowledgements 1254 The authors would like to acknowledge the contributions of Young Jae 1255 Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip 1256 Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru 1257 Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, 1258 Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, 1259 Mukul Goyal, Joseph Saloway, David Culler and Jari Arkko for their 1260 review and valuable comments. Special thank to Adrian Farrel for his 1261 thourough review. 1263 9. References 1265 9.1. Normative references 1267 [I-D.ietf-roll-rpl] 1268 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1269 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1270 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1271 Lossy Networks", draft-ietf-roll-rpl-18 (work in 1272 progress), February 2011. 1274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1275 Requirement Levels", BCP 14, RFC 2119, March 1997. 1277 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1278 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1279 May 2008. 1281 9.2. Informative references 1283 [I-D.ietf-roll-of0] 1284 Thubert, P., "RPL Objective Function 0", 1285 draft-ietf-roll-of0-05 (work in progress), January 2011. 1287 [I-D.ietf-roll-terminology] 1288 Vasseur, J., "Terminology in Low power And Lossy 1289 Networks", draft-ietf-roll-terminology-04 (work in 1290 progress), September 2010. 1292 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1293 dual environments", RFC 1195, December 1990. 1295 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1297 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1298 McManus, "Requirements for Traffic Engineering Over MPLS", 1299 RFC 2702, September 1999. 1301 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1302 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1303 Tunnels", RFC 3209, December 2001. 1305 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1306 "Routing Requirements for Urban Low-Power and Lossy 1307 Networks", RFC 5548, May 2009. 1309 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1310 "Industrial Routing Requirements in Low-Power and Lossy 1311 Networks", RFC 5673, October 2009. 1313 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1314 Routing Requirements in Low-Power and Lossy Networks", 1315 RFC 5826, April 2010. 1317 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1318 "Building Automation Routing Requirements in Low-Power and 1319 Lossy Networks", RFC 5867, June 2010. 1321 [Zinky1989] 1322 Zinky, J., Vichniac, G., and A. Khanna, "Performance of 1323 the Revised Routing Metric for ARPANET and MILNET", 1324 Military Communications Conference, 1989. MILCOM '89 , 1325 March 1989. 1327 Authors' Addresses 1329 JP Vasseur (editor) 1330 Cisco Systems, Inc 1331 11, Rue Camille Desmoulins 1332 Issy Les Moulineaux, 92782 1333 France 1335 Email: jpv@cisco.com 1337 Mijeom Kim (editor) 1338 Corporate Technology Group, KT 1339 17 Woomyeon-dong, Seocho-gu 1340 Seoul, 137-792 1341 Korea 1343 Email: mjkim@kt.com 1345 Kris Pister 1346 Dust Networks 1347 30695 Huntwood Ave. 1348 Hayward, CA 95544 1349 USA 1351 Email: kpister@dustnetworks.com 1353 Nicolas Dejean 1354 Elster SAS 1355 Espace Concorde, 120 impasse JB Say 1356 Perols, 34470 1357 France 1359 Email: nicolas.dejean@coronis.com 1361 Dominique Barthel 1362 France Telecom Orange 1363 28 chemin du Vieux Chene, BP 98 1364 Meylan, 38243 1365 France 1367 Email: dominique.barthel@orange-ftgroup.com