Hi Dr. Yang

I am interested to work on ALTO on ONOS. I'm new to both. Please feel free to direct me to study necessary materials and keep me involved in the discussion and implementation.

Is there an ALTO project for ONOS that I can start playing around? Are we trying to solve any specific problem on ONOS that was not addressed in the ALTO ODL app? It looked like ONOS is a distributed controller, so I guess, that's something new that was not in ODL. Looking forward to your suggestions.

About me: I am a graduate student of Kent State University. I worked as a software engineer for five years. I'm interested to solve practical networking problems using SDN. Please let me know any question.

Thanks

Tamim

On Mon, Jul 13, 2015 at 6:23 PM, Y. Richard Yang <yry@...> wrote:

Dear all,

As IETF'93 is coming soon, it is good time to get some discussion started first so that we may continue at Prague. 

One issue is the relationship between ALTO and SDN. I want to start this thread not only because SDN is a hot topic or ALTO/SDN are two of my main interests recently. More importantly, I feel that a better understanding of ALTO and SDN can help with the future direction of ALTO. This email is not intended to be complete, but more is to get the conversation started.

A good point of the discussion is our experiences in implementing ALTO in OpenDaylight (ODL). A small background digression. A basic version of ALTO has been implemented in the ODL Lithium release. We plan to participate in the next ODL release as well, to add substantial new features, such as incremental updates (Wendy's SSE design), routing state abstraction using declarative equivalence, and automatic map generations. We are also starting the integration of ALTO to ONOS soon. In you are interested in joining such design and development, please let us know. 

Now, what are some key lessons/issues that we have learned in this ALTO/SDN? 

First, a key benefit to ALTO is that it can construct its views from its access to a centralized state of the network provided by SDN. As a basic case, in the current ALTO/ODL implementation, the ALTO server uses l2switch, which is a project in ODL that collects all active endhosts in the network, to construct a dynamic network with two PIDs: internal (for those in the network) and external (for those not). A default cost map is constructed so that  internal <-> external has higher routing costs. As endhosts being collected or pruned from the network state, the ALTO server is notified by ODL's event system automatically, and ALTO's event handler updates the network map automatically. It will be great exercise to push this direction more, for example, by constructing more interesting, network-state maps and endpoint cost services (ECS).

If we say the basic case is what SDN can do for ALTO, the next is what ALTO can do for SDN. In particular, we have extended the path vector proposal substantially to design the new ALTO service called routing state abstraction using declarative equivalence (RSADE); see see http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf

We feel that the RSADE service will be a very valuable abstraction service for SDN.

Now, some issues and questions that have become more obvious in the process:

- ALTO maps are endhosts based, but SDN allows more fine-grained routing, e.g., routing depending on ports. How do we handle this?

- From the beginning, ALTO's charter limits it to be a network-state-read-only protocol. SDN allows one to "write" a network's state. Suppose we have a general SDN/ALTO environment, for applications such as large-data transfer (e.g., the multi-flow use case, big data), how can such applications use both the ALTO channel and the SDN write channel?

Let me keep this email short and stop here, so that we may have some good discussions, on the mailing list and/or at the Prague meeting.

Cheers,

Richard

 

_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev