Hi all,
Sorry to spam the list with one more work-in-progress update email. But
since it is an important, chartered task of the WG, we would like to hear
your feedback and invite more to be involved to work together.
The openalto.org team has two main objectives: (1) design and implement a
high-quality, open-source implementation of ALTO server; and (2) integrate
openalto.org with real application use cases. We plan to provide detailed
updates during the coming IETF'115 ALTO meeting in 3 weeks on Nov. 11 and
this email is to provide a quick overview of progress and thinking. The
openalto implementation and use cases are complementary to the
implementation and use cases by others such as the wonderful project at
Telefonica by Luis.
First, on (1), at the surface, ALTO only defines an interface, and the true
complexity and value of an ALTO server implementation is the process
of obtaining the information resources for an ALTO server to expose. The
current openalto implementation focuses on providing 3 types of
implementations: (A1) from configuration, adjacency, and other input such
as BGP inputs, (A2) from reading FIB directly, and (A3) from available
sampling FIB (e.g., s-flow/netflow report, traceroute essentially sampling
by ttl and ICMP report). So far good process has been made for A2 (for
looking glass for CERN and others) and A3 (based on s-flow, and others, on
top of G2 led by Jordi and Sruthi). There are also efforts to make progress
on A1, using batfish and there is ongoing work to apply the approach to
ESnet.
Building on the progress of having many ALTO servers running, the openalto
team includes a new effort to organize the existing ALTO servers. Although
there are existing ALTO server discovery mechanisms, openalto.org will now
serve as a frontend to many servers which will become available soon. One
major departure of this approach from the original ALTO thinking is that
openalto allows multiple ALTO servers to serve a single network. Hence,
openalto.org is organized as a structure motivated by the DNS structure, as
..openalto.org. For example, as513.lg.openalto.org is the
ALTO server for entity AS513 (CERN) implemented by A3 (Looking Glass
server) domain. Hence, the deployment structure is an overlay structure,
with base servers that can be overridden by authoritative servers. We feel
that this is a great way to go.
In addition to serving as a hub of network composition, the current
openalto.org will also serve as a frontend to provide a unified query
interface to existing networking information. An example that will be
deployed is to make ALTO a frontend to geoip data, in the domain of
geoip.openalto.org.
For (2), the current focus of openalto is for two applications: the
application-layer scheduling integration into FTS, which is the main
scheduling system at LHC and many others; and Rucio, which is the transfer
selection/data orchestration framework. For FTS, openalto provides the
important assets that a transfer utilizes and then the scheduler, which
knows the app and the amount of data transferred, can conduct
application-level resource partition among multiple application-level
entities (experiments/projects/activities). For Rucio, openalto provides
distance (cost map) as a unifying abstraction, including FTS distance, to
guide the transfer selection. These use cases are different from other use
cases such as those described by Luis.
We welcome feedback and broad participation. Please let us know if you can
help.
Thanks,
The openalto team
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
