Open flow
1. Introduction.
Open flow is a new kind of protocol designed to run on Switches and routers. It’s built on a separated base between the forwarding plane and control plane joined through a secure channel. The controller, within the control plane, handles the management of the tables and traffic flow through updating, deleting and adding of flows while the forwarding plane handles traffic forwarding. Open Flow is designed in a way that the devices can separate research traffic from the normal operations traffic within a network. In this protocol a user or researcher can control his/her traffic directly through attaching the routes, actions and how it should be handled. So the ‘which traffic’ – type of traffic we are sending i.e. is it multicast, broadcast, echo requests etc, ‘where to’ – to which addresses are we sending it to ‘and how / what action’ – how should it be handled. These questions are important in running this protocol as they have to always be answered.
Open Flow propagation is based on the existing inflexibility of the available network devices in leaning towards testing new operations, protocols etc. A good example would be someone coming up with a new protocol example would be RIP v3 and would want to test it. So s/he would run it through the controller and picks the routes the traffic would have to take and also the actions to be carried out on the traffic. This can be done on all switches the traffic is to traverse while separating it from the traditional traffic in the network
Delving into those three basic parameters which should be well defined, its imperative to note that Open Flow devices should have a routing table, call it a Content Addressable Memory (CAM) table for the switches. In this table all entries should have packet headers that are used to guide the flow, an action tag on how traffic should be processed i.e. either let through or dumped and the counters that show amount of packets processed or passing through for
Open flow is a new kind of protocol designed to run on Switches and routers. It’s built on a separated base between the forwarding plane and control plane joined through a secure channel. The controller, within the control plane, handles the management of the tables and traffic flow through updating, deleting and adding of flows while the forwarding plane handles traffic forwarding. Open Flow is designed in a way that the devices can separate research traffic from the normal operations traffic within a network. In this protocol a user or researcher can control his/her traffic directly through attaching the routes, actions and how it should be handled. So the ‘which traffic’ – type of traffic we are sending i.e. is it multicast, broadcast, echo requests etc, ‘where to’ – to which addresses are we sending it to ‘and how / what action’ – how should it be handled. These questions are important in running this protocol as they have to always be answered.
Open Flow propagation is based on the existing inflexibility of the available network devices in leaning towards testing new operations, protocols etc. A good example would be someone coming up with a new protocol example would be RIP v3 and would want to test it. So s/he would run it through the controller and picks the routes the traffic would have to take and also the actions to be carried out on the traffic. This can be done on all switches the traffic is to traverse while separating it from the traditional traffic in the network
Delving into those three basic parameters which should be well defined, its imperative to note that Open Flow devices should have a routing table, call it a Content Addressable Memory (CAM) table for the switches. In this table all entries should have packet headers that are used to guide the flow, an action tag on how traffic should be processed i.e. either let through or dumped and the counters that show amount of packets processed or passing through for