Re: [altoext] i2aex BOF - Large Bandwidth Use Case

[DIEGO LOPEZ GARCIA <[e-mail]>]

Hi Greg,

On 27 Mar 2012, at 19:01 , Greg Bernstein wrote:

> Hi Richard, great conversation. A couple general comments on  "large
> bandwidth" case.  I think we are seeing some good convergence for some
> of the data center and "large bandwidth" use cases.
>
> Issues with "optical" bandwidth resources:
> (a) Being well below IP this bandwidth is not visible to upper layers,
> i.e., packet probing won't detect it.
> (b) Spare optical link capacity is not inherently usable unless
> specifically allocated. This is unlike packet technologies with
> statistical multiplexing. We need to set up "light paths", "OTUs",
> "STSs" (old fashioned circuits).
>
> We would like to extend ALTO to help with (a).

Wise words!

> To take advantage of the optical capacity we need high level guidance
> from the application layer as to which circuits to set up and their
> properties. This is what I've been calling a "reservation interface".
> Where this belongs (if at all) at the IETF is an open question. I'll try
> to describe it a bit more below.
>
> It is great that we have GMPLS, MPLS and Open Flow technologies that can
> allow us to dynamically set up "express lanes". However, I would not
> want the application to have to know any details of either the optical
> network (WDM, OTN, SDH, Ethernet, etc...) or the "bypass technology"
> utilized to create the "express lanes" (AKA "traffic engineering")
> (MPLS, PBE, OpenFlow).  This stems from both security and information
> hiding principles.
>
> A carrier doesn't want to necessarily reveal the details of the
> combination of optical and packet technologies it is currently using. In
> addition, those technologies can change overtime and the application
> layer folks would not want to deal with those changes. Hence I see the
> need for an interface that is not layer specific like the control planes
> for GMPLS, MPLS and PBE, or related UNIs.  These interfaces also assume
> more trust than I would want to extend outside the network.
>
> With current trends in data center networking pushing performance and
> guarantees, I think such an interface could be useful within the data
> center.  When I look at the OpenStack project (open source IaaS cloud
> software) they have one incubator project (Quantum) with "connectivity
> as a service" maybe that would be a place for this. However, I would
> think a standard would be better. Even NIST has mentioned "Network as a
> Service" in some of there cloud computing documents…

Let me add a few other references to projects related to this idea I'm
aware of, so we have other sources of inspiration and a few software pieces
to start with. I can name initiatives like GEMBus (in which I was
heavily involved in a past life, http://www.geant.net/Research/Multidomain_User_Application_Research/Pages/GEMBus.aspx), GEYSERS (http://www.geysers.eu/), and MANTYCHORE
(http://www.mantychore.eu/), which is even developing something called
OpenNaaS...

> Let me know if this makes the concept of "reservation interface"
> clearer. I'm not saying where it belongs organizationally only that it
> could be very useful.

I fully agree, though I think that abstract control has a longer history (see
for example, http://tools.ietf.org/html/draft-ietf-opsawg-management-stds-03)
than abstract information, and it would be wise to explore this previous
results before, and probably separate the focus on both interfaces.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [e-mail]
Tel:    [phone]
Mobile: [phone]
-----------------------------------------


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx