Internet Engineering Task Force                           H. Seidel, Ed.
Internet-Draft                                               BENOCS GmbH
Intended status: Informational                          October 19, 2015
Expires: April 21, 2016


              ALTO map calculation from live network data
                  draft-seidel-alto-map-calculation-00

Abstract

   This document describes a process to generate ALTO compliant
   information from live network data.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Seidel                   Expires April 21, 2016                 [Page 1]


Internet-Draft            ALTO Map Calculation              October 2015


Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Network Data Collection . . . . . . . . . . . . . . . . . . .   3
     2.1.  Topology Information  . . . . . . . . . . . . . . . . . .   3
     2.2.  Routing Information . . . . . . . . . . . . . . . . . . .   4
     2.3.  Extended Information  . . . . . . . . . . . . . . . . . .   4
     2.4.  Example Network . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Experiences . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Network Data Processing . . . . . . . . . . . . . . . . . . .   7
     3.1.  Topology Graph  . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Router  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Links . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Example Router R2 . . . . . . . . . . . . . . . . . .   8
       3.2.2.  Example Router R8 . . . . . . . . . . . . . . . . . .   9
       3.2.3.  Example Link  . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Experiences . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  ALTO Map Calculation  . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Network Map Calculation . . . . . . . . . . . . . . . . .  11
       4.1.1.  Network Map Example . . . . . . . . . . . . . . . . .  11
       4.1.2.  Experiences . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Cost Map Calculation  . . . . . . . . . . . . . . . . . .  13
       4.2.1.  Cost Map Example  . . . . . . . . . . . . . . . . . .  13
       4.2.2.  Experiences . . . . . . . . . . . . . . . . . . . . .  14
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Overview

   The ALTO protocol is designed to export network information to
   applications that need to select suitable endpoints among a wider set
   of available ones.  However, it does provide details about the
   network information retrieval and processing.

   This document describes a process to generate ALTO network and cost
   maps from live network data and provides experience details about
   that process in a large network.

   The ALTO map generation process comprises three steps.  The first
   step is to gather information which is described in Section 2.
   Subsequently the gathered data is processed which is described in
   Section 3.  The last section defines methods to generate ALTO network
   and cost maps from the processed data.

   In general it is not possible to gather detailed information about
   the whole Internet since it is segmented in many networks and in most




Seidel                   Expires April 21, 2016                 [Page 2]


Internet-Draft            ALTO Map Calculation              October 2015


   cases it is not possible to collect information across network
   borders.  Hence, information sources are limited to the own network.

2.  Network Data Collection

   The first step in the process of generating ALTO network and cost
   maps from live network data is to gather the required information
   from the network.  This comprises at least topology and routing
   information which contain details about present endpoints and their
   interconnection and form the basic dataset.  With this information it
   is possible to compute paths between all known endpoints.  The basic
   dataset can be extended by many other information obtainable from the
   network.

2.1.  Topology Information

   Topology information comprises details about routers and their
   interconnection, also called links, within a network.  Such
   information are provided by various sources.  The most prevalent
   sources are interior gateway protocols (IGPs) which can be divided in
   link-state (e.g.  IS-IS, OSPF) and distance-vector protocols (RIP).
   Most suitable are link-state protocols since every router propagates
   its information throughout the whole network.  Hence, it is possible
   to obtain information about all routers and their neighbors from one
   single router in the network.  In contrast, distance-vector protocols
   are less suitable since routing information is only shared among
   neighbors.  To obtain the whole topology with distance-vector routing
   protocols it is necessary to retrieve routing information from every
   router in the network.

   Since IGPs lack of the possibility to easily steer traffic within the
   network many network operators utilize MPLS to enable custom path
   configuration.  MPLS uses labels to identify configured paths.  These
   labelled paths create an overlay network on top of the actual network
   forming its own virtual topology.  Part of the MPLS architecture is
   the Label Distribution Protocol (LDP) that is used to configure the
   paths and therefore can be used to obtain MPLS topology information.

   With the rise of software-defined networking (SDN) and its
   abstraction of network management achieved by the decoupling of
   network data and control plane network management became easier,
   since the hardware does not require manual configuration anymore.
   This is done by SDN controllers that relay routing information to the
   switches and routers.  So instead of gathering topology information
   from the hardware within the network it can be fetched from SDN
   controller.





