SDNRG X. Long
Internet-Draft W. Wang
Intended status: Informational X. Gong
Expires: April 5, 2017 X. Que
Q. Qi
Beijing University of Post and Telecommunication
October 2, 2016
Priority based Flow Rule Request Message Processing Mechanism in the
OpenFlow Switch
draft-long-sdnrg-pfrrmpm-openflow-01
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 April 5, 2017 [Page 1]
Internet-Draft PFRRMPM October 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 April 5, 2017.
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 April 5, 2017 [Page 2]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 3]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 4]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 5]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 6]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 7]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 8]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 9]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 10]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 11]
Internet-Draft PFRRMPM October 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc5226>.
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,
<http://www.rfc-editor.org/info/rfc5810>.
[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, <http://www.rfc-editor.org/info/rfc7426>.
Long, et al. Expires April 5, 2017 [Page 12]
Internet-Draft PFRRMPM October 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 April 5, 2017 [Page 13]