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]
