Network Working Group D. von Hugo Internet-Draft Deutsche Telekom Intended status: Informational B. Sarikaya Expires: July 10, 2018 Huawei S. Bhatti University of St. Andrews M. Liebsch NEC R. Schott Deutsche Telekom S. Seo Korea Telekom January 10, 2018 Access Technology Independent Connectivity and Mobility Control Problem Statement draft-hsblss-attic-ps-01 Abstract This document attempts to make the case for new work involving possibly a framework and protocols that need to be developed to be used among various virtualized functions and the end user which may be moving. First a set of functional requirements are developed and then these requirements are further elaborated in terms of potential engineering and design constraints. The need for the new work is described next. 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 July 10, 2018. von Hugo, et al. Expires July 10, 2018 [Page 1] Internet-Draft ATTIC Problem Statement January 2018 Copyright Notice Copyright (c) 2018 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3 4. Functional Requirements . . . . . . . . . . . . . . . . . . . 4 5. Non-Functional Requirements . . . . . . . . . . . . . . . . . 4 6. IP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 (see e.g. [METIS]). Such a network if realized in terms of 5G projects being undertaken worldwide is expected to meet the stringent requirements discussed in [I-D.vonhugo-5gangip-ip-issues]. In this document a system architecture which is composed of modularised adaptable network functions of control plane and data plane and their interconnections is assumed. 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. von Hugo, et al. Expires July 10, 2018 [Page 2] Internet-Draft ATTIC Problem Statement July 2018 The system architecture we consider brings new set of functional requirements that need to be considered in developing new protocols as well as potential engineering and design constraints which we will elaborate in this document. The protocol discussion is based on and builds upon existing documents on access technology independent connectivity and mobility handling. Identifier Locator Network Protocol (ILNP) is designed as a data plane protocol based on identifier locator separation principle for end user mobility with no tunneling [RFC6740]. ILNP has control plane components defined using DNS [RFC6742] and ICMPv6 [RFC6743]. 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's applicability has been investigated in [I-D.mueller-ila-mobility] by attempting to apply it directly to 4G 3GPP Evolved Packet System (EPS). 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 next generation 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. Wherever applicable, procedures (i.e. the set of interactions between network functions) are defined as services, so that their re-use is possible. The principles include being access independent and allowing efficient multiple access. Each Network Function (NF) 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. 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 wireless access network and wireline access network closer to the user. von Hugo, et al. Expires July 10, 2018 [Page 3] Internet-Draft ATTIC Problem Statement July 2018 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. As major control plane functionalities in such a core network the handling of network access management including consideration of user mobility, measures for providing session continuity as well as accounting for security and authentication has been identified. Data plane functions for packet routing and forwarding accordingly have to be present also. 4. Functional Requirements The new system architecture brings a set of functional requirements which will be set forward in this section. o Harmonised and seamless capability, i.e. one protocol / protocol- suite that provides all the functionality listed below together, and without disruption to end-to-end connectivity. o Mobility for hosts / end-systems. o Mobility for networks / sites / routers. o Multi-homing for hosts / end-systems, including support for multi- path transport. o Multi-homing for networks / sites / routers. o Support for network virtualisation / network partitioning. 5. Non-Functional Requirements Next, we discuss non-functional requirements involving potential engineering design constraints. They arise mainly from the need to increase resource usage efficiency by reducing signalling overhead and allowing for traffic shaping according to capacity availability. o No use of tunnels, either layer 2 or layer 3. o No use of middle boxes, i.e. no proxies. 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 von Hugo, et al. Expires July 10, 2018 [Page 4] Internet-Draft ATTIC Problem Statement July 2018 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. Such an approach however may create further implications to network operators which to our knowledge have not yet been dealt with. o Support for end-to-end privacy and security. 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. 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. o Flexible addressing / numbering, e.g. distinguishing between globalised addressing as well as localised addressing. o An end-to-end model (in support to the above four requirements). o Support for current IPv6 addressing, e.g. /64 prefix assignment. o Support for Identifier-Locator separation, e.g. as discussed in [RFC6115]. o Ability to use for mapping between identifiers and addresses an existing name resolution system (e.g. DNS), but also to make use of new/future systems, e.g. Dynamic Hash Tables (DHT) [RFC7363]. o Backwards compatibility for existing applications, e.g. support of socket API so that binaries do not need to be recompiled. o Incremental deployment, e.g. only need to update those hosts that require new capability (this implies mixed operation, possibly dual-stack, within a network). 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 accessible by the UE. Network path selection should be adaptive to the link quality implications to match with service specific performance requirements. Distribution and aggregation of user data across multiple network paths at the IP layer should be supported. von Hugo, et al. Expires July 10, 2018 [Page 5] Internet-Draft ATTIC Problem Statement July 2018 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 instead. This enables that no modifications at the transport layer in the host stack are required. However, using current IPv6 addressing, it seems transport protocol level independence can not be achieved without possibly simple code modifications in widely used transport protocol software. In view of the required capability of incremental deployment this issue should be solvable. Regarding incremental deployment, legacy nodes will exist in the network especially in terms of the server nodes. How to support such legacy nodes will need to be investigated. 6. IP Sessions 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, i.e. 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 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. Enabling 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. 7. Goals From the requirements set forward above we will derive the goals that need to be achieved. 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) as well as IPv6 prefix usage, single or multiple unique /64 prefixes von Hugo, et al. Expires July 10, 2018 [Page 6] Internet-Draft ATTIC Problem Statement July 2018 o Propose solution approaches to deal with operational problems such as charging or policy and QoS enforcement in a framework not relying on tunneling and the information in tunnel headers o Develop a framework involving mobility management without tunneling, IP sessions for session continuity, handoff improvements, support for virtual network identifiers to be used by virtualized network functions in data centers, and support for legacy servers o Define a version of the protocol that supports data center execution for intercommunication among control plane virtualized network functions o Define control plane improvements to enable fast intertechnology handoffs o Define proxy node behavior to enable legacy nodes 8. IANA Considerations None. 9. Security Considerations Various white papers exist that discuss security considerations related to the next generation systems, e.g. [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 virtual network functions seems to be inevitable in the framework of next generation systems outlined in this document the need for strong security measures in such an environment is a major challenge. 10. 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. Especially as Identifiers and mapping of Locators to them are addressed some privacy concerns arise. Mobility solutions tend to expose unique identifiers. A solution inside the mobile network exposes these identifiers to the network operator, which is not a big von Hugo, et al. Expires July 10, 2018 [Page 7] Internet-Draft ATTIC Problem Statement July 2018 deal since the network operator already has information about the device's location. In contrast, an IP level solution exposes both the identifiers and the locations at the IP layer. That means that web sites, for example, can now track the device's successive locations by watching the IP address. Solutions such as transporting the identifiers not as part of the IP header should be considered, e.g. in the handling of legacy hosts. 11. 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. Comments, constructive criticisms in general on this work (including previous versions) from Christian Huitema, Cameron Bynes, Lorenzo Colitti, Mikael Abrahamsson, David Lake, Samita Chakrabarti, Jouni Korhonen, Zhu Jing are respectfully acknowledged. 12. References 12.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, . 12.2. Informative References [I-D.herbert-nvo3-ila] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", draft-herbert-intarea-ila-00 (work in progress), October 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. [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. von Hugo, et al. Expires July 10, 2018 [Page 8] Internet-Draft ATTIC Problem Statement July 2018 [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. [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, DOI 10.17487/RFC6115, February 2011, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6742] Atkinson, RJ., Bhatti, SN., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, DOI 10.17487/RFC6742, November 2012, . [RFC6743] Atkinson, RJ. and SN. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012, . [RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014, . Authors' Addresses Dirk von Hugo Deutsche Telekom Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de von Hugo, et al. Expires July 10, 2018 [Page 9] Internet-Draft ATTIC Problem Statement July 2018 Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Saleem Bhatti University of St. Andrews Email: saleem@st-andrews.ac.uk Marco Liebsch NEC Email: marco.liebsch@neclab.eu Roland Schott Deutsche Telekom Email: roland.schott@telekom.de SungHoon Seo Korea Telekom Email: sh.seo@kt.com von Hugo, et al. Expires July 10, 2018 [Page 10]