Seidel                   Expires April 21, 2016                 [Page 3]


Internet-Draft            ALTO Map Calculation              October 2015


   The data sources mentioned so far are only a subset of potential
   topology sources and depending on the network type, (e.g. mobile,
   satellite network) different hardware and protocols are in operation
   to form and maintain the network.

2.2.  Routing Information

   Routing information comprises details about known endpoints and paths
   in a network.  In general there are two types of protocols, that
   disseminate routing information on the Internet, interior gateway
   (IGP) and exterior gateway protocol (EGP).  While IGPs provide
   details about endpoints and links within the own network, EGPs are
   used to provide details about links to endpoints in foreign networks
   outside of the operation scope of the own network.  A path is
   described by two endpoints and the traversed links.  Routing
   protocols assign metric values to links called link weights which
   represents the cost to send data across a link.  With the knowledge
   about the link weights routing algorithms (e.g.  Bellman-Ford)
   calculate the path through the network for each source-destination
   endpoint pair in the network.

   The most widely-used routing protocols on the Internet are IS-IS,
   OSPF and BGP.  IS-IS and OSPF are IGPs and have already been
   introduced in Section 2.1.  BGP is an EGP based on the distance-
   vector algorithm.  As characteristic for distance-vector protocols,
   it only shares routing information among neighbors.  If no BGP route
   reflector is present that collects routing information from all BGP
   routers it is necessary to pick up that information directly from
   each BGP router in the network.  However, BGP is not only used as EGP
   but also alongside IGPs (iBGP) to distribute known endpoints and the
   corresponding metrics within a network.

   In large real life network deployments such as ISP networks IGPs are
   mainly used to disseminate topology information and link metrics.
   Endpoint information such as subnets and attachment points are mostly
   distributed by (i)BGP.

   The previously mentioned SDN controller of a SDN is also a suitable
   source for routing information.  In general, as with topology details
   the available routing information sources mainly depend on the
   network type.  However, our work focuses on networks using IS-IS or
   OSPF as IGP and BGP as EGP.

2.3.  Extended Information

   Besides topology and routing information which are fundamental to
   know how data between endpoints are exchanged, networks have a
   multitude of other attributes about its state, condition and



Seidel                   Expires April 21, 2016                 [Page 4]


Internet-Draft            ALTO Map Calculation              October 2015


   operation.  That comprises but is not limited to attributes like link
   utilization, bandwidth and delay, ingress/egress points of data flows
   from/towards endpoints outside of the network up to the location of
   nodes and endpoints.  In general, extended information comprises all
   information that a network provides which does not belong to topology
   or routing.  Typical sources are SNMP, Netflow or an operations
   support system (OSS).

2.4.  Example Network

   Figure 1 depicts a network which is used to explain the steps carried
   out in the course of this document.  The network consists of nine
   routers (R1 to R9) whereat 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, hence a /30 subnet is sufficient for each.  These
   connections also form the core network which we assigned the
   100.1.1.0/24 subnet.  This subnet is large enough to provide /30
   subnets 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
   is a /24 subnet with 100.1.10x.0 (x = [1..5]) as network address.

   The example network utilizes two different routing protocols, one for
   IGP and another for EGP routing.  The used IGP is a link-state
   protocol (IS-IS).  The applied link weights are shown in Figure 2.
   To obtain the topology and routing information from the network the
   ALTO server must be connected directly to one of the routers
   (R1...R9), Furthermore, the server must be enabled to communicate
   with the router and vice versa.

   The applied EGP in the network is the border gateway protocol (BGP),
   which is used to route between autonomous systems (AS).  So, 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.  Hence it is running on every router with an
   attached client network (R2, R5, R6, R7 and R9).  If no route
   reflector is present it is necessary to fetch routes from each BGP
   router separately.  Otherwise, only one connection to route reflector
   is sufficient to obtain all routes.

   For monitoring purposes, SNMP is enabled on all routers within the
   network.  Thus, using SNMP an ALTO server is capable to obtain
   several additional information about the state of the network.  In
   this example, utilization, latency and bandwidth information are
   retrieved periodically via SNMP from the network components to get
   and keep an up-to-date view on the network situation.



Seidel                   Expires April 21, 2016                 [Page 5]


Internet-Draft            ALTO Map Calculation              October 2015


   +--------------+      +--------+      +--------+     +--------------+
   |100.1.102.0/24+------+   R6   |      |   R7   +-----+100.1.103.0/24|
   +--------------+      +----+---+      +----+---+     +--------------+
                              |               |
   +--------------+           |               |
   |     AS 2     |           |               |
   | 100.2.0.0/16 |           |               |
   +-------+------+           |               |
           |                  |               |
           |                  |               |
       +---+----+        +----+---+      +----+---+     +--------------+
       |   R1   +--------+   R3   +------+   R5   |-----+100.1.104.0/24|
       +---+----+        +----+---+      +----+---+     +--------------+
           |     \      /     |               |
           |      \    /      |               |
           |       \  /       |               |         +--------------+
           |        \/        |               |         |     AS 4     |
           |        /\        |               |         | 100.4.0.0/16 |
           |       /  \       |               |         +------+-------+
           |      /    \      |               |                |
           |     /      \     |               |                |
       +---+----+        +----+---+      +----+---+     +------+-------+
       |   R2   |        |   R4   |      |   R8   +-----+     AS 3     |
       +---+----+        +----+---+      +----+---+     | 100.3.0.0/16 |
           |                  |               |         +--------------+
           |                  |               |
           |                  |               |
   +-------+------+           |          +----+---+     +--------------+
   |100.1.101.0/24|           +----------+   R9   +-----+100.1.105.0/24|
   +--------------+                      +--------+     +--------------+

                         Figure 1: Example Network

           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 2: Example Network Link Weights

   In summary, the following information are collected from the network:




Seidel                   Expires April 21, 2016                 [Page 6]


Internet-Draft            ALTO Map Calculation              October 2015


   IS-IS:  topology, Link weights

     BGP:  prefixes, AS numbers, AS distances, metrics

    SNMP:  latency, utilization, bandwidth

2.5.  Experiences

   To be able to retrieve the information presented in this chapter we
   implemented many of the mentioned protocols.  While connecting to the
   different data source we faced behavior that was different than we
   anticipated from our interpretation 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.

3.  Network Data Processing

   Due to the variety of data source available in today's network it is
   necessary to aggregate the information and define a suitable data
   model that can hold it efficiently and easily accessible.  The most
   suitable model is an annotated directed graph, since it perfectly
   fits to represent topology and the attributes can be annotated at the
   corresponding positions in the graph itself.  More details about the
   topology graph are provided in the following section.

3.1.  Topology Graph

   The topology graph is the data model that represents the surveyed
   network.  The node of the graph represents the routers in the network
   while the edges stand for the links that connect the routers.  Both
   routers and links have a set of attributes that holds information
   gathered from the network.

3.1.1.  Router

   The routers connect the different segments of the network.  Each
   router holds a basic set of information which are described in the
   upcoming list:

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

   Neighbor IDs:  List of directly connected routers.

   Endpoints:  List of connected endpoints.  The endpoints can 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.  Be aware



Seidel                   Expires April 21, 2016                 [Page 7]


Internet-Draft            ALTO Map Calculation              October 2015


      that endpoints can belong to more than one router, for example
      when they are assigned to link interfaces.

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

3.1.2.  Links

   A link is a unidirectional connection between two routers.  The basic
   information set hold by a link is described in the following list:

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

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

   Weight:  The cost to cross the link 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.  Even
   the link cable color is a possible attribute, even though its sense
   is doubtful.

3.2.  Example

   Picking up the example from Section 2.4 the example network shown in
   Figure 1 already represents the layout of our internal network graph
   where the routers R1 to R9 represent the nodes and the connections
   between them are the links.

3.2.1.  Example Router R2

   ID:  2

   Neighbor IDs:  1,3 (R1, R3)

   Endpoints:

      Endpoint:  100.1.101.0/24

      Metric:  10 (default client subnet metric)

      ASNumber:  1 (our own AS)




Seidel                   Expires April 21, 2016                 [Page 8]


Internet-Draft            ALTO Map Calculation              October 2015


      ASDistance:  0

   Host Name:  R2

   R2 has one directly attached IPv4 endpoint that belongs to its own
   AS.

