SDNRG X. Long Internet-Draft W. Wang Intended status: Informational X. Gong Expires: October 6, 2016 X. Que Q. Qi Beijing University of Post and Telecommunication April 4, 2016 Priority based Flow Rule Request Message Processing Mechanism in the OpenFlow Switch draft-long-sdnrg-pfrrmpm-openflow-00 Abstract In the SDN, the controller is in charge of the maintenance and administration of variable aspects like the network topology and the network resources etc. of the whole network. Administrative strategies are made upon these work and sent to the switches from the controller so as to instruct the network devices to apply appropriate policies to the data flows. As for the data packet which reaches the ingress OpenFlow switch for the first time, the packet itself or a fraction of the packet will be encapsulated into a packet-in message and will be sent to the controller to request for a new flow rule. After the flow-mod message and the packet-out message are sent back to the switch from the controller, the determined forwarding action will be applied to the certain data flow. So far, the inbound latency caused by the creation of the packet-in message and the outbound latency caused by the receive and the execution of the flow-mod message are highlighted when it comes to the concerns about the latency and the effectiveness of the data transportation in the SDN[Mazu]. Attention to the studies on the processing order of the flow rule request message like the packet-in message and the packet-out message is comparatively low. As the SDN continually grows in scale and complexity and the packets' forwarding policies become more recursive and dynamic, the number of the switches under the administration of the same controller is elevated and unavoidably causes the network congestion problem widespread. The scale of modern networks and data-centers and the associated operational expense deteriorates the delay problem in the network with congestion. The ability to help the services with high priority be processed without delay becomes critical. This document proposes the combination of appending a priority tag to the packet-in message and the Priority based Flow Rule Request Message Processing Mechanism(PFRRMPM) as a solution to help the data flow with high priority or lantency-sensitive to acquire the Long, et al. Expires October 6, 2016 [Page 1] Internet-Draft PFRRMPM April 2016 forwarding rule without or with shorter waiting latency when there are excess flow rule request messages in the SDN. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 6, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Flow Rule Request Message and Problem Analysis . . . . . . . 5 5. Priority based Flow Rule Request Message Processing Mechanism 6 5.1. Flow rule request sending module . . . . . . . . . . . . 8 5.2. Flow rule request receiving module . . . . . . . . . . . 8 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Long, et al. Expires October 6, 2016 [Page 2] Internet-Draft PFRRMPM April 2016 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Traditionally, Software-Defined Networking(SDN) introduces an abstraction between the traditional forwarding and control planes so as to provide the programmability to the network devices and therefore promote the controllability, flexibility and reduce the complexity of the whole network. OpenFlow is one of the most popular protocols that applied between the control layer and the infrastructure layer of the SDN. As illustrated in the RFC 7426 [RFC7426], this protocol is used by the application through the Control Abstraction Layer(CAL) in the Control Plane, located at the Control Plane Southbound Interface(CPSI). OpenFlow is used by the controller to control the OpenFlow-compliant switch by fine-tuning the flow tables residing in the switch to take actions regarding packet lookup and forwarding. As the SDN networks grow in scale and complexity continually and the packets' forwarding policies become more recursive and dynamic, the number of the switches under the administration of the same controller is elevated and unavoidably causes the network congestion problem widespread. The scale of modern networks and data-centers and the associated operational expense deteriorates the delay problem in the network with congestion. The ability to help the services with high priority be processed without delay becomes critical. In the traditional SDN, the processing of the flow rule request messages like the packet-in message and the packet-out message follows the FIFO rule. The threat of postponing the execution of certain services with high priority occurs when there are excess packet-in messages received by the controller simultaneously or within a short period. Section 3 provides a glossary of terminology used in this document. Section 4 describes the structure of the packet-in message used in the OpenFlow Switch[ONF-OpenFlow] and analyzes it as the foundation of the problem mainly described in this document. Section 5 provides an overview of the PFRRMPM. To support the PFRRMPM proposed in this document, the OpenFlow-compilant switch as well as the controller are in need. In addition, the switch need to implement a service-based priority table and a priority queue for the Long, et al. Expires October 6, 2016 [Page 3] Internet-Draft PFRRMPM April 2016 flow rule request messages to be sent. The controller need to implement a priority queue for the received flow rule request messages. Furthermore, these new defined priority table and priority queue need to offer interfaces to the applications in the same or different planes in the SDN. Section 6 describes the implementation of the combination of appending a priority tag to the packet-in message and the PFRRMPM. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. When these words appear in lower case, they have their natural language meaning. 3. Terminology This document uses the terminology described in [RFC7426], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow]. In addition, the following terms are defined below: o Software-Defined Networking(SDN): A set of techniques enabling to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner [ITU-T.Y.3300]. o Data Flow/ Stream: Set of network packets sharing a set of traits, for example IP destination or source values. o Network Resources: Devices in the infrastructure layer that can perform packet forwarding, dropping or modifying in a network system. The network resources include network switch, router, gateway, VPN concentrators, and similar devices. This document makes no difference if these network devices are physical or virtual. o Flow Rule Request Message: The messages used by the controller to update the switching subtrate with the appropriate forwarding state. The flow rule request message described below reflects the packet-in message, the packet-out message and the flow-mod message. o Action: Set of operations that will be applied to the data packets according to the flow table's record they matched. Long, et al. Expires October 6, 2016 [Page 4] Internet-Draft PFRRMPM April 2016 4. Flow Rule Request Message and Problem Analysis As illustrated in the terminology, the Flow Rule Request Message in this document reflect the packet-in message, the packet-out message and the flow-mod message. We focus on the structure and the processing procedure of the packet-in message among these three kinds of messages. According to the definition in the OpenFlow Sepecification 1.4.0[ONF-OpenFlow], the structure of the packet-in message is depicted in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | xid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | buffer_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total_len | reason | table_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type(match) | length(match) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | oxm_fields | pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The structure of the packet-in message o The header contains the version, type, length, xid. The header reflects any changes applied to the packet in previous processing. o The buffer_id is assigned by the data path and used to identify every single packet. o The total_len indicates the full length of the frame. o The reason indicates which context triggered the packet-in message. o The table_id indicates the id of the flow table that is to be looked up. o The cookie indicates the cookie of the flow entry that caused the packet to be sent to the controller. Long, et al. Expires October 6, 2016 [Page 5] Internet-Draft PFRRMPM April 2016 o The match contains the type, length, oxm_fields, pad. The match reflects the packet's headers and context when the event that triggers the packet-in message occurred and contains a set of OXM TLVs which includes any actions executed to the packet in previous processing. The packet-in message is supposed to be processed following the FIFO rule because of the lack of any direct or indirect definition of priority in its own structure. And this may cause the critical services with high priority can not be executed timely when there are excess packet-in messages received by the controller simultaneously or within a short period. 5. Priority based Flow Rule Request Message Processing Mechanism In the traditional SDN architecture, the switch looks up every new incoming data packet against the switch's forwarding table. If a match is found, then all the data packets of this data flow will be processed according to the forwarding actions in the flow table, which includes but is not limited to forwarding, dropping and changing packets. If any data packet is found mismatched, then the packet itself or a fraction of the packet will be encapsulated into a flow rule request message(packet-in message), which will be sent to the controller to request for a new flow rule. After the application in the controller finishes processing the request message and upon determining routes for the certain packet, it will return response messages(packet-out message and flow-mod message) to the switch, which will help the switch process the data packets in the certain data flow.[Mazu] The process described above is depicted in Figure 2. Long, et al. Expires October 6, 2016 [Page 6] Internet-Draft PFRRMPM April 2016 +------------------+ | The | | SDN Controller | +------------------+ The Flow Rule ^ | The Response Request Message | v Messages +------------------------------------------------------+ | +-----------------------------------------+ | | | The Switch's CPU | The SDN | | | board | Switch | | +-----------------------------------------+ | | The Dismatched ^ | Flow +-------------------+| | Data Packets | v Rule |+-----------------+|| Data | +---------+ +--------+ ||The Output Queues||| Data Flow | |The Input| |The Flow| |+-----------------+|| Flow ----->| | Port |------>| Table |--->| The Output Port ||-----> | +---------+ +--------+ +-------------------+| +------------------------------------------------------+ Figure 2: The traditional architectrure of a switch in the SDN Compared to the architecture described above, the new one implemented with the PFRRMPM in SDN is depicted in Figure 3. +-----------------------------------------------------------+ |+--------------------+ +---------------------+ The | ||The Receiving Module|-->| The Applications | SDN | |+--------------------+ +---------------------+ Controller| +-----------------------------------------------------------+ ^ The Flow Rule |The Response | Request Message v Messages +------------------------------------------------------+ | +----------------+ <------- +--------------+ | | | The Sending | +------>| The Switch's | The SDN | | | Module | | +---| CPU board | Switch | | +----------------+ | | +--------------+ | | The Dismatched | | Flow +-------------------+| | Data Packets | v Rule |+-----------------+|| Data | +---------+ +--------+ ||The Output Queues||| Data Flow | |The Input| |The Flow| |+-----------------+|| Flow ----->| | Port |------>| Table |--->| The Output Port ||-----> | +---------+ +--------+ +-------------------+| +------------------------------------------------------+ Figure 3: The new architecture of a switch implemented with PFRRMPM in the SDN Long, et al. Expires October 6, 2016 [Page 7] Internet-Draft PFRRMPM April 2016 As depicted in Figure 3, the sending module in the switch and the receiving module in the controller together form the PFRRMPM. 5.1. Flow rule request sending module The flow rule request sending module is resided in the switch, it contains two main parts: a group of priority queues which serve as the buffers to store the flow rule requests sequentially according to the services' priority, and one priority table which is used to determine the generic priority of the services. The schematic of the sending module is depicted in the lower part in Figure 4. When a new switch is connected into the SDN network, the switch's flow table will be configured by the network controller. Then, when the certain data packet is not matched with the flow table, the packet itself or a fraction of the packet will be encapsulated into a flow rule request message. At the same time, a priority tag will be appended to the flow rule request message(the packet-in message) by querying the priority table resided in the sending module. Finally, this message will be pushed into the certain priority queue and kept waiting to be sent to the controller. 5.2. Flow rule request receiving module The flow rule receiving module is resided in the controller, and the main component of this module is one priority queue which serves as a buffer to store the flow rule request messages sequentially according to the services' priority. The schematic of the receiving module is depicted in the upper part in Figure 4. When the controller receives the flow rule request message(the packet-in message) from the switchs in the network, the receiving module will push these requests into different priority queue according to their priority tag. Then the requests in these priority queues will be processed consecutively by the controller's application. Finally, the response messages(the packet-out message and the flow-mod message) will be sent back to the certain switch. Long, et al. Expires October 6, 2016 [Page 8] Internet-Draft PFRRMPM April 2016 +----------------------------------------------------------+ The Flow|+----------------+ +--------+ +------------+ | Rule || The | |Priority| |The Message | | Request || Scheduling |<--| Queues |<--|Distribution|<----+ | Message || Module | | | | Module | | | <-------|+----------------+ +--------+ +------------+ | | | Flow Rule Request Receiving Module | | +-----------------------------------------------------|----+ | +-----------------------------------------------------|----+ The Flow| The packet-in | | Rule |+----------------+ Message With +--------+ +----------+| Request ||The Service Type| Priority Tag |Priority| | The || Message || Based Priority |-------------->| Queues |-->|Scheduling|| ------->|| Table | | | | Module || |+----------------+ +--------+ +----------+| | Flow Rule Request Sending Module | +----------------------------------------------------------+ Figure 4: The flow rule request sending module and the flow rule request receiving module 6. Implementation Once the data flow reaches the ingress switch, the match field of the data packet in this stream will be looked up against the flow table. The match field is in the form of OXM_TLV, which is defined in the OpenFlow [ONF-OpenFlow], including IPv4 source address and destination address, TCP/UDP port number, MPLS/VLAN tag id, and the frame of the specific Ethernet etc. If a match is found, then the action set of the flow table (the 'Action' in the below stands for the same meaning) will be executed, which includes but is not limited to modifying data packets, encapsulating data packets, tuning the parameters. The number of the defined Action in the Open Flow 1.4.0 Specification is 17. When the certain data packet mismatch with any records of the switch's flow table, then the action set of the service based priority table will be executed. The essence of this priority table is a flow table, and its structure is depicted in Figure 5. Long, et al. Expires October 6, 2016 [Page 9] Internet-Draft PFRRMPM April 2016 +-------+--------+----------------------------------------+--------+ | | | The Action Set | | | | |+--------------------------------------+| | | The | The ||Action 1: ofp_action_pushPriorityTag || The | |Matched| Counter|+--------------------------------------+| Timer | | Field | |+--------------------------------------+| | | | ||Action 2: ofp_action_intoPacketInQueue|| | | | |+--------------------------------------+| | +-------+--------+----------------------------------------+--------+ Figure 5: The structure of the service based priority table Each entry in the priority table contains 4 main components: one match field , one counter, one action set and one timer. The match field is used to record whether the certain data packet has been processed or how many times that it has been matched. The action set is the set of actions that will be executed when the data packet matches with the flow table. The action set contains two main actions: ofp_action_pushPriorityTag and ofp_action_intoPacketInQueue. The ofp_action_pushPriorityTag is used to append priority tag to the packet-in message. The ofp_action_intoPacketInQueue is used to push the packet-in message to the certain priority queue according to the service's generic priority. The service type priority table is determined according to the services' fundamental traits. For instance, timely services like the video meeting possess higher priority compared to the background services like the printer access command. Besides, users can define their own priority rule by the controller and install this rule to every switch in the network. After the switch accept these configuration information, they will be installed into the service based priority table. As we known, a new incoming packet's match field will be detached and processed by the switch, then the packet itself or a fraction of the packet will be encapsulated into a packet-in message. Then, the packet-in message will look up the priority table to get the priority tag. This tag is designed for helping the controller to push the certain packet-in message into the priority queue according to the different priority level. After the actions in the action set are executed, the packet-in message with the priority tag will be gathered to the scheduling module, and be uploaded to the controller sequentially according to their priority level, so as to obtain a new flow rule to process the certain data flow. Identically, when these messages reach the controller, they will be gathered to the message distribution module Long, et al. Expires October 6, 2016 [Page 10] Internet-Draft PFRRMPM April 2016 and be pushed into the certain priority queue respectively according to their priority tag. The controller extracts these messages from a scheduling module and processes the message with high priority first, then send the packet-out message and the flow-mod message back to the switch. The flow-mod message is received and used to update the forwarding state of the flow table resided in the switch. The packet-out message is received and used to release the packets buffered at the switch to be forwarded along.[Mazu] So far, a new service has been executed in the SDN successfully. 7. Evaluation TBD 8. Conclusion This document proposes the PFRRMPM as the solution to help the data flow with high priority to acquire the forwarding rule without or with shorter waiting latency when there are excess flow rule request messages in the SDN, which can be concluded as the proposal upon the communication between the OpenFlow switch and the remote controller in the SDN. To ensure the timely execution and the QoS of the critical or lantency-sensitive services when congestion occurs in the SDN, more aspects except for OpenFlow need to be studied and be concerned. Solutions should be found from the dissection of the protocols, APIs invocation, system calls among the different planes in the SDN architecture. For instance, ForCES is another popular protocol applied in the Control Plane Southbound Interface. The communication between the Control Element and the Forwarding Element may also confront the similar problem discussed in this document. Caution should be exercised to handle the difference between the OpenFlow and the ForCES, such as the re-ordering of the messages within a transaction is undesirable in the ForCES[RFC5810]. This is waited to be researched and studied by the SDNRG and the IRTF. 9. Security Considerations TBD Long, et al. Expires October 6, 2016 [Page 11] Internet-Draft PFRRMPM April 2016 10. IANA Considerations TBD 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . 11.2. Informative References [ITU-T.Y.3300] "Recommendation ITU-T Y.3300", June 2014. [Mazu] University of Wisconsin-Madison, Bell Labs, Alcatel- Lucent, "Mazu: Taming Latency in Software Defined Networks", April 2014. [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 1.4.0)", October 2013. [ONF-SDN-Architecture] "SDN Architecture", June 2014. [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . Long, et al. Expires October 6, 2016 [Page 12] Internet-Draft PFRRMPM April 2016 Authors' Addresses Xinjian Long Beijing University of Post and Telecommunication Email: xjlong19921117@gmail.com Wendong Wang Beijing University of Post and Telecommunication Email: wdwang@bupt.edu.cn Xiangyang Gong Beijing University of Post and Telecommunication Email: xygong@bupt.edu.cn Xirong Que Beijing University of Post and Telecommunication Email: rongqx@bupt.edu.cn Qinglei Qi Beijing University of Post and Telecommunication Email: qiqinglei1984@126.com Long, et al. Expires October 6, 2016 [Page 13]