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

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,

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 generally possible through

• A manual configuration: Operators can manually create intents from the CLI / GUI that connect one or more edge ports of the network together
• 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) world get translated into ONOS intent requests, which are then compiled by ONOS itself into flow entries on the devices.