idnits 2.17.1 draft-ji-roll-traffic-aware-objective-function-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2018) is 2016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-6tisch-enrollment-enhanced-beacon-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL C. Ji, Ed. 3 Internet-Draft Alexander TEI of Thessaloniki 4 Intended status: Standards Track R. Koutsiamanis 5 Expires: April 22, 2019 G. Papadopoulos 6 IMT Atlantique 7 D. Dujovne 8 Universidad Diego Portales 9 N. Montavont 10 IMT Atlantique 11 October 19, 2018 13 Traffic-aware Objective Function 14 draft-ji-roll-traffic-aware-objective-function-03 16 Abstract 18 This document proposes a remaining throughput metric for parent and 19 DODAG selection. This metric represents the amount of remaining 20 traffic handling capacity that the node has. This document also 21 proposes an Objective Function (OF) which uses the proposed metric 22 for parent and DODAG selection to balance the amount of traffic 23 between nodes and DODAGs. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 22, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DODAG construction in RPL . . . . . . . . . . . . . . . . . . 3 62 4. Load distribution problem in RPL . . . . . . . . . . . . . . 3 63 4.1. Parent selection problem . . . . . . . . . . . . . . . . 4 64 4.2. DODAG selection problem . . . . . . . . . . . . . . . . . 6 65 5. TAOF description . . . . . . . . . . . . . . . . . . . . . . 8 66 6. DIO Metric Container Type extension . . . . . . . . . . . . . 9 67 7. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Informative references . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 RPL [RFC6550] is an IPv6 Routing protocol for LLNs. It uses 76 Objective Functions (OF) to construct the Destination Oriented 77 Directed Acyclic Graph (DODAG) containing the nodes of the network. 78 The existing OFs defined are OF Zero (OF0) [RFC6552] and Minimum Rank 79 with Hysteresis OF (MRHOF) [RFC6719]. These OFs specify how nodes in 80 a DODAG select their preferred parent using different metrics. 82 The metrics can be separated into two different types, link metrics 83 (e.g. ETX) and node metrics (e.g. energy). Experimental results 84 [I-D.qasem-roll-rpl-load-balancing] conclude that using the current 85 OFs leads to an unbalanced network within which some nodes are 86 overloaded. Here, a node is overloaded in the sense that it forwards 87 many more packets than it otherwise would if the network were 88 balanced. This problem has consequences for the lifetime of the 89 network because overloaded nodes drain quicker than others, a problem 90 which becomes even more significant when the overloaded nodes are 91 near the DODAG root [I-D.qasem-roll-rpl-load-balancing]. 93 Similarly, one DODAG might be overloaded in the same sense compared 94 to another DODAG, and this will lead to the same consequences for the 95 whole DODAG as for a specific node. 97 This problem is still an open issue. This draft proposes a new way 98 of parent and DODAG selection as an attempt towards a solution. This 99 draft proposes a new OF that considers the remaining throughput as a 100 representation of the remaining traffic handling capacity each node 101 possesses and which uses this information to balance the amount of 102 traffic between nodes and DODAGs. 104 In brief, each node tracks its remaining throughput and appends this 105 information as a DAG Metric Container option to DIO messages it 106 sends. When the DIO message is received by child nodes or potential 107 child nodes, the remaining throughput information is stored and used 108 to influence the result when RPL parent or DODAG selection is 109 performed. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. DODAG construction in RPL 119 RPL uses OFs to construct a DODAG. OFs define the way the nodes 120 select their preferred parent and DODAG and how they compute the new 121 rank. A node's rank is always larger than its parent's rank because 122 the calculation of rank is based on an increment to the parent's 123 rank. This increment differs for each OF but all OFs include the 124 MinHopRankIncrease, which is the minimum increase in rank between a 125 node and a node's parent and a step. Different OFs use different 126 metrics or constraints to select the preferred parent and DODAG and 127 to define the step, depending on application requirements. Nodes 128 obtain these values from DODAG Information Object (DIO) control 129 messages sent by their neighbor nodes. 131 The construction of a DODAG starts when the root node sends DIO 132 messages to its neighbors. After receiving the DIO, these neighbor 133 nodes select the root as their preferred parent if they wish to join 134 the DODAG. To announce that they joined the DODAG as its child node, 135 they send a Destination Advertisement Object (DAO) to their preferred 136 parent - the DODAG root. After joining the DODAG, these nodes send 137 their own DIO messages with the new computed rank to their neighbors. 138 This procedure repeats for every node which joins the DODAG. 140 4. Load distribution problem in RPL 142 According to the experiments conducted using existing OFs RPL faces a 143 load distribution problem in large LLNs. With RPL using existing 144 OFs, such as MRHOF, an unbalanced network is formed with some nodes 145 overloaded and other nodes at rest. This problem is severe for 146 network performance because overloaded nodes will use up their 147 available energy faster than other nodes. This is exacerbated for 148 nodes near the root (within 1 hop distance) or nodes which are the 149 only parent candidate for other nodes. Additionally, when the 150 overloaded node shuts down, a big part of the network will become 151 disconnected and will have to be transferred to another parent or 152 DODAG. There is a high probability that the children nodes will also 153 select the same new node as their parent or the same DODAG, leading 154 to another overloaded node/DODAG. Also, when a node has selected its 155 parent, it will change only when the parent node is not reachable 156 (due to battery depletion or packet losses). 158 The existing OFs usually use a single metric to compare parent 159 candidates, for example, as described in [RFC6719] the default metric 160 used in MRHOF is ETX [RFC6551], which represents the number of 161 transmissions a node expects to make to a destination to successfully 162 deliver one packet. The result from using a single metric is that 163 nodes prefer to select the same node as their parent, which according 164 to [I-D.qasem-roll-rpl-load-balancing] leads to an unbalanced network 165 with overloaded nodes (node load is indicated by a node's child 166 count). But the child count does not accurately indicate the load 167 because among the child nodes some may have higher traffic load and 168 others may have lower. 170 The network traffic can be quantified by tracking the packets a node 171 generates/sends/receives and the amount of energy it consumes. 172 Energy consumption is strongly correlated to the amount of network 173 traffic handled by a node since the energy consumption for the 174 operation of the radio is the primary energy consumer in typical 175 nodes. However, directly measuring the remaining throughput is both 176 more accurate and also works when nodes have atypical energy 177 consumption profiles (e.g. increased node processing or high energy 178 consumption sensors). 180 Calculating the remaining throughput then requires knowledge of the 181 total throughput supported by a node and subtraction of the used 182 throughput. 184 4.1. Parent selection problem 185 T:4p/s | T:4p/s 186 U:4p/s (R) | U:4p/s (R) 187 ^ | ^ 188 | | | 189 +--------------+ | +------+-------+ 190 | | | | | 191 T:2p/s + T:2p/s + | T:2p/s + T:2p/s + 192 U:3p/s (A) U:1p/s (B) | U:2p/s (A) U:2p/s (B) 193 ^ ^ | ^ ^ 194 | | | | | 195 +-----+------+ | | +-----+ +------+ 196 | | | | | | | | | 197 + + + + | + + + + 198 (C1) (C2) (C3) (D1) | (C1) (C2) (C3) (D1) 199 U:1p/s U:1p/s U:1p/s U:1p/s | U:1p/s U:1p/s U:1p/s U:1p/s 200 | 201 Unbalanced | Balanced 203 Figure 1: Use of Remaining Throughput with nodes with the same 204 requirements 206 As a first simple example, an unbalanced network with nodes which all 207 use the same throughput ("U:") is shown in Figure 1. Nodes A and B 208 have the same total throughput ("T:"), but node A is overloaded due 209 to trying to handle more than its ability while node B has a spare 210 throughput of 2-1=1p/s. Its transformation into a balanced network 211 is shown on the right and it involves a node (C3) switching parents 212 from A to B so that the capacity of its parent is no longer exceeded. 214 T:6p/s | T:6p/s 215 U:6p/s (R) | U:6p/s (R) 216 ^ | ^ 217 | | | 218 +------+-------+ | +--------------+ 219 | | | | | 220 T:3p/s + T:3p/s + | T:3p/s + T:3p/s + 221 U:2p/s (A) U:4p/s (B) | U:3p/s (A) U:3p/s (B) 222 ^ ^ | ^ ^ 223 | | | | | 224 +-----+ +------+ | +-----+------+ | 225 | | | | | | | | | 226 + + + + | + + + + 227 (C1) (C2) (D1) (D2) | (C1) (C2) (D1) (D2) 228 U:1p/s U:1p/s U:1p/s U:3p/s | U:1p/s U:1p/s U:1p/s U:3p/s 229 | 230 Unbalanced | Balanced 232 Figure 2: Use of Remaining Throughput with nodes with different 233 requirements 235 As a second simple example, an unbalanced network with nodes which 236 have different throughput ("U:") is shown in Figure 2. In this case, 237 node B is overloaded and node D1 should move to parent A, which as a 238 space throughput of 1p/s. Its transformation into a balanced 239 equivalent network is shown on the right. 241 4.2. DODAG selection problem 243 The purpose of the following example is to show the problem of DODAG 244 selection, and not to focus on selecting the best parent. 246 .... DODAG 1 ... ... DODAG 2 .... | .... DODAG 1 ... ... DODAG 2 .... 247 . . . | . . . 248 . T:4p/s . T:4p/s . | . T:4p/s . T:4p/s . 249 . U:4p/s (R1) . U:3p/s (R2) . | . U:5p/s (R1) . U:3p/s (R2) . 250 . ^ . ^ . | . ^ . ^ . 251 . | . | . | . | . | . 252 . +-----+ . +-----+ . | . +-----+ . +-----+ . 253 . | | . | | . | . | | . | | . 254 . + + . + + . | . + + . + + . 255 . (A1) (B1) . (A2) (B2) . | . (A1) (B1) . (A2) (B2) . 256 . U:3p/s U:1p/s . U:2p/s U:1p/s . | . U:3p/s U:1p/s . U:2p/s U:1p/s . 257 ................ ................ | ................ ................ 258 | ^ 259 | | 260 ^ | +----+ 261 | | | 262 + | + 263 (C) | (C) 264 U:1p/s | U:1p/s 265 | 266 Joining | Joined - Unbalanced 268 Figure 3: DODAG selection example leading to unbalanced traffic with 269 RT metric 271 In the example in Figure 3, there are two DODAGs (DODAG 1 and DODAG 272 2) that belong to the same RPL Instance and a node (C) that must 273 select a DODAG. Node C has to pick from the information provided by 274 its two reachable neighbors: B1 and A2. On the left, node C is shown 275 before selecting the preferred DODAG, while on the right it is shown 276 after the DODAG selection. 278 Node C might choose B1 in DODAG 1 to be its preferred parent since 279 the traffic information of the two DODAGs is not available. However, 280 at the root node (R1), it can be observed that the total network 281 traffic is higher in DODAG 1 and that after node C joins it, the 282 traffic handling capacity of the root R1 has been exceeded. 284 .... DODAG 1 ... ... DODAG 2 .... | .... DODAG 1 ... ... DODAG 2 .... 285 . . . | . . . 286 . T:4p/s . T:4p/s . | . T:4p/s . T:4p/s . 287 . U:4p/s (R1) . U:3p/s (R2) . | . U:4p/s (R1) . U:4p/s (R2) . 288 . ^ . ^ . | . ^ . ^ . 289 . | . | . | . | . | . 290 . +-----+ . +-----+ . | . +-----+ . +-----+ . 291 . | | . | | . | . | | . | | . 292 . + + . + + . | . + + . + + . 293 . (A1) (B1) . (A2) (B2) . | . (A1) (B1) . (A2) (B2) . 294 . U:3p/s U:1p/s . U:2p/s U:1p/s . | . U:3p/s U:1p/s . U:2p/s U:1p/s . 295 ................ ................ | ................ ................ 296 | ^ 297 | | 298 ^ | +----+ 299 | | | 300 + | + 301 (C) | (C) 302 U:1p/s | U:1p/s 303 | 304 Joining | Joined - Balanced 306 Figure 4: DODAG selection example leading to balanced traffic with RT 307 metric 309 If the traffic handling capacity information is available, then node 310 C could make a more efficient decision by using DODAG 2 and selecting 311 node A2 as the preferred parent, as shown in Figure 4. Such a 312 selection is based on the traffic of the entire DODAG and would not 313 lead to exceeding the traffic handling capacity of the root R2 since 314 this root had spare capacity. 316 5. TAOF description 318 In this specification, a metric is proposed to be used in the parent 319 and DODAG selection mechanism, the Remaining Throughput (RT) which 320 represents the number of packets each node can transmit (send or 321 forward) during a certain time period. The period used, named 322 THROUGHPUT_PERIOD, is a parameter common to the whole RPL instance. 323 This parameter CAN be pre-configured on all the nodes. The period 324 used SHOULD coincide with a sliding window of the same size used to 325 calculate the packets transferred during this period to facilitate 326 the calculation of the remaining possible packet transmissions. 327 Therefore, whenever the RT value is reported it will refer to the 328 previous THROUGHPUT_PERIOD period of time. This information is added 329 in DIO messages and is broadcast to every neighbor. 331 At first, each node MUST identify from their neighbor set which nodes 332 are acceptable to be selected as a parent. For this purpose, the 333 metric ETX is used as a filter to filter out parent candidates with 334 low link quality with a preference for nodes with link quality below 335 a given threshold. The ETX threshold SHOULD be different depending 336 on application requirements. The suggested value for the relevant 337 threshold MAX_PATH_COST from MRHOF [RFC6719] is 32768, which means 338 the specific path has expected transmission counts greater than 256. 340 When the ETX value is used as a filter, nodes with bad link quality 341 will not be included in the parent set. This ensures that undue 342 retransmissions caused by bad links will be avoided. After all the 343 filtering is done, if any, the node chooses the parent candidate or 344 DODAG with the highest remaining throughput. 346 For the purpose of DODAG specifically, the A field in the Routing 347 Metric/Constraint Flag field object [RFC6551] SHOULD be set to 1, 348 indicating that the value reported is a maximum. Furthermore, when a 349 node is calculating the value of RT to broadcast in a DIO, the value 350 reported SHOULD be the minimum of two values: its parent RT and the 351 node's own calculated remaining throughput. Thus, the value 352 broadcasted will be the available remaining throughput in the whole 353 path from the node to the DODAG root. 355 This proposal is expected to increase the frequency of parent changes 356 because the remaining throughput is more likely to be different 357 between DIO messages, even for DIO messages from the same node. 358 There are multiple ways to minimize the frequency of unnecessary 359 parent changes: 361 a. Use the remaining throughput in combination with another metric 362 (e.g. child count, hop counts). 364 b. Use a threshold when comparing the remaining throughput, similar 365 to the approach in MRHOF [RFC6719]. Switch parents when the 366 difference of remaining throughput between the original parent 367 and the alternative parent is above a threshold. This threshold 368 depends on different factors (e.g. network size, average traffic 369 load) and SHOULD be defined differently for each use case. 371 6. DIO Metric Container Type extension 372 0 1 373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | RT | RT: Remaining Throughput 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 5: DAG metric container type format. 380 A DIO message carries fields as described in RFC6550 [RFC6550] and 381 the available options for the DAG metric container are described in 382 RFC6551 [RFC6551]. In this specification, a metric container option 383 is proposed and the detailed format is shown in Figure 5. The 384 information carried is the RT, represented as a 2 byte unsigned 385 integer and the unit is packets per THROUGHPUT_PERIOD time. 387 0 1 2 3 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 5 6 7 8 9 0 1 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | RPLInstanceID |Version Number | Rank | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |G|0| MOP | Prf | DTSN | Flags | Reserved | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 + + 396 | | 397 + DODAGID + 398 | | 399 + + 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | DAGMC Type (2)| DAGMC Length | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 404 | | 405 // DAG Metric Container data // 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 6: Example DIO Message with a DAG Metric Container option 411 The structure of the DIO Control Message when a DAG Metric Container 412 option is included is shown in Figure 6. The DAG Metric Container 413 option type (DAGMC Type in Figure 6) has the value 0x02 as per the 414 IANA registry for the RPL Control Message Options and is defined in 415 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 416 Figure 6) expresses the DAG Metric Container length in bytes. DAG 417 Metric Container data holds the actual data and is shown further 418 expanded in Figure 7. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | RT | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 7: DAG Metric Container (MC) data with Remaining Throughput 429 (RT) object body 431 An example DAG Metric Container containing the proposed Metric 432 Container object is shown in Figure 7. The explicit definition of 433 the fields is: 435 Routing-MC-Type: TBD1. The type of the proposed DAGMC extension. 436 To be assigned by IANA. 438 Remaining Throughput (RT): The remaining throughput, represented as 439 a 2-byte unsigned integer in units of packets per 440 THROUGHPUT_PERIOD time. 442 7. Enrollment 444 The RT metric SHOULD be used not only for ongoing parent selection 445 but also especially within enrollment, i.e. the process a node 446 follows to join a 6TiSCH network. In accordance to 447 [I-D.ietf-6tisch-enrollment-enhanced-beacon], the value in RT SHOULD 448 be used to affect the enrollment process so that a new node will be 449 able to directly select a DODAG which will be able to cover its 450 traffic needs and to spread the traffic load between different 451 DODAGs. More specifically, the pan priority field described in 452 [I-D.ietf-6tisch-enrollment-enhanced-beacon] can be derived from the 453 RT value. For this purpose, the RT value SHOULD be used with the 454 maximum value aggregation mode (A field in the Routing Metric/ 455 Constraint Flag field object [RFC6551] set to 1), to report the 456 maximum remaining throughput in the whole path to the DODAG root. 457 The pan priority field is an unsigned 8-bit integer with lower values 458 signifying higher priority while the RT value is a 16-bit unsigned 459 integer with higher values signifying more remaining throughput. To 460 convert the RT value to a pan priority the following formula should 461 be used: 463 pan priority = 16 - FLOOR(LOG2(RT + 1)) 465 where LOG2 is the logarithm function with a base of 2. The use of 466 the LOG function allows having higher accuracy in the low values of 467 the remaining throughput, where small value differences are 468 significant, and lower accuracy in the high values of the remaining 469 throughput, where small differences are less significant. The 470 addition of 1 to the RT allows converting RT=0. 472 8. Security Considerations 474 The structure of the DIO control message is extended, within the pre- 475 defined DIO options. Therefore, the security mechanisms defined in 476 RPL [RFC6550] apply to this proposed extension. 478 9. IANA Considerations 480 This proposal requests the allocation of a new value TBD1 for the 481 metric type "RT" in the Routing-MC-Type field in the DAG MC from 482 IANA. 484 Additionally, an Objective Code Point (OCP) with value TBD2 for TAOF 485 needs to be assigned in the Objective Code Point Registry as 486 described in Section 20.5 of [RFC6550]. 488 10. Informative references 490 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 491 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 492 Element encapsulation of 6tisch Join and Enrollment 493 Information", draft-ietf-6tisch-enrollment-enhanced- 494 beacon-00 (work in progress), July 2018. 496 [I-D.qasem-roll-rpl-load-balancing] 497 Qasem, M., Al-Dubai, A., Romdhani, I., Ghaleb, B., Hou, 498 J., and R. Jadhav, "Load Balancing Objective Function in 499 RPL", draft-qasem-roll-rpl-load-balancing-02 (work in 500 progress), October 2017. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 508 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 509 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 510 Low-Power and Lossy Networks", RFC 6550, 511 DOI 10.17487/RFC6550, March 2012, 512 . 514 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 515 and D. Barthel, "Routing Metrics Used for Path Calculation 516 in Low-Power and Lossy Networks", RFC 6551, 517 DOI 10.17487/RFC6551, March 2012, 518 . 520 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 521 Protocol for Low-Power and Lossy Networks (RPL)", 522 RFC 6552, DOI 10.17487/RFC6552, March 2012, 523 . 525 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 526 Hysteresis Objective Function", RFC 6719, 527 DOI 10.17487/RFC6719, September 2012, 528 . 530 Authors' Addresses 532 Chenyang Ji (editor) 533 Alexander TEI of Thessaloniki 534 Department of Informatics 535 Thessaloniki 57400 536 GREECE 538 Email: jichenyang920@gmail.com 540 Remous-Aris Koutsiamanis 541 IMT Atlantique 542 Office B00 - 126A 543 2 Rue de la Chataigneraie 544 Cesson-Sevigne - Rennes 35510 545 FRANCE 547 Phone: +33 299 12 70 49 548 Email: aris@ariskou.com 550 Georgios Papadopoulos 551 IMT Atlantique 552 Office B00 - 114A 553 2 Rue de la Chataigneraie 554 Cesson-Sevigne - Rennes 35510 555 FRANCE 557 Phone: +33 299 12 70 04 558 Email: georgios.papadopoulos@imt-atlantique.fr 559 Diego Dujovne 560 Universidad Diego Portales 561 Escuela de Informatica y Telecomunicaciones, Av. Ejercito 441 562 Santiago, Region Metropolitana 563 Chile 565 Phone: +56 (2) 676-8121 566 Email: diego.dujovne@mail.udp.cl 568 Nicolas Montavont 569 IMT Atlantique 570 Office B00 - 106A 571 2 Rue de la Chataigneraie 572 Cesson-Sevigne - Rennes 35510 573 FRANCE 575 Phone: +33 299 12 70 23 576 Email: nicolas.montavont@imt-atlantique.fr