idnits 2.17.1 draft-wang-pce-vlan-based-traffic-forwarding-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 33 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2022) is 785 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-pce-pcep-extension-for-pce-controller' is defined on line 946, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-pce-pcep-extension-native-ip-17 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 8283 ** Downref: Normative reference to an Informational RFC: RFC 8735 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Wang 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: September 4, 2022 F. Qin 6 China Mobile 7 H. Chen 8 Futurewei 9 C. Zhu 10 ZTE Corporation 11 March 3, 2022 13 PCEP Procedures and Extension for VLAN-based Traffic Forwarding 14 draft-wang-pce-vlan-based-traffic-forwarding-05 16 Abstract 18 This document defines the Path Computation Element Communication 19 Protocol (PCEP) extension for VLAN-based traffic forwarding in native 20 IP network and describes the essential elements and key processes of 21 the data packet forwarding system based on VLAN info to accomplish 22 the End to End (E2E) traffic assurance for VLAN-based traffic 23 forwarding in native IP network. 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 https://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 September 4, 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 (https://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 used in this document . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Procedures for VLAN-based Traffic Forwarding . . . . . . . . 4 63 5. Capability Advertisement . . . . . . . . . . . . . . . . . . 5 64 6. PCEP message . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 6 66 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 7 67 7. VSP Operations . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. VXLAN-based traffic forwarding Procedures . . . . . . . . . . 12 69 8.1. Multiple BGP Session Establishment Procedures . . . . . . 12 70 8.2. BGP Prefix Advertisement Procedures . . . . . . . . . . . 13 71 8.3. VLAN mapping info Advertisement Procedures . . . . . . . 13 72 8.3.1. VLAN-Based forwarding info Advertisement Procedures . 13 73 8.3.2. VLAN-Based crossing info Advertisement Procedures . . 15 74 9. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. VLAN forwarding CCI Object . . . . . . . . . . . . . . . 17 76 9.2. Address TLVs . . . . . . . . . . . . . . . . . . . . . . 19 77 9.3. VLAN crossing CCI Object . . . . . . . . . . . . . . . . 19 78 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 20 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 12.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 20 82 12.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 21 83 12.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 21 84 12.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 21 85 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 86 14. Normative References . . . . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 [RFC8283] introduces the architecture for the PCE as a central 92 controller as an extension to the architecture described in 93 [RFC4655]. Based on such mechanism, the PCE can calculate the 94 optimal path for various applications and send the instructions to 95 the network equipment via PCEP protocol, thus control the packet 96 forwarding and achive the QoS assurance effects for priority traffic. 97 . 99 [RFC8735] describes the scenarios of QoS assurance for hybrid cloud- 100 based application within one domain and traffic engineering in multi- 101 domain. It proposes also the consideration for the potential 102 solution, that is: 104 1. Should be applied both in native IPv4 and IPv6 environment. 106 2. Should be same procedures for the intra-domain and inter-domain 107 scenario. 109 3. Should utilize the existing forwarding capabilities of the 110 deployed network devices. 112 With the large scale deployment of Ethernet interfaces in operator 113 network and PCECC architecture, it is possible to utilize the VLAN 114 information within the Ethernet header to build one end-to-end 115 dedicated path to guide the forwarding of the packet. Similar with 116 the PCECC for LSP [RFC9050], this document defines a Path Computation 117 Element Communication Protocol (PCEP) Extension for VLAN-based 118 traffic forwarding by using the VLAN info contained in the Ethernet 119 frame in native IP network and the mechanism is actually the PCECC 120 for VSP(VLAN Switching Path). It is an end to end traffic guarantee 121 mechanism based on the PCEP protocol in the native IP environment, 122 which can ensure the connection-oriented network communication. It 123 can simplify the calculation and forwarding process of the optimal 124 path by blending it with elements of PCEP and without necessarily 125 completely replacing it. The overall QoS assurance effect is 126 achieved via the central controller by calculating and deploying the 127 optimal VSP to bypass the congested nodes and links, thus avoids the 128 resource reservation on each nodes in advance. 130 Compared with other traffic assurance technologies such as MPLS or 131 srv6 which is supported only in IPv6 environment, and has the obvious 132 packet overhead problems, the VLAN-based traffic forwarding (VTF) 133 mechanism uses a completely new address space which will not conflict 134 with other existing protocols and can easily avoid these problems and 135 be deployed in IPv4 and IPv6 environment simultaneously. It is 136 suitable for ipv4 and ipv6 networks and can leverage the existing PCE 137 technologies as much as possible. 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119] . 145 3. Terminology 147 The following terms are defined in this draft: 149 o PCC: Path Computation Client 151 o PCE: Path Computation Element 153 o PCEP: PCE Communication Protocol 155 o PCECC: PCE-based Central Controller 157 o LSP: Lable Switching Path 159 o PST: Path Setup Type 161 4. Procedures for VLAN-based Traffic Forwarding 163 The target deployment environment of VLAN based traffic forwarding 164 mechanism is for Native IP(IPv4 and IPv6). In such scenarios, the 165 BGP is used for the prefix distribution among underlying 166 devices(PCCs), no MPLS is involved. 168 In order to set up the VLAN-based traffic forwarding paths for 169 different applications in native IP network, multiple BGP sessions 170 should be deployed between the ingress PCC and egress PCC at the edge 171 of the network respectively. 173 Based on the business requirements, the PCE calculates the explicit 174 route and sends the route information to the PCCs through PCInitiate 175 messages. When received the PCInitiate message, the ingress PCC will 176 form a VLAN-Forwarding routing table defined in this document. The 177 packet to be guaranteed will be matched in the table and then be 178 labeled with corresponding VLAN tag. The labeled packet will be 179 further sent to the PCC's specific subinterface identified by the 180 VLAN tag and then be forwarded. Similarly, the transit PCC and the 181 egress PCC will form a VLAN-Crossing routing table after received the 182 PCInitiate message. The packet to be guaranteed will be relabled 183 with new VLAN tag and then be forwarded. For PCC, there is no 184 corresponding VLAN allocation mechanism at present which is different 185 with the label in MPLS, so the mechanism of allocating and managing 186 VLAN ID by PCC will not be considered in this draft as per [RFC9050]. 188 The whole procedures mainly focus on the end-to-end traffic for key 189 application which can ensure the adequacy of VLAN number for this 190 scenario. During the whole packet forwarding process, the packet can 191 be encapsulated with reserved multicast MAC addresses(e.g. 193 0180:C200:0014 for ISIS levle1, 0180:C200:0015 for ISIS levle2) and 194 don't need to change hop by hop so as to accept by each PCC. 196 5. Capability Advertisement 198 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 199 advertise their support of VLAN-based trafficforwarding extensions. 200 This document defines a new Path Setup Type (PST)[RFC8408] for PCECC, 201 as follows: 203 o PST=TBD1: Path is a VLAN-based traffic forwarding type. 205 A PCEP speaker MUST indicate its support of the function described in 206 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 207 object with this new PST included in the PST list. 209 Because the path is set up through PCE, a PCEP speaker must advertise 210 the PCECC capability by using PCECC-CAPABILITY sub-TLV which is used 211 to exchange information about their PCECC capability as per PCEP 212 extensions defined in [RFC9050] 214 A new flag is defined in PCECC-CAPABILITY sub-TLV for VLAN-based 215 traffic forwarding. 217 V (VLAN-based-forwarding-CAPABILITY - 1 bit - TBD2): If set to 1 by a 218 PCEP speaker, it indicates that the PCEP speaker supports the 219 capability of VLAN based traffic forwarding as specified in this 220 document. The flag MUST be set by both the PCC and PCE in order to 221 support this extension. 223 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 224 the newly defined path setup type, but without the V bit set in 225 PCECC-CAPABILITY sub-TLV, it MUST: 227 o Send a PCErr message with Error-Type=10(Reception of an invalid 228 object) and Error-Value TBD3(PCECC VLAN-based-forwarding- 229 CAPABILITY bit is not set). 231 o Terminate the PCEP session 233 6. PCEP message 235 As per [RFC8281] ,the PCInitiate message sent by a PCE was defined to 236 trigger LSP instantiation or deletion with the SRP and LSP object 237 included during the PCEP initialization phase. The Path Computation 238 LSP State Report message (PCRpt message) was defined in [RFC8231], 239 which is used to report the current state of a LSP. A PCC can send a 240 LSP State Report message in response to a LSP instantiation. 242 Besides, the message can either in response to a LSP Update Request 243 from a PCE or asynchronously when the state of a LSP changes . 245 [RFC9050] defines an object called Central Controller Instructions 246 (CCI) to specify the forwarding instructions to the PCC. During the 247 coding process used for central controller instructions, the object 248 contains the label information and is carried within PCInitiate or 249 PCRpt message for label download . 251 This document specify two new CCI object-types for VLAN-based traffic 252 forwarding in the native IP network and are said to be mandatory in a 253 PCEP message when the object must be included for the message to be 254 considered valid. In addition, this document extends the PCEP 255 message to handle the VLAN-based traffic forwarding path in the 256 native IP network with the new CCI object. 258 6.1. The PCInitiate message 260 The PCInitiate message[RFC8281] extended in[RFC9050] can be used to 261 download or remove labels by using the CCI Object. 263 Based on the extended PCInitiate message and PCRpt described in 264 [I-D.ietf-pce-pcep-extension-native-ip], the (BGP Peer Info (BPI) 265 Object and the Peer Prefix Association (PPA) Object is used to 266 establish multi BGP sessions and advertise route prefixes among 267 different BGP sessions before setting up a VLAN-based traffic 268 forwarding path. 270 This document extends the PCInitiate message as shown below: 272 ::= 273 274 Where: 275 is defined in [RFC5440] 277 ::= 278 [] 280 ::= 281 (| 282 | 283 ) 285 ::= 286 287 | 288 ((|) 289 ) 291 ::= 292 [] 294 Where: 295 is as per 296 [RFC9050]. 297 and 298 are as per [RFC8281]. 299 and are as per 300 [draft-ietf-pce-pcep-extension-native-ip-09] 302 When PCInitiate message is used to create VLAN-based forwarding 303 instructions, the SRP, LSP and CCI objects MUST be present. The 304 error handling for missing SRP, LSP or CCI object is as per 305 [RFC9050]. Further only one of BPI, PPA or one type of CCI objects 306 MUST be present. If none of them are present, the receiving PCE MUST 307 send a PCErr message with Error- type=6 (Mandatory Object missing) 308 and Error-value=TBD4 ( VLAN-based forwarding object missing). If 309 there are more than one of BPI, PPA or one type of CCI objects are 310 presented, the receiving PCC MUST send a PCErr message with Error- 311 type=19(Invalid Operation) and Error- value=TBD5(Only one of BPI, PPA 312 or one type of the CCI objects for VLAN can be included in this 313 message). 315 6.2. The PCRpt message 317 The PCRpt message is used to report the state and confirm the VLAN 318 info that were allocated by the PCE, to be used during the state 319 synchronization phase or as acknowledgement to PCInitiate message. 321 The format of the PCRpt message is as follows: 323 ::= 324 325 Where: 327 ::= [] 329 ::= (| 330 ) 332 ::= [] 333 334 336 ::= [] 337 338 | 339 ((|) 340 () 342 Where: 343 is as per [RFC8231] and the LSP and SRP object are 344 also defined in [RFC8231]. 345 and are as per 346 [draft-ietf-pce-pcep-extension-native-ip-09] 348 The error handling for missing LSP or CCI object is as per [RFC9050]. 349 Further only one of BPI, PPA or one type of CCI objects MUST be 350 present. If none of them are present, the receiving PCE MUST send a 351 PCErr message with Error- type=6 (Mandatory Object missing) and 352 Error-value=TBD4 ( VLAN-based forwarding object missing). If there 353 are more than one of BPI, PPA or one type of CCI objects are 354 presented, the receiving PCC MUST send a PCErr message with Error- 355 type=19(Invalid Operation) and Error- value=TBD5(Only one of BPI, PPA 356 or one type of the CCI objects for VLAN can be included in this 357 message). 359 7. VSP Operations 361 Based on [RFC8281] and [RFC9050], in order to set up a PCE-initiated 362 VSP based on the PCECC mechanism, a PCE needs to send a PCInitiate 363 message with the PST set to TBD1 in SRP for the PCECC to the ingress 364 PCC. 366 The VLAN-forwarding instructions from the PCECC needs to be sent 367 after the initial PCInitiate and PCRpt message exchange with the 368 ingress PCC. On receipt of a PCInitiate message for the PCECC VSP, 369 the PCC responds with a PCRpt message with the status set to 'Going- 370 up', carrying the assigned PLSP-ID and set the D(Delegate) flag and 371 C(Create) flag(see Figure 1). 373 After that, the PCE needs to send a PCInitiate message to each node 374 along the path to download the VLAN instructions. The new CCI for 375 the VLAN operations in PCEP are done via the PCInitiate message by 376 defining a new PCEP object for CCI operations. The LSP and the LSP- 377 IDENTIFIERS TLV are described for the RSVP-signaled LSPs but are 378 applicable to the PCECC VSP as well. So the LSP is included in the 379 PCInitiate message can still be used to identify the PCECC VSP for 380 this instruction and the process is the same. 382 When the PCE receives this PCRpt message with the PLSP-ID, it assigns 383 VLAN along the path and sets up the path by sending a PCInitiate 384 message to each node along the path of the VSP, as per the PCECC 385 technique. The ingress PCC would receive one VLAN forwarding CCI 386 Object which contains VLAN on the logical subinterface and the Peer 387 IP address. The transit PCC would receive two VLAN crossing CCI 388 Objects with the O bit set for the out-VLAN on the egress 389 subinterface and the O bit unset for the in-VLAN on the ingress 390 subinterface. Similar with the transit PCC, the egress PCC would 391 receive two VLAN crossing CCI Objects but the out-VLAN on the egress 392 subinterface is set to 0. Once the VLAN operations are completed, 393 the PCE MUST send a PCUpd message to the ingress PCC. 395 +-------+ +-------+ 396 |PCC | | PCE | 397 |ingress| +-------+ 398 +------| | | 399 | PCC +-------+ | 400 | transit| | | 401 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1------| PCECC VSP 402 |PCC +--------+ |----PCRpt,PLSP-ID=2,D=1,C=1---------->| Initiate 403 |egress | | | (GOING-UP) | PCECC VSP 404 +--------+ | | | 405 | | | | 406 |<-------PCInitiate,VLAN-CROSSING-CC-ID=X1,X2--------| VLAN 407 | | PLSP-ID=2,IN-VLAN=N1,OUT-VLAN=0 | download 408 | | | | CCI 409 |--------PCRpt,VLAN-CROSSING-CC-ID=X1,X2------------>| 410 | |PLSP-ID=2,IN-VLAN=N1,OUT-VLAN=0 | 411 | | | | 412 | |<---PCInitiate,VLAN-CROSSING-CC-ID=Y1,Y2--->| VLAN 413 | | |PLSP-ID=2,IN-VLAN=N2,OUT-VLAN=N1 | download 414 | | | | CCI 415 | |-------PCRpt,VLAN-CROSSING-CC-ID=Y1,Y2----->| 416 | | |PLSP-ID=2,IN-VLAN=N2,OUT-VLAN=N1 | 417 | | | | 418 | | |<--PCInitiate,VLAN-FORWARDING-CC-ID=Z-| VLAN 419 | | | PLSP-ID=2,VLAN=N2 | download 420 | | | | CCI 421 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| 422 | | | PLSP-ID=2,VLAN=N2 | 423 | | | | 424 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC VSP 425 | | | (UP) | Update 426 | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| 427 | | | (UP) | 428 Figure 1: PCE-Initiated PCECC VSP 430 In order to delete an LSP based on the PCECC, the PCE sends CCI and 431 SRP object with the R bit set to 1 via a PCInitiate message to each 432 node along the path of the VSP to clean up the label-forwarding 433 instruction. 435 As per [RFC9050], the PCECC VSP also follows the same make-before- 436 break principles. As shown in the figure 2, new path for VSP 437 triggers the new CCI Distribution process. The PCECC first updates 438 the new VLAN instructions and informs each node along the new path 439 through the new VLAN crossing CCI Objects and VLAN forwarding CCI 440 Objects to download the new VSP. The PCUpd message then triggers the 441 traffic switch on the updated path. On receipt of the PCRpt message 442 corresponding to the PCUpd message, the PCE does the cleanup 443 operation for the former VSP,which is the same as the LSP update 444 process. 446 +-------+ +-------+ 447 |PCC | | PCE | 448 |ingress| +-------+ 449 +------| | | 450 | PCC +-------+ | 451 | transit| | | 452 +------| | | | 453 |PCC +--------+ | | 454 |egress | | | | 455 +--------+ | | | 456 | | | | 457 |<----- PCInitiate,VLAN-CROSSING-CC-ID=NEW-X1,X2----| New Path 458 | | PLSP-ID=1,IN-VLAN=NEW-N1,OUT-VLAN=0 | for VSP 459 | | | | triggers 460 |--------PCRpt,VLAN-CROSSING-CC-ID=NEW-X1,X2------->| new CCI 461 | | PLSP-ID=1,IN-VLAN=NEW-N1,OUT-VLAN=0 | 462 | | | | 463 | |<----------PCInitiate,PLSP-ID=1------------| 464 | | |VLAN-CROSSING-CC-ID=NEW-Y1,NEW-Y2 | Label 465 | | | IN-VLAN=NEW-N2,OUT-VLAN=NEW-N1 | download 466 | | | | CCI 467 | |--------------PCRpt,PLSP-ID=1------------->| 468 | | |VLAN-CROSSING-CC-ID=NEW-Y1,NEW-Y2 | 469 | | | IN-VLAN=NEW-N2,OUT-VLAN=NEW-N1 | 470 | | | | 471 | | |<--------PCInitiate,PLSP-ID=1--------| Label 472 | | | VLAN-FORWARDING-CC-ID=NEW-Z | download 473 | | | VLAN=NEW-N2 | CCI 474 | | | | 475 | | |----------PCRpt,PLSP-ID=1----------->| 476 | | | LAN-FORWARDING-CC-ID=NEW-Z | 477 | | | VLAN=NEW-N2 | 478 | | | | 479 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC 480 | | | (SRP=S) | VSP Update 481 | | | | 482 | | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| Trigger 483 | | | (SRP=S) | Delete 484 | | | | former CCI 485 | | | | 486 |<--------------PCInitiate, PLSP-ID=1---------------| Label 487 | | |VLAN-CROSSING-CC-ID=X1,X2,R=1 | cleanup 488 |----------------PCRpt,PLSP-ID=1------------------->| CCI 489 | | |VLAN-CROSSING-CC-ID=X1,X2,R=1 | 490 | | | | 491 | |<------------PCInitiate,PLSP-ID=1----------| Label 492 | | |VLAN-CROSSING-CC-ID=Y1,Y2,R=1 | cleanup 493 | |---------------PCRpt,PLSP-ID=1------------>| CCI 494 | | |VLAN-CROSSING-CC-ID=Y1,Y2,R=1 | 495 | | | | 496 | | |<--------PCInitiate,PLSP-ID=1--------| Label 497 | | |VLAN-FORWARDING-CC-ID=Z,R=1 | cleanup 498 | | |---------PCRpt,PLSP-ID=1------------>| CCI 499 | | |VLAN-FORWARDING-CC-ID=Z,R=1 | 501 Figure 2: PCECC VSP Update 503 8. VXLAN-based traffic forwarding Procedures 505 8.1. Multiple BGP Session Establishment Procedures 507 As described in section 4, multiple BGP sessions should be deployed 508 between the ingress device and egress device at the edge of the 509 network respectively in order to carry information of different 510 applications. As per [I-D.ietf-pce-pcep-extension-native-ip], the 511 PCE should send the BPI((BGP Peer Info) Object to the ingress and 512 egress device with the indicated Peer AS and Local/Peer IP address. 513 The Ingress and egress devices will receive multiple BPI objects to 514 establish sessions with different next hop. The specific process is 515 as follows: 517 +----------------------+ 518 +---------+- PCE + --------+ 519 | +----------^-----------+ | 520 | | | | | 521 | +--+ +--+ +--+ | 522 |------- +R2+ ------+R3+-------+R4+ -------- 523 | +--+ +--+ +--+ | 524 | | 525 +--+ +--+ +--+ 526 +R1+----------------+R5+----------------+R6+ 527 +--+ +--+ +--+ 528 | | 529 |<------------- BGP Session A ------------>| 530 |<------------- BGP Session B ------------>| 531 |<------------- BGP Session C ------------>| 533 Figure 3: BGP Session Establishment Procedures 535 8.2. BGP Prefix Advertisement Procedures 537 The detail procedures for BGP prefix advertisement procedures is 538 introduced in [I-D.ietf-pce-pcep-extension-native-ip], using 539 PCInitiate and PCRpt message pair. 541 The BGP prefix for different BGP sessions should be sent to the 542 ingress and egress device respectively. The end-to-end traffic for 543 key application can be identified based on these BGP prefix 544 informations and be further assured. As per 545 [I-D.ietf-pce-pcep-extension-native-ip], the PPA(Peer Prefix 546 Association) object with list of prefix subobjects and the peer 547 address will be sent through the PCInitiate and PCRpt message pair. 548 Through BGP protocol, the ingress device can learn different BGP 549 prefix of the egress device based on the different BGP sessions. 551 8.3. VLAN mapping info Advertisement Procedures 553 After the BGP prefix for different BGP session are successfully 554 advertised, information of different applications should be forwarded 555 to different VLAN-based traffic forwarding paths. In order to set up 556 a VLAN-based traffic forwarding path, the PCE should send the VLAN 557 forwarding CCI Object with the VLAN-ID included to the ingress PCC 558 and the VLAN crossing CCI Object to the transit PCC and egress PCC. 560 8.3.1. VLAN-Based forwarding info Advertisement Procedures 562 The detail procedures for VLAN-Based forwarding info advertisement 563 contained in the VLAN forwarding CCI Object is shown below, using 564 PCInitiate and PCRpt message pair. 566 The VLAN forwarding CCI Object should be sent through the PCInitiate 567 and PCRpt message pair. After the PCC receives the CCI object (with 568 the R bit set to 0 in SRP object) in PCInitiate message, the PCC will 569 form a VLAN-Forwarding routing table and the PCC's subinterface will 570 set up the specific VLAN based on the VLAN forwarding CCI object, 571 source and destination BGP prefix learnt before. When the ingress 572 PCC receives a packet, it will look up the VLAN-Forwarding routing 573 table based on the source and destination IP contained in the packet. 574 The packet to be guaranteed will be matched in the table and then be 575 labeled with corresponding VLAN tag. After that, The labeled packet 576 will be further forwarded to the specific subinterface. 578 When PCC receives the VLAN forwarding CCI Object with the R bit set 579 to 1 in SRP object in PCInitiate message, the PCC should withdraw the 580 VLAN-Based forwarding info advertisement to the peer that indicated 581 by this object. 583 On receipt of a PCInitiate message for the PCECC VSP, the PCC should 584 report the result via the PCRpt messages, with the corresponding SRP 585 and CCI object included. 587 +----------------------+ 588 +---------+ PCE + --------+ 589 | +----------^-----------+ | 590 | | | | | 591 M1&M1-R | | | | 592 | | | | | 593 | | | | | 594 | +--+ +--+ +--+ | 595 |------- +R2+ ------+R3+-------+R4+ -------- 596 | +--+ +--+ +--+ | 597 | | 598 +--+ +--+ +--+ 599 +R1+----------------+R5+----------------+R6+ 600 +--+ +--+ +--+ 601 Figure 4: VLAN-Based forwarding info Advertisement 602 Procedures for Ingress PCC 604 The message number, message peers, message type and message key 605 parameters in the above figures are shown in below table: 607 Table 1: Message Information 608 +-------------------------------------------------------------+ 609 | No.| Peers| Type | Message Key Parameters | 610 +-------------------------------------------------------------+ 611 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 612 |M1-R| |PCRpt |VLAN Forwarding CCI Object | 613 | | | |(Peer_IP=R6_A,Interface_Address=INF1, | 614 | | | |VLAN_ID=VLAN_R1_R2) | 615 +-------------------------------------------------------------+ 617 VLAN-Forwarding routing table maintained in the ingress PCC is as 618 follows, which is used to match the packet to be guaranteed based on 619 the source and destination BGP prefix. 621 Table 2: VLAN-Forwarding routing table 622 +--------------------------------------------------------+ 623 | Dst IP Address | Interface | VLAN | 624 +--------------------------------------------------------+ 625 | Prefixes from R6 Session1 | INF 1 | VLAN_R1_R2 | 626 | Prefixes from R6 SessionX | INF X | X | 627 | ... | 628 +--------------------------------------------------------+ 630 8.3.2. VLAN-Based crossing info Advertisement Procedures 632 The detail procedures for VLAN-Based crossing info advertisement 633 contained in the VLAN crossing CCI Object is shown below, using 634 PCInitiate and PCRpt message pair. 636 The PCC would receive VLAN crossing CCI Objects with the in-VLAN CCI 637 without the O bit set and the out-VLAN CCI with the O bit set. After 638 the process of VLAN-Based forwarding info advertisement mentioned 639 above, the PCC will form a VLAN-crossing routing table and the PCC's 640 subinterface will set up the specific VLAN based on the VLAN crossing 641 CCI Object(with the R bit set to 0 in SRP object) contained in the 642 PCInitiate message. The VLAN-crossing routing table consists of an 643 in-VLAN tag and an out-VLAN tag which specifies a new VLAN forwarding 644 path. When the transit PCC receives a data packet that has been 645 labeled with VLAN by ingress PCC before, it will look up the VLAN- 646 Crossing routing table based on the VLAN tag. If matched, the in- 647 VLAN tag of this data packet will be replaced by a new out-VLAN tag 648 of the current transit PCC according to the table. The packet with 649 the new VLAN tag will be further forwarded to the next hop. 651 For the egress PCC, the out-VLAN tag in the VLAN-crossing routing 652 table should be 0 which indicates it is the last hop of the 653 transmission. So the egress PCC will directly remove the in-VLAN tag 654 of the packet and the packet will be forwarded. 656 When PCC receives the VLAN crossing CCI Object with the R bit set to 657 1 in SRP object in PCInitiate message, the PCC should withdraw the 658 VLAN-Based crossing info advertisement to the peer that indicated by 659 this object. 661 On receipt of a PCInitiate message for the PCECC VSP, the PCC should 662 report the result via the PCRpt messages, with the corresponding SRP 663 and CCI object included. 665 When the out-VLAN tag conflicts with a pre-defined VLAN tag or the 666 PCC can not set up a VLAN forwarding path with the out-VLAN tag, an 667 error (Error-type=TBD6, VLAN-based forwarding failure, Error- 668 value=TBD7, VLAN crossing CCI Object peer info mismatch) should be 669 reported via the PCRpt message. 671 +----------------------+ 672 +---------+ PCE + --------+ 673 | +----------^-----------+ | 674 | | | | | 675 | M1&M1-R M2&M2-R M3&M3-R M4&M4-R 676 | | | | | 677 | +--+ +--+ +--+ | 678 |------- +R2+ ------+R3+-------+R4+ -------| 679 | +--+ +--+ +--+ | 680 | | 681 +--+ +--+ +--+ 682 +R1+----------------+R5+----------------+R6+ 683 +--+ +--+ +--+ 684 Figure 5: VLAN-Based crossing info Advertisement Procedures 685 for transit PCC and egress PCC 687 The message number, message peers, message type and message key 688 parameters in the above figures are shown in below table: 690 Table 3: Message Information 691 +--------------------------------------------------------------------------+ 692 | No.| Peers| Type | Message Key Parameters | 693 +--------------------------------------------------------------------------+ 694 |M1 |PCE/R2|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 695 |M1-R| |PCRpt |VLAN crossing CCI Object(IN) | 696 | | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R1_R2) | 697 | | | |VLAN crossing CCI Object(OUT) | 698 | | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R2_R3)| 699 +--------------------------------------------------------------------------+ 700 |M2 |PCE/R3|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 701 |M2-R| |PCRpt |VLAN crossing CCI Object(IN) | 702 | | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R2_R3) | 703 | | | |VLAN crossing CCI Object(OUT) | 704 | | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R3_R4)| 705 +--------------------------------------------------------------------------+ 706 |M3 |PCE/R4|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 707 |M3-R| |PCRpt |VLAN crossing CCI Object(IN) | 708 | | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R3_R4) | 709 | | | |VLAN crossing CCI Object(OUT) | 710 | | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R4_R6)| 711 +--------------------------------------------------------------------------+ 712 |M4 |PCE/R6|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 713 |M4-R| |PCRpt |VLAN crossing CCI Object(IN) | 714 | | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R4_R6) | 715 | | | |VLAN crossing CCI Object(OUT) | 716 | | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=0) | 717 +--------------------------------------------------------------------------+ 718 VLAN-Crossing routing table maintained in the transit PCC and egress 719 PCC is as follows. Through the mapping of the in-VLAN and the out 720 VLAN, the data packet to be guaranteed will be transferred to the 721 specific interface and be switched on the out VLAN for the transit 722 PCC or 0 for the egress PCC. 724 Table 4: VLAN-Crossing routing table 725 +----------------------------------------------------------------------+ 726 | IN-Interface | IN-VLAN | OUT-Interface | OUT-VLAN | 727 +----------------------------------------------------------------------+ 728 | INF1 | VLAN_R1_R2 | INF2 | VLAN_R2_R3 | 729 | INF3 | X | INF4 | Y | 730 | INF5 | Z | INF6 | 0 | 731 | ... | 732 +----------------------------------------------------------------------+ 734 9. New PCEP Objects 736 The Central Control Instructions (CCI) Object is used by the PCE to 737 specify the forwarding instructions is defined in [RFC9050]. This 738 document defines another two CCI object-types for VLAN-based traffic 739 forwarding network. All new PCEP objects are compliant with the PCEP 740 object format defined in [RFC5440]. 742 9.1. VLAN forwarding CCI Object 744 The VLAN forwarding CCI Object is used to set up the specific VLAN 745 forwarding path of the logical subinterface that the traffic will be 746 forwarded to and transfer the packet to the specific hop. Combined 747 with this type of CCI Object and the Peer Prefix Association 748 object(PPA) defined in [I-D.ietf-pce-pcep-extension-native-ip], the 749 ingress PCC will form a VLAN-Forwarding routing table which is used 750 to identify the traffic that needs to be protected. This object 751 should only be included and sent to the ingress PCC of the end2end 752 path. 754 CCI Object-Class is 44. 756 CCI Object-Type is TBD8 for VLAN forwarding info in the native IP 757 network. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | CC-ID | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Reserved1 | Flags | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | VLAN-ID | Reserved2 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | 769 // Interface Address TLV // 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 // Peer IP Address TLV // 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 // Additional TLVs // 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Figure 6: VLAN Forwarding CCI Object 783 The fields in the CCI object are as follows: 785 CC-ID: is as described in [RFC9050]. Following fields are defined 786 for CCI Object-Type TBD8. 788 Reserved1(16 bits): is set to zero while sending, ignored on receipt. 790 Flags(16 bits): is used to carry any additional information 791 pertaining to the CCI. Currently no flag bits are defined. 793 VLAN ID(12 bits):the ID of the VLAN forwarding path that the PCC will 794 set up on its logical subinterface in order to transfer the packet to 795 the specific hop. 797 Reserved2(20 bits): is set to zero while sending, ignored on receipt. 799 Interface Address TLV [RFC8779] MUST be included in this CCI Object- 800 Type TBD8 to specify the interface which will set up the vlan defined 801 in the VLAN Forwarding CCI Object. 803 The Peer IP Address TLV[RFC8779]MUST be included in this CCI Object- 804 Type TBD8 to identify the end to end TE path in VLAN-based traffic 805 forwarding network and MUST be unique. 807 9.2. Address TLVs 809 [RFC8779] defines IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT 810 TLVs for the use of Generalized Endpoint. The same TLVs can also be 811 used in the CCI object to find the Peer address that matches egress 812 PCC and further identify the packet to be guaranteed. If the PCC is 813 not able to resolve the peer information or can not find the 814 corresponding ingress device, it MUST reject the CCI and respond with 815 a PCErr message with Error-Type = TBD6 ("VLAN-based forwarding 816 failure") and Error Value = TBD9 ("Invalid egress PCC information"). 818 9.3. VLAN crossing CCI Object 820 The VLAN crossing CCI object is defined to control the transmission- 821 path of the packet by VLAN-ID. This new type of CCI Object can be 822 carried within a PCInitiate message sent by the PCE to the transit 823 PCC and the egress PCC in the VLAN-based traffic forwarding 824 scenarios. 826 CCI Object-Class is 44. 828 CCI Object-Type is TBD10 for VLAN crossing info in the native IP 829 network. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | CC-ID | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Reserved1 | Flags |O| 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | VLAN-ID(in/out) | Reserved2 | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | | 841 // Interface Address TLV // 842 | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | | 845 // Additional TLVs // 846 | | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Figure 7: VLAN Crossing CCI Object 851 CC-ID: is as described in [RFC9050]. Following fields are defined 852 for CCI Object-Type TBD10. 854 Reserved1(16 bits): is set to zero while sending, ignored on receipt. 856 Flags(16 bits): is used to carry any additional information 857 pertaining to the CCI. Currently, the following flag bit are 858 defined: 860 * O bit (out-label) : If the bit is set to '1', it specifies the VLAN 861 is the out-VLAN, and it is mandatory to encode the egress interface 862 information(via Interface Address TLVs in the CCI object). If the 863 bit is not set or set to '0', it specifies the VLAN is the in-VLAN, 864 and it is mandatory to encode the ingress interface information. 866 VLAN ID(12 bits): The ID of the VLAN switching path. When the O bit 867 is set to 0, the VLAN is the in-VLAN and the ID indicates a VLAN 868 forwarding path which is used to identify the traffic that needs to 869 be protected. When the O bit is set to 1, the VLAN is the out-VLAN 870 and it indicates the ID of the VLAN forwarding path that the PCC will 871 set up on its logical subinterface in order to transfer the packet 872 labled with this VLAN ID to the specific hop. To the transit PCC, 873 the value must not be 0 to indicate it is not the last hop of the 874 VLAN-based traffic forwarding path. To the egress PCC, the value 875 must be 0 to indicate it is the last hop of the VLAN-based traffic 876 forwarding path. 878 Reserved2(8 bits): is set to zero while sending, ignored on receipt. 880 Interface Address TLV [RFC8779] MUST be included in this CCI Object- 881 Type TBD8 to specify the interface which will set up the vlan defined 882 in the VLAN Forwarding CCI Object. 884 10. Deployment Considerations 886 11. Security Considerations 888 12. IANA Considerations 890 12.1. Path Setup Type Registry 892 [RFC8408] created a sub-registry within the "Path Computation Element 893 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 894 IANA is requested to allocate a new code point within this registry, 895 as follows: 897 Value Description Reference 898 TBD1 VLAN-Based Traffic Forwarding Path This document 900 12.2. PCECC-CAPABILITY sub-TLV's Flag field 902 [RFC9050] created a sub- registry within the "Path Computation 903 Element Protocol (PCEP) Numbers" registry to manage the value of the 904 PCECC-CAPABILITY sub- TLV's 32-bits Flag field. IANA is requested to 905 allocate a new bit position within this registry, as follows: 907 Value Description Reference 908 TBD2(V) VLAN-Based Forwarding CAPABILITY This document 910 12.3. PCEP Object Types 912 IANA is requested to allocate new registry for the PCEP Object Type: 914 Object-Class Value Name Reference 915 44 CCI Object-Type This document 916 TBD8: VLAN forwarding CCI 917 TBD10: VLAN crossing CCI 919 12.4. PCEP-Error Object 921 IANA is requested to allocate new error types and error values within 922 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 923 PCEP Numbers registry for the following errors: 925 Error-Type Meaning Error-value Reference 926 6 Mandatory Object missing TBD4:VLAN-based This document 927 forwarding object 928 missing 929 10 Reception of an TBD3:PCECC This document 930 invalid object VLAN-based-forwarding 931 -CAPABILITY 932 bit is not set 933 19 Invalid Operation TBD5: Only one of BPI, This document 934 PPA or one type of 935 the CCI objects 936 for VLAN can be included 937 in this message 938 TBD6 VLAN-based forwarding TBD7: VLAN crossing CCI This document 939 failure Object peer info mismatch 940 TBD9: Invalid egress This document 941 PCC information 943 13. Acknowledgement 944 14. Normative References 946 [I-D.ietf-pce-pcep-extension-for-pce-controller] 947 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 948 "Path Computation Element Communication Protocol (PCEP) 949 Procedures and Extensions for Using the PCE as a Central 950 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 951 extension-for-pce-controller-14 (work in progress), March 952 2021. 954 [I-D.ietf-pce-pcep-extension-native-ip] 955 Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu, 956 "PCEP Extension for Native IP Network", draft-ietf-pce- 957 pcep-extension-native-ip-17 (work in progress), February 958 2022. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, 962 DOI 10.17487/RFC2119, March 1997, 963 . 965 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 966 Element (PCE)-Based Architecture", RFC 4655, 967 DOI 10.17487/RFC4655, August 2006, 968 . 970 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 971 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 972 DOI 10.17487/RFC5440, March 2009, 973 . 975 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 976 Computation Element Communication Protocol (PCEP) 977 Extensions for Stateful PCE", RFC 8231, 978 DOI 10.17487/RFC8231, September 2017, 979 . 981 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 982 Computation Element Communication Protocol (PCEP) 983 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 984 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 985 . 987 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 988 Architecture for Use of PCE and the PCE Communication 989 Protocol (PCEP) in a Network with Central Control", 990 RFC 8283, DOI 10.17487/RFC8283, December 2017, 991 . 993 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 994 Hardwick, "Conveying Path Setup Type in PCE Communication 995 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 996 July 2018, . 998 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 999 "Scenarios and Simulation Results of PCE in a Native IP 1000 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1001 . 1003 [RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. 1004 Zhang, Ed., "Path Computation Element Communication 1005 Protocol (PCEP) Extensions for GMPLS", RFC 8779, 1006 DOI 10.17487/RFC8779, July 2020, 1007 . 1009 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 1010 Computation Element Communication Protocol (PCEP) 1011 Procedures and Extensions for Using the PCE as a Central 1012 Controller (PCECC) of LSPs", RFC 9050, 1013 DOI 10.17487/RFC9050, July 2021, 1014 . 1016 Authors' Addresses 1018 Yue Wang 1019 China Telecom 1020 Beiqijia Town, Changping District 1021 Beijing, Beijing 102209 1022 China 1024 Email: wangy73@chinatelecom.cn 1026 Aijun Wang 1027 China Telecom 1028 Beiqijia Town, Changping District 1029 Beijing, Beijing 102209 1030 China 1032 Email: wangaj3@chinatelecom.cn 1033 Fengwei Qin 1034 China Mobile 1035 32 Xuanwumenxi Ave. 1036 Beijing 100032 1037 China 1039 Email: qinfengwei@chinamobile.com 1041 Huaimo Chen 1042 Futurewei 1043 Boston 1044 USA 1046 Email: Huaimo.chen@futurewei.com 1048 Chun Zhu 1049 ZTE Corporation 1050 50 Software Avenue, Yuhua District 1051 Nanjing, Jiangsu 210012 1052 China 1054 Email: zhu.chun1@zte.com.cn