Hi all,
For anyone who is interested in playing around or participating in the
development/deployment of the openalto project, here is a brief introduction to
the code base. We will post further information such as the architecture and
how to install/deploy the server to the mailing list as well.
The openalto project is open source and accessible from
https://github.com/openalto/alto. The source code is released under the MIT
license. For fast development and deployment, the project is using Python as
the programming language.
The main components of the project and their code structure are organized as
follows:
- ALTO client library: The client library wraps the ALTO requests and provides
some high level APIs. The source code is under src/alto/client. Currently the
client library supports the parsing of network map, cost map and endpoint cost
service with path vector extension.
- ALTO data broker: The data broker provides API to connect to and access data
from a data base (which is redis in our current development/deployment). It
serves as a middle layer to decouple ALTO service implementations and data
sources.
- ALTO server frontend: We use the django framework as the server frontend,
which handles the parsing of requests and the encoding of responses. The code
is mainly under src/alto/server/django_server. Currently it supports the
network map, cost map, and endpoint cost service with the path vector extension.
- ALTO server backend: A backend component is basically an algorithm that reads
data from the data broker and generates data (as python objects) that can be
further encoded by the frontend. Currently the project supports the endpoint
cost service with the path vector extension. The source code is at
src/alto/server/backend.py.
- ALTO agents: An ALTO agent is configued to connect to one or multiple data
sources. It collects the data from the data source(s) either in the pull or
push mode. Then it writes the data to the data base that can be consumed by the
backends. We have developed some agents already, under src/alto/agent. For
example, in the CERN deployment, we have developed an agent to fetch
information from the CRIC database and an agent to periodically fetch the
routing information from the CERN looking glass server.
This is only an overview of the project and we will post more technical details
soon. Please feel free to reply to this thread if you have any questions or
comments.
Best,
The openalto team
-----Original Messages-----
From:"Y. Richard Yang" <[email protected]>
Sent Time:2022-10-22 05:03:04 (Saturday)
To: "IETF ALTO" <[email protected]>, "Jensen Zhang" <[email protected]>,
"Kai Gao" <[email protected]>, "Lauren Delwiche" <[email protected]>,
"Jordi Ros Giralt" <[email protected]>, "Martin Duke"
<[email protected]>, "Qin (Bill) Wu" <[email protected]>, "Mohamed
Boucadair" <[email protected]>
Cc:
Subject: openalto.org updates
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
<entity>.<domain>.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
[email protected]
https://www.ietf.org/mailman/listinfo/alto
