idnits 2.17.1 draft-ietf-roll-p2p-measurement-02.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 29, 2011) is 4563 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Index' is mentioned on line 584, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-04 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: May 1, 2012 E. Baccelli 6 INRIA 7 A. Brandt 8 Sigma Designs 9 J. Martocci 10 Johnson Controls 11 October 29, 2011 13 A Mechanism to Measure the Quality of a Point-to-point Route in a Low 14 Power and Lossy Network 15 draft-ietf-roll-p2p-measurement-02 17 Abstract 19 This document specifies a mechanism that enables an RPL router to 20 measure the quality of an existing route towards another RPL router 21 in a low power and lossy network, thereby allowing the router to 22 decide if it wants to initiate the discovery of a better route. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 1, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 4 62 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5 63 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Originating a Measurement Request . . . . . . . . . . . . . . 9 65 4.1. To Measure A Hop-by-hop Route with a Global 66 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. To Measure A Hop-by-hop Route with a Local 68 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11 70 5. Processing a Measurement Request at an Intermediate Router . . 12 71 5.1. Determining Next Hop For An MO Measuring A Source Route . 13 72 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop 73 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Processing a Measurement Request at the Target . . . . . . . . 14 75 7. Processing a Measurement Reply at the Origin . . . . . . . . . 15 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 Point to point (P2P) communication between arbitrary routers in a Low 87 power and Lossy Network (LLN) is a key requirement for many 88 applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6 89 Routing Protocol for LLNs, constrains the LLN topology to a Directed 90 Acyclic Graph (DAG) built to optimize routing costs to reach the 91 DAG's root and requires the P2P routes to use the DAG links only. 92 Such P2P routes may potentially be suboptimal and may lead to traffic 93 congestion near the DAG root. Additionally, RPL is a proactive 94 routing protocol and hence all P2P routes must be established ahead 95 of the time they are used. 97 To ameliorate situations, where RPL's P2P routing functionality does 98 not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a 99 reactive mechanism to discover P2P routes that meet the specified 100 performance criteria. This mechanism, henceforth referred to as the 101 reactive P2P route discovery, allows the specification of routing 102 constraints [I-D.ietf-roll-routing-metrics], that the discovered 103 routes must satisfy. In some cases, the application requirements or 104 the LLN's topological features allow a router to infer the routing 105 constraints intrinsically. For example, the application may require 106 the end-to-end loss rate and/or latency on the route to be below 107 certain thresholds or the LLN topology may be such that a router can 108 safely assume its destination to be less than a certain number of 109 hops away from itself. 111 When the existing routes are deemed unsatisfactory but the router 112 does not intrinsically know the routing constraints to be used in P2P 113 route discovery, it may be necessary for the router to determine the 114 aggregated values of the routing metrics along the existing route. 115 This knowledge will allow the router to frame reasonable routing 116 constraints for use in P2P route discovery to determine a better 117 route. For example, if the router determines the aggregate ETX 118 [I-D.ietf-roll-routing-metrics] along an existing route to be "x", it 119 can use "ETX < x*y", where y is a certain fraction, as the routing 120 constraint for use in P2P route discovery. Note that it is important 121 that the routing constraints are not overly strict; otherwise the P2P 122 route discovery may fail even though a route, much better than the 123 one currently being used, exists. 125 This document specifies a mechanism that enables an RPL router to 126 measure the aggregated values of the routing metrics along an 127 existing route to another RPL router in an LLN, thereby allowing the 128 router to decide if it wants to initiate the reactive discovery of a 129 more optimal route and determine the routing constraints to be used 130 for this purpose. 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 Additionally, this document uses terminology from 140 [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and 141 [I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in 142 [I-D.ietf-roll-p2p-rpl], are redefined in the following manner. 144 Origin: The origin refers to the router that initiates the 145 measurement process defined in this document and is the start point 146 of the P2P route being measured. 148 Target: The target refers to the router at the end point of the P2P 149 route being measured. 151 Intermediate Router: A router, other than the origin and the target, 152 on the P2P route being measured. 154 2. Overview 156 The mechanism described in this document can be used by an origin in 157 an RPL domain to measure the aggregated values of the routing metrics 158 along a P2P route to a target within the same RPL domain. Such a 159 route could be a source route or a hop-by-hop route established using 160 RPL [I-D.ietf-roll-rpl] or the reactive P2P route discovery 161 [I-D.ietf-roll-p2p-rpl]. The origin sends a Measurement Request 162 message along the route. The Measurement Request accumulates the 163 values of the routing metrics as it travels towards the target. Upon 164 receiving the Measurement Request, the target unicasts a Measurement 165 Reply message, carrying the accumulated values of the routing 166 metrics, back to the origin. Optionally, the origin may allow an 167 intermediate route to generate the Measurement Reply if it already 168 knows the relevant routing metric values along rest of the route. 170 3. The Measurement Object (MO) 172 This document defines two new RPL Control Message types, the 173 Measurement Object (MO), with code 0x06 (to be confirmed by IANA), 174 and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO 175 serves as both Measurement Request and Measurement Reply. 177 3.1. Format of the base MO 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 | Origin Address | 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 | Target Address | 191 | | 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 . Address[1..Num] . 196 . . 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 . Metric Container Option(s) . 201 . . 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 1: Format of the base Measurement Object (MO) 207 The format of a base MO is shown in Figure 1. A base MO consists of 208 the following fields: 210 o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop 211 route. This field identifies the RPLInstanceID of the hop-by-hop 212 route being measured. If the route being measured is a source 213 route, this field MUST be set to 10000000 on transmission and 214 ignored on reception. 216 o Compr: In many LLN deployments, IPv6 addresses share a well known, 217 common prefix. In such cases, the common prefix can be elided 218 when specifying IPv6 addresses in Origin/Target Address fields and 219 the Address vector. The "Compr" field is a 4-bit unsigned integer 220 that indicates the number of prefix octets that are elided from 221 the IPv6 addresses in Origin/Target Address fields and the Address 222 vector. The Compr value will be 0 if full IPv6 addresses are 223 carried in the Origin/Target Address fields and the Address 224 vector. 226 o Type (T): This flag is set if the MO represents a Measurement 227 Request. The flag is cleared if the MO is a Measurement Reply. 229 o Hop-by-hop (H): This flag is set if the MO travels along a hop-by- 230 hop route. In that case, the hop-by-hop route is identified by 231 the RPLInstanceID and, if the RPLInstanceID is a local value, the 232 Origin Address serving as the DODAGID. This flag is cleared if 233 the MO travels along a source route specified in the Address 234 vector. Note that, in case the P2P route being measured lies 235 along a non-storing DAG, an MO message may travel along a hop-by- 236 hop route till it reaches the DAG's root, which then sends it 237 along a source route to its destination. In that case, the DAG 238 root will reset the H flag and also insert the source route to the 239 destination inside the Address vector. 241 o Accumulate Route (A): This flag is relevant only if the MO 242 represents a Measurement Request that travels along a hop-by-hop 243 route represented by a local RPLInstanceID. In other words, this 244 flag MAY be set only if T = 1, H = 1 and the RPLInstanceID field 245 has a local value. Otherwise, this flag MUST be cleared. A value 246 1 in this flag indicates that the Measurement Request MUST 247 accumulate a source route for use by the target to send the 248 Measurement Reply back to the origin. In this case, the 249 intermediate routers MUST add their IPv6 addresses (after eliding 250 Compr number of prefix octets) to the Address vector in the manner 251 specified later. 253 o Reverse (R): This flag is relevant only if the MO represents a 254 Measurement Request that travels along a source route, specified 255 in the Address vector, to the target. In other words, this flag 256 MAY be set only if T = 1 and H = 0. Otherwise, this flag MUST be 257 cleared. A value 1 in the flag indicates that the Address vector 258 contains a complete source route from the origin to the target, 259 which can be used, after reversal, by the target to source route 260 the Measurement Reply message back to the origin. 262 o Back Request (B): This flag serves as a request to the target to 263 send a Measurement Request towards the origin. The origin MAY set 264 this flag if it wants to make such a request to the target. On 265 receiving this request, the target MAY generate a Measurement 266 Request to measure the cost of its current (or the most preferred) 267 route to the origin. Receipt of this Measurement Request would 268 allow the origin to know the cost of the back route from the 269 target to itself and thus determine the round-trip cost of 270 reaching the target. 272 o Intermediate Reply (I): Relevant only if a hop-by-hop route is 273 being measured, this flag serves as a permission to an 274 intermediate router to generate a Measurement Reply if it knows 275 the cost of the rest of the route being measured. The origin MAY 276 set this flag if a hop-by-hop route is being measured (i.e., H = 277 1) and the origin wants to allow the intermediate routers to 278 generate the Measurement Reply in response to this Measurement 279 Request. Setting this flag may be useful in scenarios where Hop 280 Count [I-D.ietf-roll-routing-metrics] is the routing metric of 281 interest and the origin expects an intermediate router (e.g. the 282 root of a non-storing DAG or a common ancestor of the origin and 283 the target in a storing DAG) to know the Hop Count of the 284 remainder of the route to the target. This flag MUST be cleared 285 if the route being measured is a source route (i.e., H = 0). 287 o SequenceNo: A 6-bit sequence number, assigned by the origin, that 288 allows the origin to uniquely identify a Measurement Request and 289 the corresponding Measurement Reply. 291 o Num: This field indicates the number of fields in the Address 292 vector. If the value of this field is zero, the Address vector is 293 not present in the MO. 295 o Index: If the Measurement Request is traveling along a source 296 route contained in the Address vector (T=1,H=0), this field 297 indicates the index in the Address vector of the next hop on the 298 route. If the Measurement Request is traveling along a hop-by-hop 299 route with a local RPLInstanceID and the A flag is set 300 (T=1,H=1,A=1 and RPLInstanceID field has a local value), this 301 field indicates the index in the Address vector where an 302 intermediate router receiving the MO message must store its IPv6 303 address. Otherwise, this field MUST be set to zero on 304 transmission and ignored on reception. 306 o Origin Address: An IPv6 address of the origin after eliding Compr 307 number of prefix octets. If the MO is traveling along a hop-by- 308 hop route and the RPLInstanceID field indicates a local value, the 309 Origin Address field MUST contain the DODAGID value that, along 310 with the RPLInstanceID, uniquely identifies within the RPL domain 311 the hop-by-hop route being measured. 313 o Target Address: An IPv6 address of the target after eliding Compr 314 number of prefix octets. 316 o Address[1..Num]: A vector of IPv6 addresses (with Compr number of 317 prefix octets elided) representing a source route to the target: 319 * Each element in the vector has size (16 - Compr) octets. 321 * The total number of elements inside the Address vector is given 322 by the Num field. 324 * When the Measurement Request is traveling along a hop-by-hop 325 route with local RPLInstanceID and has the A flag set, the 326 Address vector is used to accumulate a source route to be used 327 by the target to send the Measurement Reply back to the origin. 328 In this case, the route MUST be accumulated in the forward 329 direction, i.e., from the origin to the target. The target 330 router would reverse this route to obtain a source route from 331 itself to the origin. The IPv6 addresses in the accumulated 332 route MUST be accessible in the backward direction. An 333 intermediate router adding its address to the Address vector 334 MUST ensure that its address does not already exist in the 335 vector. 337 * When the Measurement Request is traveling along a source route, 338 the Address vector MUST contain a complete route to the target 339 and the IPv6 addresses in the Address vector MUST be accessible 340 in the forward direction, i.e., from the origin to the target. 341 A router (origin or an intermediate router) inserting an 342 Address vector inside an MO MUST ensure that no address appears 343 more than once inside the vector. Each router on the way MUST 344 ensure that the loops do not exist within the source route. 345 The origin may set the R flag in the MO if the route in the 346 Address vector represents a complete route from the origin to 347 the target and this route can be used after reversal by the 348 target to send the Measurement Reply message back to the 349 origin. 351 * The origin and target addresses MUST NOT be included in the 352 Address vector. 354 * The Address vector MUST NOT contain any multicast addresses. 356 o Metric Container Options: An MO MUST contain one or more Metric 357 Container options to accumulate routing metric values for the 358 route being measured. 360 3.2. Secure MO 362 A Secure MO message follows the format in Figure 7 of 363 [I-D.ietf-roll-rpl], where the base format is the base MO shown in 364 Figure 1. 366 4. Originating a Measurement Request 368 If an origin needs to measure the routing metric values along a P2P 369 route towards a target, it generates an MO message and sets its 370 fields in the manner described below. Additionally, the origin MUST 371 set the T flag to 1 to indicate that the MO represents a Measurement 372 Request. The origin MUST also include one or more Metric Container 373 options inside the MO that carry the routing metric objects of 374 interest. If required, the origin must also initiate these routing 375 metric objects by including the values of the routing metrics for the 376 first hop on the P2P route being measured. 378 After setting the MO fields as described below, the origin MUST 379 unicast the MO message to the next hop on the P2P route. 381 4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID 383 If a hop-by-hop route with a global RPLInstanceID is being measured, 384 the MO message MUST NOT contain the Address vector and the following 385 MO fields MUST be set in the manner specified below: 387 o Hop-by-hop (H): This flag MUST be set; 389 o Accumulate Route (A): This flag MUST be cleared; 391 o Reverse (R): This flag MUST be cleared; 393 o Back Request (B): This flag MAY be set if the origin wants to 394 request the target to generate a Measurement Request back to 395 itself; 397 o Intermediate Reply (I): This flag MAY be set if the origin wants 398 to permit the intermediate routers to generate the Measurement 399 Reply on the target's behalf; 401 o Num: This field MUST be set to zero; 403 o Index: This field MUST be set to zero. 405 4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID 407 If a hop-by-hop route with a local RPLInstanceID is being measured 408 and the MO is not accumulating a source route for the target's use, 409 the MO message MUST NOT contain the Address vector and the following 410 MO fields MUST be set in the manner specified below: 412 o Hop-by-hop (H): This flag MUST be set; 413 o Accumulate Route (A): This flag MUST be cleared; 415 o Reverse (R): This flag MUST be cleared; 417 o Back Request (B): This flag MAY be set if the origin wants to 418 request the target to generate a Measurement Request back to 419 itself; 421 o Intermediate Reply (I): This flag MAY be set if the origin wants 422 to permit the intermediate routers to generate the Measurement 423 Reply on the target's behalf; 425 o Num: This field MUST be set to zero; 427 o Index: This field MUST be set to zero; 429 o Origin Address: This field MUST contain the DODAGID value (after 430 eliding Compr number of prefix octets) associated with the route 431 being measured. 433 If a hop-by-hop route with a local RPLInstanceID is being measured 434 and the origin desires the MO to accumulate a source route for the 435 target to send the Measurement Reply message back, it MUST set the 436 following MO fields in the manner specified below: 438 o Hop-by-hop (H): This flag MUST be set; 440 o Accumulate Route (A): This flag MUST be set; 442 o Reverse (R): This flag MUST be cleared; 444 o Back Request (B): This flag MAY be set if the origin wants to 445 request the target to generate a Measurement Request back to 446 itself; 448 o Intermediate Reply (I): This flag MAY be set if the origin wants 449 to permit the intermediate routers to generate the Measurement 450 Reply on the target's behalf; 452 o Address vector: The Address vector must be large enough to 453 accomodate a complete source route from the origin to the target. 454 All the bits in the Address vector field MUST be set to zero; 456 o Num: This field MUST specify the number of address elements that 457 can fit inside the Address vector; 459 o Index: This field MUST be set to 1; 460 o Origin Address: This field MUST contain the DODAGID value (after 461 eliding Compr number of prefix octets) associated with the route 462 being measured. 464 4.3. To Measure A Source Route 466 If a source route is being measured, the origin MUST set the 467 following MO fields in the manner specified below: 469 o RPLInstanceID: This field MUST be set to 10000000; 471 o Hop-by-hop (H): This flag MUST be cleared; 473 o Accumulate Route (A): This flag MUST be cleared; 475 o Reverse (R): This flag MUST be set if the source route in the 476 Address vector can be reversed and used by the target to source 477 route the Measurement Reply message back to the origin. 478 Otherwise, this flag MUST be cleared; 480 o Back Request (B): This flag MAY be set if the origin wants to 481 request the target to generate a Measurement Request back to 482 itself; 484 o Intermediate Reply (I): This flag MUST be cleared. 486 o Address vector: 488 * The Address vector MUST contain a complete route from the 489 origin to the target (excluding the origin and the target); 491 * The IPv6 addresses (with Compr prefix octets elided) in the 492 Address vector MUST be accessible in the forward direction, 493 i.e., from the origin to the target; 495 * To prevent loops in the source route, the origin MUST ensure 496 that 498 + Any IPv6 address MUST NOT appear more than once in the 499 Address vector; 501 + If the Address vector includes multiple IPv6 addresses 502 assigned to the origin's interfaces, such addresses MUST 503 appear back to back inside the Address vector. 505 * Each address appearing in the Address vector MUST be a unicast 506 address. 508 o Num: This field MUST be set to indicate the number of elements in 509 the Address vector; 511 o Index: This field MUST be set to 1. 513 The origin MUST NOT send the packet further if the next hop address 514 on the source route is not on-link. 516 5. Processing a Measurement Request at an Intermediate Router 518 A router MAY discard a received MO with no further processing to meet 519 any policy-related goal. Such policy goals may include the need to 520 reduce the router's CPU load or to enhance its battery life. 522 On receiving an MO, if a router chooses to process the packet 523 further, it MUST check if one of its IPv6 addresses is listed as 524 either the Origin or the Target Address. If not, the router 525 considers itself an Intermediate Router and MUST process the received 526 MO in the following manner. 528 An intermediate router MUST discard the packet with no further 529 processing if the received MO is not a Measurement Request. 531 If the I flag is set in the received MO and the intermediate router 532 knows the values of the routing metrics, specified in the Metric 533 Container, for the remainder of the route, it MAY generate a 534 Measurement Reply on the target's behalf in the manner specified in 535 Section 6 (after including in the Measurement Reply the relevant 536 routing metric values for the complete route being measured). 537 Otherwise, the intermediate router MUST process the received MO in 538 the following manner. 540 The router MUST determine the next hop on the P2P route being 541 measured in the manner described below. The router MUST drop the MO 542 with no further processing and MAY send an ICMPv6 Destination 543 Unreachable (with Code 0 - No Route To Destination) error message to 544 the source of the message if it can not determine the next hop for 545 the message. 547 After determining the next hop, the router MUST update the routing 548 metric objects, contained in the Metric Container options inside the 549 MO, either by updating the aggregated value for the routing metric or 550 by attaching the local values for the metric inside the object. 551 After updating the routing metrics, the router MUST unicast the MO to 552 the next hop. 554 5.1. Determining Next Hop For An MO Measuring A Source Route 556 In case the received MO is measuring a source route (H=0), the router 557 MUST increment the Index field and use the Address[Index] element as 558 the next hop. If Index is greater than Num, the router MUST use the 559 Target Address as the next hop. 561 An intermediate router MUST discard the MO packet with no further 562 processing if the next hop address is not on-link or is not a unicast 563 address. To prevent loops, an intermediate router MUST check if the 564 Address vector includes multiple IPv6 addresses assigned to the 565 router's interfaces and if such addresses do not appear back to back 566 inside the Address vector. In this case, the router MUST discard the 567 MO packet with no further processing. An MO message MUST NOT leave 568 the RPL domain where it originated. Hence, an intermediate router 569 MUST discard an MO message traveling along a source route if the next 570 hop on the way does not lie within the RPL domain. 572 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route 574 If the received MO is measuring a hop-by-hop route (H=1), the router 575 MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID 576 is a local value, the DODAGID (same as the Origin Address) to 577 determine the next hop for the MO. Moreover, 579 o If the RPLInstanceID of the hop-by-hop route is a local value and 580 the A flag is set, the router MUST check if the Address vector 581 already contains one of its IPv6 addresses. If yes, the router 582 MUST discard the packet with no further processing. Otherwise, 583 the router MUST store one of its IPv6 addresses (after eliding 584 Compr prefix octets) at location Address[Index] and then increment 585 the Index field. 587 o If the router is the root of the non-storing DAG along which the 588 received MO message has been traveling, the router MUST do the 589 following: 591 * Reset the H, A and R flags. 593 * Insert a source route to the target inside the Address vector 594 as per the following rules: 596 + The Address vector MUST contain a complete route from the 597 router to the target (excluding the router and the target); 599 + The IPv6 addresses (with Compr prefix octets elided) in the 600 Address vector MUST be accessible in the forward direction, 601 i.e., towards the target; 603 + To prevent loops in the source route, the router MUST ensure 604 that 606 - Any IPv6 address MUST NOT appear more than once in the 607 Address vector; 609 - If the Address vector includes multiple IPv6 addresses 610 assigned to the router's interfaces, such addresses MUST 611 appear back to back inside the Address vector. 613 + Each address appearing in the Address vector MUST be a 614 unicast address. 616 * Specify in the Num field the number of address elements in the 617 Address vector. 619 * Set the Index field to 1. 621 6. Processing a Measurement Request at the Target 623 On receiving an MO, if a router chooses to process the packet further 624 and finds one of its IPv6 addresses listed as the Target Address, it 625 MUST process the received MO in the following manner. 627 The target MUST discard the packet with no further processing if the 628 received MO is not a Measurement Request. 630 The target MUST update the routing metric objects in the Metric 631 Container options if required and MAY note the measured values for 632 the complete route if desired. 634 The target MUST generate a Measurement Reply message. The received 635 Measurement Request message can be trivially converted into the 636 Measurement Reply by reseting the T flag to zero. The target MAY 637 remove the Address vector from the Measurement Reply if desired. The 638 target MUST then unicast the Measurement Reply back to the origin: 640 o If the Measurement Request traveled along a DAG with a global 641 RPLInstanceID, the Measurement Reply MAY be unicast back to the 642 origin along the same DAG. 644 o If the Measurement Request traveled along a hop-by-hop route with 645 a local RPLInstanceID and the A flag inside the received message 646 is set, the target MAY reverse the source route contained in the 647 Address vector and use it to send the Measurement Reply back to 648 the origin. 650 o If the Measurement Request traveled along a source route and the R 651 flag inside the received message is set, the target MAY reverse 652 the source route contained in the Address vector and use it to 653 send the Measurement Reply back to the origin. 655 If the B flag is set in the received Measurement Request, the target 656 MAY generate a new Measurement Request to measure the cost of its 657 current (or the most preferred) route to the origin. The routing 658 metrics used in the new Measurement Request MUST include the routing 659 metrics specified in the received Measurement Request. 661 7. Processing a Measurement Reply at the Origin 663 When a router receives an MO, it examines if one of its IPv6 664 addresses is listed as the Origin Address. If yes, the router MUST 665 process the received message in the following manner. 667 The origin MUST discard the packet with no further processing if the 668 received MO is not a Measurement Reply or if the origin has no 669 recollection of sending a Measurement Request with the sequence 670 number listed in the received MO. 672 The origin SHOULD examine the routing metric objects inside the 673 Metric Container options to evaluate the quality of the measured P2P 674 route. If a routing metric object contains local metric values 675 recorded by routers on the route, the origin MAY aggregate these 676 local values into an end-to-end value as per the aggregation rules 677 for the metric. 679 8. Security Considerations 681 The mechanism defined in this document can potentially be used by a 682 compromised router to generate bogus measurement requests to 683 arbitrary target routers. Such bogus measurement requests may cause 684 processing overload in the routers in the network, drain their 685 batteries and cause traffic congestion in the network. Note that 686 some of these problems would occur even if the compromised router 687 were to generate bogus data traffic to arbitrary destinations. 689 Since a Measurement Request can travel along a source route specified 690 in the Address vector, some of the security concerns that led to the 691 deprecation of Type 0 routing header [RFC5095] may be valid here. To 692 address such concerns, the mechanism described in this document 693 includes several remedies: 695 o This document requires that a route inserted inside the Address 696 vector must be a strict source route and must not include any 697 multicast addresses. 699 o This document requires that an MO message must not cross the 700 boundaries of the RPL domain where it is originated. Hence, any 701 security problems associated with the mechanism would be limited 702 to the RPL domain where the MO message is generated. 704 o A router must drop a received MO message if the next hop address 705 is not on-link or if it is not a unicast address. 707 o A router must check the source route inside the Address vector of 708 each received MO message to ensure that it does not contain a loop 709 involving the router. The router must drop the received packet if 710 the source route does contain such a loop. This and the previous 711 rule protect the network against some of the security concerns 712 even if a compromised node inserts the Address vector inside the 713 MO message. 715 9. IANA Considerations 717 IANA is requested to allocate a new code point in the "RPL Control 718 Codes" registry for the "Measurement Object" described in this 719 document. 721 +------+---------------------------+---------------+ 722 | Code | Description | Reference | 723 +------+---------------------------+---------------+ 724 | 0x06 | Measurement Object | This document | 725 | 0x86 | Secure Measurement Object | This document | 726 +------+---------------------------+---------------+ 728 RPL Control Codes 730 10. Acknowledgements 732 Authors gratefully acknowledge the contributions of Pascal Thubert, 733 Richard Kelsey and Zach Shelby in the development of this document. 735 11. References 736 11.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 11.2. Informative References 743 [I-D.ietf-roll-p2p-rpl] 744 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie, 745 R., and J. Martocci, "Reactive Discovery of Point-to-Point 746 Routes in Low Power and Lossy Networks", 747 draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011. 749 [I-D.ietf-roll-routing-metrics] 750 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 751 Barthel, "Routing Metrics used for Path Calculation in Low 752 Power and Lossy Networks", 753 draft-ietf-roll-routing-metrics-19 (work in progress), 754 March 2011. 756 [I-D.ietf-roll-rpl] 757 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 758 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 759 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 760 Lossy Networks", draft-ietf-roll-rpl-19 (work in 761 progress), March 2011. 763 [I-D.ietf-roll-terminology] 764 Vasseur, J., "Terminology in Low power And Lossy 765 Networks", draft-ietf-roll-terminology-06 (work in 766 progress), September 2011. 768 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 769 of Type 0 Routing Headers in IPv6", RFC 5095, 770 December 2007. 772 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 773 Routing Requirements in Low-Power and Lossy Networks", 774 RFC 5826, April 2010. 776 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 777 "Building Automation Routing Requirements in Low-Power and 778 Lossy Networks", RFC 5867, June 2010. 780 Authors' Addresses 782 Mukul Goyal (editor) 783 University of Wisconsin Milwaukee 784 3200 N Cramer St 785 Milwaukee, WI 53211 786 USA 788 Phone: +1 414 2295001 789 Email: mukul@uwm.edu 791 Emmanuel Baccelli 792 INRIA 794 Phone: +33-169-335-511 795 Email: Emmanuel.Baccelli@inria.fr 796 URI: http://www.emmanuelbaccelli.org/ 798 Anders Brandt 799 Sigma Designs 800 Emdrupvej 26A, 1. 801 Copenhagen, Dk-2100 802 Denmark 804 Phone: +45 29609501 805 Email: abr@sdesigns.dk 807 Jerald Martocci 808 Johnson Controls 809 507 E Michigan Street 810 Milwaukee 53202 811 USA 813 Phone: +1 414 524 4010 814 Email: jerald.p.martocci@jci.com