idnits 2.17.00 (12 Aug 2021) /tmp/idnits55389/draft-chunduri-dmm-5g-mobility-with-ppr-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-chunduri-lsr-isis-preferred-path-routing-06 == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-07 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-09 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 1 error (**), 0 flaws (~~), 7 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 Futurewei 4 Intended status: Informational L. Contreras 5 Expires: May 6, 2021 Telefonica 6 S. Bhaskaran 7 Altiostar 8 J. Tantsura 9 Apstra, Inc. 10 P. Muley 11 Nokia 12 November 2, 2020 14 Transport aware 5G mobility with PPR 15 draft-chunduri-dmm-5g-mobility-with-ppr-00 17 Abstract 19 This document describes few 5G mobility scenarios and how mobile 20 network functions map its SST criteria to identifiers in IP packets 21 that transport segments use to grant transport layer services. This 22 is based on mapping between mobile and IP transport underlays (IPv6, 23 MPLS, IPv4) and a new transport network underlay routing mechanism, 24 Preferred Path Routing (PPR), which brings slice properties and works 25 with any underlying transport (L2, IPv4, SR and MPLS) is described. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 6, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Transport Network Underlays . . . . . . . . . . . . . . . . . 4 70 2.1. Using PPR as TN Underlay . . . . . . . . . . . . . . . . 4 71 2.1.1. PPR on F1-U/N3/N9 Interfaces . . . . . . . . . . . . 5 72 2.1.2. Path Steering Support to native IP user planes . . . 6 73 2.1.3. Service Level Guarantee in Underlay . . . . . . . . . 6 74 3. PPR with various 5G Mobility procedures . . . . . . . . . . . 7 75 3.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 7.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 [I-D.clt-dmm-tn-aware-mobility] describes in detail on how TN aware 89 mobility can be built irrespective of underlying TN technology used. 91 This document specifies an approach to fulfil the needs of 5GS to 92 transport user plane traffic from 5G-AN to UPF for all session and 93 service continuity modes (SSC) [TS.23.501-3GPP] in an optimized 94 fashion. This is done by, keeping establishment and mobility 95 procedures aware of underlying transport network along with slicing 96 requirements using integrated routing and traffic engineering 97 mechanism, Preferred Path Routing (PPR). 99 PPR is applicable to any transport network underlay (IPv6, MPLS and 100 IPv4) is detailed in Section 2.1 used 5G x-haul as described in 101 [I-D.clt-dmm-tn-aware-mobility] . At the end, Section 3 further 102 describes the applicability and procedures of PPR with 5G mobility 103 scenarios in variou mobility scenarios in variouss SSC modes on F1-U, 104 N3 and N9 interfaces. 106 1.1. Acronyms 108 5G-AN - 5G Access Network 110 BP - Branch Point (5G) 112 CSR - Cell Site Router 114 DN - Data Network (5G) 116 eMBB - enhanced Mobile Broadband (5G) 118 FRR - Fast ReRoute 120 gNB - 5G NodeB 122 GBR - Guaranteed Bit Rate (5G) 124 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 126 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 128 mIOT - Massive IOT (5G) 130 MPLS - Multi Protocol Label Switching 132 NSSMF - Network Slice Selection Management Function 134 PPR - Preferred Path Routing 136 PDU - Protocol Data Unit (5G) 138 RAN - Radio Access Network 140 SID - Segment Identifier 142 SSC - Session and Service Continuity (5G) 144 SST - Slice and Service Types (5G) 146 SR - Segment Routing 147 TE - Traffic Engineering 149 ULCL - Uplink Classifier (5G) 151 UP - User Plane(5G) 153 UPF - User Plane Function (5G) 155 URLLC - Ultra reliable and low latency communications (5G) 157 2. Transport Network Underlays 159 Apart from the various flavors of IETF VPN technologies to share the 160 transport network resources and capacity, TE capabilities in the 161 underlay network is an essential component to realize the 5G TN 162 requirements. This section focuses on PPR and its applicability to 163 realize Midhaul/Backhaul transport networks. Focus is on the user/ 164 data plane i.e., F1-U/N3/N9 interfaces as laid out in the framework 165 [I-D.clt-dmm-tn-aware-mobility]. 167 2.1. Using PPR as TN Underlay 169 In a network implementing source routing, packets may be transported 170 through the use of Segment Identifiers (SIDs), where a SID uniquely 171 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 172 The need for underlay agnostic (L2/IPv4/IPv6/MPLS) TE requirements 173 are addressed by PPR, of which this section provides an overview. 175 With PPR, the label/PPR-ID refer not to individual segments of which 176 the path is composed, but to the identifier of a path that is 177 deployed on network nodes. The fact that paths and path identifiers 178 can be computed and controlled by a controller, not a routing 179 protocol, allows the deployment of any path that network operators 180 prefer, not just shortest paths. As packets refer to a path towards 181 a given destination and nodes make their forwarding decision based on 182 the identifier of a path, not the identifier of a next segment node, 183 it is no longer necessary to carry a sequence of labels. This 184 results in multiple benefits including significant reduction in 185 network layer overhead, increased performance and hardware 186 compatibility for carrying both path and services along the path. 188 Details of the IGP extensions for PPR are provided here: 190 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 192 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 194 o PPR Graph Structure (P2MP) - [I-D.ce-lsr-ppr-graph] 196 2.1.1. PPR on F1-U/N3/N9 Interfaces 198 PPR does not remove GTP-U, unlike some other proposals laid out in 199 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 200 with the existing cellular user plane (GTP-U) for F1-U/N3 and N9 201 (encapsulation or no-encapsulation). In this scenario, PPR will only 202 help providing TE benefits needed for 5G slices from transport domain 203 perspective. It does so for any underlying user/data plane used in 204 the transport network (L2/IPv4/IPv6/MPLS). This is achieved by: 206 o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in 207 the transport network. For Uplink traffic, the 5G-AN will choose 208 the right PPR-ID based on the S-NSSAI the PDU Session belongs to 209 and/or the UDP Source port (corresponds to the MTNC-ID 210 [I-D.clt-dmm-tn-aware-mobility]) of the GTP-U encapsulation 211 header. Similarly in the Downlink direction matching PPR-ID of 212 the 5G-AN is chosen based on the S-NSSAI the PDU Session belongs 213 to. The table below shows a typical mapping: 215 +----------------+------------+------------------+-----------------+ 216 |GTP/UDP SRC PORT| SST | Transport Path | Transport Path | 217 | | in S-NSSAI | Info | Characteristics | 218 +----------------+------------+------------------+-----------------+ 219 | Range Xx - Xy | | | | 220 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 221 | values) | (massive | PPR-ID-A | Bit Rate) | 222 | | IOT) | | Bandwidth: Bx | 223 | | | | Delay: Dx | 224 | | | | Jitter: Jx | 225 +----------------+------------+------------------+-----------------+ 226 | Range Yx - Yy | | | | 227 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 228 | values) | (ultra-low | PPR-ID-B | Req. | 229 | | latency) | | Bandwidth: By | 230 | | | | Delay: Dy | 231 | | | | Jitter: Jy | 232 +----------------+------------+------------------+-----------------+ 233 | Range Zx - Zy | | | | 234 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 235 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 236 +----------------+------------+------------------+-----------------+ 238 Figure 1: Mapping of PPR-IDs on N3/N9 240 o It is possible to have a single PPR-ID for multiple input points 241 through a PPR tree/graph structure ([I-D.ce-lsr-ppr-graph]) 242 separate in UL and DL direction. 244 o Same set of PPRs are created uniformly across all needed 5G-ANs 245 and UPFs to allow various mobility scenarios. 247 o Any modification of TE parameters of the path, replacement path 248 and deleted path needed to be updated from TNF to the relevant 249 ingress points. Same information can be pushed to the NSSF, and/ 250 or SMF as needed. 252 o PPR can be supported with any native IPv4 and IPv6 data/user 253 planes (Section 2.1.2) with optional TE features (Section 2.1.3) . 254 As this is an underlay mechanism it can work with any overlay 255 encapsulation approach including GTP-U as defined currently for N3 256 interface. 258 2.1.2. Path Steering Support to native IP user planes 260 PPR works in fully compatible way with SR [RFC8402] defined user 261 planes (SR-MPLS and SRv6) by reducing the path overhead and other 262 challenges as listed in Section 5.3.7 of 263 [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the 264 source routing to beyond SR-MPLS and SRv6 i.e., L2, native IPv6 and 265 IPv4 user planes. 267 This helps legacy transport networks to get the immediate path 268 steering benefits and helps in overall migration strategy of the 269 network to the desired user plane. Some of these benefits with PPR 270 can be realized with no hardware upgrade except control plane 271 software for native IPv6 and IPv4 user planes. 273 2.1.3. Service Level Guarantee in Underlay 275 PPR optionally allows to allocate resources that are to be reserved 276 along the preferred path. These resources are required in some cases 277 (for some 5G SSTs with stringent GBR and latency requirements) not 278 only for providing committed bandwidth or deterministic latency, but 279 also for assuring overall service level guarantee in the network. 280 This approach does not require per-hop provisioning and reduces the 281 OPEX by minimizing the number of protocols needed and allows dynamism 282 with Fast-ReRoute (FRR) capabilities. 284 3. PPR with various 5G Mobility procedures 286 PPR fulfills the needs of 5GS to transport the user plane traffic 287 from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This 288 is done in keeping the backhaul network at par with 5G slicing 289 requirements that are applicable to Radio and virtualized core 290 network to create a truly end-to-end slice path for 5G traffic. When 291 UE moves across the 5G-AN (e.g. from one gNB to another gNB), there 292 is no transport network reconfiguration required with the approach 293 above. 295 SSC mode would be specified/defaulted by SMF. No change in the mode 296 once connection is initiated and this property is not altered here. 298 3.1. SSC Mode1 300 +--------------+ 301 +---+----+ |NSSMF +-----+ | +----------------+ 302 | AMF | | | TNF | | | SMF | 303 +---+--+-+ | +-+-+-+ | +-----+----------+ 304 N1 | +--------+-+---+ | 305 | | | | | 306 | | +---+-+--+ | 307 | | | SDN-C | | 308 | | +---+-+--+ | 309 | | | | | 310 +--------+ N2 +---------+ + ---+ | 311 | | | | | 312 + +---+--+ +--++ +---+ +-+--+ +----+ 313 UE1 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN | 314 == +---+ +---+ +---+ +----+ +----+ 316 Figure 2: SSC Mode1 with integrated Transport Slice Function 318 After UE1 moved to another gNB in the same UPF serving area 319 +--------------+ 320 +---+----+ |NSSMF +-----+ | +----------------+ 321 | AMF | | | TNF | | | SMF | 322 +------+-+ | +-+-+-+ | +-----+----------+ 323 | +--------+-+---+ | 324 | | | | 325 | +---+-+--+ | 326 | | SDN-C | | 327 | +---+-+--+ | 328 | | | | 329 N2 +---------+ + ---+ | 330 | | | | 331 +---+--+ +--++ +---+ +-+--+ +----+ 332 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN | 333 +---+ +---+ +-+-+ +----+ +----+ 334 | 335 | 336 | 337 | 338 +----+ +---+ | 339 UE1 |gNB2|======|CSR|------N3-------+ 340 == +----+ +---+ 342 Figure 3: SSC Mode1 with integrated Transport Slice Function 344 In this mode, IP address at the UE is preserved during mobility 345 events. This is similar to 4G/LTE mechanism and for respective 346 slices, corresponding PPR-ID (TE Path) has to be assigned to the 347 packet at UL and DL direction. During Xn mobility as shown above, 348 source gNB has to additionally ensure transport path's resources from 349 TNF are available at the target gNB apart from radio resources check 350 (at decision and request phase of Xn/N2 mobility scenario). 352 3.2. SSC Mode2 354 In this case, if IP Address is changed during mobility (different UPF 355 area), then corresponding PDU session is released. No session 356 continuity from the network is provided and this is designed as an 357 application offload and application manage the session continuity, if 358 needed. For PDU Session, Service Request and Mobility cases 359 mechanism to select the transport resource and the PPR-ID (TE Path) 360 is similar to SSC Mode1. 362 3.3. SSC Mode3 364 In this mode, new IP address may be assigned because of UE moved to 365 another UPF coverage area. Network ensures UE suffers no loss of 366 'connectivity'. A connection through new PDU session anchor point is 367 established before the connection is terminated for better service 368 continuity. There are two ways in which this happens. 370 o Change of SSC Mode 3 PDU Session Anchor with multiple PDU 371 Sessions. 373 o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU 374 Session. 376 In the first mode, from user plane perspective, the two PDU sessions 377 are independent and the use of PPR-ID by gNB and UPFs is exactly 378 similar to SSC Mode 1 described above. The following paragraphs 379 describe the IPv6 multi-homed PDU session case for SSC Mode 3. 381 +--------------+ 382 +---+----+ |NSSMF +-----+ | +----------------+ 383 | AMF | | | TNF | | | SMF | 384 +---+--+-+ | +-+-+-+ | +-+-----------+--+ 385 | | +--------+-+---+ | | 386 N1 | | | | | 387 | | +---+-+--+ | | 388 | | | SDN-C | | | 389 | | +---+-+--+ | | 390 | | | | | | 391 to-UE+----+ N2 +-----------+ | N4 N4| 392 +---+ | | | | 393 | | | | | 394 +---+ +---++ +---+ +-------+--+ +---+ +---+ 395 |gNB|===|CSR |---N3---|PE |-| BP UPF |-N9-|PE |-|UPF|-N6-> 396 +---+ +----+ +---+ +-------+--+ +---+ +---+ to DN 397 | +----+ 398 +-| DN | 399 N6 +----+ 401 Figure 4: SSC Mode3 and Service Continuity 403 In the uplink direction for the traffic offloading from the Branching 404 Point UPF, packet has to reach to the right exit UPF. In this case 405 packet gets re-encapsulated by the BP UPF (with either GTP-U or the 406 chosen encapsulation) after bit rate enforcement and LI, towards the 407 anchor UPF. At this point packet has to be on the appropriate VPN/PW 408 to the anchor UPF. This mapping is done based on the S-NSSAI the PDU 409 session belongs to and/or with the UDP source port (corresponds to 410 the MTNC-ID [I-D.clt-dmm-tn-aware-mobility]) of the GTP-U 411 encapsulation header to the PPR-ID of the exit node by selecting the 412 respective TE PPR-ID (PPR path) of the UPF. If it's a non-MPLS 413 underlay, destination IP address of the encapsulation header would be 414 the mapped PPR-ID (TE path). 416 In the downlink direction for the incoming packet, UPF has to 417 encapsulate the packet (with either GTP-U or the chosen 418 encapsulation) to reach the BP UPF. Here mapping is done based on 419 the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the 420 BP UPF. If it's a non-MPLS underlay, destination IP address of the 421 encapsulation header would be the mapped PPR-ID (TE path). In 422 summary: 424 o Respective PPR-ID on N3 and N9 has to be selected with correct 425 transport characteristics from TNF. 427 o For N2 based mobility SMF has to ensure transport resources are 428 available for N3 Interface to new BP UPF and from there the 429 original anchor point UPF. 431 o For Service continuity with multi-homed PDU session same transport 432 network characteristics of the original PDU session (both on N3 433 and N9) need to be observed for the newly configured IPv6 434 prefixes. 436 4. Acknowledgements 438 TBD. 440 5. IANA Considerations 442 This document has no requests for any IANA code point allocations. 444 6. Security Considerations 446 This document does not introduce any new security issues. 448 7. References 449 7.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 7.2. Informative References 458 [I-D.bogineni-dmm-optimized-mobile-user-plane] 459 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 460 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 461 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 462 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 463 optimized-mobile-user-plane-01 (work in progress), June 464 2018. 466 [I-D.ce-lsr-ppr-graph] 467 Chunduri, U. and T. Eckert, "Preferred Path Route Graph 468 Structure", draft-ce-lsr-ppr-graph-04 (work in progress), 469 September 2020. 471 [I-D.chunduri-lsr-isis-preferred-path-routing] 472 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 473 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 474 draft-chunduri-lsr-isis-preferred-path-routing-06 (work in 475 progress), September 2020. 477 [I-D.chunduri-lsr-ospf-preferred-path-routing] 478 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 479 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 480 chunduri-lsr-ospf-preferred-path-routing-04 (work in 481 progress), March 2020. 483 [I-D.clt-dmm-tn-aware-mobility] 484 Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J., 485 Tantsura, J., Contreras, L., and P. Muley, "Transport 486 Network aware Mobility for 5G", draft-clt-dmm-tn-aware- 487 mobility-07 (work in progress), September 2020. 489 [I-D.ietf-dmm-srv6-mobile-uplane] 490 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 491 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 492 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09 493 (work in progress), July 2020. 495 [I-D.ietf-spring-segment-routing] 496 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 497 Litkowski, S., and R. Shakir, "Segment Routing 498 Architecture", draft-ietf-spring-segment-routing-15 (work 499 in progress), January 2018. 501 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 502 Decraene, B., Litkowski, S., and R. Shakir, "Segment 503 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 504 July 2018, . 506 [TS.23.501-3GPP] 507 3rd Generation Partnership Project (3GPP), "System 508 Architecture for 5G System; Stage 2, 3GPP TS 23.501 509 v2.0.1", December 2017. 511 Authors' Addresses 513 Uma Chunduri (editor) 514 Futurewei 515 2330 Central Expressway 516 Santa Clara, CA 95050 517 USA 519 Email: umac.ietf@gmail.com 521 Luis M. Contreras 522 Telefonica 523 Sur-3 building, 3rd floor 524 Madrid 28050 525 Spain 527 Email: luismiguel.contrerasmurillo@telefonica.com 529 Sridhar Bhaskaran 530 Altiostar 532 Email: sridharb@altiostar.com 534 Jeff Tantsura 535 Apstra, Inc. 537 Email: jefftant.ietf@gmail.com 538 Praveen Muley 539 Nokia 540 440 North Bernardo Ave 541 Mountain View, CA 94043 542 USA 544 Email: praveen.muley@nokia.com