idnits 2.17.1 draft-ietf-roll-p2p-measurement-05.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 (May 10, 2012) is 4367 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 427 == Missing Reference: 'Index' is mentioned on line 636, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-12 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: November 11, 2012 E. Baccelli 6 INRIA 7 A. Brandt 8 Sigma Designs 9 J. Martocci 10 Johnson Controls 11 May 10, 2012 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-05 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 November 11, 2012. 41 Copyright Notice 43 Copyright (c) 2012 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) . . . . . . . . . . . . . . . . . 5 62 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5 63 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Originating a Measurement Request . . . . . . . . . . . . . . 9 65 4.1. To Measure A Hop-by-hop Route with a Global 66 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2. To Measure A Hop-by-hop Route with a Local 68 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 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 . 14 72 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop 73 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6. Processing a Measurement Request at the Target . . . . . . . . 15 75 7. Processing a Measurement Reply at the Origin . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 [RFC6550], the IPv6 Routing 89 Protocol for LLNs, constrains the LLN topology to a Directed Acyclic 90 Graph (DAG) built to optimize the routing costs to reach the DAG's 91 root. The P2P routing functionality, available under RPL, has the 92 following key limitations: 94 o The P2P routes are restricted to use the DAG links only. Such P2P 95 routes may potentially be suboptimal and may lead to traffic 96 congestion near the DAG root. 98 o RPL is a proactive routing protocol and hence requires all P2P 99 routes to be established ahead of the time they are used. Many 100 LLN applications require the ability to establish P2P routes "on 101 demand". 103 To ameliorate situations, where the core RPL's P2P routing 104 functionality does not meet the application requirements, 105 [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. 106 P2P-RPL provides a reactive mechanism to discover P2P routes that 107 meet the specified routing constraints [RFC6551]. In some cases, the 108 application requirements or the LLN's topological features allow a 109 router to infer these routing constraints implicitly. For example, 110 the application may require the end-to-end loss rate and/or latency 111 along the route to be below certain thresholds or the LLN topology 112 may be such that a router can safely assume its destination to be 113 less than a certain number of hops away from itself. 115 When the existing routes are deemed unsatisfactory but the router 116 does not implicitly know the routing constraints to be used in P2P- 117 RPL route discovery, it may be necessary for the router to measure 118 the aggregated values of the routing metrics along the existing 119 route. This knowledge will allow the router to frame reasonable 120 routing constraints to discover a better route using P2P-RPL. For 121 example, if the router determines the aggregate ETX [RFC6551] along 122 an existing route to be "x", it can use "ETX < x*y", where y is a 123 certain fraction, as the routing constraint for use in P2P-RPL route 124 discovery. Note that it is important that the routing constraints 125 are not overly strict; otherwise the P2P-RPL route discovery may fail 126 even though a route, much better than the one currently being used, 127 exists. 129 This document specifies a mechanism that enables an RPL router to 130 measure the aggregated values of the routing metrics along an 131 existing route to another RPL router in an LLN, thereby allowing the 132 router to decide if it wants to discover a better route using P2P-RPL 133 and determine the routing constraints to be used for this purpose. 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 [RFC2119]. 142 Additionally, this document uses terminology from [RFC6550] and 143 [I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in 144 [I-D.ietf-roll-p2p-rpl], are redefined in the following manner. 146 Origin: The Origin refers to the RPL router that initiates the 147 measurement process defined in this document and is the start point 148 of the P2P route being measured. 150 Target: The Target refers to the RPL router at the end point of the 151 P2P route being measured. 153 Intermediate Router: An RPL router, other than the Origin and the 154 Target, on the P2P route being measured. 156 2. Overview 158 The mechanism described in this document can be used by an Origin in 159 an LLN to measure the aggregated values of some routing metrics along 160 a P2P route to a Target within the LLN. The route is measured in the 161 direction from the Origin to the Target. Such a route could be a 162 source route or a hop-by-hop route established using RPL [RFC6550] or 163 P2P-RPL [I-D.ietf-roll-p2p-rpl]. The Origin decides what metrics to 164 measure and sends a Measurement Request message, carrying the desired 165 routing metric objects, along the route. On receiving a Measurement 166 Request, an Intermediate Router updates the routing metric values 167 inside the message and forwards it to the next hop on the route. 168 Thus, the Measurement Request accumulates the values of the routing 169 metrics for the complete route as it travels towards the Target. 170 Upon receiving the Measurement Request, the Target unicasts a 171 Measurement Reply message, carrying the accumulated values of the 172 routing metrics, back to the Origin. Optionally, the Origin may 173 allow an Intermediate Router to generate the Measurement Reply if it 174 already knows the relevant routing metric values along rest of the 175 route. 177 3. The Measurement Object (MO) 179 This document defines two new RPL Control Message types, the 180 Measurement Object (MO), with code 0x06 (to be confirmed by IANA), 181 and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO 182 serves as both Measurement Request and Measurement Reply. 184 3.1. Format of the base MO 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | Origin Address | 193 | | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 | Target Address | 198 | | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 . Address[1..Num] . 203 . . 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 . Metric Container Option(s) . 208 . . 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: Format of the base Measurement Object (MO) 214 The format of a base MO is shown in Figure 1. A base MO consists of 215 the following fields: 217 o RPLInstanceID: This field is relevant only if a hop-by-hop route 218 is being measured, i.e., the H flag, described subsequently, is 219 set to one. In this case, the Origin MUST set this field to the 220 RPLInstanceID of the hop-by-hop route being measured. If a source 221 route is being measured, the Origin MUST set this field to binary 222 value 10000000. An Intermediate Router MUST set the RPLInstanceID 223 field in the outgoing MO packet to the same value that it had in 224 the corresponding incoming MO packet unless it is the root of a 225 non-storing global DAG, identified by the RPLInstanceID, along 226 which the MO packet had been traveling so far and the router 227 intends to insert a source route inside the Address vector to 228 direct it towards the Target. In that case, the router MUST set 229 the RPLInstanceID field in the outgoing MO packet to binary value 230 10000000. 232 o Compr: In many LLN deployments, IPv6 addresses share a well known, 233 common prefix. In such cases, the common prefix can be elided 234 when specifying IPv6 addresses in the Origin/Target Address fields 235 and the Address vector. The "Compr" field, a 4-bit unsigned 236 integer, is set by the Origin to specify the number of prefix 237 octets that are elided from the IPv6 addresses in Origin/Target 238 Address fields and the Address vector. An Intermediate Router 239 MUST set the Compr field in the outgoing MO packet to the same 240 value that it had in the corresponding incoming MO packet. The 241 Intermediate Router MUST drop the received MO message if the Compr 242 value specified in the message does not match what the router 243 considers the length of the common prefix to be. The Origin will 244 set the Compr value to zero if full IPv6 addresses are to be 245 carried in the Origin Address/Target Address fields and the 246 Address vector. 248 o Type (T): This flag is set to one if the MO represents a 249 Measurement Request. The flag is set to zero if the MO is a 250 Measurement Reply. 252 o Hop-by-hop (H): The Origin MUST set this flag to one if the route 253 being measured is a hop-by-hop route. In that case, the hop-by- 254 hop route is identified by the RPLInstanceID and, if the 255 RPLInstanceID is a local value, the Origin Address and Target 256 Address fields inside the message. The Origin MUST set this flag 257 to zero if the route being measured is a source route specified in 258 the Address vector. An Intermediate Router MUST set the H flag in 259 an outgoing MO packet to the same value that it had in the 260 corresponding incoming MO packet unless the router is the root of 261 the non-storing global DAG, identified by the RPLInstanceID, along 262 which the MO packet had been traveling so far and the router 263 intends to insert a source route inside the Address vector to 264 direct it towards the Target. In that case, the router MUST reset 265 the H flag to zero in the outgoing MO packet. 267 o Accumulate Route (A): This flag is relevant only if the MO 268 represents a Measurement Request that travels along a hop-by-hop 269 route represented by a local RPLInstanceID. In other words, this 270 flag MAY be set to one only if T = 1, H = 1 and the RPLInstanceID 271 field has a local value. Otherwise, this flag MUST be set to 272 zero. A value 1 in this flag indicates that the Measurement 273 Request MUST accumulate a source route for use by the Target to 274 send the Measurement Reply back to the Origin. In this case, an 275 Intermediate Router MUST add its unicast IPv6 address (after 276 eliding Compr number of prefix octets) to the Address vector in 277 the manner specified later. Route accumulation is not allowed 278 when the Measurement Request travels along a hop-by-hop route with 279 a global RPLInstanceID, i.e., along a global DAG, because: 281 * The DAG's root may need the Address vector to insert a source 282 route to the Target; and 284 * The Target can presumably reach the Origin along this global 285 DAG. 287 o Reverse (R): This flag is relevant only if the MO represents a 288 Measurement Request that travels along a source route, specified 289 in the Address vector, to the Target. In other words, this flag 290 MAY be set to one only if T = 1 and H = 0. Otherwise, this flag 291 MUST be set to zero. A value 1 in the flag indicates that the 292 Address vector contains a complete source route from the Origin to 293 the Target, which can be used, after reversal, by the Target to 294 source route the Measurement Reply message back to the Origin. 296 o Back Request (B): This flag serves as a request to the Target to 297 send a Measurement Request towards the Origin. The Origin MAY set 298 this flag to one to make such a request to the Target. An 299 Intermediate Router MUST set the B flag in an outgoing MO packet 300 to the same value that it had in the corresponding incoming MO 301 packet. On receiving a Measurement Request with the B flag set to 302 one, the Target SHOULD generate a Measurement Request to measure 303 the cost of its current (or the most preferred) route to the 304 Origin. Receipt of this Measurement Request would allow the 305 Origin to know the cost of the back route from the Target to 306 itself and thus determine the round-trip cost of reaching the 307 Target. 309 o Intermediate Reply (I): Relevant only if a hop-by-hop route is 310 being measured, this flag serves as a permission to an 311 Intermediate Router to generate a Measurement Reply if it knows 312 the cost of the rest of the route being measured. The Origin MAY 313 set this flag to one if a hop-by-hop route is being measured 314 (i.e., H = 1) and the Origin wants to allow an Intermediate Router 315 to generate the Measurement Reply in response to this Measurement 316 Request. Setting this flag to one may be useful in scenarios 317 where the Hop Count [RFC6551] is the routing metric of interest 318 and the Origin expects an Intermediate Router (e.g. the root of a 319 non-storing DAG or a common ancestor of the Origin and the Target 320 in a storing DAG) to know the Hop Count of the remainder of the 321 route to the Target. This flag MUST be set to zero if the route 322 being measured is a source route (i.e., H = 0). 324 o SequenceNo: A 6-bit sequence number, assigned by the Origin, that 325 allows the Origin to uniquely identify a Measurement Request and 326 the corresponding Measurement Reply. An Intermediate Router MUST 327 set this field in the outgoing MO packet to the same value that it 328 had in the corresponding incoming MO packet. The Target MUST set 329 this field in a Measurement Reply message to the same value that 330 it had in the corresponding Measurement Request message. 332 o Num: This field indicates the number of elements, each (16 - 333 Compr) octets in size, inside the Address vector. If the value of 334 this field is zero, the Address vector is not present in the MO. 336 o Index: If the Measurement Request is traveling along a source 337 route contained in the Address vector (T=1,H=0), this field 338 indicates the index in the Address vector of the next hop on the 339 route. If the Measurement Request is traveling along a hop-by-hop 340 route with a local RPLInstanceID and the A flag is set 341 (T=1,H=1,A=1 and RPLInstanceID field has a local value), this 342 field indicates the index in the Address vector where an 343 Intermediate Router receiving the MO message must store its IPv6 344 address. Otherwise, this field MUST be set to zero on 345 transmission and ignored on reception. 347 o Origin Address: A unicast IPv6 address of the Origin after eliding 348 Compr number of prefix octets. If the MO is traveling along a 349 hop-by-hop route and the RPLInstanceID field indicates a local 350 value, the Origin Address field MUST specify the DODAGID value 351 that, along with the RPLInstanceID and the Target Address, 352 uniquely identifies the hop-by-hop route being measured. 354 o Target Address: A unicast IPv6 address of the Target after eliding 355 Compr number of prefix octets. 357 o Address[1..Num]: A vector of unicast IPv6 addresses (with Compr 358 number of prefix octets elided) representing a source route to the 359 Target: 361 * Each element in the vector has size (16 - Compr) octets. 363 * The total number of elements inside the Address vector is given 364 by the Num field. 366 * When the Measurement Request is traveling along a hop-by-hop 367 route with local RPLInstanceID and has the A flag set, the 368 Address vector is used to accumulate a source route to be used 369 by the Target to send the Measurement Reply back to the Origin. 370 In this case, the route MUST be accumulated in the forward 371 direction, i.e., from the Origin to the Target. The Target 372 router would reverse this route to obtain a source route from 373 itself to the Origin. The IPv6 addresses in the accumulated 374 route MUST be reachable in the backward direction, i.e., from 375 the Target to the Origin. An Intermediate Router adding its 376 address to the Address vector MUST ensure that its address does 377 not already exist in the vector. 379 * When the Measurement Request is traveling along a source route, 380 the Address vector MUST contain a complete route to the Target 381 and the IPv6 addresses in the Address vector MUST be reachable 382 in the forward direction, i.e., from the Origin to the Target. 383 A router (Origin or an Intermediate Router) inserting an 384 Address vector inside an MO MUST ensure that no address appears 385 more than once inside the vector. Each router on the way MUST 386 ensure that the loops do not exist within the source route. 387 The Origin MAY set the R flag in the MO if the route in the 388 Address vector represents a complete route from the Origin to 389 the Target and this route can be used after reversal by the 390 Target to send the Measurement Reply message back to the Origin 391 (i.e., the IPv6 addresses in the Address vector are reachable 392 in the backward direction - from the Target to the Origin). 394 * The Origin and Target addresses MUST NOT be included in the 395 Address vector. 397 * The Address vector MUST NOT contain any multicast addresses. 399 o Metric Container Options: An MO MUST contain one or more Metric 400 Container options to accumulate the routing metric values for the 401 route being measured. 403 3.2. Secure MO 405 A Secure MO message follows the format in Figure 7 of [RFC6550], 406 where the base format is the base MO shown in Figure 1. 408 4. Originating a Measurement Request 410 If an Origin needs to measure the routing metric values along a P2P 411 route towards a Target, it generates an MO message and sets its 412 fields as described in Section 3.1. The setting of MO fields in 413 specific cases is described below. In all cases, the Origin MUST set 414 the T flag to one to indicate that the MO represents a Measurement 415 Request. The Origin MUST also include the routing metric objects of 416 interest inside one or more Metric Container options inside the MO. 417 Depending on the metrics being measured, the Origin must also 418 initiate these routing metric objects by including the values of the 419 routing metrics for the first hop on the P2P route being measured. 421 After setting the MO fields appropriately, the Origin determines the 422 next hop on the P2P route being measured. If a hop-by-hop route is 423 being measured (i.e., the H flag is set to one), the next hop is 424 determined using the RPLInstanceID, the Target Address and, if 425 RPLInstanceID is a local value, the Origin Address fields in the MO. 426 If a source route is being measured (i.e., the H flag is set to 427 zero), the Address[1] element contains the next hop address. 429 The Origin MUST discard the MO message if: 431 o the next hop address is not a unicast address; or 433 o the next hop is not on-link; or 435 o the next hop is not in the same RPL routing domain as the Origin. 437 Otherwise, the Origin MUST unicast the MO message to the next hop on 438 the P2P route. 440 4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID 442 If a hop-by-hop route with a global RPLInstanceID is being measured, 443 the MO message MUST NOT contain the Address vector and the following 444 MO fields MUST be set in the manner specified below: 446 o Hop-by-hop (H): This flag MUST be set to one. 448 o Accumulate Route (A): This flag MUST be set to zero. 450 o Reverse (R): This flag MUST be set to zero. 452 o Num: This field MUST be set to zero. 454 o Index: This field MUST be set to zero. 456 4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID 458 If a hop-by-hop route with a local RPLInstanceID is being measured 459 and the MO is not accumulating a source route for the Target's use, 460 the MO message MUST NOT contain the Address vector and the following 461 MO fields MUST be set in the manner specified below: 463 o Hop-by-hop (H): This flag MUST be set to one. 465 o Accumulate Route (A): This flag MUST be set to zero. 467 o Reverse (R): This flag MUST be set to zero. 469 o Num: This field MUST be set to zero. 471 o Index: This field MUST be set to zero. 473 o Origin Address: This field MUST contain the DODAGID value (after 474 eliding Compr number of prefix octets) associated with the route 475 being measured. 477 If a hop-by-hop route with a local RPLInstanceID is being measured 478 and the Origin desires the MO to accumulate a source route for the 479 Target to send the Measurement Reply message back, it MUST set the 480 following MO fields in the manner specified below: 482 o Hop-by-hop (H): This flag MUST be set to one. 484 o Accumulate Route (A): This flag MUST be set to one. 486 o Reverse (R): This flag MUST be set to zero. 488 o Intermediate Reply (I): This flag MUST be set to zero. 490 o Address vector: The Address vector must be large enough to 491 accomodate a complete source route from the Origin to the Target. 492 All the bits in the Address vector field MUST be set to zero. 494 o Num: This field MUST specify the number of address elements that 495 can fit inside the Address vector. 497 o Index: This field MUST be set to one. 499 o Origin Address: This field MUST contain the DODAGID value (after 500 eliding Compr number of prefix octets) associated with the route 501 being measured. 503 4.3. To Measure A Source Route 505 If a source route is being measured, the Origin MUST set the 506 following MO fields in the manner specified below: 508 o Hop-by-hop (H): This flag MUST be set to zero. 510 o Accumulate Route (A): This flag MUST be set to zero. 512 o Reverse (R): This flag SHOULD be set to one if the source route in 513 the Address vector can be reversed and used by the Target to 514 source route the Measurement Reply message back to the Origin. 515 Otherwise, this flag MUST be set to zero. 517 o Intermediate Reply (I): This flag MUST be set to zero. 519 o Address vector: 521 * The Address vector MUST contain a complete route from the 522 Origin to the Target (excluding the Origin and the Target). 524 * The IPv6 addresses (with Compr prefix octets elided) in the 525 Address vector MUST be reachable in the forward direction, 526 i.e., from the Origin to the Target. 528 * If the R flag is set to one, the IPv6 addresses (with Compr 529 prefix octets elided) in the Address vector MUST also be 530 reachable in the backward direction, i.e., from the Target to 531 the Origin. 533 * To prevent loops in the source route, the Origin MUST ensure 534 compliance to the following rules: 536 + Any IPv6 address MUST NOT appear more than once in the 537 Address vector. 539 + If the Address vector includes multiple IPv6 addresses 540 assigned to the Origin's interfaces, such addresses MUST 541 appear back to back inside the Address vector. 543 * Each address appearing in the Address vector MUST be a unicast 544 address. 546 o Num: This field MUST be set to indicate the number of elements in 547 the Address vector. 549 o Index: This field MUST be set to one. 551 5. Processing a Measurement Request at an Intermediate Router 553 A router (an Intermediate Router or the Target) MAY discard a 554 received MO with no processing to meet any policy-related goal. Such 555 policy goals may include the need to reduce the router's CPU load or 556 to enhance its battery life. 558 A router MUST discard a received MO with no further processing if the 559 Compr field inside the received message is not same as what the 560 router considers the length of the common prefix used in IPv6 561 addresses in the LLN to be. 563 On receiving an MO, if a router chooses to process the packet 564 further, it MUST check if one of its IPv6 addresses is listed as 565 either the Origin or the Target Address. If neither, the router 566 considers itself an Intermediate Router and MUST process the received 567 MO in the following manner. 569 An Intermediate Router MUST discard the packet with no further 570 processing if the received MO is not a Measurement Request. 572 If the H and I flags are set to one in the received MO and the 573 Intermediate Router knows the values of the routing metrics, 574 specified in the Metric Container, for the remainder of the route, it 575 MAY generate a Measurement Reply on the Target's behalf in the manner 576 specified in Section 6 (after including in the Measurement Reply the 577 relevant routing metric values for the complete route being 578 measured). Otherwise, the Intermediate Router MUST process the 579 received MO in the following manner. 581 The router MUST determine the next hop on the P2P route being 582 measured in the manner described below. The router MUST drop the MO 583 with no further processing and MAY send an ICMPv6 Destination 584 Unreachable (with Code 0 - No Route To Destination) error message to 585 the source of the message if it can not determine the next hop for 586 the message. The router MUST drop the MO with no further processing: 588 o If the next hop address is not a unicast address; or 590 o If the next hop is not on-link; or 592 o If the next hop is not in the same RPL routing domain as the 593 router. 595 Next, the router MUST update the routing metric objects, contained in 596 the Metric Container option(s) inside the MO, either by updating the 597 aggregated value for the routing metric or by attaching the local 598 values for the metric inside the object. An Intermediate Router can 599 only update the existing metric objects and MUST NOT add any new 600 routing metric object to the Metric Container. An Intermediate 601 Router MUST drop the MO if it cannot update a routing metric object 602 specified inside the Metric Container. 604 After updating the routing metrics, the router MUST unicast the MO to 605 the next hop. 607 5.1. Determining Next Hop For An MO Measuring A Source Route 609 In case the received MO is measuring a source route (H=0), 611 o The router MUST verify that the Address[Index] element lists one 612 of its unicast IPv6 addresses, failing which the router MUST 613 discard the MO packet with no further processing; 615 o The router MUST then increment the Index field and use the 616 Address[Index] element as the next hop. If Index is greater than 617 Num, the router MUST use the Target Address as the next hop. 619 To prevent loops, an Intermediate Router MUST discard the MO packet 620 with no further processing if the Address vector includes multiple 621 IPv6 addresses assigned to the router's interfaces and if such 622 addresses do not appear back to back inside the Address vector. 624 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route 626 If the received MO is measuring a hop-by-hop route (H=1), the router 627 MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID 628 is a local value, the Origin Address to determine the next hop for 629 the MO. Moreover, 631 o If the RPLInstanceID of the hop-by-hop route is a local value and 632 the A flag is set, the router MUST check if the Address vector 633 already contains one of its IPv6 addresses. If yes, the router 634 MUST discard the packet with no further processing. Otherwise, 635 the router MUST store one of its IPv6 addresses (after eliding 636 Compr prefix octets) at location Address[Index] and then increment 637 the Index field. 639 o If the router is the root of the non-storing global DAG along 640 which the received MO message had been traveling so far, 642 * The router discards the MO packet with no further processing if 643 it does not know of a source route to reach the Target 644 (specified by the Target Address listed in the packet). 646 * Otherwise, the router MUST do the following: 648 + Set the H, A and R flags to zero and the RPLInstanceID field 649 to binary value 10000000. 651 + Remove any existing Address vector inside the MO. 653 + Insert a new Address vector inside the MO and specify a 654 source route to the Target inside the Address vector as per 655 the following rules: 657 - The Address vector MUST contain a complete route from the 658 router to the Target (excluding the router and the 659 Target); 661 - The IPv6 addresses (with Compr prefix octets elided) in 662 the Address vector MUST be reachable in the forward 663 direction, i.e., towards the Target; 665 - To prevent loops in the source route, the router MUST 666 ensure that 668 o Any IPv6 address MUST NOT appear more than once in the 669 Address vector; 671 o If the Address vector includes multiple IPv6 addresses 672 assigned to the router's interfaces, such addresses 673 MUST appear back to back inside the Address vector. 675 - Each address appearing in the Address vector MUST be a 676 unicast address. 678 + Specify in the Num field the number of address elements in 679 the Address vector. 681 + Set the Index field to one. 683 6. Processing a Measurement Request at the Target 685 On receiving an MO, if a router chooses to process the packet further 686 and finds one of its unicast IPv6 addresses listed as the Target 687 Address, the router considers itself the Target and MUST process the 688 received MO in the following manner. 690 The Target MUST discard the packet with no further processing if the 691 received MO is not a Measurement Request. 693 The Target MUST update the routing metric objects in the Metric 694 Container options if required and MAY note the measured values for 695 the complete route (especially, if the received Measurement Request 696 is likely a response to an earlier Measurement Request that the 697 Target had sent to the Origin with B flag set to one). 699 The Target MUST generate a Measurement Reply message. The 700 Measurement Reply message MUST have the same SequenceNo field as the 701 received Measurement Request message. The received Measurement 702 Request message can be trivially converted into the Measurement Reply 703 by setting the T flag to zero. The Target MAY remove the Address 704 vector from the Measurement Reply if desired. The Target MUST then 705 unicast the Measurement Reply back to the Origin: 707 o If the Measurement Request traveled along a global DAG (i.e., one 708 with a global RPLInstanceID), the Measurement Reply MAY be unicast 709 back to the Origin along the same DAG. 711 o If the Measurement Request traveled along a hop-by-hop route with 712 a local RPLInstanceID and the A flag inside the received message 713 is set to one, the Target MAY reverse the source route contained 714 in the Address vector and use it to send the Measurement Reply 715 back to the Origin. 717 o If the Measurement Request traveled along a source route and the R 718 flag inside the received message is set to one, the Target MAY 719 reverse the source route contained in the Address vector and use 720 it to send the Measurement Reply back to the Origin. 722 If the B flag in the received Measurement Request is set to one, the 723 Target SHOULD generate a new Measurement Request to measure the cost 724 of its current (or the most preferred) route to the Origin. The 725 routing metrics used in the new Measurement Request MUST include the 726 routing metrics specified in the received Measurement Request. 728 7. Processing a Measurement Reply at the Origin 730 When a router receives an MO, it examines if one of its unicast IPv6 731 addresses is listed as the Origin Address. If yes, the router is the 732 Origin and MUST process the received message in the following manner. 734 The Origin MUST discard the packet with no further processing if the 735 received MO is not a Measurement Reply or if the Origin has no 736 recollection of sending a Measurement Request with the sequence 737 number listed in the received MO. 739 The Origin MUST examine the routing metric objects inside the Metric 740 Container options to evaluate the quality of the measured P2P route. 741 If a routing metric object contains local metric values recorded by 742 routers on the route, the Origin MUST aggregate these local values 743 into an end-to-end value as per the aggregation rules for the metric. 745 8. Security Considerations 747 The mechanism defined in this document can potentially be used by a 748 compromised router to generate bogus Measurement Requests to 749 arbitrary Target routers. Such Measurement Requests may cause CPU 750 overload in the routers in the network, drain their batteries and 751 cause traffic congestion in the network. Note that some of these 752 problems would occur even if the compromised router were to generate 753 bogus data traffic to arbitrary destinations. 755 Since a Measurement Request can travel along a source route specified 756 in the Address vector, some of the security concerns that led to the 757 deprecation of Type 0 routing header [RFC5095] may be valid here. To 758 address such concerns, the mechanism described in this document 759 includes several remedies: 761 o This document requires that a route inserted inside the Address 762 vector must be a strict source route and must not include any 763 multicast addresses. 765 o This document requires that an MO message must not cross the 766 boundaries of the RPL routing domain where it originated. A 767 router must not forward a received MO message further if the next 768 hop belongs to a different RPL routing domain. Hence, any 769 security problems associated with the mechanism would be limited 770 to one RPL routing domain. 772 o This document requires that a router must drop a received MO 773 message if the next hop address is not on-link or if it is not a 774 unicast address. 776 o This document requires that a router must check the source route 777 inside the Address vector of each received MO message to ensure 778 that it does not contain a loop involving the router. The router 779 must drop the received packet if the source route does contain 780 such a loop. This and the previous two rules protect the network 781 against some of the security concerns even if a compromised node 782 inserts a malformed Address vector inside the MO message. 784 9. IANA Considerations 786 This document defines two new RPL messages: 788 o "Measurement Object" (see Section 3.1), assigned a value of 0x06 789 from the "RPL Control Codes" space [to be removed upon 790 publication: 791 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 792 [RFC6550]. 794 o "Secure Measurement Object" (see Section 3.2), assigned a value of 795 0x86 from the "RPL Control Codes" space [to be removed upon 796 publication: 797 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 798 [RFC6550]. 800 +------+---------------------------+---------------+ 801 | Code | Description | Reference | 802 +------+---------------------------+---------------+ 803 | 0x06 | Measurement Object | This document | 804 | 0x86 | Secure Measurement Object | This document | 805 +------+---------------------------+---------------+ 807 RPL Control Codes 809 10. Acknowledgements 811 Authors gratefully acknowledge the contributions of Matthias Philipp, 812 Pascal Thubert, Richard Kelsey and Zach Shelby in the development of 813 this document. 815 11. References 817 11.1. Normative References 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 11.2. Informative References 824 [I-D.ietf-roll-p2p-rpl] 825 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 826 Martocci, "Reactive Discovery of Point-to-Point Routes in 827 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-12 828 (work in progress), May 2012. 830 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 831 of Type 0 Routing Headers in IPv6", RFC 5095, 832 December 2007. 834 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 835 Routing Requirements in Low-Power and Lossy Networks", 836 RFC 5826, April 2010. 838 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 839 "Building Automation Routing Requirements in Low-Power and 840 Lossy Networks", RFC 5867, June 2010. 842 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 843 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 844 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 845 Lossy Networks", RFC 6550, March 2012. 847 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 848 Barthel, "Routing Metrics Used for Path Calculation in 849 Low-Power and Lossy Networks", RFC 6551, March 2012. 851 Authors' Addresses 853 Mukul Goyal (editor) 854 University of Wisconsin Milwaukee 855 3200 N Cramer St 856 Milwaukee, WI 53211 857 USA 859 Phone: +1 414 2295001 860 Email: mukul@uwm.edu 862 Emmanuel Baccelli 863 INRIA 865 Phone: +33-169-335-511 866 Email: Emmanuel.Baccelli@inria.fr 867 URI: http://www.emmanuelbaccelli.org/ 869 Anders Brandt 870 Sigma Designs 871 Emdrupvej 26A, 1. 872 Copenhagen, Dk-2100 873 Denmark 875 Phone: +45 29609501 876 Email: abr@sdesigns.dk 877 Jerald Martocci 878 Johnson Controls 879 507 E Michigan Street 880 Milwaukee 53202 881 USA 883 Phone: +1 414 524 4010 884 Email: jerald.p.martocci@jci.com