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]