idnits 2.17.1 draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid-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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 9, 2013) is 4117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '4461' is mentioned on line 100, but not defined == Missing Reference: '4875' is mentioned on line 351, but not defined == Missing Reference: 'G.FLEXGRID' is mentioned on line 237, but not defined == Missing Reference: 'G.FLEXIGRID' is mentioned on line 342, but not defined == Missing Reference: '3630' is mentioned on line 370, but not defined == Missing Reference: '5862' is mentioned on line 411, but not defined == Unused Reference: 'RFC3630' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 457, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 463, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 469, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 473, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 477, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group YL. Zhao 3 Internet-Draft XS. Yu 4 Intended status: Informational J. Zhang 5 Expires: July 13, 2013 BUPT 6 JY. Wang 7 XF. Lin 8 ZTE Corporation 9 January 9, 2013 11 Requirements for Supporting P2MP in Flexi-Grid Networks 12 draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid-01 14 Abstract 16 Multicasting over WDM optical networks has enabled many popular 17 Point-to-Multipoint (P2MP) applications, such as video conference, 18 interactive distance learning, replicated database, distributed 19 computing, and so on. However, on the one hand, the low-rate 20 multicasting traffic demands cannot make full use of the capacity of 21 the entire wavelength, and on the other hand, new services such as 22 data center migration and cloud applications need higher transmission 23 rates and higher spectrum efficiency. Flexi-grid network is an 24 effective solution to address the problem of transmission rate and 25 spectrum utilization. It overcomes the fixed grid constraint of 26 Wavelength Swithched Optical Network (WSON) by using advanced 27 technologies such as coherent detection and Bandwidth Variable- 28 Wavelength Selective Switches (BV-WSS). Therefore, it is essential 29 to exploit multicasting over flexi-grid networks. This document 30 covers the requirements for supporting P2MP over flexi-grid 31 infrastructure. Specifically, the scope of requirements listed in 32 this document covers the functionality that should be supported by 33 the control plane. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 13, 2013. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Conventions Used in This Document . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Requirements for Supporting P2MP in Flexi-grid Networks . . . 6 74 4.1. Requirements description . . . . . . . . . . . . . . . . . 6 75 4.2. Examples for Requirements . . . . . . . . . . . . . . . . 7 76 5. Framework of Protocol Extensions . . . . . . . . . . . . . . . 9 77 5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.3. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 Multicasting over WDM optical networks has enabled many popular 98 Point-to-Multipoint (P2MP) applications, such as video conference, 99 interactive distance learning, replicated database, distributed 100 computing, and so on. RFC [4461] presents a set of requirements for 101 the establishment and maintenance of P2MP Traffic-Engineered (TE) 102 Label Switched Paths (LSPs). The requirements not only apply to 103 packet-switched networks under the control of MPLS protocols, but 104 also encompass the requirements of Layer Two Switching (L2SC), Time 105 Division Multiplexing (TDM), lambda, and port switching networks 106 managed by GMPLS protocols. RFC [4875] describes extensions to 107 Resource reSerVation Protocol - Traffic Engineering (RSVP-TE) for the 108 setup of Traffic Engineered (TE) based P2MP Label Switched Paths 109 (LSPs) in MPLS and GMPLS networks. However, the low-rate 110 multicasting traffic demands cannot make full use of the capacity of 111 the entire wavelength. Furthermore, new services such as data center 112 migration and cloud applications need higher transmission rates and 113 higher spectrum efficiency. Flexi-grid network discussed recently is 114 an effective solution to address the problem of transmission rate and 115 spectrum utilization. It overcomes the fixed grid constraint of 116 Wavelength Swithched Optical Network (WSON) by using advanced 117 technologies such as coherent detection and Bandwidth Variable- 118 Wavelength Selective Switches (BV-WSS). It's essential to extend the 119 protocols to exploit P2MP applications over such flexi-grid networks. 121 Flexible grid technology is defined in the latest version of ITU-T 122 G.694.1, which is also a dense wavelength division multiplexing and 123 different from traditional fixed grid technology. Compared to fixed 124 grids, flexible grid has a smaller and agile granularity for the 125 central frequencies and the slot width may range from 12.5GHz to 126 hundreds of GHz. The flexible grid technology allows mixed bit rates 127 or mixed modulation formats transmission system to allocate frequency 128 slots with different slot widths. So that they can be optimized for 129 the bandwidth requirements of a particular bit rate and modulation 130 scheme of the individual channels. In the dynamic flexi-grid 131 networks, not only an appropriate route is necessary to be selected 132 for the client LSP, but also the appropriate width of spectrum slot 133 is needed for the client LSP. The spectrum slot here is made up of 134 several consecutive spectrum slots from end-to-end, and is determined 135 by the data rate and the modulation level. 137 There are several drafts addressing the extensions of GMPLS protocols 138 to support the flexi-grid networks. 139 [draft-ogrcetal-ccamp-flexi-grid-fwk-01] defines a framework and the 140 associated control plane requirements for the GMPLS based control of 141 flexi-grid DWDM networks, and 142 [draft-farrkingel-ccamp-flexigrid-lambda-label-04] defines a new 143 GMPLS lambda label format to support flexi-grid. Besides, 144 [draft-dhillon-ccamp-super-channel-ospfte-ext-04] specifies the 145 extension to TELINK LSA of OSPF routing protocol in support of GMPLS 146 for flex-grid networks, and 147 [draft-hussain-ccamp-super-channel-label-04] defines a super-channel 148 label as a Super-Channel Identifier and an associated list of 12.5 149 GHz slices representing the optical spectrum of the super-channel. 150 This label format can be used in GMPLS signaling and routing protocol 151 to establish super-channel based optical label switched paths (LSPs). 153 This document covers the requirements for supporting P2MP over flexi- 154 grid infrastructure. First, section 3 provides some definitions 155 including background terminology and acronym list. Then, section 4 156 goes over a set of requirements that should be considered when 157 defining the protocol extensions to support P2MP in flexi-grid 158 networks. Next, the framework of extensions for supporting P2MP in 159 flexi-grid networks is presented in Section 5. 161 3. Definitions 163 3.1. Terminologies 165 Flexi-grid: a new technology allows mixed bit rates or mixed 166 modulation formats transmission system to allocate frequency slots 167 with different slot widths. So they can be optimized for the 168 bandwidth requirements of a particular bit rate and modulation scheme 169 of the individual channels. 171 Frequency Slot: a frequency slot is defined by its nominal central 172 frequency and its slot width. It denotes the frequency range 173 allocated to a channel, but unavailable for any other channels. 175 Spectral Slice: the minimum granularity of a frequency slot (e.g. 176 12.5 GHz). 178 Slot Width: the full width of a frequency slot in a flexible grid. 180 Frequency Range: a frequency range is defined as the portion of 181 frequency spectrum included between a lowest and a highest frequency. 183 P2MP tree: the ordered set of LSRs and TE links that comprise the 184 path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. 186 Ingress LSR: the LSR that is responsible for initiating the signaling 187 messages that set up the P2MP TE LSP. 189 Egress LSR: one of potential many destinations of the P2MP TE LSP. 190 Egress LSRs may also be referred to as leaf nodes or leaves. 192 Branch LSR: an LSR that has more than one directly connected 193 downstream LSRs. 195 Source: the sender of traffic that is carried on a P2MP service 196 supported by a P2MP LSP. The sender is not necessarily the ingress 197 LSR of the P2MP LSP. 199 Receiver: a recipient of traffic carried on a P2MP service supported 200 by a P2MP LSP. A receiver is not necessarily an egress LSR of the 201 P2MP LSP. Zero, one, or more receivers may receiver data through a 202 given egress LSR. 204 3.2. Acronyms 206 GMPLS: Generalized Multi-Protocol Label Switching 208 P2MP: Point-to-Multipoint 210 LSP: Label Switched Paths 212 LSR: Label Switched Router 214 WXC: Wavelength Cross Connect 216 WSS: Wavelength Selective Switch 218 4. Requirements for Supporting P2MP in Flexi-grid Networks 220 4.1. Requirements description 222 The broadcast-and-select mechanism at the WXC node by employing 223 bandwidth-variable WSS is suitable for multicasting traffic. This 224 document covers the high level requirements for the support P2MP over 225 flexi-grid infrastructure. 227 [Requirement 1 ] Flexible Bandwidth of P2MP LSP 229 The protocol should allow the P2MP LSP in the flexi-grid network to 230 be of different sizes/bandwidths. The number of Spectral Slices and 231 the granularity of each slice could be flexible. 233 [Requirement 2 ] Flexible mapping of P2MP LSP 235 This means the P2MP LSP should be allowed to be mapped to any 236 Frequency Range in the ITU grid. Note that the Frequency Range 237 allocation of P2MP LSP on the ITU-Grid shall confirm to [G.FLEXGRID]. 239 [Requirement 3 ] Consecutive Frequency Range of P2MP LSP 241 This means that the spectral resources allocated to P2MP LSP must be 242 consecutive. 244 [Requirement 4 ] Flexibly choose the modulation format for P2MP LSP 246 Each channel mapped to the flexi-grid system shall have the 247 capability to support different modulation formats, e.g. BPSK, QPSK, 248 8PSK, 16QAM, 64QAM, and so on. 250 [Requirement 5 ] Bandwidth Resizing of P2MP LSP 252 Since the bandwidth of P2MP LSP depends on the modulation format of 253 the signal, the protocol shall allow bandwidth resizing if the 254 modulation format of optical signal changes. 256 [Requirement 6 ] Bandwidth Resizing for subset of P2MP LSP 258 Moreover, the extended protocol should support the functionality 259 which allows a subset of the P2MP LSP bandwidth resizing, e.g., 260 changing the modulation format of optical signal. 262 4.2. Examples for Requirements 264 In the current optical networks, a single given modulation format, 265 such as BPSK, QPSK, and most recently n-QAM is employed. In P2MP 266 scenario, there may be more than one destination LSR, and each 267 destination LSR has a different path length. The design of the 268 system ensures that the longest path can be transmitted with a 269 sufficient quality of signal. Therefore, at the transmitter of all 270 destination LSRs have the highest modulation format and occupy the 271 largest spectral width regardless of the different optical path 272 length. Thus, some paths shorter than the others result in 273 overspending of network resources. 275 However, in the flexi-grid networks, the modulation format can be 276 elastically selected based on the length of the LSP. The different 277 assignment of spectral bandwidth of P2MP LSP for each destination LSR 278 (including Egress LSR and branch LSR) is based on the different 279 modulation format by varying the number of bits per symbol, for 280 example QPSK (2 bits per symbol) for one destination LSR and 16QAM (4 281 bits per symbol) for another. Note that the increasing of modulation 282 levels lies in the narrower spacing of symbols of signal 283 constellation, resulting in receiver sensitivity deterioration. 285 Here is an example for P2MP in flexi-grid network as shown in figure 286 1. 288 Egress LSR 289 +++++ 290 - + F + 291 Ingress Branch - +++++ 292 LSR LSR LSR LSR LSR - Receiver 293 +++++ +++++ +++++ +++++ +++++ - 294 + A + --- + B + --- + C + --- + D + --- + E + - 295 +++++ +++++ +++++ +++++ +++++ - 296 Source - LSR Egress LSR 297 - +++++ +++++ 298 - + G + --- + H + 299 +++++ +++++ 300 Receiver 302 Figure 1 An example for bandwidth resizing of P2MP LSP 304 There is a P2MP request from Node A to Nodes F and H, and suppose its 305 bit rate is 60Gbit/s. When we construct a P2MP tree like figure 1, 306 the hops from A to F is 5, and from A to H is 6. Suppose a LSP which 307 has more than 5 hops must take QPSK modulation level for reducing the 308 nonlinear transmission impairments. then, in order to ensure that the 309 worst case optical path in this P2MP request, usually we take QPSK as 310 the modulate level. Here, 60 GHz spectral resources are needed. 311 Since the minimum granularity of a Frequency Slot is 12.5 GHz, a 312 frequency slot consisting 5 spectral slices with the Slot Width being 313 62.5 GHz are used. Note that these 5 frequency slices must be 314 consecutive in the spectral domain. 316 In the first scenario, link A-B has not enough spectral resources, 317 e.g. only has 4 spectral slices being consecutive. So we could 318 change the modulate level if we want to route this P2MP LSP 319 successfully. Here, we change the modulation level from QPSK to 320 16QAM. That's mean only 3 spectral slices are needed here. 322 In the second scenario, link A-B has not enough spectral resources, 323 e.g. only has 4 spectral slices being consecutive. Under the 324 assumption that O/E/O converting is permitted at the middle nodes, we 325 could cut this P2MP LSPs into three parts, one from A to D, one from 326 D to F, and the third one from D to H. For the LSP from A to D, we 327 take 16QAM as its modulation level; for the LSP from D to F, we take 328 64 QAM as the modulation level; and for the LSP from D to H, we take 329 16 QAM as the modulation level. That's means that only 3, 2, 3 330 spectral slices are needed here respectively. 332 5. Framework of Protocol Extensions 334 Mixed bitrate transmission systems can allocate their channels with 335 different spectral bandwidths so that the channels can be optimized 336 for the bandwidth requirements of the particular bit rate and 337 modulation format of the individual channels. A flexible grid 338 network selects its data channels as arbitrarily assigned spectral 339 slices. It is being developed within the ITU-T Study Group 15 to 340 allow the selection and switching of individual lambdas chosen 341 flexibly from a detailed, fine granularity grid of wavelength with 342 arbitrary spectral bandwidth [G.FLEXIGRID]. Our analysis has 343 determined that there are significant problems with existing 344 protocols for supporting P2MP in flexi-grid networks. The problems 345 include RSVP, OSPF, PCE, PCEP and so on. So additional extensions 346 may be needed because of new features introduced by flexible grid. 347 This section addresses the framework extensions of the requirements. 349 5.1. Signaling 351 RFC [4875] describes extensions to Resource reSerVation Protocol- 352 Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered 353 (TE) P2MP Label Switched Paths (LSPs) in MPLS and GMPLS networks. 354 This section outlines RSVP-TE extensions for the support of P2MP in 355 flexi-grid networks. The ingress and egress nodes of the LSP must be 356 capable of indicating whether the Link-State and the modulation 357 format of the LSP should be collected during the signaling procedure 358 of setting up the LSP, and the endpoints of the LSP may collect the 359 Link-State and modulation format information and use it for 360 configuration purposes. When the Link-State and the modulation 361 format of a LSP changes, e.g., if the administrator changes the route 362 of a LSP, the endpoints of the LSP need to be capable of updating the 363 Link-State information and the modulation format information of the 364 LSA. During a new P2MP LSP establishment, each node along the path 365 allocates the required number of spectral slices and also learns the 366 other optical parameters. 368 5.2. Routing 370 RFC [3630] describes extensions to the OSPF protocol version 2 to 371 support intra-area traffic engineering, using Opaque Link State 372 Advertisements. This section outlines OSPF-TE extensions for the 373 support of P2MP in flexi-grid networks. As for stateful PCE, the PCE 374 has a TED plus an LSP-DB which are the active LSPs state (e.g. the 375 route and the slot used by a working LSP). So no extensions needed 376 here; As for stateless PCE, the TED may be filled through OSPF-TE, 377 thus OSPF-TE extensions may be required to carry used frequency slot 378 information, such as the associated bit-rate and modulation format. 380 5.3. PCE 382 The Path Computation Element (PCE) defined in [RFC4655] provides path 383 computation functions in support of traffic engineering in GMPLS 384 networks. It is an entity that is capable of computing a network 385 path or route based on a network graph and of applying computational 386 constraints. [RFC4655] also defines various deployment models that 387 place PCEs differently within the network. The PCEs may be 388 collocated with the Label Switching Routers (LSRs), may be part of 389 the management system that requests the LSPs to be established, or 390 may be positioned as one or more computation servers within the 391 network. 393 This part examines the applicability of PCE to path computation for 394 P2MP TE LSPs in Flexi-grid networks. As for stateful PCE, PCE has a 395 TED plus an LSP-DB which are the active LSPs state; and as for 396 stateless PCE, PCE exploits a TED which includes per-link information 397 regarding the usage of the optical spectrum resource. In order to 398 identify the information of the route, the TED plus the LSP-DB 399 exploited by the PCE should be extended to store the following 400 information: 402 o Bit rate of any working LSP in the network. 404 o Modulation format of any working LSP in the network. 406 o Allocated central frequency and slot width for any active LSP in 407 the network. 409 5.4. PCEP 411 RFC [5862] complements the general requirements and presents a 412 detailed set of PCC-PCE communication protocol requirements for P2MP 413 MPLS/GMPLS traffic engineering. This part examines the applicability 414 of PCEP to path computation for P2MP TE LSPs in Flexi-grid networks. 415 Similar with PCE, an extension may be needed in the PCEP Path 416 Computation Reply message to inform the ingress node about the 417 following information along the route: 419 o Bit rate of any working LSP in the network. 421 o Modulation format of any working LSP in the network. 423 o Allocated central frequency and slot width for any active LSP in 424 the network. 426 6. Security Considerations 428 TBD. 430 7. IANA Considerations 432 TBD. 434 8. References 436 8.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 439 Requirement Levels", RFC 2119, March 1997. 441 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 442 (TE) Extensions to OSPF Version 2", RFC 3630, 443 September 2003. 445 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 446 Multipoint Traffic-Engineered MPLS Label Switched Paths 447 (LSPs)", RFC 4461, April 2006. 449 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 450 Element (PCE)-Based Architecture", RFC 4655, August 2006. 452 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 453 "Extensions to Resource Reservation Protocol - Traffic 454 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 455 Switched Paths (LSPs)", RFC 4875, May 2007. 457 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 458 (PCC) "C Path Computation Element (PCE) Requirements for 459 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 461 8.2. Informative References 463 [1] ITU-T, "Draft revised G.694.1 version 1.6", December 2011. 465 [2] Gonzalez de Dios, O., Casellas, R., Zhang, F., Fu, X., 466 Ceccarelli, D., and I. Hussain, 467 "draft-ogrcetal-ccamp-flexi-grid-fwk-01", October 2012. 469 [3] King, D., Farrel, A., Li, Y., Zhang, F., and R. Casellas, 470 "draft-farrkingel-ccamp-flexigrid-lambda-label-04", 471 October 2012. 473 [4] Dhillon, A., Hussain, I., Rao, R., and M. Sosa, 474 "draft-dhillon-ccamp-super-channel-ospfte-ext-04", 475 November 2012. 477 [5] Hussain, I., Dhillon, A., Pan, Z., Sosa, M., Basch, B., 478 Liu, S., and Andrew G. Malis, 479 "draft-hussain-ccamp-super-channel-label-04", September 480 2012 . 482 Appendix A. Acknowledgments 484 The RFC text was produced using Marshall Rose's xml2rfc tool. 486 Authors' Addresses 488 Yongli Zhao 489 BUPT 490 No.10,Xitucheng Road,Haidian District 491 Beijing 100876 492 P.R.China 494 Phone: +8613811761857 495 Email: yonglizhao@bupt.edu.cn 496 URI: http://www.bupt.edu.cn/ 497 Xiaosong Yu 498 BUPT 499 No.10,Xitucheng Road,Haidian District 500 Beijing 100876 501 P.R.China 503 Phone: +8613811731723 504 Email: xiaosongyu@bupt.edu.cn 505 URI: http://www.bupt.edu.cn/ 507 Jie Zhang 508 BUPT 509 No.10,Xitucheng Road,Haidian District 510 Beijing 100876 511 P.R.China 513 Phone: +8613911060930 514 Email: lgr24@bupt.edu.cn 515 URI: http://www.bupt.edu.cn/ 517 Jiayu Wang 518 ZTE Corporation 519 No.16,Huayuan Road,Haidian District 520 Beijing 100191 521 P.R.China 523 Phone: +861061198108 524 Email: wang.jiayu1@zte.com.cn 525 URI: http://www.zte.com.cn/ 527 Xuefeng Lin 528 ZTE Corporation 529 No.16,Huayuan Road,Haidian District 530 Beijing 100191 531 P.R.China 533 Phone: +8615901011821 534 Email: lin.xuefeng@zte.com.cn 535 URI: http://www.zte.com.cn/