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

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Greg,

Just a minor clarification about GEYSERS.  It is not actually focused on NREN; it really targets network operators, not only traditional ones, but facilitating new roles defining different interacting actors: Physical Infrastructure Providers (PIPs), Virtual Infrastructure Providers (VIPs), Virtual Infrastructure Operators (VIOs), etc.

All this roles, actors and interactions are well documented and available on public deliverables that can be downloaded from the project website (www.geysers.eu<http://www.geysers.eu>). Let me know if you want further information or clarification.

Best regards,

Luis

De: [e-mail] [mailto:[e-mail]] En nombre de Greg Bernstein
Enviado el: miércoles, 04 de abril de 2012 19:35
Para: [e-mail]
Asunto: Re: [altoext] i2aex BOF - Large Bandwidth Use Case

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: From http://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]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/altoext








--

===================================================

Dr Greg Bernstein, Grotto Networking [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