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