Internet DRAFT - draft-cui-v6ops-lte-lw4over6

draft-cui-v6ops-lte-lw4over6







v6ops Working Group                                               Y. Cui
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                     Tsinghua University
Expires: August 17, 2014                               February 13, 2014


                  Lightweight 4over6 for LTE Networks
                    draft-cui-v6ops-lte-lw4over6-00

Abstract

   Operators of Long Term Evolution (LTE) networks have been suffering
   from IPv4 address shortages and are forced to migrate to IPv6.  Many
   operators prefer to build new LTE networks based on IPv6.  However,
   at present there are still a lot of IPv4-only mobile terminals.  A
   large number of high-quality applications are also in the IPv4-only
   Internet.  There exist needs from IPv4 users to access IPv4 Internet
   across an IPv6-only LTE network.  This document describes a tunneling
   mechanism that enables the IPv4 users to connect to the IPv4 Internet
   through an IPv6-only LTE network.  Port-restricted public IPv4
   addresses are assigned to eNodeBs to remove the NAT functionality on
   the PGW, which helps to offload the processing burden of PGW.  The
   eNodeB is extended to allocate private IPv4 addresses to UEs, as well
   as the private- public IPv4 address translation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 17, 2014.

Copyright Notice

   Copyright (c) 2014 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



Cui & Sun                Expires August 17, 2014                [Page 1]

Internet-Draft              lw4over6 for LTE               February 2014


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  IP Address Configuration on eNodeB  . . . . . . . . . . . . .   4
   6.  The Modification of Nodes . . . . . . . . . . . . . . . . . .   5
   7.  The GTP Tunnel Usage  . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Contributors List . . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Long Term Evolution (LTE) is a standard for wireless communication
   based on 3GPP technologies, providing high-speed data transmission
   for mobile terminals.  LTE's long-term goal is to simplify and
   redesign network architecture, making it an IP network, which helps
   reduce the potential adverse factors in the transformation of 3G.
   "Always online" is one of the goals of LTE system.  The so-called
   "always online" does not mean that each section of connection or
   bearer between UE and the Evolved Packet Core (EPC) network exists at
   any time.  When a UE registers to the network, the network will save
   the user's UE context.  When we initiate the connection to the UE at
   any time, the network can depend on the context to find the UE and
   establish a connection in a short period of time.

   In the scenario that this document describes, IPv4 users access IPv4
   Internet through IPv6 LTE network.  A number of architectural
   solutions have been discussed in the IETF to make whole network
   migrate to IPv6 smoothly.  Many A+P-like solutions, including
   Lightweight 4over6 [I-D.ietf-softwire-lw4over6], have been proposed.
   In this document, we extend Lightweight 4over6 in the LTE network
   environment to transition the whole LTE architecture to IPv6:



Cui & Sun                Expires August 17, 2014                [Page 2]

Internet-Draft              lw4over6 for LTE               February 2014


   allocating IPv4 address + port to eNodeB, using existing LTE GTP
   tunnel and completing the encapsulation and decapsulation in eNodeB
   and PGW.

   Because the LTE network is an All-IP network, eNodeB, SGW and PGW
   have IP network layer.  So that we can extend those nodes to move the
   function of IPv4 address allocation to UE from the PGW to the eNodeB.
   The eNodeB assigns private IPv4 addresses to UEs.  The PGW allocates
   public IPv4 address and port-set to the eNodeB.  When a UE sends IPv4
   packets to the Internet, the private IPv4 address will be translated
   to public IPv4 address at the eNodeB.  The packets are then
   transported to the PGW after GTP tunnel encapsulation.  We maintain
   the mapping between IPv4 address plus port-set and the IPv6 address
   of eNodeB on the PGW.  IPv4 packets from the Internet can find the
   correct eNodeBs by looking up this mapping table, guaranteeing the
   bidirectional exchange between UEs and the Internet.

2.  Requirements Language

   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 [RFC2119].

3.  Terminology

   This document makes use of the following terms:

   UE:                 A User Equipment is a host with the ability to
                       obtain Internet connectivity via a 3GPP network.

   eNodeB:             Evolved NodeB, base station name in LTE, features
                       include: RRM function, IP header compression,
                       user data stream encryption, MME choice in UE
                       attach, etc.

   SGW:                Serving Gateway is a gateway in the EPS, which
                       terminates the interface towards the E-UTRAN.
                       The SGW is the Mobility Anchor point for layer-2
                       mobility (inter-eNodeB handovers).  For each UE
                       connected to the EPS, at any given point in time,
                       there is only one SGW.

   PGW:                Packet Data Network Gateway is the SGi interface
                       that terminates outside data network such as the
                       Internet, IMS, etc.  It is responsible for
                       managing the data routing between 3GPP and non-
                       3GPP, and the mobility between 3GPP access and
                       non-3GPP access (such as WLAN, WiMAX).  It is



