[Sdn] Fwd: New Version Notification for draft-long-sdnrg-pfrrmpm-openflow-00.txt

[xinjian Long <[e-mail]>]

Hello, we want to make you aware of a new I-D named Priority based Flow
Rule Request Message Processing Mechanism in the OpenFlow Switch.



The interesting part of this document for SDNRG is probably the processing
order of the control messages within a transaction between the controller
and the OpenFlow switch. This document proposes the combination of
appending the priority attribute to the packet-in message and the PFRRMPM
as one solution to this problem. On the other hand, we want to have more
people to recognize and highlight the similar problem so as to extend and
generalize it to the other aspects in the Control Plane Southbound
Interface(or the SDN) instead of being specific to the OpenFlow.



We are eager to hear your comments, criticisms, and questions.


Best regards,

Xinjian Long

---------- Forwarded message ----------
From: <[e-mail]>
Date: 2016-04-05 22:15 GMT+08:00
Subject: New Version Notification for
draft-long-sdnrg-pfrrmpm-openflow-00.txt
To: Xinjian Long <[e-mail]>om>, Xiangyang Gong <
[e-mail]>gt;, Xirong Que <[e-mail]>cn>, Wendong Wang <
[e-mail]>gt;, Qinglei Qi <[e-mail]>



A new version of I-D, draft-long-sdnrg-pfrrmpm-openflow-00.txt
has been successfully submitted by Xinjian Long and posted to the
IETF repository.

Name:           draft-long-sdnrg-pfrrmpm-openflow
Revision:       00
Title:          Priority based Flow Rule Request Message Processing
Mechanism in the OpenFlow Switch
Document date:  2016-04-04
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/internet-drafts/draft-long-sdnrg-pfrrmpm-openflow-00.txt
Status:
https://datatracker.ietf.org/doc/draft-long-sdnrg-pfrrmpm-openflow/
Htmlized:
https://tools.ietf.org/html/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
   forwarding rule without or with shorter waiting latency when there
   are excess flow rule request messages in the SDN.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat