idnits 2.17.1 draft-medved-alto-svr-apis-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 04, 2011) is 4801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-gredler-bgp-te-00 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-06 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-07 ** Downref: Normative reference to an Informational draft: draft-ietf-alto-reqs (ref. 'I-D.ietf-alto-reqs') ** Downref: Normative reference to an Informational RFC: RFC 5693 == Outdated reference: A later version (-04) exists of draft-lee-alto-chinatelecom-trial-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO J. Medved 3 Internet-Draft D. Ward 4 Intended status: Standards Track Juniper Networks 5 Expires: September 5, 2011 J. Peterson 6 Neustar 7 R. Woundy 8 Comcast Corporation 9 D. McDysan 10 Verizon 11 March 04, 2011 13 ALTO Network-Server and Server-Server APIs 14 draft-medved-alto-svr-apis-00 16 Abstract 18 ALTO servers require automated operation, where the topology of the 19 underlying networks is incorporated into network maps automatically. 20 In addition to the Client-to-Server API defined in the ALTO protocol 21 document, two more standardized API are required: an API between the 22 ALTO Server and networking nodes (e.g. routers), through which the 23 ALTO Server can get topology information from the network, and an API 24 between the ALTO Servers, through which they can exchange topology 25 and status information between themselves. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119] 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 5, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. ALTO Server API Reference . . . . . . . . . . . . . . . . . . 4 71 4.1. The ALTO Server-to-Network Interface . . . . . . . . . . . 5 72 4.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . 5 73 4.1.2. BGP with TE Extensions . . . . . . . . . . . . . . . . 6 74 4.2. The ALTO Server-to-Server Interface . . . . . . . . . . . 8 75 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 ALTO Servers are becoming increasingly important technology for 87 finding "the best" or "most preferred" content or server. For 88 example, an ALTO Server can be used to facilitate the selection of 89 the best cache in a CDN, the best set of peers for a P2P node 90 ([RFC5632] or [I-D.lee-alto-chinatelecom-trial]), or the best service 91 instance in a cloud. These use cases will require that network and 92 cost map information accurately reflects the actual network topology 93 and utilization. Static configuration of network and cost maps is 94 not feasible even for moderately sized networks. Therefore, creation 95 of network and cost maps in the ALTO Server should be automated and 96 policy driven. 98 The ALTO Server can use multiple sources of information to generate 99 the network and cost maps. Network topology data coming directly 100 from routers is required. Additionally, traffic engineering data, 101 geo location data, or network resource utilization data could also be 102 used to further refine the maps, or to generate different maps for 103 different clients. The ALTO Server should use well defined APIs to 104 get the data required to generate maps, since the data will be 105 obtained from different sources provided by a multitude of vendors, 106 and vendor inter-operability will be critical for adoption of ALTO- 107 based solutions. For network topology data, this draft proposes BGP 108 with TE extensions as the ALTO Server-to-Network API. 110 The ALTO Server will typically only have partial topology data, which 111 will depend on the Server's location and the sources from which it 112 obtains data to generate the network and cost maps. To obtain a full 113 view of the network topology, the ALTO Server will have to exchange 114 topology data with other ALTO Servers, or redirect Endpoint Cost 115 ranking requests to the best possible ALTO Server. Therefore, a 116 standard Server-to-Server API is also required. 118 2. Scope 120 The scope of this draft are the ALTO Server-to-Network APIs and 121 Server-to-Server API that are required for automated operation of the 122 ALTO Service. The Server-to-Network API is used to obtain network 123 topology information from the underlying network. Server-to-Server 124 API is used to exchange topology information between ALTO servers, or 125 to redirect ranking requests from one ALTO Server to another. The 126 ALTO Client-to-Server protocol [I-D.ietf-alto-protocol] itself may be 127 used as the ALTO Server-to-Server protocol; in other words, one ALTO 128 Server may request maps or status from other servers. 130 3. Terminology 132 We use the following terms defined in ALTO Problem Statement 133 [RFC5693]: Application, ALTO Service, ALTO Server, ALTO Client, ALTO 134 Query, ALTO Reply, ALTO Transaction. 136 4. ALTO Server API Reference 138 In addition to the ALTO protocol, which constitutes the API between 139 the ALTO Server and its clients, the ALTO Server needs several other 140 APIs to get data that are required to generate the network and cost 141 maps. The reference diagram of possible ALTO Server APIs is shown in 142 Figure 1. 144 +---------+ +---------+ 145 | ALTO | | ALTO | 146 | Client | | Client | 147 |(e.g.CDN)| |(e.g.CDN)| 148 +---------+ +---------+ 149 ^ ^ 150 | (1) CS | (1) CS 151 V V 152 +---------+ +---------+ 153 | | (2) SS | | 154 | ALTO |<---------------------------->| ALTO | 155 | Server | | Server | 156 +---------+ +---------+ 157 ^ ^ 158 | (3) SN | (3) SN 159 V V 160 +---------+ +---------+ 161 | | (4) NN | | 162 | Network |<---------------------------->| Network | 163 | | | | 164 +---------+ +---------+ 166 Figure 1: ALTO Server API reference 168 The ALTO Server interfaces shown in Figure 1 are as follows: 170 1. CS: The Client-to-Server interface has been the focus of the ALTO 171 WG, and is defined in [I-D.ietf-alto-protocol]. 173 2. SS: The Server-to-Server interface is required to exchange 174 topology data and status between ALTO servers in different 175 networks or administrative domains. For Endpoint Cost queries, 176 the interface can be used to direct the client's request to the 177 peer ALTO Server that has the best data to respond to the query. 178 The interface may also facilitate other functions, such as ALTO 179 Server discovery. 181 3. SN: The Server-to-Network interface is used to get the network 182 topology data from the network. 184 4. NN: The Network-to-Network routing and data interfaces are well- 185 defined in a number of standards (for example, BGP [RFC4271]), 186 and they are not in scope of this draft. 188 4.1. The ALTO Server-to-Network Interface 190 4.1.1. Requirements 192 The Server-to-Network interface should satisfy the following 193 requirements: 195 o Enable automation of the operation of the ALTO server with minimal 196 human intervention 198 o Leverage existing sources of network topology data; don't 199 introduce new (routing) protocols; don't force un-natural 200 deployment of routing protocols within the ISP network 202 o Leverage scalable mechanisms for (near real-time) network topology 203 acquisition; don't use fragile mechanisms to obtain data (e.g. 204 screen-scraping information from looking glass servers) 206 o Enable centralized and/or distributed deployments of ALTO servers 208 o Provide network topology information from within the ISP network 209 (intra-AS) as well as from outside the ISP network (inter-AS), as 210 well as from different intra-domain routing areas. (Note that 211 some ISPs use multiple AS's for different components of the 212 overall network topology.) 214 o Enable automated ALTO server policy controls above and beyond mere 215 routing metrics 217 o Provide origin security for network topology information 219 o Provide the right balance between frequency of updates and 220 accuracy /timeliness of the data. Topology updates from the 221 network should be throttled. For ALTO application, a 15 minute 222 time interval between topology updates from the network should be 223 sufficient. 225 In addition to having a standardized Server-to-Network interface, the 226 algorithms for generation of ALTO network / cost maps and for 227 endpoint ranking should be normalized as well, to facilitate inter- 228 operability of different ALTO Server implementations. 230 4.1.2. BGP with TE Extensions 232 Network topology is best conveyed through routing protocols. BGP 233 carries information about all subnets in the network, and subnet / 234 prefix data from BGP is required to generate ALTO network maps. 235 Intra-AS topology information that is carried in link-state IGPs and 236 inter-AS topology information carried in BGP is required to generate 237 ALTO cost maps. IGP TE data is required if costs in the cost maps 238 have a link utilization component. 240 This draft proposes to use BGP with TE extensions 241 [I-D.gredler-bgp-te] as the ALTO Server-to-Network API that can carry 242 both the subnet/prefix data for network map generation and the 243 topology data for cost map generation. A BGP Speaker can learn a 244 part or the entire intra-AS topology by participating in the IGP and 245 then distribute the learned topology to other BGP Speakers in the AS. 246 The ALTO Server establishes an iBGP session with a BGP speaker within 247 the AS, typically a Route Reflector, and learns the intra-AS topology 248 from its peer BGP speaker, along with the inter-AS topology and the 249 subnet/prefix data. 251 Using BGP with TE extensions as the ALTO Server-to-Network API has 252 several advantages: 254 o Avoid peering with IGP routers, which is more challenging than BGP 255 peering. Moreover, IS-IS, OSPF and EIGRP implementations would be 256 required, although only one IGP peering implementation would 257 typically be used at any given time. 259 o Unified interface to the network (single protocol), which carries 260 all the network information required to generate the topological 261 component of network and cost maps. The alternative would be for 262 the ALTO Server to interface - in addition to BGP - with IS-IS, 263 OSPF and EIGRP routing protocols. 265 o Simplified handling of multi-area IGP topologies: if the ALTO 266 Server wants to see the entire multi-area IGP topology, it would 267 need to peer with at least one IGP router in each area. Since the 268 ALTO Server would have to reside in one of the areas, it would 269 have to peer with IGP routers in other areas over GRE tunnels, 270 which is complex and potentially error prone. Alternatively, an 271 ALTO Server would have to be placed in each area, and the ALTO 272 Servers would have to exchange topology information between 273 themselves via the Server-to-Server API. 275 o The ALTO Server can peer with a BGP Route Reflector. Route 276 Reflectors are widely deployed, and the Route Reflector control 277 architecture dovetails nicely with the desired ALTO Server control 278 architecture. 280 o BGP policy and marking capabilities allow the operator to modify 281 or filter / adjust both the prefix and the connectivity 282 information specifically for the ALTO Server's use. This 283 capability is important if the BGP Speaker and the ALTO Server are 284 in different administrative domains. 286 o BGP has some origin security. This capability is important if the 287 BGP Speaker and the ALTO Server are in different administrative 288 domains. 290 o BGP carries multicast for future enhancements, where the ALTO 291 Server will be creating multicast network and cost maps. 293 o Using BGP with TE extensions means that there only needs to be one 294 BGP speaker in each area (or two for redundancy) that gets the 295 area's topology from local IGP routers. The topology information 296 is then distributed throughout the AS and relayed to all 297 interested ALTO Servers. The topology information can be 298 appropriately tagged so that is only stored by those Route 299 Reflectors that talk to ALTO Servers. BGP Input and Output 300 filtering could ensure that only the minimum set of BGP Speakers 301 would need to store the topology information. 303 o The ALTO Server only needs to peer with a single BGP Speaker to 304 get the entire network topology. 306 o BGP with TE extensions can be used between eBGP peers to advertise 307 intra-AS topology information between peers in different ASes. 308 Intra-AS topology information from multiple ASes can then be used 309 by an ALTO Server to create more detailed network and cost maps 310 for the combined network. 312 Due to policy and security considerations, it is assumed that an ALTO 313 Server speaks via the Server-to-Network APIs only to a BGP Speaker in 314 the same Administrative Domain (that may encompass multiple IGP areas 315 and ASes). Any other use cases are for further study. 317 Note that the network topology received by the ALTO Server must not 318 be summarized beyond what is expressed by the IGP in each area. This 319 is because the network (router) does not understand the application- 320 specific constraints of the ALTO Server for suitable summarization. 322 Also, where different scaling of metrics and different policies exist 323 inside an Administrative Domain, the Alto Server is instructed via 324 management on how to compare or normalize the data received from the 325 network. The network is not expected to provide translation or 326 normalization. 328 4.2. The ALTO Server-to-Server Interface 330 The ALTO Server-to-Server API is required because each ALTO Server 331 will likely have only a partial view of the overall network. The 332 ALTO Server's view of the network depends on which routers are the 333 sources of its topology data. Each router's topology data depends on 334 the administrative domain (Autonomous System) where the router is 335 deployed. In order to generate a combined network/cost map that 336 covers the network beyond its own Autonomous System, an ALTO Server 337 needs to exchange its map information with other ALTO Servers in 338 other network locations and/or administrative domains. To allow 339 generation of combined maps, costs in partial cost maps must be 340 normalized. 342 The network and cost maps defined in the Client-to-Server ALTO 343 interface provide sufficient semantics to be considered a good 344 candidate for the Server-to-Server information exchange. In other 345 words, the ALTO Client-to-Server interface can be used for 346 communication between ALTO Servers as well. 348 Note that the idea of sharing information directly between ALTO 349 clients has already been anticipated, as stated in Section 3.1.4 in 350 ALTO Requirements [I-D.ietf-alto-reqs]: 352 REQ. ARv07-31: The ALTO client protocol SHOULD allow the ALTO server 353 to add information about appropriate modes of re-use to its ALTO 354 responses. Re-use may include redistributing an ALTO response to 355 other parties, as well as using the same ALTO information in a 356 resource directory to improve the responses to different resource 357 consumers, within the specified lifetime of the ALTO response... 359 Also, although not a formal part of the ALTO protocol, support for 360 redistribution of ALTO data between clients has been anticipated in 361 the ALTO Protocol specification [I-D.ietf-alto-protocol] - see 362 Sections 6.2 and 8. Sharing data between ALTO Servers is similar, 363 but not the same. 365 Typically, an ALTO Server will handle requests for different 366 services. Moreover, the level of trust between different ALTO 367 Servers can vary. Therefore, topology passed via the Server-to- 368 Server API may be summarized, aggregated, or incomplete as long as 369 they are sufficient to meet the requirements implied by the client's 370 request. 372 5. Conclusion 374 Having well-defined standard APIs will facilitate inter-operation 375 between ALTO Servers and the different sources of information that 376 are required to put together the maps. It will also facilitate 377 inter-operation between the ALTO Servers themselves. Multiple ALTO 378 Servers in different administrative domains may be required to 379 combine partial network maps / cost maps into an overall set of maps 380 that cover a larger multi-provider network or the whole internet. 381 Altogether, having standardized APIs will facilitate inter- 382 operability between ALTO Servers from different vendors. 384 6. IANA Considerations 386 This document makes no request of IANA. 388 Note to RFC Editor: this section may be removed on publication as an 389 RFC. 391 7. Security Considerations 393 ALTO offers advice to applications on the optimality of various 394 possible Internet destinations for acquiring a resource or service. 395 An attacker who subverts or impersonates an ALTO service might be 396 able to trick many application on the Internet into contacting the 397 same host as a part of a distributed denial of service attack, for 398 example. Interfaces that provision the back-end of ALTO servers are 399 therefore a potentially attractive to attackers, as attackers might 400 attempt to corrupt the ALTO database in order to launch such an 401 attack. 403 For an ALTO server back-end interface to accept topology data from 404 BGP, the server must trust the source of the information. The ALTO 405 server must peer with a known route reflector, and must authenticate 406 that entity, especially if it is outside the administrative domain of 407 the ALTO server. Any origin security mechanisms will also increase 408 the assurance of the ALTO server. Integrity protection for the 409 channel between the ALTO server and the BGP speaker will also prevent 410 malicious parties from inserting problem information. 412 Similarly, the ALTO server-to-server mechanism also requires an 413 authentication and data integrity mechanism. If ALTO servers share 414 network maps between one another, for example, assuring the 415 authenticity and source of data is essential. If ALTO servers share 416 network maps with one another over a public network, a 417 confidentiality mechanism will also be desirable in order to prevent 418 eavesdropping. 420 8. Acknowledgements 422 Hannes Gredler from Juniper Networks made significant contributions 423 to concepts presented in this draft. We would like to thank Alia 424 Atlas from Juniper Networks for her input and comments. 426 9. References 428 9.1. Normative References 430 [I-D.gredler-bgp-te] 431 Gredler, H. and J. Medved, "Advertising Traffic 432 Engineering Information in BGP", draft-gredler-bgp-te-00 433 (work in progress), March 2011. 435 [I-D.ietf-alto-protocol] 436 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 437 draft-ietf-alto-protocol-06 (work in progress), 438 October 2010. 440 [I-D.ietf-alto-reqs] 441 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 442 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 443 Requirements", draft-ietf-alto-reqs-07 (work in progress), 444 January 2011. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 450 Protocol 4 (BGP-4)", RFC 4271, January 2006. 452 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 453 Optimization (ALTO) Problem Statement", RFC 5693, 454 October 2009. 456 9.2. Informative References 458 [I-D.lee-alto-chinatelecom-trial] 459 Li, K. and G. Jian, "ALTO and DECADE service trial within 460 China Telecom", draft-lee-alto-chinatelecom-trial-01 (work 461 in progress), October 2010. 463 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 464 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 465 Provider Participation for P2P (P4P) Technical Trial", 466 RFC 5632, September 2009. 468 Authors' Addresses 470 Jan Medved 471 Juniper Networks 472 1194 N. Mathilda Ave. 473 Sunnyvale, CA 94089 474 US 476 Email: jmedved@juniper.net 478 David Ward 479 Juniper Networks 480 1194 N. Mathilda Ave. 481 Sunnyvale, CA 94089 482 US 484 Email: dward@juniper.net 486 Jon Peterson 487 Neustar 489 Email: jon.peterson@neustar.biz 491 Richard Woundy 492 Comcast Corporation 493 27 Industrial Avenue 494 Chelmsford, MA 01824 495 US 497 Email: Richard_Woundy@cable.comcast.com 498 David McDysan 499 Verizon 500 22001 Loudoun County Pkwy 501 Ashburn, VA 20147 502 US 504 Email: dave.mcdysan@verizon.com