Software-defined networks

A software-defined network (SDN) optimizes and simplifies network operations by closely tying applications and network services, whether real or virtual. By establishing a logically centralized network control point (typically an SDN controller), the control point orchestrates, mediates, and facilitates communication between applications that wish to interact with network elements and network elements that want to communicate information with those applications. The controller exposes and abstracts network functions and operations through modern, application-friendly, bidirectional programmatic interfaces.

As a result, software-defined, software-driven, and programmable networks have a rich and complex history and various challenges and solutions to those challenges. Because of the success of technologies that preceded them, software-defined, software-driven, and programmable networks are now possible.IP, BGP, MPLS, and Ethernet are the fundamental elements of most networks worldwide.

Control and Data Plane Separation

SDN’s early proponents advocated separating a network device’s control and data planes as a potential advantage. Network operators benefit from this separation regarding centralized or semi-centralized programmatic control. As well as being economically advantageous, it can consolidate into a few places, usually a complex piece of software to configure and control, onto less expensive, so-called commodity hardware.

One of SDN’s most controversial tenets is separating control and data planes. It’s not a new concept, but the contemporary way of thinking puts a twist on it: how far should the control plane be from the data plane, how many instances are needed for resiliency and high availability, and if 100% of the control plane can be moved beyond a few inches are all intensely debated. There are many possible control planes, ranging from the simplest, the fully distributed, to the semi- and logically centralized, to the strictly centralized.

OpenFlow Matching

With OpenFlow, the forwarding path is determined more precisely (matching fields in the packet) than traditional routing protocols because the tables OpenFlow supports more than just the destination address. Using the source address to determine the next routing hop is similar to the granularity offered by PBR. In the same way that OpenFlow would do many years later, PBR permits network administrators to forward traffic based on “nontraditional” attributes, such as the source address of a packet. However, it took quite some time for PBR-forwarded traffic for network vendors to offer equivalent performance, and the final result was very vendor-specific.

The Role of SDN Solutions

Most existing SDN solutions are aimed at cellular core networks, enterprises, and the data center. However, at the WAN edge, SD-WAN and WAN SDN are leading a solid path, with many companies offering a BGP SDN solution augmenting natural Border Gateway Protocol (BGP) IP forwarding behavior with a controller architecture, optimizing both inbound and outbound Internet-bound traffic. So, how can we use these existing SDN mechanisms to enhance BGP for interdomain routing at Internet Exchange Points (IXP)?

The Role of IXPs

IXPs are location points where networks from multiple providers meet to exchange traffic with BGP routing. Each participating AS exchanges BGP routes by peering eBGP with a BGP route server, which directs traffic to another network ASes over a shared Layer 2 fabric. The shared Layer 2 fabric provides the data plane forwarding of packets. The actual BGP route server is the control plane to exchange routing information.

For additional pre-information, you may find the following posts helpful:

1. Ansible Variables
2. Open Networking
3. Software Defined Perimeter Solutions
4. Distributed Solutions
5. Full Proxy

Back to basics with the Internet Exchange.

An Internet exchange point (IXP) is a physical location through which Internet infrastructure companies such as Internet Service Providers (ISPs) and CDNs connect. These locations exist on the “edge” of different networks and allow network providers to share transit outside their network. IXPs will run BGP.

Also, it is essential to understand that Internet exchange point participants often require that the BGP NEXT_HOP specified in UPDATE messages be that of the peer’s IP address, as a matter of policy.

Benefits of SD-IX:

1. Enhanced Performance: SD-IX enables organizations to bypass the public internet and establish direct peering connections with ISPs. By reducing the number of network hops and congestion points, SD-IX improves network performance, resulting in lower latency and faster data transfer speeds.

2. Improved Reliability: SD-IX allows organizations to create redundant connections with multiple ISPs, ensuring high availability and resilience. In an ISP outage, traffic can be seamlessly rerouted through alternate connections, minimizing downtime and ensuring continuous connectivity.

3. Cost Efficiency: SD-IX eliminates the need for physical infrastructure and costly cross-connect fees by virtualizing the interconnection process. Organizations can leverage SD-IX to establish private interconnections with multiple ISPs at a fraction of the cost, significantly reducing network expenses.

4. Scalability and Flexibility: SD-IX allows organizations to scale their network connections on demand. Adding or removing connections can be complex and time-consuming with traditional interconnections. SD-IX simplifies this process by allowing organizations to provision and manage connections through a centralized portal, enabling rapid network expansion or modification.

5. Enhanced Security: SD-IX enables organizations to establish private, direct connections with ISPs, reducing exposure to potential security threats associated with the public internet. By bypassing the public internet, SD-IX provides a secure and controlled environment for data transfer, ensuring confidentiality and integrity.

Route Server

A route server provides an alternative to full eBGP peering between participating AS members, enabling network traffic engineering. It’s a control plane device and does not participate in data plane forwarding. There are currently around 300 IXPs worldwide. IXPs are good locations to deploy SDN of their simple architecture with flat networks.

There is no routing for forwarding, so there is a huge need for innovation. They usually consist of small teams, making innovation easy to introduce. Fear is one of the primary emotions that prohibit innovation, and one thing that creates fear is Loss of Service.

