Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SDN - OpenFlow protocol

991 views

Published on

The document is a scientific composition about the
system architecture of OpenFlow and describes their principles of data handling, the types of messages and operations on the network.

Published in: Engineering
  • Be the first to comment

SDN - OpenFlow protocol

  1. 1. OpenFlow Protocol Principles, Messages and Operation Published by B.Sc. Ulf Marxen on 20.04.2015 University of Applied Science of Saarland Computer Science and Communication Systems Saarbrücken, Germany Contact: ulf-marxen@gmx.de Abstract — the document is a scientific composition about the system architecture of OpenFlow and describes their principles of data handling, the types of messages and operations on the network. It is related to the course of “Future Internet” of Prof. Dr. Joberto S. B. Martins at University of Applied Science of Saarland in Saarbrücken in March 2015. I. INTRODUCTION Nowadays Mobile-Computing, Cloud-Services and Big- Data Applications are transferring a huge amount of data cross the internet, but the network services are not enough efficient for the future internet. The fast evolution of internet services is requiring a powerful network and intelligent network management, but the current communication and data networks have become ossified. This problem is related to the network concept of well-defined layer, which is very inflexible and inability to be changed. There is no separation of the data plane and control plane, which is forcing the situation. Novel software technologies for distributed networks developed a software-based solution the software-defined or software-driven networks (SDN), which separates the control plane from the network equipment. As result of the separation they received an abstracted overview from the network, which enables and simplifies the programmability of the network. Also they introduced the new signaling protocol OpenFlow on the new network architecture, which makes the network flexible and will meet the requirements of future internet. [1, 2] II. OPENFLOW PRINCIPLES Present routing on networks is based on distributed, complex and not optimal algorithm, which decide forwarding by the destination. Instead OpenFlow offers a more flexible way of manipulating the routing tables of the network equipment, which can use multiple algorithm modules and also algorithms, which haven’t been practical before. OpenFlow controls the routing process, which distributes their decisions to the dummy network equipment. The forwarding of messages on network equipment is now based on flow matching. [3] III. SDN ARCHITECTURE A. Overview On classic network equipment forwarding decisions are controlled by each device and these are managed by an administrator. SDN breaks this concept into three layers the data, control and management plane [Fig.1]. These planes are interconnected from the data plan to the control plane by southbound interface and from the control plane to the management plane by the northbound interface. [4] B. Data Plane The data plane includes the network infrastructure like switches and routers and use small operation system, which makes them dumb, but more efficient. The manufactures of network equipment usually hide their operation system and it works often different to other manufactures. For this reason all manufactures have to integrate a standardized interface, the southbound interface, which is using the OpenFlow Protocol to communicate with the control plane. [4] C. Control Plane The intelligence of network is based on the control plane, which is supported by the Network Operating Systems (NOS). There are several NOS, which are relating to different operator. The network equipment is connected by the southbound interface to Network Hypervisors, which are acting as proxy to forward OpenFlow communications to the relating NOS. [4] Fig. 1. Layered view of networking functionality [4]
  2. 2. D. Management Plane Finally the management plane is responsible to configure and monitor the NOS by applications, which are connected to the northbound interface of the control plane. [4] IV. OPENFLOW ARCHTIECTURE As introduced in the SDN architecture OpenFlow is the Application Programming Interface (API) corresponding for the Southbound-Interface and operates on the data and control plane. The illustration [Fig.2] presents the design of the OpenFlow concept. The control plane works by a centralized OpenFlow Controller. The data plane contains the network equipment running by OpenFlow Switches, which integrate an OpenFlow Client and use the OpenFlow Protocol to connect by a Secure Channel to the OpenFlow Controller. [3, 5] V. OPENFLOW COMPONENTS A. OpenFlow Client An OpenFlow Switch uses an OpenFlow Client, which consisting essentially one or more flow table, a group table and a Secure Channel. The OpenFlow Switch is connected to an external OpenFlow Controller and communicates by the OpenFlow Protocol. The illustration [Fig.3] displays the setup of an OpenFlow Switch. [3] B. Flow table This section specifies the definition of the flow table and the operation process flow of receiving data packets. A flow entry describes a data packet, which exhibits the same attributes. These attributes represent mainly header address information, but can include all data information of all OSI- layers. Packets with the same information belong to the same flow. For example a flow definition could be that all packets with the same source IP-address passing the same flow. Initial the flow table is empty and will save dedicated flow entries. The flow table stores entries until they idle and will be automatically removed if they occur a timeout. The illustration [Fig.4] shows the structure of a flow entry, which is specified by rules, actions and stats. [1, 4] The rules of the recent OpenFlow version 1.4 include the following values [Fig.5]: Fig. 4. Example of the basic Flow Table [4] Fig. 2. Overview of an sample network structure [6] Fig. 3. Visualization of the functionality of a OpenFlow Switch [6] Fig. 5. Extract of the OpenFlow rules from the recent specification [7] enum oxm_ofb_match_fields { OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */ OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */ OFPXMT_OFB_METADATA = 2, /* Metadata between tables. */ OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */ OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */ OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */ OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */ OFPXMT_OFB_VLAN_PCP = 7, /* VLAN priority. */ OFPXMT_OFB_IP_DSCP = 8, /* IP DSCP (6 bits in ToS field).*/ OFPXMT_OFB_IP_ECN = 9, /* IP ECN (2 bits in ToS field). */ OFPXMT_OFB_IP_PROTO = 10, /* IP protocol. */ OFPXMT_OFB_IPV4_SRC = 11, /* IPv4 source address. */ OFPXMT_OFB_IPV4_DST = 12, /* IPv4 destination address. */ OFPXMT_OFB_TCP_SRC = 13, /* TCP source port. */ OFPXMT_OFB_TCP_DST = 14, /* TCP destination port. */ OFPXMT_OFB_UDP_SRC = 15, /* UDP sorce port. */ OFPXMT_OFB_UDP_DST = 16, /* UDP destination port. */ OFPXMT_OFB_SCTP_SRC = 17, /* SCTP source port. */ OFPXMT_OFB_SCTP_DST = 18, /* SCTP destination port. */ OFPXMT_OFB_ICMPV4_TYPE = 19, /* ICMP type. */ OFPXMT_OFB_ICMPV4_CODE = 20, /* ICMP code. */ OFPXMT_OFB_ARP_OP = 21, /* ARP opcode. */ OFPXMT_OFB_ARP_SPA = 22, /* ARP source IPv4 address. */ OFPXMT_OFB_ARP_TPA = 23, /* ARP target IPv4 address. */ OFPXMT_OFB_ARP_SHA = 24, /* ARP source hardware address. */ OFPXMT_OFB_ARP_THA = 25, /* ARP target hardware address. */ OFPXMT_OFB_IPV6_SRC = 26, /* IPv6 source address. */ OFPXMT_OFB_IPV6_DST = 27, /* IPv6 destination address. */ OFPXMT_OFB_IPV6_FLABEL = 28, /* IPv6 Flow Label */ OFPXMT_OFB_ICMPV6_TYPE = 29, /* ICMPv6 type. */ OFPXMT_OFB_ICMPV6_CODE = 30, /* ICMPv6 code. */ OFPXMT_OFB_IPV6_ND_TARGET = 31, /* Target address for ND. * OFPXMT_OFB_IPV6_ND_SLL = 32, /* Source link-layer for ND. */ OFPXMT_OFB_IPV6_ND_TLL = 33, /* Target link-layer for ND. */ OFPXMT_OFB_MPLS_LABEL = 34, /* MPLS label. */ OFPXMT_OFB_MPLS_TC = 35, /* MPLS TC. */ OFPXMT_OFP_MPLS_BOS = 36, /* MPLS BoS bit. */ OFPXMT_OFB_PBB_ISID = 37, /* PBB I-SID. */ OFPXMT_OFB_TUNNEL_ID = 38, /* Logical Port Metadata. */ OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header */ OFPXMT_OFB_PBB_UCA = 41, /* PBB UCA header field. */ };
  3. 3. Fig. 7. Extract of the OpenFlow actions from the recent specification [7] An OpenFlow Switch does not need to support all rules and operations depending on the running OpenFlow Version. As minimum it must integrate the following rules, which are listed in the table [Fig.6] to support a basic level of handling. [6] The packet field values are acting as matching criterion (rules, filter) for flow indication and relate them to new instructions (actions). These instructions are currently defined in the following list [Fig.7]. [3, 6] If a packet is indicated by a filter OpenFlow may execute basic actions like to forward a packet to one or more ports or to drop the packet. Also if multiple flow tables or a group table exist, the OpenFlow Client can process the packet handling in a pipeline of flow tables. Optionally the OpenFlow Client can modify defined packet fields. This offers a big scope of facilities to act maybe like the Network Address Translation (NAT) function of a router. If there is no match by a filter, the OpenFlow Client acts depending on the configuration to ignore the packet, process the packet by standard router handling or it will forward the received packet to the OpenFlow Controller. The OpenFlow Controller has to provide a new flow entry to the requesting OpenFlow Switch. Additional each flow table contains stats about the matched filter and executed instructions. These stats are counting the transferred packets and bytes, which are passing the OpenFlow Switch. [1] C. Secure channel OpenFlow uses a Secure Channel to connect the interface from the OpenFlow Switch to the OpenFlow Controller, which enables the OpenFlow Controller to configure and manage the OpenFlow Switch. The communication is secured by a Secure Sockets Layer (SSL) and used internally by the OpenFlow Protocol to transfer messages. Mostly the Secure Channel is running on a separated Out-of-Band network. Initialized the OpenFlow Switch needs the IP-address and port-number of the responsible OpenFlow Controller to initialize a connection. [5] D. OpenFlow Controller The intelligence of the network is abstracted from the network equipment to a centralized and/or distributed OpenFlow Controller, which is running a Network Operating System on separated hardware. It is reliable for the flow processing to define new filters and instructions and to add them to the OpenFlow Switch. Also it can change or delete entries from the existing flow tables. [5] VI. OPENFLOW PROTOCOL The communication between the OpenFlow components is using three types of message: Controller-to-switch, asynchronous and symmetric each with subtypes A. Controller-to-switch messages The OpenFlow Controller initiates this message type to request or change the configuration, request the supported functionalities and stats of an OpenFlow Switch. Mostly it sends the Flow_Modification-Message to add, change or delete entries of the flow table. Additionally the OpenFlow Controller can send a Packet_out-Message to an OpenFlow Switch. [1, 3] B. Asynchronous messages The type of asynchronous messages is used by the OpenFlow Switch, which automatically sends information to the OpenFlow Controller, if a received data packet or a switch state hits a defined trigger. As example these triggers can be a change of a port state, a timeout of a Flow entry or a response of a Flow_ Modification-Action. Furthermore the OpenFlow Switch can send the content of a received data packet to the OpenFlow Controller by a Packet_In-Message. [1, 3] C. Symmetric messages A message of the type symmetric can be initiated by the OpenFlow Controller and Switch, too. To initialize a communication between both entities they exchange Hello- messages and negotiate the supported OpenFlow Protocol Version. In addition they use Echo-messages to test bandwidth, latency and availability. [1, 3] enum ofp_instruction_type { OFPIT_GOTO_TABLE = 1, /* Setup the next table in the lookup pipeline */ OFPIT_WRITE_METADATA = 2, /* Setup the metadata field for use in pipeline*/ OFPIT_WRITE_ACTIONS = 3, /* Write the action onto the datapath action set */ OFPIT_APPLY_ACTIONS = 4, /* Applies the action(s) immediately */ OFPIT_CLEAR_ACTIONS = 5, /* Clears all actions from the datapath action set */ OFPIT_METER = 6, /* Apply meter (rate limiter) */ OFPIT_EXPERIMENTER = 0xFFFF /* Experimenter instruction */ }; Fig. 6. Mandatory rules of a Flow Table [7]
  4. 4. D. Basic operation of an OpenFlow Switch The illustration [Fig.8] emulates a basic process of communication between the OpenFlow Switch and Controller. This example describes the case that the OpenFlow Switch receives a data packet and tries to index it by the filters of the flow table and relate to some instructions. (1) In the current flow table there is no match for the received data packet and the OpenFlow Switch is configured to request the OpenFlow Controller in this situation. (2) This miss of the filters triggers a Packet_In message, which forwards the data content of the received packet and the trigger information Reason=No_Match to the OpenFlow Controller. Additional the OpenFlow Switch adds the port number to the message, where it received the data packet. (3) The OpenFlow Controller receives the message and checks the data base of flow definition. Then it creates a Flow_Modification message containing new filter and instruction and response the message to the OpenFlow Switch. (4) The OpenFlow Client evaluates the Flow_Modification message and modifies the flow table. After execution the OpenFlow Switch receipted the modification of the flow table. (5) Once the OpenFlow Controller receives an accomplished receipt, it returns the original packet to the OpenFlow Switch by a Packet_Out-Message. Before sending it copies the port information from the Packet_In-Message to the outgoing message. This information is important to the OpenFlow Switch to know where the data content of the Packet_Out-Message original comes from. (6) Finally the OpenFlow Switch will start again to index the received data from the Packet_Out-Message and relate them to the new instructions of the flow entry. All following similar data packets will handle directly. [1] VII. CONCLUSION The realization of splitting the data and control plane from the network equipment and using OpenFlow Protocol to exchange control information between both planes afford an integration of a new network management. The availability to execute instructions to specified indicated packets by the flow table makes the network management very powerful and allows integrating new network protocols to improve the network services. The specialty of OpenFlow is that the manufactures don’t need to open their operation systems of their network equipment. They just have to add the OpenFlow feature to their operation system without changing the basic software. This future network management will realize a better scalability, efficiency, stability and integration and offer an optimal routing on a global network. It will replace many network patches and provide an easy integration of new configurable services. The concept of SDN enables redesigning and developing of new multicast distribution services, server load balancing, dynamic access control, new mobility facilities and many more. [1, 3, 5] REFERENCES [1] Jonas Danzl, “Konzeption und Implementierung eines OpenFlow-basierten IP-Multicast-Dienstes für Datenzentren,” Diploma Thesis, Institut für Parallele und Verteilte Systeme, Universität Stuttgart, 2013. [2] A. Galis, The future internet: Future Internet Assembly 2013 : validated results and new horizons. Berlin [u.a.]: Springer, 2013. [3] Prof. Dr. Joberto S. B. Martins, OpenFlow: Principles, Components and Operation. Saarbrücken, 2015. [4] D. Kreutz, F. Ramos and P. Verissimo, “Software- Defined Networking: A Comprehensive Survey,” University of Lisbon, Lisbon, Portugal. [5] Filip Kostadinow, “Implementierung von OpenFlow für Juniper Router,” Diploma Thesis, Institut für Kommunikationsnetze und Rechnersysteme, Universität Stuttgart, 2011. [6] Open Networking Foundation, OpenFlow Switch Specification: Version 1.4.0. Available: https://www.opennetworking.org/images/stories/downlo ads/sdn-resources/onf- specifications/openflow/openflow-spec-v1.4.0.pdf (2015, Apr. 18). Fig. 8. Example flow handling on the OpenFlow Switch and Controller [1, 6]

×