idnits 2.17.00 (12 Aug 2021) /tmp/idnits10585/draft-clt-dmm-tn-aware-mobility-01.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 16, 2018) is 1405 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 255, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 786, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-04 == Outdated reference: A later version (-07) exists of draft-chunduri-lsr-isis-preferred-path-routing-01 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-01 == Outdated reference: A later version (-14) exists of draft-farinacci-lisp-mobile-network-03 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-02 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 1 error (**), 0 flaws (~~), 12 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: January 17, 2019 J. Tantsura 6 Nuage Networks 7 L. Contreras 8 Telefonica 9 X. De Foy 10 InterDigital Communications, LLC 11 July 16, 2018 13 Transport Network aware Mobility for 5G 14 draft-clt-dmm-tn-aware-mobility-01 16 Abstract 18 This document specifies a framework and a mapping function for 5G 19 mobile user plane with transport network slicing, integrated with 20 Mobile Radio Access and a Virtualized Core Network. The integrated 21 approach specified in a way to address all the mobility scenarios 22 defined in [TS23.501] and to be backward compatible with LTE 23 [TS.23.401-3GPP] network deployments. 25 It focuses on an optimized mobile user plane functionality with 26 various transport services needed for some of the 5G traffic needing 27 low and deterministic latency, real-time, mission-critical services. 28 This document describes, how this objective is achieved agnostic to 29 the transport underlay used (IPv4, IPv6, MPLS) in various deployments 30 and with a new transport network underlay routing, called Preferred 31 Path Routing (PPR). 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 17, 2019. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction and Problem Statement . . . . . . . . . . . . . 3 74 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 76 2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5 77 2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6 78 2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7 79 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9 80 3.1. PPR with Transport Slicing aware Mobility on N3/N9 . . . 9 81 3.2. Path Steering Support to native IP user planes . . . . . 11 82 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 11 83 3.4. PPR with various 5G Mobility procedures . . . . . . . . . 11 84 3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12 85 3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13 86 3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 13 87 4. Other TE Technologies Applicability . . . . . . . . . . . . . 14 88 5. New Control Plane and User Planes . . . . . . . . . . . . . . 15 89 5.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 15 90 5.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 15 91 6. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . 16 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction and Problem Statement 102 3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 103 [TS.23.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9 104 [TS.23.501-3GPP] has been created between 2 User Plane 105 Functionalities (UPFs). While user plane for N9 interface being 106 finalized for REL16, both GTP-U based encapsulation or any other 107 compatible approach is being considered [CT4SID]. Concerning to this 108 document another relevant interface is N3, which is between gNB and 109 the UPF. N3 interface is similar to the user plane interface S1U in 110 LTE [TS.23.401-3GPP]. This document: 112 o does not propose any change to existing N3 user plane 113 encapsulations to realize the benefits with the approach specified 114 here 116 o and can work with any encapsulation (including GTP-U) for the N9 117 interface. 119 [TS.23.501-3GPP] defines various Session and Service Continuity (SSC) 120 modes and mobility scenarios for 5G with slice awareness from Radio 121 and 5G Core (5GC) network. 5G System (5GS) as defined, allows 122 transport network between N3 and N9 interfaces work independently 123 with various IETF Traffic Engineering (TE) technologies. 125 However, lack of underlying Transport Network (TN) awareness can be 126 problematic for some of the 5GS procedures, for real-time, mission- 127 critical or for any deterministic latency services. These 5GS 128 procedures including but not limited to Service Request, PDU Session, 129 or User Equipment (UE) mobility need same service level 130 characteristics from the TN for the Protocols Data Unit (PDU) 131 session, similar to as provided in Radio and 5GC for various 5QI's 132 defined in [TS.23.501-3GPP] . 134 1.1. Acronyms 136 5QI - 5G QoS Indicator 138 AMF - Access and Mobility Management Function (5G) 140 BP - Branch Point (5G) 142 CSR - Cell Site Router 144 DN - Data Network (5G) 145 eMBB - enhanced Mobile Broadband (5G) 147 FRR - Fast ReRoute 149 gNB - 5G NodeB 151 GBR - Guaranteed Bit Rate (5G) 153 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 155 LFA - Loop Free Alternatives (IP FRR) 157 mIOT - Massive IOT (5G) 159 MPLS - Multi Protocol Label Switching 161 QFI - QoS Flow ID (5G) 163 PPR - Preferred Path Routing 165 PDU - Protocol Data Unit (5G) 167 PW - Pseudo Wire 169 RQI - Reflective QoS Indicator (5G) 171 SBI - Service Based Interface (5G) 173 SID - Segment Identifier 175 SMF - Session Management Function (5G) 177 SSC - Session and Service Continuity (5G) 179 SST - Slice and Service Types (5G) 181 SR - Segment Routing 183 TE - Traffic Engineering 185 ULCL - Uplink Classifier (5G) 187 UPF - User Plane Function (5G) 189 URLLC - Ultra reliable and low latency communications (5G) 191 1.2. Solution Approach 193 This document specifies a mechanism to fulfil the needs of 5GS to 194 transport user plane traffic from gNB to UPF for all service 195 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 196 done by, keeping mobility procedures aware of underlying transport 197 network along with slicing requirements. TN with mobility awareness 198 described here in a way, which does not erase performance and latency 199 gains made with 5G New Radio(5GNR) and virtualized cellular core 200 network features developed in [TS.23.501-3GPP]. 202 Section 2 describes two methods, with which Transport Network (TN) 203 aware mobility can be built irrespective of underlying TN technology 204 used. Using Preferred Path Routing (PPR) as TN Underlay is detailed 205 in Section 3. Section 3.4 further describes the applicability and 206 procedures of the same with 5G SSC modes on N3 and N9 interfaces. At 207 the end, Section 6 recapitulates the benefits of specified approach 208 in mobile networks. 210 2. Transport Network (TN) and Slice aware Mobility on N3/N9 212 Service Based Interfaces (SBI) 213 ----+-----+-----+----+----+-----+----+--------+-----+----+------ 214 | | | | | | | | | | 215 +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ 216 | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | 217 +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ 218 +---+----+ +--+--+ +---=++ +--------------+-+ 219 | AMF | | PCF | | TNF | | SMF | 220 +---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ 221 N1 | | | | To | 222 to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 223 | | | | | | 224 +---+---+ +--++ +-+--+---+ +-+-----+ +----+ 225 |gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | 226 +---+ +---+ +-+------+ +-------+ +----+ 227 | +----+ 228 +-| DN | 229 N6 +----+ 231 Figure 1: 5G Service Based Architecture 233 The above diagrams depicts one of the scenarios of the 5G network 234 specified in [TS.23.501-3GPP] and with a new and virtualized control 235 component Transport Network Function (TNF). A Cell Site Router (CSR) 236 is shown connecting to gNB. Though it is shown as a separate block 237 from gNB, in some cases both of these can be co-located. This 238 document concerns with backhaul TN, from CSR to UPF on N3 interface 239 or from Staging UPF to Anchor UPF on N9 interface. 241 Currently specified Control Plane (CP) functions Access and Mobility 242 Management Function (AMF), Session Management Function (SMF) and User 243 plane (UP) components gNodeB (gNB), User Plane Function (UPF) with 244 N2, N3, N4, N6 and N9 are relevant to this document. Other 245 Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, 246 NEF, and AF are not directly relevant for the discussion in this 247 document and one can see the functionalities of these in 248 [TS.23.501-3GPP]. 250 N3 interface is similar to S1U in 4G/LTE [TS.23.401-3GPP] network and 251 uses GTP-U [TS.29.281-3GPP] encapsulation to transport any UE PDUs 252 (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). N9 interface is a 253 new interface to connect UPFs in SSC Mode3 Section 3.4.3 and right 254 user plane protocol/encapsulation is being studied through 3GPP CT4 255 WG approved study item [CT4SID] for REL-16. 257 TN Aware Mobility with optimized transport network functionality is 258 explained below. How PPR fits in this framework in detail along with 259 other various TE technologies briefly are in Section 3 and Section 4 260 respectively. 262 2.1. Discrete Approach 264 In this approach transport network functionality from gNB to UPF is 265 discrete and 5GS is not aware of the underlying transport network and 266 the resources available. Deployment specific mapping function is 267 used to map the GTP-U encapsulated traffic at gNB at UL and UPF in DL 268 direction to the appropriate transport slice or transport Traffic 269 Engineered (TE) paths. These TE paths can be established using RSVP- 270 TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing] 271 for both MPLS and IPv6 underlay or PPR 272 [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 with 273 SRH, native IPv6 and native IPv4 underlays. 275 In this case, the encapsulation provided by GTP-U helps carry 276 different PDU session types (IPv4, IPv6, IPv4IPv6, Ethernet and 277 Unstructured) independent of the underlying transport or user plane 278 (IPv4, IPv6 or MPLS) network. Mapping of the PDU sessions to TE 279 paths can be done based on the source UDP port ranges (if these are 280 assigned based on the PDU session QCIs, as done in some deployments 281 with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or 282 RQI values in the GTP-U header. Here, TNF as shown in Figure 1 need 283 not be part of the 5G Service Based Interface (SBI). Only management 284 plane functionality is needed to create, monitor, manage and delete 285 (life cycle management) the transport TE paths/transport slices from 286 gNB to UPF (on N3/N9 interfaces). This approach provide partial 287 integration of the transport network into 5GS with some benefits. 289 One of the limitations of this approach is the inability of 5GS 290 procedures to know, if underlying transport resources are available 291 for the traffic type being carried in PDU session before making 292 certain decisions in the 5G CP. One example scenario/decision could 293 be, a target gNB selection in Xn mobility in SSC Mode1, without 294 knowing if the target gNB is having a underlay transport slice 295 resource for the 5QI of the PDU session. The below approach can 296 mitigate this. 298 2.2. Integrated Approach 300 Network Slice Selection Function (NSSF) as defined in 301 [TS.23.501-3GPP] concerns with multiple aspects related to creation, 302 selection, mobility, roaming and co-ordination among other CP 303 functions in 5GS. However, the scope is only in 5GC (both control 304 and user plane) and NG Radio Access network including N3IWF for non- 305 3GPP access. Slice functionality is per PDU session granularity. 306 While this fully covers needed functionality and resources from UE 307 registration, Tracking Area (TA) updates, mobility and roaming, 308 resources and functionalities needed from transport network is not 309 specified. This is seen as independent functionality though part of 310 5GS. If transport network is not factored in an integrated fashion 311 w.r.t available resources (with network characteristics from desired 312 bandwidth, latency, burst size handling and optionally jitter) some 313 of the gains made with optimizations through 5GNR and 5GC can be 314 degraded. 316 To assuage the above situation, TNF is described (Figure 1) as part 317 of control plane. This has the view of the underlying transport 318 network with all links and nodes as well as various possible underlay 319 paths with different characteristics. TNF can be seen as supporting 320 PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get 321 the TE and topology information of the underlying IGP network. 323 A south bound interface Ns is shown which interacts with the gNB/CSR. 324 'Ns' can use one or more mechanism available today (PCEP [RFC5440], 325 NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3 326 VPNs along with TE underlay paths from gNB to UPF. 328 These VPNs and/or underlay TE paths MUST be similar on all gNB/CSRs 329 and UPFs concerned to allow mobility of UEs while associated with one 330 of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. A 331 north bound interface 'Nn' is shown from one or more of the transport 332 network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as shown in 333 Figure 1. It would enable learning the TE characteristics of all 334 links and nodes of the network continuously (through BGP-LS [RFC7752] 335 or through a passive IGP adjacency and PCEP [RFC5440]). 337 With the TNF in 5GS Service Based Interface, the following additional 338 functionalities are required for end-2-end slice management including 339 the transport network: 341 o In the Network Slice Selection Assistance Information (NSSAI) PDU 342 session's assigned transport VPN and the TE path information is 343 needed. 345 o For transport slice assignment for various SSTs (eMBB, URLLC, 346 MIoT) corresponding underlay paths need to be created and 347 monitored from each transport end point (gNB/CSR and UPF). 349 o During PDU session creation, apart from radio and 5GC resources, 350 transport network resources needed to be verified matching the 351 characteristics of the PDU session traffic type. 353 o Mapping of PDU session parameters to underlay SST paths need to be 354 done. One way to do this is through 5QI/QFI information in the 355 GTP-U header and map the same to the underlying transport path 356 (including VPN or PW). This works for uplink (UL) direction. 358 o For downlink direction RQI need to be considered to map the DL 359 packet to one of the underlay paths at the UPF. 361 o If any other form of encapsulation (other than GTP-U) either on N3 362 or N9 corresponding 5QI/QFI or RQI information MUST be there in 363 the encapsulation header. 365 o If SSC Mode3 Section 3.4.3 is used, segmented path (gNB to 366 staging/ULCL/BP-UPF to anchor-point-UPF) with corresponding path 367 characteristics MUST be used. This includes a path from gNB/CSR 368 to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF 369 access to DN. 371 o Continuous monitoring of transport path characteristics and 372 reassignment at the endpoints MUST be performed. For all the 373 effected PDU sessions, degraded transport paths need to be updated 374 dynamically with similar alternate paths. 376 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 377 based or N2 based), for target gNB selection, apart from radio 378 resources, transport resources MUST be factored. This enables 379 handling of all PDU sessions from the UE to target gNB and this 380 require co-ordination of AMF, SMF with the TNF module. 382 Changes to detailed signaling to integrate the above for various 5GS 383 procedures as defined in [TS.23.502-3GPP] is beyond the scope of this 384 document. 386 3. Using PPR as TN Underlay 388 In a network implementing source routing, packets may be transported 389 through the use of Segment Identifiers (SIDs), where a SID uniquely 390 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 391 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 392 all SRv6 features along with a few concerns in Section 5.3.7 of the 393 same document. Those concerns are addressed by a new backhaul 394 routing mechanism called Preferred Path Routing (PPR), of which this 395 Section provides an overview. 397 The label/PPR-ID refer not to individual segments of which the path 398 is composed, but to the identifier of a path that is deployed on 399 network nodes. The fact that paths and path identifiers can be 400 computed and controlled by a controller, not a routing protocol, 401 allows the deployment of any path that network operators prefer, not 402 just shortest paths. As packets refer to a path towards a given 403 destination and nodes make their forwarding decision based on the 404 identifier of a path, not the identifier of a next segment node, it 405 is no longer necessary to carry a sequence of labels. This results 406 in multiple benefits including significant reduction in network layer 407 overhead, increased performance and hardware compatibility for 408 carrying both path and services along the path. 410 Details of the IGP extensions for PPR are provided here: 412 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 414 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 416 3.1. PPR with Transport Slicing aware Mobility on N3/N9 418 PPR does not remove GTP-U, unlike some other proposals laid out in 419 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 420 with the existing cellular user plane (GTP-U) for both N3 and any 421 approach selected for N9 (encap or no-encap). In this scenario, PPR 422 will only help providing TE benefits needed for 5G slices from 423 transport domain perspective. It does so without adding any 424 additional overhead to the user plane, unlike SR-MPLS or SRv6. This 425 is achieved by: 427 o For 3 different SSTs, 3 PPR-IDs can signaled from any node in the 428 transport network. For Uplink traffic, gNB will choose the right 429 PPR-ID of the UPF based on the 5QI value in the encapsulation 430 header of the PDU session. Similarly in the Downlink direction 431 matching PPR-ID of the gNB is chosen for the RQI value in the 432 encapsulated SL payload. The table below shows a typical mapping: 434 +----------------+------------+------------------+-----------------+ 435 | 5QI (Ranges)/ | SST | Transport Path | Transport Path | 436 | RQI (Ranges) | | Info | Characteristics | 437 +----------------+------------+------------------+-----------------+ 438 | Range Xx - Xy | | | | 439 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 440 | values) | (massive | PPR-ID-A | Bit Rate) | 441 | | IOT) | | Bandwidth: Bx | 442 | | | | Delay: Dx | 443 | | | | Jitter: Jx | 444 +----------------+------------+------------------+-----------------+ 445 | Range Yx - Yy | | | | 446 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 447 | values) | (ultra-low | PPR-ID-B | Req. | 448 | | latency) | | Bandwidth: By | 449 | | | | Delay: Dy | 450 | | | | Jitter: Jy | 451 +----------------+------------+------------------+-----------------+ 452 | Range Zx - Zy | | | | 453 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 454 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 455 +----------------+------------+------------------+-----------------+ 457 Figure 2: 5QI/RQI Mapping with PPR-IDs on N3/N9 459 o It is possible to have a single PPR-ID for multiple input points 460 through a PPR tree structure separate in UL and DL direction. 462 o Same set of PPRs are created uniformly across all needed gNBs and 463 UPFs to allow various mobility scenarios. 465 o Any modification of TE parameters of the path, replacement path 466 and deleted path needed to be updated from TNF to the relevant 467 ingress points. Same information can be pushed to the NSSF, AMF 468 and SMF as needed. 470 o PPR can be supported with any native IPv4 and IPv6 data/user 471 planes (Section 3.2 with optional TE features Section 3.3 . As 472 this is an underlay mechanism it can work with any overlay 473 encapsulation approach including GTP-U as defined currently for N3 474 interface. 476 3.2. Path Steering Support to native IP user planes 478 PPR works in fully compatible way with SR defined user planes (SR- 479 MPLS and SRv6) by reducing the path overhead and other challenges as 480 listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or 481 Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR 482 also expands the source routing to user planes beyond SR-MPLS and 483 SRv6 i.e., native IPv6 and IPv4 user planes. 485 This helps legacy transport networks to get the immediate path 486 steering benefits and helps in overall migration strategy of the 487 network to the desired user plane. It is important to note, these 488 benefits can be realized with no hardware upgrade except control 489 plane software for native IPv6 and IPv4 user planes. 491 3.3. Service Level Guarantee in Underlay 493 PPR also optionally allows to allocate resources that are to be 494 reserved along the preferred path. These resources are required in 495 some cases (for some 5G SSTs with stringent GBR and latency 496 requirements) not only for providing committed bandwidth or 497 deterministic latency, but also for assuring overall service level 498 guarantee in the network. This approach does not require per-hop 499 provisioning and reduces the OPEX by minimizing the number of 500 protocols needed and allows dynamism with Fast-ReRoute (FRR) 501 capabilities. 503 3.4. PPR with various 5G Mobility procedures 505 PPR fulfills the needs of 5GS to transport the user plane traffic 506 from gNB to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This is 507 done in keeping the backhaul network at par with 5G slicing 508 requirements that are applicable to Radio and virtualized core 509 network to create a truly end-to-end slice path for 5G traffic. When 510 UE moves from one gNB to another gNB, there is no transport network 511 reconfiguration require with the approach above. 513 SSC mode would be specified/defaulted by SMF. No change in the mode 514 once connection is initiated and this property is not altered here. 516 3.4.1. SSC Mode1 518 +---+----+ +-----+ +----------------+ 519 | AMF | | TNF | | SMF | 520 +---+--+-+ +-+-+-+ +-+--------------+ 521 N1 | | | | 522 +--------+ N2 +----Ns---+ +-Nn-+ N4 523 | | | | | 524 + +---+---+ +--++ +-+--+---+ +----+ 525 UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN | 526 == +---+ +---+ +--------+ +----+ 528 Figure 3: SSC Mode1 with integrated Transport Slice Function 530 After UE1 moved to another gNB in the same UPF serving area 532 +---+----+ +-----+ +----------------+ 533 | AMF | | TNF | | SMF | 534 +---_--+-+ +-+-+-+ +-+--------------+ 535 | | | | 536 N2 +----Ns---+ +-Nn-+ N4 537 | | | | 538 +----+--+ +-+-+ ++--+----+ +----+ 539 |gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN | 540 +----+ +---+ +---+----+ +----+ 541 | 542 | 543 | 544 | 545 +----+ +--++ | 546 UE1 |gNB2+======+CSR+------N3--------+ 547 == +----+ +---+ 549 Figure 4: SSC Mode1 with integrated Transport Slice Function 551 In this mode, IP address at the UE is preserved during mobility 552 events. This is similar to 4G/LTE mechanism and for respective 553 slices, corresponding PPR-ID (TE Path) has to be assigned to the 554 packet at UL and DL direction. During Xn mobility as shown above, 555 AMF has to additionally ensure transport path's resources from TNF 556 are available at the target gNB apart from radio resources check (at 557 decision and request phase of Xn/N2 mobility scenario). 559 3.4.2. SSC Mode2 561 In this case, if IP Address is changed during mobility (different UPF 562 area), then corresponding PDU session is released. No session 563 continuity from the network is provided and this is designed as an 564 application offload and application manages the session continuity, 565 if needed. For PDU Session, Service Request and Mobility cases 566 mechanism to select the transport resource and the PPR-ID (TE Path) 567 is similar to SSC Mode1. 569 3.4.3. SSC Mode3 571 In this mode, new IP address may be assigned because of UE moved to 572 another UPF coverage area. Network ensures UE suffers no loss of 573 'connectivity'. A connection through new PDU session anchor point is 574 established before the connection is terminated for better service 575 continuity. 577 +---+----+ +-----+ +----------------+ 578 | AMF | | TNF | | SMF | 579 +---+--+-+ +-+-+-+ +-+-----------+--+ 580 N1 | | | | | 581 to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| 582 | | | | | 583 +-------+--+ +--+-------+--+ +-----+-+ 584 |gNB/CSR +---N3---+ BP/ULCL UPF +-N9--+ UPF +-N6-- 585 +----------+ +----------+--+ +-------+ to DN 586 | +----+ 587 +-| DN | 588 N6 +----+ 590 Figure 5: SSC Mode3 and Service Continuity 592 In the uplink direction for the traffic offloading from UL/CL case, 593 packet has to reach to the right exit UPF. In this case packet gets 594 re-encapsulated with ULCL marker (with either GTP-U or the chosen 595 encapsulation) after bit rate enforcement and LI to the anchor UPF. 596 At this point packet has to be on the appropriate VPN/PW to the 597 anchor UPF. This mapping is done based on the 5QI to the PPR-ID of 598 the exit node by selecting the respective TE PPR-ID (PPR path) of the 599 UPF. If it's a non-MPLS underlay, destination IP address of the 600 encapsulation header would be the mapped PPR-ID (TE path). 602 In the downlink direction for the incoming packet, UPF has to 603 encapsulate the packet (with either GTP-U or the chosen 604 encapsulation) to reach the BP/ULCL UPF. Here mapping is done for 605 RQI parameter in the encapsulation header to PPR-ID (TE Path) of the 606 BP/ULCL UPF. If it's a non-MPLS underlay, destination IP address of 607 the encapsulation header would be the mapped PPR-ID (TE path). In 608 summary: 610 o Respective PPR-ID on N3 and N9 has to be selected with correct 611 transport characteristics from TNF. 613 o For N2 based mobility AMF/SMF has to ensure transport resources 614 are available for N3 Interface to new ULCL and from there the 615 original anchor point UPF. 617 o For Service continuity with multi-homed PDU session same transport 618 network characteristics of the original PDU session (both on N3 619 and N9) need to be observed for the newly created PDU session. 621 4. Other TE Technologies Applicability 623 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 624 for MPLS user plane. However, it is perceived as less dynamic in 625 some cases and has some provisioning overhead across all the nodes in 626 N3 and N9 interface nodes. Also it has another drawback with 627 excessive state refresh overhead across adjacent nodes and this can 628 be mitigated with [RFC8370]. 630 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 631 neither bandwidth reservation nor mechanism to guarantee latency on 632 the nodes/links on SR path. But, SR allows path steering for any 633 flow at the ingress and particular path for a flow can be chosen. 634 Some of the issues around path overhead/tax, MTU issues are 635 documented at Section 5.3 of 636 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Also SR allows 637 reduction of the control protocols to one IGP (with out needing for 638 LDP and RSVP). 640 However, as specified above with PPR (Section 3), in the integrated 641 transport network function (TNF) a particular RSVP-TE path for MPLS 642 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to 643 NSSF/AMF/SMF for mapping a particular PDU session to the transport 644 path. 646 5. New Control Plane and User Planes 648 5.1. LISP and PPR 650 PPR can also be used with LISP control plane for 3GPP as described in 651 [I-D.farinacci-lisp-mobile-network]. This can be achieved by mapping 652 the UE IP address (EID) to PPR-ID, which acts as Routing Locator 653 (RLOC). Any encapsulation supported by LISP can work well with PPR. 654 If the RLOC refers to an IPv4 or IPv6 destination address in the LISP 655 encapsulated header, packets are transported on the preferred path in 656 the network as opposed to traditional shortest path routing with no 657 additional user plane overhead related to TE path in the network 658 layer. 660 Some of the distinct advantages of the LISP approach is, its 661 scalability, support for service continuity in SSC Mode3 as well as 662 native support for session continuity (session survivable mobility). 663 Various other advantages are documented at 664 [I-D.farinacci-lisp-mobile-network]. 666 5.2. ILA and PPR 668 If an ILA-prefix is allowed to refer to a PPR-ID, ILA can be 669 leveraged with all the benefits (including mobility) that it 670 provides. This works fine in the DL direction as packet is destined 671 to UE IP address at UPF. However, in the UL direction, packet is 672 destined to an external internet address (SIR Prefix to ILA Prefix 673 transformation happens on the Source address of the original UE 674 packet). One way to route the packet with out bringing the complete 675 DFZ BGP routing table is by doing a default route to the UPF (ILA-R). 676 In this case, how TE can be achieved is TBD (to be expanded further 677 with details). 679 6. Summary and Benefits with PPR 681 This document specifies an approach to transport and slice aware 682 mobility with a simple mapping function from PDU Session to transport 683 path applicable to any TE underlay. 685 This also describes PPR 686 [I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay 687 routing mechanism, which helps with goal of optimized user plane for 688 N9 interface. PPR provides a method for N3 and N9 interfaces to 689 support transport slicing in a way which does not erase the gains 690 made with 5GNR and virtualized cellular core network features for 691 various types of 5G traffic (e.g. needing low and deterministic 692 latency, real-time, mission-critical or AR/VR traffic). PPR provides 693 path steering, optionally guaranteed services with TE, unique Fast- 694 ReRoute (FRR) mechanism with preferred backups (beyond shortest path 695 backups through existing LFA schemes) in the mobile backhaul network 696 with any underlay being used in the operator's network (IPv4, IPv6 or 697 MPLS) in an optimized fashion. 699 7. Acknowledgements 701 TBD. 703 8. IANA Considerations 705 This document has no requests for any IANA code point allocations. 707 9. Security Considerations 709 This document does not introduce any new security issues. 711 10. References 713 10.1. Normative References 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 10.2. Informative References 722 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 723 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 724 Francois, P., and d. daniel.voyer@bell.ca, "Topology 725 Independent Fast Reroute using Segment Routing", draft- 726 bashandy-rtgwg-segment-routing-ti-lfa-04 (work in 727 progress), April 2018. 729 [I-D.bogineni-dmm-optimized-mobile-user-plane] 730 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 731 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 732 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 733 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 734 optimized-mobile-user-plane-01 (work in progress), June 735 2018. 737 [I-D.chunduri-lsr-isis-preferred-path-routing] 738 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 739 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 740 draft-chunduri-lsr-isis-preferred-path-routing-01 (work in 741 progress), July 2018. 743 [I-D.chunduri-lsr-ospf-preferred-path-routing] 744 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 745 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 746 chunduri-lsr-ospf-preferred-path-routing-01 (work in 747 progress), July 2018. 749 [I-D.farinacci-lisp-mobile-network] 750 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 751 for the Mobile Network", draft-farinacci-lisp-mobile- 752 network-03 (work in progress), March 2018. 754 [I-D.ietf-dmm-srv6-mobile-uplane] 755 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 756 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 757 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 758 uplane-02 (work in progress), July 2018. 760 [I-D.ietf-spring-segment-routing] 761 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 762 Litkowski, S., and R. Shakir, "Segment Routing 763 Architecture", draft-ietf-spring-segment-routing-15 (work 764 in progress), January 2018. 766 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 767 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 768 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 769 . 771 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 772 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 773 DOI 10.17487/RFC5440, March 2009, 774 . 776 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 777 and A. Bierman, Ed., "Network Configuration Protocol 778 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 779 . 781 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 782 Locator/ID Separation Protocol (LISP)", RFC 6830, 783 DOI 10.17487/RFC6830, January 2013, 784 . 786 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 787 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 788 RFC 7490, DOI 10.17487/RFC7490, April 2015, 789 . 791 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 792 S. Ray, "North-Bound Distribution of Link-State and 793 Traffic Engineering (TE) Information Using BGP", RFC 7752, 794 DOI 10.17487/RFC7752, March 2016, 795 . 797 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 798 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 799 . 801 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 802 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 803 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 804 . 806 [TS.23.401-3GPP] 807 3rd Generation Partnership Project (3GPP), "Procedures for 808 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 810 [TS.23.501-3GPP] 811 3rd Generation Partnership Project (3GPP), "System 812 Architecture for 5G System; Stage 2, 3GPP TS 23.501 813 v2.0.1", December 2017. 815 [TS.23.502-3GPP] 816 3rd Generation Partnership Project (3GPP), "Procedures for 817 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 818 2017. 820 [TS.23.503-3GPP] 821 3rd Generation Partnership Project (3GPP), "Policy and 822 Charging Control System for 5G Framework; Stage 2, 3GPP TS 823 23.503 v1.0.0", December 2017. 825 [TS.29.281-3GPP] 826 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 827 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 828 December 2017. 830 Authors' Addresses 832 Uma Chunduri (editor) 833 Huawei USA 834 2330 Central Expressway 835 Santa Clara, CA 95050 836 USA 838 Email: uma.chunduri@huawei.com 839 Richard Li 840 Huawei USA 841 2330 Central Expressway 842 Santa Clara, CA 95050 843 USA 845 Email: renwei.li@huawei.com 847 Jeff Tantsura 848 Nuage Networks 849 755 Ravendale Drive 850 Mountain View, CA 94043 851 USA 853 Email: jefftant.ietf@gmail.com 855 Luis M. Contreras 856 Telefonica 857 Sur-3 building, 3rd floor 858 Madrid 28050 859 Spain 861 Email: luismiguel.contrerasmurillo@telefonica.com 863 Xavier De Foy 864 InterDigital Communications, LLC 865 1000 Sherbrooke West 866 Montreal 867 Canada 869 Email: Xavier.Defoy@InterDigital.com