idnits 2.17.00 (12 Aug 2021) /tmp/idnits49975/draft-mornulo-ippm-registry-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 10 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2013) is 3148 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) == Unused Reference: 'RFC2679' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC4737' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC1242' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 593, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) == Outdated reference: draft-ietf-ippm-lmap-path has been published as RFC 7398 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track A. Morton 5 Expires: March 30, 2014 AT&T Labs 6 P. Eardley 7 BT 8 September 30, 2013 10 A Registry for Performance Metrics 11 draft-mornulo-ippm-registry-00 13 Abstract 15 This memo investigates a scheme to organize registry entries, 16 especially those defined in RFCs prepared in the IP Performance 17 Metrics (IPPM) Working Group of the IETF, and applicable to all IETF 18 metrics. Three aspects make IPPM metric registration difficult: (1) 19 Use of the Type-P notion to allow users to specify their own packet 20 types. (2) Use of flexible input variables, called Parameters in IPPM 21 definitions, some which determine the quantity measured and others 22 which should not be specified until execution of the measurement. (3) 23 Allowing flexibility in choice of statistics to summarize the results 24 on a stream of measurement packets. Specifically, this memo proposes 25 a way to organize registry entries into columns that are well- 26 defined, permiting consistent development of entries over time. 27 Also, this fosters development of registry entries based on existing 28 reference RFCs for performance metrics, and requires expert review 29 for every entry before IANA action. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 22, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Background and Motivation . . . . . . . . . . . . . . . . 4 73 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Registry Columns and Sub-Columns . . . . . . . . . . . . . . . 5 75 3.1. Metric ID . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.3. Metric Description . . . . . . . . . . . . . . . . . . . . 7 78 3.4. Method of Measurement . . . . . . . . . . . . . . . . . . 7 79 3.4.1. Reference Method . . . . . . . . . . . . . . . . . . . 7 80 3.4.2. Fixed Parameters . . . . . . . . . . . . . . . . . . . 7 81 3.4.3. Schedule . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.4.4. Output Type . . . . . . . . . . . . . . . . . . . . . 8 83 3.4.5. Run-time Parameters . . . . . . . . . . . . . . . . . 9 84 3.5. Metric Units . . . . . . . . . . . . . . . . . . . . . . . 10 85 3.6. Measurement Point . . . . . . . . . . . . . . . . . . . . 10 86 3.7. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.8. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 4. Example of allocation . . . . . . . . . . . . . . . . . . . . 10 89 4.1. UDP latency metric . . . . . . . . . . . . . . . . . . . . 10 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 This memo investigates a scheme to organize registry entries, 101 especially those defined in RFCs prepared in the IP Performance 102 Metrics (IPPM) Working Group of the IETF, according to their 103 framework [RFC2330]. Three aspects make IPPM metric registration 104 difficult: (1) Use of the Type-P notion to allow users to specify 105 their own packet types. (2) Use of Flexible input variables, called 106 Parameters in IPPM definitions, some which determine the quantity 107 measured and others which should not be specified until execution of 108 the measurement. (3) Allowing flexibility in choice of statistics to 109 summarize the results on a stream of measurement packets. This memo 110 uses terms and definitions from the IPPM literature, primarily 111 [RFC2330], and the reader is assumed familiar with them or may refer 112 questions there as necessary. 114 This registry is based on the template defined in [RFC6390] expanded 115 with further details to fully cover the needs of a registry. 117 The authors of [draft-bagnulo-ippm-new-registry] and 118 [draft-bagnulo-ippm-new-registry-independent] made important 119 contributions to this memo in the registry column structure, and the 120 problem of registry development in general. We also acknowledge 121 input from the authors of [draft-claise-ippm-perf-metric-registry], 122 especially the value of an Element ID and the need for naming 123 conventions. 125 1.1. Background and Motivation 127 The motivation for having such registry is to allow a controller to 128 request a measurement agent to execute a measurement using a specific 129 metric. Such request can be performed using any control protocol 130 that refers to the value assigned to the specific metric in the 131 registry. Similarly, the measurement agent can report the results of 132 the measurement and by referring to the metric value it can 133 unequivocally identify the metric that the results correspond to. 135 There was a previous attempt to define a metric registry RFC 4148 136 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because 137 it was "found to be insufficiently detailed to uniquely identify IPPM 138 metrics... [there was too much] variability possible when 139 characterizing a metric exactly" which led to the RFC4148 registry 140 having "very few users, if any". 142 Our approach learns from this, by tightly defining each entry in the 143 registry with only a few parameters open for each. The idea is that 144 the entries in the registry represent different measurement tests, 145 whilst the run-time parameters set things like source and destination 146 addresses that don't change the fundamental nature of the test. The 147 downside of this approach is that it could result in an explosion in 148 the number of entries in the registry. We believe that less is more 149 in this context - it is better to have a reduced set of useful 150 metrics rather than a large set of metrics with questionable 151 usefulness. Therefore this document defines that the registry only 152 includes commonly used metrics that are well defined; hence we 153 require both reference specification required AND expert review 154 policies for the assignment of values in the registry. 156 There are a couple of side benefits of having such registry. First 157 the registry could serve as an inventory of useful and used metrics, 158 that are normally supported by different implementations of 159 measurement agents. Second, the results of the metrics would be 160 comparable even if they are performed by different implementations 161 and in different networks, as the metric is properly defined. 163 2. Scope 165 Specifically, this memo proposes a way to organize registry entries 166 into columns that are well-defined, permiting consistent development 167 of entries over time. Also, this fosters development of registry 168 entries based on existing reference RFCs for performance metrics, and 169 requires expert review for every entry before IANA action. 171 In this memo, we attempt a combinatoric registry, where all factors 172 that can be reasonably specified ARE specified, and changing even one 173 factor would require a new registry entry (row). It is believed that 174 this exercise can also be instructive for a registry based on 175 independent factors, [draft-bagnulo-ippm-new-registry-independent] 176 but that topic is beyond the scope of this effort. 178 Entries in the registry must reference an existing RFC or other 179 recognized standard, and are subject to expert review. The expert 180 review must make sure that the proposed metric is operationally 181 useful. This means that the metric has proven to be useful in 182 operational/real scenarios. 184 3. Registry Columns and Sub-Columns 186 This section describes the columns and sub-columns proposed for the 187 registry. Below, columns are described at the 3.x heading level, and 188 sub-columns are at the 3.x.y heading level. The Figure below 189 illustrates this organization. 191 Taken as a whole, each entries (row) in the registry gives a 192 registered instance of a metric with sufficient specificity to 193 promote comparable results across independent implementations. In 194 other words, a *complete description* of a Metric Instance. Some 195 instances may not require entries in all sub-columns, but this is 196 preferred to more general organization because each sub-column serves 197 as a check-list item and helps to avoid omissions during registration 198 and expert review. The columns are extracted directly from [RFC6390] 199 while the sub-columns provide additional detailed required for each 200 column. 202 +----+------+-------------+--------+-------+--------------------+--------|-------+ 203 | ID | Name | Description | Method | Units | Measurement Points | Timing | Other | 204 +----+------+-------------+--------+-------+--------------------+--------+-------+ 205 | | | | | | | | | 206 +----+------+-------------+--------+-------+--------------------+--------+-------+ 207 Figure 1: Registry columns 209 We describe the content of each of the columns next, some of them 210 contain sub-columns. 212 3.1. Metric ID 214 An integer having enough digits to uniquely identify each entry in 215 the Registry. 217 3.2. Metric Name 219 The current guidance from Section 13 of [RFC2330], where Type-P is a 220 feature of all IPPM metric names, is: 222 "... we introduce the generic notion of a "packet of type P", where 223 in some contexts P will be explicitly defined (i.e., exactly what 224 type of packet we mean), partially defined (e.g., "with a payload of 225 B octets"), or left generic. Thus we may talk about generic IP-type- 226 P-connectivity or more specific IP-port-HTTP-connectivity. Some 227 metrics and methodologies may be fruitfully defined using generic 228 type P definitions which are then made specific when performing 229 actual measurements. Whenever a metric's value depends on the type 230 of the packets involved in the metric, the metric's name will include 231 either a specific type or a phrase such as "type-P". ..." 233 Registry entries are a context where Type-P must be defined. 235 IPPM Metric names have also included the typically included the 236 stream type, to distinguish between singleton and sample metrics (see 237 [RFC2330] for the definition of these terms). 239 Based on this, the metric name is composed in the following way: 241 P_type-Descriptive_name-Schedule-Output-Other, where: 243 o P-type is a text describing the P-type selected 245 o Descriptive_name describes the nature of the metric 247 o The schedule describes the so-called stream type 249 o The output describes the expected output of the metric, in 250 particular, the type of statistic which is outputted, if it is 251 one. 253 o Other, describes other consideration that affects the nature of 254 the metric, for example the presence or absence of cross traffic 256 3.3. Metric Description 258 This entry provides references to relevant sections of the RFC(s) 259 defining the metric, as well as any supplemental information needed 260 to ensure an unambiguous definition for implementations. 262 3.4. Method of Measurement 264 This column is composed by the following sub-columns: 266 +------------------------------------------------------------------------------+ 267 | Method | 268 +-----------------+------------------+----------+-------------+----------------+ 269 |Reference Method | Fixed Parameters | Schedule | Output Type | Run-time Param | 270 +------------------------------------------------------------------------------+ 272 3.4.1. Reference Method 274 This sub-column provides references to relevant sections of the 275 specifications or RFC(s) describing the method of measurement, as 276 well as any supplemental information needed to ensure unambiguous 277 interpretation for implementations referring to the RFC text. 279 3.4.2. Fixed Parameters 281 In the case that the metric is defined as a more specific instance of 282 a broader metric defined in the specification pointed in the 283 "Reference method" column, this is done by defining as fixed some of 284 the open parameters defined in the broader metric. If this should be 285 the case of the specific entry in the registry, this sub-column 286 specifies the values of these parameters in the Registry. 288 A Parameter which is Fixed for one Registry entry may be designated 289 as a Run-time Parameter for another Registry entry. 291 3.4.3. Schedule 293 Principally, two different schedules are used in IPPM metrics, 294 Poisson distributed as described in [RFC2330] and Periodic as 295 described in [RFC3432]. Both Poisson and Periodic have their own 296 unique parameters, and the relevant set of values is specified in 297 this column. 299 Some metrics, such as those intended for passive monitoring or RTCP 300 and RTCP-XR metrics, will not specify an entry for this column. 302 Each entry for this sub-column contains the following information: 304 o Value: The name of the packet stream scheduling discipline 306 o Schedule Parameters: The values and formats of input factors for 307 each type of stream. For example, the average packet rate and 308 distribution truncation value for streams with Poisson-distributed 309 inter-packet sending times. 311 o Reference: the specification where the stream is defined 313 +-----------------------------------------+ 314 | Schedule | 315 +-------+---------------------+-----------+ 316 | Value | Schedule Parameters | Reference | 317 +-----------------------------------------+ 319 The simplest example of stream specification is Singleton scheduling, 320 where a single atomic measurement is conducted. Each atomic 321 measurement could consist of sending a single packet (such as a DNS 322 request) or sending several packets (for example, to request a a 323 webpage). Other streams support a series of atomic measurements in a 324 "sample", with a schedule defining the timing between each transmited 325 packet and subsequent measurement. 327 3.4.4. Output Type 329 For some entries, a statistic may be specified in this column to 330 summarize the results to a single value. If the complete set of 331 measured singletons is output, this will be specified here. 333 Some metrics embed one specific statistic in the reference metric 334 definition, while others allow several output types or statistics. 336 Each entry in the output type column contains the following 337 information: 339 o Value: The name of the output type 341 o Data Format: provided to simplify the communication with 342 collection systems and implementation of measurement devices. 344 o Reference: the specification where the output type is defined 346 +---------------------------------+ 347 | Output type | 348 +-------+-------------+-----------+ 349 | Value | Data format | Reference | 350 +---------------------------------+ 352 The output type defines the type of result that the metric produces. 353 It can be the raw results or it can be some form of statistic. The 354 specification of the output type must define the format of the 355 output. Note that if two different statistics are required from a 356 single measurement (for example, both "Xth percentile mean" and 357 "Raw"), then a new output type must be defined ("Xth percentile mean 358 AND Raw"). 360 3.4.5. Run-time Parameters 362 Run-Time Parameters are input factors that must be determined, 363 configured into the measurement system, and reported with the results 364 for the context to be complete. However, the actual values of these 365 parameters is not specified in the Registry, rather these parameters 366 are listed as an aid to the measurement system implementor or user 367 (they must be left as variables, and supplied on execution). 369 Where metrics supply a list of Parameters as part of their 370 descriptive template, a sub-set of the Parameters will be designated 371 as Run-Time Parameters. 373 The Data Format of each Run-time Parameter SHALL be specified in this 374 column, to simplify the control and implementation of measurement 375 devices. 377 Examples of Run-time Parameters include IP addresses, measurement 378 point designations, start times and end times for measurement, and 379 other measurement-specific information. 381 3.5. Metric Units 383 The measured results of a metric must be expressed using some 384 standard dimension or units of measure. This column provides the 385 units (and if possible, the data format, whose specification will 386 simplify both measurement implementation and collection/storage 387 tasks, see the Output Type column below). 389 When a sample of singletons (see [RFC2330] for definitions of these 390 terms) is collected, this entry will specify the units for each 391 measured value. 393 3.6. Measurement Point 395 Measurement Point(s) with potential Measurement Domain: A pointer to 396 the specification that defines whether the metric is specific to a 397 given measurement point or measurement domain. A canonical reference 398 path is defined in [I-D.ietf-ippm-lmap-path]. 400 3.7. Timing 402 A pointer to the specification where the acceptable range of timing 403 intervals or sampling intervals are defined, if any. 405 3.8. Other 407 Besides providing additional details which do not appear in other 408 categories, this open Category (single column) allows for unforeseen 409 issues to be addressed by simply updating this Informational entry. 411 4. Example of allocation 413 In this section we provide a few example of allocations. 415 4.1. UDP latency metric 417 The registry entry for for the Xth percentile mean of the UDP latency 418 using a Poisson stream of packets would look like this: 420 ID: 344 (for example, typically assigned by IANA) 422 Name: UDP-Latency-Poisson-Xth_percentile_mean. 424 Description: This metric is a specific instance of the Round trip 425 metric defined in RFC2681 and it measures the Xth percentile mean 426 of the UDP latency of a Poisson stream of packets. 428 Method: 430 Reference Method: The methodology for this metric is defined as 431 Type-P-Round-trip-Delay-Poisson-Stream in RFC 2681. 433 Fixed Parameters: 435 P-Type: 437 IPv4 header values: 439 DSCP: set to 0 441 TTL set to 255 443 Protocol: Set to 17 (UDP) 445 UDP header values: Checksum: the checksum must be 446 calculated 448 Payload 450 Sequence number: 8-byte integer 452 Timestamp: 8 byte integer. Expressed as 64-bit NTP 453 timestamp as per section 6 of RFC 5905 455 No padding 457 Timeout: 3 seconds 459 Schedule: 461 Value: Poisson 463 Schedule Parameters: 465 lambda: the parameter defining the Poisson distribution. 466 Lambda is the mean number of distinct measurements per 467 second in the sample. 469 T0: time to begin a test 471 Tf: time to end a test 472 T0 and Tf are both in seconds and use the date (yyyy- 473 mm-dd) and NTP 64 bit timestamp. T0 includes any 474 control handshaking before the test stream or 475 singleton. Tf is the time the last test data is sent. 476 As a result, we have that the ime when test devices 477 may close the test socket is Tf + Waiting Time (the 478 time to wait before declaring a packet lost is fixed 479 for each metric) and the Total duration of the test: 480 Tf - T0 + Waiting Time 482 Reference: The Poisson scheduling is defined in section 483 11.1.1 of RFC 2330 485 Output Type 487 Value: Xth percentile mean 489 Data format: 491 Reference: 493 Run-time Param 495 Source IP Address 497 Destination IP Address 499 Source UDP port 501 Destination UDP port 503 Initial time T0 505 end time Tf 507 Rate lambda 509 X 511 Units: milliseconds 513 Measurement Points: The metric is not specific to any particular 514 measurement point. 516 Timing: between microseconds and seconds 517 Other 519 5. Security Considerations 521 This registry has no known implications on Internet Security. 523 6. IANA Considerations 525 Metrics previously defined in IETF were registered in the IANA IPPM 526 METRICS REGISTRY, however this process was discontinued when the 527 registry structure was found to be inadequate, and the registry was 528 declared Obsolete [RFC6248]. 530 The form of metric registration will finalized in the future, and no 531 IANA Action is requested at this time. 533 7. Acknowledgements 535 The author thanks Brian Trammell for suggesting the term "Run-time 536 Parameters", which led to the distinction between run-time and fixed 537 parameters implemented in this memo. 539 8. References 541 8.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 547 "Framework for IP Performance Metrics", RFC 2330, 548 May 1998. 550 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 551 Delay Metric for IPPM", RFC 2679, September 1999. 553 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 554 Packet Loss Metric for IPPM", RFC 2680, September 1999. 556 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 557 Delay Metric for IPPM", RFC 2681, September 1999. 559 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 560 Metric for IP Performance Metrics (IPPM)", RFC 3393, 561 November 2002. 563 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 564 performance measurement with periodic streams", RFC 3432, 565 November 2002. 567 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 568 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 569 November 2006. 571 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 572 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 573 RFC 5357, October 2008. 575 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 576 Time Protocol Version 4: Protocol and Algorithms 577 Specification", RFC 5905, June 2010. 579 8.2. Informative References 581 [I-D.ietf-ippm-lmap-path] 582 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 583 A. Morton, "A Reference Path and Measurement Points for 584 LMAP", draft-ietf-ippm-lmap-path-00 (work in progress), 585 July 2013. 587 [RFC1242] Bradner, S., "Benchmarking terminology for network 588 interconnection devices", RFC 1242, July 1991. 590 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 591 Registry", BCP 108, RFC 4148, August 2005. 593 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 594 Applicability Statement", RFC 5481, March 2009. 596 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 597 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 598 April 2011. 600 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 601 Performance Metric Development", BCP 170, RFC 6390, 602 October 2011. 604 Authors' Addresses 606 Marcelo Bagnulo 607 Universidad Carlos III de Madrid 608 Av. Universidad 30 609 Leganes, Madrid 28911 610 SPAIN 612 Phone: 34 91 6249500 613 Email: marcelo@it.uc3m.es 614 URI: http://www.it.uc3m.es 616 Al Morton 617 AT&T Labs 618 200 Laurel Avenue South 619 Middletown,, NJ 07748 620 USA 622 Phone: +1 732 420 1571 623 Fax: +1 732 368 1192 624 Email: acmorton@att.com 625 URI: http://home.comcast.net/~acmacm/ 627 Philip Eardley 628 British Telecom 629 Adastral Park, Martlesham Heath 630 Ipswich 631 ENGLAND 633 Email: philip.eardley@bt.com