[c] keyword volatile

[c] keyword  volatile


Ref :
http://freestyler.pixnet.net/blog/post/23872864

[sdn][openflow] OpenFlow protocol primer : Looking under the hood

[sdn][openflow] OpenFlow protocol primer : Looking under the hood


OpenFlow protocol operations

The OpenFlow specification defines a protocol between the controller and the switches and a set of operations on the switches. The controller-to-switch protocol runs over either Transport Layer Security (TLS) or an unprotected TCP connection. Commands from the controller to the switch specify how packets are to be forwarded and configures parameters such as VLAN priorities. Messages from switches inform the controller when links go down or when a packet arrives with no specified forwarding instructions.

Forwarding instructions are based on a flow, which consists of all packets sharing a common set of characteristics. A large variety of parameters can be specified to define a flow. Possible criteria include the switch port where the packet arrived, the source Ethernet port, source IP port, VLAN tag, destination Ethernet or IP port, and a number of other packet characteristics. The controller specifies to the switch the set of parameters that define each flow and how packets that match the flow should be processed.

Each switch maintains a number of flow tables, with each table containing a list of flow entries. Each flow entry contains a match field that defines the flow, a counter and a set of instructions. Entries in the match field contain either a specific value against which the corresponding parameter in the incoming packet is compared or a value indicating that the entry is not included in this flow’s parameter set.

Flow tables are numbered beginning with table zero, with incoming packets first compared to flow table entries in table zero. When a match is found, the flow counter is incremented and the specified set of instructions is carried out.

A new flow must be created when a packet arrives that does not match any flow table entry. The switch may have been configured to simply drop packets for which no flow has been defined, but in most cases, the packet will be sent to the controller. The controller then defines a new flow for that packet and creates one or more flow table entries. It then sends the entry or entries to the switch to be added to flow tables. Finally, the packet is sent back to the switch to be processed as determined by the newly created flow entries.

Flow table instructions modify the action set associated with each packet. Packets begin processing with an empty action set. Actions can specify that the packet be forwarded through a specified port or modify packet TTL, VLAN, MPLS tags or packet QOS.

Instructions in the first flow table may carry out an action on the packet or add actions to be carried out later. Instructions may also direct packet processing to continue by comparing it to entries in another flow table. A flow entry in a subsequent table may contain instructions that add further actions, delete or modify actions added earlier or carry out actions.


An instruction may also add a value called metadata to a packet before sending it to the next flow table. That value becomes an additional parameter to be matched against the metadata value in flow table entries in the next table. Processing continues table by table until all specified instructions have been completed and the packet has been forwarded.

An instruction may specify a group identifier. Groups provide an efficient way to direct that the same set of actions must be carried out on multiple flows. Group operations are defined within the switch by entries in the group table. Each entry consists of its identifier value, a group type, a counter and a set of action buckets. Group type specifies whether all action buckets should be executed, which is useful for implementing broadcast or multicast, or that only specific buckets are to be executed.


OpenFlow protocol messaging

The protocol consists of three types of messages : controller-to-switch, asynchronous and symmetric.

• Controller-to-switch messages are sent by the controller to :

1. Specify, modify or delete flow definitions
2. Request information on switch capabilities
3. Retrieve information like counters from the switch
4. Send a packet back to a switch for processing after a new flow is created

• Asynchronous messages are sent by the switch to :

1. Send the controller a packet that does not match an existing flow
2. Inform the controller that a flow has been removed because its time to live parameter or inactivity timer has expired
3. Inform the controller of a change in port status or that an error as occurred on the switch

• Symmetric messages can be sent by both the switch or the controller and are used for :

1. Hello messages exchanged between controller and switch on startup
2. Echo messages used to determine the latency of the controller-to-switch connection and to verify that the controller-to-switch connection is still operative
3. Experimenter messages to provide a path for future extensions to OpenFlow technology

OpenFlow protocol development : A promising future

The Open Networking Foundation was founded in 2011 to develop and standardize OpenFlow. Members include Cisco, Facebook, Google, HP, IBM and Juniper Networks.

The current OpenFlow specification, Version 1.1.0, contains a large number of optional features to enable further experimentation, and work is underway on Version 1.2 of the specification.

While Cisco has not announced an OpenFlow-friendly switch, other switch vendors, such as the  IBM and NEC partnership, as well as HP, have implemented OpenFlow in existing products and made these units available for continued development. As vendors and network operators gain further experience with the technology, OpenFlow promises to produce a profound change in the way that networks are managed and operated.


Ref :
http://searchsdn.techtarget.com/feature/OpenFlow-protocol-primer-Looking-under-the-hood