Subject: Re: [Sdn] Agenda items for Vancouver?

From: Zoltán Lajos Kis <[email-masked]>
Date: Thu, 21 Jun 2012 19:02:37 +0200

Hi,

I'd also drop in some items that might be of interest. I guess they are mostly covered by the listed areas...

Gather the potential benefits of SDN as compared to the current distributed and layered control planes. Identify the domains and/or use-cases, where those are applicable or not.
- Separation of control and forwarding topology. (centralized calculations, abstracting subnetworks as nodes for the distributed control plane, ...)
- Cross-layer/flattened packet processing. (deep packet inspection and fine grained steering in the core, ...)
- Software-definedness. (faster innovation, evolution, easier network planning, testing, ...)

Hierarchical control architectures, where the hierarchy is not based on network layers or technologies (but on topology, on administrative domains, on event rates, ...).
- Composing a sub-network into a virtul network node for upper levels. Either in a managed manner, or on-the-fly based on network policies (think self-* and ambient-*).
- Define a model for delegating responsibilites/tasks in a software defined manner, e.g. by pushing processing states (e.g., state-machines) to lower layers. This can potentially reach all the way to the southbound interface, where the controller could push stateful processing to the datapath nodes (which is something missing from e.g., OpenFlow).
- Look at possible ways to extend such delegation of tasks to between the SDN and the traditional control planes, creating integrated hybrid networks. 
- Collect the requirements on a controller-internal interface for the above. (This might end up being the same as the southbound interface?)

Study current distributed protocols, dissect them into components, and see how those map into SDN-based solutions. Current control protocols are well designed complex systems,
consisting of a number of components highly-dependent on each other: a database model with consistency requirements, a data distribution scheme, failure detection, distributed
calculations, .... Current SDN solutions seem to only focus on centralizing the calculation, while taking a consistent database a given (and completely ignoring failure detection).

Kind Regards,
Zoltan.

---

From: Dirk Kutscher <[email-masked]>
Date: Sat, 23 Jun 2012 11:11:07 +0000

Hi,

I'd like to offer a presentation on SDN APIs / northbound interfaces and our underlying design ideas.

Best regards,
Dirk

--
Dr. Dirk Kutscher | NEC Laboratories Europe
phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Zoltán Lajos Kis
> Sent: Donnerstag, 21. Juni 2012 19:03
> To: [email-masked]
> Subject: Re: [Sdn] Agenda items for Vancouver?
> 
> Hi,
> 
> Gather the potential benefits of SDN as compared to the current distributed
> and layered control planes. Identify the domains and/or use-cases, where
> those are applicable or not.
> - Separation of control and forwarding topology. (centralized calculations,
> abstracting subnetworks as nodes for the distributed control plane, ...)
> Hierarchical control architectures, where the hierarchy is not based on
> network layers or technologies (but on topology, on administrative domains,
> on event rates, ...).
> - Composing a sub-network into a virtul network node for upper levels.
> Either in a managed manner, or on-the-fly based on network policies (think
> self-* and ambient-*).
> - Define a model for delegating responsibilites/tasks in a software defined
> manner, e.g. by pushing processing states (e.g., state-machines) to lower
> layers. This can potentially reach all the way to the southbound interface,
> where the controller could push stateful processing to the datapath nodes
> (which is something missing from e.g., OpenFlow).
> - Look at possible ways to extend such delegation of tasks to between the
> SDN and the traditional control planes, creating integrated hybrid networks.
> - Collect the requirements on a controller-internal interface for the above.
> (This might end up being the same as the southbound interface?)
> 
> Study current distributed protocols, dissect them into components, and see
> how those map into SDN-based solutions. Current control protocols are well
> designed complex systems, consisting of a number of components highly-
> dependent on each other: a database model with consistency requirements,
> a data distribution scheme, failure detection, distributed calculations, ....
> Current SDN solutions seem to only focus on centralizing the calculation,
> while taking a consistent database a given (and completely ignoring failure
> detection).
> 
> Kind Regards,
> Zoltan.
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn