[alto] ALTO Topology Use Cases

[Greg Bernstein <[e-mail]>]

Hi fellow ALTOers. It seems appropriate to revisit the ALTO topology use 
cases in a systematic fashion as it seemed the last time we did this was 
in 2012. In the following I focus on bandwidth considerations, since 
these can introduce mutual constraints among flows and were the original 
motivation for our ALTO topology work.

It seems useful to introduce the concepts of “source-destination” 
/choice/ made by the client and of “path” /choice/ which may or may not 
be supported by the network to help discern various use cases. Let me 
know if this breakdown is helpful. At the end I give a quick 
review/summary of the “path” and “graph” representations.

Cheers

Greg B.


    ALTO Topology Use Cases

 1.

    Single or Multiple Paths between a given Source and Destination

     1.

        Underlying technology only supports single path at a time
        between source and destination. For example IP, single spanning
        tree ethernet bridging.

     2.

        Underlying network supports multiple paths between source and
        destination. For example MPLS, GMPLS, SDN.

         1. Provider offers /path choice/ as a service. This is a form
            of /network virtualization/. Emerging SDN scenario.
 2.

    Numbers and Choices of Sources and Destinations

     1.

        Single source and Single destination
        Bandwidth between source and destination is a well defined
        notion. If network supports path choice then either
        “path-vector” or “graph” representation can be used mutual
        bandwidth constraint information isn’t needed since we only have
        one flow.

     2.

        Single source and Multiple destinations simultaneously
        Bandwidth between a single source and multiple destinations is
        not well defined since we can have shared bottlenecks between
        paths. Knowing this information in the case with no path choice
        maybe useful for adjusting sending rates. If given path choice
        one can optimize chosen paths.

     3.

        Single source, choice of one or more destinations out of a
        larger pool of destinations.

        This is almost a classic ALTO scenario with additional bandwidth
        information. Does not require mutual constraint information
        since only one flow. In path choice case multiple paths could
        allow for delay vs. bandwidth or other trade offs.

     4.

        Multiple sources and Multiple destinations simultaneously

        Like cases 1. and 2. for no path choice. But with path choice
        mutual bandwidth constraints are important for optimization.

     5.

        Choices of multiple source-destination pairs from a pool of
        possible sources and destinations.

        Even with no path choice mutual bandwidth information is key to
        the selection of optimum source-destination pairs. In case with
        path-choice we may prefer “graph” representation over
        “path-vector” which may need to furnish an abundance of possible
        paths.

 3.

    Choice of Bandwidth Constraint Representation

     1.

        “Path-Vector”: here we represent a path between a source and
        destination in terms of a list of “abstract” links. We associate
        bandwidth constraints with this abstract links so that the ALTO
        client can understand the mutual bandwidth constraints between
        paths. In networks where path choice is supported one may need
        give a large number of paths between a given source and
        destination to support good optimization. Note that our use of
        the term “path-vector” is particular to ALTO topology discussions.

     2.

        “Graph”: Here we present an “abstraction” of the network in
        terms of nodes and links. With the links having capacity
        constraints. Client would obtain paths based on criteria
        furnished from the network (no path choice) or its own criteria
        (path choice). In the case of path choice the network would be
        responsible for taking a path request and realizing it (network
        virtualization implementation).

     3.

        If multiple choices how well does provider understand clients
        application? If very well (or network simple) then lists of
        possible paths with mutual constraints (“path vector”) can be
        sufficient if not very well or the network is very meshy then a
        graph representation is better.

​