The aerodynamics of routing
Enzo Ferrari once stated, “Aerodynamics are for people that can’t build engines”. To be fair, the 1960 quote was to Paul Frère in answer to why he felt his 250TR’s ugly windscreen was limiting his top speed at Le Mans. At that time, Enzo was like most in putting in a bigger engine to try and defeat any aerodynamic advancements of the day.
Similarly, historically adding a bigger routing fabric, more memory, and more compute power (CPU) have pretty much enabled network operators to expediently route packets for almost any IP routed service. With the unprecedent demand in services and scale, that’s all about to change, as operators must simplify End-to-End (E2E) traffic and services across segmented network infrastructures.
In a previous article I wrote about how static and dynamic routing works for an Autonomous System (AS). However, when routing packets from source to destination across multiple networks IP routing is used.
For example: Have you ever sent a piece of registered (snail) mail and tracked it, only to notice it took rather odd stops or hops at various locations along its journey? Well that’s very similar to how IP routing works on the Internet. There is no path or instruction when the router receives an IP packet, only the destination address.
Each routing engine (CPU) has to make an independent forwarding decision for each packet, based on the network-layer header in a routing table stored in Random Access Memory (RAM). Each router’s complex routing tables are used to tell the packet where the next hop is, repeating this process until the packet eventually arrives at its final destination. All these hops, individual routing decisions, and buffering result in poor and unpredictable performance for time-sensitive applications.
A bigger routing engine doesn’t mean better performance.
Moving packets from source to destination across multiple networks can be complex and difficult, but just adding a bigger (router) engine won’t necessarily make how routers communicate with each other more efficient.
For management and supervision, IP networks are grouped into an AS, which can be public and/or private routers/networks using either static or dynamic routing. Here are some of the advantages and disadvantages for Static Routing:
Static Routing Advantages & Disadvantages
As a network operator, with static routing, you must enter “all” routes and tell every static router or IP network what the next hop traffic is delivered to. For small networks, three or less routers, static works just fine. For large networks static routing doesn’t scale, is too operationally complex and expensive to maintain. A dynamic routing protocol can resolve these concerns.
As a network operator, with dynamic routing, you configure the interface with a routing protocol, that routing protocol (within its limits) automatically learns routes by exchanging routing table information between itself and other routers such that they always have the up-to-date routes. Each router learns from the each other about networks they are connected to.
As illustrated below, dynamic routing is broken into Interior Gateway Protocol (IGP) and Exterior Gateway Protocol (EGP), and their respective routing protocols.
IGP protocols are used to route traffic within an AS, while EGPs route traffic between autonomous systems. In some cases, a link-state protocol can be used between ASs, but not for very large networks. Here are some of the advantages and disadvantages for dynamic routing:
Dynamic Routing Advantages and Disadvantages
Dynamic routing protocols provide operational simplicity, automated routing updates, and change notifications. For E2E services dynamic routing for IGP does not scale well, must be “stitched” between each AS or IP network domain, and is expensive and complex to manage, maintain, and troubleshoot.
One way to scale a very large network with multiple IGP domains is to use seamless Multiprotocol Label Switching (MPLS). By encapsulating all services as an E2E Label Switched Path (LSP), seamless MPLS simplifies network provisioning, operations, and maintenance. IGP ASs were never designed to support 100,000s of IP prefix (IP address + bit mask), while ERP (BGP) was designed to support the Internet with 100,000s of routes and millions of MPLS-VPN entries.
Network operators traditionally build two networks, one for wireline and the other for wireless, each with multiple Ethernet and MPLS aggregation access networks.
Traditional Wireless and Wireline Network Topology
Converging access, aggregation, metro, and core to a seamless MPLS network, simplifies provisioning, operations, and maintenance with E2E Pseudowire Emulation (PWE) Label Switched Path (LSP), as illustrated below.
Seamless MPLS Network
To offer true E2E connectivity, having seamless MPLS as an underlay eliminates manual stitching of the underlay boundaries from two or more ASs, ensuring seamless and boundary-less connectivity.
The good news is Ethernet, MPLS, L2, L3, and Private Line Services no longer need to be separated. PWE from Ciena’s 3926m and 6500 PTS platforms can be used to connect E2E services or to the Core using iBGP to scale and Targeted Label Distribution Protocol (T-LDP) to signal service labels for the service tunnel.
History, however, has shown that both horsepower and aerodynamics play vital roles in performance. While horsepower enables speed, aerodynamics makes the car more drag efficient and can provide down force. Down force improves the cars grip, but also increases drag, limiting your top speed. One way of reducing drag is to apply active aerodynamics, like an openable rear wing to reduce drag and downforce when you don’t need it.
Network operators can aerodynamically route existing and new services using seamless MPLS at scale, reduce network complexity, and provide (new) service velocity.
So, get ready to reduce network drag and connect all your network services across a single network, providing a migration to the future for legacy services, and enabling new opportunities.
Ask us how Ciena helps Evolutionize Your Packet Network.
Thank you. Your comment has been received and should appear on the blog shortly.