Network Working Group D. von Hugo Internet-Draft Deutsche Telekom - Technology Innovation Intended status: Informational B. Sarikaya Expires: November 3, 2017 Huawei T. Herbert Quantonium K. Satish Nokia R. Schott Deutsche Telekom May 2, 2017 5G IP Access Mobility and Session Management Protocols draft-xyx-5gip-ps-00 Abstract This document builds upon 5G IP issues work and - based on a simplified 5G system architecture - attempts to make the case for a possible set of new protocols that need to be developed to be used among various virtualized functions in a 5G network. 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 November 3, 2017. Copyright Notice Copyright (c) 2017 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 von Hugo, et al. Expires November 3, 2017 [Page 1] Internet-Draft 5G IP Problem Statements May 2017 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3 4. Access Management Protocols . . . . . . . . . . . . . . . . 6 5. Mobility Management Protocols . . . . . . . . . . . . . . . . 8 6. Session Management Protocols . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Current networking infrastructure is moving towards a converged common core network serving wireline and wireless access networks to which the end users are connected. Such a network if realized in terms of 5G project being undertaken worldwide is expected to meet the stringent requirements discussed in [I-D.vonhugo-5gangip-ip-issues]. In this document we elaborate upon 5G system architecture which is composed of modularised adaptable network functions of control plane and data plane and their interconnections. Much of this functionality is expected to be implemented as virtualized functions running in central and/or distributed computation environment (cloud) as well as traditional physical entities in parallel. We discuss IP level protocols that need to be developed. The discussion is based on and builds upon our existing documents on mobility management and access management. Identifier Locator Addressing (ILA) protocol is designed as a data plane protocol for task communication and migration in L3 based data center networks [I-D.herbert-nvo3-ila]. ILA can also be used in user mobility. This aspect of ILA is investigated in [I-D.mueller-ila-mobility] by von Hugo, et al. Expires November 3, 2017 [Page 2] Internet-Draft 5G IP Problem Statements May 2017 attempting to apply it directly to 4G 3GPP Evolved Packet System (EPS). Regarding access management, a framework allowing clients and networks in a multi-network scenario to negotiate combination of uplink and downlink paths taking into account client's application needs and network conditions has been developed in [I-D.kanugovi-intarea-mams-protocol]. A control plane protocol for configuring the user plane in a multi access management framework that can be used to flexibly select the combination of uplink and downlink access and core network paths is described in [I-D.zhu-intarea-mams-control-protocol]. A data plane protocol for multiplexing end to end connections is described in [I-D.zhu-intarea-mams-user-protocol] using trailer approach. 2. 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 [RFC2119]. 3. Converged Access-Agnostic Core Network Key principles and concepts in 5G system architecture include separation of User Plane (UP) functions from the Control Plane (CP) functions, allowing independent scalability, evolution, and a flexible deployment at e.g. centralised location or distributed (remote) locations; the concept relies on a new definition of the network functions, e.g. to enable flexible and efficient provision of logically separated network slices. Network slicing with slice instantiations that may include components served by fixed networks is another innovation in 3GPP 5G system architecture as well as the definition of a common core network which is access agnostic. Wherever applicable, procedures (i.e. the set of interactions between network functions) are defined as services, so that their re-use is possible. Each Network Function can interact with the other NF directly if required. The architecture does not preclude the use of an intermediate function to help route control plane messages. On the other hand, the architecture shall be flexible enough to allow for hassle-free introduction of newly specified network services if required by a specific network slice for a prospective new use case. Currently network infrastructure is being transformed into two-layer data center or cloud as Core Network (CN) and the Access Network (AN) which mainly accommodates 5G radio access network on the wireless side and central office on the wireline network closer to the user. This new architecture enables us to flexibly deploy 5G Virtual Network Functions (VNFs) based on the service scenarios. The von Hugo, et al. Expires November 3, 2017 [Page 3] Internet-Draft 5G IP Problem Statements May 2017 division of work in this case is to deploy 5G control plane VNFs and 5G data plane VNFs with related applications in both the central core cloud and distributed local edge clouds. Especially for new ultra low latency services offering vehicular communications a placement of both user data plane functions (e.g. caches or anchors) and corresponding control plane tasks (e.g. activating and monitoring them) near the points of attachment (e.g. road side radio antennas) may be required. These Network Function names as defined in current version of draft 3GPP specifications are given here exemplarily and shall serve for illustrative purposes. The final version of the architecture is still under discussion. 5G system architecture is based on a complete system operation including policy control, authentication, quality of service (QoS), subscriber profiles and charging which are not of interest to us in this document. Based on this abstraction we can simplify the architecture with the elimination of the corresponding network functions and their interconnections. The resulting simplified system architecture is shown in Figure 1. The rectangles are the network functions and the lines are their interconnections. Network Function names are given on the right hand side. +---+ +---+ ________|AMF|-----|SMF| / +---+ +---+ / / / / / / Access and Mobility / / / Function (AMF) / / / Session Management / / / Function (SMF) / / / Data Network, e.g. / / / Internet (DN) +--+ +-----+ +---+ /---\ User Equipment(UE) |UE|-----|(R)AN|--------|UPF|------ | DN | (Radio)Access Network ((R)AN) +--+ +-----+ +---+ \---/ User Plane Function (UPF) Figure 1: Simplified 5G System Architecture Access and Mobility Management Function (AMF) is in charge of registration management, connection management, reachability management, mobility management. It does access authentication and access authorization. Session Management Function (SMF) is in charge of session establishment, modify and release, including tunnel maintenance von Hugo, et al. Expires November 3, 2017 [Page 4] Internet-Draft 5G IP Problem Statements May 2017 between UPF and the access network (AN) node (if applicable). UE IP address allocation and management (incl. optional authorization), selection and control of the user plane (UP), i.e. data plane function. SMF configures traffic steering at UPF to route traffic to proper destination (i.e. the corresponding Data Network, DN); initiator of AN specific SM information, sent via AMF to AN; support for interaction with external DN for transport of signalling for PDU session authorization/authentication by external DN. User Plane Function (UPF) is anchor point for mobility; external PDU session point of interconnect to Data Network; Packet routing and forwarding; Packet inspection and User plane part of Policy rule enforcement; uplink classifier to support routing traffic flows to a data network; branching point to support multi-homed PDU session; transport level packet marking in the uplink and downlink; downlink packet buffering and downlink data notification triggering. The reference points in the original 5G system architecture [TR23.501], [TR23.502] usually carry a specific protocol such as GTP (GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g. over N3) or Non-Access Stratum (NAS) of 3GPP. Access and Mobility Management Function (AMF) is the Network Function (NF) that terminates N1 and N2. User Plane Function (UPF) is the NF that terminates N3. N1 which is the reference point between UE and AMF represents interactions going over (R)AN but these interactions are transparently relayed by (R)AN. That is the difference between N1 and N2 which is the reference point between (R)AN and AMF. According to 5G architecture, 5G UE is expected to use Non-Access Stratum (as opposed to Access-Stratum (AS) which is used between access network and UE) signaling for establishment of communication sessions and for maintaining continuous communications with the user equipment as it moves in 5G core network even when UE is connected to 5G core network via a non-3GPP access network, e.g. over Wi-Fi, oftentimes simultaneously to the wireless radio access network (RAN). Some of the procedures for the 5G system being defined in [TR23.502] are to be used in establishing an IP link, like Non-Access Stratum signaling. Such link layer aspects of 5G System Architecture are out of scope. In the simplified 5G system architecture, our interest in this document is to use IETF protocols in the interconnection points shown in Figure 1. The goals of the work will involve: o Align with the identifier usage, e.g. 64-bit identifier for UE, e.g. International Mobile Subscriber Identity (IMSI) von Hugo, et al. Expires November 3, 2017 [Page 5] Internet-Draft 5G IP Problem Statements May 2017 o Adopt the same network functions, e.g. Access and mobility Management Function, Session Management Function (SMF), User Plane Function (UPF) o Address multiple access issue in the access management and also session management o Adopt the identifier locator addressing protocol which does not involve tunneling for mobility management o Define address allocation function of the session management as part of the mobility management protocol o Define session and service continuity as part of the session management One of the challenges in 5G FMC is how to provide seamless mobility when 5G UE while in a 5G radio access network later moves to an area of served by a Wi-Fi access point connected to a central office within the fixed network while both access networks are served by a converged common core. Another challenge is to enable flexible and seamless management of the user sessions while accessing the network sometimes simultaneously over UE's multiple interfaces, e.g. 5G and Wi-Fi. In the next sections, we discuss access (Section 4) and mobility (Section 5) and session (Section 6) management protocols that need to be developed in order to satisfy the key features and requirements of the upcoming 5G networks described in [I-D.vonhugo-5gangip-ip-issues]. These protocols will be defined to be potentially used in the interconnections of the virtualized network functions shown in Figure 1. 4. Access Management Protocols An investigation of multiple access management for a UE that simultaneously connects to multiple data networks is presented in [I-D.kanugovi-intarea-mams-protocol]. [I-D.kanugovi-intarea-mams-protocol] sets forward the requirements such as enabling connectivity using different access networks. The network path selection and user data distribution should work transparently. Access path selection should be independent for Uplink and Downlink. A common core network independent of the access networks should be accessed by the UE. Network path selection should be adaptive to the link quality. Distribution and aggregation of user data across multiple network paths at the IP layer should be von Hugo, et al. Expires November 3, 2017 [Page 6] Internet-Draft 5G IP Problem Statements May 2017 supported. Heterogeneous access networks, which may have different MTU sizes should be supported using concatenation and fragmentation. Based on these requirements, control and data plane functions for connection management can be determined. Network Connection Manager (NCM) is the control plane function. There is a data plane component for user data traffic forwarding called Network Multi-Access Data Proxy (MADP) which is part of the User Plane Function (UPF) in Figure 1. It can be argued that we also need corresponding client side counter part of NCM, called CCM and MADP hosted on the UE. Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the core network handles the user data traffic forwarding across multiple network paths, as well as other user-plane functionalities, e.g. encapsulation, fragmentation, concatenation, reordering, retransmission, etc. N-MADP is the distribution node for uplink and downlink data with visibility of packets at the IP layer. Network Connection Manager (NCM) in the core network configures identification and distribution rules for different user data traffic type at the N-MADP. The NCM configures the routing in the MADP based on signaling exchanged with the CCM in UE. In the uplink, NCM specifies the core network path to be used by MADP to route uplink user data at the MADP. In the downlink, NCM specifies the access links to be used for delivery of data to the client at the MADP. At the UE, MADP handles encapsulation, fragmentation, concatenation, reordering, retransmissions, etc. C-MADP is configured by CCM based on signaling exchange with NCM and local policies at the UE. At the UE, CCM manages the multiple network connections. CCM is responsible for exchange of MAMS signaling messages with the NCM for supporting functions like configuring uplink and downlink user network paths for transporting user data packets, link sounding and reporting to support adaptive network path selection by NCM. In the downlink, for the user data received by UE, it configures IP layer forwarding for application data packets received over any of the accesses to reach the appropriate application module on the client. In the uplink, for the data transmitted by UE, it configures the routing table to determine the best access to be used for uplink data based on a combination of local policy and network policy delivered by the NCM. IP level protocols need to be developed supporting connection management in a 5G IP network. An example is the trailer based approach integrating multiple connections into a single end to end IP connection. A multiplexing trailer is added to the end of IP payload to flexibly support concatenation and fragmentation. von Hugo, et al. Expires November 3, 2017 [Page 7] Internet-Draft 5G IP Problem Statements May 2017 [I-D.zhu-intarea-mams-user-protocol] gives an earlier 4G approach, there could possibly be other similar approaches. 5. Mobility Management Protocols Next, we discuss mobility management. Anchor-less mobility in a 5G fixed mobile convergence network with a converged core network possibly based on identifier and locator separation should be the preferred approach as opposed to tunneling approaches with fixed anchors, e.g. or with distributed anchors. The prospective approach is to overcome tunneling and encapsulation overhead explained in detail in [I-D.vonhugo-5gangip-ip-issues] by simplified routing in the edge network according to identifiers not bound to locations and thus allowing for relocation within underlying infrastructure. Such an approach should also incorporate session management in support of session and service continuity in the 5G architecture with a common core enabling mobility in multiple access networks. Anchor points perform important duties such as policy, accounting etc. as well as mapping that cannot be ignored. In anchor-less mobility, without anchor points, UE is the only common device in the path to perform these functions. When anchors are removed then it becomes a challenge to provide functions like security and trust. One option is to use the UE as the only remaining single anchor point to perform its own accounting and policy and other functions. There are secure execution environments/processors in UE's these days, where all the finger print recognition, password encryption etc. is done and perhaps it is possible to extend these to run secure network functions on behalf of the slices. However, a trusted federation between any UE and the corresponding/accessible network entities cannot be assumed without doubt in any case. In view of this, virtualizing and distributing anchor point functions, e.g. mapping identifiers to the most recent locators, security associations (SA), etc. so they can run in the network at the points of attachment close to the UE will need to be investigated. Transport protocol level independence is a strong requirement in identifier locator separation based mobility protocols. This means that UE can have a locator or address but it should not be used as connection end point. The identifier which may not be routable should be used as the connection end point. This enables no modifications at the transport layer in the host stack. Based on the requirements, Identifier Locator Addressing (ILA) protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base von Hugo, et al. Expires November 3, 2017 [Page 8] Internet-Draft 5G IP Problem Statements May 2017 protocol. IPv6 operation in the current ILA need to be improved in order to be used by the end nodes such as the UEs. Mobility procedures in the control plane need to be defined. ILA design is influenced by UE prefix/address allocation and management which is part of Session Management function. Therefore the two functions need to be designed in an integrated fashion. Multihoming, UEs with more than one network interfaces should be supported including simultaneous usage of the interfaces to connect to multiple access networks. ILNP [RFC6740] supports multihoming. ILA support could be similarly designed. 6. Session Management Protocols Session management responsible for the setup of the connectivity for the UE as well as managing the user plane for that connectivity is identified as one of the key issues in 5G system architecture in [TR23.799]. Session management design issues include managing multiple access, multiple connectivity, multiple transport paths, e.g. to RAN and to non-3GPP access network (AN), sometimes simultaneously and how to efficiently transmit and receive infrequent small amounts of data and short data bursts, e.g. for Narrow Band Internet of Things (NB-IoT). The challenges of this kind of session management design include if such a design can be simplified so that NB-IoT type of very simple sessions can also be handled. Regarding SMF and AMF, identifying the correlation between session management and mobility management, identifying the interactions between session management and the mobility framework required to enable the various mobility scenarios while minimizing any negative impact on the user experience investigating solutions to coordinate the relocation of user-plane flows with the relocation of applications (hosted close to the point of attachment of the UE) due to the mobility of users can be considered as the challenges of 5G architecture. Network layer or IP session normally has two components: source IP address and destination IP address. In case identifier locator separation protocol is used IP session has four components source locator, source identifier, destination locator and destination identifier. With transport layer independence IP session should be composed of source identifier and destination identifier only. Session management deals with IP address management. SMF performs IP address allocation. Both IPv4 and IPv6 should be supported. In an identifier locator separation system, IPv4 can be supported transparently by keeping the communication in IPv6 and converting the addresses at the end points. von Hugo, et al. Expires November 3, 2017 [Page 9] Internet-Draft 5G IP Problem Statements May 2017 Session continuity in the case of UE mobility should be provided. In an anchorless system, UE mobility incurs changes to the locators. Session management should maintain the established sessions when the UE moves. This also involves informing the destinations of the locator change. This is done in the control plane of the mobility management. 7. IANA Considerations None. 8. Security Considerations Security considerations related to the 5G systems are discussed in [NGMN]. Due to the request for intrinsic realization of security such aspects have to be considered by design for architecture and protocols. Especially as a joint usage of resources and network functions by different separate logical network slices (e.g. in terms of virtual network functions) seems to be inevitable in the framework of 5G the need for strong security measures in such an environment is a major challenge. 9. Privacy Considerations Support of full privacy of the users (customers and tenants / end service providers) is a basic feature of the next generation trusted and reliable communications offering system. Such a high degree of ensured privacy shall be reflected in the proposed architecture and protocol solutions (details have to be added). Especially as Identifiers and mapping of locators to them are addressed the discussion on identifier and privacy should consider existing solutions such as 3GPP Globally Unique Temporary UE Identity (GUTI) which is a temporary identity obfuscating the permanent identity in the mobile network and specified in [TS23.003]. 10. Acknowledgements This work has been partially performed in the framework of the cooperation Config. Contributions of the project partners are gratefully acknowledged. The project consortium is not liable for any use that may be made of any of the information contained therein. von Hugo, et al. Expires November 3, 2017 [Page 10] Internet-Draft 5G IP Problem Statements May 2017 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11.2. Informative References [I-D.arkko-ietf-trends-and-observations] Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O., olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R. White, "IETF Trends and Observations", draft-arkko-ietf- trends-and-observations-00 (work in progress), February 2016. [I-D.farinacci-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in progress), November 2016. [I-D.herbert-nvo3-ila] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", draft-herbert-nvo3-ila-04 (work in progress), March 2017. [I-D.ietf-dmm-4283mnids] Perkins, C. and V. Devarapalli, "MN Identifier Types for RFC 4283 Mobile Node Identifier Option", draft-ietf-dmm- 4283mnids-04 (work in progress), January 2017. [I-D.kanugovi-intarea-mams-protocol] Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng, S., Mueller, J., and S. Seo, "Multiple Access Management Services", draft-kanugovi-intarea-mams-protocol-04 (work in progress), March 2017. [I-D.mueller-ila-mobility] Mueller, J. and T. Herbert, "Mobility Management Using Identifier Locator Addressing", draft-mueller-ila- mobility-03 (work in progress), February 2017. von Hugo, et al. Expires November 3, 2017 [Page 11] Internet-Draft 5G IP Problem Statements May 2017 [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-02 (work in progress), April 2017. [I-D.vonhugo-5gangip-ip-issues] Hugo, D. and B. Sarikaya, "Review on issues in discussion of next generation converged networks (5G) from an IP point of view", draft-vonhugo-5gangip-ip-issues-03 (work in progress), March 2017. [I-D.zhu-intarea-mams-control-protocol] Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng, S., and S. Seo, "Control Plane Protocols and Procedures for Multiple Access Management Services", draft-zhu- intarea-mams-control-protocol-01 (work in progress), March 2017. [I-D.zhu-intarea-mams-user-protocol] Zhu, J. and S. Seo, "User-Plane Protocols for Multiple Access Management Service", draft-zhu-intarea-mams-user- protocol-01 (work in progress), March 2017. [M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and overall objectives of the future development of IMT for 2020 and beyond", September 2015. [METIS] Elayoubi, S. and et al., "5G Service Requirements and Operational Use Cases: Analysis and METIS II Vision", Proc. euCNC, 2016. [NGMN] NGMN Alliance, "NGMN White Paper", February 2015. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . von Hugo, et al. Expires November 3, 2017 [Page 12] Internet-Draft 5G IP Problem Statements May 2017 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, . [TR23.501] "3GPP TR23.501, System Architecture for the 5G System (Release 15)", December 2017. [TR23.502] "3GPP TR23.502, Procedures for the 5G System (Release 15)", December 2017. [TR23.799] "3GPP TR23.799, Study on Architecture for Next Generation System (Release 14)", December 2016. [TS23.003] "3GPP TS23.003, Numbering, addressing and identification (Release 14)", September 2016. Authors' Addresses Dirk von Hugo Deutsche Telekom - Technology Innovation Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org von Hugo, et al. Expires November 3, 2017 [Page 13] Internet-Draft 5G IP Problem Statements May 2017 Tom Herbert Quantonium Email: tom@herbertland.com K Satish Nokia Email: satish.k@nokia.com Roland Schott Deutsche Telekom Email: roland.schott@telekom.de von Hugo, et al. Expires November 3, 2017 [Page 14]