idnits 2.17.1 draft-ietf-roll-p2p-measurement-09.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 (February 4, 2013) is 4092 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 947 == Missing Reference: 'Index' is mentioned on line 895, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Goyal, Ed. 3 Internet-Draft University of Wisconsin 4 Intended status: Experimental Milwaukee 5 Expires: August 8, 2013 E. Baccelli 6 INRIA 7 A. Brandt 8 Sigma Designs 9 J. Martocci 10 Johnson Controls 11 February 4, 2013 13 A Mechanism to Measure the Routing Metrics along a Point-to-point Route 14 in a Low Power and Lossy Network 15 draft-ietf-roll-p2p-measurement-09 17 Abstract 19 This document specifies a mechanism that enables an RPL router to 20 measure the aggregated values of given routing metrics along an 21 existing route towards another RPL router, thereby allowing the 22 router to decide if it wants to initiate the discovery of a better 23 route. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF 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 http://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 August 8, 2013. 42 Copyright Notice 44 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6 63 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6 64 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4. Originating a Measurement Request . . . . . . . . . . . . . . 11 66 4.1. When Measuring A Hop-by-hop Route with a Global 67 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2. When Measuring A Hop-by-hop Route with a Local 69 RPLInstanceID With Route Accumulation Off . . . . . . . . 13 70 4.3. When Measuring A Hop-by-hop Route with a Local 71 RPLInstanceID With Route Accumulation On . . . . . . . . . 14 72 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 15 73 5. Processing a Measurement Request at an Intermediate Point . . 16 74 5.1. When Measuring A Hop-by-hop Route with a Global 75 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 17 76 5.2. When Measuring A Hop-by-hop Route with a Local 77 RPLInstanceID With Route Accumulation Off . . . . . . . . 18 78 5.3. When Measuring A Hop-by-hop Route with a Local 79 RPLInstanceID With Route Accumulation On . . . . . . . . . 19 80 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19 81 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 20 82 6. Processing a Measurement Request at the End Point . . . . . . 20 83 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 21 84 7. Processing a Measurement Reply at the Start Point . . . . . . 22 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 Point to point (P2P) communication between arbitrary routers in a Low 96 power and Lossy Network (LLN) is a key requirement for many 97 applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs 98 (RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic 99 Graph (DAG) built to optimize the routing costs to reach the DAG's 100 root. The P2P routing functionality, available under RPL, has the 101 following key limitations: 103 o The P2P routes are restricted to use the DAG links only. Such P2P 104 routes may potentially be suboptimal and may lead to traffic 105 congestion near the DAG root. 107 o RPL is a proactive routing protocol and hence requires all P2P 108 routes to be established ahead of the time they are used. Many 109 LLN applications require the ability to establish P2P routes "on 110 demand". 112 To ameliorate situations, where the core RPL's P2P routing 113 functionality does not meet the application requirements, 114 [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. 115 P2P-RPL provides a reactive mechanism to discover P2P routes that 116 meet the specified routing constraints [RFC6551]. In some cases, the 117 application requirements or the LLN's topological features allow a 118 router to infer these routing constraints implicitly. For example, 119 the application may require the end-to-end loss rate and/or latency 120 along the route to be below certain thresholds or the LLN topology 121 may be such that a router can safely assume its destination to be 122 less than a certain number of hops away from itself. 124 When the existing routes are deemed unsatisfactory but the router 125 does not implicitly know the routing constraints to be used in P2P- 126 RPL route discovery, it may be necessary for the router to measure 127 the aggregated values of the routing metrics along the existing 128 route. This knowledge will allow the router to frame reasonable 129 routing constraints to discover a better route using P2P-RPL. For 130 example, if the router determines the aggregate ETX (Expected Number 131 of Transmissions) [RFC6551] along an existing route to be "x", it can 132 use "ETX < x*y", where y is a certain fraction, as the routing 133 constraint for use in P2P-RPL route discovery. Note that it is 134 important that the routing constraints not be overly strict; 135 otherwise, the P2P-RPL route discovery may fail even though a route 136 exists that is much better than the one currently being used. 138 This document specifies a mechanism that enables an RPL router to 139 measure the aggregated values of the routing metrics along an 140 existing route to another RPL router in an LLN, thereby allowing the 141 router to decide if it wants to discover a better route using P2P-RPL 142 and determine the routing constraints to be used for this purpose. 143 Thus, the utility of this mechanism is dependent on the existence of 144 P2P-RPL, which is targeting publication as an Experimental RFC. It 145 makes sense, therefore, for this document also to target publication 146 as an Experimental RFC. The hope is that experiments with P2P-RPL 147 and the mechanism defined in this document will result in feedback on 148 the utility and benefits of this document and it will be revised and 149 progressed on the Standards Track based on this feedback. 151 1.1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 [RFC2119]. 158 This document uses terminology from [RFC6550] and 159 [I-D.ietf-roll-p2p-rpl]. Additionally, this document defines the 160 following terms. 162 Start Point: The Start Point refers to the RPL router that initiates 163 the measurement process defined in this document and is the start 164 point of the P2P route being measured. 166 End Point: The End Point refers to the RPL router at the end point of 167 the P2P route being measured. 169 Intermediate Point: An RPL router, other than the Start Point and the 170 End Point, on the P2P route being measured. 172 The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have 173 been redefined in this document in the following manner. 175 Forward direction: The direction from the Start Point to the End 176 Point. 178 Reverse direction: The direction from the End Point to the Start 179 Point. 181 2. Overview 183 The mechanism described in this document can be used by a Start Point 184 in an LLN to measure the aggregated values of selected routing 185 metrics along a P2P route to an End Point within the LLN. The route 186 is measured in the Forward direction. Such a route could be a Source 187 Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route 189 [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL 190 [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route 191 with the initial part consisting of hop-by-hop ascent to the root of 192 a non-storing DAG [RFC6550] and the final part consisting of a 193 source-routed descent to the End Point. The Start Point decides what 194 metrics to measure and sends a Measurement Request message, carrying 195 the desired routing metric objects, along the route. If a Source 196 Route is being measured, the Measurement Request carries the route 197 inside an Address vector. If a Hop-by-hop Route is being measured, 198 the Measurement Request identifies the route by its RPLInstanceID 199 [RFC6550] (and, in case the RPLInstanceID is a local value, the Start 200 Point's IPv6 address associated with the route). On receiving a 201 Measurement Request, an Intermediate Point updates the routing metric 202 values inside the message and forwards it to the next hop on the 203 route. Thus, the Measurement Request accumulates the values of the 204 routing metrics for the complete route as it travels towards the End 205 Point. Upon receiving the Measurement Request, the End Point 206 unicasts a Measurement Reply message, carrying the accumulated values 207 of the routing metrics, back to the Start Point. Optionally, the 208 Start Point may allow an Intermediate Point to generate the 209 Measurement Reply if the Intermediate Point already knows the 210 relevant routing metric values along rest of the route. 212 The Measurement Request may include an Address vector that serves one 213 of the following functions: 215 o To accumulate a Source Route for End Point's use: If a Hop-by-hop 216 Route with a local RPLInstanceID is being measured, the Start 217 Point may require each Intermediate Point to add its IPv6 address 218 to an Address vector inside the Measurement Request. The Source 219 Route, thus accumulated, can be used by the End Point to reach the 220 Start Point. In particular, the End Point may use the accumulated 221 Source Route to send the Measurement Reply back to the Start 222 Point. In this case, the Start Point includes a suitably-sized 223 Address vector in the Measurement Request. The size of the 224 Address vector puts a hard limit on the length of the accumulated 225 route. An Intermediate Point is not allowed to modify the size of 226 the Address vector and must discard a received Measurement Request 227 if the Address vector is not large enough to contain the complete 228 route. 230 o To carry the Source Route being measured: The Start Point may 231 insert an Address vector inside the Measurement Request to carry 232 the Source Route being measured. Also, the root of a global non- 233 storing DAG may insert an Address vector, carrying a Source Route 234 from itself to the End Point, inside a Measurement Request message 235 if this message had been traveling along this DAG so far. In both 236 cases, an Intermediate Point is not allowed to modify an existing 237 Address vector before forwarding the Measurement Request further. 238 In other words, an Intermediate Point is not allowed to modify the 239 Source Route along which the Measurement Request is currently 240 traveling. 242 3. The Measurement Object (MO) 244 This document defines two new RPL Control Message types, the 245 Measurement Object (MO), with code TBD1, and the Secure MO, with code 246 TBD2. An MO serves as both Measurement Request and Measurement 247 Reply. 249 3.1. Format of the base MO 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 . Start Point Address . 258 . . 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 . End Point Address . 263 . . 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 . Address[0..Num-1] . 268 . . 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 . Metric Container Option(s) . 273 . . 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 1: Format of the base Measurement Object (MO) 279 The format of a base MO is shown in Figure 1. A base MO consists of 280 the following fields: 282 o RPLInstanceID: This field specifies the RPLInstanceID of the Hop- 283 by-hop Route along which the Measurement Request travels (or 284 traveled initially until it switched over to a Source Route). 286 o Compr: In many LLN deployments, IPv6 addresses share a well known, 287 common prefix. In such cases, the common prefix can be elided 288 when specifying IPv6 addresses in the Start Point/End Point 289 Address fields and the Address vector. The "Compr" field, a 4-bit 290 unsigned integer, is set by the Start Point to specify the number 291 of prefix octets that are elided from the IPv6 addresses in Start 292 Point/End Point Address fields and the Address vector. The Start 293 Point will set the Compr value to zero if full IPv6 addresses are 294 to be carried in the Start Point Address/End Point Address fields 295 and the Address vector. 297 o Type (T): This flag is set to one if the MO represents a 298 Measurement Request. The flag is set to zero if the MO is a 299 Measurement Reply. 301 o Hop-by-hop (H): The Start Point MUST set this flag to one if (at 302 least the initial part of) the route being measured is hop-by-hop. 303 In that case, the Hop-by-hop Route is identified by the 304 RPLInstanceID, the End Point Address and, if the RPLInstanceID is 305 a local value, the Start Point Address fields inside the 306 Measurement Request. Here, the Start Point Address field is 307 required to be same as the DODAGID (the identifier of the 308 destination-oritented DAG root) [RFC6550] of the route being 309 measured. The Start Point MUST set the H flag to zero if the 310 route being measured is a Source Route specified in the Address 311 vector. An Intermediate Point MUST set the H flag in an outgoing 312 Measurement Request to the same value that it had in the 313 corresponding incoming Measurement Request unless it is the root 314 of the non-storing global DAG, identified by the RPLInstanceID, 315 along which the Measurement Request had been traveling so far and 316 the Intermediate Point intends to insert a Source Route inside the 317 Address vector to direct it towards the End Point. In that case, 318 the Intermediate Point MUST set the H flag to zero. 320 o Accumulate Route (A): A value 1 in this flag indicates that the 321 Measurement Request is accumulating a Source Route for use by the 322 End Point to send the Measurement Reply back to the Start Point. 323 Route accumulation is allowed (i.e., this flag MAY be set to one) 324 inside a Measurement Request only if it travels along a Hop-by-hop 325 Route represented by a local RPLInstanceID (i.e., H = 1, 326 RPLInstanceID has a local value). In this case, an Intermediate 327 Point adds its unicast IPv6 address (after eliding Compr number of 328 prefix octets) to the Address vector in the manner specified in 329 Section 5.3. In other cases, this flag MUST be set to zero on 330 transmission and ignored on reception. Route accumulation is not 331 allowed when the Measurement Request travels along a Hop-by-hop 332 Route with a global RPLInstanceID, i.e., along a global DAG, 333 because: 335 * The DAG's root may need the Address vector to insert a Source 336 Route to the End Point; and 338 * The End Point can presumably reach the Start Point along this 339 global DAG (identified by the RPLInstanceID field). 341 o Reverse (R): A value 1 in this flag inside a Measurement Request 342 indicates that the Address vector contains a complete Source Route 343 from the Start Point to the End Point, which can be used, after 344 reversal, by the End Point to send the Measurement Reply back to 345 the Start Point. This flag MAY be set to one inside a Measurement 346 Request only if a Source Route, from the Start Point to the End 347 Point, is being measured. Otherwise, this flag MUST be set to 348 zero on transmission and ignored on reception. 350 o Back Request (B): A value 1 in this flag serves as a request to 351 the End Point to send a Measurement Request towards the Start 352 Point. On receiving a Measurement Request with the B flag set to 353 one, the End Point SHOULD generate a Measurement Request to 354 measure the cost of its current (or the most preferred) route to 355 the Start Point. Receipt of this Measurement Request would allow 356 the Start Point to know the cost of the back route from the End 357 Point to itself and thus determine the round-trip cost of reaching 358 the End Point. 360 o Intermediate Reply (I): A value 1 in this flag serves as a 361 permission to an Intermediate Point to generate a Measurement 362 Reply if it knows the aggregated values of the routing metrics 363 being measured for the rest of the route. Setting this flag to 364 one may be useful in scenarios where the Hop Count [RFC6551] is 365 the routing metric of interest and an Intermediate Point (e.g. the 366 root of a non-storing global DAG or a common ancestor of the Start 367 Point and the End Point in a storing global DAG) may know the Hop 368 Count of the remainder of the route to the End Point. This flag 369 MAY be set to one only if a Hop-by-hop Route with a global 370 RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a 371 global value). Otherwise, this flag MUST be set to zero on 372 transmission and ignored on reception. 374 o SequenceNo: A 6-bit sequence number, assigned by the Start Point, 375 that allows the Start Point to uniquely identify a Measurement 376 Request and the corresponding Measurement Reply. 378 o Num: This field indicates the number of elements, each (16 - 379 Compr) octets in size, inside the Address vector. If the value of 380 this field is zero, the Address vector is not present in the MO. 382 o Index: If the Measurement Request is traveling along a Source 383 Route contained in the Address vector (i.e., H = 0), this field 384 indicates the index in the Address vector of the next hop on the 385 route. If the Measurement Request is traveling along a Hop-by-hop 386 Route with a local RPLInstanceID and the Route Accumulation is on 387 (i.e., H = 1, RPLInstanceID has a local value, A = 1), this field 388 indicates the index in the Address vector where an Intermediate 389 Point receiving the Measurement Request must store its IPv6 390 address. Otherwise, this field MUST be set to zero on 391 transmission and ignored on reception. 393 o Start Point Address: A unicast IPv6 address of the Start Point 394 after eliding Compr number of prefix octets. If the Measurement 395 Request is traveling along a Hop-by-hop Route and the 396 RPLInstanceID field indicates a local value, the Start Point 397 Address field MUST specify the DODAGID value that, along with the 398 RPLInstanceID and the End Point Address, uniquely identifies the 399 Hop-by-hop Route being measured. 401 o End Point Address: A unicast IPv6 address of the End Point after 402 eliding Compr number of prefix octets. 404 o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr 405 number of prefix octets elided) representing a Source Route: 407 * Each element in the vector has size (16 - Compr) octets. 409 * The total number of elements inside the Address vector is given 410 by the Num field. 412 * The Start Point and End Point addresses MUST NOT be included in 413 the Address vector. 415 * The Address vector MUST NOT contain any multicast addresses. 417 * If the Start Point wants to measure a Hop-by-hop Route with a 418 local RPLInstanceID and accumulate a Source Route for the End 419 Point's use (i.e., the Measurement Request has the H flag set 420 to 1, RPLInstanceID set to a local value and the A flag set to 421 1), it MUST include a suitably-sized Address vector in the 422 Measurement Request. As the Measurement Request travels over 423 the route being measured, the Address vector accumulates a 424 Source Route that can be used by the End Point, after reversal, 425 to reach (and, in particular, to send the Measurement Reply 426 back to) the Start Point. The route MUST be accumulated in the 427 Forward direction but the IPv6 addresses in the accumulated 428 route MUST be reachable in the Reverse direction. An 429 Intermediate Point adding its address to the Address vector 430 MUST NOT modify the size of the Address vector. 432 * If the Start Point wants to measure a Source Route, it MUST 433 include an Address vector, containing the route being measured, 434 inside the Measurement Request. Similarly, if the Measurement 435 Request had been traveling along a global non-storing DAG so 436 far, the root of this DAG may insert an Address vector, 437 containing a Source Route from itself to the End Point, inside 438 the Measurement Request. In both cases, the Source Route 439 inside the Address vector MUST consist of IPv6 addresses 440 reachable in the Forward direction. Further, in both cases, an 441 Intermediate Point MUST NOT modify the contents of the existing 442 Address vector before forwarding the Measurement Request 443 further. In other words, an Intermediate Point MUST NOT modify 444 the Source Route along which the Measurement Request is 445 currently traveling. The Start Point MAY set the R flag in the 446 Measurement Request to one if the Source Route inside the 447 Address vector can be used by the End Point, after reversal, to 448 reach (and, in particular, to send the Measurement Reply back 449 to) the Start Point. In other words, the Start Point MAY set 450 the R flag to one only if all the IPv6 addresses in the Address 451 vector are reachable in the Reverse direction. 453 o Metric Container Options: A Measurement Request MUST contain one 454 or more Metric Container options [RFC6550] to accumulate the 455 values of the selected routing metrics in the manner described in 456 [RFC6551] for the route being measured. 458 Section 4 describes how a Start Point sets various fields inside a 459 Measurement Request in different cases. Section 5 describes how an 460 Intermediate Point processes a received Measurement Request before 461 forwarding it further. Section 6 describes how the End Point 462 processes a received Measurement Request and generate a Measurement 463 Reply. Finally, Section 7 describes how the Start Point processes a 464 received Measurement Reply. In the following discussion, any 465 reference to discarding a received Measurement Request/Reply with "no 466 further processing" does not preclude updating the appropriate error 467 counters or any similar actions. 469 3.2. Secure MO 471 A Secure MO follows the format in Figure 7 of [RFC6550], where the 472 base format is the base MO shown in Figure 1. 474 An LLN deployment MUST support the use of Secure MO messages to have 475 the ability to invoke RPL-provided security mechanisms and prevent 476 misuse of the measurement mechanism by unauthorized routers. 478 In the following discussion, any reference to MO message is also 479 applicable to Secure MO message unless noted otherwise. 481 4. Originating a Measurement Request 483 A Start Point sets various fields inside the Measurement Request it 484 generates in the manner described below. The Start Point MUST also 485 include the routing metric objects [RFC6551] of interest inside one 486 or more Metric Container options inside the Measurement Request. The 487 Start Point then determines the next hop on the route being measured. 488 If a Hop-by-hop route is being measured (i.e., H = 1), the next hop 489 is determined using the RPLInstanceID, the End Point Address and, if 490 RPLInstanceID is a local value, the Start Point Address fields in the 491 Measurement Request. If a Source Route is being measured (i.e., H = 492 0), the Address[0] element inside the Measurement Request contains 493 the next hop address. The Start Point MUST ensure that 495 o the next hop address is a unicast address; and 497 o the next hop is on-link; and 499 o the next hop is in the same RPL routing domain as the Start Point; 501 failing which the Start Point MUST discard the Measurement Request 502 without sending. Depending on the routing metrics, the Start Point 503 must initiate the routing metric objects inside the Metric Container 504 options by including the routing metric values for the first hop on 505 the route being measured. Finally, the Start Point MUST unicast the 506 Measurement Request to the next hop on the route being measured. 508 The Start Point MUST maintain state for just transmitted Measurement 509 Request for a life time duration that is large enough to allow the 510 corresponding Measurement Reply to return. This state consists of 511 the RPLInstanceID, the SequenceNo and the End Point Address fields of 512 the Measurement Request. The life time duration for this state is 513 locally determined by the Start Point and may be deployment specific. 514 This state expires when the corresponding Measurement Reply is 515 received or when the life time is over, whichever occurs first. 516 Failure to receive the corresponding Measurement Reply before the 517 expiry of a state may occur due to a number of reasons including 518 unwillingness on part of an Intermediate Point or the End Point to 519 process the Measurement Request. The Start Point should take such 520 possibilities in account when deciding whether to generate another 521 Measurement Request for this route. The Start Point MUST discard a 522 received Measurement Reply with no further processing if the state 523 for the corresponding Measurement Request has already expired. 525 4.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 527 If a Hop-by-hop Route with a global RPLInstanceID is being measured 528 (i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT 529 contain an Address vector and various MO fields MUST be set in the 530 following manner: 532 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 533 measured. 535 o Compr: MUST be set to specify the number of prefix octets that are 536 elided from the IPv6 addresses in Start Point/End Point Address 537 fields. 539 o Type (T): MUST be set to one since the MO represents a Measurement 540 Request. 542 o Hop-by-hop (H): MUST be set to one. 544 o Accumulate Route (A): This flag MUST be set to zero. 546 o Reverse (R): This flag MUST be set to zero. 548 o Back Request (B): This flag MAY be set to one to request the End 549 Point to send a Measurement Request to the Start Point. 551 o Intermediate Reply (I): This flag MAY be set to one if the Start 552 Point expects an Intermediate Point to know the values of the 553 routing metrics being measured for the remainder of the route. 555 o SequenceNo: Assigned by the Start Point so that it can uniquely 556 identify the Measurement Request and the corresponding Measurement 557 Reply. 559 o Num: This field MUST be set to zero. 561 o Index: This field MUST be set to zero. 563 o Start Point Address: MUST be set to a unicast IPv6 address of the 564 Start Point after eliding Compr number of prefix octets. 566 o End Point Address: MUST be set to a unicast IPv6 address of the 567 End Point after eliding Compr number of prefix octets. 569 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 570 Route Accumulation Off 572 If a Hop-by-hop Route with a local RPLInstanceID is being measured 573 and the Start Point does not want the MO to accumulate a Source Route 574 for the End Point's use, the MO MUST NOT contain the Address vector 575 and various MO fields MUST be set in the following manner: 577 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 578 measured. 580 o Compr: MUST be set to specify the number of prefix octets that are 581 elided from the IPv6 addresses in Start Point/End Point Address 582 fields. 584 o Type (T): MUST be set to one since the MO represents a Measurement 585 Request. 587 o Hop-by-hop (H): MUST be set to one. 589 o Accumulate Route (A): This flag MUST be set to zero. 591 o Reverse (R): This flag MUST be set to zero. 593 o Back Request (B): This flag MAY be set to one to request the End 594 Point to send a Measurement Request to the Start Point. 596 o Intermediate Reply (I): This flag MUST be set to zero. 598 o SequenceNo: Assigned by the Start Point so that it can uniquely 599 identify the Measurement Request and the corresponding Measurement 600 Reply. 602 o Num: This field MUST be set to zero. 604 o Index: This field MUST be set to zero. 606 o Start Point Address: This field MUST contain the DODAGID value 607 (after eliding Compr number of prefix octets) associated with the 608 route being measured. 610 o End Point Address: MUST be set to a unicast IPv6 address of the 611 End Point after eliding Compr number of prefix octets. 613 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 614 Route Accumulation On 616 If a Hop-by-hop Route with a local RPLInstanceID is being measured 617 and the Start Point desires the MO to accumulate a Source Route for 618 the End Point to send the Measurement Reply message back, the MO MUST 619 contain a suitably-sized Address vector and various MO fields MUST be 620 set in the following manner: 622 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 623 measured. 625 o Compr: MUST be set to specify the number of prefix octets that are 626 elided from the IPv6 addresses in Start Point/End Point Address 627 fields and the Address vector. 629 o Type (T): MUST be set to one since the MO represents a Measurement 630 Request. 632 o Hop-by-hop (H): MUST be set to one. 634 o Accumulate Route (A): This flag MUST be set to one. 636 o Reverse (R): This flag MUST be set to zero. 638 o Back Request (B): This flag MAY be set to one to request the End 639 Point to send a Measurement Request to the Start Point. 641 o Intermediate Reply (I): This flag MUST be set to zero. 643 o SequenceNo: Assigned by the Start Point so that it can uniquely 644 identify the Measurement Request and the corresponding Measurement 645 Reply. 647 o Num: This field MUST specify the number of address elements, each 648 (16 - Compr) octets in size, that can fit inside the Address 649 vector. 651 o Index: This field MUST be set to zero to indicate the position in 652 the Address vector where the next hop must store its IPv6 address. 654 o Start Point Address: This field MUST contain the DODAGID value 655 (after eliding Compr number of prefix octets) associated with the 656 route being measured. 658 o End Point Address: MUST be set to a unicast IPv6 address of the 659 End Point after eliding Compr number of prefix octets. 661 o Address vector: The Address vector must be large enough to 662 accomodate a complete Source Route from the End Point to the Start 663 Point. All the bits in the Address vector field MUST be set to 664 zero. 666 4.4. When Measuring A Source Route 668 If a Source Route is being measured, the Start Point MUST set various 669 MO fields in the following manner: 671 o RPLInstanceID: MUST be set to the binary value 10000000. 673 o Compr: MUST be set to specify the number of prefix octets that are 674 elided from the IPv6 addresses in Start Point/End Point Address 675 fields and the Address vector. 677 o Type (T): MUST be set to one since the MO represents a Measurement 678 Request. 680 o Hop-by-hop (H): MUST be set to zero. 682 o Accumulate Route (A): This flag MUST be set to zero. 684 o Reverse (R): This flag SHOULD be set to one if the Source Route in 685 the Address vector can be reversed and used by the End Point to 686 send the Measurement Reply message back to the Start Point. 687 Otherwise, this flag MUST be set to zero. 689 o Back Request (B): This flag MAY be set to one to request the End 690 Point to send a Measurement Request to the Start Point. 692 o Intermediate Reply (I): This flag MUST be set to zero. 694 o SequenceNo: Assigned by the Start Point so that it can uniquely 695 identify the Measurement Request and the corresponding Measurement 696 Reply. 698 o Num: This field MUST specify the number of address elements, each 699 (16 - Compr) octets in size, inside the Address vector. 701 o Index: This field MUST be set to zero to indicate the position in 702 the Address vector of the next hop on the route. 704 o Start Point Address: MUST be set to a unicast IPv6 address of the 705 Start Point after eliding Compr number of prefix octets. 707 o End Point Address: MUST be set to a unicast IPv6 address of the 708 End Point after eliding Compr number of prefix octets. 710 o Address vector: 712 * The Address vector MUST contain a complete Source Route from 713 the Start Point to the End Point (excluding the Start Point and 714 the End Point). 716 * The IPv6 addresses (with Compr prefix octets elided) in the 717 Address vector MUST be reachable in the Forward direction. 719 * If the R flag is set to one, the IPv6 addresses (with Compr 720 prefix octets elided) in the Address vector MUST also be 721 reachable in the Reverse direction. 723 * Each address appearing in the Address vector MUST be a unicast 724 address. 726 5. Processing a Measurement Request at an Intermediate Point 728 A router (an Intermediate Point or the End Point) MAY discard a 729 received MO with no processing to meet any policy-related goal. Such 730 policy goals may include the need to reduce the router's CPU load or 731 to enhance its battery life or to prevent misuse of this mechanism by 732 unauthorized nodes. 734 A router MUST discard a received MO with no further processing if the 735 value in the Compr field inside the received message is more than 736 what the router considers the length of the common prefix used in 737 IPv6 addresses in the LLN to be. 739 On receiving an MO, if a router chooses to process the packet 740 further, it MUST check if one of its IPv6 addresses is listed as 741 either the Start Point or the End Point Address. If neither, the 742 router considers itself an Intermediate Point and MUST process the 743 received MO in the following manner. 745 An Intermediate Point MUST discard the packet with no further 746 processing if the received MO is not a Measurement Request (i.e., T = 747 0). 749 Next, the Intermediate Point determines the type of the route being 750 measured (by checking the values of the H flag and the RPLInstanceID 751 field) and processes the received MO accordingly in the manner 752 specified next. 754 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 756 If a Hop-by-hop Route with a global RPLInstanceID is being measured 757 (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate 758 Point MUST process the received Measurement Request in the following 759 manner. 761 If the Num field inside the received Measurement Request is not set 762 to zero, thereby implying that an Address vector is present, the 763 Intermediate Point MUST discard the received message with no further 764 processing. 766 If the Intermediate Reply (I) flag is set to one in the received 767 Measurement Request and the Intermediate Point knows the values of 768 the routing metrics, specified in the Metric Container options, for 769 the remainder of the route, it MAY generate a Measurement Reply on 770 the End Point's behalf in the manner specified in Section 6.1 (after 771 including in the Measurement Reply the relevant routing metric values 772 for the complete route being measured). Otherwise, the Intermediate 773 Point MUST process the received message in the following manner. 775 The Intermediate Point MUST determine the next hop on the route being 776 measured using the RPLInstanceID and the End Point Address. If the 777 Intermediate Point is the root of the non-storing global DAG along 778 which the received Measurement Request had been traveling so far, it 779 MUST process the received Measurement Request in the following 780 manner: 782 o If the router does not know how to reach the End Point, it MUST 783 discard the Measurement Request with no further processing and MAY 784 send an ICMPv6 Destination Unreachable (with Code 0 - No Route To 785 Destination) error message [RFC4443] to the Start Point. 787 o Otherwise, unless the router determines the End Point itself to be 788 the next hop, the router MUST make the following changes in the 789 received Measurement Request: 791 * Set the H, A, R and I flags to zero (the A and R flags should 792 already be zero in the received message). 794 * Leave remaining fields unchanged (the Num field would be 795 modified in next steps). Note that the RPLInstanceID field 796 identifies the non-storing global DAG along which the 797 Measurement Request traveled so far. This information MUST be 798 preserved so that the End Point may use this DAG to send the 799 Measurement Reply back to the Start Point. 801 * Insert a new Address vector inside the Measurement Request and 802 specify a Source Route to the End Point inside the Address 803 vector as per the following rules: 805 + The Address vector MUST contain a complete route from the 806 router to the End Point (excluding the router and the End 807 Point); 809 + The IPv6 addresses (with Compr prefix octets elided) in the 810 Address vector MUST be reachable in the Forward direction; 812 + Each address appearing in the Address vector MUST be a 813 unicast address. 815 * Specify in the Num field the number of address elements in the 816 Address vector. 818 * Set the Index field to zero to indicate the position in the 819 Address vector of the next hop on the route. Thus, Address[0] 820 element contains the address of the next hop on the route. 822 The Intermediate Point MUST then complete the processing of the 823 received Measurement Request as specified in Section 5.5. 825 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 826 Route Accumulation Off 828 If a Hop-by-hop Route with a local RPLInstanceID is being measured 829 and the route accumulation is off (i.e., H = 1, RPLInstanceID has a 830 local value, A = 0), the Intermediate Point MUST process the received 831 Measurement Request in the following manner. 833 If the Num field inside the received Measurement Request is not set 834 to zero, thereby implying that an Address vector is present, the 835 Intermediate Point MUST discard the received message with no further 836 processing. 838 The Intermediate Point MUST then determine the next hop on the route 839 being measured using the RPLInstanceID, the End Point Address and the 840 Start Point Address (which represents the DODAGID of the route being 841 measured). If the Intermediate Point can not determine the next hop, 842 it MUST discard the Measurement Request with no further processing 843 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 844 Route To Destination) error message [RFC4443] to the Start Point. 845 Otherwise, the Intermediate Point MUST complete the processing of the 846 received Measurement Request as specified in Section 5.5. 848 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 849 Route Accumulation On 851 If a Hop-by-hop Route with a local RPLInstanceID is being measured 852 and the route accumulation in on (i.e., H = 1, RPLInstanceID has a 853 local value, A = 1), the Intermediate Point MUST process the received 854 Measurement Request in the following manner. 856 If the Num field inside the received Measurement Request is set to 857 zero, thereby implying that an Address vector is not present, the 858 Intermediate Point MUST discard the received message with no further 859 processing. 861 The Intermediate Point MUST then determine the next hop on the route 862 being measured using the RPLInstanceID, the End Point Address and the 863 Start Point Address (which represents the DODAGID of the route being 864 measured). If the Intermediate Point can not determine the next hop, 865 it MUST discard the Measurement Request with no further processing 866 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 867 Route To Destination) error message [RFC4443] to the Start Point. If 868 the index field has value Num - 1 and the next hop is not same as the 869 End Point, the Intermediate Point MUST drop the received Measurement 870 Request with no further processing. In this case, the next hop would 871 have no space left in the Address vector to store its address. 872 Otherwise, the router MUST store one of its unicast IPv6 addresses 873 (after eliding Compr prefix octets) at location Address[Index] and 874 then increment the Index field. The IPv6 address added to the 875 Address vector MUST be reachable in the Reverse direction. 877 The Intermediate Point MUST then complete the processing of the 878 received Measurement Request as specified in Section 5.5. 880 5.4. When Measuring A Source Route 882 If a Source Route is being measured (i.e., H = 0), the Intermediate 883 Point MUST process the received Measurement Request in the following 884 manner. 886 If the Num field inside the received Measurement Request is set to 887 zero, thereby implying that an Address vector is not present, the 888 Intermediate Point MUST discard the received message with no further 889 processing. 891 The Intermediate Point MUST verify that the Address[Index] element 892 lists one of its unicast IPv6 addresses, failing which it MUST 893 discard the Measurement Request with no further processing. The 894 Intermediate Point MUST then increment the Index field and use the 895 Address[Index] element as the next hop (unless Index value is now 896 Num). If the Index value is now Num, the Intermediate Point MUST use 897 the End Point Address as the next hop. 899 The Intermediate Point MUST then complete the processing of the 900 received Measurement Request as specified in Section 5.5. 902 5.5. Final Processing 904 The Intermediate Point MUST drop the received Measurement Request 905 with no further processing: 907 o If the next hop address is not a unicast address; or 909 o If the next hop is not on-link; or 911 o If the next hop is not in the same RPL routing domain as the 912 Intermediate Point. 914 Next, the Intermediate Point MUST update the routing metric objects, 915 inside the Metric Container option(s) inside the Measurement Request, 916 either by updating the aggregated value for the routing metric or by 917 attaching the local values for the metric inside the object. An 918 Intermediate Point can only update the existing metric objects and 919 MUST NOT add any new routing metric object to the Metric Container. 920 An Intermediate Point MUST drop the Measurement Request with no 921 further processing if it cannot update a routing metric object 922 specified inside the Metric Container. 924 Finally, the Intermediate Point MUST unicast the Measurement Request 925 to the next hop. 927 6. Processing a Measurement Request at the End Point 929 On receiving an MO, if a router chooses to process the message 930 further and finds one of its unicast IPv6 addresses listed as the End 931 Point Address, the router considers itself the End Point and MUST 932 process the received MO in the following manner. 934 The End Point MUST discard the received message with no further 935 processing if it is not a Measurement Request (i.e., T = 0). 937 If the received Measurement Request traveled on a Hop-by-hop Route 938 with a local RPLInstanceID with route accumulation on (i.e., H = 1, 939 RPLInstanceID has a local value and A = 1), elements Address[0] 940 through Address[Index - 1] in the Address vector contain a complete 941 Source Route from the Start Point to the End Point (excluding the 942 Start Point and the End Point), which the End Point MAY use, after 943 reversal, to reach the Start Point. 945 If the received Measurement Request traveled on a Source Route and 946 the Reverse flag is set to one (i.e., H = 0, R = 1), elements 947 Address[0] through Address[Num - 1] in the Address vector contain a 948 complete Source Route from the Start Point to the End Point 949 (excluding the Start Point and the End Point), which the End Point 950 MAY use, after reversal, to reach the Start Point. 952 The End Point MUST update the routing metric objects in the Metric 953 Container options if required and MAY note the measured values for 954 the complete route (especially, if the received Measurement Request 955 is likely a response to an earlier Measurement Request that the End 956 Point had sent to the Start Point with B flag set to one). 958 The End Point MUST generate a Measurement Reply message as specified 959 in Section 6.1. If the B flag is set to one in the received 960 Measurement Request, the End Point SHOULD generate a new Measurement 961 Request to measure the cost of its current (or the most preferred) 962 route to the Start Point. The routing metrics used in the new 963 Measurement Request MUST include the routing metrics specified in the 964 received Measurement Request. 966 6.1. Generating the Measurement Reply 968 A Measurement Reply MUST have the Type (T) flag set to zero and need 969 not contain the Address vector. The following fields inside a 970 Measurement Reply MUST have the same values as they had inside the 971 corresponding Measurement Request: RPLInstanceID, Compr, SequenceNo, 972 Start Point Address, End Point Address and Metric Container 973 Option(s). The remaining fields inside a Measurement Reply may have 974 any value and MUST be ignored on reception at the Start Point; the 975 received Measurement Request can, therefore, trivially be converted 976 into a Measurement Reply by setting the Type (T) flag to zero. 978 A Measurement Reply MUST be unicast back to the Start Point: 980 o If the Measurement Request traveled along a global DAG, identified 981 by the RPLInstanceID field, the Measurement Reply MAY be unicast 982 back to the Start Point along the same DAG. 984 o If the Measurement Request traveled along a Hop-by-hop Route with 985 a local RPLInstanceID and accumulated a Source Route from the 986 Start Point to the End Point, this Source Route MAY be used after 987 reversal to send the Measurement Reply back to the Start Point. 989 o If the Measurement Request traveled along a Source Route and the R 990 flag inside the received message is set to one, the End Point MAY 991 reverse the Source Route contained in the Address vector and use 992 it to send the Measurement Reply back to the Start Point. 994 7. Processing a Measurement Reply at the Start Point 996 When a router receives an MO, it examines if one of its unicast IPv6 997 addresses is listed as the Start Point Address. If yes, the router 998 is the Start Point and MUST process the received message in the 999 following manner. 1001 If the Start Point discovers that the received MO is not a 1002 Measurement Reply or if it no longer maintains state for the 1003 corresponding Measurement Request, it MUST discard the received 1004 message with no further processing. 1006 The Start Point can use the routing metric objects inside the Metric 1007 Container to evaluate the metrics for the measured P2P route. If a 1008 routing metric object contains local metric values recorded by 1009 routers on the route, the Start Point can make use of these local 1010 values by aggregating them into an end-to-end metric according to the 1011 aggregation rules for the specific metric. A Start Point is then 1012 free to interpret the metrics for the route according to its local 1013 policy. 1015 8. Security Considerations 1017 The mechanism defined in this document can potentially be used by a 1018 compromised router to send bogus Measurement Requests to arbitrary 1019 End Points. If sufficient Measurement Requests are sent, then it may 1020 cause CPU overload in the routers in the network, drain their 1021 batteries and cause traffic congestion in the network. Note that 1022 some of these problems would occur even if the compromised router 1023 were to generate bogus data traffic to arbitrary destinations. 1025 Since a Measurement Request can travel along a Source Route specified 1026 in the Address vector, some of the security concerns that led to the 1027 deprecation of Type 0 routing header [RFC5095] may be valid here. To 1028 address such concerns, the mechanism described in this document 1029 includes several remedies: 1031 o This document requires that a route inserted inside the Address 1032 vector must be a strict Source Route and must not include any 1033 multicast addresses. 1035 o This document requires that an MO message must not cross the 1036 boundaries of the RPL routing domain where it originated. A 1037 router must not forward a received MO message further if the next 1038 hop belongs to a different RPL routing domain. Hence, any 1039 security problems associated with the mechanism would be limited 1040 to one RPL routing domain. 1042 o This document requires that a router must drop a received 1043 Measurement Request if the next hop address is not on-link or if 1044 it is not a unicast address. 1046 The measurement mechanism described in this document may potentially 1047 be used by a rogue router to measure routes from itself to other 1048 routers and thus find out key information about the LLN, e.g., the 1049 topological features of the LLN (such as the identity of the key 1050 routers in the topology) or the remaining energy levels [RFC6551] in 1051 the routers. This information can potentially be used to attack the 1052 LLN. To protect against such misuse, this document allows RPL 1053 routers implementing this mechanism to not process MO messages (or 1054 process such messages selectively) based on a local policy. Further, 1055 an LLN deployment is required to support Secure MO (Section 3.2) 1056 messages to have the ability to invoke RPL-provided security 1057 mechanisms and prevent misuse of the measurement mechanism by 1058 unauthorized routers. 1060 9. IANA Considerations 1062 This document defines two new RPL messages: 1064 o "Measurement Object" (see Section 3.1), assigned a value TBD1 from 1065 the "RPL Control Codes" space [to be removed upon publication: 1066 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1067 [RFC6550]. IANA is requested to allocate TBD1 from the range 1068 0x00-0x7F to indicate a message without security enabled. The 1069 string TBD1 in this document should be replaced by the allocated 1070 value. These last two sentences should be removed before 1071 publication. 1073 o "Secure Measurement Object" (see Section 3.2), assigned a value 1074 TBD2 from the "RPL Control Codes" space [to be removed upon 1075 publication: 1076 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1077 [RFC6550]. IANA is requested to allocate TBD2 from the range 1078 0x80-0xFF to indicate a message with security enabled. The string 1079 TBD2 in this document should be replaced by the allocated value. 1080 These last two sentences should be removed before publication. 1082 +------+---------------------------+---------------+ 1083 | Code | Description | Reference | 1084 +------+---------------------------+---------------+ 1085 | TBD1 | Measurement Object | This document | 1086 | TBD2 | Secure Measurement Object | This document | 1087 +------+---------------------------+---------------+ 1089 RPL Control Codes 1091 10. Acknowledgements 1093 Authors gratefully acknowledge the contributions of Adrian Farrel, 1094 Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and 1095 Zach Shelby in the development of this document. 1097 11. References 1099 11.1. Normative References 1101 [I-D.ietf-roll-p2p-rpl] 1102 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 1103 Martocci, "Reactive Discovery of Point-to-Point Routes in 1104 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 1105 (work in progress), February 2013. 1107 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1108 Requirement Levels", BCP 14, RFC 2119, March 1997. 1110 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1111 Message Protocol (ICMPv6) for the Internet Protocol 1112 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1114 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1115 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1116 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1117 Lossy Networks", RFC 6550, March 2012. 1119 11.2. Informative References 1121 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1122 of Type 0 Routing Headers in IPv6", RFC 5095, 1123 December 2007. 1125 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1126 Routing Requirements in Low-Power and Lossy Networks", 1127 RFC 5826, April 2010. 1129 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1130 "Building Automation Routing Requirements in Low-Power and 1131 Lossy Networks", RFC 5867, June 2010. 1133 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1134 Barthel, "Routing Metrics Used for Path Calculation in 1135 Low-Power and Lossy Networks", RFC 6551, March 2012. 1137 Authors' Addresses 1139 Mukul Goyal (editor) 1140 University of Wisconsin Milwaukee 1141 3200 N Cramer St 1142 Milwaukee, WI 53211 1143 USA 1145 Phone: +1 414 2295001 1146 Email: mukul@uwm.edu 1148 Emmanuel Baccelli 1149 INRIA 1151 Phone: +33-169-335-511 1152 Email: Emmanuel.Baccelli@inria.fr 1153 URI: http://www.emmanuelbaccelli.org/ 1155 Anders Brandt 1156 Sigma Designs 1157 Emdrupvej 26A, 1. 1158 Copenhagen, Dk-2100 1159 Denmark 1161 Phone: +45 29609501 1162 Email: abr@sdesigns.dk 1164 Jerald Martocci 1165 Johnson Controls 1166 507 E Michigan Street 1167 Milwaukee 53202 1168 USA 1170 Phone: +1 414 524 4010 1171 Email: jerald.p.martocci@jci.com