This is quite significant for IXP networks, as they may have over 5 Terabytes of traffic per second. IXPs are major connecting points, and a slight outage can have a significant ripple effect.

• A key point. Internet Exchange Design

SDX, a software-defined internet exchange, is an SDN solution from the combined efforts of Princeton and UC Berkeley. It aims to address IXP pain points (listed below) by deploying additional SDN controllers and OpenFlow-enabled switches. It doesn’t try to replace the entire classical IXP architecture with something new but rather augments existing designs with a controller-based solution, enhancing IXP traffic engineering capabilities. However, the risks associated with open-source dependencies shouldn’t be ignored.

Software Defined Internet Exchange: IXP Pain Points

BGP is great for scalability and reducing complexity but severely limits how networks deliver traffic over the Internet. One tricky thing to do with BGP is good inbound TE. The issue is that IP routing is destination-based, so your neighbor decides where traffic enters the network. It’s not your decision.

The forwarding mechanism is based on the destination IP prefix. A device forwards all packets with the same destination address to the same next hop and the connected neighbor decides.

 The main pain points for IXP networks:

As already mentioned, routing is based on the destination IP prefix. BGP selects and exports routes for destination prefixes only. It doesn’t match other criteria in the packet header, such as source IP address or port number. Therefore, it cannot help with application steering, which would be helpful in IXP networks.

Secondly, you can only influence direct neighbors. There is no end-to-end control, and it’s hard to influence neighbors that you are not peering. Some BGP attributes don’t carry across multiple ASes; others may be recognized differently among vendors. We also use a lot of de-aggregation to TE. Everyone is doing this, which is why we have the problem of 540,000 prefixes on the Internet. De-aggregation and multihoming create lots of scalability challenges.

Finally, there is an indirect expression of policy. Local Preference (LP) and Multiple Exit Discriminator (MED) are ineffective mechanisms influencing traffic engineering. We should have better inbound and outbound TE capabilities. MED, AS Path, pretending, and Local Preference are widely used attributes for TE, but they are not the ultimate solution.

They are inflexible because they can only influence routing decisions based on destination prefixes. You can not do source IP or application type. They are very complex, involving intense configuration on multiple network devices. All these solutions involve influencing the remote party to decide how it enters your AS, and if the remote party does not apply them correctly, TE becomes unpredictable.

SDX: Software-Defined Internet Exchange

The SDX solution proposed by Laurent is a Software-Defined Internet Exchange. As previously mentioned, it consists of a controller-based architecture with OpenFlow 1.3-enabled physical switches. It aims to solve the pain points of BGP at the edge using SDN.

Transport SDN offers direct control over packet-processing rules that match on multiple header fields (not just destination prefixes) and perform various actions (not just forwarding), offering direct control over the data path. SDN enables the network to execute a broader range of decisions concerning end-to-end traffic delivery.

 How does it work?

What is OpenFlow? Is the IXP fabric replaced with OpenFlow-enabled switches? Now, network traffic engineering is based on granular OpenFlow rules. It’s more predictable as it does not rely on 3rd party neighbors to decide the entry. OpenFlow rules can be based on any packet header field, so it’s much more flexible than existing TE mechanisms. SDN-enabled data plane enables networks to have optimal WAN traffic with application steering capabilities. 

The existing route server has not been modified, but now we can push SDN rules into the fabric without requiring classical BGP tricks (local preference, MED, AS prepend). The solution matches the destination MAC address, not the destination IP prefix, and uses an ARP proxy to convert the IP prefixes to MAC addresses.

The participants define the forwarding policies, and the role of the controller is to compile the forwarding entries into the fabric. The SDX controller implementation has two main pipelines: a policy compiler based on Pyretic and a route server based on ExaBGP.

The policy compiler accepts input policies (custom route advertisements) written in Pyretic from individual participants and BGP routes from the route server. This produces forwarding rules that implement the policies.

The SDX controller combines the policies from multiple member ASes into one policy for the physical switch implementation. The controller is like an optimized compiler, compiling down the policy and optimizing the code in the forwarding by using a virtual next hop. There are other potential design alternatives to SDX, such as BGP FlowSpec. But in this case, BGP FlowSpec would have to be supported by all participating member AS edge devices.

As the demand for high-performance and reliable internet connectivity continues to grow, SD-IX is poised to play a pivotal role in shaping the future of networking. By virtualizing the interconnection process and providing organizations with unprecedented control and flexibility over their network connections, SD-IX empowers businesses to optimize their network performance, enhance security, and reduce costs. With its ability to scale on-demand and seamlessly reroute traffic, SD-IX is well-suited for the evolving needs of cloud-based applications, IoT devices, and emerging technologies such as edge computing.

Software Defined Internet Exchange represents a paradigm shift in how organizations connect to the Internet. By virtualizing the interconnection process and providing enhanced performance, reliability, cost efficiency, scalability, and security, SD-IX offers a compelling solution for businesses seeking to optimize their network infrastructure. As the digital landscape continues to evolve, SD-IX is set to revolutionize the way we connect to the internet, enabling organizations to stay ahead of the curve and unlock new possibilities in the digital era.