This group is locked. No changes can be made to the group while it is locked.
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:
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:
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.