idnits 2.17.1 draft-jenkins-alto-cdn-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 17, 2011) is 4698 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 568, but no explicit reference was found in the text 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 B. Niven-Jenkins, Ed. 3 Internet-Draft Velocix (Alcatel-Lucent) 4 Intended status: Informational G. Watson 5 Expires: December 19, 2011 BT 6 N. Bitar 7 Verizon 8 J. Medved 9 Juniper Networks 10 S. Previdi 11 Cisco Systems 12 June 17, 2011 14 Use Cases for ALTO within CDNs 15 draft-jenkins-alto-cdn-use-cases-01 17 Abstract 19 For some time, Content Distribution Networks (CDNs) have been used in 20 the delivery of some Internet services (e.g. delivery of websites, 21 software updates and video delivery) as they provide numerous 22 benefits including reduced delivery cost for cacheable content, 23 improved quality of experience for end users and increased robustness 24 of delivery. 26 In order to derive the optimal benefit from a CDN it is preferable to 27 deliver content from the servers (caches) that are "closest" to the 28 End User requesting the content, where "closest" may be as simple as 29 "geographical or network distance" combined with CDN server load 30 within a location, but may also consider other more complex 31 combinations of metrics and CDN or Network Service Provider (NSP) 32 policies. 34 There are a number of different ways in which a CDN may obtain the 35 necessary network topology and/or cost information to allow it to 36 serve End Users from the most optimal servers/locations, such as 37 static configuration, passively listening to routing protocols 38 directly, active probing of underlying network(s), or obtaining 39 topology and cost by querying an information service such as the ALTO 40 map & cost services. 42 This document describes the use cases for a CDN to be able to obtain 43 network topology and cost information from an ALTO server(s). 45 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on December 19, 2011. 62 Copyright Notice 64 Copyright (c) 2011 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. CDN overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. CDN & ALTO Use Cases . . . . . . . . . . . . . . . . . . . . . 7 83 3.1. Exposing NSP End User Reachability to a CDN . . . . . . . 8 84 3.2. Exposing CDN End User Reachability to CSPs . . . . . . . . 9 85 3.3. CDN deployed within a Broadband network . . . . . . . . . 10 86 3.4. CDN delivering Over-The-Top of a NSP's network . . . . . . 11 87 3.5. CDN acquiring content from multiple upstream sources 88 (Origins) . . . . . . . . . . . . . . . . . . . . . . . . 11 89 3.6. Additional Use Cases . . . . . . . . . . . . . . . . . . . 12 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 94 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 For some time, Content Distribution Networks (CDNs) have been used in 100 the delivery of some Internet services (e.g. delivery of websites, 101 software updates and video delivery) as they provide numerous 102 benefits including reduced delivery cost for cacheable content, 103 improved quality of experience for end users and increased robustness 104 of delivery. 106 A CDN typically consists of a network of servers often attached to 107 Network Service Provider (NSP) networks. The point of attachment is 108 often as close to content consumers and peering points as 109 economically or operationally feasible in order to decrease traffic 110 load on the NSP backbone and to provide better user experience 111 measured by reduced latency and higher throughput. 113 As the volume of video and multimedia content delivered over the 114 Internet is rapidly increasing and expected to continue doing so in 115 the future, existing CDN providers are scaling up their 116 infrastructure and many NSPs are deploying their own CDNs. The 117 result of such deployments is typically that more CDN servers are 118 being deployed within NSP networks and those CDN servers are being 119 deployed in locations that are "deeper" (i.e. geographically closer 120 to the NSP's End Users) than was previously the case. 122 In order to derive the optimal benefit from a CDN it is preferable to 123 deliver content from the servers (caches) that are "closest" to the 124 End User requesting the content, where "closest" may be as simple as 125 "geographical or network distance" combined with CDN server load 126 within a location, but may also consider other more complex 127 combinations of metrics and CDN or NSP policies. 129 When CDN servers are deployed outside of an NSP's network or in a 130 small number of central locations within an NSP's network a 131 simplified view of the NSP's topology or an approximation of 132 proximity is typically sufficient to enable the CDN to serve End 133 Users from the optimal server/location. As CDN servers are deployed 134 deeper within NSP networks it becomes necessary for the CDN to have 135 more detailed knowledge of the underlying network topology and costs 136 between network locations in order to enable the CDN to serve End 137 Users from the most optimal servers for the NSP. 139 There are a number of different ways in which a CDN may obtain the 140 necessary network topology and/or cost information to allow it to 141 serve End Users from the most optimal servers/locations, such as 142 static configuration, passively listening to routing protocols 143 directly, active probing of underlying network(s), or obtaining 144 topology and cost by querying an information service such as the ALTO 145 map & cost services. 147 The rest of this document describes the use cases for a CDN to be 148 able to obtain network topology and cost information from an ALTO 149 server(s). 151 1.1. Terminology 153 The following terms are taken from 154 [I-D.jenkins-cdni-problem-statement] and repeated here for 155 completeness. 157 Content Distribution Network (CDN) / Content Delivery Network (CDN): 158 Network infrastructure in which the network elements cooperate at 159 layers 4 through layer 7 for more effective delivery of Content to 160 User Agents. Typically a CDN consists of a Request Routing system, a 161 Distribution System (that includes a set of Surrogates), a Logging 162 System and a CDN control system. 164 Content Service Provider (CSP): Provides a Content Service to End 165 Users (which the End Users access via a User Agent). A CSP may own 166 the Content made available as part of the Content Service, or may 167 license content rights from another party. 169 End User (EU): The 'real' user of the system, typically a human but 170 maybe some combination of hardware and/or software emulating a human 171 (e.g. for automated quality monitoring etc.) 173 Network Service Provider (NSP): Provides network-based connectivity/ 174 services to Users. 176 Surrogate: A device/function that interacts with other elements of 177 the CDN for the control and distribution of Content within the CDN 178 and interacts with User Agents for the delivery of the Content. 180 User Agent (UA): Software (or a combination of hardware and software) 181 through which the End User interacts with the Content Service. The 182 User Agent will communicate with the CSP's Service for the selection 183 of content and one or more CDNs for the delivery of the Content. 184 Such communication is not restricted to HTTP and may be via a variety 185 of protocols. Examples of User Agents (non-exhaustive) are: 186 Browsers, Set Top Boxes (STB), Dedicated content applications (e.g. 187 media players), etc. 189 2. CDN overview 191 This section provides a high level and simplified overview of the 192 operation of a CDN to help put the ALTO & CDN use cases into context. 194 A typical CDN consists of a number of functional components, however 195 in the context of ALTO three functional components are of interest: 196 The Request Routing function, the Surrogate (i.e. caching) function 197 and the Origin function. 199 The Request Routing function within a CDN is responsible for 200 receiving content requests from User Agents, obtaining and 201 maintaining necessary information about a set of candidate 202 Surrogates, and for selecting and redirecting the User Agent to the 203 appropriate Surrogate. 205 The Surrogate function interacts with other elements of the CDN for 206 the control and distribution of Content within the CDN and interacts 207 with User Agents for the delivery of the Content. 209 The figure below shows a high level call flow showing the interaction 210 between a User Agent, Request Router and Surrogate for the delivery 211 of content in a single CDN. 213 User Agent Request Router Surrogate 214 | | | 215 | (1) Initial Request | | 216 +------------------------------>| | 217 | +--+ | 218 | | | (2) Surrogate Selection | 219 | |<-+ | 220 | (3) Redirection Response | | 221 |<------------------------------+ | 222 | | | 223 | (4) Content Request | | 224 +------------------------------------------------------------>| 225 | | | 226 | | (5) Content | 227 |<------------------------------------------------------------+ 228 | | | 230 1. The User Agent makes an initial request to the CDN. Depending on 231 the type of content being delivered and the configuration of the 232 CDN this request may be an application (e.g. HTTP, RTMP, etc.) 233 level request directly from the User Agent or may be a DNS 234 request via the User Agent's assigned DNS proxy. 235 2. The Request Router selects an appropriate Surrogate (or set of 236 Surrogates) based on the User Agent's (or its proxy's) IP 237 address, the Request Router's knowledge of the network topology 238 and reachability cost between CDN caches and end users, and any 239 additional CDN policies. 240 3. The Request Router responds to the UA's initial request with an 241 appropriate response containing a redirection to the selected 242 cache, for example by returning an appropriate DNS A/AAAA record, 243 a HTTP 302 redirect, etc. 244 4. The User Agent uses the information provided in the Redirection 245 Response to connect directly to the Surrogate and request the 246 desired content. 247 5. If CDN policy allows the User Agent to receive the requested 248 content, the Surrogate delivers the content to the User Agent. 249 A. [Not Shown] If the Surrogate does not have a copy of the 250 requested content then it obtains it from the appropriate 251 Origin Server. 252 Note: A Surrogate may not communicate with the Origin directly 253 and instead obtain the requested content from other surrogates 254 or caching layers in the CDN hierarchy. The details of how 255 content requests filter through the CDN hierarchy to the 256 Origin are internal to a specific CDN and are out of scope of 257 this document. 259 3. CDN & ALTO Use Cases 261 The primary use case for ALTO in a CDN context is to improve the 262 selection of a CDN Surrogate or Origin. The CDN makes use of an ALTO 263 server to choose a better CDN Surrogate or Origin than would 264 otherwise be the case. In its simplest form an ALTO server would 265 provide an NSP with the capability to offer a service to a CDN which 266 provides network map and cost information that the CDN can use to 267 enhance its surrogate and/or Origin selection. 269 Although it is possible to obtain raw network map and cost 270 information in other ways, for example passively listening to the 271 NSP's routing protocols, the use of an ALTO service to expose that 272 information may provide additional control to the NSP over how their 273 network map/cost is exposed. Additionally it may enable the NSP to 274 maintain a functional separation between their routing plane and 275 network map computation functions. This may be attractive for a 276 number of reasons, for example: 278 o The ALTO service could provide a filtered view of the network 279 and/or cost map that relates to CDN locations and their proximity 280 to end users, for example to allow the NSP to control the level of 281 topology detail they are willing to share with the CDN. 282 o The ALTO service could apply additional policies to the network 283 map and cost information to provide a CDN-specific view of the 284 network map/cost, for example to allow the NSP to encourage the 285 CDN to use network links that would not ordinarily be preferred by 286 a Shortest Path First routing calculation. 287 o The routing plane may be operated and controlled by a different 288 operational entity (even within a single NSP) to the CDN and the 289 ALTO service could provide a layer of separation because: 290 * The CDN is not able to passively listen to routing protocols. 291 * The NSP is not willing to allow the CDN to passively listen to 292 routing protocols, e.g. because the NSP is concerned the CDN 293 may inadvertently interfere with the routing plane or because 294 the routing plane and the CDN are operated by different 295 operational entities/groups (including different entities 296 within the same NSP). 297 The use cases in this document are not necessarily specific as to the 298 relationship between the commercial/operational entity that "owns" 299 the ALTO service and the commercial/operational entity that "owns" 300 the CDN service as it is assumed that such relationships will be 301 deployment specific. Although the ownership of each service may 302 affect the level of topology detail that the ALTO service will be 303 permitted to expose, it is assumed that the general requirements a 304 CDN places on the ALTO service should not change provided that the 305 ALTO server is able to expose sufficient topology for the CDN to make 306 appropriate surrogate and/or Origin selection decisions. 308 In general, the ALTO service is expected to be operated by an entity 309 or entities that wish to optimize or otherwise influence request 310 routing decisions. Some, non-exhaustive, examples of such entities 311 are: 313 o The entity that operates the CDN's underlying network (e.g. the 314 "CDN deployed within a Broadband network" described in 315 Section 3.3). 316 o An NSP that wishes to optimize over-the-top content delivery from 317 a CDN that is deployed outside of its network (e.g. the "CDN 318 delivering Over-The-Top of a NSP" described in Section 3.4). 319 o An NSP (that may or may not operate a CDN) or a CDN that wishes to 320 advertise which End Users are reachable via its network/CDN (e.g. 321 the exposing "End User reachability" use cases described in 322 Section 3.1 and Section 3.2). 324 The following sections outline some specific, non-exhaustive, example 325 use cases, which are subsets of the primary use case outlined above 326 but applied to specific usage examples to demonstrate how a CDN could 327 make use of ALTO services. 329 3.1. Exposing NSP End User Reachability to a CDN 331 In order for a Request Router to be able to make surrogate selection 332 decisions, the Request Router needs to have information on which End 333 User IP subnets are reachable via which networks or network 334 locations. The granularity of location information required depends 335 on the specific deployment of the CDN relative to the End Users. For 336 example, an Over-The-Top CDN whose surrogates are deployed only 337 within the Internet "backbone" may only require knowledge of which 338 End User IP subnets are reachable via which NSPs' networks, whereas a 339 CDN deployed within a particular NSP's network requires a finer 340 granularity of knowledge, i.e. which End User IP subnets are 341 reachable via which regions within that NSP's network. 343 Such reachability information is often available via dynamic routing 344 protocols, however it is likely that in a number of deployment 345 scenarios that peering of the routing plane of the network with a CDN 346 would be deemed unacceptable (e.g. where the CDN is operated by an 347 entity other than the NSP(s) operating the underlying network). 349 Provided that some common mapping between ALTO PIDs and network 350 locations (or entire networks) is known to both the NSP and the CDN, 351 the network map services offered by ALTO could be used to expose 352 which End User IP subnets are reachable via a particular network or 353 network locations in order to export End User reachability to a 354 Request Router to enable the NSP to expose End User reachability 355 while also giving the NSP the ability to control the granularity of 356 any End User reachability to network location mapping while also 357 avoiding routing plane peering between the NSP and the CDN. 359 3.2. Exposing CDN End User Reachability to CSPs 361 This use case is similar to the use case described in Section 3.1 362 however in this case it is the CDN that wishes to expose which End 363 User IP subnets the CDN is capable of delivering services to. 365 In some deployments a particular CDN may not have reachability to (or 366 may not wish to offer services to) every End User IP subnet reachable 367 via the global Internet, for example because the CDN is only deployed 368 within certain networks or geographic regions and the CDN is either 369 unable (due to lack of reachability) or unwilling (due to cost or 370 policy) to serve all End Users reachable via the global Internet. 372 The reachability offered by a particular CDN may not include all the 373 End User IP subnets that a particular CSP requires in order to serve 374 all of that CSP's customers and therefore if the CSP wishes to make 375 use of the services offered by a CDN that can only serve a subset of 376 their customers the CSP must have knowledge of which End User IP 377 subnets a particulart CDN is able to serve, so that they can select 378 an appropriate CDN to use to deliver their service to particular 379 subsets of their customers. 381 In such cases, the network map services offered by ALTO could be used 382 to expose to a CSP which End User IP subnets are reachable via a 383 particular CDN. In the case where the CDN is operated by an NSP 384 using ALTO in this way could also enable the NSP to separate the 385 exposure of End User subnets reachable via their CDN from those 386 reachable via their underlying network. 388 3.3. CDN deployed within a Broadband network 390 In this use case an NSP is providing Broadband services to its 391 customers and has deployed a CDN within its Broadband network to 392 alleviate the cost and/or improve the User Experience of content 393 services for its Broadband customers. 395 The topology of Broadband access/backhaul networks is often much more 396 constrained than metro/core networks. If CDN surrogates are deployed 397 within the access/backhaul network, for a given set of End Users, the 398 NSP is likely to want to utilise the surrogates deployed in the same 399 access/backhaul region as those End Users in preference to surrogates 400 deployed within the metro/core or within other access/backhaul 401 regions. 403 It is common for Broadband subscribers to obtain their IP addresses 404 dynamically and in many deployments the IP subnets allocated to a 405 particular access/backhaul region can change relatively frequently. 406 For example new IP subnets are added as the subscriber base grows, IP 407 subnets are moved from one Broadband product in the NSP's portfolio 408 to another as customers migrate in order to optimise the NSP's IP 409 address utilisation, or they are simply moved as part of IP address 410 management, etc. 412 Additionally, in certain cases, CDN surrogates deployed in a 413 particular network region may become overloaded, leading to the CDN 414 selecting alternative surrogates in a different region of the network 415 for content delivery. If this occurs, an NSP may wish to influence 416 such a decision, for example because the NSP would prefer a surrogate 417 to be selected that is deployed in the the next best (cost-wise to 418 the NSP) location. 420 In order to meet the NSP's objective of utilising their CDN to 421 constrain access/backhaul costs and/or improve User Experience it is 422 important that the CDN is able to select the most appropriate 423 surrogate for a given set of End User IP subnets. Although the 424 network topology is often reasonably static, in networks where the IP 425 subnets allocated to a Broadband region are changing relatively 426 frequently, static configuration of End User IP Subnets to CDN 427 surrogates is possible but some NSPs may consider the operational 428 burden of having to update such static configuration too high and 429 would prefer the CDN to be able to dynamically obtain network map and 430 cost information. 432 The NSP could make use of an ALTO service to expose a cost mapping/ 433 ranking between End User IP subnets (within that NSP's network) and 434 CDN surrogate IP subnets/locations to meet its requirements while 435 avoiding static configuration or direct integration of the CDN into 436 its IP routing plane and to avoid the CDN being required to implement 437 network layer routing computations. 439 3.4. CDN delivering Over-The-Top of a NSP's network 441 In this use case a CDN is deployed within one or more NSPs' networks 442 but is delivering content "Over-The-Top" into another NSP's network 443 (which we will call NSP Z) where the CDN is not deployed. 445 The CDN is unlikely to have direct visibility of NSP Z's network 446 topology and may have a choice of entry points into NSP Z's network 447 from which it could serve content to NSP Z's End Users. For example 448 because NSP Z has direct peering links with the CDN in a number of 449 locations or NSP Z has transit and/or peering relationships with 450 several other NSPs where the CDN is deployed. NSP Z may wish to 451 influence the locations from which the CDN serves content based on 452 some factor(s) that it does not wish to expose directly or that might 453 change over time. For example the available transit/peering capacity 454 in different locations, the cost of connectivity to different 455 locations, etc. 457 For example, a CSP is using NSP A's CDN and another NSP (NSP Z) has 458 peering with NSP A in Los Angeles and New York. NSP Z would like to 459 influence which peering location NSP A's CDN delivers content out of 460 for NSP Z's end users by using their knowledge of the peering 461 capacity they have deployed in LA & NY and the capacity they have 462 between those peering locations and groups of end users without 463 directly exposing their internal topology to NSP A. 465 An NSP could make use of an ALTO service to expose a cost mapping/ 466 ranking between End User IP subnets (within that NSP's network) and 467 entry points into that NSP's network in order to try to influence the 468 locations from which the CDN serves content into that NSP's network. 470 3.5. CDN acquiring content from multiple upstream sources (Origins) 472 Before a surrogate within a CDN is able to deliver content to an End 473 User it must first have a copy of the content that the End User is 474 requesting. Content may be obtained by surrogates in advance of it 475 being requested (pre-positioned) by End Users or it may be obtained 476 by surrogates dynamically in response to End User requests for the 477 content (on-demand). 479 The ultimate source of the content (i.e. where the 'master' copy is 480 permanently stored) is typically referred to as the content's Origin 481 (or Origin Server), however CDNs often employ an internal hierarchy 482 of caching layers so that surrogates do not necessarily obtain 483 content directly from the Origin. Such a hierarchy provides a number 484 of benefits, for example reducing the number of requests for content 485 received by the Origin (and therefore reducing the scaling 486 requirements on the Origin), more efficient use of the underlying 487 network as fewer copies of the content is required to traverse the 488 same network links, etc. 490 For a particular CSP's content service multiple, possibly 491 independently addressable, Origins may be used for resiliency and the 492 Origin(s) may be deployed in a distributed manner across multiple 493 geographic locations. 495 For the rest of this use case "upstream source" is used to mean 496 either the Origin itself as well as other sources of the content, for 497 example another caching layer within the CDN that has (or will obtain 498 on demand) a copy of the content but is not the actual Origin. 500 Therefore, for a particular item of content, a surrogate may have a 501 choice of upstream sources (both internal to the CDN and external 502 Origins) from which it could obtain the content. 504 When presented with a choice of upstream sources, a surrogate may 505 utilise some combination of policy and heuristics to decide which 506 upstream sources (and in which order) it should attempt to use to 507 obtain the content. A CDN may wish to utilise network topology & 508 cost information as one of the inputs into such a content source 509 selection process, for example to weight upstream sources that are 510 topologically close to the surrogate that requires the content. 512 Additionally, where the CDN is deployed within one or more NSP 513 networks, an NSP may want to try to influence the choice of upstream 514 sources, for example the NSP may prefer the CDN to use content 515 sources that are deployed within that NSP's network or within 516 networks with which it has direct peering agreements with over other 517 content sources. 519 An NSP (or a CSP) could provide an ALTO service which a CDN could use 520 to obtain network topology and/or cost/ranking information to use as 521 an input into surrogates' selection decisions for content sources. 523 3.6. Additional Use Cases 525 The following additional use case may be relevant to ALTO and will be 526 described in more detail in a future version of this document: 528 o Inter-provider CDN / CDN Interconnect. 530 4. IANA Considerations 532 This document makes no specific request of IANA. 534 Note to RFC Editor: this section may be removed on publication as an 535 RFC. 537 5. Security Considerations 539 TBD. 541 6. Contributing Authors 543 Reinaldo Penno 544 Juniper Networks 545 Email: rpenno@juniper.net 547 Richard Alimi 548 Google 549 Email: ralimi@google.com 551 Richard Yang 552 Yale University 553 Email: ryr@yale.edu 555 7. Acknowledgements 557 The authors would like to thank Vijay Gurbani and Volker Hilt for 558 their review comments and contributions to the text. 560 8. Normative References 562 [I-D.jenkins-cdni-problem-statement] 563 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 564 Distribution Network Interconnection (CDNI) Problem 565 Statement", draft-jenkins-cdni-problem-statement-02 (work 566 in progress), March 2011. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 Authors' Addresses 573 Ben Niven-Jenkins (editor) 574 Velocix (Alcatel-Lucent) 575 326 Cambridge Science Park 576 Milton Road, Cambridge CB4 0WG 577 UK 579 Email: ben@velocix.com 581 Grant Watson 582 BT 584 Email: grant.watson@bt.com 586 Nabil Bitar 587 Verizon 588 40 Sylvan Road 589 Waltham, MA 02145 590 USA 592 Email: nabil.bitar@verizon.com 594 Jan Medved 595 Juniper Networks 597 Email: jmedved@juniper.net 599 Stefano Previdi 600 Cisco Systems 602 Email: sprevidi@cisco.com