[Opensdwmn] Fwd: Re: Introduction to open source MPLS solution

Mon Apr 1 13:42:44 CEST 2019

Pedro de las Heras Quirós <pheras at gmail.com>
Hola,

Es difícil decidir sin saber algo más. Lo que parece claro a juzgar
por lo que yo había oído estos años de Telecom Infra y por lo que
estoy leyendo de Open Cellular, es que su compromiso con tecnología
hw/sw abierta es total. El propio correo-e habla de las presiones a
WiBack para que liberen.

Respecto a si su plataforma hw/sw es más o menos interesante, estoy
mirando qué información hay por ahí de OC-Backhaul. No encuentro
mucho, debe ser muy reciente.

Voy mandando lo que encuentro:
https://cacm.acm.org/magazines/2018/8/229756-designing-sustainable-rural-infrastructure-through-the-lens-of-opencellular/fulltext

Puedo estar en la telco si soy de ayuda.

Salud,
Pedro

--
Pedro de las Heras Quirós
Departamento de Teoría de la Señal y Comunicaciones y Sistemas
Telemáticos y Computación
Universidad Rey Juan Carlos - Campus de Fuenlabrada (Madrid), España
pedro.delasheras at urjc.es | www.urjc.es | @ETSIT_URJC
On Mon, Apr 1, 2019 at 11:15 AM Javier Simó Reigadas
<javier.simo at urjc.es> wrote:
>
> Estimados
>
> El otro día os comenté que Carlos Rey me había puesto en contacto con Kashif Ali, del proyecto Open Cellular de Facebook, pero que de momento no había contestado. Pues ya ha contestado, y la pelota vuelve a estar en nuestro tejado. Si yo entiendo bien su correo, nos propone:
>
> 1.- Si nos interesa, "integrarnos" en el subproyecto OC-Backhaul, que iría controlado por el mismo controlador que la red de acceso radio. Supondría condicionarnos al "paraguas" de OpenCellular, compartir código, ...
>
> 2.- y en ese caso podría haber "alguna financiación".
>
> 3.- Tener una conferencia telefónica para discutirlo.
>
> Yo, antes de tener la conferencia telefónica querría contar con vuestro feedback. Entrar al paraguas de OpenCellular es algo que puede ser muy potente, al tiempo que muy demandante y algo restrictivo. Estaría bien decidir bajo qué criterios negociamos (p.e., estamos dispuestos a cualquier cosa siempre que sea open-source, o queremos además que sea sí o sí SDN con oopenWRT y openvSwitch?). Una vez claros en esto, no sé quién es la mejor persona para mantener una conferencia telefónica, yo solo desde luego no porque siempre he tenido cierto hándicap para entender el inglés de los nativos por teléfono.
>
> Saludos
>
>
>
> -------- Mensaje reenviado --------
> Asunto: Re: Introduction to open source MPLS solution
> Fecha: Sun, 31 Mar 2019 16:23:01 +0000
> De: Kashif Ali <kashi at fb.com>
> Para: javier.simoATurjc.es <javier.simo at urjc.es>, Carlos <carlos at apc.org>
>
>
> Hello Javier,
>
>
>
> Thanks Carlos, for the introduction and my apology for late response, as I wrote the draft and thought I have sent already!
>
>
>
> Javier, great to meet you and thanks for providing full context. I did my post-doc work with Eric Brewer at UC Berkeley, so I know bunch about the WiLD project. Great work.
>
>
>
> On my end, I have started OC-Backhaul project (as part of OpenCellular) and have been trying to convince WiBack to open-source their stack but apparently FiT management doesn’t want. Their model is to license their stack which doesn’t fit with OpenCellular: open-source and royalty-free. OC deployment model is full rural site solution, including spectrum management, power, cellular (2G/LTE), etc and ofcourse backhaul. For some of these sub-projects, we are far into development  (and even production deployments) and others early idea/design stage.
>
>
>
> OC-backhaul project will be mix of SAT and MPLS-based mesh, integrated with OC controller (we are in middle of re-arch the whole OC stack and would want to have single controller managing the network). We have x86 (E3845) and Arm (new SoC coming from Marvell) based open-source hardware for computing, which run SDR stack and NoC, and will be able to support the MPLS. What is your hardware requirement?
>
>
>
> If you open to work under the OC umbrella, contribute code and integrate with the OC architecture, so we won’t end up replicating or use resources to have two open-source implementations for same thing, I think there is great synergy and ofcourse, availability of some funding.
>
>
>
> Maybe we should schedule a conf call sometime this week to discuss?
>
>
>
> Looking forward to chatting with you.
>
>
>
> Thanks
>
> Kashif
>
>
>
> From: Javier Simó Reigadas <javier.simo at urjc.es>
> Date: Thursday, March 21, 2019 at 6:55 AM
> To: Carlos <carlos at apc.org>, Kashif Ali <kashi at fb.com>
> Subject: Re: Introduction to open source MPLS solution
>
>
>
> Dear Kashif,
>
> As Carlos says, we have been working on rural backhaul networks for many years now. Back in 2003 we started to consider multi-hop wireless rural networks based on WiLD (WiFi over Long Distances), initially with telemedicine purposes only. Our first networks of that type connected remote rural health facilities with reference hospitals in Peru, Colombia, Ecuador and Cuba. After many years accumulating experience with technology, logistics, management, etc. we saw that it was not reasonable that our rural networks, always in regions where no other telecommunications infrastructures were present, could be exploited for telecommunications services other than telemedicine. So we decided that it was time to collaborate with operators and see how those rural transport networks could be both telemedicine networks and the backhaul for rural base stations for general-purpose mobile communications.
>
> That is why we started the TUCAN3G project in 2013. In 2016 we had demonstrated how rural networks based on multi-hop low-cost wireless networks could act as carrier-class backhaul solutions for rural femtocells, and the overall solution would allow operators to extend services to very small and remote villages with a sustainable business model, specially if infrastructures were shared with communities or public administrations. Our backhaul networks required initial planning and had tree topology; we never worked on dynamic routing or self-configuring topologies. On the other hand, we handled very carefully QoS issues, differentiating signalling, voice traffic and data and providing guarantees for end-to-end QoS as recommended by ITU G.1010 for each service. Moreover, we designed distributed optimization algorithms that could reallocate network resources among the different traffic classes and source nodes dynamically as the traffic load and the link conditions change, always ensuring priority and quality at least for voice and signaling traffic. We demonstrated our results in two real testbeds, one in the Napo river managing traffic QoS with a DiffServ approach, and the other one in the Paranapura river based on MPLS (both in the Amazon rainforest in Peru). Real users received services through those networks, though Telefonica del Perú discontinued the service at the end of the project, at least in the Paranapura river.
>
> After completion of the TUCAN3G project, we contacted the Fraunhofer institute because we wanted to know more about the WiBACK technology. We signed an agreement with them in which they accepted to provide us with their software for integration with our own embedded WiFi routers in laboratory for free, and we accepted not to distribute the software or to publish any results or observations without their supervision. For one year we tested the WiBACK solution with our hardware, which was somehow problematic because there were bugs that had been corrected in the past for their official ARM hardware but not for x86 platforms as ours. Their support was incredibly good for the whole process, with good responses to all our questions always in less than 24H. We found out that WiBACK was very interesting, having a very good architectural base, really self-configuring in terms of topology and routing. There is a good support for traffic classification and mapping into MPLS classes, with central management in the coordinator node. The whole thing is very well conceived. Our observations were not that positive in terms of real carrier-class QoS support, as we did not find a perfect matching between the QoS and the capacity assigned for each flow and what actually happened, but that could be because of our measurements. I mean, the evaluation was run by a student with very little time for the project, and he could perfectly have made mistakes. So I cannot be sure about the real nature of the "issues" we found. However, we saw that there was little flexibility in the way resources were allocated for the different LSPs, and how priorities were applied; that did not seem to be as flexible as topology self-configuration.
>
> Then we got some funding for a pre-doc full-time grant, and one person started working with us three weeks ago. We met (our team are 6 professors with partial dedication to this project, and a full-time pre-doc student), we discussed about what to do for the next 12 months, and we decided to leave WiBACK aside for the moment and focus on how to implement an open-source SDN version of what we did for TUCAN3G, but with improvements in the self-configuring part that we have seen so good in WiBACK. Here we are now, starting this project.
>
> Although we are in the first steps of this new project, we would be working in parallel with the functional definition, software development in a simulation platform (mininet + openvSwitch) and identifying an appropriate hardware for the moment we want to go into real testbeds. We are also trying to get some libreRouter devices to see if, adding a openvSwitch to them, we can chose them as our hardware, as they meet most of our requirements.
>
> In parallel, one of our researchers in working with two students in implementing a virtualized mobile network in the lab with OpenAirInterface and B210 Ettus SDR devices. We were also interested at some point last year in OpenCellular, but we were told (may be wrongly?) that it was not possible to use it for LTE or beyond by that time.
>
> All I could add is that we have experience and ideas, but scarce resources that limit the speed and scope of the objectives we can have for the short term.
>
> I hope this is not "too" long as a detailed presentation. Please do not hesitate to make any questions about what we are/know/can do and what we are not/don't know/cannot do. Best wishes,
>
> Javier
>
> El 21/3/19 a las 10:56, Carlos escribió:
>
> Hey Kashif, I wanted to follow up on the conversation we had yesterday
>
> and introduce you to Javier, cc'ed.
>
>
>
> Javier, besides having been formally my PhD supervisor, is one of the
>
> person I respect and admire the most in this space, and a personal
>
> friend. He has been involved in rural backhaul solutions for many years
>
> [1], [2]. Over the past few years, Javier has been involved in Tucan3G
>
> [3], where Mayutel (FB's partner) is also involved, focusing on
>
> developing an open source MPLS-type solution to prioritize the traffic
>
> in the backhaul, but I will let him to tell you more about it. His
>
> research group has also been analyzing WiBack's performance, and were
>
> evaluating contributing to the open API that Matthias was considering,
>
> but a couple of weeks ago they decided to work on a full open source
>
> solution providing an automatic configuration via SDN to the MPLS
>
> priorities developed in Tucan3g. Additionally, Javier was telling me
>
> yesterday that his research team is also working with some OAI
>
> solutions, to integrate access and backhaul. So, all in all it looks to
>
> me that you two make a perfect match. I leave it to you to continue this
>
> conversation!
>
>
>
> All the best,
>
>
>
> carlos
>
>
>
> [1] https://scholar.google.es/citations?user=zoKJHR4AAAAJ&hl=es
>
>
>
> [2] https://www.researchgate.net/profile/Javier_Simo
>
>
>
> [3] https://www.youtube.com/watch?v=i-CLahBb_4Q
>
>
>
>
>
>
>
> --
>
>
>
> Francisco Javier Simó Reigadas
>
> Profesor, Director de la ETSIT
>
> Dept. Teoría de la Señal y Comunic. y Sist. Telemáticos y Computación
>
> Universidad Rey Juan Carlos
>
> Campus de Fuenlabrada (Madrid), España
>
> Teléfono: 91 488 81 67
>
> javier.simo at urjc.es | www.urjc.es | @URJC |
>
>
>
> _______________________________________________
> Opensdwmn mailing list
> Opensdwmn at gsyc.urjc.es
> https://gsyc.urjc.es/cgi-bin/mailman/listinfo/opensdwmn