Software Defined Networking
Software-defined networking capabilities can be supported by hardware in the Science DMZ – software defined networking and OpenFlow allow the flexible provisioning of policies to route science flows. Having Science DMZ components in a dedicated enclave near the site border means there is a single location to install and configure new technologies such as OpenFlow and connect to wide area SDN services offered by science networks.
An example use case for SDN is to assist in identifying high profile flows from the general internet traffic, and moving those flows to dedicated WAN infrastructure.
With SDN components the identified elephant flow can be removed from the general purpose infrastructure, and placed onto dynamically controlled links. This separation allows for better performance in all cases.
ESnet and its collaborators at Indiana University and University of Delaware have demonstrated an OpenFlow-based Science DMZ architecture that interoperates with a virtual circuit service like OSCARS. An example of how these services might be integrated into a production Science DMZ is outlined below.
Service Integration - From Test to Deployment
The Science DMZ model allows new services to be tested, validated, and rolled into production once they are proven operationally sound. Testing and deploying Software Defined Networking – particularly the use of OpenFlow as a platform – is a timely example of how this model could be used. Before experimentation with a potentially production service, it is recommended that a "research" Science DMZ be created.
Initially, an OpenFlow-capable connection could be brought into the Science DMZ area and connected to a separate SDN-capable switch. A dedicated test host (e.g. a DTN) can be connected to the SDN switch for prototyping purposes.
Note that several aspects of the Science DMZ model are already at work here: the SDN switch need only permit access to the minimum set of hosts necessary to test the prototype service, so the security of the production infrastructure is not put at risk. The production Science DMZ need not trust the research area at all, and it can provide access to the research area from certain hosts if policy permits.
By provisioning the prototype in this manner, the service can be tested without the up-front requirement that enterprise firewalls or production security mechanisms support a cutting-edge service before it's ready for production deployment.
After the service is determined to be production-ready, and the security model for the new service has been vetted, the SDN-capable WAN connection can be moved to the production Science DMZ. By doing so, the Science DMZ is effectively expanded to include the SDN-enabled services, while making only minimal changes to the existing production Science DMZ environment. The research Science DMZ now receives services from the production Science DMZ, and can continue to be used for R&D activities.
Once the SDN technology is available in the next generation border router, the border router can be upgraded as well. Once this occurs, the organization has a true multi-service path to the external science network.
This example illustrates the use of the Science DMZ in the prototyping and development of a production service, and the transition to production for the capabilities developed in the research environment.