idnits 2.17.1 draft-hu-trill-rbridge-vrrp-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 281: '...dress. RBridges MUST NOT forwards a f...' RFC 2119 keyword, line 300: '... FCS check fails SHOULD be discarded (...' RFC 2119 keyword, line 346: '...t with unknown type MUST be discarded....' RFC 2119 keyword, line 361: '...virtual nickname MUST be 255 (decimal)...' RFC 2119 keyword, line 363: '...up a virtual RBridge MUST use priority...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Dec 30, 2011) is 4493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VRRPv3' is mentioned on line 167, but not defined == Missing Reference: 'CKSM' is mentioned on line 395, but not defined == Unused Reference: 'RFC1071' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC3768' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC5798' is defined on line 465, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL H. Zhai 3 Internet-Draft F. Hu 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 2, 2012 Dec 30, 2011 7 Extending the Virtual Router Redundancy Protocol for TRILL campus 8 draft-hu-trill-rbridge-vrrp-02.txt 10 Abstract 12 TRILL can be implemented in data center networks, which requires high 13 reliability and stability. Whenever the egress RBridges or links 14 break down, the TRILL rerouting time depends on the IS-IS topology 15 convergence time, which may do not meet data center service 16 requirements in terms of resiliency. VRRP provides a redundancy 17 mechanism to avoid single point of failure and fast switching over. 18 This draft proposes to extend VRRP protocol to TRILL in data center 19 networks. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 2, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 4 58 4. TRILL VRRP Frames . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. TRILL-VRRP Multicast Address . . . . . . . . . . . . . . . 7 60 4.2. Source RBridge MAC Address . . . . . . . . . . . . . . . . 7 61 4.3. L2-TRILL-VRRP Ethertype . . . . . . . . . . . . . . . . . 7 62 4.4. Frame Check Sequence (FCS) . . . . . . . . . . . . . . . . 8 63 5. TRILL VRRP Payload Format . . . . . . . . . . . . . . . . . . 8 64 5.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.3. Virtual RB ID . . . . . . . . . . . . . . . . . . . . . . 9 67 5.4. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.5. Count Nicknames . . . . . . . . . . . . . . . . . . . . . 9 69 5.6. Rsvd . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.7. Maximum Advertisement Interval (Max Adver Int) . . . . . . 9 71 5.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.9. Virtual System ID . . . . . . . . . . . . . . . . . . . . 10 73 5.10. Nickname(s) . . . . . . . . . . . . . . . . . . . . . . . 10 74 6. VRRP Protocol State Machine . . . . . . . . . . . . . . . . . 10 75 7. IS-IS Adjacency . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative references . . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 TRILL (Transparent Interconnection of Lots of Links) provides optimal 86 pair-wise data forwarding without configuration, safe forwarding even 87 during periods of temporary loops, and support for multi-pathing of 88 both unicast and multicast traffic[RFC6325]. TRILL is designed to 89 replace STP (Spanning Tree Protocol) for data center networks.The 90 IS-IS routing protocol is used as a control plane protocol to 91 discover the topology and advertise link states. When the topology 92 changes, IS-IS LSPs flood the link state information to other 93 adjacencies. The topology convergence time can go up to about dozens 94 of seconds for particular data center topologies, which may do not 95 meet data center service requirements. 97 VRRP (Virtual Router Redundancy Protocol) specifies an election 98 protocol that dynamically assigns responsibility for a virtual router 99 to one of the VRRP routers on a LAN in IP network. There is one 100 master equipment and one or several backup equipments in a VRRP 101 group. The VRRP group looks like one equipment from the host side. 102 This document is to extend VRRP to support nickname namespace and 103 apply the VRRP protocol in TRILL network. VRRP is used to solve the 104 single of point failure of edge equipment, and fast the switching 105 over time by avoiding topology changed in TRILL campus network. 106 There is a VRRP group including one master BRB(Border RBridge) and 107 one or several backup BRBs in the TRILL edge network. When the 108 master BRB is failed, one of the backup BRB takes the role of master 109 in the VRRP group. The master BRB floods the virtual nickname in 110 TRILL campus network. The other RBridges doesn't feel the change of 111 master and the ISIS topology doesn't change. 113 The remainder of this document is organized as follows: Sction 3 114 describes the VRRP application scenarios. There are two application 115 scenarios introduced in the document. Section 4 specifics the TRILL 116 VRRP frame structure and encapsulation. The TRILL VRRP frame is 117 encapsulated as the payload of Ethernet Frame. There is new type 118 "L2-TRILL-VRRP" Ethertype to identify the TRILL VRRP frame. Section 119 5 specifics the VRRP frame fields in details. Section 6 describes 120 the VRRP protocol state machine. Section 7 describes IS-IS adjacency 121 when deployed VRRP protocol in the RBridges. 123 2. Terminology 125 Border RBridge: Abbr.BRB, a device locates the border of TRILL campus 126 and runs TRILL protocol, BRB is used to communicate with other TRILL 127 campus 129 VRRP RBridge: an RBridge running the Virtual Router Redundancy 130 Protocol. It may participate in one or more VRRP groups. 132 Virtual RBridge: An abstract object managed by VRRP that acts as a 133 default RBridge for devices on a shared LAN. It consists of a 134 Virtual System Identifier and a set of associated nickname (s) across 135 a common LAN. A VRRP RBridge may backup one or more virtual 136 RBridges. 138 Nickname Owner:The VRRP RBridge that has the virtual RBridge's 139 nickname as one of its nickname addresses. This is the RBridge that, 140 when up, will respond to packets addressed to one of these nickname 141 addresses for ICMP pings, TCP connections, etc. 143 Virtual RBridge master:The VRRP RBridge that is assuming the 144 responsibility of forwarding packets sent to the nickname associated 145 with the virtual RBridge, and answering ARP requests for these 146 nickname. Note that if the nickname owner is available, then it will 147 always become the Master. 149 Virtual RBridge backup:The set of VRRP RBridge available to assume 150 forwarding responsibility for a virtual RBridge should the current 151 Master fail. 153 3. Application Scenario 155 Figure 1 is a data center application scenario. BRB is the edge of 156 data center and the exit RBridge for the VLAN. In order to improve 157 the reliability, BRB2 is the backup of BRB1 for the VLAN. If BRB1 is 158 broken, RB1 and RB2 recalculate the route, and BRB2 becomes the exit 159 RBridge for the VLAN. RB1 and RB2 should flush the new LSP in the 160 network. It takes more than several seconds to switch data traffic 161 from BRB1 to BRB2, which is not satisfied to the current data center 162 video traffic. In addition, if the physical connection between RT1 163 and BRB1 is broken, RB1 can not feel the failure. 165 This document proposes to apply VRRP for ensure fast BRB switching 166 upon failure. The VRRP mechanism can guarantee a sub-second (less 167 than 50ms) switching time to ensure video data [VRRPv3]. Master BRB 168 and backup BRBs are configured as belonging to a same VRRP group with 169 the same virtual system ID and virtual nickname. The master BRB of 170 the group floods the virtual nickname to adjacencues. If the Master 171 BRB becomes unavailable, then the highest priority Backup BRB will be 172 elected as Master after a short delay, providing a controlled 173 transition of the virtual RBridge responsibility with minimal service 174 interruption, and the Master BRB elected floods Link State Packets 175 (LSPs) and is responsible for data forwarding in TRILL campus 176 network, and the content of LSPs and the IS-IS link state topology 177 doesn't change. 179 In addition, two VRRP groupes can be configured in the BRBs, one 180 group is used to down link, and the other is used to up link. The 181 two VRRP groupes can be linkage: Once a VRRP group switches over the 182 master,the other VRRP group will switch over the master BRB too. The 183 physical connection between RT1 and RBR1 is broken, the up VRRP group 184 switches the master to BRB2, and notifies the down link VRRP group to 185 switch BRB2 too. 187 +-------+ +-------+ 188 | RT1 | | RT2 | 189 +---+---+ +---+---+ 190 | | IP Cloud 191 ------------------------------------------------- 192 | | data center 193 +---+---+ +---+---+ 194 | BRB1 | | BRB2 | 195 +---+---+ +---+---+ 196 | \ / | 197 | \/ | 198 | /\ | 199 | / \ | 200 +---+---+ +---+---+ 201 | RB1 | | RB2 | 202 +-------+ +-------+ 204 Figure 1 206 Figure 2 is multi-level TRILL deployment scenario. It is 207 recommedated that there is only one BRB in the border of two levels. 208 The BRB becomes the bottleneck of TRILL network in case of failure, 209 and is very easy to create such a single point of failure. Extension 210 of VRRP can improve the reliability of BRB and avoiding the single 211 point of failure. 213 +---------------------------------------+ 214 | | 215 | +-------+ +-------+ | 216 | | RBx | | RBy | | 217 | +---+---+ +---+---+ | 218 | | | Level 2 | 219 | | | | 220 | +---+---+ +---+---+ | 221 +-----| BRB1 |-----| BRB2 |-----------+ 222 +-----| |-----| |-----------+ 223 | +---+---+ +---+---+ Level 1 | 224 | | \ / | | 225 | | \/ | | 226 | | /\ | | 227 | | / \ | | 228 | +---+---+ +---+---+ | 229 | | RB1 | | RB2 | | 230 | +-------+ +-------+ | 231 +---------------------------------------+ 233 Figure 2 235 4. TRILL VRRP Frames 237 By multicasting periodically a TRILL VRRP frame, a master RBridge 238 announces its existence and functionality to the backup RBridge(s) in 239 a VRRP group. If none TRILL VRRP frame is received in a certain 240 time, backup RBridge(s) will consider the master unavailable and 241 trigger a new master RBridge election process. 243 A TRILL VRRP frame on an 802.3 link is structured as figure 3. All 244 such frames are Ethertype encoded. The RBridge port out which such a 245 frame is sent will strip the outer VLAN tag if configured to do so. 247 VRRP Frame Structure 249 Outer Ethernet Header: 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | TRILL-VRRP Multicast Address | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | TRILL-VRRP continued | Source RBridge MAC Address | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Source RBridge MAC Address continued | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | L2-TRILL-VRRP Ethertype | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 VRRP for TRILL Payload: 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | TRILL VRRP Payload | 266 Frame Check Sequence: 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | FCS (Frame Check Sequence) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 3 273 4.1. TRILL-VRRP Multicast Address 275 The TRILL-VRRP multicast address is an IP-derived multicast MAC 276 address. The IP address is: 278 224.0.0.18 280 The IP-derived multicast address is a link local scope multicast 281 address. RBridges MUST NOT forwards a frame with this destination 282 address to another link. 284 4.2. Source RBridge MAC Address 286 It is a MAC address of RBridge port out which this TRILL VRRP frame 287 is sent 289 4.3. L2-TRILL-VRRP Ethertype 291 It is used to indicate that the payload in the frame is a TRILL VRRP 292 packet 294 4.4. Frame Check Sequence (FCS) 296 Each Ethernet frame has a single Frame Check Sequence (FCS) that is 297 computed to cover the entire frame, for detecting frame corruption 298 due to bit errors on a link. Thus, when a frame is encapsulated, the 299 original FCS is not included but is discarded. Any received frame 300 for which the FCS check fails SHOULD be discarded (this may not be 301 possible in the case of cut through forwarding). 303 Although the FCS is normally calculated just before transmission, it 304 is desirable, when practical, for an FCS to accompany a frame within 305 an RBridge after receipt. 307 5. TRILL VRRP Payload Format 309 The format of TRILL VRRP payload is structured as figure 5. 311 VRRP Payload Format 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |Version| Type | Virtual RB ID | Priority |Count Nicknames| 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |(rsvd) | Max Adver Int | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Virtual System ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Virtual System ID Continued | Nickname (1) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Nickname (2) | Nickname (3) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 : : 327 : : 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Nickname (n-1) | Nickname (n) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4 334 5.1. Version 336 The version field specifies the TRILL VRRP protocol version of this 337 packet. This document defines version 1. 339 5.2. Type 341 The type field specifies the type of this TRILL VRRP packet. The 342 only packet type defined in this version of the protocol is: 344 1 ADVERTISEMENT 346 A packet with unknown type MUST be discarded. 348 5.3. Virtual RB ID 350 The Virtual RBridge Identifier (VRBID) field identifies the virtual 351 RBridge this packet is reporting status for. It is a configurable 352 item in the range 1-255 (decimal). There is no default. 354 5.4. Priority 356 The priority field specifies the sending TRILL VRRP RBridge's 357 priority for the virtual RBridge. Higher values equal higher 358 priority. This field is an 8-bit unsigned integer field. 360 The priority value for the TRILL VRRP RBridge that owns the nicknames 361 associated with the virtual nickname MUST be 255 (decimal). 363 TRILL VRRP RBridges backing up a virtual RBridge MUST use priority 364 values between 1-254 (decimal) and the default priority value is 365 100(decimal). 367 The priority value zero (0) has special meaning, indicating that the 368 current Master has stopped participating in TRILL VRRP. This is used 369 to trigger backup RBridges to quickly transition to Master without 370 having to wait for the current Master to time out. 372 5.5. Count Nicknames 374 The number of nicknames contained in this TRILL VRRP advertisement. 376 5.6. Rsvd 378 This field MUST be set to zero on transmission and ignored on 379 reception. 381 5.7. Maximum Advertisement Interval (Max Adver Int) 383 The Maximum Advertisement Interval is a 12-bit field that indicates 384 the time interval (in centiseconds) between ADVERTISEMENTS. The 385 default is 100 centiseconds (1 second). 387 5.8. Checksum 389 The checksum field is used to detect data corruption in the TRILL 390 VRRP message. 392 The checksum is the 16-bit one's complement of the one's complement 393 sum of the entire TRILL VRRP message starting with the version field. 394 For computing the checksum, the checksum field is set to zero. See 395 RFC1071 for more detail [CKSM]. 397 5.9. Virtual System ID 399 The virtual system id is a 48-bit field that indicates the system id 400 of the virtual RBridge this packet is reporting status for. 402 All the RBridges in a virtual RBridge MUST be configured with the 403 same virtual system id. When a TRILL VRRP packet with different 404 virtual system id from local virtual system id is received, the 405 packet MUST be discarded. This field is used for troubleshooting 406 misconfigured RBridges. 408 5.10. Nickname(s) 410 One or more nicknames are associated with the virtual RBridge. The 411 number of nicknames included is specified in the "Count Nicknames" 412 field. These fields are used for troubleshooting misconfigured 413 RBridges. 415 6. VRRP Protocol State Machine 417 The VRRP protocol state machine is not changed. There are three 418 states: Initialize, backup and master. Initialize state is to wait 419 for a startup event; backup state is to monitor the availability and 420 state of the master RBridge. 422 The master BRB election is according to the priority value. When the 423 RBridge is elected as a virtual RBridge master, it floods LSP with 424 virtual nickname to its adjacencies. If the RBridge is the nickname 425 owner, it becomes the virtual nickname master automatically, and 426 floods LSPs with owner nickname. Backup RBridge monitors and 427 receives the VRRP packet from master. If backup RBridge has already 428 enabled IS-IS protocol, it should flood LSP to withdraw its nickname 429 LSA. Otherwise the backup RBridge should not flood LSP to its 430 neighbors. The Backup RBridge exchanges hello packet with its 431 neighbor, and receives LSPs from its adjacencies except from the 432 master RBridge. Moreover, it never advertises local LSA, which is 433 advertised by master RBridge. 435 7. IS-IS Adjacency 437 Master RBridge should setup and maintain all the adjacencies with the 438 other RBridges except the backup RBridge. The Backup RBridge 439 receives the other RBridges hello packets and IS-IS packets (such as 440 LSP, CSNP, PSNP) besides master RBridge, but should not send any 441 hello and IS-IS packets (LSP, CSNP, PSNP) to other RBridges. The 442 backup RBridge can be detect, 2-way, and report states [RFC6326]. 444 8. Security Considerations 446 9. Acknowledgements 448 The authors would like to gratefully acknowledge many people who have 449 contributed discussion and ideas to the making of this proposal. 451 10. References 453 10.1. Normative references 455 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 456 "Computing the Internet checksum", RFC 1071, 457 September 1988. 459 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 460 dual environments", RFC 1195, December 1990. 462 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 463 RFC 3768, April 2004. 465 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 466 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 468 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 469 Ghanwani, "Routing Bridges (RBridges): Base Protocol 470 Specification", RFC 6325, July 2011. 472 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 473 Ghanwani, "Transparent Interconnection of Lots of Links 474 (TRILL) Use of IS-IS", RFC 6326, July 2011. 476 10.2. Informative References 477 Authors' Addresses 479 Hongjun Zhai 480 ZTE Corporation 481 68 Zijinghua Road 482 Nanjing 200012 483 China 485 Phone: +86-25-52877345 486 Email: zhai.hongjun@zte.com.cn 488 Fangwei Hu 489 ZTE Corporation 490 889 Bibo Road 491 Shanghai 201203 492 China 494 Phone: +86-21-68896273 495 Email: hu.fangwei@zte.com.cn