Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7971

 
 
 

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Part 3 of 4, p. 36 to 58
Prev Section       Next Section

 


prevText      Top      ToC       Page 36 
3.5.  Abstract Map Examples for Different Types of ISPs

3.5.1.  Small ISP with Single Internet Uplink

   The ALTO protocol does not mandate how to determine costs between
   endpoints and/or determine map data.  In complex usage scenarios,
   this can be a non-trivial problem.  In order to show the basic
   principle, this and the following sections explain for different
   deployment scenarios how ALTO maps could be structured.

   For a small ISP, the inter-domain traffic optimizing problem is how
   to decrease the traffic exchanged with other ISPs, because of high
   settlement costs.  By using the ALTO service to optimize traffic, a
   small ISP can define two "optimization areas": one is its own network
   and the other one consists of all other network destinations.  The
   cost map can be defined as follows: the cost of a link between
   clients of the inner ISP's network is lower than between clients of
   the outer ISP's network and clients of inner ISP's network.  As a
   result, a host with an ALTO client inside the network of this ISP
   will prefer retrieving data from hosts connected to the same ISP.

   An example is given in Figure 9.  It is assumed that ISP A is a small
   ISP only having one access network.  As operator of the ALTO service,
   ISP A can define its network to be one optimization area, named as
   PID1, and define other networks to be the other optimization area,
   named as PID2.  C1 is denoted as the cost inside the network of ISP
   A.  C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to
   PID2.  In the following, C2=C3 is assumed for the sake of simplicity.
   In order to keep traffic local inside ISP A, it makes sense to define
   C1<C2.

Top      Up      ToC       Page 37 
              -----------
          ////           \\\\
        //                   \\
      //                       \\                  /-----------\
     | +---------+               |             ////             \\\\
     | | ALTO    |  ISP A        |    C2      |    Other Networks   |
    |  | Service |  PID 1         <-----------     PID 2
     | +---------+  C1           |----------->|                     |
     |                           |  C3 (=C2)   \\\\             ////
      \\                       //                  \-----------/
        \\                   //
          \\\\           ////
              -----------

             Figure 9: Example ALTO Deployment for a Small ISP

   A simplified extract of the corresponding ALTO network and cost maps
   is listed in Figures 10 and 11, assuming that the network of ISP A
   has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, as well
   as the IPv6 address range 2001:db8:100::/48.  In this example, the
   cost values C1 and C2 can be set to any number C1<C2.

Top      Up      ToC       Page 38 
      HTTP/1.1 200 OK
      ...
      Content-Type: application/alto-networkmap+json

      {
       ...
        "network-map" : {
          "PID1" : {
            "ipv4" : [
              "192.0.2.0/24",
              "198.51.100.0/25"
            ],
            "ipv6" : [
              "2001:db8:100::/48"
            ]
          },
          "PID2" : {
            "ipv4" : [
              "0.0.0.0/0"
            ],
            "ipv6" : [
              "::/0"
            ]
          }
        }
      }

                    Figure 10: Example ALTO Network Map

      HTTP/1.1 200 OK
      ...
      Content-Type: application/alto-costmap+json

      {
          ...
          "cost-type" : {"cost-mode"  : "numerical",
                         "cost-metric": "routingcost"
          }
        },
        "cost-map" : {
          "PID1": { "PID1": C1,  "PID2": C2 },
          "PID2": { "PID1": C2,  "PID2": 0 },
        }
      }

                     Figure 11: Example ALTO Cost Map

Top      Up      ToC       Page 39 
3.5.2.  ISP with Several Fixed-Access Networks

   This example discusses a P2P application traffic optimization use
   case for a larger ISP with a fixed network comprising several access
   networks and a core network.  The traffic optimizing objectives
   include (1) using the backbone network efficiently, (2) adjusting the
   traffic balance in different access networks according to traffic
   conditions and management policies, and (3) achieving a reduction of
   settlement costs with other ISPs.

   Such a large ISP deploying an ALTO service may want to optimize its
   traffic according to the network topology of its access networks.
   For example, each access network could be defined to be one
   optimization area, i.e., traffic should be kept local withing that
   area if possible.  This can be achieved by mapping each area to a
   PID.  Then, the costs between those access networks can be defined
   according to a corresponding traffic optimizing requirement by this
   ISP.  One example setup is further described below and also shown in
   Figure 12.

   In this example, ISP A has one backbone network and three access
   networks, named as AN A, AN B, and AN C.  A P2P application is used
   in this example.  For a reasonable application-level traffic
   optimization, the first requirement could be a decrease of the P2P
   traffic on the backbone network inside the AS of ISP A and the second
   requirement could be a decrease of the P2P traffic to other ISPs,
   i.e., other ASes.  The second requirement can be assumed to have
   priority over the first one.  Also, we assume that the settlement
   rate with ISP B is lower than with other ISPs.  ISP A can deploy an
   ALTO service to meet these traffic distribution requirements.  In the
   following, we will give an example of an ALTO setting and
   configuration according to these requirements.

   In the network of ISP A, the operator of the ALTO server can define
   each access network to be one optimization area, and assign one PID
   to each access network, such as PID 1, PID 2, and PID 3.  Because of
   different peerings with different outer ISPs, one can define ISP B to
   be one additional optimization area and assign PID 4 to it.  All
   other networks can be added to a PID to be one further optimization
   area (PID 5).

   In the setup, costs (C1, C2, C3, C4, C5, C6, C7, C8) can be assigned
   as shown in Figure 12.  Cost C1 is denoted as the link cost in inner
   AN A (PID 1), and C2 and C3 are defined accordingly.  C4 is denoted
   as the link cost from PID 1 to PID 2, and C5 is the corresponding
   cost from PID 3, which is assumed to have a similar value.  C6 is the
   cost between PID 1 and PID 3.  For simplicity, this scenario assumes

