idnits 2.17.1
draft-kiesel-alto-h12-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
== There are 9 instances of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 26 instances of lines with non-RFC6890-compliant IPv4
addresses in the document. If these are example addresses, they should
be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 8, 2010) is 5163 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: 'RFC2119' is defined on line 475, but no explicit
reference was found in the text
Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ALTO S. Kiesel
3 Internet-Draft University of Stuttgart
4 Intended status: Standards Track M. Stiemerling
5 Expires: September 9, 2010 NEC Europe Ltd.
6 March 8, 2010
8 ALTO H12
9 draft-kiesel-alto-h12-02
11 Abstract
13 Many Internet applications are used to access resources, such as
14 pieces of information or server processes, which are available in
15 several equivalent replicas on different hosts. This includes, but
16 is not limited to, peer-to-peer file sharing applications. The goal
17 of Application-Layer Traffic Optimization (ALTO) is to provide
18 guidance to applications, which have to select one or several hosts
19 from a set of candidates, that are able to provide a desired
20 resource. This memo proposes the Simple ALTO (H12) protocol.
22 Status of this Memo
24 This Internet-Draft is submitted to IETF in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as Internet-
30 Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt.
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 This Internet-Draft will expire on September 9, 2010.
45 Copyright Notice
47 Copyright (c) 2010 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 4
64 3. H12 Operational Model . . . . . . . . . . . . . . . . . . . . 6
65 4. Proposed Protocol Semantics . . . . . . . . . . . . . . . . . 8
66 4.1. Locating the H12 Server Capabilities . . . . . . . . . . . 8
67 4.2. Learning the H12 Server Capabilities . . . . . . . . . . . 8
68 4.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 9
69 4.4. Querying the ALTO Server . . . . . . . . . . . . . . . . . 9
70 4.5. ALTO Server Response . . . . . . . . . . . . . . . . . . . 12
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
75 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
76 Appendix 1. Full XML-Response . . . . . . . . . . . . . . . . . . 17
77 Appendix 2. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
80 1. Introduction
82 Many Internet applications are used to access resources, such as
83 pieces of information or server processes, which are available in
84 several equivalent replicas on different hosts. This includes, but
85 is not limited to, peer-to-peer file sharing applications. The goal
86 of Application-Layer Traffic Optimization (ALTO) is to provide
87 guidance to applications, which have to select one or several hosts
88 from a set of candidates, that are able to provide a desired
89 resource. This memo proposes the Simple ALTO (H12) protocol. The
90 H12 protocol is a client/server protocol between ALTO clients and
91 ALTO servers, where ALTO clients can be either peer-to-peer
92 applications residing on end hosts or peer-to-peer tracker servers.
94 The basic ideas of ALTO are described in the problem space of ALTO is
95 described in [RFC5693] and the set of requirements is discussed in
96 [I-D.kiesel-alto-reqs].
98 Comments and discussions about this protocol proposal should be
99 directed to the ALTO working group: alto@ietf.org.
101 2. Protocol Framework
103 The ALTO protocol is a client/server protocol, operating between a
104 number of ALTO clients and an ALTO server, as sketched in Figure 1
106 +----------+
107 | ALTO |
108 | Server |
109 +----------+
110 ^
111 _.-----|------.
112 ,-'' | `--.
113 ,' | `.
114 ( Network | )
115 `. | ,'
116 `--. | _.-'
117 `------|-----''
118 v
119 +----------+ +----------+ +----------+
120 | ALTO | | ALTO |...| ALTO |
121 | Client | | Client | | Client |
122 +----------+ +----------+ +----------+
124 Figure 1: Network Overview of ALTO Protocol
126 An ALTO server stores information about preferences (e.g., a list of
127 preferred autonomous systems, IP ranges, etc) and ALTO clients can
128 retrieve these preferences. However, there are basically two
129 different approaches on where the preferences are actually processed:
131 1. The ALTO server has a list of preferences and clients can
132 retrieve this list via the ALTO protocol. This preference list
133 can be partially updated by the server. The actual processing of
134 the data is done on the client and thus there is no data of the
135 client's operation revealed to the ALTO server . This approach
136 has been proposed by [I-D.shalunov-alto-infoexport].
138 2. The ALTO server has a list of preferences or preferences
139 calculated during runtime and the ALTO client is sending
140 information of its operation (e.g., a list of IP addresses) to
141 the server. The server is using this operational information to
142 determine its preferences and returns these preferences (e.g., a
143 sorted list of the IP addresses) back to the ALTO client. This
144 approach has been initially described in [ACM.ispp2p], but never
145 been described on the protocol level.
147 Approach 1 (we call it H1) has the advantage (seen from the client)
148 that all operational information stays within the client and is not
149 revealed to the provider of the server. On the other hand, does
150 approach 1 require that the provider of the ALTO server, i.e., the
151 network operator, reveals information about its network structure
152 (e.g., AS numbers, IP ranges, topology information in general) to the
153 ALTO client.
155 Approach 2 (we call it H2) has the advantage (seen from the operator)
156 that all operational information stays with the ALTO server and is
157 not revealed to the ALTO client. On the other hand, does approach 2
158 require that the clients send their operational information to the
159 server.
161 Both approaches have their pros and cons and are extensively
162 discussed on the ALTO mailing list. But there is basically a
163 dilemma: Approach 1 is seen as the only working solution by peer-to-
164 peer software vendors and approach 2 is seen as the only working by
165 the network operators. But neither the software vendors nor the
166 operators seem to willing to change their position. However, there
167 is the need to get both sides on board, to come to a solution.
169 Therefore, this does memo proposes to integrate both approaches in
170 one protocol and offer a way for clients and servers to learn each
171 preferred way of operating.
173 3. H12 Operational Model
175 The P4P protocol proposal [I-D.penno-alto-protocol] assumes that the
176 ALTO server maintains two different databases that store the server-
177 side information necessary to guide ALTO clients. There is the
178 network map that provides a mapping between network prefixes and a
179 macro called partition ID (PID) and the cost map that relates PIDs to
180 costs.
182 H12 assumes also that the H12 server internally maintains two maps,
183 one for the network partitioning and the other for the associated
184 costs, but does not need that the information stored in these maps is
185 also conveyed to the H12 client in one piece. However, this memo is
186 not specifying how the server is implemented, it is only specifying
187 the ALTO protocol.
189 The client puts one or several host location attributes, about which
190 it wants to receive a rating, in the query message.
192 The server replies with a list of network location attributes, in the
193 same format as in the query, and the respective ratings for the
194 requested attributes. However, the number of lines in this list may
195 be shorter or longer than in the query, and the prefix lengths may be
196 different:
198 o The server may decide not to give any rating for a specific
199 location attribute. In this case, a default value applies.
201 o Instead of rating several location attributes with long prefix
202 lengths (in particular: individual IP addresses) individually, the
203 server may decide to give only one rating for a broader address
204 range (i.e., prefix length is shorter).
206 o Instead of giving one rating for a large address range, the server
207 may decide to give several ratings for smaller ranges (i.e., i.e.,
208 each returned entry has a prefix length that is longer that
209 requested).
211 The actual rating is given for each rating criterion as a signed
212 integer value. A value of zero (0) means "default value". This
213 value is to be used if the server has no information regarding this
214 (network location attribute, rating criteria) tuple, or if it does
215 not want to disclose it. Positive values mean that this location is
216 "better" than default and therefore should be preferred for peer
217 selection, while negative values indicate the location to be "worse"
218 than default and therefore that it should be avoided. The meaning of
219 "better" and "worse", as well as the scale has to be defined
220 individually for each rating criterion.
222 This approach gives both sides, i.e., server and clients, to still
223 exchange their desired information and level of precision, but also
224 gives the chance to hide information if necessary and desired.
226 4. Proposed Protocol Semantics
228 H12 uses HTTP/1.1 and TCP as transport protocol between H12 clients
229 and H12 servers. The encoding of the message body is done with XML.
230 The usage of HTTP is similar to [I-D.penno-alto-protocol] also with
231 the intention to reuse existing HTTP software and deployments.
233 H12 is aiming at keeping the level of involvement of the application
234 that is using ALTO as low as possible. I.e., requiring an
235 application, such as p2p file sharing, to use ALTO is already a
236 considerable step. The implementers of the application must be able
237 to use ALTO with a very low effort. It is assumed that the
238 complexity of ALTO, in terms of implementation and operational
239 effort, is mainly handled at the server.
241 Unlike the H1H2 protocol[I-D.stiemerling-alto-h1h2-protocol] the H12
242 protocol does not have several modes of operation, which have to be
243 negotiated at the startup. Instead it allows the client and the
244 server some flexibility in the requests and the responses while using
245 only on mode of operation.
247 4.1. Locating the H12 Server Capabilities
249 H12 clients initially need to locate the right H12 server that is in
250 charge of serving them. This step and the technical solution to
251 locate such ALTO server is currently discussed within the ALTO
252 working group. This memo does not yet define such H12 server
253 discovery.
255 4.2. Learning the H12 Server Capabilities
257 This section describes how an ALTO client can learn about the
258 capabilities of the ALTO server.
260 H12 clients initially need to locate the right H12 server that is in
261 charge of serving them. This step and the technical solution to
262 locate such ALTO server is currently discussed within the ALTO
263 working group. This memo does not yet define such H12 server
264 discovery.
266 The first step for a H12 client, before it can start querying for
267 ALTO guidance, is to request the H12 server capabilities. The server
268 capabilities are, e.g., administrative information (operator of the
269 server, contact addresses, etc), the supported host location
270 attributes (IP addresses or IP prefixes), the supported rating
271 criteria, and the URIs to query for ALTO guidance. The H12 protocol
272 uses only a single static URI path for retrieving the capability
273 information. All other query URIs are announced by the server during
274 the capability retrieval.
276 4.3. Redirection
278 There are basically two cases where a H12 server has to redirect
279 request to other locations:
281 a. the queried H12 server is overload and can tell about other H12
282 server;
284 b. the queried H12 server is overload and cannot tell about other
285 H12 server;
287 c. the queried H12 server is solely used as entry point and
288 redirects the actual H12 server;
290 d. the querying host in not allowed to use this ALTO server (e.g.,
291 host in ISP1 is querying ALTO server in ISP2) (which is a sub
292 case of (a)).
294 4.4. Querying the ALTO Server
296 An ALTO client can query on its own or on behalf of other peers
297 (e.g., a tracker). This is indicated in the resource consumer host
298 location attribute rc_hla in the ALTO query. The query body itself
299 contains the list of IP addresses or IP prefixes the ALTO client is
300 asking guidance for. This shows a example list Figure 2 of IP
301 addresses queried for
302 195.37.70.39/32 # mito.netlab.nec.de
303 193.141.139.237/32 # www.nec.de
304 58.89.210.171/32 # www.nec.co.jp
305 122.224.8.143/32 # www.huawei.cn
306 202.103.147.132/32 # www.zte.com.cn
307 135.245.1.29/32 # www.alcatel.de
308 139.15.248.12/32 # www.bosch.de
309 141.113.97.34/32 # www.daimler.de
310 129.206.0.0/16 # university of heidelberg
311 129.13.0.0/16 # university of karlsruhe
312 129.69.0.0/16 # university of stuttgart
313 130.83.0.0/16 # university of darmstadt
314 130.149.0.0/16 # university of berlin (TU)
315 171.67.0.0/16 # stanford university
316 129.78.64.24 # university of sidney
317 12.110.110.204/32 # www.nsa.gov
318 85.180.57.61/32 # some random residential DSL user (ALICE)
319 84.56.180.139/32 # some random residential DSL user (Arcor)
320 62.227.16.206/32 # some random residential DSL user (DTAG)
321 80.238.206.25/32 # some random residential DSL user in .ch
323 Figure 2: Example Candidate IPs for Query
325 The query is constructed as show in the below exampleFigure 3. The
326 client requests guidance for the IP prefixes out of Figure 2 for its
327 own IP address (prefix='195.37.70.39/32') stated in the rc_hla.
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
359 Figure 3: XML encoded Query
361 This ipprefix tag carries a full IP address or an IP address prefix,
362 leaving the client the choice how much of an IP address it wants to
363 reveal to the server. That is, the client can request information
364 for one or several specific IP addresses (prefix length equal 32 or
365 128), for address ranges, or for "the whole Internet" (prefix length
366 equal 0). However, the "whole Internet" is not really referring to
367 the whole Internet as such, as no single entity can have such a big
368 knowledge, but to whatever broader scope the server can give guidance
369 about. This scope can include, for instance, its own complete
370 network.
372 Furthermore, the client specifies one or several rating criteria,
373 such as operator preference, lower bound for delay, etc. Here is a
374 work-in-progress list of such rating criteria, consisting of two
375 levels of rating criteria offered to the client are:
377 o Primary rating criterion
379 o Further rating criteria
381 The offered rating criteria are:
383 o operator's relative preference
385 o Topological distance (Number of AS hops)
387 o minimum boundary for upload bandwidth
389 4.5. ALTO Server Response
391 This section discussions at this of point of time only a positive
392 reply. All other cases are TBD in this write-up. The listed
393 response is shortened, see Section 1 for the full answer. The
394 examplatory answer is listed for the IP address 193.141.139.237/32
395 and 202.103.147.132/32, and for the IP prefix 129.13.0.0/16.
397 The rating response given in the candidate host location attributes
398 (cnd_hla) is different for the single requests, depending on what
399 information can be delivered by the server. For 193.141.139.237/32,
400 the server replies with two prefixes belonging to the same ISP. For
401 202.103.147.132/32, the server replies with even more details about
402 other prefixes belonging to the same operator. The ensures that the
403 client automatically learns even more prefixes the operator gives the
404 same guidance for. A simple response is shown for the query about
405 129.13.0.0/16, where the response contains only the same prefixes as
406 in the request.
408
409
411
412
413
414
415
416
418
419
420
421
422
423
424
425
426
427
428
429
431
432
433
434
435
437
438
439
440
441
442
443
444
446 Figure 4: XML encoded Query
448 The response contains also a resource consumer host location
449 attribute (rc_hla). This rc_hla echos partially the information from
450 the request, but gives actually guidance to the ALTO client in what
451 scope this information can be distributed amongst other peers. In
452 this response, the server allows the redistribution of the received
453 guidance to peers with the IP prefix 195.37.0.0/16.
455 5. Security Considerations
457 This initial version of this memo does not yet a full security
458 considerations, but they will be added in future revision.
460 minimum boundary for upload bandwidth (AKA provisioned upload
461 bandwidth): criminal suspects can easily re-use the geographical
462 coordinates of an IP address (taken from whois) and google maps to
463 correlate IP addresses and wealth of subscribers of that IP address.
465 6. Conclusion
467 This memo presents a very basic protocol, for sure work in progress,
468 and is requesting feedback from the ALTO working group. Sebastian
469 Kiesel is implementing the herein proposed protocol.
471 7. References
473 7.1. Normative References
475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
476 Requirement Levels", BCP 14, RFC 2119, March 1997.
478 7.2. Informative References
480 [ACM.ispp2p]
481 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
482 and P2P systems co-operate for improved performance?", In
483 ACM SIGCOMM Computer Communications Review
484 (CCR), 37:3, pp. 29-40.
486 [I-D.kiesel-alto-reqs]
487 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
488 Yang, "Application-Layer Traffic Optimization (ALTO)
489 Requirements", draft-kiesel-alto-reqs-02 (work in
490 progress), March 2009.
492 [I-D.penno-alto-protocol]
493 Penno, R. and Y. Yang, "ALTO Protocol",
494 draft-penno-alto-protocol-04 (work in progress),
495 October 2009.
497 [I-D.shalunov-alto-infoexport]
498 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
499 Export Service", draft-shalunov-alto-infoexport-00 (work
500 in progress), October 2008.
502 [I-D.stiemerling-alto-h1h2-protocol]
503 Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol",
504 draft-stiemerling-alto-h1h2-protocol-00 (work in
505 progress), March 2009.
507 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
508 Optimization (ALTO) Problem Statement", RFC 5693,
509 October 2009.
511 1. Full XML-Response
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
655
656
657
658
659
660
661
662
663
665 Figure 5: XML encoded Query
667 2. Acknowledgments
669 Martin Stiemerling is partially supported by the NAPA-WINE project
670 (Network-Aware P2P-TV Application over Wise Networks,
671 http://www.napa-wine.org), a research project supported by the
672 European Commission under its 7th Framework Program (contract no.
673 214412). The views and conclusions contained herein are those of the
674 authors and should not be interpreted as necessarily representing the
675 official policies or endorsements, either expressed or implied, of
676 the NAPA-WINE project or the European Commission.
678 Authors' Addresses
680 Sebastian Kiesel
681 University of Stuttgart, Computing Center
682 Allmandring 30
683 Stuttgart 70550
684 Germany
686 Email: ietf-alto@skiesel.de
688 Martin Stiemerling
689 NEC Laboratories Europe/University of Goettingen
690 Kurfuerstenanlage 36
691 Heidelberg 69115
692 Germany
694 Phone: +49 6221 4342 113
695 Fax: +49 6221 4342 155
696 Email: stiemerling@cs.uni-goettingen.de