idnits 2.17.1 draft-goyal-roll-p2p-measurement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2010) is 4902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 352 -- Looks like a reference, but probably isn't: '1' on line 359 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-00 == Outdated reference: A later version (-19) exists of draft-ietf-roll-routing-metrics-11 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-13 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 == Outdated reference: A later version (-01) exists of draft-thubert-6man-reverse-routing-header-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 Milwaukee 4 Intended status: Standards Track E. Baccelli, Ed. 5 Expires: April 29, 2011 INRIA 6 P2P. Team 7 October 26, 2010 9 A Mechanism to Measure the Quality of a Point-to-point Route in a Low 10 Power and Lossy Network 11 draft-goyal-roll-p2p-measurement-01 13 Abstract 15 This document specifies a mechanism that enables an RPL node to 16 measure the quality of an existing route to/from another RPL node in 17 a low power and lossy network, thereby allowing the node to decide if 18 it wants to initiate the discovery of a more optimal route. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 29, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5 58 4. Originating an MO To Measure a P2P Route . . . . . . . . . . . 6 59 4.1. From the Origin Node to the Target Node . . . . . . . . . 7 60 4.2. From the Target Node to the Origin Node . . . . . . . . . 8 61 5. Processing a Received MO at an Intermediate Router . . . . . . 8 62 6. Processing a Received MO at the Target Node . . . . . . . . . 9 63 7. Processing a Received MO at the Origin Node . . . . . . . . . 11 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 10. Authors and Contributors . . . . . . . . . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 Point to point (P2P) communication between arbitrary nodes in a Low 75 power and Lossy Network (LLN) is a key requirement for many 76 applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6 77 Routing Protocol for LLNs, constrains the LLN topology to a Directed 78 Acyclic Graph (DAG) built to optimize routing costs to reach the 79 DAG's root and requires the P2P routes to use the DAG links only. 80 Such P2P routes may potentially be suboptimal and may lead to traffic 81 congestion near the DAG root. Additionally, RPL is a proactive 82 routing protocol and hence all P2P routes must be established ahead 83 of the time they are used. 85 To ameliorate situations, where RPL's P2P routing functionality does 86 not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a 87 reactive mechanism to discover P2P routes that meet the specified 88 performance characteristics. This mechanism, henceforth referred to 89 as the reactive P2P route discovery, requires the specification of 90 "good enough criteria", in terms of constraints on aggregated values 91 of the relevant routing metrics [I-D.ietf-roll-routing-metrics], that 92 the discovered routes must satisfy. In some cases, the application 93 requirements or the LLN's topological features allow a node to infer 94 the good enough criteria intrinsically. For example, the application 95 may require the end-to-end loss rate and/or latency on the route to 96 be below certain thresholds or the LLN topology may be such that a 97 router can safely assume its destination to be less than a certain 98 number of hops away from itself. 100 When the existing P2P routes are deemed unsatisfactory by the 101 application layer but the node does not intrinsically know the good 102 enough criteria, it may be necessary for the node to determine the 103 aggregated values of relevant routing metrics along the existing 104 routes. This knowledge will allow the node to frame a reasonable 105 good enough criteria and initiate a reactive P2P route discovery to 106 determine better routes. For example, if the router determines the 107 aggregate ETX [I-D.ietf-roll-routing-metrics] along an existing route 108 to be "x", it can use "ETX < x*y", where y is a certain fraction, as 109 a constraint in the good enough criteria. Note that it is important 110 that the good enough criteria is not overly strict; otherwise the 111 route discovery may fail even though routes, much better than the 112 ones being currently used, exist. 114 This document specifies a mechanism that enables an RPL node to 115 measure the aggregated values of the routing metrics along an 116 existing route to/from another RPL node in an LLN, thereby allowing 117 the node to decide if it wants to initiate the reactive discovery of 118 a more optimal route and determine the good enough criteria to be 119 used for this purpose. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 Additionally, this document uses terminology from 129 [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and 130 [I-D.ietf-roll-p2p-rpl]. Specifically, the term node refers to an 131 RPL router or an RPL host as defined in [I-D.ietf-roll-rpl]. The 132 following terms, originally defined in [I-D.ietf-roll-p2p-rpl], are 133 redefined in the following manner. 135 Origin Node: The origin node refers to the node that initiates the 136 measurement process defined in this document and is one end point of 137 the P2P route being measured. 139 Target Node: The target node refers to the other end of the P2P route 140 being measured. 142 Intermediate Router: A router, other than the origin and the target 143 node, on the P2P route being measured. 145 2. Functional Overview 147 The mechanism described in this document can be used by an origin 148 node to measure the aggregated values of the routing metrics along a 149 P2P route to/from a target node in the LLN. Such a route could be a 150 source route or a hop-by-hop route established using RPL 151 [I-D.ietf-roll-rpl] or the reactive P2P route discovery 152 [I-D.ietf-roll-p2p-rpl]. 154 When an origin node desires to measure the aggregated values of the 155 routing metrics along a P2P route from itself to a target node, it 156 sends a Measurement Request message along that route. The 157 Measurement Request message accumulates the values of the relevant 158 routing metrics as it travels towards the target node. Upon 159 receiving the Measurement Request message, the target node unicasts a 160 Measurement Reply message, carrying the accumulated values of the 161 routing metrics, back to the origin node. 163 When an origin node desires to measure the aggregated values of the 164 routing metrics along a P2P route from a target node to itself, it 165 unicasts a Measurement Request message, specifying the routing 166 metrics to be measured, to the target node. On receiving the 167 Measurement Request message, the target node sends a Measurement 168 Reply message to the origin node along the P2P route to be measured. 169 The Measurement Reply message accumulates the values of the relevant 170 routing metrics as it travels towards the origin node. 172 3. The Measurement Object (MO) 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | RPLInstanceID | SequenceNo |T|H|I|D| Resvd | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 | Origin Address | 181 | | 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 | Target Address | 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 . Source Route Option(*) . 191 . . 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 . Metric Container Options . 196 . . 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 1: Format of the Measurement Object (MO) 202 This document defines a new RPL Control Message type, the Measurement 203 Object (MO) with code 0x05 (to be confirmed by IANA) that serves as 204 both Measurement Request and Measurement Reply. The format of an MO 205 is shown in Figure 1. An MO consists of the following fields: 207 o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop 208 route. This field identifies the RPLInstanceID of the hop-by-hop 209 route. 211 o SequenceNo: A 16-bit sequence number that uniquely identifies a 212 Measurement Request and the corresponding Measurement Reply to the 213 origin node. 215 o T: The type flag. This flag is set if the MO represents a 216 Measurement Request. The flag is cleared if the MO is a 217 Measurement Reply. 219 o H: This flag is set if the MO travels along a hop-by-hop route. 220 In that case, the hop-by-hop route is identified by the 221 RPLInstanceID and, if required, the Origin/Target Address serving 222 as the DODAGID. This flag is cleared if the MO travels along a 223 source route. In that case, the MO MUST contain a Source Route 224 option [I-D.ietf-roll-p2p-rpl]. Note that, in case of a P2P route 225 along a non-storing DAG, it is possible that an MO message travels 226 along a hop-by-hop route till the DAG's root, which then sends it 227 along a source route to its destination. In that case, the DAG 228 root will reset the H flag and also insert a Source Route option 229 in the MO. 231 o I: A flag that indicates which of the two - the Origin Address and 232 the Target Address - indicates the DODAGID for the hop-by-hop 233 route. This flag is relevant only if the MO travels along a hop- 234 by-hop route (i.e., H flag is set) and a local RPLInstanceID has 235 been specified to identify the hop-by-hop route. This flag is set 236 if the Origin Address indicates the DODAGID; the flag is cleared 237 if the Target Address indicates the DODAGID. 239 o D: A flag that indicates the direction of the P2P route. This 240 flag is set when the route to be measured is from the origin node 241 to the target node. Otherwise, the flag is cleared. 243 o Reserved: These bits are reserved for future use. These bits MUST 244 be set to zero on transmission and MUST be ignored on reception. 246 o Origin Address: The IPv6 address of the origin node. 248 o Target Address: The IPv6 address of the target node. 250 o Source Route Option: An MO MUST contain one Source Route option if 251 it travels along a source route. 253 o Metric Container Options: An MO MUST contain one or more Metric 254 Container options to carry the routing metric objects 255 [I-D.ietf-roll-routing-metrics]. 257 4. Originating an MO To Measure a P2P Route 258 4.1. From the Origin Node to the Target Node 260 If the origin node intends to measure the routing metric values along 261 a P2P route towards a target node, it generates an MO message and 262 sets its fields as follows: 264 o RPLInstanceID: If the P2P route is a hop-by-hop route, the origin 265 node specifies the RPLInstanceID to identify the route in this 266 field. This field is not relevant if the P2P route is a source 267 route specified in the Source Route option. This document 268 RECOMMENDS a value 10000000 for this field if the P2P route is a 269 source route. 271 o SequenceNo: The origin node assigns a sequence number to the MO to 272 uniquely identify the corresponding Measurement Reply. 274 o T: The T flag is set to indicate that MO represents a Measurement 275 Request. 277 o H: The H flag is set if the MO travels along a hop-by-hop route. 279 o I: This field in relevant only if the H flag is set and the 280 RPLInstanceID is a local value. The origin node sets this flag if 281 the Origin Address indicates the DODAGID. The origin node clears 282 this flag if the Target Address indicates the DODAGID. 284 o D: This flag is set. 286 o Origin Address, Target Address: These fields are set to the IPv6 287 addresses of the origin and target nodes respectively. If the H 288 flag is set and the RPLInstanceID is a local value, the Origin 289 Address or the Target Address MUST also indicate the DODAGID value 290 required to identify the hop-by-hop route. 292 o Source Route Option: If the P2P route is a source route (i.e., the 293 H flag is cleared), the Source Route option MUST be present and 294 MUST include a complete source route to the target node in forward 295 direction (excluding the addresses of the origin and target 296 nodes). 298 o Metric Container Options: The origin node MUST also include one or 299 more Metric Container options containing relevant routing metric 300 objects to accumulate the costs for these metrics along the P2P 301 route. The origin node also initiates the routing metric objects 302 by including the local values of the routing metrics for the first 303 hop on the P2P route. 305 After setting the MO fields as described above, the origin node MUST 306 unicast the MO message to the next hop on the P2P route. The origin 307 node MAY include a Record Route IPv6 Extension Header, proposed in 308 [I-D.thubert-6man-reverse-routing-header], in the MO message to 309 accumulate a reverse route that the target node can use to send the 310 Measurement Reply back to the origin node. 312 4.2. From the Target Node to the Origin Node 314 If the origin node intends to measure the routing metric values along 315 a P2P route from a target node to itself, it generates an MO message 316 and sets its fields as follows: 318 o SequenceNo: The origin node assigns a sequence number to the MO to 319 uniquely identify the corresponding Measurement Reply. 321 o T: The T flag is set to indicate that MO represents a Measurement 322 Request. 324 o D: This flag is cleared. 326 o Origin Address, Target Address: These fields are set to the IPv6 327 addresses of the origin and target nodes respectively. 329 o Source Route Option: In this case, the MO SHOULD NOT include any 330 Source Route option. 332 o Metric Container Options: The origin node MUST include one or more 333 Metric Container options containing relevant routing metric 334 objects to accumulate the costs for these metrics along the P2P 335 route. These routing metric objects MUST be empty. 337 The other fields in the MO are not relevant in this case and SHOULD 338 be set to zero. After setting the MO fields as described above, the 339 origin node MUST unicast the MO message to the target node. 341 5. Processing a Received MO at an Intermediate Router 343 When a node receives an MO, it examines if one of its IPv6 addresses 344 is listed as the Origin Address or the Target Address. If not, the 345 node checks if H bit is clear (i.e., the MO is traveling along a 346 source route). If yes, the node checks the Address[0] field inside 347 the Source Route Option contained in the MO. The node MUST drop the 348 MO with no further processing and send an ICMPv6 Destination 349 Unreachable error message to the source of the message (the Origin 350 Address if the MO is a Measurement Request; otherwise the Target 351 Address) if the received MO has a clear H bit but does not contain a 352 Source Route Option or if the Address[0] inside the Source Route 353 option does not match one of the node's IPv6 address. 355 The node then determines the next hop on the P2P route being 356 measured. In case the received MO has a clear H flag, the Address[1] 357 field (the second element in the Address vector) inside the Source 358 Route Option is taken as the next hop. If the Source Route Option 359 does not contain Address[1] element, the node checks the T flag 360 inside the MO. If T flag is set, i.e., MO is a Measurement Request, 361 the Target Address is taken as the next hop; otherwise the Origin 362 Address is the next hop. If the received MO has H flag set, the node 363 uses the RPLInstanceID, the ultimate destination of the MO (Target 364 Address if T flag is set; otherwise the Origin Address) and, if 365 RPLInstanceID is a local value, the DODAGID (the Origin Address if I 366 flag is set; otherwise the Target Address) to determine the next hop 367 for the MO. If the H flag in the MO is set and the node is the root 368 of a non-storing DAG, indicated by the RPLInstanceID, the node MAY 369 reset the H flag and insert a Source Route option in the MO to 370 indicate a source route along which the MO should travel on rest of 371 its way to its destination. The node MUST drop the MO with no 372 further processing and send an ICMPv6 Destination Unreachable error 373 message to the source of the message if it can not determine the next 374 hop for the message. 376 After determining the next hop, the node updates the routing metric 377 objects, contained in the Metric Container options inside the MO, 378 either by updating the aggregated value for the routing metric or by 379 attaching the local values for the metric inside the object. The 380 node MUST drop the MO with no further processing and send a suitable 381 ICMPv6 error message to the source of the message if the node does 382 not know the relevant routing metric values for the next hop. 384 After updating the routing metrics, the node MUST unicast the MO to 385 the next hop. If the MO to be forwarded has a clear H flag, the node 386 MUST ensure that the Address vector in the Source Route option 387 contains the next hop address as the first element. 389 6. Processing a Received MO at the Target Node 391 When a node receives an MO, it examines if one of its IPv6 addresses 392 is listed as the Target Address. If yes, the node checks the T flag. 393 The node MUST drop the MO with no further processing and optionally 394 log an error if the T flag is clear (i.e. the received MO is a 395 Measurement Reply). 397 The target node then checks the D flag to determine the direction of 398 the P2P route to be measured. If the D flag is set (i.e., the P2P 399 route to be measured is from the origin node to the target node), the 400 target node updates the routing metrics objects in the Metric 401 Container options if required, removes the Source Route Option if 402 present and clears the T bit thereby converting the MO into a 403 Measurement Reply. The target node then unicasts the updated MO back 404 to the origin node. For this purpose, the target node MAY use the 405 reverse route accumulated in the Record Route IPv6 Extension Header 406 [I-D.thubert-6man-reverse-routing-header] if present in the received 407 MO message. 409 If the D flag in the received MO message is clear (i.e., the P2P 410 route to be measured is from the target node to the origin node), the 411 target node selects the P2P route to be measured and modifies the 412 following MO fields: 414 o RPLInstanceID: If the P2P route is a hop-by-hop route, the target 415 node specifies in this field the RPLInstanceID associated with the 416 route. This field is not relevant if the P2P route is a source 417 route. This document RECOMMENDS a value 10000000 for this field 418 if the P2P route is a source route. 420 o T: The T flag is cleared to indicate that MO represents a 421 Measurement Reply. 423 o H: The H flag is set if the P2P route is a hop-by-hop one. 425 o I: If the H flag is set and the RPLInstanceID is a local value, 426 the target node sets this flag if the Origin Address indicates the 427 DODAGID. The target node clears this flag if the Target Address 428 indicates the DODAGID. 430 o D: This flag is cleared. 432 o Source Route Option: If the P2P route is a source route, the 433 Source Route option MUST be present and MUST include a complete 434 source route from the target node to the origin node (excluding 435 the addresses of the target and origin nodes). 437 o Metric Container Options: The target node MUST initiate the 438 routing metric objects inside the Metric Container options by 439 including the local values of the routing metrics for the first 440 hop on the P2P route. 442 The target node need not modify the other fields in the received MO. 443 After these modifications, the target node MUST unicast the MO 444 message to the next hop on the P2P route. 446 7. Processing a Received MO at the Origin Node 448 When a node receives an MO, it examines if one of its IPv6 addresses 449 is listed as the Origin Address. If yes, the node checks the T flag. 450 The node MUST drop the MO with no further processing and optionally 451 log an error if the T flag is set (i.e. the received MO is a 452 Measurement Request) or if the node has no recollection of sending a 453 Measurement Request with the sequence number listed in the received 454 MO. 456 If the D flag in the received MO is clear (i.e., the P2P route to be 457 measured is from the target node to the origin node), the origin node 458 MUST update the routing metrics objects in the Metric Container 459 options if required. 461 The origin node can now examine the routing metric objects inside the 462 Metric Container options to evaluate the quality of the measured P2P 463 route. If a routing metric object contains local metric values 464 recorded by enroute nodes, the origin node MAY aggregate these local 465 values into an end-to-end value as per the aggregation rules for the 466 metric. 468 8. Security Considerations 470 TBA 472 9. IANA Considerations 474 TBA 476 10. Authors and Contributors 478 In addition to the editors, the authors of this document include the 479 following individuals (listed in alphabetical order). 481 Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100, 482 Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk 484 Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4 485 4WA, UK. Phone: +44 1924910888; Email: robert.cragie@gridmerge.com 487 Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone: 488 +1 414 524 4010; Email:jerald.p.martocci@jci.com 490 Charles Perkins, Tellabs Inc., USA. Email:charliep@computer.org 491 Authors gratefully acknowledge the contributions of Richard Kelsey 492 and Zach Shelby in the development of this document. 494 11. References 496 11.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 11.2. Informative References 503 [I-D.ietf-roll-p2p-rpl] 504 Goyal, M. and E. Baccelli, "Reactive Discovery of Point- 505 to-Point Routes in Low Power and Lossy Networks", 506 draft-ietf-roll-p2p-rpl-00 (work in progress), 507 August 2010. 509 [I-D.ietf-roll-routing-metrics] 510 Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. 511 Barthel, "Routing Metrics used for Path Calculation in Low 512 Power and Lossy Networks", 513 draft-ietf-roll-routing-metrics-11 (work in progress), 514 October 2010. 516 [I-D.ietf-roll-rpl] 517 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 518 Kelsey, R., Levis, P., Networks, D., Struik, R., and J. 519 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 520 Lossy Networks", draft-ietf-roll-rpl-13 (work in 521 progress), October 2010. 523 [I-D.ietf-roll-terminology] 524 Vasseur, J., "Terminology in Low power And Lossy 525 Networks", draft-ietf-roll-terminology-04 (work in 526 progress), September 2010. 528 [I-D.thubert-6man-reverse-routing-header] 529 Thubert, P., "Reverse Routing Header", 530 draft-thubert-6man-reverse-routing-header-00 (work in 531 progress), June 2010. 533 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 534 Routing Requirements in Low-Power and Lossy Networks", 535 RFC 5826, April 2010. 537 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 538 "Building Automation Routing Requirements in Low-Power and 539 Lossy Networks", RFC 5867, June 2010. 541 Authors' Addresses 543 Mukul Goyal (editor) 544 University of Wisconsin Milwaukee 545 3200 N Cramer St 546 Milwaukee, WI 53211 547 USA 549 Phone: +1 414 2295001 550 Email: mukul@uwm.edu 552 Emmanuel Baccelli (editor) 553 INRIA 555 Phone: +33-169-335-511 556 Email: Emmanuel.Baccelli@inria.fr 557 URI: http://www.emmanuelbaccelli.org/ 559 P2P Team