idnits 2.17.1 draft-penno-alto-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 04, 2009) is 5524 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) == Unused Reference: '14' is defined on line 893, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- No information found for draft-wang-p4p-spec - is the name correct? == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-04 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 == Outdated reference: A later version (-02) exists of draft-mrw-behave-nat66-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Penno, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Yang, Ed. 5 Expires: September 5, 2009 Yale University 6 March 04, 2009 8 ALTO Protocol 9 draft-penno-alto-protocol-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The ALTO Service enables an Internet Service Provider (ISP) to convey 48 cost preferences to network applications in order to modify network 49 resource consumption patterns while maintaining or improving 50 application performance. Applications that could use this service 51 are those that have a choice in connection endpoints. Examples of 52 such applications are peer-to-peer (P2P) and content delivery 53 networks. 55 Applications already have access to great amount of underlying 56 topology information. For example, views of the Internet routing 57 table are easily available at looking glass servers and entirely 58 practical to download to every client. What is missing is the cost 59 information -- what does an ISP or Content Provider actually prefer? 61 This document describes a very simple protocol that allows a ISP to 62 convey such information to applications. While such service would 63 primarily be provided by the network, i.e., the local ISP, Content 64 Provider and third parties could also operate this service. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [1]. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Protocol Design Approach . . . . . . . . . . . . . . . . . . . 5 77 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 78 5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 6. ALTO Specification . . . . . . . . . . . . . . . . . . . . . . 7 80 6.1. Protocol Version (v=) . . . . . . . . . . . . . . . . . . 8 81 6.2. Message Identifier (m=) . . . . . . . . . . . . . . . . . 8 82 6.3. Query Type (q=) . . . . . . . . . . . . . . . . . . . . . 8 83 6.4. Response (r=) . . . . . . . . . . . . . . . . . . . . . . 8 84 6.5. Originator (o=) . . . . . . . . . . . . . . . . . . . . . 8 85 6.6. Network Location (n=) . . . . . . . . . . . . . . . . . . 9 86 6.7. Cost (c=) . . . . . . . . . . . . . . . . . . . . . . . . 9 87 7. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 88 7.1. Getcost Query . . . . . . . . . . . . . . . . . . . . . . 10 89 7.2. Getcost Response . . . . . . . . . . . . . . . . . . . . . 11 90 7.3. GetnetworkIdentifier Query . . . . . . . . . . . . . . . . 12 91 7.4. GetnetworkIdentifier Response . . . . . . . . . . . . . . 12 92 7.5. Getnetworkmap Query . . . . . . . . . . . . . . . . . . . 13 93 7.6. Getnetworkmap Response . . . . . . . . . . . . . . . . . . 13 94 8. Alto Server Message Processing . . . . . . . . . . . . . . . . 13 95 8.1. Exception Handling . . . . . . . . . . . . . . . . . . . . 13 96 8.2. Successful Responses . . . . . . . . . . . . . . . . . . . 13 97 8.3. Invalid Query Format . . . . . . . . . . . . . . . . . . . 13 98 8.4. Unsupported Query . . . . . . . . . . . . . . . . . . . . 13 99 9. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 10. P2P Client Peer Selection Example . . . . . . . . . . . . . . 14 101 11. Message Exchanges Examples . . . . . . . . . . . . . . . . . . 15 102 11.1. Request cost for all NL-IDs . . . . . . . . . . . . . . . 15 103 11.2. Request NL-ID for Own IP Address . . . . . . . . . . . . . 16 104 11.3. Request NL-IDs for List of IP Addresses . . . . . . . . . 16 105 11.4. Request NL-ID Map . . . . . . . . . . . . . . . . . . . . 16 106 11.5. Request the Cost Between two NL-IDs . . . . . . . . . . . 16 107 12. Network Address Translation Considerations . . . . . . . . . . 16 108 13. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . . . 16 109 14. ALTO Protocol Grammar . . . . . . . . . . . . . . . . . . . . 17 110 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 111 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 113 18. Security Considerations . . . . . . . . . . . . . . . . . . . 19 114 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 19.1. Normative References . . . . . . . . . . . . . . . . . . . 19 116 19.2. Informative References . . . . . . . . . . . . . . . . . . 20 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 119 1. Introduction 121 Applications employ a variety of methods to get the best performance 122 out of the network. Today the information available to applications 123 is mostly the view from end hosts. There is no clear mechanism to 124 convey information about the network's preferences to applications. 125 For example, peer-to-peer applications have been successful in 126 achieving a good level of service for bulk transfer applications, but 127 can work with the network better if they can leverage ISP policy and 128 information. The ALTO service intends to provide a simple way to 129 convey ISP preferences to applications. 131 This document describes a very simple protocol that allows a ISP to 132 convey such information to applications. The protocol specified here 133 is a merge between two other protocols, Alto Info-Export[4] and 134 P4P[5][6] and due to this fact is a work in progress. 136 2. Terminology 138 We use the following terms defined in [7]: Application, Overlay 139 Network, Peer, Resource, Resource Identifier, Resource Provider, 140 Resource Consumer, Resource Directory, Transport Address, Host 141 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 142 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 143 Transit Traffic. 145 The terminology introduced in this document is listed below. 147 o Cost: Cost defines the preference of a network location type and 148 identifier from the point of view of another network location 149 identifier. The notion of cost was decouple from the network 150 location type to allow for maximum flexibility in meeting 151 different requirements. 153 o Network location type (NL-T): There are many types of network 154 location types: IP Prefixes, Autonomous System, PIDs, geographical 155 location, etc 157 o Network Location Identifier (NL-ID): A specific value of a network 158 location type. 160 o PID: A Partition ID, or a PID for short, is an identifier that 161 provide an indirect and network agnostic way to specifying NL-IDs. 162 It can denote a subnet, a set of subnets, or an autonomous system 163 (AS), for example. 165 3. Protocol Design Approach 167 The protocol specified in this document is a merge between two other 168 protocols, Alto Info-Export[4] and P4P[5][6]. The goal is to provide 169 an unified protocol that meets the ALTO requirement[8], provides an 170 migration path for ISP, Content Providers, and clients that have 171 deployed the above mentioned protocols and yet remain simple. 173 4. Protocol Overview 175 Each network region can choose to support the ALTO service. (A 176 network region in this context is an Autonomous System, an ISP, or 177 perhaps a smaller region -- the details depend on the mechanism of 178 discovery.) 180 +--------------------------------------------------------------------+ 181 | ISP | 182 | | 183 | +---------+ | 184 | | Routing | | 185 | +--------------+ | Policy | | 186 | | Provisioning | +---------+ | 187 | | Policy | | | 188 | +--------------+\ | | 189 | `. | | 190 | \ | | 191 | +-----------+ `.+---------+ +--------+ | 192 | |Dynamic | | ALTO | ALTO Query/Response | ALTO | | 193 | |Network |.......| Server | -------------------- | Client | | 194 | |Information| +---------+ +--------+ | 195 | +-----------+ .,- / | 196 | _,-' ALTO SD Query/Response / | 197 | ,-' / | 198 | +----------+ +--------------+ | 199 | | External | | ALTO Service | | 200 | | Interface| | Discovery | | 201 | +----------+ +--------------+ | 202 | | | 203 | | Figure 1: Basic ALTO Architecture. | 204 | | | 205 +--------------------------------------------------------------------+ 206 | 207 +------------------+ 208 | Third Parties | 209 | | 210 | Content Providers| 211 +------------------+ 213 The service works as follows: 215 1. The ISP prepares the ALTO information which constitutes the ISP's 216 "My-Internet view" [9] and populates the ALTO Server. This 217 information mainly consists of network locations identifiers and 218 their associated cost. The information in the ALTO Server can be 219 updated dynamically based on network conditions or can be seen as 220 a policy, which is updated on much longer time-scales. In the 221 most simple case this maps some IP prefixes or AS numbers into 222 priority values. 224 2. The ISP serializes the information into a sequence of octets. 226 3. The application, running on a given host, discovers the resource 227 and fetches the serialized ALTO information (Section 7). 229 4. The application makes use of the information by preferring 230 network locations with higher priority (Section 8) 232 The part of the ISP MAY be implemented, to give a few examples, that 233 do not preclude other implementation options: 235 by running a script connecting to existing equipment, fetching 236 routing information, and then generating and uploading the 237 requisite file; 239 by running a database-backed application that is obtains routing 240 information from existing equipment and generates the requisite 241 file dynamically; 243 by modifying the software or hardware of existing equipment to 244 support these functions; or 246 by using new equipment for the purpose of operating this network 247 service. 249 5. Discovery 251 Discovery of the ALTO Server is out of scope for this document and 252 will be handled separately. A discussion of the different possible 253 protocols to discover an ALTO Service can be found in [10] 255 The necessary property of discovery is that a client, starting from 256 nothing on today's Internet that does not yet universally support 257 global-scope multicast and may include NATO's, can ultimately find 258 the IP address of the ALTO Server as configured by the ISP. 259 Subsequent sections assume that this IP address is known to the 260 client 262 6. ALTO Specification 264 The ALTO protocol design borrows ideas from the Session Description 265 Protocol[2] with the goal of leveraging the current HTTP[[3]RFC2616] 266 implementations and infrastructure. An ALTO information exchange is 267 denoted by the HTTP header Content-Type "application/alto" and is 268 carried within HTTP similarly to how SDP is carried within SIP. This 269 approach has several advantages: 271 o It leverages the huge installed base of HTTP infrastructure 273 o It leverages all the mature software that has been implemented for 274 both HTTP and SDP. 276 o It leaves HTTP free of proprietary headers ("X-") 278 o It does not require use of specific URIs to denote service 280 o It allows the protocol to evolve separately from HTTP. 282 o it makes the protocol easy to understand and debug 284 o It leverages the fact that many P2P clients already have an 285 embedded HTTP client 287 o Finally it allows the ALTO protocol to be carried by other 288 protocols other than HTTP in the future, such as SIP. 290 An ALTO Information description consists of a number of lines of text 291 of the form: = where MUST be exactly one case- 292 significant character and is structured text whose format 293 depends on . In general, is either a number of fields 294 delimited by a single space character or a free format string, and is 295 case-significant unless a specific field defines otherwise. 296 Whitespace MUST NOT be used on either side of the "=" sign. 298 Some lines in each description are REQUIRED and some are OPTIONAL, 299 but all MUST appear in exactly the order given here (the fixed order 300 greatly enhances error detection and allows for a simple parser). 301 OPTIONAL items are marked with a "*". 303 Support Types: 305 v=(protocol version) 307 m=(message identifier) 309 q=(Query type) 311 r=(Response) 313 o=(originator) 315 c=(cost) 317 n=(network) 319 6.1. Protocol Version (v=) 321 v=1 323 The line defines the protocol version. The version specified in this 324 document is 1. 326 6.2. Message Identifier (m=) 328 m= 330 This allows transactions and demultiplexing of messages at the 331 application level 333 6.3. Query Type (q=) 335 q= [[:SRC ]] 338 The query type can be getcost, getnetworklocation and getstatus. 339 Depending on the query type, different types of parameters are sent 340 and received from the server 342 6.4. Response (r=) 344 r = [[ | [ ]] 346 This line is used by the Server in a response to a previous query. 348 6.5. Originator (o=) 350 o= 352 This line identifies the originator of cost information, which is not 353 necessarily related to the source IP address of the message. 355 6.6. Network Location (n=) 357 n=[:]SRC 358 DEST [] 360 The following network location types are specified in this document: 362 o ASN: Autonomous System Number 364 o IPV4: IP Protocol version 4 366 o IPV6: IP Protocol version 6 368 o PID: Partition ID 370 The network location can be used in the getcost and 371 getnetworklocation query to specify the mapping needed. 373 6.7. Cost (c=) 375 c=:SRC DEST 376 378 The cost is the measure of an network identifier preference. This 379 document specifies the following network location types: IP Prefixes, 380 ASNs and PIDs. The cost needs to include the location type unless it 381 is present at the subsection level. Network Locations with positive 382 priorities are more desirable than the default. Network Locations 383 with negative priorities are less desirable than the default. 385 The cost type defines the contextual representation of the cost. The 386 specification defines two cost types: rank and generic distance. 388 7. ALTO Messages 390 ALTO Queries must have the following lines: 392 v=(version) 394 m=(message identifier) 396 q=(query type) 398 Alto responses must have: 400 v=(version ) 402 m=(message identifier) 404 r=(response) 406 7.1. Getcost Query 408 q=getcost [[:SRC ]] 411 n=[:]SRC DEST [] 414 A getcost request causes the server to return a list of network 415 location types, identifiers and their associated cost. If the 416 message does not specify the source network identifier and type the 417 server should assume that the source IP addresses indicates the 418 source network identifier. Alternatively the client can specify a 419 source network location type and identifier to be used for computing 420 the cost to other locations. 422 q=getcost :SRC 425 The response from the server in both of these cases is an unordered 426 list of costs for the network source and type specified by the client 427 such as: 429 r = getcost [[ | [ ]] 431 c=[:SRC ] 434 436 438 440 ... 442 Another possibility is for the client to request the cost between one 443 or more pair of network identifiers. 445 q=getcost [network location type] 446 n=[]:SRC DEST 447 449 In this case the response contain an ordered list of costs 450 corresponding to each pair specified in the request. If the server 451 for any reason cannot compute the cost between a certain SRC-DEST 452 pair, it needs to use an invalid cost in the reply. 454 The default network location type for request and responses are IP 455 Prefixes. 457 7.2. Getcost Response 459 The network location types used in the response should match the one 460 specified in the request unless none was specified. If a network 461 location type was specified, the response would be as follows: 463 r=getcost [[ | [ ]] 465 c=[:SRC ] 468 470 472 474 476 .... 478 If a network location type was not specified the server can bundle 479 the costs for each network type in sections as below: 481 r=getcost [[ | [ ]] 483 c=[:SRC ] 486 488 490 492 .... 494 c=[:SRC ] 497 499 501 503 .... 505 In the case the server responds the request with interleaved network 506 types, each cost needs to be present in a fully specified line as 507 below: 509 c=: 512 7.3. GetnetworkIdentifier Query 514 q=getnetworklocation [[:SRC ]] 517 n=[:]SRC 520 This request allows the client to query the network location for a 521 certain network identifier. The network location types used in the 522 request and response can be different. This query assumes a 1->1 523 relationship between the network identifier in the query and the one 524 in the response. This means that the query can be used to map from a 525 more fine grained network identifier to a more less granular one. 526 So, the client can use an IP address in the request and get a PID in 527 the response. 529 7.4. GetnetworkIdentifier Response 531 r=getnetworklocation [[ | [ ]] 534 n=: 536 The response to q network location query includes the network 537 location type and identifier. More than one network location line 538 can be present for a single query. 540 7.5. Getnetworkmap Query 542 TBD 544 7.6. Getnetworkmap Response 546 TBD 548 8. Alto Server Message Processing 550 This section specifies ALTO Server behavior when processing ALTO 551 queries. In general the ALTO protocol uses the same status codes as 552 HTTP. 554 8.1. Exception Handling 556 Standard HTTP status codes are returned by an ALTO Server in the 557 response (r=) line. 559 8.2. Successful Responses 561 An ALTO Server MUST use Status Code 200 when replying to an operation 562 that completed successfully. Note that this includes cases where the 563 ALTO Server responds with only a subset of the requested information. 564 The requesting application is expected to detect such cases if 565 necessary. 567 8.3. Invalid Query Format 569 If the Request Data is formatted incorrectly (i.e., it does not 570 follow the syntax in Section 6), the ALTO Server MUST return an 571 status code and reason of "400 Bad Request". 573 8.4. Unsupported Query 575 If an Alto Server does not support a certain type of query, e.g., 576 cost for SRC-DEST pairs, a status code and reason of "501 Not 577 Implemented" might be returned in lieu of returning an invalid cost. 579 9. Semantics 581 Network location identifiers with positive priorities are more 582 desirable than the default. Network locations identifiers with 583 negative priorities are less desirable than the default. In general, 584 greater values are more desirable. Zero priority is the default. 585 Network Location Identifiers not specified are treated as if they had 586 priority zero. 588 The absolute value of the priorities does not matter. Only their 589 relative order is meaningful. Higher values are more desirable. For 590 example, multiplying all the priority values in a given file by the 591 same positive integer constant does not change the semantics of the 592 file. 594 Some ISPs already convey information such as "traffic in the local 595 country is free" to their customers. These ISPs will find the ALTO 596 service an excellent means of conveying similar information in a 597 machine-readable form. Only one (positive) priority value is needed 598 for such use. 600 It is up to the ISP deploying the file to choose how much information 601 to publish in it. 603 10. P2P Client Peer Selection Example 605 After the client application receives a list of network location 606 identifier and their cost from the ALTO Server, it needs to make a 607 selection on of which peers to use based on this and other sources of 608 information. With this in mind, the semantics of the information are 609 intentionally flexible, because: 611 Different applications will necessarily use the information 612 differently. For example, an application that connects to just 613 one address is going to have a different algorithm for selecting 614 it than an application that connects to many. 616 Given lack of Internet-scale experimentation with using the 617 information, we don't yet know what the best ways are. We want to 618 give different approaches a chance to compete. 620 However, it's important to provide at least a non-normative example 621 of how such cost information could be used. 623 Consider a BitTorrent client that wishes to use the ALTO information. 624 The client will have a list of perhaps up to 200 initial candidate 625 peers, out of which it will select perhaps 50 peers to try to connect 626 to. In an initial implementation, the client could: 628 Split the candidates into three sets: preferred (those with 629 positive priorities), to-be-avoided (those with negative 630 priorities), and default (0 or unspecified priority) 631 Select up to 25 candidates randomly from the preferred set. In 632 particular, if there are fewer than 25 in the preferred set, 633 select them all. 635 Fill remaining slots up to 50 with candidates from the default 636 set. 638 If this didn't fill the slots (i.e., fewer than 50 of the 639 candidates were in the union of preferred and default sets), fill 640 the rest by candidates from the to-be-avoided set. 642 When establishing connections after the initial startup, continue 643 using the policy of giving up to half the slots to preferred with 644 the rest for default and to-be-avoided only as last resort. 646 When selecting a peer to optimistically unchoke, half the time 647 select a preferred peer if there is one. 649 (The particular numbers could be different.) If the preferred peers 650 perform better than default ones, they will dominate the transfers. 651 To-be-avoided peers are largely not contacted, unless the prohibitive 652 policy is broad enough or the swarm is small enough that it is 653 necessary to contact them to fill the slots. 655 In addition, the application might use some form of randomized test 656 to see if it performs better or worse when the ALTO service use is 657 on. 659 11. Message Exchanges Examples 661 The sections below depict a few typical messages examples. The ALTO 662 protocol can be used with both GET and POST HTTP methods, the 663 difference is mainly how caching would work. This section will be 664 further specified in the next revisions of the document. 666 11.1. Request cost for all NL-IDs 668 In the simplest form the client sends a getcost query to the ALTO 669 Server specifying nothing else. The server assumes the source NL-ID 670 is the source IP address of the packet and returns the cost for all 671 NL-IDs from this point of view. See below 673 v=1 675 q=getcost 677 This allow the protocol to work through NATO's without ALGs support. 679 The format and purpose of the query becomes is to download the full 680 list of costs to every other NL-ID from the client point of view. 682 11.2. Request NL-ID for Own IP Address 684 The following message exchange illustrates a client requesting its 685 own NL-ID from the ALTO Server. The client uses an empty query, and 686 the Alto Server responds with the client's IP address and the NL-ID 687 corresponding to the IP address. 689 11.3. Request NL-IDs for List of IP Addresses 691 The following message exchange illustrates a client directly asking 692 the ALTO Server to map a set of IP addresses into their corresponding 693 NL-IDs. 695 11.4. Request NL-ID Map 697 The following message exchange illustrates an application requesting 698 the set of IP addresses contained within a set of NL-IDs. 700 11.5. Request the Cost Between two NL-IDs 702 The following message exchange illustrates an application requesting 703 the routing cost between particular NL-IDs. 705 12. Network Address Translation Considerations 707 At this day and age of v4<->v4, v4<->v6[11] and possibly v6<->v6[12] 708 NATO's, a protocol should strive to be NAT friendly and minimize 709 carrying IP addresses in the payload, or provide a mode of operation 710 where the source IP address provide the information necessary to the 711 server. 713 The protocol specified in this document provides a mode of operation 714 where the source NL-ID is the source IP address of the packet. This 715 is very similar to how Tracker based P2P networks such as Bittorrent 716 work. See "Tracker HTTP/HTTPS Protocol" in [13]. This allows a 717 client to work through NATO's without the need for ALGs or NAT 718 traversal mechanisms. 720 13. Mapping IPs to ASNs 722 DISCUSSION: Applications can already map IPs to ASNs using 723 information from a BGP looking glass. To do so, they have to 724 download a file of about 1.5MB when compressed (as of October 2008, 725 with all information not needed for IP to ASN mapping removed) and 726 periodically (perhaps monthly) refresh it. 728 Alternatively, the ALTO service as defined in this document could be 729 expanded so that there is another file that expands every ASN 730 mentioned in the policy file into a set of IP prefixes. In that 731 case, the ASNs in the policy file, from a client's perspective, would 732 be treated like macros. The mapping file provided by the ISP would 733 be both smaller and more authoritative. 735 For simplicity of implementation, it's highly desirable that clients 736 only have to implement exactly one mechanism of mapping IPs to ASNs. 738 We're interested in perspectives of others on this. 740 14. ALTO Protocol Grammar 742 All of the mechanisms specified in this document are described in 743 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 744 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that 745 are used by this specification, and not repeated here. Implementers 746 need to be familiar with the notation and content of RFC 2234 in 747 order to understand this specification. Certain basic rules are in 748 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle 749 brackets are used within definitions to clarify the use of rule 750 names. 752 hostport = host [ ":" port ] 754 host = hostname / IPv4address / IPv6reference 756 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 758 IPv6address = hexpart [ ":" IPv4address ] 760 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 762 hexseq = hex4 *( ":" hex4) 764 hex4 = 1*4HEXDIG 766 port = 1*DIGIT 768 15. Acknowledgements 770 TBD. 772 16. Contributors 774 The people listed here should be viewed as co-authors of the 775 document. Due to the limit of 5 authors per draft the co-authors 776 were moved to the contributors section at this point. 778 Richard Alimi 780 Yale University 782 EMail: richard.alimi@yale.edu 784 D. Pasko 786 Verizon 788 EMail: pasko@verizon.com 790 L. Popkin 792 Pando Networks 794 EMail: laird@pando.com 796 Satish Raghunath 798 Juniper Networks 800 satishr@juniper.net 802 Stanislav Shalunov 804 BitTorrent 806 EMail: shalunov@bittorrent.com 808 Yu-Shun Wang 809 Microsoft Corp. 811 yu-shun.wang@microsoft.com 813 Richard Woundy 815 Comcast 817 Richard_Woundy@cable.comcast.com 819 17. IANA Considerations 821 This document request the registration of a new media type: 822 "application/alto" 824 18. Security Considerations 826 The ISP publishing the ALTO policy information has to treat it as 827 publishing to the entire world. 829 Applications using the information must be cognizant of the 830 possibility that the information is malformed or incorrect. Even 831 when it is correct, its use might harm the performance. When an 832 application concludes that it would get better performance 833 disregarding the ALTO information, the decision to discontinue the 834 use of ALTO information is likely best left to the user. 836 The use of TLS (using the "https" URL schema) will make it easier for 837 clients to verify the origin of ALTO information. 839 19. References 841 19.1. Normative References 843 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 844 Levels", BCP 14, RFC 2119, March 1997. 846 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 847 Description Protocol", July 2006. 849 [3] Fielding, R., J. Gettys, V., Mogul, J., Frystyk, H., Masinter, 850 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol 851 -- HTTP/1.1", June 1999. 853 19.2. Informative References 855 [4] S. Shalunov, R. Penno, and R. Woundy, "ALTO Information Export 856 Service", draft-shalunov-alto-infoexport-00 (work 857 in progress) 2008. 859 [5] R. Alimi, D. Pasko, L. Popkin, Y. Wang., "P4P: Provider Portal 860 for (P2P) Applications", draft-p4p-framework-00 (work in 861 Progress) 2008. 863 [6] Wang, Y., Alimi, R., Popkin, L., and YR. Yang, "P4P Protocol 864 Spec", draft-wang-p4p-spec-00, 2009. 866 [7] Seedorf, J. and E. Burger, "Application-Layer Traffic 867 Optimization (ALTO) Problem Statement", 868 draft-marocco-alto-problem-statement-04 (work in 869 progress) 2009. 871 [8] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and YR. Yang, 872 "Application-Layer Traffic Optimization (ALTO) Requirements", 873 draft-kiesel-alto-reqs-01 (work in progress) 874 2008. 876 [9] Yang (Ed.), YR., "An Architecture of ALTO for P2P 877 Applications", draft-yang-alto-architecture-00.txt, 2009. 879 [10] Garcia, G., Tomsu, M., and Wang, Y., "Alto Discovery Protocol", 880 draft-wang-alto-discovery-00.txt, 2009. 882 [11] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 883 Translation", February draft-baker-behave-v4v6-framework-02, 884 2009. 886 [12] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 887 Translation (NAT66)", November draft-mrw-behave-nat66-01.txt, 888 2008. 890 [13] "Bittorrent Protocol Specification v1.0", 891 http://wiki.theory.org/BitTorrentSpecification, 2009. 893 [14] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 894 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 895 In SIGCOMM 2008. 897 Authors' Addresses 899 Reinaldo Penno (editor) 900 Juniper Networks 901 1194 N Mathilda Avenue 902 Sunnyvale, 904 Phone: 905 Fax: 906 Email: rpenno@juniper.net 907 URI: 909 Y. Richard Yang (editor) 910 Yale University 912 Phone: 913 Fax: 914 Email: yry@cs.yale.edu 915 URI: