Internet DRAFT - draft-jeongyun-spring-mobility-use-cases
draft-jeongyun-spring-mobility-use-cases
Network Working Group J. Kim
Internet Draft ETRI
Intended status: Informational January 13, 2015
Expires: July 2015
SPRING Use cases for IP Flow Mobility
draft-jeongyun-spring-mobility-use-cases-01
Abstract
The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed'.
The objective of this document is to illustrate some use cases that
need to be taken into account by the Source Packet Routing in
Networking (SPRING) architecture.
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), 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Kim Expires July 13, 2015 [Page 1]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
This Internet-Draft will expire on July 13,, 2015.
Copyright Notice
Copyright (c) 2015 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 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.
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 to this document.
Kim Expires July 13, 2015 [Page 2]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
Table of Contents
1. Introduction ................................................ 4
1.1. Terminology and abbreviations ........................... 4
2. Mobile network overview ...................................... 5
2.1. Building blocks of 3GPP mobile networks ................. 6
3. Use case .................................................... 8
3.1. High level use case ..................................... 8
3.2. SPRING use case........................................ 10
4. Security Considerations ..................................... 12
5. IANA Considerations ........................................ 12
6. References ................................................. 12
6.1. Normative References ................................... 12
6.2. Informative References ................................. 12
7. Acknowledgments ............................................ 13
Kim Expires July 13, 2015 [Page 3]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
1. Introduction
Source Packet Routing in Networking (SPRING) architecture leverages
the source routing paradigm. An ingress node steers a packet through
a controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can represent a local
semantic on the SPRING node, or a global semantic within the SPRING
domain. SPRING allows one to enforce a flow through any topological
path and service chain while maintaining per-flow state only at the
ingress node to the SPRING domain.
The SPRING architecture is described in [I-D.filsfils-rtgwg-segment-
routing]. The SPRING control plane is agnostic to the dataplane,
thus it can be applied to both MPLS and IPv6. In case of MPLS the
(list of) segment identifiers are carried in the MPLS label stack,
while for the IPv6 dataplane, a new type of routing extension header
is required.
The scope of this document is to study the use cases for UEs with
multiple interfaces which will simultaneously connect to 3GPP access
and non-3GPP WLAN access. In this use cases, the forwarding paths
can be explicitly specified by taking into account the Source Packet
Routing in Networking (SPRING) architecture.
1.1. Terminology and abbreviations
Much of the terminology used in this document has been defined by
the 3rd Generation Partnership Project (3GPP), which defines
standards for mobile service provider networks. Although a few terms
are defined here for convenience, further terms can be found in
[RFC6459].
AS Access Switch
AR Aggregation Router
CE Customer Edge Router
ER Edge Router
UE User equipment like tablets or smartphones
eNB enhanced NodeB, radio access part of the LTE system
Kim Expires July 13, 2015 [Page 4]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
S-GW Serving Gateway, primary function is user plane mobility
P-GW Packet Gateway, actual service creation point, terminates 3GPP
mobile network, interface to Packet Data Networks (PDN)
PE Provider Edge Router
HSS Home Subscriber System (control plane element)
MME Mobility Management Entity (control plane element)
GTP GPRS (General Packet Radio Service) Tunnel Protocol
S-IP Source IP address
D-IP Destination IP address
IMSI The International Mobile Subscriber Identity that identifies a
mobile subscriber
(S)Gi Egress termination point of the mobile network (SGi in case of
LTE, Gi in case of UMTS/HSPA). The internal data structure of this
interface is not standardized by 3GPP
PCRF 3GPP standardized Policy and Charging Rules Function
2. Mobile network overview
For simplicity we only describe IP flow mobility in the context of
LTE (Long Term Evolution), which aims to provide seamless Internet
Protocol (IP) connectivity between user equipment (UE) and the
packet data network (PDN). But indeed IP flow mobility also applies
to earlier generations of mobile networks, such as purely UMTS-based
mobile networks.
An IP packet for a UE is encapsulated in an EPC-specific protocol
and tunneled between the P-GW and the eNodeB for transmission to the
UE. Different tunneling protocols are used across different
interfaces. A 3GPP-specific tunneling protocol called the GPRS
Tunneling Protocol (GTP) is used over the CN interfaces, S1 and
S5/S8.
Kim Expires July 13, 2015 [Page 5]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
2.1. Building blocks of 3GPP mobile networks
The major functional components of a LTE network are shown in Figure
2 and include user equipment (UE) like smartphones or tablets, the
LTE radio unit named enhanced NodeB (eNB), the serving gateway (S-
GW) which together with the mobility management entity (MME) takes
care of mobility and the packet gateway (P-GW), which finally
terminates the actual mobile service. These elements are described
in detail in [TS.23.401]. Other important components are the home
subscriber system (HSS) and the policy and charging rule function
(PCRF), which are described in [TS.23.203]. The P-GW interface
towards the SGi-LAN is called the SGi-interface, which is described
in [TS.29.061]. Finally, the SGi-LAN is the home of service function
chains (SFC), which are not standardized by 3GPP.
The radio-based IP traffic between the UE and the eNB is encrypted
according 3GPP standards. Between the eNB, S-GW, and P-GW user plane
IP packets are encapsulated in 3GPP-specific tunnels. In some mobile
carrier networks the 3GPP specific tunnels between eNB and S-GW are
even additionally IPSec-encrypted. More precisely, IPSec
originates/terminates at the eNB and on the other side at an IPSec-
GW often placed just in front of the S-GW. For more details see
[TS.29.281], [TS.29.274] and [TS.33.210].
+----------------------------------------+
| Mobile Network [HSS] | [OTT Appl. Platform]
| | | |
| +--------- [MME] [PCRF]-----+--------+ |
| | | | | | |
| + [S-GW] [P-GW] | | Internet
| | | | | | |
| [UE] -- [eNB] +------+ | | |
| | | | | |
+===========|===================|========+ +-----+-----+-------+
| | | | | |
| [AS] - [AR(PE)] == [ER(PE)] == +--+----[SGi-LAN] |
| | | | |
| | | | |
| | | [Appl. Platform] |
| IP Network | | |
+----------------------------------------+ +-------------------+
Figure 1 Mobile and IP network in case of 3GPP access
Kim Expires July 13, 2015 [Page 6]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
Mobile network consists of some LTE components in 3GPP access and GTP
connections between eNB and S-GW, and between S-GW and P-GW are
established, as shown in Figure 1. The LTE components are connected to
MPLS components such as AS, AR and ER in IP network. The interactions
between LTE components occur through MPLS components.
+----------------------------------------+
| Mobile Network [HSS] | [OTT Appl. Platform]
| | | |
| +--------- [AAA] [PCRF]-----+--------+ |
| | | | | | |
| + [ePDG] [P-GW] | | Internet
| | | | | | |
| [UE] -- [AP/APC] +------+ | | |
| | | | | |
+===========|===================|========+ +-----+-----+-------+
| | | | | |
| [AS] - [AR(PE)] == [ER(PE)] == +--+----[SGi-LAN] |
| | | | |
| | | | |
| | | [Appl. Platform] |
| IP Network | | |
+----------------------------------------+ +-------------------+
Figure 2 Mobile and IP network in case of Non-3GPP access
Mobile network consists of some LTE components in non-3GPP access
(WLAN) and GTP connections or IPsec between AP/APC and ePDG, and
between ePDG and P-GW are established, as shown in Figure 2. The WLAN
components are connected to MPLS components such as AS, AR and ER in IP
network. The interactions between WLAN components occur through MPLS
components.
Kim Expires July 13, 2015 [Page 7]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
3. Use case
With an explosive increase of data traffic, cellular networks are
likely to be operating at their capacity limits and hence. Data
offload is regarded as one of solutions that can avoid overload and
improve the overall end user experience by redirection.
3.1. High level use case
This sub-clause describes a use case where the UE is connected to
the EPS via different accesses simultaneously, sending and receiving
different IP flows through different accesses.
Michael is in an outdoor area and the 3GPP accesses are only
available. Michael is accessing different services with different
characteristics in terms of QoS requirements and bandwidth:
- a Video Telephony call: IP Flow 1 and 5
- a p2p download: IP Flow 2
- a media file synchronization (e.g. a podcast and downloading of a
TV series): IP Flow 3
- a non-conversational video streaming (e.g. IPTV): IP Flow 4
The scenario is depicted in Figure 3.
Kim Expires July 13, 2015 [Page 8]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
+----------------------+ +-----------------------+
| 3GPP Access | | EPC/WLAN |
| | | |
| | | |
| +-----------|----|-----------------------|----IP Flow 1
| | +---------|----|-----------------------|----IP Flow 2
| | | +-------|----|-----------------------|----IP Flow 3
| | | | +-----|----|-----------------------|----IP Flow 4
| | | | | +---|----|-----------------------|----IP Flow 5
| | | | | | | | |
| +--------+ | | |
+===============| UE | | | |
| +--------+ | | |
| |----+ | |
| | | |
| | | |
| | | |
| Non-3GPP Access | | |
+======================+ +-----------------------+
Figure 3 Routing of different IP flows through 3GPP access
After a while Michael comes back home where both 3GPP access and a
trusted or untrusted non-3GPP access are available. As an example,
the non-3GPP access may be a domestic WiFi hotspot. Some of these
flows may be from the same application (e.g. the Video Telephony may
be via a virtual private network tunnel). Based on operator's
policies, the user's preferences and the characteristics of the
application and the accesses, the IP flows are routed differently;
as an example, the audio media (conversational voice) of the VT call
and the video streaming are routed via 3GPP access, while the video
media (conversational video (live streaming)) of the VT, the p2p
download (best effort) and media file synchronization are routed
through the non-3GPP access. The scenario is depicted in Figure 4.
Kim Expires July 13, 2015 [Page 9]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
+----------------------+ +-----------------------+
| 3GPP Access | | EPC/WLAN |
| | | |
| | | |
| | | |
| | | |
| | | |
| +-----|----|-----------------------|----IP Flow 4
| | +---|----|-----------------------|----IP Flow 5
| | | | | |
| +--------+ | | |
+===============| UE | | | |
| +--------+ | | |
| | | | |----+ | |
| | | +-|---------|-----------------------|----IP Flow 1
| | +---|---------|-----------------------|----IP Flow 2
| +-----|---------|-----------------------|----IP Flow 3
| Non-3GPP Access | | |
+======================+ +-----------------------+
Figure 4 Routing of different IP flows through different accesses
3.2. SPRING use case
Devices with multiple wireless interfaces (e.g. 3GPP, WLAN, etc.)
are becoming commonly available and the set of applications running
in the mobile devices is diversifying with some applications suited
to run over 3GPP access systems and other applications well suited
to run over non-3GPP WLAN access systems. It is called IP flow
mobility to allow a telecom operator to seamlessly and selectively
switch over a single IP flow (e.g., user application) to a different
radio access, while keeping all other ongoing connections for this
and the rest of the users on both radio accesses untouched. However
IP flow mobility (e.g., traffic redirection) always introduces some
kind of delay, due to processing, forwarding, and the difference in
round-trip time (RTT) between the different accesses.
With segment routing, the paths between PEs that connect LTE
components (e.g., eNB and S-GE, AP/APC and ePDG, S-GE and P-GW, and
ePDG and P-GW) can be explicitly specified instead of RSVP or LDP.
When data over 3GPP access are redirected to non-3GPP access, the
path of data over non-3GPP access can be specified in the similar
way of data over 3GPP access in order to reduce the redirection
Kim Expires July 13, 2015 [Page 10]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
delay. When the PEs connecting the relevant LTE components is same,
then the paths can be exactly same. Therefore redirection delay
could be significantly reduced.
In order to more clearly explain use cases of IP flow mobility, two
cases are assumed that (i) Segment routing when mobile (e.g., LTE,
WiFi) nodes are connected to the same transport node, (ii) Segment
routing when mobile nodes are connected to different transport nodes.
In first use case, both S-GW and ePDG (CE1 and CE2, respectively)
are connected to the same router (PE1) and P-GW (CE3) is connected
to a router (PE3). There are two alternative paths between PE1 and
PE2, as shown in Figure 5. When an UE is connected to a Web server
through LTE access, it is assumed both S-GW and P-GW communicate
each other via the path using a segment list (PE1-A-B-F-E-PE3).
After moving into home when a part of IP flows could hand-over from
LTE to WiFi access, once again the path can be used for WiFi access
that both ePDG and P-GW communicate each other. Therefore the path
establishment for WiFi access could be skipped even though pairs of
LTE nodes are different.
+-C---D-+
| |
CE1--PE1--A--B---F---E--PE3--CE3
/
CE2
Figure 5 Segment routing when mobile nodes are connected to the same
transport node
In second use case, both S-GW and ePDG (CE1 and CE2, respectively)
are connected to different routers (PE1 and PE2, respectively).
There are two alternative paths between PE1, PE2 and PE3 as shown in
Figure 6. Comparing to first use case, node A could be a branch to
forward packets to either PE1 or PE2 according to their destination
(CE1 or CE2 respectively). In this case, the most part of the
segment list (A-B-F-E-PE3) could be used for both accesses.
Therefore the paths for both accesses would traverse different node
connecting different mobile nodes except common segment list. It
could quite reduce effort to establish paths whenever IP flow
mobility happens.
Kim Expires July 13, 2015 [Page 11]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
+-C---D-+
| |
CE1--PE1--A--B---F---E--PE3--CE3
/
CE2--PE2-
Figure 6 Segment routing when mobile nodes are connected to
different transport nodes
4. Security Considerations
TBD
5. IANA Considerations
TBD
6. References
6.1. Normative References
None
6.2. Informative References
[TR.23.816]
"Network based IP flow mobility", 3GPP TR 23.816, July 2014.
[TS.23.401]
Kim Expires July 13, 2015 [Page 12]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
"General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network (E-
UTRAN) access", 3GPP TS 23.401 12.3.0, December 2013.
[TS. 29.061]
"Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN)", 3GPP TS 29.061 12.4.0, December 2013.
[TS. 29.274]
"3GPP Evolved Packet System (EPS); Evolved General Packet
Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3", 3GPP TS 29.274 12.3.0, December 2013.
[TS.29.281]
"General Packet Radio System (GPRS) Tunnelling Protocol
User Plane (GTPv1-U)", 3GPP TS 29.281 11.6.0, March 2013.
[draft-ietf-sfc-use-case-mobility]
W. Haeffner, J. Napper, M. Stiemerling, D. Lopez and J.
Uttaro, "Service Function Chaining Use Cases in Mobile
Networks", draft-ietf-sfc-use-case-mobility-01, July 2014.
[draft-ietf-spring-problem-statement]
S. Previdi, C. Filsfils, B. Decraene, S. Litkowski, R.
Geib, R. Shakir and R. Raszuk, "SPRING Problem Statement
and Requirements", draft-ietf-spring-problem-statement-01,
June 2014.
7. Acknowledgments
TBD
Kim Expires July 13, 2015 [Page 13]
Internet-Draft SPRING Use cases for IP Flow Mobility January 2015
Authors' Addresses
Jeongyun Kim (editor)
ETRI
218 Gajeong-ro, Yuseong-gu, Daejeon, 305-700, KR
Email: jykim@etri.re.kr
Kim Expires July 13, 2015 [Page 14]
