OpenFlowMPLS Design Philosophy

From OpenFlow Wiki

This page is no longer maintained. For up to date information on the OpenFlow MPLS Extension, please visit the main page and the pages linked from there: OpenFlowMPLS.

Philosophy Behind Our Design

Protocol and Application Agnostic:
The main advantage of taking our proposed approach is that it is Protocol and Application agnostic. Not only will this work for MPLS, but for other tunneling protocols such as GRE, or L2TP. It will also work for L2 protocols such as PBB, and applications such as VPLS. Variants such as Nested LSPs are handled as well in the same manner. Our goal is to make the switch as protocol/application unaware as possible. Instead the protocol and applications reside in the controller only.

Specification vs. Implementation:
Our Specification is Implementation independent (aka Platform Independent), as a specification should be. At the same time, we do leverage our extensive experience with implementations to make sure that our specification is not devised in vacuum. We have gone to pains to make sure that the implementations will have the flexibility to address their own specific constraints and optimizations while working within the boundaries of the specification.

Flow & Port Table Workings:
The current OF spec (v1) only defines the Flow Table. The outgoing ports are represented by a bit map of ports. This will not be enough to handle certain functionality that is in common use. For example IP Multicasting will require that a packet be replicated to multiple outgoing VLANs. OFv1 cannot handle that, because the FT can specify only one outgoing VLAN. Other examples that will not work include VPLS, Point-to-Multipoint Tunnels etc.

Today, all packet processing in the OF architecture is specified in the FT. There is a “mention” of a Virtual Port, but it is NOT defined anywhere. It is clear that that the term Virtual Port is being used as a Place Holder . It is used in an “abstract” way to explain functionality that in reality is not possible or even exists in OF today.

At Ericsson Research we are in the process of defining and implementing MPLS capability for OF. Therefore we don’t have the luxury of treating the Virtual Port as a vague notion that will somehow provide the functionality that is required by tunneling (such as Nested Tunnels, VPLS, FRR etc).

The Virtual Port Table (VPT), as described earlier, extends the architecture in a manner that is very similar to the Flow Table. One can think of the VPT as the FT for packets as they egress the box. It is a symmetrical manifestation of the FT. Instead of matching on various fields of the packet, a VPT is indexed by the VP handle. This makes it easier to implement and cheaper. It can be thought of as the match on the VP index.

Hierarchical Virtual Ports (aka Port Chaining):
The VP entry yields a set of table actions very much like the FT entry does. These actions are necessary to put the packet on the port. One important capability of the VPT is the optional chaining of VP entries. This allows for Hierarchical Ports. For example a PW port will be chained to its parent Tunnel port, which is chained to its parent physical port.

Port Chain Short Circuits:
Port chaining is a powerful concept that can handle any complexity of encapsulations. But it comes at a price. It is essentially a linked list and that means that its processing takes O(n). This is not acceptable for the typical cases of encapsulation. The forwarding path processing is sacred for the typical cases since it impacts the Line Rate. Therefore we allow that a VP entry can short cut the chain. It does so, by compressing the actions of all the chain into one entry. For example a PW port can push the VPN and Tunnel labels from one entry to avoid chaining. Another example would be where a Tunnel over a Link Bundle, keeps the cached active or hashed constituent of the bundle in the Tunnel entry.

Outgoing Port List:
The Port Table also contains the block of Outgoing Port Lists (OPLs). The OPL is used for replication, which is required in a number of applications such as Multicast, VPLS etc. Each replication will represented by an entry, and all the entries of a particular OPL will be contiguous. The last replication entry in the OPL will have EOL (End Of List) flag.

On Demand Virtual Ports:
Typically a VP will be setup preemptively, either by configuration, or signaling. However the spec does allow the creation of VPs on the fly, or on demand.

An example is show below:

Initial tunnel egress entry (Tunnel VP):

The above Flow Table entry embodies the Tunnel VP. Now if a Subscriber flow egresses the tunnel it will get punted to the controller, which will install the specific entry for it:

The more specific entry above is also a VP, in a hierarchy of ports. In this case, the new on demand VP is a Subscriber VP.

The ability to increase the match specificity allows us to de-capsulate and forward in a single lookup cycle.

Flow Table vs. Port Table:
As presented so far Flow Table and Port Table have identical actions. Some people have pushed back that certain new actions required for encapsulation/decapsulation (such as push/pop) should not be added to the Flow Table. This is understandably so since this is motivated by a desire to keep the new functionality quarantined in the new entity described as the Port Table. The case has also been made that we can defer the action to the port table, so why add it to the flow table.

The author strongly disagrees with the above argument. There is no technical reason for quarantining the new actions required for tunneling to the port table. On the other hand common functionality in both tables helps with a number of cases. For example, in the case of VPNs, an incoming packet can immediately be tagged with its VPN label in the flow table, thereby establishing the context for the packet before it gets injected into the switch fabric. In this manner the outgoing virtual port is the common transport tunnel (transporting all PWs) as opposed to a PW. Since a box can have 10s of thousands of VPNs, this can lead to a big saving in the Port Table size and complexity. It also simplifies the management of entries by the controller.

By providing symmetry between the Flow Table and Port Table, the architecture provides the necessary flexibility to the switch implementer, without introducing unique functionality for the two tables.

Ingress and Egress Flow Tables:
Finally the author is going to make a very strong case that the Port Table should really be the same as the Flow Table. The port table that has been described so far is really an Economical Flow Table, since the match is only on the outgoing port. While this works for the use cases presented so far, there are many important functions that require that the Port Table should be the same as the Flow Table. Examples include Outbound ACLs, Lawful Intercept, Multi-Stage Forwarding etc. Lawful intercept is an example of functionality where the Government requires that it be supported for sale to carriers. Port Chaining will still be required for Port Hierarchy, Multicast etc.

The spec should provider the flexibility for an implementation to choose the level of complexity in the Port Table depending upon the market niche it is addressing. The range would be from:

• No Port Table (support only L2 and unicast L3/L4 functionality)
• Economical Port Table (adds tunneling and L3 multicast)
• Egress Flow Table (adds Outbound ACLs, LI, Multi-Stage Forwarding etc.)