idnits 2.17.1 draft-clt-dmm-tn-aware-mobility-02.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 (October 16, 2018) is 2019 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 259, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 768, but no explicit reference was found in the text == Outdated reference: A later version (-08) 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 (-18) exists of draft-farinacci-lisp-mobile-network-04 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-02 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group U. Chunduri, Ed. 3 Internet-Draft R. Li 4 Intended status: Standards Track Huawei USA 5 Expires: April 19, 2019 J. Tantsura 6 Apstra, Inc. 7 L. Contreras 8 Telefonica 9 X. De Foy 10 InterDigital Communications, LLC 11 October 16, 2018 13 Transport Network aware Mobility for 5G 14 draft-clt-dmm-tn-aware-mobility-02 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 April 19, 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 2.3. Transport Network Function . . . . . . . . . . . . . . . 9 80 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9 81 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 10 82 3.2. Path Steering Support to native IP user planes . . . . . 12 83 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 12 84 3.4. PPR with various 5G Mobility procedures . . . . . . . . . 12 85 3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12 86 3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13 87 3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 14 88 4. Other TE Technologies Applicability . . . . . . . . . . . . . 15 89 5. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 9.2. Informative References . . . . . . . . . . . . . . . . . 16 96 Appendix A. Appendix: New Control Plane and User Planes . . . . 19 97 A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 19 98 A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction and Problem Statement 103 3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 104 [TS.23.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9 105 [TS.23.501-3GPP] has been created between 2 User Plane 106 Functionalities (UPFs). While user plane for N9 interface being 107 finalized for REL16, both GTP-U based encapsulation or any other 108 compatible approach is being considered [CT4SID]. Concerning to this 109 document another relevant interface is N3, which is between gNB and 110 the UPF. N3 interface is similar to the user plane interface S1U in 111 LTE [TS.23.401-3GPP]. This document: 113 o does not propose any change to existing N3 user plane 114 encapsulations to realize the benefits with the approach specified 115 here 117 o and can work with any encapsulation (including GTP-U) for the N9 118 interface. 120 [TS.23.501-3GPP] defines various Session and Service Continuity (SSC) 121 modes and mobility scenarios for 5G with slice awareness from Radio 122 and 5G Core (5GC) network. 5G System (5GS) as defined, allows 123 transport network between N3 and N9 interfaces work independently 124 with various IETF Traffic Engineering (TE) technologies. 126 However, lack of underlying Transport Network (TN) awareness can be 127 problematic for some of the 5GS procedures, for real-time, mission- 128 critical or for any deterministic latency services. These 5GS 129 procedures including but not limited to Service Request, PDU Session, 130 or User Equipment (UE) mobility need same service level 131 characteristics from the TN for the Protocols Data Unit (PDU) 132 session, similar to as provided in Radio and 5GC for various 5QI's 133 defined in [TS.23.501-3GPP] . 135 1.1. Acronyms 137 5QI - 5G QoS Indicator 139 AMF - Access and Mobility Management Function (5G) 141 BP - Branch Point (5G) 143 CSR - Cell Site Router 144 DN - Data Network (5G) 146 eMBB - enhanced Mobile Broadband (5G) 148 FRR - Fast ReRoute 150 gNB - 5G NodeB 152 GBR - Guaranteed Bit Rate (5G) 154 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 156 LFA - Loop Free Alternatives (IP FRR) 158 mIOT - Massive IOT (5G) 160 MPLS - Multi Protocol Label Switching 162 QFI - QoS Flow ID (5G) 164 PPR - Preferred Path Routing 166 PDU - Protocol Data Unit (5G) 168 PW - Pseudo Wire 170 RQI - Reflective QoS Indicator (5G) 172 SBI - Service Based Interface (5G) 174 SID - Segment Identifier 176 SMF - Session Management Function (5G) 178 SSC - Session and Service Continuity (5G) 180 SST - Slice and Service Types (5G) 182 SR - Segment Routing 184 TE - Traffic Engineering 186 ULCL - Uplink Classifier (5G) 188 UPF - User Plane Function (5G) 190 URLLC - Ultra reliable and low latency communications (5G) 192 1.2. Solution Approach 194 This document specifies a mechanism to fulfil the needs of 5GS to 195 transport user plane traffic from gNB to UPF for all service 196 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 197 done by, keeping mobility procedures aware of underlying transport 198 network along with slicing requirements. TN with mobility awareness 199 described here in a way, which does not erase performance and latency 200 gains made with 5G New Radio(5GNR) and virtualized cellular core 201 network features developed in [TS.23.501-3GPP]. 203 Section 2 describes two methods, with which Transport Network (TN) 204 aware mobility can be built irrespective of underlying TN technology 205 used. Using Preferred Path Routing (PPR) as TN Underlay is detailed 206 in Section 3. Section 3.4 further describes the applicability and 207 procedures of the same with 5G SSC modes on N3 and N9 interfaces. At 208 the end, Section 5 recapitulates the benefits of specified approach 209 in mobile networks. 211 2. Transport Network (TN) and Slice aware Mobility on N3/N9 213 Service Based Interfaces (SBI) 214 ----+-----+-----+----+----+-----+----+--------+-----+----+------ 215 | | | | | | | | | | 216 +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ 217 | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | 218 +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ 219 +---+----+ +--+--+ +---=++ +--------------+-+ 220 | AMF | | PCF | | TNF | | SMF | 221 +---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ 222 N1 | | | | To | 223 to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 224 | | | | | | 225 +---+---+ +--++ +-+--+---+ +-+-----+ +----+ 226 |gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | 227 +---+ +---+ +-+------+ +-------+ +----+ 228 | +----+ 229 +-| DN | 230 N6 +----+ 232 Figure 1: 5G Service Based Architecture 234 The above diagrams depicts one of the scenarios of the 5G network 235 specified in [TS.23.501-3GPP] and with a new and virtualized control 236 component Transport Network Function (TNF). A Cell Site Router (CSR) 237 is shown connecting to gNB. Though it is shown as a separate block 238 from gNB, in some cases both of these can be co-located. This 239 document concerns with backhaul TN, from CSR to UPF on N3 interface 240 or from Staging UPF to Anchor UPF on N9 interface. 242 Currently specified Control Plane (CP) functions Access and Mobility 243 Management Function (AMF), Session Management Function (SMF) and User 244 plane (UP) components gNodeB (gNB), User Plane Function (UPF) with 245 N2, N3, N4, N6 and N9 are relevant to this document. Other 246 Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, 247 NEF, and AF are not directly relevant for the discussion in this 248 document and one can see the functionalities of these in 249 [TS.23.501-3GPP]. 251 From encapsulation perspective, N3 interface is similar to S1U in 4G/ 252 LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to 253 transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). 254 Unlike S1U, N3 has some additional aspects as there is no bearer 255 concept and per no per bearer GTP-U tunnels. Instead, QoS 256 information is carried in the PDU Session Container GTP-U extension 257 header. N9 interface is a new interface to connect UPFs and right 258 user plane protocol/encapsulation is being studied through 3GPP CT4 259 WG approved study item [CT4SID] for REL-16. 261 TN Aware Mobility with optimized transport network functionality is 262 explained below. How PPR fits in this framework in detail along with 263 other various TE technologies briefly are in Section 3 and Section 4 264 respectively. 266 2.1. Discrete Approach 268 In this approach transport network functionality from gNB to UPF is 269 discrete and 5GS is not aware of the underlying transport network and 270 the resources available. Deployment specific mapping function is 271 used to map the GTP-U encapsulated traffic at gNB at UL and UPF in DL 272 direction to the appropriate transport slice or transport Traffic 273 Engineered (TE) paths. These TE paths can be established using RSVP- 274 TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing] 275 for both MPLS and IPv6 underlay or PPR 276 [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 with 277 SRH, native IPv6 and native IPv4 underlays. 279 In this case, the encapsulation provided by GTP-U helps carry 280 different PDU session types (IPv4, IPv6, IPv4IPv6, Ethernet and 281 Unstructured) independent of the underlying transport or user plane 282 (IPv4, IPv6 or MPLS) network. Mapping of the PDU sessions to TE 283 paths can be done based on the source UDP port ranges (if these are 284 assigned based on the PDU session QCIs, as done in some deployments 285 with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or 286 RQI values in the GTP-U header. Here, TNF as shown in Figure 1 need 287 not be part of the 5G Service Based Interface (SBI). Only management 288 plane functionality is needed to create, monitor, manage and delete 289 (life cycle management) the transport TE paths/transport slices from 290 gNB to UPF (on N3/N9 interfaces). This approach provide partial 291 integration of the transport network into 5GS with some benefits. 293 One of the limitations of this approach is the inability of 5GS 294 procedures to know, if underlying transport resources are available 295 for the traffic type being carried in PDU session before making 296 certain decisions in the 5G CP. One example scenario/decision could 297 be, a target gNB selection in Xn mobility event, without knowing if 298 the target gNB is having a underlay transport slice resource for the 299 5QI of the PDU session. The below approach can mitigate this. 301 2.2. Integrated Approach 303 Network Slice Selection Function (NSSF) as defined in 304 [TS.23.501-3GPP] concerns with multiple aspects including selecting a 305 network slice instance when requested by AMF based on the requested 306 SNSSAI, current location of UE, roaming indication etc. It also 307 notifies NF service consumers (e.g AMF) whenever the status about the 308 slice availability changes. However, the scope is only in 5GC (both 309 control and user plane) and NG Radio Access network including N3IWF 310 for non-3GPP access. Slice functionality is per PDU session 311 granularity, which covers needed functionality and resources from UE 312 registration, Tracking Area (TA) updates, mobility and roaming, 313 resources and functionalities needed from transport network is not 314 specified. This is seen as independent functionality and currently 315 not part of 5GS. If transport network is not factored in an 316 integrated fashion w.r.t available resources (with network 317 characteristics from desired bandwidth, latency, burst size handling 318 and optionally jitter) some of the gains made with optimizations 319 through 5GNR and 5GC can be degraded. 321 To assuage the above situation, TNF is described (Figure 1) as part 322 of control plane. This has the view of the underlying transport 323 network with all links and nodes as well as various possible underlay 324 paths with different characteristics. TNF can be seen as supporting 325 PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get 326 the TE and topology information of the underlying IGP network. 328 A south bound interface Ns is shown which interacts with the gNB/CSR. 329 'Ns' can use one or more mechanism available today (PCEP [RFC5440], 330 NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3 331 VPNs along with TE underlay paths from gNB to UPF. Ns and Nn 332 interfaces can be part of the integrated 3GPP architecture, but the 333 specification/ownership of these interfaces SHOULD be left out of 334 scope of 3GPP. 336 These VPNs and/or underlay TE paths MUST be similar on all gNB/CSRs 337 and UPFs concerned to allow mobility of UEs while associated with one 338 of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. A 339 north bound interface 'Nn' is shown from one or more of the transport 340 network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as shown in 341 Figure 1. It would enable learning the TE characteristics of all 342 links and nodes of the network continuously (through BGP-LS [RFC7752] 343 or through a passive IGP adjacency and PCEP [RFC5440]). 345 With the TNF in 5GS Service Based Interface, the following additional 346 functionalities are required for end-2-end slice management including 347 the transport network: 349 o The Specific Network Slice Selection Assistance Information 350 (SNSSAI) of PDU session's SHOULD be mapped to the assigned 351 transport VPN and the TE path information for that slice. 353 o For transport slice assignment for various SSTs (eMBB, URLLC, 354 MIoT) corresponding underlay paths need to be created and 355 monitored from each transport end point (gNB/CSR and UPF). 357 o During PDU session creation, apart from radio and 5GC resources, 358 transport network resources needed to be verified matching the 359 characteristics of the PDU session traffic type. 361 o Mapping of PDU session parameters to underlay SST paths need to be 362 done. One way to do this is through 5QI/QFI information in the 363 GTP-U header and map the same to the underlying transport path 364 (including VPN or PW). This works for uplink (UL) direction. 366 o For downlink direction RQI need to be considered to map the DL 367 packet to one of the underlay paths at the UPF. 369 o If any other form of encapsulation (other than GTP-U) either on N3 370 or N9 corresponding 5QI/QFI or RQI information MUST be there in 371 the encapsulation header. 373 o In some SSC modes Section 3.4, if segmented path (gNB to 374 staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then 375 corresponding path characteristics MUST be used. This includes a 376 path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP 377 UPF to eventual UPF access to DN. 379 o Continuous monitoring of transport path characteristics and 380 reassignment at the endpoints MUST be performed. For all the 381 effected PDU sessions, degraded transport paths need to be updated 382 dynamically with similar alternate paths. 384 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 385 based or N2 based), for target gNB selection, apart from radio 386 resources, transport resources MUST be factored. This enables 387 handling of all PDU sessions from the UE to target gNB and this 388 require co-ordination of gNB, AMF, SMF with the TNF module. 390 Changes to detailed signaling to integrate the above for various 5GS 391 procedures as defined in [TS.23.502-3GPP] is beyond the scope of this 392 document. 394 2.3. Transport Network Function 396 Proposed TNF as part of the 5GC shown in Figure 1 can be realized 397 using Abstraction and Control of TE Networks (ACTN). ACTN 398 architecture, underlying topology abstraction methods and 399 manageability considerations of the same are detailed in [RFC8453]. 401 3. Using PPR as TN Underlay 403 In a network implementing source routing, packets may be transported 404 through the use of Segment Identifiers (SIDs), where a SID uniquely 405 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 406 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 407 all SRv6 features along with a few concerns in Section 5.3.7 of the 408 same document. Those concerns are addressed by a new backhaul 409 routing mechanism called Preferred Path Routing (PPR), of which this 410 Section provides an overview. 412 The label/PPR-ID refer not to individual segments of which the path 413 is composed, but to the identifier of a path that is deployed on 414 network nodes. The fact that paths and path identifiers can be 415 computed and controlled by a controller, not a routing protocol, 416 allows the deployment of any path that network operators prefer, not 417 just shortest paths. As packets refer to a path towards a given 418 destination and nodes make their forwarding decision based on the 419 identifier of a path, not the identifier of a next segment node, it 420 is no longer necessary to carry a sequence of labels. This results 421 in multiple benefits including significant reduction in network layer 422 overhead, increased performance and hardware compatibility for 423 carrying both path and services along the path. 425 Details of the IGP extensions for PPR are provided here: 427 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 429 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 431 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 433 PPR does not remove GTP-U, unlike some other proposals laid out in 434 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 435 with the existing cellular user plane (GTP-U) for both N3 and any 436 approach selected for N9 (encap or no-encap). In this scenario, PPR 437 will only help providing TE benefits needed for 5G slices from 438 transport domain perspective. It does so without adding any 439 additional overhead to the user plane, unlike SR-MPLS or SRv6. This 440 is achieved by: 442 o For 3 different SSTs, 3 PPR-IDs can signaled from any node in the 443 transport network. For Uplink traffic, gNB will choose the right 444 PPR-ID of the UPF based on the 5QI value in the encapsulation 445 header of the PDU session. Similarly in the Downlink direction 446 matching PPR-ID of the gNB is chosen for the RQI value in the 447 encapsulated SL payload. The table below shows a typical mapping: 449 +----------------+------------+------------------+-----------------+ 450 | 5QI (Ranges)/ | SST | Transport Path | Transport Path | 451 | RQI (Ranges) | | Info | Characteristics | 452 +----------------+------------+------------------+-----------------+ 453 | Range Xx - Xy | | | | 454 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 455 | values) | (massive | PPR-ID-A | Bit Rate) | 456 | | IOT) | | Bandwidth: Bx | 457 | | | | Delay: Dx | 458 | | | | Jitter: Jx | 459 +----------------+------------+------------------+-----------------+ 460 | Range Yx - Yy | | | | 461 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 462 | values) | (ultra-low | PPR-ID-B | Req. | 463 | | latency) | | Bandwidth: By | 464 | | | | Delay: Dy | 465 | | | | Jitter: Jy | 466 +----------------+------------+------------------+-----------------+ 467 | Range Zx - Zy | | | | 468 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 469 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 470 +----------------+------------+------------------+-----------------+ 472 Figure 2: 5QI/RQI Mapping with PPR-IDs on N3/N9 474 o It is possible to have a single PPR-ID for multiple input points 475 through a PPR tree structure separate in UL and DL direction. 477 o Same set of PPRs are created uniformly across all needed gNBs and 478 UPFs to allow various mobility scenarios. 480 o Any modification of TE parameters of the path, replacement path 481 and deleted path needed to be updated from TNF to the relevant 482 ingress points. Same information can be pushed to the NSSF, AMF 483 and SMF as needed. 485 o PPR can be supported with any native IPv4 and IPv6 data/user 486 planes (Section 3.2 with optional TE features Section 3.3 . As 487 this is an underlay mechanism it can work with any overlay 488 encapsulation approach including GTP-U as defined currently for N3 489 interface. 491 3.2. Path Steering Support to native IP user planes 493 PPR works in fully compatible way with SR defined user planes (SR- 494 MPLS and SRv6) by reducing the path overhead and other challenges as 495 listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or 496 Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR 497 also expands the source routing to user planes beyond SR-MPLS and 498 SRv6 i.e., native IPv6 and IPv4 user planes. 500 This helps legacy transport networks to get the immediate path 501 steering benefits and helps in overall migration strategy of the 502 network to the desired user plane. It is important to note, these 503 benefits can be realized with no hardware upgrade except control 504 plane software for native IPv6 and IPv4 user planes. 506 3.3. Service Level Guarantee in Underlay 508 PPR also optionally allows to allocate resources that are to be 509 reserved along the preferred path. These resources are required in 510 some cases (for some 5G SSTs with stringent GBR and latency 511 requirements) not only for providing committed bandwidth or 512 deterministic latency, but also for assuring overall service level 513 guarantee in the network. This approach does not require per-hop 514 provisioning and reduces the OPEX by minimizing the number of 515 protocols needed and allows dynamism with Fast-ReRoute (FRR) 516 capabilities. 518 3.4. PPR with various 5G Mobility procedures 520 PPR fulfills the needs of 5GS to transport the user plane traffic 521 from gNB to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This is 522 done in keeping the backhaul network at par with 5G slicing 523 requirements that are applicable to Radio and virtualized core 524 network to create a truly end-to-end slice path for 5G traffic. When 525 UE moves from one gNB to another gNB, there is no transport network 526 reconfiguration require with the approach above. 528 SSC mode would be specified/defaulted by SMF. No change in the mode 529 once connection is initiated and this property is not altered here. 531 3.4.1. SSC Mode1 532 +---+----+ +-----+ +----------------+ 533 | AMF | | TNF | | SMF | 534 +---+--+-+ +-+-+-+ +-+--------------+ 535 N1 | | | | 536 +--------+ N2 +----Ns---+ +-Nn-+ N4 537 | | | | | 538 + +---+---+ +--++ +-+--+---+ +----+ 539 UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN | 540 == +---+ +---+ +--------+ +----+ 542 Figure 3: SSC Mode1 with integrated Transport Slice Function 544 After UE1 moved to another gNB in the same UPF serving area 546 +---+----+ +-----+ +----------------+ 547 | AMF | | TNF | | SMF | 548 +---_--+-+ +-+-+-+ +-+--------------+ 549 | | | | 550 N2 +----Ns---+ +-Nn-+ N4 551 | | | | 552 +----+--+ +-+-+ ++--+----+ +----+ 553 |gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN | 554 +----+ +---+ +---+----+ +----+ 555 | 556 | 557 | 558 | 559 +----+ +--++ | 560 UE1 |gNB2+======+CSR+------N3--------+ 561 == +----+ +---+ 563 Figure 4: SSC Mode1 with integrated Transport Slice Function 565 In this mode, IP address at the UE is preserved during mobility 566 events. This is similar to 4G/LTE mechanism and for respective 567 slices, corresponding PPR-ID (TE Path) has to be assigned to the 568 packet at UL and DL direction. During Xn mobility as shown above, 569 source gNB has to additionally ensure transport path's resources from 570 TNF are available at the target gNB apart from radio resources check 571 (at decision and request phase of Xn/N2 mobility scenario). 573 3.4.2. SSC Mode2 575 In this case, if IP Address is changed during mobility (different UPF 576 area), then corresponding PDU session is released. No session 577 continuity from the network is provided and this is designed as an 578 application offload and application manages the session continuity, 579 if needed. For PDU Session, Service Request and Mobility cases 580 mechanism to select the transport resource and the PPR-ID (TE Path) 581 is similar to SSC Mode1. 583 3.4.3. SSC Mode3 585 In this mode, new IP address may be assigned because of UE moved to 586 another UPF coverage area. Network ensures UE suffers no loss of 587 'connectivity'. A connection through new PDU session anchor point is 588 established before the connection is terminated for better service 589 continuity. 591 +---+----+ +-----+ +----------------+ 592 | AMF | | TNF | | SMF | 593 +---+--+-+ +-+-+-+ +-+-----------+--+ 594 N1 | | | | | 595 to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| 596 | | | | | 597 +-------+--+ +--+-------+--+ +-----+-+ 598 |gNB/CSR +---N3---+ BP/ULCL UPF +-N9--+ UPF +-N6-- 599 +----------+ +----------+--+ +-------+ to DN 600 | +----+ 601 +-| DN | 602 N6 +----+ 604 Figure 5: SSC Mode3 and Service Continuity 606 In the uplink direction for the traffic offloading from UL/CL case, 607 packet has to reach to the right exit UPF. In this case packet gets 608 re-encapsulated with ULCL marker (with either GTP-U or the chosen 609 encapsulation) after bit rate enforcement and LI to the anchor UPF. 610 At this point packet has to be on the appropriate VPN/PW to the 611 anchor UPF. This mapping is done based on the 5QI to the PPR-ID of 612 the exit node by selecting the respective TE PPR-ID (PPR path) of the 613 UPF. If it's a non-MPLS underlay, destination IP address of the 614 encapsulation header would be the mapped PPR-ID (TE path). 616 In the downlink direction for the incoming packet, UPF has to 617 encapsulate the packet (with either GTP-U or the chosen 618 encapsulation) to reach the BP/ULCL UPF. Here mapping is done for 619 RQI parameter in the encapsulation header to PPR-ID (TE Path) of the 620 BP/ULCL UPF. If it's a non-MPLS underlay, destination IP address of 621 the encapsulation header would be the mapped PPR-ID (TE path). In 622 summary: 624 o Respective PPR-ID on N3 and N9 has to be selected with correct 625 transport characteristics from TNF. 627 o For N2 based mobility AMF/SMF has to ensure transport resources 628 are available for N3 Interface to new ULCL and from there the 629 original anchor point UPF. 631 o For Service continuity with multi-homed PDU session same transport 632 network characteristics of the original PDU session (both on N3 633 and N9) need to be observed for the newly created PDU session. 635 4. Other TE Technologies Applicability 637 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 638 for MPLS user plane. However, it is perceived as less dynamic in 639 some cases and has some provisioning overhead across all the nodes in 640 N3 and N9 interface nodes. Also it has another drawback with 641 excessive state refresh overhead across adjacent nodes and this can 642 be mitigated with [RFC8370]. 644 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 645 bandwidth reservation or mechanism to guarantee latency on the nodes/ 646 links on SR path. But, SR allows path steering for any flow at the 647 ingress and particular path for a flow can be chosen. Some of the 648 issues around path overhead/tax, MTU issues are documented at 649 Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- 650 MPLS allows reduction of the control protocols to one IGP (with out 651 needing for LDP and RSVP-TE). 653 However, as specified above with PPR (Section 3), in the integrated 654 transport network function (TNF) a particular RSVP-TE path for MPLS 655 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to 656 SMF for mapping a particular PDU session to the transport path. 658 5. Summary and Benefits with PPR 660 This document specifies an approach to transport and slice aware 661 mobility with a simple mapping function from PDU Session to transport 662 path applicable to any TE underlay. 664 This also describes PPR 665 [I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay 666 routing mechanism, which helps with goal of optimized user plane for 667 N9 interface. PPR provides a method for N3 and N9 interfaces to 668 support transport slicing in a way which does not erase the gains 669 made with 5GNR and virtualized cellular core network features for 670 various types of 5G traffic (e.g. needing low and deterministic 671 latency, real-time, mission-critical or AR/VR traffic). PPR provides 672 path steering, optionally guaranteed services with TE, unique Fast- 673 ReRoute (FRR) mechanism with preferred backups (beyond shortest path 674 backups through existing LFA schemes) in the mobile backhaul network 675 with any underlay being used in the operator's network (IPv4, IPv6 or 676 MPLS) in an optimized fashion. 678 6. Acknowledgements 680 Thanks to Young Lee and John Kaippallimalil for discussions on this 681 document including ACTN applicability for the proposed TNF. Thanks 682 to Sri Gundavelli and 3GPP delegates who provided detailed feedback 683 on this document. 685 7. IANA Considerations 687 This document has no requests for any IANA code point allocations. 689 8. Security Considerations 691 This document does not introduce any new security issues. 693 9. References 695 9.1. Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, 699 DOI 10.17487/RFC2119, March 1997, 700 . 702 9.2. Informative References 704 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 705 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 706 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 707 Camarillo, "Topology Independent Fast Reroute using 708 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 709 lfa-05 (work in progress), October 2018. 711 [I-D.bogineni-dmm-optimized-mobile-user-plane] 712 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 713 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 714 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 715 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 716 optimized-mobile-user-plane-01 (work in progress), June 717 2018. 719 [I-D.chunduri-lsr-isis-preferred-path-routing] 720 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 721 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 722 draft-chunduri-lsr-isis-preferred-path-routing-01 (work in 723 progress), July 2018. 725 [I-D.chunduri-lsr-ospf-preferred-path-routing] 726 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 727 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 728 chunduri-lsr-ospf-preferred-path-routing-01 (work in 729 progress), July 2018. 731 [I-D.farinacci-lisp-mobile-network] 732 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 733 for the Mobile Network", draft-farinacci-lisp-mobile- 734 network-04 (work in progress), September 2018. 736 [I-D.ietf-dmm-srv6-mobile-uplane] 737 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 738 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 739 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 740 uplane-02 (work in progress), July 2018. 742 [I-D.ietf-spring-segment-routing] 743 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 744 Litkowski, S., and R. Shakir, "Segment Routing 745 Architecture", draft-ietf-spring-segment-routing-15 (work 746 in progress), January 2018. 748 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 749 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 750 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 751 . 753 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 754 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 755 DOI 10.17487/RFC5440, March 2009, 756 . 758 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 759 and A. Bierman, Ed., "Network Configuration Protocol 760 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 761 . 763 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 764 Locator/ID Separation Protocol (LISP)", RFC 6830, 765 DOI 10.17487/RFC6830, January 2013, 766 . 768 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 769 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 770 RFC 7490, DOI 10.17487/RFC7490, April 2015, 771 . 773 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 774 S. Ray, "North-Bound Distribution of Link-State and 775 Traffic Engineering (TE) Information Using BGP", RFC 7752, 776 DOI 10.17487/RFC7752, March 2016, 777 . 779 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 780 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 781 . 783 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 784 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 785 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 786 . 788 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 789 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 790 DOI 10.17487/RFC8453, August 2018, 791 . 793 [TS.23.401-3GPP] 794 3rd Generation Partnership Project (3GPP), "Procedures for 795 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 797 [TS.23.501-3GPP] 798 3rd Generation Partnership Project (3GPP), "System 799 Architecture for 5G System; Stage 2, 3GPP TS 23.501 800 v2.0.1", December 2017. 802 [TS.23.502-3GPP] 803 3rd Generation Partnership Project (3GPP), "Procedures for 804 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 805 2017. 807 [TS.23.503-3GPP] 808 3rd Generation Partnership Project (3GPP), "Policy and 809 Charging Control System for 5G Framework; Stage 2, 3GPP TS 810 23.503 v1.0.0", December 2017. 812 [TS.29.281-3GPP] 813 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 814 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 815 December 2017. 817 Appendix A. Appendix: New Control Plane and User Planes 819 A.1. LISP and PPR 821 PPR can also be used with LISP control plane for 3GPP as described in 822 [I-D.farinacci-lisp-mobile-network]. This can be achieved by mapping 823 the UE IP address (EID) to PPR-ID, which acts as Routing Locator 824 (RLOC). Any encapsulation supported by LISP can work well with PPR. 825 If the RLOC refers to an IPv4 or IPv6 destination address in the LISP 826 encapsulated header, packets are transported on the preferred path in 827 the network as opposed to traditional shortest path routing with no 828 additional user plane overhead related to TE path in the network 829 layer. 831 Some of the distinct advantages of the LISP approach is, its 832 scalability, support for service continuity in SSC Mode3 as well as 833 native support for session continuity (session survivable mobility). 834 Various other advantages are documented at 835 [I-D.farinacci-lisp-mobile-network]. 837 A.2. ILA and PPR 839 If an ILA-prefix is allowed to refer to a PPR-ID, ILA can be 840 leveraged with all the benefits (including mobility) that it 841 provides. This works fine in the DL direction as packet is destined 842 to UE IP address at UPF. However, in the UL direction, packet is 843 destined to an external internet address (SIR Prefix to ILA Prefix 844 transformation happens on the Source address of the original UE 845 packet). One way to route the packet with out bringing the complete 846 DFZ BGP routing table is by doing a default route to the UPF (ILA-R). 847 In this case, how TE can be achieved is TBD (to be expanded further 848 with details). 850 Authors' Addresses 851 Uma Chunduri (editor) 852 Huawei USA 853 2330 Central Expressway 854 Santa Clara, CA 95050 855 USA 857 Email: uma.chunduri@huawei.com 859 Richard Li 860 Huawei USA 861 2330 Central Expressway 862 Santa Clara, CA 95050 863 USA 865 Email: renwei.li@huawei.com 867 Jeff Tantsura 868 Apstra, Inc. 870 Email: jefftant.ietf@gmail.com 872 Luis M. Contreras 873 Telefonica 874 Sur-3 building, 3rd floor 875 Madrid 28050 876 Spain 878 Email: luismiguel.contrerasmurillo@telefonica.com 880 Xavier De Foy 881 InterDigital Communications, LLC 882 1000 Sherbrooke West 883 Montreal 884 Canada 886 Email: Xavier.Defoy@InterDigital.com