idnits 2.17.1 draft-dulinski-alto-inter-alto-protocol-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2010) is 5050 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 (-27) exists of draft-ietf-alto-protocol-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Z. Dulinski 3 Internet-Draft Jagiellonian University 4 Intended status: Standards Track R. Stankiewicz 5 Expires: December 31, 2010 P. Cholda 6 P. Wydrych 7 AGH University of Science and 8 Technology 9 B. Stiller 10 University of Zurich 11 June 29, 2010 13 Inter-ALTO communication protocol 14 draft-dulinski-alto-inter-alto-protocol-00 16 Abstract 18 The ALTO service provides the information, which can make 19 communication between applications more efficient, especially in case 20 of overlay applications. Such applications can use the information 21 to perform better-than-random peer selection. The ALTO protocol 22 conveys network information to applications. The protocol definition 23 of this document extends the functionality of this ALTO service by 24 introducing a standardized manner of communications between ALTO 25 servers. A new inter-ALTO protocol is proposed, which enables the 26 exchange of information between ALTO servers. The servers can 27 coordinate actions and can introduce policies, which provide 28 communication between applications localized in cooperating 29 Autonomous Systems with a higher performance and a better cost 30 efficiency. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 31, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1. Route asymmetry . . . . . . . . . . . . . . . . . . . . . 6 76 2.2. Different types of business relations . . . . . . . . . . 7 77 2.3. Congestion avoidance . . . . . . . . . . . . . . . . . . . 7 78 2.4. Proximity awareness . . . . . . . . . . . . . . . . . . . 7 79 2.5. Remote ISP preference . . . . . . . . . . . . . . . . . . 8 80 2.6. Coordination of ISPs' policies . . . . . . . . . . . . . . 8 81 2.7. Sensitivity of topology information . . . . . . . . . . . 9 83 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.1. ALTO-ISP communities . . . . . . . . . . . . . . . . . . . 10 85 3.1.1. Mandatory parameters . . . . . . . . . . . . . . . . . 10 86 3.1.2. Optional parameters . . . . . . . . . . . . . . . . . 10 87 3.1.3. Parameter updates . . . . . . . . . . . . . . . . . . 11 88 3.2. GENERAL Community . . . . . . . . . . . . . . . . . . . . 12 89 3.3. ISP defined communities . . . . . . . . . . . . . . . . . 12 90 3.4. Inter-ALTO server capability . . . . . . . . . . . . . . . 13 92 4. Protocol description . . . . . . . . . . . . . . . . . . . . . 14 93 4.1. Definitions of elements of request/response messages . . . 14 94 4.1.1. Community . . . . . . . . . . . . . . . . . . . . . . 14 95 4.1.2. Peer list . . . . . . . . . . . . . . . . . . . . . . 14 96 4.1.3. List of parameters . . . . . . . . . . . . . . . . . . 15 97 4.1.4. Suggested parameter significance sequence . . . . . . 15 98 4.2. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 4.2.1. EXTENDED REQUEST . . . . . . . . . . . . . . . . . . . 16 100 4.2.2. BASIC REQUEST . . . . . . . . . . . . . . . . . . . . 17 101 4.2.3. Recommended usage of requests . . . . . . . . . . . . 18 102 4.3. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18 103 4.3.1. REFUSE RESPONSE . . . . . . . . . . . . . . . . . . . 18 104 4.3.2. ERROR RESPONSE . . . . . . . . . . . . . . . . . . . . 19 105 4.3.3. NORMAL RESPONSE . . . . . . . . . . . . . . . . . . . 19 106 4.4. Message exchange patterns . . . . . . . . . . . . . . . . 20 107 4.4.1. Successful communication within a given community . . 20 108 4.4.2. Rejected communication within the given community . . 21 109 4.4.3. Handling wrong parameter names in the request . . . . 23 111 5. Inter-ALTO server discovery . . . . . . . . . . . . . . . . . 25 113 6. Reliability considerations . . . . . . . . . . . . . . . . . . 27 114 6.1. Reliability of a local ALTO server . . . . . . . . . . . . 27 115 6.1.1. Redundancy of elements . . . . . . . . . . . . . . . . 28 116 6.1.2. Partitioning of functionalities . . . . . . . . . . . 28 117 6.2. Reliability of a remote ALTO server . . . . . . . . . . . 29 118 6.3. Reliability of underlying IP networks . . . . . . . . . . 29 119 6.4. Reliability of the inter-ALTO server discovery . . . . . . 29 121 7. Scalability considerations . . . . . . . . . . . . . . . . . . 31 123 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 125 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 126 9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 33 127 9.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 33 128 9.3. Data confidentiality . . . . . . . . . . . . . . . . . . . 33 129 9.4. Data integrity . . . . . . . . . . . . . . . . . . . . . . 33 130 9.5. Availability . . . . . . . . . . . . . . . . . . . . . . . 34 132 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 134 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 136 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 137 12.1. Normative References . . . . . . . . . . . . . . . . . . . 37 138 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 142 1. Introduction 144 This document describes the communication protocol to be used between 145 ALTO servers located in different autonomous systems (AS). The 146 proposed inter-ALTO protocol extends the ALTO service [RFC5693] 147 capabilities and provides additional information on remote peers, 148 that is, peers located in other ASes. This information MAY be used 149 by an ALTO server to perform advanced sorting/rating procedure of 150 peers. The general idea is as follows: 152 1. A peer receives from a tracker a list of other peers - potential 153 candidates to communicate with. 155 2. A peer uses the ALTO protocol [I-D.ietf-alto-protocol] to send 156 the list of peers to its local ALTO server. 158 3. Local ALTO server obtains additional information on remote peers 159 by communicating respective ALTO servers. 161 4. Using ISP specific policies and values of parameters associated 162 with remote peers the local ALTO server performs sorting/rating 163 procedure. 165 5. Sorted/rated list of peers is sent back to the peer. 167 The sorting/rating procedure is out of scope of this document. The 168 inter-ALTO communication protocol that makes it possible to obtain 169 extended information on remote peers is proposed. 171 To make the consideration more clear we distinguish local AS and 172 remote ASes. Local AS is the one from which perspective we describe 173 the communication. Local peers are located in the local AS and are 174 served by a local ALTO server. On contrary, all other peers are 175 located in remote ASes. Those peers are referred to as remote and 176 are served by remote ALTO server. This basic terminology adheres to 177 majority of considerations in this document. 179 2. Motivation 181 ALTO server optimization capabilities are limited by the fact that 182 they use information available locally only. It can be shown that 183 more information on remote peers, a routing path, or remote ISP 184 preferences would be useful. The data from remote peer ASes will 185 have a substantial significance for the management of overlay traffic 186 (e.g. with respect to peer rating, sorting, or the choice of the best 187 peers). The suggested approach to deliver these types of information 188 is defined in the inter-ALTO communication protocol proposed. 190 In particular, the following key aspects motivate the proposal of an 191 inter-ALTO protocol: 193 o Route asymmetry. 195 o Different types of business relations. 197 o Congestion avoidance. 199 o Proximity awareness (distance to the remote AS), e.g.: 201 * number of inter-AS hops; 203 * delay (RTT). 205 o Remote ISP preference. 207 o Coordination of ISPs' policies. 209 2.1. Route asymmetry 211 The communication between two ASes does not need to follow the same 212 path in the upstream and downstream direction. It was shown that 213 about 29% of paths between AS pairs in the Internet are fully 214 symmetric, that is upstream and downstream traffic follows exactly 215 the same path [Dulinski_ICC2010]. In 51% cases the number of 216 inter-AS hops is different for the upstream and downstream direction. 217 Additionally, in 50.5% of all path pairs a neighbor AS for upstream 218 and downstream paths are different. 220 The ALTO server can obtain routing information locally (e.g. from 221 BGP) and can determine the upstream path. Information about the 222 downstream path is usually not easily available. Some additional 223 routing information can be obtained from Looking Glass Servers, but 224 not all ASes provide them. The inter-ALTO protocol supports the 225 exchange of relevant information between ALTO servers. Especially, 226 the downstream path can be reliably determined using the information 227 provided by remote ALTO server. In the light of route asymmetry in 228 the Internet such information appears to be useful for a better 229 optimization of a peer rating/sorting algorithm. 231 2.2. Different types of business relations 233 Two basic business relations between ISPs may be distinguished. 235 When two ISPs agree to exchange the traffic without any charge, such 236 a relation is called peering. The inter-domain link between the 237 respective ASes is also called a peering link. Usually, there is not 238 charge if the difference between traffic volumes passing such a link 239 in different directions does not exceed agreed limit. 241 Often one ISP serves as a network provider to another ISP (e.g. 242 relation between tier 2 and tier 3 ISPs). In such a case one ISP 243 (acting as a customer) has to pay the other ISP (acting as provider) 244 for the traffic sent over the inter-AS link connecting them. The 245 real monetary cost of the traffic volume exchanged on such a link 246 depends on agreements between ISPs. In general, some links may be 247 considered as cheaper or more expensive. 249 AS may be connected to many other ASes with various agreements. The 250 cost of the inter-AS traffic transfer may differ depending on which 251 neighbor AS the path passes. For this reason an ISP may prefer its 252 own customers to exchange data with remote peers located in such ASes 253 that the path to them passes cheaper links. The ALTO server may sort 254 peers taking into account these criteria. To receive almost complete 255 information on routing paths to different remote domains the 256 information provided by remote ALTO server using inter-AS protocol 257 can be helpful. 259 2.3. Congestion avoidance 261 A peer sorting procedure MAY also take into account the congestions 262 on inter-AS links. An ISP can monitor queues on its inter-domain 263 links and assign metrics indicating the buffer occupancy or bandwidth 264 utilization. These metrics can express percentage use of buffers or 265 bandwidth on a particular inter-AS link. If one inter-domain link is 266 congested it is desirable to promote peers reachable through lightly 267 loaded links. Again, information provided by the remote ALTO server 268 would support such optimization. 270 2.4. Proximity awareness 272 For a set of reasons (e.g. the performance of an application) the 273 ALTO server may suggest its customers to connect to remote peers 274 located in its proximity. The simplest measure of proximity is the 275 number of inter-AS hops. Due to route asymmetry the number of hops 276 may differ between upstream and downstream paths, as indicated above. 277 Such information for the downstream path may be provided by the 278 remote ALTO server. A more advanced metric of proximity can be found 279 in the delay that can be approximated by exchanging messages between 280 ALTO servers. The ALTO servers can be equipped with an application 281 ping functionality which only operates between ALTO servers. By 282 exchanging special packets prepared by the ALTO servers, these 283 servers can estimate delay and packet loss. 285 2.5. Remote ISP preference 287 If two ISPs agree on a cooperation, the remote ALTO server MAY 288 provide its preference parameters (remote preference parameters) 289 indicating which peers are better from the point of view of the 290 remote ISP. For instance, the AS in which the remote ALTO server is 291 located may possess two subnets connected to the operator core 292 network by distinct links. It may happen that a connection to one of 293 the subnets is cheaper than the other. The remote operator may 294 prefer connections through cheaper link, so peers located in the 295 subnet transferring data via this cheaper link are preferred. 297 The remote preference parameter MAY be also used when a remote ISP 298 wants to suggest peers which are conncected to the Internet through 299 access links of higher capacity. This way, the remote ALTO server, 300 without exposing the exact values of access link bandwidth, may 301 indicate peers with higher throughput. The remote preference 302 parameters have only local meaning, that is, their values are 303 comparable for peers located in the same AS only. 305 If a remote ISP does not want to reveal numerical values of network 306 parameters related to its peers (such information might be considered 307 as confidential) the remote ALTO server may perform a sorting 308 procedure and assign priority parameter to its peers. The sorting 309 criteria MAY remain hidden for the requesting local ALTO server. 311 2.6. Coordination of ISPs' policies 313 Operators MAY coordinate their efforts in order to lower transfer 314 costs on inter-domain links or improve transfer performance 315 experienced by peers, namely coordinate peer sorting/rating 316 strategies. This way operators may avoid contradictory strategies 317 resulting in inefficiency of sorting/rating algorithms. Operators 318 may agree to promote each others peers, e.g. by always placing peers 319 serviced by the other party on the sorted/rated list amongst first 10 320 entries. 322 For example, it may happen that operator A wanting to decrease 323 traffic on one of its links discourages its own peers from 324 communicating with peers located in operator B's domain. On the 325 other hand, operator B would consider peers located in a domain of 326 operator A as very attractive for its own peers. As a result, 327 sorting/rating procedures performed by respective ALTO servers give 328 contradictory results what may lower the effectiveness of these 329 procedures. To avoid such a situation, the inter-ALTO protocol is 330 needed. 332 Another example of a usefulness of coordination of policies is 333 clustering of ASes. Recent studies have shown that locality 334 promotion might be ineffective or even harmful if used in AS with 335 small number of peers. A proposed solution is to create cluster of 336 two or more ASes. Then ALTO servers serving different ASes in the 337 cluster treat all peers located in the cluster as if they were in a 338 single AS. In other words, from a point of view of locality 339 promotion algorithm all peers located in the cluster are local, 340 regardless of their home AS. 342 2.7. Sensitivity of topology information 344 The minimum information that the remote AS MUST provide to the local 345 ALTO server via the inter-ALTO protocol are the number of inter-AS 346 hops and the number of the local AS' neighbor in the downstream path 347 (the full downstream AS_PATH MAY be not exchanged). Such information 348 does not reveal any sensitive information neither on the ISP internal 349 topology details nor remote AS connections with other ASes, but does 350 provide basic and useful information for the local ALTO server. 352 If two ISPs or even more agree on the exchange of additional 353 information, the protocol does allow for it. 355 3. Definitions 357 The inter-ALTO protocol enables communications between ALTO servers 358 located in remote ASes. Communicating ALTO servers MAY belong to 359 different ISPs. ISPs MAY decide to cooperate and exchange some set 360 of parameters. 362 3.1. ALTO-ISP communities 364 The set of parameters exchanged between ALTO servers is classified as 365 mandatory or optional. ALTO servers that agree on the exchange of a 366 particular set of mandatory parameters form an ALTO-ISP community. 367 These mandatory parameters MUST be exchanged always by ALTO servers 368 belonging to a given ALTO-ISP community. By joining a particular 369 ALTO-ISP community an ISP commits to be ready to send mandatory 370 parameters to all other members of the community. A unique set of 371 mandatory parameters constitutes the community. 373 The ALTO server MAY belong to many ALTO-ISP communities, depending on 374 which set of mandatory parameters it is willing to exchange. An ISP 375 MAY possess a few ALTO servers in order to separate the inter-ALTO 376 traffic. 378 3.1.1. Mandatory parameters 380 The names of mandatory parameters and their meaning MUST be defined 381 for each ALTO-ISP community. 383 All mandatory parameters defined for a given community MUST always be 384 sent in a response to the request. A local ALTO server MAY use only 385 a selection of received mandatory parameters for sorting peers or it 386 MAY use none of them. Thus, the receipt of mandatory parameters does 387 not oblige operators to use them for overlay management. 389 3.1.2. Optional parameters 391 The names of optional parameters and their meaning MUST be defined 392 for each ALTO-ISP community. 394 Optional parameters MAY be exchanged on demand or on scheduled basis. 395 These optional parameters MAY be requested by the local ALTO server, 396 but the remote ALTO server MAY refuse to deliver them. 398 The remote ALTO server responding to the request MAY also send some 399 unsolicited optional parameters. In this way a remote ALTO server 400 suggests the local ALTO server additional criteria that MAY be used 401 for sorting peers. For instance a remote ALTO server can send a 402 remote preference parameter (described in Section 2.5) as an optional 403 parameter. The ALTO server to which the response is addressed MAY 404 always ignore these parameters. 406 3.1.3. Parameter updates 408 It is assumed that for sorting/rating procedures ALTO servers mostly 409 use parameters which are quite constant in time. ALTO servers SHOULD 410 extensively cache received parameter values. Timers MAY be 411 established for all cached parameters, and the update procedures MUST 412 be decided during the parameter exchange. 414 Two update methods are defined: "push" and "pull". 416 The "pull" update method indicates that when a new value is expected, 417 the local ALTO server sends a request with the name of the parameter 418 (with a relevant peer list) for which the current value is required. 420 The "push" update method is used if a decision on when to send a new 421 parameter value is left to the ALTO server responsible for this 422 parameter. The ALTO server implements a timer. The value of the 423 timer determines how often updates of this parameter value will be 424 sent. If the value of a timer equals 0, it means that a remote site 425 will send the current value, if a parameter value has changed (when a 426 predefined event changing a value of parameter has happened). A 427 value different from 0 defines update periodicity. A timer value 428 MUST be defined, if the "push" update method has been chosen. 430 The update method MUST be negotiated between ALTO servers. An ALTO 431 server sending a request for parameter values MAY suggest the update 432 method ("pull" or "push" with a timer setting MAY be proposed). A 433 decision about the update method is taken by the ALTO server sending 434 a parameter value. Finally, an ALTO server that receives the 435 parameter value and associated update method MAY accept this update 436 setting or reject it. The "pull" method MUST be always accepted. If 437 the "push" method is accepted a timer setting MUST also be accepted; 438 no more negotiation of timer setting is allowed. If an ALTO server 439 rejects "push" update method it means that it does not want to 440 receive unsolicited updates. Then it may change the update method to 441 "pull". It is done by requesting the same parameter again with the 442 "pull" update method. 444 The "pull" method is considered as the lowest update requirement. A 445 higher requirement is an event-based update (timer set to 0). The 446 highest requirement is periodic update. If an update method was 447 suggested by an ALTO server requesting a parameter value, the 448 responding ALTO server MAY accept the proposed settings or MAY lower 449 those setting requirements. 451 Communicating ALTO servers MAY change the update settings. The 452 "push" method MAY be always changed to the "pull". The timer value 453 MAY be changed to 0. Also, an ALTO server MAY resign from periodic 454 updates anytime by sending a request with the related parameter name 455 and the update parameter defined to the "pull" value. 457 3.2. GENERAL Community 459 The members of the GENERAL community MUST send information, which 460 follows from the BGP AS_PATH attribute. There are two mandatory 461 parameters: 463 o The autonomous system number of AS being a neighbor of a local AS 464 with respect to the downstream path (from the remote-AS to the 465 local-AS). The AS number is to be extracted from the AS_PATH 466 attribute. This parameter is referred to as AS_neighbor. 468 o An integer value number, which expresses the distance between 469 remote AS and local AS measured in the number of AS hops. The 470 name for this parameter is AS_hops. 472 Sending the full AS_PATH information is OPTIONAL, since some 473 operators may want to limit the proliferated information about the 474 way their traffic comes out of their domain. If some operators agree 475 to exchange the full AS_PATH, they MAY exchange it as a mandatory 476 parameter in the frame of ISP defined community (see Section 3.3). 478 3.3. ISP defined communities 480 A group of operators MAY decide to create a set of mandatory 481 parameters on their own. These ISPs define a community with a new 482 set of mandatory parameters. 484 An ISP defined community MUST inherit mandatory and optional 485 parameters from previously defined ALTO-ISP communities. They form 486 an inheritance tree. A root of a community tree is always the 487 GENERAL community, since belonging to the GENERAL community is 488 REQUIRED. A new community MUST have one and only one ancestor 489 community. 491 Each mandatory parameter of the ancestor community MUST be defined as 492 mandatory parameter of the derived community. Each optional 493 parameter of the ancestor community MAY be defined as mandatory or 494 parameter of the derived community or MAY be defined as optional one. 495 There is no limitation on the number and type of new mandatory and 496 optional parameters within ISP-defined communities. 498 Any operator, which is a member of a given ISP-defined community, 499 MUST be a member of the ancestor community. Consequently, it MUST be 500 a member of the GENERAL community. 502 3.4. Inter-ALTO server capability 504 An inter-ALTO server capability service MAY be provided by each ALTO 505 server. This service running on a particular ALTO server MUST 506 deliver the information on all communities supported by this server 507 and also MUST describe the communities supported, i.e., it MUST 508 provide names of the communities and the names of all the mandatory 509 and optional parameters defined for each of the communities, the 510 descriptions of all units used, and the relations between them. 512 This service MAY be used only by ALTO servers, the service MUST NOT 513 be accessible by third party. The proper security measures MUST be 514 undertaken in order to protect information storage and transfer. The 515 service MAY also be used for proliferation of newly defined 516 parameters in a particular ALTO server. Each ALTO server MAY limit 517 the accessibility of some information for some ALTO servers 518 (operators) through access lists. The detailed description of the 519 inter-ALTO server capability service is out of scope of this 520 document. 522 4. Protocol description 524 The local ALTO server can request parameters from a remote ALTO 525 server. Depending on the community some parameters MAY or MUST be 526 delivered by the remote ALTO servers. A remote ALTO server MUST 527 respond to a request. 529 Inter-ALTO servers MUST use TCP to establish connections. 531 This section defines types and formats of request and response 532 messages. 534 The Java Message Service [JMS] ObjectMessages are used to encode the 535 messages. 537 4.1. Definitions of elements of request/response messages 539 The main elements that appear in request/response messages are as 540 follows. 542 4.1.1. Community 544 Contains a name of a community. This element MUST be sent in any 545 type of message. It can contain letters, digits, and the colon. The 546 community name is case-insensitive: 548 community-name = 1*(ALPHA / DIGIT / ":") 550 4.1.2. Peer list 552 Contains individual or aggregated IP addresses of peers (e.g. 553 192.0.2.2/24). It is used either to: 555 o request parameters values for the peers on the peer list from a 556 remote ALTO server, or 558 o to indicate the peers the provided parameters values apply to. 560 individual-peer =
562 aggregated-peers =
564 peer-list = 1*( / ) 566 4.1.3. List of parameters 568 For each parameter its name, and update method MUST be provided both 569 in request and response messages. The names MUST contain only 570 letters and digits, and are case-insensitive. Additionally, if an 571 ALTO server sends a parameter value the meaning of this parameter 572 MUST be specified. The parameter can be used for sorting or can have 573 informational purpose. It takes values "descending" or "ascending" 574 which indicates whether lower or higher values of the parameters 575 should be preferred in case of sorting. The "info" value represents 576 informational purpose. 578 parameter-name = 1*(ALPHA / DIGIT) 580 parameter-meaning = / / 582 An update method MUST be established for all exchanged parameters 583 since most recent parameter values are necessary for proper peer 584 sorting/rating procedure. "Pull" or "push" update method may be 585 chosen. If "push" method is used a timer value MUST be specified. 587 parameter-update-method = / ( ) 589 4.1.4. Suggested parameter significance sequence 591 An ALTO server sending parameter values MAY suggest the other party 592 the sequence in which the parameters should be taken into account for 593 peer sorting/ranking procedure. In other words, this indicates the 594 sequence of the parameter importance from the point of view of ALTO 595 server sending the parameter values. For this purpose, the ALTO 596 server MAY send ordered list of parameter names. An ALTO server 597 receiving parameter values MAY use this sequence exactly as proposed, 598 partially, or MAY completely ignore it, and thus decide which 599 parameters take into account and in which order on its own. 601 significance-sequence = 1* 603 4.2. Requests 605 Two types of request are defined: 607 o an EXTENDED REQUEST and 609 o a BASIC REQUEST. 611 For each request a response MUST be sent. Both types of requests are 612 sent within a community. The selected community MUST be specified in 613 each type of request. 615 4.2.1. EXTENDED REQUEST 617 The EXTENDED REQUEST is used to ask a remote ALTO server for all 618 mandatory parameters defined within a frame of a community specified 619 in the request. Some optional parameters MAY be requested. It is 620 expected that the remote ALTO server will be interested in parameters 621 related to local peers, that is located at requesting party&s AS, and 622 would request them in the near future. To reduce the number of 623 exchanged messages, a local ALTO server places parameters values for 624 local peers in the EXTENDED REQUEST and sends them to remote ALTO 625 server although they are unsolicited. 627 There are two main parts of the EXTENDED REQUEST message: "local 628 parameters" and "remote parameters". 630 All parameters describing local peers are placed in the "local 631 parameters" section of the request. A local ALTO server MUST sent 632 values of all its mandatory parameters. Additionally a local ALTO 633 server MAY send values of optional parameters describing those local 634 peers. For all local parameters an update method MUST be 635 established. A local ALTO server MAY suggest a parameter 636 significance sequence by sending ordered list of local parameter 637 names. 639 The "remote parameters" part of the message is used to specify the 640 list of remote peers for which a local ALTO server request values of 641 mandatory parameters. Values of all mandatory parameters defined for 642 a given community MUST be requested in the EXTENDED REQUEST. 643 Additionally, a local ALTO server MAY request a remote ALTO server 644 for some optional parameters. The format of messages is organized in 645 such a way that parameters names together with attributes precede a 646 peer list which relates to them. Such groups MAY appear in a message 647 many times. 649 If a remote ALTO server agrees to respond to the EXTENDED REQUEST, it 650 MUST respond with all mandatory parameters defined for a specified 651 community. A remote ALTO server MAY refuse to respond in the frame 652 of a community specified in a request. 654 The format of an EXTENDED REQUEST message is defined as outlined 655 below: 657 extended-request = 658 660 local-parameters = 661 [] 662 [] 664 remote-parameters = 665 [] 667 mandatory-local-parameters = 1*(1* ) 669 optional-local-parameters = 1*(1* ) 671 mandatory-remote-parameters = 1*(1* ) 673 optional-remote-parameters = 1*(1* ) 675 local-parameter = 676 678 remote-parameter = 680 4.2.2. BASIC REQUEST 682 The BASIC REQUEST message MAY be used by the local ALTO server to 683 request for any subset of mandatory parameters defined for a 684 specified community as well as optional parameters. Any mandatory or 685 optional parameter MAY be requested. Specifically, the basic request 686 MAY be used for requesting a single parameter (mandatory or 687 optional). 689 In this request, the requesting party does not send parameters of 690 local peers. The message consists only of "remote parameters" part. 691 It contains the list of requested parameters, both mandatory and 692 optional ones, and the list of remote peers the parameters are 693 requested for. Similarly to the EXTENDED REQUEST, an update method 694 for requested parameters MUST be suggested by requesting party. The 695 negotiation of the update method is described in Section 3.1.3. 697 The format of a BASIC REQUEST is defined as outlined below: 699 basic-request = 700 702 4.2.3. Recommended usage of requests 704 A few types of applications may be distinguished: the ones which 705 perform uploading and downloading, and the other which only download. 706 For the simultaneously uploading and downloading applications the 707 EXTENDED REQUEST is RECOMMENDED. It is expected that the ALTO server 708 from the peer AS will request parameters, at least obligatory 709 parameters. In order to limit message transfer the local ALTO server 710 sends the values of all local obligatory parameters in advance in the 711 EXTENDED REQUEST. For downloading only applications, the BASIC 712 request is to be used. Note that applications which only upload 713 content may use only information available in the local AS and the 714 local ALTO server does not need to communicate with the remote ALTO 715 server. 717 The more advanced sorting/rating procedures may require information 718 from the remote AS for all types of applications. 720 4.3. Responses 722 A remote ALTO server SHOULD always send a response to the requests 723 received. 725 A remote ALTO server can receive requests for optional parameters. 726 It depends on the operator's policy possessing an ALTO server, which 727 optional parameters values MAY be sent in a response. If a 728 particular optional parameter is not supposed to be sent, a 729 responding ALTO server does not place the parameter in a response. 731 4.3.1. REFUSE RESPONSE 733 The REFUSE RESPONSE is sent when a responding ALTO server does not 734 want to communicate with the requesting ALTO server within the 735 indicated community. In other words, a responding ALTO server 736 informs the requesting party that in the frame of the community 737 specified there will be no communication between them. Operators 738 SHOULD regulate these actions through policies (e.g. access lists). 740 REFUSE RESPONSE message MUST NOT be sent if the request is within the 741 GENERAL community. 743 If an ALTO server requests some mandatory parameters, which are out 744 of the scope of the community specified in that request, it SHOULD be 745 treated as an attempt to swindle data. A responding party SHOULD 746 send the REFUSE RESPONSE message. 748 refuse-response = 750 4.3.2. ERROR RESPONSE 752 The ERROR RESPONSE message MAY be used when an unrecognized parameter 753 name has been received in a request. Having received a request with 754 wrong names, a responding ALTO server MAY optionally send a set of 755 unrecognized parameter names: 757 error-response = 758 760 wrong-parameter-names = 1* 762 If other errors appear they SHOULD be processed by lower level 763 protocols. 765 4.3.3. NORMAL RESPONSE 767 An ALTO server uses NORMAL RESPONSE message in order to respond to 768 both types of requests. NORMAL RESPONSE message is also used by ALTO 769 servers for generating parameter updates, both periodic and event- 770 based. When an ALTO server responds to EXTENDED REQUEST, it MUST 771 send values for all mandatory parameters defined for the community 772 specified in the request. 774 When an ALTO server responds to BASIC REQUEST it MUST sent values 775 only for those mandatory parameters which have been requested (all or 776 a subset of mandatory parameters defined for community specified in 777 the request). 779 If an ALTO server does not want to communicate with a requesting ALTO 780 server within the community specified in the request it MUST NOT send 781 any parameters and then MUST send RESPONSE REFUSE. 783 If optional parameters were requested (in either BASIC or EXTENDED 784 REQUEST) the responding ALTO server MAY sent their values in NORMAL 785 RESPONSE. Sending values of optional parameters is OPTIONAL. 787 An ALTO server sending NORMAL RESPONSE MAY also send additional, not 788 requested optional parameters for the peers specified in the request. 789 In this way, the responding ALTO server may suggest additional 790 parameters it wants to be used by requesting ALTO server for a 791 sorting/rating procedure. Together with a parameter name, its value 792 MUST be sent and the update method MUST be specified. 794 The ALTO server sending the NORMAL RESPONSE MAY suggest a parameter 795 significance sequence by sending ordered list of the parameter names. 797 The proposed format of NORMAL RESPONSE is defined as follows: 799 normal-response = 800 801 [] 802 [] 803 [] 805 non-requested-optional-local-parameters = 806 1*(1* ) 808 4.4. Message exchange patterns 810 This section presents three sample scenarios showing the idea of 811 inter-ALTO protocol and message exchange. In Figures 1, 2, and 3, 812 the local ALTO server communicates only one remote ALTO server. This 813 is done for readability. A local ALTO server SHOULD asynchronously 814 communicate as much remote ALTO servers as it is needed. 816 4.4.1. Successful communication within a given community 818 1. The local ALTO server receives a peer list from a local peer 819 (amongst the peers on this list there are the peers located in 820 the remote AS). 822 2. For each peer from the list, the local ALTO server searches in 823 the cache for parameters necessary for sorting/rating. If the 824 necessary parameters have been retrieved for a particular peer, 825 these parameters are assigned to that peer. If the necessary 826 parameters are absent in the cache, the local ALTO server 827 discovers the address of the remote ALTO server (the peer address 828 is the input parameter for discovery procedure). 830 3. The local ALTO server sends the request (BASIC or EXTENDED) to 831 the remote ALTO server, specifying a community and required 832 parameters. 834 4. The remote ALTO server sends the NORMAL RESPONSE to the local 835 ALTO server. The local ALTO server assigns parameters to the 836 peers according to the received response. The received 837 parameters SHOULD be cached. 839 5. After parameter assignment to all peers from the list, the peer 840 sorting/rating procedure is performed. 842 6. The sorted list is sent to the local peer. 844 +----+ ========== =========== 845 |peer| |local-ALTO| |remote-ALTO| 846 +----+ | server | | server | 847 | ========== =========== 848 | | | 849 | (1) List of peers | | 850 |------------------->| | 851 | |--- (2) Cache lookup | 852 | | | | 853 | |<-- | 854 | | | 855 | | (3)Request parameter values for peers | 856 | | (BASIC or EXTENDED request) | 857 | |-------------------------------------->| 858 | | | 859 | | (4) NORMAL RESPONSE | 860 | |<--------------------------------------| 861 | | | 862 | |--- (5) Perform peer | 863 | | | sorting/rating procedure | 864 | |<-- | 865 |(6)Sorted/rated list| | 866 |<-------------------| | 868 Figure 1: Successful message exchange. 870 4.4.2. Rejected communication within the given community 872 If a remote ALTO server rejects communication within the frame of a 873 specified community, the local ALTO server MAY lower community 874 requirements and send the request again. 876 1. The local ALTO server receives a peer list from a local peer 877 (amongst the peers on this list there are the peers located in 878 the remote AS). 880 2. For each peer from the list, the local ALTO server searches in 881 the cache for parameters necessary for sorting/rating. If the 882 necessary parameters have been retrieved for a particular peer, 883 these parameters are assigned to that peer. If the necessary 884 parameters are absent in the cache, the local ALTO server 885 discovers the address of the remote ALTO server (the peer address 886 is the input parameter for discovery procedure). 888 3. The local ALTO server sends the request (BASIC or EXTENDED) to 889 the remote ALTO server, specifying a community and required 890 parameters. 892 4. The remote ALTO server sends the REJECT RESPONSE to the local 893 ALTO server. 895 5. The local ALTO server sends the request (BASIC or EXTENDED) to 896 the remote ALTO server, specifying a community with smaller set 897 of mandatory parameters. 899 6. The remote ALTO server sends the NORMAL RESPONSE to the local 900 ALTO server. The local ALTO server assigns parameters to the 901 peers according to the received response. The received 902 parameters are cached. 904 7. After parameter assignment to all peers from the list, the peer 905 sorting/rating procedure is performed. 907 8. The sorted list is sent to the local peer. 909 Steps 4 and 5 MAY be repeated as many times as it is needed. 911 +----+ ========== =========== 912 |peer| |local ALTO| |remote ALTO| 913 +----+ | server | | server | 914 | ========== =========== 915 | | | 916 | (1)List of peers | | 917 |------------------->| | 918 | |--- (2) Cache lookup | 919 | | | | 920 | |<-- | 921 | | | 922 | | (3)Request parameter values for peers | 923 | | (BASIC or EXTENDED request) | 924 | |--------------------------------------->| 925 | -->| | 926 | | | (4) REJECT RESPONSE | 927 | | |<---------------------------------------| 928 | | | | 929 | | | (5)Request parameter values for peers | 930 | | | (BASIC or EXTENDED request) | 931 | | | with lower community requirements | 932 | | |--------------------------------------->| 933 | | | | 934 | ---+ (6) NORMAL RESPONSE | 935 | |<---------------------------------------| 936 | | | 937 | |--- (7) Perform peer | 938 | | | sorting/rating procedure | 939 | |<-- | 940 |(8)Sorted/rated list| | 941 |<-------------------| | 943 Figure 2: Message exchange in the case of rejected communication 944 within the given community. 946 4.4.3. Handling wrong parameter names in the request 948 1. The local ALTO server receives a peer list from a local peer 949 (amongst the peers on this list there are the peers located in 950 the remote AS). 952 2. For each peer from the list, the local ALTO server searches in 953 the cache for parameters necessary for sorting/rating. If the 954 necessary parameters have been retrieved for a particular peer, 955 these parameters are assigned to that peer. If the necessary 956 parameters are absent in the cache, the local ALTO server 957 discovers the address of the remote ALTO server (the peer address 958 is the input parameter for discovery procedure). 960 3. The local ALTO server sends the request (BASIC or EXTENDED) to 961 the remote ALTO server, specifying a community and required 962 parameters. 964 4. The remote ALTO server discovers wrong parameter names, it sends 965 the ERROR RESPONSE to the local ALTO server. The erroneous 966 parameters are specified in the response. 968 5. The local ALTO server performs sorting/rating with incomplete 969 knowledge. 971 6. The sorted list is sent to the local peer. 973 +----+ ========== =========== 974 |peer| |local ALTO| |remote ALTO| 975 +----+ | server | | server | 976 | ========== =========== 977 | | | 978 | (1)List of peers | | 979 |------------------->| | 980 | |--- (2) Cache lookup | 981 | | | | 982 | |<-- | 983 | | | 984 | | (3)Request parameter values for peers | 985 | | (BASIC or EXTENDED request) | 986 | |--------------------------------------->| 987 | | | 988 | | (4) ERROR RESPONSE | 989 | |<---------------------------------------| 990 | | | 991 | |--- (5) Perform peer | 992 | | | sorting/rating procedure | 993 | |<-- with incomplete knowledge | 994 |(6)Sorted/rated list| | 995 |<-------------------| | 997 Figure 3: Message exchange in the case of sending wrong parameter 998 names. 1000 5. Inter-ALTO server discovery 1002 The local ALTO server needs to know the IP address of the remote ALTO 1003 server in order to contact with this remote server. A service which 1004 enables an ALTO server discovery has to be proposed. 1006 The main assumptions for this service are described below. 1008 The local ALTO server receives peer list from a peer. This list 1009 contains IP addresses of peers. For some remote peers the IP address 1010 of remote ALTO server may be unknown. The local ALTO server, using 1011 peer IP addresses, has to able to establish the addresses of the 1012 remote ALTO servers. 1014 In order to determine IP address of a remote ALTO server quickly and 1015 to limit the network load, a database of IP addresses of all ALTO 1016 servers should be stored locally in each ALTO server. All database 1017 search are performed locally unless the remote ALTO server for a 1018 given peer is unknown. The database stores network prefixes 1019 announced by BGP together with the IP address of an ALTO server 1020 serving these prefixes. The database may also contain information 1021 about the AS number and served communities to which a particular ALTO 1022 server belongs. 1024 Two approaches to the remote ALTO server discovery are proposed: 1025 centralized and distributed. 1027 The centralized approach assumes the existence of so called info-ALTO 1028 servers that are supposed to be managed by a trusted organization, 1029 which ensures a proper level of security and confidentiality. The 1030 organization managing info-ALTO servers is responsible for 1031 registering ALTO servers and for the verification of ISPs that want 1032 to join a selected ALTO-ISP community. Info-ALTO servers store 1033 necessary information for ALTO servers' localization and 1034 communication. They can be found by DNS. 1036 In a decentralized approach it is assumed that ALTO servers will 1037 establish adjacency with some other ALTO servers and will exchange 1038 databases containing IP addresses of ALTO servers with them. A new 1039 ALTO server, which requires to exchange information with other ALTO 1040 servers, MUST communicate with any ALTO server, which is using this 1041 service. It must establish adjacency with at least one existing ALTO 1042 server in this context (this server is called old ALTO server). Each 1043 old ALTO servers stores a database of addresses of all other old ALTO 1044 servers. The new ALTO server and the old ALTO server perform an 1045 authorization and an authentication procedure. In the next step the 1046 new ALTO server downloads the database from the old ALTO server. 1048 In case of a database change, the old ALTO server is responsible for 1049 delivering updates to the new ALTO server. In an update, only 1050 changes in the database MUST be delivered, and not the entire updated 1051 database. 1053 Detailed specification of inter-ALTO server discovery procedures is 1054 out of the scope of this document. It is left for a separate draft. 1056 6. Reliability considerations 1058 Reliability, that is fault-tolerance to failures, is a basic feature 1059 that SHOULD be provided to the inter-ALTO protocol. Lack of 1060 functionality in the case of inter-ALTO protocol may lead to two 1061 important problems: losses related to suboptimal flow of traffic 1062 caused by the application layer routing and decrease of the 1063 credibility of the operator in the inter-AS environment. 1065 A successful operation of inter-ALTO protocol involves the proper 1066 work of a local ALTO server that decides that a new inter-ALTO query 1067 is necessary to be sent to a remote ALTO server with the usage of 1068 global Internet. To find this remote ALTO server a usage of inter- 1069 ALTO server discovery might be necessary. Therefore, the reliability 1070 of the inter-ALTO protocol is dependent on four factors: reliability 1071 of a local ALTO server, reliability of a remote ALTO server, 1072 reliability of underlying IP networks, and reliability of the inter- 1073 ALTO server discovery. They are described below in following 1074 sections. 1076 The reliability of the whole protocol operation is dependent serially 1077 on the four enumerated factors, that means a failure of at least one 1078 of them makes the whole operation of the inter-ALTO protocol for a 1079 pair of ALTO servers in different ASes impossible. Thus, having the 1080 assessment of the reliability metrics, for instance in terms of the 1081 steady-state availability, of all four components, it is possible to 1082 assess the resulting reliability (e.g. as the product of the 1083 availabilities). 1085 The reliability assessment is necessary to find the weak points of 1086 the system and to predict the output reliability metric to decide if 1087 it meets the operator's requirements. As a result, it is possible to 1088 improve the fault-tolerance of the components due to which the 1089 reliability is below expectations. 1091 6.1. Reliability of a local ALTO server 1093 Reliability of a local ALTO server is determined by elements which 1094 this server is built of. As it is a typical networking computing 1095 system, it depends on two kinds of building blocks, that is: software 1096 and hardware. Both serving the storage, computational logic and 1097 networking part. 1099 From all reliability features impacting the operation of the inter- 1100 ALTO protocol, the ones related to a local ALTO server are most 1101 controllable by an operator. Therefore, an operator SHOULD take care 1102 of this component most and maximize the related reliability metrics 1103 for it. There are three main options for protecting the local ALTO 1104 against negative impact of failures: 1106 o introduction of fast restarting procedures to enable effective 1107 software reaction to errors that otherwise might cause breakdown 1108 of the local ALTO server operation; 1110 o introduction of redundant hardware elements (with supporting 1111 software) to provide backup(s) in case the basic elements fail; 1113 o partitioning of operation of different functionalities of the 1114 system to provide partial operation when some elements fail. 1116 Both latter options are described below. 1118 6.1.1. Redundancy of elements 1120 Redundancy, that is introduction of additional elements that will 1121 replace the faulty elements, is a basic option for improving 1122 reliability of local ALTO server. It is possible to introduce 1123 redundancy at the level of a single server (e.g. by adding internally 1124 additional CPUs, storage or memory facilities etc.) or append the 1125 system with a complete alternative server. Three options for cold, 1126 warm and hot backup are available. Except for having a basic fault- 1127 tolerance consisting in subsistence of the functionality, it is 1128 necessary to have a system that makes the working server and its 1129 backup consistent. Thus, warm or hot backup is advised in order to 1130 update the storage and memory contents online. Then, it is possible 1131 that after a failure, the backup server does not start to work with 1132 empty caching information and there is not temporary performance 1133 degradation (caused by necessity to find inter-AS data for previously 1134 known prefixes) nor necessity to use the inter-ALTO service discovery 1135 in relation to previously known remote ALTO servers. 1137 The fact that the local ALTO server uses backup should be masked from 1138 the viewpoint of the remote ALTO server in order not to make the 1139 protocol operation too complex, e.g. to omit necessity for dealing 1140 with changed IP addresses. Also the recovery time should be 1141 diminished as much as possible in order to avoid the switching to be 1142 noticed. 1144 6.1.2. Partitioning of functionalities 1146 Partitioning of functionalities of an local ALTO server is an option 1147 not dependent on redundancy and can be combined with. It consists in 1148 using separate entities (obtained by virtualization of a software/ 1149 hardware system or by implementation of additional facilities) for 1150 serving group of functions that can be logically separated in order 1151 to decrease the impact of failures on the whole operation. The 1152 following options are useful: 1154 o partitioning of functionalities supporting (1) transfer of 1155 information from/to local peers, and, (2) communications with 1156 remote ALTO servers: due to this option it is possible to sustain 1157 the inter-ALTO operation even in the situation when the operator 1158 cannot provide the ALTO functionality in its AS (e.g. due to 1159 denial of service attack initiated in its domain); 1161 o partitioning of functionalities supporting different communities. 1163 As an additional option it is possible to consider the situation when 1164 element supporting a separate functionality is a backup for element 1165 supporting another functionality. 1167 6.2. Reliability of a remote ALTO server 1169 The reliability of a remote ALTO server is independent of the local 1170 operator. However, the operation of the local ALTO service is 1171 dependent on the reliability of remote ALTO servers as they are used 1172 to gain information interesting for sorting/rating. An operator can 1173 assess the reliability of remote ALTO server as similar to the one 1174 provided to its local ALTO server as those components serve analogous 1175 functions. From the viewpoint of the system operation it is 1176 necessary that the remote AS provides fault-tolerance to its remote 1177 ALTO server in a way that the failures are not visible to the local 1178 ALTO server. 1180 6.3. Reliability of underlying IP networks 1182 The reliability of underlying IP networks is the component to some 1183 extent independent of two communicating parties. The communication 1184 chain typically passes the local AS, different ASes in the Internet 1185 independent of the communicating parties, and the remote AS. To 1186 improve the fault tolerance of the networking communications the 1187 connections used for supporting transfer of inter-ALTO messages 1188 SHOULD use recovery techniques adequate for providing fault-tolerance 1189 to connections against network failures (e.g. 1:1 or 1+1 protections 1190 or re-routing procedures). Additionally, the inter-ALTO messages 1191 MUST be supported by an underlying protocol providing retransmission 1192 of lost data and information protection at the coding level (e.g. by 1193 FEC). 1195 6.4. Reliability of the inter-ALTO server discovery 1197 The reliability of an inter-ALTO server discovery is independent of 1198 the local operator. However, the operation of the local ALTO service 1199 is dependent on the reliability of inter-ALTO server discovery as it 1200 is used to find out addresses of remote ALTO servers of ASes not 1201 contacted before. Contrary to the three other components described 1202 above, there are cases when the reliability of this component does 1203 not influence the overall operation. Hence a negative impact on the 1204 whole inter-ALTO protocol operation in a single AS is not very 1205 strong. The exception is related to the situations when the 1206 discovery functionality is down when the local ALTO server has empty 1207 caches and needs to intensively use the inter-ALTO server discover 1208 functionality. 1210 When the centralized approach to inter-ALTO server discovery is 1211 adopted, it is maintained by a specialized institution and the 1212 reliability of this component will be high. In the case of the 1213 decentralized approach the unavailability of the service means that 1214 many remote ALTO servers are down and the operation of the whole 1215 inter-ALTO protocol is jeopardized. 1217 From the viewpoint of the system operation it is necessary that the 1218 discovery functionality is fault-tolerant in a way that the failures 1219 of it are not visible to local ALTO servers. 1221 7. Scalability considerations 1223 Scalability is a significant requirement of inter-ALTO protocol. The 1224 main threat related to it concerns two situations: 1226 o too large number of queries to be effectively served generated by 1227 local peers resulting in necessity for a burdening communications 1228 with remote ALTO protocols, 1230 o too large number of queries to be effectively served due to a 1231 significant load related to necessity to reply to many 1232 simultaneous requests from remote ALTO servers. 1234 While the former problem is easier to solve, as the local ALTO server 1235 can simply temporarily cease to response to local peers or queue them 1236 (and increases delays in serving the sorting/rating requests), the 1237 latter situation is more challenging, as the response to inter-ALTO 1238 messages is mandatory. Then, the response in a relatively short time 1239 is necessary. In case of breaking this rule, the local ALTO server 1240 is erroneously perceived as either faulty or not conforming to the 1241 recommendations of this draft. 1243 8. IANA Considerations 1245 The IANA has registered "inter-alto" as TCP port number TDB1. 1247 9. Security Considerations 1249 ALTO server possesses information about the network topology and it 1250 MAY share this information with other servers through the inter-ALTO 1251 communication. Potential intruders can make an attempt to eavesdrop 1252 transmission in order to gain confidential information, i.e., by 1253 spoofing an ALTO server. One of the most dangerous attack could be 1254 the data modification during transmission between ALTO servers. This 1255 type of interference can result in wrong management of the network. 1257 During the considerations about security of inter-ALTO protocol the 1258 crucial issue is proper balance between security and performance. 1259 Too many protection mechanisms implemented in the protocol can 1260 degrade efficiency. Nevertheless, the inter-ALTO protocol SHOULD 1261 provide basic security services at least. Below, some crucial 1262 security services and general solutions was presented. 1264 9.1. Authorization 1266 Authorization (access control) service is based on desired behaviors 1267 of ALTO servers. Each entity SHOULD belong to some group of 1268 privileges and have specific roles and permissions. First of all, 1269 the membership of the communities influences ALTO server permissions. 1270 An attempt of unauthorized access to resources should cause the 1271 RESPONSE REFUSE message. 1273 9.2. Authentication 1275 Authentication service SHOULD be applied by ALTO server, because 1276 other server must be sure that are connecting to proper entity. One 1277 of the best way to achieve this aim is certificate provided by 1278 server. By means of certificate, which can be validating by trusted 1279 entity, the ALTO server is able to confirm the identity. 1281 9.3. Data confidentiality 1283 Data encryption ensures secure transfer of sensitive information. If 1284 server has his own certificate, encryption can be realized by means 1285 of asymmetric ciphers. The main advantage of this solution is the 1286 usage of the public keys for the message encryption, which eliminates 1287 the problem of the secret key distribution or agreement. To ensure 1288 better performance, the messages could be encrypted by symmetric 1289 cipher but session keys could be encrypted by asymmetric ciphers. 1291 9.4. Data integrity 1293 Data integrity assures that during communication between ALTO 1294 servers, data must not change imperceptibly. This requirement is met 1295 by means of one-way hash functions. Content of the messages SHOULD 1296 be protected by data integrity assurance to avoid any modifications. 1298 9.5. Availability 1300 The availability is assured by good quality of system design and 1301 implementation process as well as redundancy of system resources. 1302 Such attacks as Denial of Service (DoS) or Distributed DoS (DDoS) 1303 attacks can be performed to prevent or inhibit normal use of ALTO 1304 server. These attacks are performed by flooding the server with 1305 unwanted traffic, i.e. false inter-ALTO requests. To ensure the 1306 protection of ALTO server, it MAY be secured by external devices, 1307 such as Intrusion Detection/Prevention Systems (IDS/IPS). 1309 10. Contributors 1311 The people listed here should be viewed as co-authors of the 1312 document. Due to the limit of 5 authors per draft the co-authors 1313 were moved to the contributors section at this point. 1315 o Marcin Niemiec (AGH University of Science and Technology) 1317 o Miroslaw Kantor (AGH University of Science and Technology) 1319 11. Acknowledgements 1321 This work has been partially supported by the EU through the ICT FP7 1322 Project SmoothIT (FP7-2007-ICT-216259). 1324 The authors would like to thank Fabio Hecht from University of Zurich 1325 for his helpful comments. 1327 12. References 1329 12.1. Normative References 1331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1332 Requirement Levels", BCP 14, RFC 2119, March 1997. 1334 12.2. Informative References 1336 [Dulinski_ICC2010] 1337 Dulinski, Z., Kantor, M., Krzysztofek, W., Stankiewicz, 1338 R., and P. Cholda, "Optimal Choice of Peers based on BGP 1339 Information", Proceedings of 2010 IEEE International 1340 Conference on Communications (ICC), May 2010. 1342 [I-D.ietf-alto-protocol] 1343 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1344 draft-ietf-alto-protocol-04 (work in progress), May 2010. 1346 [JMS] "Java Message Service (JMS)", 1347 . 1349 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1350 Optimization (ALTO) Problem Statement", RFC 5693, 1351 October 2009. 1353 Authors' Addresses 1355 Zbigniew Dulinski 1356 Jagiellonian University 1357 Reymonta 4 1358 Krakow 30-059 1359 Poland 1361 Phone: +48 12 663 5571 1362 Fax: +48 12 633 4079 1363 Email: dulinski@th.if.uj.edu.pl 1365 Rafal Stankiewicz 1366 AGH University of Science and Technology 1367 al. Mickiewicza 30 1368 Krakow 30-059 1369 Poland 1371 Phone: +48 12 617 4036 1372 Fax: +48 12 634 2372 1373 Email: rstankie@agh.edu.pl 1375 Piotr Cholda 1376 AGH University of Science and Technology 1377 al. Mickiewicza 30 1378 Krakow 30-059 1379 Poland 1381 Phone: +48 12 617 4036 1382 Fax: +48 12 634 2372 1383 Email: piotr.cholda@agh.edu.pl 1385 Piotr Wydrych 1386 AGH University of Science and Technology 1387 al. Mickiewicza 30 1388 Krakow 30-059 1389 Poland 1391 Phone: +48 12 617 3805 1392 Fax: +48 12 634 2372 1393 Email: piotr.wydrych@agh.edu.pl 1394 Burkhard Stiller 1395 University of Zurich 1396 Binzmuhlestrasse 14 1397 Zurich CH-8050 1398 Switzerland 1400 Phone: +41 44 635 67 10 1401 Fax: +41 44 635 68 09 1402 Email: stiller@ifi.uzh.ch