Browse Prior Art Database

Adaptive Flows for SDN - Open Flow

IP.com Disclosure Number: IPCOM000236397D
Publication Date: 2014-Apr-24
Document File: 7 page(s) / 74K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a enhancement over OpenFlow specification to handle flows and events more efficiently. When any event occurs in a Open flow switch, the event is sent to controller and switch will have to wait till controller processes the event and take action. Proposed Solution will allow switch to take quicker actions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 01 of 7

Adaptive Flows for SDN - Open Flow

Adaptive Flows model for OpenFlow

    Disclosed is a enhancement over OpenFlow specification to handle flows and events more efficiently. When any event occurs in a Open flow switch, the event is sent to controller and switch will have to wait till controller processes the event and take action. Proposed Solution will allow switch to take quicker actions.

Background

    OpenFlow enables remote controllers to determine the path of data packets through the network of switches. Controller installs flow rules in the flow tables of all network nodes in the network that drive the forwarding decisions. OpenFlow Specification defines how a switch should use these flows in its flow table and forward data traffic. OpenFlow also defines on events that a OpenFlow switch need to detect and inform controller. When a switch is managed by a remote controller, the response time for any network event might be delayed.

Introduction

    In an SDN environment control plane will be available in a single centralized controller. Unlike the traditional network where each node will have a data plane and control plane. In SDN environment network nodes will have data plane and thin layer running Openflow to communicate with the controller. Controller installs flow rules in the flow tables of all network nodes in the network that drive the forwarding decisions.

    Time to react for a network event will also depend on switch to controller communication of event and processing delay in controller to process the even and take action. The proposed solution will provide better handling of network events compared to traditional OpenFlow model.

Problem:

When a OpenFlow switch is managed by controller, controller will install flows in the switch for different hosts to communicate with each other. At any given point, switch will have a flow table with match and actions. When any problem occurs, The Open Flow switch will notify controller of the problem using Error messages. Similarly, OF Switch will send port-status message when port status changes.

     Controller will receive these Events from switch and take necessary
actions. Actions can possibly be a flow install/un-install. The total latency
involved for controller to install/un-install a flow after event occurrence
will be:
total latency (TL ) = network latency 1+
controller processing latency +
network latency 2+
switch install time


*network latency1 = Latency involved when event is sent from switch to

1

Abstract



Page 02 of 7

controller

     *controller processing latency = depends on how busy controller is.
Processing delay at controller

     *network latency 2 = Latency involved in flow install/un-install to
reach switch.

     *switch install time = time taken by switch to (un)/install a flow.
Depends on number of flow mods received.

     A invalid flow might exist in the flow table for TL seconds. For example
a following flow with action as output-port = port 32 can exist in flow table
even when port status is down for max...