Transport SDN – Multi-area/Multi-AS TE
The traditional ways to build routing networks is where the SDN revolution is happening. Networks started with tight coupling between data and control planes. The control plane was distributed, meaning each node had a control element and performed its own control plane activities. SDN changed this architecture, centralized the control plane with a controller and used OpenFlow or some other protocol to communicate with the data plane. All control functions are handled by a central controller, which obviously has many scaling drawbacks. Now, we seem to me moving to a scalable hybrid control plane architecture. Hybrid control plane is a mixture of distributed and centralized. Centralization offers global visibility, better network operations and optimizations. A distributed control remains best for specific use-cases, for example IGP convergence. More importantly, a centralized element introduces additional value to the Wide Area Network (WAN) network such as Traffic Engineering (TE) placement optimization aka Transport Software Defined Networking (SDN).
SDN has two buckets, the Wide Area Network (WAN) and the Data Centre (DC). There is a difference with what SDN is trying to achieve in the WAN than what it is trying to achieve in the DC. Within the DC, every point is connected together and you can assume unconstrained capacity. A common data centre design is a leaf and spine architecture, where all nodes have equidistant endpoints. This is not the case in the WAN. The WAN has completely different requirements and must meet SLA with less bandwidth. The requirement deriving from the WAN and data centre are completely different, resulting in two SDN models. The SDN data centre model builds logical network overlays over fully meshed unconstrained physical infrastructure. The WAN does not follow this model. The SDN DC model aims to replace, while the SDN WAN model aims to augment. We can evolve the IP/MPLS control plane to a hybrid control plane. We go from a fully distributed control plane architecture where we maintain as much of the distributed control plane as it makes sense (convergence). At the same time produce a controller than can help you enhance the control plane functionality of the network and interact with applications. Global optimization of traffic engineering offers many benefits.
WAN is all about SLA
Service Providers offer Service Level Agreement (SLA) assurance ensuring sufficient capacity relative to the actual offered traffic load. The goal of Traffic Engineering (TE) is to ensure there is sufficient capacity to deliver the promised SLA, routing customers traffic where the network capacity is. Some WAN SP use point-to-point LSP TE tunnels for individual customer SLA’s.
WAN networks are all about SLA’s and there are a number of ways to satisfy them – Network Planning & Traffic Engineering. The better planning you do the less TE you need. However, planning requires accurate statistics of traffic flows in order to fully understand the network’s capabilities. Sometimes an accurate network traffic profile doesn’t exist and many networks are vastly over provisioned.
Netflow is one of the most popular way to measure your traffic mix. Routers collect “flow” information and export the data to a collector agent. There are different approaches to aggregate flows depending on the netflow version. Netflow version 5 is the most common and version 9 offers MPLS aware netflow. BGP Policy Accounting and Destination Class Usage enables routers to collect aggregated destination statistics (limited to 16/64/126 buckets). BGP permits accounting for traffic mapping to destination address. For MPLS LSP we have LDP and RSVP-TE. Both LDP and RSVP-TE have inconsistencies in vendor implementations and RSVP-TE requires a full mesh of TE tunnels. Is this good enough or can we use SDN tools to enhance and augment existing monitoring? Juniper NorthStar central controller offers nice end-to-end analytic.
The real problem comes with TE. IP routing is destination based and path computation is based on an additive metric. Bandwidth availability is not taken into account. Some links may be congested, others underutilized. By default, the routing protocol has no way of knowing this. The main traditional approaches to TE are MPLS TE and IGP Metric based TE. Varying the link metric just moves the problem around, however you can tweak metrics to enable ECMP, spreading traffic via a hash algorithm over dispersed paths. ECMP is good for local path diversity but we are still lacking the global visibility for optimum end-to-end TE. Having a centralized-control improves the distribution-control insufficiency needed for optimal path computation for Multi-area/Multi-AS TE.
BGP-LS & PCEP
OpenDaylight is a SDN infrastructure controller that enhances the control plane; offering a service abstraction layer. It carries out network abstraction of whatever service exist on top of the controller. Then on top of that there are API enabling applications to interface with the network. Its supports BGP-LS and PCEP; two protocols commonly used in transport SDN framework.
BGP-LS makes BGP an extraction protocol.
The challenge is that the contents of a Link State Database (LSDB) and an IGP’s Traffic Engineering Database (TED) describe only the links and nodes within that domain. When there is a requirement for end-to-end TE capabilities through a multi domain and multi protocol architecture, TE applications require visibility outside one area in order to make better decisions. New tools like BGP-LS and PCEP combined with a central controller enhance TE and provide multi domain visibility.
We can improve the IGP topology by extending BGP to BGP Link-State. This wraps up the LSDB in BGP transport and pushes to BGP speakers. It’s a useful extension used to introduce link state into BGP. PCEP was introduced by vendors 2005 to solve the TE problem. Initially, it was stateless but now available in a stateful mode. PCEP address path computation is multi-domain and multi-layer networks. Its main driver was to decrease the complexity around MPLS and GMPLS traffic engineering. In complex typologies, the constrained shortest path first (CSPF) process was not sufficient. Dijkstra-based link state routing protocols suffer from what is known as bin-packing, where they don’t take into consideration network utilization as a whole.