idnits 2.17.1 draft-eardley-lmap-framework-02.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 (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 192 -- Looks like a reference, but probably isn't: '180' on line 192 == Unused Reference: 'RFC6241' is defined on line 590, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eardley 3 Internet-Draft T. Burbridge 4 Intended status: Informational BT 5 Expires: January 16, 2014 A. Morton 6 AT&T Labs 7 July 15, 2013 9 A framework for large-scale measurements 10 draft-eardley-lmap-framework-02 12 Abstract 14 Measuring broadband service on a large scale requires standardisation 15 of the logical architecture and a description of the key protocols 16 that coordinate interactions between the components. The document 17 presents an overall framework for large-scale measurements and 18 discusses which elements could be standardised in the IETF. It is 19 intended to assist the work of the LMAP working group. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 16, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Outline of framework . . . . . . . . . . . . . . . . . . . . . 4 57 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Measurement system is under the direction of a single 59 organisation . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Each MA may only have a single Controller at any point 61 in time . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. A Measurement Agent acts autonomously . . . . . . . . . . 7 63 4. Work items for LMAP WG . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Information Model . . . . . . . . . . . . . . . . . . . . 9 65 4.2. Control Protocol . . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Report Protocol . . . . . . . . . . . . . . . . . . . . . 10 67 5. Related work required but out of scope of LMAP . . . . . . . . 10 68 5.1. Standard measurement tests . . . . . . . . . . . . . . . . 10 69 5.2. Characterisation plan . . . . . . . . . . . . . . . . . . 11 70 5.3. Other elements . . . . . . . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. from -00 to -01 . . . . . . . . . . . . . . . . . . . . . 13 76 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The Large-Scale Measurement of Broadband Performance (LMAP) working 82 group standardizes the LMAP measurement system for performance 83 measurements of broadband access devices such as home and enterprise 84 edge routers, personal computers, mobile devices, set top box, 85 whether wired or wireless. Measuring portions of the Internet on a 86 large scale is essential for accurate characterizations of 87 performance over time and geography. 89 [use-cases] discusses several use cases have been proposed for large- 90 scale measurements: 92 o Operators: to help plan their network and identify faults 94 o End Users: to run diagnostic checks, such as a network speed test 96 o Regulators: to benchmark several network operators and support 97 public policy development 99 The LMAP framework should be useful for all these. 101 The goal is to have the measurements (made using the same metrics and 102 mechanisms) for a large number of points on the Internet, and to have 103 the results collected and stored in the same form. 105 There are existing measurement systems. However, they typically lack 106 some of the desirable features for a large-scale measurement system: 108 o Standardised - in terms of the tests that they perform, the 109 components, the data models and protocols for transferring 110 information between the components. For example so that it is 111 meaningful to compare measurements made of the same metric at 112 different times and places. For example so that the operator of a 113 measurement system can buy the various components from different 114 vendors. Today's systems are proprietary in some or all of these 115 aspects. 117 o Extensible - it should be easy to add or modify tests, for example 118 an improved test methodology or to measure a performance metric 119 not previously considered important (e.g., bufferbloat). 121 o Large-scale - [use-cases] envisages Measurement Agents in every 122 home gateway and edge device such as set-top-boxes and tablet 123 computers. Existing systems have up to a few thousand Measurement 124 Agents (without judging how much further they could scale). 126 o Diversity - a measurement system should handle different types of 127 Measurement Agent - for example Measurement Agents may come from 128 different vendors, be in wired and wireless networks and be on 129 devices with IPv4 or IPv6 addresses. 131 2. Outline of framework 133 The LMAP framework for large-scale measurements has four elements: 135 o Measurement Agent (MA) 137 o Measurement Peer 139 o Controller 141 o Collector 143 In addition there are some components that are outside LMAP but 144 useful within the context of a large scale measurement system: 146 o Initialiser 148 o Subscriber Parameter Database 150 o Results Database 152 o Data Analysis Tools 154 o Operator's OAM (Operations Administration and Management) 156 a large-scale measurement system essentially has three sets of 157 communications: 159 o several measurement protocols between a Measurement Agent and a 160 Measurement Peer 162 o a Control Protocol between a Controller and a MA 164 o a Report Protocol between a MA and a Collector. 166 A Measurement Agent and a Measurement Peer jointly perform an active 167 measurement test, by generating test traffic and measuring some 168 metric associated with its transfer over the path from one to the 169 other; for example the time taken to transfer a 'test file'. A MA 170 may also conduct passive testing through the observation of traffic 171 (i.e. without the involvement of a Measurement Peer); for example an 172 end user's mix of applications. 174 The MA interacts with the Controller and Collector, and a Measurement 175 Peer only takes part in active tests (and does not interact with the 176 Controller and Collector). 178 The MA functions are implemented either in specialised hardware or as 179 code on general purpose devices like a PC, tablet or smartphone. The 180 Measurement Peer may be an LMAP device or a normal, non-LMAP device 181 (for example if the MA measures the time for a DNS response or a 182 webpage download from www.example.com). 184 The Controller manages a MA by instructing it which tests it should 185 perform and when. For example it may instruct a MA at a home 186 gateway: "Run the 'download speed test' with the test server at the 187 end user's first IP point in the network; if the end user is active 188 then delay the test and re-try 1 minute later, with up to 3 re-tries; 189 repeat every hour at xx.05 + Unif[0,180] seconds". The Controller 190 also manages a MA by instructing it how to report the test results, 191 for example: "Report results once a day in a batch at 4am + 192 Unif[0,180] seconds; if the end user is active then delay the report 193 5 minutes". As well as regular tests, a Controller can initiate a 194 one-off test ("Do test now", "Report as soon as possible"). These 195 are called the Test and Report Schedule. 197 The Collector accepts a Report from a MA with the results from its 198 tests. It may also do some processing on the results - for instance 199 to eliminate outliers, as they can severely impact the aggregated 200 results. 202 Therefore the MA is a LMAP-specific device that initiates the test, 203 gets instructions from the Controller and reports to the Collector. 205 It is possible that communications between two Collectors, two 206 Controllers and a Controller and Collector may be useful in some use 207 cases, perhaps to help a measurement system scale. Work on such a 208 protocol is out of scope of LMAP (?) 210 The Initialiser, Subscriber Parameter Database, Results Database, 211 Data Analysis Tools and OAM are out of scope of LMAP. They may be 212 provided through existing protocols or applications and are likely to 213 be part of a complete large-scale measurement system. See Section 5 214 for further discussion. 216 +------------+ +-----------+ +-----------+ 217 | | Instruction | | test traffic | | 218 | Controller | --------------> |Measurement| ............. |Measurement| 219 | | |Agent (MA) | | Peer | 220 +------------+ +-----------+ +-----------+ 221 | 222 | Report 223 | 224 V 225 +-------------+ 226 | Collector | 227 +-------------+ 229 Figure 1: Schematic of main elements of LMAP framework 231 3. Constraints 233 3.1. Measurement system is under the direction of a single organisation 235 In the LMAP framework (as defined in the WG's charter) the 236 measurement system is under the direction of a single organisation 237 that is responsible both for the data and the quality of experience 238 delivered to its users. Clear responsibility is critical given that 239 a misbehaving large-scale measurement system could potentially harm 240 user experience, user privacy and network security. 242 However, the components of an LMAP measurement system can be deployed 243 in administrative domains that are not owned by the measuring 244 organisation. Thus, the system of functions deployed by a single 245 organisation constitutes a single LMAP domain which may span 246 ownership or other administrative boundaries. 248 Note that different LMAP measurement systems may overlap, in the 249 sense that the active measurement packets of one measurement system 250 appear along with normal user traffic to another measurement system. 251 For instance, imagine an operator with an MA on the home gateway and 252 an end user with an MA on their laptop. Rather than making separate 253 measurements, an organisation might share its measurement data, or a 254 suitably anonymised version of it, with another organisation. 255 However, any form of coordination between different organisation 256 involves difficult commercial and technical issues and so, given the 257 novelty of large-scale measurement efforts, any form of inter- 258 organisation coordination is outside the scope of LMAP. 260 3.2. Each MA may only have a single Controller at any point in time 262 The constraint avoids different Controllers giving a MA conflicting 263 instructions and so means that the MA does not have to manage 264 contention between multiple Test (or Report) Schedules. This 265 simplifies the design of MAs (critical for a large-scale 266 infrastructure) and allows a Test Schedule to be tested on specific 267 types of MA before deployment to ensure that the home user experience 268 is not impacted (due to CPU, memory or broadband-product 269 constraints). 271 An operator may have several Controllers, perhaps with a Controller 272 for different types of MA (home gateways, tablets) or location 273 (Ipswich, Edinburgh). 275 To avoid problems with NAT and firewalls, it is likely that the MA 276 'pulls' the configuration from its Controller, as identified by the 277 Initialiser. 279 o Open issue: Should there be negotiation between a Controller and 280 its MA, or should the Controller simply instruct the MA by sending 281 its Test and Report Schedules? 283 * The argument for negotiation is that occasionally the MA may be 284 updated with enhanced with versions of existing tests. It is 285 easier for the Controller to learn the MAs capabilities 286 directly from the MA than from a management system. It avoids 287 any mis-synchronisation. 289 * The argument against negotiation is that it makes the 290 Controller-MA protocol more complicated, increases the MAs 291 resource requirements and increases the complexity of the 292 Controller when it decides how to schedule tests across 293 numerous MAs or when it deploys a new Test Schedule to 294 potentially millions of MAs. 296 o Open issue: what happens if a Controller fails, how is the MA is 297 homed onto a new one? 299 3.3. A Measurement Agent acts autonomously 301 Once the MA gets its Test and Report Schedules from its Controller 302 then it acts autonomously, in terms of operation of the tests and 303 reporting of the result. 305 Firstly, this means that the MA initiates Measurement Tasks. For the 306 typical case where the MA is on a home gateway or edge device, this 307 means that the MA initiates a 'download speed test' by asking a 308 Measurement Peer to send the file. The main rationale is that, for a 309 test that should be performed when there is no user traffic on the 310 link, the MA knows whether the end user is active and therefore 311 whether to start the test or delay it. Having the Schedule on the MA 312 also avoids it having to check frequently with the Controller. 313 Further, if the MA is behind a NAT then the Measurement Peer 314 naturally learns its public-facing IP address. 316 Secondly, it is useful for the MA and perhaps the Measurement Peer to 317 make some 'admission control' checks at the initiation of the 318 Measurement Task to ensure that desired test conditions are present. 319 The exchange of initialization packets between the MA and Measurement 320 Peer ensures basic connectivity between them. Also, the MA may delay 321 Measurement Task may if the associated subscriber is active, or the 322 Measurement Peer may reject a testing request if it is overloaded. 323 It has also been suggested that, in extremis, the Controller may want 324 the ability to send a Measurement Suppression message to an MA, which 325 causes the Measurement Tasks to be temporarily stopped. 327 Last, it is easier to secure the reporting process, for example with 328 a unique certificate for each MA-Collector pair, so that the 329 Collector is confident the results really do originate from the MA. 330 All measurement results are sent from the MA. 332 4. Work items for LMAP WG 334 This Section considers the work that the LMAP working group needs to 335 tackle. Section 5 considers other work that needs doing that would 336 be beyond the scope of the LMAP WG. 338 The main work items are: 340 o Information Model, the abstract definition of the information 341 carried from the Controller to the MA and the information carried 342 from the MA to the Collector. 344 o Control protocol and the associated data model: The definition of 345 how instructions are delivered from a Controller to a MA; this 346 includes a Data Model consistent with the Information Model plus a 347 transport protocol. 349 o Report protocol and the associated data model: The definition of 350 how the Report is delivered from a MA to a Collector; this 351 includes a Data Model consistent with the Information Model plus a 352 transport protocol. 354 4.1. Information Model 356 The Information Model provides a protocol and device independent view 357 of the information carried from the Controller to the MA and the 358 information carried from the MA to the Collector. It can be 359 implemented via a Control Protocol and Report Protocol, as defined by 360 the LMAP WG. It is also possible that other Control and Report 361 Protocols could be defined by other standards bodies or proprietary, 362 however it is important that they all implement the same Information 363 Model, in order to ease the definition, operation and 364 interoperability of large-scale measurement systems. 366 The Information Model also includes information that is pre- 367 configured on the MA in order that it can start communicating with a 368 Controller. 370 An initial proposal for the Information Model is in 371 [information-model]. 373 The Information Model is divided into two main parts, each of which 374 may be broken down into sub-parts: 376 o information about the Instruction: Information that is received by 377 the MA from the Controller pertaining to the measurement and 378 reporting configuration. This includes: 380 * what measurements to do: the Measurement Task could be defined 381 by reference to a registry entry, along with any parameters 382 that need to be set (such as the address of the Measurement 383 Peer) and any Environmental Constraint (such as, delay the test 384 if the end user is active) 386 * when to do them: the Measurement Schedule details the timings 387 of regular tests, one-off tests, and if regularly tests should 388 be temporarily suppressed 390 * how to report the Measurement Results: via Reporting 391 Channel(s), each of which defines a target Collector and Report 392 Schedule 394 o information about the Report: Information transmitted from the MA 395 to the Collector including measurement results and the context in 396 which they were conducted. This includes: 398 * the MAs identifier, or perhaps a Group-ID to anonymise results 400 * the actual Measurement Results, including the time they were 401 measured 403 * the details of the Measurement Task (to avoid the Collector 404 having to ask the Controller for this information later) 406 It is important to consider how to divide the Information Model into 407 (sub-)parts, so that each (sub-)part can be updated independently at 408 different times and regularities, as discussed in [information-model] 410 4.2. Control Protocol 412 The Control protocol and its associated data model define how 413 instructions are delivered from a Controller to a MA; this includes a 414 Data Model consistent with the Information Model plus a transport 415 protocol. This may be a simple instruction - response protocol, and 416 LMAP will specify how it operates over an existing protocol (to be 417 selected, perhaps REST-style HTTP(s) or NETCONF). 419 4.3. Report Protocol 421 The Report protocol and the associated data model: The definition of 422 how the Report is delivered from a MA to a Collector; this includes a 423 Data Model consistent with the Information Model plus a transport 424 protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). 426 5. Related work required but out of scope of LMAP 428 This section considers the items that need to be agreed between 429 deployers of large-scale measurement systems, but that are out of 430 scope of the LMAP WG (Section 4 considers items within its scope). 432 5.1. Standard measurement tests 434 Standardised methods are needed for each metric that is measured. A 435 registry for commonly-used metrics [registry] is also required, so 436 that a test can be defined simply by its identifier in the registry. 437 The methods and registry would hopefully also be referenced by other 438 standards organisations. 440 o Such activities are in scope of the IPPM working group (possibly 441 re-chartered) and not LMAP. 443 A new (or revised) test may need to be uploaded to MAs. How this is 444 done is out of scope of the IETF; it could be as a firmware upgrade 445 for a home hub, or new app for a PC, etc and may be device-specific. 447 5.2. Characterisation plan 449 Each organisation operating an LMAP system and collecting 450 measurements for comparison purposes needs to conduct the same 451 measurements according to the same sampling plan (ie size and 452 schedule) and make the results available in the same format. The 453 scope of comparison determines the set of organisations needing to 454 agree on the common characterisation plan; for example those falling 455 within the same regulatory environment in a particular country or 456 region. Such agreements are certainly facilitated by IETF's work, 457 but the details of the plan are beyond the scope of work in IETF. 459 5.3. Other elements 461 Other elements may be useful within the context of a large scale 462 measurement system and worthy of standardisation, but are outside the 463 scope of the LMAP WG: Initialiser, Subscriber Parameter Database, 464 Results Database, Data Analysis Tools and operator's OAM. 466 An Initialiser configures a MA with details about its Controller, 467 including authentication credentials. A bootstrap protocol is likely 468 to be technology specific and so for different types of device could 469 be defined by the Broadband Forum, DOCSIS or IEEE. Possible 470 protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN Management 471 Protocol (CWMP) from the Auto Configuration Server (ACS) (as 472 specified in TR-069). 474 A Subscriber Parameter Database contains information about the line, 475 for example the customer's broadband contract (2, 40 or 80Mb/s), the 476 line technology (DSL or fibre), the time zone where the MA is 477 located, and the type of home gateway and MA. These are all factors 478 which may affect the choice of what Measurement Tasks to run and how 479 to interpret the Measurement Results. For example, a download test 480 suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s 481 line. Another example is if the Controller wants to run a one-off 482 test to diagnose a fault, then it should understand what problem the 483 customer is experiencing and what tests have already been run. The 484 subscribers' service parameters are already gathered and stored by 485 existing operations systems. 487 A Results Database records all measurements in an equivalent form, 488 for example an SQL database [schulzrinne], so that they can be easily 489 accessed by the Data Analysis Tools whilst the LMAP system 490 implementor can choose local solutions for each component. The Data 491 Analysis Tools also need to understand subscriber service 492 information, for example the broadband contract. 494 The Data Analysis Tools receive the results from the Collector or via 495 the Results Database. They might visualise the data or identify 496 which component or link is likely to be the cause of a fault or 497 degradation. 499 The operator's OAM (Operations, Administration and Management) uses 500 the results from the tools. 502 6. IANA Considerations 504 This document makes no request of IANA. 506 Note to RFC Editor: this section may be removed on publication as an 507 RFC. 509 7. Security Considerations 511 The security of the LMAP framework should protect the interests of 512 the measurement operator(s), the network user(s) and other actors who 513 could be impacted by a compromised measurement deployment. 515 We assume that each Measurement Agent will receive test 516 configuration, scheduling and reporting instructions from a single 517 organisation (operator of the Controller). These instructions must 518 be authenticated (to ensure that they come from the trusted 519 Controller), checked for integrity (to ensure no-one has tampered 520 with them) and be prevented from replay. If a malicious party can 521 gain control of the Measurement Agent they can use the MA 522 capabilities to launch DoS attacks at targets, reduce the network 523 user experience and corrupt the measurement results that are reported 524 to the Collector. By altering the tests that are operated and/or the 525 Collector address they can also compromise the confidentiality of the 526 network user and the MA environment (such as information about the 527 location of devices or their traffic). 529 The reporting of the MA must also be secured to maintain 530 confidentiality. The results must be encrypted such that only the 531 authorised Collector can decrypt the results to prevent the leakage 532 of confidential or private information. In addition it must be 533 authenticated that the results have come from the expected MA and 534 that they have not been tampered with. It must not be possible to 535 spoof an MA to inject falsified data into the measurement platform or 536 to corrupt the results of a real MA. 538 Availability should also be considered. While the loss of some MAs 539 may not be considered critical, the unavailability of the Collector 540 could mean that valuable business data or data critical to a 541 regulatory process is lost. Similarly, the unavailability of a 542 Controller could mean that the MAs continue to operate an incorrect 543 test schedule or fail to initiate. 545 A malicious party could "game the system". For example, where a 546 regulator is running a measurement system in order to benchmark 547 operators, an operator could try to identify the broadband lines that 548 the regulator was measuring and prioritise that traffic. This 549 potential issue is currently handled by a code of conduct. It is 550 outside the scope of the LMAP WG to consider the issue. 552 Concerning privacy and data protection, the role of the LMAP 553 framework should be to ensure that only authorised data is collected 554 and that this data is returned securely to the framework operator. 555 Data should be stored securely and onward sharing of data to other 556 parties should be controlled according to local data protection 557 regulations. Depending upon the ownership/placement of the MA, local 558 data protection laws, the tests being operated and existing user 559 agreements, it is possible that additional consent may need to be 560 secured from parties such as the home broadband user. Having the 561 measurement system under the direction of a single organisation 562 clarifies the responsibility for data protection. 564 The next versions of [lmap-yang] and [lmap-ipfix] will also include 565 further consideration of security. 567 8. Acknowledgements 569 Thanks to numerous people for much discussion, directly and on the 570 LMAP list. This document tries to capture the current conclusions. 572 Philip Eardley and Trevor Burbridge work in part on the Leone 573 research project, which receives funding from the European Union 574 Seventh Framework Programme [FP7/2007-2013] under grant agreement 575 number 317647. 577 9. Changes 579 9.1. from -00 to -01 581 aligned with terminology in draft-eardley-lmap-terminology 583 introduced aspects mentioned in the LMAP WG charter 585 introduced aspects from the Information model in 586 draft-burbridge-lamp-information-model 588 10. Informative References 590 [RFC6241] "Network Configuration Protocol (NETCONF)", 591 . 593 [information-model] 594 Burbridge, T., Eardley, P., Bagnulo, M., and J. 595 Schoenwaelder, "Information Model for Large-Scale 596 Measurement Platforms (LMAP)", . 599 [lmap-ipfix] 600 "An LMAP application for IPFIX", 601 . 603 [lmap-netconf] 604 "Considerations on using NETCONF with LMAP Measurement 605 Agents", 606 . 608 [lmap-yang] 609 "A YANG Data Model for LMAP Measurement Agents", 610 . 612 [registry] 613 "A registry for commonly used metrics. Independent 614 registries", . 617 [schulzrinne] 618 "Large-Scale Measurement of Broadband Performance: Use 619 Cases, Architecture and Protocol Requirements", . 622 [use-cases] 623 "Large-Scale Broadband Measurement Use Cases", 624 . 626 [yang-api] 627 "YANG-API Protocol", . 629 Authors' Addresses 631 Philip Eardley 632 British Telecom 633 Adastral Park, Martlesham Heath 634 Ipswich 635 ENGLAND 637 Email: philip.eardley@bt.com 639 Trevor Burbridge 640 British Telecom 641 Adastral Park, Martlesham Heath 642 Ipswich 643 ENGLAND 645 Email: trevor.burbridge@bt.com 647 Al Morton 648 AT&T Labs 649 200 Laurel Avenue South 650 Middletown, NJ 651 USA 653 Email: acmorton@att.com