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

[Greg Bernstein <[e-mail]>]

Hi Diego, thanks for the comments and references. This helps my thought 
processes and leads to yet more comments:

The separation between an interface such as an extended alto that could 
give an application more information about the underlying "high 
bandwidth" network in a suitably abstract form, and an interface to set 
up the "express lanes". Seems analogous to what we did in GMPLS. In 
GMPLS the routing protocols are used to give detailed network topology 
and properties, while a separate signaling protocol (RSVP-TE) is used to 
actually set up those connections. One can and usually does lag the 
other as we extend GMPLS to deal with new technologies.

In looking at the research projects you cited I noticed the following:
(a) Geysers -- has something called the /Enhanced Network Connectivity 
Service/ which sounds similar to what we might be talking about. I 
didn't see anymore details though. Anyone know of exactly where to find 
documentation (these are large multifaceted projects and a bit hard to 
sift through) . Note that they build the network side of their system 
around and extended GMPLS and PCE. Which reinforces what we said in our 
draft about GMPLS and PCE being "enabling technologies".
(b) GEMBus -- I saw a presentation of yours at the SOA layer, but 
couldn't find a document relating to application/network interfaces.
(c) MantyChore -- They have a neat logo for OpenNaas (Network as a 
service) but no documentation that I could find yet. But it sounds like 
they are trying to bring optical, IP, and compute infrastructure 
together for research networks.

Hmm, with so much activity could be ripe for some type of 
standardization...  Or at least we could try to bring folks together to 
talk...

You also commented on network management and reference the nice overview 
document  
http://tools.ietf.org/html/draft-ietf-opsawg-management-stds-03.  The 
control plane, e.g. GMPLS, does not offer the full functionality of the 
management plane. The management plane has always been able to obtain 
more information and control more aspects of a network than the control 
plane. In the control plane we perform a few limited functions (topology 
discovery and resource status via link state routing, cross connect 
setup via RSVP-TE signaling).  Though we do like to thing that we do 
these better (faster, more interoperable, more resilient, etc...)

We also make abstractions in the control plane, for example in modeling 
SONET/SDH in GMPLS we "smoosh" the physical, regenerator section, and 
line section layers together since they are not "switching layers", but 
they are very important for network monitoring and SLA enforcement.

Best Regards
Greg


On 3/28/2012 3:20 PM, DIEGO LOPEZ GARCIA wrote:
> 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
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]