idnits 2.17.1 draft-ietf-roll-routing-metrics-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 3 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 (October 26, 2009) is 5296 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 164, but not defined == Missing Reference: 'IEEE.754.1985' is mentioned on line 1219, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-03 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-roll-building-routing-reqs-07 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-08 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-02 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track M. Kim, Ed. 4 Expires: April 29, 2010 Future Tech Lab., Korea Telecom 5 K. Pister 6 Dust Networks 7 H. Chong 8 Future Tech Lab., Korea Telecom 9 October 26, 2009 11 Routing Metrics used for Path Calculation in Low Power and Lossy 12 Networks 13 draft-ietf-roll-routing-metrics-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 29, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Low power and Lossy Networks (LLNs) have unique characteristics 52 compared with traditional wired and ad-hoc networks that require the 53 specification of new routing metrics and constraints. By contrast 54 with typical Interior Gateway Protocol (IGP) routing metrics using 55 hop counts or link metrics, this document specifies a set of link and 56 node routing metrics and constraints suitable to LLNs. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Node Metrics And Constraints Objects . . . . . . . . . . . . . 9 69 3.1. Node State And Attributes Object . . . . . . . . . . . . . 9 70 3.2. Node Energy Object . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 14 72 4. Link Metrics and Constraints Objects . . . . . . . . . . . . . 14 73 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17 76 4.3.1. The Link Quality Level Reliability Metric . . . . . . 18 77 4.3.2. The Expected Transmission Count (ETX) Reliability 78 Object . . . . . . . . . . . . . . . . . . . . . . . . 19 79 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 21 80 4.4.1. Link Color Object Description . . . . . . . . . . . . 21 81 4.4.2. Mode of Operation . . . . . . . . . . . . . . . . . . 22 82 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 23 83 6. Objective Function . . . . . . . . . . . . . . . . . . . . . . 23 84 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 7.1. Other metric under consideration . . . . . . . . . . . . . 24 86 8. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 24 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 25 89 9.2. Routing Object Common Header . . . . . . . . . . . . . . . 25 90 9.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 26 91 9.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 26 92 9.5. Objective Code Point (OCP) Object . . . . . . . . . . . . 27 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 98 12.3. References . . . . . . . . . . . . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 101 1. Introduction 103 This document makes use of the terminology defined in 104 [I-D.ietf-roll-terminology]. 106 Low power and Lossy Networks (LLNs) have specific routing 107 characteristics compared with traditional wired or ad-hoc networks 108 that have been spelled out in [RFC5548], [RFC5673], 109 [I-D.ietf-roll-home-routing-reqs] and 110 [I-D.ietf-roll-building-routing-reqs]. 112 Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have 113 used quantitative static link metrics. Other mechanisms such as 114 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see 115 [RFC2702] and [RFC3209]) make use of other link attributes such as 116 the available reserved bandwidth (dynamic) or link affinities 117 (static) to compute constrained shortest paths for Traffic 118 Engineering Label Switched Paths (TE LSPs). 120 This document specifies routing constraints and metrics to be used in 121 path calculation by the Routing Protocol for Low Power and Lossy 122 Networks (RPL) specified in [I-D.ietf-roll-rpl]. 124 One of the prime objectives of this document is to propose a flexible 125 mechanism for the advertisement of routing metrics and constraints 126 used by RPL. Some RPL implementations may elect to adopt an 127 extremely simple approach based on the use of a single metric with no 128 constraint whereas other implementations may use a larger set of link 129 and node routing metrics and constraints. This specification 130 provides a high degree of flexibility and new routing metrics; new 131 constraints could be defined in the future, as needed. 133 RPL is a distance vector routing protocol that builds a Directed 134 Acyclic Graph (DAG) based on routing metrics and constraints. DAG 135 formation rules are defined in [I-D.ietf-roll-rpl]: 137 o The DAG root may advertise a routing constraint used as a "filter" 138 to prune links and nodes that do not satisfy specific properties. 139 For example, it may be required for the path to only traverse 140 nodes that are main powered or links that have at least a minimum 141 reliability or a specific "color" reflecting a user defined link 142 characteristic (e.g the link layer supports encryption). 144 o A routing metric is a quantitative value that is used to evaluate 145 the path quality, also referred to as the path cost. Link and 146 nodes metrics are usually (but not always) additive: for example, 147 the throughput or the reliability link metric can be used to 148 evaluate the path cost. 150 The best path is the path with the lowest cost with respect to some 151 metrics that satisfies all constraints (if any) and is also called 152 the shortest constrained path (in the presence of constraints). 154 Routing metrics can be classified according to the following set of 155 characteristics: 157 o Link versus Node metrics 159 o Qualitative versus quantitative 161 o Dynamic versus static 163 It must be noted that the use of dynamic metrics is not new and has 164 been experimented in ARPANET 2 [Khanna1989], with moderate success. 165 The use of dynamic metrics is not trivial and very careful care must 166 be given to the use of dynamic metrics since it may lead to potential 167 routing instabilities. 169 As pointed out in various routing requirements documents (see 170 [RFC5673], [I-D.ietf-roll-home-routing-reqs] [RFC5548] and 171 [I-D.ietf-roll-building-routing-reqs]), it must be possible to take 172 into account a variety of node constraints/metrics during path 173 computation. 175 It is also worth mentioning that it is fairly common for links in 176 LLNs to have fast changing node and link characteristics, which must 177 be taken into account when specifying routing metrics. For instance, 178 in addition to the dynamic nature of wireless connectivity, nodes' 179 resources such as residual energy and other link's charatacteristics 180 such as the throughput are changing continuously and may have to be 181 taken into account during the path computation. Similarly, link 182 attributes including throughput and reliability may drastically 183 change over time due to multi-path interference. 185 Very careful attention must be given when using dynamic metrics and 186 attributes that affect routing decisions in order to preserve routing 187 stability. Routing metrics and constraints may either be static or 188 dynamic. When dynamic, a RPL implementation SHOULD make use of a 189 multi-threshold scheme rather than fine granular metric updates so as 190 to avoid constant routing changes. 192 Furthermore, it is a time and energy consuming process to update 193 dynamic metrics and recompute the routing tables on a frequent basis. 194 Therefore, it may be desirable to use a set of discrete values to 195 reduce computational overhead and bandwidth utilization. Of course, 196 this comes with a cost, namely, reduced metric accuracy. Reliability 197 is an example of qualitative parameters which may be used as a 198 routing metric by RPL. Such qualitative parameters may be 199 transformed to quantitative values. In other cases, a set of flags 200 may be defined to reflect a node state without having to define 201 discrete values. 203 Some link or node characteristics (e.g. link reliability flag, energy 204 remaining on the node) may either be used by RPL as routing 205 constraints or metric. For example, the path may be computed to 206 avoid links that do not provide a sufficient level of reliability 207 (use as a constraint) or as the path offering the maximum number of 208 links with a specified reliability level (use as a metric). 210 It is not required to use all the metrics and attributes specified in 211 this document. The set of routing metrics and constraints used by an 212 RPL implementation is signalled along the Directed Acyclic Graph 213 (DAG) computed by RPL via an Objective Function (OF) as described in 214 [I-D.ietf-roll-rpl]. Indeed, RPL may be used to build DAGs with 215 different characteristics. For example, it may be desirable to build 216 a DAG trying to maximize reliability by using the link reliability 217 metric: in this case, the OF advertised by RPL in the Dag Information 218 Option (DIO) message specifies an Objective Code Point (OCP) 219 indicating that the link reliability metric is the metric used to 220 compute the "best" path. Another example might be to use the energy 221 node characteristic (e.g. main powered versus battery operated) as a 222 node constraint when building the DAG so as to avoid battery powered 223 nodes in the DAG. Links and nodes routing metrics and constraints 224 are not exclusive. 226 The requirements on reporting frequency may differ among metrics, 227 thus different reporting rates may be used for each category. 229 The specification of objective functions used to compute the DAG 230 built by RPL is out of the scope of this document and will be 231 specified in other documents. 233 Some metrics are either aggregated or recorded. In the former case, 234 the metric is adjusted as the DIO message travels along the DAG. For 235 example, if the metric is the link latency, each node updates the 236 latency metric along the DAG. By contrast, metric may be recorded in 237 which case each node adds a sub-object reflecting the local metric. 238 For example, it might be desirable to record the link quality level 239 along the path. In this case, each visited node adds a sub-object 240 reporting the local link quality level. In order to limit the number 241 of sub-objects, the use of a counter may be desirable (e.g. record 242 the number of links with a certain link quality level). Upon 243 receiving the DIO message from a set of parents, a node can decide 244 which node to choose as a parent based on the maximum number of links 245 with a specific link reliability level for example. 247 Notion of local versus global metric: some routing objects may have a 248 local or a global significance. In the former case, a metric may be 249 transmitted to a neighbor to charaterize a link or a node as opposed 250 to a path. For example, a node may report information about its 251 local energy without the need to propagate the energy level of all 252 nodes along the path. In contrast, other metrics such as link 253 latency metrics are cumulative and global in the sense that they 254 characterize a path cost using the latency as a metric. In this 255 particular example the delay is an aggregated global and cumulative 256 link metric. 258 2. Object Formats 260 Routing metrics and constraints are carried within the DAG Metric 261 Container object defined in [I-D.ietf-roll-rpl]. 263 0 1 2 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 266 | Type=2 | Container Len | DAG Metric data ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 269 Figure 1: DAG Metric Container Format 271 Routing metrics and constraints have a common format consisting of 272 one or more 8-bit words with a common header: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Routing-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | 280 // (Object body) // 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 2: Routing Metric/Constraint common header format 286 The object body carries one or more sub-objects. 288 Note that the routing metric objects defined in this document can 289 appear in any order in the DAG Metric Container object with the 290 exception of the Objective Function object that MUST appear first. 292 Routing-Ob-Type: (Routing Object Type - 8 bits): the Routing Object 293 Type field uniquely identifies each Routing object and is managed by 294 IANA. 296 Res flags (2 bits). Reserved field. This field MUST be set to zero 297 on transmission and MUST be ignored on receipt. 299 o C Flag. When set, this indicates that the routing object refers 300 to a routing constraint. When cleared the routing object refers 301 to a routing metric. 303 o O Flag: The O flag is used exclusively for routing constraints (C 304 flag is set) and has no meaning for routing metrics. When set, 305 this indicates that the constraint is optional. When cleared, the 306 constraint is mandatory. 308 o A Field: The A field is used to indicate whether a routing metric 309 is additive, reports a maximum or a minimum. 311 * A=0x00: The routing metric is additive 313 * A=0x01: The routing metric reports a maximum 315 * A=0x02: The routing metric reports a minimum 317 o G Flag: When set, the routing object is global. When cleared it 318 is local (see details below). 320 o R Fag: The R Flag is only relevant for global routing metric (C=0 321 and G=1) and MUST be cleared for all other values of C and G. When 322 set, this indicates that the routing metric is recorded along the 323 path. Conversely, when cleared the routing metric is aggregated. 325 The A field has no meaning when the C Flag is set (i.e. the routing 326 object refers to a routing constraint). 328 Example 1: A DAG formed by RPL where all nodes must be main powered 329 and the link metric is the link throughput. In this case the DAG 330 Metric container carries two routing objects: the link metric is the 331 link throughput (C=0, O=0, A=00, G=1, R=0) and the node constraint is 332 power (C=1, O=0, A=00, G=0, R=0). Note that in this example, the 333 link throughput is a global additive aggregated link metric. An RPL 334 implementation may use the metric to report a minimum (A=01). In 335 this case, when the link throughput metric is processed each node 336 updates it is the link throughput is less than the value reported by 337 the link throughput metric. 339 Example 2: A DAG formed by RPL where the link metric is the link 340 quality level and link quality levels must be recorded along the 341 path. In this case the DAG Metric container carries one routing 342 object: the link quality level (C=0, O=0, A=00, G=1, R=1). 344 A Routing object may also include one or more type-length-value (TLV) 345 encoded data sets. Each Routing TLV has the same structure: 347 Type: 2 bytes 348 Length: 2 bytes 349 Value: variable 351 A Routing metric TLV is comprised of 2 bytes for the type, 2 bytes 352 specifying the TLV length, and a value field. 354 The Length field defines the length of the value portion in bytes. 356 Unrecognized TLVs MUST be ignored. 358 IANA management of the routing metric objects identifier codespace is 359 described in Section 9. 361 3. Node Metrics And Constraints Objects 363 It is fairly common for LLNs to be made of nodes with heterogeneous 364 attributes and capabilities (e.g. nodes being battery operated or 365 not, amount of memory, etc). More capable and stable nodes may 366 assist the most constrained ones for routing packets, which results 367 in extension of network lifetime and efficient network operations. 368 This is a typical use of constraint-based routing where the computed 369 path may not be the shortest path according to some specified 370 metrics. 372 3.1. Node State And Attributes Object 374 The Node State and Attribute (NSA) object is used to provide 375 information on the nodes characteristics. 377 The NSA object MAY be present in the DAG Metric Container. There 378 MUST be only one NSA object per DAG Metric Container object. 380 The NSA object may also contain a set of TLVs used to convey various 381 node characteristics. No TLVs are currently defined. 383 The NSA Routing Object Type is to be assigned by IANA (recommended 384 value=1). 386 The format of the NSA object body is as follows: 387 0 1 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 390 | Res | Flags |A|O| Optional TLVs 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 393 Figure 3: NSA Object format 395 Node workload may be hard to determine and express in some scalar 396 form. However, node workload could be a useful metric to consider 397 during path calculation, in particular when queuing delays must be 398 minimized for highly sensitive traffic considering Medium Access 399 Control (MAC) layer delay. Node workload MAY be set upon CPU 400 overload, lack of memory or any other node related conditions. Using 401 a simple 1-bit flag to characterize the node workload provides a 402 sufficient level of granularity, similarly to the "overload" bit used 403 in routing protocols such as IS-IS. Algorithms used to set the 404 overload bit and to compute path to potentially avoid node with their 405 overload bit set are outside the scope of this document. 407 Data Aggregation Attribute: data fusion involves more complicated 408 processing to improve accuracy of the output data while data 409 aggregation mostly aims at reducing the amount of data. This is 410 listed as a requirement in Section 6.2 of [RFC5548]. Some 411 applications may make use of the aggregation node attribute in their 412 routing decision so as to minimize the amount of traffic on the 413 network, thus potentially increasing its life time in battery 414 operated environments. Applications where high directional data flow 415 is expected on a regular basis may take advantage of data aggregation 416 supported routing. 418 The following two bits of the NSA object are defined: 420 o O Flag: When set, this indicates that the node is overloaded and 421 may not be able to process traffic. 423 o A Flag: When set, this indicates that the node can act as a 424 traffic aggregator. An implementation MAY decide to add optional 425 TLVs (not currently defined) to further describe the node traffic 426 aggregator functionality. 428 The Flag field of the NSA Routing object is managed by IANA. 429 Unassigned bits are considered as reserved. They MUST be set to zero 430 on transmission and MUST be ignored on receipt. 432 3.2. Node Energy Object 434 Whenever possible, a node with low residual energy should not be 435 selected as a router, thus the support for constrained-based routing 436 is needed. In such cases, the routing protocol engine may compute a 437 longer path (constraint based) for some traffic in order to increase 438 the network life duration. 440 The routing engine may prefer a "longer" path that traverses mains- 441 powered nodes or nodes equipped with energy scavenging, rather than a 442 "shorter" path through battery operated nodes. 444 Power and energy are clearly critical resources in LLNs. As yet 445 there are no simple abstractions which adequately cover the broad 446 range of power sources and energy storage devices used in existing 447 LLN nodes. These include line-power, primary batteries, energy- 448 scavengers, and a variety of secondary storage mechanisms. 449 Scavengers may provide a reliable low level of power, such as might 450 be available from a 4-20mA loop; a reliable but periodic stream of 451 power, such as provided by a well-positioned solar cell; or 452 unpredictable power, such as might be provided by a vibrational 453 energy scavenger on an intermittently powered pump. Routes which are 454 viable when the sun is shining may disappear at night. A pump 455 turning on may connect two previously disconnected sections of a 456 network. 458 Storage systems like rechargeable batteries often suffer substantial 459 degradation if regularly used to full discharge, leading to different 460 residual energy numbers for regular versus emergency operation. A 461 route for emergency traffic may have a different optimum than one for 462 regular reporting. 464 Batteries used in LLNs often degrade substantially if their average 465 current consumption exceeds a small fraction of the peak current that 466 they can deliver. It is not uncommon for LLN nodes to have a 467 combination of primary storage, energy scavenging, and secondary 468 storage, leading to three different values for acceptable average 469 current depending on the time frame being considered, e.g. 470 milliseconds, seconds, and hours/years. 472 Raw power and energy values are meaningless without knowledge of the 473 energy cost of sending and receiving packets, and lifetime estimates 474 have no value without some higher-level constraint on the lifetime 475 required of a device. In some cases the path that exhausts the 476 battery of a node on the bed table in a month may be preferable to a 477 route that reduces the lifetime of a node in the wall to a decade. 479 Given the complexity of trying to address such a broad collection of 480 constraints, this document defines three levels of fidelity in the 481 solution. 483 The simplest solution relies on a 2-bit field encoding three types of 484 power sources: "powered", "battery", "scavenger". This simple 485 approach may be sufficient for many applications. 487 The mid-complexity solution is a single parameter that can be used to 488 encode the energetic happiness of both battery powered and scavenging 489 nodes. For scavenging nodes, the 8 bit quantity is the power 490 provided by the scavenger divided by the power consumed by the 491 application, H=P_in/P_out, in units of percent. Nodes which are 492 scavenging more power than they are consuming will register above 493 100. The time period for averaging power in this calculation is out 494 of the scope of this document but something related to the discharge 495 time of the energy storage device on the node is probably 496 appropriate. For battery powered devices, H is the current expected 497 lifetime divided by the desired minimum lifetime. The estimation of 498 remaining battery energy and actual power consumption can be 499 difficult, and the specifics of this calculation are out of scope of 500 this document, but two examples are presented. If the node can 501 measure its average power consumption, then H can be calculated as 502 the ratio of desired max power (initial energy E_0 divided by desired 503 lifetime T) to actual power H=P_max/P_now. Alternatively, if the 504 energy in the battery E_bat can be estimated, and the total elapsed 505 lifetime, t, is available, then H can be calculated as the total 506 stored energy remaining versus the target energy remaining: H= E_bat 507 / [E_0 (T-t)/T]. 509 An example OF is max(min(H)) for all battery operated nodes along the 510 route, subject to the constraint that H>=100 for all scavengers along 511 the route. 513 The Node Energy (NE) object is used to provide information related to 514 node energy and may be used as a metric or as constraint. 516 The NE object MAY be present in the DAG Metric Container. There MUST 517 be only one NE object per DAG Metric Container object. 519 The NE Routing Object Type is to be assigned by IANA (recommended 520 value=2). 522 The format of the NE object body is as follows: 523 0 1 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 526 | NE Sub-objects 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 529 Figure 4: NE Object format 531 When used as a constraint, the NE object comprises only one NE sub- 532 object. 534 The format of the NE sub-object body is as follows: 536 0 1 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 539 | Flags |I| T |E| E-E | Optional TLVs 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 542 Figure 5: NE sub-object format 544 The NE sub-object may also contain a set of TLVs used to convey 545 various nodes' characteristics. 547 The following flags are currently defined: 549 o T (node Type): 2-bit field indicating the node type. When E=0x00, 550 the node is main powered. When E=0x01 is battery powered. When 551 E=0x02 the node is powered by a scavenger. 553 o I (Included): the I bit is only relevant when the node type is 554 used as a constraint. For example, the OF may indicate that the 555 path must only traversed main powered node. Conversely, the OF 556 may indicate that battery operated node must be excluded. The I 557 bit is used to stipulate inclusion versus exclusion. When set, 558 this indicates that nodes of type specified in the node type field 559 MUST be included. Conversely, when cleared, this indicates that 560 nodes of type specified in the node type field MUST be excluded. 562 o E (Estimation): when set, the estimated percentage of remaining 563 energy is indicated in the E-E 8-bit field. When cleared, the 564 estimated percentage of remaining energy is not provided. 566 E-E (Estimated-Energy): 8-bit field indicating the estimated 567 percentage of remaining energy on the node. The E-E field is only 568 relevant when the E flag is set, and MUST be set to 0 when the E flag 569 is cleared. 571 No TLVs are currently defined. 573 The most complex solution involves a half dozen TLV parameters 574 representing energy storage, consumption, and generation capabilities 575 of the node, as well as desired lifetime, and will appear in the next 576 version of this document. 578 3.3. Hop-Count Object 580 The Hop-Count (HP) object is used to report the number of traversed 581 nodes along the path. 583 The HP object MAY be present in the DAG Metric Container. There MUST 584 be only one HP object per DAG Metric Container object. 586 The HP object may also contain a set of TLVs used to convey various 587 node characteristics. No TLVs are currently defined. 589 The HP routing metric object Type is to be assigned by IANA 590 (recommended value=3) 592 The HP routing metric object is a global routing object that 593 characterizes a path. 595 The format of the Hop Count object body is as follows: 596 0 1 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 599 | Res | Flags | Hop Count | Optional TLVs 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 602 Figure 6: Hop Count Object format 604 No Flags are currently defined. 606 The HP object may be used as a constraint or a metric. When used as 607 a constraint, the DAG root indicates the maximum number of hops that 608 a path may traverse. When that number is reached no other node can 609 join that path. When used as a metric each visited node simply 610 increments the Hop Count field. 612 4. Link Metrics and Constraints Objects 613 4.1. Throughput 615 Many LLNs support a wide range of throughputs, measured either in 616 bits per second or packets per second. For some links, this may be 617 due to variable coding. For the deeply duty-cycled links found in 618 many LLNs, the variability comes as a result of trading power 619 consumption for bit rate. There are several MAC sub-layer protocols 620 which allow the effective bit rate and power consumption of a link to 621 vary over more than three orders of magnitude, with a corresponding 622 change in power consumption. For efficient operation, it may be 623 desirable for nodes to report the range of throughput that their 624 links can handle in addition to the currently available throughput. 626 The Throughput object MAY be present in the DAG Metric Container. 627 There MUST be only one Throughput object per DAG Metric Container 628 object. 630 The Throughput object is made of throughput sub-objects and MUST as 631 least comprise one Throughput sub-object. Each Throughput sub-object 632 has a fixed length of 4 bytes. 634 The Throughput object does not contain any additional TLV. 636 The Throughput Object Type is to be assigned by IANA (recommended 637 value=4) 639 The Throughput Object is a global metric. 641 The format of the Throughput object body is as follows: 643 0 1 644 0 1 2 3 4 5 6 7 8 9 0 1 2 3 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | (sub-object) ..... 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Figure 7: Throughput Object Body Format 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Throughput | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 8: Throughput Sub-object format 658 Throughput: 32 bits. The Throughput is encoded in 32 bits in IEEE 659 floating point format (see [IEEE.754.1985]), expressed in bytes per 660 second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly 661 used values. 663 4.2. Latency 665 Similarly to throughput, the latency of many LLN MAC sub-layers can 666 be varied over many orders of magnitude, again with a corresponding 667 change in current consumption. Some LLN MAC link layers will allow 668 the latency to be adjusted globally on the subnet, or on a link-by- 669 link basis, or not at all. Some will insist that it be fixed for a 670 given link, but allow it to be variable from link to link. 672 The Latency object MAY be present in the DAG Metric Container. There 673 MUST be only one Latency object per DAG Metric Container object. 675 The Latency object is made of Latency sub-objects and MUST as least 676 comprise one Latency sub-object. Each Latency sub-object has a fixed 677 length of 4 bytes. 679 The Latency object does not contain any additional TLV. 681 The Latency object Type is to be assigned by IANA (recommended 682 value=5) 684 The Latency Object is a global metric or constraint. 686 The format of the Latency object body is as follows: 688 0 1 689 0 1 2 3 4 5 6 7 8 9 0 1 2 3 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | (sub-object) ..... 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 9: Latency Object Body Format 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Latency | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 10: Latency Sub-object format 704 Latency: 32 bits. The Latency is encoded in 32 bits in IEEE floating 705 point format (see [IEEE.754.1985]), expressed in milliseconds. Refer 706 to Section 3.1.2 of [RFC3471] for a table of commonly used values. 708 The Latency object may be used as a constraint or a path metric. For 709 example, an Objective Function may indicate that the latency must not 710 exceed some values. In this case, the latency object common header 711 indicates that the value relates to a constraint with a maximum 712 value. In another example, the latency object may be used as an 713 aggregated additive metric where the value is updated along the path 714 to reflect to path latency. 716 4.3. Link reliability 718 In LLNs, link reliability is degraded by external interference and 719 multi-path interference. Multipath typically affects both directions 720 on the link equally, whereas external interference is sometimes uni- 721 directional. Time scales vary from milliseconds to days, and are 722 often periodic and linked to human activity. Packet error rates can 723 generally be measured directly, and other metrics (e.g. bit error 724 rate, mean time between failures) are typically derived from that. 726 A change in link quality can affect network connectivity, thus, link 727 quality may be taken into account as a critical routing metric. Link 728 quality metric should be applied to each directional link unless bi- 729 directionality is one of routing metrics. 731 A number of link reliability metrics could be defined reflecting 732 several reliability aspects. Two link reliability metrics are 733 defined in this document: the Link Quality Level (LQL) and the 734 Expected Transmission count Metric (ETX). 736 Note that an RPL implementation MAY either use the LQL, the ETX or 737 both. 739 4.3.1. The Link Quality Level Reliability Metric 741 The Link Quality Level (LQL) object is used to quantify the link 742 reliability using a discrete value, from 0 to 3 where 0 indicates 743 that the link quality level is unknown and 1 reports the lowest link 744 quality level. The mechanisms and algorithms used to compute the LQL 745 is implementation specific and outside of the scope of this document. 747 The LQL is global and can either be used as a metric or a constraint. 748 When used as a metric, the LQL metric can be recorded or aggregated. 749 For example, the DAG may require to record the LQL for all traversed 750 links. Each node can then use the LQL to select the parent based on 751 user defined rules (e.g. "select the path with the maximum number of 752 links reporting a LQL value of 3"). By contrast the LQL link metric 753 may be aggregated in which case, the sum of all LQL may be reported 754 (additive metric) or the minimum value may be reported along the 755 path. 757 When used as a recorded metric, a counter is used to compress the 758 information where the number of links for each LQL is reported. 760 The LQL object MAY be present in the DAG Metric Container. There 761 MUST be only one LQL object with at least one LQL sub-object per DAG 762 Metric Container object. 764 The LQL object contains one or more sub-object used to report the 765 number of links along with their LQL. 767 The LQL object Type is to be assigned by IANA (recommended value=6) 769 The LQL object is a global object that characterizes the path 770 reliability. 772 The format of the LQL object body is as follows: 773 0 1 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 776 | Res | LQL Sub-object 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 779 Figure 11: LQL Object format 781 When the LQL metric is recorded, the LQL object body comprises one or 782 more LQL Type 1 sub-object. 784 The format of the LQL Type 1 sub-object is as follows 786 0 1 2 3 4 5 6 7 787 +-+-+-+-+-+-+-+-+ 788 |Val| Counter | 789 +-+-+-+-+-+-+-+-+ 791 Figure 12: LQL Type 1 sub-Object format 793 Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates 794 the lowest link quality. 796 Counter: number of links. 798 When the LQL metric is aggregated, the LQL object body comprises one 799 LQL Type 2 sub-object: 801 The format of the LQL Type 2 sub-object is as follows 803 0 1 804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Aggregated LQL Value | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 13: LQL Type 2 sub-Object format 811 Aggregated LQL Value: when used an an additive metric (A=0x00), the 812 aggregated LQL value reports the sum of all the LQL values for all 813 links along the path. When used to report a minimum (A=0x02), the 814 field reports the minimum LQL value of all links along the path. 816 4.3.2. The Expected Transmission Count (ETX) Reliability Object 818 The Expected Transmission Count (ETX) metric is the number of 819 transmissions a node expects to make to a destination in order to 820 successfully deliver a packet. 822 For example, an implementation may use the following formula: ETX= 1 823 / (Df * Dr) where Df is the measured probability that a packet is 824 received by the neighbor and Dr is the measured probability that the 825 acknowledgment packet is successfully received. This document does 826 not mandate the use of a specific formula to comput the ETX value. 828 The ETX object MAY be present in the DAG Metric Container. There 829 MUST be only one ETX object per DAG Metric Container object. 831 The ETX object is made of ETX sub-objects and MUST as least comprise 832 one ETX sub-object. Each ETX sub-object has a fixed length of 8 833 bits. 835 The ETX object does not contain any additional TLV. 837 The ETX object Type is to be assigned by IANA (recommended value=7) 839 The ETX object is a global metric or constraint. 841 The format of the Latency object body is as follows: 843 0 1 844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | (sub-object) ..... 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Figure 14: ETX Object Body Format 851 0 1 852 0 1 2 3 4 5 6 7 853 +-+-+-+-+-+-+-+-+ 854 | ETX | 855 +-+-+-+-+-+-+-+-+ 857 Figure 15: ETX Sub-object format 859 ETX: 8 bits. The ETX is encoded in 8 bits in IEEE floating point 860 format (see [IEEE.754.1985]). Refer to Section 3.1.2 of [RFC3471] 861 for a table of commonly used values. 863 The ETX object may be used as a constraint or a path metric. For 864 example, an Objective Function may indicate that the ETX must not be 865 below some specified value. In this case, the ETX object common 866 header indicates that the value relates to a constraint with a 867 minimum value. In another example, the ETX object may be used as an 868 aggregated additive metric where the value is updated along the path 869 to reflect to path quality. 871 4.4. Link Color Object 873 4.4.1. Link Color Object Description 875 The Link Color (LC) object is an administrative 10-bit static link 876 constraint used to avoid or attract specific links for specific 877 traffic types. 879 The LC object can either be used as a metric or as a constraint. 880 When used as a metric, the LC metric can only be recorded. For 881 example, the DAG may require recording the link colors for all 882 traversed links. Each node can then use the LC to select the parent 883 based on user defined rules (e.g. "select the path with the maximum 884 number of links having their first bit set 1 (e.g. encrypted 885 links)"). The LC object may also be used as a constraint. 887 When used as a recorded metric, a counter is used to compress the 888 information where the number of links for each Link Color is 889 reported. 891 The Link Color (LC) object MAY be present in the DAG Metric 892 Container. There MUST be only one LC object with at least one LC 893 sub-object per DAG Metric Container object. 895 The LC routing object does not contain any additional TLV. 897 The LC routing object Type is to be assigned by IANA (recommended 898 value=8) 900 The LC object may either be local or global. 902 The format of the LC object body is as follows: 903 0 1 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 | LC Sub-objects 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 909 Figure 16: LC Object format 911 When the LC object is used as a global recorded metric, the LC object 912 body comprises one or more LC Type 1 sub-objects. 914 The format of the LC Type 1 sub-object body is as follows: 916 0 1 917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Link Color | Counter | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 17: LC Type 1 sub-object format 924 When the LC object is used as a constraint, the LC object body 925 comprises one or more LC Type 2 sub-objects. 927 The format of the LC Type 2 sub-object body is as follows: 929 0 1 930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Link Color |I| 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Figure 18: LC Type 2 sub-object format 937 I Bit: When cleared, this indicates that links with the specified 938 color must be included. When set, this indicates that links with the 939 specified color must be excluded. 941 The use of the LC object is outside of the scope of this document. 943 4.4.2. Mode of Operation 945 The Objective Function may use the link color as a constraint or a 946 metric. 948 o When used as global constraint, the LC object may be inserted in 949 the DAG Container metric object to indicate that links with a 950 specific color should be included or excluded from the computed 951 path. 953 o When used as global recorded metric, each node along the path may 954 insert a LC object in the DAG container metric to report the color 955 of the local link. If there is already a LC object reported a 956 similar color, the node MUST NOT add another identical LC sub- 957 object and MUST increment the counter field. 959 5. Computation of Dynamic Metrics and Attributes 961 As already pointed out, dynamically calculated metrics are of the 962 utmost importance in many circumstances in LLNs. This is mainly 963 because a variety of metrics change on a frequent basis, thus 964 implying the need to adapt the routing decisions. That being said, 965 care must be given to the pace at which changes are reported in the 966 network. The attributes will change according to their own time 967 scales. RPL controls the reporting rate. 969 To minimize metric updates, multi-threshold algorithms MAY be used to 970 determine when updates should be sent. When practical, a low-pass 971 filter should be used to avoid rapid fluctuations of these values. 972 Finally, although the specification of path computation algorithms 973 using dynamic metrics are out the scope of this document, the 974 objective function should be designed carefully to avoid too frequent 975 computation of new routes upon metric values changes. 977 Controlled adaptation of the routing metrics and rate at which paths 978 are computed are critical to avoid undesirable routing instabilities 979 resulting in increased latencies and packet loss because of temporary 980 micro-loops. Furthermore, excessive route changes will impact the 981 traffic and power consumption in the network adversely. 983 6. Objective Function 985 The Objective Function (OF) is used by RPL to specify how the routing 986 metric and constraints should be used to reach specific objectives. 987 For example, the OF may specify that the objective is to find the 988 constrained shortest path where the constraint is related to the node 989 power mode and the metric is the ETX (e.g. "Avoid battery operated 990 links and compute the path that optimizes reliability"). As 991 specified in [I-D.ietf-roll-rpl], the OF is used by a node to select 992 its parent during the DAG building construction process. 994 The OCP object is used to specify the OF and is carried within the 995 DAG Metric Container object defined in [I-D.ietf-roll-rpl]. 997 There MUST be a single instance of the OCP object within the DAG 998 Metric Container object. 1000 0 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1003 | OCP | (TLVs) 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1006 Figure 19: OCP Object Format 1008 The OCP object is not preceded by the common header specified for the 1009 routing and metric objects. 1011 The OCP object body may carry optional TLVs. No TLVs are currently 1012 defined. 1014 OCP (Objective Code Point - 16 bits): the OCP field identifies the OF 1015 and is managed by IANA. 1017 7. Open Issues 1019 Other items to be addressed in further revisions of this document 1020 include: 1022 7.1. Other metric under consideration 1024 Metrics related to security (e.g. capability to avoid a node that has 1025 not been authorized or authenticated). 1027 8. Metric Consistency 1029 Since a set of metrics and constraints will be used for links and 1030 nodes in LLN, it is particularly critical to ensure the use of 1031 consistent metric calculation mechanisms for all links and nodes in 1032 the network. 1034 9. IANA Considerations 1036 IANA is requested to establish a new top-level registry to contain 1037 all Routing Objects codepoints and sub-registries. 1039 The allocation policy for each new registry is by IETF Consensus: new 1040 values are assigned through the IETF consensus process (see 1041 [RFC5226]). Specifically, new assignments are made via RFCs approved 1042 by the IESG. Typically, the IESG will seek input on prospective 1043 assignments from appropriate persons (e.g., a relevant Working Group 1044 if one exists). 1046 9.1. Routing Objects 1048 IANA is requested to create a registry for Routing objects. Each 1049 Routing object has a Routing object type value. 1051 Value Meaning Reference 1052 1 Node State and Attribute This document 1053 2 Node Energy This document 1054 3 Hop Count This document 1055 4 Link Throughput This document 1056 5 Link Latency This document 1057 6 Link Quality Level This document 1058 7 Link ETX This document 1059 8 Link Color This document 1061 9.2. Routing Object Common Header 1063 IANA is requested to create a registry to manage the codespace of A 1064 field and the Flag field of the Routing Common header. 1066 Codespace of the A field (NSA Object) 1067 Value Meaning Reference 1069 0 Routing metric is additive This document 1070 2 Routing metric reports a maximum This document 1071 3 Routing metric reports a minimum This document 1073 IANA is requested to create a registry to manage the Flag field of 1074 the Routing metric common header. 1076 New bit numbers may be allocated only by an IETF Consensus action. 1077 Each bit should be tracked with the following qualities: 1079 o Bit number 1081 o Capability Description 1083 o Defining RFC 1085 Several bits are defined for the Routing metric common header in this 1086 document. The following values have been assigned: 1088 Codespace of the Flag field (Routing common header) 1089 Bit Description Reference 1091 8 Constraint/metric This document 1092 7 Optional Constraint This document 1093 5-6 Additive/Max/Min This document 1094 4 Global/Local This document 1095 3 Recorded/Aggregated This document 1097 9.3. NSA Object 1099 IANA is requested to create a registry to manage the codespace of the 1100 Flag field of the NSA Object. 1102 New bit numbers may be allocated only by an IETF Consensus action. 1103 Each bit should be tracked with the following qualities: 1105 o Bit number 1107 o Capability Description 1109 o Defining RFC 1111 Several bits are defined for the NSA Object flag field in this 1112 document. The following values have been assigned: 1114 Codespace of the Flag field (RP Object) 1115 Bit Description Reference 1117 14 Aggregator This document 1118 15 Overloaded This document 1120 9.4. Hop-count Object 1122 IANA is requested to create a registry to manage the codespace of the 1123 Flag field of the Hop-count Object. 1125 New bit numbers may be allocated only by an IETF Consensus action. 1126 Each bit should be tracked with the following qualities: 1128 o Bit number 1130 o Capability Description 1132 o Defining RFC 1134 No Flags are currently defined. 1136 9.5. Objective Code Point (OCP) Object 1138 IANA is requested to create a registry to manage the codespace of the 1139 OCP field of the OCP object. 1141 No OCP codepoints are defined in this specification. 1143 10. Security Considerations 1145 Routing metrics should be handled in a secure and trustful manner. 1146 For instance, a malicious node can not advertise falsely that it has 1147 good metrics for routing and belong to the established path to have a 1148 chance to intercept packets. 1150 11. Acknowledgements 1152 The authors would like to acknowledge the contributions of Young Jae 1153 Kim, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal 1154 Thubert, Richard Kelsey, Jonathan Hui, Phil Levis and Tim Winter for 1155 their review and comments. 1157 12. References 1159 12.1. Normative References 1161 [I-D.ietf-roll-rpl] 1162 Winter, T., Thubert, P., and R. Team, "RPL: Routing 1163 Protocol for Low Power and Lossy Networks", 1164 draft-ietf-roll-rpl-03 (work in progress), October 2009. 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, March 1997. 1169 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1170 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1171 May 2008. 1173 12.2. Informative References 1175 [I-D.ietf-roll-building-routing-reqs] 1176 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 1177 "Building Automation Routing Requirements in Low Power and 1178 Lossy Networks", draft-ietf-roll-building-routing-reqs-07 1179 (work in progress), September 2009. 1181 [I-D.ietf-roll-home-routing-reqs] 1182 Brandt, A., Buron, J., and G. Porcu, "Home Automation 1183 Routing Requirements in Low Power and Lossy Networks", 1184 draft-ietf-roll-home-routing-reqs-08 (work in progress), 1185 September 2009. 1187 [I-D.ietf-roll-terminology] 1188 Vasseur, J., "Terminology in Low power And Lossy 1189 Networks", draft-ietf-roll-terminology-02 (work in 1190 progress), October 2009. 1192 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1193 dual environments", RFC 1195, December 1990. 1195 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1197 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1198 McManus, "Requirements for Traffic Engineering Over MPLS", 1199 RFC 2702, September 1999. 1201 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1202 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1203 Tunnels", RFC 3209, December 2001. 1205 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1206 (GMPLS) Signaling Functional Description", RFC 3471, 1207 January 2003. 1209 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1210 "Routing Requirements for Urban Low-Power and Lossy 1211 Networks", RFC 5548, May 2009. 1213 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1214 "Industrial Routing Requirements in Low-Power and Lossy 1215 Networks", RFC 5673, October 2009. 1217 12.3. References 1219 [IEEE.754.1985] 1220 IEEE Standard 754, "Standard for Binary Floating-Point 1221 Arithmetic", August 1985. 1223 Authors' Addresses 1225 JP Vasseur (editor) 1226 Cisco Systems, Inc 1227 11, Rue Camille Desmoulins 1228 Issy Les Moulineaux, 92782 1229 France 1231 Email: jpv@cisco.com 1233 Mijeom (editor) 1234 Future Tech Lab., Korea Telecom 1235 17 Woomyeon-dong, Seocho-gu 1236 Seoul, 137-792 1237 Korea 1239 Email: mjkim@kt.com 1241 Kris 1242 Dust Networks 1243 30695 Huntwood Ave. 1244 Hayward, CA 95544 1245 USA 1247 Email: kpister@dustnetworks.com 1249 Hakjin 1250 Future Tech Lab., Korea Telecom 1251 17 Woomyeon-dong, Seocho-gu 1252 Seoul, 137-792 1253 Korea 1255 Email: hjchong@kt.com