Interaction of OpenFlow with PCE (17-Nov-2009)

Interaction of OpenFlow with PCE

Idea: Klaus Hoffmann

The following article is related to the PCE (Path Computation Element) technology. PCE is addressed within IETF (Internet Engineering Task Force) to define path computational elements, which is a growing field. The occurrences of optimized ETE (End To End) path creation leads to the need for distributed PCC (Path Computation Client) and PCE (Path Computation Element). A general external PCE node as known in prior art is shown in Figure 1.

In the field of network engineering, transport networks gain in importance. A number of RFC's (Request For Comment) related to PCE are published in prior art. Furthermore the OpenFlow standard suggests a kind of separation of the control and forwarding plane.

As it is anticipated that the OpenFlow standard will minimize the cost for the forwarding of packets on the data plane since this can easily be provided by competitors, the OpenFlow architecture will soon be incorporated into the future architecture of telecommunication networks. But with the separation of control and data plane the PCE algorithms need to be updated for optimized path computation. In the following a solution to the said problem is provided.

In prior art the OpenFlow standard documented the separation of control- and dataplane. An OpenFlow switch communicates with a controller over a secure connection using the OpenFlow protocol as shown in Figure 2.

Combing the PCE architecture with the OpenFlow approach leads to an architecture shown in Figure
3. As shown, the PCC is also used as OpenFlow controller of the switching matrix in the Data plane and may lose connection to the switching matrix and vice versa.

However, it may still happen that the forwarding of the packets in the data plane is fully functional and the adjacent node does not detect any loss of packets on the data plane. Therefore there is no need to reroute the current traffic, since the data plane forwarding in the switching matrix may be functional but new requests to change the switching matrix via OpenFlow will fail.

But in case a service request arrives at the PCC (which is in this proposal also the Head-end node), the PCC/OpenFlow controller cannot modify the switching matrix for new labels/tunnels to be created since the connectivity was lost between PCC and the switching matrix.

Therefore, the PCE may have had computed a path traversing the said PCC which does not have connection to the switching matrix. This is a waste of CPU (Central Processing Unit) time in the PCE because the Service request cannot be successfully served and needs to be rejected. That means that the PCE needs to be consulted a second time for creating an alternative path.

For the solution of the described problem an architecture is proposed that is schematically shown in Figure 4.

Once the PCC/OpenFlow controller d...