Top      Up      ToC       Page 40 
   symmetrical costs between the AN this example.  C7 is denoted as the
   link cost from the ISP B to ISP A.  C8 is the link cost from other
   networks to ISP A.

   According to previous discussion of the first requirement and the
   second requirement, the relationship of these costs will be defined
   as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)

    +------------------------------------+         +----------------+
    | ISP A   +---------------+          |         |                |
    |         |    Backbone   |          |   C7    |      ISP B     |
    |     +---+    Network    +----+     |<--------+      PID 4     |
    |     |   +-------+-------+    |     |         |                |
    |     |           |            |     |         |                |
    |     |           |            |     |         +----------------+
    | +---+--+     +--+---+     +--+---+ |
    | |AN A  |  C4 |AN B  |  C5 |AN C  | |
    | |PID 1 +<--->|PID 2 |<--->+PID 3 | |
    | |C1    |     |C2    |     |C3    | |         +----------------+
    | +---+--+     +------+     +--+---+ |         |                |
    |     ^                        ^     |   C8    | Other Networks |
    |     |                        |     |<--------+ PID 5          |
    |     +------------------------+     |         |                |
    |                  C6                |         |                |
    +------------------------------------+         +----------------+

           Figure 12: ALTO Deployment in Large ISPs with Layered
                         Fixed-Network Structures

3.5.3.  ISP with Fixed and Mobile Network

   An ISP with both mobile network and fixed network may focus on
   optimizing the mobile traffic by keeping traffic in the fixed network
   as much as possible, because wireless bandwidth is a scarce resource
   and traffic is costly in mobile network.  In such a case, the main
   requirement of traffic optimization could be decreasing the usage of
   radio resources in the mobile network.  An ALTO service can be
   deployed to meet these needs.

   Figure 13 shows an example: ISP A operates one mobile network, which
   is connected to a backbone network.  The ISP also runs two fixed-
   access networks AN A and AN B, which are also connected to the
   backbone network.  In this network structure, the mobile network can
   be defined as one optimization area, and PID 1 can be assigned to it.
   Access networks AN A and B can also be defined as optimization areas,
   and PID 2 and PID 3 can be assigned, respectively.  The cost values
   are then defined as shown in Figure 13.

Top      Up      ToC       Page 41 
   To decrease the usage of wireless link, the relationship of these
   costs can be defined as follows:

   From view of mobile network: C4 < C1 and C4 = C8.  This means that
   clients in mobile network requiring data resources from other clients
   will prefer clients in AN A or B to clients in the mobile network.
   This policy can decrease the usage of wireless link and power
   consumption in terminals.

   From view of AN A: C2 < C6, C5 = maximum cost.  This means that
   clients in other optimization area will avoid retrieving data from
   the mobile network.

   From view of AN B: Analog to the view of AN A, C3 < C8 and C9 =
   maximum cost.

   +-----------------------------------------------------------------+
   |                                                                 |
   |  ISP A                 +-------------+                          |
   |               +--------+   ALTO      +---------+                |
   |               |        |   Service   |         |                |
   |               |        +------+------+         |                |
   |               |               |                |                |
   |               |               |                |                |
   |               |               |                |                |
   |       +-------+-------+       | C6    +--------+------+         |
   |       |     AN A      |<--------------|      AN B     |         |
   |       |     PID 2     |   C7  |       |      PID 3    |         |
   |       |     C2        |-------------->|      C3       |         |
   |       +---------------+       |       +---------------+         |
   |             ^    |            |              |     ^            |
   |             |    |            |              |     |            |
   |             |    | C4         |           C8 |     |            |
   |          C5 |    |            |              |     | C9         |
   |             |    |   +--------+---------+    |     |            |
   |             |    +-->|  Mobile Network  |<---+     |            |
   |             |        |  PID 1           |          |            |
   |             +------- |  C1              |----------+            |
   |                      +------------------+                       |
   +-----------------------------------------------------------------+

          Figure 13: ALTO Deployment in ISPs with Mobile Network

   These examples show that for ALTO in particular the relationships
   between different costs matter; the operator of the server has
   several degrees of freedom how to set the absolute values.

Top      Up      ToC       Page 42 
3.6.  Comprehensive Example for Map Calculation

   In addition to the previous, abstract examples, this section presents
   a more detailed scenario with a realistic IGP and BGP routing
   protocol configuration.  This example was first described in
   [MAP-CALC].

3.6.1.  Example Network

   Figure 14 depicts a network that is used to explain the steps carried
   out in the course of this example.  The network consists of nine
   routers (R1 to R9).  Two of them are border routers (R1 + R8)
   connected to neighbored networks (AS 2 to AS 4).  Furthermore, AS 4
   is not directly connected to the local network, but has AS 3 as
   transit network.  The links between the routers are point-to-point
   connections.  These connections also form the core network with the
   2001:db8:1:0::/56 prefix.  This prefix is large enough to provide
   addresses for all router interconnections.  In addition to the core
   network, the local network also has five client networks attached to
   five different routers (R2, R5, R6, R7 and R9).  Each client network
   has a /56 prefix with 2001:db8:1:x00:: (x = [1..5]) as network
   address.

