idnits 2.17.00 (12 Aug 2021) /tmp/idnits11770/draft-clt-dmm-tn-aware-mobility-03.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 (February 14, 2019) is 1192 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CT4SID' is mentioned on line 265, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 776, 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 (-07) exists of draft-chunduri-lsr-isis-preferred-path-routing-02 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-02 == Outdated reference: A later version (-14) exists of draft-farinacci-lisp-mobile-network-04 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-03 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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: Standards Track Huawei USA 5 Expires: August 18, 2019 S. Bhaskaran 6 Huawei Technologies India Pvt Ltd 7 J. Tantsura 8 Apstra, Inc. 9 L. Contreras 10 Telefonica 11 P. Muley 12 Nokia 13 February 14, 2019 15 Transport Network aware Mobility for 5G 16 draft-clt-dmm-tn-aware-mobility-03 18 Abstract 20 This document specifies a framework and a mapping function for 5G 21 mobile user plane with transport network slicing, integrated with 22 Mobile Radio Access and a Virtualized Core Network. The integrated 23 approach is specified in a way to fit into the 5G core network 24 architecture defined in [TS23.501]. 26 It focuses on an optimized mobile user plane functionality with 27 various transport services needed for some of the 5G traffic needing 28 low and deterministic latency, real-time, mission-critical services. 29 This document describes, how this objective is achieved agnostic to 30 the transport underlay used (IPv4, IPv6, MPLS) in various deployments 31 and with a new transport network underlay routing, called Preferred 32 Path Routing (PPR). 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 18, 2019. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction and Problem Statement . . . . . . . . . . . . . 3 75 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 77 2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5 78 2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 7 79 2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 8 80 2.3. Transport Network Function . . . . . . . . . . . . . . . 10 81 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 10 82 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 11 83 3.2. Path Steering Support to native IP user planes . . . . . 13 84 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 13 85 3.4. PPR with various 5G Mobility procedures . . . . . . . . . 13 86 3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 13 87 3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 14 88 3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 15 89 4. Other TE Technologies Applicability . . . . . . . . . . . . . 16 90 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 96 9.2. Informative References . . . . . . . . . . . . . . . . . 17 97 Appendix A. Appendix: New Control Plane and User Planes . . . . 20 98 A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 20 99 A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 102 1. Introduction and Problem Statement 104 3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 105 [TS.23.502-3GPP] and [TS.23.503-3GPP]. User Plane Functions (UPF) 106 are the data forwarding entities in the 5GC architecture. The 107 architecture allows the placement of Branching Point (BP) and Uplink 108 Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- 109 AN can be a radio access network or any non-3GPP access network, for 110 example, WLAN. The IP address is anchored by a PDU session anchor 111 UPF (PSA UPF). The interface between the BP/ULCL UPF and the PSA UPF 112 is called N9. While in REL15, 3GPP has adopted GTP-U for the N9 113 interface, new user plane protocols along with GTP-U are being 114 investigated for N9 interface in REL16, as part of [CT4SID]. 115 Concerning to this document another relevant interface is N3, which 116 is between the 5G-AN and the UPF. N3 interface is similar to the 117 user plane interface S1U in LTE [TS.23.401-3GPP]. This document: 119 o does not propose any change to existing N3 user plane 120 encapsulations to realize the benefits with the approach specified 121 here 123 o and can work with any encapsulation (including GTP-U) for the N9 124 interface. 126 [TS.23.501-3GPP] defines network slicing as one of the core 127 capability of 5GC with slice awareness from Radio and 5G Core (5GC) 128 network. It also defines various Session and Service Continuity 129 (SSC) modes and mobility scenarios for 5G. The 5G System (5GS) as 130 defined, allows transport network between N3 and N9 interfaces work 131 independently with various IETF Traffic Engineering (TE) 132 technologies. 134 However, lack of underlying Transport Network (TN) awareness may lead 135 to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS 136 procedures. This could lead to inability to meet SLAs for real-time, 137 mission-critical or latency sensitive services. These 5GS procedures 138 including but not limited to Service Request, PDU Session 139 Establishment, or User Equipment (UE) mobility need same service 140 level characteristics from the TN for the Protocols Data Unit (PDU) 141 session, similar to as provided in Radio and 5GC for the various 142 Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP] . 144 1.1. Acronyms 146 5QI - 5G QoS Indicator 148 5G-AN - 5G Access Network 150 AMF - Access and Mobility Management Function (5G) 152 BP - Branch Point (5G) 154 CSR - Cell Site Router 156 DN - Data Network (5G) 158 eMBB - enhanced Mobile Broadband (5G) 160 FRR - Fast ReRoute 162 gNB - 5G NodeB 164 GBR - Guaranteed Bit Rate (5G) 166 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 168 LFA - Loop Free Alternatives (IP FRR) 170 mIOT - Massive IOT (5G) 172 MPLS - Multi Protocol Label Switching 174 QFI - QoS Flow ID (5G) 176 PPR - Preferred Path Routing 178 PDU - Protocol Data Unit (5G) 180 PW - Pseudo Wire 182 RQI - Reflective QoS Indicator (5G) 184 SBI - Service Based Interface (5G) 186 SID - Segment Identifier 188 SMF - Session Management Function (5G) 190 SSC - Session and Service Continuity (5G) 191 SST - Slice and Service Types (5G) 193 SR - Segment Routing 195 TE - Traffic Engineering 197 ULCL - Uplink Classifier (5G) 199 UPF - User Plane Function (5G) 201 URLLC - Ultra reliable and low latency communications (5G) 203 1.2. Solution Approach 205 This document specifies a mechanism to fulfil the needs of 5GS to 206 transport user plane traffic from 5G-AN to UPF for all service 207 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 208 done by, keeping mobility procedures aware of underlying transport 209 network along with slicing requirements. 211 Section 2 describes two methods, with which Transport Network (TN) 212 aware mobility can be built irrespective of underlying TN technology 213 used. Using Preferred Path Routing (PPR) as TN Underlay is detailed 214 in Section 3. Section 3.4 further describes the applicability and 215 procedures of the same with 5G SSC modes on N3 and N9 interfaces. 217 2. Transport Network (TN) and Slice aware Mobility on N3/N9 218 Service Based Interfaces (SBI) 219 ----+-----+-----+----+----+-----+----+--------+-----+----+------ 220 | | | | | | | | | | 221 +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ 222 | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | 223 +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ 224 +---+----+ +--+--+ +---=++ +--------------+-+ 225 | AMF | | PCF | | TNF | | SMF | 226 +---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ 227 N1 | | | | To | 228 to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 229 | | | | | | 230 +---+---+ +--++ +-+--+---+ +-+-----+ +----+ 231 |gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | 232 +---+ +---+ +-+------+ +-------+ +----+ 233 | +----+ 234 +-| DN | 235 N6 +----+ 237 Figure 1: 5G Service Based Architecture 239 The above diagrams depicts one of the scenarios of the 5G network 240 specified in [TS.23.501-3GPP] and with a new and virtualized control 241 component Transport Network Function (TNF). A Cell Site Router (CSR) 242 is shown connecting to gNB. gNB is an entity in 5G-AN. Though it is 243 shown as a separate block from gNB, in some cases both of these can 244 be co-located. This document concerns with backhaul TN, from CSR to 245 UPF on N3 interface or from Staging UPF to Anchor UPF on N9 246 interface. 248 Currently specified Control Plane (CP) functions - the Access and 249 Mobility Management Function (AMF), the Session Management Function 250 (SMF) and the User plane (UP) components gNodeB (gNB), User Plane 251 Function (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to 252 this document. Other Virtualized 5G control plane components NRF, 253 AUSF, PCF, AUSF, UDM, NEF, and AF are not directly relevant for the 254 discussion in this document and one can see the functionalities of 255 these in [TS.23.501-3GPP]. 257 From encapsulation perspective, N3 interface is similar to S1U in 4G/ 258 LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to 259 transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). 260 Unlike S1U, N3 has some additional aspects as there is no bearer 261 concept and no per bearer GTP-U tunnels. Instead, QoS information is 262 carried in the PDU Session Container GTP-U extension header. N9 263 interface is a new interface to connect UPFs and the right user plane 264 protocols for N9, including GTP-U, are being studied through 3GPP CT4 265 WG approved study item [CT4SID] for REL-16. 267 TN Aware Mobility with optimized transport network functionality is 268 explained below. How PPR fits in this framework in detail along with 269 other various TE technologies briefly are in Section 3 and Section 4 270 respectively. 272 2.1. Discrete Approach 274 In this approach transport network functionality from the 5G-AN to 275 UPF is discrete and 5GS is not aware of the underlying transport 276 network and the resources available. Deployment specific mapping 277 function is used to map the GTP-U encapsulated traffic at the 5G-AN 278 (e.g. gNB) in UL and UPF in DL direction to the appropriate transport 279 slice or transport Traffic Engineered (TE) paths. These TE paths can 280 be established using RSVP-TE [RFC3209] for MPLS underlay, SR 281 [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or 282 PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 283 with SRH, native IPv6 and native IPv4 underlays. 285 As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 286 user plane traffic forwarding rules in the UPF. The UPFs have a 287 concept of a "Network Instance" which logically abstracts the 288 underlying transport path. When the SMF creates the packet detection 289 rules (PDR) and forwarding action rules (FAR) for a PDU session at 290 the UPF, the SMF identifies the network instance through which the 291 packet matching the PDR has to be forwarded. A network instance can 292 be mapped to a TE path at the UPF. In this approach, TNF as shown in 293 Figure 1 need not be part of the 5G Service Based Interface (SBI). 294 Only management plane functionality is needed to create, monitor, 295 manage and delete (life cycle management) the transport TE paths/ 296 transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). 297 The management plane functionality also provides the mapping of such 298 TE paths to a network instance identifier to the SMF. The SMF uses 299 this mapping to install appropriate FARs in the UPF. This approach 300 provide partial integration of the transport network into 5GS with 301 some benefits. 303 One of the limitations of this approach is the inability of the 5GS 304 procedures to know, if underlying transport resources are available 305 for the traffic type being carried in PDU session before making 306 certain decisions in the 5G CP. One example scenario/decision could 307 be, a target gNB selection during a N2 mobility event, without 308 knowing if the target gNB is having a underlay transport slice 309 resource for the S-NSSAI and 5QI of the PDU session. The Integrated 310 approach specified below can mitigate this. 312 2.2. Integrated Approach 314 Network Slice Selection Function (NSSF) as defined in 315 [TS.23.501-3GPP] concerns with multiple aspects including selecting a 316 network slice instance when requested by AMF based on the requested 317 SNSSAI, current location of UE, roaming indication etc. It also 318 notifies NF service consumers (e.g AMF) whenever the status about the 319 slice availability changes. However, the scope is only in 5GC (both 320 control and user plane) and NG Radio Access network including the 321 N3IWF for the non-3GPP access. The network slice instance(s) 322 selected by the NSSF are applicable at a per PDU session granularity. 323 An SMF and UPF are allocated from the selected slice instance during 324 the PDU session establishment procedure. [TS.23.501-3GPP] and 325 [TS.23.502-3GPP] do not consider the resources and functionalities 326 needed from transport network for the selection of UPF. This is seen 327 as independent functionality and currently not part of 5GS. If 328 transport network is not factored in an integrated fashion w.r.t 329 available resources (with network characteristics from desired 330 bandwidth, latency, burst size handling and optionally jitter) some 331 of the gains made with optimizations through 5GNR and 5GC can be 332 degraded. 334 To assuage the above situation, TNF is described (Figure 1) as part 335 of control plane. This has the view of the underlying transport 336 network with all links and nodes as well as various possible underlay 337 paths with different characteristics. TNF can be seen as supporting 338 PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get 339 the TE and topology information of the underlying IGP network. 341 A south bound interface Ns is shown which interacts with the 5G 342 Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism 343 available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF 344 [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay 345 paths from gNB to UPF. Ns and Nn interfaces can be part of the 346 integrated 3GPP architecture, but the specification/ownership of 347 these interfaces SHOULD be left out of scope of 3GPP. 349 These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs 350 and UPFs concerned to allow mobility of UEs while associated with one 351 of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. A 352 north bound interface 'Nn' is shown from one or more of the transport 353 network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as shown in 354 Figure 1. It would enable learning the TE characteristics of all 355 links and nodes of the network continuously (through BGP-LS [RFC7752] 356 or through a passive IGP adjacency and PCEP [RFC5440]). 358 With the TNF in 5GS Service Based Interface, the following additional 359 functionalities are required for end-2-end slice management including 360 the transport network: 362 o The Specific Network Slice Selection Assistance Information 363 (SNSSAI) of PDU session's SHOULD be mapped to the assigned 364 transport VPN and the TE path information for that slice. 366 o For transport slice assignment for various SSTs (eMBB, URLLC, 367 MIoT) corresponding underlay paths need to be created and 368 monitored from each transport end point (gNB/CSR and UPF). 370 o During PDU session creation, apart from radio and 5GC resources, 371 transport network resources needed to be verified matching the 372 characteristics of the PDU session traffic type. 374 o The TNF MUST provide an API that takes as input the source and 375 destination 3GPP user plane element address, required bandwidth, 376 latency and jitter characteristics between those user plane 377 elements and returns as output a particular TE path's identifier, 378 that satisfies the requested requirements. 380 o Mapping of PDU session parameters to underlay SST paths need to be 381 done. One way to do this to let the SMF install a Forwarding 382 Action Rule (FAR) in the UPF via N4 with the FAR pointing to a 383 "Network Instance" in the UPF. A "Network Instance" is a logical 384 identifier for an underlying network. The "Network Instance" 385 pointed by the FAR can be mapped to a transport path (through L2/ 386 L3 VPN). FARs are associated with Packet Detection Rule (PDR). 387 PDRs are used to classify packets in the uplink (UL) and the 388 downlink (DL) direction. For UL GTP-U TEID and/or the QFI marked 389 in the GTPU packet can be used for classifying a packet belonging 390 to a particular slice characteristics. For DL, at a PSA UPF, the 391 UE IP address is used to identify the PDU session, and hence the 392 slice a packet belongs to and the IP 5 tuple can be used for 393 identifying the flow and QoS characteristics to be applied on the 394 packet. 396 o If any other form of encapsulation (other than GTP-U) either on N3 397 or N9 corresponding QFI information MUST be there in the 398 encapsulation header. 400 o In some SSC modes Section 3.4, if segmented path (gNB to 401 staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then 402 corresponding path characteristics MUST be used. This includes a 403 path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP 404 UPF to eventual UPF access to DN. 406 o Continuous monitoring of transport path characteristics and 407 reassignment at the endpoints MUST be performed. For all the 408 affected PDU sessions, degraded transport paths need to be updated 409 dynamically with similar alternate paths. 411 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 412 based or N2 based), for target gNB selection, apart from radio 413 resources, transport resources MUST be factored. This enables 414 handling of all PDU sessions from the UE to target gNB and this 415 require co-ordination of gNB, AMF, SMF with the TNF module. 417 Integrating the TNF as part of the 5GS Service Based Interfaces, 418 provides the flexibility to control the allcoation of required 419 characteristics from the TN during a 5GS signalling procedure (e.g. 420 PDU Session Establishment). If TNF is seen as part of management 421 plane, this real time flexibility is lost. Changes to detailed 422 signaling to integrate the above for various 5GS procedures as 423 defined in [TS.23.502-3GPP] is beyond the scope of this document. 425 2.3. Transport Network Function 427 Proposed TNF as part of the 5GC shown in Figure 1 can be realized 428 using Abstraction and Control of TE Networks (ACTN). ACTN 429 architecture, underlying topology abstraction methods and 430 manageability considerations of the same are detailed in [RFC8453]. 432 3. Using PPR as TN Underlay 434 In a network implementing source routing, packets may be transported 435 through the use of Segment Identifiers (SIDs), where a SID uniquely 436 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 437 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 438 all SRv6 features along with a few concerns in Section 5.3.7 of the 439 same document. Those concerns are addressed by a new backhaul 440 routing mechanism called Preferred Path Routing (PPR), of which this 441 section provides an overview. 443 The label/PPR-ID refer not to individual segments of which the path 444 is composed, but to the identifier of a path that is deployed on 445 network nodes. The fact that paths and path identifiers can be 446 computed and controlled by a controller, not a routing protocol, 447 allows the deployment of any path that network operators prefer, not 448 just shortest paths. As packets refer to a path towards a given 449 destination and nodes make their forwarding decision based on the 450 identifier of a path, not the identifier of a next segment node, it 451 is no longer necessary to carry a sequence of labels. This results 452 in multiple benefits including significant reduction in network layer 453 overhead, increased performance and hardware compatibility for 454 carrying both path and services along the path. 456 Details of the IGP extensions for PPR are provided here: 458 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 460 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 462 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 464 PPR does not remove GTP-U, unlike some other proposals laid out in 465 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 466 with the existing cellular user plane (GTP-U) for both N3 and any 467 approach selected for N9 (encap or no-encap). In this scenario, PPR 468 will only help providing TE benefits needed for 5G slices from 469 transport domain perspective. It does so without adding any 470 additional overhead to the user plane, unlike SR-MPLS or SRv6. This 471 is achieved by: 473 o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in 474 the transport network. For Uplink traffic, the 5G-AN will choose 475 the right PPR-ID of the UPF based on the S-NSSAI the PDU Session 476 belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U 477 encapsulation header. Similarly in the Downlink direction 478 matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the 479 PDU Session belongs to. The table below shows a typical mapping: 481 +----------------+------------+------------------+-----------------+ 482 | QFI (Ranges) | SST | Transport Path | Transport Path | 483 | | in S-NSSAI | Info | Characteristics | 484 +----------------+------------+------------------+-----------------+ 485 | Range Xx - Xy | | | | 486 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 487 | values) | (massive | PPR-ID-A | Bit Rate) | 488 | | IOT) | | Bandwidth: Bx | 489 | | | | Delay: Dx | 490 | | | | Jitter: Jx | 491 +----------------+------------+------------------+-----------------+ 492 | Range Yx - Yy | | | | 493 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 494 | values) | (ultra-low | PPR-ID-B | Req. | 495 | | latency) | | Bandwidth: By | 496 | | | | Delay: Dy | 497 | | | | Jitter: Jy | 498 +----------------+------------+------------------+-----------------+ 499 | Range Zx - Zy | | | | 500 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 501 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 502 +----------------+------------+------------------+-----------------+ 504 Figure 2: QFI Mapping with PPR-IDs on N3/N9 506 o It is possible to have a single PPR-ID for multiple input points 507 through a PPR tree structure separate in UL and DL direction. 509 o Same set of PPRs are created uniformly across all needed 5G-ANs 510 and UPFs to allow various mobility scenarios. 512 o Any modification of TE parameters of the path, replacement path 513 and deleted path needed to be updated from TNF to the relevant 514 ingress points. Same information can be pushed to the NSSF, and/ 515 or SMF as needed. 517 o PPR can be supported with any native IPv4 and IPv6 data/user 518 planes (Section 3.2) with optional TE features (Section 3.3) . As 519 this is an underlay mechanism it can work with any overlay 520 encapsulation approach including GTP-U as defined currently for N3 521 interface. 523 3.2. Path Steering Support to native IP user planes 525 PPR works in fully compatible way with SR defined user planes (SR- 526 MPLS and SRv6) by reducing the path overhead and other challenges as 527 listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or 528 Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR 529 also expands the source routing to user planes beyond SR-MPLS and 530 SRv6 i.e., native IPv6 and IPv4 user planes. 532 This helps legacy transport networks to get the immediate path 533 steering benefits and helps in overall migration strategy of the 534 network to the desired user plane. It is important to note, these 535 benefits can be realized with no hardware upgrade except control 536 plane software for native IPv6 and IPv4 user planes. 538 3.3. Service Level Guarantee in Underlay 540 PPR also optionally allows to allocate resources that are to be 541 reserved along the preferred path. These resources are required in 542 some cases (for some 5G SSTs with stringent GBR and latency 543 requirements) not only for providing committed bandwidth or 544 deterministic latency, but also for assuring overall service level 545 guarantee in the network. This approach does not require per-hop 546 provisioning and reduces the OPEX by minimizing the number of 547 protocols needed and allows dynamism with Fast-ReRoute (FRR) 548 capabilities. 550 3.4. PPR with various 5G Mobility procedures 552 PPR fulfills the needs of 5GS to transport the user plane traffic 553 from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This 554 is done in keeping the backhaul network at par with 5G slicing 555 requirements that are applicable to Radio and virtualized core 556 network to create a truly end-to-end slice path for 5G traffic. When 557 UE moves across the 5G-AN (e.g. from one gNB to another gNB), there 558 is no transport network reconfiguration required with the approach 559 above. 561 SSC mode would be specified/defaulted by SMF. No change in the mode 562 once connection is initiated and this property is not altered here. 564 3.4.1. SSC Mode1 565 +---+----+ +-----+ +----------------+ 566 | AMF | | TNF | | SMF | 567 +---+--+-+ +-+-+-+ +-+--------------+ 568 N1 | | | | 569 +--------+ N2 +----Ns---+ +-Nn-+ N4 570 | | | | | 571 + +---+---+ +--++ +-+--+---+ +----+ 572 UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN | 573 == +---+ +---+ +--------+ +----+ 575 Figure 3: SSC Mode1 with integrated Transport Slice Function 577 After UE1 moved to another gNB in the same UPF serving area 579 +---+----+ +-----+ +----------------+ 580 | AMF | | TNF | | SMF | 581 +---_--+-+ +-+-+-+ +-+--------------+ 582 | | | | 583 N2 +----Ns---+ +-Nn-+ N4 584 | | | | 585 +----+--+ +-+-+ ++--+----+ +----+ 586 |gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN | 587 +----+ +---+ +---+----+ +----+ 588 | 589 | 590 | 591 | 592 +----+ +--++ | 593 UE1 |gNB2+======+CSR+------N3--------+ 594 == +----+ +---+ 596 Figure 4: SSC Mode1 with integrated Transport Slice Function 598 In this mode, IP address at the UE is preserved during mobility 599 events. This is similar to 4G/LTE mechanism and for respective 600 slices, corresponding PPR-ID (TE Path) has to be assigned to the 601 packet at UL and DL direction. During Xn mobility as shown above, 602 source gNB has to additionally ensure transport path's resources from 603 TNF are available at the target gNB apart from radio resources check 604 (at decision and request phase of Xn/N2 mobility scenario). 606 3.4.2. SSC Mode2 608 In this case, if IP Address is changed during mobility (different UPF 609 area), then corresponding PDU session is released. No session 610 continuity from the network is provided and this is designed as an 611 application offload and application manages the session continuity, 612 if needed. For PDU Session, Service Request and Mobility cases 613 mechanism to select the transport resource and the PPR-ID (TE Path) 614 is similar to SSC Mode1. 616 3.4.3. SSC Mode3 618 In this mode, new IP address may be assigned because of UE moved to 619 another UPF coverage area. Network ensures UE suffers no loss of 620 'connectivity'. A connection through new PDU session anchor point is 621 established before the connection is terminated for better service 622 continuity. There are two ways in which this happens. 624 o Change of SSC Mode 3 PDU Session Anchor with multiple PDU 625 Sessions. 627 o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU 628 Session. 630 In the first mode, from user plane perspective, the two PDU sessions 631 are independent and the use of PPR-ID by gNB and UPFs is exactly 632 similar to SSC Mode 1 described above. The following paragraphs 633 describe the IPv6 multi-homed PDU session case for SSC Mode 3. 635 +---+----+ +-----+ +----------------+ 636 | AMF | | TNF | | SMF | 637 +---+--+-+ +-+-+-+ +-+-----------+--+ 638 N1 | | | | | 639 to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| 640 | | | | | 641 +-------+--+ +--+-------+--+ +-----+-+ 642 |gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6-- 643 +----------+ +----------+--+ +-------+ to DN 644 | +----+ 645 +-| DN | 646 N6 +----+ 648 Figure 5: SSC Mode3 and Service Continuity 650 In the uplink direction for the traffic offloading from the Branching 651 Point UPF, packet has to reach to the right exit UPF. In this case 652 packet gets re-encapsulated by the BP UPF (with either GTP-U or the 653 chosen encapsulation) after bit rate enforcement and LI, towards the 654 anchor UPF. At this point packet has to be on the appropriate VPN/PW 655 to the anchor UPF. This mapping is done based on the S-NSSAI the PDU 656 session belongs to and/or the QFI marking in the GTPU encapsulation 657 header (e.g. 5QI value) to the PPR-ID of the exit node by selecting 658 the respective TE PPR-ID (PPR path) of the UPF. If it's a non-MPLS 659 underlay, destination IP address of the encapsulation header would be 660 the mapped PPR-ID (TE path). 662 In the downlink direction for the incoming packet, UPF has to 663 encapsulate the packet (with either GTP-U or the chosen 664 encapsulation) to reach the BP UPF. Here mapping is done based on 665 the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the 666 BP UPF. If it's a non-MPLS underlay, destination IP address of the 667 encapsulation header would be the mapped PPR-ID (TE path). In 668 summary: 670 o Respective PPR-ID on N3 and N9 has to be selected with correct 671 transport characteristics from TNF. 673 o For N2 based mobility SMF has to ensure transport resources are 674 available for N3 Interface to new BP UPF and from there the 675 original anchor point UPF. 677 o For Service continuity with multi-homed PDU session same transport 678 network characteristics of the original PDU session (both on N3 679 and N9) need to be observed for the newly configured IPv6 680 prefixes. 682 4. Other TE Technologies Applicability 684 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 685 for MPLS user plane. However, it is perceived as less dynamic in 686 some cases and has some provisioning overhead across all the nodes in 687 N3 and N9 interface nodes. Also it has another drawback with 688 excessive state refresh overhead across adjacent nodes and this can 689 be mitigated with [RFC8370]. 691 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 692 bandwidth reservation or mechanism to guarantee latency on the nodes/ 693 links on SR path. But, SR allows path steering for any flow at the 694 ingress and particular path for a flow can be chosen. Some of the 695 issues around path overhead/tax, MTU issues are documented at 696 Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- 697 MPLS allows reduction of the control protocols to one IGP (with out 698 needing for LDP and RSVP-TE). 700 However, as specified above with PPR (Section 3), in the integrated 701 transport network function (TNF) a particular RSVP-TE path for MPLS 702 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to 703 SMF for mapping a particular PDU session to the transport path. 705 5. Acknowledgements 707 Thanks to Young Lee and John Kaippallimalil for discussions on this 708 document including ACTN applicability for the proposed TNF. Thanks 709 to Sri Gundavelli and 3GPP delegates who provided detailed feedback 710 on this document. 712 6. IANA Considerations 714 This document has no requests for any IANA code point allocations. 716 7. Security Considerations 718 This document does not introduce any new security issues. 720 8. Contributing Authors 722 The following people contributed substantially to the content of this 723 document and should be considered co-authors. 725 Xavier De Foy 726 InterDigital Communications, LLC 727 1000 Sherbrooke West 728 Montreal 729 Canada 731 Email: Xavier.Defoy@InterDigital.com 733 9. References 735 9.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 9.2. Informative References 744 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 745 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 746 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 747 Camarillo, "Topology Independent Fast Reroute using 748 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 749 lfa-05 (work in progress), October 2018. 751 [I-D.bogineni-dmm-optimized-mobile-user-plane] 752 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 753 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 754 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 755 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 756 optimized-mobile-user-plane-01 (work in progress), June 757 2018. 759 [I-D.chunduri-lsr-isis-preferred-path-routing] 760 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 761 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 762 draft-chunduri-lsr-isis-preferred-path-routing-02 (work in 763 progress), February 2019. 765 [I-D.chunduri-lsr-ospf-preferred-path-routing] 766 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 767 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 768 chunduri-lsr-ospf-preferred-path-routing-02 (work in 769 progress), February 2019. 771 [I-D.farinacci-lisp-mobile-network] 772 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 773 for the Mobile Network", draft-farinacci-lisp-mobile- 774 network-04 (work in progress), September 2018. 776 [I-D.ietf-dmm-srv6-mobile-uplane] 777 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 778 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 779 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 780 uplane-03 (work in progress), October 2018. 782 [I-D.ietf-spring-segment-routing] 783 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 784 Litkowski, S., and R. Shakir, "Segment Routing 785 Architecture", draft-ietf-spring-segment-routing-15 (work 786 in progress), January 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.29.281-3GPP] 853 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 854 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 855 December 2017. 857 Appendix A. Appendix: New Control Plane and User Planes 859 A.1. LISP and PPR 861 PPR can also be used with LISP control plane for 3GPP as described in 862 [I-D.farinacci-lisp-mobile-network]. This can be achieved by mapping 863 the UE IP address (EID) to PPR-ID, which acts as Routing Locator 864 (RLOC). Any encapsulation supported by LISP can work well with PPR. 865 If the RLOC refers to an IPv4 or IPv6 destination address in the LISP 866 encapsulated header, packets are transported on the preferred path in 867 the network as opposed to traditional shortest path routing with no 868 additional user plane overhead related to TE path in the network 869 layer. 871 Some of the distinct advantages of the LISP approach is, its 872 scalability, support for service continuity in SSC Mode3 as well as 873 native support for session continuity (session survivable mobility). 874 Various other advantages are documented at 875 [I-D.farinacci-lisp-mobile-network]. 877 A.2. ILA and PPR 879 If an ILA-prefix is allowed to refer to a PPR-ID, ILA can be 880 leveraged with all the benefits (including mobility) that it 881 provides. This works fine in the DL direction as packet is destined 882 to UE IP address at UPF. However, in the UL direction, packet is 883 destined to an external internet address (SIR Prefix to ILA Prefix 884 transformation happens on the Source address of the original UE 885 packet). One way to route the packet with out bringing the complete 886 DFZ BGP routing table is by doing a default route to the UPF (ILA-R). 887 In this case, how TE can be achieved is TBD (to be expanded further 888 with details). 890 Authors' Addresses 891 Uma Chunduri (editor) 892 Huawei USA 893 2330 Central Expressway 894 Santa Clara, CA 95050 895 USA 897 Email: uma.chunduri@huawei.com 899 Richard Li 900 Huawei USA 901 2330 Central Expressway 902 Santa Clara, CA 95050 903 USA 905 Email: renwei.li@huawei.com 907 Sridhar Bhaskaran 908 Huawei Technologies India Pvt Ltd 909 Survey No.37, Whitefield Road, Kundalahalli 910 Bengaluru, Karnataka 911 India 913 Email: sridhar.bhaskaran@huawei.com 915 Jeff Tantsura 916 Apstra, Inc. 918 Email: jefftant.ietf@gmail.com 920 Luis M. Contreras 921 Telefonica 922 Sur-3 building, 3rd floor 923 Madrid 28050 924 Spain 926 Email: luismiguel.contrerasmurillo@telefonica.com 927 Praveen Muley 928 Nokia 929 440 North Bernardo Ave 930 Mountain View, CA 94043 931 USA 933 Email: praveen.muley@nokia.com