OPEN CALL – SOFTWARE DEFINED NETWORKING
II. TOPOLOGY EXCHANGE ARCHITECTURE
The architecture presented here is based on a generic topology exchange architecture described in . The main requirements addressed within the scope of MOTE are as the following: • • • •
Every administrative domain exclusively controls the way it shares its own topology information Domains have the possibility of providing representations of the same topology based on e.g. requesting party The topology documents exchanged among different domains are using the same data model. The architecture supports security for document exchange and multiple disclosure levels
Our architecture distinguishes three main components: • • •
Topology Index (TI) is a database that holds pointers to the topology providers and summary information. Topology Provider (TP) hosts the topology descriptions. Topology Consumers (TCs) are the components that use topologies, e.g. path finding component or lookup components (lookup service).
The architecture supports push/pull model as TCs could register to receive notifications from TI about the topology updates from particular domains. Once a notification is obtained, TC uses the topology pointer (URL) from TI, and requests the topology from the domain itself. The topology documents themselves are therefore not stored at a centralized server, but are rather kept by individual domains. Only the location (URL) of the topology document is kept at the central location. Once a request for topology document is obtained, a domain decides based on the requesting party what topology information (e.g. full/partial, version) would be provided. The architecture is flexible as the implementation of our solution may be deployed in different scenarios.
III. OPENFLOW TOPOLOGY DOCUMENTS
IV. CONCLUSIONS AND FUTURE WORK
We successfully deployed the topology exchange solution that embraces OpenFlow domains. We plan to extend our work (OpenFlow TC) such that it accommodates end-to-end network connections across multiple OpenFlow/NSI domains.
ACKNOWLEDGMENT
This work has been carried out within the scope of GN3plus project MOTE. The authors kindly acknowledge the useful discussions with Ralph Koning and Stavros Konstantaras from the SNE group at the University of Amsterdam.
REFERENCES
[1] Open Networking Foundation, “Software-Defined Networking: The New Norm for Networks”, published online at https://www.opennetworking.org/images/stories/downloads/ sdn-resources/white-papers/wp-sdn-newnorm.pdf [2] R. Sherwood, G. Gibb, K.-Kiong Yap, G. Appenzeller, M. Casado, N. McKeown, G. Parulkar† “FlowVisor: A Network Virtualization Layer”, Technical report, 2009. [3] Open Grid Forum (OGF) https://www.ogf.org/ [4] G. Roberts, T. Kudoh, I. Monga, J. Sobieski, C. Guok, J. MacAuley “Network Services Framework v2.0”, http://www.ogf.org/documents/GFD.213.pdf [5] R. Koning, M. Živković, S. Konstantaras, P. Grosso, C. de Laat, F. Iqbal, F. Kuipers, “Architecture for Exchanging Topology Information in Multi--domain Networked Environments”, unpublished. [6] J. vd. Ham, F. Dijkstra, R. Lapacz, J. Zurawski, “Network Markup Language Base Schema Version 1”, http://www.ogf.org/documents/GFD.206.pdf [7] Floodlight, Open SDN controller http://www.projectfloodlight.org/floodlight/ [8] Ryu, http://osrg.github.io/ryu/
One of the challenges to exchange topologies from OpenFlow domains is that these documents may be in different formats. This stems from the fact that different OpenFlow controllers may be deployed at different domains. In order to overcome this we use the OGF Network Markup Language (NML) . The controllers need to parse and interpret received NML documents in order to use them locally. Similarly, the controllers need to convert the local topology representation into NML in order to exchange them. We have verified the topology exchange architecture by implementing the prototype at our MOTE testbed. This testbed consists of a number of OpenFlow-enabled switches deployed at participating partners’ laboratories. The deployed controllers are Floodlight and Ryu which were extended with the described topology conversion functionality.
For more information on GÉANT Open Call see www.geant.net/opencall 41