Top      Up      ToC       Page 43 
   +-------------------+    +-----+    +-----+    +-------------------+
   |2001:db8:1:200::/56+----+ R6  |    | R7  +----+2001:db8:1:300::/56|
   +-------------------+    +--+--+    +--+--+    +-------------------+
                               |          |
   +---------------+           |          |
   |      AS 2     |           |          |
   |2001:db8:2::/48|           | 10       | 10
   +------------+--+           |          |
                |              |          |
                |              |          |
             +--+--+   15   +--+--+    +--+--+    +-------------------+
             | R1  +--------+ R3  +----+ R5  |----+2001:db8:1:400::/56|
             +--+--+        +--+--+ 5  +--+--+    +-------------------+
                |   \      /   |          |
                |    \    / 15 |          |
                |     \  /     |          |           +---------------+
                |      \/      |          |           |      AS 4     |
                | 20   /\      | 5        | 10        |2001:db8:4::/48|
                |     /  \     |          |           +-------+-------+
                |    /    \ 20 |          |                   |
                |   /      \   |          |                   |
             +--+--+        +--+--+    +--+--+        +-------+-------+
             | R2  |        | R4  |    | R8  +--------+      AS 3     |
             +--+--+        +--+--+    +--+--+        |2001:db8:3::/48|
                |              |          |           +---------------+
                |              |          | 10
                |              | 20       |
   +------------+------+       |       +--+--+    +-------------------+
   |2001:db8:1:100::/56|       +-------+ R9  +----+2001:db8:1:500::/56|
   +-------------------+               +-----+    +-------------------+

                        Figure 14: Example Network

   The example network utilizes two different routing protocols, one for
   IGP and another for EGP routing.  The used IGP is a link-state
   protocol such as IS-IS.  The applied link weights are annotated in
   the graph and additionally shown in Figure 15.  All links are
   bidirectional and their weights are symmetric.  To obtain the
   topology and routing information from the network, the topology data
   source must be connected directly to one of the routers (R1...R9).
   Furthermore, the topology data source must be enabled to communicate
   with the router and vice versa.

   The BGP is used in this scenario to route between autonomous systems.
   External BGP is running on the two border routers R1 and R8.
   Furthermore, internal BGP is used to propagate external as well as
   internal prefixes within the network boundaries; it is running on
   every router with an attached client network (R2, R5, R6, R7 and R9).

Top      Up      ToC       Page 44 
   Since no route reflector is present it is necessary to fetch routes
   from each BGP router separately.

              R1   R2   R3   R4   R5   R6   R7   R8   R9
          R1   0   15   15   20    -    -    -    -    -
          R2  15    0   20    -    -    -    -    -    -
          R3  15   20    0    5    5   10    -    -    -
          R4  20    -    5    0    5    -    -    -   20
          R5   -    -    5    5    0    -   10   10    -
          R6   -    -   10    -    -    0    -    -    -
          R7   -    -    -    -   10    -    0    -    -
          R8   -    -    -    -   10    -    -    0   10
          R9   -    -    -   20    -    -    -   10    0

                  Figure 15: Example Network Link Weights

   For monitoring purposes, it is possible to enable, e.g., SNMP or
   NETCONF on the routers within the network.  This way an ALTO server
   may obtain several additional information about the state of the
   network.  For example, utilization, latency, and bandwidth
   information could be retrieved periodically from the network
   components to get and keep an up-to-date view on the network
   situation.

   In the following, it is assumed that the listed attributes are
   collected from the network:

   o  IS-IS: topology, link weights

   o  BGP: prefixes, AS numbers, AS distances, or other BGP metrics

   o  SNMP: latency, utilization, bandwidth

3.6.2.  Potential Input Data Processing and Storage

   Due to the variety of data sources available in a network, it may be
   necessary to aggregate the information and define a suitable data
   model that can hold the information efficiently and easily
   accessible.  One potential model is an annotated directed graph that
   represents the topology.  The attributes can be annotated at the
   corresponding positions in the graph.  The following shows how such a
   topology graph could describe the example topology.

   In the topology graph, a node represents a router in the network,
   while the edges stand for the links that connect the routers.  Both
   routers and links have a set of attributes that store information
   gathered from the network.

Top      Up      ToC       Page 45 
   Each router could be associated with a basic set of information, such
   as:

   o  ID: Unique ID within the network to identify the router.

   o  Neighbor IDs: List of directly connected routers.

   o  Endpoints: List of connected endpoints.  The endpoints may also
      have further attributes themselves depending on the network and
      address type.  Such potential attributes are costs for reaching
      the endpoint from the router, AS numbers, or AS distances.

   In addition to the basic set, many more attributes may be assigned to
   router nodes.  This mainly depends on the utilized data sources.
   Examples for such additional attributes are geographic location, host
   name and/or interface types, just to name a few.

   The example network shown in Figure 14 represents such an internal
   network graph where the routers R1 to R9 represent the nodes and the
   connections between them are the links.  For instance, R2 has one
   directly attached IPv6 endpoint that belongs to its own AS, as shown
   in Figure 16.

      ID:  2

      Neighbor IDs:  1,3 (R1, R3)

      Endpoints:

         Endpoint:  2001:db8:1:100::/56

         Weight:  10 (e.g., the default IGP metric value)

         ASNumber:  1 (our own AS)

         ASDistance:  0

      Host Name:  R2

                       Figure 16: Example Router R2

   Router R8 has two attached IPv6 endpoints, as explained in Figure 17.
   The first one belongs to a directly neighbored AS with AS number 3.
   The AS distance from our network to AS3 is 1.  The second endpoint
   belongs to an AS (AS4) that is no direct neighbor but directly
   connected to AS3.  To reach endpoints in AS4, it is necessary to
   cross AS3, which increases the AS distance by one.

