idnits 2.17.1 draft-ietf-roll-routing-metrics-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2010) is 5039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Khanna1989' is mentioned on line 161, but not defined == Unused Reference: 'RFC3471' is defined on line 1276, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-10 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group JP. Vasseur, Ed. 3 Internet-Draft Cisco Systems, Inc 4 Intended status: Standards Track M. Kim, Ed. 5 Expires: January 10, 2011 Corporate Technology Group, KT 6 K. Pister 7 Dust Networks 8 N. Dejean 9 Coronis SAS 10 D. Barthel 11 France Telecom Orange 12 July 09, 2010 14 Routing Metrics used for Path Calculation in Low Power and Lossy 15 Networks 16 draft-ietf-roll-routing-metrics-08 18 Abstract 20 Low power and Lossy Networks (LLNs) have unique characteristics 21 compared with traditional wired and ad-hoc networks that require the 22 specification of new routing metrics and constraints. By contrast 23 with typical Interior Gateway Protocol (IGP) routing metrics using 24 hop counts or link metrics, this document specifies a set of link and 25 node routing metrics and constraints suitable to LLNs. 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." 48 This Internet-Draft will expire on January 10, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 9 70 3.1. Node State and Attributes object . . . . . . . . . . . . . 9 71 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 11 72 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 14 73 3.4. Node Fanout Ratio object . . . . . . . . . . . . . . . . . 15 74 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16 75 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 18 78 4.3.1. The Link Quality Level reliability metric . . . . . . 19 79 4.3.2. The Expected Transmission Count (ETX) reliability 80 object . . . . . . . . . . . . . . . . . . . . . . . . 20 81 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 22 82 4.4.1. Link Color object description . . . . . . . . . . . . 22 83 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 23 84 5. Computation of dynamic metrics and attributes . . . . . . . . 23 85 6. Use of multiple DAG Metric Container . . . . . . . . . . . . . 24 86 7. Metric consistency . . . . . . . . . . . . . . . . . . . . . . 24 87 8. Metric usage . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 9.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 90 9.2. Routing Metric/Constraint common header . . . . . . . . . 26 91 9.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 92 9.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 27 93 10. Security considerations . . . . . . . . . . . . . . . . . . . 28 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 12.1. Normative references . . . . . . . . . . . . . . . . . . . 28 97 12.2. Informative references . . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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 115 (static) to compute constrained shortest paths for Traffic 116 Engineering Label Switched Paths (TE LSPs). 118 This document specifies routing metrics and constraints to be used in 119 path calculation by the Routing Protocol for Low Power and Lossy 120 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 122 One of the prime objectives of this document is to propose a flexible 123 mechanism for the advertisement of routing metrics and constraints 124 used by RPL. Some RPL implementations may elect to adopt an 125 extremely simple approach based on the use of a single metric with no 126 constraint whereas other implementations may use a larger set of link 127 and node routing metrics and constraints. This specification 128 provides a high degree of flexibility and a set of routing metrics 129 and constraints. New routing metrics and constraints could be 130 defined in the future, as needed. 132 RPL is a distance vector routing protocol that builds a Directed 133 Acyclic Graph (DAG) based on routing metrics and constraints. DAG 134 formation rules are defined in [I-D.ietf-roll-rpl]: 136 o The DAG root may advertise a routing constraint used as a "filter" 137 to prune links and nodes that do not satisfy specific properties. 138 For example, it may be required for the path to only traverse 139 nodes that are mains powered or links that have at least a minimum 140 reliability or a specific "color" reflecting a user defined link 141 characteristic (e.g the link layer supports encryption). 143 o A routing metric is a quantitative value that is used to evaluate 144 the path cost. Link and nodes metrics are usually (but not 145 always) additive. 147 The best path is the path with the lowest cost with respect to some 148 metrics that satisfies all constraints (if any) and is also called 149 the shortest constrained path (in the presence of constraints). 151 Routing metrics can be classified according to the following set of 152 characteristics: 154 o Link versus Node metrics 156 o Qualitative versus quantitative 158 o Dynamic versus static 160 It must be noted that the use of dynamic metrics is not new and has 161 been experimented in ARPANET 2 [Khanna1989], with moderate success. 162 The use of dynamic metrics is not trivial and great care must be 163 given to the use of dynamic metrics since it may lead to potential 164 routing instabilities. 166 As pointed out in various routing requirements documents (see 167 [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to 168 take into account a variety of node constraints/metrics during path 169 computation. 171 It is also worth mentioning that it is fairly common for links in 172 LLNs to have fast changing node and link characteristics, which must 173 be taken into account when specifying routing metrics. For instance, 174 in addition to the dynamic nature of wireless connectivity, nodes' 175 resources such as residual energy and other link's charatacteristics 176 such as the throughput are changing continuously and may have to be 177 taken into account during the path computation. Similarly, link 178 attributes including throughput and reliability may drastically 179 change over time due to multi-path interference. 181 Very careful attention must be given when using dynamic metrics and 182 attributes that affect routing decisions in order to preserve routing 183 stability. Routing metrics and constraints may either be static or 184 dynamic. When dynamic, a RPL implementation SHOULD make use of a 185 multi-threshold scheme rather than fine granular metric updates so as 186 to avoid constant routing changes. 188 Furthermore, it is a time and energy consuming process to update 189 dynamic metrics and recompute the routing tables on a frequent basis. 190 Therefore, it may be desirable to use a set of discrete values to 191 reduce computational overhead and bandwidth utilization. Of course, 192 this comes with a cost, namely, reduced metric accuracy. In other 193 cases, a set of flags may be defined to reflect a node state without 194 having to define discrete values. 196 Some link or node characteristics (e.g. link reliability flag, energy 197 remaining on the node) may either be used by RPL as routing 198 constraints or metric. For example, the path may be computed to 199 avoid links that do not provide a sufficient level of reliability 200 (use as a constraint) or as the path offering the maximum number of 201 links with a specified reliability level (use as a metric). 203 The set of routing metrics and constraints used by an RPL 204 implementation is signalled along the Directed Acyclic Graph (DAG) 205 that is built according to the Objective Function (rules governing 206 how to build a DAG) and the routing metrics and constraints 207 advertised in the Dag Information Option (DIO) message specified in 208 [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different 209 characteristics. For example, it may be desirable to build a DAG 210 with the goal to maximize reliability by using the link reliability 211 metric to compute the "best" path. Another example might be to use 212 the energy node characteristic (e.g. mains powered versus battery 213 operated) as a node constraint when building the DAG so as to avoid 214 battery powered nodes in the DAG while optimizing the link 215 throughput. 217 Links and nodes routing metrics and constraints are not exclusive. 219 The requirements on reporting frequency may differ among metrics, 220 thus different reporting rates may be used for each category. 222 The specification of objective functions used to compute the DAG 223 built by RPL is out of the scope of this document and will be 224 specified in other documents. Routing metrics and constraints are 225 decoupled from the objective function. So a generic objective 226 function could for example specify the rules to select the best 227 parents in the DAG, the number of backup parents, etc. Such 228 objective function can be used with any routing metrics and/or 229 contraints such as the ones specified in this document. 231 Some metrics are either aggregated or recorded. In the former case, 232 the metric is adjusted as the DIO message travels along the DAG. For 233 example, if the metric is the link latency, each node updates the 234 latency metric along the DAG. By contrast, metric may be recorded in 235 which case each node adds a sub-object reflecting the local metric. 236 For example, it might be desirable to record the link quality level 237 along the path. In this case, each visited node adds a sub-object 238 reporting the local link quality level. In order to limit the number 239 of sub-objects, the use of a counter may be desirable (e.g. record 240 the number of links with a certain link quality level). Upon 241 receiving the DIO message from a set of parents, a node can decide 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 Notion of local versus global metric: some routing objects may have a 246 local or a global significance. In the former case, a metric may be 247 transmitted to a neighbor to charaterize a link or a node as opposed 248 to a path. For example, a node may report information about its 249 local energy without the need to propagate the energy level of all 250 nodes along the path. In contrast, other metrics such as link 251 latency metrics are additive and global in the sense that they 252 characterize a path cost using the latency as a metric. In this 253 particular example the path latency is an aggregated global and 254 additive link metric. 256 2. Object formats 258 Routing metrics and constraints are carried within the DAG Metric 259 Container object defined in [I-D.ietf-roll-rpl]. 261 0 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 264 | Type=2 | Option Len | Routing Metric/Constraint objects 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 267 Figure 1: DAG Metric Container format 269 The Routing Metric/Contraints objects have a common format consisting 270 of one or more 8-bit words with a common header: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 // (object body) // 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 2: Routing Metric/Constraint object generic format 284 The object body carries one or more sub-objects. 286 Note that the Routing Metric/Constraint objects defined in this 287 document can appear in any order in the DAG Metric Container. 288 However, for some of them, the order is significant (as described in 289 Section 8 and Section 3.2, for example). 291 Routing-MC-Type: (Routing Metric/Contraint Type - 8 bits): the 292 Routing Metric/Constraint Type field uniquely identifies each Routing 293 Metric/Constraint object and is managed by IANA. 295 Res flags (2 bits). Reserved field. This field MUST be set to zero 296 on transmission and MUST be ignored on receipt. 298 o C Flag. When set, this indicates that the Routing Metric/ 299 Constraint object refers to a routing constraint. When cleared 300 the routing object refers to a routing metric. 302 o O Flag: The O flag is used exclusively for routing constraints (C 303 flag is set) and has no meaning for routing metrics. When set, 304 this indicates that the constraint is optional. When cleared, the 305 constraint is mandatory. 307 o A Field: The A field is used to indicate whether a routing metric 308 is additive, multiplicative, reports a maximum or a minimum. 310 * A=0x00: The routing metric is additive 312 * A=0x01: The routing metric reports a maximum 314 * A=0x02: The routing metric reports a minimum 316 * A=0x03: The routing metric is multiplicative 318 The A field has no meaning when the C Flag is set (i.e. when the 319 Routing Metric/Constraint object refers to a routing constraint). 321 o G Flag: When set, the Routing Metric/Constraint object is global. 322 When cleared it is local (see details below). 324 o R Flag: The R Flag is only relevant for global routing metric (C=0 325 and G=1) and MUST be cleared for all other values of C and G. When 326 set, this indicates that the routing metric is recorded along the 327 path. Conversely, when cleared the routing metric is aggregated. 329 Example 1: A DAG formed by RPL where all nodes must be mains powered 330 and the link metric is the link quality characterized by the ETX. In 331 this case the DAG Metric container carries two Routing Metric/ 332 Constraint objects: the link metric is the link ETX (C=0, O=0, A=00, 333 G=1, R=0) and the node constraint is power (C=1, O=0, A=00, G=0, 334 R=0). Note that in this example, the link quality is a global 335 additive aggregated link metric. Note that a RPL implementation may 336 use the metric to report a maximum (A=0x01) or a minimum (A=0x02). 337 If the best path is characterized by the path avoiding low quality 338 links for example, then the path metric reports a maximum (A=0x02): 340 when the link quality metric (ETX) is processed each node updates it 341 if the link quality (ETX) is higher than the current value reported 342 by the link quality metric. 344 Example 2: A DAG formed by RPL where the link metric is the link 345 quality level and link quality levels must be recorded along the 346 path. In this case, the DAG Metric Container carries a Routing 347 Metric/Constraint object: link quality level (C=0, O=0, A=00, G=1, 348 R=1) containing multiple sub-objects. 350 A Routing Metric/Constraint object may also include one or more type- 351 length-value (TLV) encoded data sets. Each Routing Metric/Constraint 352 TLV has the same structure: 354 Type: 1 byte 355 Length: 1 byte 356 Value: variable 358 A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 359 1 byte specifying the TLV length, and a value field. 361 The Length field defines the length of the value field in bytes. 363 Unrecognized TLVs MUST be ignored. 365 IANA management of the Routing Metric/Constraint objects identifier 366 codespace is described in Section 9. 368 3. Node Metric/Constraint objects 370 It is fairly common for LLNs to be made of nodes with heterogeneous 371 attributes and capabilities (e.g. nodes being battery operated or 372 not, amount of memory, etc). More capable and stable nodes may 373 assist the most constrained ones for routing packets, which results 374 in extension of network lifetime and efficient network operations. 375 This is a typical use of constraint-based routing where the computed 376 path may not be the shortest path according to some specified 377 metrics. 379 3.1. Node State and Attributes object 381 The Node State and Attribute (NSA) object is used to provide 382 information on the nodes characteristics. 384 The NSA object MAY be present in the DAG Metric Container. There 385 MUST be no more than one NSA object as a constraint per DAG Metric 386 Container, and no more than one NSA object as a metric per DAG Metric 387 Container. 389 The NSA object may also contain a set of TLVs used to convey various 390 node characteristics. No TLV is currently defined. 392 The NSA Routing Metric/Constraint Type is to be assigned by IANA 393 (recommended value=1). 395 The format of the NSA object body is as follows: 397 0 1 2 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 400 | Res | Flags |A|O| Optional TLVs 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 403 Figure 3: NSA object format 405 Node workload may be hard to determine and express in some scalar 406 form. However, node workload could be a useful metric to consider 407 during path calculation, in particular when queuing delays must be 408 minimized for highly sensitive traffic considering Medium Access 409 Control (MAC) layer delay. Node workload MAY be set upon CPU 410 overload, lack of memory or any other node related conditions. Using 411 a simple 1-bit flag to characterize the node workload provides a 412 sufficient level of granularity, similarly to the "overload" bit used 413 in routing protocols such as IS-IS. Algorithms used to set the 414 overload bit and to compute path to potentially avoid node with their 415 overload bit set are outside the scope of this document. 417 Data Aggregation Attribute: data fusion involves more complicated 418 processing to improve accuracy of the output data while data 419 aggregation mostly aims at reducing the amount of data. This is 420 listed as a requirement in Section 6.2 of [RFC5548]. Some 421 applications may make use of the aggregation node attribute in their 422 routing decision so as to minimize the amount of traffic on the 423 network, thus potentially increasing its life time in battery 424 operated environments. Applications where high directional data flow 425 is expected on a regular basis may take advantage of data aggregation 426 supported routing. 428 The following two bits of the NSA object are defined: 430 o O Flag: When set, this indicates that the node is overloaded and 431 may not be able to process traffic. 433 o A Flag: When set, this indicates that the node can act as a 434 traffic aggregator. An implementation MAY decide to add optional 435 TLVs (not currently defined) to further describe the node traffic 436 aggregator functionality. 438 The Flag field of the NSA Routing Metric/Constraint object is managed 439 by IANA. Unassigned bits are considered as reserved. They MUST be 440 set to zero on transmission and MUST be ignored on receipt. 442 3.2. Node Energy object 444 Whenever possible, a node with low residual energy should not be 445 selected as a router, thus the support for constraint-based routing 446 is needed. In such cases, the routing protocol engine may compute a 447 longer path (constraint based) for some traffic in order to increase 448 the network life duration. 450 The routing engine may prefer a "longer" path that traverses mains- 451 powered nodes or nodes equipped with energy scavenging, rather than a 452 "shorter" path through battery operated nodes. 454 Power and energy are clearly critical resources in LLNs. As yet 455 there is no simple abstraction which adequately covers the broad 456 range of power sources and energy storage devices used in existing 457 LLN nodes. These include line-power, primary batteries, energy- 458 scavengers, and a variety of secondary storage mechanisms. 459 Scavengers may provide a reliable low level of power, such as might 460 be available from a 4-20mA loop; a reliable but periodic stream of 461 power, such as provided by a well-positioned solar cell; or 462 unpredictable power, such as might be provided by a vibrational 463 energy scavenger on an intermittently powered pump. Routes which are 464 viable when the sun is shining may disappear at night. A pump 465 turning on may connect two previously disconnected sections of a 466 network. 468 Storage systems like rechargeable batteries often suffer substantial 469 degradation if regularly used to full discharge, leading to different 470 residual energy numbers for regular versus emergency operation. A 471 route for emergency traffic may have a different optimum than one for 472 regular reporting. 474 Batteries used in LLNs often degrade substantially if their average 475 current consumption exceeds a small fraction of the peak current that 476 they can deliver. It is not uncommon for LLN nodes to have a 477 combination of primary storage, energy scavenging, and secondary 478 storage, leading to three different values for acceptable average 479 current depending on the time frame being considered, e.g. 480 milliseconds, seconds, and hours/years. 482 Raw power and energy values are meaningless without knowledge of the 483 energy cost of sending and receiving packets, and lifetime estimates 484 have no value without some higher-level constraint on the lifetime 485 required of a device. In some cases the path that exhausts the 486 battery of a node on the bed table in a month may be preferable to a 487 route that reduces the lifetime of a node in the wall to a decade. 489 Given the complexity of trying to address such a broad collection of 490 constraints, this document defines three levels of fidelity in the 491 solution. 493 The simplest solution relies on a 2-bit field encoding three types of 494 power sources: "powered", "battery", "scavenger". This simple 495 approach may be sufficient for many applications. 497 The mid-complexity solution is a single parameter that can be used to 498 encode the energetic happiness of both battery powered and scavenging 499 nodes. For scavenging nodes, the 8 bit quantity is the power 500 provided by the scavenger divided by the power consumed by the 501 application, H=P_in/P_out, in units of percent. Nodes which are 502 scavenging more power than they are consuming will register above 503 100. The time period for averaging power in this calculation is out 504 of the scope of this document but something related to the discharge 505 time of the energy storage device on the node is probably 506 appropriate. For battery powered devices, H is the current expected 507 lifetime divided by the desired minimum lifetime. The estimation of 508 remaining battery energy and actual power consumption can be 509 difficult, and the specifics of this calculation are out of scope of 510 this document, but two examples are presented. If the node can 511 measure its average power consumption, then H can be calculated as 512 the ratio of desired max power (initial energy E_0 divided by desired 513 lifetime T) to actual power H=P_max/P_now. Alternatively, if the 514 energy in the battery E_bat can be estimated, and the total elapsed 515 lifetime, t, is available, then H can be calculated as the total 516 stored energy remaining versus the target energy remaining: H= E_bat 517 / [E_0 (T-t)/T]. 519 An example of optimized route is max(min(H)) for all battery operated 520 nodes along the route, subject to the constraint that H>=100 for all 521 scavengers along the route. 523 The Node Energy (NE) object is used to provide information related to 524 node energy and may be used as a metric or as constraint. 526 The NE object MAY be present in the DAG Metric Container. There MUST 527 be no more than one NE object as a constraint per DAG Metric 528 Container, and no more than one NE object as a metric per DAG Metric 529 Container. 531 The NE object Type is to be assigned by IANA (recommended value=2). 533 The format of the NE object body is as follows: 535 0 1 2 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 538 | NE Sub-objects 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 541 Figure 4: NE object format 543 The format of the NE sub-object body is as follows: 545 0 1 2 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 548 | Flags |I| T |E| E-E | Optional TLVs 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 551 Figure 5: NE sub-object format 553 The NE sub-object may also contain a set of TLVs used to convey 554 various nodes' characteristics. 556 The following flags are currently defined: 558 o T (node Type): 2-bit field indicating the node type. When E=0x00, 559 the node is mains powered. When E=0x01 is battery powered. When 560 E=0x02 the node is powered by a scavenger. 562 o I (Included): the I bit is only relevant when the node type is 563 used as a constraint. For example, the path must only traverse 564 mains powered node. Conversely, battery operated node must be 565 excluded. The I bit is used to stipulate inclusion versus 566 exclusion. When set, this indicates that nodes of type specified 567 in the node type field MUST be included. Conversely, when 568 cleared, this indicates that nodes of type specified in the node 569 type field MUST be excluded. 571 o E (Estimation): when the E bit is set for a metric, the estimated 572 percentage of remaining energy on the node is indicated in the E-E 573 8-bit field. When cleared, the estimated percentage of remaining 574 energy is not provided. When the E bit is set for a constraint, 575 the E-E field defines a threshold for the inclusion/exclusion: if 576 an inclusion, nodes with values higher than the threshold are to 577 be included; if an exclusion, nodes with values lower than the 578 threshold are to be excluded. 580 E-E (Estimated-Energy): 8-bit unsigned integer field indicating an 581 estimated percentage of remaining energy. The E-E field is only 582 relevant when the E flag is set, and MUST be set to 0 when the E flag 583 is cleared. 585 If the NE object comprises several sub-objects when used as a 586 constraint, each sub-object adds or subtracts node subsets as the 587 sub-objects are parsed in order. The initial set (full or empty) is 588 defined by the I bit of the first sub-object: full if that I bit is 589 an exclusion, empty is that I bit is an inclusion. 591 No TLV is currently defined. 593 The most complex solution involves a half dozen TLV parameters 594 representing energy storage, consumption, and generation capabilities 595 of the node, as well as desired lifetime, and will appear in a future 596 version of this document. 598 3.3. Hop-Count object 600 The HoP-Count (HP) object is used to report the number of traversed 601 nodes along the path. 603 The HP object MAY be present in the DAG Metric Container. There MUST 604 be no more than one HP object as a constraint per DAG Metric 605 Container, and no more than one HP object as a metric per DAG Metric 606 Container. 608 The HP object may also contain a set of TLVs used to convey various 609 node characteristics. No TLV is currently defined. 611 The HP routing metric object Type is to be assigned by IANA 612 (recommended value=3) 614 The HP routing metric object is a global routing object that 615 characterizes a path. 617 The format of the Hop Count object body is as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 622 | Res | Flags | Hop Count | Optional TLVs 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 625 Figure 6: Hop Count object format 627 No Flag is currently defined. 629 The HP object may be used as a constraint or a metric. When used as 630 a constraint, the DAG root indicates the maximum number of hops that 631 a path may traverse. When that number is reached, no other node can 632 join that path. When used as a metric each visited node simply 633 increments the Hop Count field. 635 3.4. Node Fanout Ratio object 637 The Node Fanout Ratio (NFR) object is used to provide information on 638 the nodes current forwarding load. 640 The NFR object MAY be present in the DAG Metric Container. There 641 MUST be no more than one NFR object as a constraint per DAG Metric 642 Container, and no more than one NFR object as a metric per DAG Metric 643 Container. 645 The NFR object may also contain a set of TLVs used to convey various 646 forwarding load characteristics. No TLV is currently defined. 648 The NFR object Type is to be assigned by IANA (recommended value=9). 650 The format of the NFR 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 | Res | F R | Optional TLVs 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 658 Figure 7: NFR object format 660 When the data traffic of the application supported by the network is 661 known a priori, energy depletion in the network can be equalized 662 simply by controlling the fanout ratio of router nodes. 664 Algorithms describing how to compute the FR value and how to use it 665 are outside the scope of this document. 667 The following field of the NFR object is defined: 669 o FR Field: a 4-bit unsigned integer that indicates a relative 670 fanout of the node. A value of 15 indicates a node that is very 671 close to, or at its maximum supported fanout capability. A value 672 of 0 indicates a very small fanout. 674 Unassigned bits are considered as reserved. They MUST be set to zero 675 on transmission and MUST be ignored on receipt. 677 4. Link Metric/Constraint objects 679 4.1. Throughput 681 Many LLNs support a wide range of throughputs. For some links, this 682 may be due to variable coding. For the deeply duty-cycled links 683 found in many LLNs, the variability comes as a result of trading 684 power consumption for bit rate. There are several MAC sub-layer 685 protocols which allow the effective bit rate and power consumption of 686 a link to vary over more than three orders of magnitude, with a 687 corresponding change in power consumption. For efficient operation, 688 it may be desirable for nodes to report the range of throughput that 689 their links can handle in addition to the currently available 690 throughput. 692 The Throughput object MAY be present in the DAG Metric Container. 693 There MUST be no more than one Throughput object as a constraint per 694 DAG Metric Container, and no more than one Throughput object as a 695 metric per DAG Metric Container. 697 The Throughput object is made of throughput sub-objects and MUST at 698 least comprise one Throughput sub-object. The first Throughput sub- 699 object MUST be the most recently estimated actual throughput. Each 700 Throughput sub-object has a fixed length of 4 bytes. 702 The Throughput object does not contain any additional TLV. 704 The Throughput object Type is to be assigned by IANA (recommended 705 value=4) 707 The Throughput object is a global metric. 709 The format of the Throughput object body is as follows: 711 0 1 712 0 1 2 3 4 5 6 7 8 9 0 1 2 3 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | (sub-object) ..... 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 8: Throughput object body format 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Throughput | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Figure 9: Throughput sub-object format 727 Throughput: 32 bits. The Throughput is encoded in 32 bits in 728 unsigned integer format, expressed in bytes per second. 730 4.2. Latency 732 Similarly to throughput, the latency of many LLN MAC sub-layers can 733 be varied over many orders of magnitude, again with a corresponding 734 change in current consumption. Some LLN MAC link layers will allow 735 the latency to be adjusted globally on the subnet, or on a link-by- 736 link basis, or not at all. Some will insist that it be fixed for a 737 given link, but allow it to be variable from link to link. 739 The Latency object MAY be present in the DAG Metric Container. There 740 MUST be no more than one Latency object as a constraint per DAG 741 Metric Container, and no more than one Latency object as a metric per 742 DAG Metric Container. 744 The Latency object is made of Latency sub-objects and MUST at least 745 comprise one Latency sub-object. Each Latency sub-object has a fixed 746 length of 4 bytes. 748 The Latency object does not contain any additional TLV. 750 The Latency object Type is to be assigned by IANA (recommended 751 value=5) 753 The Latency object is a global metric or constraint. 755 The format of the Latency object body is as follows: 757 0 1 758 0 1 2 3 4 5 6 7 8 9 0 1 2 3 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | (sub-object) ..... 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 10: Latency object body format 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Latency | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Figure 11: Latency sub-object format 773 Latency: 32 bits. The Latency is encoded in 32 bits in unsigned 774 integer format, expressed in microseconds. 776 The Latency object may be used as a constraint or a path metric. For 777 example, one may want the latency not to exceed some value. In this 778 case, the Latency object common header indicates that the provided 779 value relates to a constraint. In another example, the Latency 780 object may be used as an aggregated additive metric where the value 781 is updated along the path to reflect the path latency. 783 4.3. Link reliability 785 In LLNs, link reliability is degraded by external interference and 786 multi-path interference. Multipath typically affects both directions 787 on the link equally, whereas external interference is sometimes uni- 788 directional. Time scales vary from milliseconds to days, and are 789 often periodic and linked to human activity. Packet error rates can 790 generally be measured directly, and other metrics (e.g. bit error 791 rate, mean time between failures) are typically derived from that. 793 A change in link quality can affect network connectivity, thus, link 794 quality may be taken into account as a critical routing metric. Link 795 quality metric should be applied to each directional link unless bi- 796 directionality is one of routing metrics. 798 A number of link reliability metrics could be defined reflecting 799 several reliability aspects. Two link reliability metrics are 800 defined in this document: the Link Quality Level (LQL) and the 801 Expected Transmission count Metric (ETX). 803 Note that an RPL implementation MAY either use the LQL, the ETX or 804 both. 806 4.3.1. The Link Quality Level reliability metric 808 The Link Quality Level (LQL) object is used to quantify the link 809 reliability using a discrete value, from 0 to 7 where 0 indicates 810 that the link quality level is unknown and 1 reports the highest link 811 quality level. The mechanisms and algorithms used to compute the LQL 812 is implementation specific and outside the scope of this document. 814 The LQL is global and can either be used as a metric or a constraint. 815 When used as a metric, the LQL metric can be recorded or aggregated. 816 For example, the DAG may require to record the LQL for all traversed 817 links. Each node can then use the LQL to select the parent based on 818 user defined rules (e.g. "select the path with the maximum number of 819 links reporting a LQL value of 3"). By contrast the LQL link metric 820 may be aggregated, in which case the sum of all LQL may be reported 821 (additive metric) or the minimum value may be reported along the 822 path. 824 When used as a recorded metric, a counter is used to compress the 825 information where the number of links for each LQL is reported. 827 The LQL object MAY be present in the DAG Metric Container. There 828 MUST be no more than one LQL object as a constraint per DAG Metric 829 Container, and no more than one LQL object as a metric per DAG Metric 830 Container. 832 The LQL object MUST contain one or more sub-object used to report the 833 number of links along with their LQL. 835 The LQL object Type is to be assigned by IANA (recommended value=6) 837 The LQL object is a global object that characterizes the path 838 reliability. 840 The format of the LQL object body is as follows: 842 0 1 2 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 845 | Res | LQL sub-object 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 848 Figure 12: LQL object format 850 When the LQL metric is recorded, the LQL object body comprises one or 851 more LQL Type 1 sub-object. 853 The format of the LQL Type 1 sub-object is as follows 855 0 1 2 3 4 5 6 7 856 +-+-+-+-+-+-+-+-+ 857 | Val | Counter | 858 +-+-+-+-+-+-+-+-+ 860 Figure 13: LQL Type 1 sub-object format 862 Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates 863 the highest link quality. 865 Counter: number of links with that value. 867 When the LQL metric is aggregated, the LQL object body comprises one 868 LQL Type 2 sub-object: 870 The format of the LQL Type 2 sub-object is as follows 872 0 1 873 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Aggregated LQL Value | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 14: LQL Type 2 sub-object format 880 Aggregated LQL Value: when used an an additive metric (A=0x00), the 881 aggregated LQL value reports the sum of all the LQL values for all 882 links along the path. When used to report a minimum (A=0x02), the 883 field reports the minimum LQL value of all links along the path 884 ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to 885 report a maximum (A=0x01), the field reports the maximum LQL value of 886 all links along the path. When used to report a multiplication 887 (A=0x03), and the LQL field of one of the links along the path is 888 undetermined (LQL=0), the undetermined LQL will be ignored and not be 889 aggregated (i.e. no reset to Aggregated LQL Value field). 891 4.3.2. The Expected Transmission Count (ETX) reliability object 893 The Expected Transmission Count (ETX) metric is the number of 894 transmissions a node expects to make to a destination in order to 895 successfully deliver a packet. 897 For example, an implementation may use the following formula: ETX= 1 898 / (Df * Dr) where Df is the measured probability that a packet is 899 received by the neighbor and Dr is the measured probability that the 900 acknowledgment packet is successfully received. This document does 901 not mandate the use of a specific formula to compute the ETX value. 903 The ETX object MAY be present in the DAG Metric Container. There 904 MUST be no more than one ETX object as a constraint per DAG Metric 905 Container, and no more than one ETX object as a metric per DAG Metric 906 Container. 908 The ETX object is made of ETX sub-objects and MUST at least comprise 909 one ETX sub-object. Each ETX sub-object has a fixed length of 8 910 bits. 912 The ETX object does not contain any additional TLV. 914 The ETX object Type is to be assigned by IANA (recommended value=7) 916 The ETX object is a global metric or constraint. 918 The format of the ETX object body is as follows: 920 0 1 921 0 1 2 3 4 5 6 7 8 9 0 1 2 3 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | (sub-object) ..... 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Figure 15: ETX object body format 928 0 1 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | ETX | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 16: ETX sub-object format 936 ETX: 16 bits. The ETX * 128 is encoded in 16 bits in unsigned 937 integer format, rounded off to the nearest whole number. For 938 example, if ETX = 3.569, the object value will be 457. If ETX > 939 511.9921875, the object value will be the maximum which is 65535. 941 The ETX object may be used as a constraint or a path metric. For 942 example, it may be required that the ETX must not exceed some 943 specified value. In this case, the ETX object common header 944 indicates that the value relates to a constraint . In another 945 example, the ETX object may be used as an aggregated additive metric 946 where the value is updated along the path to reflect to path quality. 948 4.4. Link Color object 950 4.4.1. Link Color object description 952 The Link Color (LC) object is an administrative 10-bit static link 953 constraint used to avoid or attract specific links for specific 954 traffic types. 956 The LC object can either be used as a metric or as a constraint. 957 When used as a metric, the LC metric can only be recorded. For 958 example, the DAG may require recording the link colors for all 959 traversed links. Each node can then use the LC to select the parent 960 based on user defined rules (e.g. "select the path with the maximum 961 number of links having their first bit set 1 (e.g. encrypted 962 links)"). The LC object may also be used as a constraint. 964 When used as a recorded metric, a counter is used to compress the 965 information where the number of links for each Link Color is 966 reported. 968 The Link Color (LC) object MAY be present in the DAG Metric 969 Container. There MUST be no more than one LC object as a constraint 970 per DAG Metric Container, and no more than one LC object as a metric 971 per DAG Metric Container. 973 There MUST be a at least one LC sub-object per LC object. 975 The LC object does not contain any additional TLV. 977 The LC object Type is to be assigned by IANA (recommended value=8) 979 The LC object may either be local or global. 981 The format of the LC object body is as follows: 983 0 1 2 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 986 | Res | LC sub-objects 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 989 Figure 17: LC object format 991 When the LC object is used as a global recorded metric, the LC object 992 body comprises one or more LC Type 1 sub-objects. 994 The format of the LC Type 1 sub-object body is as follows: 996 0 1 997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Link Color | Counter | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Figure 18: LC Type 1 sub-object format 1004 When the LC object is used as a constraint, the LC object body 1005 comprises one or more LC Type 2 sub-objects. 1007 The format of the LC Type 2 sub-object body is as follows: 1009 0 1 1010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Link Color |I| 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 Figure 19: LC Type 2 sub-object format 1017 I Bit: When cleared, this indicates that links with the specified 1018 color must be included. When set, this indicates that links with the 1019 specified color must be excluded. 1021 The use of the LC object is outside the scope of this document. 1023 4.4.2. Mode of operation 1025 The link color may be used as a constraint or a metric. 1027 o When used as global constraint, the LC object may be inserted in 1028 the DAG Metric Container to indicate that links with a specific 1029 color should be included or excluded from the computed path. 1031 o When used as global recorded metric, each node along the path may 1032 insert a LC object in the DAG Metric Container to report the color 1033 of the local link. If there is already a LC object reported a 1034 similar color, the node MUST NOT add another identical LC sub- 1035 object and MUST increment the counter field. 1037 5. Computation of dynamic metrics and attributes 1039 As already pointed out, dynamically calculated metrics are of the 1040 utmost importance in many circumstances in LLNs. This is mainly 1041 because a variety of metrics change on a frequent basis, thus 1042 implying the need to adapt the routing decisions. That being said, 1043 care must be given to the pace at which changes are reported in the 1044 network. The attributes will change according to their own time 1045 scales. RPL controls the reporting rate. 1047 To minimize metric updates, multi-threshold algorithms MAY be used to 1048 determine when updates should be sent. When practical, low-pass 1049 filtering and/or hysteresis should be used to avoid rapid 1050 fluctuations of these values. Finally, although the specification of 1051 path computation algorithms using dynamic metrics are out the scope 1052 of this document, the route optimization algorithm should be designed 1053 carefully to avoid too frequent computation of new routes upon metric 1054 values changes. 1056 Controlled adaptation of the routing metrics and rate at which paths 1057 are computed are critical to avoid undesirable routing instabilities 1058 resulting in increased latencies and packet loss because of temporary 1059 micro-loops. Furthermore, excessive route changes will adversely 1060 impact the traffic and power consumption in the network. 1062 6. Use of multiple DAG Metric Container 1064 Since RPL options length are coded using 1 octet, their length cannot 1065 exceed 256 bytes, which also applies to the DAG Metric Container. 1066 Although in the vast majority of cases, the advertised routing 1067 metrics and constraints will not require that much space, there might 1068 be circumstances where larger space will be required, should for 1069 example a set of routing metrics be recorded along a long path. In 1070 this case, as specified in [I-D.ietf-roll-rpl], routing metrics will 1071 be carried using multiple DAG Metric Containers. 1073 In the rest of this document, this use of multiple DAG Metric 1074 Containers will be considered as if they were actually just one long 1075 DAG Metric Container. For this to hold, nodes propagating multiple 1076 DAG Metric Containers MUST keep their order unchanged. 1078 7. Metric consistency 1080 Since a set of metrics and constraints will be used for links and 1081 nodes in LLN, it is particularly critical to ensure the use of 1082 consistent metric calculation mechanisms for all links and nodes in 1083 the network. 1085 8. Metric usage 1087 This section describes how metrics carried in the DAG Metric 1088 Container shall be used. 1090 When the DAG Metric Container contains a single aggregated metric 1091 (scalar value), the order relation to select the best path is 1092 implicitely derived from the metric type. For example, lower is 1093 better for Hop Count, Link Latency, ETX and Fanout Ratio. For Node 1094 Energy or Throughput, higher is better. 1096 An exemple of using such a single aggregated metric is optimizing 1097 routing for node energy. The Node Energy metric (E-E field) is 1098 aggregated along pathes with an explicit min function (A field), and 1099 the best path is selected through an implied Max function because the 1100 metric is Energy. 1102 When the DAG Metric Container contains several aggregated metrics, 1103 they are to be used as tie-brakers in the order that they appear in 1104 the DAG Metric Container. A node propagating a DAG Metric Container 1105 MUST keep the order of metric objects unchanged. 1107 An example of such use of multiple aggregated metrics is the 1108 following: Hop-Count as the primary criterion, LQL as the secondary 1109 criterion and Fanout Ratio as the ultimate tie-braker. In such a 1110 case, the Hop-Count, LQL and Fanout Ratio metric objects need to 1111 appear in that order in the DAG Metric Container. 1113 The use of compound metrics, such as a polynomial function of 1114 individual metric values, will be described in a future revision of 1115 this document. 1117 The use of recorded metrics will be described in a future revision of 1118 this document. 1120 9. 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 9.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 1146 9 Node Fanout Ratio This document 1148 9.2. Routing Metric/Constraint common header 1150 IANA is requested to create a registry to manage the codespace of A 1151 field of the Routing Metric/Constraint common header. 1153 Codespace of the A field (Routing Metric/Constraint common header) 1154 Value Meaning Reference 1156 0 Routing metric is additive This document 1157 1 Routing metric reports a maximum This document 1158 2 Routing metric reports a minimum This document 1159 3 Routing metric is multiplicative This document 1161 IANA is requested to create a registry to manage the Flag field of 1162 the Routing Metric/Constraint common header. 1164 New bit numbers may be allocated only by an IETF Consensus action. 1165 Each bit should be tracked with the following qualities: 1167 o Bit number 1169 o Capability Description 1171 o Defining RFC 1173 Several bits are defined for the Routing Metric/Constraint common 1174 header in this document. The following values have been assigned: 1176 Codespace of the Flag field (Routing Metric/Constraint common header) 1177 Bit Description Reference 1179 8 Constraint/metric This document 1180 7 Optional Constraint This document 1181 5-6 Additive/Max/Min/Multi This document 1182 4 Global/Local This document 1183 3 Recorded/Aggregated This document 1185 9.3. NSA object 1187 IANA is requested to create a registry to manage the codespace of the 1188 Flag field of the NSA object. 1190 New bit numbers may be allocated only by an IETF Consensus action. 1191 Each bit should be tracked with the following qualities: 1193 o Bit number 1195 o Capability Description 1197 o Defining RFC 1199 Several bits are defined for the NSA object flag field in this 1200 document. The following values have been assigned: 1202 Codespace of the Flag field (NSA object) 1203 Bit Description Reference 1205 14 Aggregator This document 1206 15 Overloaded This document 1208 9.4. Hop-Count object 1210 IANA is requested to create a registry to manage the codespace of the 1211 Flag field of the Hop-count object. 1213 New bit numbers may be allocated only by an IETF Consensus action. 1214 Each bit should be tracked with the following qualities: 1216 o Bit number 1218 o Capability Description 1220 o Defining RFC 1222 No Flag is currently defined. 1224 10. Security considerations 1226 Routing metrics should be handled in a secure and trustful manner. 1227 For instance, a malicious node can not advertise falsely that it has 1228 good metrics for routing and belong to the established path to have a 1229 chance to intercept packets. 1231 11. Acknowledgements 1233 The authors would like to acknowledge the contributions of Young Jae 1234 Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip 1235 Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru 1236 Petrescu, Ricahrd Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, 1237 Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads 1238 Westergreen and Mukul Goyal for their review and comments. 1240 12. References 1242 12.1. Normative references 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, March 1997. 1247 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1248 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1249 May 2008. 1251 12.2. Informative references 1253 [I-D.ietf-roll-rpl] 1254 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 1255 Protocol for Low power and Lossy Networks", 1256 draft-ietf-roll-rpl-10 (work in progress), June 2010. 1258 [I-D.ietf-roll-terminology] 1259 Vasseur, J., "Terminology in Low power And Lossy 1260 Networks", draft-ietf-roll-terminology-03 (work in 1261 progress), March 2010. 1263 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1264 dual environments", RFC 1195, December 1990. 1266 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1268 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1269 McManus, "Requirements for Traffic Engineering Over MPLS", 1270 RFC 2702, September 1999. 1272 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1273 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1274 Tunnels", RFC 3209, December 2001. 1276 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1277 (GMPLS) Signaling Functional Description", RFC 3471, 1278 January 2003. 1280 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1281 "Routing Requirements for Urban Low-Power and Lossy 1282 Networks", RFC 5548, May 2009. 1284 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1285 "Industrial Routing Requirements in Low-Power and Lossy 1286 Networks", RFC 5673, October 2009. 1288 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1289 Routing Requirements in Low-Power and Lossy Networks", 1290 RFC 5826, April 2010. 1292 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1293 "Building Automation Routing Requirements in Low-Power and 1294 Lossy Networks", RFC 5867, June 2010. 1296 Authors' Addresses 1298 JP Vasseur (editor) 1299 Cisco Systems, Inc 1300 11, Rue Camille Desmoulins 1301 Issy Les Moulineaux, 92782 1302 France 1304 Email: jpv@cisco.com 1306 Mijeom Kim (editor) 1307 Corporate Technology Group, KT 1308 17 Woomyeon-dong, Seocho-gu 1309 Seoul, 137-792 1310 Korea 1312 Email: mjkim@kt.com 1313 Kris Pister 1314 Dust Networks 1315 30695 Huntwood Ave. 1316 Hayward, CA 95544 1317 USA 1319 Email: kpister@dustnetworks.com 1321 Nicolas Dejean 1322 Coronis SAS 1323 Espace Concorde, 120 impasse JB Say 1324 Perols, 34470 1325 France 1327 Email: nicolas.dejean@coronis.com 1329 Dominique Barthel 1330 France Telecom Orange 1331 28 chemin du Vieux Chene, BP 98 1332 Meylan, 38243 1333 France 1335 Email: dominique.barthel@orange-ftgroup.com