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.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
