• 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 Università Roma Tor Vergata through Consortium GARR and GEANT (http://geant.net)
• Korea - KREONET (http://www.gloriad.org/gloriaddrupal/?q=node/114)
• Taiwan - National Chiao Tung University - NCTU (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)

Design 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.

Different domains are then connected through dedicated Layer 2 connections, over which routes are exchanged using BGP.

Layer 0 - Layer 2

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. As it happens for the intra-domain communication, also (and specially) inter-domain communication can vary depending on the infrastructure in between the two RENs. Sometime, OpenFlow switches of different domains get connected using dedicated fibers or through a Layer2 circuit carried over a third partner network using a VLAN or as an Ethernet over MPLS frame.

Currently, the optical layer is totally transparent to the deployment. Anyway, different RENs are investigating with ON.Lab how to coherently control both the packet and the optical layers from ONOS.

Layer 3

One of the basic services generally offered to end users is Layer 3 connectivity. This is possible through

• A manual configuration: Operators can manually create "ONOS intents" from the CLI / GUI, connecting one or more edge ports of the network together
• ONOS Applications that automatically translate information gained from standard network protocols into intent/flow requests

L3 connectivity is not only used to connect internal users, but also to create inter-domain connectivity. Indeed, RENs establish Layer 3 connectivity on top of the dedicated Layer 2 circuits connecting them. Once Layer 3 connectivity is established, a BGP peering session is created and networks start to exchange routes, without any need of legacy routers.

For example, applications such as SDN-IP are usually adopted to let an OpenFlow network become an IP transit network. BGP routes advertised from the outside (legacy) ASs get translated into ONOS intent requests, which are then compiled by ONOS itself into flow entries on the devices.

RENs can opt to use either public or private Layer 3 address schemes and AS numbers. Sometime, for pure experimentation private AS numbers and addresses are announced and exchanged over certain segments of the global infrastructure. Through the usage of route maps and filters, RENs make sure the private routes don't get propagated to the public Internet, outside the Global Deployment network. Other times, public AS numbers and addresses are announced and exchanged and these get propagated by/to other ASs, just as any other public address does on the Internet.

Incrementally migrate to OpenFlow. Layer 3 inter-domain failover mechanisms

ONOS is already highly reliable. Anyway, willing to innovate and at the same time run a production network is still a tough task. When it's time to move from a private addressing scheme to a public addressing scheme, taking the right precautions is a must. Layer 3 connectivity and inter-domain Layer 3 protocols (i.e. BGP) related issues usually worry more Operators, since this implies problems to their accessibility from the public Internet.

On the other hand, many of these networks still run in parallel a legacy Layer3 network and the new OpenFlow network, in order to gradually transition to the new technology. Often in these cases, a small part of the Layer3 addresses is initially moved to the new network and gradually then incremented.

Still having two infrastructures running in parallel may be very useful for putting in place defensing mechanisms, in case something fails in the new network. Indeed, RENs use to advertise the same network prefix from two different next-hops or using two different VRFs. The prefix advertised by OpenFlow gets higher priority than the one advertised by the legacy network. In this way, if anything goes wrong with the OpenFlow network, external domains will always be able to automatically transition through the legacy devices.

Applications deployed

Innovate is a key rationale behind SDN deployments. For the first time, Operators don't necessarily have to wait for vendors to deploy features in their network, but can instead proactively create and deploy new features, just as happens nowadays with Personal Computers.

Different RENs have developed and deployed different ONOS applications on top of their controllers, because having different needs. This is a list with a brief description of the different applications developed and deployed today by the RENs