idnits 2.17.1 draft-ietf-ippm-lmap-path-03.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 289: '...ere, the measuring organization SHOULD...' RFC 2119 keyword, line 291: '...hat follow), and MUST supply it when a...' RFC 2119 keyword, line 302: '...rative or ownership domains) SHOULD be...' RFC 2119 keyword, line 304: '... SHOULD be one greater than the ...' RFC 2119 keyword, line 316: '... A. 00 SHOULD be used for a mea...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 128 has weird spacing: '...gnostic where...' == Line 131 has weird spacing: '...parison where...' -- The document date (May 28, 2014) is 3622 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-05 Summary: 1 error (**), 0 flaws (~~), 4 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: November 29, 2014 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 May 28, 2014 14 A Reference Path and Measurement Points for LMAP 15 draft-ietf-ippm-lmap-path-03 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 November 29, 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 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 65 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 66 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 4 67 3.6. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 4 68 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 70 6. Translation Between Reference Path and Various Technologies . 10 71 7. Example Resource Transition . . . . . . . . . . . . . . . . . 11 72 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 11.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 This document defines a reference path for Large-scale Measurement of 83 Broadband Access Performance (LMAP) or similar measurement projects. 84 The series of IP Performance Metrics (IPPM) RFCs have developed terms 85 that are generally useful for path description (section 5 of 86 [RFC2330]). There are a limited number of additional terms needing 87 definition here, and they will be defined in this memo. 89 The reference path is usually needed when attempting to communicate 90 precisely about the components that comprise the path, often in terms 91 of their number (hops) and geographic location. This memo takes the 92 path definition further, by establishing a set of measurement points 93 along the path and ascribing a unique designation to each point. 94 This topic has been previously developed in section 5.1 of [RFC3432], 95 and as part of the updated framework for composition and aggregation, 96 section 4 of [RFC5835] (which may also figure in the LMAP work 97 effort). Section 4.1 of [RFC5835] defines the term "measurement 98 point". 100 Measurement points and the paths they cover are often described in 101 general terms, like "end-to-end", "user-to-user", or "access". These 102 terms alone are insufficient for scientific method: What is an end? 103 Where is a user located? Is the home network included? 105 The motivation for this memo is to provide an unambiguous framework 106 to describe measurement coverage, or scope of the reference path. 107 This is an essential part of the meta-data to describe measurement 108 results. Measurements conducted over different path scopes are not a 109 valid basis for performance comparisons. 111 2. Purpose and Scope 113 The scope of this memo is to define a reference path for LMAP 114 activities with sufficient level of detail to determine the location 115 of different measurement points along a path without ambiguity. 117 The connection between the reference path and specific network 118 technologies (with differing underlying architectures) is within the 119 scope of this method, and examples are provided. Both wired and 120 wireless technologies are in-scope. 122 The purpose is to create an efficient way to describe the location of 123 the measurement point(s) used to conduct a particular measurement so 124 that the measurement result will adequately described in terms of 125 scope or coverage. This should serve many measurement uses, 126 including: 128 diagnostic where the same metric may be measured over many different 129 path scopes 131 comparison where the same metric may be measured on equivalent 132 portions of different network infrastructures 134 3. Terms and Definitions 136 This section defines key terms and concepts for the purposes of this 137 memo. 139 3.1. Reference Path 141 A reference path is a serial combination of routers, switches, links, 142 radios, and processing elements that comprise all the network 143 elements traversed by each packet between the source and destination 144 hosts. The reference path is intended to be equally applicable to 145 all networking technologies, therefore the components are generically 146 defined, but their functions should have a clear counterpart or be 147 obviously omitted in any network technology. 149 3.2. Subscriber 151 An entity (associated with one or more users) that is engaged in a 152 subscription with a service provider. The subscriber is allowed to 153 subscribe and un-subscribe services, and to register a user or a list 154 of users authorized to enjoy these services. [Q1741] Both the 155 subscriber and service provider are allowed to set the limits 156 relative to the use that associated users make of subscribed 157 services. 159 3.3. Dedicated Component (Links or Nodes) 161 All resources of a Dedicated component (typically a link or node on 162 the Reference Path) are allocated to serving the traffic of an 163 individual Subscriber. Resources include transmission time-slots, 164 queue space, processing for encapsulation and address/port 165 translation, and others. A Dedicated component can affect the 166 performance of the Reference Path, or the performance of any sub-path 167 where the component is involved. 169 3.4. Shared Component (Links or Nodes) 171 A component on the Reference Path is designated a Shared component 172 when the traffic associated with multiple Subscribers is served by 173 common resources. 175 3.5. Resource Transition Point 177 A point between Dedicated and Shared components on a Reference Path 178 that may be a point of significance, and is identified as a 179 transition between two types of resources. 181 3.6. Managed and Un-Managed Sub-paths 183 Service providers are responsible for the portion of the path they 184 manage. However, most paths involve a sub-path which is beyond the 185 management of the subscriber's service provider. This means that 186 private networks, wireless networks using unlicensed frequencies, and 187 the networks of other service are designated as un-managed sub-paths. 188 The Service demarcation point always divides managed and un-managed 189 sub-paths. 191 4. Reference Path 193 This section defines a reference path for Internet communication. 195 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 196 device Net #1 Net #2 Demarc. Access GW GRA GW 198 ... Transit -- GRA -- Service -- Private -- Private -- Destination 199 GRA GW GW Demarc. Net #n Net #n+1 Host 201 GRA = Globally Routable Address, GW = Gateway 203 The following are descriptions of reference path components that may 204 not be clear from their name alone. 206 o Subsc. (Subscriber) device - This is a host that normally 207 originates and terminates communications conducted over the IP 208 packet transfer service. 210 o Private Net #x - This is a network of devices owned and operated 211 by the Internet Service Subscriber. In some configurations, one 212 or more private networks and the device that provides the Service 213 Demarcation point are collapsed in a single device (and ownership 214 may shift to the service provider), and this should be noted as 215 part of the path description. 217 o Service Demarcation point - This is the point where service 218 managed by the serivce provider begins (or ends), and varies by 219 technology. For example, this point is usually defined as the 220 Ethernet interface on a residential gateway or modem where the 221 scope of a packet transfer service begins and ends. In the case 222 of a WiFi Service, this would be an Air Interface within the 223 intended service boundary (e.g., walls of the coffee shop). The 224 Demarcation point may be within an integrated endpoint using an 225 Air Interface (e.g., LTE UE). Ownership may not affect the 226 demarcation point; a Subscriber may own all equipment on their 227 premises, but it is likely that the service provider will certify 228 such equipment for connection to their network, or a third-party 229 will certify standards compliance. 231 o Intra IP Access - This is the first point in the access 232 architecture beyond the Service Demarc. where a globally routable 233 IP address is exposed and used for routing. In architectures that 234 use tunneling, this point may be equivalent to the GRA GW. This 235 point could also collapse to the device providing the Service 236 Demarc., in principle. Only one Intra IP Access point is shown, 237 but they can be identified in any access network. 239 o GRA GW - the point of interconnection between a Service Provider's 240 administrative domain and the rest of the Internet, where routing 241 will depend on the GRAs in the IP header. 243 o Transit GRA GW - If one or more networks intervene between the 244 Service Provider's access networks of the Subscriber and of the 245 Destination Host, then such networks are designated "transit" and 246 are bounded by two Transit GRA GW. 248 Use of multiple IP address families in the measurement path must be 249 noted, as the conversions between IPv4 and IPv6 certainly influence 250 the visibility of a GRA for each family. 252 In the case that a private address space is used throughout an access 253 architecture, then the Service Demarc. and the Intra IP Access points 254 must use the same address space and be separated by the shared and 255 dedicated access link infrastructure, such that a test between these 256 points produces a useful assessment of access performance. 258 5. Measurement Points 260 A key aspect of measurement points, beyond the definition in section 261 4.1 of [RFC5835], is that the innermost IP header and higher layer 262 information must be accessible through some means. This is essential 263 to measure IP metrics. There may be tunnels and/or other layers 264 which encapsulate the innermost IP header, even adding another IP 265 header of their own. 267 In general, measurement points cannot always be located exactly where 268 desired. However, the definition in [RFC5835] and the discussion in 269 section 5.1 of [RFC3432] indicate that allowances can be made: for 270 example, it is nearly ideal when there are deterministic errors that 271 can be quantified between desired and actual measurement point. 273 The Figure below illustrates the assignment of measurement points to 274 selected components of the reference path. 276 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 277 device Net #1 Net #2 Demarc. Access GW GRA GW 278 mp000 mp100 mp150 mp190 mp200 280 ... Transit -- GRA -- Service -- Private -- Private -- Destination 281 GRA GW GW Demarc. Net #n Net #n+1 Host 282 mpX90 mp890 mp800 mp900 284 GRA = Globally Routable Address, GW = Gateway 286 Figure 1 288 When communicating the results of measurements using the measurement 289 point designations described here, the measuring organization SHOULD 290 supply a diagram similar to Figure 1 (and the technology-specific 291 examples that follow), and MUST supply it when additional measurement 292 point numbers have been defined and used, with sufficient detail to 293 identify measurement locations in the path. Organizations with 294 similar technologies and architectures are encouraged to coordinate 295 on local numbering and diagrams, when possible. 297 The measurement point numbering system, mpXnn, has two independent 298 parts: 300 1. The X in mpXnn indicates the network number. The network with 301 the Subscriber's device is network 0. The network of a different 302 organization (administrative or ownership domains) SHOULD be 303 assigned a different number. Each successive network number 304 SHOULD be one greater than the previous network's number. Two 305 circumstances make it necessary to designate X=9 in the 306 Destination Host's network and X=8 for the Service Provider 307 network at the Destination: 309 A. The number of Transit networks is unknown. 311 B. The number of Transit networks varies over time. 313 2. The nn in mpXnn indicates the measurement point and is locally- 314 assigned by network X. The following conventions are suggested: 316 A. 00 SHOULD be used for a measurement point at the Subscriber's 317 device and at the Service Demarcation point or GW nearest to 318 the Subscriber's device for Transit Networks. 320 B. 90 SHOULD be used for a measurement point at the GW of a 321 network (opposite from the Subscriber's device or Service 322 Demarc.). 324 C. In most networks, measurement point numbers SHOULD 325 monotonically increase from point nearest the Subscriber's 326 device to the opposite network boundary on the path (see 327 below). 329 D. When a Detination host is part of the path, 00 SHOULD be used 330 for a measurement point at the Destination host and at the 331 the Destination's Service Demarcation point. Measurement 332 point numbers SHOULD monotonically increase from point 333 nearest the Destination's host to the opposite network 334 boundary on the path ONLY in these networks. This 335 directional numbering reversal allows consistent 00 336 designation for end hosts and Service Demarcs. 338 E. 50 MAY be used for an intermediate measurement point of 339 significance, such as a Network Address Translator (NAT). 341 F. 20 MAY be used for a traffic aggregation point such as a 342 DSLAM within a network. 344 G. Any other measurement points SHOULD be assigned unused 345 integers between 01 and 99. The assignment SHOULD be stable 346 for at least the duration of a particular measurement study, 347 and SHOULD avoid numbers that have been assigned to other 348 locations within network X (unless the assignment is 349 considered sufficiently stale). Sub-networks or domains 350 within a network are useful locations for measurement points. 352 In order to define the measurement points and the scope of 353 measurements without ambiguity, the operator of the measurement 354 system SHOULD indicate on a diagram (similar to those in this 355 document): the reference path, the numbers (mpXnn) of the measurement 356 points, and the definition of any measurement point other than 00 and 357 90 (with sufficient detail to clearly define its location). 359 If the number of intermediate networks (between the source and 360 destination) is not known or is unstable, then this SHOULD be 361 indicated on the diagram and results from measurement points within 362 those networks need to be treated with caution. 364 Notes: 366 o Some use the terminology "on-net" and "off-net" when referring to 367 the Subscriber's Internet Service Provider (ISP) measurement 368 coverage. With respect to the reference path, tests between mp100 369 and mp190 are "on-net". 371 o Widely deployed broadband Internet access measurements have used 372 pass-through devices[SK] (at the subscriber's location) directly 373 connected to the service demarcation point: this would be located 374 at mp100. 376 o The networking technology must be indicated for the measurement 377 points used, especially the interface standard and configured 378 speed (because the measurement connectivity itself can be a 379 limiting factor for the results). 381 o If it can be shown that a link connecting to a measurement point 382 has reliably deterministic performance or negligible impairments, 383 then the remote end of the connecting link is an equivalent point 384 for some methods of measurement (To Be Specified Elsewhere). In 385 any case, the presence of a link and claimed equivalent 386 measurement point must be reported. 388 o Some access network architectures may have an additional traffic 389 aggregation device between mp100 and mp150. Use of a measurement 390 point at this location would require a local number and diagram. 392 o A Carrier Grade NAT (CGN) deployed in the Service Provider's 393 access network would be positioned between mp100 and mp190, and 394 the egress side of the CGN may be designated mp150. mp150 is 395 generally an intermediate measurement point in the same address 396 space as mp190. 398 o In the case that private address space is used in an access 399 architecture, then mp100 may need to use the same address space as 400 its "on-net" measurement point counterpart, so that a test between 401 these points produces a useful assessment of network performance. 402 Tests between mp000 and mp100 could use a different private 403 address space, and when the globally-routable side of a CGN is at 404 mp150, then the private address side of the CGN could be 405 designated mp149 for tests with mp100. 407 o Measurement points at Transit GRA GWs are numbered mpX00 and 408 mpX90, where X is the lowest positive integer not already used in 409 the path. The GW of first transit network is shown, with point 410 mp200 and the last transit network GW with mpX90. 412 6. Translation Between Reference Path and Various Technologies 414 This section and those that follow are intended to provide a more 415 exact mapping between particular network technologies and the 416 reference path. 418 We provide an example for 3G Cellular access below. 420 Subscriber -- Private --- Service ------------- GRA --- Transit ... 421 device Net #1 Demarc. GW GRA GW 422 mp000 mp100 mp190 mp200 424 |_____________UE______________|___RAN+Core____|___GGSN__| 425 |_____Un-managed sub-path_____|____Managed sub-path_____| 427 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 428 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 430 We next provide a few examples of DSL access. Consider first the 431 case where: 433 o The Customer Premises Equipment (CPE) has a NAT device that is 434 configured with a public IP address. 436 o The CPE is a home router that has also an incorporated a WiFi 437 access point and this is the only networking device in the home 438 network, all endpoints attach directly to the CPE though the WiFi 439 access. 441 We believe this is a fairly common configuration in some parts of the 442 world and fairly simple as well. 444 This case would map into the defined reference measurement points as 445 follows: 447 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit 448 device Net #1 Net #2 Demarc. Access GW GRA GW 449 mp000 mp100 mp150 mp190 mp200 450 |--UE--|------------CPE/NAT--------|------|-BRAS-|------| 451 |------DSL Network---| 452 |_______Un-managed sub-path________|__Managed sub-path__| 454 GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband 455 Remote Acess Server 457 Consider next the case where: 459 o The Customer Premises Equipment (CPE) is a NAT device that is 460 configured with a private IP address. 462 o There is a Carrier Grade NAT (CGN) located deep into the Access 463 ISP network. 465 o The CPE is a home router that has also an incorporated a WiFi 466 access point and this is the only networking device in the home 467 network, all endpoints attach directly to the CPE though the WiFi 468 access. 470 We believe this is becoming a fairly common configuration in some 471 parts of the world. 473 This case would map into the defined reference measurement points as 474 follows: 476 Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit 477 device Net #1 Demarc. Access GW GRA GW 478 mp000 mp100 mp150 mp190 mp200 479 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 480 |-----DSL Network---| 481 |_______Un-managed sub-path________|_Managed sub-path__| 483 GRA = Globally Routable Address, GW = Gateway 485 7. Example Resource Transition 487 This section gives an example of Shared and Dedicated portions with 488 the reference path. This example shows two Resource Transition 489 Points. 491 Consider the case where: 493 o The CPE is wired Residential GW and modem (Private Net#2) 494 connected to a WiFi access point (Private Net#1). The Subscriber 495 device (UE) attaches to the CPE though the WiFi access. 497 o The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio 498 channel resources with other W-Fi access networks (and potentially 499 other sources of interference), thus this is a Shared portion of 500 the path. 502 o The wired subnetwork (Private Net#2) and a portion of the Service 503 Provider's Network are Dedicated Resources (for a single 504 Subscriber), thus there is a Resource Transition Point between 505 (Private Net#1) and (Private Net#2). 507 o Subscriber traffic shares common resources with other subscribers 508 upon reaching the Carrier Grade NAT (CGN), thus there is a 509 Resource Transition Point and further network components are 510 designated as Shared Resources. 512 We believe this is a fairly common configuration in parts of the 513 world. 515 This case would map into the defined reference measurement points as 516 follows: 518 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 519 device Net #1 Net #2 Demarc. Access GW GRA GW 520 mp000 mp100 mp150 mp190 mp200 521 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 522 | Wi-Fi | 1000Base-T |-----DSL Network---| 524 |-Shared--|RT|------Dedicated------| RT |-----Shared------... 525 |_______Un-managed sub-path________|_Managed sub-path__| 527 GRA = Globally Routable Address, GW = Gateway, RT = Resource 528 Transition Point 530 8. Security considerations 532 Specification of a Reference Path and identification of measurement 533 points on the path represent agreements among interested parties, and 534 they present no threat to the readers of this memo or to the Internet 535 itself. 537 When considering privacy of those involved in measurement or those 538 whose traffic is measured, there is sensitive information 539 communicated to recipients of the network diagrams illustrating paths 540 and measurement points described above. We refer the reader to the 541 privacy considerations described in the Large Scale Measurement of 542 Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], 543 which covers active and passive measurement techniques and supporting 544 material on measurement context. 546 9. IANA Considerations 548 This memo makes no requests for IANA consideration. 550 10. Acknowledgements 552 Thanks to Matt Mathis, Charles Cook, Dan Romascanu, and Lingli Deng 553 for review and comments. 555 11. References 557 11.1. Normative References 559 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 560 "Framework for IP Performance Metrics", RFC 2330, May 561 1998. 563 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 564 performance measurement with periodic streams", RFC 3432, 565 November 2002. 567 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 568 Composition", RFC 5835, April 2010. 570 11.2. Informative References 572 [I-D.ietf-lmap-framework] 573 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 574 Aitken, P., and A. Akhter, "A framework for large-scale 575 measurement platforms (LMAP)", draft-ietf-lmap- 576 framework-05 (work in progress), May 2014. 578 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 579 Whitebox Briefing Note 580 http://www.samknows.com/broadband/index.php, July 2011. 582 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 583 evolved UMTS core network", 584 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 586 Authors' Addresses 588 Marcelo Bagnulo 589 Universidad Carlos III de Madrid 590 Av. Universidad 30 591 Leganes, Madrid 28911 592 SPAIN 594 Phone: 34 91 6249500 595 Email: marcelo@it.uc3m.es 596 URI: http://www.it.uc3m.es 597 Trevor Burbridge 598 BT 599 Adastral Park, Martlesham Heath 600 Ipswich 601 ENGLAND 603 Email: trevor.burbridge@bt.com 605 Sam Crawford 606 SamKnows 608 Email: sam@samknows.com 610 Phil Eardley 611 BT 612 Adastral Park, Martlesham Heath 613 Ipswich 614 ENGLAND 616 Email: philip.eardley@bt.com 618 Al Morton 619 AT&T Labs 620 200 Laurel Avenue South 621 Middletown, NJ 622 USA 624 Email: acmorton@att.com