idnits 2.17.1 draft-ietf-roll-p2p-measurement-08.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 (January 21, 2013) is 4112 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 922 == Missing Reference: 'Index' is mentioned on line 870, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-15 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: July 25, 2013 E. Baccelli 6 INRIA 7 A. Brandt 8 Sigma Designs 9 J. Martocci 10 Johnson Controls 11 January 21, 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-08 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 in a low power and lossy 22 network, thereby allowing the router to decide if it wants to 23 initiate the discovery of a better 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 July 25, 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 . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. When Measuring A Hop-by-hop Route with a Local 69 RPLInstanceID With Route Accumulation Off . . . . . . . . 12 70 4.3. When Measuring A Hop-by-hop Route with a Local 71 RPLInstanceID With Route Accumulation On . . . . . . . . . 13 72 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14 73 5. Processing a Measurement Request at an Intermediate Point . . 15 74 5.1. When Measuring A Hop-by-hop Route with a Global 75 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 16 76 5.2. When Measuring A Hop-by-hop Route with a Local 77 RPLInstanceID With Route Accumulation Off . . . . . . . . 17 78 5.3. When Measuring A Hop-by-hop Route with a Local 79 RPLInstanceID With Route Accumulation On . . . . . . . . . 18 80 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19 81 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 19 82 6. Processing a Measurement Request at the End Point . . . . . . 20 83 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 20 84 7. Processing a Measurement Reply at the Start Point . . . . . . 21 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 [RFC6551] along 131 an existing route to be "x", it can use "ETX < x*y", where y is a 132 certain fraction, as the routing constraint for use in P2P-RPL route 133 discovery. Note that it is important that the routing constraints 134 are not overly strict; otherwise the P2P-RPL route discovery may fail 135 even though a route, much better than the one currently being used, 136 exists. 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. As more operational experience is gained 147 using P2P-RPL, it is hoped that the mechanism described in this 148 document will also be used, and feedback will be provided to the ROLL 149 working group on the utility and benefits of this document. 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 Backward 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 (required to be same as the 306 DODAGID of the route being measured) fields inside the Measurement 307 Request. The Start Point MUST set this flag to zero if the route 308 being measured is a Source Route specified in the Address vector. 309 An Intermediate Point MUST set the H flag in an outgoing 310 Measurement Request to the same value that it had in the 311 corresponding incoming Measurement Request unless it is the root 312 of the non-storing global DAG, identified by the RPLInstanceID, 313 along which the Measurement Request had been traveling so far and 314 the Intermediate Point intends to insert a Source Route inside the 315 Address vector to direct it towards the End Point. In that case, 316 the Intermediate Point MUST set the H flag to zero. 318 o Accumulate Route (A): A value 1 in this flag indicates that the 319 Measurement Request is accumulating a Source Route for use by the 320 End Point to send the Measurement Reply back to the Start Point. 321 Route accumulation is allowed (i.e., this flag MAY be set to one) 322 inside a Measurement Request only if it travels along a Hop-by-hop 323 Route represented by a local RPLInstanceID (i.e., H = 1, 324 RPLInstanceID has a local value). In this case, an Intermediate 325 Point adds its unicast IPv6 address (after eliding Compr number of 326 prefix octets) to the Address vector in the manner specified in 327 Section 5.3. In other cases, this flag MUST be set to zero on 328 transmission and ignored on reception. Route accumulation is not 329 allowed when the Measurement Request travels along a Hop-by-hop 330 Route with a global RPLInstanceID, i.e., along a global DAG, 331 because: 333 * The DAG's root may need the Address vector to insert a Source 334 Route to the End Point; and 336 * The End Point can presumably reach the Start Point along this 337 global DAG (identified by the RPLInstanceID field). 339 o Reverse (R): A value 1 in this flag inside a Measurement Request 340 indicates that the Address vector contains a complete Source Route 341 from the Start Point to the End Point, which can be used, after 342 reversal, by the End Point to send the Measurement Reply back to 343 the Start Point. This flag MAY be set to one inside a Measurement 344 Request only if a Source Route, from the Start Point to the End 345 Point, is being measured. Otherwise, this flag MUST be set to 346 zero on transmission and ignored on reception. 348 o Back Request (B): A value 1 in this flag serves as a request to 349 the End Point to send a Measurement Request towards the Start 350 Point. On receiving a Measurement Request with the B flag set to 351 one, the End Point SHOULD generate a Measurement Request to 352 measure the cost of its current (or the most preferred) route to 353 the Start Point. Receipt of this Measurement Request would allow 354 the Start Point to know the cost of the back route from the End 355 Point to itself and thus determine the round-trip cost of reaching 356 the End Point. 358 o Intermediate Reply (I): A value 1 in this flag serves as a 359 permission to an Intermediate Point to generate a Measurement 360 Reply if it knows the aggregated values of the routing metrics 361 being measured for the rest of the route. Setting this flag to 362 one may be useful in scenarios where the Hop Count [RFC6551] is 363 the routing metric of interest and an Intermediate Point (e.g. the 364 root of a non-storing global DAG or a common ancestor of the Start 365 Point and the End Point in a storing global DAG) may know the Hop 366 Count of the remainder of the route to the End Point. This flag 367 MAY be set to one only if a Hop-by-hop Route with a global 368 RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a 369 global value). Otherwise, this flag MUST be set to zero on 370 transmission and ignored on reception. 372 o SequenceNo: A 6-bit sequence number, assigned by the Start Point, 373 that allows the Start Point to uniquely identify a Measurement 374 Request and the corresponding Measurement Reply. 376 o Num: This field indicates the number of elements, each (16 - 377 Compr) octets in size, inside the Address vector. If the value of 378 this field is zero, the Address vector is not present in the MO. 380 o Index: If the Measurement Request is traveling along a Source 381 Route contained in the Address vector (i.e., H = 0), this field 382 indicates the index in the Address vector of the next hop on the 383 route. If the Measurement Request is traveling along a Hop-by-hop 384 Route with a local RPLInstanceID and the Route Accumulation is on 385 (i.e., H = 1, RPLInstanceID has a local value, A = 1), this field 386 indicates the index in the Address vector where an Intermediate 387 Point receiving the Measurement Request must store its IPv6 388 address. Otherwise, this field MUST be set to zero on 389 transmission and ignored on reception. 391 o Start Point Address: A unicast IPv6 address of the Start Point 392 after eliding Compr number of prefix octets. If the Measurement 393 Request is traveling along a Hop-by-hop Route and the 394 RPLInstanceID field indicates a local value, the Start Point 395 Address field MUST specify the DODAGID value that, along with the 396 RPLInstanceID and the End Point Address, uniquely identifies the 397 Hop-by-hop Route being measured. 399 o End Point Address: A unicast IPv6 address of the End Point after 400 eliding Compr number of prefix octets. 402 o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr 403 number of prefix octets elided) representing a Source Route: 405 * Each element in the vector has size (16 - Compr) octets. 407 * The total number of elements inside the Address vector is given 408 by the Num field. 410 * The Start Point and End Point addresses MUST NOT be included in 411 the Address vector. 413 * The Address vector MUST NOT contain any multicast addresses. 415 * If the Start Point wants to measure a Hop-by-hop Route with a 416 local RPLInstanceID and accumulate a Source Route for the End 417 Point's use (i.e., the Measurement Request has the H flag set 418 to 1, RPLInstanceID set to a local value and the A flag set to 419 1), it MUST include a suitably-sized Address vector in the 420 Measurement Request. As the Measurement Request travels over 421 the route being measured, the Address vector accumulates a 422 Source Route that can be used by the End Point, after reversal, 423 to reach (and, in particular, to send the Measurement Reply 424 back to) the Start Point. The route MUST be accumulated in the 425 Forward direction but the IPv6 addresses in the accumulated 426 route MUST be reachable in the Backward direction. An 427 Intermediate Point adding its address to the Address vector 428 MUST NOT modify the size of the Address vector. 430 * If the Start Point wants to measure a Source Route, it MUST 431 include an Address vector, containing the route being measured, 432 inside the Measurement Request. Similarly, if the Measurement 433 Request had been traveling along a global non-storing DAG so 434 far, the root of this DAG may insert an Address vector, 435 containing a Source Route from itself to the End Point, inside 436 the Measurement Request. In both cases, the Source Route 437 inside the Address vector MUST consist of IPv6 addresses 438 reachable in the Forward direction. Further, in both cases, an 439 Intermediate Point MUST NOT modify the contents of the existing 440 Address vector before forwarding the Measurement Request 441 further. In other words, an Intermediate Point MUST NOT modify 442 the Source Route along which the Measurement Request is 443 currently traveling. The Start Point MAY set the R flag in the 444 Measurement Request to one if the Source Route inside the 445 Address vector can be used by the End Point, after reversal, to 446 reach (and, in particular, to send the Measurement Reply back 447 to) the Start Point. In other words, the Start Point MAY set 448 the R flag to one only if all the IPv6 addresses in the Address 449 vector are reachable in the Backward direction. 451 o Metric Container Options: A Measurement Request MUST contain one 452 or more Metric Container options [RFC6550] to accumulate the 453 values of the selected routing metrics in the manner described in 454 [RFC6551] for the route being measured. 456 Section 4 describes how does a Start Point set various fields inside 457 a Measurement Request in different cases. Section 5 describes how 458 does an Intermediate Point process a received Measurement Request 459 before forwarding it further. Section 6 describes how does the End 460 Point process a received Measurement Request and generate a 461 Measurement Reply. Finally, Section 7 describes how does the Start 462 Point process a received Measurement Reply. In the following 463 discussion, any reference to discarding a received Measurement 464 Request/Reply with "no further processing" does not preclude updating 465 the appropriate error counters or any similar actions. 467 3.2. Secure MO 469 A Secure MO follows the format in Figure 7 of [RFC6550], where the 470 base format is the base MO shown in Figure 1. 472 4. Originating a Measurement Request 474 A Start Point sets various fields inside the Measurement Request it 475 generates in the manner described below. The Start Point MUST also 476 include the routing metric objects [RFC6551] of interest inside one 477 or more Metric Container options inside the Measurement Request. The 478 Start Point then determines the next hop on the route being measured. 479 If a Hop-by-hop route is being measured (i.e., H = 1), the next hop 480 is determined using the RPLInstanceID, the End Point Address and, if 481 RPLInstanceID is a local value, the Start Point Address fields in the 482 Measurement Request. If a Source Route is being measured (i.e., H = 483 0), the Address[0] element inside the Measurement Request contains 484 the next hop address. The Start Point MUST discard the Measurement 485 Request if: 487 o the next hop address is not a unicast address; or 489 o the next hop is not on-link; or 491 o the next hop is not in the same RPL routing domain as the Start 492 Point. 494 Otherwise, depending on the routing metrics, the Start Point must 495 initiate the routing metric objects inside the Metric Container 496 options by including the routing metric values for the first hop on 497 the route being measured. Finally, the Start Point MUST unicast the 498 Measurement Request to the next hop on the route being measured. 500 4.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 502 If a Hop-by-hop Route with a global RPLInstanceID is being measured 503 (i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT 504 contain an Address vector and various MO fields MUST be set in the 505 following manner: 507 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 508 measured. 510 o Compr: MUST be set to specify the number of prefix octets that are 511 elided from the IPv6 addresses in Start Point/End Point Address 512 fields. 514 o Type (T): MUST be set to one since the MO represents a Measurement 515 Request. 517 o Hop-by-hop (H): MUST be set to one. 519 o Accumulate Route (A): This flag MUST be set to zero. 521 o Reverse (R): This flag MUST be set to zero. 523 o Back Request (B): This flag MAY be set to one to request the End 524 Point to send a Measurement Request to the Start Point. 526 o Intermediate Reply (I): This flag MAY be set to one if the Start 527 Point expects an Intermediate Point to know the values of the 528 routing metrics being measured for the remainder of the route. 530 o SequenceNo: Assigned by the Start Point so that it can uniquely 531 identify the Measurement Request and the corresponding Measurement 532 Reply. 534 o Num: This field MUST be set to zero. 536 o Index: This field MUST be set to zero. 538 o Start Point Address: MUST be set to a unicast IPv6 address of the 539 Start Point after eliding Compr number of prefix octets. 541 o End Point Address: MUST be set to a unicast IPv6 address of the 542 End Point after eliding Compr number of prefix octets. 544 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 545 Route Accumulation Off 547 If a Hop-by-hop Route with a local RPLInstanceID is being measured 548 and the Start Point does not want the MO to accumulate a Source Route 549 for the End Point's use, the MO MUST NOT contain the Address vector 550 and various MO fields MUST be set in the following manner: 552 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 553 measured. 555 o Compr: MUST be set to specify the number of prefix octets that are 556 elided from the IPv6 addresses in Start Point/End Point Address 557 fields. 559 o Type (T): MUST be set to one since the MO represents a Measurement 560 Request. 562 o Hop-by-hop (H): MUST be set to one. 564 o Accumulate Route (A): This flag MUST be set to zero. 566 o Reverse (R): This flag MUST be set to zero. 568 o Back Request (B): This flag MAY be set to one to request the End 569 Point to send a Measurement Request to the Start Point. 571 o Intermediate Reply (I): This flag MUST be set to zero. 573 o SequenceNo: Assigned by the Start Point so that it can uniquely 574 identify the Measurement Request and the corresponding Measurement 575 Reply. 577 o Num: This field MUST be set to zero. 579 o Index: This field MUST be set to zero. 581 o Start Point Address: This field MUST contain the DODAGID value 582 (after eliding Compr number of prefix octets) associated with the 583 route being measured. 585 o End Point Address: MUST be set to a unicast IPv6 address of the 586 End Point after eliding Compr number of prefix octets. 588 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 589 Route Accumulation On 591 If a Hop-by-hop Route with a local RPLInstanceID is being measured 592 and the Start Point desires the MO to accumulate a Source Route for 593 the End Point to send the Measurement Reply message back, the MO MUST 594 contain a suitably-sized Address vector and various MO fields MUST be 595 set in the following manner: 597 o RPLInstanceID: MUST be set to the RPLInstanceID of the route being 598 measured. 600 o Compr: MUST be set to specify the number of prefix octets that are 601 elided from the IPv6 addresses in Start Point/End Point Address 602 fields and the Address vector. 604 o Type (T): MUST be set to one since the MO represents a Measurement 605 Request. 607 o Hop-by-hop (H): MUST be set to one. 609 o Accumulate Route (A): This flag MUST be set to one. 611 o Reverse (R): This flag MUST be set to zero. 613 o Back Request (B): This flag MAY be set to one to request the End 614 Point to send a Measurement Request to the Start Point. 616 o Intermediate Reply (I): This flag MUST be set to zero. 618 o SequenceNo: Assigned by the Start Point so that it can uniquely 619 identify the Measurement Request and the corresponding Measurement 620 Reply. 622 o Num: This field MUST specify the number of address elements, each 623 (16 - Compr) octets in size, that can fit inside the Address 624 vector. 626 o Index: This field MUST be set to zero to indicate the position in 627 the Address vector where the next hop must store its IPv6 address. 629 o Start Point Address: This field MUST contain the DODAGID value 630 (after eliding Compr number of prefix octets) associated with the 631 route being measured. 633 o End Point Address: MUST be set to a unicast IPv6 address of the 634 End Point after eliding Compr number of prefix octets. 636 o Address vector: The Address vector must be large enough to 637 accomodate a complete Source Route from the End Point to the Start 638 Point. All the bits in the Address vector field MUST be set to 639 zero. 641 4.4. When Measuring A Source Route 643 If a Source Route is being measured, the Start Point MUST set various 644 MO fields in the following manner: 646 o RPLInstanceID: MUST be set to the binary value 10000000. 648 o Compr: MUST be set to specify the number of prefix octets that are 649 elided from the IPv6 addresses in Start Point/End Point Address 650 fields and the Address vector. 652 o Type (T): MUST be set to one since the MO represents a Measurement 653 Request. 655 o Hop-by-hop (H): MUST be set to zero. 657 o Accumulate Route (A): This flag MUST be set to zero. 659 o Reverse (R): This flag SHOULD be set to one if the Source Route in 660 the Address vector can be reversed and used by the End Point to 661 send the Measurement Reply message back to the Start Point. 662 Otherwise, this flag MUST be set to zero. 664 o Back Request (B): This flag MAY be set to one to request the End 665 Point to send a Measurement Request to the Start Point. 667 o Intermediate Reply (I): This flag MUST be set to zero. 669 o SequenceNo: Assigned by the Start Point so that it can uniquely 670 identify the Measurement Request and the corresponding Measurement 671 Reply. 673 o Num: This field MUST specify the number of address elements, each 674 (16 - Compr) octets in size, inside the Address vector. 676 o Index: This field MUST be set to zero to indicate the position in 677 the Address vector of the next hop on the route. 679 o Start Point Address: MUST be set to a unicast IPv6 address of the 680 Start Point after eliding Compr number of prefix octets. 682 o End Point Address: MUST be set to a unicast IPv6 address of the 683 End Point after eliding Compr number of prefix octets. 685 o Address vector: 687 * The Address vector MUST contain a complete Source Route from 688 the Start Point to the End Point (excluding the Start Point and 689 the End Point). 691 * The IPv6 addresses (with Compr prefix octets elided) in the 692 Address vector MUST be reachable in the Forward direction. 694 * If the R flag is set to one, the IPv6 addresses (with Compr 695 prefix octets elided) in the Address vector MUST also be 696 reachable in the Backward direction. 698 * Each address appearing in the Address vector MUST be a unicast 699 address. 701 5. Processing a Measurement Request at an Intermediate Point 703 A router (an Intermediate Point or the End Point) MAY discard a 704 received MO with no processing to meet any policy-related goal. Such 705 policy goals may include the need to reduce the router's CPU load or 706 to enhance its battery life or to prevent misuse of this mechanism by 707 unauthorized nodes. 709 A router MUST discard a received MO with no further processing if the 710 value in the Compr field inside the received message is more than 711 what the router considers the length of the common prefix used in 712 IPv6 addresses in the LLN to be. 714 On receiving an MO, if a router chooses to process the packet 715 further, it MUST check if one of its IPv6 addresses is listed as 716 either the Start Point or the End Point Address. If neither, the 717 router considers itself an Intermediate Point and MUST process the 718 received MO in the following manner. 720 An Intermediate Point MUST discard the packet with no further 721 processing if the received MO is not a Measurement Request (i.e., T = 722 0). 724 Next, the Intermediate Point determines the type of the route being 725 measured (by checking the values of the H flag and the RPLInstanceID 726 field) and processes the received MO accordingly in the manner 727 specified next. 729 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 731 If a Hop-by-hop Route with a global RPLInstanceID is being measured 732 (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate 733 Point MUST process the received Measurement Request in the following 734 manner. 736 If the Num field inside the received Measurement Request is not set 737 to zero, thereby implying that an Address vector is present, the 738 Intermediate Point MUST discard the received message with no further 739 processing. 741 If the Intermediate Reply (I) flag is set to one in the received 742 Measurement Request and the Intermediate Point knows the values of 743 the routing metrics, specified in the Metric Container options, for 744 the remainder of the route, it MAY generate a Measurement Reply on 745 the End Point's behalf in the manner specified in Section 6.1 (after 746 including in the Measurement Reply the relevant routing metric values 747 for the complete route being measured). Otherwise, the Intermediate 748 Point MUST process the received message in the following manner. 750 The Intermediate Point MUST then determine the next hop on the route 751 being measured using the RPLInstanceID and the End Point Address. If 752 the Intermediate Point is the root of the non-storing global DAG 753 along which the received Measurement Request had been traveling so 754 far, it MUST process the received Measurement Request in the 755 following manner: 757 o If the router does not know how to reach the End Point, it MUST 758 discard the Measurement Request with no further processing and MAY 759 send an ICMPv6 Destination Unreachable (with Code 0 - No Route To 760 Destination) error message to the Start Point. 762 o Otherwise, unless the router determines the End Point itself to be 763 the next hop, the router MUST make the following changes in the 764 received Measurement Request: 766 * Set the H, A, R and I flags to zero (the A and R flags should 767 already be zero in the received message). 769 * Leave remaining fields unchanged (the Num field would be 770 modified in next steps). Note that the RPLInstanceID field 771 identifies the non-storing global DAG along which the 772 Measurement Request traveled so far. This information MUST be 773 preserved so that the End Point may use this DAG to send the 774 Measurement Reply back to the Start Point. 776 * Insert a new Address vector inside the Measurement Request and 777 specify a Source Route to the End Point inside the Address 778 vector as per the following rules: 780 + The Address vector MUST contain a complete route from the 781 router to the End Point (excluding the router and the End 782 Point); 784 + The IPv6 addresses (with Compr prefix octets elided) in the 785 Address vector MUST be reachable in the Forward direction; 787 + Each address appearing in the Address vector MUST be a 788 unicast address. 790 * Specify in the Num field the number of address elements in the 791 Address vector. 793 * Set the Index field to zero to indicate the position in the 794 Address vector of the next hop on the route. Thus, Address[0] 795 element contains the address of the next hop on the route. 797 The Intermediate Point MUST then complete the processing of the 798 received Measurement Request as specified in Section 5.5. 800 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 801 Route Accumulation Off 803 If a Hop-by-hop Route with a local RPLInstanceID is being measured 804 and the route accumulation is off (i.e., H = 1, RPLInstanceID has a 805 local value, A = 0), the Intermediate Point MUST process the received 806 Measurement Request in the following manner. 808 If the Num field inside the received Measurement Request is not set 809 to zero, thereby implying that an Address vector is present, the 810 Intermediate Point MUST discard the received message with no further 811 processing. 813 The Intermediate Point MUST then determine the next hop on the route 814 being measured using the RPLInstanceID, the End Point Address and the 815 Start Point Address (which represents the DODAGID of the route being 816 measured). If the Intermediate Point can not determine the next hop, 817 it MUST discard the Measurement Request with no further processing 818 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 819 Route To Destination) error message to the Start Point. Otherwise, 820 the Intermediate Point MUST complete the processing of the received 821 Measurement Request as specified in Section 5.5. 823 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 824 Route Accumulation On 826 If a Hop-by-hop Route with a local RPLInstanceID is being measured 827 and the route accumulation in on (i.e., H = 1, RPLInstanceID has a 828 local value, A = 1), the Intermediate Point MUST process the received 829 Measurement Request in the following manner. 831 If the Num field inside the received Measurement Request is set to 832 zero, thereby implying that an Address vector is not present, the 833 Intermediate Point MUST discard the received message with no further 834 processing. 836 The Intermediate Point MUST then determine the next hop on the route 837 being measured using the RPLInstanceID, the End Point Address and the 838 Start Point Address (which represents the DODAGID of the route being 839 measured). If the Intermediate Point can not determine the next hop, 840 it MUST discard the Measurement Request with no further processing 841 and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No 842 Route To Destination) error message to the Start Point. If the index 843 field has value Num - 1 and the next hop is not same as the End 844 Point, the Intermediate Point MUST drop the received Measurement 845 Request with no further processing. In this case, the next hop would 846 have no space left in the Address vector to store its address. 847 Otherwise, the router MUST store one of its unicast IPv6 addresses 848 (after eliding Compr prefix octets) at location Address[Index] and 849 then increment the Index field. The IPv6 address added to the 850 Address vector MUST be reachable in the Backward direction. 852 The Intermediate Point MUST then complete the processing of the 853 received Measurement Request as specified in Section 5.5. 855 5.4. When Measuring A Source Route 857 If a Source Route is being measured (i.e., H = 0), the Intermediate 858 Point MUST process the received Measurement Request in the following 859 manner. 861 If the Num field inside the received Measurement Request is set to 862 zero, thereby implying that an Address vector is not present, the 863 Intermediate Point MUST discard the received message with no further 864 processing. 866 The Intermediate Point MUST verify that the Address[Index] element 867 lists one of its unicast IPv6 addresses, failing which it MUST 868 discard the Measurement Request with no further processing. The 869 Intermediate Point MUST then increment the Index field and use the 870 Address[Index] element as the next hop (unless Index value is now 871 Num). If the Index value is now Num, the Intermediate Point MUST use 872 the End Point Address as the next hop. 874 The Intermediate Point MUST then complete the processing of the 875 received Measurement Request as specified in Section 5.5. 877 5.5. Final Processing 879 The Intermediate Point MUST drop the received Measurement Request 880 with no further processing: 882 o If the next hop address is not a unicast address; or 884 o If the next hop is not on-link; or 886 o If the next hop is not in the same RPL routing domain as the 887 Intermediate Point. 889 Next, the Intermediate Point MUST update the routing metric objects, 890 inside the Metric Container option(s) inside the Measurement Request, 891 either by updating the aggregated value for the routing metric or by 892 attaching the local values for the metric inside the object. An 893 Intermediate Point can only update the existing metric objects and 894 MUST NOT add any new routing metric object to the Metric Container. 895 An Intermediate Point MUST drop the Measurement Request with no 896 further processing if it cannot update a routing metric object 897 specified inside the Metric Container. 899 Finally, the Intermediate Point MUST unicast the Measurement Request 900 to the next hop. 902 6. Processing a Measurement Request at the End Point 904 On receiving an MO, if a router chooses to process the message 905 further and finds one of its unicast IPv6 addresses listed as the End 906 Point Address, the router considers itself the End Point and MUST 907 process the received MO in the following manner. 909 The End Point MUST discard the received message with no further 910 processing if it is not a Measurement Request (i.e., T = 0). 912 If the received Measurement Request traveled on a Hop-by-hop Route 913 with a local RPLInstanceID with route accumulation on (i.e., H = 1, 914 RPLInstanceID has a local value and A = 1), elements Address[0] 915 through Address[Index - 1] in the Address vector contain a complete 916 Source Route from the Start Point to the End Point (excluding the 917 Start Point and the End Point), which the End Point MAY use, after 918 reversal, to reach the Start Point. 920 If the received Measurement Request traveled on a Source Route and 921 the Reverse flag is set to one (i.e., H = 0, R = 1), elements 922 Address[0] through Address[Num - 1] in the Address vector contain a 923 complete Source Route from the Start Point to the End Point 924 (excluding the Start Point and the End Point), which the End Point 925 MAY use, after reversal, to reach the Start Point. 927 The End Point MUST update the routing metric objects in the Metric 928 Container options if required and MAY note the measured values for 929 the complete route (especially, if the received Measurement Request 930 is likely a response to an earlier Measurement Request that the End 931 Point had sent to the Start Point with B flag set to one). 933 The End Point MUST generate a Measurement Reply message as specified 934 in Section 6.1. If the B flag is set to one in the received 935 Measurement Request, the End Point SHOULD generate a new Measurement 936 Request to measure the cost of its current (or the most preferred) 937 route to the Start Point. The routing metrics used in the new 938 Measurement Request MUST include the routing metrics specified in the 939 received Measurement Request. 941 6.1. Generating the Measurement Reply 943 A Measurement Reply MUST have the Type (T) flag set to zero and need 944 not contain the Address vector. The following fields inside a 945 Measurement Reply MUST have the same values as they had inside the 946 corresponding Measurement Request: RPLInstanceID, Compr, SequenceNo, 947 Start Point Address, End Point Address and Metric Container 948 Option(s). The remaining fields inside a Measurement Reply may have 949 any value and MUST be ignored on reception at the Start Point. The 950 received Measurement Request MAY trivially be converted into a 951 Measurement Reply by setting the Type (T) flag to zero. 953 A Measurement Reply MUST be unicast back to the Start Point: 955 o If the Measurement Request traveled along a global DAG, identified 956 by the RPLInstanceID field, the Measurement Reply MAY be unicast 957 back to the Start Point along the same DAG. 959 o If the Measurement Request traveled along a Hop-by-hop Route with 960 a local RPLInstanceID and accumulated a Source Route from the 961 Start Point to the End Point, this Source Route MAY be used after 962 reversal to send the Measurement Reply back to the Start Point. 964 o If the Measurement Request traveled along a Source Route and the R 965 flag inside the received message is set to one, the End Point MAY 966 reverse the Source Route contained in the Address vector and use 967 it to send the Measurement Reply back to the Start Point. 969 7. Processing a Measurement Reply at the Start Point 971 When a router receives an MO, it examines if one of its unicast IPv6 972 addresses is listed as the Start Point Address. If yes, the router 973 is the Start Point and MUST process the received message in the 974 following manner. 976 If the Start Point discovers that the received MO is not a 977 Measurement Reply or if it has no recollection of sending the 978 corresponding Measurement Request, it MUST discard the received 979 message with no further processing. 981 The Start Point can use the routing metric objects inside the Metric 982 Container to evaluate the metrics for the measured P2P route. If a 983 routing metric object contains local metric values recorded by 984 routers on the route, the Start Point can make use of these local 985 values by aggregating them into an end-to-end metric according to the 986 aggregation rules for the specific metric. A Start Point is then 987 free to interpret the metrics for the route according to its local 988 policy. 990 8. Security Considerations 992 The mechanism defined in this document can potentially be used by a 993 compromised router to send bogus Measurement Requests to arbitrary 994 End Points. Such Measurement Requests may cause CPU overload in the 995 routers in the network, drain their batteries and cause traffic 996 congestion in the network. Note that some of these problems would 997 occur even if the compromised router were to generate bogus data 998 traffic to arbitrary destinations. 1000 Since a Measurement Request can travel along a Source Route specified 1001 in the Address vector, some of the security concerns that led to the 1002 deprecation of Type 0 routing header [RFC5095] may be valid here. To 1003 address such concerns, the mechanism described in this document 1004 includes several remedies: 1006 o This document requires that a route inserted inside the Address 1007 vector must be a strict Source Route and must not include any 1008 multicast addresses. 1010 o This document requires that an MO message must not cross the 1011 boundaries of the RPL routing domain where it originated. A 1012 router must not forward a received MO message further if the next 1013 hop belongs to a different RPL routing domain. Hence, any 1014 security problems associated with the mechanism would be limited 1015 to one RPL routing domain. 1017 o This document requires that a router must drop a received 1018 Measurement Request if the next hop address is not on-link or if 1019 it is not a unicast address. 1021 The measurement mechanism described in this document may potentially 1022 be used by a rogue node to find out key information about the LLN, 1023 e.g., the topological features of the LLN (such as the identity of 1024 the key nodes in the topology) or the remaining energy levels 1025 [RFC6551] in the LLN routers. This information can potentially be 1026 used to attack the LLN. To protect against such misuse, this 1027 document allows RPL routers implementing this mechanism to not 1028 process MO messages (or process such messages selectively) based on a 1029 local policy. Further, an LLN deployment may use Secure MO 1030 Section 3.2 messages to invoke RPL-provided security mechanisms and 1031 prevent misuse of the measurement mechanism by unauthorized nodes. 1033 9. IANA Considerations 1035 This document defines two new RPL messages: 1037 o "Measurement Object" (see Section 3.1), assigned a value TBD1 from 1038 the "RPL Control Codes" space [to be removed upon publication: 1039 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1040 [RFC6550]. IANA is requested to allocate TBD1 from the range 1041 0x00-0x7F to indicate a message without security enabled. The 1042 string TBD1 in this document should be replaced by the allocated 1043 value. These last two sentences should be removed before 1044 publication. 1046 o "Secure Measurement Object" (see Section 3.2), assigned a value 1047 TBD2 from the "RPL Control Codes" space [to be removed upon 1048 publication: 1049 http://www.iana.org/assignments/rpl/rpl.xml#control-codes] 1050 [RFC6550]. IANA is requested to allocate TBD2 from the range 1051 0x80-0xFF to indicate a message with security enabled. The string 1052 TBD2 in this document should be replaced by the allocated value. 1053 These last two sentences should be removed before publication. 1055 +------+---------------------------+---------------+ 1056 | Code | Description | Reference | 1057 +------+---------------------------+---------------+ 1058 | TBD1 | Measurement Object | This document | 1059 | TBD2 | Secure Measurement Object | This document | 1060 +------+---------------------------+---------------+ 1062 RPL Control Codes 1064 10. Acknowledgements 1066 Authors gratefully acknowledge the contributions of Adrian Farrel, 1067 Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and 1068 Zach Shelby in the development of this document. 1070 11. References 1072 11.1. Normative References 1074 [I-D.ietf-roll-p2p-rpl] 1075 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 1076 Martocci, "Reactive Discovery of Point-to-Point Routes in 1077 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-15 1078 (work in progress), December 2012. 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, March 1997. 1083 11.2. Informative References 1085 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1086 of Type 0 Routing Headers in IPv6", RFC 5095, 1087 December 2007. 1089 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1090 Routing Requirements in Low-Power and Lossy Networks", 1091 RFC 5826, April 2010. 1093 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1094 "Building Automation Routing Requirements in Low-Power and 1095 Lossy Networks", RFC 5867, June 2010. 1097 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1098 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1099 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1100 Lossy Networks", RFC 6550, March 2012. 1102 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1103 Barthel, "Routing Metrics Used for Path Calculation in 1104 Low-Power and Lossy Networks", RFC 6551, March 2012. 1106 Authors' Addresses 1108 Mukul Goyal (editor) 1109 University of Wisconsin Milwaukee 1110 3200 N Cramer St 1111 Milwaukee, WI 53211 1112 USA 1114 Phone: +1 414 2295001 1115 Email: mukul@uwm.edu 1117 Emmanuel Baccelli 1118 INRIA 1120 Phone: +33-169-335-511 1121 Email: Emmanuel.Baccelli@inria.fr 1122 URI: http://www.emmanuelbaccelli.org/ 1124 Anders Brandt 1125 Sigma Designs 1126 Emdrupvej 26A, 1. 1127 Copenhagen, Dk-2100 1128 Denmark 1130 Phone: +45 29609501 1131 Email: abr@sdesigns.dk 1132 Jerald Martocci 1133 Johnson Controls 1134 507 E Michigan Street 1135 Milwaukee 53202 1136 USA 1138 Phone: +1 414 524 4010 1139 Email: jerald.p.martocci@jci.com