Subject: [alto] ALTO in an SDN environment

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 14 Jul 2015 06:23:22 +0800

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

---

From: tony <[email-masked]>
Date: Tue, 14 Jul 2015 12:44:17 +0800

Hi all,

I am quite interested in the second one that how the application influences ALTO through SDN. Assume that there are several paths for data transfer computed initially at SDN controller, and path can not be set anymore after even the network becomes congested. Then applications decide how to schedule data transfer along these paths. When the result computed by applications submitted to SDN controller, the controller sets rules for these flows. Finally, ALTO server collects the current network state, and finds the cost has been updated.

However, it would become complex when the SDN controller can set new paths for applications requirements. The controller can move the data flows from the original path to the new one, or only makes new data flows transmit through new paths. Both would affect the cost in ALTO server. 

I would like to focus on this problem these days.

Xin
> On Jul 14, 2015, at 6:23 AM, Y. Richard Yang <[email-masked]> 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 <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.
> 
> - 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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 15 Jul 2015 00:25:04 +0800

I was asked to elaborate a bit more on the paragraph below. So here it is.

> can such applications use both the ALTO channel and the SDN write channel?

Imagine a centralized control plane that can coordinate the data transfers.
Applying divide-and-conquer, we can see three key modules:

M1: Endpoint (resource) selection: A receiver may have a set of candidate
senders and can choose one (or multiple and then conduct reassembly);  A
sender may have multiple receivers to choose from as well.

M2: Routing: Given a sender and a receiver, what is the path (or are the
paths) of the packets from the sender to the receiver?

M3: Rate allocation: What is the transmission rate from a sender to a
receiver? We assume no multicast.

To see how each module is implemented by network and/or by application,
consider what is network state. In a current, typical OF setting, the
network switches will have flow tables and ovsdb, which implement routing
(M2) and queueing (M3). Hence, we have the following implementation options:
M1: app
M2: net
M3: app and/or net

So far, the main focus of ALTO is on providing info from network to app for
the app to implement M1. The recent effort on path vector starts to help
providing  info from network to app for the app to implement M3.

Now, suppose SDN becomes widely used, and hence app may have an
(north-bound) API to influence M2 (e.g., a first API might be PCEP like
API). This will create control feedback, and hence a key issue for ALTO
then is what the interactions might look like. IETF does not define
algorithms but can provide guidance on the architecture.

Cheers,
Richard