Internet DRAFT - draft-long-sdnrg-pfrrmpm-openflow

draft-long-sdnrg-pfrrmpm-openflow







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]