idnits 2.17.00 (12 Aug 2021) /tmp/idnits56850/draft-mhkk-dmm-srv6mup-architecture-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8986], [RFC7333]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (19 March 2022) is 56 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) == Unused Reference: 'RFC8402' is defined on line 724, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-18 ** Downref: Normative reference to an Informational RFC: RFC 7333 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Matsushima 3 Internet-Draft K. Horiba 4 Intended status: Standards Track A. Khan 5 Expires: 20 September 2022 Y. Kawakami 6 SoftBank 7 T. Murakami 8 K. Patel 9 Arrcus, Inc 10 M. Kohno 11 T. Kamata 12 P. Camarillo 13 Cisco Systems, Inc. 14 D. Voyer 15 Bell Canada 16 S. Zadok 17 I. Meilik 18 Broadcom 19 A. Agrawal 20 K. Perumal 21 Intel 22 J. Horn 23 Cisco Systems, Inc. 24 19 March 2022 26 Segment Routing IPv6 Mobile User Plane Architecture for Distributed 27 Mobility Management 28 draft-mhkk-dmm-srv6mup-architecture-03 30 Abstract 32 This document defines the Segment Routing IPv6 Mobile User Plane 33 (SRv6 MUP) architecture for Distributed Mobility Management. The 34 requirements for Distributed Mobility Management described in 35 [RFC7333] can be satisfied by routing fashion. 37 Mobile services are deployed over several parts of IP networks. A 38 Segment Routing over IPv6 (SRv6) network can accommodate all, or part 39 of those networks thanks to the large address space of IPv6 and the 40 network programming capability described in [RFC8986]. 42 Segment Routing IPv6 Mobile User Plane Architecture can incorporate 43 existing session based mobile networks. By leveraging SRv6 network 44 programmability, mobile user plane can be integrated into the SRv6 45 data plane. In that routing paradigm, session information between 46 the entities of the mobile user plane is turned to routing 47 information. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on 20 September 2022. 66 Copyright Notice 68 Copyright (c) 2022 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 73 license-info) in effect on the date of publication of this document. 74 Please review these documents carefully, as they describe your rights 75 and restrictions with respect to this document. Code Components 76 extracted from this document must include Revised BSD License text as 77 described in Section 4.e of the Trust Legal Provisions and are 78 provided without warranty as described in the Revised BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 86 4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6 87 5. Distribution of Mobile User Plane Segment Information . . . . 7 88 5.1. Direct Segment Discovery Route . . . . . . . . . . . . . 7 89 5.2. Interwork Segment Discovery Route . . . . . . . . . . . . 8 90 6. Distribution of Session Transformed Route . . . . . . . . . . 8 91 6.1. Type 1 Session Transformed Route . . . . . . . . . . . . 9 92 6.2. Type 2 Session Transformed Route . . . . . . . . . . . . 9 93 6.3. MUP Controller . . . . . . . . . . . . . . . . . . . . . 9 94 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 10 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 10.2. Informative References . . . . . . . . . . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 Mobile services require IP connectivity for communication between the 105 entities of mobile service architecture [RFC5213][TS.23501]. To 106 provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a 107 candidate solution. 109 In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be 110 provided over SR networks, as well as LMA and Internet. In 3GPP 5G 111 [TS.23501], IP connectivity for N3 interface between gNodeB(es) and 112 UPFs can also be provided by SR, as well as for N6 interface between 113 UPFs and DNs (Data Network). 115 These IP connectivities may be covered by multiple SR networks, or 116 just one SR network, depending on the size of the deployment. In the 117 latter case, it is expected that the address space of the SR network 118 should be large enough to cover a vast number of nodes, such as 119 millions of base stations. For this reason, use of IPv6 for the SR 120 dataplane looks sufficiently suitable. 122 SRv6 is an instantiation of SR over IPv6 dataplane in which a single 123 network can accommodate all entities of mobile services thanks to the 124 huge available address space and network programming capability 125 described in [RFC8986]. 127 Meanwhile, SRv6 network programmability enhances SRv6 dataplane to be 128 integrated with mobile user plane [I-D.ietf-dmm-srv6-mobile-uplane]. 129 It will make an entire SRv6 network support the user plane in a very 130 efficient distributed routing fashion. 132 On the other hand, the requirements for Distributed Mobility 133 Management (DMM) described in [RFC7333] can be satisfied by session 134 management based solutions. [RFC8885] defines protocol extension to 135 PMIPv6 for the DMM requirements. 3GPP 5G defines an architecture in 136 which multiple session anchors can be added to one mobility session 137 by the session management. 139 As a reminder, the user plane related requirements in [RFC7333] are 140 reproduced here: 142 REQ1: Distributed mobility management 143 IP mobility, network access solutions, and forwarding 144 solutions provided by DMM MUST enable traffic to avoid 145 traversing a single mobility anchor far from the optimal 146 route. It is noted that the requirement on distribution 147 applies to the data plane only. 149 REQ3: IPv6 deployment 150 DMM solutions SHOULD target IPv6 as the primary deployment 151 environment and SHOULD NOT be tailored specifically to 152 support IPv4, particularly in situations where private IPv4 153 addresses and/or NATs are used. 155 REQ4: Existing mobility protocols 156 A DMM solution MUST first consider reusing and extending IETF 157 standard protocols before specifying new protocols. 159 REQ5: Coexistence with deployed networks/hosts and operability 160 across different networks 161 A DMM solution may require loose, tight, or no integration 162 into existing mobility protocols and host IP stacks. 163 Regardless of the integration level, DMM implementations MUST 164 be able to coexist with existing network deployments, end 165 hosts, and routers that may or may not implement existing 166 mobility protocols. Furthermore, a DMM solution SHOULD work 167 across different networks, possibly operated as separate 168 administrative domains, when the needed mobility management 169 signaling, forwarding, and network access are allowed by the 170 trust relationship between them. 172 This document defines the Segment Routing IPv6 Mobile User Plane 173 (SRv6 MUP) architecture for Distributed Mobility Management. SRv6 174 MUP is not a mobility management system itself, but an architecture 175 to integrate mobile user plane into the SRv6 data plane. 177 In this routing paradigm, session information from a mobility 178 management system will be transformed to routing information. It 179 means that mobile user plane specific nodes for the anchor or 180 intermediate points are no longer required. The user plane anchor 181 and intermediate functions can be supported by SR throughout an SR 182 domain (REQ1), not to mention that SRv6 MUP will naturally be 183 deployed over IPv6 networks (REQ3). 185 SRv6 MUP architecture is independent from the mobility management 186 system. For the requirements (REQ4, 5), SRv6 MUP architecture is 187 designed to be pluggable user plane part of existing mobile service 188 architectures. Those existing architectures are for example defined 189 in [RFC5213], [TS.23501], or if any. 191 The level of SRv6 MUP integration for mobile networks running based 192 on the existing architecture will be varied and depending on the 193 level of SRv6 awareness of the control and user plane entities. 195 Specifying how to modify the existing architecture to integrate SRv6 196 MUP is out of scope of this document. What this document provides 197 for the existing architecture is an interface for SRv6 MUP which the 198 existing or future architectures can easily integrate. 200 1.1. Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC 2119 [RFC2119]. 206 2. Terminology 208 MUP: Mobile User Plane 210 MUP Segment: Representation of mobile user plane segment 212 PE: Provider Edge node in an SR network 214 MUP Controller: Controller node for an SR network 216 UE: User Equipment, as per [TS.23501] 218 MN: Mobile Node, as per [RFC5213] 220 3. Architecture Overview 222 SRv6 MUP architecture defined in this document introduces new segment 223 types of MUP segment called "Direct segment", and "Interwork 224 Segment". An SR node of PE accommodates an Interwork Segment and/or 225 a Direct Segment. Figure 1 depicts the overview. 227 * Mobility * 228 * Management * 229 * System * 230 *........* 231 | 232 Session Information 233 | 234 ______________v______________ 235 _______ / |MUP-C| \ _______ 236 / \ / +-----+ \ / \ 237 /Interwork\__ | | __/ Direct \ 238 \ Segment / \ |----+ +----| / \ Segment / 239 \_______/ \| PE | SRv6 | PE |/ \_______/ 240 _______ /|----+ Network +----|\ _______ 241 / \ / | | \ / \ 242 / Direct \_/ \ / \_/Interwork\ 243 \ Segment / \____________________________/ \ Segment / 244 \_______/ \_______/ 246 Figure 1: Overview of SRv6 MUP Architecture 248 This document also defines new routing information called "Segment 249 Discovery route" and "Session Transformed route". To carry these new 250 routing information, this architecture requires extending the 251 existing routing protocols. Any routing protocol can be used to 252 carry this information but this document recommends using BGP. Thus, 253 this document describes extensions on BGP as an example. 255 4. Mobile User Plane Segment 257 This document defines two new types of Mobile User Plane (MUP) 258 segment. A MUP segment represents a network segment consisting of a 259 mobile service. The MUP segment can be created by a PE which 260 provides connectivity for the mobile user plane. 262 Direct Segment is a type of MUP segment that provides connectivity 263 between MUP segments through the SRv6 network. Interwork Segment is 264 another type of MUP segment. It provides connectivity between a user 265 plane protocol of existing or future mobile service architecture and 266 other MUP segments through the SRv6 networks. 268 An SRv6 SID (Segment Identifier) can represents a MUP segment. The 269 SID can be any behavior defined in [RFC8986], 270 [I-D.ietf-dmm-srv6-mobile-uplane], or any other extensions for 271 further use cases. The behavior of the MUP segment will be chosen by 272 the role of the representing MUP segment. 274 For example, in case of a PE interfaces to 5G user plane on the 275 access side defined as "N3" in [TS.23501], the PE accommodates the N3 276 network as Interwork Segment in a routing instance and then the 277 behavior of created segment SID by the PE will be "End.M.GTP4.E", or 278 "End.M.GTP6.E". In this case, the PE may associate the SID to the 279 routing instance for the N3 access network (N3RAN). 281 Another example here is that a PE interfaces to 5G DN on the core 282 side defined as "N6" in [TS.23501], the PE accommodates the N6 283 network in a routing instance as Direct Segment and then the behavior 284 of the created segment SID by the PE will be "End.DT4", "End.DT6", or 285 "End.DT2". In this case, the PE may associate the SID to the routing 286 instance for the N6 data network (N6DN). 288 5. Distribution of Mobile User Plane Segment Information 290 Distribution of MUP segment information can be done by advertising 291 routing information with the MUP segment for mobile service. A PE 292 distributes MUP segment information when a MUP segment is connected 293 to the PE. 295 A MUP Segment Discovery route is routing information that associates 296 the MUP segment with network reachability. This document defines the 297 basic discovery route types, Direct Segment Discovery route, and 298 Interwork Segment Discovery route. Other types of segment discovery 299 route may be mobile service architecture specific. Defining the 300 architecture specific network reachability is out of scope of this 301 document and it will be specified in another document. 303 5.1. Direct Segment Discovery Route 305 When a PE accommodates a network through an interface or a routing 306 instance as a Direct Segment, the PE advertises the corresponding 307 Direct Segment Discovery route for the interface or the routing 308 instance. The Direct Segment Discovery route includes an address of 309 the PE in the network reachability information with an extended 310 community indicating the corresponding Direct Segment, and SID of the 311 routing instance to the SR domain. 313 For example in 3GPP 5G specific case, an PE may connect to N6 314 interface on a DN side, an MUP Segment Discovery route for the DN 315 will be advertised with an address of the PE, corresponding SID and 316 Direct Segment extended community to the routing instance for the DN 317 from the PE. 319 When a PE receives a Direct Segment Discovery route from other PEs, 320 the PE keeps the received Direct Segment Discovery route in the RIB. 321 The PE uses the received Direct Segment Discovery route to resolve 322 Type 2 session transformed routes reachability, described in 323 Section 6.2. If the Direct Segment Discovery route resolves 324 reachability for the endpoints, and match the Direct Segment extended 325 community of the Type 2 session transformed routes, the PE updates 326 the FIB entry for the Type 2 session transformed route with the SID 327 of the matched Direct Segment Discovery route. 329 5.2. Interwork Segment Discovery Route 331 When a PE accommodates a network through an interface or a routing 332 instance for the user plane protocol of the mobile service 333 architecture as an Interwork Segment, the PE advertises the 334 corresponding Interwork Segment Discovery route with the prefixes of 335 the Interwork Segment and the corresponding SID of the prefixes to 336 the SR domain. 338 For example in 3GPP 5G specific case, an Interwork Segment Discovery 339 route for N3 network accommodating RAN will be incorporated in an 340 N3RAN segment discovery route associated with a RAN segment SID. 342 When a PE receives a Interwork Segment Discovery route, the PE keeps 343 the received Interwork Segment Discovery routes in the RIB. The PE 344 uses the received Interwork Segment Discovery routes to resolve the 345 reachability for remote endpoint of Type 1 session transformed 346 routes, described in Section 6.1. If the Interwork Segment Discovery 347 route resolves the reachability for Type 1 session transformed 348 routes, the PE updates the FIB entry for the prefix of Type 1 session 349 transformed route with the SID of the matched MUP segment discovery 350 route. 352 The received Interwork Segment Discovery routes MUST be used only to 353 resolve reachability for the remote endpoints of Type 1 session 354 transformed routes. The connectivity among the routing instances for 355 Interwork Segments may be advertised as VPN routes. This is to avoid 356 forwarding entries to the prefixes of Interwork Segment mingled in 357 the other type of routing instance. A PE may discard the received 358 Interwork segment discovery route if the Route Target extended 359 communities of the route does not meet the PE's import policy. 361 6. Distribution of Session Transformed Route 363 SRv6 MUP architecture defines two types of session transformed route. 365 6.1. Type 1 Session Transformed Route 367 First type route, called Type 1 Session Transformed route, encodes IP 368 prefix(es) for a UE or MN in a BGP MP-NLRI attribute with associated 369 session information of the tunnel endpoint identifier on the access 370 side. The MUP controller advertises the Type 1 Session Transformed 371 route with the Route Target extended communities for the UE or MN to 372 the SR domain. 374 A PE may receive the Type 1 Session Transformed routes from the MUP 375 Controller in the SR domain. The PE may keep the received Type 1 376 Session Transformed routes advertised from the MUP Controller. The 377 receiving PE will perform the importing of the received Type 1 378 Session Transformed routes in the configured routing instances based 379 on the Route Target extended communities. A PE may discard the 380 received Type 1 Session Transformed route if the PE fails to import 381 the route based on the Route Target extended communities. 383 6.2. Type 2 Session Transformed Route 385 Second type route, called Type 2 Session Transformed route, encodes 386 the tunnel endpoint identifier of the session on the core side in a 387 BGP MP-NLRI attribute with the nature of tunnel decapsulation. 388 Longest match algorithm for the prefix in this type of session 389 transformed route should be applicable to aggregate the routes for 390 scale. The MUP controller advertises the Type 2 Session Transformed 391 route with the Route Target and Direct Segment extended communities 392 for the endpoint to the SR domain. 394 A PE may receive the Type 2 Session Transformed routes from the MUP 395 Controller in the SR domain. The PE may keep the received Type 2 396 Session Transformed routes advertised from the MUP Controller. The 397 receiving PE will perform the importing of the received Type 2 398 Session Transformed routes in the configured routing instances based 399 on the Route Target extended communities. A PE may discard the 400 received Type 2 Session Transformed route if the PE fails to import 401 the route based on the Route Target extended communities. 403 6.3. MUP Controller 405 A MUP controller provides a northbound API. A consumer of the API 406 inputs session information for a UE or a MN from mobility management 407 system. The MUP controller transforms the received session 408 information to routing information and will advertise the session 409 transformed routes with the corresponding extended communities to the 410 SR domain. 412 The received session information is expected to include the UE or MN 413 IP prefix(es), tunnel endpoint identifiers for both ends, and any 414 other attributes for the mobile networks. For example in a 3GPP 5G 415 specific case, the tunnel endpoint identifier will be a pair of the 416 F-TEIDs on both the N3 access side (RAN) and core side (UPF). 418 7. Illustration 420 This section shows an illustration of SRv6 MUP deployment. The 421 example deployment cases here is 3GPP 5G. 423 Before enabling SRv6 MUP, how SRv6 networks can accommodate existing 424 mobile network service shown in Figure 2. The PEs of S1, S2, and S3 425 join an SR network. A routing instance is configured to each network 426 of the mobile service. N6DN in S1 and S2 are supposed to provide 427 connectivity to edge servers and the Internet respectively. 429 VRF (Virtual Routing Forwarding) is the routing instance to 430 accommodate MUP segments in this section. All example cases in this 431 section follow the typical routing policy control using the BGP 432 extended community described in [RFC4360] and [RFC4684] 434 __ N3 /-----------+-----+------------\ 435 / \RAN / |MUP-C| \ 436 / V/v\_ | +-----+ | N6 __ 437 \ / \ |----+ +----| DN / \ 438 \__/ \| S1 | | S2 |----/W/w \ 439 __ /|----+ +----| \ / 440 / \__/ | +----+ | \__/ 441 / E/e\N6 \ | S3 | / 442 \ /DN \------------+----+------------/ 443 \__/ N3UPF /\ N6UPF 444 X/x / \ Y/y 445 +-----+ 446 | UPF | 447 +-----+ 449 Figure 2 451 The following routing instances are configured: 453 * N3RAN in S1 455 - export route V/v with route-target (RT) community C1 457 - import routes which have route-target (RT) community C1 and C2 459 * N6DN in S1 460 - export route E/e with RT C4 462 - import routes which have RT C3 and C4 464 * N6DN in S2 466 - export route W/w with RT C4 468 - import routes which have RT C3 and C4 470 * N3UPF in S3 472 - export route X/x with RT C2 474 - import routes which have RT C1 476 * N6UPF in S3 478 - export route Y/y with RT C3 480 - import routes which have RT C4 482 Note: The above configurations are just to provide typical IP 483 connectivity for 3GPP 5G. When the above configurations have 484 been done, each endpoint in V/v and X/x can communicate through 485 S1 and S3, but they can not communicate with nodes in E/e, W/w 486 and Y/y. 488 Here, the PEs are configured to enable SRv6 MUP as following: 490 * S1 492 - advertises Interwork type discovery route: V/v with SID S1:: 494 - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E 496 * S1 498 - advertise Direct type discovery route: MUP Direct Segment 499 community D1 and SID S1:1:: 501 - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 503 * S2 505 - advertise Direct type route: MUP Direct Segment community D1 506 and SID S2:: 508 - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 510 S1 here adopts the local N6DN to prioritize closer segment for the 511 same Direct Segment. Another PE may adopt D1 from S2, if the PE has 512 no local N6DN for D1 and closer to S2 than S1. 514 U1 515 | 516 U/u v 517 \__ N3 /-----------+-----+------------\ 518 / \RAN / |MUP-C| \ 519 / V/v\_ | +-----+ | N6 __ 520 \ / \ |----+ +----| DN / \ 521 \__/ \| S1 | | S2 |----/W/w \ 522 __ /|----+ +----| \ / 523 / \__/ | +----+ | \__/ 524 / E/e\N6 \ | S3 | / 525 \ /DN \------------+----+------------/ 526 \__/ N3UPF /\ N6UPF 527 X/x / \ Y/y 528 +-----+ 529 | UPF | 530 +-----+ 532 Figure 3 534 Now, session information U1 is put to a MUP Controller, MUP-C, and 535 MUP-C is configured to transforms U1 to the routes as follows: 537 * MUP-C 539 - attach the RT C3 to the DN in U1 541 - transforms UE's prefix U/u, the F-TEID on access side (gNB) and 542 QFI in U1 to the Type 1 session transformed route for the 543 prefix U/u with the F-TEID, the QFI, and RT C3 545 - transforms F-TEID on core side (UPF) X in U1 to the Type 2 546 session transformed route for X with MUP segment-ID D1 and RT 547 C2 549 Then N3RAN and N6DN import route X and U/u respectively. S1 and S2 550 resolves U/u's remote endpoint with V/v and then install SID S1:: for 551 U/u in FIB. S1:: will not be appeared in the packet from E/e to U/u 552 over the wire. 554 As S1 adopts local N6DN for D1, N3RAN in S1 decapsulates GTP-U 555 packets from V/v to X and then lookup the inner packets from U/u in 556 N6DN after the decapsulation. 558 Note: When the above configurations have been done, SRv6 MUP is 559 applied only to the packets from/to U/u. Each endpoint in U/u, 560 W/w and E/e can communicate through S1 and S2. The rest of 561 traffic from/to other UEs go through the usual 3GPP 5G user 562 plane path using UPF via S3. 564 Another case shown in Figure 4 is that S4 joins the SR network and 565 accommodates edge servers in the N6DN in S4. 567 U1 568 | 569 U/u v __ 570 \__ N3 /-----------+-----+------------\ / \ 571 / \RAN / |MUP-C| \ __/W/w \ 572 / V/v\_ | +-----+ +----|_/N6\ / 573 \ / \ |----+ | S2 | DN \__/ 574 \__/ \| S1 | +----| __ 575 __ /|----+ +----|_ / \ 576 / \__/ | +----+ | S4 | \__/E/e \ 577 / \N6 \ | S3 | +----/ N6\ / 578 \ /DN \------------+----+------------/ DN \__/ 579 \__/ N3UPF /\ N6UPF 580 X/x / \ Y/y 581 +-----+ 582 | UPF | 583 +-----+ 585 Figure 4 587 The following routing instances are configured: 589 * N3RAN in S1 (same with the previous case) 591 - export route V/v with RT C1 593 - import routes which have RT C1 and C2 595 * N6DN in S1 597 - export no route 599 - import routes which have RT C4 601 * N6DN in S2 (same with the previous case) 602 - export route W/w with RT C4 604 - import routes which have RT C3 and C4 606 * N3UPF in S3 (same with the previous case) 608 - export route X/x with RT C2 610 - import routes which have RT C1 612 * N6UPF in S3 (same with the previous case) 614 - export route Y/y with RT C3 616 - import routes which have RT C4 618 * N6DN in S4 620 - export route E/e with RT C4 622 - import routes which have RT C3 and C4 624 Here, the PEs are configured to enable SRv6 MUP as following: 626 * S1 (same with the previous case) 628 - advertises Interwork type route: V/v with SID S1:: 630 - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E 632 * S1 634 - advertise Direct type route: MUP Direct Segment community D1 635 for the local N6DN 637 - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 639 * S2 (same with the previous case) 641 - advertise Direct type route: MUP Direct Segment community D1 642 and SID S2:: 644 - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 646 * S4 648 - advertise Direct type route: MUP Direct Segment community D2 649 and SID S4:: 651 - set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4 653 As same as the previous case, S1 adopts the local N6DN for D1 as long 654 as S1 prioritizes closer segment for the same MUP Direct Segment. 655 The Direct type route from S4 for D2 with SID S4:: will be kept in 656 S1. 658 * MUP-C (same with the previous case) 660 - attach the RT C3 to the DN in U1 662 - transforms UE's prefix U/u, the F-TEID on access side (gNB) and 663 QFI in U1 to the Type 1 session transformed route for the 664 prefix U/u with the F-TEID, the QFI, and RT C3 666 - transforms F-TEID on core side (UPF) X in U1 to the Type 2 667 session transformed route for X with MUP Direct Segment 668 community D1 and RT C2 670 Then N3RAN and N6DN import route X and U/u respectively. S2 and S4 671 resolve U/u's remote endpoint with V/v and then install SID S1:: for 672 U/u in FIB. 674 As same as the previous case, S1 adopts local N6DN for D1, N3RAN in 675 S1 decapsulates GTP-U packets from V/v to X and then lookup the inner 676 packets from U/u in N6DN after the decapsulation. 678 For D2 on the other hand, no corresponding N6DN existed in S1. 679 However E/e with RT C4 from S4 is imported into N6DN in S1 as a vpn 680 route, E/e is reachable from U/u via N6DN for D1 in S1. 682 If a session U1' includes DN corresponding to D2, MUP-C advertises 683 Type 2 session transformed route X' with MUP Direct Segment community 684 D2, and then N3RAN in S1 instantiates H.M.GTP4.D or End.M.GTP6.D for 685 X with S4:: as the last SID in the received Direct type route from 686 S4. 688 Note: When the above configurations have been done, SRv6 MUP is 689 applied only to the packets from/to U/u. Each endpoint in U/u, 690 W/w and E/e can communicate through S1, S2 and S4. The rest of 691 traffic from/to other UEs go through the usual 3GPP 5G user 692 plane path using UPF via S3. 694 8. IANA Considerations 696 This memo includes no request to IANA. 698 9. Security Considerations 700 TBD. 702 10. References 704 10.1. Normative References 706 [I-D.ietf-dmm-srv6-mobile-uplane] 707 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 708 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 709 Mobile User Plane", Work in Progress, Internet-Draft, 710 draft-ietf-dmm-srv6-mobile-uplane-18, 18 February 2022, 711 . 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, 716 DOI 10.17487/RFC2119, March 1997, 717 . 719 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 720 Korhonen, "Requirements for Distributed Mobility 721 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 722 . 724 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 725 Decraene, B., Litkowski, S., and R. Shakir, "Segment 726 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 727 July 2018, . 729 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 730 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 731 (SRv6) Network Programming", RFC 8986, 732 DOI 10.17487/RFC8986, February 2021, 733 . 735 10.2. Informative References 737 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 738 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 739 February 2006, . 741 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 742 R., Patel, K., and J. Guichard, "Constrained Route 743 Distribution for Border Gateway Protocol/MultiProtocol 744 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 745 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 746 November 2006, . 748 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 749 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 750 RFC 5213, DOI 10.17487/RFC5213, August 2008, 751 . 753 [RFC8885] Bernardos, CJ., de la Oliva, A., Giust, F., Zúñiga, JC., 754 and A. Mourad, "Proxy Mobile IPv6 Extensions for 755 Distributed Mobility Management", RFC 8885, 756 DOI 10.17487/RFC8885, October 2020, 757 . 759 [TS.23501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP 760 TS 23.501 17.2.0, 24 September 2021, 761 . 763 Authors' Addresses 765 Satoru Matsushima 766 SoftBank 767 Japan 768 Email: satoru.matsushima@g.softbank.co.jp 770 Katsuhiro Horiba 771 SoftBank 772 Japan 773 Email: katsuhiro.horiba@g.softbank.co.jp 775 Ashiq Khan 776 SoftBank 777 Japan 778 Email: ashiq.khan@g.softbank.co.jp 780 Yuya Kawakami 781 SoftBank 782 Japan 783 Email: yuya.kawakami01@g.softbank.co.jp 784 Tetsuya Murakami 785 Arrcus, Inc. 786 United States of America 787 Email: tetsuya@arrcus.com 789 Keyur Patel 790 Arrcus, Inc. 791 United States of America 792 Email: keyur@arrcus.com 794 Miya Kohno 795 Cisco Systems, Inc. 796 Japan 797 Email: mkohno@cisco.com 799 Teppei Kamata 800 Cisco Systems, Inc. 801 Japan 802 Email: tkamata@cisco.com 804 Pablo Camarillo Garvia 805 Cisco Systems, Inc. 806 Spain 807 Email: pcamaril@cisco.com 809 Daniel Voyer 810 Bell Canada 811 Canada 812 Email: daniel.voyer@bell.ca 814 Shay Zadok 815 Broadcom 816 Israel 817 Email: shay.zadok@broadcom.com 819 Israel Meilik 820 Broadcom 821 Israel 822 Email: israel.meilik@broadcom.com 823 Ashutosh Agrawal 824 Intel 825 United States of America 826 Email: ashutosh.agrawal@intel.com 828 Kumaresh Perumal 829 Intel 830 United States of America 831 Email: kumaresh.perumal@intel.com 833 Jakub Horn 834 Cisco Systems, Inc. 835 Czech Republic 836 Email: jakuhorn@cisco.com