Cui & Sun                Expires August 17, 2014                [Page 3]

Internet-Draft              lw4over6 for LTE               February 2014


                       also responsible for DHCP, strategy
                       implementation, billing, etc.

   GTP:                GPRS Tunnelling Protocol is a tunnelling protocol
                       defined by 3GPP.  It is a network-based mobility
                       protocol and is similar to Proxy Mobile IPv6
                       (PMIPv6) [RFC5213].  GTP also provides
                       functionality beyond mobility, such as in-band
                       signaling related to Quality of Service (QoS) and
                       charging, etc.

4.  Architecture Overview

   In this LTE network architecture, eNodeB and UE communicate by air
   interface Uu, SGW communicates with eNodeB and PGW respectively
   through S1 interface and S5 / S8 interface.  Wireless networks under
   SGW use P2P, the network between SGW and PGW uses IP, which is
   managed by operators.  PGW, as a gateway, connects the IP networks of
   operators and the Internet.

   The architecture described here addresses a typical use case, where
   an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this
   eNodeB wants to access IPv4 Internet.  The network architecture is
   shown in Figure 1.  In this scenario, the UE can only use the IPv6
   network to access IPv4 services, so IPv4 services must be configured
   over IPv6.

                                                                  +--------+
                                                                  |   IP   |
                         S1-MME  +-------+  S11                   |Services|
                       +----|----|  MME  |----|----+              +--------+
                       |         |       |         |                  |SGi
                       |         +-------+         |      S5/         |
    +----+    Uu  +-------+ S1-U                +-------+  S8       +-------+
    | UE |----|---|eNodeB |---|-----------------| SGW   |-----|-----|PDN-GW |
    | v4 |        |v4 A+P |------v6 network-----|       |v6 network |       |
    +----+        |-------|=========GTP=========|-------|===GTP=====|-------|


                        Figure 1: LTE Architecture

5.  IP Address Configuration on eNodeB

   The IPv6 network is deployed between eNodeB and PGW.  The eNodeB
   needs to get port-restricted public IPv4 addresses across IPv6
   network.  Currently, there are two ways to assign IPv4 addresses
   across IPv6 network, one is DHCPv4 over DHCPv6
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and the other is the Softwire DHCP



Cui & Sun                Expires August 17, 2014                [Page 4]

Internet-Draft              lw4over6 for LTE               February 2014


   option [I-D.ietf-softwire-map-dhcp].  DHCPv4 over DHCPv6 describes a
   mechanism for obtaining IPv4 configuration information dynamically in
   IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport.
   Softwire DHCP option defines DHCPv6 options to carry IPv4 address and
   port-set.

   After obtaining an IPv6 address, eNodeB can request public IPv4
   address and port-set from the PGW through DHCPv4-over-DHCPv6. eNodeB,
   as DHCP 4o6 client, puts DHCPv4 message in a DHCPv6 option named
   DHCPv4 Message Option, and finds correct SGW to forward to PGW; PGW,
   as the DHCP 4o6 server, extracts the DHCPv4 message from the DHCPv4
   Message Option and deals with the requests.  After processing, PGW
   will forward DHCPv6 message that encapsulates a DHCPv4 message to
   eNodeB.  Two new DHCPv6 messages carrying DHCPv4 messages between the
   client and the server is defined in
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6].  DHCPv4-query is used by client to
   request IPv4 configuration parameters from the server, while
   DHCPv4-response is used to respond to the request of client.
   Figure 2 shows this address configuration procedure.

       +---------------+                     +---------------+
       |    eNodeB     |                     |      PGW      |
       |DHCP 4o6 Client|                     |DHCP 4o6 Server|
       +---------------+                     +---------------+
       |
       |
       |DHCPv4 discover |   DHCPv4-QUERY    | DHCPv4 discover |
       |                |------------------>|                 |
       |DHCPv4 Advertise|  DHCPv4-RESPONSE  | DHCPv4 Advertise|
       |                |<------------------|                 |
       |DHCPv4 Request  |   DHCPv4-QUERY    | DHCPv4 Request  |
       |                |------------------>|                 |
       |DHCPv4 Reply    |  DHCPv4-RESPONSE  | DHCPv4 Reply    |
       |                |<------------------|                 |


                    Figure 2: eNodeB IPv4 configuration