Top      Up      ToC       Page 46 
      ID:  8

      Neighbor IDs:  5,9 (R5, R9)

      Endpoints:

         Endpoint:  2001:db8:3::/48

         Weight:  100

         ASNumber:  3

         ASDistance:  1

         Endpoint:  2001:db8:4::/48

         Weight:  200

         ASNumber:  4

         ASDistance:  2

      Host Name:  R8

                       Figure 17: Example Router R8

   A potential set of attributes for a link is described in the
   following list:

   o  Source ID: ID of the source router of the link.

   o  Destination ID: ID of the destination router of the link.

   o  Weight: The cost to cross the link, e.g., defined by the used IGP.

   Additional attributes that provide technical details and state
   information can be assigned to links as well.  The availability of
   such additional attributes depends on the utilized data sources.
   Such attributes can be characteristics like maximum bandwidth,
   utilization, or latency on the link as well as the link type.

   In the example, the link attributes are equal for all links and only
   their values differ.  It is assumed that the attributes utilization,
   bandwidth, and latency are collected, e.g., via SNMP or NETCONF.  In
   the topology of Figure 14, the links between R1 and R2 would then
   have the following link attributes explained in Figure 18:

Top      Up      ToC       Page 47 
      R1->R2:

      Source ID:  1

      Destination ID:  2

      Weight:  15

      Bandwidth:  10 Gbit/s

      Utilization:  0.1

      Latency:  2 ms

      R2->R1:

      Source ID:  2

      Destination ID:  1

      Weight:  15

      Bandwidth:  10 Gbit/s

      Utilization:  0.55

      Latency:  5 ms

                        Figure 18: Link Attributes

   It has to be emphasized that values for utilization and latency can
   be very volatile.

3.6.3.  Calculation of Network Map from the Input Data

   The goal of the ALTO map calculation process is to get from the graph
   representation of the network to a coarser-grained and abstract
   matrix representation.  The first step is to generate the network
   map.  Only after the network map has been generated is it possible to
   compute the cost map since it relies on the network map.

   To generate an ALTO network map, a grouping function is required.  A
   grouping function processes information from the network graph to
   group endpoints into PIDs.  The way of grouping is manifold and
   algorithms can utilize any information provided by the network graph
   to perform the grouping.  The functions may omit certain endpoints in

Top      Up      ToC       Page 48 
   order to simplify the map or in order to hide details about the
   network that are not intended to be published in the resulting ALTO
   network map.

   For IP endpoints, which are either an IP (version 4 or version 6)
   address or prefix, [RFC7285] requires the use of a longest-prefix
   matching algorithm to map IPs to PIDs.  This requirement results in
   the constraints that every IP must be mapped to a PID and the same
   prefix or address not be mapped to more than one PID.  To meet the
   first constraint, every calculated map must provide a default PID
   that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6.
   Both prefixes cover their entire address space, and if no other PID
   matches an IP endpoint, the default PID will.  The second constraint
   must be met by the grouping function that assigns endpoints to PIDs.
   In case of collision, the grouping function must decide to which PID
   an endpoint is assigned.  These or other constraints may apply to
   other endpoint types depending on the used matching algorithm.

   A simple example for such grouping is to compose PIDs by host names.
   For instance, each router's host name is selected as the name for a
   PID and the attached endpoints are the member endpoints of the
   corresponding PID.  Additionally, backbone prefixes should not appear
   in the map so they are filtered out.  The following table in
   Figure 19 shows the resulting ALTO network map, using the network in
   Figure 14 as example:

          PID  |  Endpoints
      ---------+-----------------------------------
           R1  |  2001:db8:2::/48
           R2  |  2001:db8:1:100::/56
           R5  |  2001:db8:1:400::/56
           R6  |  2001:db8:1:200::/56
           R7  |  2001:db8:1:300::/56
           R8  |  2001:db8:3::/48, 2001:db8:4::/48
           R9  |  2001:db8:1:500::/56
       default |  0.0.0.0/0, ::/0

                    Figure 19: Example ALTO Network Map

   Since router R3 and R4 have no endpoints assigned, they are not
   represented in the network map.  Furthermore, as previously
   mentioned, the "default" PID was added to represent all endpoints
   that are not part of the example network.

