idnits 2.17.00 (12 Aug 2021) /tmp/idnits64001/draft-jenkins-alto-cdn-use-cases-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 (December 7, 2011) is 3817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 569, but no explicit reference was found in the text == Outdated reference: draft-ietf-cdni-problem-statement has been published as RFC 6707 Summary: 0 errors (**), 0 flaws (~~), 3 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: June 9, 2012 BT 6 N. Bitar 7 Verizon 8 J. Medved 9 Juniper Networks 10 S. Previdi 11 Cisco Systems 12 December 7, 2011 14 Use Cases for ALTO within CDNs 15 draft-jenkins-alto-cdn-use-cases-02 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 June 9, 2012. 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 [I-D.ietf-cdni-problem-statement] 154 and repeated here for completeness. 156 Content Distribution Network (CDN) / Content Delivery Network (CDN): 157 Network infrastructure in which the network elements cooperate at 158 layers 4 through layer 7 for more effective delivery of Content to 159 User Agents. Typically a CDN consists of a Request Routing system, a 160 Distribution System (that includes a set of Surrogates), a Logging 161 System and a CDN control system. 163 Content Service Provider (CSP): Provides a Content Service to End 164 Users (which the End Users access via a User Agent). A CSP may own 165 the Content made available as part of the Content Service, or may 166 license content rights from another party. 168 End User (EU): The 'real' user of the system, typically a human but 169 maybe some combination of hardware and/or software emulating a human 170 (e.g. for automated quality monitoring etc.) 172 Network Service Provider (NSP): Provides network-based connectivity/ 173 services to Users. 175 Surrogate: A device/function that interacts with other elements of 176 the CDN for the control and distribution of Content within the CDN 177 and interacts with User Agents for the delivery of the Content. 179 User Agent (UA): Software (or a combination of hardware and software) 180 through which the End User interacts with the Content Service. The 181 User Agent will communicate with the CSP's Service for the selection 182 of content and one or more CDNs for the delivery of the Content. 183 Such communication is not restricted to HTTP and may be via a variety 184 of protocols. Examples of User Agents (non-exhaustive) are: 185 Browsers, Set Top Boxes (STB), Dedicated content applications (e.g. 186 media players), etc. 188 2. CDN overview 190 This section provides a high level and simplified overview of the 191 operation of a CDN to help put the ALTO & CDN use cases into context. 193 A typical CDN consists of a number of functional components, however 194 in the context of ALTO three functional components are of interest: 195 The Request Routing function, the Surrogate (i.e. caching) function 196 and the Origin function. 198 The Request Routing function within a CDN is responsible for 199 receiving content requests from User Agents, obtaining and 200 maintaining necessary information about a set of candidate 201 Surrogates, and for selecting and redirecting the User Agent to the 202 appropriate Surrogate. 204 The Surrogate function interacts with other elements of the CDN for 205 the control and distribution of Content within the CDN and interacts 206 with User Agents for the delivery of the Content. 208 The figure below shows a high level call flow showing the interaction 209 between a User Agent, Request Router and Surrogate for the delivery 210 of content in a single CDN. 212 User Agent Request Router Surrogate 213 | | | 214 | (1) Initial Request | | 215 +------------------------------>| | 216 | +--+ | 217 | | | (2) Surrogate Selection | 218 | |<-+ | 219 | (3) Redirection Response | | 220 |<------------------------------+ | 221 | | | 222 | (4) Content Request | | 223 +------------------------------------------------------------>| 224 | | | 225 | | (5) Content | 226 |<------------------------------------------------------------+ 227 | | | 229 1. The User Agent makes an initial request to the CDN. Depending on 230 the type of content being delivered and the configuration of the 231 CDN this request may be an application (e.g. HTTP, RTMP, etc.) 232 level request directly from the User Agent or may be a DNS 233 request via the User Agent's assigned DNS proxy. 234 2. The Request Router selects an appropriate Surrogate (or set of 235 Surrogates) based on the User Agent's (or its proxy's) IP 236 address, the Request Router's knowledge of the network topology 237 and reachability cost between CDN caches and end users, and any 238 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. 288 o The routing plane may be operated and controlled by a different 289 operational entity (even within a single NSP) to the CDN and the 290 ALTO service could provide a layer of separation because: 291 * The CDN is not able to passively listen to routing protocols. 292 * The NSP is not willing to allow the CDN to passively listen to 293 routing protocols, e.g. because the NSP is concerned the CDN 294 may inadvertently interfere with the routing plane or because 295 the routing plane and the CDN are operated by different 296 operational entities/groups (including different entities 297 within the same NSP). 298 The use cases in this document are not necessarily specific as to the 299 relationship between the commercial/operational entity that "owns" 300 the ALTO service and the commercial/operational entity that "owns" 301 the CDN service as it is assumed that such relationships will be 302 deployment specific. Although the ownership of each service may 303 affect the level of topology detail that the ALTO service will be 304 permitted to expose, it is assumed that the general requirements a 305 CDN places on the ALTO service should not change provided that the 306 ALTO server is able to expose sufficient topology for the CDN to make 307 appropriate surrogate and/or Origin selection decisions. 309 In general, the ALTO service is expected to be operated by an entity 310 or entities that wish to optimize or otherwise influence request 311 routing decisions. Some, non-exhaustive, examples of such entities 312 are: 314 o The entity that operates the CDN's underlying network (e.g. the 315 "CDN deployed within a Broadband network" described in 316 Section 3.3). 317 o An NSP that wishes to optimize over-the-top content delivery from 318 a CDN that is deployed outside of its network (e.g. the "CDN 319 delivering Over-The-Top of a NSP" described in Section 3.4). 320 o An NSP (that may or may not operate a CDN) or a CDN that wishes to 321 advertise which End Users are reachable via its network/CDN (e.g. 322 the exposing "End User reachability" use cases described in 323 Section 3.1 and Section 3.2). 325 The following sections outline some specific, non-exhaustive, example 326 use cases, which are subsets of the primary use case outlined above 327 but applied to specific usage examples to demonstrate how a CDN could 328 make use of ALTO services. 330 3.1. Exposing NSP End User Reachability to a CDN 332 In order for a Request Router to be able to make surrogate selection 333 decisions, the Request Router needs to have information on which End 334 User IP subnets are reachable via which networks or network 335 locations. The granularity of location information required depends 336 on the specific deployment of the CDN relative to the End Users. For 337 example, an Over-The-Top CDN whose surrogates are deployed only 338 within the Internet "backbone" may only require knowledge of which 339 End User IP subnets are reachable via which NSPs' networks, whereas a 340 CDN deployed within a particular NSP's network requires a finer 341 granularity of knowledge, i.e. which End User IP subnets are 342 reachable via which regions within that NSP's network. 344 Such reachability information is often available via dynamic routing 345 protocols, however it is likely that in a number of deployment 346 scenarios that peering of the routing plane of the network with a CDN 347 would be deemed unacceptable (e.g. where the CDN is operated by an 348 entity other than the NSP(s) operating the underlying network). 350 Provided that some common mapping between ALTO PIDs and network 351 locations (or entire networks) is known to both the NSP and the CDN, 352 the network map services offered by ALTO could be used to expose 353 which End User IP subnets are reachable via a particular network or 354 network locations in order to export End User reachability to a 355 Request Router to enable the NSP to expose End User reachability 356 while also giving the NSP the ability to control the granularity of 357 any End User reachability to network location mapping while also 358 avoiding routing plane peering between the NSP and the CDN. 360 3.2. Exposing CDN End User Reachability to CSPs 362 This use case is similar to the use case described in Section 3.1 363 however in this case it is the CDN that wishes to expose which End 364 User IP subnets the CDN is capable of delivering services to. 366 In some deployments a particular CDN may not have reachability to (or 367 may not wish to offer services to) every End User IP subnet reachable 368 via the global Internet, for example because the CDN is only deployed 369 within certain networks or geographic regions and the CDN is either 370 unable (due to lack of reachability) or unwilling (due to cost or 371 policy) to serve all End Users reachable via the global Internet. 373 The reachability offered by a particular CDN may not include all the 374 End User IP subnets that a particular CSP requires in order to serve 375 all of that CSP's customers and therefore if the CSP wishes to make 376 use of the services offered by a CDN that can only serve a subset of 377 their customers the CSP must have knowledge of which End User IP 378 subnets a particulart CDN is able to serve, so that they can select 379 an appropriate CDN to use to deliver their service to particular 380 subsets of their customers. 382 In such cases, the network map services offered by ALTO could be used 383 to expose to a CSP which End User IP subnets are reachable via a 384 particular CDN. In the case where the CDN is operated by an NSP 385 using ALTO in this way could also enable the NSP to separate the 386 exposure of End User subnets reachable via their CDN from those 387 reachable via their underlying network. 389 3.3. CDN deployed within a Broadband network 391 In this use case an NSP is providing Broadband services to its 392 customers and has deployed a CDN within its Broadband network to 393 alleviate the cost and/or improve the User Experience of content 394 services for its Broadband customers. 396 The topology of Broadband access/backhaul networks is often much more 397 constrained than metro/core networks. If CDN surrogates are deployed 398 within the access/backhaul network, for a given set of End Users, the 399 NSP is likely to want to utilise the surrogates deployed in the same 400 access/backhaul region as those End Users in preference to surrogates 401 deployed within the metro/core or within other access/backhaul 402 regions. 404 It is common for Broadband subscribers to obtain their IP addresses 405 dynamically and in many deployments the IP subnets allocated to a 406 particular access/backhaul region can change relatively frequently. 407 For example new IP subnets are added as the subscriber base grows, IP 408 subnets are moved from one Broadband product in the NSP's portfolio 409 to another as customers migrate in order to optimise the NSP's IP 410 address utilisation, or they are simply moved as part of IP address 411 management, etc. 413 Additionally, in certain cases, CDN surrogates deployed in a 414 particular network region may become overloaded, leading to the CDN 415 selecting alternative surrogates in a different region of the network 416 for content delivery. If this occurs, an NSP may wish to influence 417 such a decision, for example because the NSP would prefer a surrogate 418 to be selected that is deployed in the the next best (cost-wise to 419 the NSP) location. 421 In order to meet the NSP's objective of utilising their CDN to 422 constrain access/backhaul costs and/or improve User Experience it is 423 important that the CDN is able to select the most appropriate 424 surrogate for a given set of End User IP subnets. Although the 425 network topology is often reasonably static, in networks where the IP 426 subnets allocated to a Broadband region are changing relatively 427 frequently, static configuration of End User IP Subnets to CDN 428 surrogates is possible but some NSPs may consider the operational 429 burden of having to update such static configuration too high and 430 would prefer the CDN to be able to dynamically obtain network map and 431 cost information. 433 The NSP could make use of an ALTO service to expose a cost mapping/ 434 ranking between End User IP subnets (within that NSP's network) and 435 CDN surrogate IP subnets/locations to meet its requirements while 436 avoiding static configuration or direct integration of the CDN into 437 its IP routing plane and to avoid the CDN being required to implement 438 network layer routing computations. 440 3.4. CDN delivering Over-The-Top of a NSP's network 442 In this use case a CDN is deployed within one or more NSPs' networks 443 but is delivering content "Over-The-Top" into another NSP's network 444 (which we will call NSP Z) where the CDN is not deployed. 446 The CDN is unlikely to have direct visibility of NSP Z's network 447 topology and may have a choice of entry points into NSP Z's network 448 from which it could serve content to NSP Z's End Users. For example 449 because NSP Z has direct peering links with the CDN in a number of 450 locations or NSP Z has transit and/or peering relationships with 451 several other NSPs where the CDN is deployed. NSP Z may wish to 452 influence the locations from which the CDN serves content based on 453 some factor(s) that it does not wish to expose directly or that might 454 change over time. For example the available transit/peering capacity 455 in different locations, the cost of connectivity to different 456 locations, etc. 458 For example, a CSP is using NSP A's CDN and another NSP (NSP Z) has 459 peering with NSP A in Los Angeles and New York. NSP Z would like to 460 influence which peering location NSP A's CDN delivers content out of 461 for NSP Z's end users by using their knowledge of the peering 462 capacity they have deployed in LA & NY and the capacity they have 463 between those peering locations and groups of end users without 464 directly exposing their internal topology to NSP A. 466 An NSP could make use of an ALTO service to expose a cost mapping/ 467 ranking between End User IP subnets (within that NSP's network) and 468 entry points into that NSP's network in order to try to influence the 469 locations from which the CDN serves content into that NSP's network. 471 3.5. CDN acquiring content from multiple upstream sources (Origins) 473 Before a surrogate within a CDN is able to deliver content to an End 474 User it must first have a copy of the content that the End User is 475 requesting. Content may be obtained by surrogates in advance of it 476 being requested (pre-positioned) by End Users or it may be obtained 477 by surrogates dynamically in response to End User requests for the 478 content (on-demand). 480 The ultimate source of the content (i.e. where the 'master' copy is 481 permanently stored) is typically referred to as the content's Origin 482 (or Origin Server), however CDNs often employ an internal hierarchy 483 of caching layers so that surrogates do not necessarily obtain 484 content directly from the Origin. Such a hierarchy provides a number 485 of benefits, for example reducing the number of requests for content 486 received by the Origin (and therefore reducing the scaling 487 requirements on the Origin), more efficient use of the underlying 488 network as fewer copies of the content is required to traverse the 489 same network links, etc. 491 For a particular CSP's content service multiple, possibly 492 independently addressable, Origins may be used for resiliency and the 493 Origin(s) may be deployed in a distributed manner across multiple 494 geographic locations. 496 For the rest of this use case "upstream source" is used to mean 497 either the Origin itself as well as other sources of the content, for 498 example another caching layer within the CDN that has (or will obtain 499 on demand) a copy of the content but is not the actual Origin. 501 Therefore, for a particular item of content, a surrogate may have a 502 choice of upstream sources (both internal to the CDN and external 503 Origins) from which it could obtain the content. 505 When presented with a choice of upstream sources, a surrogate may 506 utilise some combination of policy and heuristics to decide which 507 upstream sources (and in which order) it should attempt to use to 508 obtain the content. A CDN may wish to utilise network topology & 509 cost information as one of the inputs into such a content source 510 selection process, for example to weight upstream sources that are 511 topologically close to the surrogate that requires the content. 513 Additionally, where the CDN is deployed within one or more NSP 514 networks, an NSP may want to try to influence the choice of upstream 515 sources, for example the NSP may prefer the CDN to use content 516 sources that are deployed within that NSP's network or within 517 networks with which it has direct peering agreements with over other 518 content sources. 520 An NSP (or a CSP) could provide an ALTO service which a CDN could use 521 to obtain network topology and/or cost/ranking information to use as 522 an input into surrogates' selection decisions for content sources. 524 3.6. Additional Use Cases 526 The following additional use case may be relevant to ALTO and will be 527 described in more detail in a future version of this document: 529 o Inter-provider CDN / CDN Interconnect. 531 4. IANA Considerations 533 This document makes no specific request of IANA. 535 Note to RFC Editor: this section may be removed on publication as an 536 RFC. 538 5. Security Considerations 540 TBD. 542 6. Contributing Authors 544 Reinaldo Penno 545 Juniper Networks 546 Email: rpenno@juniper.net 548 Richard Alimi 549 Google 550 Email: ralimi@google.com 552 Richard Yang 553 Yale University 554 Email: ryr@yale.edu 556 7. Acknowledgements 558 The authors would like to thank Vijay Gurbani and Volker Hilt for 559 their review comments and contributions to the text. 561 8. Normative References 563 [I-D.ietf-cdni-problem-statement] 564 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 565 Distribution Network Interconnection (CDNI) Problem 566 Statement", draft-ietf-cdni-problem-statement-01 (work in 567 progress), October 2011. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 Authors' Addresses 574 Ben Niven-Jenkins (editor) 575 Velocix (Alcatel-Lucent) 576 326 Cambridge Science Park 577 Milton Road, Cambridge CB4 0WG 578 UK 580 Email: ben@velocix.com 582 Grant Watson 583 BT 585 Email: grant.watson@bt.com 587 Nabil Bitar 588 Verizon 589 40 Sylvan Road 590 Waltham, MA 02145 591 USA 593 Email: nabil.bitar@verizon.com 595 Jan Medved 596 Juniper Networks 598 Email: jmedved@juniper.net 600 Stefano Previdi 601 Cisco Systems 603 Email: sprevidi@cisco.com