OpenFlow did not introduce any new (or revolutionary) ideas. FORCeS has been around for a while (with almost zero traction), and concepts similar to reactive flow setup were floated in 1990’s and failed miserably. For more details, read Flow-Based Packet Forwarding.

Not surprisingly, the flow-based forwarding ideas floundered (yet again) in the decade since I wrote this blog post. There are few hardware implementations, and even virtual switches experienced severe performance penalty when trying to use so-called microflows.

I’d promised to record another MPLS-related podcast and wanted to refresh my failing memory and revisit the beginnings of Tag Switching (Cisco’s proprietary technology that was used as the basis for MPLS). Several companies were trying to solve the IP+ATM integration problem in mid-nineties, most of them using IP-based architectures (Cisco, IBM, 3Com), while Ipsilon tried its luck with a flow-based solutions.

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.