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

• A manual configuration: Operators can manually create "ONOS intents" from the CLI / GUI that connect , 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) world 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.

Layer 3 inter-domain failover mechanisms

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