3.2.2.  Example Router R8

   ID:  8

   Neighbor IDs:  5,9 (R5, R9)

   Endpoints:

      Endpoint:  100.3.0.0/16

      Metric:  100

      ASNumber:  3

      ASDistance:  1

      Endpoint:  100.4.0.0/16

      Metric:  200

      ASNumber:  4

      ASDistance:  2

   Host Name:  R8

   R8 has two attached IPv4 endpoints.  The first one belongs to a
   directly neighbored AS with AS number 3.  So 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.

3.2.3.  Example Link

   The collectable link attributes are equal for all links and only
   their values differ.  The attributes utilization, bandwidth and
   latency collected via SNMP where added to the existing example from
   Section 2.4.  Taking the links between R1 and R2 as example, we get
   the following link attributes:




Seidel                   Expires April 21, 2016                 [Page 9]


Internet-Draft            ALTO Map Calculation              October 2015


   R1->R2:

   Source ID:  1

   Destination ID:  2

   Weight:  15

   Bandwidth:  10Gbit/s

   Utilization:  0.1

   Latency:  2ms

   R2->R1:

   Source ID:  2

   Destination ID:  1

   Weight:  15

   Bandwidth:  10Gbit/s

   Utilization:  0.55

   Latency:  5ms

   Since the values for utilization and latency are very volatile the
   presented values are only exemplary.

3.3.  Experiences

   Processing network information is very complex with a high demand in
   resources.  Gathering information from an autonomous system connected
   to Internet means the software and machine must be able to store and
   process hundreds of thousands of prefixes, several hundreds of
   megabytes of Netflow information per minute, information from
   hundreds of routers and attributes of thousands of links.  Hence, a
   lot of disk memory, RAM and CPU cycles as well as efficient
   algorithms are required to process the information as they come in.

4.  ALTO Map Calculation

   The goal of the ALTO map calculation process is to get from the graph
   presentation of the network as described in Section 3 to a coarse-
   grained matrix presentation.  The first step is to generate the




Seidel                   Expires April 21, 2016                [Page 10]


Internet-Draft            ALTO Map Calculation              October 2015


   network map.  Only after the network map has been generated it is
   possible to compute the cost map since it relies on the network map.

4.1.  Network Map Calculation

   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
   algorithm can utilize all information provided by the network graph
   to perform the grouping.  The functions may omit certain endpoints to
   simplify the map or to hide details about the network that are not
   intended to be published with the resulting ALTO network map.

   For IP endpoints which is either an IP (version 4 or version 6)
   address or prefix, [RFC7285] requires the use of longest-prefix
   matching algorithm (Section 5.2.4.3 [RFC1812]) to map IPs to PIDs.
   This requirement yields the constraints that every IP must be mapped
   to a PID and that the same prefix or address is not 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 since it
   assigns endpoints to PIDs, so in case of collision the grouping
   function must decide which PID get the endpoint.  Be aware that these
   or even other constraints may apply to other endpoint types depending
   on the used matching algorithm.

4.1.1.  Network Map Example

   A simple example on how such grouping can work is to group per host
   name from our network graph.  Each router host name is the name for a
   PID and and the attached endpoints are the member endpoints of the
   corresponding router PID.  Additionally backbone prefixes should not
   appear in the map so they are filtered out.  The following table
   shows the resulting ALTO network map based on the example network
   from Section 2.4:














Seidel                   Expires April 21, 2016                [Page 11]


Internet-Draft            ALTO Map Calculation              October 2015


       PID  |  Endpoints
   ---------+-----------------------------------
        R1  |  100.2.0.0/16
        R2  |  100.1.101.0/24
        R5  |  100.1.104.0/24
        R6  |  100.1.102.0/24
        R7  |  100.1.103.0/24
        R8  |  100.3.0.0/16, 100.4.0.0/16
        R9  |  100.1.105.0/24
    default |  0.0.0.0/0, ::/0

                    Figure 3: 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.

