Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Overview
Recently, ON.Lab has successfully deployed ONOS and some of its applications on both production and experimental networks, managed by Research and Educational Networks (RENs), thus creating a global network facility, entirely based on OpenFlow.
The network deployed is able to provide Layer2 and Layer3 connectivity to the end users with no need of any legacy device in the network cores. The actual facility interconnects Australia, Brazil, Chile Europe, Korea, Taiwan and United States, linking together Universities, Research Centers and RENs. More than 60 switches from different vendors are controlled by ONOS clusters geographically distributed and administratively isolated.
Goals and Motivations
By definition, RENs are the perfect environment where to deploy SDN. Historically, RENs are the ones providing high-quality production network services to Academia and Research Centers around the globe, while maintaining a standing leadership in network innovation. While innovating on the computing has been facilitated by the introduction of open hardware interfaces and Open Source software, network research has always been an hard - if not impossible job. SDN (and ONOS) gives the ability to Academia and Universities to run Carrier Grade networks, while enabling innovation.
The goal of the deployment is to provide L2 and L3 connectivity to end users, without using any legacy device, while enabling innovation. Deploying ONOS in RENs give the ability to the Academia and the R&D Departments to develop new network applications, that can then be validated in real network on hardware, thus being able to get used in production.
Deploying ONOS in production networks is important because it demonstrates the ONOS ability to work at scale on real infrastructures while providing High Performances and HA.
Moreover, the feedback from the Teams running the production networks is continuously translated into new requirements for the next releases of ONOS. Once the new features get implemented, ONOS gets deployed again. This is what we usually call Agile Deployment Model.
Participants
The deployment currently connects:
- Australia - AARNet (https://aarnet.edu.au/)
- Brazil - ANSP and RNP through AmLight (http://amlight.net/)
- Caribbean - CKLN through AmLight (http://amlight.net/)
- Chile - Reuna through AmLight (http://amlight.net/)
- Europe through GEANT PAN European Network GTS testbed facility http://geant.net)
- Italy - CREATE-NET and Università Roma Tor Vergata through Consortium GARR (http://garr.it)
- Korea - KREONET (http://www.gloriad.org/gloriaddrupal/?q=node/114)
- Taiwan - National Chiao Tung University (http://nctu.edu.tw)
- United States - Clemson University, Duke University, Florida International University, Georgia Tech, Indiana GigaPoP, University of Huston, University of Maryland, University of Oklahoma at Norman, University of Utah - through Internet2 (http://internet2.edu)
Architectural principles
Each REN acts as a separate Autonomous System, administratively isolated from others. This gives to Operators the possibility to be enough independent, experimenting within their domain specific features while enforcing their own settings and polices.
The networks are composed by different (usually OpenFlow) devices, connected to one or more ONOS clusters, made of one or more instances. Operators enforce network polices from the logically centralized ONOS controller and install different applications on top of it, depending on the needs (i.e. provide L2 or L3 connectivity to end-users).
Depending on the infrastructure offered/run by each REN, the SDN devices may be:
- Running as the production network
- The same of the production network, but ONOS is running in a L2 slice given by the OF (or legacy) network hypervisor offered by the REN itself
- Deployed in parallel to the production network as a completely separate Future Internet research infrastructure
- Connected directly with dedicated fibers
- Connected on top of/through an underlying legacy production L2 network
The same usually happens for the L2 connections from the PoP to the end-users.
The RENs are connected through dedicated Layer 2 circuits, terminated on each end at the OpenFlow switches