idnits 2.17.1 draft-ietf-ippm-2330-ipv6-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2330, but the abstract doesn't seem to directly say this. It does mention RFC2330 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2330, updated by this document, for RFC5378 checks: 1998-05-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Updates: 2330 (if approved) J. Fabini 5 Intended status: Informational TU Wien 6 Expires: September 7, 2017 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 March 6, 2017 14 IPv6 Updates for IPPM's Active Metric Framework 15 draft-ietf-ippm-2330-ipv6-01 17 Abstract 19 This memo updates the IP Performance Metrics (IPPM) Framework RFC 20 2330 with new considerations for measurement methodology and testing. 21 It updates the definition of standard-formed packets in RFC 2330 to 22 include IPv6 packets and augments distinguishing aspects of packets, 23 referred to as Type-P for test packets in RFC 2330. This memo 24 identifies that IPv4-IPv6 co-existence can challenge measurements 25 within the scope of the IPPM Framework. Exemplary use cases include, 26 but are not limited to IPv4-IPv6 translation, NAT, protocol 27 encapsulation, or IPv6 header compression. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 7, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 72 5. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The IETF IP Performance Metrics (IPPM) working group first created a 84 framework for metric development in [RFC2330]. This framework has 85 stood the test of time and enabled development of many fundamental 86 metrics. It has been updated in the area of metric composition 87 [RFC5835], and in several areas related to active stream measurement 88 of modern networks with reactive properties [RFC7312]. 90 The IPPM framework [RFC2330] recognized (in section 13) that many 91 aspects of IP packets can influence its processing during transfer 92 across the network. 94 In Section 15 of [RFC2330], the notion of a "standard-formed" packet 95 is defined. However, the definition was never updated to include 96 IPv6, as the original authors planned. 98 In particular, IPv6 Extension Headers and protocols which use IPv6 99 header compression are growing in use. This memo seeks to provide 100 the needed updates. 102 2. Scope 104 The purpose of this memo is to expand the coverage of IPPM metrics to 105 include IPv6, and to highlight additional aspects of test packets and 106 make them part of the IPPM performance metric framework. 108 The scope is to update key sections of [RFC2330], adding 109 considerations that will aid the development of new measurement 110 methodologies intended for today's IP networks. Specifically, this 111 memo expands the Type-P examples in section 13 of [RFC2330] and 112 expands the definition (in section 15 of [RFC2330]) of a standard- 113 formed packet to include IPv6 header aspects and other features. 115 Other topics in [RFC2330] which might be updated or augmented are 116 deferred to future work. This includes the topics of passive and 117 various forms of hybrid active/passive measurements. 119 3. Packets of Type-P 121 A fundamental property of many Internet metrics is that the measured 122 value of the metric depends on characteristics of the IP packet(s) 123 used to make the measurement. Potential influencing factors include 124 IP header fields and their values, but also higher-layer protocol 125 headers and their values. Consider an IP-connectivity metric: one 126 obtains different results depending on whether one is interested in 127 connectivity for packets destined for well-known TCP ports or 128 unreserved UDP ports, or those with invalid IPv4 checksums, or those 129 with TTL or Hop Limit of 16, for example. In some circumstances 130 these distinctions will result in special treatment of packets in 131 intermediate nodes and end systems (for example, if Diffserv 132 [RFC2780], ECN [RFC3168], Router Alert, Hop-by-hop extensions 133 [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of 134 firewalls or RSVP reservations). 136 Because of this distinction, we introduce the generic notion of a 137 "packet of Type-P", where in some contexts P will be explicitly 138 defined (i.e., exactly what type of packet we mean), partially 139 defined (e.g., "with a payload of B octets"), or left generic. Thus 140 we may talk about generic IP-Type-P-connectivity or more specific IP- 141 port-HTTP-connectivity. Some metrics and methodologies may be 142 fruitfully defined using generic Type-P definitions which are then 143 made specific when performing actual measurements. 145 Whenever a metric's value depends on the type of the packets involved 146 in the metric, the metric's name will include either a specific type 147 or a phrase such as "Type-P". Thus we will not define an "IP- 148 connectivity" metric but instead an "IP-Type-P-connectivity" metric 149 and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming 150 convention serves as an important reminder that one must be conscious 151 of the exact type of traffic being measured. 153 If the information constituting Type-P at the Source is found to have 154 changed at the Destination (or at a measurement point between the 155 Source and Destination, as in [RFC5644]), then the modified values 156 SHOULD be noted and reported with the results. Some modifications 157 occur according to the conditions encountered in transit (such as 158 congestion notification) or due to the requirements of segments of 159 the Source to Destination path. For example, the packet length will 160 change if IP headers are converted to the alternate version/address 161 family, or if optional Extension Headers are added or removed. Even 162 header fields like TTL/Hop Limit that typically change in transit may 163 be relevant to specific tests. For example Neighbor Discovery 164 Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value 165 set to 255, and the validity test specifies that the Hop Limit must 166 have a value of 255 at the receiver, too. So, while other tests may 167 intentionally exclude the TTL/Hop Limit value from their Type-P 168 definition, for this particular test the correct Hop Limit value is 169 of high relevance and must be part of the Type-P definition. 171 Local policies in intermediate nodes based on examination of IPv6 172 Extension Headers may affect measurement repeatability. If 173 intermediate nodes follow the recommendations of [RFC7045], 174 repeatability may be improved to some degree. 176 A closely related note: it would be very useful to know if a given 177 Internet component (like host, link, or path) treats equally a class 178 C of different types of packets. If so, then any one of those types 179 of packets can be used for subsequent measurement of the component. 180 This suggests we devise a metric or suite of metrics that attempt to 181 determine C. 183 Load balancing over parallel paths is one particular example where 184 such a class C would be more complex to determine in IPPM 185 measurements. Load balancers often use flow identifiers, computed as 186 hashes of (specific parts of) the packet header, for deciding among 187 the available parallel paths a packet will traverse. Packets with 188 identical hashes are assigned to the same flow and forwarded to the 189 same resource in the load balancer's pool. The presence of a load 190 balancer on the measurement path, as well as the specific headers and 191 fields that are used for the forwarding decision, are not known when 192 measuring the path as a black-box. Potential assessment scenarios 193 include the measurement of one of the parallel paths, and the 194 measurement of all available parallel paths that the load balancer 195 can use. Knowledge of a load balancer's flow definition 196 (alternatively: its class C specific treatment in terms of header 197 fields in scope of hash operations) is therefore a prerequisite for 198 repeatable measurements. A path may have more than one stage of load 199 balancing, adding to class C definition complexity. 201 4. Standard-Formed Packets 203 Unless otherwise stated, all metric definitions that concern IP 204 packets include an implicit assumption that the packet is *standard- 205 formed*. A packet is standard-formed if it meets all of the following 206 criteria: 208 + It includes a valid IP header: see below for version-specific 209 criteria. 211 + It is not an IP fragment. 213 + The Source and Destination addresses correspond to the intended 214 Source and Destination, including Multicast Destination addresses. 216 + If a transport header is present, it contains a valid checksum and 217 other valid fields. 219 For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, 220 the following additional criteria are required: 222 o The version field is 4 224 o The Internet Header Length (IHL) value is >= 5; the checksum is 225 correct. 227 o Its total length as given in the IPv4 header corresponds to the 228 size of the IPv4 header plus the size of the payload. 230 o Either the packet possesses sufficient TTL to travel from the 231 Source to the Destination if the TTL is decremented by one at each 232 hop, or it possesses the maximum TTL of 255. 234 o It does not contain IP options unless explicitly noted. 236 For an IPv6 ([RFC2460] and updates) packet to be standard-formed, the 237 following criteria are required: 239 o The version field is 6. 241 o Its total length corresponds to the size of the IPv6 header (40 242 octets) plus the length of the payload as given in the IPv6 243 header. 245 o The payload length value for this packet (including Extension 246 Headers) conforms to the IPv6 specifications. 248 o Either the packet possesses sufficient Hop Count to travel from 249 the Source to the Destination if the Hop Count is decremented by 250 one at each hop, or it possesses the maximum Hop Count of 255. 252 o Either the packet does not contain IP Extension Headers, or it 253 contains the correct number and type of headers as specified in 254 the packet, and the headers appear in the standard-conforming 255 order (Next Header). 257 o All parameters used in the header and Extension Headers are found 258 in the IANA Registry of Internet Protocol Version 6 (IPv6) 259 Parameters, partly specified in [RFC7045]. 261 Compressed IPv6 headers must be compliant with [RFC4494], as updated 262 by [RFC6282], in order to be declared "standard-formed". 264 The topic of IPv6 Extension Headers brings current controversies into 265 focus as noted by [RFC6564] and [RFC7045]. The following additional 266 considerations apply when IPv6 Extension Headers are present: 268 o Extension Header inspection: Some intermediate nodes may inspect 269 Extension Headers or the entire IPv6 packet while in transit. In 270 exceptional cases, they may drop the packet or route via a sub- 271 optimal path, and measurements may be unreliable or unrepeatable. 272 The packet (if it arrives) may be standard-formed, with a 273 corresponding Type-P. 275 o Extension Header modification: In Hop-by-Hop headers, some TLV 276 encoded options may be permitted to change at intermediate nodes 277 while in transit. The resulting packet may be standard-formed, 278 with a corresponding Type-P. 280 o Extension Header insertion or deletion: It is possible that 281 Extension Headers could be added to, or removed from the header 282 chain. The resulting packet may be standard-formed, with a 283 corresponding Type-P. 285 o A change in packet length (from the corresponding packet observed 286 at the Source) or header modification is a significant factor in 287 Internet measurement, and requires a new Type-P to be reported. 289 We further require that if a packet is described as having a "length 290 of B octets", then 0 <= B <= 65535; and if B is the payload length in 291 octets, then B <= (65535-IP header size in octets, including any 292 Extension Headers). The jumbograms defined in [RFC2675] are not 293 covered by this length analysis. In practice, the path MTU will 294 restrict the length of standard-formed packets that can successfully 295 traverse the path. 297 So, for example, one might imagine defining an IP connectivity metric 298 as "IP-type-P-connectivity for standard-formed packets with the IP 299 Diffserv field set to 0", or, more succinctly, "IP-type- 300 P-connectivity with the IP Diffserv Field set to 0", since standard- 301 formed is already implied by convention. Changing the contents of a 302 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 303 have a profound affect on packet handling during transit, but does 304 not affect a packet's status as standard-formed. 306 A particular type of standard-formed packet often useful to consider 307 is the "minimal IP packet from A to B" - this is an IP packet with 308 the following properties: 310 + It is standard-formed. 312 + Its data payload is 0 octets. 314 + It contains no options or Extension Headers. 316 (Note that we do not define its protocol field, as different values 317 may lead to different treatment by the network.) 319 When defining IP metrics we keep in mind that no packet smaller or 320 simpler than this can be transmitted over a correctly operating IP 321 network. 323 5. NAT, IPv4-IPv6 Transition and Compression Techniques 325 This memo adds the key considerations for utilizing IPv6 in two 326 critical conventions of the IPPM Framework, namely packets of Type-P 327 and standard-formed packets. The need for co-existence of IPv4 and 328 IPv6 has originated transitioning standards like the Framework for 329 IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms 330 in [RFC6145] and [RFC7757]. 332 The definition and execution of measurements within the context of 333 the IPPM Framework is challenged whenever such translation mechanisms 334 are present along the measurement path. In particular use cases like 335 IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header 336 compression may result in modification of the measurement packet's 337 Type-P along the path. All these changes must be reported. 338 Exemplary consequences include, but are not limited to: 340 o Modification or addition of headers or header field values in 341 intermediate nodes. As noted in Section 4 for IPv6 extension 342 header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header 343 compression mechanisms may result in changes of the measurement 344 packets' Type-P, too. Consequently, hosts along the measurement 345 path may treat packets differently because of the Type-P 346 modification. Measurements at observation points along the path 347 may also need extra context to uniquely identify a packet. 349 o Network Address Translators (NAT) on the path can have 350 unpredictable impact on latency measurement (in terms of the 351 amount of additional time added), and possibly other types of 352 measurements. It is not usually possible to control this impact 353 (as testers may not have any control of the underlying network or 354 middleboxes). There is a possibility that stateful NAT will lead 355 to unstable performance for a flow with specific Type-P, since 356 state needs to be created for the first packet of a flow, and 357 state may be lost later if the NAT runs out of resources. 358 However, this scenario does not invalidate the Type-P for testing 359 - for example the purpose of a test might be exactly to quantify 360 the NAT's impact on delay variation. The presence of NAT may mean 361 that the measured performance of Type-P will change between the 362 source and the destination. This can cause an issue when 363 attempting to correlate measurements conducted on segments of the 364 path that include or exclude the NAT. Thus, it is a factor to be 365 aware of when conducting measurements. 367 o Variable delay due to internal state. One side effect of changes 368 due to IPv4-IPv6 transitioning mechanisms is the variable delay 369 that intermediate nodes spend for header modifications. Similar 370 to NAT the allocation of internal state and establishment of 371 context within intermediate nodes may cause variable delays, 372 depending on the measurement stream pattern and position of a 373 packet within the stream. For example the first packet in a 374 stream will typically trigger allocation of internal state in an 375 intermediate IPv4-IPv6 transition host. Subsequent packets can 376 benefit from lower processing delay due to the existing internal 377 state. However, large inter-packet delays in the measurement 378 stream may result in the intermediate host deleting the associated 379 state and needing to re-establish it on arrival of another stream 380 packet. It is worth noting that this variable delay due to 381 internal state allocation in intermediate nodes can be an explicit 382 use case for measurements. 384 o Variable delay due to packet length. IPv4-IPv6 transitioning or 385 header compression mechanisms modify the length of measurement 386 packets. The modification of the packet size may or may not 387 change the way how the measurement path treats the packets. 389 Points that are worthwhile discussing further: handling of large 390 packets in IPv6 (including fragment extension headers, PMTUD, 391 PLMTUD), extent of coverage for 6LO and IPv6 Header Compression, and 392 the continued need to define a "minimal standard-formed packet". 394 . 396 6. Security Considerations 398 The security considerations that apply to any active measurement of 399 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 401 When considering privacy of those involved in measurement or those 402 whose traffic is measured, the sensitive information available to 403 potential observers is greatly reduced when using active techniques 404 which are within this scope of work. Passive observations of user 405 traffic for measurement purposes raise many privacy issues. We refer 406 the reader to the privacy considerations described in the Large Scale 407 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 408 which covers active and passive techniques. 410 7. IANA Considerations 412 This memo makes no requests of IANA. 414 8. Acknowledgements 416 The authors thank Brian Carpenter for identifying the lack of IPv6 417 coverage in IPPM's Framework, and for listing additional 418 distinguishing factors for packets of Type-P. Both Brian and Fred 419 Baker discussed many of the interesting aspects of IPv6 with the co- 420 authors, leading to a more solid first draft: thank you both. Thanks 421 to Bill Jouris for an editorial pass through the pre-00 text. 423 9. References 425 9.1. Normative References 427 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 428 DOI 10.17487/RFC0791, September 1981, 429 . 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 437 "Framework for IP Performance Metrics", RFC 2330, 438 DOI 10.17487/RFC2330, May 1998, 439 . 441 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 442 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 443 December 1998, . 445 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 446 RFC 2675, DOI 10.17487/RFC2675, August 1999, 447 . 449 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 450 Values In the Internet Protocol and Related Headers", 451 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 452 . 454 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 455 of Explicit Congestion Notification (ECN) to IP", 456 RFC 3168, DOI 10.17487/RFC3168, September 2001, 457 . 459 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 460 Algorithm and Its Use with IPsec", RFC 4494, 461 DOI 10.17487/RFC4494, June 2006, 462 . 464 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 465 Zekauskas, "A One-way Active Measurement Protocol 466 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 467 . 469 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 470 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 471 DOI 10.17487/RFC4861, September 2007, 472 . 474 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 475 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 476 RFC 5357, DOI 10.17487/RFC5357, October 2008, 477 . 479 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 480 Metrics (IPPM): Spatial and Multicast", RFC 5644, 481 DOI 10.17487/RFC5644, October 2009, 482 . 484 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 485 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 486 2010, . 488 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 489 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 490 April 2011, . 492 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 493 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 494 . 496 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 497 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 498 DOI 10.17487/RFC6282, September 2011, 499 . 501 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 502 "IPv6 Flow Label Specification", RFC 6437, 503 DOI 10.17487/RFC6437, November 2011, 504 . 506 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 507 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 508 RFC 6564, DOI 10.17487/RFC6564, April 2012, 509 . 511 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 512 of IPv6 Extension Headers", RFC 7045, 513 DOI 10.17487/RFC7045, December 2013, 514 . 516 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 517 Framework for IP Performance Metrics (IPPM)", RFC 7312, 518 DOI 10.17487/RFC7312, August 2014, 519 . 521 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 522 Mappings for Stateless IP/ICMP Translation", RFC 7757, 523 DOI 10.17487/RFC7757, February 2016, 524 . 526 9.2. Informative References 528 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 529 Aitken, P., and A. Akhter, "A Framework for Large-Scale 530 Measurement of Broadband Performance (LMAP)", RFC 7594, 531 DOI 10.17487/RFC7594, September 2015, 532 . 534 Authors' Addresses 536 Al Morton 537 AT&T Labs 538 200 Laurel Avenue South 539 Middletown, NJ 07748 540 USA 542 Phone: +1 732 420 1571 543 Fax: +1 732 368 1192 544 Email: acmorton@att.com 545 URI: http://home.comcast.net/~acmacm/ 547 Joachim Fabini 548 TU Wien 549 Gusshausstrasse 25/E389 550 Vienna 1040 551 Austria 553 Phone: +43 1 58801 38813 554 Fax: +43 1 58801 38898 555 Email: Joachim.Fabini@tuwien.ac.at 556 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 558 Nalini Elkins 559 Inside Products, Inc. 560 Carmel Valley, CA 93924 561 USA 563 Email: nalini.elkins@insidethestack.com 565 Michael S. Ackermann 566 Blue Cross Blue Shield of Michigan 568 Email: mackermann@bcbsm.com 569 Vinayak Hegde 570 Consultant 571 Brahma Sun City, Wadgaon-Sheri 572 Pune, Maharashtra 411014 573 INDIA 575 Phone: +91 9449834401 576 Email: vinayakh@gmail.com 577 URI: http://www.vinayakhegde.com