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

[Greg Bernstein <[e-mail]>]

Once again Diego, great pointers, and more fuel for thought.

It is very interesting to compare the different notions of "Network as a 
Service" (NaaS) and see what type of additional information various NaaS 
notions would require from the network.

A rough summary from this perspective might be:

(a) GEYSERS -- they virtualize optical network elements such as OXCs, 
ROADMS, and optical links. They do not hide the fact that these are 
"optical" links and users would need to know how to perform RWA (routing 
and wavelength assignment). This seemed quite strange to me at first, 
then I remembered that this is an NREN project so the users want/need 
limited control capabilities over the optical layer.

(b) MantyChore -- "Mantychore Project: OpenNaaS, a toolkit for IP 
Networks as a Service". It looks like they are controlling "logical 
switches" and "logical routers". This is explained a bit more in 
http://jira.i2cat.net:8090/display/MANTECH/Project+Overview. Once again 
part of an NREN, gives control of virtualized layer 2 and 3 networks. It 
seems that explicit traffic engineering would come as they tie this in 
with GEYSERS.

(c) OpenStack - Quantum Project: 
Fromhttp://wiki.openstack.org/QuantumOverview /Quantum is a "virtual 
network service" that aims to provide a powerful API to define the 
network connectivity between "interface" devices implemented by other 
OpenStack services. --snip-- To start, Quantum is focused on providing 
L2 connectivity between "interfaces". However, the Quantum API will be 
extensible, allowing plugins to introduce new logical network 
abstractions, for example, to provide more advanced security or QoS 
policies. Extensions provide an avenue for innovation by allowing new 
functionality to be exposed. --snip--/  The V1.0 API contains interfaces 
for CRUD operations on L2 networks (VLANs), VLAN ports, and vNICs. 
Plugins exist for open source, e.g., Open vSwitch, as well as vendor 
specific software/hardware. Work has started on L3 network abstractions 
(IP subnets, routing tables). Note that there is a related but separate 
OpenStack project that deals with IP address management.

(d) Our High Bandwidth ALTO use cases: We were thinking of a "traffic 
engineered service" aimed at either layer 2 or layer 3 users. For 
simplicity to the application layer we were thinking of only exposing a 
single layer and hiding all the lower layer details, in particular the 
optical layer and method of implementing the "express lanes". However we 
would did want to show bandwidth and QoS related measures (e.g., 
latency, reliability, etc...).

It seems that the graph based I2AEX extensions that we like would apply 
to (a) and (d), and to all casesl if traffic engineering (layer 2 or 3) 
is desired.  Comments? Other examples that we should look at? I'm 
working to formalize the graph stuff we showed at the BoF in proper ALTO 
protocol form and should have a draft in a few more weeks.

Best Regards

Greg B.



On 4/2/2012 2:37 AM, DIEGO LOPEZ GARCIA wrote:
> Hi Greg,
>
> On 29 Mar 2012, at 20:12 , Greg Bernstein wrote:
>> 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.
> And using an extended ALTO plus the request interface would provide an
> additional management plane, with suitable abstractions according to the
> type of application and the level of control and information the network
> operator is willing to provide in each case.
>
>> 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".
> Indeed. For documents related to what matters in this discussion, I'd
> recommend the description of what is called LICL (Logical Infrastructure
> Composition Layer, http://www.geysers.eu/images/stories/deliverables/geysers-deliverable_3.1.pdf)
>
> A more condensed description will be soon available
> at https://tnc2012.terena.org/core/presentation/58 as part of a GEYSERS
> presentation in the TNC2012 conference.
>
>> (b) GEMBus -- I saw a presentation of yours at the SOA layer, but couldn't find a document relating to application/network interfaces.
> GEMBus is more oriented to the core services enabling these (and other)
> interfaces, like a service registry and security mechanisms. So GEMBus could
> be applicable here more as a supporting framework than as a direct model
> for net/app interfaces. The most recent update on GEMBus is available at
> http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-12-003_Composable_Network_Services%20DJ3_3_3_v1.0.pdf
>
> I know the team is working in what they call a cookbook for GEMBus. I can
> update you when it becomes available.
>
>> (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.
> The demonstrators of the project will run on research networks, but is our
> intention to explore its application in more general case. OpenNaas is
> available as part of the Mantychore software releases (http://jira.i2cat.net:8090/display/MANTECH/Home), though it is right that
> documentation is not its strongest point.
>
> There is going to be a workshop on Mantychore during the next TNC as well
> (https://tnc2012.terena.org/core/event/7)
>
>> 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…
> That's precisely the point! I'm trying to make this alignment to happen, as
> I am or have been somehow involved in the three projects, and I'd like to see
> them contribute to progressing standards in this are.
>
>> 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.
> And that brings me back to the idea of a management plane that can provide
> adapted views, based on the rights of the requester and the policy of the
> operator.
>
> 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
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext
>
>


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