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