Editorial Staff
In this two-part blog series, we cover how traffic engineering has evolved over the years from an offline model, performed with the help of external network planning tools, to the on-device model in use today. In part two, we’ll outline the challenges of this on-device model based on RSVP-TE and how SDN can help.
These articles are based on an APRICOT presentation our CTO Cengiz Alaettinoglu gave earlier this year in Ho Chi Minh City, Vietnam. They were originally published as one article in the APNIC blog under the title “Overcoming traffic engineering challenges with SDN.”What’s the goal when a network provider invests in building their network infrastructure? To build a scalable network that can handle current as well as future traffic demand, with as few upgrades and capital expenditures as possible.
Traffic engineering is the technology that network providers use when they need to optimize their existing IP/MPLS networks and provide more services to customers. Most IP networks use hop-by-hop based routing where the shortest path between a source and destination is used to route packets, even when the shortest path is not the best performing one. Traffic engineering allows the provider to ignore the shortest path rule by sending traffic over longer but less congested links. This helps alleviate network congestion and maximizes the use of the existing network infrastructure.
The Traffic Engineering Evolution
Offline Model
The early implementations of traffic engineering used an offline model, which involved loading the current network topology and traffic demand matrix into a planning tool that calculated the best paths using optimization algorithms. But this offline model could not handle the network changes efficiently enough due to several challenges.
The biggest issue came from having to add the network topology into the planning tool. This is easy in a network with only a handful of routers, but the process of manually adding the topology of a network with several hundreds or even thousands of routers is a major challenge.
The difficulty became even greater when the network topology changed before the next traffic engineering adjustments. This meant that the next change required adding the updated topology and once again calculating the traffic demand matrix. The other challenge was how long it took the optimization algorithms to calculate new paths, which typically ranged from a few hours to even a couple of days in very large networks. All this meant that when a link failure caused congestion, the network provider could not find alternate paths quickly enough for their customers and resulted in customers possibly moving away to competition.
On-Device Traffic Engineering
Next came on-device traffic engineering using RSVP-TE and the constraint based shortest path first (CSPF) algorithm. This involved the router, rather than external planning tools, managing the traffic engineering function. This method leverages the behavior of IGP routers, where they flood the available link bandwidth through the network. Traffic engineering tunnels are then set up between a source and destination router, and the utilization on these tunnels is monitored to understand the traffic demand matrix.
When congestion is caused on a tunnel because of increased utilization, the headend router of the tunnel runs its CSPF algorithm to re-optimize the path. It then uses RSVP-TE to signal the new path to the other routers along the path. The CSPF algorithm used here is extremely fast, and because this model works from the routers themselves, the network topology is readily available. This allows it to respond in real time and overcome the limitations of offline traffic engineering. This is especially useful in alleviating congestion that is caused by link failures.
While RSVP-TE made it much easier and faster than the offline model to perform traffic engineering tasks, it also created other challenges. In our next post, we will discuss the challenges with RSVP-TE and how SDN can help address them.
Add comment