Top      Up      ToC       Page 49 
3.6.4.  Calculation of Cost Map

   After successfully creating the network map, the typical next step is
   to calculate the costs between the generated PIDs, which form the
   cost map.  Those costs are calculated by cost functions.  A cost
   function may calculate unidirectional values, which means it is
   necessary to compute the costs from every PID to every PID.  In
   general, it is possible to use all available information in the
   network graph to compute the costs.  In case a PID contains more than
   one IP address or prefix, the cost function may first calculate a set
   of cost values for each source/destination IP pair.  In that case, a
   tiebreaker function is required to decide the resulting cost value,
   as [RFC7285] allows one cost value only between two PIDs.  Such a
   tiebreaker can be a simple function such as minimum, maximum, or
   average value.

   No matter what metric the cost function uses, the path from source to
   destination is usually defined by the path with minimum weight.  When
   the link weight is represented by an additive metric, the path weight
   is the sum of link weights of all traversed links.  The path may be
   determined, for instance, with the Bellman-Ford or Dijkstra
   algorithms.  The latter progressively builds the shortest path in
   terms of cumulated link lengths.  In our example, the link lengths
   are link weights with values illustrated in Figure 15.  Hence, the
   cost function generally extracts the optimal path with respect to a
   chosen metric, such as the IGP link weight.  It is also possible that
   more than one path with the same minimum weight exists, which means
   it is not entirely clear which path is going to be selected by the
   network.  Hence, a tiebreaker similar to the one used to resolve
   costs for PIDs with multiple endpoints is necessary.

   An important note is that [RFC7285] does not require cost maps to
   provide costs for every PID pair, so if no path cost can be
   calculated for a certain pair, the corresponding field in the cost
   map is left out.  Administrators may also not want to provide cost
   values for some PID pairs due to various reasons.  Such pairs may be
   defined before the cost calculation is performed.

   Based on the network map example shown in the previous section, it is
   possible to calculate the cost maps.  Figure 20 provides an example
   where the selected metric for the cost map is the minimum number of
   hops necessary to get from the endpoints in the source PID to
   endpoints in the destination PID.  Our chosen tiebreaker selects the
   minimum hop count when more than one value is returned by the cost
   function.

Top      Up      ToC       Page 50 
         PID  | default | R1  | R2  | R5  | R6  | R7  | R8  | R9  |
      --------+---------+-----+-----+-----+-----+-----+-----+-----|
      default |    x    |  x  |  x  |  x  |  x  |  x  |  x  |  x  |
         R1   |    x    |  0  |  2  |  3  |  3  |  4  |  4  |  3  |
         R2   |    x    |  2  |  0  |  3  |  3  |  4  |  4  |  4  |
         R5   |    x    |  3  |  3  |  0  |  3  |  2  |  2  |  3  |
         R6   |    x    |  3  |  3  |  3  |  0  |  4  |  4  |  4  |
         R7   |    x    |  4  |  4  |  2  |  4  |  0  |  3  |  4  |
         R8   |    x    |  4  |  4  |  2  |  4  |  3  |  0  |  2  |
         R9   |    x    |  3  |  4  |  3  |  4  |  4  |  2  |  0  |

                Figure 20: Example ALTO Hop Count Cost Map

   It should be mentioned that R1->R9 has several paths with equal path
   weights.  The paths R1->R3->R5->R8->R9, R1->R3->R4->R9, and
   R1->R4->R9 all have a path weight of 40.  Due to the minimum hop
   count value tiebreaker, 3 hops is chosen as value for the path
   R1->R4->R9.  Furthermore, since the "default" PID is, in a sense, a
   virtual PID with no endpoints that are part of the example network,
   no cost values are calculated for other PIDs from or towards it.

3.7.  Deployment Experiences

   There are multiple interoperable implementations of the ALTO
   protocol.  Some experiences in implementing and using ALTO for large-
   scale networks have been documented in [MAP-CALC] and are here
   summarized:

   o  Data collection: Retrieving topology information typically
      requires implementing several protocols other than ALTO for data
      collection.  For such other protocols, ALTO deployments faced
      protocol behaviors that were different from what would be expected
      from the specification of the corresponding protocol.  This
      includes behavior caused by older versions of the protocol
      specification, a lax interpretation on the remote side or simply
      incompatibility with the corresponding standard.  This sort of
      problems in collecting data can make an ALTO deployment more
      complicated, even if it is unrelated to ALTO protocol itself.

   o  Data processing: Processing network information can be very
      complex and quite resource demanding.  Gathering information from
      an autonomous system connected to the Internet may imply that a
      server must store and process hundreds of thousands of prefixes,
      several hundreds of megabytes of IPFIX/Netflow information per
      minute, and information from hundreds of routers and attributes of
      thousands of links.  A lot of disk memory, RAM, and CPU cycles as
      well as efficient algorithms are required to process the

