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