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]