Top      Up      ToC       Page 51 
      information.  Operators of an ALTO server have to be aware that
      significant compute resources are not only required for the ALTO
      server, but also for the corresponding data collection.

   o  Network map calculation: Large IP-based networks consist of
      hundreds of thousands of prefixes that have to be mapped to PIDs
      in the process of network map calculation.  As a result, network
      maps get very large (up to tens of megabytes).  However, depending
      on the design of the network and the chosen grouping function the
      calculated network maps contains redundancy that can be removed.
      There are at least two ways to reduce the size by removing
      redundancy.  First, adjacent IP prefixes can be merged.  When a
      PID has two adjacent prefix entries it can merge them together to
      one larger prefix.  It is mandatory that both prefixes be in the
      same PID.  However, the large prefix being assigned to another PID
      cannot be ruled out.  This must be checked, and it is up to the
      grouping function whether or not to merge the prefixes and remove
      the larger prefix from the other PID.  A simple example, when a
      PID comprises the prefixes 2001:db8:0:0::/64 and 2001:db8:0:1::/64
      it can easily merge them to 2001:db8:0:0::/63.  Second, a prefix
      and its next-longest-prefix match may be in the same PID.  In this
      case, the smaller prefix can simply be removed since it is
      redundant for obvious reasons.  A simple example, a PID comprises
      the prefixes 2001:db8:0:0::/62 and 2001:db8:0:1::/64 and the /62
      is the next-longer prefix match of the /64, the /64 prefix can
      simply be removed.  In contrast, if another PID contains the
      2001:db8:0:0::/63 prefix, the entry 2001:db8:0:1::/64 cannot be
      removed since the next-longest prefix is not in the same PID
      anymore.  Operators of an ALTO server thus have to analyze whether
      their address assignment schemes allows such tuning.

   o  Cost map calculation: One known implementation challenge with cost
      map calculations is the vast amount of CPU cycles that may be
      required to calculate the costs in large networks.  This is
      particular problematic if costs are calculated between the
      endpoints of each source-destination PID pair.  Very often several
      to many endpoints of a PID are attached to the same node, so the
      same path cost is calculated several times.  This is clearly
      inefficient.  A remedy could be more sophisticated algorithms,
      such as looking up the routers the endpoints of each PID are
      connected to in our network graph and calculated cost map based on
      the costs between the routers.  When deploying and configuring
      ALTO servers, administrators should consider the impact of huge
      cost maps and possibly ensure that map sizes do not get too large.

   In addition, further deployment experiences have been documented.
   One real example is described in greater detail in reference
   [CHINA-TRIAL].

Top      Up      ToC       Page 52 
   Also, experiments have been conducted with ALTO-like deployments in
   ISP networks.  For instance, NTT performed tests with their HINT
   server implementation and dummy nodes to gain insight on how an ALTO-
   like service can influence peer-to-peer systems [RFC6875].  The
   results of an early experiment conducted in the Comcast network are
   documented in [RFC5632].

4.  Using ALTO for P2P Traffic Optimization

4.1.  Overview

4.1.1.  Usage Scenario

   Originally, P2P applications were the main driver for the development
   of ALTO.  In this use case, it is assumed that one party (usually the
   operator of a "managed" IP network domain) will disclose information
   about the network through ALTO.  The application overlay will query
   this information and optimize its behavior in order to improve
   performance or Quality of Experience in the application while
   reducing the utilization of the underlying network infrastructure.
   The resulting win-win situation is assumed to be the incentive for
   both parties to provide or consume the ALTO information,
   respectively.

   P2P systems can be built with or without use of a centralized
   resource directory ("tracker").  The scope of this section is the
   interaction of P2P applications with the ALTO service.  In this
   scenario, the resource consumer ("peer") asks the resource directory
   for a list of candidates that can provide the desired resource.
   There are different options for how ALTO can be deployed in such use
   cases with a centralized resource directory.

   For efficiency reasons (i.e., message size), only a subset of all
   resource providers known to the resource directory will be returned
   to the resource consumer.  Some or all of these resource providers,
   plus further resource providers learned by other means such as direct
   communication between peers, will be contacted by the resource
   consumer for accessing the resource.  The purpose of ALTO is giving
   guidance on this peer selection, which should yield better-than-
   random results.  The tracker response as well as the ALTO guidance
   are most beneficial in the initial phase after the resource consumer
   has decided to access a resource, as long as only few resource
   providers are known.  Later, when the resource consumer has already
   exchanged some data with other peers and measured the transmission
   speed, the relative importance of ALTO may dwindle.

Top      Up      ToC       Page 53 
4.1.2.  Applicability of ALTO

   A tracker-based P2P application can leverage ALTO in different ways.
   In the following, the different alternatives and their pros and cons
   are discussed.

                            ,-------.         +-----------+
          ,---.          ,-'         ========>|   Peer 1  |********
       ,-'     `-.      /     ISP 1  V  \     |ALTO Client|       *
      /           \    / +-------------+ \    +-----------+       *
     /    ISP X    \   | + ALTO Server | |    +-----------+       *
    /               \  \ +-------------+<====>|   Peer 2  |       *
   ;   +---------+   :  \               /     |ALTO Client|****** *
   |   | Global  |   |   `-.         ,-'      +-----------+     * *
   |   | Tracker |   |      `-------'                           * *
   |   +---------+   |      ,-------.         +-----------+     * *
   :        *        ;   ,-'         ========>|   Peer 3  |     * *
    \       *       /   /     ISP 2  V  \     |ALTO Client|**** * *
     \      *      /   / +-------------+ \    +-----------+   * * *
      \     *     /    | | ALTO Server | |    +-----------+   * * *
       `-.  *  ,-'     \ +-------------+<====>|   Peer 4  |** * * *
          `-*-'         \               /     |ALTO Client| * * * *
            *            `-.         ,-'      +-----------+ * * * *
            *               `-------'                       * * * *
            *                                               * * * *
            *******************************************************
       Legend:
       === ALTO protocol
       *** Application protocol

             Figure 21: Global Tracker and Local ALTO Servers

   Figure 21 depicts a tracker-based P2P system with several peers.  The
   peers (i.e., resource consumers) embed an ALTO client to improve the
   resource provider selection.  The tracker (i.e., resource directory)
   itself may be hosted and operated by another entity.  A tracker
   external to the ISPs of the peers may be a typical use case.  For
   instance, a tracker like Pirate Bay can serve BitTorrent peers
   worldwide.  The figure only shows one tracker instance, but
   deployments with several trackers could be possible, too.

   The scenario depicted in Figure 21 lets the peers directly
   communicate with their ISP's ALTO server (i.e., ALTO client embedded
   in the peers), thus giving the peers the most control on which
   information they query for, as they can integrate information
   received from one tracker or several trackers and through direct
   peer-to-peer knowledge exchange.  For instance, the latter approach

