OpenFlow and Ipsilon: Nothing New Under the Sun


I found a great overview of IP+ATM solutions in an article published on the University of Washington web site. This is what the article has to say about Ipsilon’s approach (and if you really want to know the details, read GSMP (RFC 1987) and Ipsilon Flow Management Protocol (RFC 1953)):

An IP switch controller routes like an ordinary router, forwarding packets on a default VC. However, it also performs flow classification for traffic optimization.

Replace IP switch controller with OpenFlow controller and default VC with switch-to-controller OpenFlow session.

Once a flow is identified, the IP switch sets up a cut-through connection by first establishing a VC for subsequent flow traffic, and then by asking the upstream node to use this VC.

Likewise, some people propose downloading 5-tuples or 12-tuples in all the switches along the flow path. The only difference is that 15 years ago engineers understood virtual circuit labels use fewer resources than 5-to-12-tuple policy-based routing.

As expected, Ipsilon’s approach had a few scaling issues. From the same article:

The bulk of the criticism, however, relates to Ipsilon's use of virtual circuits. Flows are associated with application-to-application conversations and each flow gets its very own VC. Large environments like the Internet with millions of individual flows would exhaust VC tables.

Not surprisingly, a number of people (myself included) that still remember a bit of the networking history are making the exact same argument about usage of microflows in OpenFlow environments ... but it seems RFC 1925 (section 2.11) will yet again carry the day.

An hour after publishing this blog post, I realized (reading an article by W.R. Koss) that Ed Crabbe mentioned Ipsilon being the first attempt at SDN during his OpenFlow Symposium presentation.


  1. Those who do not know history ... Your article sims up one of my big concerns re open flow, the other being central control vs distributed and speed / scalability.

  2. upon all my memory and knowledge, the centralized control model only works with connection-oriented systems, where the control plane is not that 'busy'. And actually that model has it's own pain, e.g. the reachability of the controller to all service node, the availability of the controller. I think Nicira is more clever in this, they just leverage the general model and framework of it, but actually mainly use it for management plane.

  3. Cisco already has Pfr...that somewhat resembles SDN... :-)


