One document matched: draft-penno-alto-protocol-01.txt
Differences from draft-penno-alto-protocol-00.txt
ALTO WG R. Penno, Ed.
Internet-Draft Juniper Networks
Intended status: Standards Track Y. Yang, Ed.
Expires: September 10, 2009 Yale University
March 09, 2009
ALTO Protocol
draft-penno-alto-protocol-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The ALTO Service enables an Internet Service Provider (ISP) to convey
cost preferences to network applications in order to modify network
Penno & Yang Expires September 5, 2009 [Page 1]
Internet-Draft ALTO Protocol March 2009
resource consumption patterns while maintaining or improving
application performance. Applications that could use this service
are those that have a choice in connection endpoints. Examples of
such applications are peer-to-peer (P2P) and content delivery
networks.
Applications already have access to great amount of underlying
topology information. For example, views of the Internet routing
table are easily available at looking glass servers and entirely
practical to download to every client. What is missing is the cost
information -- what does an ISP or Content Provider actually prefer?
This document describes a very simple protocol that allows a ISP to
convey such information to applications. While such service would
primarily be provided by the network (i.e., the local ISP). Content
Provider and third parties could also operate this service.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Penno & Yang Expires September 5, 2009 [Page 2]
Internet-Draft ALTO Protocol March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
2. ALTO Network Information . . . . . . . . . . . . . . . . . . . 8
2.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Example Scenario . . . . . . . . . . . . . . . . . . . . . 9
3.2. Design Approach . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Key Features . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Use of HTTP . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. ALTO Information Reuse . . . . . . . . . . . . . . . . 10
3.2.4. ALTO Interfaces . . . . . . . . . . . . . . . . . . . 10
4. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Protocol Version (v=) . . . . . . . . . . . . . . . . 12
4.1.2. Transaction Identifier (t=) . . . . . . . . . . . . . 12
4.1.3. Query Type (q=) . . . . . . . . . . . . . . . . . . . 12
4.1.4. Response (r=) . . . . . . . . . . . . . . . . . . . . 13
4.1.5. Originator (o=) . . . . . . . . . . . . . . . . . . . 13
4.1.6. Cost (c=) . . . . . . . . . . . . . . . . . . . . . . 13
4.1.7. Network Locations (n=) . . . . . . . . . . . . . . . . 13
4.1.8. Network Map (m=) . . . . . . . . . . . . . . . . . . . 14
4.1.9. Interface Definition (i=) . . . . . . . . . . . . . . 14
4.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. getcost . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. getnetworkidentifier . . . . . . . . . . . . . . . . . 16
4.2.3. getnetworkmap . . . . . . . . . . . . . . . . . . . . 16
4.3. ALTO Server Message Processing . . . . . . . . . . . . . . 17
4.3.1. Exception Handling . . . . . . . . . . . . . . . . . . 17
4.3.2. Successful Responses . . . . . . . . . . . . . . . . . 17
4.3.3. Invalid Query Format . . . . . . . . . . . . . . . . . 18
4.3.4. Unsupported Query . . . . . . . . . . . . . . . . . . 18
5. ALTO Interfaces . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Interface Descriptor . . . . . . . . . . . . . . . . . . . 19
5.2. Cost Map Interfaces . . . . . . . . . . . . . . . . . . . 20
5.2.1. GetCost . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2. GetCost-Source . . . . . . . . . . . . . . . . . . . . 20
5.2.3. GetCost-Complete . . . . . . . . . . . . . . . . . . . 20
5.3. Network Map Interfaces . . . . . . . . . . . . . . . . . . 21
5.3.1. GetNetworkIdentifier . . . . . . . . . . . . . . . . . 21
5.3.2. GetNetworkMap . . . . . . . . . . . . . . . . . . . . 21
5.3.3. GetNetworkMap-Source . . . . . . . . . . . . . . . . . 22
5.3.4. GetNetworkMap-Complete . . . . . . . . . . . . . . . . 22
5.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22
Penno & Yang Expires September 5, 2009 [Page 3]
Internet-Draft ALTO Protocol March 2009
6. ALTO Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Type Attribute . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Mode Attribute . . . . . . . . . . . . . . . . . . . . . . 23
6.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Network Address Translation Considerations . . . . . . . . 24
7.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 25
7.4. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 25
7.4.1. Client-based Peer Selection . . . . . . . . . . . . . 26
7.4.2. Server-based Peer Selection . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Penno & Yang Expires September 5, 2009 [Page 4]
Internet-Draft ALTO Protocol March 2009
1. Introduction
Today, information available to applications is mostly from the view
of endhosts. Using this view, they currently employ a variety of
methods to improve performance. However, there is no clear mechanism
to convey information about the network's preferences to
applications. By better leveraging network-provided information,
applications can become more network-efficient and acheive better
performance. For example, peer-to-peer applications have been
successful in achieving a good level of service for bulk-transfer
applications. By also considering network preferences, downloads can
be accelerated and network resource consumption can be reduced. The
ALTO service intends to provide a simple way to convey ISP
preferences to applications.
This document describes a simple protocol that allows an ISP to
convey such information to applications. The protocol specified here
is a merge between two other designs, ALTO Info-Export [5] and P4P
[6] [7]. The goal is to provide a simple, unified protocol that
meets the ALTO requirements [8], provides a migration path for ISPs,
Content Providers, and clients that have deployed the above mentioned
protocols. This document is a work in progress and will be updated
with further developments.
1.1. Terminology
We use the following terms defined in [9]: Application, Overlay
Network, Peer, Resource, Resource Identifier, Resource Provider,
Resource Consumer, Resource Directory, Transport Address, Host
Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO
Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic,
Transit Traffic.
The terminology introduced in this document is listed below:
o Network Location Identifier (NL-ID): identifier indicating a
particular host or group of hosts. Currently-defined types of
Network Location Identifiers are IP Address, IP Prefix, Autonomous
System, PID, Geographical Location. Others may be defined.
o PID (Partition ID): identifier providing an indirect and network-
agnostic way to specify a group of NL-IDs. For example, a PID may
be defined (by a network operator) to denote a subnet, set of
subnets, autonomous system, PoP, or metropolitan area.
Aggregation into PIDs can improve scalablity. In particular,
network preferences (costs) may be specified between PIDs,
allowing cost information to be more compact and updated at a
smaller time scale than the network locations themselves.
Penno & Yang Expires September 5, 2009 [Page 5]
Internet-Draft ALTO Protocol March 2009
o Top-Level NL-ID: NL-ID that is either a PID, or a NL-ID not
contained within another PID. For example, if a PID 'pid1'
containing the NL-IDs '1.2.0.0/16' and 'AS29', then 'pid1' is a
Top-Level NL-ID, but '1.2.0.0/16' and 'AS29' are not.
o Cost: indicates the preference of a NL-ID from the point of view
of another NL-ID. Costs have attributes indicating their type
(e.g., routing cost, hop-count, air-miles), and mode (numerical or
ordinal interpretation).
o ALTO Message: Single message (either request or response) carried
between an ALTO Server and ALTO Client.
o ALTO Interface: Endpoint offered by an ALTO Server for accepting
ALTO Messages.
o Source Grouping: A group of ALTO Clients which can have similar
costs to other network locations. See [10] for further
discussion. This current document assumes that Source Groups ar
denoted as top-level PIDs.
1.2. Architecture
Each network region can choose to support the ALTO service. A
network region in this context is an Autonomous System, an ISP, or
perhaps a smaller region; the details depend on the discovery
mechanism.
An illustration of the overall system architecture is presented in
the following figure.
Penno & Yang Expires September 5, 2009 [Page 6]
Internet-Draft ALTO Protocol March 2009
+-------------------------------------------------------------------+
| ISP |
| |
| +---------+ |
| | Routing | |
| +--------------+ | Policy | |
| | Provisioning | +---------+ |
| | Policy | | |
| +--------------+\ | |
| \ | |
| \ | |
| +-----------+ \+---------+ +--------+ |
| |Dynamic | | ALTO | ALTO Query/Response | ALTO | |
| |Network |.......| Server | -------------------- | Client | |
| |Information| +---------+ +--------+ |
| +-----------+ / / |
| / ALTO SD Query/Response / |
| / / |
| +----------+ +--------------+ |
| | External | | ALTO Service | |
| | Interface| | Discovery | |
| +----------+ +--------------+ |
| | |
| | Figure 1: Basic ALTO Architecture. |
| | |
+-------------------------------------------------------------------+
|
+------------------+
| Third Parties |
| |
| Content Providers|
+------------------+
ALTO Architecture
The network information provided by an ALTO Server may be influenced
(at the operator's discretion) by other systems. Examples include
(but are not limited to) dynamic network information, routing
policies, provisioning policies, and interfaces to outside parties.
These components are outside the scope of this document.
After using ALTO Service Discovery to identify an appropriate ALTO
Server, an ALTO Client may then request available network information
from the ALTO Server. This document specifies a protocol through
which this network information is made available.
Penno & Yang Expires September 5, 2009 [Page 7]
Internet-Draft ALTO Protocol March 2009
2. ALTO Network Information
An ISP prepares the ALTO information constituting the ISP's "my-
Internet View" [10]. The ALTO information provided by the ALTO
Server can be updated dynamically based on network conditions, or can
be seen as a policy which is updated at a larger time-scale.
In a simple case, the ALTO information maps, for a particular Source
Group, a cost for IP prefixes and AS numbers as viewed from that
group.
ALTO information is comprised of two sets of information: the Network
Map and Cost Map. Separating ALTO information into a Network Map and
Cost Map as the two components can be updated at different time
scales. For example, Network Maps may be stable for a longer time
while Cost Maps may be updated to reflect dynamic network conditions.
Version Tags are introduced to ensure that ALTO Clients are able to
use consistent information even though the information is provided in
two sets.
2.1. Network Map
The Network Map defines a set of network locations (NL-IDs) within
the network. Network locations may also be logically grouped into
PIDs.
The GetNetworkMap and GetNetworkIdentifier interfaces allow ALTO
Clients to query the Network Map.
2.2. Cost Map
The Cost Map defines the network costs, or preferences, between
network locations. Note that the network costs may be dependent on
the specific network locations and groupings defined in the Network
Map. Thus, we say that a particular Cost Map is generated based on a
particular Network Map.
The GetCost interfaces allow ALTO Clients to query the Cost Map.
2.3. Version Tag
When an ALTO Client retrieves cost information in the ALTO Server's
current Cost Map, it must ensure that the cost information is
consistent with any locally-stored Network Map information. If the
ALTO Server had recently updated its Network Map (perhaps causing
changes in the Cost Map), the ALTO Client must be able to detect that
the new costs pertain to a Network Map different than the one
currently stored. The ALTO Client can then refresh the Network Map
Penno & Yang Expires September 5, 2009 [Page 8]
Internet-Draft ALTO Protocol March 2009
information from the ALTO Server.
Version Tags allow ALTO Clients to detect this case. The Network Map
maintained by the ALTO Server has an associated opaque identifier
called a Version Tag. When the Network Map is modified, its Version
Tag is changed. A simple way to implement the Version Tag is as an
integer that incremented (wrapping around to 0 as necessary) when the
Network Map changes.
When ALTO information (either generated from the Network Map or Cost
Map) is returned by the ALTO Server, the Version Tag is included in
the response message. Specifically, if the returned information is
from the Network Map, the Network Map's Version Tag is included. If
the returned information is from the Cost Map, the Version Tag of the
Network Map used to generate the Cost Map is included.
3. Protocol Overview
3.1. Example Scenario
The ALTO service may operate as follows:
1. The ISP prepares ALTO information as discussed in Section 2.
2. An application (ALTO Client), running on a given host, discovers
the ALTO Server and fetches the ALTO information (Section 4.2).
3. The application may integrate ALTO information into its decision
making process, possibly by making use of network locations with
lower cost. See Section 6 for further discussion on semantics of
network costs.
3.2. Design Approach
3.2.1. Key Features
The ALTO Protocol design borrows ideas from the Session Description
Protocol [2] with the goal of leveraging current HTTP [3] [4]
implementations and infrastructure. An ALTO information exchange is
carried within HTTP similarly to how SDP is carried within SIP. ALTO
messages are denoted with HTTP Content-Type "application/alto". The
ALTO Protocol described in this document has several features:
o Leverages the huge installed base of HTTP infrastructure,
including HTTP caches
Penno & Yang Expires September 5, 2009 [Page 9]
Internet-Draft ALTO Protocol March 2009
o Leverages mature software implementations for both HTTP and SDP
o Leverages the fact that many P2P clients already have an embedded
HTTP client
o Makes protocol easy to understand and debug
o Allows the protocol to evolve separately from HTTP; Leaves HTTP
free of proprietary headers ("X-")
o Allows the ALTO protocol to be carried by other protocols other
than HTTP in the future, such as SIP.
o Allows flexible ALTO Server implementation strategies.
The rest of this section elaborates on the key design considerations
use in the protocol.
3.2.2. Use of HTTP
An important design consideration for the ALTO Protocol is easy
integration with existing applications and infrastructure. As
outlined above, HTTP is a natural choice. The message formats
themselves, however, remain independent of HTTP to allow flexibility
and transition to other transport protocols.
3.2.3. ALTO Information Reuse
ALTO information may be useful to a large number of applications and
users. Distributing ALTO information must be efficient and not
become a bottleneck. Therefore, the ALTO Protocol specified in this
document integrates with existing HTTP caching infrastructure to
allow reuse of ALTO information by ALTO Clients and reduce load on
ALTO servers. ALTO information may also be cached using application-
dependent mechanisms, such as P2P DHTs.
For example, a Cost Map may be reused by all ALTO Clients within a
particular Source Grouping [10]. A full Network Map may be reused by
all ALTO Clients using the ALTO Server.
3.2.4. ALTO Interfaces
Three basic interfaces are provided by the ALTO Protocol, which allow
ALTO Clients to request specific information: GetNetworkIdentifier,
GetNetworkMap, and GetCost. An ALTO Server additionally defines
instances of the GetNetworkMap and GetCost interfaces that provide
the full Network Map and Cost Map, or only the subset pertaining to
the Source Grouping containing the ALTO Client.
Penno & Yang Expires September 5, 2009 [Page 10]
Internet-Draft ALTO Protocol March 2009
Each ISP may have different infrastructure and services which produce
and update the ALTO information, and may provide ALTO information
using any number of implementation strategies. The ALTO Protocol
specified in this document uses a single endpoint URI (e.g.,
discovered via ALTO Service Discovery), and offers ALTO interfaces
using URI endpoints advertised by the ALTO Server. Using distinct
URIs for each ALTO Interface provides the following benefits:
o Flexible implementation strategies for ALTO Server (e.g., flat
files, database-backed CGI script, dedicated server, etc)
o Allows ALTO information to be provided using existing, mature
software (e.g., web servers)
o Integration with HTTP Caching while reducing dependence of
messaging format on HTTP.
Further details are provided in Section 5.
ALTO Interfaces and their URIs are provided to an ALTO Client via an
Interface Descriptor. A Interface Descriptor is expected to be
stable for a long period of time, so an ALTO Client may cache it
locally and possibly share amongst many ALTO clients running on the
same physical machine.
4. ALTO Messages
4.1. Basic Syntax
This section describes the basic components of an ALTO Protocol
message. The ALTO Protocol borrows its message encoding syntax from
SDP [2], but necessary definitions are included here.
An ALTO Information description consists of a number of lines of text
of the form: <type>=<value> where <type> MUST be exactly one case-
significant character and <value> is structured text whose format
depends on <type>. In general, <value> is either a number of fields
delimited by a single space character or a free format string, and is
case-significant unless a specific field defines otherwise.
Whitespace MUST NOT be used on either side of the "=" sign.
Some lines in each description are REQUIRED and some are OPTIONAL,
but all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*".
ALTO Messages use lowercase names to distinguish them from the names
Penno & Yang Expires September 5, 2009 [Page 11]
Internet-Draft ALTO Protocol March 2009
of their corresponding ALTO Interfaces.
The textual encoding of a particular NL-ID indicates its type (IP
prefix, AS number, PID, etc).
ALTO Protocol messages use the following types:
v=(Protocol Version)
t=(Transaction Identifier)
q=(Query)
r=(Response)
o=(Originator)
c=(Cost)
n=(Network Location)
m=(Network Map)
i=(Interface Description)
4.1.1. Protocol Version (v=)
v=1
The line defines the protocol version. The version specified in this
document is 1.
4.1.2. Transaction Identifier (t=)
t=<integer>
This allows transactions and demultiplexing of messages at the
application level. It is possible that response for queries are not
received in order (e.g., if a transport other than HTTP is used), so
a mechanism is needed to match responses to queries.
4.1.3. Query Type (q=)
q=<query type> [SRC <Source NL-ID> | complete]
The query type can be 'getcost', 'getnetworkidentifier',
'getnetworkmap' or 'getstatus'. Certain queries allow either
complete ALTO information to be requested, or only a subset of ALTO
Penno & Yang Expires September 5, 2009 [Page 12]
Internet-Draft ALTO Protocol March 2009
information.
4.1.4. Response (r=)
r=<query type> [<success code> | [<failure code> <failure desc>]]
[<map version tag>] [COST <cost type> <cost mode>]
This line is used by the Server in a response to a previous query.
Success and failures codes are based on HTTP's status codes but
specific to the ALTO Protocol, so semantically different from those
of HTTP or other protocol serving as transport. For example, if ALTO
protocol is carried within HTTP, the HTTP status code can be "200
OK", but the ALTO status code can be "400 Bad Request".
The map version tag is used when the query type is
'getnetworkidentifier', 'getnetworkmap', or 'getcost'. It tells the
client which version of the Network Map was used to generated
response data.
The type and mode of costs returned is indicated in the 'getcost'
response. See Section 6 for details about costs as well as the type
and mode attributes.
4.1.5. Originator (o=)
o=<FQDN> | <IP address>
This line identifies the originator of cost information, which is not
necessarily related to the source IP address of the message.
4.1.6. Cost (c=)
c=SRC <Source NL-ID> [DEST <Dest NL-ID> <cost value>]
The cost is a generic measure of network preference.
4.1.7. Network Locations (n=)
n=SRC <Source NL-ID> [DEST <Dest NL-ID>]
The network location line can be used in the 'getcost',
'getnetworkmap', and 'getnetworkidentifier' messages to indicate
specific mappings that are needed.
The following network location types are specified in this document:
Penno & Yang Expires September 5, 2009 [Page 13]
Internet-Draft ALTO Protocol March 2009
o 'ASN': Autonomous System Number
o 'IPV4': IP Protocol version 4
o 'IPV6': IP Protocol version 6
o 'PID': Partition ID
4.1.8. Network Map (m=)
m=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]
The network map line is sent by server in a 'getnetworkmap' or
'getnetworkidentifier' response message. It conveys which Network
Location Identifiers are mapped to particular Top-Level NL-IDs
(PIDs).
4.1.9. Interface Definition (i=)
i=<interface name> <interface URI>
The interface definition line is sent by a server in a
'getinterfaces' response. It identifies an interface available from
an ALTO Server. See Section 5 for details.
4.2. Message Syntax
ALTO queries (requests) MUST have the following lines:
v=(version)
t=(transaction identifier)
q=(query type)
ALTO responses MUST have:
v=(version)
t=(transaction identifier)
r=(response)
4.2.1. getcost
This message instructs the server to return costs amongst Network
Location Identifiers.
Penno & Yang Expires September 5, 2009 [Page 14]
Internet-Draft ALTO Protocol March 2009
4.2.1.1. Query
q=getcost [SRC <Source NL-ID>] | complete
[COST <cost type> <cost mode>]
n=SRC <Source NL-ID> [DEST <Dest NL-ID>]
n=SRC <Source NL-ID> [DEST <Dest NL-ID>]
...
If the request does not specify either the Source NL-ID or the
'complete' token, the server assumes that the requesting IP addresses
indicates the Source NL-ID.
If the request does not specify the desired cost type and mode, then
the server assumes the type to be 'routingcost' and the mode to be
'numerical'.
If the 'complete' token is specified, costs between each pair of Top-
level NL-IDs are returned. Otherwise, the costs from Source NL-ID to
all Top-Level NL-IDs is returned.
4.2.1.2. Response
The server may reply with a message enumerating pairs of Network
Location Identifiers and associated costs:
r=getcost [<success code> | [<failure code> <failur desc>]]
<map version tag> COST <cost type> <cost mode>
c=SRC <Source NL-ID> DEST <Dest NL-ID> <cost value>
c=SRC <Source NL-ID> DEST <Dest NL-ID> <cost value>
...
If the server replies with multiple costs from a particular Source
NL-ID to multiple Destination NL-IDs, a more efficient encoding may
be used:
r=getcost [<success code> | [<failure code> <failur desc>]]
<map version tag> COST <cost type> <cost mode>
c=SRC <Source NL-ID>
<Dest NL-ID> <cost value>
<Dest NL-ID> <cost value>
...
c=SRC <Source NL-ID>
<Dest NL-ID> <cost value>
<Dest NL-ID> <cost value>
...
If the server for any reason cannot compute the cost between a
certain SRC-DEST pair contained in the request, it may omit the pair
Penno & Yang Expires September 5, 2009 [Page 15]
Internet-Draft ALTO Protocol March 2009
from the response.
4.2.2. getnetworkidentifier
This message requests the server to map a requested Network Location
Identifier into its corresponding Top-Level NL-ID. The default query
(with no parameters listed) can be used to discover the Source Group
for a particular ALTO Client.
4.2.2.1. Query
q=getnetworkidentifier [SRC <Source NL-ID>]
n=SRC <Source NL-ID>
If the request does not specify any Source NL-IDs, the server assumes
that the requesting IP addresses indicates the Source NL-ID.
4.2.2.2. Response
r=getnetworkidentifier [<success code> | [<failure code>
<failur desc>]] <map version tag>
m=<Top-Level NL-ID> [ <NL-ID> ... <NL-ID> ]
m=<Top-Level NL-ID> [ <NL-ID> ... <NL-ID> ]
...
The response includes the corresponding Top-Level NL-IDs for the
requested list of Source NL-IDs.
If the server for any reason cannot compute the Top-Level NL-ID for a
particular Source NL-ID, it may omit the Source NL-ID in the
response.
For example, if the query is for IP address 1.2.3.4 (in PID1),
1.2.3.5 (in PID1) and 128.1.1.2 (in PID2) the response would be:
r=getnetworkidentifier 200 1
m=PID1 IPV4:1.2.3.4 IPV4:1.2.3.5
m=PID2 IPV4:128.1.1.2
4.2.3. getnetworkmap
This message instructs the server to return the Network Location
Identifiers (e.g., IP Prefixes) contained within the specified Top-
Level NL-IDs (e.g., PIDs). By storing such a mapping, an ALTO Client
can locally map from IP addresses to PIDs without consulting the ALTO
Server.
Penno & Yang Expires September 5, 2009 [Page 16]
Internet-Draft ALTO Protocol March 2009
4.2.3.1. Query
q=getnetworkmap [SRC <Top-Level NL-ID>] | complete
n=SRC <Top-Level NL-ID>
n=SRC <Top-Level NL-ID>
...
If the 'complete' token is specified, the server assumes the set of
Top-Level NL-IDs to be all Top-Level NL-IDs defined in the Network
Map. Otherwise, mappings for only the specified Top-Level NL-IDs are
queried.
4.2.3.2. Response
r=getnetworkmap [<success code> | [<failure code>
| <failure desc>]] <map version tag>
m=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]
m=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]
...
Each line of the response indicates the NL-IDs contained within a
particular Top-Level NL-ID.
If the server for any reason cannot identify a particular Top-Level
NL-ID contained in the request, it may omit that Top-Level NL-ID from
the response.
4.3. ALTO Server Message Processing
This section specifies ALTO Server behavior when processing ALTO
queries. In general the ALTO protocol uses the same status codes as
HTTP.
4.3.1. Exception Handling
Standard HTTP status codes are returned by an ALTO Server in the
response (r=) line.
4.3.2. Successful Responses
An ALTO Server MUST use Status Code 200 when replying to an operation
that completed successfully. Note that this includes cases where the
ALTO Server responds with only a subset of the requested information.
The requesting application is expected to detect such cases if
necessary.
Penno & Yang Expires September 5, 2009 [Page 17]
Internet-Draft ALTO Protocol March 2009
4.3.3. Invalid Query Format
If the Request Data is formatted incorrectly (i.e., it does not
follow the syntax in Section 6), the ALTO Server MUST return an
status code and reason of "400 Bad Request".
4.3.4. Unsupported Query
If an ALTO Server does not support a certain type of query, e.g.,
cost for SRC-DEST pairs, a status code and reason of "501 Not
Implemented" might be returned in lieu of returning an invalid cost.
5. ALTO Interfaces
An ALTO Server exposes multiple interfaces to ALTO Clients, each of
which provides certain ALTO information to clients. Clients send
ALTO Messages (Section 4.2) to the ALTO Server interfaces to query
information, and receive ALTO Messages containing the requested
information.
Two sets of ALTO Interfaces are provided, corresponding to the two
sets of ALTO information:
o Network Map Interfaces: GetNetworkIdentifier, GetNetworkMap
o Cost Map Interfaces: GetCost
The GetNetworkMap and GetCost interfaces each define instances that
may reply with static messages as opposed to dynamically-constructed
responses. In particular:
o GetNetworkMap-Source, GetCost-Source: provide at least subset the
of the ALTO information reusable by all ALTO Clients within a
particular Source Grouping (e.g., PID). These interfaces are
expected to be used by ALTO Clients such as P2P clients which
primarily consider costs from themselves to other network
locations.
o GetNetworkMap-Complete, GetCost-Complete: provide the complete set
of ALTO information, which is reusable by all ALTO Clients. These
interfaces are expected to be used by ALTO Clients such as P2P
trackers which may require global information.
Note that it is possible for GetNetworkMap-Source and GetCost-Source
to return more than the subset specific to ALTO Clients within the
particular Source Group. In particular, they may be pointers to the
GetNetworkMap-Complete and GetCost-Complete interfaces. However,
Penno & Yang Expires September 5, 2009 [Page 18]
Internet-Draft ALTO Protocol March 2009
this approach is only recommended if the total amount ALTO
information returned is small.
Each ALTO Interface has a corresponding URI. Using separate URIs for
each interface allows for implementation flexibility, the ability to
reuse common ALTO information based on the request URI (e.g.,
existing HTTP cache servers), and avoids defining the protocol to
explicitly duplicate request parameters in HTTP headers or query-
string parameters.
This section defines the ALTO Interfaces provided by the ALTO Server
and messages that may be sent to each interface's URI:
o Accepted Query: query type for messages allowed to be sent to the
interface. The ALTO Server MUST indicate an error if the query
type does not match the expected query type.
o Accepted Parameters: expected query parameters in request message.
The ALTO Server MUST indicate an error if the supplied parameters
do not meet these preconditions.
5.1. Interface Descriptor
The URI for each interface exposed by an ALTO Server is listed in the
Interface Descriptor given to an ALTO Client.
The URIs for the GetNetworkMap-Source and GetCost-Source interfaces
MAY include the string '<SRC-GRP>', which is replaced by ALTO Clients
with the Network Location Identifier denoting a particular Source
Group.
An ALTO Server accepts the 'getinterfaces' query at a well-known URI.
This URI could either be discovered directly by the ALTO Discovery
mechanism, or be standardized (e.g., '/alto-interfaces') and appended
to a hostname and port discovered by the ALTO Discovery mechanism.
An ALTO Client requests the Interface Descriptor using the
'getinterfaces' query:
q=getinterfaces
The returned Interface Descriptor is encoded as:
r=getinterfaces <success code>
i=<interface name> <interface URI template>
...
i=<interface name> <interface URI template>
Penno & Yang Expires September 5, 2009 [Page 19]
Internet-Draft ALTO Protocol March 2009
If an ALTO Server does not provide a certain interface, it does not
appear in the Interface Descriptor.
5.2. Cost Map Interfaces
5.2.1. GetCost
This interface returns all or a subset of the Cost Map. It also
allows ALTO Clients to query for costs with Type or Mode different
from the ALTO Server's default cost Type and Mode. This interface
should only be used by ALTO Clients requiring customized cost
information. ALTO Clients should use the GetCost-Source and GetCost-
Complete where possible.
The GetCost interface MAY be provided by an ALTO Server.
Interface Specification:
o Accepted Query: getcost
o Accepted Parameters: Any
There are no guarantees about the reusability of successful requests
to this interface. Thus, the ALTO Server MUST indicate in the HTTP
response that it is not cacheable.
5.2.2. GetCost-Source
This interface returns a subset of the Cost Map containing only costs
from a particular Source Group to other network locations.
The GetCost-Source interface MAY be provided by an ALTO Server.
Interface Specification:
o Accepted Query: getcost
o Accepted Parameters: Indicate Source NL-ID consistent with URI.
Successful requests to this interface MUST generate a response
message that is independent of the querying ALTO Client. Thus, the
ALTO Server MAY indicate caching parameters in the HTTP response.
5.2.3. GetCost-Complete
This interface returns the complete Cost Map.
The GetCost-Complete interface MUST be provided by an ALTO Server.
Penno & Yang Expires September 5, 2009 [Page 20]
Internet-Draft ALTO Protocol March 2009
Interface Specification:
o Accepted Query: getcost
o Accepted Parameters: Indicate 'complete' token
Successful requests to this interface MUST generate a response
message that is independent of the querying ALTO Client. Thus, the
ALTO Server MAY indicate caching parameters in the HTTP response.
5.3. Network Map Interfaces
5.3.1. GetNetworkIdentifier
This interface returns mappings between Network Location Identifiers
computed using the Network Map. Without any request parameters, it
returns the Source Group containing the requesting ALTO Client.
The GetNetworkIdentifier interface MUST be provided by an ALTO Server
for the case of replying with the Source Group for the requesting
ALTO Client.
Interface Specification:
o Accepted Query: getnetworkidentifier
o Accepted Parameters: Any
There are no guarantees about the reusability of successful requests
to this interface. Thus, the ALTO Server MUST indicate in the HTTP
response that it is not cacheable.
5.3.2. GetNetworkMap
This interface returns all or a subset of the Network Map. This
interface should only be used by ALTO Clients requiring specific
portions of the Network Map. ALTO Clients should use the
GetNetworkMap-Source and GetNetworkMap-Complete where possible.
The GetNetworkMap interface MAY be provided by an ALTO Server.
Interface Specification:
o Accepted Query: getnetworkmap
o Accepted Parameters: Any
There are no guarantees about the reusability of successful requests
Penno & Yang Expires September 5, 2009 [Page 21]
Internet-Draft ALTO Protocol March 2009
to this interface. Thus, the ALTO Server MUST indicate in the HTTP
response that it is not cacheable.
5.3.3. GetNetworkMap-Source
This interface returns a subset of the Network Map containing at
least Network Locations used in the response to the GetCost-Source
interface.
The GetNetworkMap-Source interface MAY be provided by an ALTO Server.
Interface Specification:
o Accepted Query: getnetworkmap
o Accepted Parameters: Indicate Source NL-ID consistent with URI.
Successful requests to this interface MUST generate a response
message that is independent of the querying ALTO Client. Thus, the
ALTO Server MAY indicate caching parameters in the HTTP response.
5.3.4. GetNetworkMap-Complete
This interface returns the full Network Map.
The GetNetworkMap-Complete interface MUST be provided by an ALTO
Server.
Interface Specification:
o Accepted Query: getnetworkmap
o Accepted Parameters: Indicate 'complete' token
Successful requests to this interface MUST generate a response
message that is independent of the querying ALTO Client. Thus, the
ALTO Server MAY indicate caching parameters in the HTTP response.
5.4. Example Usage
An ALTO Client embedded in a P2P client (e.g., BitTorrent client) may
request an Interface Descriptor from its ALTO Server. The ALTO
Server may return the following Interface Descriptor:
Penno & Yang Expires September 5, 2009 [Page 22]
Internet-Draft ALTO Protocol March 2009
GetNetworkIdentifier /alto/msg.cgi?query=getnetworkidentifier
GetNetworkMap /alto/msg.cgi?query=getnetworkmap
GetNetworkMap-Source /alto/networkmap-src-<SRC-GRP>.txt
GetNetworkMap-Complete /alto/networkmap-complete.txt
GetCost /alto/msg.cgi?query=getcost
GetCost-Source /alto/costmap-src-<SRC-GRP>.txt
GetCost-Complete /alto/costmap-complete.txt
Next, if any URI used by the client contains the '<SRC-GRP>' token,
the P2P client queries GetNetworkIdentifier without any parameters to
obtain its Source Group. It then replaces the '<SRC-GRP>' token in
the URI template.
Last, the client may then use the GetCost-Source interface with the
computed URI.
6. ALTO Costs
Preferences are communicated to ALTO Clients in the form of network
costs. ALTO Costs have two attributes:
o Type: identifies what the costs represent
o Mode: identifies how the costs should be interprested
6.1. Type Attribute
The Type attribute indicates what the cost represents. For example,
an ALTO Server could define costs representing air-miles, hop-counts,
ranking, or generic routing costs.
Cost types are indicated in protocol messages as alphanumeric
strings. An ALTO Server MUST at least define the routing cost type
denoted by the string 'routingcost'.
Note that an ISP may internally compute routing cost using any method
it chooses (including air-miles or hop-count).
If an ALTO Client requests a cost Type that is not available, the
ALTO Server responds with an error as specified in Section 4.3.4.
6.2. Mode Attribute
The Mode attribute indicates how costs should be interpreted. For
example, an ALTO Server could return costs that should be interpreted
as numerical values or ordinal rankings.
Penno & Yang Expires September 5, 2009 [Page 23]
Internet-Draft ALTO Protocol March 2009
It is important to communicate such information to ALTO Clients, as
certain operations may not be valid on certain costs returned by an
ALTO Server. For example, it is possible for an ALTO Server to
return a set of IP addresses with costs indicating a ranking of the
IP addresses. Arithmetic operations, such as summation, that would
make sense for numerical values, do not make sense for ordinal
rankings. ALTO Clients may want to handle such costs differently.
Cost Modes are indicated in protocol messages as alphanumeric
strings. An ALTO Server MUST at least define the modes 'numerical'
and 'ordinal'.
If an ALTO Client requests a cost Mode that is not supported, the
ALTO Server MUST reply with costs having Mode either 'numerical' or
'ordinal'. Thus, an ALTO Server must implement at least one of
'numerical' or 'ordinal' Costs, but it may choose which to support.
ALTO Clients may choose how to handle such situations. Two
particular possibilities are to use the returned costs as-is (e.g.,
treat numerical costs as ordinal rankings) or ignore the ALTO
information altogether.
6.3. Semantics
Costs returned by an ALTO Server SHOULD be defined such that higher
values indicate a lower preference, while smaller values indicate a
higher preference.
7. Discussions
7.1. Discovery
The particular mechanism by which an ALTO Client discovers its ALTO
Server is an important component to the ALTO architecture and
numerous techniques have been discussed [11] [12]. However, the
discovery mechanism is out of scope for this document.
Some ISPs have proposed the possibility of delegation, in which an
ISP provides information for customer networks which do not wish to
run Portal Servers themselves. A consideration for delegation is
that customer networks may wish to explicitly configure such
delegation.
7.2. Network Address Translation Considerations
At this day and age of v4<->v4, v4<->v6[13], and possibly v6<->v6[14]
NATO's, a protocol should strive to be NAT friendly and minimize
carrying IP addresses in the payload, or provide a mode of operation
Penno & Yang Expires September 5, 2009 [Page 24]
Internet-Draft ALTO Protocol March 2009
where the source IP address provide the information necessary to the
server.
The protocol specified in this document provides a mode of operation
(the GetCost-Source interface) where the source NL-ID is computed by
the ALTO Server (via the GetNetworkIdentifier interface) from the
source IP address ALTO Client requests. This is similar to how some
P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS
Protocol" in [15]).
7.3. Mapping IPs to ASNs
The ALTO Protocol described in this document allows ISPs to provide
ALTO information including ASNs. Thus, ALTO Clients may need to
identify the ASN for a Resource Provider to determine the cost to
that Resource Provider.
Applications can already map IPs to ASNs using information from a BGP
Looking Glass. To do so, they must download a file of about 1.5MB
when compressed (as of October 2008, with all information not needed
for IP to ASN mapping removed) and periodically (perhaps monthly)
refresh it.
Alternatively, the GetNetworkMap interface defined in this document
could be extended to map ASNs into a set of IP prefixes. The
mappings provided by the ISP would be both smaller and more
authoritative.
For simplicity of implementation, it's highly desirable that clients
only have to implement exactly one mechanism of mapping IPs to ASNs.
7.4. P2P Peer Selection
This section discusses possible approaches to peer selection using
ALTO information (Network Location Identifiers and associated Costs)
from an ALTO Server. Specifically, the application must select which
peers to use based on this and other sources of information. With
this in mind, the usage of ALTO Costs is intentionally flexible,
because:
Different applications may use the information differently. For
example, an application that connects to just one address may have
a different algorithm for selecting it than an application that
connects to many.
Though initial experiments have been conducted [16], more
investigation is needed to identify other methods.
Penno & Yang Expires September 5, 2009 [Page 25]
Internet-Draft ALTO Protocol March 2009
In addition, the application might account for robustness, perhaps
using randomized exploration to determine if it performs better
without ALTO information.
7.4.1. Client-based Peer Selection
One possibility is for peer selection using ALTO costs to be done
entirely by a P2P client. The following are some techniques have
been proposed and/or used:
o Prefer network locations with lower ordinal rankings (i.e., higher
priority) [17] [5].
o Optimistically unchoking low-cost peers with higher probability
[5].
7.4.2. Server-based Peer Selection
Another possibility is for ALTO costs to be used by an Application
Tracker (e.g., BitTorrent Tracker) when returning peer lists. The
following are techniques that have been proposed and/or used:
o Using bandwidth matching (e.g., at an Application Tracker) and
choosing solution (within bound of optimal) with minimal network
cost [16].
8. IANA Considerations
This document request the registration of a new media type:
"application/alto"
9. Security Considerations
9.1. ISPs
ISPs must be cognizant of the network topology and provisioning
information provided through ALTO Interfaces. ISPs should evaluate
how much information is revealed and the associated risks. In
particular, providing overly fine-grained information may make it
easier for attackers to infer network topology. On the other hand,
revealing overly coarse-grained information may not provide benefits
to network efficiency or performance improvements to ALTO Clients.
Penno & Yang Expires September 5, 2009 [Page 26]
Internet-Draft ALTO Protocol March 2009
9.2. ALTO Clients
Applications using the information must be cognizant of the
possibility that the information is malformed or incorrect. Even
when it is correct, its use might harm the performance. When an
application concludes that it would get better performance
disregarding the ALTO information, the decision to discontinue the
use of ALTO information is likely best left to the user.
ALTO Clients should also be cognizant of revealing Network Location
Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server,
as doing so may allow the ALTO Server to infer communication
patterns. One possibility is for the ALTO Client to only rely on the
GetNetworkMap-Source/GetNetworkMap-Complete and GetCost-Source/
GetCost-Complete interfaces.
The use of SSL/TLS can make it easier for clients to verify the
origin of ALTO information.
9.3. ALTO Information
An ALTO Server may optionally use authentication and encryption to
protect ALTO information. Authentication and encryption may be
provided using HTTP Basic or Digest Authentication and/or SSL/TLS.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
10.2. Informative References
[5] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Export Service", draft-shalunov-alto-infoexport-00 (work in
progress), October 2008.
Penno & Yang Expires September 5, 2009 [Page 27]
Internet-Draft ALTO Protocol March 2009
[6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P:
Provider Portal for P2P Applications", draft-p4p-framework-00
(work in progress), November 2008.
[7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P
Protocol Specification", draft-wang-alto-p4p-specification-00
(work in progress), March 2009.
[8] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang,
"Application-Layer Traffic Optimization (ALTO) Requirements",
draft-kiesel-alto-reqs-02 (work in progress), March 2009.
[9] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-marocco-alto-problem-statement-05 (work in progress),
March 2009.
[10] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An
Architecture of ALTO for P2P Applications",
draft-yang-alto-architecture-00 (work in progress), March 2009.
[11] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols",
draft-wang-alto-discovery-00 (work in progress), March 2009.
[12] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application-
Layer Traffic Optimization (ALTO): Discover ALTO Servers",
draft-song-alto-server-discovery-00 (work in progress),
March 2009.
[13] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
Translation", draft-baker-behave-v4v6-framework-02 (work in
progress), February 2009.
[14] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
Translation (NAT66)", draft-mrw-behave-nat66-01 (work in
progress), November 2008.
[15] "Bittorrent Protocol Specification v1.0",
http://wiki.theory.org/BitTorrentSpecification, 2009.
[16] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A.
Silberschatz., "P4P: Provider Portal for (P2P) Applications",
In SIGCOMM 2008.
[17] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D.
Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00
(work in progress), March 2009.
Penno & Yang Expires September 5, 2009 [Page 28]
Internet-Draft ALTO Protocol March 2009
Appendix A. Contributors
The people listed here should be viewed as co-authors of the
document. Due to the limit of 5 authors per draft the co-authors
were moved to the contributors section at this point.
Richard Alimi
Yale University
EMail: richard.alimi@yale.edu
D. Pasko
Verizon
EMail: pasko@verizon.com
L. Popkin
Pando Networks
EMail: laird@pando.com
Satish Raghunath
Juniper Networks
satishr@juniper.net
Stanislav Shalunov
BitTorrent
EMail: shalunov@bittorrent.com
Yu-Shun Wang
Penno & Yang Expires September 5, 2009 [Page 29]
Internet-Draft ALTO Protocol March 2009
Microsoft Corp.
yu-shun.wang@microsoft.com
Richard Woundy
Comcast
Richard_Woundy@cable.comcast.com
Appendix B. Acknowledgements
We would like to thank the following additional people who were
involved in either of the projects (P4P or ALTO Info-Export) that
contributed to this merged document: Alex Gerber (AT&T), Chris
Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind
Krishnamurthy (University of Washington), Marty Lafferty (DCIA),
Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson),
Jason Livingood (Comcast), Michael Merritt (AT&T), Stefano Previdi
(Cisco), James Royalty (Pando Networks), Thomas Scholl (AT&T), Emilio
Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan
Sipra (Bell Canada), Haibin Song (Huawei), Oliver Spatscheck (AT&T),
See-Mong Tang (Microsoft), Jia Wang (AT&T), Hao Wang (Yale
University), Ye Wang (Yale University), Haiyong Xie (Yale
University), and David Zhang (PPLive).
Authors' Addresses
Reinaldo Penno (editor)
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA
USA
Email: rpenno@juniper.net
Y. Richard Yang (editor)
Yale University
Email: yry@cs.yale.edu
Penno & Yang Expires September 5, 2009 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:34 |