Top      Up      ToC       Page 54 
   is called peer exchange (PEX) in BitTorrent.  In this deployment
   scenarios, the peers have to discover a suitable ALTO server (e.g.,
   offered by their ISP, as described in [RFC7286]).

   There are also tracker-less P2P system architectures that do not rely
   on centralized resource directories, e.g., unstructured P2P networks.
   Regarding the use of ALTO, their deployment would be similar to
   Figure 21, since the ALTO client would be embedded in the peers as
   well.  This option is not further considered in this memo.

                                 ,-------.
          ,---.               ,-'         `-.   +-----------+
       ,-'     `-.           /     ISP 1     \  |   Peer 1  |********
      /           \         / +-------------+ \ |           |       *
     /    ISP X    \   ++====>| ALTO Server |  )+-----------+       *
    /               \  ||   \ +-------------+ / +-----------+       *
   ; +-----------+   : ||    \               /  |   Peer 2  |       *
   | |  Tracker  |<====++     `-.         ,-'   |           |****** *
   | |ALTO Client|   |           `-------'      +-----------+     * *
   | +-----------+<====++        ,-------.                        * *
   :        *        ; ||     ,-'         `-.   +-----------+     * *
    \       *       /  ||    /     ISP 2     \  |   Peer 3  |     * *
     \      *      /   ||   / +-------------+ \ |           |**** * *
      \     *     /    ++====>| ALTO Server |  )+-----------+   * * *
       `-.  *  ,-'          \ +-------------+ / +-----------+   * * *
          `-*-'              \               /  |   Peer 4  |** * * *
            *                 `-.         ,-'   |           | * * * *
            *                    `-------'      +-----------+ * * * *
            *                                                 * * * *
            *                                                 * * * *
            *********************************************************
       Legend:
       === ALTO protocol
       *** Application protocol

      Figure 22: Global Tracker Accessing ALTO Server at Various ISPs

   An alternative deployment scenario for a tracker-based system is
   depicted in Figure 22.  Here, the tracker embeds the ALTO client.
   When the tracker receives a request from a querying peer, it first
   discovers the ALTO server responsible for the querying peer.  This
   discovery can be done by using various ALTO server discovery
   mechanisms [RFC7286] [XDOM-DISC].  The ALTO client subsequently sends
   to the querying peer only those peers that are preferred by the ALTO
   server responsible for the querying peer.  The peers do not query the
   ALTO servers themselves.  This gives the peers a better initial
   selection of candidates, but does not consider peers learned through
   direct peer-to-peer knowledge exchange.

Top      Up      ToC       Page 55 
                      ISP 1  ,-------.         +-----------+
           ,---.          +-------------+******|   Peer 1  |
        ,-'     `-.      /|   Tracker   |\     |           |
       /           \    / +-------------+****  +-----------+
      /    ISP X    \   |       ===       | *  +-----------+
     /               \  \ +-------------+ / *  |   Peer 2  |
    ;   +---------+   :  \| ALTO Server |/  ***|           |
    |   | Global  |   |   +-------------+      +-----------+
    |   | Tracker |   |      `-------'
    |   +---------+   |                        +-----------+
    :        *        ;      ,-------.         |   Peer 3  |
     \       *       /    +-------------+  ****|           |
      \      *      /    /|   Tracker   |***   +-----------+
       \     *     /    / +-------------+ \    +-----------+
        `-.  *  ,-'     |       ===       |    |   Peer 4  |**
           `-*-'        \ +-------------+ /    |           | *
             *           \| ALTO Server |/     +-----------+ *
             *            +-------------+                    *
             *        ISP 2  `-------'                       *
             *************************************************
        Legend:
        === ALTO protocol
        *** Application protocol

      Figure 23: Local Trackers and Local ALTO Servers (P4P Approach)

   There are some attempts to let ISPs deploy their own trackers, as
   shown in Figure 23.  In this case, the client cannot get guidance
   from the ALTO server other than by talking to the ISP's tracker,
   which in turn communicates with the ALTO server using the ALTO
   protocol.  It should be noted that the peers are still allowed to
   contact other trackers operated by entities other than the peer's
   ISP, but in this case they cannot benefit from ALTO guidance.

4.2.  Deployment Recommendations

4.2.1.  ALTO Services

   The ALTO protocol specification [RFC7285] details how an ALTO client
   can query an ALTO server for guiding information and receive the
   corresponding replies.  In case of peer-to-peer networks, two
   different ALTO services can be used: the cost map service is often
   preferred as solution by peer-to-peer software implementors and
   users, since it avoids disclosing peer IP addresses to a centralized
   entity.  Alternatively, network operators may have a preference for
   the ECS, since it does not require exposure of the network topology.

Top      Up      ToC       Page 56 
   For actual use of ALTO in P2P applications, both software vendors and
   network operators have to agree which ALTO services to use.  The ALTO
   protocol is flexible and supports both services.  Note that for other
   use cases of ALTO, in particular in more controlled environments,
   both the cost map service and the ECS might be feasible; it is more
   of an engineering trade-off whether to use a map-based or query-based
   ALTO service.

