dmm K. Bogineni Internet-Draft Verizon Intended status: Informational A. Akhavain Expires: December 31, 2018 Huawei Canada Research Centre T. Herbert Quantonium D. Farinacci lispers.net A. Rodriguez-Natal G. Carofiglio J. Auge L. Muscariello P. Camarillo Cisco Systems, Inc. S. Homma NTT June 29, 2018 Optimized Mobile User Plane Solutions for 5G draft-bogineni-dmm-optimized-mobile-user-plane-01 Abstract 3GPP CT4 has approved a study item to study different mobility management protocols for potential replacement of GTP tunnels between UPFs (N9 Interface) in the 3GPP 5G system architecture. This document provides an overview of 5G system architecture in the context of N9 Interface which is the scope of the 3GPP CT4 study item [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP], [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and [TS.38.401-3GPP]. Architecture requirements for evaluation of candidate protocols are provided. Optimization of the user plane can be in different ways - packet overhead, transport integration, etc. Several IETF protocols are considered for comparison: SRv6, LISP, ILA and several combinations of control plane and user plane protocols. 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 Bogineni, et al. Expires December 31, 2018 [Page 1] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://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 December 31, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of 3GPP Study Items . . . . . . . . . . . . . . . . 5 1.2. Relevance to IETF . . . . . . . . . . . . . . . . . . . . 6 1.3. Rationale for GTP replacement . . . . . . . . . . . . . . 6 1.4. Usage of GTP . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Document Structure . . . . . . . . . . . . . . . . . . . 7 2. Conventions and terminology . . . . . . . . . . . . . . . . . 7 3. Overview of 3GPP Release 15 5G Architecture . . . . . . . . . 8 3.1. Non-Roaming Reference Architecture . . . . . . . . . . . 8 3.2. End-to-end Protocol Stack . . . . . . . . . . . . . . . . 10 3.3. Mobility Architecture with reference to N9 . . . . . . . 11 3.3.1. User Plane Function (UPF) Functionalities . . . . . . 12 3.3.2. N9 Interface . . . . . . . . . . . . . . . . . . . . 15 3.4. Roaming Architectures . . . . . . . . . . . . . . . . . . 16 3.4.1. Roaming and policy management . . . . . . . . . . . . 17 3.4.2. Local Break Out Model . . . . . . . . . . . . . . . . 18 3.4.3. Home Routed Model . . . . . . . . . . . . . . . . . . 18 3.5. Support for Multiple PDU Sessions . . . . . . . . . . . . 19 3.6. Service and Session Continuity Modes . . . . . . . . . . 21 4. Architectural requirements . . . . . . . . . . . . . . . . . 22 5. Data plane architecture models for N9 . . . . . . . . . . . . 23 Bogineni, et al. Expires December 31, 2018 [Page 2] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Forwarding and mobility paradigms . . . . . . . . . . . . 23 5.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 5.3.2. SRv6 with Traffic Engineering . . . . . . . . . . . . 26 5.3.3. Service Programming with SRv6 . . . . . . . . . . . . 27 5.3.4. SRv6 and Entropy . . . . . . . . . . . . . . . . . . 28 5.3.5. SRv6 and transport slicing . . . . . . . . . . . . . 28 5.3.6. SRv6 and Alternative Approaches to Advanced Mobility Support . . . . . . . . . . . . . . . . . . . . . . . 28 5.3.7. Areas of Concerns . . . . . . . . . . . . . . . . . . 29 5.4. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 30 5.4.2. LISP Encapsulation . . . . . . . . . . . . . . . . . 30 5.4.3. LISP Mapping Systems . . . . . . . . . . . . . . . . 30 5.4.4. LISP Mobility Features . . . . . . . . . . . . . . . 31 5.4.5. ILSR . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 32 5.5.2. Protocol Layering . . . . . . . . . . . . . . . . . . 33 5.5.3. Control plane . . . . . . . . . . . . . . . . . . . . 33 5.5.4. IP addressing . . . . . . . . . . . . . . . . . . . . 34 5.5.5. Traffic engineering . . . . . . . . . . . . . . . . . 36 5.5.6. Locator Chaining with ILA . . . . . . . . . . . . . . 36 5.5.7. Security considerations . . . . . . . . . . . . . . . 36 5.6. Hybrid ICN (hICN) . . . . . . . . . . . . . . . . . . . . 37 5.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 5.6.2. Consumer and Producer mobility . . . . . . . . . . . 37 5.6.3. Anchorless mobility support . . . . . . . . . . . . . 38 5.6.4. Benefits . . . . . . . . . . . . . . . . . . . . . . 38 5.6.5. Deployment considerations . . . . . . . . . . . . . . 39 5.6.6. hICN with SRv6 . . . . . . . . . . . . . . . . . . . 40 5.6.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 41 6. Integration into the 5G framework . . . . . . . . . . . . . . 41 6.1. Locator based - SRv6 . . . . . . . . . . . . . . . . . . 41 6.1.1. Insertion in N9 interface . . . . . . . . . . . . . . 41 6.1.2. Control Plane considerations . . . . . . . . . . . . 42 6.1.3. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 43 6.1.4. Coexistence with GTP-based architecture . . . . . . . 43 6.2. ID-LOC split . . . . . . . . . . . . . . . . . . . . . . 44 6.2.1. Insertion in N9 interface . . . . . . . . . . . . . . 44 6.2.2. LISP control plane . . . . . . . . . . . . . . . . . 46 6.2.3. ILA control plane . . . . . . . . . . . . . . . . . . 47 6.2.4. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 47 6.2.5. Coexistence with GTP-based architecture . . . . . . . 48 6.3. ID-based - hICN . . . . . . . . . . . . . . . . . . . . . 50 6.3.1. Insertion in N9 interface . . . . . . . . . . . . . . 50 6.3.2. Control plane considerations . . . . . . . . . . . . 51 Bogineni, et al. Expires December 31, 2018 [Page 3] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.3.3. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 52 6.3.4. Coexistence with GTP-based architecture . . . . . . . 52 6.4. Coexistence of multiple protocols in network slices . . . 53 6.5. Interoperability/Roaming considerations . . . . . . . . . 54 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 9. Security Consideration . . . . . . . . . . . . . . . . . . . 56 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 1. Introduction Release 15 of the 3GPP specifications provide the 5G System Architecture in [TS.23.501-3GPP], [TS.23.502-3GPP], and [TS.23.503-3GPP]. They come with significant changes to the radio and core architectures with respect to previous generations, with the objective of enabling new use case requirements expected from 5G networks. The user plane is however still based on GTP-U, and tunnelling user-traffic to anchor points in the core network. User, data and forwarding plane are used with the same meaning in this context. 3GPP CT4 is in charge of specifying the user plane interface named N9, and has approved a study item [CP-173160-1] to study possible candidates for user plane protocol for the 5GC in Release 16. This document comprehensively describes the various user plane protocols and how they can be used in the 3GPP 5G architecture. Specifically Segment Routing v6 (SRv6), Locator Identifier Separation Protocol (LISP), Identifier Locator Addressing (ILA) and Hybrid Information-Centric Networking (hICN) are introduced and their use as replacement of GTP for N9 is further described. Analysis work for clarifying the specifications of GTP-U as the current mobile user plane protocol and the architectural requirements of the 5G system is provided in [I-D.hmm-dmm-5g-uplane-analysis]. That provides observations of GTP-U, the architectural requirements for UP protocol, and some evaluation criteria based on the requirements. Optimization of the user plane can be in one more more of the following: o reduction/elimination of encapsulation; Bogineni, et al. Expires December 31, 2018 [Page 4] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 o use of native routing mechanisms; o efficient forwarding during, and in between mobility events; o support of anchor-less mobility management and offloading of local traffic; o reduction of session state and signaling associated with mobility management; o convergence towards a flatter architecture, consistent with other mobility proposals. 1.1. Scope of 3GPP Study Items 3GPP CT4 WG has approved a Release 16 study item [CP-173160-1] to study user-plane protocol for N9 in 5GC architecture as specified in [TS.23.501-3GPP] and [TS.23.502-3GPP]. This provides an opportunity to investigate potential limits of the existing user plane solution and potential benefits of alternative user plane solutions. The following is extracted from the CT4 study item [CP-173160-1]. The expected work in CT4 will include: o Identify the possible candidate protocols for user-plane including existing protocol; o Define a list of evaluation criteria based on Rel-16 stage 2 requirements to evaluate the candidate protocols; o Evaluate the candidate solutions against the list of requirements and the potential benefits against the existing user plane solution in 5GS. CT4 will coordinate with RAN3 for selecting the user plane protocols for N3 and F1-U interfaces in RAN. CT4 will also coordinate with CT3 Working Group for potential impacts to N6 interface and with SA2 for potential impacts on stage 2 specifications. Coordination will also be required with CT3 for potential impacts on N6, and with SA2 if the work has possible impacts on the stage 2 specifications. Extracted from [SP-180231-1], the work in SA2 Study item will study the feasibility of extending the service concept from 5GC control plane to the user plane function(s). Impact to User plane traffic processing is not expected in this study. Bogineni, et al. Expires December 31, 2018 [Page 5] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 1.2. Relevance to IETF IETF has some protocols for potential consideration as candidates. These protocols have the potential to simplify the architecture through reduction/elimination of encapsulation; use of native routing mechanisms; support of anchor-less mobility management; reduction of session state and reduction of signaling associated with mobility management. This document provides an overview of the various protocols and how they can be used in the 3GPP 5G architecture. Details of the protocols will be provided as references in the respective sections, then described in the context of the 3GPP 5G architecture. ILNP is an end-to-end protocol and is not included in this document. The scenario of replacing GTP on N9 as the focus of CT4 study is discussed for each protocol. Additional scenarios are related to N3/ F1-U; integration of mobility with transport; support for different mobility protocols on different slices of the 5G system, etc. 1.3. Rationale for GTP replacement Although being different in terms of architecture or implementations, common objectives emerge from the different proposals and their positioning with respect to the GTP-U tunnel-based architecture. We succintly discuss those aspects here, that will be detailed in the sections dedicated to each protocol, clarifying some terminology at the same occasion. _Simplification_ : simplify the management of networks, flat and converge architecture with other mobility proposals. _Efficiency_ : performance of the proposal for both packet forwarding, and handling of traffic during mobility events. _Overhead_ : remove encapsulation overhead due to tunneling. _Data plane anchors_ : remove anchoring of all communications in a central core location, and opt for distributed/decentralized/full removal of anchors. _Offloading of local communications_ : a direct consequence on the distribution/removal of user plane anchors is the ability to offload local traffic from the core. _Control plane anchors_ : remove dependency on additional control plane anchors, and interoperability with the SMF. Bogineni, et al. Expires December 31, 2018 [Page 6] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 _Transport_ : Relieve transport and application layers from the impact of mobility and related management protocols. 1.4. Usage of GTP The main focus of the study is on the N9 interfaces that interconnect UPFs and could span over the mobile backhaul. However, GTP is used at multiple interfaces beyond N9. N3 and N9 interfaces are tightly coupled and Section 6 discusses the possibility to extend the deployment of new user planes to N3. The impact on N3, F1-U, and Xn-U interfaces is still TBD. 1.5. Document Structure Section 3 provides a high level overview of the 5G system architecture and the relevant scenarios like roaming, support fo multiple PDU sessions, etc. Section 4 provides a list of architectural requirements that candidate solutions should address are provided. Section 5 provides an overview of the various protocols. Section 6 discusses how various approaches can be integrated into the 5G framework. A summary is provided in Section 7. 2. Conventions and terminology In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. In this document, the characters ">>" preceding an indented line(s) indicates a statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the portions of this RFC covered by these keywords. Acronyms _AF_: Application Function _AUSF_: Authentication Server Function Bogineni, et al. Expires December 31, 2018 [Page 7] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 _AMF_: Access and Mobility Management Function _DN_: Data Network, e.g. operator services, Internet access or 3rd party services _NEF_: Network Exposure Function _NRF_: Network Repository Function _NSSF_: Network Slice Selection Function _PCF_: Policy Control Function _RAN_: (Radio) Access Network _SMF_: Session Management Function _UDM_: Unified Data Management _UDR_: Unified Data Repository _UE_: User Equipment _UPF_: User Plane Function 3. Overview of 3GPP Release 15 5G Architecture This section briefly describes the 5G system architecture as specified in [TS.23.501-3GPP]. The key relevant features for session management and mobility management are: o Separate the User Plane (UP) functions from the Control Plane (CP) functions, allowing independent scalability, evolution and flexible deployments e.g. centralized location or distributed (remote) location. o Support concurrent access to local and centralized services. To support low latency services and access to local data networks, UP functions can be deployed close to the Access Network. o Support roaming with both Home routed traffic as well as Local breakout traffic in the visited PLMN. 3.1. Non-Roaming Reference Architecture This section briefly describes the 5G system architecture as specified in 3GPP TS 23.501, and represented in Figure 1 and Figure 2. Bogineni, et al. Expires December 31, 2018 [Page 8] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +------+ +------+ +------+ | NSSF | | AUSF +-N13-+ UDM | +------+ +------+ +------+ \ | / \ N22 N12 N8 N10 \ | / \ +----+----+ +-------+ +------+ +------+ +-----------+ AMF +- N11 -+ SMF +- N7 -+ PCF +- N5 -+ AF | | +++-----+++ +---+---+ +--+---+ +------+ | || || | | | || |+------------|----- N15 ---+ N1 N2|+-N14-+ N4 | | | +--+--+ ++-------+ +---+---+ +------+ | UE +-- NR --+ (R)AN +-- N3 --+ UPF +-- N6 --+ DN | +-----+ +--------+ ++-----++ +------+ | | +--N9-+ Figure 1: 5G System Architecture in Reference Point Representation A short description of the network functions is provided below. Details are in [TS.23.501-3GPP]. Access and Mobility Management Function (AMF) interfaces with the Radio access network and provides management of registration/connection/reachability/mobility, access authentication and authorization, etc. Session Management function (SMF) handles session management, UE IP address allocation & management, DHCP, ARP proxying, selection and control of UP function, traffic steering, interface to PCF,charging data collection, roaming, etc. User Plane Function (UPF) is the anchor point mobility, packet routing/forwarding/marking, packet inspection, policy rule enforcement, lawful intercept, QoS handling,etc. Policy Control Function (PCF) provides policy rules to Control Plane function(s) to enforce them. Network Exposure Function (NEF) supports exposure of capabilities and events between network functions, to 3rd party, Application Functions, Edge Computing, etc. Network Repository Function (NRF) supports service discovery function. Bogineni, et al. Expires December 31, 2018 [Page 9] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Unified Data Management (UDM) supports access authorization, subscription management, etc. Authentication Server Function (AUSF) supports authentication for 3GPP access and untrusted non-3GPP access. Network Slice Selection Function (NSSF) selects the set of Network Slice instances serving the UE, determines the allowed slices, etc. Application Function (AF) Service Based Interfaces ----+-----+-----+----+----+---------+--------+-----+----+---- | | | | | | | | | +---+---+ | +--+--+ | +--+---+ +--+--+ +--+--+ | +----+ | NSSF | | | NRF | | | AUSF | | UDM | | NEF | | | AF | +-------+ | +-----+ | +------+ +-----+ +-----+ | +----+ +---+----+ +--+--+ +-------------+--+ | AMF | | PCF | | SMF | +---+--+-+ +-----+ +-+-----------+--+ N1 | | | +-------+ | | N4 N4 | 5G UE |--+ | | | +---+---+ N2 +-----+-+ +---+---+ +----+ | | +----N3------+ UPF +-N9--+ UPF +--N6--+ DN | | | | ++----+-+ +-------+ +----+ | | | | | | +---+------+-+ +-N9-+ +-----| gNB | +------------+ Figure 2: 5G Service Based Architecture 3.2. End-to-end Protocol Stack The protocol stack for the User Plane transport for a PDU session is depicted below in Figure 3. Bogineni, et al. Expires December 31, 2018 [Page 10] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +-----+ | | | | App +---------------------|-----------------------|----------| +-----+ | | +------+ | | PDU +---------------------|-----------------------|-+ PDU | | +-----+ +---------------+ | +-----------------+ | +------+ | | | |\ /| | |\ /| | | | | | | | \ Relay / | | | \ Relay / | | | | | | | | \ / | | | \ / | | |5G UP | | | AN | | --+-- | | | ---+--- | | | Enc | | | Pro | |AN Pro | GTP-U +--|--+ GTP-U |5GUP Enc+--|-+ | | | Lyrs| | Lyrs +-------+ | +--------+--------+ | +------+ | | +--+ |UDP/IP +--|--+ UDP/IP | UDP/IP +--|-+UDP/IP| | | | | +-------+ | +--------+--------+ | +------+ | | | | | L2 +--|--+ L2 | L2 +--|-+ L2 | | | | | +-------+ | +--------+--------+ | +------+ | | | | | L1 +--|--+ L1 | L1 +--|-+ L1 | | +-----+ +-------+-------+ | +--------+--------+ | +------+ | UE AN N3 UPF N9 N6 UPF (PDU Session Anchor) Legend: o PDU layer: This layer corresponds to the PDU carried between the UE and the DN over the PDU session. When the PDU session Type is IPV6, it corresponds to IPv6 packets; When the PDU session Type is Ethernet, it corresponds to Ethernet frames; etc. o GPRS Tunnelling Protocol for the user plane (GTP U): This protocol supports multiplexing traffic of different PDU sessions (possibly corresponding to different PDU session Types) by tunnelling user data over N3 (i.e. between the AN node and the UPF) in the backbone network. GTP shall encapsulate all end user PDUs. It provides encapsulation on a per PDU session level. This layer carries also the marking associated with a QoS Flow. o 5G Encapsulation: This layer supports multiplexing traffic of different PDU sessions (possibly corresponding to different PDU session Types) over N9 (i.e. between different UPF of the 5GC). It provides encapsulation on a per PDU session level. This layer carries also the marking associated with a QoS Flow. Figure 3: Non-roaming 5G SA for multiple PDU Sessions 3.3. Mobility Architecture with reference to N9 This document focuses on the N9 interface which represents the user user plane between UPFs in 5G architecture. Figure 4 shows the relevant functions and interfaces. Bogineni, et al. Expires December 31, 2018 [Page 11] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +-----------------+ | SMF | +-+-------------+-+ | | N4 N4 | | +-----------+ +------+-+ +-+------+ +----+ | gNB/RAN |---N3---+ UPF |---N9----| UPF +---N6---| DN | +-----------+ +--------+ +--------+ +----+ Figure 4: N3, N4, N9, and N6 interfaces in 5G Service Based Architecture 3.3.1. User Plane Function (UPF) Functionalities The User plane function (UPF) is the function relevant to this evaluation and the N9 interface between two UPFs. The User Plane Function (UPF) handles the user plane path of PDU sessions. The UPF transmits the PDUs of the PDU session in a single tunnel between 5GC and (R)AN. The UPF includes the following functionality. Some or all of the UPF functionalities may be supported in a single instance of a UPF. Not all of the UPF functionalities are required to be supported in an instance of user plane function of a Network Slice. The following provides a brief list of main UPF functionalities. Please refer to section 6.2.3 of [TS.23.501-3GPP] for detailed description of UPF and its functionalities. o Anchor point for Intra-/Inter-RAT mobility (when applicable)" o Sending and forwarding of one or more end marker to the source NG- RAN node o External PDU Session point of interconnect to Data Network. o PDU session type: IPv4, IPv6, Ethernet, Unstructured (type of PDU totally transparent to 5GS) o Activation and release of the UP connection of an PDU session, upon UE transition between the CM-IDLE and CM-CONNECTED states(i.e. activation and release of N3 tunnelling towards the access network) o Data forwarding between the SMF and the UE or DN (e.g. IP address allocation or DN authorization during the establishment of a PDU session) Bogineni, et al. Expires December 31, 2018 [Page 12] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 o Packet routing and forwarding (e.g. support of Uplink classifier to route traffic flows to an instance of a data network, support of Branching point to support IPv6 multi-homed PDU session> o Branching Point to support routing of traffic flows of an IPv6 multi-homed PDU session to a data network, based on the source Prefix of the PDU o User Plane part of policy rule enforcement (e.g. Gating, Redirection, Traffic steering) o Uplink Classifier enforcement to support routing traffic flows to a data network, e.g. based on the destination IP address/Prefix of the UL PDU o Lawful intercept (UP collection) o Traffic usage reporting o QoS handling for user plane including: * packet filtering, gating, UL/DL rate enforcement, UL/DL Session-AMBR enforcement (with the Session-AMBR computed by the UPF over the Averaging window provisioned over N4, see subclause 5.7.3 of 3GPP [TS.23.501-3GPP]), UL/DL Guaranteed Flow Bit Rate (GFBR) enforcement, UL/DL Maximum Flow Bit Rate (MFBR) enforcement, etc * marking packets with the QoS Flow ID (QFI) in an encapsulation header on N3 (the QoS flow is the finest granularity of QoS differentiation in the PDU session) * enabling/disabling reflective QoS activation via the User Plane, i.e. marking DL packets with the Reflective QoS Indication (RQI) in the encapsulation header on N3, for DL packets matching a QoS Rule that contains an indication to activate reflective QoS o Uplink Traffic verification (SDF to QoS flow mapping, i.e. checking that QFIs in the UL PDUs are aligned with the QoS Rules provided to the UE or implicitly derived by the UE e.g. when using reflective QoS) o Transport level packet marking in the uplink and downlink, e.g. based on 5QI and ARP of the associated QoS flow. o Downlink packet buffering and downlink data notification triggering: This includes the support and handling of the ARP Bogineni, et al. Expires December 31, 2018 [Page 13] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 priority of QoS Flows over the N4 interface, to support priority mechanism: * "For a UE that is not configured for priority treatment, upon receiving the "N7 PDU-CAN Session Modification" message from the PCF with an ARP priority level that is entitled for priority use, the SMF sends an "N4 Session Modification Request" to update the ARP for the Signalling QoS Flows, and sends an "N11 SM Request with PDU Session Modification Command" message to the AMF, as specified in clause 4.3.3.2 of [TS.23.502-3GPP]. * "If an IP packet arrives at the UPF for a UE that is CM-IDLE over a QoS Flow which has an ARP priority level value that is entitled for priority use, delivery of priority indication during the Paging procedure is provided by inclusion of the ARP in the N4 interface "Downlink Data Notification" message, as specified in clause 4.2.3.4 of [TS.23.502-3GPP]." o ARP proxying as specified in [RFC1027] and / or IPv6 Neighbour Solicitation Proxying as specified in [RFC4861] functionality for the Ethernet PDUs. The UPF responds to the ARP and / or the IPv6 Neighbour Solicitation Request by providing the MAC address corresponding to the IP address sent in the request. o Packet inspection (e.g. Application detection based on service data flow template and the optional PFDs received from the SMF in addition) o Traffic detection capabilities. * For IP PDU session type, the UPF traffic detection capabilities may detect traffic using traffic pattern based on at least any combination of: + PDU session + QFI + IP Packet Filter Set. Please refer to section 5.7.6.2 of 3GPP TS 23.501 for further details. * For Ethernet PDU session type, the SMF may control UPF traffic detection capabilities based on at least any combination of: + PDU session + QFI Bogineni, et al. Expires December 31, 2018 [Page 14] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 + Ethernet Packet Filter Set. Please refer to section 5.7.6.3 of 3GPP TS 23.501 for further details. o Network slicing Requirements for different MM mechanisms on different slice. The selection mechanism for SMF to select UPF based on the selected network slice instance, DNN and other information e.g. UE subscription and local operator policies. 3.3.2. N9 Interface The details of N9 interface are extracted from [TR.29.891-3GPP]. The following information is sent in an encapsulation header over the N3 interface. N9 needs to support that. o QFI (QoS Flow Identifier), see subclause 5.7.1 of [TS.23.501-3GPP]. o RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of [TS.23.501-3GPP]. o Support of RAN initiated QoS Flow mobility, when using Dual connectivity, also requires the QFI to be sent within End Marker packets. See subclause 5.11.1 of [TS.23.501-3GPP] and subclause 4.14.1 of [TS.23.502-3GPP] respectively. GTPv1-U as defined in [TS.29.281-3GPP] is used over the N3 and N9 interfaces in Release 15. Release 15 is still work-in-progress and RAN3 will specify the contents of the 5GS Container. It is to be decided whether CT4 needs to specify new GTP-U extension header(s) in [TS.29.281-3GPP] for the 5GS Container. A GTP-U tunnel is used per PDU session to encapsulate T-PDUs and GTP-U signaling messages (e.g. End Marker, Echo Request, Error Indication) between GTP-U peers. A 5GS Container is defined as a new single GTP-U Extension Header over the N3 and N9 interfaces and the elements are added to this container as they appear with the forthcoming features and releases. This approach would allow to design the 5GS information elements independently from the tunneling protocol used within the 5GS, i.e. it would achieve the separation of the Transport Network Layer (TNL) and Radio Network Layer (RNL) as required in 3GPP TR 38.801 subclause 7.3.2. This would allow to not impact the RNL if in a future release a new transport network layer (TNL) other than GTP-U/UDP/IP (e.g. GRE/IP) was decided to be supported. Bogineni, et al. Expires December 31, 2018 [Page 15] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 3.4. Roaming Architectures 3GPP specifies two roaming models in [TS.23.501-3GPP], namely the Local Break Out (LBO) and the Home Routed (HR) model. o Local Break Out Model: This model enables traffic to be offloaded locally in the visited network. o Home Routed Model: In this model, the traffic is always routed to the home network. A given UE can have multiple simultaneous PDU sessions with different roaming models. In these scenarios, the HPLMN uses subscription data per Data Network Name(DNN) and per Single Network Slice Selection Assistance Information(S-NSSAI) to determine PDU sessions's roaming model. They are represented in Figure 5 and Figure 6 to the extent relevant to N9. VPLMN | HPLMN +-----+ +-------+ | +-------+ | AF |----N5---| V-PCF |-----------N24-------| H-PCF | +-----+ +-------+ | +-------+ | | N7 | | | +--+--+ | | SMF | | +--+--+ | | | +-------+ N4 | | 5G UE + | | +---+---+ +-----+--+ | | | | | | +---+-+ +-+-+ +-+-+ +----+ | +---| gNB |---|UPF|-N9-|UPF|--| DN | | +-----+ +-+-+ +---+ +----+ | Figure 5: Roaming 5G System Architecture - Local Breakout Scenario Bogineni, et al. Expires December 31, 2018 [Page 16] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 VPLMN | HPLMN -------------------- N32 ---------------------------- | | | | +-------+ | +-------+ | +-----+ | | V-PCF |--- N24 ---| H-PCF |---N5---| AF | | +-------+ | +-------+ | +-----+ | | | | | | N7 | | | | | | +--+--+ | +--+--+ | +------|V-SMF| | |H-SMF|--+ +--+--+ | +--+--+ | | | +-------+ | | | | 5G UE | | | | +---+---+ N4 | N4 | | | | | +-+---+ +--+--+ | +--+--+ +----+ +-----| gNB |-----| UPF |-----N9------| UPF |------| DN | +-----+ +--+--+ | +-----+ +----+ Figure 6: Roaming 5G System Architecture- Home Routed Scenario 3.4.1. Roaming and policy management In general, the Policy Control Functions (PCF)s in Home PLMN (HPLMN) and Visited PLMN (VPLMN) interact with their respective SMFs as well as one another to support roaming. The interface between the PCF and SMF allows the PCF to have dynamic control over policy and charging decisions at SMF. More specifically, the interface o Enables the SMF to establish PDU session, o Allows policy and charging control decisions to be requested from the SMF to the PCF direction or to be provisioned from the opposite direction. o Provides a mean for SMF to deliver network events and PDU session parameters to PCF. o Provides for PDU session termination at either PCF or SMF end. The N24 interface betweeen V-PCF and H-PCF provides a communication path between these two entities. The interface enables H-PCF to provision access and mobility management related policies to V-PCF, and allows V-PCF to send Policy Association Establishmenent and Bogineni, et al. Expires December 31, 2018 [Page 17] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Termination requests to H-PCF during UE registration and deregistration procedures. 3.4.2. Local Break Out Model In the LBO model, visited operator routes user traffic locally through UPFs that are local to the visited operator. In this model, the SMF and all UPF(s) involved by the PDU Session are located and are under the control of the VPLMN. In this model, the V-PCF generates Policy and Charging Control (PCC) rules from the local configuration data that are based on the roaming agreement with the HPLMN. The V-PCF might also use information from Application Function(AF) to generate PCC rules for VPLMN delivered services. Here, the H-PCF uses the N24 interface to deliver UE access selection, and PDU session selection policies to the V-PCF. The V-PCF can either provide access and mobility policy information on its own, or alternatively obtain the required information from the H-PCF via the N24 interface. 3.4.3. Home Routed Model In the HR model, user traffic is routed to the UPF in HPLMN via the UPF in the visited network. In this scenario, the SMF in HPLMN (H-SMF) selects the UPF(s) in the HPLMN and the SMF in VPLMN(V-SMF) selects the UPF(s) in the VPLMN. In this model, the UE obtains services from its home network. Here, the UPF acting as PGW resides in home network, and can directly communicate with policy and billing system. In the HR roaming model: o The NAS SM terminates at the V-SMF. o The V-SMF forwards SM related informaton to the SMF in the HPLMN. o The V-SMF sends UE's Subscription Permanent Identifier(SUPI) to the H-SMF during the PDU session establishment procedure. o The V-SMF sends the PDU Session Establishment Request message to the H-SMF along with the S-NSSAI with the value from the HPLMN. o The H-SMF obtains subscription data directly from the Unified Data Management(UDM) and is responsible for checking the UE request with regard to the user subscription, and may reject the request in case of mismatch. Bogineni, et al. Expires December 31, 2018 [Page 18] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 o The H-SMF may send QoS requirements associated with a PDU Session to the V-SMF. This may happen at PDU Session establishment and after the PDU Session is established. The interface between H-SMF and V-SMF is also able to carry (N9) User Plane forwarding information exchanged between H-SMF and V-SMF. The V-SMF may check QoS requests from the H-SMF with respect to roaming agreements.At the user plane, the ecapsulation header carries QoS flow ID (QFI) over N3, and N9 without any changes to the end to end packet header. o The AMF selects a V-SMF and a H-SMF, and provides the identifier of the selected H-SMF to the selected V-SMF. o The H-SMF performs IP address management procedure based on the selected PDU session type. 3.5. Support for Multiple PDU Sessions Figure 7 depicts the non-roaming architecture for UEs concurrently accessing two (e.g. local and central) data networks using multiple PDU Sessions, using the reference point representation. This figure shows the architecture for multiple PDU Sessions where two SMFs are selected for the two different PDU Sessions. However, each SMF may also have the capability to control both a local and a central UPF within a PDU Session. Service Based Interfaces ---------+------------+------------------+---------------------- | | +--+--+ +--+--+ | SMF | | SMF | +--+--+ +--+--+ | | +-------+ N4 N4 | 5G UE | | | +---+---+ +--+--+ +----+ +-----------+ | +---| UPF |----| DN | | | | | +-----+ +----+ | | | +-+---+-+ +--+--+ +--+--+ +----+ +-----| gNB |--------------------| UPF |--N9-| UPF |--| DN | +-------+ +-----+ +-----+ +----+ Figure 7: Non-roaming 5G System Architecture for multiple PDU Sessions Service Based Interface Figure 8 depicts the non-roaming architecture in case concurrent access to two (e.g. local and central) data networks is provided within a single PDU Session. Bogineni, et al. Expires December 31, 2018 [Page 19] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Service Based Interfaces ---------+-----------------------+----------------------- | +--+--+ | SMF | +--+--+ | +-------+ +------+-------+ | 5G UE | | | +---+---+ N4 N4 | +-+---+ +--+--+ +--+--+ +----+ +-----| gNB |-------| UPF |----N9--| UPF |----| DN | +-----+ +--+--+ +-----+ +----+ | +--+--+ | DN | +-----+ Figure 8: Non-roaming 5G System Architecture for Current Access to Two (e.g. local and central) Data Networks (single PDU Session option Figure 9 depicts overview of a network model where multiple UPFs are distributed geographically. Such networks have two types of UPFs: central UPF (cUPF) deployed for covering wide area, and local/ distributed UPF (dUPF) deployed close to UEs' access points. UPFs are connected via N9 interfaces over transport network. Bogineni, et al. Expires December 31, 2018 [Page 20] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +----------+ | cDN/ | | Internet | +----------+ |N6 +-----+-----+ | cUPF | +-----+-----+ |N9 ,-----------------------+-----------------------. / \ | Transport Network | \ / `----+---------------------------+--------------' |N9 |N9 +-----+-----+ +-----+-----+ | dUPF#1 |N6 +-------+ | dUPF#2 |N6 +-------+ | [UL/CL] +---| dDN#A | | [UL/CL] +---| dDN#B | +-----------+ +-------+ +-----------+ +-------+ |N3 |N3 +-----+ +-----+ | gNB | | gNB | +-----+ +-----+ | | +----+ +----+ | UE | | UE | +----+ +----+ dUPF: Distributed UPF cUPF: Central UPF dDN: Distributed DN cDN: Central DN Figure 9: Overview of Network Model with Distributed UPFs 3.6. Service and Session Continuity Modes The 5G System supports different session and service continuity (SSC) modes. _SSC mode 1_: the network preserves the connectivity service provided to the UE. _SSC mode 2_: the network may release the connectivity service delivered to the UE and release the corresponding PDU Session. Bogineni, et al. Expires December 31, 2018 [Page 21] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 _SSC mode 3_: changes to the user plane can be visible to the UE, while the network ensures that the UE suffers no loss of connectivity. A connection through new PDU Session Anchor point is established before the previous connection is terminated in order to allow for better service continuity. 4. Architectural requirements [I-D.hmm-dmm-5g-uplane-analysis] provides a comprehensive summary of GTP architecture, and architectural requirements related to user plane collected from 3GPP specifications that we summarize here: ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU The 5G system defines four types of PDU session as IPv4, IPv6, Ethernet, and Unstractured, and UP protocol would be required to support to convey all of these PDUs session type. ARCH-Req-2: Supporting IP Connectivity over N3, N6, and N9 The 5G system provides IP connectivity over N3, N6, and N9 interfaces. ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a single PDU session The 5G system allows to deploy multiple UPFs as anchors for a single PDU session, and suupports multihoming of a single PDU session for such anchor UPFs. ARCH-Req-4: Supporting flexible UPF selection for PDU The appropriate UPFs are selected for a PDU session based on parameters and information such as UPF's dynamic load or UE location information. ARCH-Req-5: No limitation for number of UPFs in a user plane path The number of UPF in the data path is not constrained by 3GPP specifications. ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated with QFI into a PDU Session In the 5G system, a single tunnel/data-path includes multiple QFIs contrast to just one QoS Flow (a bearer) to one tunnel/data-path Bogineni, et al. Expires December 31, 2018 [Page 22] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 User plane protocol needs to support fundamentally these requirements. In addition, [I-D.hmm-dmm-5g-uplane-analysis] provides evaluation aspects for user plane protocol that are mainly derived from the architectural requirements, such as Supporting PDU Session Type Variations, Nature of Data Path, Data Path Management, etc. The details are described in [I-D.hmm-dmm-5g-uplane-analysis]. For each protocol, we will attempt in the next section to discuss to what extent those architectural requirements are addressed. However, it is worth noticing that it is not mandatory that all those requirements are supported by the user plane protocol itself, as they might be realized through complementary mechanisms Section 6.6. 5. Data plane architecture models for N9 5.1. Overview The user plane architectures considered for UPF connectivity in mobile packet core fall into two categories: o Interworking model: * This model uses GWs. * UPFs and 3GPP control remain unchanged. * 3GPP user plane becomes an overlay on top of new user planes * GWs convert GTP traffic to underlying user plane format. o Integrated model: * In this model UPFs transmit/receive packets in accordance with the new user plane format. * UPFs and 3GPP control will be modified. * 3GPP and transport user plane are collapsed into one user plane. 5.2. Forwarding and mobility paradigms Based on their use of identifiers and locators, mobility approaches can be broadly categorized in the three following classes: *Locator-based* Bogineni, et al. Expires December 31, 2018 [Page 23] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 IP communication relies solely on locators (host interfaces' addresses) that are also used as node/service identifiers at network layer. Such semantic overloading of IP addresses as both identifiers and locators does not allow to disentangle locators from location- independent traffic identifiers, thus complexifying mobility management. As a result, traffic anchors and tunnels have been introduced to handle mobility while preserving the identifier exposed to the transport layer. *Locator-ID separation* To overcome the limitations of purely locator-based architectures, "locator/identifier separation" (or Loc/ID split) schemes have been proposed, that use separate namespaces for so-called End-point Identifiers (EID) and Route Locators (RLOC), bound together through a mapping system. This service can be centralized, decentralized or distributed and offers control plane protocols for storage, update or retrieval of the correspondence between EIDs and RLOCs. Loc/ID split has been originally proposed by LISP to solve the scalability challenges of Internet routing, and further adapted as a mobility management solution. This category includes most of the approaches reviewed in this document, namely ILA, ILSR and a SRv6-based solution, which all share the requirement for a mapping system. *ID-based* A third class of approaches exists that redefines IP communication principles (i.e. network and transport layers) around location- independent identifiers [I-D.vonhugo-5gangip-ip-issues]. Information-Centric Networking (ICN) approaches fall into such class of approaches that we refer to as purely ID-based, or in that specific case, as name-based [I-D.irtf-icnrg-terminology]. Previous work has highlighted the interest of ICN for mobility management [RFC7476]. The rest of this section details the set of reviewed approaches, namely SRv6, LISP, ILSR, ILA and hICN, as summarized in Figure 10. Each proposal consists in an overview with pointers to reference material for a more in depth description. The focus is then given to a discussion on its integration at N9 interface, as well as the benefits with respect to GTP-U. Extensions to N3 interface as well as alternative deployments preserving GTP tunnels as discussed later in this document in Section 6. Bogineni, et al. Expires December 31, 2018 [Page 24] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 *Reviewed approaches* |_ Mobility Management |_ Locator-based |_ Tunnelling |_ 3GPP / GTP-U Sec. 4 |_ Packet steering |_ SRv6 (backwards-compatible) Sec. 5.2.1 |_ Loc/ID split |_ Packet steering |_ SRv6 Sec 5.2.2 |_ Encapsulation |_ LISP, LISP-MN, ILSR Sec. 5.3 |_ Address rewrite |_ Network-based translation |_ ILA Sec. 5.5 |_ ID-based |_ Information-Centric Networking |_ ID-based mobility / IPv6 |_ Hybrid ICN Sec. 5.6 Figure 10: Overview of reviewed approaches 5.3. SRv6 5.3.1. Overview SRv6 [I-D.filsfils-spring-srv6-network-programming] is the IPv6 dataplane instantiation of Segment Routing [I-D.ietf-spring-segment-routing]. Segment Routing is a network architecture based on source-routing (the headend inserts the nodes that a packet must traverse for TE, NFV and VPN purposes). Thus confining flow states to the ingress nodes in the SR domain. The SRv6 dataplane consists on leveraging the IPv6 extension headers, defined in RFC8200, to include in the IPv6 header a new "Segment Routing Header" [I-D.ietf-6man-segment-routing-header] (SRH). SRv6 encodes segments (SIDs) as IPv6 addresses in the Segment List of its header. The IPv6 Destination Address (DA) specifies the active segment in the Segment List, while the Segments Left (SL) field of the SRH points to the next active segment in the Segment List. SRv6 routes over the shortest ECMP-aware path in the network up the the node instantiating the active segment. Once the packet has reached this node, the segment is executed. This implies running its associated function on the router, decrementing the SL value and updating the IPv6 DA to the next active segment. Notice that transit Bogineni, et al. Expires December 31, 2018 [Page 25] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 routers neither inspect the SRH nor process it. Thus they only need to be IPv6 capable. The main benefit of SRv6 overlays is the reduction of state in the network (there is no state in the forwarding fabric), with optimized MTU overhead, and its capability to integrate with the underlay (SLA; Traffic Engineering) and distributed NFVi. Hence there is no need NSH for NVF, RSVP for TE, or UDP for ECMP. SR also supports natively network slicing, which implies that SRv6 can offer end-to-end network slices that spans all those elements (overlay, underlay, NFV). The versatility and adaptability of SR combined with IPv6's ample and flexible address space positions SRv6 as a viable user plane for the next generation of mobile user-plane, in particular the 3GPP N3 and N9 interfaces. Notice that SRv6 applicability does not require a new mobility control-plane. SRv6 can be combined with other control- planes such as LISP, hICN described later in this document or others such as DHT, propietary CP, etc. The applicability of SRv6 to mobility is described in [I-D.ietf-dmm-srv6-mobile-uplane]. SRv6 counts with three open-source implementations (Linux Kernel, FD.io VPP, P4) and several propietary implementations (4xCisco, 1xBarefoot Networks, 1xUTStarcom) which have publicly participated in interops and all execute at linecard rate. This section starts by summarising the use of SRv6 as a drop-in alternative for GTP-U over the N9 interface connecting different User Plane Functions (UPF). It then shows how SRv6 as a GTP-U replacement can then provide additional features such as TE, IP session aggregation, rate limiting, and distributed NFVi that are not natively available by GTP. It must be noted that the SRv6 models discussed in this document can follow either of the interworking or the integration model mentioned earlier depending on operator's requirements. SRv6 appears well placed as a mechanism to replace GTP-U with initially no control plane changes, but to then offer a progressive path towards many innovations in routing. 5.3.2. SRv6 with Traffic Engineering SRv6 can be applied as a drop-in replacement for GTP without changes in the control-plane. This is a simple 1 to 1 replacement discussed in section 6.1. However, SRv6 offers much richer possibilities. Bogineni, et al. Expires December 31, 2018 [Page 26] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Traffic engineering is a native feature of SR. The SRv6 variant of SR of course supports both strict and loose models of source routing. Here, the SID list in SRH can represent a loose or strict path to UPFs. Therefore, traffic engineering can easily be supported regardless of any of the aforementioned approaches. The main benefit of leveraging SRv6 for TE is the natural ability to create end-to-end network slices that spans both the UPFs and the underlaying transport network with TE optimization objectives (i.e. low-latency). It must be noted that the SRH could contain multiple sets of SIDs each representing a TE path between a pair of UPFs. Alternatively, the SRH can contain a fully resolved end to end TE path that covers every intermediate node and UPF along the user plane. SR considers segments to be instructions. Therefore each SID can represent a function that enforces a specific nodal or global packet treatment. Attributes such as jitter and delay requirement, rate limiting factors, etc. can be easily encoded in to SIDs in order to apply the desired treatment as packets traverse the network from UPF to UPF. [I-D.ietf-dmm-srv6-mobile-uplane] suggests a SID encoding mechanism for rate limiting purposes. Please refer to the followings for further details about SR traffic engineering capabilities, the network programming concept, and some of the main SRv6 functions. o [I-D.ietf-spring-segment-routing] o [I-D.ietf-spring-segment-routing-policy] o [I-D.filsfils-spring-srv6-network-programming] o [I-D.ietf-6man-segment-routing-header] 5.3.3. Service Programming with SRv6 Service programming -or distributed NFVi- is another intrinsic feature of SR. Leveraging this capability, operators can steer user traffic through a set of UPFs where each UPF performs a specific service on the traffic. Service programming is achieved through the use of SIDs in an identical manner to what was described in the previous section: the SRH is populated with a set of SIDs with each SID identifying a specific UPF in the network. Starting from the ingress SRv6 node, Bogineni, et al. Expires December 31, 2018 [Page 27] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 packets are then forwarded through the network visiting the set of UPFs listed as SIDs in the SRH. Please refer to [I-D.xuclad-spring-sr-service-chaining] for further detail. 5.3.4. SRv6 and Entropy Ability to provide a good level of entropy is an important aspect of user plane protocols. If included in network node's hashing, the TEID field in GTP tunnels algorithms can result in good load balancing. Therefore, any new user plane proposal should be able to deal with entropy in an efficient manner. SRv6 natively supports entropy by using the IPv6 Flow Label. Additionally, SRv6 SIDs can easily accommodate entropy at a hop by hop level by reserving a set of bits in the SID construct itself. In this way, the hashing algorithm at different nodes distribute traffic flows based on the SID which has been copied to IPv6 DA field. 5.3.5. SRv6 and transport slicing Slicing is one of the main features in 5G [TS.23.501-3GPP]. Several Slices with different requirements can coexist on top of the common network infrastructure. Diverse flows belonging to different 5G slices can be completely disjoint or can share different parts of the network infrastructure. SRv6 has native support for network slicing spanning the UPFs, underlay -transport network- and NFVi. Also, SRv6 creates network slices without per-flow state in the fabric, hence simplifying the slicing paradigm. Please refer to [I-D.ietf-spring-segment-routing-policy] for further detail. 5.3.6. SRv6 and Alternative Approaches to Advanced Mobility Support SRv6 flexibility enables it to support different methods of providing mobility in the network. ID-LOC for mobility support is one such option. The previous sections discussed how SRv6 could be employed as a replacement for GTP tunnels while leaving the existing control plane intact. This section describes the use of SRv6 as a vehicle to implement Locator/ID Separation model for UPF user plane connectivity. It must be ntoed that SRv6 implementation of the ID- LOC architecture can employ a variety of different control planes including LISP, , different variety of DHT, proprietary, etc. Bogineni, et al. Expires December 31, 2018 [Page 28] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.3.6.1. UPF connectivity via SRv6 with Loc-ID separation (Interworking model) SRv6 can easily implement ID-LOC Separation model for UPF connectivity. The SIDs are once again the main vehicle here. In this model, UPFs are considered to be the IDs while the nodes where the UPFs attach to take on the role of the Locators. In this approach, UPFs connect to SRv6 capable Locators. UPFs use IPv4/IPv6 transport either in conjunction with GTP or without any GTP tunnel and send the packets to their associated Locator at the near end (Ingress SRv6 Locator). It must be noted that use of GTP at UPFs allows us to leave the 3GPP control plane intact and hence provides a smooth migration path toward SRv6 with ID-Locator model. 5.3.6.2. SRv6 Capable UPFs and RLOCs (Integration model) In this model, the head-end UPF (Ingress UPF) is the ingress node and the entity that constructs the SRH in the SRv6 domain. The 3GPP control plane is responsible for distributing UPF's endpoint information. But it requires some modifications to be able to convey endpoint information to interested parties. The SMF can provide a fully resolved SID list by communicating with a centralised or distributed ID-LOC mapping system containing all the relevant data regarding the UPF-Locator relationship. 5.3.6.3. Advanced Features in ID-Locator Architecture SRv6's native features such as Traffic Engineering, QoS support, UPF Chaining, network slicing, etc. can be easily added to ID-Locator support. As it was noted earlier, these features are not readily available by GTP. 5.3.7. Areas of Concerns Support for IPv6 is a precondition for SRv6. Although SRv6 can support hybrid IPv4/IPv6 mobile user plane through an interworking node, support of UPFs with IPv4 address is rather complex. Due to IPv6 128-bit address space, large SRH size can have a negative impact on MTU. Large SRH size can also exert undesirable header tax especially in the case of small payload size. Bogineni, et al. Expires December 31, 2018 [Page 29] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 ID-LOC architecture relies on high performance mapping systems. The SRv6 support of ID-LOC as described earlier can employ different control planes. Distributed mapping systems using some form Distributed Hash Table(DHT) however, exhibit very promising results. But further investigation is needed to ensure comformance with performance metrics required by the mobile networks, specially for slice types supporting high speed mobility. 5.4. LISP 5.4.1. Overview The Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from Endpoint Identifiers (EIDs) that are not globally routable to routable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across a network infrastructure that uses RLOCs for routing and forwarding. An introduction to LISP can be found in [I-D.ietf-lisp-introduction]. A complete RFC-set of specifications can be found in [RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061], [RFC8111]. They describe support and mechanisms for all combinations of inner and outer IPv4 and IPv6 packet headers for unicast and multicast packet flows that also interwork with non-LISP sites as well as two designs to realize a scalable mapping system. A standards-track based set of drafts [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] are products and work in progress of the LISP Working Group. 5.4.2. LISP Encapsulation LISP uses dynamic tunnel encapsulation as its fundadmental mechanism for the data-plane. Fixed headers are used between the outer and inner IP headers which are 16 bytes in length. Details can be found in [RFC6830]. 5.4.3. LISP Mapping Systems Many years of research dating back to 2007 have gone into LISP scalable mapping systems. They can be found at [LISP-WG] and [IRTF-RRG]. The two that show promise and have deployment experience are LISP-DDT [RFC8111] and LISP-ALT [RFC6836]. Bogineni, et al. Expires December 31, 2018 [Page 30] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 The control-plane API which LISP xTRs are the clients of is documented in [RFC6833]. Various mapping system and control-plane tools are available [RFC6835] [RFC8112] and are in operational use. 5.4.4. LISP Mobility Features LISP supports multi-homed shortest-path session survivable mobility. An EID can remain fixed for a node that roams while its dynamic binding changes to the RLOCs it uses when it reconnect to the new network location. When the roaming node supports LISP, its EIDs and RLOCs are local to the node. This form of mobility is call LISP Mobile-Node. Details can be found in [I-D.ietf-lisp-mn]. When the roaming node does not support LISP, but LISP runs in the network the node roams to, the EIDs and RLOCs are not co-located in the same device. In this case, EIDs are assigned to the roaming node and RLOCs are assigned to LISP xTRs. So when the roaming node attaches to the network, its EIDs are mapped to the RLOCs of the LISP xTRs in the network. This form of mobility is called LISP EID- Mobility. Details can be found in [I-D.ietf-lisp-eid-mobility]. For a 3GGP mobile network, the LISP EID-Mobility form of mobility is recommended and is specified in the use-case document [I-D.farinacci-lisp-mobile-network]. 5.4.5. ILSR ILSR is a specific recommendation for using LISP in the 3GPP 5G mobile network architecture. A detailed whitepaper can be found at [ILSR-WP]. The recommendation is to use the mechanisms in [I-D.farinacci-lisp-mobile-network]. 5.5. ILA Identifier-Locator Addressing [I-D.herbert-intarea-ila] is a protocol to implement transparent network overlays without encapsulation. It addresses the need for network overlays in virtualization and mobility that are efficient, lightweight, performant, scalable, secure, provide seamless mobility, leverage and encourage use of IPv6, provide strong privacy, are interoperable with existing infrastructure, applicable to a variety of use cases, and have simplified control and management. Bogineni, et al. Expires December 31, 2018 [Page 31] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.5.1. Overview ILA is a form of identifier/locator split where IPv6 addresses are transformed from application-visible, non-topological "identifier" addresses to topological "locator" addresses. Locator addresses allow packets to be forwarded to the network location where a logical or mobile node currently resides or is attached. Before delivery to the ultimate destination, locator addresses are reverse transformed back to the original application visible addresses. ILA does address "transformation" as opposed to "translation" since address modifications are always undone. ILA is conceptually similar to ILNP and 8+8, however ILA is contained in the network layer. It is not limited to end node deployment, does not require any changes to transport layer protocols, and does not use extension headers. ILA includes both a user plane and control plane. The user plane defines the address structure and mechanisms for transforming application visible identifier addresses to locator addresses. The control plane's primary focus is a mapping system that includes a database of identifier to locator mappings. This mapping database drives ILA transformations. Control plane protocols disseminate identifier to locator mappings amongst ILA nodes. The use cases of ILA include mobile networks, datacenter virtualization, and network virtualization. A recent trend in the industry is to build converged networks containing all three of these to provide low latency and high availability. A single network overlay solution that works across multiple use cases is appealing. Benefits of ILA include: o Facilitates node mobility and virtualization o Multiple use cases (mobile, datacenter, cloud) o Super efficient and performant user plane o Allows strong privacy in addressing o Promotes anchorless mobility o No typical tunneling issues (e.g. MTU) or management related to encapsulation o Flexible control plane that splits data and control o Modern "SDN" control protocols (e.g. RPC/TCP) Bogineni, et al. Expires December 31, 2018 [Page 32] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 o Scale number of nodes to billions for 5G, DC virtualization o Upstream Linux kernel data path and open source ctrl plane [ILACONTROL]. The ILA user plane protocol is described in [I-D.herbert-intarea-ila], motivation and problems areas are described in [ILAMOTIVE], ILA in the mobile user-plane is described in detail in [I-D.herbert-ila-mobile]. 5.5.2. Protocol Layering Figure 11 illustrates the protocol layers of packets packets sent over various user plane interfaces in the downlink direction of data network to a mobile node. Note that this assumes the topology shown in Figure 2 where GTP-U is used over N3 and ILA is used on N9. - - - DN to ILA-R ILA-R to ILA-N ILA-N to gNB gNB to UE +------------+ +------------+ +------------+ +------------+ | Application| | Application| | Application| | Application| +------------+ +------------+ +------------+ +------------+ | L4 | | L4 | | L4 | | L4 | +------------+ +------------+ +------------+ +------------+ | IPv6 | | IPv6 (ILA) | | IPv6 | | PDU Layer | +------------+ | +------------+ | +------------+ +------------+ | L2 | | | L2 | | | GTP-U | | AN Protocol| +------------+ | +------------+ | +------------+ | Layers | | | | UDP/IP | | | N6 <--N9 N3 +------------+ +------------+ | L2 | +------------+ Figure 11: ILA and protocol layer in 5G 5.5.3. Control plane ILA-M provides the interface between the 5G services architecture and the common ILA control plane. 5.5.3.1. ILA-M services interface The control interface into ILA is via an ILA-M that interacts with 5G network services. ILA-M uses RESTful APIs to make requests to network services. An ILA-M receives notifications when devices enter the network, leave it, or move within the network. The ILA-M writes the ILA mapping entries accordingly. Bogineni, et al. Expires December 31, 2018 [Page 33] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 ILA is a consumer of several 5G network services. The service operations of interest to ILA are: o Nudm (Unified Data Management): Provides subscriber information. o Nsmf (Service Managment Function): Provides information about PDU sessions. o Namf (Core Access and Mobility Function): Provides notifications of mobility events. 5.5.3.2. ILA control plane The ILA control plane is composed of mapping protocols that manage and disseminate information about the mapping database. There are two levels of mapping protocols: one used by ILA routers that require the full set of ILA mappings for a domain, and one used by ILA nodes that maintain a caches of mappings. The ILA mapping system is effectively a key/value datastore that maps identifiers to locators. The protocol for sharing mapping information amongst ILA routers can thus be implemented by a distributed database [I-D.herbert-ila-ilamp]. ILA separates the control plane from the user plane, so alternative control plane protocols may be used with a common user plane [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp]. The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA forwarding nodes and ILA mapping routers. The purpose of the protocol is to populate and maintain the ILA mapping cache in forwarding nodes. ILAMP defines redirects, a request/response protocol, and a push mechanism to populate the mapping table. Unlike traditional routing protocols that run over UDP, this protocol is intended to be run over TCP and may be RPC oriented. TCP provides reliability, statefulness implied by established connections, ordering, and security in the form of TLS. Secure redirects are facilitated by the use of TCP. RPC facilities such REST, Thrift, or GRPC leverage widely deployed models that are popular in SDN. 5.5.4. IP addressing ILA supports single address assignments as well as prefix assignments. ILA will also support strong privacy in addressing. Bogineni, et al. Expires December 31, 2018 [Page 34] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.5.4.1. Singleton address assignment Singleton addresses can use a canonical 64/64 locator/identifier split. Singleton addresses can be assigned by DHCPv6. 5.5.4.2. Network prefix assignment Prefix assignment can be done via SLAAC or DHCPv6-PD. To support /64 prefix assignment with ILA, the ILA identifier can be encoded in the upper sixty-four bits of an address. A level of indirection is used so that ILA transforms the upper sixty four bits to contain both a locator and an index into a locator (ILA-N) specific table. The entry in the table provides the original sixty- four bit prefix so that locator to identifier address transformation can be done. As an example of this scheme, suppose network has a /24 prefix. The identifier address format for /64 assignment might be: +-------------+---------------------|------------------------------+ | 24 bits | 40 bits | 64 bits | +-------------+---------------------|------------------------------+ | Network | Identifier | IID | +-------------+---------------------+------------------------------+ The IID part is arbitrarily assigned by the device, so that is ignored by ILA. All routing, lookups, and transformations (excepting checksum neutral mapping) are based on the upper sixty-four bits. For identifier to locator address transformation, a lookup is done on the upper sixty-four bits. That returns a value that contains a locator and a locator table index. The resulting packet format may be something like: +-------------+---------------------|------------------------------+ | 24 bits | 20 bits | 20 bits | 64 bits | +-------------+---------------------|------------------------------+ | Network | Locator | Loc index | IID | +-------------+---------+-----------+------------------------------+ The packet is forwarded and routed to the ILA-N addressed by locator (/44 route in this case). At the ILA forwarding node, the locator index is used as a key to an ILA-N specific table that returns a 40 bit Identifier. This value is then written in the packet do ILA to identifier address transformation thereby restoring the original destination address. Bogineni, et al. Expires December 31, 2018 [Page 35] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 The locator index is not globally unique, it is specific to each ILA- N. When a node attaches to an ILA-N, an index is chosen so that the table is populated at the ILA-N and the ILA mapping includes the locator and index. When a node detaches from on ILA, it's entry in the table is removed and the index can be reused after a hold-down period to allow stale mappings to be purged. 5.5.4.3. Strong privacy addresses Note that when a /64 is assigned to UEs, the assigned prefix may become a persistent identifier for a device. This is a potential privacy issue. 5.5.5. Traffic engineering ILA is primarily a mechanism for mobility and network virtualization. Transport mechanisms for traffic engineering such as MPLS, network slices, encapsulation, routing based on flow hash(flow label) can be applied independently of ILA. This separation allows any discussion related to transport to be left to operator deployment. 5.5.6. Locator Chaining with ILA ILA transformations can be performed on a hop-by-hop bases. In this manner a packet can be source routed through a sequence of nodes. At each hop a determination is made as to the next hop the packet should visit. The locator for the target is then written into the destination. Eventually, the packet will be forwarded to an ILA forwarding node that will restore the original address before delivery to the final destination. 5.5.7. Security considerations A mobile public infrastructure has many considerations in security as well as privacy. Fundamentally, a system must protect against misdirection for the purposes of hijacking traffic, spoofing, revealing user identities, exposing accurate geo-location, and Denial of Service attacks on the infrastructure. The ILA mapping system contains personally identifiable information (PII) including user identities and geo-location. The information must be safeguarded. An ILA domain is confined to one administrative domain, only trusted parties entities in the domain participate in ILA. There is no concept of a global, public mapping system and UEs in public networks generally do not participate in ILA protocols since they are untrusted. ILA control protocols, include ILA redirects, use TCP. TLS or other protocols can be applied for strong security. Bogineni, et al. Expires December 31, 2018 [Page 36] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Privacy in addressing is a consideration. ILA endeavors to provide a mechanism of address assignment that prevents inference of user identity or location. 5.6. Hybrid ICN (hICN) 5.6.1. Overview hICN Anchorless Mobility Management (hICN-AMM) refers to a novel mobility management approach, introduced in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, (also referred to as Hybrid ICN, or hICN) [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP (conf)using locators as identifiers, (ii) to remove the need for a global mapping system as the one required by locator-identifier separation solutions. 5.6.2. Consumer and Producer mobility In ICN and hICN endpoints can act as consumers and/or producers. Consumers when they emit requests for named data packets (so called Interests), producers when they send data packets in response to consumers request (pull-based transport model). Clearly a node can be a consumer and a producer at the same time (e.g. in a voice conversation). Consumer and producer mobility are handled in a different way due to the pull-based request model. More specifically, consumer mobility is natively supported: consumers pull traffic by sending Interest packets towards named content (wherever produced/stored, the source is a priori unknown by the consumer). Interests are named-based forwarded using the information found in traversed routers' FIBs. In case of consumer mobility, i.e. mobility of the endpoint issuing the requests, selection of a new available output interface and retransmission of not-yet-satisfied Interests is sufficient for data delivery to continue, independently from the underlying change of locators. Consumer mobility is fully anchorless with hICN, and does not incur any signalization nor tunneling overhead. Producer mobility is not natively supported by ICN architecture, rather handled in different ways according to the selected producer mobility management scheme. Bogineni, et al. Expires December 31, 2018 [Page 37] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.6.3. Anchorless mobility support The selected mobility management scheme for hICN is MAP-Me, an anchorless producer mobility management solution originally proposed for ICN [I-D.irtf-icnrg-mapme] [MAPME] and further extended to hICN in [I-D.auge-dmm-hicn-mobility]. MAP-Me belongs to the class of anchorless approaches that relies on scope-limited forwarding updates triggered by producer mobility events to keep locally up-to-date FIB information for a low-latency guaranteed reroute of consumer Interests towards changing location of the producer. Forwarding and mobility management operations in hICN are based only location-independent identifiers, preserving coexistence with IP locators whose existence may be required by non- hICN services and by control/management plane operations specific to the considered network architecture. Signaling of mobility is only required upon producer movements and limited in scope to current-to-previous network hops. Unlike routing updates, it is not necessary to update all routers' FIBs after a node has moved, but only those located on the path between the new and a former position of the producer. Scalability of producer mobility is guaranteed by an efficient and secure FIB update process with minimal and bounded path stretch. The difference w.r.t. to other classes of approaches is that it does not require an anchor neither in forwarding plane (no tunnel, traffic does not need to pass through a specific network node), nor in the control plane (no rendez-vous point, no mapping system). 5.6.4. Benefits The appeal of purely ID-based architectures is that they move Loc/ID split one step further by embedding ID-awareness in the network and transport layer by default and as such completely decoupling data delivery from underlying network connectivity. The resulting mobility management solution is fully anchorless for both consumer and producer mobility. Forwarding is performed directly based on identifiers stored in routers' FIBs and no mapping of ID into locators is required. In this way, purely ID-based architectures remove the need to maintain a global mapping system at scale, and its intrinsic management complexity. Additional benefits brought specifically by ICN principles motivate the consideration of ICN solutions for next generation mobility architectures, like for instance: Bogineni, et al. Expires December 31, 2018 [Page 38] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 o the flexibility of multi-source/multi-path connectionless pull- based transport. An example is the native support for consumer mobility, i.e. the transparent emission of data requests over multiple and varying available network interfaces during node mobility; o the opportunity to define fine-grained per-application forwarding and security policies (in the network, and in-between UPFs); o low-latency and multicast capabilities by means of in-path edge caching; o network-assisted transport. An in depth analysis of benefits originating from the coupling between a purely identifier-based approach and from specific hICN properties can be found in [I-D.auge-dmm-hicn-mobility-deployment-options] along with some illustrative examples. 5.6.5. Deployment considerations *Partial insertion* The benefits previously described can be obtained by an upgrade of only a few selected routers at the network edge. The design of hICN allows the rest of the infrastructure to remain unmodified, and to leverage existing management and monitoring tools. There exists thus a tradeoff between incremental deployment and benefits which are proportionally related to the degree of hICN penetration. *End-to-end deployment* The deployment of an hICN stack in endpoints is the preferred option and offers the full range of benefits. Both the hICN forwarder and the transport stack are available as reference implementations based on the CICN project [CICN]. They are both designed to facilitate insertion on routers and end-user devices thanks to implementation in user space, one targetting high-performance, the other aiming at wide support from major vendors including iOS, Android, Linux, MacOSX and Windows. *Network-contained deployment* It is not always possible nor desirable to affect endpoints, and a deployment fully contained in the network is possible through the deployment of proxies. An example would be the deployment of HTTP proxies at the ingress and egress (resp. first and last UPFs), in Bogineni, et al. Expires December 31, 2018 [Page 39] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 order to benefit from content awareness in the network. Such configuration however reduces the flexibility and dynamic forwarding capabilities in endpoints. In particular, existing transport protocols have limited support for dynamically changing paths or network conditions. Traffic that is not handled though hICN mechanisms can still benefit from the lower overhead and anchorless mobility capabilities coming from the removal of GTP tunnels, as well as dynamic forwarding capabilities that are inherent to the forwarding pipeline. This results from the ability to assign location-independent identifiers to endpoints. It preserves the advantage of removing the mapping system, and of a lightweight FIB update process. No encapsulation is required and packet headers are not modified, which allows the network to have visibility in the source and/or destination identifiers. *hICN in a slice* The use of hICN does not impose any specific slicing of the network. Rather, it can assist a transition of services towards hICN, and/or the coexistence of different hICN deployment options. As an example of use of hICN in a slice, a service provider might for instance decide to use an hICN-enabled slice dedicated to video delivery, with appropriate mobility management, and dedicated hICN nodes with appropriate caching/forwarding strategies at places aggregating considerable number of user requests. 5.6.6. hICN with SRv6 The association of hICN with other user planes technologies, such as SRv6, is investigated as a possibility to overcome the above- mentioned tradeoff yielding to a selective, yet fully beneficial insertion of hICN in IP networks. This would inherit all SRv6 advantages for underlay (TE, FRR) and service programming (NFV), but also extend the reach of hICN on regular IP routers with SRv6 functionality. One realization consists in creating SRv6 domains in between hICN nodes. The hICN router (through forwarding strategies) would then act as a control plane for SRv6 by specifying the list of SIDs to insert in the packet. Bogineni, et al. Expires December 31, 2018 [Page 40] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 5.6.7. Summary hICN proposes a general purpose network architecture that combines the benefits of a pure-ID architecture with those of ICN. While a full deployment is recommended to make efficient use of available network resources, it is still possible to opt for a partial or phased deployment, with the associated tradeoffs that we have reviewed here. An hICN enabled network offers native offloading capabilities thanks to the anchorless properties resulting from the pure-ID communication scheme. It does so without the need for a third party mapping system, and further requires no change in the 5G architecture nor in its control plane. The architecture will further leverage the incremental insertion of information centric functionalities through proxies or direct insertion in user devices as the technology gets adopted and deployed. 6. Integration into the 5G framework 6.1. Locator based - SRv6 6.1.1. Insertion in N9 interface Existing mobile backhaul employs GTP tunnels to carry user traffic flows in the network. These tunnels are unidirectional, are established via the control plane for a particular QoS level, and run on links between access and the different anchor nodes all the way to DN gateways. The Tunnel Endpoint Id (TEID) field in the GTP tunnel plays a crucial role in stitching the data path between the above mentioned network nodes for a particular user flow. In other words, TEIDs are used to coordinate traffic hand off between different UPFs. In its most basic form, SRv6 can be used as a simple drop-in alternative for GTP tunnels. The control plane in this approach remains the same, and still attempts to establish GTP-U tunnels and communicate TEIDs between the tunnel end points. However, at the next level, SRv6 capable nodes use SIDs to direct user traffic between the UPFs. The simplest option here is to encapsulate the entire GTP frame as a payload within SRv6. This scheme still carries the GTP header as the payload and as such doesn't offer any significant advantage. A much more promising and efficient option however is to use SIDs to carry tunnel related information. This is commonly known as the Bogineni, et al. Expires December 31, 2018 [Page 41] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Traditional Mode for SRv6 support for mobility. Here, TEIDs and other relevant data can be encoded into SRv6 SIDs which can be mapped back to TEID's at the intermediate UPFs thus requiring no changes except at the encapsulation and de-encapsulation points in the UPF chains. Note that this is a direct replacement of GTP by SRv6. It's also worth noting that in this case the MTU overhead in the N9 interface is reduced. [I-D.ietf-dmm-srv6-mobile-uplane] discusses the details of leveraging the existing control plane for distributing GTP tunnel information between the end nodes and employing SRv6 in user plane for UPF connectivity. The document defines a SID structure for conveying TEID, DA, and SA of GTP tunnels, shows how hybrid IPV4/IPV6 networks are supported by this model and in doing so, it paves a migration path toward a full SRv6 user plane. Another alternative that can provide for a smooth migration toward SRv6 data plane between UPFs is via the use of "Tag", and optional TLV fields in SRH. Similar to the previously described method, this approach takes advantage of the existing control plane to deliver GTP tunnel information to the UPF endpoints. "Tag" and optional TLV fields in SRH are then used to encode tunnel information in the SRv6 user plane where the UPFs can determine the TEID etc. by inverting the mapping. In yet another option, GTP tunnel information can be encoded as a separate SID either within the same SRH after the SID that identifies the UPF itself (SRH-UPF) or inside a separate SRH (SRH-GTP). This option resembles the MPLS label stacking mechanism which is widely used in different VPN scenarios. Here, we use one SID to carry traffic to the target UPF and use the other to encode and decode GTP related information. It must be noted that in any of the above mentioned approaches, the ingress UPF in SRv6 domain can insert a SRH containing the list of SIDs that corresponds to all UPFs along the path. Alternatively, UPFs can stack a new SRH on top of the one inserted by the previous one as packets traverse network paths between different pairs of UPFs in the network. 6.1.2. Control Plane considerations SRv6, when applied in Tradditional Mode follows the inteworking model and as such does not require control-plane changes. It still attemps to establish GTP-U tunnels and communicate TEIDs between the tunnel Bogineni, et al. Expires December 31, 2018 [Page 42] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 endpoints. AT the next level of user plane however, SRv6 capable nodes use SIDs to direct user traffic between the UPFs. 6.1.3. Extensions to N3/F1-U/Xn-U interface Although not strictly the object of study by 3GPP, previous solutions can (and would gain to) be extended beyond N9 to cover N3 interface too. The immediate benefit is the complete removal of all GTP tunnels, along with associated mangement complexity and traffic overhead. In particular, this removes the need for internetworking between N3 and N9 technologies, and offers a uniform user plane as recommended in the specification. Potential gains can result for an early handling of traffic right from the RAN and thus possibly closer to the UE. The result is a simpler and lighter architecture, allowing convergence with other non-3GPP accesses. The mobile network would benefit of the application of SRv6 to both, N3 and N9 interfaces. The intrinsic ability of SRv6 to integrate, in a single protocol, the control of the overlay, underlay and NFV implies that if applied to the N3 interface the end-to-end SRv6-based network slice can start on the NodeB itself. In addition, SRv6 could be applied to the F1-U interface for cloud- RAN and TE purposes. 6.1.4. Coexistence with GTP-based architecture An alternative vision, although not recommended, would be to preserve the current architecture as is, and deploy alternative user planes on top. As explained in section 5.3.1, SRv6 can co-exist with the current GTP-based control plane. Additionally, the current control plane can be extended to suport TE as defined in 5.3.2. From a dataplane perspective, SRv6 can coexist on the N9 interface together with GTP-U traffic. This is important towards a slow migration from a GTP-based architecture into different architectures. Bogineni, et al. Expires December 31, 2018 [Page 43] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.2. ID-LOC split 6.2.1. Insertion in N9 interface An ID-LOC network architecture is able to decouple the identity of endpoints (ID) from their location in the network (LOC). Common ID- LOC architectures are based on two main components, ID-LOC data-plane nodes and an ID-LOC mapping system. ID-LOC data-plane nodes act upon received data traffic and perform ID-LOC data-plane operation. The specific operation that these ID- LOC data-plane nodes perform is based on the particular ID-LOC data- plane protocol that they implement. ID-LOC data-plane protocols are usually divided in two categories, (1) those that encapsulate ID- based data-plane packets into LOC-based data-plane packets and (2) those that transform the addresses on the data-plane packets from ID- based addresses to LOC-based addresses. SRv6 and LISP-DP protocols are examples of the former while the ILA protocol is an example of the latter. The ID-LOC mapping system is a database that provides mappings of Identity to Location for ID-LOC data-plane nodes to use. Usually, ID-LOC architectures use an ID-LOC control plane protocol to make available at the data-plane nodes the ID-LOC mappings that they need to operate. Examples of such ID-LOC control plane protocols are LISP-CP and ILAMP, which are discussed later in this section. When integrating ID-LOC architecture into the 5G framework there are several aspects to take into account. One is that the ID-LOC data- plane function needs to be performed in the data-plane path as the packets enter and leave the ID-LOC domain. On option for this is to deploy ID-LOC data-plane nodes adjacent to UPFs to perform the ID-LOC operation on the traffic as it leaves or enters the UPFs (as shown in Fig. Figure 12). In this case the ID-LOC data-plane protocol will be part of the N9 interface along with current GTP. Bogineni, et al. Expires December 31, 2018 [Page 44] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +----+----+ +-------------N4--------+ SMF +--------N4-----------+ | +----+----+ | | | | | +----+----+ | | | ID-LOC | | | | Mapping | ID-LOC | | +------>| System |<--control-plane | | | +----+----+ | | | V V | +---+---+ +----+----+ +----+----+ +---+---+ --N3-+ UPF-A +--N9--+ID-L Node+<--ID-LOC--->+ID-L Node+--N9--+ UPF-B +-N6-- +-------+ GTP +----+----+ data-plane +----+----+ GTP +-------+ Figure 12: 5G Integration with ID-LOC (Interworking model) Another option is to implement the ID-LOC data-plane function directly in the UPFs (as shown in Fig. Figure 13). In this case, these ID-LOC enabled UPFs will directly generate packets encapsulated or transformed and will be able to directly process packets encapsulated or transformed. In this case the ID-LOC protocol will completely replace GTP in the N9 interface. +----+----+ +-------------N4--------+ SMF +--------N4-----------+ | +----+----+ | | | | | +----+----+ | | | ID-LOC | | | | Mapping | ID-LOC | | +------------------->| System |<--control-plane--+ | | | +----+----+ | | | V V | +---+---+ +---+---+ --N3-+ UPF-A +<---------- N9 - ID-LOC data-plane ----------->+ UPF-B +-N6-- +-------+ +-------+ Figure 13: 5G Integration with ID-LOC (Integrated model) Finally, another aspect to consider when integrating the ID-LOC architecture into the 5G framework is that the Mapping System needs to contain the appropriate ID-LOC mappings in coordination with the SMF. In order to do so, the mappings in the Mapping System are populated either by the SMF directly or by the LOC-nodes that should be in synch with the SMF. In the former case, an interface from the SMF to the Mapping System is needed (as shown in Figs. Figure 12 and Figure 13). Bogineni, et al. Expires December 31, 2018 [Page 45] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.2.2. LISP control plane The current LISP control-plane (LISP-CP) specification [I-D.ietf-lisp-rfc6833bis] is data-plane agnostic and can serve as control plane for different data-plane protocols (beyond the LISP data-plane). LISP-CP offers different mechanisms to register, request, notify and update ID-Loc mappings between ID-LOC data-plane elements and the ID-LOC Mapping System. In the sections below we describe how LISP-CP can serve to enable the operation of the ILA data-plane and the SRv6 data-plane. It should be noted that the LISP-CP can run over TCP or UDP. The same signaling and logic applies independently of the transport. Additionally, when running over TCP, the optimizations specified in [I-D.kouvelas-lisp-map-server-reliable-transport] can be applied. 6.2.2.1. LISP-CP for ILA The LISP-CP can serve to resolve the Identifier-to-Locator mappings required for the operation of an ILA data-plane. The required ILA control plane operations of "request/response" and "push" are implemented via the LISP mechanisms defined in [I-D.ietf-lisp-rfc6833bis] and [I-D.ietf-lisp-pubsub] respectively. In addition, the ILA "redirect" operation is implemented via the mapping notifications described in [I-D.ietf-lisp-pubsub] triggered as response to data-plane events. Furthermore, the LISP-CP can also be used to obtain the ILA Identifier when it is not possible to locally derivate it from the endpoint address. These two mapping operations, Endpoint-to- Identifier and Identifier-to-Locator, can be combined into one mapping operation to obtain the ILA Identifier and associated Locators in a single round of signaling. The complete specification of how to use the LISP-CP in conjunction with an ILA data-plane can be found in [I-D.rodrigueznatal-ila-lisp]. 6.2.2.2. LISP-CP for SRv6 The LISP-CP can be used by an ingress SRv6 node to obtain the egress node SRv6 VPN SID and its corresponding SLA associated with such endpoint. Alternatively, an ingress SRv6 node can use the LISP-CP to obtain not only the egress SRv6 VPN segment for a particular endpoint but also the SRv6 SID list to steer the traffic to that egress SRv6 node. Bogineni, et al. Expires December 31, 2018 [Page 46] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 The complete specification of how to use the LISP-CP in conjunction with an SRv6 data-plane can be found in [I-D.rodrigueznatal-lisp-srv6]. 6.2.3. ILA control plane The ILA control plane is composed of mapping protocols that manage and disseminate information about the mapping database. There are two levels of mapping protocols: one used by ILA routers that require the full set of ILA mappings for a domain, and one used by ILA nodes that maintain a caches of mappings. The ILA mapping system is effectively a key/value datastore that maps identifiers to locators. The protocol for sharing mapping information amongst ILA routers can thus be implemented by a distributed database [I-D.herbert-ila-ilamp]. ILA separates the control plane from the user plane, so alternative control plane protocols may be used with a common user plane [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp]. The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA forwarding nodes and ILA mapping routers. The purpose of the protocol is to populate and maintain the ILA mapping cache in forwarding nodes. ILAMP defines redirects, a request/response protocol, and a push mechanism to populate the mapping table. Unlike traditional routing protocols that run over UDP, this protocol is intended to be run over TCP and may be RPC oriented. TCP provides reliability, statefulness implied by established connections, ordering, and security in the form of TLS. Secure redirects are facilitated by the use of TCP. RPC facilities such REST, Thrift, or GRPC leverage widely deployed models that are popular in SDN. 6.2.4. Extensions to N3/F1-U/Xn-U interface While not the main focus of this document, it is worth noting that it is also possible to enable an ID-LOC data-plane over the N3 interface and to instantiate the ID-LOC overlay directly at the NodeB. In this case, the NodeB will implement the functionality of an ID-LOC node, i.e. it will retrieve ID-LOC mappings using an ID-LOC control protocol and will encapsulate/transform ID packets into LOC packets. Bringing the ID-LOC data-plane to the NodeB (closer to the UE) has several advantages: (1) complete removal of GTP tunnels, (2) unified management of the ID-LOC data-plane across the network, (3) improved data-plane latency due to traffic being forwarded to the destination ID-LOC node directly from the NodeB, and (4) lower handover time since the ID-LOC mobility event can start at the NodeB itself. Bogineni, et al. Expires December 31, 2018 [Page 47] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.2.5. Coexistence with GTP-based architecture ID-Locator separation architecture can be implemented by control plane of a dedicated protocol such as LISP, ILA, etc., however, it may cause major impact to the specifications of 3GPP 5GS. The approach, described in [I-D.homma-dmm-5gs-id-loc-coexistence], enables to introduce such ID-Locator separation protocols into 5GS with no or low impacts. It would also support a migration path toward a network which an ID-Locator separation protocol is completely incorporated. This approach establishes an individual domain/slice in which an ID- Locator separation protocol works as packet forwarding mechanism, and divert the appropriate packets (e.g., packets for UE-to-UE communication) to the domain at local/distributed UPFs by using Up-Link Classifier (ULCL). ULCL is a fundamental function of UPF, and it diverts uplink traffic based on filter rules indicated by SMF. The other packets to a central UPF (e.g., packets for Internet access) are forwarded with GTP-U via N9 interface. The architecture is shown in Figure 14. Bogineni, et al. Expires December 31, 2018 [Page 48] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 +-----------------------------+ | SMF +<-------------+ +--+----------------------+---+ | N4 N4 | | | | +--+---+ +--+---+ +-----+ | ---- N3 ---+ dUPF +---N9(GTP-U)---+ cUPF +-N6-+ cDN | | |[ULCL]| | | | | | +--+---+ +------+ +-----+ | | Sync N6 | . . | . . . . . . . . . . . . . . . | +-----+ . +--+---+ +---------+ . | | dDN +-N6-+ ID-L +--ID-LOC CP---+ ID-LOC | . | | | . | Node | | Mapping |<-----------+ +-----+ . | +--ID-LOC UP | System | . . +------+ | +---+-----+ . . | | . . +------+ | | . -N6-+ ID-L +---------+ | . . | Node | | . . | +--ID-LOC CP-------+ . . +--+---+ . . . N6 . . . . . . . . . . . . . . | ID-LOC Domain Figure 14: Architecture of 5GS and ID-LOC Coexistence Coexistence approach allows to use GTP-U or any other forwarding protocol described in this document as user plane mechanism. However, each LOC-Node must be connected to the all other LOC-Nodes, and thus it may cause complexity of path management if you use a protocol which needs session establishment. Regarding to control plane of this approach, every dedicated ID- Locator separation protocol described in this document can be used. For management of mobility of UEs in ID-Locator separation domain, some cooperation between SMF and mapping system is needed. In this approach, a UE is attached to a LOC-Node only when it communicates to another UE or an NF in a dDN. In 5GS, SMF manages sessions, and thus SMF may be required to update mapping database when an UE moves to under another UPF or an NF is moved to another dDN. The impact caused by such cooperation can be reduced by using Naf interface which is defined in 5GS specifications. This approach provides a mechanism for introducing ID-Locator separation architecture into 5GS with no or nominal impact, and achieves optimization of forwarding path and session continuity. Bogineni, et al. Expires December 31, 2018 [Page 49] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Moreover, this can keep scalability on forwarding on down link from cDN/Internet because it can use the current GTP-based mechanism. Meanwhile, this approach causes an extra hop when diverting packets to ID-Locator separation domain, and it may leads to increase of latency. 6.3. ID-based - hICN By operating directly on routers' FIBs for mobility updates, dynamic hop-by-hop forwarding strategies etc., hICN inherits the simplicity of IP forwarding and reuses IP routing protocols for ID prefixes advertisement and routing. In this way it removes the challenges of managing a distributed mapping service at scale (cache update/ refresh, etc.). In addition it remains compatible with the exiting control plane architecture as proposed in the 3GPP standard, with no change required to N1, N2 or N4. MAP-Me anchorless producer mobility management does not imply SMF interaction, but does not exclude neither to use SMF signaling to trigger MAP-Me updates or to handle FIB updates, at the condition to follow the same procedure described for MAP-Me. However, the absence of SMF interaction might be beneficial in case of dense deployments or failure of the central control entities (infrastructure-less communication scenarios) to empower distributed control of local mobility within an area. 6.3.1. Insertion in N9 interface Insertion of hICN in 5G IP infrastructure is facilitated by its design allowing a selective insertion of hICN capabilities in a few network nodes at the edge (no need for pervasive fully hICN network enablement), and to guarantee a transparent interconnection with hICN-unaware IP nodes, without using overlays. The deployment of hICN routers allow to avoid the reliance on GTP tunnels, and to provide an agile transport and native anchorless mobility natively. The resulting protocol stack is showin in Figure 15. We remark that in the protocol layer, hICN is associated to IPv6 PDU layer, transported in N9 directly over L2. Bogineni, et al. Expires December 31, 2018 [Page 50] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 UE 5G-AN N3 UPF N9 UPF N6 | | | +--------+ | | | | App. |--------------------------------------------------------| +--------+ | | +--------+ | | IP PDU | | | | IP PDU | | | (hICN) |---------------------------------------------| (hICN) | | +--------+ +-----------------+ | +-----------------+ | | | | | | |\ relay /| | |\ decap / | | | | | | | \_____________/ |-|-| \_____________/ | | | | | | | | GTP-U | | | GTP-U | | | | | | | | +--------+ | +--------+ | | | | | 5G | | 5G | UDP |-|-| UDP | | | | | | AN |-| AN +--------+ | +--------+ | | | | |protocol| |protocol| IP |-|-| IP | | | | | | layers | | layers +--------+ | +--------+--------+ | +--------+ | | | | | L2 |-|-| L2 | L2 |-|-| L2 | | | | | +--------+ | +--------+--------+ | +--------+ | | | | | L1 |-|-| L1 | L1 |-|-| L1 | | +--------+ +-----------------+ | +-----------------+ | +--------+ | | | | Figure 15: Replacement of N9 interface - Protocol layers 6.3.2. Control plane considerations By operating directly on routersa€™ FIBs for mobility updates, dynamic hop-by-hop forwarding strategies etc., hICN inherits the simplicity of IP forwarding and reuses IP routing protocols for ID prefixes advertisement and routing. In this way it removes the challenges of managing a distributed mapping service at scale (cache update/refresh, etc.). In addition it remains compatible with the exiting control plane architecture as proposed in the 3GPP standard, with no change required to N1, N2 or N4. MAP-Me anchorless producer mobility management does not imply SMF interaction, but does not exclude neither to use SMF signaling to trigger MAP-Me updates or to handle FIB updates, at the condition to follow the same procedure described for MAP-Me. However, the absence of SMF interaction might be beneficial in case of dense deployments or failure of the central control entities (infrastructure-less communication scenarios) to empower distributed control of local mobility within an area. Bogineni, et al. Expires December 31, 2018 [Page 51] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.3.3. Extensions to N3/F1-U/Xn-U interface This option ensures that forwarding beyond the radio access is directly managed through hICN. As a consequence, no additional state nor signaling is required for static and mobile consumers, nor for static producers. The impact of producer mobility is low because of the small number of impacted routers. Dynamic forwarding capabilities are extended in this configuration to the selection of the first UPF, with the potential of additional performance improvement and higher traffic offload because of the deployment of hICN functionalities closer to the UE. A significant advantage arises in dense deployments scenarios where it becomes possible to isolate the core network from the locally-management mobility (a design objective of the mobile architecture), while allowing distributed selection of ingress UPFs, and dynamic per- packet load balancing of traffic across them. 6.3.4. Coexistence with GTP-based architecture This section discusses the insertion of hICN-AMM in an unmodified 3GPP 5G reference architecture, where GTP tunnels are preserved. As previously stated, maintaining GTP tunnels does not allow to overcome limitations of anchor-based approaches. However, a transparent integration of hICN-AMM limits to the minimum deployment costs and already brings advantages over the baseline architecture presented earlier. The first option shares some similarities with the previous situation and proposes to deploy hICN-AMM within Mobile Edge Computing (MEC) platforms. It relies on the local breakout capability introduced in 5G through the UL/CL. This function is used to realize the hICN punting function described in [I-D.muscariello-intarea-hicn], i.e. to identify hICN traffic (Interest and Data packets) and forward it to the local MEC hICN instance. Although it preserves tunnels and anchor points, this option permits an early termination of tunnels and the distribution of hICN capabilities close to the edge like in path caching and rate/loss/congestion control which may be leveraged for efficient low-latency content distribution especially in presence of consumer mobility. The second option consists in the deployment of hICN-AMM as User Plane Function (UPF) inside mobile user plane. It has the advantage of preserving hICN benefits in terms of consumer mobility and flexible transport. A more in depth presentation of those alternative deployments can be found in [I-D.auge-dmm-hicn-mobility-deployment-options]. Bogineni, et al. Expires December 31, 2018 [Page 52] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 6.4. Coexistence of multiple protocols in network slices Slicing is one of the main features in 5G. Several Slices with different requirements can coexist on top of the common network infrastructure. Diverse flows belonging to different 5G slices can be completely disjoint or can share different parts of the network infrastructure. All proposals reviewed in this draft lend themselves well to 5G slicing paradigm, that can assist a transition of services towards these new user plane protocols, or allow the coexistence of different deployment options. Figure 16 illustrates the use of network slices with the different proposals. All categories of approach can coexist in separate slices, so as different deployments of the same approach. We refer to previous sections for more details about the possible configurations for ID-LOC, and limit our discussion here to the possibility for different slices to deploy their own mapping system, or share it as illustrated here. Locator-based ID-LOC split ID-based (GTP, SRv6-T) (LISP, ILSR, ILA, SRv6-E) (hICN) ----+-------------------------------+-----------------------+---------- | | | +---------------------+ +-----------------------+ +--------------------+ | +-------+ Slice #1 | | +----------+ Slice #2 | | +-------+ Slice #4 | | | SMF |---+ GTP | | | Mapping +---+ | | | SMF |---+ hICN | | +--+----+ | | | +---+-----++ | | | +--+----+ | AMM | | N4 | | N4 | | | | | | | N4 | | N4 | | +--+--+ +--+----+ | | +---+---+ | +--+----+ | | +--+--+ +--+----+ | | | UPF | | UPF | | | | LOC-A | | | LOC-B | | | | UPF | | UPF | | | +-----+ +-------+ | | +-------+ | +-------+ | | +-----+ +-------+ | +----------- ---------+ +-----------|-----------+ +--------------------+ | | | | | +--+-+ | +--+-+ +--+--+ +--+-+ | DN | | | DN | | MEC | | DN | +----+ | +----+ +-----+ +----+ +------------|------------+ | | Slice #3 | | +------+---+ | | | | | | +---+---+ +-+-----+ | +----+ +-----+ | | LOC-A | | LOC-B | |---| DN | | MEC |--| +-------+ +-------+ | +----+ +-----+ +-------------------------+ Figure 16: Network slices in 5G Bogineni, et al. Expires December 31, 2018 [Page 53] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 *Locator-based* Slice #1 illustrates legacy use of UPFs with GTP in a slice. New approaches can be deployed incrementally or in parts of the network. As demonstrated, the use of network slices can provide domain isolation for this. *ID-LOC split* Slice #2 and #3 support ID-LOC. We illustrate in slice #2 a typical deployment with ILA. Mapping then corresponds to ILA-M, LOC-A to ILA-N and LOC-B to ILA-R. Some number of ILA-Ns and ILA-Rs are deployed. ILA transformations are performed over the N9 interface. ILA-Rs would be deployed at the N6 interface to perform transformations on packets received from a data network. ILA-Ns will be deployed deeper in the network at one side of the N3 interface. ILA-Ns may be supplemented by ILA-Rs that are deployed in the network. ILA-M manages the ILA nodes and mapping database within the slice. Slice #3 shows another slice that supports ILA. In this scenario, the slice is for Mobile Edge Computing. The slice contains ILA-Rs and ILA-Ns, and as illustrated, it may also contain ILA_Hs that run directly on edge computing servers. Note in this example, one ILA-M, and hence one ILA domain, is shared between slice #2 and slice #3. Alternatively, the two slices could each have their own ILA-M and define separate ILA domains. *ID-based* Finally, in slice #4, a slice using hICN-AMM is shown, that does not require any mapping system nor changes in N4. 6.5. Interoperability/Roaming considerations Different situations including roaming scenarios might require the coexistence of different mobility protocols for the same user plane. In Figure 17 and Figure 18, we illustrate two possible deployments for the Home-Routed Roaming Scenario, respectively using a UPF supporting several protocols, and relying on an exchange service point for interconnection. Bogineni, et al. Expires December 31, 2018 [Page 54] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 VPLMN | HPLMN -----+----- N32 --------+-------- | | | +--+--+ | +--+--+ | SMF | | | SMF | +--+--+ | +--+--+ | | | +-------+ | | | | 5G UE | | | | +---+---+ N4 | N4 | | | | +-----+ +--+--+ +--+--+ +----+ +-----| gNB |-----| UPF |-----N9------| UPF |------| DN | +-----+ +-----+ +-----+ +----+ Figure 17: Direct Connectivity between operators with UPFs supporting more than one mobility protocols VPLMN | HPLMN -----+----- N32 --------+-------- | | | +--+--+ | +--+--+ | SMF | | | SMF | +--+--+ | +--+--+ | | | +-------+ | | | | 5G UE | | | | +---+---+ N4 | N4 | | | | +-----+ +--+--+ +-----+ +--+--+ +----+ +-----| gNB |-----| UPF |---| Exc |----| UPF |------| DN | +-----+ +-----+ +-----+ +-----+ +----+ Figure 18: Connectivity between operators using an Exchange that supports multiple mobility protocols 7. Summary This document summarizes the various IETF protocol options for GTP replacement on N9 interface of 3GPP 5G architecture. The document also proposes optional raplacemets of GTP in N3 interface. 8. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [RFC2234]. Bogineni, et al. Expires December 31, 2018 [Page 55] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 9. Security Consideration All 3GPP security aspects apply to all the protocols discussed in this document. 10. IANA Considerations There are no IANA considerations in this specification. 11. Acknowledgement The authors would like to thank Farooq Bari, Devaki Chandramouli, Ravi Guntupalli, Sri Gundavelli, Peter Ashwood Smith, Satoru Matsushima, Michael Mayer, Vina Ermagan, Fabio Maino, Albert Cabellos, Cameron Byrne for reviewing various iterations of the document and for providing content into various sections. 12. References 12.1. Normative References [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, DOI 10.17487/RFC1027, October 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . Bogineni, et al. Expires December 31, 2018 [Page 56] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [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, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . Bogineni, et al. Expires December 31, 2018 [Page 57] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [RFC8112] Farinacci, D., Jain, A., Kouvelas, I., and D. Lewis, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)", RFC 8112, DOI 10.17487/RFC8112, May 2017, . 12.2. Informative References [CICN] Linux Foundation fd.io, "CICN project", 2018. [CP-173160-1] 3rd Generation Partnership Project (3GPP), "New Study Item on User Plane Protocol in 5GC", December 2017. [I-D.auge-dmm-hicn-mobility] Auge, J., Carofiglio, G., Muscariello, L., and M. Papalini, "Anchorless mobility through hICN", draft-auge- dmm-hicn-mobility-00 (work in progress), June 2018. [I-D.auge-dmm-hicn-mobility-deployment-options] Auge, J., Carofiglio, G., Muscariello, L., and M. Papalini, "Anchorless mobility management through hICN (hICN-AMM): Deployment options", draft-auge-dmm-hicn- mobility-deployment-options-00 (work in progress), June 2018. [I-D.farinacci-lisp-mobile-network] Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP for the Mobile Network", draft-farinacci-lisp-mobile- network-03 (work in progress), March 2018. [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and M. Sharif, "SRv6 Network Programming", draft-filsfils- spring-srv6-network-programming-04 (work in progress), March 2018. [I-D.herbert-ila-ilamp] Herbert, T., "Identifier Locator Addressing Mapping Protocol", draft-herbert-ila-ilamp-00 (work in progress), December 2017. Bogineni, et al. Expires December 31, 2018 [Page 58] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [I-D.herbert-ila-mobile] Herbert, T. and K. Bogineni, "Identifier Locator Addressing for Mobile User-Plane", draft-herbert-ila- mobile-01 (work in progress), March 2018. [I-D.herbert-intarea-ila] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", draft-herbert-intarea-ila-01 (work in progress), March 2018. [I-D.hmm-dmm-5g-uplane-analysis] Homma, S., Miyasaka, T., and S. Matsushima, "User Plane Protocol and Architectural Analysis on 3GPP 5G System", 2018. [I-D.homma-dmm-5gs-id-loc-coexistence] Homma, S., Kawakami, K., and A. Akhavain, "Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture", draft-homma-dmm-5gs-id-loc-coexistence-01 (work in progress), May 2018. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-13 (work in progress), May 2018. [I-D.ietf-dmm-srv6-mobile-uplane] Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- uplane-01 (work in progress), March 2018. [I-D.ietf-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-ietf-lisp-eid-mobility-02 (work in progress), May 2018. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. Bogineni, et al. Expires December 31, 2018 [Page 59] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-02 (work in progress), April 2018. [I-D.ietf-lisp-pubsub] Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Subscribe Functionality for LISP", draft-ietf-lisp- pubsub-00 (work in progress), April 2018. [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), March 2018. [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-10 (work in progress), March 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-01 (work in progress), June 2018. [I-D.irtf-icnrg-mapme] Auge, J., Carofiglio, G., Muscariello, L., and M. Papalini, "MAP-Me : Managing Anchorless Mobility in Content Centric Networking", draft-irtf-icnrg-mapme-00 (work in progress), March 2018. [I-D.irtf-icnrg-terminology] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): CCN and NDN Terminology", draft-irtf-icnrg- terminology-00 (work in progress), December 2017. Bogineni, et al. Expires December 31, 2018 [Page 60] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [I-D.kouvelas-lisp-map-server-reliable-transport] Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. Arango, "LISP Map Server Reliable Transport", draft- kouvelas-lisp-map-server-reliable-transport-04 (work in progress), September 2017. [I-D.lapukhov-bgp-ila-afi] Lapukhov, P., "Use of BGP for dissemination of ILA mapping information", draft-lapukhov-bgp-ila-afi-02 (work in progress), October 2016. [I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J., and M. Papalini, "Hybrid Information-Centric Networking", draft- muscariello-intarea-hicn-00 (work in progress), June 2018. [I-D.rodrigueznatal-ila-lisp] Rodriguez-Natal, A., Ermagan, V., Maino, F., and A. Cabellos-Aparicio, "LISP control-plane for Identifier Locator Addressing (ILA)", draft-rodrigueznatal-ila- lisp-01 (work in progress), April 2018. [I-D.rodrigueznatal-lisp-srv6] Rodriguez-Natal, A., et al., "LISP Control Plane for SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00 (work in progress) , June 2018. [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.xuclad-spring-sr-service-chaining] Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Segment Routing for Service Chaining", draft-xuclad-spring-sr-service- chaining-01 (work in progress), March 2018. [ILACONTROL] Herbert, T., "Identifier Locator Addressing Mapping Protocol draft-herbert-ila-ilamp-00", December 2017. [ILAGRPS] Herbert, T., "Identifier Groups draft-herbert-idgroups- 00", February 2018. Bogineni, et al. Expires December 31, 2018 [Page 61] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [ILAMOTIVE] Herbert, T., "Identifier Locator Addressing: Problem Areas, Motivation, and Use Cases draft-herbert-ila- motivation-00", January 2018. [ILSR-WP] Kurebayashi, R., Ashwood-Smith, P., and D. Farinacci, "Evolving 5G Routing", December 2017. [IRTF-RRG] Li, T., "IRTF Routing Research Group (rrg)", November 2012. [LISP-WG] Halrpen, J. and L. Iannone, "IETF Locator/ID Separation Protocol (lisp) Working Group", June 2018. [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks", IEEE Transactions on Network and Service Management Vol. 15, pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018. [SP-180231-1] 3rd Generation Partnership Project (3GPP), "New Study on Enhancements to the Service-Based 5G System Architecture", March 2018. [TR.29.891-3GPP] 3rd Generation Partnership Project (3GPP), "5G System ? Phase 1, CT WG4 Aspects, 3GPP TR 29.891 v15.0.0", December 2017. [TS.23.203-3GPP] 3rd Generation Partnership Project (3GPP), "Policy and Charging Control Architecture, 3GPP TS 23.203 v2.0.1", December 2017. [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "System ARchitecture for the 5G System; Stage 2, 3GPP TS 23.501, v15.2.0", June 2018. [TS.23.502-3GPP] 3rd Generation Partnership Project (3GPP), "Procedures for 5G System; Stage 2, 3GPP TS 23.502, v15.2.0", June 2018. Bogineni, et al. Expires December 31, 2018 [Page 62] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 [TS.23.503-3GPP] 3rd Generation Partnership Project (3GPP), "Policy and Charging Control System for 5G Framework; Stage 2, 3GPP TS 23.503 v15.2.0", June 2018. [TS.29.244-3GPP] 3rd Generation Partnership Project (3GPP), "Interface between the Control Plane and the User Plane Nodes; Stage 3, 3GPP TS 29.244 v15.2.0", June 2018. [TS.29.281-3GPP] 3rd Generation Partnership Project (3GPP), "GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.3.0", June 2018. [TS.38.300-3GPP] 3rd Generation Partnership Project (3GPP), "NR and NG-RAN Overall Description: Stage 2, 3GPP TS 38.300 v15.2.0", June 2018. [TS.38.401-3GPP] 3rd Generation Partnership Project (3GPP), "NG-RAN: Architecture Description, 3GPP TS 38.401 v15.2.0", June 2018. [TS.38.801-3GPP] 3rd Generation Partnership Project (3GPP), "Study on new radio access technology: Radio access architecture and interfaces", March 2017. [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, N., and X. Zeng, "Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks", Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking - ACM-ICN '16, DOI 10.1145/2984356.2984361, 2016. Authors' Addresses Kalyani Bogineni Verizon Email: kalyani.bogineni@verizon.com Bogineni, et al. Expires December 31, 2018 [Page 63] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Arashmid Akhavain Huawei Canada Research Centre Email: arashmid.akhavain@huawei.com Tom Herbert Quantonium Email: tom@quantonium.net Dino Farinacci lispers.net Email: farinacci@gmail.com Alberto Rodriguez-Natal Cisco Systems, Inc. Email: natal@cisco.com Giovanna Carofiglio Cisco Systems, Inc. Email: gcarofig@cisco.com Jordan Auge Cisco Systems, Inc. Email: jordan.auge@cisco.com Luca Muscariello Cisco Systems, Inc. Email: lumuscar@cisco.com Pablo Camarillo Garvia Cisco Systems, Inc. Email: pcamaril@cisco.com Bogineni, et al. Expires December 31, 2018 [Page 64] Internet-Draft draft-bogineni-dmm-optimized-mobile-up June 2018 Shunsuke Homma NTT Email: homma.shunsuke@lab.ntt.co.jp Bogineni, et al. Expires December 31, 2018 [Page 65]