idnits 2.17.00 (12 Aug 2021) /tmp/idnits15361/draft-chen-id-locator-split-5g-solution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 150, but not defined == Missing Reference: 'RFC7401' is mentioned on line 191, but not defined == Missing Reference: 'RFC6740' is mentioned on line 207, but not defined == Unused Reference: 'KEYWORDS' is defined on line 605, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 6830 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C.Chen 3 Intended Status: Proposed Standard X.Wei 4 Expires: May 4, 2017 Huawei Technologies Co., Ltd 5 October 31, 2016 7 ID Locator Split Based Solution for 5G Network 8 draft-chen-id-locator-split-5g-solution-00 10 Abstract 12 In this memo, a generic network scheme based on ID / Locator 13 separation architecture is proposed to satisfy the emerging new 14 requirements of future networks. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Current Solution Analysis . . . . . . . . . . . . . . . . . . 4 57 2.1 GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 MIPv4/MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4 HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.5 LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3 Design Principle . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4 Architecture Design . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . 6 66 4.2 Reference Point Definition . . . . . . . . . . . . . . . . 8 67 4.3 Signaling and Data Flow Overview . . . . . . . . . . . . . 8 68 4.3.1 Packet Forwarding Procedure . . . . . . . . . . . . . . 8 69 4.3.2 Handover Procedures . . . . . . . . . . . . . . . . . . 10 70 4.3.2.1 Handover without routing optimization . . . . . . . 10 71 4.3.2.2 Handover with routing optimization . . . . . . . . . 11 72 4.3.3 Interconnection between ID Network and IP Network . . . 13 73 5 Message Definition . . . . . . . . . . . . . . . . . . . . . . . 15 74 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 75 7 Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 76 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 77 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 78 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 80 10.2 Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1 Introduction 85 With the emergence of various new communication services, there have 86 been many new network communication needs, and also more and more new 87 demands for network capability. For example, there are high mobility 88 requirements, such as high-speed railway communications; low latency 89 and high reliability, such as for industrial Internet production 90 control process; low power consumption and low complexity of small 91 data reported such as the mass of the sensor device access network. 92 Another example, AR/VR communication needs end-to-end delay 93 requirement of less than 20ms, excluding terminal and network side of 94 the business processing delay, the network transmission delay 95 requirements of less than 10ms , it needs to maintain business 96 continuity while maintaining low latency as the AR / VR end-user 97 moves. 99 In the field of wireless communication network, 5G wireless system 100 researches also proposed to the mobile network a list of new design 101 requirements in order to meet the needs of future communication, such 102 as flexible mobility management solutions, multi-access, efficient 103 use of network resources, efficient data transmission, ultra-low 104 latency transmission, a large number of equipment access and so on. 106 The overall look at mass terminal access, ubiquitous mobility, low 107 latency, high bandwidth, high reliability, low power consumption and 108 low complexity, is to meet the basic characteristics of the new 109 business network and requirements. Currently the IP address indicates 110 both the identity and location of the end host. It doesn't support 111 mobility and multiple accesses naturally. It is also inefficient in 112 terms of route validity (referring to route aggregation with 113 Locator), scalability, and security. 115 If the communication address and Identifier are separated, the 116 connection can be established with any identifier, not limited by the 117 communication address segment of the IP network. At the same time, 118 the communication message is transmitted by any address, and is not 119 affected the identifier of both ends of the communication. In this 120 memo, a generic network scheme based on ID / Locator separation 121 architecture is proposed to satisfy the following requirements of 122 future networks: 124 (1) Ubiquitous mobility: the identifier is independent from network 125 location and can cope with the change of network location. 127 (2) Low latency: select any optimal communication path, not subject 128 to IP network segment restrictions, especially for the mobile 129 communication. 131 (3) High reliability: one communication identifier could be mapped to 132 multi-address, multi transmission path, which can be back up each 133 other. 135 (4) High-bandwidth: multi-address, make full use of a variety of 136 access technologies; multi-path, take full advantage of network 137 bandwidth. 139 (5) Low-power and low complexity network, mass IOT device access and 140 small data packet message transmission: transmission mechanism is 141 simple, based on arbitrary identification of data transmission; 142 simple signaling, transmission redundancy, to avoid heavy protocol 143 stack and complex IP address allocation mechanism. 145 1.1 Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Current Solution Analysis 153 This chapter makes a preliminary analysis of some existing mobility 154 management protocols and protocols based on ID-Locator separation 155 scheme. 157 2.1 GTP 159 GTP [TS29.060] is a 3GPP-defined tunneling protocol that provides 160 mobility support in 3GPP network. GTP is an access-related L2 161 mobility management protocol; it supports mobility of 3GPP access 162 technologies. But for non-3GPP access technology, such as WiFi 163 access, through a special access adapter to access 4G EPC network. At 164 the same time GTP is a local mobility protocol, and it does not 165 support the user to switch the anchor after moving. 167 2.2 MIPv4/MIPv6 169 MIPv4 [RFC5944] and MIPv6 [RFC6275] are the Host Based mobility 170 management protocol. RFC4830 analysis of the support of the routing 171 optimization Host-based mobility management protocol several major 172 issues: (1) User privacy disclosure: in case of routing optimization, 173 the correspondent node can see the local IP changes, and it can track 174 the location of the user; (2) Switching performance: end to end, 175 long-distance communication, the location of the change of 176 information to inform the end of a greater delay; (3) Low efficiency 177 of air interface: IP over IP transmission format, the head in the 178 empty packet transmission load, transmission inefficient; (4) 179 Backward compatibility issue, need to modify the terminal to support 180 MIP protocol stack. 182 2.3 PMIPv6 184 PMIPv6 [RFC5213] migrates MIPv6 mobility management capabilities to 185 the edge of the network, through the network proxy. PMIP is a local 186 scope mobility management protocol, and it does not support the user 187 to move the anchor after the switch. 189 2.4 HIP 191 The HIP [RFC7401] protocol is a protocol that conforms to the idea of 192 ID Locator separation. It can support Host-based mobility and is more 193 secure than MIP. It has the same problem as MIP. 195 2.5 LISP 197 The main purpose of LISP [RFC6830] protocol design is to support the 198 scalability of IP network routing, and to collect the IP packets with 199 the same route through Locator to reduce the number of routes of 200 network devices and to support traffic engineering. LISP protocol 201 does not support network-side mobility; LISP extension protocol can 202 support Host-based mobility, and MIP, HIP with the same host mobility 203 issues; 205 2.6 ILNP 207 ILNP [RFC6740] protocol divide 128-bit long IPv6 address into two 208 parts, high 64-bit locator, and low 64-bit ID, this format can reduce 209 the header overload; the control plane is designed mainly through 210 enhancement of DNS protocol and ICMP protocol. ILNP protocol mainly 211 supports Host Based mobility; and through the DNS system to track the 212 user mobile location, it can not support high-speed mobile and 213 service continuity. 215 3 Design Principle 217 The ID Locator separation scheme in this document is designed to 218 adhere to the following design principles: 220 1. Providing high-performance, flexible, ubiquitous mobility support 222 2. Support IoT transmission characteristics, for example, large 223 connections, sleep, different levels of mobility. 225 3. Support multi-access 226 4. Delay performance requirements 228 5. Has good scalability 230 6. Minimize modifications to existing terminals. Supports legacy 231 terminals. 233 7. Compatible with existing IP networks. 235 8. Support any form of ID forwarding, not only limit to the IP 236 address compatible format. 238 9. Support multiple forwarding plane format, which can be selected 239 flexible, such as LISP format or ILA format. 241 10. Access agnostic: the L3 network mobility is supported mainly, and 242 can be compatible with a variety of L2 mobility technology. 244 11. Support the network based mobility, can be deployed in the 245 terminal to support the host based mobility flexible. 247 4 Architecture Design 249 4.1 Architecture Overview 251 Based on the idea of ID-Locator separation, combining the above new 252 design requirements, the following scheme architecture is proposed. 253 The architecture contains the ID domain, that is, using the ID- 254 Locator separation to communicate, also includes the IP domain, that 255 is, the existing IP address-based communication. 257 ---------------------. 258 | IP Domain | 259 | | 260 +-------+ | +-------+ | 261 |Ext DNS|---------------|IP host| | 262 +---|---+ | +-.-----+ | 263 | | | | 264 | | | | 265 | '------------|-------- 266 | | 267 +----------------------------------|---------------------|--------+ 268 | ID Domain | | | 269 | +--------------------------+--'+ | | 270 | | +----------+UCP|--------+ I5| | 271 | | | I4 +---+ I4 | | | 272 | |I2 | | | | 273 | | | | | | 274 | | | | +---------+ | 275 | | | | | | 276 | +--+----+ I1 +-+-+ I3 +'-|+ I1 +-------+ | 277 | |ID host|--------|LPF|--------------------|LPF|------|ID host| | 278 | +-------+ +---+ +---+ +-------+ | 279 | | 280 +-----------------------------------------------------------------+ 282 Figure 1: Architecture Overview 284 Functionality Definitions: 286 ID host 288 The host that uses ID-based communication scheme, the ID hosts in ID 289 domain communicate with each other through ID-based communication 290 scheme. The ID host could be devices such as broadband mobile phones, 291 IOT equipment, vehicles etc. 293 UCP 295 The universal control plane of the architecture. The ID-Locator 296 mapping is maintained. 298 LPF 299 Including user Locator allocation, Locator registration, user packet 300 encapsulation and decapsulation and forwarding functions. 302 IP Host 304 The host that uses IP-based communication scheme, the IP hosts in IP 305 domain communicate with each other through IP-based communication 306 scheme. The IP host could be devices such as broadband mobile phones, 307 IOT equipment, vehicles etc. 309 Ext DNS 311 Resolve host's forwarding ID by permanent ID. 313 4.2 Reference Point Definition 315 I1: ID registration, activation and motion detection. 317 I2: ID packets are received and transmitted on the L2 network. 319 I4: ID over Locator message reception and transmission. 321 I3: Locator Allocation Update, ID / Locator Association Mapping, ID / 322 Locator Query Subscription. 324 I5: Interfaces between the ID domain and the IP domain. 326 4.3 Signaling and Data Flow Overview 328 4.3.1 Packet Forwarding Procedure 330 The process shows a normal data sending and receiving process. 332 +--------+ +---+ +---+ +---+ +--------+ 333 |ID host1| |LPF| |UCP| |LPF| |ID host2| 334 +--------+ +-.-+ +-.-+ +--.+ +---.----+ 335 | | |(1) ID and LOC Registration 336 | | |<---------------------| 337 |(2)resolve | | | | 338 | peer ID ||-------+| | | 339 |------------->Ext DNS|| | | 340 | |+-------+| | | 341 |(3)ID packet| | | | 342 |------------> | | | 343 | |(4)LOC | | | 344 | | query | | | 345 | |---------> | | 346 | |(5)assign| | | 347 | | ID/LOC | | | 348 | | mapping | | | 349 | <---------| | | 350 | | | | | 351 | |(6)packet transmission| | 352 | |----------------------> | 353 | | | (7)packet | 354 | | | | forward | 355 | | | |---------> 356 | | | | | 358 Figure 2: Packet Forwarding Procedure 360 (1) Host1 registration ID and location information in UCP. 362 (2) Resolve peer host's forwarding ID by permanent ID. 364 (3) Encapsulate the ID packet and send it to the LPF; 366 (4) The LPF receives the ID packet, searches for the ID / Locator 367 mapping table (only for the first packet) according to the 368 destination ID, sends the destination ID to the UCP, and searches for 369 the ID / Locator mapping relationship. 371 (5) The UCP allocates the LPF and the corresponding Locator based on 372 the ID and location registration relation registered with the peer 373 host and sends the ID / Locator mapping to the LPF. 375 (6) The local LPF encapsulates the Locator + ID packet according to 376 the ID / Locator mapping relationship and sends the packet to the 377 peer LPF through IP routing. 379 (7) Encapsulating the ID packet and forwarding to the host2. 381 4.3.2 Handover Procedures 383 This subsection describes handover procedures that the host moves 384 from SRC LPF to DEST LPF. 386 4.3.2.1 Handover without routing optimization 388 +--------+ +-------+ +-------+ +---+ +--------+ 389 |ID host1| |SRC LPF| |DST LPF| |UCP| |ID host2| 390 +---+----+ +---+---+ +---+---+ +-+-+ +----+---+ 391 | | | | | 392 |(1) ID and | | | | 393 | LOC regist.| | | | 394 |----------------------------------->| | 395 | |(2)config | | | 396 | | ID/LOC map. | | 397 | |<----------------------| | 398 | |(3)data forwarding path| | 399 |<-----------|<--------------------------------| 400 +----+ | | | | 401 |Move| | | | | 402 +----+ | | | | 403 | (4)ID and LOC registration | | 404 |----------------------------------->| | 405 | | |(5)config | | 406 | | |ID/LOC map.| | 407 | | |<----------| | 408 | |(6)indicate to redirect| | 409 | |packets from SRC LPF to| | 410 | |DEST LPF | | | 411 | |<----------------------| | 412 | |(7) redirect | | 413 | |packets | | | 414 | |---------->| | | 415 |<-----------------------| | | 416 | | | | | 418 Figure 3: Handover without routing optimization 420 (1) Host1 registration ID and location information in UCP. 422 (2) The UCP allocates the LPF and the corresponding Locator based on 423 the ID and location registration relation registered with the peer 424 host2 and sends the ID / Locator mapping to the LPF. 426 (3) Data forwarding path from peer host2 to host1 through SRC LPF. 428 (4) After host1 moves to a new DEST LPF, it re-registers ID and 429 locator information in UCP. 431 (5) UCP configures host1's ID-locator mapping in DEST LPF. 433 (6) UCP indicates SRC LPF to redirect packets for host1 from SRC LPF 434 to DEST LPF. 436 (7) SRC LPF redirects received downlink packets to DEST LPF and the 437 packets will be forwarded from DEST LPF to host1. 439 4.3.2.2 Handover with routing optimization 440 +-----+ 441 +--------+ +-------+ +-------+ +---+ |Peer | +--------+ 442 |ID host1| |SRC LPF| |DST LPF| |UCP| |LPF | |ID host2| 443 +---+----+ +---+---+ +---+---+ +-+-+ +-----+ +----+---+ 444 | | | | | | 445 |(1) ID and | | | | | 446 | LOC regist.| | | | | 447 |----------------------------------->| | | 448 | |(2)config | | | | 449 | | ID/LOC map. | | | 450 | |<----------------------| | | 451 | |(3)data forwarding path| | | 452 |<-----------|<------------------------------------------| 453 +----+ | | | | | 454 |Move| | | | | | 455 +----+ | | | | | 456 | (4)ID and LOC registration | | | 457 |----------------------------------->| | | 458 | | |(5)config | | | 459 | | |ID/LOC map.| | | 460 | | |<----------| | | 461 | |(6)indicate to redirect| | | 462 | |packets from SRC LPF to| | | 463 | |DEST LPF | | | | 464 | |<----------------------| | | 465 | |(7) redirect | | | 466 | |packets | | | | 467 | |---------->| | | | 468 |<-----------------------| | | | 469 | | |(8)recofig ID/LOC mapping | 470 | | |<----------|--------> | 471 | |(9)release ID/LOC mapping | | 472 | |<----------------------| | | 473 | | | | | | 474 | | (10) data forwarding | | | 475 |<-----------------------|<------------------------------| 477 Figure 4: Handover with routing optimization 479 (1) Host1 registration ID and location information in UCP. 481 (2) The UCP allocates the LPF and the corresponding Locator based on 482 the ID and location registration relation registered with the peer 483 host2 and sends the ID / Locator mapping to the LPF. 485 (3) Data forwarding path from peer host2 to host1 through SRC LPF. 487 (4) After UE moves to a new DEST LPF, it re-registers ID and locator 488 information in UCP. 490 (5) UCP configures host1's ID-locator mapping in DEST LPF. 492 (6) UCP indicates SRC LPF to redirect packets for UE from SRC LPF to 493 DEST LPF. 495 (7) SRC LPF redirects received downlink packets to DEST LPF and the 496 packets will be forwarded from DEST LPF to host1. 498 (8) UCP reconfigure ID-locator mapping on peer LPF to indicate peer 499 LPF forwarding packets directly to DEST LPF. 501 (9) Release ID-locator mapping on SRC LPF. 503 (10) Packets are forwarded directly from peer LPF to DEST LPF to 504 host1. 506 4.3.3 Interconnection between ID Network and IP Network 508 This process shows how to communicate between an ID network and an IP 509 network. 511 +-------+ +---+ +---+ +-------+ +-------+ 512 |ID host| |LPF| |UCP| |Ext DNS| |IP host| 513 +---.---+ +-.-+ +-.-+ +---.---+ +---.---+ 514 | | | | | 515 | (1)ID/LOC regist. | | | 516 |-------------------->| | | 517 | | |(2)regis. | | 518 | | | of IP for ID | 519 | | | host | | 520 | | |--------->| | 521 | |(3)config. | | 522 | |mapping relation | | 523 | |between ID and |(3.1)query| 524 | |proxy IP addr. |IP according 525 | |<--------| |to ID | 526 | | | |<---------| 527 | | (3.2)sending IP packet | 528 | |<------------------------------| 529 |(3.3) packet | | | 530 |with ID | | | | 531 |<----------| | | | 532 | (4.1) resolve peer's ID | | 533 |------------------------------->| | 534 |(4.2)packet| | | | 535 |with ID | | | | 536 |---------->| | | | 537 | | (4.3)sending IP packet | 538 |------------------------------------------>| 539 | | | | | 541 Figure 5: Interconnection between ID Network and IP Network 543 (1) ID host registers ID and ID location information. 545 (2) The UCP allocates a designated IP address to each registered ID 546 host as a proxy IP for interworking with the external IP network; and 547 registers the relation between the ID and the IP in the DNS system; 549 (3) Communication from IP-based host to ID-based host. 551 (3.1) The UCP instructs the LPF to establish a mapping table between 552 the ID and the IP, which acts as the proxy point for interworking 553 with the IP network. 555 (3.2) When an IP entity needs to communicate with an ID host, it 556 first resolves the proxy IP from the DNS system and then communicates 557 with the ID host through the standard IP packet. 559 (3.3) The LPF receives the IP packet, finds the mapping relationship, 560 de-encapsulates the packet, and re-encapsulates the ID packet header, 561 and sends the packet to the destination ID host; 563 (4) Communication from ID host to IP host. 565 (4.1) ID host resolves the domain name of the remote end, and DNS 566 returns the IP address of the remote end. 568 (4.2) If the peer ID is a standard IP address, it must be explicitly 569 marked in the encapsulated packet so that the LPF can determine the 570 difference. 572 (4.3) When the LPF receives a packet and determines that the peer end 573 is an IP address, the LPF de-encapsulates ID packet. Packets are 574 encapsulated with proxy IPs on the LPF and then sent to the remote 575 end in the IP domain. 577 (4.4) If the ID host does not support DNS resolution, the LPF could 578 finish the DNS procedure instead of ID host. 580 5 Message Definition 582 TBD. 584 6 Security Considerations 586 TBD. 588 7 Privacy Considerations 590 TBD. 592 8 IANA Considerations 594 TBD. 596 9 Acknowledgements 598 Thanks for Fei Yang, Rui Meng, TingFang Tang and Xiaoyan Shi for 599 their insightful suggestion and reviews for the document. 601 10 References 603 10.1 Normative References 605 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997, 607 . 609 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 610 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 611 RFC 5213, August 2008, . 614 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 615 RFC 5944, November 2010, . 618 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 619 Support in IPv6", RFC 6275, July 2011, . 622 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 623 Locator/ID Separation Protocol (LISP)", RFC 6830, January 624 2013, . 626 10.2 Informative References 628 [TS29.060] 3GPP TS 29.060: "GPRS Tunnelling Protocol (GTP) across the 629 Gn and Gp interface"3GPP TS 29.060: "GPRS Tunnelling Protocol (GTP) 630 across the Gn and Gp interface". 632 Authors' Addresses 634 Cheng Chen 636 Z-park M06 Q20, Beiqing Road No.156, Haidian District, Beijing, China 638 EMail: chencheng@huawei.com 640 Xinpeng Wei 642 Z-park M06 Q20, Beiqing Road No.156, Haidian District, Beijing, China 644 EMail: weixinpeng@huawei.com