idnits 2.17.1 draft-ietf-ippm-lmap-path-04.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 (June 19, 2014) is 3600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational T. Burbridge 5 Expires: December 21, 2014 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 June 19, 2014 14 A Reference Path and Measurement Points for LMAP 15 draft-ietf-ippm-lmap-path-04 17 Abstract 19 This document defines a reference path for Large-scale Measurement of 20 Broadband Access Performance (LMAP) and measurement points for 21 commonly used performance metrics. The methods for measurement point 22 location may be applicable to similar measurement projects using the 23 extensions described here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 21, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 66 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 67 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 4 68 3.6. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 5 69 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 71 6. Translation Between Reference Path and Various Technologies . 10 72 7. Example Resource Transition . . . . . . . . . . . . . . . . . 11 73 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 11.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document defines a reference path for Large-scale Measurement of 84 Broadband Access Performance (LMAP) or similar measurement projects. 85 The series of IP Performance Metrics (IPPM) RFCs have developed terms 86 that are generally useful for path description (section 5 of 87 [RFC2330]). There are a limited number of additional terms needing 88 definition here, and they will be defined in this memo. 90 The reference path is usually needed when attempting to communicate 91 precisely about the components that comprise the path, often in terms 92 of their number (hops) and geographic location. This memo takes the 93 path definition further, by establishing a set of measurement points 94 along the path and ascribing a unique designation to each point. 95 This topic has been previously developed in section 5.1 of [RFC3432], 96 and as part of the updated framework for composition and aggregation, 97 section 4 of [RFC5835] (which may also figure in the LMAP work 98 effort). Section 4.1 of [RFC5835] defines the term "measurement 99 point". 101 Measurement points and the paths they cover are often described in 102 general terms, like "end-to-end", "user-to-user", or "access". These 103 terms alone are insufficient for scientific method: What is an end? 104 Where is a user located? Is the home network included? 106 The motivation for this memo is to provide an unambiguous framework 107 to describe measurement coverage, or scope of the reference path. 108 This is an essential part of the meta-data to describe measurement 109 results. Measurements conducted over different path scopes are not a 110 valid basis for performance comparisons. We note that additional 111 measurement context information may be necessary to support a valid 112 comparison of results. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. Purpose and Scope 122 The scope of this memo is to define a reference path for LMAP 123 activities with sufficient level of detail to determine the location 124 of different measurement points along a path without ambiguity. 125 These conventions are likely to be useful in other measurement 126 projects as well. 128 The connection between the reference path and specific network 129 technologies (with differing underlying architectures) is within the 130 scope of this method, and examples are provided. Both wired and 131 wireless technologies are in-scope. 133 The purpose is to create an efficient way to describe the location of 134 the measurement point(s) used to conduct a particular measurement so 135 that the measurement result will adequately described in terms of 136 scope or coverage. This should serve many measurement uses, 137 including: 139 diagnostic: where the same metric may be measured over many 140 different path scopes 142 comparison: where the same metric may be measured on equivalent 143 portions of different network infrastructures 145 3. Terms and Definitions 147 This section defines key terms and concepts for the purposes of this 148 memo. 150 3.1. Reference Path 152 A reference path is a serial combination of routers, switches, links, 153 radios, and processing elements that comprise all the network 154 elements traversed by each packet between the source and destination 155 hosts. The reference path is intended to be equally applicable to 156 all networking technologies, therefore the components are generically 157 defined, but their functions should have a clear counterpart or be 158 obviously omitted in any network technology. 160 3.2. Subscriber 162 An entity (associated with one or more users) that is engaged in a 163 subscription with a service provider. The subscriber is allowed to 164 subscribe and un-subscribe services, and to register a user or a list 165 of users authorized to enjoy these services. [Q1741] Both the 166 subscriber and service provider are allowed to set the limits 167 relative to the use that associated users make of subscribed 168 services. 170 3.3. Dedicated Component (Links or Nodes) 172 All resources of a Dedicated component (typically a link or node on 173 the Reference Path) are allocated to serving the traffic of an 174 individual Subscriber. Resources include transmission time-slots, 175 queue space, processing for encapsulation and address/port 176 translation, and others. A Dedicated component can affect the 177 performance of the Reference Path, or the performance of any sub-path 178 where the component is involved. 180 3.4. Shared Component (Links or Nodes) 182 A component on the Reference Path is designated a Shared component 183 when the traffic associated with multiple Subscribers is served by 184 common resources. 186 3.5. Resource Transition Point 188 A point between Dedicated and Shared components on a Reference Path 189 that may be a point of significance, and is identified as a 190 transition between two types of resources. 192 3.6. Managed and Un-Managed Sub-paths 194 Service providers are responsible for the portion of the path they 195 manage. However, most paths involve a sub-path which is beyond the 196 management of the subscriber's service provider. This means that 197 private networks, wireless networks using unlicensed frequencies, and 198 the networks of other service are designated as un-managed sub-paths. 199 The Service demarcation point always divides managed and un-managed 200 sub-paths. 202 4. Reference Path 204 This section defines a reference path for Internet communication. 206 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 207 device Net #1 Net #2 Demarc. Access GW GRA GW 209 ... Transit -- GRA -- Service -- Private -- Private -- Destination 210 GRA GW GW Demarc. Net #n Net #n+1 Host 212 GRA = Globally Routable Address, GW = Gateway 214 The following are descriptions of reference path components that may 215 not be clear from their name alone. 217 o Subsc. (Subscriber) device - This is a host that normally 218 originates and terminates communications conducted over the IP 219 packet transfer service. 221 o Private Net #x - This is a network of devices owned and operated 222 by the Internet Service Subscriber. In some configurations, one 223 or more private networks and the device that provides the Service 224 Demarcation point are collapsed in a single device (and ownership 225 may shift to the service provider), and this should be noted as 226 part of the path description. 228 o Service Demarcation point - This is the point where service 229 managed by the serivce provider begins (or ends), and varies by 230 technology. For example, this point is usually defined as the 231 Ethernet interface on a residential gateway or modem where the 232 scope of a packet transfer service begins and ends. In the case 233 of a WiFi Service, this would be an Air Interface within the 234 intended service boundary (e.g., walls of the coffee shop). The 235 Demarcation point may be within an integrated endpoint using an 236 Air Interface (e.g., LTE UE). Ownership may not affect the 237 demarcation point; a Subscriber may own all equipment on their 238 premises, but it is likely that the service provider will certify 239 such equipment for connection to their network, or a third-party 240 will certify standards compliance. 242 o Intra IP Access - This is the first point in the access 243 architecture beyond the Service Demarc. where a globally routable 244 IP address is exposed and used for routing. In architectures that 245 use tunneling, this point may be equivalent to the GRA GW. This 246 point could also collapse to the device providing the Service 247 Demarc., in principle. Only one Intra IP Access point is shown, 248 but they can be identified in any access network. 250 o GRA GW - the point of interconnection between a Service Provider's 251 administrative domain and the rest of the Internet, where routing 252 will depend on the GRAs in the IP header. 254 o Transit GRA GW - If one or more networks intervene between the 255 Service Provider's access networks of the Subscriber and of the 256 Destination Host, then such networks are designated "transit" and 257 are bounded by two Transit GRA GW. 259 Use of multiple IP address families in the measurement path must be 260 noted, as the conversions between IPv4 and IPv6 certainly influence 261 the visibility of a GRA for each family. 263 In the case that a private address space is used throughout an access 264 architecture, then the Service Demarc. and the Intra IP Access points 265 must use the same address space and be separated by the shared and 266 dedicated access link infrastructure, such that a test between these 267 points produces a useful assessment of access performance. 269 5. Measurement Points 271 A key aspect of measurement points, beyond the definition in section 272 4.1 of [RFC5835], is that the innermost IP header and higher layer 273 information must be accessible through some means. This is essential 274 to measure IP metrics. There may be tunnels and/or other layers 275 which encapsulate the innermost IP header, even adding another IP 276 header of their own. 278 In general, measurement points cannot always be located exactly where 279 desired. However, the definition in [RFC5835] and the discussion in 280 section 5.1 of [RFC3432] indicate that allowances can be made: for 281 example, it is nearly ideal when there are deterministic errors that 282 can be quantified between desired and actual measurement point. 284 The Figure below illustrates the assignment of measurement points to 285 selected components of the reference path. 287 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 288 device Net #1 Net #2 Demarc. Access GW GRA GW 289 mp000 mp100 mp150 mp190 mp200 291 ... Transit -- GRA -- Service -- Private -- Private -- Destination 292 GRA GW GW Demarc. Net #n Net #n+1 Host 293 mpX90 mp890 mp800 mp900 295 GRA = Globally Routable Address, GW = Gateway 297 Figure 1 299 When communicating the results of measurements using the measurement 300 point designations described here, the measuring organization SHOULD 301 supply a diagram similar to Figure 1 (and the technology-specific 302 examples that follow), and MUST supply it when additional measurement 303 point numbers have been defined and used, with sufficient detail to 304 identify measurement locations in the path. Organizations with 305 similar technologies and architectures are encouraged to coordinate 306 on local numbering and diagrams, when possible. 308 The measurement point numbering system, mpXnn, has two independent 309 parts: 311 1. The X in mpXnn indicates the network number. The network with 312 the Subscriber's device is network 0. The network of a different 313 organization (administrative or ownership domains) SHOULD be 314 assigned a different number. Each successive network number 315 SHOULD be one greater than the previous network's number. Two 316 circumstances make it necessary to designate X=9 in the 317 Destination Host's network and X=8 for the Service Provider 318 network at the Destination: 320 A. The number of Transit networks is unknown. 322 B. The number of Transit networks varies over time. 324 2. The nn in mpXnn indicates the measurement point and is locally- 325 assigned by network X. The following conventions are suggested: 327 A. 00 SHOULD be used for a measurement point at the Subscriber's 328 device and at the Service Demarcation point or GW nearest to 329 the Subscriber's device for Transit Networks. 331 B. 90 SHOULD be used for a measurement point at the GW of a 332 network (opposite from the Subscriber's device or Service 333 Demarc.). 335 C. In most networks, measurement point numbers SHOULD 336 monotonically increase from point nearest the Subscriber's 337 device to the opposite network boundary on the path (see 338 below). 340 D. When a Detination host is part of the path, 00 SHOULD be used 341 for a measurement point at the Destination host and at the 342 the Destination's Service Demarcation point. Measurement 343 point numbers SHOULD monotonically increase from point 344 nearest the Destination's host to the opposite network 345 boundary on the path ONLY in these networks. This 346 directional numbering reversal allows consistent 00 347 designation for end hosts and Service Demarcs. 349 E. 50 MAY be used for an intermediate measurement point of 350 significance, such as a Network Address Translator (NAT). 352 F. 20 MAY be used for a traffic aggregation point such as a 353 DSLAM within a network. 355 G. Any other measurement points SHOULD be assigned unused 356 integers between 01 and 99. The assignment SHOULD be stable 357 for at least the duration of a particular measurement study, 358 and SHOULD avoid numbers that have been assigned to other 359 locations within network X (unless the assignment is 360 considered sufficiently stale). Sub-networks or domains 361 within a network are useful locations for measurement points. 363 In order to define the measurement points and the scope of 364 measurements without ambiguity, the operator of the measurement 365 system SHOULD indicate on a diagram (similar to those in this 366 document): the reference path, the numbers (mpXnn) of the measurement 367 points, and the definition of any measurement point other than 00 and 368 90 (with sufficient detail to clearly define its location). 370 If the number of intermediate networks (between the source and 371 destination) is not known or is unstable, then this SHOULD be 372 indicated on the diagram and results from measurement points within 373 those networks need to be treated with caution. 375 Notes: 377 o Some use the terminology "on-net" and "off-net" when referring to 378 the Subscriber's Internet Service Provider (ISP) measurement 379 coverage. With respect to the reference path, tests between mp100 380 and mp190 are "on-net". 382 o Widely deployed broadband Internet access measurements have used 383 pass-through devices[SK] (at the subscriber's location) directly 384 connected to the service demarcation point: this would be located 385 at mp100. 387 o The networking technology must be indicated for the measurement 388 points used, especially the interface standard and configured 389 speed (because the measurement connectivity itself can be a 390 limiting factor for the results). 392 o If it can be shown that a link connecting to a measurement point 393 has reliably deterministic performance or negligible impairments, 394 then the remote end of the connecting link is an equivalent point 395 for some methods of measurement (To Be Specified Elsewhere). In 396 any case, the presence of a link and claimed equivalent 397 measurement point must be reported. 399 o Some access network architectures may have an additional traffic 400 aggregation device between mp100 and mp150. Use of a measurement 401 point at this location would require a local number and diagram. 403 o A Carrier Grade NAT (CGN) deployed in the Service Provider's 404 access network would be positioned between mp100 and mp190, and 405 the egress side of the CGN may be designated mp150. mp150 is 406 generally an intermediate measurement point in the same address 407 space as mp190. 409 o In the case that private address space is used in an access 410 architecture, then mp100 may need to use the same address space as 411 its "on-net" measurement point counterpart, so that a test between 412 these points produces a useful assessment of network performance. 413 Tests between mp000 and mp100 could use a different private 414 address space, and when the globally-routable side of a CGN is at 415 mp150, then the private address side of the CGN could be 416 designated mp149 for tests with mp100. 418 o Measurement points at Transit GRA GWs are numbered mpX00 and 419 mpX90, where X is the lowest positive integer not already used in 420 the path. The GW of first transit network is shown, with point 421 mp200 and the last transit network GW with mpX90. 423 6. Translation Between Reference Path and Various Technologies 425 This section and those that follow are intended to provide a more 426 exact mapping between particular network technologies and the 427 reference path. 429 We provide an example for 3G Cellular access below. 431 Subscriber -- Private --- Service ------------- GRA --- Transit ... 432 device Net #1 Demarc. GW GRA GW 433 mp000 mp100 mp190 mp200 435 |_____________UE______________|___RAN+Core____|___GGSN__| 436 |_____Un-managed sub-path_____|____Managed sub-path_____| 438 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 439 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 441 We next provide an example of DSL access. Consider the case where: 443 o The Customer Premises Equipment (CPE) has a NAT device that is 444 configured with a public IP address. 446 o The CPE is a home router that has also an incorporated a WiFi 447 access point and this is the only networking device in the home 448 network, all endpoints attach directly to the CPE though the WiFi 449 access. 451 We believe this is a fairly common configuration in some parts of the 452 world and fairly simple as well. 454 This case would map into the defined reference measurement points as 455 follows: 457 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 458 device Net #1 Net #2 Demarc. Access GW GRA GW 459 mp000 mp100 mp150 mp190 mp200 460 |--UE--|------------CPE/NAT--------|------|-BRAS-|------| 461 |------DSL Network---| 462 |_______Un-managed sub-path________|__Managed sub-path__| 464 GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband 465 Remote Acess Server 467 Consider next another access network case where: 469 o The Customer Premises Equipment (CPE) is a NAT device that is 470 configured with a private IP address. 472 o There is a Carrier Grade NAT (CGN) located deep in the Access ISP 473 network. 475 o The CPE is a home router that has also an incorporated a WiFi 476 access point and this is the only networking device in the home 477 network, all endpoints attach directly to the CPE though the WiFi 478 access. 480 We believe this is becoming a fairly common configuration in some 481 parts of the world. 483 This case would map into the defined reference measurement points as 484 follows: 486 Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit 487 device Net #1 Demarc. Access GW GRA GW 488 mp000 mp100 mp150 mp190 mp200 489 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 490 |--Access Network---| 491 |_______Un-managed sub-path________|_Managed sub-path__| 493 GRA = Globally Routable Address, GW = Gateway 495 7. Example Resource Transition 497 This section gives an example of Shared and Dedicated portions with 498 the reference path. This example shows two Resource Transition 499 Points. 501 Consider the case where: 503 o The CPE is wired Residential GW and modem (Private Net#2) 504 connected to a WiFi access point (Private Net#1). The Subscriber 505 device (UE) attaches to the CPE though the WiFi access. 507 o The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio 508 channel resources with other W-Fi access networks (and potentially 509 other sources of interference), thus this is a Shared portion of 510 the path. 512 o The wired subnetwork (Private Net#2) and a portion of the Service 513 Provider's Network are Dedicated Resources (for a single 514 Subscriber), thus there is a Resource Transition Point between 515 (Private Net#1) and (Private Net#2). 517 o Subscriber traffic shares common resources with other subscribers 518 upon reaching the Carrier Grade NAT (CGN), thus there is a 519 Resource Transition Point and further network components are 520 designated as Shared Resources. 522 We believe this is a fairly common configuration in parts of the 523 world. 525 This case would map into the defined reference measurement points as 526 follows: 528 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 529 device Net #1 Net #2 Demarc. Access GW GRA GW 530 mp000 mp100 mp150 mp190 mp200 531 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 532 | Wi-Fi | 1000Base-T |--Access Network---| 534 |-Shared--|RT|------Dedicated------| RT |-----Shared------... 535 |_______Un-managed sub-path________|_Managed sub-path__| 537 GRA = Globally Routable Address, GW = Gateway, RT = Resource 538 Transition Point 540 8. Security considerations 542 Specification of a Reference Path and identification of measurement 543 points on the path represent agreements among interested parties, and 544 they present no threat to the readers of this memo or to the Internet 545 itself. 547 When considering privacy of those involved in measurement or those 548 whose traffic is measured, there is sensitive information 549 communicated to recipients of the network diagrams illustrating paths 550 and measurement points described above. We refer the reader to the 551 privacy considerations described in the Large Scale Measurement of 552 Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], 553 which covers active and passive measurement techniques and supporting 554 material on measurement context. 556 9. IANA Considerations 558 This memo makes no requests for IANA consideration. 560 10. Acknowledgements 562 Thanks to Matt Mathis, Charles Cook, Dan Romascanu, and Lingli Deng 563 for review and comments. 565 11. References 567 11.1. Normative References 569 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 570 "Framework for IP Performance Metrics", RFC 2330, May 571 1998. 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, March 1997. 576 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 577 performance measurement with periodic streams", RFC 3432, 578 November 2002. 580 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 581 Composition", RFC 5835, April 2010. 583 11.2. Informative References 585 [I-D.ietf-lmap-framework] 586 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 587 Aitken, P., and A. Akhter, "A framework for large-scale 588 measurement platforms (LMAP)", draft-ietf-lmap- 589 framework-06 (work in progress), June 2014. 591 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 592 Whitebox Briefing Note 593 http://www.samknows.com/broadband/index.php, July 2011. 595 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 596 evolved UMTS core network", 597 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 599 Authors' Addresses 600 Marcelo Bagnulo 601 Universidad Carlos III de Madrid 602 Av. Universidad 30 603 Leganes, Madrid 28911 604 SPAIN 606 Phone: 34 91 6249500 607 Email: marcelo@it.uc3m.es 608 URI: http://www.it.uc3m.es 610 Trevor Burbridge 611 BT 612 Adastral Park, Martlesham Heath 613 Ipswich 614 ENGLAND 616 Email: trevor.burbridge@bt.com 618 Sam Crawford 619 SamKnows 621 Email: sam@samknows.com 623 Phil Eardley 624 BT 625 Adastral Park, Martlesham Heath 626 Ipswich 627 ENGLAND 629 Email: philip.eardley@bt.com 631 Al Morton 632 AT&T Labs 633 200 Laurel Avenue South 634 Middletown, NJ 635 USA 637 Email: acmorton@att.com