idnits 2.17.1 draft-dong-teas-enhanced-vpn-vtn-scalability-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 date (November 2, 2020) is 1270 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'I-D.dong-spring-sr-for-enhanced-vpn' is defined on line 513, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-10 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-00 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: May 6, 2021 F. Qin 6 China Mobile 7 G. Yang 8 China Telecom 9 November 2, 2020 11 Scalability Considerations for Enhanced VPN (VPN+) 12 draft-dong-teas-enhanced-vpn-vtn-scalability-01 14 Abstract 16 Enhanced VPN (VPN+) aims to provide enhancements to existing VPN 17 services to support the needs of new applications, particularly 18 including the applications that are associated with 5G services. 19 VPN+ could be used to provide network slicing in 5G, and may also be 20 of use in more generic scenarios, such as enterprise services which 21 have demanding requirement. With the requirement for VPN+ services 22 increase, scalability would become an important factor for deployment 23 of VPN+. This document describes the scalability considerations in 24 the control plane and data plane to enable VPN+ services, some 25 optimization mechanisms are also described. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 6, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. VPN+ Scalability Requirements . . . . . . . . . . . . . . . . 3 63 3. VPN+ Scalability Considerations . . . . . . . . . . . . . . . 4 64 3.1. Control Plane Scalability . . . . . . . . . . . . . . . . 5 65 3.1.1. Distributed Control Plane . . . . . . . . . . . . . . 5 66 3.1.2. Centralized Control Plane . . . . . . . . . . . . . . 5 67 3.2. Data Plane Scalability . . . . . . . . . . . . . . . . . 6 68 3.3. Gap Analysis of Existing Mechanisms . . . . . . . . . . . 6 69 4. Possible Optimizations . . . . . . . . . . . . . . . . . . . 7 70 4.1. Control Plane Optimization . . . . . . . . . . . . . . . 7 71 4.2. Data Plane Optimization . . . . . . . . . . . . . . . . . 9 72 5. Solution Evolution for Improved Scalability . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Virtual Private Networks (VPNs) have served the industry well as a 85 means of providing different groups of users with logically isolated 86 connectivity over a common network infrastructure. The VPN service 87 is provided with two network layers: the overlay and the underlay. 88 The underlay is responsible for establishing network connectivity and 89 managing network resources to meet the service requirement. The 90 overlay is used to distribute the membership and reachability 91 information of the tenants, and provide logical separation of service 92 delivery between different tenants. 94 Enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is targeted 95 at new applications which require better isolation between tenants 96 and/or services, and have more stringent performance requirements 97 than can be provided with existing VPNs. To meet the requirement of 98 VPN+ services, Virtual Transport Networks (VTN) need to be created, 99 each with a subset of the underlay network topology and a set of 100 network resources allocated to meet the requirements of one or a 101 group of VPN+ services. The VPN in overlay together with the 102 corresponding VTN in the underlay provide the VPN+ service. 104 [I-D.ietf-teas-enhanced-vpn] provides some general analysis of the 105 scalability of VPN+. This document gives detailed analysis of the 106 scalability considerations when enabling VPN+ services. The focus of 107 this document is mainly on the scalability of the underlay of VPN+, 108 i.e. the VTN. 110 2. VPN+ Scalability Requirements 112 As described in [I-D.ietf-teas-enhanced-vpn], VPN+ services may 113 require additional state to be introduced into the network to take 114 advantage of the enhanced functionality. This introduces some 115 scalability considerations to the network. This section gives some 116 analysis of the number of VPN+ services that might be needed in a 117 network. 119 There are several use cases where VPN+ may be necessary, and these 120 determine how many will be required in a network. One typical use 121 case of VPN+ is to provide network slicing for applications or 122 services in 5G, thus the number of network slices needed could 123 reflect the number of VPN+ services. In the future, with the 124 development and evolution of 5G, it is expected that more and more 125 network slices will be deployed. The number of network slices 126 required is relevant to how network slicing will be used, and the 127 progress of 5G for vertical industrial services. The potential 128 number of network slices is analyzed by classifying the network 129 slicing deployment into three typical scenarios: 131 1. Network slicing can be used by a network opeartor internally to 132 isolate different types of services. For example, in a converged 133 multi-service network, different network slices can be created to 134 carry mobile transport service, fixed broadband service and 135 enterprise services respectively, each type of service could be 136 managed by a separate department or management team. Some 137 service types, such as multicast service may also be deployed in 138 a dedicated network slice. It is also possible that an 139 infrastructure network operator provides network slices to other 140 network operators as a wholesale service. In this scenario, the 141 number of network slices in a network would be relatively small, 142 such as on the order of 10 or so. This could be the typical case 143 in the beginning of the network slicing deployment. 145 2. Network slicing can be used to provide isolated and customized 146 virtual networks for tenants in different vertical industries. 147 At the early stage of the vertical industrial service deployment, 148 a few top tenants in some typical industries will begin to use 149 network slicing to support their business, such as smart grid, 150 manufacturing, public safety, on-line gaming, etc. Considering 151 the number of the vertical industries, and the number of top 152 tenants in each industry, the number of network slices may 153 increase to the order of 100. 155 3. With the evolution of 5G, network slicing could be widely used by 156 both vertical industrial tenants and enterprise tenants which 157 require guaranteed or predictable service performance. The total 158 amount of network slices may increase to the order of 1000 or 159 more. While it is expected that the number of network slices 160 would still be less than the number of traditional VPN services 161 in the network. 163 In 3GPP [TS23501], a 5G network slice is identified using Single 164 Network Slice Selection Assistance Information (S-NSSAI), which is a 165 32-bit identifier comprised of 8-bit Slice/Service Type (SST) and 166 24-bit Slice Differentiator (SD). This allows the mobile network 167 (RAN and CN) to provide a large number of network slices. Although 168 it is possible that multiple network slices in RAN and CN can be 169 mapped to the same transport network slice, the amount of transport 170 slice still needs to be comparable with the number of 5G network 171 slices. Thus the scalability of transport network slices needs to be 172 taken into consideration from the beginning. 174 8-bit 24-bit 175 +------------+-------------------------+ 176 | SST | Slice Differentiator | 177 +------------+-------------------------+ 179 Figure 1. Format of S-NSSAI in 3GPP 181 VPN+ needs to meet the scalability requirement of network slicing in 182 different scenarios. The increased number of VPN+s will introduce 183 additional complexity and overhead to both the control plane and data 184 plane, especially for the underlying virtual transport network. 186 3. VPN+ Scalability Considerations 188 In this section, the scalability in control and data plane is 189 analyzed to understand the possible gaps in meeting the scalability 190 requirement of VPN+. 192 3.1. Control Plane Scalability 194 As described in [I-D.ietf-teas-enhanced-vpn], the control plane of 195 VPN+ could be based on the hybrid of centralized controller and 196 distributed control plane. 198 3.1.1. Distributed Control Plane 200 At part of the construction of VPN+ services, it is necessary to 201 create different VTNs that provide customized topology and resource 202 attributes. The attributes and state information of each VTN needs 203 to be exchanged in the control plane. The scalability of the 204 distributed control plane for the establishment and maintenance of 205 VTNs needs to be considered in the following aspects: 207 o The number of control protocol instances maintained on each node 209 o The number of protocol sessions maintained on each link 211 o The number of routes advertised by each node 213 o The amount of attributes associated with each route 215 o The number of route computation (i.e. SPF) executed on each node 217 As the number of VTNs increases, it is expected that for some of the 218 above aspects, the overhead in the control plane may increase 219 dramatically. For example, the overhead of maintaining separated 220 control protocol instances for each VTN is considered higher than 221 maintaining separated virtual network topologies for different VTNs 222 in the same routing instance, and the overhead of maintaining 223 separate protocol sessions for each VTN is considered higher than 224 using a shared protocol session for the information exchange of 225 multiple VTNs. To meet the requirement of the increasing number of 226 VTNs, It is suggested to choose the control plane mechanisms which 227 could improve the scalability while still provide the required 228 functionality. 230 3.1.2. Centralized Control Plane 232 Although the SDN approach can reduce the amount of control plane 233 overhead in the distributed control plane, it may transfer some of 234 the scalability concerns from network nodes to the centralized 235 controller, thus the scalability of the controller also needs to be 236 considered. 238 To provide global optimization for Traffic Engineered (TE) paths in 239 different VTNs, the controller needs to keep the topology and 240 resource information of all the VTNs up to date. To achieve this, 241 the controller may need to maintain a communication channel with each 242 network node in the network. When there is significant change in the 243 network and multiple VTNs requires global optimization concurrently, 244 there may be a heavy processing burden at the controller, and a heavy 245 load in the network surrounding the controller for the distribution 246 of the updated network state. 248 3.2. Data Plane Scalability 250 To provide different VPN+ services with the required isolation and 251 performance characteristics, it is necessary to allocate different 252 sets of network resources to different VTNs. As the number of VPN+ 253 increases, the number of VTNs will increase accordingly. This 254 requires the underlying network to provide finer-granular network 255 resource partitioning, which means the amount of state about the 256 reserved network resources to be maintained on network nodes will 257 also increase accordingly. 259 In data plane, traffic of different VPN+ services need to be 260 processed separately according to the topology and resource 261 constraints of the associated VTN , thus the identifier of VTN needs 262 to be carried either directly or implicitly in the data packet. 263 Different representations of the VTN identifier in data packet have 264 different scalability implication. One approach is to reuse some 265 existing fields in packet headers to additionally identify the VTN 266 the packet belongs to. As this introduces additional semantics to an 267 existing identifier, it may increase the amount of the identifiers to 268 be allocated and managed, which may not be expected in its original 269 design and could cause scalability problem. An alternative is to 270 introduce a dedicated identifier in the packet for VTN 271 identification. 273 In addition, the introduction of per VTN packet forwarding has impact 274 on the scalability of the forwarding entries on network nodes, as a 275 network node needs to maintain separate forwarding entries for a 276 target node in each VTN it participates. 278 3.3. Gap Analysis of Existing Mechanisms 280 One candidate approach to build VTN is using Segment Routing (either 281 SR-MPLS or SRv6) as the data plane, and distributing the customized 282 topology and resource attribute based on Multi-topology [RFC4915] 283 [RFC5120], Flex-Algo [I-D.ietf-lsr-flex-algo] or the combination of 284 these mechanisms in the control plane. If the number of VTNs 285 increases to a certain extent, such approach may have several 286 scalability issues: 288 1. The number of SR SIDs needed will increase dependent upon the 289 number of VTNs in the network, which will bring challenges both 290 to the SID information distribution in control plane and to the 291 installation of forwarding entries for the SIDs in data plane. 293 2. The number of SPF computation will also increase in proportion to 294 the number of VTNs in the network, which can introduce 295 significant overhead of the computing resources on network nodes. 297 3. The maximum number of network topology supported by OSPF Multi- 298 topology is 128, the maximum number of Flex-Algo is 128, which 299 may not meet the required number of VTNs in some networks. 301 4. Possible Optimizations 303 4.1. Control Plane Optimization 305 For the distributed control plane, several optimizations can be 306 considered to reduce the overhead and improve the control plane 307 scalability. 309 The first optimization mechanism is to reduce the amount of control 310 plane sessions used for the establishment and maintenance of the 311 VTNs. For multiple VTNs which have the same peering relationship 312 between two adjacent network nodes, it is proposed that one single 313 control session is used for the establishment of multiple VTNs. 314 Information of different VTNs can be exchanged over the same control 315 session, with necessary identification information to distinguish 316 them in the control messages. This could reduce the overhead of 317 maintaining a large number of control protocol sessions, and could 318 also reduce the amount of control plane message flooding in the 319 network. 321 The second optimization mechanism is to decompose the attributes of a 322 VTN into different groups, so that different types of attribute can 323 be advertised and processed separately in control plane. For a VTN, 324 there are two basic types of attributes: the topology attribute and 325 the associated network resource attribute. In a network, it is 326 possible that multiple VTNs share the same topology, and multiple 327 VTNs may share the same set of network resource on particular network 328 segments. It is more efficient if only one copy of the topology 329 attribute is advertised, then multiple VTNs sharing the same topology 330 could refer to the topology information, and share the result of 331 topology-based route computation. Similarly, information of a subset 332 of network resource reserved on network segments could be advertised 333 once and then be used by multiple VTNs. This methodology could also 334 apply to other attributes of VTN which may be introduced later and 335 can be processed independently. 337 O#####O#####O O*****O*****O 338 # # # * * * 339 # # # * * * 340 O#####O#####O O*****O*****O 342 VTN-1 VTN-2 344 O-----O-----O 345 | | | 346 | | | 347 O-----O-----O 349 Shared Network Topology 351 Legend 353 O Virtual node 354 ### Virtual links with a set of reserved resource 355 *** Virtual links with another set of reserved resource 357 Figure 2. Topology Sharing between VTNs 359 FIG-2 361 Figure 2 gives an example of multiple VTNs which share the same 362 topology attribute. As shown in the figure, VTN-1 and VTN-2 have the 363 same topology, while the link resource attributes of each VTN are 364 different. In this case, only one copy of the network topology 365 information needs to be advertised, and the topology-based route 366 computation result can be used by both VTNs to generate the routing 367 tables. 369 O#####O#####O O- -O#####O 370 # # # \/ # # 371 # # # /\ # # 372 O#####O#####O O- -O#####O 374 VTN-1 VTN-2 376 Legend 378 O Virtual node 379 ### Virtual links with a set of reserved resource 380 --- Virtual links with another set of reserved resource 382 Figure 3. Resource Sharing between VTNs 384 Figure 3 gives another example of multiple VTNs which shares the same 385 set of network resources on some links. In this case, information 386 about the reserved resource on each link only needs to be advertised 387 once, then both VTN-1 and VTN-2 could refer to the link resource for 388 constraint based computation. 390 For the centralized control plane, it is suggested that the 391 centralized controller is deployed as a complementary mechanism to 392 the distributed control plane rather than replacement, so that the 393 computation burden in control plane could be shared by both the 394 centralized controller and the network nodes, thus the scalability of 395 both systems could be improved. 397 4.2. Data Plane Optimization 399 To support more VPN+ services while keeping the amount of data plane 400 state in a reasonable scale, one possible approach is to classify a 401 set of VPN+ services which has similar service characteristics and 402 performance requirements into a group, and such group of VPN+ is 403 mapped to one VTN, which is allocated with an aggregated set of 404 network topology and resources to meet the service requirement of the 405 whole group of VPN+. Different groups of VPN+ need to be mapped to 406 different VTNs with different set of network resources allocated. 407 With appropriate grouping of VPN+ services, a reasonable number of 408 VTNs with network resources reservation and aggregation could still 409 meet the service requirements. 411 Another optimization in the data plane is to decouple the identifier 412 used for topology-based forwarding and the identifier used for the 413 resource-specific processing introduced by VTN. One possible 414 mechanism is to introduce a dedicated field in the packet header to 415 uniquely identify the set of local network resources allocated to a 416 VTN on each network node for the processing and forwarding of the 417 received packet. Then the existing identifier in the packet header 418 used for topology based forwarding is kept unchanged. The benefit is 419 the number of existing topology-specific identifiers will only 420 increase in proportion to the number of topologies rather than the 421 number of VTNs, so that its scalability will not be impacted by the 422 increase of VTN. Note this probably requires network nodes to 423 support a hierarchical forwarding table in the data plane. Figure 4 424 shows the concept of using different data plane identifiers for 425 topology-based and VTN resource-based packet processing respectively. 427 +--------------------------+ 428 | Packet Header | 429 | | 430 | +----------------------+ | 431 | | Topology-specific ID | | 432 | +----------------------+ | 433 | | 434 | +----------------------+ | 435 | | VTN Resource ID | | 436 | +----------------------+ | 437 +--------------------------+ 439 Figure 4. Decoupled Data Plane Identifiers 441 In an IPv6 [RFC8200] based network, this could be achieved by 442 introducing a dedicated field in either the IPv6 fixed header or one 443 of the extension headers to carry the VTN identifier for the 444 resource-specific forwarding, while keeping the destination IP 445 address field used for routing towards the destination prefix in the 446 corresponding topology. Note that the VTN ID needs to be parsed by 447 every node along the path which is capable of VTN-specific 448 forwarding. In an MPLS [RFC3032] based network, this may be achieved 449 by introducing a dedicated MPLS label to identify the VTN instance, 450 while the existing MPLS labels could be used for topology-based 451 packet forwarding towards the associated destination prefix. This 452 requires that both labels be parsed by each node along the forwarding 453 path of the packet. The detailed extensions in IPv6 and MPLS 454 encapsulation are out of the scope of this document. 456 5. Solution Evolution for Improved Scalability 458 Based on the analysis in this document, the control plane and data 459 plane for VPN+ needs to evolve to support the increasing number of 460 VPN+ services in the network. 462 For example, by introducing resource-awareness to segment routing 463 SIDs [I-D.ietf-spring-resource-aware-segments], and using Multi- 464 Topology or Flex-Algo as control plane could provide a solution for 465 building a limited set of VTNs in the network to meet the requirement 466 of a small number of VPN+ in the network. Such mechanism is 467 considered as basic SR-VTN. 469 As the number of required VPN+ services increases, more VTNs needs to 470 be created, then the control plane scalability could be improved by 471 decoupling the topology attribute from other attributes (e.g. 472 resource attribute) of VTN, so that multiple VTNs could share the 473 same topology or resource attribute. 475 To further improve the data plane scalability, dedicated data plane 476 identifiers of VTN can be introduced to decouple the topology- 477 specific forwarding and the VTN resource-based processing in data 478 plane. 480 6. Security Considerations 482 TBD 484 7. IANA Considerations 486 This document makes no request of IANA. 488 8. Contributors 490 Zhibo Hu 491 Email: huzhibo@huawei.com 493 9. Acknowledgments 495 The authors would like to thank XXX for the review and discussion of 496 this document. 498 10. References 500 10.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 10.2. Informative References 513 [I-D.dong-spring-sr-for-enhanced-vpn] 514 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 515 Z., and F. Clad, "Segment Routing based Virtual Transport 516 Network for Enhanced VPN", draft-dong-spring-sr-for- 517 enhanced-vpn-10 (work in progress), August 2020. 519 [I-D.ietf-lsr-flex-algo] 520 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 521 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 522 algo-13 (work in progress), October 2020. 524 [I-D.ietf-spring-resource-aware-segments] 525 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 526 Z., and F. Clad, "Introducing Resource Awareness to SR 527 Segments", draft-ietf-spring-resource-aware-segments-00 528 (work in progress), July 2020. 530 [I-D.ietf-teas-enhanced-vpn] 531 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 532 Framework for Enhanced Virtual Private Networks (VPN+) 533 Service", draft-ietf-teas-enhanced-vpn-06 (work in 534 progress), July 2020. 536 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 537 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 538 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 539 . 541 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 542 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 543 RFC 4915, DOI 10.17487/RFC4915, June 2007, 544 . 546 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 547 Topology (MT) Routing in Intermediate System to 548 Intermediate Systems (IS-ISs)", RFC 5120, 549 DOI 10.17487/RFC5120, February 2008, 550 . 552 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 553 (IPv6) Specification", STD 86, RFC 8200, 554 DOI 10.17487/RFC8200, July 2017, 555 . 557 [TS23501] "3GPP TS23.501", 2016, 558 . 561 Authors' Addresses 563 Jie Dong 564 Huawei Technologies 565 Huawei Campus, No. 156 Beiqing Road 566 Beijing 100095 567 China 569 Email: jie.dong@huawei.com 570 Zhenbin Li 571 Huawei Technologies 572 Huawei Campus, No. 156 Beiqing Road 573 Beijing 100095 574 China 576 Email: lizhenbin@huawei.com 578 Fengwei Qin 579 China Mobile 580 No. 32 Xuanwumenxi Ave., Xicheng District 581 Beijing 582 China 584 Email: qinfengwei@chinamobile.com 586 Guangming Yang 587 China Telecom 588 No.109 West Zhongshan Ave., Tianhe District 589 Guangzhou 590 China 592 Email: yangguangm@chinatelecom.cn