DMM Working Group U. Chunduri, Ed. Internet-Draft R. Li Intended status: Informational Futurewei Expires: May 7, 2020 S. Bhaskaran Altiostar J. Kaippallimalil Futurewei J. Tantsura Apstra, Inc. L. Contreras Telefonica P. Muley Nokia November 4, 2019 Transport Network aware Mobility for 5G draft-clt-dmm-tn-aware-mobility-05 Abstract This document specifies a framework and a mapping function for 5G mobile user plane with transport network slicing, integrated with Mobile Radio Access and a Virtualized Core Network. The integrated approach is specified in a way to fit into the 5G core network architecture defined in [TS23.501]. It focuses on an optimized mobile user plane functionality with various transport services needed for some of the 5G traffic needing low and deterministic latency, real-time, mission-critical services. This document describes, how this objective is achieved agnostic to the transport underlay used (IPv6, MPLS, IPv4) in various deployments and with a new transport network underlay routing, called Preferred Path Routing (PPR). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 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 Chunduri, et al. Expires May 7, 2020 [Page 1] Internet-Draft Transport Network aware Mobility for 5G November 2019 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 May 7, 2020. Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 6 2.1. XHaul Transport Network . . . . . . . . . . . . . . . . . 7 2.2. Mobile Transport Network Context (MTNC) and Scalability . 8 2.3. Transport Network Function (TNF) . . . . . . . . . . . . 9 2.4. TNF Interfaces . . . . . . . . . . . . . . . . . . . . . 9 2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 10 2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 11 2.7. Functionality for E2E Management . . . . . . . . . . . . 12 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 13 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 14 3.2. Path Steering Support to native IP user planes . . . . . 16 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 16 4. Other TE Technologies Applicability . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 Chunduri, et al. Expires May 7, 2020 [Page 2] Internet-Draft Transport Network aware Mobility for 5G November 2019 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. New Control Plane and User Planes . . . . . . . . . 20 A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 20 Appendix B. PPR with various 5G Mobility procedures . . . . . . 21 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 22 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 23 B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP], [TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a comprehensive set of functions for access mobility, session handling and related functions for subscription management, authentication and policy among others. These network functions (NF) are defined using a service-based architecture (SBA) that allows NFs to expose their functions via an API and common service framework. The architecture also defines slicing aspects where the Network Slice Selection Function (NSSF) assists the Access Mobility Manager (AMF) and Session Management Function (SMF) to assist and select the right entities and resources corresponding to the slice requested by the user equipment (UE). The User Equipment (UE) indicates slice information in the Network Slice Selection Assistance Information (NSSAI) field during session establishment (Attach). The AMF selects the right SMF and the SMF in turn selects the User Plane Functions (UPF) so that the QoS and capabilities requested can be fulfilled. UPFs are the data forwarding entities in the 5GC architecture. The architecture allows the placement of Branching Point (BP) and Uplink Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-AN can be a radio access network or any non-3GPP access network, for example, WLAN. The IP address is anchored by a PDU session anchor UPF (PSA UPF). 5GS allows more than one UPF on the path for a PDU (Protocol Data Unit) session that provides various functionality including session anchoring, uplink classification and branching point for a multihomed IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9 and N3 interface between the various UPF instances and the (R)AN. 3GPP has specified control and user plane aspects in [TS.23.501-3GPP] to provide slice and QoS support. 3GPP has defined three broad slice types to cover enhanced mobile broadband (eMBB) communications, ultra-reliable low latency communications(URLLC) and massive internet of things (mIoT). ATIS [ATIS075] has defined an additional slice type for V2X services. There may be multiple instances of a slice type to satisfy some characteristics like isolation. The slice Chunduri, et al. Expires May 7, 2020 [Page 3] Internet-Draft Transport Network aware Mobility for 5G November 2019 details in 3GPP, ATIS or NGMN do not specify how slice characteristics for QoS, hard /soft isolation, protection and other aspects should be satisfied in IP transport networks. This is explored further in this document. 1.1. Problem Statement [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one of the core capability of 5GC with slice awareness from Radio and 5G Core (5GC) network. The 5G System (5GS) as defined, does not consider the resources and functionalities needed from transport network for the selection of UPF. This is seen as independent functionality and currently not part of 5GS. However, the lack of underlying Transport Network (TN) awareness may lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS various procedures (e.g., session establishment, mobility). Meeting the specific slice characteristics on the N3 and N9 interfaces depends on the IP transport underlay providing these resources and capabilities. This could also lead to the inability in meeting SLAs for real-time, mission-critical or latency sensitive services. 5GS procedures including but not limited to Service Request, PDU Session Establishment, or UE mobility need same service level characteristics from the TN for the Protocols Data Unit (PDU) session, similar to as provided in Radio and 5GC for the various Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP]. The 5GS provides slices to its clients (UEs). The UE's PDU session spans the access network (radio) and N3 and N9 transport segments which have an IP transport underlay. The 5G operator needs to obtain slice capability from the IP transport provider. Several UE sessions that match a slice may be mapped to an IP transport segment. Thus there needs to be a mapping between the slice capability offered to the UE (NSSAI) and what is provided by the IP transport. 1.2. Solution Approach This document specifies an approach to fulfil the needs of 5GS to transport user plane traffic from 5G-AN to UPF for all service continuity modes [TS.23.501-3GPP] in an optimized fashion. This is done by, keeping mobility procedures aware of underlying transport network along with slicing requirements. Section 2 describes in detail on how TN aware mobility can be built irrespective of underlying TN technology used. Using Preferred Path Routing (PPR), applicable to any transport network underlay (IPv6, MPLS and IPv4) is detailed in Section 3. How other IETF TE technologies applicable for this draft is specified in Section 4. At Chunduri, et al. Expires May 7, 2020 [Page 4] Internet-Draft Transport Network aware Mobility for 5G November 2019 the end, Appendix B further describes the applicability and procedures of PPR with 5G SSC modes on N3 and N9 interfaces. 1.3. Acronyms 5QI - 5G QoS Indicator 5G-AN - 5G Access Network AMF - Access and Mobility Management Function (5G) BP - Branch Point (5G) CSR - Cell Site Router DN - Data Network (5G) eMBB - enhanced Mobile Broadband (5G) FRR - Fast ReRoute gNB - 5G NodeB GBR - Guaranteed Bit Rate (5G) GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) LFA - Loop Free Alternatives (IP FRR) mIOT - Massive IOT (5G) MPLS - Multi Protocol Label Switching QFI - QoS Flow ID (5G) PPR - Preferred Path Routing PDU - Protocol Data Unit (5G) PW - Pseudo Wire RQI - Reflective QoS Indicator (5G) SBI - Service Based Interface (5G) SID - Segment Identifier Chunduri, et al. Expires May 7, 2020 [Page 5] Internet-Draft Transport Network aware Mobility for 5G November 2019 SMF - Session Management Function (5G) SSC - Session and Service Continuity (5G) SST - Slice and Service Types (5G) SR - Segment Routing TE - Traffic Engineering ULCL - Uplink Classifier (5G) UPF - User Plane Function (5G) URLLC - Ultra reliable and low latency communications (5G) 2. Transport Network and Slice aware Mobility on N3/N9 Currently specified Control Plane (CP) functions - the AMF, the SMF and the User plane (UP) components 5G-AN (e.g. gNB), UPF with N2, N3, N4, N6 and N9 interfaces are relevant to this document. Other Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, NEF, and AF are not directly relevant for the discussion in this document and one can see the functionalities of these in [TS.23.501-3GPP]. From encapsulation perspective, N3 interface is similar to S1U in 4G/ LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). Unlike S1U, N3 has some additional aspects as there is no bearer concept and no per bearer GTP-U tunnels. Instead, QoS information is carried in the PDU Session Container GTP-U extension header. Chunduri, et al. Expires May 7, 2020 [Page 6] Internet-Draft Transport Network aware Mobility for 5G November 2019 +------+ +-----+ +-------+ +-----+ | NSSF | | NRF | | NWDAF | | PCF | +---+--+ +--+--+ +---+---+ +--+--+ | | | | --+-----+--------+--+-----------+-----+-----+----- | | Service Based Interfaces (SBI) | +-----+--------+ | +--+--+ | +-----+ NSSMF| +--+--+ +-----+ AMF | | | TNF | | | SMF | | +--+--+ | +--+--+ | +--+--+ | +---+----------+ | | |ACTN | | +---+--+ | N2 | +--------|SDN-C |-------+ | | | +--+---+ | +----------+ | |Ns _______ Nn| | N4 | | | ___/ \______|_______|__________|___ | | / | | | \ +------+ +--+---+ IP +-++ +--+---+ +--+----+ +--+ |(R)AN |====|CSR/PE| Backhaul |PE|+++|UP-NF2|+++|PE+UPF2|---|DN| +------+ +------+ +--+ +------+ +-------+ +--+ \___ _____________________________/ Front/ \ / N3 N9 N6 Midhaul +-----+ Figure 1: 5G Service Based Architecture with Transport Network TN Aware Mobility with optimized transport network functionality is explained below. How PPR fits in this framework in detail along with other various TE technologies briefly are in Section 3 and Section 4 respectively. 2.1. XHaul Transport Network Figure 1 depicts IP Xhaul network with SDN-C and CSR/PE (Provider Edge) routers provide IP transport service to 5GS user plane entities 5G-AN (e.g. gNB) and UPF. 5GS architecture with key control and user plane entities and its interaction with the IP transport plane is shown here. When a UE initiates session establishment, it indicates the desired slice type in the S-NSSAI (Specific Network Slice Selection Assistance Information) field. The AMF uses the S-NSSAI, other subscription information and configuration in the NSSF to select the appropriate SMF and the SMF in turn selects UPFs (User Plane Functions) that are able to provide the specified slice resources and capabilities. Some of the slice capabilities along the user plane path between the (R)AM and UPFs (N3, N9 segments) such as Chunduri, et al. Expires May 7, 2020 [Page 7] Internet-Draft Transport Network aware Mobility for 5G November 2019 a low latency path, jitter, protection and priority needs these to be provided by the IP transport network. Interface between (R)AN/5G-AN and CSR includes fronthaul and midhaul part of the transport network. In some cases midhaul can also a layer-2 network. In deployments where virtualized 5G-AN is used, F1U interface with GTP encapsulation is considered between the Distributed Unit (DU) and Centralized Unit (CU). Slice capability required in IP transport networks is estimated and provisioned by the functionality as specified in Section 2.3 (TNF) with support from various other functions such as the Network Data Analytics Function (NWDAF), Network Resource Function (NRF) and Policy Control Function (PCF). Figure 1 depicts the PE router, where transport paths are initiated/terminated can be deployed seperately with UPF or both functionalities can be in the same node. The TNF provisions this in the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP encapsulated user packet from the (R)AN or UPF with the slice information traverses the F1U/N3/N9 segment, the PE router of the IP transport underlay can inspect the slice information and provide the provisioned capabilities. This is elaborated further in Section 2.5. 2.2. Mobile Transport Network Context (MTNC) and Scalability The MTNC represents a slice, QoS configuration for a transport path between two 3GPP user plane functions. The Mobile-Transport Network Context Identifier (MTNC-ID) is generated by the TNF to be unique for each path and per traffic class (including QoS and slice aspects). Thus, there may be more than one MTNC-ID for the same QoS and path if there is a need to provide isolation (slice) of the traffic. It should be noted that MTNC are per class/path and not per user session (nor is it per data path entity). The MTNC-IDs are configured by the TNF to be unique within a provisioning domain. Since the MTNC-IDs are not generated per user flow or session, there is no need for unique MTNC-IDs per flow/session. In addition, since the traffic estimation not performed at the time of session establishment, there is no provisioning delay experienced during session setup. The MTNC-ID space scales as a square of the number sites between which 3GPP user plane functions require paths. If there are T traffic classes across N sites, the number of MTNC-IDs in a fully meshed network is (N*(N-1)/2) * T. For example, if there are 3 traffic classes between 25 sites, there would be at most 900 MTNC- IDs required. Multiple slices for the same QoS class that need to be fully isolated, will add to the MTNC provisioning. An MTNC-ID space of 16 bits (65K+ identifiers) can be expected to be sufficient. Chunduri, et al. Expires May 7, 2020 [Page 8] Internet-Draft Transport Network aware Mobility for 5G November 2019 2.3. Transport Network Function (TNF) Figure 1 shows a view of the functions and interfaces for provisioning the MTNC-IDs. The focus is on provisioning between the 3GPP management plane (NSSMF), transport network (SDN-C) and carrying the MTNC-IDs in PDU packets for the transport network to grant the provisioned resources. In Figure 1, the TNF (logical functionality within the NSSMF) requests the SDN-C in the transport domain to program the TE path using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE) routers and internal routers according to the underlay transport technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming PDU data packets for the MTNC-ID, classifies and provides the VN service provisioned across the transport network. The detailed mechanisms by which the NSSMF provides the MTNC-IDs to the control plane and user plane functions are for 3GPP to specify. Two possible options are outlined below for completeness. The NSSMF may provide the MTNC-IDs to the 3GPP control plane by either providing it to the Session Management Function (SMF), and the SMF in turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU session setup. Alternatively, the user plane functions may request the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case where user plane entities request the TNF/NSSMF to translate the Request and get the MTNC-ID (over interface Ns/Nn). The TNF should be seen as a logical entity that can be part of NSSMF in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use network configuration, policies, history, heuristics or some combination of these to derive traffic estimates that the TNF would use. How these estimates are derived are not in the scope of this document. The focus here is only in terms of how the TNF and SDN-C are programmed given that slice and QoS characteristics across a transport path can be represented by an MTNC-ID. The TNF requests the SDN-C in the transport network to provision paths in the transport domain based on the MTNC-ID. The TNF is capable of providing the MTNC-ID provisioned to control and user plane functions in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID should be part of the 3GPP specifications. 2.4. TNF Interfaces A south bound interface Ns is shown which interacts with the 5G Access Network (e.g. CSR). 'Ns' can use one or more mechanism available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay paths from CSR to PE@UPF. Ns and Nn interfaces can be part of the Chunduri, et al. Expires May 7, 2020 [Page 9] Internet-Draft Transport Network aware Mobility for 5G November 2019 integrated 3GPP architecture, but the specification/ownership of these interfaces SHOULD be left out of scope of 3GPP. A north bound interface 'Nn' is shown from one or more of the transport network nodes (or PE @ ULCL/BP UPF, Anchor Point UPF) to TNF as shown in Figure 1. It would enable learning the TE characteristics of all links and nodes of the network continuously (through BGP-LS [RFC7752] or through a passive IGP adjacency and PCEP [RFC5440]). These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs and UPFs concerned to allow mobility of UEs while associated with one of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. 2.5. Transport Provisioning Functionality of transport provisioning for an engineered IP transport that supports 3GPP slicing and QoS requirements in [TS.23.501-3GPP] is described in this section. During a PDU session setup, the AMF using input from the NSSF selects a network slice and SMF. The SMF with user policy from Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the path of the PDU session. While QoS and slice selection for the PDU session can be applied across the 3GPP control and user plane functions as outlined in Section 2, the IP transport underlay across N3 and N9 segments do not have enough information to apply the resource constraints represented by the slicing and QoS classification. Current guidelines for interconnection with transport networks [IR.34-GSMA] provide an application mapping into DSCP. However, these recommendations do not take into consideration other aspects in slicing like isolation, protection and replication. IP transport networks have their own slice and QoS configuration based on domain policies and the underlying network capability. Transport networks can enter into an agreement for virtual network services (VNS) with client domains using the ACTN [RFC8453] framework. An IP transport network may provide such slice instances to mobile network operators, CDN providers or enterprises for example. The 3GPP mobile network, on the other hand, defines a slice instance for UEs as are the the mobile operator's 'clients'. The Network Slice Selection Management Function (NSSMF) [TS 28.533] that interacts with a TN controller like an SDN-C (that is out of scope of 3GPP). The ACTN VN service can be used across the IP transport networks to provision and map the slice instance and QoS of the 3GPP domain to the IP transport domain. An abstraction that represents QoS and Chunduri, et al. Expires May 7, 2020 [Page 10] Internet-Draft Transport Network aware Mobility for 5G November 2019 slice instance in the mobile domain and mapped to ACTN VN service in the transport domain is represented here as MTNC-IDs. Details of how the MTNC-IDs are derived are upto functions that can estimate the level of traffic demand. The 3GPP network/5GS provides slices instances to its clients (UE) that include resources for radio and mobile core segments. The UE's PDU session spans the access network (radio) and N3 and N9 transport segments which have an IP transport underlay. The 5G operator needs to obtain slice capability from the IP transport provider since these resources are not seen by the 5GS. Several UE sessions that match a slice may be mapped to an IP transport segment. Thus, there needs to be a mapping between the slice capability offered to the UE (NSSAI) and what is provided by the IP transport. When the 3GPP user plane function (5G-AN, UPF) does not terminate the transport underlay protocol (e.g., MPLS), it needs to be carried in the IP protocol header from end-to-end of the mobile transport connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses these scenarios in detail. 2.6. MTNC-ID in the Data Packet When the 3GPP user plane function (5G-AN, UPF) and transport provider edge is on different nodes, the PE router needs to have the means by which to classify the PDU packet. The mapping information is provisioned between the 5G provider and IP transport network and corresponding information should be carried in each IP packet on the N3, N9 interface. To allow the IP transport edge nodes to inspect the transport context information efficiently, it should be carried in an IP header field that is easy to inspect. It may be noted that the N3 and N9 interfaces in 5GS are IP interfaces. Thus, Layer 2 alternatives such as VLAN will fail if there are multiple L2 networks on the N3 or N9 path. Another alternative is to use L3 VPNs. However, in the 5G architecture, there may be a large number of smaller UPFs that are dynamically inserted on path. Adding this VPN information for dynamic UPF insertion is configuration intensive and error prone. GTP (N3, N9 encapsulation header) field extensions offer a possibility, however these extensions are hard for a transport edge router to parse efficiently on a per packet basis. Other IP header fields like DSCP are not suitable as it only conveys the QoS aspects (but not other aspects like isolation, protection, etc.) IPv6 extension headers like FaST, or SRv6 may be options to carry the MTNC-ID when such mechanism is a viable (if complete transport network is IPv6 based). To mininise the protocol changes are required and make this underlay tranport independed (IPv4/IPv6/MPLS/ Chunduri, et al. Expires May 7, 2020 [Page 11] Internet-Draft Transport Network aware Mobility for 5G November 2019 L2), an option is to provision a mapping of MTNC-ID to a UDP port range of the GTP encapsulated user packet. A simple mapping table between the MTNC-ID and the source UDP port number can be configured to ensure that ECMP /load balancing is not affected adversely by encoding the UDP source port with an MTNC-ID mapping. This mapping is configured in 3GPP user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that process MTNC-IDs. PE routers can thus provision a policy based on the source UDP port number (which reflects the mapped MTNC-ID) to underlying transport path and then deliver the QoS/slice resource provisioned in the transport network. The source UDP port that is encoded is the outer IP (corresponding to GTP header) while the inner IP packet (UE payload) is unaltered. 2.7. Functionality for E2E Management With the TNF finctionality in 5GS Service Based Interface, the following additional functionalities are required for end-2-end slice management including the transport network: o The Specific Network Slice Selection Assistance Information (S-NSSAI) of PDU session SHOULD be mapped to the assigned transport VPN and the TE path information for that slice. o For transport slice assignment for various SSTs (eMBB, URLLC, MIoT) corresponding underlay paths need to be created and monitored from each transport end point (CSR and PE@UPF). o During PDU session creation, apart from radio and 5GC resources, transport network resources needed to be verified matching the characteristics of the PDU session traffic type. o The TNF MUST provide an API that takes as input the source and destination 3GPP user plane element address, required bandwidth, latency and jitter characteristics between those user plane elements and returns as output a particular TE path's identifier, that satisfies the requested requirements. o Mapping of PDU session parameters to underlay SST paths need to be done. One way to do this to let the SMF install a Forwarding Action Rule (FAR) in the UPF via N4 with the FAR pointing to a "Network Instance" in the UPF. A "Network Instance" is a logical identifier for an underlying network. The "Network Instance" pointed by the FAR can be mapped to a transport path (through L2/ L3 VPN). FARs are associated with Packet Detection Rule (PDR). PDRs are used to classify packets in the uplink (UL) and the downlink (DL) direction. For UL procedures specified in Section 2.5, Section 2.6 can be used for classifying a packet belonging to a particular slice characteristics. For DL, at a PSA Chunduri, et al. Expires May 7, 2020 [Page 12] Internet-Draft Transport Network aware Mobility for 5G November 2019 UPF, the UE IP address is used to identify the PDU session, and hence the slice a packet belongs to and the IP 5 tuple can be used for identifying the flow and QoS characteristics to be applied on the packet at UPF. If a PE is not co-located at the UPF then mapping to the underlying TE paths at PE happens based on the encapsulated GTP-US packet as specified in Section 2.6. o If any other form of encapsulation (other than GTP-U) either on N3 or N9 corresponding QFI information MUST be there in the encapsulation header. o In some SSC modes Appendix B, if segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then corresponding path characteristics MUST be used. This includes a path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN. o Continuous monitoring of the underlying transport path characteristics should be enabled at the endpoints (technologies for monitoring depends traffic engineering technique used as described in Section 3 and Section 4). If path characteristics are degraded, reassignment of the paths at the endpoints should be performed. For all the affected PDU sessions, degraded transport paths need to be updated dynamically with similar alternate paths. o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn based or N2 based), for target gNB selection, apart from radio resources, transport resources MUST be factored. This enables handling of all PDU sessions from the UE to target gNB and this require co-ordination of gNB, AMF, SMF with the TNF module. Integrating the TNF as part of the 5GS Service Based Interfaces, provides the flexibility to control the allocation of required characteristics from the TN during a 5GS signaling procedure (e.g. PDU Session Establishment). If TNF is seen as part of management plane, this real time flexibility is lost. Changes to detailed signaling to integrate the above for various 5GS procedures as defined in [TS.23.502-3GPP] is beyond the scope of this document. 3. Using PPR as TN Underlay In a network implementing source routing, packets may be transported through the use of Segment Identifiers (SIDs), where a SID uniquely identifies a segment as defined in [I-D.ietf-spring-segment-routing]. Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out all SRv6 features along with a few concerns in Section 5.3.7 of the same document. Those concerns as well as need for underlay agnostic (L2/Ipv4/IPv6/MPLS) TE requirements are addressed by a new XHaul Chunduri, et al. Expires May 7, 2020 [Page 13] Internet-Draft Transport Network aware Mobility for 5G November 2019 routing mechanism called Preferred Path Routing (PPR), of which this section provides an overview. With PPR, the label/PPR-ID refer not to individual segments of which the path is composed, but to the identifier of a path that is deployed on network nodes. The fact that paths and path identifiers can be computed and controlled by a controller, not a routing protocol, allows the deployment of any path that network operators prefer, not just shortest paths. As packets refer to a path towards a given destination and nodes make their forwarding decision based on the identifier of a path, not the identifier of a next segment node, it is no longer necessary to carry a sequence of labels. This results in multiple benefits including significant reduction in network layer overhead, increased performance and hardware compatibility for carrying both path and services along the path. Details of the IGP extensions for PPR are provided here: o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces PPR does not remove GTP-U, unlike some other proposals laid out in [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works with the existing cellular user plane (GTP-U) for both N3 and any approach selected for N9 (encapsulation or no-encapsulation). In this scenario, PPR will only help providing TE benefits needed for 5G slices from transport domain perspective. It does so for any underlying data plane used in the transport network (L2/IPv4/IPv6/ MPLS). This is achieved by: o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in the transport network. For Uplink traffic, the 5G-AN will choose the right PPR-ID of the UPF based on the S-NSSAI the PDU Session belongs to and/or the UDP Source port (corresponds to the MTNC-ID Section 2.5) of the GTP-U encapsulation header. Similarly in the Downlink direction matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the PDU Session belongs to. The table below shows a typical mapping: Chunduri, et al. Expires May 7, 2020 [Page 14] Internet-Draft Transport Network aware Mobility for 5G November 2019 +----------------+------------+------------------+-----------------+ |GTP/UDP SRC PORT| SST | Transport Path | Transport Path | | | in S-NSSAI | Info | Characteristics | +----------------+------------+------------------+-----------------+ | Range Xx - Xy | | | | | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | | values) | (massive | PPR-ID-A | Bit Rate) | | | IOT) | | Bandwidth: Bx | | | | | Delay: Dx | | | | | Jitter: Jx | +----------------+------------+------------------+-----------------+ | Range Yx - Yy | | | | | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | | values) | (ultra-low | PPR-ID-B | Req. | | | latency) | | Bandwidth: By | | | | | Delay: Dy | | | | | Jitter: Jy | +----------------+------------+------------------+-----------------+ | Range Zx - Zy | | | | | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | +----------------+------------+------------------+-----------------+ Figure 2: Mapping of PPR-IDs on N3/N9 o It is possible to have a single PPR-ID for multiple input points through a PPR tree structure separate in UL and DL direction. o Same set of PPRs are created uniformly across all needed 5G-ANs and UPFs to allow various mobility scenarios. o Any modification of TE parameters of the path, replacement path and deleted path needed to be updated from TNF to the relevant ingress points. Same information can be pushed to the NSSF, and/ or SMF as needed. o PPR can be supported with any native IPv4 and IPv6 data/user planes (Section 3.2) with optional TE features (Section 3.3) . As this is an underlay mechanism it can work with any overlay encapsulation approach including GTP-U as defined currently for N3 interface. Chunduri, et al. Expires May 7, 2020 [Page 15] Internet-Draft Transport Network aware Mobility for 5G November 2019 3.2. Path Steering Support to native IP user planes PPR works in fully compatible way with SR defined user planes (SR- MPLS and SRv6) by reducing the path overhead and other challenges as listed in Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the source routing to user planes beyond SR-MPLS and SRv6 i.e., L2, native IPv6 and IPv4 user planes. This helps legacy transport networks to get the immediate path steering benefits and helps in overall migration strategy of the network to the desired user plane. Some of these benefits with PPR can be realized with no hardware upgrade except control plane software for native IPv6 and IPv4 user planes. 3.3. Service Level Guarantee in Underlay PPR also optionally allows to allocate resources that are to be reserved along the preferred path. These resources are required in some cases (for some 5G SSTs with stringent GBR and latency requirements) not only for providing committed bandwidth or deterministic latency, but also for assuring overall service level guarantee in the network. This approach does not require per-hop provisioning and reduces the OPEX by minimizing the number of protocols needed and allows dynamism with Fast-ReRoute (FRR) capabilities. 4. Other TE Technologies Applicability RSVP-TE [RFC3209] provides a lean transport overhead for the TE path for MPLS user plane. However, it is perceived as less dynamic in some cases and has some provisioning overhead across all the nodes in N3 and N9 interface nodes. Also it has another drawback with excessive state refresh overhead across adjacent nodes and this can be mitigated with [RFC8370]. SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal bandwidth reservation or mechanism to guarantee latency on the nodes/ links on SR path. But, SR allows path steering for any flow at the ingress and particular path for a flow can be chosen. Some of the issues around path overhead/tax, MTU issues are documented at Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- MPLS allows reduction of the control protocols to one IGP (with out needing for LDP and RSVP-TE). However, as specified above with PPR (Section 3), in the integrated transport network function (TNF) a particular RSVP-TE path for MPLS Chunduri, et al. Expires May 7, 2020 [Page 16] Internet-Draft Transport Network aware Mobility for 5G November 2019 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to SMF for mapping a particular PDU session to the transport path. 5. Acknowledgements Thanks to Young Lee for discussions on this document including ACTN applicability for the proposed TNF. Thanks to Sri Gundavelli and 3GPP delegates who provided detailed feedback on this document. 6. IANA Considerations This document has no requests for any IANA code point allocations. 7. Security Considerations This document does not introduce any new security issues. 8. Contributing Authors The following people contributed substantially to the content of this document and should be considered co-authors. Xavier De Foy InterDigital Communications, LLC 1000 Sherbrooke West Montreal Canada Email: Xavier.Defoy@InterDigital.com 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [ATIS075] Alliance for Telecommunications Industry Solutions (ATIS), "IOT Categorization: Exploring the Need for Standardizing Additional Network Slices ATIS-I-0000075", September 2019. Chunduri, et al. Expires May 7, 2020 [Page 17] Internet-Draft Transport Network aware Mobility for 5G November 2019 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- lfa-05 (work in progress), October 2018. [I-D.bogineni-dmm-optimized-mobile-user-plane] Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Rodriguez-Natal, A., Carofiglio, G., Auge, J., Muscariello, L., Camarillo, P., and S. Homma, "Optimized Mobile User Plane Solutions for 5G", draft-bogineni-dmm- optimized-mobile-user-plane-01 (work in progress), June 2018. [I-D.chunduri-lsr-isis-preferred-path-routing] Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", draft-chunduri-lsr-isis-preferred-path-routing-04 (work in progress), July 2019. [I-D.chunduri-lsr-ospf-preferred-path-routing] Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. Contreras, "Preferred Path Routing (PPR) in OSPF", draft- chunduri-lsr-ospf-preferred-path-routing-03 (work in progress), May 2019. [I-D.farinacci-lisp-mobile-network] Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP for the Mobile Network", draft-farinacci-lisp-mobile- network-06 (work in progress), September 2019. [I-D.ietf-dmm-5g-uplane-analysis] Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, "User Plane Protocol and Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-5g-uplane-analysis-02 (work in progress), July 2019. [I-D.ietf-dmm-srv6-mobile-uplane] Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., Voyer, D., and C. Perkins, "Segment Routing IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06 (work in progress), September 2019. [I-D.ietf-intarea-gue-extensions] Herbert, T., Yong, L., and F. Templin, "Extensions for Generic UDP Encapsulation", draft-ietf-intarea-gue- extensions-06 (work in progress), March 2019. Chunduri, et al. Expires May 7, 2020 [Page 18] Internet-Draft Transport Network aware Mobility for 5G November 2019 [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. [IR.34-GSMA] GSM Association (GSMA), "Guidelines for IPX Provider Networks (Previously Inter-Service Provider IP Backbone Guidelines, Version 14.0", August 2018. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Chunduri, et al. Expires May 7, 2020 [Page 19] Internet-Draft Transport Network aware Mobility for 5G November 2019 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [TS.23.401-3GPP] 3rd Generation Partnership Project (3GPP), "Procedures for 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.1", December 2017. [TS.23.502-3GPP] 3rd Generation Partnership Project (3GPP), "Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 2017. [TS.23.503-3GPP] 3rd Generation Partnership Project (3GPP), "Policy and Charging Control System for 5G Framework; Stage 2, 3GPP TS 23.503 v1.0.0", December 2017. [TS.28.533-3GPP] 3rd Generation Partnership Project (3GPP), "Management and Orchestration Architecture Framework (Release 15)", June 2018. [TS.29.281-3GPP] 3rd Generation Partnership Project (3GPP), "GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", December 2018. Appendix A. New Control Plane and User Planes A.1. Slice aware Mobility: Discrete Approach In this approach transport network functionality from the 5G-AN to UPF is discrete and 5GS is not aware of the underlying transport network and the resources available. Deployment specific mapping function is used to map the GTP-U encapsulated traffic at the 5G-AN (e.g. gNB) in UL and UPF in DL direction to the appropriate transport Chunduri, et al. Expires May 7, 2020 [Page 20] Internet-Draft Transport Network aware Mobility for 5G November 2019 slice or transport Traffic Engineered (TE) paths. These TE paths can be established using RSVP-TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 with SRH, native IPv6 and native IPv4 underlays. As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the user plane traffic forwarding rules in the UPF. The UPFs have a concept of a "Network Instance" which logically abstracts the underlying transport path. When the SMF creates the packet detection rules (PDR) and forwarding action rules (FAR) for a PDU session at the UPF, the SMF identifies the network instance through which the packet matching the PDR has to be forwarded. A network instance can be mapped to a TE path at the UPF. In this approach, TNF as shown in Figure 1 need not be part of the 5G Service Based Interface (SBI). Only management plane functionality is needed to create, monitor, manage and delete (life cycle management) the transport TE paths/ transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). The management plane functionality also provides the mapping of such TE paths to a network instance identifier to the SMF. The SMF uses this mapping to install appropriate FARs in the UPF. This approach provide partial integration of the transport network into 5GS with some benefits. One of the limitations of this approach is the inability of the 5GS procedures to know, if underlying transport resources are available for the traffic type being carried in PDU session before making certain decisions in the 5G CP. One example scenario/decision could be, a target 5G-AN selection during a N2 mobility event, without knowing if the target 5G-AN is having a underlay transport slice resource for the S-NSSAI and 5QI of the PDU session. The Integrated approach specified below can mitigate this. Appendix B. PPR with various 5G Mobility procedures PPR fulfills the needs of 5GS to transport the user plane traffic from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This is done in keeping the backhaul network at par with 5G slicing requirements that are applicable to Radio and virtualized core network to create a truly end-to-end slice path for 5G traffic. When UE moves across the 5G-AN (e.g. from one gNB to another gNB), there is no transport network reconfiguration required with the approach above. SSC mode would be specified/defaulted by SMF. No change in the mode once connection is initiated and this property is not altered here. Chunduri, et al. Expires May 7, 2020 [Page 21] Internet-Draft Transport Network aware Mobility for 5G November 2019 B.1. SSC Mode1 +--------------+ +---+----+ |NSSMF +-----+ | +----------------+ | AMF | | | TNF | | | SMF | +---+--+-+ | +-+-+-+ | +-+--------------+ N1 | +--------+-+---+ | | | | | | +--------+ N2 +----Ns---+ +-Nn-+ N4 | | | | | + +---+---+ +--++ +-+--+---+ +----+ UE1 |gNB|======|CSR|------N3---- | PE+UPF |-N6--| DN | == +---+ +---+ +--------+ +----+ Figure 3: SSC Mode1 with integrated Transport Slice Function After UE1 moved to another gNB in the same UPF serving area +--------------+ +---+----+ |NSSMF +-----+ | +----------------+ | AMF | | | TNF | | | SMF | +---+--+-+ | +-+-+-+ | +-+--------------+ | +--------+-+---+ | | | | | N2 +----Ns---+ +-Nn-+ N4 | | | | +----+--+ +-+-+ ++--+----+ +----+ |gNB1|======|CSR|------N3-----| PE+UPF |-N6--| DN | +----+ +---+ +---+----+ +----+ | | | | +----+ +--++ | UE1 |gNB2|======|CSR|------N3--------+ == +----+ +---+ Figure 4: SSC Mode1 with integrated Transport Slice Function In this mode, IP address at the UE is preserved during mobility events. This is similar to 4G/LTE mechanism and for respective slices, corresponding PPR-ID (TE Path) has to be assigned to the packet at UL and DL direction. During Xn mobility as shown above, Chunduri, et al. Expires May 7, 2020 [Page 22] Internet-Draft Transport Network aware Mobility for 5G November 2019 source gNB has to additionally ensure transport path's resources from TNF are available at the target gNB apart from radio resources check (at decision and request phase of Xn/N2 mobility scenario). B.2. SSC Mode2 In this case, if IP Address is changed during mobility (different UPF area), then corresponding PDU session is released. No session continuity from the network is provided and this is designed as an application offload and application manages the session continuity, if needed. For PDU Session, Service Request and Mobility cases mechanism to select the transport resource and the PPR-ID (TE Path) is similar to SSC Mode1. B.3. SSC Mode3 In this mode, new IP address may be assigned because of UE moved to another UPF coverage area. Network ensures UE suffers no loss of 'connectivity'. A connection through new PDU session anchor point is established before the connection is terminated for better service continuity. There are two ways in which this happens. o Change of SSC Mode 3 PDU Session Anchor with multiple PDU Sessions. o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU Session. In the first mode, from user plane perspective, the two PDU sessions are independent and the use of PPR-ID by gNB and UPFs is exactly similar to SSC Mode 1 described above. The following paragraphs describe the IPv6 multi-homed PDU session case for SSC Mode 3. Chunduri, et al. Expires May 7, 2020 [Page 23] Internet-Draft Transport Network aware Mobility for 5G November 2019 +--------------+ +---+----+ |NSSMF +-----+ | +----------------+ | AMF | | | TNF | | | SMF | +---+--+-+ | +-+-+-+ | +-+-----------+--+ | | +--------+-+---+ | | N1 | | | | | to-UE+----+ N2 +------Ns---+ +-Nn-+ N4 N4| +---+ | | | | | | | | | +---+ +---++ +--+-------+--+ +---+---+ |gNB|===|CSR |---N3---| PE+BP UPF |-N9--| PE+UPF|-N6-> +---+ +----+ +----------+--+ +-------+ to DN | +----+ +-| DN | N6 +----+ Figure 5: SSC Mode3 and Service Continuity In the uplink direction for the traffic offloading from the Branching Point UPF, packet has to reach to the right exit UPF. In this case packet gets re-encapsulated by the BP UPF (with either GTP-U or the chosen encapsulation) after bit rate enforcement and LI, towards the anchor UPF. At this point packet has to be on the appropriate VPN/PW to the anchor UPF. This mapping is done based on the S-NSSAI the PDU session belongs to and/or with the UDP source port (corresponds to the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR path) of the UPF. If it's a non-MPLS underlay, destination IP address of the encapsulation header would be the mapped PPR-ID (TE path). In the downlink direction for the incoming packet, UPF has to encapsulate the packet (with either GTP-U or the chosen encapsulation) to reach the BP UPF. Here mapping is done based on the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the BP UPF. If it's a non-MPLS underlay, destination IP address of the encapsulation header would be the mapped PPR-ID (TE path). In summary: o Respective PPR-ID on N3 and N9 has to be selected with correct transport characteristics from TNF. o For N2 based mobility SMF has to ensure transport resources are available for N3 Interface to new BP UPF and from there the original anchor point UPF. Chunduri, et al. Expires May 7, 2020 [Page 24] Internet-Draft Transport Network aware Mobility for 5G November 2019 o For Service continuity with multi-homed PDU session same transport network characteristics of the original PDU session (both on N3 and N9) need to be observed for the newly configured IPv6 prefixes. Authors' Addresses Uma Chunduri (editor) Futurewei 2330 Central Expressway Santa Clara, CA 95050 USA Email: umac.ietf@gmail.com Richard Li Futurewei 2330 Central Expressway Santa Clara, CA 95050 USA Email: richard.li@futurewei.com Sridhar Bhaskaran Altiostar Email: sridharb@altiostar.com John Kaippallimalil Futurewei Email: john.kaippallimalil@futurewei.com Jeff Tantsura Apstra, Inc. Email: jefftant.ietf@gmail.com Chunduri, et al. Expires May 7, 2020 [Page 25] Internet-Draft Transport Network aware Mobility for 5G November 2019 Luis M. Contreras Telefonica Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com Praveen Muley Nokia 440 North Bernardo Ave Mountain View, CA 94043 USA Email: praveen.muley@nokia.com Chunduri, et al. Expires May 7, 2020 [Page 26]