idnits 2.17.1 draft-lw-spring-sid-allocation-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 : ---------------------------------------------------------------------------- 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 date (July 6, 2015) is 3211 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) == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-ospf-prefix-link-attr-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-03 ** Downref: Normative reference to an Informational draft: draft-kh-spring-ip-ran-use-case (ref. 'I-D.kh-spring-ip-ran-use-case') ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG Ting. Liao 3 Internet-Draft Bo. Wu 4 Intended status: Standards Track Fangwei. Hu 5 Expires: January 7, 2016 ZTE Corporation 6 Bhumip. Khasnabish 7 ZTE TX Inc. 8 July 6, 2015 10 SPRING SID Allocation 11 draft-lw-spring-sid-allocation-02.txt 13 Abstract 15 Segment Routing (SR) allows for a flexible definition of end-to-end 16 paths within IGP topologies by encoding paths as sequences of 17 topological sub-paths, called "segments". These segments are 18 advertised by the link-state routing protocols (IS-IS and OSPF). And 19 a segment is identified by a Segment Routing ID (SID). This document 20 proposes a method to reduce the SID configuration in a SR domain. 21 Only the selected SR nodes which named Segment Routing Management 22 Nodes (SRMNs) are configured by NMS, while other SRs in the domain 23 need zero-SR-configuration. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. SID generation and allocation . . . . . . . . . . . . . . . . 4 63 4.1. SID generation . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. SID allocation . . . . . . . . . . . . . . . . . . . . . 5 65 5. IGP extension . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. The ISIS SID-allocation TLV . . . . . . . . . . . . . . . 6 67 5.2. The OSPF SID-Allocation TLV . . . . . . . . . . . . . . . 7 68 6. SID Allocation Ability extension . . . . . . . . . . . . . . 8 69 6.1. The ISIS SR Capabilities Sub-TLV extension . . . . . . . 8 70 6.2. The OSPF SR Capabilities TLV extension . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 Segment Routing (SR) allows for a flexible definition of end-to-end 80 paths within IGP topologies by encoding paths as sequences of 81 topological sub-paths, called "segments". These segments are 82 advertised by the link-state routing protocols (IS-IS and OSPF). And 83 a segment is identified by a Segment Identifier (SID). A segment can 84 be encoded as a MPLS label or an IPv6 address. Typically a SID is 85 configured by NMS and it very rarely changes. When the SID 86 configured, each node could send out its IGP TLV extensions which had 87 described in [I-D.ietf-isis-segment-routing-extensions] and 88 [I-D.ietf-ospf-segment-routing-extensions]. 90 In some situation where users expect to simply plug in a SR node and 91 have it automatically enable Segment Routing. One of the use cases 92 is described in [I-D.kh-spring-ip-ran-use-case], with hundreds of 93 CSGs in an IP RAN network, the configuration assigned by NMS could be 94 very complexity. And with the complexity of the network such as 95 nodes adding and removing, the management on NMS is a hard work. If 96 the CSGs can plug and play, it will be very useful. And the CSGs 97 could be uploaded with zero-touch currently, by generating the ip 98 address from MAC by default algorithm and with the ospf process 99 default uploaded, have a mechanism to ensure the uniqueness of ip. 100 Then the CSGs could be connected, and the topology will be collected 101 by the ASGs. With the mechanism described in this draft, there is no 102 SR configuration on the CSGs, the CSGs could be zero-touch still, 103 reduce the complexity of SR related configuration and reduce the 104 complexity of NMS. 106 This draft describes a mechanism to optimize SID allocation 107 operation. 109 2. Conventions and Abbreviations 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119] . 115 The following notations and abbreviations are used throughout this 116 draft. 118 ASG: Aggregation Site/Service Gateway. 120 BS: Base Station. 122 CSG: Cell Site Gateway. 124 IP RAN: Internet Protocol RAN 126 RAN: Radio Access Network. 128 RNC: Radio Network Controller. 130 RSG: Radio Service Gateway. 132 SR: Segment Routing. 134 SID: Segment Identifiers. 136 3. Motivation 138 As described in [I-D.kh-spring-ip-ran-use-case] , the IP RAN network 139 scenario is shown in the figure 1. 141 ---------------- 142 / \ 143 / \ 144 +------+ +----+ +----+ +----+ +----+ 145 | BS |---|CSG1| |ASG1|------|RSG1|-----|RNC1| 146 +------+ +-+--+ +----+ +----+ +----+ 147 | Access | Aggration | 148 | Domain | Domain | 149 +------+ +-+--+ +----+ +----+ +----+ 150 | BS |---|CSG2| |ASG2|------|RSG2|-----|RNC2| 151 +------+ +----+ +----+ +----+ +----+ 152 \ / 153 \ / 154 -------------- 156 Figure 1 IP RAN Network Scenario 158 There are hundreds of CSGs (Cell Site Gateway) and a few sets of ASGs 159 (Aggregation Site/Service Gateway) in the Access Domain of an IP RAN 160 network. With the increase of mobile Internet traffic, more CSGs 161 could be added to the Access Domain, and CSGs could be installed in 162 wide area. So, there is a great need to do little or no 163 configuration on CSGs to avoid configuration operation. 165 In current IP RAN implementation, as the CSGs could be uploaded with 166 zero-touch, by generating the ip address from MAC by default 167 algorithm and with the ospf process default uploaded, have a 168 mechanism to ensure the uniqueness of ip. Then the CSGs could be 169 connected, and the topology will be collected by the ASGs. ASGs are 170 configured by NMS, and the configurations on CSGs are configured by 171 ASGs, typical MPLS protocols like LDP protocol is used. With SR 172 replacing LDP, complexity in LDP configuration could be greatly 173 reduced. But in current SR process, each SR node should be 174 configured by NMS, including the SR related configurations such as 175 SIDs and SR algorithm and SR global blocks. 177 If the configuration on CSGs still need to be came from ASGs, a 178 specific mechanism is proposed in this draft to fulfill this 179 requirement. Like the network in the above figure, an ASG or both 180 the ASGs could be selected as a SID management node to advertise CSGs 181 and ASGs SID mapping to the whole SR domain. 183 4. SID generation and allocation 185 In the proposed mechanism, one or more Segment Routing Management 186 Nodes (SRMNs) reside at SR nodes and advertise the SID mapping 187 information for the various prefix associated with the SR nodes in 188 the SR domain. 190 4.1. SID generation 192 The NMS configure the SRGB block to the SRMN. The SRMN will generate 193 SIDs to other nodes'router-ids and to the router-id of itself, the 194 generation principle based on the configuration of the NMS or the 195 default generation rule, the default allocation rule MAY be based on 196 the numerically higher router-id with the higher SID allocated. 198 4.2. SID allocation 200 As described in section 3, when the SR node is powdered on, the IGP 201 protocol as default function loaded, each node flooding out each 202 router information in ISIS LSP or OSPF LSA when the ISIS adjacency or 203 OSPF adjacency relations formed, and every node will acquire the 204 router-ids of other nodes from the information (such as the IP 205 address of router id) of IGP TLV. 207 Then the SRMN generates the SIDs mapping to the router-ids and 208 allocates the SIDs to each SR node by using the extension of SID 209 Allocation TLV or the SID Binding TLV(as described in 210 [I-D.ietf-isis-segment-routing-extensions] and 211 [I-D.ietf-ospf-segment-routing-extensions]. )in the IGP packet, 212 flooding the packet out. In the SID Allocation TLV, it carries the 213 router-id and SID mapping, and related algorithm type, and related 214 multi-topology number. And in one SID-Allocation TLV, it can carry 215 one or more IP addresses. 217 Optionally, If more than one SRMN assigned by the NMS, the SRMNs May 218 flood out another extension which indicating having the capability to 219 allocate SID, this extension is called the SR Allocation Ability 220 extension and be included in the SR capabilities. When other SR 221 nodes receive more than one of the SRMN advertised the extension, the 222 SR node could decide how to choose the Allocated SID, the choosing 223 principle is based on the value of SRMNs' router id or system id, the 224 maximum or the minimum value is chosen, and the SID allocated by the 225 maximum or minimum id's SRMN be chosen. When each SR node received 226 the IGP packet with the SID Allocation TLV, it will know which SID is 227 allocated to itself, and then the SR node sends out the prefix-SID 228 sub-TLV in its IGP packet flooding out in the IGP area. 230 Then each SR node will know the other SR nodes' SID, and the related 231 algorithm will calculate the path to each SR node's SID. 233 With the automatic uniform allocation by the SRMN in the IGP area, 234 when a new node is added, the SRMN will know which SIDs had been 235 allocated, and allocate an unused SID in the SRGB to the new node's 236 IP address. And if the node has moved, the SRMN will delete the 237 related SID to the moving node's IP address and recycle this SID. 239 The SID uniqueness is managed on the SRMN. 241 If more than one SRMN assigned by the NMS, the SR Allocation Ability 242 extension will be used, the detail information is described in 243 section 4.2. 245 5. IGP extension 247 The SID Allocation TLV MAY be originated by any assigned router in an 248 IS-IS domain or an OSPF domain. As 249 [I-D.ietf-ospf-segment-routing-extensions] defines OSPF extension 250 for the purpose of the advertisements of various SID values, new 251 Opaque LSAs [RFC5250] are defined in 252 [I-D.ietf-ospf-prefix-link-attr]. But the SID Allocation TLV is no 253 need to binding with the prefix of the router or re-advertised by the 254 router. The SID Allocation TLV may be advertised in a new Opaque 255 LSA. 257 5.1. The ISIS SID-allocation TLV 259 The SID Allocation TLV has Type TBD, and has the following format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Flags | Range | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MT-ID | Algorithm | Prefix | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Prefix | SID (variable) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2 ISIS SID-allocation TLV 273 o Type: TBD. 275 o 1 octet of Length: variable, in bytes. 277 o 1 octet of flags. 279 o 1 octets of Range: The 'Range' field provides the ability to 280 specify a range of addresses and their allocated SIDs. It is 281 essentially a compression scheme to allocate a continuous Prefix 282 and their continuous, corresponding SID/Label Block. If a single 283 SID is advertised then the range field MUST be set to one. For 284 range advertisements > 1, the number of addresses that need to be 285 mapped into a Prefix-SID and the starting value of the Prefix-SID 286 range. 288 o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]). 290 o 1 octet of Algorithm: one octet identifying the algorithm type the 291 Prefix-SID is associated. The following value is defined by this 292 document: 294 * 0: IGP metric based Shortest Path Tree (SPT). 296 o 4 octet of Prefix. 298 o 4 octet of SID: according to the flags, it contains: 300 * A 32 bit index defining the offset in the SID/Label space 301 advertised by this router using the encodings defined in 302 Section 3.1. 304 * A 24 bit label where the 20 rightmost bits are used for 305 encoding the label value. 307 5.2. The OSPF SID-Allocation TLV 309 The SID Allocation TLV has Type TBD, and has the following format: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | Flags | Range | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | MT-ID | Algorithm | Prefix | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Prefix | SID (variable) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 3 OSPF SID-allocation TLV 323 o Type: TBD. 325 o 1 octet of Length: variable, in bytes. 327 o 1 octet of flags. 329 o 1 octets of Range: The 'Range' field provides the ability to 330 specify a range of addresses and their allocated SIDs. It is 331 essentially a compression scheme to allocate a continuous Prefix 332 and their continuous, corresponding SID/Label Block. If a single 333 SID is advertised then the range field MUST be set to one. For 334 range advertisements > 1, the number of addresses that need to be 335 mapped into a Prefix-SID and the starting value of the Prefix-SID 336 range. 338 o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]) 340 o 1 octet of Algorithm: one octet identifying the algorithm type the 341 Prefix-SID is associated. The following value is defined by this 342 document: 344 * 0: IGP metric based Shortest Path Tree (SPT). 346 o 4 octet of Prefix. 348 o 4 octet of SID: according to the flags, it contains: 350 * A 32 bit index defining the offset in the SID/Label space 351 advertised by this router using the encodings defined in 352 Section 3.1. 354 * A 24 bit label where the 20 rightmost bits are used for 355 encoding the label value. 357 6. SID Allocation Ability extension 359 With the compatibility consideration, nodes in the SR domain need to 360 advertise its SR data-plane capability by using SR-Capabilities TLV 361 in OSPF area or SR-Capabilities sub-TLV in ISIS area. So the 362 assigned router advertises its SID allocation capability, it may be 363 included in SR-Capabilities Sub-TLV of ISIS or in SR-Capabilities TLV 364 of OSPF, with the Special Flag to indicate it is an assigned router. 366 6.1. The ISIS SR Capabilities Sub-TLV extension 368 The ISIS SR Capabilities Sub-TLV (Type: TBD) is optional, MAY appear 369 multiple times inside the Router Capability TLV and has following 370 format: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | Flags | Range | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Range (cont.) | SID/Label Sub-TLV (variable) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 4 ISIS SR Capabilities Sub-TLV 382 o Type: TBD. 384 o 1 octet of Length: variable, in bytes. 386 o 1 octet of flags, the following are defined: 388 0 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 |I|V|A| | 392 +-+-+-+-+-+-+-+-+ 394 where: 396 o I-Flag: IPv4 flag. If set, then the router is capable of outgoing 397 IPv4 encapsulation on all interfaces. 399 o V-Flag: IPv6 flag. If set, then the router is capable of outgoing 400 IPv6 encapsulation on all interfaces. 402 o A-Flag: Allocation flag. If set, then the router is capable of 403 allocating SID capability. 405 3 octets of Range: defining the number of values of the range from 406 the starting value defined in the SID/Label Sub-TLV. 408 SID/Label Sub-TLV: SID/Label value as defined in 409 [I-D.ietf-isis-segment-routing-extensions]. 411 6.2. The OSPF SR Capabilities TLV extension 413 As described in [I-D.ietf-ospf-segment-routing-extensions], the SID/ 414 Label Range TLV as an additional router capability of SR, it is a 415 top-level TLV of the Router Information Opaque LSA (defined in 416 [RFC4970] ). 418 The SID/Label Range TLV MAY appear multiple times and has the 419 following format: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Range Size | Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sub-TLVs (variable) | 429 +---------------------------------------------------------------+ 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 5 OSPF SR Capabilities TLV 435 o Type: TBD. 437 o 1 octet of Length: variable, in bytes. 439 o Range Size: 3 octets of the SID/label range. 441 o Reserved: 1 octets, where the following extension are defined: 443 0 444 0 1 2 3 4 5 6 7 445 +-+-+-+-+-+-+-+-+ 446 |A| | 447 +-+-+-+-+-+-+-+-+ 449 where: 451 o A-Flag: Allocation flag. If set, then the router is capable of 452 allocating SID capability. 454 Sub-TLVs: Initially, the only supported Sub-TLV is the SID/Label TLV 455 as defined in [I-D.ietf-ospf-segment-routing-extensions]. 457 7. Security Considerations 459 TBD. 461 8. Acknowledgements 463 In progress. 465 9. IANA Considerations 467 TBD. 469 10. Normative References 471 [I-D.ietf-isis-segment-routing-extensions] 472 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 473 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 474 Extensions for Segment Routing", draft-ietf-isis-segment- 475 routing-extensions-05 (work in progress), June 2015. 477 [I-D.ietf-ospf-prefix-link-attr] 478 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 479 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 480 Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work 481 in progress), June 2015. 483 [I-D.ietf-ospf-segment-routing-extensions] 484 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 485 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 486 Extensions for Segment Routing", draft-ietf-ospf-segment- 487 routing-extensions-05 (work in progress), June 2015. 489 [I-D.ietf-spring-segment-routing] 490 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 491 and R. Shakir, "Segment Routing Architecture", draft-ietf- 492 spring-segment-routing-03 (work in progress), May 2015. 494 [I-D.kh-spring-ip-ran-use-case] 495 Khasnabish, B., hu, f., and L. Contreras, "Segment Routing 496 in IP RAN use case", draft-kh-spring-ip-ran-use-case-02 497 (work in progress), November 2014. 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 503 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 504 4915, June 2007. 506 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 507 Shaffer, "Extensions to OSPF for Advertising Optional 508 Router Capabilities", RFC 4970, July 2007. 510 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 511 OSPF Opaque LSA Option", RFC 5250, July 2008. 513 Authors' Addresses 515 Ting Liao 516 ZTE Corporation 517 No.50 Software Avenue 518 Nanjing, Jiangsu 210012 519 China 521 Phone: +86 25 88018801 522 Email: liao.ting@zte.com.cn 524 Bo Wu 525 ZTE Corporation 526 No.50 Software Avenue 527 Nanjing, Jiangsu 210012 528 China 530 Phone: +86 25 88018801 531 Email: bo.wu@zte.com.cn 533 Fangwei Hu 534 ZTE Corporation 535 No.889 Bibo Rd 536 Shanghai 201203 537 China 539 Phone: +86 21 68896273 540 Email: hu.fangwei@zte.com.cn 542 Bhumip Khasnabish 543 ZTE TX Inc. 544 55 Madison Avenue, Suite 160 545 Morristown, New Jersey 07960 546 USA 548 Phone: +001-781-752-8003 549 Email: bhumip.khasnabish@ztetx.com