6.  The Modification of Nodes

   When new eNodeB supporting this feature enters the network, it can
   obtain IPv6 address by Stateless Address Auto Configuration(SLAAC),
   and then apply for public IPv4 address and port set.  Now there
   exists a mapping between bearer and IP address on PGW, an IP address
   corresponds to a kind of bearer, and the bearer is identified by GTP
   Tunnel Endpoint ID (TEID).  Each UE's IP packet needs to be
   transported by the corresponding bearer.  Each eNodeB has only a
   port-restricted IPv4 address and an IPv6 address.  When a package



Cui & Sun                Expires August 17, 2014                [Page 5]

Internet-Draft              lw4over6 for LTE               February 2014


   from the IPv4 Internet forwarded to UE wants to find the right
   eNodeB, it needs to identify IPv6 addresses of eNodeB and the bearer
   according to the IPv4 destination address and port.  PGW needs to
   modify their original mapping table from between IPv4 address and
   bearer to among IPv4 address plus port-set, IPv6 address and the
   bearer to determine the correct transmission path.

   In this mechanism, the function of IPv4 address allocation to UE is
   moved from PGW to eNodeB.  Once UE enters a LTE network, it will
   initiate attach procedure to request relational configuration.  In
   EPS bearer establishment process, PGW will send a Create bearer
   response message to UE, which have a null IP segment.  After
   receiving it, eNodeB allocates a private IPv4 address and fills it in
   the null IP segment to build full message and then sends to UE.  When
   completing this process, UE gets IPv4 address and other configuration
   parameters.  This procedure can be shown in Figure 3.  The benefits
   of this mechanism are maintaining UE's original configuration
   process, enabling UE to have no sense of address configuration
   changes.

    +----+  Insert a IPv4 +-------+ Create bearer response msg +-------+
    |    | address in msg |       |   (have null IP segment)   |       |
    | UE |<---------------|eNodeB |<---------------------------|PDN-GW |
    |    |                |       |                            |       |
    +----+                |-------|                            +-------+

                    Figure 3: UE Address Configuration

7.  The GTP Tunnel Usage

   Data transmission between PGW and eNodeB uses GTP tunnel, which is
   encapsulated with IPv6.  When a UE initiates access to the Internet,
   eNodeB translates private IPv4 addresses to appropriate public IPv4
   addresses and port-set, and transports packets through the GTP tunnel
   to PGW for forwarding to the Internet.  When IP packets coming from
   the Internet send to a UE, PGW forwards packets via GTP tunnel to
   correct eNodeB by looking up the mapping table (IPv4 address, port
   set, IPv6 address, TEID).  The eNodeB performs NAT function and sends
   IP packets to UE through the air interface Uu, which completes the
   two-way communications.

   This is quite similar to that in the Lightweight 4over6, which uses
   IPv4-in-IPv6 tunnel.  The difference is the encapsulation structure
   is IP-GTP-IP.  The mechanism this document describes is a combination
   of GTP encapsulation and Lightweight 4over6 (the IPv4 package is
   encapsulated with GTP and then is encapsulated with IPv6), conforming
   the need of IPv6 transition in LTE.




Cui & Sun                Expires August 17, 2014                [Page 6]

Internet-Draft              lw4over6 for LTE               February 2014


8.  Security Considerations

   Section 9 of Lightweight 4over6 [I-D.ietf-softwire-lw4over6] applies
   to this memo.

9.  IANA Considerations

   This memo does not include an IANA request.

10.  Contributors List

   Many thanks to Yuqi Wang and Yan Zhang for their great contributions
   to the draft.

11.  References

11.1.  Normative References

   [I-D.ietf-softwire-lw4over6]
              Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", draft-ietf-softwire-lw4over6-06 (work
              in progress), February 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

11.2.  Informative References

   [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
              Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
              dhcpv4-over-dhcpv6-04 (work in progress), January 2014.

   [I-D.ietf-softwire-map-dhcp]
              Mrugalski, T., Troan, O., Dec, W., Bao, C.,
              leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
              for configuration of Softwire Address and Port Mapped
              Clients", draft-ietf-softwire-map-dhcp-06 (work in
              progress), November 2013.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.




Cui & Sun                Expires August 17, 2014                [Page 7]

Internet-Draft              lw4over6 for LTE               February 2014


Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn


   Qi Sun
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: sunqi@csnet1.cs.tsinghua.edu.cn

































Cui & Sun                Expires August 17, 2014                [Page 8]