4.2.2.  Guidance Considerations

   As explained in Section 4.1.2, for a tracker-based P2P application,
   there are two fundamentally different possibilities where to place
   the ALTO client:

   1.  ALTO client in the resource consumer ("peer")

   2.  ALTO client in the resource directory ("tracker")

   Both approaches have advantages and drawbacks that have to be
   considered.  If the ALTO client is in the resource consumer
   (Figure 21), a potentially very large number of clients has to be
   deployed.  Instead, when using an ALTO client in the resource
   directory (Figures 22 and 23), ostensibly peers do not have to
   directly query the ALTO server.  In this case, an ALTO server could
   even not permit access to peers.

   However, it seems to be beneficial for all participants to let the
   peers directly query the ALTO server.  Considering the plethora of
   different applications that could use ALTO, e.g., multiple-tracker-
   based or non-tracker-based P2P systems or other applications
   searching for relays, this renders the ALTO service more useful.  The
   peers are also the single point having all operational knowledge to
   decide whether to use the ALTO guidance and how to use the ALTO
   guidance.  For a given peer, one can also expect that an ALTO server
   of the corresponding ISP provides useful guidance and can be
   discovered.

   Yet, ALTO clients in the resource consumer also have drawbacks
   compared to use in the resource directory.  In the following, both
   scenarios are compared more in detail in order to explain the impact
   on ALTO guidance and the need for third-party ALTO queries.

   In the first scenario (see Figure 24), the peer (resource consumer)
   queries the tracker (resource directory) for the desired resource
   (F1).  The resource directory returns a list of potential resource
   providers without considering ALTO (F2).  It is then the duty of the
   resource consumer to invoke ALTO (F3/F4), in order to solicit
   guidance regarding this list.

Top      Up      ToC       Page 57 
   Peer w. ALTO cli.            Tracker               ALTO Server
   --------+--------       --------+--------       --------+--------
           | F1 Tracker query      |                       |
           |======================>|                       |
           | F2 Tracker reply      |                       |
           |<======================|                       |
           | F3 ALTO protocol query                        |
           |---------------------------------------------->|
           | F4 ALTO protocol reply                        |
           |<----------------------------------------------|
           |                       |                       |

   ====  Application protocol (i.e., tracker-based P2P app protocol)
   ----  ALTO protocol

                Figure 24: Basic Message Sequence Chart for
                  Resource-Consumer-Initiated ALTO Query

   In the second scenario (see Figure 25), the resource directory has an
   embedded ALTO client, which we will refer to as Resource Directory
   ALTO Client (RDAC) in this document.  After receiving a query for a
   given resource (F1), the resource directory invokes the RDAC to
   evaluate all resource providers it knows (F2/F3).  Then, it returns
   a, possibly shortened, list containing the "best" resource providers
   to the resource consumer (F4).

         Peer               Tracker w. RDAC           ALTO Server
   --------+--------       --------+--------       --------+--------
           | F1 Tracker query      |                       |
           |======================>|                       |
           |                       | F2 ALTO cli. p. query |
           |                       |---------------------->|
           |                       | F3 ALTO cli. p. reply |
           |                       |<----------------------|
           | F4 Tracker reply      |                       |
           |<======================|                       |
           |                       |                       |

   ====  Application protocol (i.e., tracker-based P2P app protocol)
   ----  ALTO protocol

    Figure 25: Basic Message Sequence Chart for Third-Party ALTO Query

   Note: The message sequences depicted in Figures 24 and 25 may occur
   both in the target-aware and the target-independent query mode (cf.
   [RFC6708]).  In the target-independent query mode, no message
   exchange with the ALTO server might be needed after the tracker

Top      Up      ToC       Page 58 
   query, because the candidate resource providers could be evaluated
   using a locally cached "map", which has been retrieved from the ALTO
   server some time ago.

   The first approach has the following problem: While the resource
   directory might know thousands of peers taking part in a swarm, the
   list returned to the resource consumer is usually shortened for
   efficiency reasons.  Therefore, the "best" (in the sense of ALTO)
   potential resource providers might not be contained in that list
   anymore, even before ALTO can consider them.

   Much better traffic optimization could be achieved if the tracker
   would evaluate all known peers using ALTO.  This list would then
   include a significantly higher fraction of "good" peers.  If the
   tracker returned "good" peers only, there might be a risk that the
   swarm might disconnect and split into several disjunct partitions.
   However, finding the right mix of ALTO-biased and random peer
   selection is out of the scope of this document.

   Therefore, from an overall optimization perspective, the second
   scenario with the ALTO client embedded in the resource directory is
   advantageous, because it is ensured that the addresses of the "best"
   resource providers are actually delivered to the resource consumer.
   An architectural implication of this insight is that the ALTO server
   discovery procedures must support third-party discovery.  That is, as
   the tracker issues ALTO queries on behalf of the peer that contacted
   the tracker, the tracker must be able to discover an ALTO server that
   can give guidance suitable for that respective peer (see
   [XDOM-DISC]).

   In principle, a combined approach could also be possible.  For
   instance, a tracker could use a coarse-grained "global" ALTO server
   to find the peers in the general vicinity of the requesting peer,
   while peers could use "local" ALTO servers for a more fine-grained
   guidance.  Yet, there is no known deployment experience for such a
   combined approach.



(page 58 continued on part 4)

Next Section