4.1.2.  Experiences

   Large IP based networks consist of hundreds of thousands of prefixes
   which are 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 are in the same PID.
   However, it cannot be ruled out that the large prefix is assigned to
   another PID.  This MUST BE checked and it is up to the grouping
   function whether it merges the prefixes and removes the larger prefix
   from the other PID or not.  A simple example, when a PID comprises
   the prefixes 192.168.0.0/24 and 192.168.1.0/24 it can easily merge
   them to 192.168.0.0/23.

   Second, a prefix and its next-longer-prefix match are 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 192.168.0.0/22 and 192.168.1.0/24 and the /22 is the
   next-longer prefix match of the /24, the /24 prefix can simply be
   removed.  In contrast, if another PID contains the 192.168.0.0/23
   prefix 192.168.1.0/24 cannot be removed since the next-longer prefix
   is not in the same PID anymore.





Seidel                   Expires April 21, 2016                [Page 12]


Internet-Draft            ALTO Map Calculation              October 2015


4.2.  Cost Map Calculation

   After successfully creating the network map, the next step is to
   calculate the costs between the PIDs, which forms the cost map.
   Those costs are calculated by cost functions which use the
   information provided by the network graph described in Section 3.
   Cost function calculate values unidirectional which means that 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 subnet the cost function calculates a set of cost
   values for each source/destination IP pair.  In that case a tie-
   breaker function is required which decides the resulting cost value.
   Such tie-breaker can be simple functions such as minimum, maximum or
   average value.

   Be aware, no matter what metric the cost function is using, the path
   from source to destination is defined by the minimum path weight.
   The path weight is the sum of link weights of all traversed links.
   Usually, the path is determined with the Bellman-Ford or Dijkstra
   algorithm.  Hence, the cost function must first determine the path
   before it can determine any other metric value.  As a result, the
   metric value can differ from the expectation where the path with the
   shortest path weight was not considered.  But it is also possible
   that more than one path with the same minimum path weight exist,
   which means it is not entirely clear which path is going to be
   selected by the network.  Hence, a tie-breaker 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 other PID pairs for arbitrary reasons.  Such pairs MAY BE defined
   before the cost calculation is performed and should be respected in
   the calculation process even though cost values are computable.

   There is an active internet draft [I-D.yang-alto-path-vector] that
   proposes vector based cost maps rather then the current point-to-
   point matrix.  A vector representation can reduce the required
   computation to generate cost maps from a directed graph as proposed
   in Section 3.

4.2.1.  Cost Map Example

   Based on the network map generated in Section 4.1.1 it is possible to
   calculate the cost maps.  In this example the chosen metric for the
   cost map is the minimum number of hops necessary to get from source



Seidel                   Expires April 21, 2016                [Page 13]


Internet-Draft            ALTO Map Calculation              October 2015


   to destination PID.  Our chosen tie-breaker selects the minimum hops
   when more than one value is returned by the cost function.

      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 4: Example ALTO Hopcount Cost Map

   Interesting to mention is, 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 our minimum value
   tie-breaker 3 hops for the path R1->R4->R9 is chosen as value.
   Furthermore, since the "default" PID is sort of virtual PID with no
   endpoints that are part of the example network no cost values are
   calculated for other PIDs from or towards it.

4.2.2.  Experiences

   The major challenge we encountered with cost map calculations was the
   vast amount of CPU cycles that where required to calculate the costs
   in large networks.  The issue was that the costs were calculated
   between the endpoints of each source-destination PID pair.  However,
   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.  So instead, we looked 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.

5.  Informative References

   [I-D.yang-alto-path-vector]
              Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y.
              Yang, "ALTO Extension: Abstract Path Vector as a Cost
              Mode", draft-yang-alto-path-vector-01, July 2015.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
              Simple Network Management Protocol (SNMP)", RFC 1157, May
              1990.





Seidel                   Expires April 21, 2016                [Page 14]


Internet-Draft            ALTO Map Calculation              October 2015


   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC2328]  Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [RFC7285]  Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
              Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
              Traffic Optimization (ALTO) Protocol", RFC 7285, September
              2014.

   [RFC7607]  Kumari, W., Bush, R., Schiller, H., and K. Patel,
              "Codification of AS 0 Processing", RFC 7607, August 2015.

Author's Address

   Hans Seidel (editor)
   BENOCS GmbH

   Email: hseidel@benocs.com





















Seidel                   Expires April 21, 2016                [Page 15]