This week in Manchester, SURF participated in the 54th LHCOPN-LHCONE meeting, where global experts gathered to discuss the evolution of research networking. It was a special occasion as we celebrated 20 years since the first LHCOPN meeting, reflecting on how far we’ve come in enabling high-speed data transfer from CERN’s Large Hadron Collider (LHC) to researchers worldwide.
At the heart of it all, we organize IT infrastructure to make science happen—to help researchers probe the fundamental nature of the universe. Whether it’s LHC physicists searching for the building blocks of matter or SKA astronomers listening to the faintest signals from the early universe, both fields generate massive amounts of data that push the limits of computing and networking.
Sessions on LHC’s evolving network infrastructure highlighted valuable lessons as we discuss how to develop the SKA Observatory’s data systems. While the scale and patterns of data movement may differ, exploring synergies between NREN-based networks for LHC and SKA was particularly insightful.
Of course, no meeting is complete without spirited debates—this time on the broader challenges of expanding network capabilities for large-scale scientific projects. The conversation naturally raised questions of trust, Acceptable Use Policies (AUP), and the impact on existing communities. The balance between openness and security, integration and specialization, is a fine one. And as history has shown, discussions on centralized vs. federated models tend to resurface over time—sometimes wrapped in new proposals, sometimes in a familiar shade of red.
As always in these meetings, technical discussions mixed with broader questions of policy, trust, and governance—some unfolding over structured sessions, others in those classic last-minute deep dives when time was running short. Because in research networking, the big questions are never just about technology.
Grateful for the engaging discussions, the shared knowledge, and the beautiful opening trip down memory lane. Plenty to reflect on and even more to explore—let’s keep the momentum going!
Back from #APAN59, and what a fantastic experience! Honored to represent SURF and #NetherLight, highlighting their impact in international research collaborations—especially between scientists in Japan and in the Netherlands.
It was great to reconnect with peers worldwide, make new connections, and gain fresh insights. Huge thanks to all the speakers and moderators for their excellent work, including my dear colleague Alexander van den Hil whose expertise also as a moderator I very much admire!
And of course, a big thank you to everyone who made this event so valuable, and to #APAN for an outstanding conference. Looking forward to what’s next!
皆さん、本当にありがとうございました！ (Minasan, hontō ni arigatō gozaimashita!) Thank you all very much!
Did you know that radio telescopes are synchronized down to the nanosecond (1/1,000,000,000 s) via the SURF Network? And that VU leverages the frequency signal provided by SURF to determine the weight of an electron?
Through the new SURF Time & Frequency network, the Dutch UTC time from VSL in Delft is distributed with extreme precision across the Netherlands via the SURF fiber optic network.
???? Curious to learn more? Last month, I recorded a podcast at SURF about Time & Frequency Transfer, where I explain what this technology is and how it is used.
Since the nineties, SURF has supported IP Multicast within its network. What once started as a special network for this technology, grew into a standard part of the SURF network. However, after decades of use, SURF has decided to phase out IP Multicast. In this blog post I will explain what IP Multicast exactly is, how it was used within SURF in the past, and why the technology must now make way for modern alternatives.
What is IP Multicast? IP Multicast is a technology that makes it possible to send data from a server to multiple recipients in a scalable way. The server only needs to send the data once, after which the network takes care of the replication to all recipients.
An example of this is the broadcasting of a live lecture to various universities in the Netherlands. Instead of the live video stream being sent multiple times from the source (once for each recipient), it is only sent once via IP Multicast. The network then ensures that the stream is distributed to all affiliated universities. This reduces the required bandwidth and ensures more efficient use of network resources.
Use and applications within SURF Over the years, this technology has been tested and used in various ways by affiliated institutions. Examples of applications were:
Sending television channels to student houses.
Broadcasting webcam images, such as those of the coast of Vlissingen.
Sending satellite weather images from Germany to the KNMI and universities in various European countries.
Why is IP Multicast used less these days? Although IP Multicast once held great promise, it is increasingly being used less and less due to management complexity and limitations in modern networks. In cloud environments, where networks are often dynamic and virtual, IP Multicast can be difficult to implement. Many networks prefer unicast streaming and Content Delivery Networks because of their greater scalability and flexibility.
Unicast streaming sends separate data streams to each recipient, which requires more bandwidth, but with the increased capacity of modern networks this is no longer a major issue
Why is SURF discontinuing IP Multicast? None of the old IP Multicast applications are still active, and IP Multicast has not been used on the SURF network for some time. Supporting IP Multicast introduces significant protocol complexity, both for SURF and for the connected institutions.
By phasing out IP Multicast, SURF is simplifying its network protocols. This decision marks the end of an era, but also opens the door to new technologies and enables a less complex migration to a next-generation network in the future.
As of January 2024, the names of the network services will change. We are doing this to better align our services with the terms and conventions used in the network community. We hope that this will make it clearer to network administrators which services are provided.
Current service name
New service name per 1 Jan 2024
SURFlichtpad
EVPN – Point-to-point
SURFlichtpad – Redundant
EVPN – Point-to-point Redundant
L2VPN
EVPN – Multipoint
L3VPN
L3VPN – Multipoint
SURFinternet
Internet
Multi Service Poort (MSP)
Service Port
Lightpath becomes EVPN
The term lightpath, although well established in SURF language, has always caused some confusion. This is not an optically illuminated path but a dedicated network connection over the service layer between two points. EVPN (Ethernet-VPN) is what is provided here and the addition (Point to point vs Multipoint) indicates whether it is set up between two points or more than two points.
Multi Service Port becomes Service Port
Under the new All-In Network Tariff, which came into effect on September 1, 2023, institutions can adjust their network port configuration as they see fit. This effectively makes all the network ports “multi” service ports. That is why they will simply be called Service Port from 2024.
The changed names have been implemented in the network dashboard, on (mijn)surf.nl and on invoices.
We have been providing SURFlichtpaden for a long time. Up until now, these were always ethernet services with two endpoints. We had SURFlichtpaden in roughly four flavors; protected or redundant and on a Single Service Port (SSP, untagged) or Multi Service Port (MSP, tagged). Now, with the new SURF network, we can add new possibilities to the SURFlichtpaden. For example, we now offer a multipoint variant (or L2VPN) and there are more possibilities in the field of redundancy and resiliency. Read here what we have done so far and what we plan to do.
SURF light paths have always met a need to connect institutions, or dislocations of an institution, with each other. SURF light paths are therefore often used for research purposes or for internal business operations. In recent years, connections with cloud providers of all shapes and sizes have also been added, such as IaaS, SaaS, CaaS, DaaS; in short, *aaS. Business operations with *aaS providers often require a high degree of service availability. That is why light paths have become quite popular for that purpose.
However, light paths have a number of limitations. Firstly, they are Point-2-Point. That provides control, but can also become complex if you want to connect many locations or networks with each other, because many individual light paths are required. In addition, it is difficult if you want to extend redundant VLANs to a cloud provider via such light paths. That causes a major risk of Ethernet loops, which can cause network instability. We could not offer a good solution for this in SURFnet7.
With the migration of SURFnet7 to the new SURF network, we have switched from PBB-TE to EVPN over MPLS. EVPN is a technology that is fully based on IP and Ethernet networks. This also provides new opportunities to evolve our light path services to the current times and needs of the connected institutions.
So what’s new?
The migration to the new SURF network is now almost complete. If you have MSPs (Multi Service Ports) that have already migrated to the new SURF network, we can now offer multipoint light paths (L2VPNs) there. Suppose you have a VLAN running over the light path between two locations, you can now easily add a third location. This way you have three locations connected to each other without having to build a whole tangle of light paths. Within the new SURF network, traffic always takes the most optimal route through the network.
To visualize the whole thing, we show in the example below how we want to connect three networks to each other over a VLAN with the MSPs. Each network (or location) is connected to one MSP. This means that no Ethernet loops can be created, because each location has one connection. But unfortunately there is no redundancy for business-critical applications. If something happens in this scenario, one or more locations can become isolated in the event of a malfunction or work.
Figuur 1: niet redundant L2VPN
Ideally, we would of course be able to connect each network/location to 2 MSPs, for more redundancy. But if we just do this, Ethernet loops are guaranteed to occur, resulting in disruptions. See the example below. Ethernet does not have a loop prevention mechanism by itself. As a result, when a loop occurs, packets continue to circulate endlessly until the loop is interrupted. In SURFnet7, we could therefore not offer such a scenario.
Figuur 2 Ethernet loops in een redundant L2VPN
Within EVPN (the protocol used in the new SURF network for light paths and L2VPNs) there are a number of mechanisms that ensure that Ethernet loops can no longer occur. We can now offer one of these on the new SURF network: ‘Single-Active multihoming’ on a VLAN service. This allows us to configure a VLAN service on multiple MSPs at the same location. These MSPs are grouped in an ESI (Ethernet Segment Identifier) and in this ESI only 1 port is active at any given time. When the active port goes down, the other port immediately becomes active and this new port will forward the traffic. During the setup, MAC learning will ensure that all MAC addresses move to the new active port. This happens in just 1-2 seconds. The figure below shows what that would look like. There you can see that 1 port in an ESI group is always active and there is a loop-free topology.
Figuur 3 Loop preventie mbv single-active multihoming in L2VPN
Possible use cases
The above is quite a technical story. It may come to life more if we explain some possible use cases.
EduVPN scenario
eduVPN is a VPN service from SURF to allow employees and students of an institution to work safely at home or remotely. We are currently testing whether we can make the eduVPN service more reliable using multihomed L2VPN, which adds more resilience to the eduVPN service. This scenario looks like this:
The eduVPN servers run in two data centers in Amsterdam and are connected to the institution with a light path. The eduVPN service can currently only exchange traffic between the institution and eduVPN using static routes. This makes it impossible to create a redundant scenario of this service using traditional light paths. This is possible using the ESI mechanism in the L2VPN.
Figuur 4 Usecase EduVPN
The above scenario shows the eduVPN service at the top. The eduVPN server can be moved between data centers in the event of outages. In the eduVPN setting, resilience is achieved by using VRRP (or a variant of this, such as HSRP).
Twin data center plus cloud IaaS provider
When an institution has multiple data centers and also wants to use an IaaS provider, the use of an L2VPN can provide redundancy. This can be used to, for example, migrate services to the cloud provider or to outsource certain matters. This may create the need to be able to extend the VLANs in the data centers to the IaaS provider. This allows systems to be moved without having to be renumbered. Such a scenario could look like this:
Each data center is doubly connected and has 2 ports in an ESI group. This prevents loops and provides sufficient redundancy. The L2VPN can contain a bundle of VLANs.
You then get the scenario in figure 3. Where 1 of the locations can be a cloud provider
Future
With this functionality, we believe we have taken a step in the right direction to add functions to our lightpath services that can help institutions.
EVPN has even more possibilities that we can use to, hopefully, even better meet the needs of institutions.
Within the lightpath services, we also hope to be able to do link bundling based on LACP over multiple chassis (MC-LAG) in the future. Many institutions already use a form of Virtual Chassis or VSS for redundancy. MC-LAG could tie in nicely with this. This allows both interfaces that form an ESI to be active at the same time.
Figuur 5 Multi-chassis link aggregation
In addition, we are developing an L3VPN service. L3VPN is a virtual router that can be configured on SN8. This virtual router can be used, for example, to efficiently connect multiple cloud providers (MS Azure or Amazon AWS) to a setup network.
Figuur 6 L3VPN multicloud voorbeeld
Do you have any ideas or questions about these new features and functionalities? Or do you have suggestions that can help us further develop the service? Then please contact me!
