INTERNET-DRAFT K. Bogineni Intended Status: Informational Verizon Expires: September 2018 A. Akhavain Huawei Technologies Canada T. Herbert Quantonium D. Farinacci lispers.net A. Rodriguez-Natal Cisco March 5, 2018 Optimized Mobile User Plane Solutions for 5G draft-bogineni-dmm-optimized-mobile-user-plane-00.txt 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 [23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The requirements for the network functions and the relevant interfaces are provided. Reference scenarios and criteria for evaluation of various IETF protocols are provided. 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 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 K. Bogineni Expires September 6, 2018 [Page 1] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction and Problem Statement . . . . . . . . . . . . . . 4 2 Conventions used in this document . . . . . . . . . . . . . . . 4 3 Overview of Existing Architecture and Protocol Stack . . . . . 4 4 Reference Scenario(s) for Evaluation . . . . . . . . . . . . . 14 5 SRv6 Based Solution . . . . . . . . . . . . . . . . . . . . . . 15 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 SRV6 as Drop-In Alternative for GTP-U . . . . . . . . . . . 15 5.3 SRV6 as Drop-In GTP Replacement with TE . . . . . . . . . . 17 5.4 UPF Chaining with SRV6 . . . . . . . . . . . . . . . . . . . 18 5.5 SRV6 and Entropy . . . . . . . . . . . . . . . . . . . . . . 19 5.6 SRV6 and 5G Slicing . . . . . . . . . . . . . . . . . . . . 19 5.7 SRV6 and Lawful Interception in 5G . . . . . . . . . . . . . 20 5.8 SRV6 and Alternative Approaches to Advanced Mobility Support . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.8.1 SRV6 and Locator/ID Separation Paradigm for N9 Interface . . . . . . . . . . . . . . . . . . . . . . . 20 5.8.2 Brief Overview of Locator-ID Separation . . . . . . . . 20 5.8.3 Locator-ID Separation via SRV6 for UPF connectivity . . 21 5.8.3.1 Overlay model with SRV6 Locators . . . . . . . . . . 21 5.8.3.2 SRV6 Capable UPFs and RLOCs . . . . . . . . . . . . 22 5.8.4 Advanced Features in ID-Locator Architecture . . . . . . 23 5.9 Areas of Concern . . . . . . . . . . . . . . . . . . . . . . 23 6 LISP based Solution . . . . . . . . . . . . . . . . . . . . . . 24 K. Bogineni Expires September 6, 2018 [Page 2] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2 LISP Data-Plane . . . . . . . . . . . . . . . . . . . . . . 25 6.3 LISP Control-Plane . . . . . . . . . . . . . . . . . . . . . 25 6.4 LISP Mobility Features . . . . . . . . . . . . . . . . . . . 25 6.5 ILSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.6 LISP Control-Plane with ILA Data-Plane . . . . . . . . . . . 26 7 ILNP Based Solution . . . . . . . . . . . . . . . . . . . . . . 27 8 ILA based Solution . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Overview of ILA . . . . . . . . . . . . . . . . . . . . . . 28 8.2 ILA in the 5G architecture . . . . . . . . . . . . . . . . . 29 8.3 Protocol layering . . . . . . . . . . . . . . . . . . . . . 31 8.4 Control plane . . . . . . . . . . . . . . . . . . . . . . . 32 8.4.1 ILA-M services interface . . . . . . . . . . . . . . . . 32 8.4.2 ILA control plane . . . . . . . . . . . . . . . . . . . 32 8.5 IP addressing . . . . . . . . . . . . . . . . . . . . . . . 33 8.5.1 Singleton address assignment . . . . . . . . . . . . . . 33 8.5.2 Network prefix assignment . . . . . . . . . . . . . . . 33 8.5.3 Strong privacy addresses . . . . . . . . . . . . . . . . 34 8.6 Traffic engineering . . . . . . . . . . . . . . . . . . . . 34 8.7 Locator Chaining with ILA . . . . . . . . . . . . . . . . . 35 8.8 ILA and network slices . . . . . . . . . . . . . . . . . . . 35 8.9 Security considerations . . . . . . . . . . . . . . . . . . 36 9 No Protocol Option . . . . . . . . . . . . . . . . . . . . . . 36 10 Comparison of Protocols . . . . . . . . . . . . . . . . . . . . 36 11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 37 13 Security Considerations . . . . . . . . . . . . . . . . . . . . 37 14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 37 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.1 Normative References . . . . . . . . . . . . . . . . . . . 37 15.2 Informative References . . . . . . . . . . . . . . . . . . 37 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 K. Bogineni Expires September 6, 2018 [Page 3] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 1 Introduction and Problem Statement 3GPP CT4 WG has approved a study item [CT4SID] to study user-plane protocol for N9 in 5GC architecture as specified in TS 23.501 [23501] and TS 23.502 [23502] for Rel-15. This provides an opportunity to investigate potential limits of the existing user plane solution and potential benefits of alternative user plane solutions. 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 comprehensively describes the various protocols and how they can be used in the 3GPP 5G architecture. Specifically Segment Routing v6 (SRv6), Locator Identifier Separation Protocol (LISP) and Identifier Locator Addressing (ILA) are described in the context of the 3GPP 5G architecture for several scenarios: as a replacement of GTP on N9; as a replacement of GTP in the whole system; integrated with transport; used in specific network slices, etc. A comparison of the various protocols is also provided. 2 Conventions used in this document 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. 3 Overview of Existing Architecture and Protocol Stack This section briefly describes the 5G system architecture as specified in 3GPP TS 23.501. The key relevant features for session management and mobility management are: K. Bogineni Expires September 6, 2018 [Page 4] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 - 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. - 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. - Support roaming with both Home routed traffic as well as Local breakout traffic in the visited PLMN. +------+ +------+ +------+ | 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 K. Bogineni Expires September 6, 2018 [Page 5] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 Service Based Interfaces ----+-----+-----+----+----+----+----+--------+-----+-------- | | | | | | | | | +---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ | | NSSF | | | NRF | | | DSF | | | UDM | | NEF | | +-------+ | +-----+ | +-----+ | +-----+ +-----+ | +---+----+ +--+--+ +---+--+ +-------------+--+ | AMF | | PCF | | AUSF | | SMF | +---+--+-+ +-----+ +------+ +-+-----------+--+ N1 | | | +-------+ | | N4 N4 | 5G UE |--+ | | | +---+---+ N2 +-----+-+ +---+---+ +----+ | | +----N3------+ UPF +-N9--+ UPF +--N6--+ DN | | | | ++----+-+ +-------+ +----+ | | | | | | +---+------+-+ +-N9-+ +-----| gNB | +------------+ Figure 2: 5G Services Based Architecture The roaming architectures are depicted in the two figures below. VPLMN | HPLMN ----------+-------+------+------+---- N32 -------+------+---- | | | | | | | +--+--+ +-+-+ +--+--+ +-+-+ | +--+--+ +-+-+ | AMF | |PCF| | SMF | |AF | | | UDM | |PCF| +-+-+-+ +---+ +--+--+ +---+ | +-----+ +---+ N1| | | +-------+ | | N4 | | 5G UE +-+ | | | +---+---+ N2 +-----+--+ | | | | | | | +---+-+ +-+-+ +-+-+ +----+ | +---| gNB |---|UPF|-N9-|UPF|--| DN | | +-----+ +-+-+ +---+ +----+ | Figure 3: Roaming 5G System architecture- local breakout scenario K. Bogineni Expires September 6, 2018 [Page 6] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 VPLMN | HPLMN ----------+------+------+----- N32 --------+-------+------+-----+-- | | | | | | | | +--+--+ +-+-+ +--+--+ | +--+--+ +--+--+ +-+-+ +-+-+ | AMF | |PCF| | SMF | | | SMF | | UDM | |PCF| |AF | +-+-+-+ +---+ +--+--+ | +--+--+ +-----+ +---+ +---+ N1 | | | | +-------+ | | | | | | 5G UE |-+ | | | | +---+---+ N2 N4 | N4 | | | | | +-+---+ +--+--+ +--+--+ +----+ +-----| gNB |-----| UPF |-----N9------| UPF |------| DN | +-----+ +--+--+ +-----+ +----+ Figure 4: Roaming 5G System architecture - home routed scenario Figure 5 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 ---------+------------+------------------+---------------------- | | | +--+--+ +--+--+ +--+--+ | AMF | | SMF | | SMF | +--+-++ +--+--+ +--+--+ N1| | | +-------+ | | N4 N4 | 5G UE |-+ | | | +---+---+ N2 +--+--+ +----+ +-----------+ | | +---| UPF |----| DN | | | | | | +-----+ +----+ | | | +-+---+-+ +--+--+ +--+--+ +----+ +-----| gNB |--------------------| UPF |--N9-| UPF |--| DN | +-------+ +-----+ +-----+ +----+ Figure 5: Non-roaming architecture for multiple PDU Sessions K. Bogineni Expires September 6, 2018 [Page 7] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 Service Based Interfaces ---------+-----------------------+----------------------- | | +--+---+ +--+--+ | AMF | | SMF | +--+-+-+ +--+--+ N1 | | +-------+ | | +------+-------+ | 5G UE |-+ | | | +---+---+ N2 N4 N4 | +-+---+ +--+--+ +--+--+ +----+ +-----| gNB |-------| UPF |----N9--| UPF |----| DN | +-----+ +--+--+ +-----+ +----+ | +--+--+ | DN | +-----+ Figure 6: Non-roaming 5G System architecture for concurrent access to two (e.g. local and central) data networks (single PDU Session option) Figure 6 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. The User plane function (UPF) is the function relevant to this evaluation and the N9 interface between two UPFs [23501]. 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. 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 the 5GS) o Activation and release of the UP connection of an PDU session, K. Bogineni Expires September 6, 2018 [Page 8] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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 o Packet routing & 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 e.g. allowing SMF support for charging, and/or allowing the SMF to initiate a CN initiated deactivation of UP connection of an existing PDU session when the UPF detects that the PDU Session has no user plane data activity for a specified Inactivity period provided by the SMF 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), 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 K. Bogineni Expires September 6, 2018 [Page 9] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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 Packet Filter Set is used in the QoS rules or SDF template to identify a QoS flow. The Packet Filter Set may contain packet filters for the DL direction, the UL direction or packet filters that are applicable to both directions. o Downlink packet buffering and downlink data notification triggering: This includes the support and handling of the ARP 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. - "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." o ARP proxying as specified in IETF RFC 1027 [53] and / or IPv6 Neighbour Solicitation Proxying as specified in IETF RFC 4861 [54] 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) K. Bogineni Expires September 6, 2018 [Page 10] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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, comprising: - Source/destination IP address or IPv6 network prefix - Source / destination port number - Protocol ID of the protocol above IP/Next header type - Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask - Flow Label (IPv6) - Security parameter index Application Identifier: The Application ID is an index to a set of application detection rules configured in UPF In the IP Packet Filter Set: - a value left unspecified in a filter matches any value of the corresponding information in a packet - an IP address or Prefix may be combined with a prefix mask - port numbers may be specified as port ranges For Ethernet PDU session type, the SMF may control UPF traffic detection capabilities based on at least any combination of: PDU session QFI Ethernet Packet Filter Set, comprising: - Source/destination MAC address - EtherType as defined in IEEE 802.3 - Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S- TAG) VID fields as defined in IEEE 802.1Q - Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S- TAG) PCP/DEI fields as defined in IEEE 802.1Q - IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 payload 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. The following information is sent in an encapsulation header over the N3 interface. N9 needs to support that. QFI (QoS Flow Identifier), see subclause 5.7.1 of 3GPP TS 23.501: K. Bogineni Expires September 6, 2018 [Page 11] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 "A QoS Flow ID (QFI) is used to identify a QoS flow in the 5G system. User Plane traffic with the same QFI within a PDU session receives the same traffic forwarding treatment (e.g. scheduling, admission threshold). The QFI is carried in an encapsulation header on N3 (and N9) i.e. without any changes to the e2e packet header. It can be applied to PDUs with different types of payload, i.e. IP packets, non-IP PDUs and Ethernet frames. The QFI shall be unique within a PDU session." The QFI is sent for both downlink and uplink user plane traffic. RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of 3GPP TS 23.501: "When the 5GC determines to activate reflective QoS via U-plane, the SMF shall include a QoS rule including an indication to the UPF via N4 interface to activate User Plane with user plane reflective. When the UPF receives a DL packet matching the QoS rule that contains an indication to activate reflective QoS, the UPF shall include the RQI in the encapsulation header on N3 reference point. The UE creates a UE derived QoS rule when the UE receives a DL packet with a RQI." The RQI is sent for downlink user plane traffic only. 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 3GPP TS 23.501 and subclause 4.14.1 of 3GPP TS 23.502 respectively: " For some other PDU sessions of an UE: Direct the DL User Plane traffic of some QoS flows of the PDU session to the Secondary (respectively Master) RAN Node while the remaining QoS flows of the PDU session are directed to the Master (respectively Secondary) RAN Node. In this case there are, irrespective of the number of QoS Flows, two N3 tunnel terminations at the RAN for such PDU session." " In order to assist the reordering function in the Master RAN node and/or Secondary RAN node, for the QFIs that are switched between Master RAN node and Secondary RAN node, the UPF sends one or more "end marker" packets along with QFI on the old tunnel immediately after switching the tunnel for the QFI. The UPF starts sending downlink packets to the Target RAN." GTPv1-U as defined in 3GPP TS 29.281 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 K. Bogineni Expires September 6, 2018 [Page 12] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 3GPP TS 29.281 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. The protocol stack for the User Plane transport for a PDU session is depicted below in Figure 7. +-----+ | | | | 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: - 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. - 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 K. Bogineni Expires September 6, 2018 [Page 13] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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. - 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 7: User Plane Protocol Stack 4 Reference Scenario(s) for Evaluation Different proposals will be described for the following scenarios: 1. Non-Roaming Scenarios a. UE- Internet Connectivity (mobility cases) b. UE-UE IP Packet Flow (mobility cases) c. UE - 2 DNs with multiple PDU sessions d. UE - 2 DNs single PDU session 2. Roaming Scenarios a. Local Break out b. Home routed Flows will be provided for mobility cases (UE mobility, UPF mobility) and session continuity cases (SSC Mode 1/2/3). 1. UE mobility SSC Mode 1 a. Single UPF b. Multiple UPF 2. UE Mobility SSC Mode 2 a. Single UPF b. Multiple UPF 3. UE Mobility SSC Mode 3 a. Single UPF b. Multiple UPF Each proposal will also describe how network slicing will be supported for the following configurations: o Support for independent slices using GTP and/or other protocol will be covered. Mobility Management will be within each slice. o Support for one UE connected to multiple slices using different mobility protocols will be described. K. Bogineni Expires September 6, 2018 [Page 14] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 The criteria for evaluation will be the ability to support the above scenarios and identifying the impacts to N2, N3, N4, gNB, AMF and SMF. 5 SRv6 Based Solution 5.1 Overview Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing] generalises the source routing paradigm with an ordered list of global and/or nodal instructions (segments) prepended in an SR header in order to either steer traffic flows through the network while confining flow states to the ingress nodes in the SR domains and/or to indicate functions that are performed at specific network locations. The IPV6 realisation of SR (SRV6) defines a SR Header (SRH), see [I- D.ietf-6man-segment-routing-header]. SRV6 encodes segments as IPV6 addresses in the Segment List (SL) of its header. The packet destination address in SRV6 specifies the active segment while an index field in the SRH points to the next active segment in the list. The index field in SRH is decremented as SRV6 progressively forces packet flows through different segments over the IPV6 data plane. The versatility and adaptability of SR combined with IPV6's ample and flexible address space positions SRV6 as a viable data path technology for the next generation of mobile user plane, in particular the 3GPP N9 (UPF to UPF). 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, sparing, rate limiting, and service chaining that are not natively available by GTP. The discussion then focuses on advanced routing with the Identifier/Locator paradigm and shows how SRV6 can be used to realise this model in the mobile back-haul in either an anchored or anchorless mode of operation. 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.2 SRV6 as Drop-In Alternative for GTP-U Existing mobile back-haul employs GTP tunnels to carry user traffic K. Bogineni Expires September 6, 2018 [Page 15] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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. 3GPP uses the term UPF to refer to the variety of functions performing different tasks on user traffic along the data path in 5G networks and suggests the use of GTP tunnels to carry user traffic between these UPFs (N9 interface). The Tunnel 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 user plane, SRV6 capable nodes use SIDs to direct user traffic between the UPFs. The simplest option is to encapsulate the entire GTP frame as a payload within SRV6. However, this scheme still carries the GTP header as the payload and as such doesn't offer significant advantage. A much more promising option however is to use SIDs to carry tunnel related information. 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. [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 data 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 data 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 data plane where the UPFs can determine the TEID etc. by inverting the mapping. K. Bogineni Expires September 6, 2018 [Page 16] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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-G). In this option, SID representing the GTP tunnel information acts as both start and end point of a segment within the UPF. This option resembles the MPLS label stacking mechanism which is widely used in different VPN scenarios. 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. +-------+ +------+ SMF +------+ | +-------+ | N4 N4 | | +-------+ +---+---+ +---+---+ +-------+ | RAN |--N3--| UPF | | UPF |--N6--| DN | +-------+ +---+---+ +---+---+ +-------+ | SRV6 N9 | | carries GTP info. | +---------------------+ Figure 8: SRV6 as Drop-In replacement for GTP-U in 5G 5.3 SRV6 as Drop-In GTP Replacement with TE The previous section discussed using SRV6 as a drop-in replacement for GTP tunnels in existing mobile networks. No new capabilities were introduced by this simple 1 to 1 replacement. We now explore additional possible features once SRV6 has been introduced. Traffic engineering is an integral 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. For loose paths to UPFs, a set of one or more SIDs in SRH's SID list identifies on or more, but not all the intermediate nodes to a particular UPF. Packets then follow the IGP shortest path through the network to each specified intermediate node till they reach the target UPF. K. Bogineni Expires September 6, 2018 [Page 17] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 In the case of strict path to UPFs, SRH contains a set of SIDs representing all the intermediate nodes and links that the packet must visit on its route to a particular UPF. The last SID in the set represents the target UPF itself or the last link to this UPF. Here, SRV6 packet processing at each node invokes the function(s) that is associated with SID[SL], the packet then receives the required treatment and gets forwarded over the SRH's specified path toward the target UPF. 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 data 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 and SRV6 traffic engineering capabilities, network programming concept, and a list of some of the main SR functions. [I-D.ietf-spring-segment-routing] [I-D.ietf-6man-segment-routing-header] [I-D.filsfils-spring-srv6-network-programming]. [draft-gundavelli-dmm-mfa-00.txt] 5.4 UPF Chaining with SRV6 Service or function chaining is another intrinsic feature of SR and its SRV6 derivative. Using this capability, operators can direct user traffic through a set of UPFs where each UPF performs a specific task or executes certain functions on the traffic. UPF chaining is achieved through the use of SIDs in SRV6 in the manner identical to what was described in the previous section regarding SRV6 support for traffic engineering. Generally speaking, 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, packets are then forwarded through the network in K. Bogineni Expires September 6, 2018 [Page 18] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 either loose or explicit mode toward each UPF. Please refer to [I-D.xuclad-spring-sr-service-chaining] for further detail. 5.5 SRV6 and Entropy Ability to provide a good level of entropy is an important aspect of data plane protocols. The TEID field in GTP tunnels if included in network node's hashing algorithms can result in good load balancing. Therefore, any new data plane proposal should be able to deal with entropy in an efficient manner. SRV6 SIDs can easily accommodate entropy at either hop by hop or global level via reserving a set of bits in the SID construct itself; and hence, eliminate the need for a special entropy Segment ID in SRH. Here, the hashing algorithm at different nodes distribute traffic flows based on the SID which has been copied to IPV6 DA field. Alternatively, entropy related information can be encoded as optional TLV field in SRV6's SRH. 5.6 SRV6 and 5G Slicing Slicing is one of the main features in 5G [3GPP 23501]. 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's native features such as TE, Chaining, one-plus-one protection, etc. either in stand-alone or in conjunction with other alternatives for mobility support such as ID-LOC model lend themselves well to 5G slicing paradigm. K. Bogineni Expires September 6, 2018 [Page 19] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 +--+ +--+ +----------------+N1| . . . |Nn+----------------+ | ++-+ +-++ | | | | | +---+---+ | | +---+---+ | UPF-1 | +------+ +------+ | UPF-2 | +---+---+ | | +---+---+ | | Slice-A | | --------------------|-------------------------|---------------------- Slice-B | | +----------+ +----------+ | | +---+---+ +---+---+ | UPF-1'| | UPF-2'| +---+---+ +---+---+ | +--+ +--+ | +----------------+M1| . . . |Mn+----------------+ +--+ +--+ Figure 9: SRV6 TE, Service Chaining, Sparing, and Protection for 5G Slices 5.7 SRV6 and Lawful Interception in 5G To be filled. 5.8 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. 5.8.1 SRV6 and Locator/ID Separation Paradigm for N9 Interface 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 data plane connectivity. 5.8.2 Brief Overview of Locator-ID Separation Traditional routing architecture uses IP addresses as both device identity and its location in the network. Locator-ID Separation model establishes a paradigm in which a device identity and its network location are split into two separate namespaces: End-point Identifiers (EID), and Route Locators (RLOC) that are correlated via K. Bogineni Expires September 6, 2018 [Page 20] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 a control plane, or a dynamic (centralised or distributed) mapping system. RLOCs are tied to network topology. They represent network devices that are reachable via traditional routing. EIDs, on the other hand, represent mobile or stationary devices, functions, etc. that are reachable via different RLOCs based on the network location where they get instantiated, activated or moved. Using this model, as long as EID-RLOC relationship remains up to date, EIDs can easily move between the RLOCs. That is the EID namespace can freely move without any impact to the routing paths and connectivity between the Route Locators. This type of multi encapsulation and routing has been employed in fixed networks (IP, VPN, MPLS, etc.). The use of this paradigm in mobile data plane, therefore, offers an approach that takes advantage of a mature and proven technology to implement the N9 interface for UPF connectivity. 5.8.3 Locator-ID Separation via SRV6 for UPF connectivity 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. Multiple UPFs are allowed to attach to the same Locator. It is also possible for a UPF to connect to multiple Locators. There are several implementation options. The followings highlights a few possibilities. 5.8.3.1 Overlay model with SRV6 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). In either case, the ingress SRV6 Locator uses the DA field in arriving packets to identify the far end Locator (Egress SRV6 Locator) where the target UPF is attached and obtains its associated SID. For GTP encapsulated traffic from UPFs, the ingress SRV6 Locator must also deliver GTP information to the far end Locator. Please see section 5.2. for more information on different methods of conveying GTP information in SRV6 domains. The ingress SRV6 Locator then constructs the SRH and sends the K. Bogineni Expires September 6, 2018 [Page 21] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 traffic through the SRV6 network toward the egress SRV6 Locator. Egress Locator marks the end of the segment and ships the traffic to the target UPF. 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. For inter UPF traffic that doesn't use GTP, the control plane requires some modifications in order to be able to convey endpoint information to interested parties. +----+----+ +----------N4--------+ SMF +--------N4--------+ | +----+----+ | | | | | | +----+----+ | | | ID-Loc | | | +----->| Mapping |<----+ | | | +----+----+ | | | V V | +---+---+ +----+----+ +----+----+ +---+---+ --N3-+ UPF-A +----+ RLOC-A +<---SRV6--->+ RLOC-B +---+ UPF-B +-N6-- +---+---+ +----+----+ +----+----+ +---+---+ <----------------------N9-GTP-----------------------> Figure 10: Overlay Model with SRV6 Locator in 5G 5.8.3.2 SRV6 Capable UPFs and RLOCs In this model, the head end UPF (Ingress UPF) is the ingress node and the entity that constructs the SRH in the SRV6 domain. Here, both UPFs (IDs) and Locators are represented by SIDs in the SRH. The SID list establishes either a partial or the full path to a target or a set of UPFs that traffic is required to traverse. 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. In its simplest form, the SMF using policy information prepares a set of one or more UPFs along the traffic path and distributes this set in the form a SID list to the ingress UPF. This SID list of UPFs is then gets augmented with a set of SIDs identifying the Locators representing the current point of attachment for each UPF along the data path. Alternatively, 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 K. Bogineni Expires September 6, 2018 [Page 22] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 relationship. In yet another approach, the SMF can provide a partial SID list representing the segment between each pair of UPFs to individual UPFs along the path. Regardless of the approach, any changes to UPF's point of attachment must be reflected in the mapping system and communicated to the SMF for distribution to the appropriate set of UPFs. Keeping the mapping system current is essential to proper operation. As long as the mapping database is up-to-date, UPFs can be easily moved in the network. Design of ID-Locator mapping system is beyond the scope of this document. However, experiment with distributed mapping systems offered by today's public clouds has shown very promising results which can be further improved and tailored to mobile network requirements. The following figure shows the use of SRV6 UPFs and RLOCs in 5G. +----+----+ | ID-Loc | +----->+ Mapping | +----+----+ | | | + +<------+ +----+----+ | SMF | +----------N4--------+ +--------N4--------+ | +----+----+ | SID-UA | SID-RA SID-RB | SID-UB +---+---+ +----+----+ +----+----+ +---+---+ --N3-+ UPF-A +-----+ RLOC-A +---------+ RLOC-B +-----+ UPF-B +-N6-- +---+---+ +----+----+ +----+----+ +---+---+ <---------------------N9-SRV6---------------------> Figure 11: SRV6 Capable UPFs and Locators in 5G 5.8.4 Advanced Features in ID-Locator Architecture SRV6's native features such as Traffic Engineering, QoS support, UPF Chaining, etc. can be easily added to ID-Locator support. As it was noted earlier, these features are not readily available by GTP. 5.9 Areas of Concern Support for IPV6 is a precondition for SRV6. Although SRV6 can support hybrid IPV4/IPV6 mobile data 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 K. Bogineni Expires September 6, 2018 [Page 23] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 impact on MTU. Large SRH size can also exert undesirable header tax especially in the case of small payload size. Furthermore, compound SID processing at each node might affect line rate. ID-LOC architecture relies on high performance mapping systems. Distributed mapping systems using some form Distributed Hash Table(DHT) exhibit very promising results. But further investigation is required to ensure mobility requirements in mobile data plane. 6 LISP based Solution +------------------------------------------------------+ | SMF | +-+-----------+- - - - - - - - - - - - - +---+-------+-+ | | Mapping System | | | | +--+----+---------------+--+ | | N4 | | | N4 N4 | | LISP-CP | | | | | | | | | +--+---+ | | +------+ | | +---+--+ | UPF | | | | UPF +-------------+ | UPF | --N3-+------+ | | +------+ | +------+-N6-- | XTR +--LISP-CP-+ +-+ XTR | +--LISP-CP-+ XTR | +--+-+-+ +-+--+-+ +-+-+--+ | | | | | | | +-------LISP-DP-------+ +--------LISP-DP------+ | | | +----------------------LISP-DP---------------------+ Figure 12: LISP in the 5G architecture 6.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], [RFC.8111]. 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 K. Bogineni Expires September 6, 2018 [Page 24] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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. 6.2 LISP Data-Plane 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]. 6.3 LISP Control-Plane 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]. 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. 6.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.ietf- farinacci-lisp-mobile-network]. K. Bogineni Expires September 6, 2018 [Page 25] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 6.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.ietf- farinacci-lisp-mobile-network]. 6.6 LISP Control-Plane with ILA Data-Plane In the LISP WG re-charter of 2016, consensus was reached to separate the data-plane and control-plane aspects of the protocol. 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. In this section we describe how LISP-CP can serve to enable the operation of an ILA data-plane. A similar approach can be followed to use LISP-CP as control-plane for other data-plane protocols (e.g. VXLAN, SRv6, etc). +------------------------------------------------------+ | SMF | +-+-----------+- - - - - - - - - - - - - +---+-------+-+ | | Mapping System | | | | +--+----+---------------+--+ | | N4 | | | N4 N4 | | LISP-CP | | | | | | | | | +--+---+ | | +------+ | | +---+--+ | UPF | | | | UPF +-------------+ | UPF | --N3-+------+ | | +------+ | +------+-N6-- | XTR +--LISP-CP-+ +-+ XTR | +--LISP-CP-+ XTR | +--+-+-+ +-+--+-+ +-+-+--+ | | | | | | | +---------ILA---------+ +----------ILA--------+ | | | +------------------------ILA-----------------------+ Figure 13: LISP-CP + ILA in the 5G architecture Please refer to Section 8 for description of the ILA data-plane. 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]. Below are summarized the major points to take into account when running LISP-CP as control-plane for ILA. o Leveraging on the flexible LISP-CP address encoding defined in [RFC8060], different ILA address types are defined in [I- D.rodrigueznatal-ila-lisp] to carry ILA metadata over the LISP- CP. K. Bogineni Expires September 6, 2018 [Page 26] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 o XTRs can serve as both ILA-Ns (when their map-cache is incomplete) or ILA-Rs (when their map-cache is complete). XTRs serving as ILA-Rs subscribe to the Mapping System to populate their map-cache with all the mappings in the domain (or its shard) using [I-D.rodrigueznatal-lisp-pubsub]. o 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. o The ILA control-plane operations "request/response" and "push" are implemented via the LISP mechanisms defined in [I-D.ietf- lisp-rfc6833bis] and [I-D.rodrigueznatal-lisp-pubsub] respectively. When the Mapping System is co-located with the XTRs serving as ILA-Rs, the ILA "redirect" operation is implemented via the mapping notifications described in [I- D.rodrigueznatal-lisp-pubsub]. o XTRs serving as ILA-Ns can use LISP-CP as described in [I- D.ietf-lisp-rfc6833bis] to register and keep updated in the Mapping System the information regarding their local mappings. o When using ILA as data-plane, the mobility features and benefits discussed in Section 8 and in [I-D.ietf-lisp-eid-mobility] still apply. o As discussed in [I-D.rodrigueznatal-ila-lisp], the LISP-CP can be used not only to resolve ID-Loc mappings but also to obtain the ILA Identifier when it is not possible to locally derivate it from the endpoint address. These two mapping operations can be combined into one to obtain the ILA Identifier and associated locators in a single round of signaling. 7 ILNP Based Solution . 8 ILA based Solution Identifier-Locator Addressing [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. K. Bogineni Expires September 6, 2018 [Page 27] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 8.1 Overview of ILA 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 data plane and control plane. The data 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 data plane o Allows strong privacy in addressing [ADDRPRIV] o Promotes anchorless mobility o No typical tunneling issues (e.g. MTU) or management related to encapsulation o Flexible control plane that splits data & control o Modern "SDN" control protocols (e.g. RPC/TCP) K. Bogineni Expires September 6, 2018 [Page 28] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 o Scale number of nodes to billions for 5G, DC virtualization o Upstream Linux kernel data path [ILAKERNEL] and open source ctrl plane [ILACONTROL]. The ILA data plane protocol is described in [ILA], motivation and problems areas are described in [ILAMOTIVE], ILA in the mobile user- plane is described in detail in [ILAMOBILE]. 8.2 ILA in the 5G architecture ILA is a proposed alternative to GTP-U and encapsulation. It does not require anchors and simplifies both the data plane and control plane. ILA is a general network overlay protocol can be used to meet the requirements of use cases in a converged network. User Plane Functions (UPF) with ILA are lightweight and stateless such that they can be brought up quickly as needed. Figures 13 and 14 depict two architectural options for the use of ILA in a 5G architecture. ILA is logically a network function and ILA interfaces to the 5G control plane via service based interfaces. In this architecture, ILA replaces GTP use over the N9 interface. Identifier address to locator address transformations in the downlink from the data network are done by an ILA-R. Transformations for intra domain traffic can be done by an ILA-N close to the gNB or by an ILA- R in the case of a cache miss. Locator address to identifier address transformation happen at ILA-Ns. ILA could be supported on a gNB. In this case, an ILA-N would be co- resident at a gNB and ILA is used over N3 interface in lieu GTP-U. Figures 14 and 15 depict two options of how ILA can be used in the 5G architecture. The control plane functions can be implemented as standalone network functions or can be implemented with other network functions. The control plane protocol can be implemented as enhancement to N4, as APIs or as independent protocol. Use of ILA in roaming scenarios is still TBD. K. Bogineni Expires September 6, 2018 [Page 29] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 Service Based Interfaces ----+-----+-----+----+----+----+----+--------+-----+-------- | | | | | | | | | +---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ | | NSSF | | | NRF | | | DSF | | | UDM | | NEF | | +-------+ | +-----+ | +-----+ | +-----+ +-----+ | | | | | +---+----+ +--+--+ +---+--+ +-------------+--+ | AMF | | PCF | | AUSF | | ILA-M | +---+--+-+ +-----+ +------+ +-+-----------+--+ +-------+ | | | | | 5G UE |--+ | | | +---+---+ | N2 +-----+----+ +---+---+ +----+ | | +------------| ILA-N |--| ILA-R |----| DN | | | | N3 +-+---+--+-+ +-+-----+ +----+ | | | | | | | | +---+------+-+ +---+ +------+ +-----| gNB | N9 N9 +------------+ Figure 14: ILA in 5G architecture - Option 1 Service Based Interfaces ----+-----+-----+----+----+----+------+----+----+----+--------+-- | | | | | | | | | | | +---+---+ | +--+--+ | +--+--+ | | | | +--+--+ +--+--+ | NSSF | | | NRF | | | DSF | | | | | | UDM | | NEF | +-------+ | +-----+ | +-----+ | | | | +-----+ +-----+ | | | | | | +---+----+ +--+--+ +---+--+ | +--+--+ | | AMF | | PCF | | AUSF | | |ILA-M| | +---+--+-+ +-----+ +------+ | +--+--+ | +-------+ | | | | | 5G UE |--+ | | | +---+---+ | N2 +----+--+ +---+---+ +----+ | | +------------| ILA-N |--| ILA-R |------| DN | | | | N3 ++--+-+-+ +-+-----+ +----+ | | | | | | | | +---+------+-+ +--+ +------+ +-----| gNB | N9 N9 +------------+ Figure 15: ILA in 5G architecture - Option 2 K. Bogineni Expires September 6, 2018 [Page 30] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 Service Based Interfaces ---------+-------+------------------+---------------------- | | | +--+--+ +--+--+ +---+---+ | AMF | | SMF | | ILA-M | +--+-++ +--+--+ +---+---+ N1| | +-------+ | | +-------------+----+ | 5G UE |-+ | | | +---+---+ N2 +---+---+ +----+ +-----------+ | | +--| ILAN/R|----| DN | | | | | | +-------+ +----+ | | | +-+---+-+ +--+--+ +--+--+ +----+ +-----| gNB |--------------------|ILAN |--N9-|ILAR |--| DN | +-------+ +-----+ +-----+ +----+ Figure 16: Non-roaming ILA-based architecture for multiple PDU Sessions Service Based Interfaces ---------+----------+------------+----------- | | | +--+---+ +--+--+ +---+---+ | AMF | | SMF | | ILA-M | +--+-+-+ +--+--+ +---+---+ N1 | | +-------+ | | +------+-------+ | 5G UE |-+ | | | +---+---+ N2 | | | +-+---+ +---+---+ +--+--+ +----+ +-----| gNB |------| ILAN/R|---N9--| ILAR|----| DN | +-----+ +---+---+ +-----+ +----+ | +--+--+ | DN | +-----+ Figure 17: Non-roaming 5G ILA-based System architecture for concurrent access to two (e.g. local and central) data networks (single PDU Session option) 8.3 Protocol layering Figure 3 illustrates the protocol layers of packets packets sent over various data 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. K. Bogineni Expires September 6, 2018 [Page 31] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 ---> ---> ---> 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 18: ILA and protocol layer in 5G 8.4 Control plane ILA-M provides the interface between the 5G services architecture and the common ILA control plane. 8.4.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. 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. 8.4.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. K. Bogineni Expires September 6, 2018 [Page 32] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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 [ILAMP]. ILA separates the control plane from the data plane, so alternative control plane protocols may be used with a common data plane [ILABGP],[ILALISP]. The ILA Mapping Protocol [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. 8.5 IP addressing ILA supports single address assignments as well as prefix assignments. ILA will also support strong privacy in addressing [ADDRPRIV]. 8.5.1 Singleton address assignment Singleton addresses can use a canonical 64/64 locator/identifier split. Singleton addresses can be assigned by DHCPv6. 8.5.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: K. Bogineni Expires September 6, 2018 [Page 33] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 | 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. 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. 8.5.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. [ADDPRIV] describes this problem and suggests some solutions that may be used with ILA. 8.6 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. K. Bogineni Expires September 6, 2018 [Page 34] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 8.7 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. 8.8 ILA and network slices Figure 19 illustrates the use of network slices with ILA. ----+--------------------------------+-------------------- | | +----------------------+ +------------------------+ | +-------+ Slice #1 | | +-----------+ Slice #2 | | | SMF |----+ GTP | | | ILA-M |---+ ILA | | +--+----+ | | | +---------+-+ | | | N4 | | N4 | | | | | | | +--+--+ +--+----+ | | +-------+ | +--+----+ | +----+ | | UPF | | UPF | | | | ILA-N | | | ILA-R | |---| DN | | +-----+ +-------+ | | +-------+ | +-------+ | +----+ +------------ ---------+ +-----------|------------+ | | +--+-+ +------------|-------------+ | DN | | | Slice #3 | +----+ | +------+----+ ILA | | | | | | +-------+ +-------+ | +----+ +-----+ | | ILA-N | | ILA-R | |---| DN | | MEC |--| +-------+ +-------+ | +----+ +-----+ +--------------------------+ Figure 19: ILA and network slices in 5G In this figure, slice #1 illustrates legacy use of UPFs without ILA in a slice. ILA can be deployed incrementally or in parts of the network. As demonstrated, the use of network slices can provide domain isolation for this. Slice #2 supports ILA. 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 K. Bogineni Expires September 6, 2018 [Page 35] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 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. 8.9 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. Privacy in addressing is a consideration. ILA endeavors to provide a mechanism of address assignment that prevents inference of user identity or location. This problem is described in [ADDRPRIV]. 9 No Protocol Option In this option, mobility is handled nomadically by the app. 10 Comparison of Protocols This section will compare the different protocols with reference to how they will support the requirements for UPF and N9 interface; how the various scenarios identified in Sections 3 and 4 will be supported and impacts to other interfaces and functions of the architecture (e.g. N3, N4, SMF, AMF, etc). 11 Summary This document summarized the various IETF protocol options for GTP replacement on N9 interface of 3GPP 5G architecture. K. Bogineni Expires September 6, 2018 [Page 36] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 12 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234]. 13 Security Considerations 14 IANA Considerations 15 References 15.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.2 Informative References [ILA] Herbert, T., and Lapukhov, P., "Identifier Locator Addressing for IPv6" draft-herbert-intarea-ila-00 [ILAMP] Herbert, T., "Identifier Locator Addressing Mapping Protocol" draft-herbert-ila-ilamp-00 [29891] 5G System - Phase 1, CT WG4 Aspects, 3GPP TR 29891 v15.0.0, December 2017 [29244] Interface between the Control Plane and the User Plane Nodes; Stage 3, 3GPP TS 29.244 v15.0.0, December 2017 [29281] GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0, December 2017 [23501] System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.1, December 2017 [23502] Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.0, December 2017 [23503] Policy and Charging Control System for 5G Framework; Stage 2, 3GPP TS 23.503 v1.0.0, December 2017 [38300] NR and NG-RAN Overall Description: Stage 2, 3GPP TS 38.300 v2.0.0, December 2017 K. Bogineni Expires September 6, 2018 [Page 37] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 [38401] NG-RAN: Architecture Description, 3GPP TS 38.401 v1.0.0, December 2017 [CT4SID] Study on User Plane Protocol in 5GC, 3GPP CP-173037, December 2017 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/RFC3513, April 2003, . [RFC4941] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, DOI 10.17487/RFC4641, September 2006, https://www.rfc-editor.org/info/rfc4641 [ILAGRPS] Herbert, T., "Identifier Groups in ILA", To be published [BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA mapping information" draft-lapukhov-bgp-ila-afi-02 [3GPPTS] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502", http://www.3gpp.org/DynaReport/23-series.htm Acknowledgments The author 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, and Cameron Byrne for reviewing various iterations of the document and for providing content into various sections. Authors' Addresses K. Bogineni Verizon Email: kalyani.bogineni@verizon.com A, Akhavain Huawei Technologies Canada Email: arashmid.akhavain@huawei.com T. Herbert Quantonium Email: tom@quantonium.net D. Farinacci lispers.net Email: farinacci@gmail.com A. Rodriguez-Natal Cisco K. Bogineni Expires September 6, 2018 [Page 38] INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018 Email: natal@cisco.com K. Bogineni Expires September 6, 2018 [Page 39]