Internet DRAFT - draft-chen-id-locator-split-5g-solution
draft-chen-id-locator-split-5g-solution
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
<Author> Expires May 4, 2017 [Page 1]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 2]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 3]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 4]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 5]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 6]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 7]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 8]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 9]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 10]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 11]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 12]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 13]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 14]
INTERNET DRAFT <Document Title> 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.
<Author> Expires May 4, 2017 [Page 15]
INTERNET DRAFT <Document Title> 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008, <http://www.rfc-
editor.org/info/rfc5213>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010, <http://www.rfc-
editor.org/info/rfc5944>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011, <http://www.rfc-
editor.org/info/rfc6275>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013, <http://www.rfc-editor.org/info/rfc6830>.
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)
<Author> Expires May 4, 2017 [Page 16]
INTERNET DRAFT <Document Title> 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
<Author> Expires May 4, 2017 [Page 17]
