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