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

xinjian Long <xjlong19921117@gmail.com> Tue, 05 April 2016 14:26 UTC

Return-Path: <xjlong19921117@gmail.com>
X-Original-To: sdn@ietfa.amsl.com
Delivered-To: sdn@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 02CB912D186 for <sdn@ietfa.amsl.com>; Tue, 5 Apr 2016 07:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.468
X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YIEmotkHI3sS for <sdn@ietfa.amsl.com>; Tue, 5 Apr 2016 07:26:54 -0700 (PDT)
Received: from mail-ob0-x241.google.com (mail-ob0-x241.google.com [IPv6:2607:f8b0:4003:c01::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3506B12D557 for <sdn@irtf.org>; Tue, 5 Apr 2016 07:21:16 -0700 (PDT)
Received: by mail-ob0-x241.google.com with SMTP id c1so1083757obw.3 for <sdn@irtf.org>; Tue, 05 Apr 2016 07:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=slBe+Y7wSck+07U9dDSeRNq0VzRbRHtEJVBOHxOUO4o=; b=HD5/Wa+Z+I5UKiYrbaeMHNHa0S/sfEClb20buV/6zd/PZ045qhl9i0/pWj97nCpOzr DOfHIZawJhNTmusgi6mnhRV8sjl5Bf8ZkH+M45T1zbtenubQ3qm2Dbeja/TQlctR89OW G0kJAcdYmpff2/qjGAIQPfBQdqBUW3K86hojXOXrk4dAgi0G1JFBcGhAUaIBrMww4cN7 mpK8dw2qxyEoteicixijsTDNZJlvAU3GUoQu/QUGUkNgIiFuJpgxG1yx55E/Fdm0uvsq nee3GNwGgELwaAGJeohDMNIy2fBRBdqB9uYCA5gaE8y6iijxTN+kUMCBNKuAPtVcAjSg drNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=slBe+Y7wSck+07U9dDSeRNq0VzRbRHtEJVBOHxOUO4o=; b=UV1cFfLiMK75cAhdwzX1RKCxk8aGv6LJ/xyoHcr9yOXGqvJ0S3mAMiM/1KBWQ/guFT mSXbonxWOWQIPlBnQxt2Ai1D4x78D6ES7mpVpiQPAcR2osb4NaYj0gnAbUFRy0PkI/nZ wi8BaxC5EybHCzH5rg/9X96n5mK4P7WJcOHEV5CTP0wusyirsTKRzVPGykwpOsBK/Fne NVjEjZRjH3kVPB30rQxSK7n9HEPRlGT5yCte5ZvZZoepuQivZLRMo1qoVmZvkzZyBfnl 5tCCMIvdfxJLuv0Rq3WKgXYFLt7vqf+DRFv6/Oc0tpRwDWxhFfKj4oXGla/qmp2y5PoN WGbg==
X-Gm-Message-State: AD7BkJIkiYCu0phaAaFIy6jkMK9WkA8e5uuujYidnqj2UfLLhUmXXI3lFkiASNNtGzeNI2QowHrcmyP/L9h/mw==
MIME-Version: 1.0
X-Received: by with SMTP id i7mr14431606obk.86.1459866075498; Tue, 05 Apr 2016 07:21:15 -0700 (PDT)
Received: by with HTTP; Tue, 5 Apr 2016 07:21:15 -0700 (PDT)
In-Reply-To: <20160405141525.25931.4285.idtracker@ietfa.amsl.com>
References: <20160405141525.25931.4285.idtracker@ietfa.amsl.com>
Date: Tue, 5 Apr 2016 22:21:15 +0800
Message-ID: <CAME5St31bF56tBCcEEk4QdNnwrV+pfzp_Mka7b0sfK9ztOBUBA@mail.gmail.com>
From: xinjian Long <xjlong19921117@gmail.com>
To: sdn@irtf.org
Content-Type: multipart/alternative; boundary=001a11c32ddcd98f96052fbd8e6d
Archived-At: <http://mailarchive.ietf.org/arch/msg/sdn/VV9vTfeD0kk-CcL3NPn_t6JUolQ>
Subject: [Sdn] Fwd: New Version Notification for draft-long-sdnrg-pfrrmpm-openflow-00.txt
X-BeenThere: sdn@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <sdn.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/sdn>, <mailto:sdn-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdn/>
List-Post: <mailto:sdn@irtf.org>
List-Help: <mailto:sdn-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/sdn>, <mailto:sdn-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 14:26:57 -0000

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: <internet-drafts@ietf.org>
Date: 2016-04-05 22:15 GMT+08:00
Subject: New Version Notification for
To: Xinjian Long <xjlong19921117@gmail.com>om>, Xiangyang Gong <
xygong@bupt.edu.cn>gt;, Xirong Que <rongqx@bupt.edu.cn>cn>, Wendong Wang <
wdwang@bupt.edu.cn>gt;, Qinglei Qi <qiqinglei1984@126.com>

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

   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