INTERNET-DRAFT C.Chen Intended Status: Proposed Standard X.Wei Expires: May 4, 2017 Huawei Technologies Co., Ltd October 31, 2016 ID Locator Split Based Solution for 5G Network draft-chen-id-locator-split-5g-solution-00 Abstract In this memo, a generic network scheme based on ID / Locator separation architecture is proposed to satisfy the emerging new requirements of future networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Expires May 4, 2017 [Page 1] INTERNET DRAFT October 31, 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Current Solution Analysis . . . . . . . . . . . . . . . . . . 4 2.1 GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 MIPv4/MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Design Principle . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Architecture Design . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . 6 4.2 Reference Point Definition . . . . . . . . . . . . . . . . 8 4.3 Signaling and Data Flow Overview . . . . . . . . . . . . . 8 4.3.1 Packet Forwarding Procedure . . . . . . . . . . . . . . 8 4.3.2 Handover Procedures . . . . . . . . . . . . . . . . . . 10 4.3.2.1 Handover without routing optimization . . . . . . . 10 4.3.2.2 Handover with routing optimization . . . . . . . . . 11 4.3.3 Interconnection between ID Network and IP Network . . . 13 5 Message Definition . . . . . . . . . . . . . . . . . . . . . . . 15 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 7 Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 10.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Expires May 4, 2017 [Page 2] INTERNET DRAFT October 31, 2016 1 Introduction With the emergence of various new communication services, there have been many new network communication needs, and also more and more new demands for network capability. For example, there are high mobility requirements, such as high-speed railway communications; low latency and high reliability, such as for industrial Internet production control process; low power consumption and low complexity of small data reported such as the mass of the sensor device access network. Another example, AR/VR communication needs end-to-end delay requirement of less than 20ms, excluding terminal and network side of the business processing delay, the network transmission delay requirements of less than 10ms , it needs to maintain business continuity while maintaining low latency as the AR / VR end-user moves. In the field of wireless communication network, 5G wireless system researches also proposed to the mobile network a list of new design requirements in order to meet the needs of future communication, such as flexible mobility management solutions, multi-access, efficient use of network resources, efficient data transmission, ultra-low latency transmission, a large number of equipment access and so on. The overall look at mass terminal access, ubiquitous mobility, low latency, high bandwidth, high reliability, low power consumption and low complexity, is to meet the basic characteristics of the new business network and requirements. Currently the IP address indicates both the identity and location of the end host. It doesn't support mobility and multiple accesses naturally. It is also inefficient in terms of route validity (referring to route aggregation with Locator), scalability, and security. If the communication address and Identifier are separated, the connection can be established with any identifier, not limited by the communication address segment of the IP network. At the same time, the communication message is transmitted by any address, and is not affected the identifier of both ends of the communication. In this memo, a generic network scheme based on ID / Locator separation architecture is proposed to satisfy the following requirements of future networks: (1) Ubiquitous mobility: the identifier is independent from network location and can cope with the change of network location. (2) Low latency: select any optimal communication path, not subject to IP network segment restrictions, especially for the mobile communication. Expires May 4, 2017 [Page 3] INTERNET DRAFT October 31, 2016 (3) High reliability: one communication identifier could be mapped to multi-address, multi transmission path, which can be back up each other. (4) High-bandwidth: multi-address, make full use of a variety of access technologies; multi-path, take full advantage of network bandwidth. (5) Low-power and low complexity network, mass IOT device access and small data packet message transmission: transmission mechanism is simple, based on arbitrary identification of data transmission; simple signaling, transmission redundancy, to avoid heavy protocol stack and complex IP address allocation mechanism. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Current Solution Analysis This chapter makes a preliminary analysis of some existing mobility management protocols and protocols based on ID-Locator separation scheme. 2.1 GTP GTP [TS29.060] is a 3GPP-defined tunneling protocol that provides mobility support in 3GPP network. GTP is an access-related L2 mobility management protocol; it supports mobility of 3GPP access technologies. But for non-3GPP access technology, such as WiFi access, through a special access adapter to access 4G EPC network. At the same time GTP is a local mobility protocol, and it does not support the user to switch the anchor after moving. 2.2 MIPv4/MIPv6 MIPv4 [RFC5944] and MIPv6 [RFC6275] are the Host Based mobility management protocol. RFC4830 analysis of the support of the routing optimization Host-based mobility management protocol several major issues: (1) User privacy disclosure: in case of routing optimization, the correspondent node can see the local IP changes, and it can track the location of the user; (2) Switching performance: end to end, long-distance communication, the location of the change of information to inform the end of a greater delay; (3) Low efficiency of air interface: IP over IP transmission format, the head in the Expires May 4, 2017 [Page 4] INTERNET DRAFT October 31, 2016 empty packet transmission load, transmission inefficient; (4) Backward compatibility issue, need to modify the terminal to support MIP protocol stack. 2.3 PMIPv6 PMIPv6 [RFC5213] migrates MIPv6 mobility management capabilities to the edge of the network, through the network proxy. PMIP is a local scope mobility management protocol, and it does not support the user to move the anchor after the switch. 2.4 HIP The HIP [RFC7401] protocol is a protocol that conforms to the idea of ID Locator separation. It can support Host-based mobility and is more secure than MIP. It has the same problem as MIP. 2.5 LISP The main purpose of LISP [RFC6830] protocol design is to support the scalability of IP network routing, and to collect the IP packets with the same route through Locator to reduce the number of routes of network devices and to support traffic engineering. LISP protocol does not support network-side mobility; LISP extension protocol can support Host-based mobility, and MIP, HIP with the same host mobility issues; 2.6 ILNP ILNP [RFC6740] protocol divide 128-bit long IPv6 address into two parts, high 64-bit locator, and low 64-bit ID, this format can reduce the header overload; the control plane is designed mainly through enhancement of DNS protocol and ICMP protocol. ILNP protocol mainly supports Host Based mobility; and through the DNS system to track the user mobile location, it can not support high-speed mobile and service continuity. 3 Design Principle The ID Locator separation scheme in this document is designed to adhere to the following design principles: 1. Providing high-performance, flexible, ubiquitous mobility support 2. Support IoT transmission characteristics, for example, large connections, sleep, different levels of mobility. 3. Support multi-access Expires May 4, 2017 [Page 5] INTERNET DRAFT October 31, 2016 4. Delay performance requirements 5. Has good scalability 6. Minimize modifications to existing terminals. Supports legacy terminals. 7. Compatible with existing IP networks. 8. Support any form of ID forwarding, not only limit to the IP address compatible format. 9. Support multiple forwarding plane format, which can be selected flexible, such as LISP format or ILA format. 10. Access agnostic: the L3 network mobility is supported mainly, and can be compatible with a variety of L2 mobility technology. 11. Support the network based mobility, can be deployed in the terminal to support the host based mobility flexible. 4 Architecture Design 4.1 Architecture Overview Based on the idea of ID-Locator separation, combining the above new design requirements, the following scheme architecture is proposed. The architecture contains the ID domain, that is, using the ID- Locator separation to communicate, also includes the IP domain, that is, the existing IP address-based communication. Expires May 4, 2017 [Page 6] INTERNET DRAFT October 31, 2016 ---------------------. | IP Domain | | | +-------+ | +-------+ | |Ext DNS|---------------|IP host| | +---|---+ | +-.-----+ | | | | | | | | | | '------------|-------- | | +----------------------------------|---------------------|--------+ | ID Domain | | | | +--------------------------+--'+ | | | | +----------+UCP|--------+ I5| | | | | I4 +---+ I4 | | | | |I2 | | | | | | | | | | | | | | +---------+ | | | | | | | | +--+----+ I1 +-+-+ I3 +'-|+ I1 +-------+ | | |ID host|--------|LPF|--------------------|LPF|------|ID host| | | +-------+ +---+ +---+ +-------+ | | | +-----------------------------------------------------------------+ Figure 1: Architecture Overview Functionality Definitions: ID host The host that uses ID-based communication scheme, the ID hosts in ID domain communicate with each other through ID-based communication scheme. The ID host could be devices such as broadband mobile phones, IOT equipment, vehicles etc. UCP The universal control plane of the architecture. The ID-Locator mapping is maintained. LPF Expires May 4, 2017 [Page 7] INTERNET DRAFT October 31, 2016 Including user Locator allocation, Locator registration, user packet encapsulation and decapsulation and forwarding functions. IP Host The host that uses IP-based communication scheme, the IP hosts in IP domain communicate with each other through IP-based communication scheme. The IP host could be devices such as broadband mobile phones, IOT equipment, vehicles etc. Ext DNS Resolve host's forwarding ID by permanent ID. 4.2 Reference Point Definition I1: ID registration, activation and motion detection. I2: ID packets are received and transmitted on the L2 network. I4: ID over Locator message reception and transmission. I3: Locator Allocation Update, ID / Locator Association Mapping, ID / Locator Query Subscription. I5: Interfaces between the ID domain and the IP domain. 4.3 Signaling and Data Flow Overview 4.3.1 Packet Forwarding Procedure The process shows a normal data sending and receiving process. Expires May 4, 2017 [Page 8] INTERNET DRAFT October 31, 2016 +--------+ +---+ +---+ +---+ +--------+ |ID host1| |LPF| |UCP| |LPF| |ID host2| +--------+ +-.-+ +-.-+ +--.+ +---.----+ | | |(1) ID and LOC Registration | | |<---------------------| |(2)resolve | | | | | peer ID ||-------+| | | |------------->Ext DNS|| | | | |+-------+| | | |(3)ID packet| | | | |------------> | | | | |(4)LOC | | | | | query | | | | |---------> | | | |(5)assign| | | | | ID/LOC | | | | | mapping | | | | <---------| | | | | | | | | |(6)packet transmission| | | |----------------------> | | | | (7)packet | | | | | forward | | | | |---------> | | | | | Figure 2: Packet Forwarding Procedure (1) Host1 registration ID and location information in UCP. (2) Resolve peer host's forwarding ID by permanent ID. (3) Encapsulate the ID packet and send it to the LPF; (4) The LPF receives the ID packet, searches for the ID / Locator mapping table (only for the first packet) according to the destination ID, sends the destination ID to the UCP, and searches for the ID / Locator mapping relationship. (5) The UCP allocates the LPF and the corresponding Locator based on the ID and location registration relation registered with the peer host and sends the ID / Locator mapping to the LPF. (6) The local LPF encapsulates the Locator + ID packet according to the ID / Locator mapping relationship and sends the packet to the peer LPF through IP routing. (7) Encapsulating the ID packet and forwarding to the host2. Expires May 4, 2017 [Page 9] INTERNET DRAFT October 31, 2016 4.3.2 Handover Procedures This subsection describes handover procedures that the host moves from SRC LPF to DEST LPF. 4.3.2.1 Handover without routing optimization +--------+ +-------+ +-------+ +---+ +--------+ |ID host1| |SRC LPF| |DST LPF| |UCP| |ID host2| +---+----+ +---+---+ +---+---+ +-+-+ +----+---+ | | | | | |(1) ID and | | | | | LOC regist.| | | | |----------------------------------->| | | |(2)config | | | | | ID/LOC map. | | | |<----------------------| | | |(3)data forwarding path| | |<-----------|<--------------------------------| +----+ | | | | |Move| | | | | +----+ | | | | | (4)ID and LOC registration | | |----------------------------------->| | | | |(5)config | | | | |ID/LOC map.| | | | |<----------| | | |(6)indicate to redirect| | | |packets from SRC LPF to| | | |DEST LPF | | | | |<----------------------| | | |(7) redirect | | | |packets | | | | |---------->| | | |<-----------------------| | | | | | | | Figure 3: Handover without routing optimization (1) Host1 registration ID and location information in UCP. (2) The UCP allocates the LPF and the corresponding Locator based on the ID and location registration relation registered with the peer host2 and sends the ID / Locator mapping to the LPF. (3) Data forwarding path from peer host2 to host1 through SRC LPF. (4) After host1 moves to a new DEST LPF, it re-registers ID and Expires May 4, 2017 [Page 10] INTERNET DRAFT October 31, 2016 locator information in UCP. (5) UCP configures host1's ID-locator mapping in DEST LPF. (6) UCP indicates SRC LPF to redirect packets for host1 from SRC LPF to DEST LPF. (7) SRC LPF redirects received downlink packets to DEST LPF and the packets will be forwarded from DEST LPF to host1. 4.3.2.2 Handover with routing optimization Expires May 4, 2017 [Page 11] INTERNET DRAFT October 31, 2016 +-----+ +--------+ +-------+ +-------+ +---+ |Peer | +--------+ |ID host1| |SRC LPF| |DST LPF| |UCP| |LPF | |ID host2| +---+----+ +---+---+ +---+---+ +-+-+ +-----+ +----+---+ | | | | | | |(1) ID and | | | | | | LOC regist.| | | | | |----------------------------------->| | | | |(2)config | | | | | | ID/LOC map. | | | | |<----------------------| | | | |(3)data forwarding path| | | |<-----------|<------------------------------------------| +----+ | | | | | |Move| | | | | | +----+ | | | | | | (4)ID and LOC registration | | | |----------------------------------->| | | | | |(5)config | | | | | |ID/LOC map.| | | | | |<----------| | | | |(6)indicate to redirect| | | | |packets from SRC LPF to| | | | |DEST LPF | | | | | |<----------------------| | | | |(7) redirect | | | | |packets | | | | | |---------->| | | | |<-----------------------| | | | | | |(8)recofig ID/LOC mapping | | | |<----------|--------> | | |(9)release ID/LOC mapping | | | |<----------------------| | | | | | | | | | | (10) data forwarding | | | |<-----------------------|<------------------------------| Figure 4: Handover with routing optimization (1) Host1 registration ID and location information in UCP. (2) The UCP allocates the LPF and the corresponding Locator based on the ID and location registration relation registered with the peer host2 and sends the ID / Locator mapping to the LPF. (3) Data forwarding path from peer host2 to host1 through SRC LPF. Expires May 4, 2017 [Page 12] INTERNET DRAFT October 31, 2016 (4) After UE moves to a new DEST LPF, it re-registers ID and locator information in UCP. (5) UCP configures host1's ID-locator mapping in DEST LPF. (6) UCP indicates SRC LPF to redirect packets for UE from SRC LPF to DEST LPF. (7) SRC LPF redirects received downlink packets to DEST LPF and the packets will be forwarded from DEST LPF to host1. (8) UCP reconfigure ID-locator mapping on peer LPF to indicate peer LPF forwarding packets directly to DEST LPF. (9) Release ID-locator mapping on SRC LPF. (10) Packets are forwarded directly from peer LPF to DEST LPF to host1. 4.3.3 Interconnection between ID Network and IP Network This process shows how to communicate between an ID network and an IP network. Expires May 4, 2017 [Page 13] INTERNET DRAFT October 31, 2016 +-------+ +---+ +---+ +-------+ +-------+ |ID host| |LPF| |UCP| |Ext DNS| |IP host| +---.---+ +-.-+ +-.-+ +---.---+ +---.---+ | | | | | | (1)ID/LOC regist. | | | |-------------------->| | | | | |(2)regis. | | | | | of IP for ID | | | | host | | | | |--------->| | | |(3)config. | | | |mapping relation | | | |between ID and |(3.1)query| | |proxy IP addr. |IP according | |<--------| |to ID | | | | |<---------| | | (3.2)sending IP packet | | |<------------------------------| |(3.3) packet | | | |with ID | | | | |<----------| | | | | (4.1) resolve peer's ID | | |------------------------------->| | |(4.2)packet| | | | |with ID | | | | |---------->| | | | | | (4.3)sending IP packet | |------------------------------------------>| | | | | | Figure 5: Interconnection between ID Network and IP Network (1) ID host registers ID and ID location information. (2) The UCP allocates a designated IP address to each registered ID host as a proxy IP for interworking with the external IP network; and registers the relation between the ID and the IP in the DNS system; (3) Communication from IP-based host to ID-based host. (3.1) The UCP instructs the LPF to establish a mapping table between the ID and the IP, which acts as the proxy point for interworking with the IP network. (3.2) When an IP entity needs to communicate with an ID host, it first resolves the proxy IP from the DNS system and then communicates Expires May 4, 2017 [Page 14] INTERNET DRAFT October 31, 2016 with the ID host through the standard IP packet. (3.3) The LPF receives the IP packet, finds the mapping relationship, de-encapsulates the packet, and re-encapsulates the ID packet header, and sends the packet to the destination ID host; (4) Communication from ID host to IP host. (4.1) ID host resolves the domain name of the remote end, and DNS returns the IP address of the remote end. (4.2) If the peer ID is a standard IP address, it must be explicitly marked in the encapsulated packet so that the LPF can determine the difference. (4.3) When the LPF receives a packet and determines that the peer end is an IP address, the LPF de-encapsulates ID packet. Packets are encapsulated with proxy IPs on the LPF and then sent to the remote end in the IP domain. (4.4) If the ID host does not support DNS resolution, the LPF could finish the DNS procedure instead of ID host. 5 Message Definition TBD. Expires May 4, 2017 [Page 15] INTERNET DRAFT October 31, 2016 6 Security Considerations TBD. 7 Privacy Considerations TBD. 8 IANA Considerations TBD. 9 Acknowledgements Thanks for Fei Yang, Rui Meng, TingFang Tang and Xiaoyan Shi for their insightful suggestion and reviews for the document. 10 References 10.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013, . 10.2 Informative References [TS29.060] 3GPP TS 29.060: "GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface"3GPP TS 29.060: "GPRS Tunnelling Protocol (GTP) Expires May 4, 2017 [Page 16] INTERNET DRAFT October 31, 2016 across the Gn and Gp interface". Authors' Addresses Cheng Chen Z-park M06 Q20, Beiqing Road No.156, Haidian District, Beijing, China EMail: chencheng@huawei.com Xinpeng Wei Z-park M06 Q20, Beiqing Road No.156, Haidian District, Beijing, China EMail: weixinpeng@huawei.com Expires May 4, 2017 [Page 17]