Re: ALTO in an SDN environment

Y. Richard Yang

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

On Tue, Jul 14, 2015 at 6:23 AM, Y. Richard Yang <yry@...> wrote:
- 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?

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.


Join to automatically receive all group messages.