Interface to the Routing System: In the Background
An SDN Blog by Russ White
Through this (probably far too long) series on SDNs, we have looked at BGP, Fibbing, and Openflow. BGP and Fibbing would be described as augmented control planes; the distributed control plane is not replaced, but rather augmented with a controller that modifies the best path decisions of the control plane by interacting with the control itself in a somewhat “native” way.
Openflow, on the other hand, replaces the distributed control plane; it would actually be difficult to build a system that talks directly to the FIB that does not entirely replace the control plane. But in the original classification, there was a third type of SDN highlighted, a hybrid model. Are there any instances of this sort of model being developed?
Yes, there is: the Interface to the Routing System (I2RS), currently under development by the IETF (you can find the working group page here). The objective of I2RS is to provide a near real time interface into the routing table. By taking one step back from the table the hardware actually uses to forward packets, I2RS allows distributed protocols to co-exist alongside a more centralized controller. Hybrid mode allows the operator to replace as much—or as little—of the distributed control plane with a more centralized overlay as they would like to.
Perhaps a use case might be useful to set the stage for a more operational look at the architecture of I2RS. Use cases mean network diagrams, of course, like the one below.
In this rather simple network, D is a botnet that is being used to attack the server at A. B and C are an external peering point, and E is a legitimate customer. How can you block the attack without blocking the legitimate traffic? Given there is some way to differentiate the legitimate traffic from the attack traffic (perhaps a questionable assumption in some cases), the most natural way to block the attack traffic would be at C (or even before), but given this is a provider’s network, we would normally settle for blocking the traffic at B. The problem is, of course, that the attack is most readily detectable at A. It is possible, of course, to install some sort of system that would detect the attack without A being involved, but any such system is going to be slower and less accurate than any system that actually resides at A itself.
What is needed here is some way for A to detect the attack and then signal B about which streams need to be blocked. This is simple enough, of course, using BGP and flowspec—if A runs BGP, that is. What if A must interface with some sort of controller that validates the policy before it can be implemented? Suddenly BGP+flowspec becomes somewhat more like a hack, and less like a clean, scalable solution.
I2RS can easily step into this gap, as it is YANG based, near real time, and describes routing information directly, outside the semantics of a routing protocol. Using I2RS, A could send a message to a controller (not shown in the network), marshalled using YANG, which could then be validated, and injected directly into the routing table at B. Since BGP, and any other routing protocols, are (or at least can be, if they choose to be) aware of what is being installed in the routing table, the I2RS injected information can be “seen” by the other local routing processes.
So far, then, you should be able to figure this much out: I2RS is a YANG based set of models, protocols, and architectures that provide near real time access to the routing table (not the forwarding table) in the routing system. We’ll look at the architecture of I2RS a little more closely in the next post in this series.