idnits 2.17.1 draft-clt-dmm-tn-aware-mobility-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CT4SID' is mentioned on line 122, but not defined == Missing Reference: 'RFC 8453' is mentioned on line 475, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-mobile-network' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 808, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-03 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-05 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-02 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-05 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group U. Chunduri, Ed. 3 Internet-Draft R. Li 4 Intended status: Informational Futurewei 5 Expires: January 9, 2020 S. Bhaskaran 6 Altiostar 7 J. Tantsura 8 Apstra, Inc. 9 L. Contreras 10 Telefonica 11 P. Muley 12 Nokia 13 J. Kaippallimalil 14 Futurewei 15 July 8, 2019 17 Transport Network aware Mobility for 5G 18 draft-clt-dmm-tn-aware-mobility-04 20 Abstract 22 This document specifies a framework and a mapping function for 5G 23 mobile user plane with transport network slicing, integrated with 24 Mobile Radio Access and a Virtualized Core Network. The integrated 25 approach is specified in a way to fit into the 5G core network 26 architecture defined in [TS23.501]. 28 It focuses on an optimized mobile user plane functionality with 29 various transport services needed for some of the 5G traffic needing 30 low and deterministic latency, real-time, mission-critical services. 31 This document describes, how this objective is achieved agnostic to 32 the transport underlay used (IPv6, MPLS, IPv4) in various deployments 33 and with a new transport network underlay routing, called Preferred 34 Path Routing (PPR). 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 9, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 78 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 79 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 5 81 2.1. Integrated Approach with TNF in SBI . . . . . . . . . . . 6 82 2.1.1. Transport Network Function and Interfaces . . . . . . 7 83 2.1.2. Functionality for E2E Management . . . . . . . . . . 7 84 2.2. TNF as part of existing 5G Control Function . . . . . . . 9 85 2.2.1. Mobile Transport Network Context and Scalability . . 11 86 2.2.2. MTNC Identifier in the Data Packet . . . . . . . . . 12 87 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 12 88 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 13 89 3.2. Path Steering Support to native IP user planes . . . . . 15 90 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 15 91 4. Other TE Technologies Applicability . . . . . . . . . . . . . 15 92 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 9.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Appendix A. New Control Plane and User Planes . . . . . . . . . 19 100 A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 19 101 Appendix B. PPR with various 5G Mobility procedures . . . . . . 20 102 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 20 103 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 21 104 B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 107 1. Introduction 109 3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 110 [TS.23.502-3GPP] and [TS.23.503-3GPP]. User Plane Functions (UPF) 111 are the data forwarding entities in the 5GC architecture. The 112 architecture allows the placement of Branching Point (BP) and Uplink 113 Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- 114 AN can be a radio access network or any non-3GPP access network, for 115 example, WLAN. The IP address is anchored by a PDU session anchor 116 UPF (PSA UPF). 118 N3, N9 Interfaces: The interface between the BP/ULCL UPF and the PSA 119 UPF is called N9 [TS.23.501-3GPP]. While in REL15, 3GPP has adopted 120 GTP-U for the N9 interface, new user plane protocols along with GTP-U 121 are being investigated for N9 interface in REL16, as part of 122 [CT4SID]. Concerning to this document another relevant interface is 123 N3, which is between the 5G-AN and the UPF. N3 interface is similar 124 to the user plane interface S1U in LTE [TS.23.401-3GPP]. This 125 document: 127 o Do not need architectural change to[TS.23.501-3GPP] to provide 128 3GPP slice, QoS support in transport plane 130 o and can work with any encapsulation (including GTP-U) for the N9 131 interface. 133 1.1. Problem Statement 135 [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one 136 of the core capability of 5GC with slice awareness from Radio and 5G 137 Core (5GC) network. The 5G System (5GS) as defined, do not consider 138 the resources and functionalities needed from transport network for 139 the selection of UPF. This is seen as independent functionality and 140 currently not part of 5GS. 142 However, the lack of underlying Transport Network (TN) awareness may 143 lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS 144 procedures. This could also lead to inability to meet SLAs for real- 145 time, mission-critical or latency sensitive services. 5GS procedures 146 including but not limited to Service Request, PDU Session 147 Establishment, or User Equipment (UE) mobility need same service 148 level characteristics from the TN for the Protocols Data Unit (PDU) 149 session, similar to as provided in Radio and 5GC for the various 150 Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP]. 152 1.2. Solution Approach 154 This document specifies 2 approaches to fulfil the needs of 5GS to 155 transport user plane traffic from 5G-AN to UPF for all service 156 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 157 done by, keeping mobility procedures aware of underlying transport 158 network along with slicing requirements. 160 Section 2 describes in detail on how TN aware mobility can be built 161 irrespective of underlying TN technology used. Using Preferred Path 162 Routing (PPR), applicable to any transport network underlay (IPv6, 163 MPLS and IPv4) is detailed in Section 3. How other IETF TE 164 technologies applicable for this draft is specified in Section 4. At 165 the end, Appendix B further describes the applicability and 166 procedures of PPR with 5G SSC modes on N3 and N9 interfaces. 168 1.3. Acronyms 170 5QI - 5G QoS Indicator 172 5G-AN - 5G Access Network 174 AMF - Access and Mobility Management Function (5G) 176 BP - Branch Point (5G) 178 CSR - Cell Site Router 180 DN - Data Network (5G) 182 eMBB - enhanced Mobile Broadband (5G) 184 FRR - Fast ReRoute 186 gNB - 5G NodeB 188 GBR - Guaranteed Bit Rate (5G) 190 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 192 LFA - Loop Free Alternatives (IP FRR) 193 mIOT - Massive IOT (5G) 195 MPLS - Multi Protocol Label Switching 197 QFI - QoS Flow ID (5G) 199 PPR - Preferred Path Routing 201 PDU - Protocol Data Unit (5G) 203 PW - Pseudo Wire 205 RQI - Reflective QoS Indicator (5G) 207 SBI - Service Based Interface (5G) 209 SID - Segment Identifier 211 SMF - Session Management Function (5G) 213 SSC - Session and Service Continuity (5G) 215 SST - Slice and Service Types (5G) 217 SR - Segment Routing 219 TE - Traffic Engineering 221 ULCL - Uplink Classifier (5G) 223 UPF - User Plane Function (5G) 225 URLLC - Ultra reliable and low latency communications (5G) 227 2. Transport Network and Slice aware Mobility on N3/N9 229 Currently specified Control Plane (CP) functions - the Access and 230 Mobility Management Function (AMF), the Session Management Function 231 (SMF) and the User plane (UP) components gNB, User Plane Function 232 (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to this 233 document. Other Virtualized 5G control plane components NRF, AUSF, 234 PCF, AUSF, UDM, NEF, and AF are not directly relevant for the 235 discussion in this document and one can see the functionalities of 236 these in [TS.23.501-3GPP]. 238 From encapsulation perspective, N3 interface is similar to S1U in 4G/ 239 LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to 240 transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). 242 Unlike S1U, N3 has some additional aspects as there is no bearer 243 concept and no per bearer GTP-U tunnels. Instead, QoS information is 244 carried in the PDU Session Container GTP-U extension header. 246 TN Aware Mobility with optimized transport network functionality is 247 explained below with approaches specified in Section 2.1 and 248 Section 2.2 . How PPR fits in this framework in detail along with 249 other various TE technologies briefly are in Section 3 and Section 4 250 respectively. 252 2.1. Integrated Approach with TNF in SBI 254 Service Based Interfaces (SBI) 255 ----+-----+-----+----+----+-----+----+--------+-----+----+------ 256 | | | | | | | | | | 257 +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ 258 | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | 259 +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ 260 +---+----+ +--+--+ +----++ +--------------+-+ 261 | AMF | | PCF | | TNF | | SMF | 262 +---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ 263 N1 | | | | To | 264 to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 265 | | | | | | 266 +---+---+ +--++ +-+--+---+ +-+-----+ +----+ 267 |gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | 268 +---+ +---+ +-+------+ +-------+ +----+ 269 | +----+ 270 +-| DN | 271 N6 +----+ 273 Figure 1: 5G Service Based Architecture 275 The above diagrams depicts one of the scenarios of the 5G network 276 specified in [TS.23.501-3GPP] and with a new and virtualized control 277 component Transport Network Function (TNF). A Cell Site Router (CSR) 278 is shown connecting to gNB. gNB is an entity in 5G-AN. Though it is 279 shown as a separate block from gNB, in some cases both of these can 280 be co-located. This document concerns with backhaul TN, from CSR to 281 UPF on N3 interface or from Staging UPF to Anchor UPF on N9 282 interface. 284 Network Slice Selection Function (NSSF) as defined in 285 [TS.23.501-3GPP] concerns with multiple aspects including selecting a 286 network slice instance when requested by AMF based on the requested 287 SNSSAI, current location of UE, roaming indication etc. It also 288 notifies NF service consumers (e.g AMF) whenever the status about the 289 slice availability changes. However, the scope is only in 5GC (both 290 control and user plane) and NG Radio Access network including the 291 N3IWF for the non-3GPP access. The network slice instance(s) 292 selected by the NSSF are applicable at a per PDU session granularity. 293 An SMF and UPF are allocated from the selected slice instance during 294 the PDU session establishment procedure. 296 2.1.1. Transport Network Function and Interfaces 298 To assuage the above situation, TNF is described (Figure 1) as part 299 of control plane. This has the view of the underlying transport 300 network with all links and nodes as well as various possible underlay 301 paths with different characteristics. TNF can be seen as supporting 302 PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get 303 the TE and topology information of the underlying IGP network. 305 A south bound interface Ns is shown which interacts with the 5G 306 Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism 307 available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF 308 [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay 309 paths from gNB to UPF. Ns and Nn interfaces can be part of the 310 integrated 3GPP architecture, but the specification/ownership of 311 these interfaces SHOULD be left out of scope of 3GPP. 313 A north bound interface 'Nn' is shown from one or more of the 314 transport network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as 315 shown in Figure 1. It would enable learning the TE characteristics 316 of all links and nodes of the network continuously (through BGP-LS 317 [RFC7752] or through a passive IGP adjacency and PCEP [RFC5440]). 319 These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs 320 and UPFs concerned to allow mobility of UEs while associated with one 321 of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. 323 Proposed TNF as part of the 5GC shown in Figure 1 can be realized 324 using Abstraction and Control of TE Networks (ACTN). ACTN 325 architecture, underlying topology abstraction methods and 326 manageability considerations of the same are detailed in [RFC8453]. 328 2.1.2. Functionality for E2E Management 330 With the TNF in 5GS Service Based Interface, the following additional 331 functionalities are required for end-2-end slice management including 332 the transport network: 334 o The Specific Network Slice Selection Assistance Information 335 (SNSSAI) of PDU session's SHOULD be mapped to the assigned 336 transport VPN and the TE path information for that slice. 338 o For transport slice assignment for various SSTs (eMBB, URLLC, 339 MIoT) corresponding underlay paths need to be created and 340 monitored from each transport end point (gNB/CSR and UPF). 342 o During PDU session creation, apart from radio and 5GC resources, 343 transport network resources needed to be verified matching the 344 characteristics of the PDU session traffic type. 346 o The TNF MUST provide an API that takes as input the source and 347 destination 3GPP user plane element address, required bandwidth, 348 latency and jitter characteristics between those user plane 349 elements and returns as output a particular TE path's identifier, 350 that satisfies the requested requirements. 352 o Mapping of PDU session parameters to underlay SST paths need to be 353 done. One way to do this to let the SMF install a Forwarding 354 Action Rule (FAR) in the UPF via N4 with the FAR pointing to a 355 "Network Instance" in the UPF. A "Network Instance" is a logical 356 identifier for an underlying network. The "Network Instance" 357 pointed by the FAR can be mapped to a transport path (through L2/ 358 L3 VPN). FARs are associated with Packet Detection Rule (PDR). 359 PDRs are used to classify packets in the uplink (UL) and the 360 downlink (DL) direction. For UL GTP-U TEID and/or the QFI marked 361 in the GTPU packet can be used for classifying a packet belonging 362 to a particular slice characteristics. For DL, at a PSA UPF, the 363 UE IP address is used to identify the PDU session, and hence the 364 slice a packet belongs to and the IP 5 tuple can be used for 365 identifying the flow and QoS characteristics to be applied on the 366 packet. 368 o If any other form of encapsulation (other than GTP-U) either on N3 369 or N9 corresponding QFI information MUST be there in the 370 encapsulation header. 372 o In some SSC modes Appendix B, if segmented path (gNB to 373 staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then 374 corresponding path characteristics MUST be used. This includes a 375 path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP 376 UPF to eventual UPF access to DN. 378 o Continuous monitoring of transport path characteristics and 379 reassignment at the endpoints MUST be performed. For all the 380 affected PDU sessions, degraded transport paths need to be updated 381 dynamically with similar alternate paths. 383 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 384 based or N2 based), for target gNB selection, apart from radio 385 resources, transport resources MUST be factored. This enables 386 handling of all PDU sessions from the UE to target gNB and this 387 require co-ordination of gNB, AMF, SMF with the TNF module. 389 Integrating the TNF as part of the 5GS Service Based Interfaces, 390 provides the flexibility to control the allocation of required 391 characteristics from the TN during a 5GS signaling procedure (e.g. 392 PDU Session Establishment). If TNF is seen as part of management 393 plane, this real time flexibility is lost. Changes to detailed 394 signaling to integrate the above for various 5GS procedures as 395 defined in [TS.23.502-3GPP] is beyond the scope of this document. 397 2.2. TNF as part of existing 5G Control Function 399 Another solution approach with TNF in Section 2.1 and transport 400 provisioning for an engineered IP transport that supports 3GPP 401 slicing and QoS requirements in [TS.23.501-3GPP] is described in this 402 section. 404 During a PDU session setup, the 3GPP AMF using input from the NSSF 405 selects a network slice and SMF. The SMF with user policy from 406 Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF 407 on the path of the PDU session. While QoS and slice selection for 408 the PDU session can be applied across the 3GPP control and user plane 409 functions as outlined above, the transport underlay across N3 and N9 410 segments do not have enough information to apply the resource 411 constraints represented by the slicing and QoS classification. 412 Current guidelines for interconnection with transport networks 413 [IR.34-GSMA] provide an application mapping into DSCP. However, 414 apart from problems with classification of encrypted packets, these 415 recommendations do not take into consideration other aspects in 416 slicing like isolation, protection and replication. 418 Transport networks have their own slice and QoS configuration based 419 on domain policies and the underlying network capability. Transport 420 networks can enter into an agreement for virtual network services 421 (VNS) with client domains using the ACTN [RFC8453] framework. The 422 3GPP mobile network, on the other side, defines a Network Slice 423 Selection Management Function (NSSMF) [TS 28.533] that interacts with 424 a TN domain manager (that is out of scope of 3GPP). 426 The ACTN VN service can be used across the 3GPP and transport 427 networks to provision and map between slices, QoS in the two domains. 428 An abstraction that represents QoS and slice information in the 429 mobile domain and mapped to ACTN VN service in the transport domain 430 is represented here as MTNC (Mobile Transport Network Context) 431 identifiers. Details of how the 3GPP domain derives the MTNC 432 identifiers and how it programs it across its control and user plane 433 functions are for 3GPP standards to define. For completeness, some 434 minimal outlines are provided in the description below. 436 When the 3GPP user plane function (gNB, UPF) does not terminate the 437 transport underlay protocol (e.g., MPLS), it needs to be carried in 438 the IP protocol header from end-to-end of the mobile transport 439 connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses 440 these scenarios in detail. 442 Figure 2 shows a view of the functions and interfaces for 443 provisioning the MTNC identifiers. The focus is on provisioning 444 between the 3GPP management plane (NSSMF), transport network (SDN-C) 445 and carrying the MTNC identifiers in PDU packets for the transport 446 network to grant the provisioned resources. 448 +----------------------------------------------------+ 449 | 3GPP Control/Management Plane | 450 | +----------------------------------------|-------+ 451 | | +---------------+ | | 452 | | | +-----+ NSSMF | +---+---+ | 453 | | | | TNF | | | SMF | | 454 | | | +--+--+ | +---+---+ | 455 | | +----|----------+ | | 456 | +------|---------------------------------|-------+ 457 | |ACTN (RFC8453) | 458 | +---+---+ | 459 | | SDN-C +---+ | 460 | +---+---+ | | 461 | 3GPP N2/N4 ___^___ |3GPP N2/N4 462 | _____/ \_____ | 463 | / \ | 464 +---+--+ +--+ IP +--+ +---+--+ 465 |UP-NF1|+++++++++++|PE| Backhaul |PE|+++++++++|UP-NF2| 466 +------+ +--+ +--+ +------+ 467 \_____ _____/ 468 \ / 469 ---v--- 471 Figure 2: 5G Transport Plane Provisioning 473 In Figure 2, the TNF (logical functionality within the NSSMF) 474 requests the SDN-C in the transport domain to program the TE path 475 using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE) 476 routers and internal routers according to the underlay transport 477 technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming 478 PDU data packets for the MTNC identifier, classifies and provides the 479 VN service provisioned across the transport network. 481 The detailed mechanisms by which the NSSMF provides the MTNC 482 identifiers to the control plane and user plane functions are for 483 3GPP to specify. Two possible options are outlined below for 484 completeness. The NSSMF may provide the MTNC identifiers to the 3GPP 485 control plane by either providing it to the Session Management 486 Function (SMF), and the SMF in turn provisions the user plane 487 functions (UP-NF1, UP-NF2) during PDU session setup. Alternatively, 488 the user plane functions may request the MTNC identifiers directly 489 from the NSSMF. 491 In this approach, TNF can be seen as a logical entity that can be 492 part of NSSMF in the 3GPP management plane [TS.28.533-3GPP]. The 493 NSSMF may use network configuration, policies, history, heuristics or 494 some combination of these to derive traffic estimates that the TNF 495 would use. How these estimates are derived are not in the scope of 496 this document. The focus here is only in terms of how the TNF and 497 SDN-C are programmed given that slice and QoS characteristics across 498 a transport path can be represented by an MTNC identifier. The TNF 499 requests the SDN-C in the transport network to provision paths in the 500 transport domain based on the MTNC identifier. The TNF is capable of 501 providing the MTNC identifier provisioned to control and user plane 502 functions in the 3GPP domain. Detailed mechanisms for programming 503 the MTNC identifier should be part of the 3GPP specifications. 505 2.2.1. Mobile Transport Network Context and Scalability 507 The MTNC (Mobile Transport Network Context) represents a slice, QoS 508 configuration for a transport path between two 3GPP user plane 509 functions. The Mobile-Transport Network Context Identifier (MTNC-ID) 510 is generated by the TNF to be unique for each path and per traffic 511 class (including QoS and slice aspects). Thus, there may be more 512 than one MTNC-ID for the same QoS and path if there is a need to 513 provide isolation (slice) of the traffic. It should be noted that 514 MTNC are per class/path and not per user session (nor is it per data 515 path entity). The MTNC identifiers are configured by the TNF to be 516 unique within a provisioning domain. 518 Since the MTNC identifiers are not generated per user flow or 519 session, there is no need for unique MTNC identifiers per flow/ 520 session. In addition, since the traffic estimation not performed at 521 the time of session establishment, there is no provisioning delay 522 experienced during session setup. The MTNC identifier space scales 523 as a square of the number sites between which 3GPP user plane 524 functions require paths. If there are T traffic classes across N 525 sites, the number of MTNC identifiers in a fully meshed network is 526 (N*(N-1)/2) * T. For example, if there are 3 traffic classes between 527 25 sites, there would be at most 900 MTNC identifiers required. 528 Multiple slices for the same QoS class that need to be fully 529 isolated, will add to the MTNC provisioning. An MTNC identifier 530 space of 16 bits (65K+ identifiers) can be expected to be sufficient. 532 2.2.2. MTNC Identifier in the Data Packet 534 When the 3GPP user plane function (gNB, UPF) and transport provider 535 edge are on different nodes, the PE router needs to have the means by 536 which to classify the PDU packet. IP header fields such as DSCP 537 (DiffServ Code Point) or the IPv6 Flow Label do not satisfy the 538 requirement as they are not immutable. 540 Different options for carrying the MTNC identifier in the IP data 541 packet or in the existing user plane overlay like GTP-U 542 [TS.29.281-3GPP] or a new overlay like GUE 543 [I-D.ietf-intarea-gue-extensions] are possible. There are various 544 trade-offs in terms of packet overhead, support in IPv4 and IPv6 545 networks as well as working across legacy and evolving transport 546 networks that need to be considered. These considerations will be 547 addressed in future revisions. 549 3. Using PPR as TN Underlay 551 In a network implementing source routing, packets may be transported 552 through the use of Segment Identifiers (SIDs), where a SID uniquely 553 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 554 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 555 all SRv6 features along with a few concerns in Section 5.3.7 of the 556 same document. Those concerns are addressed by a new backhaul 557 routing mechanism called Preferred Path Routing (PPR), of which this 558 section provides an overview. 560 The label/PPR-ID refer not to individual segments of which the path 561 is composed, but to the identifier of a path that is deployed on 562 network nodes. The fact that paths and path identifiers can be 563 computed and controlled by a controller, not a routing protocol, 564 allows the deployment of any path that network operators prefer, not 565 just shortest paths. As packets refer to a path towards a given 566 destination and nodes make their forwarding decision based on the 567 identifier of a path, not the identifier of a next segment node, it 568 is no longer necessary to carry a sequence of labels. This results 569 in multiple benefits including significant reduction in network layer 570 overhead, increased performance and hardware compatibility for 571 carrying both path and services along the path. 573 Details of the IGP extensions for PPR are provided here: 575 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 577 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 579 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 581 PPR does not remove GTP-U, unlike some other proposals laid out in 582 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 583 with the existing cellular user plane (GTP-U) for both N3 and any 584 approach selected for N9 (encapsulation or no-encapsulation). In 585 this scenario, PPR will only help providing TE benefits needed for 5G 586 slices from transport domain perspective. It does so without adding 587 any additional overhead to the user plane, unlike SR-MPLS or SRv6. 588 This is achieved by: 590 o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in 591 the transport network. For Uplink traffic, the 5G-AN will choose 592 the right PPR-ID of the UPF based on the S-NSSAI the PDU Session 593 belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U 594 encapsulation header. Similarly in the Downlink direction 595 matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the 596 PDU Session belongs to. The table below shows a typical mapping: 598 +----------------+------------+------------------+-----------------+ 599 | QFI (Ranges) | SST | Transport Path | Transport Path | 600 | | in S-NSSAI | Info | Characteristics | 601 +----------------+------------+------------------+-----------------+ 602 | Range Xx - Xy | | | | 603 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 604 | values) | (massive | PPR-ID-A | Bit Rate) | 605 | | IOT) | | Bandwidth: Bx | 606 | | | | Delay: Dx | 607 | | | | Jitter: Jx | 608 +----------------+------------+------------------+-----------------+ 609 | Range Yx - Yy | | | | 610 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 611 | values) | (ultra-low | PPR-ID-B | Req. | 612 | | latency) | | Bandwidth: By | 613 | | | | Delay: Dy | 614 | | | | Jitter: Jy | 615 +----------------+------------+------------------+-----------------+ 616 | Range Zx - Zy | | | | 617 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 618 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 619 +----------------+------------+------------------+-----------------+ 621 Figure 3: QFI Mapping with PPR-IDs on N3/N9 623 o It is possible to have a single PPR-ID for multiple input points 624 through a PPR tree structure separate in UL and DL direction. 626 o Same set of PPRs are created uniformly across all needed 5G-ANs 627 and UPFs to allow various mobility scenarios. 629 o Any modification of TE parameters of the path, replacement path 630 and deleted path needed to be updated from TNF to the relevant 631 ingress points. Same information can be pushed to the NSSF, and/ 632 or SMF as needed. 634 o PPR can be supported with any native IPv4 and IPv6 data/user 635 planes (Section 3.2) with optional TE features (Section 3.3) . As 636 this is an underlay mechanism it can work with any overlay 637 encapsulation approach including GTP-U as defined currently for N3 638 interface. 640 3.2. Path Steering Support to native IP user planes 642 PPR works in fully compatible way with SR defined user planes (SR- 643 MPLS and SRv6) by reducing the path overhead and other challenges as 644 listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or 645 Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR 646 also expands the source routing to user planes beyond SR-MPLS and 647 SRv6 i.e., native IPv6 and IPv4 user planes. 649 This helps legacy transport networks to get the immediate path 650 steering benefits and helps in overall migration strategy of the 651 network to the desired user plane. It is important to note, these 652 benefits can be realized with no hardware upgrade except control 653 plane software for native IPv6 and IPv4 user planes. 655 3.3. Service Level Guarantee in Underlay 657 PPR also optionally allows to allocate resources that are to be 658 reserved along the preferred path. These resources are required in 659 some cases (for some 5G SSTs with stringent GBR and latency 660 requirements) not only for providing committed bandwidth or 661 deterministic latency, but also for assuring overall service level 662 guarantee in the network. This approach does not require per-hop 663 provisioning and reduces the OPEX by minimizing the number of 664 protocols needed and allows dynamism with Fast-ReRoute (FRR) 665 capabilities. 667 4. Other TE Technologies Applicability 669 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 670 for MPLS user plane. However, it is perceived as less dynamic in 671 some cases and has some provisioning overhead across all the nodes in 672 N3 and N9 interface nodes. Also it has another drawback with 673 excessive state refresh overhead across adjacent nodes and this can 674 be mitigated with [RFC8370]. 676 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 677 bandwidth reservation or mechanism to guarantee latency on the nodes/ 678 links on SR path. But, SR allows path steering for any flow at the 679 ingress and particular path for a flow can be chosen. Some of the 680 issues around path overhead/tax, MTU issues are documented at 681 Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- 682 MPLS allows reduction of the control protocols to one IGP (with out 683 needing for LDP and RSVP-TE). 685 However, as specified above with PPR (Section 3), in the integrated 686 transport network function (TNF) a particular RSVP-TE path for MPLS 687 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to 688 SMF for mapping a particular PDU session to the transport path. 690 5. Acknowledgements 692 Thanks to Young Lee for discussions on this document including ACTN 693 applicability for the proposed TNF. Thanks to Sri Gundavelli and 694 3GPP delegates who provided detailed feedback on this document. 696 6. IANA Considerations 698 This document has no requests for any IANA code point allocations. 700 7. Security Considerations 702 This document does not introduce any new security issues. 704 8. Contributing Authors 706 The following people contributed substantially to the content of this 707 document and should be considered co-authors. 709 Xavier De Foy 710 InterDigital Communications, LLC 711 1000 Sherbrooke West 712 Montreal 713 Canada 715 Email: Xavier.Defoy@InterDigital.com 717 9. References 719 9.1. Normative References 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 9.2. Informative References 728 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 729 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 730 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 731 Camarillo, "Topology Independent Fast Reroute using 732 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 733 lfa-05 (work in progress), October 2018. 735 [I-D.bogineni-dmm-optimized-mobile-user-plane] 736 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 737 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 738 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 739 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 740 optimized-mobile-user-plane-01 (work in progress), June 741 2018. 743 [I-D.chunduri-lsr-isis-preferred-path-routing] 744 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 745 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 746 draft-chunduri-lsr-isis-preferred-path-routing-03 (work in 747 progress), May 2019. 749 [I-D.chunduri-lsr-ospf-preferred-path-routing] 750 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 751 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 752 chunduri-lsr-ospf-preferred-path-routing-03 (work in 753 progress), May 2019. 755 [I-D.farinacci-lisp-mobile-network] 756 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 757 for the Mobile Network", draft-farinacci-lisp-mobile- 758 network-05 (work in progress), March 2019. 760 [I-D.ietf-dmm-5g-uplane-analysis] 761 Homma, S., Miyasaka, T., Matsushima, S., and d. 762 daniel.voyer@bell.ca, "User Plane Protocol and 763 Architectural Analysis on 3GPP 5G System", draft-ietf-dmm- 764 5g-uplane-analysis-02 (work in progress), July 2019. 766 [I-D.ietf-dmm-srv6-mobile-uplane] 767 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 768 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 769 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 770 uplane-05 (work in progress), July 2019. 772 [I-D.ietf-intarea-gue-extensions] 773 Herbert, T., Yong, L., and F. Templin, "Extensions for 774 Generic UDP Encapsulation", draft-ietf-intarea-gue- 775 extensions-06 (work in progress), March 2019. 777 [I-D.ietf-spring-segment-routing] 778 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 779 Litkowski, S., and R. Shakir, "Segment Routing 780 Architecture", draft-ietf-spring-segment-routing-15 (work 781 in progress), January 2018. 783 [IR.34-GSMA] 784 GSM Association (GSMA), "Guidelines for IPX Provider 785 Networks (Previously Inter-Service Provider IP Backbone 786 Guidelines, Version 14.0", August 2018. 788 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 789 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 790 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 791 . 793 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 794 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 795 DOI 10.17487/RFC5440, March 2009, 796 . 798 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 799 and A. Bierman, Ed., "Network Configuration Protocol 800 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 801 . 803 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 804 Locator/ID Separation Protocol (LISP)", RFC 6830, 805 DOI 10.17487/RFC6830, January 2013, 806 . 808 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 809 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 810 RFC 7490, DOI 10.17487/RFC7490, April 2015, 811 . 813 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 814 S. Ray, "North-Bound Distribution of Link-State and 815 Traffic Engineering (TE) Information Using BGP", RFC 7752, 816 DOI 10.17487/RFC7752, March 2016, 817 . 819 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 820 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 821 . 823 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 824 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 825 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 826 . 828 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 829 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 830 DOI 10.17487/RFC8453, August 2018, 831 . 833 [TS.23.401-3GPP] 834 3rd Generation Partnership Project (3GPP), "Procedures for 835 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 837 [TS.23.501-3GPP] 838 3rd Generation Partnership Project (3GPP), "System 839 Architecture for 5G System; Stage 2, 3GPP TS 23.501 840 v2.0.1", December 2017. 842 [TS.23.502-3GPP] 843 3rd Generation Partnership Project (3GPP), "Procedures for 844 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 845 2017. 847 [TS.23.503-3GPP] 848 3rd Generation Partnership Project (3GPP), "Policy and 849 Charging Control System for 5G Framework; Stage 2, 3GPP TS 850 23.503 v1.0.0", December 2017. 852 [TS.28.533-3GPP] 853 3rd Generation Partnership Project (3GPP), "Management and 854 Orchestration Architecture Framework (Release 15)", June 855 2018. 857 [TS.29.281-3GPP] 858 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 859 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 860 December 2018. 862 Appendix A. New Control Plane and User Planes 864 A.1. Slice aware Mobility: Discrete Approach 866 In this approach transport network functionality from the 5G-AN to 867 UPF is discrete and 5GS is not aware of the underlying transport 868 network and the resources available. Deployment specific mapping 869 function is used to map the GTP-U encapsulated traffic at the 5G-AN 870 (e.g. gNB) in UL and UPF in DL direction to the appropriate transport 871 slice or transport Traffic Engineered (TE) paths. These TE paths can 872 be established using RSVP-TE [RFC3209] for MPLS underlay, SR 873 [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or 874 PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 875 with SRH, native IPv6 and native IPv4 underlays. 877 As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 878 user plane traffic forwarding rules in the UPF. The UPFs have a 879 concept of a "Network Instance" which logically abstracts the 880 underlying transport path. When the SMF creates the packet detection 881 rules (PDR) and forwarding action rules (FAR) for a PDU session at 882 the UPF, the SMF identifies the network instance through which the 883 packet matching the PDR has to be forwarded. A network instance can 884 be mapped to a TE path at the UPF. In this approach, TNF as shown in 885 Figure 1 need not be part of the 5G Service Based Interface (SBI). 886 Only management plane functionality is needed to create, monitor, 887 manage and delete (life cycle management) the transport TE paths/ 888 transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). 889 The management plane functionality also provides the mapping of such 890 TE paths to a network instance identifier to the SMF. The SMF uses 891 this mapping to install appropriate FARs in the UPF. This approach 892 provide partial integration of the transport network into 5GS with 893 some benefits. 895 One of the limitations of this approach is the inability of the 5GS 896 procedures to know, if underlying transport resources are available 897 for the traffic type being carried in PDU session before making 898 certain decisions in the 5G CP. One example scenario/decision could 899 be, a target gNB selection during a N2 mobility event, without 900 knowing if the target gNB is having a underlay transport slice 901 resource for the S-NSSAI and 5QI of the PDU session. The Integrated 902 approach specified below can mitigate this. 904 Appendix B. PPR with various 5G Mobility procedures 906 PPR fulfills the needs of 5GS to transport the user plane traffic 907 from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This 908 is done in keeping the backhaul network at par with 5G slicing 909 requirements that are applicable to Radio and virtualized core 910 network to create a truly end-to-end slice path for 5G traffic. When 911 UE moves across the 5G-AN (e.g. from one gNB to another gNB), there 912 is no transport network reconfiguration required with the approach 913 above. 915 SSC mode would be specified/defaulted by SMF. No change in the mode 916 once connection is initiated and this property is not altered here. 918 B.1. SSC Mode1 919 +---+----+ +-----+ +----------------+ 920 | AMF | | TNF | | SMF | 921 +---+--+-+ +-+-+-+ +-+--------------+ 922 N1 | | | | 923 +--------+ N2 +----Ns---+ +-Nn-+ N4 924 | | | | | 925 + +---+---+ +--++ +-+--+---+ +----+ 926 UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN | 927 == +---+ +---+ +--------+ +----+ 929 Figure 4: SSC Mode1 with integrated Transport Slice Function 931 After UE1 moved to another gNB in the same UPF serving area 933 +---+----+ +-----+ +----------------+ 934 | AMF | | TNF | | SMF | 935 +---_--+-+ +-+-+-+ +-+--------------+ 936 | | | | 937 N2 +----Ns---+ +-Nn-+ N4 938 | | | | 939 +----+--+ +-+-+ ++--+----+ +----+ 940 |gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN | 941 +----+ +---+ +---+----+ +----+ 942 | 943 | 944 | 945 | 946 +----+ +--++ | 947 UE1 |gNB2+======+CSR+------N3--------+ 948 == +----+ +---+ 950 Figure 5: SSC Mode1 with integrated Transport Slice Function 952 In this mode, IP address at the UE is preserved during mobility 953 events. This is similar to 4G/LTE mechanism and for respective 954 slices, corresponding PPR-ID (TE Path) has to be assigned to the 955 packet at UL and DL direction. During Xn mobility as shown above, 956 source gNB has to additionally ensure transport path's resources from 957 TNF are available at the target gNB apart from radio resources check 958 (at decision and request phase of Xn/N2 mobility scenario). 960 B.2. SSC Mode2 962 In this case, if IP Address is changed during mobility (different UPF 963 area), then corresponding PDU session is released. No session 964 continuity from the network is provided and this is designed as an 965 application offload and application manages the session continuity, 966 if needed. For PDU Session, Service Request and Mobility cases 967 mechanism to select the transport resource and the PPR-ID (TE Path) 968 is similar to SSC Mode1. 970 B.3. SSC Mode3 972 In this mode, new IP address may be assigned because of UE moved to 973 another UPF coverage area. Network ensures UE suffers no loss of 974 'connectivity'. A connection through new PDU session anchor point is 975 established before the connection is terminated for better service 976 continuity. There are two ways in which this happens. 978 o Change of SSC Mode 3 PDU Session Anchor with multiple PDU 979 Sessions. 981 o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU 982 Session. 984 In the first mode, from user plane perspective, the two PDU sessions 985 are independent and the use of PPR-ID by gNB and UPFs is exactly 986 similar to SSC Mode 1 described above. The following paragraphs 987 describe the IPv6 multi-homed PDU session case for SSC Mode 3. 989 +---+----+ +-----+ +----------------+ 990 | AMF | | TNF | | SMF | 991 +---+--+-+ +-+-+-+ +-+-----------+--+ 992 N1 | | | | | 993 to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| 994 | | | | | 995 +-------+--+ +--+-------+--+ +-----+-+ 996 |gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6-- 997 +----------+ +----------+--+ +-------+ to DN 998 | +----+ 999 +-| DN | 1000 N6 +----+ 1002 Figure 6: SSC Mode3 and Service Continuity 1004 In the uplink direction for the traffic offloading from the Branching 1005 Point UPF, packet has to reach to the right exit UPF. In this case 1006 packet gets re-encapsulated by the BP UPF (with either GTP-U or the 1007 chosen encapsulation) after bit rate enforcement and LI, towards the 1008 anchor UPF. At this point packet has to be on the appropriate VPN/PW 1009 to the anchor UPF. This mapping is done based on the S-NSSAI the PDU 1010 session belongs to and/or the QFI marking in the GTPU encapsulation 1011 header (e.g. 5QI value) to the PPR-ID of the exit node by selecting 1012 the respective TE PPR-ID (PPR path) of the UPF. If it's a non-MPLS 1013 underlay, destination IP address of the encapsulation header would be 1014 the mapped PPR-ID (TE path). 1016 In the downlink direction for the incoming packet, UPF has to 1017 encapsulate the packet (with either GTP-U or the chosen 1018 encapsulation) to reach the BP UPF. Here mapping is done based on 1019 the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the 1020 BP UPF. If it's a non-MPLS underlay, destination IP address of the 1021 encapsulation header would be the mapped PPR-ID (TE path). In 1022 summary: 1024 o Respective PPR-ID on N3 and N9 has to be selected with correct 1025 transport characteristics from TNF. 1027 o For N2 based mobility SMF has to ensure transport resources are 1028 available for N3 Interface to new BP UPF and from there the 1029 original anchor point UPF. 1031 o For Service continuity with multi-homed PDU session same transport 1032 network characteristics of the original PDU session (both on N3 1033 and N9) need to be observed for the newly configured IPv6 1034 prefixes. 1036 Authors' Addresses 1038 Uma Chunduri (editor) 1039 Futurewei 1040 2330 Central Expressway 1041 Santa Clara, CA 95050 1042 USA 1044 Email: umac.ietf@gmail.com 1046 Richard Li 1047 Futurewei 1048 2330 Central Expressway 1049 Santa Clara, CA 95050 1050 USA 1052 Email: richard.li@futurewei.com 1053 Sridhar Bhaskaran 1054 Altiostar 1056 Email: sridhar.bhaskaran@gmail.com 1058 Jeff Tantsura 1059 Apstra, Inc. 1061 Email: jefftant.ietf@gmail.com 1063 Luis M. Contreras 1064 Telefonica 1065 Sur-3 building, 3rd floor 1066 Madrid 28050 1067 Spain 1069 Email: luismiguel.contrerasmurillo@telefonica.com 1071 Praveen Muley 1072 Nokia 1073 440 North Bernardo Ave 1074 Mountain View, CA 94043 1075 USA 1077 Email: praveen.muley@nokia.com 1079 John Kaippallimalil 1080 Futurewei 1081 5700 Tennyson Parkway, Suite 600 1082 Plano, TX 75024 1083 USA 1085 Email: john.kaippallimalil@futurewei.com