This series of blogs is inspired by content originally written by Jac Kloots, Teamlead Network Services at SURFnet.
In part 2 of this blog series, we previously outlined the steps SURF has taken to create a robust and highly configurable network.
Continued Development of Self-Service Portal: SURFnet Network Dashboard
With this in place, the next stage is the SURFnet Network Dashboard, which is being developed to increase user self-sufficiency. The current dashboard provides authorised users with an overview of connections to the SURFnet network, as well as purchased network services such as SURF internet and SURF light paths. Using the dashboard, limited light paths can be made available without the intervention of SURFnet Network Operations Center (NOC). The dashboard also shows usage and performance statistics for all purchased network services.
Once it is ready, users and administrators will be able to use the SURFnet network dashboard to set up network services on their own within minutes – services for which they currently must wait a long time. Further development also includes plans for accessing and creating tickets and real-time overviews of purchased service performance. In the future, this process will be increasingly intent-based; eventually, users will request, check and/or configure all innovative services—such as multipoint-to-multipoint services (E-LAN) and virtual network functions like Firewall as a Service—through the dashboard. In addition, institutions will have the option to use the open APIs in the SURFnet automation infrastructure, allowing them to automate tasks or monitor services based on their own needs.
New Service Layer: Programmability and Automation
SURF is fully focused on programmability and automating currently manual network tasks.
The newly created service layer will make it possible to provide automated service rollout in a controlled, programme-based environment, ensuring that institutions will be able to respond more quickly and flexibly to developments as they emerge. To make this possible, SURF issued a request for tenders for the service layer, specifying a network that can provide specific services and has specific behaviours that can be controlled through open APIs. This approach contrasts with earlier generations of network tenders, which mainly asked for specific technologies.
A new factor was the request for software that could be used for completely automated management of requested services. With the new service layer, SURF will focus on the software side of the infrastructure, in which automation and orchestration will provide the necessary flexibility. To that end, SURF has developed an automation architecture in which hardware and software will be connected by means of software-defined technologies. This will make the future SURFnet network more flexible, ensuring that changes can be implemented quickly and easily. Physical forklift upgrades will be a thing of the past; it will be possible to continuously innovate in the technology domains and in parts of the network as needed.
The tender for providing the SURFnet8 service layer was awarded to Juniper Networks’ Elite partner Telindus, and we will cover the reasons for its selection and approach in the next blog.