idnits 2.17.1 draft-long-sdnrg-pfrrmpm-openflow-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 37 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([Mazu]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2, 2016) is 2763 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 503, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG X. Long 3 Internet-Draft W. Wang 4 Intended status: Informational X. Gong 5 Expires: April 5, 2017 X. Que 6 Q. Qi 7 Beijing University of Post and Telecommunication 8 October 2, 2016 10 Priority based Flow Rule Request Message Processing Mechanism in the 11 OpenFlow Switch 12 draft-long-sdnrg-pfrrmpm-openflow-01 14 Abstract 16 In the SDN, the controller is in charge of the maintenance and 17 administration of variable aspects like the network topology and the 18 network resources etc. of the whole network. Administrative 19 strategies are made upon these work and sent to the switches from the 20 controller so as to instruct the network devices to apply appropriate 21 policies to the data flows. As for the data packet which reaches the 22 ingress OpenFlow switch for the first time, the packet itself or a 23 fraction of the packet will be encapsulated into a packet-in message 24 and will be sent to the controller to request for a new flow rule. 25 After the flow-mod message and the packet-out message are sent back 26 to the switch from the controller, the determined forwarding action 27 will be applied to the certain data flow. 29 So far, the inbound latency caused by the creation of the packet-in 30 message and the outbound latency caused by the receive and the 31 execution of the flow-mod message are highlighted when it comes to 32 the concerns about the latency and the effectiveness of the data 33 transportation in the SDN[Mazu]. Attention to the studies on the 34 processing order of the flow rule request message like the packet-in 35 message and the packet-out message is comparatively low. As the SDN 36 continually grows in scale and complexity and the packets' forwarding 37 policies become more recursive and dynamic, the number of the 38 switches under the administration of the same controller is elevated 39 and unavoidably causes the network congestion problem widespread. 40 The scale of modern networks and data-centers and the associated 41 operational expense deteriorates the delay problem in the network 42 with congestion. The ability to help the services with high priority 43 be processed without delay becomes critical. 45 This document proposes the combination of appending a priority tag to 46 the packet-in message and the Priority based Flow Rule Request 47 Message Processing Mechanism(PFRRMPM) as a solution to help the data 48 flow with high priority or lantency-sensitive to acquire the 49 forwarding rule without or with shorter waiting latency when there 50 are excess flow rule request messages in the SDN. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on April 5, 2017. 69 Copyright Notice 71 Copyright (c) 2016 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 87 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 88 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 4. Flow Rule Request Message and Problem Analysis . . . . . . . 5 90 5. Priority based Flow Rule Request Message Processing Mechanism 6 91 5.1. Flow rule request sending module . . . . . . . . . . . . 8 92 5.2. Flow rule request receiving module . . . . . . . . . . . 8 93 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 94 7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 100 11.2. Informative References . . . . . . . . . . . . . . . . . 12 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 103 1. Introduction 105 Traditionally, Software-Defined Networking(SDN) introduces an 106 abstraction between the traditional forwarding and control planes so 107 as to provide the programmability to the network devices and 108 therefore promote the controllability, flexibility and reduce the 109 complexity of the whole network. 111 OpenFlow is one of the most popular protocols that applied between 112 the control layer and the infrastructure layer of the SDN. As 113 illustrated in the RFC 7426 [RFC7426], this protocol is used by the 114 application through the Control Abstraction Layer(CAL) in the Control 115 Plane, located at the Control Plane Southbound Interface(CPSI). 116 OpenFlow is used by the controller to control the OpenFlow-compliant 117 switch by fine-tuning the flow tables residing in the switch to take 118 actions regarding packet lookup and forwarding. 120 As the SDN networks grow in scale and complexity continually and the 121 packets' forwarding policies become more recursive and dynamic, the 122 number of the switches under the administration of the same 123 controller is elevated and unavoidably causes the network congestion 124 problem widespread. The scale of modern networks and data-centers 125 and the associated operational expense deteriorates the delay problem 126 in the network with congestion. The ability to help the services 127 with high priority be processed without delay becomes critical. In 128 the traditional SDN, the processing of the flow rule request messages 129 like the packet-in message and the packet-out message follows the 130 FIFO rule. The threat of postponing the execution of certain 131 services with high priority occurs when there are excess packet-in 132 messages received by the controller simultaneously or within a short 133 period. 135 Section 3 provides a glossary of terminology used in this document. 137 Section 4 describes the structure of the packet-in message used in 138 the OpenFlow Switch[ONF-OpenFlow] and analyzes it as the foundation 139 of the problem mainly described in this document. 141 Section 5 provides an overview of the PFRRMPM. To support the 142 PFRRMPM proposed in this document, the OpenFlow-compilant switch as 143 well as the controller are in need. In addition, the switch need to 144 implement a service-based priority table and a priority queue for the 145 flow rule request messages to be sent. The controller need to 146 implement a priority queue for the received flow rule request 147 messages. Furthermore, these new defined priority table and priority 148 queue need to offer interfaces to the applications in the same or 149 different planes in the SDN. 151 Section 6 describes the implementation of the combination of 152 appending a priority tag to the packet-in message and the PFRRMPM. 154 2. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 When these words appear in lower case, they have their natural 160 language meaning. 162 3. Terminology 164 This document uses the terminology described in [RFC7426], 165 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow]. In addition, 166 the following terms are defined below: 168 o Software-Defined Networking(SDN): A set of techniques enabling to 169 directly program, orchestrate, control, and manage network 170 resources, which facilitates the design, delivery and operation of 171 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 173 o Data Flow/ Stream: Set of network packets sharing a set of traits, 174 for example IP destination or source values. 176 o Network Resources: Devices in the infrastructure layer that can 177 perform packet forwarding, dropping or modifying in a network 178 system. The network resources include network switch, router, 179 gateway, VPN concentrators, and similar devices. This document 180 makes no difference if these network devices are physical or 181 virtual. 183 o Flow Rule Request Message: The messages used by the controller to 184 update the switching subtrate with the appropriate forwarding 185 state. The flow rule request message described below reflects the 186 packet-in message, the packet-out message and the flow-mod 187 message. 189 o Action: Set of operations that will be applied to the data packets 190 according to the flow table's record they matched. 192 4. Flow Rule Request Message and Problem Analysis 194 As illustrated in the terminology, the Flow Rule Request Message in 195 this document reflect the packet-in message, the packet-out message 196 and the flow-mod message. We focus on the structure and the 197 processing procedure of the packet-in message among these three kinds 198 of messages. According to the definition in the OpenFlow 199 Sepecification 1.4.0[ONF-OpenFlow], the structure of the packet-in 200 message is depicted in Figure 1. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | version | type | length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | xid | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | buffer_id | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | total_len | reason | table_id | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | cookie | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | cookie | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | type(match) | length(match) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | oxm_fields | pad | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: The structure of the packet-in message 224 o The header contains the version, type, length, xid. The header 225 reflects any changes applied to the packet in previous processing. 227 o The buffer_id is assigned by the data path and used to identify 228 every single packet. 230 o The total_len indicates the full length of the frame. 232 o The reason indicates which context triggered the packet-in 233 message. 235 o The table_id indicates the id of the flow table that is to be 236 looked up. 238 o The cookie indicates the cookie of the flow entry that caused the 239 packet to be sent to the controller. 241 o The match contains the type, length, oxm_fields, pad. The match 242 reflects the packet's headers and context when the event that 243 triggers the packet-in message occurred and contains a set of OXM 244 TLVs which includes any actions executed to the packet in previous 245 processing. 247 The packet-in message is supposed to be processed following the FIFO 248 rule because of the lack of any direct or indirect definition of 249 priority in its own structure. And this may cause the critical 250 services with high priority can not be executed timely when there are 251 excess packet-in messages received by the controller simultaneously 252 or within a short period. 254 5. Priority based Flow Rule Request Message Processing Mechanism 256 In the traditional SDN architecture, the switch looks up every new 257 incoming data packet against the switch's forwarding table. If a 258 match is found, then all the data packets of this data flow will be 259 processed according to the forwarding actions in the flow table, 260 which includes but is not limited to forwarding, dropping and 261 changing packets. If any data packet is found mismatched, then the 262 packet itself or a fraction of the packet will be encapsulated into a 263 flow rule request message(packet-in message), which will be sent to 264 the controller to request for a new flow rule. After the application 265 in the controller finishes processing the request message and upon 266 determining routes for the certain packet, it will return response 267 messages(packet-out message and flow-mod message) to the switch, 268 which will help the switch process the data packets in the certain 269 data flow.[Mazu] The process described above is depicted in Figure 2. 271 +------------------+ 272 | The | 273 | SDN Controller | 274 +------------------+ 275 The Flow Rule ^ | The Response 276 Request Message | v Messages 277 +------------------------------------------------------+ 278 | +-----------------------------------------+ | 279 | | The Switch's CPU | The SDN | 280 | | board | Switch | 281 | +-----------------------------------------+ | 282 | The Dismatched ^ | Flow +-------------------+| 283 | Data Packets | v Rule |+-----------------+|| 284 Data | +---------+ +--------+ ||The Output Queues||| Data 285 Flow | |The Input| |The Flow| |+-----------------+|| Flow 286 ----->| | Port |------>| Table |--->| The Output Port ||-----> 287 | +---------+ +--------+ +-------------------+| 288 +------------------------------------------------------+ 290 Figure 2: The traditional architectrure of a switch in the SDN 292 Compared to the architecture described above, the new one implemented 293 with the PFRRMPM in SDN is depicted in Figure 3. 295 +-----------------------------------------------------------+ 296 |+--------------------+ +---------------------+ The | 297 ||The Receiving Module|-->| The Applications | SDN | 298 |+--------------------+ +---------------------+ Controller| 299 +-----------------------------------------------------------+ 300 ^ The Flow Rule |The Response 301 | Request Message v Messages 302 +------------------------------------------------------+ 303 | +----------------+ <------- +--------------+ | 304 | | The Sending | +------>| The Switch's | The SDN | 305 | | Module | | +---| CPU board | Switch | 306 | +----------------+ | | +--------------+ | 307 | The Dismatched | | Flow +-------------------+| 308 | Data Packets | v Rule |+-----------------+|| 309 Data | +---------+ +--------+ ||The Output Queues||| Data 310 Flow | |The Input| |The Flow| |+-----------------+|| Flow 311 ----->| | Port |------>| Table |--->| The Output Port ||-----> 312 | +---------+ +--------+ +-------------------+| 313 +------------------------------------------------------+ 315 Figure 3: The new architecture of a switch implemented with PFRRMPM 316 in the SDN 318 As depicted in Figure 3, the sending module in the switch and the 319 receiving module in the controller together form the PFRRMPM. 321 5.1. Flow rule request sending module 323 The flow rule request sending module is resided in the switch, it 324 contains two main parts: a group of priority queues which serve as 325 the buffers to store the flow rule requests sequentially according to 326 the services' priority, and one priority table which is used to 327 determine the generic priority of the services. The schematic of the 328 sending module is depicted in the lower part in Figure 4. 330 When a new switch is connected into the SDN network, the switch's 331 flow table will be configured by the network controller. Then, when 332 the certain data packet is not matched with the flow table, the 333 packet itself or a fraction of the packet will be encapsulated into a 334 flow rule request message. At the same time, a priority tag will be 335 appended to the flow rule request message(the packet-in message) by 336 querying the priority table resided in the sending module. Finally, 337 this message will be pushed into the certain priority queue and kept 338 waiting to be sent to the controller. 340 5.2. Flow rule request receiving module 342 The flow rule receiving module is resided in the controller, and the 343 main component of this module is one priority queue which serves as a 344 buffer to store the flow rule request messages sequentially according 345 to the services' priority. The schematic of the receiving module is 346 depicted in the upper part in Figure 4. 348 When the controller receives the flow rule request message(the 349 packet-in message) from the switchs in the network, the receiving 350 module will push these requests into different priority queue 351 according to their priority tag. Then the requests in these priority 352 queues will be processed consecutively by the controller's 353 application. Finally, the response messages(the packet-out message 354 and the flow-mod message) will be sent back to the certain switch. 356 +----------------------------------------------------------+ 357 The Flow|+----------------+ +--------+ +------------+ | 358 Rule || The | |Priority| |The Message | | 359 Request || Scheduling |<--| Queues |<--|Distribution|<----+ | 360 Message || Module | | | | Module | | | 361 <-------|+----------------+ +--------+ +------------+ | | 362 | Flow Rule Request Receiving Module | | 363 +-----------------------------------------------------|----+ 364 | 365 +-----------------------------------------------------|----+ 366 The Flow| The packet-in | | 367 Rule |+----------------+ Message With +--------+ +----------+| 368 Request ||The Service Type| Priority Tag |Priority| | The || 369 Message || Based Priority |-------------->| Queues |-->|Scheduling|| 370 ------->|| Table | | | | Module || 371 |+----------------+ +--------+ +----------+| 372 | Flow Rule Request Sending Module | 373 +----------------------------------------------------------+ 375 Figure 4: The flow rule request sending module and the flow rule 376 request receiving module 378 6. Implementation 380 Once the data flow reaches the ingress switch, the match field of the 381 data packet in this stream will be looked up against the flow table. 382 The match field is in the form of OXM_TLV, which is defined in the 383 OpenFlow [ONF-OpenFlow], including IPv4 source address and 384 destination address, TCP/UDP port number, MPLS/VLAN tag id, and the 385 frame of the specific Ethernet etc. If a match is found, then the 386 action set of the flow table (the 'Action' in the below stands for 387 the same meaning) will be executed, which includes but is not limited 388 to modifying data packets, encapsulating data packets, tuning the 389 parameters. The number of the defined Action in the Open Flow 1.4.0 390 Specification is 17. 392 When the certain data packet mismatch with any records of the 393 switch's flow table, then the action set of the service based 394 priority table will be executed. The essence of this priority table 395 is a flow table, and its structure is depicted in Figure 5. 397 +-------+--------+----------------------------------------+--------+ 398 | | | The Action Set | | 399 | | |+--------------------------------------+| | 400 | The | The ||Action 1: ofp_action_pushPriorityTag || The | 401 |Matched| Counter|+--------------------------------------+| Timer | 402 | Field | |+--------------------------------------+| | 403 | | ||Action 2: ofp_action_intoPacketInQueue|| | 404 | | |+--------------------------------------+| | 405 +-------+--------+----------------------------------------+--------+ 407 Figure 5: The structure of the service based priority table 409 Each entry in the priority table contains 4 main components: one 410 match field , one counter, one action set and one timer. The match 411 field is used to record whether the certain data packet has been 412 processed or how many times that it has been matched. The action set 413 is the set of actions that will be executed when the data packet 414 matches with the flow table. The action set contains two main 415 actions: ofp_action_pushPriorityTag and ofp_action_intoPacketInQueue. 416 The ofp_action_pushPriorityTag is used to append priority tag to the 417 packet-in message. The ofp_action_intoPacketInQueue is used to push 418 the packet-in message to the certain priority queue according to the 419 service's generic priority. 421 The service type priority table is determined according to the 422 services' fundamental traits. For instance, timely services like the 423 video meeting possess higher priority compared to the background 424 services like the printer access command. 426 Besides, users can define their own priority rule by the controller 427 and install this rule to every switch in the network. After the 428 switch accept these configuration information, they will be installed 429 into the service based priority table. 431 As we known, a new incoming packet's match field will be detached and 432 processed by the switch, then the packet itself or a fraction of the 433 packet will be encapsulated into a packet-in message. Then, the 434 packet-in message will look up the priority table to get the priority 435 tag. This tag is designed for helping the controller to push the 436 certain packet-in message into the priority queue according to the 437 different priority level. 439 After the actions in the action set are executed, the packet-in 440 message with the priority tag will be gathered to the scheduling 441 module, and be uploaded to the controller sequentially according to 442 their priority level, so as to obtain a new flow rule to process the 443 certain data flow. Identically, when these messages reach the 444 controller, they will be gathered to the message distribution module 445 and be pushed into the certain priority queue respectively according 446 to their priority tag. The controller extracts these messages from a 447 scheduling module and processes the message with high priority first, 448 then send the packet-out message and the flow-mod message back to the 449 switch. The flow-mod message is received and used to update the 450 forwarding state of the flow table resided in the switch. The 451 packet-out message is received and used to release the packets 452 buffered at the switch to be forwarded along.[Mazu] So far, a new 453 service has been executed in the SDN successfully. 455 7. Evaluation 457 TBD 459 8. Conclusion 461 This document proposes the PFRRMPM as the solution to help the data 462 flow with high priority to acquire the forwarding rule without or 463 with shorter waiting latency when there are excess flow rule request 464 messages in the SDN, which can be concluded as the proposal upon the 465 communication between the OpenFlow switch and the remote controller 466 in the SDN. 468 To ensure the timely execution and the QoS of the critical or 469 lantency-sensitive services when congestion occurs in the SDN, more 470 aspects except for OpenFlow need to be studied and be concerned. 471 Solutions should be found from the dissection of the protocols, APIs 472 invocation, system calls among the different planes in the SDN 473 architecture. 475 For instance, ForCES is another popular protocol applied in the 476 Control Plane Southbound Interface. The communication between the 477 Control Element and the Forwarding Element may also confront the 478 similar problem discussed in this document. Caution should be 479 exercised to handle the difference between the OpenFlow and the 480 ForCES, such as the re-ordering of the messages within a transaction 481 is undesirable in the ForCES[RFC5810]. 483 This is waited to be researched and studied by the SDNRG and the 484 IRTF. 486 9. Security Considerations 488 TBD 490 10. IANA Considerations 492 TBD 494 11. References 496 11.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 504 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 505 DOI 10.17487/RFC5226, May 2008, 506 . 508 11.2. Informative References 510 [ITU-T.Y.3300] 511 "Recommendation ITU-T Y.3300", June 2014. 513 [Mazu] University of Wisconsin-Madison, Bell Labs, Alcatel- 514 Lucent, "Mazu: Taming Latency in Software Defined 515 Networks", April 2014. 517 [ONF-OpenFlow] 518 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 519 October 2013. 521 [ONF-SDN-Architecture] 522 "SDN Architecture", June 2014. 524 [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., 525 Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and 526 J. Halpern, "Forwarding and Control Element Separation 527 (ForCES) Protocol Specification", RFC 5810, 528 DOI 10.17487/RFC5810, March 2010, 529 . 531 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 532 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 533 Defined Networking (SDN): Layers and Architecture 534 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 535 2015, . 537 Authors' Addresses 539 Xinjian Long 540 Beijing University of Post and Telecommunication 542 Email: xjlong19921117@gmail.com 544 Wendong Wang 545 Beijing University of Post and Telecommunication 547 Email: wdwang@bupt.edu.cn 549 Xiangyang Gong 550 Beijing University of Post and Telecommunication 552 Email: xygong@bupt.edu.cn 554 Xirong Que 555 Beijing University of Post and Telecommunication 557 Email: rongqx@bupt.edu.cn 559 Qinglei Qi 560 Beijing University of Post and Telecommunication 562 Email: qiqinglei1984@126.com