idnits 2.17.1 draft-homma-dmm-5gs-id-loc-coexistence-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2019) is 1829 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: 'A' is mentioned on line 990, but not defined == Missing Reference: 'B' is mentioned on line 853, but not defined == Missing Reference: 'C' is mentioned on line 919, but not defined == Missing Reference: 'D' is mentioned on line 992, but not defined == Unused Reference: 'I-D.farinacci-lisp-mobile-network' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-rfc6830bis' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC6832' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC7215' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC8061' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC8111' is defined on line 624, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-03 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-predictive-rlocs-03 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-03 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dmm S. Homma 3 Internet-Draft K. Kawakami 4 Intended status: Standards Track NTT 5 Expires: October 25, 2019 A. Akhavain 6 Huawei Canada Research Centre 7 A. Rodriguez-Natal 8 R. Shekhar 9 Cisco Systems Inc. 10 April 23, 2019 12 Co-existence of 3GPP 5GS and Identifier-Locator Separation Architecture 13 draft-homma-dmm-5gs-id-loc-coexistence-03 15 Abstract 17 This document describes an approach to introduce Identifier Locator 18 Separation architecture into 3GPP 5GS with low-impact on its 19 specifications, and shows the features and considerations of this 20 approach. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 25, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Terms of ID-LOC Protocols . . . . . . . . . . . . . . . . 4 59 2.2. Terms of 5GS . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Mechanism on Data Plane . . . . . . . . . . . . . . . . . . . 5 61 4. Mechanisms on Control Plane . . . . . . . . . . . . . . . . . 10 62 4.1. Model 1: Independent Control Planes . . . . . . . . . . . 11 63 4.2. Model 2: Interworking Control Planes . . . . . . . . . . 11 64 4.3. Model 3: Integrated Control Planes . . . . . . . . . . . 12 65 5. Features Analysis . . . . . . . . . . . . . . . . . . . . . . 12 66 5.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. Informative References . . . . . . . . . . . . . . . . . . . 13 72 Appendix A. Case Studies on Use of LISP . . . . . . . . . . . . 15 73 A.1. UE-to-UE Communication . . . . . . . . . . . . . . . . . 16 74 A.1.1. Case A-1: UEs allocated different dUPF . . . . . . . 16 75 A.1.2. Case A-2: UEs allocated the same xTR . . . . . . . . 18 76 A.1.3. Consideration of Case that UE Moves to under Another 77 xTR . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 A.2. UE-to-dDN Communication . . . . . . . . . . . . . . . . . 19 79 A.2.1. Case A-3: UE communicates with neighbor dDN . . . . . 19 80 A.2.2. Case A-4: UE communicates with non-neighbor dDN . . . 21 81 A.3. UE-to-cDN/Internet Communication . . . . . . . . . . . . 22 82 A.3.1. Case A-5: UE communicates with cDN . . . . . . . . . 23 83 Appendix B. Case Studies on Use of ILA . . . . . . . . . . . . . 24 84 B.1. UE-to-UE Communications . . . . . . . . . . . . . . . . . 25 85 B.1.1. Case B-1: UEs allocated different dUPF . . . . . . . 25 86 B.1.2. Case B-2: UEs allocated the same ILA node . . . . . . 26 87 B.2. UE-to-dDN Communication . . . . . . . . . . . . . . . . . 28 88 B.2.1. Case B-3: UE communicates with neighbor dDN . . . . . 28 89 B.2.2. Case B-4: UE communicates with non-neighbor dDN . . . 30 90 B.3. UE-to-cDN/Internet Communication . . . . . . . . . . . . 32 91 B.3.1. Case B-5: Internet Communication . . . . . . . . . . 33 92 B.3.2. Case B-6: Internet Communication . . . . . . . . . . 34 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 95 1. Introduction 97 Identifier-Locator Separation (ID-LOC) architectures aim to simplify 98 management of network, devices, and sessions by employing two 99 namespaces: Identifier for device's identity, and Locator for its 100 location in the network. 102 An ID-LOC architecture can be implemented by a dedicated protocol 103 such as LISP [I-D.ietf-lisp-rfc6833bis], ILA 104 [I-D.herbert-intarea-ila], ILNP [RFC6740], etc. The control plane of 105 such ID-LOC protocols can be combined with one of different 106 encapsulation techniques such as GTP-U [TS.29281], SRv6 107 [I-D.filsfils-spring-srv6-network-programming], MPLS [RFC3031], VXLAN 108 [RFC7348], etc. at data plane to provide a customized solution. 109 Furthermore, regarding control plane of ID-LOC, it can optionally 110 even take advantage of enhanced PUB/SUB capable distributed databases 111 to store ID-LOC mappings. 113 ID-LOC protocols are also expected to be used for optimizing user- 114 plane of mobile network 115 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Different 116 alternatives to introduce ID-LOC architecture into 3GPP 5GS(5th 117 Generation System), are under consideration in related IETF WG such 118 as DMM WG. 120 Introducing ID-LOC architecture into mobile network can involve 121 modifications to 5GS architecture and specifications that might span 122 over several 5GS releases. 124 Therefore, an approach that enables the introduction of ID-LOC 125 architecture into 5GS without change of its specifications and 126 supports migration path toward a native ID-LOC network can be useful 127 to operators. Here, ID-LOC native network refers to a network that 128 employs the ID-LOC architecture as only mechanism for packet 129 forwarding. 131 The document aims to describe one such approach and clarify different 132 features, and benefits. 134 2. Definition of Terms 136 This section describes general terms of ID-LOC architecture. This 137 document also refers definitions of 3GPP 5GS [TS.23.501-3GPP], and 138 some of such terms which are used in this document are listed in this 139 section. 141 The LISP terms are described in [I-D.ietf-lisp-rfc6833bis]. 143 The ILA terms are described in [I-D.herbert-intarea-ila]. 145 The SRv6 terms are described in 146 [I-D.ietf-6man-segment-routing-header]. 148 2.1. Terms of ID-LOC Protocols 150 Device Identifier (ID): An ID is an identifier of host or end point 151 such as UE or network function including VM instance, container, 152 etc. In ID-LOC architectures, an IP or MAC address is generally 153 assigned to an end device as identifier. In this case, IDs are 154 used as values for the source and destination IP/MAC address 155 fields of packets sent from end points. Alternatively, other 156 attributes of the end point, such as its Fully Qualified Domain 157 Name (FQDN), can also be used as IDs. 159 Locator (LOC): A LOC is generally an address (e.g. IPv4, IPv6, MAC, 160 etc) of the ID-LOC node. In the case of SRv6 it can be the ID-LOC 161 node's local SID representing the segment for which the ID-LOC 162 node is the segment termination node. 164 ID-LOC node; An ID-LOC node is a node that has at least one unique 165 locator within a network domain, and has functionalities to obtain 166 destination locator and to forward packets to the ID-LOC node 167 which has the destination locator. This node has an ID-LOC 168 mapping cache and obtains destination locator by looking up 169 destination ID (destination address of a data packet) from the 170 mapping cache. If ID of the received packet is not present in its 171 own mapping cache, an ID-LOC node requests mapping information of 172 the ID and the assigned locator to ID-to-LOC mapping system. Also 173 an ID-LOC node forwards packet to a peered LOC node by 174 encapsulation or conversion of the IP header field such as IP 175 address field, and decapsulates or reconverts packets received 176 from another ID-LOC node. Different implementations of ID-LOC 177 architecture use different forwarding mechanisms. LISP data- 178 plane, for example, uses IPv4/v6 header and LISP header for 179 encapsulation, whereas ILA tightly couples itself with IPv6, and 180 SRv6 uses IPv6 and SIDs (Segment Identifiers). 182 ID-to-LOC Mapping System: An ID-to-LOC mapping system is a database 183 which contains all known ID-to-LOC mappings within an ID-LOC 184 domain. The mapping information is updated when an end point 185 moves to under another ID-LOC node. This database can be 186 logically centralized, distributed across the ID-LOC nodes, or a 187 combination of both. If the database is logically centralized, 188 each ID-LOC node has an interface to the system to send a request 189 and receive mapping information. 191 ID-to-LOC Mapping Cache: An ID-LOC mapping cache is a table in an 192 ID-LOC node that stores ID-to-LOC mapping information and it is 193 used for obtaining destination LOC from ID of received packet. 194 ID-to-LOC mapping cache typically contains a small piece of 195 database. The cache is updated when the ID-LOC node receives a 196 new ID-to-LOC mapping information from ID-to-LOC mapping system. 198 2.2. Terms of 5GS 200 User Plane Function (UPF): An UPF handles the user plane paths. An 201 UPF is connected to SMF with N4 interface. More detailed 202 information is described in [TS.23.501-3GPP]. This document 203 defines two types of UPF, Central UPF (cUPF) and Distributed UPF 204 (dUPF). Their features are described in Section 3 206 Uplink Classifier (ULCL): An ULCL is an UPF functionality that aims 207 at diverting Uplink traffic, based on filter rules provided by 208 SMF, towards Data Network (DN). 210 Data Network (DN): A DN is a network where network functions and 211 entities, including operator or 3rd party services, are deployed. 212 This document defines two types of DN, Central DN (cDN) and 213 Distributed DN (dDN). Their features are described in Section 3. 215 Radio Access Network (RAN): A RAN is an access network where radio 216 bearer sent by UEs traverse. A RAN encapsulate users' packets 217 with GTP-U. 219 Session Management Function (SMF): An SMF is a function which 220 provides control plane functionalities for handling user traffic. 222 Application Function (AF): An AF is a control plane functionality 223 and connected to SMF with Naf interfaces. 225 3. Mechanism on Data Plane 227 This approach achieves traffic forwarding with optimized path and 228 session continuity by using ID-LOC and ULCL for particular 229 communication including UE-to-UE or MEC (Mobile Edge Computing) 230 communication. ULCL is one of fundamental functions of 5GC Rel.15 231 and it provides functionalities of packet filtering and divert for 232 uplink packets sent by UEs. 234 The overview of the assumed 5GC architecture of data plane where the 235 proposal approach works is shown in Figure 1. The details of 236 numbered interfaces in the figure are described in [TS.23.501-3GPP]. 238 .--. 239 ( )-. 240 .' cDN/ ' 241 ( Internet ) 242 ( -' 243 '-( ) 244 '---' 245 |N6 246 +-----+-----+ 247 | cUPF | === 248 +-----+-----+ ^ 249 |N9 | 250 ,-----------------------+-----------------------. | 251 / \ | 252 | Transport Network | | 253 \ / | 254 `----+---------------------------+--------------' 255 |N9 |N9 Connected 256 +-----+-----+ ,-----. +-----+-----+ ,-----. with 257 | dUPF#1 |N6 / \ | dUPF#2 |N6 / \ GTP-U 258 | [UL]+---| dDN#A | | [UL]+---| dDN#B |.. 259 | [CL]| \ / | [CL]| \ / | 260 +-----+-----+ `-----' +-----+-----+ `-----' | 261 |N3 |N3 | 262 | 263 (( o )) (( o )) | 264 A A v 265 /-\ RAN /-\ RAN === 266 /-|-\ /-|-\ 268 | | 270 [ UE ] .. [ UE ] .. 272 dUPF: Distributed UPF 273 cUPF: Central UPF 274 dDN: Distributed DN 275 cDN: Central DN 277 Figure 1: Assumed 5GC Network Architecture 279 This network has following features; 281 o A Central UPF (cUPF) is deployed at a connecting point to Central 282 DN (cDN). A cUPF becomes anchor point for UEs and it assigns IP 283 addresses (IDs) for each UE. The traffic transmitted from UEs are 284 basically sent to the cUPF. 286 o Distributed UPFs (dUPFs) and Distributed DNs (dDNs) are deployed 287 and geographically distributed at user edge side. A unique 288 address space (it's not necessarily globally unique) is assigned 289 to dDN. When a dUPF forwards a UE's uplink packet, and if the 290 subnet of the destination address is the same as the one assigned 291 to dDN at proximity, then dUPF, with the help of ULCL, may divert 292 the packet to that dDN. Here, the ULCL identifies each 293 encapsulated uplink packet to be diverted, by checking if the 294 destination of the inner packet is one of IP addresses assigned 295 the dDN. A dUPF removes GTP-U header from the packets, and sends 296 them to dDN via N6. When dUPF receives packets from dDN, dUPF 297 encapsulates them with GTP-U header, and merges them into downlink 298 packets from cUPF. An overview of behaviors of dUPF and ULCL is 299 shown in Figure 2. 301 o Network topology between RAN and dUPF/cUPF adopts tree structure 302 and the section between RAN and dUPF and the section between dUPF 303 and cUPF are connected with GTP-U. 305 GTP-U packets GTP-U packets 306 from cUPF to cUPF 308 | ^ 309 | N9 | 310 | | 311 +----|------------|-----+ 312 | | dUPF | | ,---------. 313 | v | | IP packet / \ 314 | o<-----------------------------| | 315 | | | | | | 316 | | | | N6 | dDN | 317 | | +------+ | | | 318 | | | ULCL |------------->| | 319 | | +------+ | IP packet | | 320 | | ^ | \ / 321 +----|------------|-----+ `---------' 322 | | 323 | | 324 | N3 | 325 v | 327 GTP-U packets GTP-U packets 328 to UE from UE 330 Figure 2: Behaviors of dUPF and ULCL 332 In the proposed approach, IDs are assumed to be IP addresses and an 333 ID-LOC node is installed between dUPF and dDN. ID-LOC nodes are 334 connected with a IP mechanism such as IP tunnels or translation of 335 destination IP field. As examples of such data plane protocols for 336 providing connectivity between ID-LOC nodes, IPv4/v6 header with LISP 337 header or SRv6 ([I-D.ietf-6man-segment-routing-header]) can be used. 338 In addition, each ID-LOC node has connectivity with one or more 339 Mapping Systems. The overview is shown in Figure 3. 341 .--. 342 ( )-. 343 .' cDN/ ' 344 ( Internet ) 345 ( -' 346 '-( ) 347 '---' 348 |N6 ,---------. 349 +-----+-----+ | Mapping | 350 | cUPF | | System | 351 +-----+-----+ `---------' 352 |N9 . 353 ,-----------------------+----------------.---------. 354 / Transport Network . . . . . . . . . . . . . . . \ 355 | . . | 356 \ #===========================#=== / 357 `----+------------#--.-----------+------------#--.-' 358 |N9 # . |N9 # . 359 +-----+-----+ +-------+ +-----+-----+ +-------+ 360 | dUPF#1 |N6 | ID-LOC| | dUPF#2 |N6 | ID-LOC| 361 | [UL]+---+ Node#1| | [UL]+---| Node#2|.. 362 | [CL]| | | | [CL]| | | 363 +-----+-----+ +---+---+ +-----+-----+ +---+---+ 364 |N3 | |N3 | 365 ,-----. ,-----. 366 (( o )) / \ (( o )) / \ 367 A | dDN#A | A | dDN#B | 368 /-\ RAN \ / /-\ RAN \ / 369 /-|-\ `-----' /-|-\ `-----' 371 | | 373 [ UE ] .. [ UE ] .. 375 ===== : Connection between LOC nodes 376 . . . : IF to Mapping System 378 Figure 3: Proposal Network Architecture 380 Each dUPF has a filter table of ULCL. Each filter table is 381 configured to match the addresses of UEs within the network domain 382 (i.e., addresses for UEs assigned by the cUPF). Filter tables can 383 also be configured to match the address corresponding to the address 384 space (or part of) corresponding with the dDNs in the network domain. 385 UPFs monitor each uplink GTP-U packet with its ULCL and divert it to 386 the connected ID-LOC node with decapsulation of GTP-U if the 387 destination address of the inner packet (payload) matches the 388 filtering table. When ID-LOC node receives a packet from the dUPF, 389 it obtains LOC which the destination of the packet (ID) belongs to by 390 looking up its own ID-to-LOC mapping table or querying it from the 391 Mapping System according ID-LOC mechanism. Then it sends the packet 392 to peered ID-LOC node indicated by the LOC. The peered ID-LOC node 393 converts the received packet to appropriate form and forwards them 394 the destination by following its own forwarding table. 396 From such processes, forwarding paths of user traffic diverted by 397 ULCL from 5GC to ID-LOC node are optimized. 399 A cUPF is connected with dUPFs via N9 interface and packets are 400 forwarded with GTP-U encapsulation between cUPF and dUPF. 402 Some case studies of ID-LOC protocols are described in Appendix A and 403 Appendix B. 405 4. Mechanisms on Control Plane 407 For ID-LOC mechanism in mobile networks, a control plane mechanism is 408 required to manage location information of UEs and NFs in each dDN. 409 There are mainly three models to realize control plane mechanism for 410 ID-LOC as follows: 412 Model 1: Independent Control Planes 414 Model 2: Interworking Control Planes 416 Model 3: Integrated Control Planes 418 Some of models may require to use 5GS interfaces or add some 419 functionalities to functions of 5GC. 5GS architecture and the 420 service-based interfaces are shown in Figure 4. The details of 421 functions and interfaces are described in [TS.23.501-3GPP]. 423 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 424 |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 425 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 426 Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf 427 ---+--------+--+-----+--+--------+--+-----+--------+- 428 Nausf| Namf| Nsmf| 429 +--+--+ +--+--+ +--+--+ 430 |AUSR | | AMF | | SMF | 431 +-----+ +--+--+ +-----+ 432 /| | 433 C-plane N1/ |N2 |N4 435 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 436 U-plane / | | 437 N1 / |N2 |N4 438 / | | 439 +-+-+ +--+--+ N3 +--+--+ N6 +----+ 440 |UE +--+(R)AN+-----+ UPF +-----+ DN | 441 +---+ +-----+ ++---++ +----+ 442 | | 443 +---+ 444 N9 446 Figure 4: 5GS Architecture and Service-based Interfaces 448 4.1. Model 1: Independent Control Planes 450 In this model, control plane of 5GC and ID-to-LOC mapping mechanism 451 are completely separated. Information of a UE and an ID-LOC node 452 which the UE is attached is sent to a mapping system and registered 453 in the mapping database only when the ID-LOC node receives a packet 454 from the UE and the UE is not registered yet. 456 This model does not cause any impacts on 5GC architecture. However, 457 in this model, a UE cannot be accessed from other UEs within the same 458 network domain until a packet from the UE is diverted to the ID-LOC 459 node by the UPF which the UE is located and the ID and LOC are 460 registered to the Mapping System. 462 4.2. Model 2: Interworking Control Planes 464 In this model, a mapping system interworks with an SMF which manages 465 sessions of each UE. A scheme to inform, that a UE moves and is 466 relocated to another UPF, from SMF to AF via Naf interface is defined 467 in 5GS ([TS.23.502-3GPP])*. A Mapping System is installed as an AF 468 and obtains mobility information of UEs with the above scheme. 470 * The stage 3 of discussion of 5GS has not been fixed yet and the 471 specification may be changed. 473 This model would not cause any impacts on 5GS architecture, and a 474 mapping system can always keep the current mobility information of 475 each UE. 477 4.3. Model 3: Integrated Control Planes 479 In this model, SMF functionalities are integrated into a mapping 480 system. In other words, the mapping system becomes a part of 5GS. 481 In 5GS architecture, an SMF has a role of session management of UEs, 482 and it updates its own mapping database depending on movement of a 483 UE. 485 This approach enables to always keep mapping databases the latest 486 status, however, it obviously requires extension or replacement of 487 SMF actually deployed in 5GS network. 489 5. Features Analysis 491 5.1. Benefits 493 o This approach provides a mechanism for introducing ID-LOC 494 architecture into 5GS with no or nominal impact, and achieves 495 optimized forwarding with session continuity in the assumed use 496 cases such as UE-to-UE or UE-to-dDN communications. 498 o Regarding communication to the cDN, this approach can keep 499 scalability because it does not change the current mechanism of 500 5GS. 502 5.2. Issues 504 o dUPF and ID-LOC node are separated, and thus an extra hop may 505 occur against the optimized forwarding. However, it can be 506 resolved by implementing dUPF and ID-LOC node within a same box or 507 application. 509 6. Security Considerations 511 TBD 513 7. IANA Considerations 515 This memo includes no request to IANA. 517 8. Acknowledgement 519 The authors would like to thank Ryosuke Kurebayashi, Koji Tsubouchi, 520 Toru Okugawa, and Dino Farinacci for their kind reviews and technical 521 feedback. 523 9. Informative References 525 [I-D.bogineni-dmm-optimized-mobile-user-plane] 526 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 527 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 528 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 529 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 530 optimized-mobile-user-plane-01 (work in progress), June 531 2018. 533 [I-D.farinacci-lisp-mobile-network] 534 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 535 for the Mobile Network", draft-farinacci-lisp-mobile- 536 network-05 (work in progress), March 2019. 538 [I-D.filsfils-spring-srv6-network-programming] 539 Filsfils, C., Camarillo, P., Leddy, J., 540 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 541 Network Programming", draft-filsfils-spring-srv6-network- 542 programming-07 (work in progress), February 2019. 544 [I-D.herbert-intarea-ila] 545 Herbert, T. and P. Lapukhov, "Identifier-locator 546 addressing for IPv6", draft-herbert-intarea-ila-01 (work 547 in progress), March 2018. 549 [I-D.ietf-6man-segment-routing-header] 550 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 551 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 552 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 553 progress), April 2019. 555 [I-D.ietf-lisp-eid-mobility] 556 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 557 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 558 Unified Control Plane", draft-ietf-lisp-eid-mobility-03 559 (work in progress), November 2018. 561 [I-D.ietf-lisp-predictive-rlocs] 562 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 563 RLOCs", draft-ietf-lisp-predictive-rlocs-03 (work in 564 progress), November 2018. 566 [I-D.ietf-lisp-pubsub] 567 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 568 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 569 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 570 Subscribe Functionality for LISP", draft-ietf-lisp- 571 pubsub-03 (work in progress), March 2019. 573 [I-D.ietf-lisp-rfc6830bis] 574 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 575 Cabellos-Aparicio, "The Locator/ID Separation Protocol 576 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 577 November 2018. 579 [I-D.ietf-lisp-rfc6833bis] 580 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 581 "Locator/ID Separation Protocol (LISP) Control-Plane", 582 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 583 2019. 585 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 586 Label Switching Architecture", RFC 3031, 587 DOI 10.17487/RFC3031, January 2001, 588 . 590 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 591 Protocol (ILNP) Architectural Description", RFC 6740, 592 DOI 10.17487/RFC6740, November 2012, 593 . 595 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 596 Locator/ID Separation Protocol (LISP) for Multicast 597 Environments", RFC 6831, DOI 10.17487/RFC6831, January 598 2013, . 600 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 601 "Interworking between Locator/ID Separation Protocol 602 (LISP) and Non-LISP Sites", RFC 6832, 603 DOI 10.17487/RFC6832, January 2013, 604 . 606 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 607 Pascual, J., and D. Lewis, "Locator/Identifier Separation 608 Protocol (LISP) Network Element Deployment 609 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 610 2014, . 612 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 613 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 614 eXtensible Local Area Network (VXLAN): A Framework for 615 Overlaying Virtualized Layer 2 Networks over Layer 3 616 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 617 . 619 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 620 (LISP) Data-Plane Confidentiality", RFC 8061, 621 DOI 10.17487/RFC8061, February 2017, 622 . 624 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 625 Smirnov, "Locator/ID Separation Protocol Delegated 626 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 627 May 2017, . 629 [TS.23.501-3GPP] 630 3rd Generation Partnership Project (3GPP), "3GPP TS 631 23.501", December 2017, 632 . 634 [TS.23.502-3GPP] 635 3rd Generation Partnership Project (3GPP), "3GPP TS 636 23.502", December 2017, 637 . 639 [TS.29281] 640 3GPP, "General Packet Radio System (GPRS) Tunnelling 641 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 642 December 2017. 644 Appendix A. Case Studies on Use of LISP 646 This Appendix describes detailed processes of the proposal approach 647 with LISP mechanism in the following types of communications. 649 1. UE-to-UE Communication 651 2. UE-to-dDN Communication 653 3. UE-to-cDN/Internet Communication 655 In the following description of case studies, ID and Locator are 656 called EID (End-point Identifier) and RLOC (Routing Locator) in LISP 657 terms. Mapping Server has the master of EID-to-RLOC mapping 658 database, and each xTR (Ingress/Egress Tunnel Router) has EID-to-RLOC 659 mapping cache. An xTR obtains the destination RLOC from its own 660 cache by looking up the destination EID of received packet. They 661 obtain mappings from the mapping system if an EID looked up is not 662 registered in the cache. Packets are passed between xTRs with some 663 tunnel protocols. 665 A.1. UE-to-UE Communication 667 In the current architecture, a cUPF becomes an anchor point for UEs, 668 and all packets between UEs even those which are located to the same 669 dUPF are transferred through the anchor point. This may cause 670 communication delay and inefficient resource usage. In the proposed 671 procedure, packets can be transferred without going through an anchor 672 point, and low latency and efficient resource usage can be achieved. 674 The UE-to-UE communications include communications between UEs 675 located to different dUPFs (Case 1), and communication between UEs 676 located to the same dUPF (Case 2). In this section, the detailed 677 procedures of the cases are described. 679 Moreover, in a mobile network, a UE may move during communications. 680 This section describes considerations about UE's handover in such 681 case. 683 A.1.1. Case A-1: UEs allocated different dUPF 684 +-------+ 685 |Mapping| 686 |System | 687 +-------+ 688 . 689 . 690 . 691 (3) . #==========================# 692 . # (4) # 693 . # V 694 +-------+ +-------+ +-------+ +-------+ 695 | dUPF#1| | xTR#1 | | dUPF#2| | xTR#2 | 696 | | | RLOC=X| |+------|<-----| RLOC=Y| 697 | [UL]| | | || [UL]| (5) | | 698 | [CL]|------>| | |v [CL]| | | 699 +-------+ (2) +-------+ +-------+ +-------+ 700 ^ | 701 | (1) |(6) 702 | v 704 [UE#1] [UE#2] 705 EID=a-1 EID=a-2 707 Figure 5: Procedure in Case A-1 709 (0) Within this network, addresses are assigned to UEs from a 710 address space [A]. These addresses are described as a-n 711 (n=1,2,..). EID=a-1 and a-2 are assigned to UE#1 and UE#2. 713 (1) UE#1 sends packets to UE#2 with setting EID=a-2 as the 714 destination IP address. 716 (2) dUPF#1 monitors inner packet of received GTP-U packet and divert 717 it to xTR#1 with decapsulation if the destination address is one 718 of address space [A]. 720 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 721 Mapping System (if needed). 723 (4) xTR#1 obtains the RLOC(=Y) of EID=a-2 from the EID-to-RLOC 724 mapping cache, and sends the packets to the xTR#2 with a tunnel 725 with RLOC=Y as the destination address. 727 (5) xTR#2 decapsulate the packets, and sends them to dUPF#2. 729 (6) dUPF#2 encapsulate packets with GTP-U header, and sends them to 730 UE#2. 732 A.1.2. Case A-2: UEs allocated the same xTR 734 +-------+ 735 |Mapping| 736 |System | 737 +-------+ 739 +-------+ +-------+ +-------+ +-------+ 740 | dUPF#1| (3) | xTR#1 | | dUPF#2| | xTR#2 | 741 |+------|<----- | RLOC=X| | | | RLOC=Y| 742 || [UL]| | | | [UL]| | | 743 |v [CL]|------>| | | [CL]| | | 744 +-------+ (2) +-------+ +-------+ +-------+ 745 | ^ 746 (4) | | (1) 747 v | 749 [UE#2] [UE#1] 750 EID=a-2 EID=a-1 752 Figure 6: Procedure in Case A-2 754 (0) Within this network, addresses are assigned to UEs from a 755 address space [A]. These addresses are described as a-n 756 (n=1,2,..). EID=a-1 and a-2 are assigned to UE#1 and UE#2. 758 (1) UE#1 sends packets to UE#2 with setting EID=a-2 as the 759 destination IP address. 761 (2) dUPF#1 monitors inner packets of received GTP-U traffic and 762 divert it to xTR#1 with decapsulation if the destination address 763 is one of address space [A]. 765 (3) Since xTR#1 serves UE#2, it locally routes the traffic for 766 EID=a-2. xTR#1 sends the received packets back to dUPF#1. 768 (4) dUPF#1 encapsulate packets with GTP-U, and sends them to UE#2. 770 A.1.3. Consideration of Case that UE Moves to under Another xTR 772 When a UE moves to a serving area of another dUPF during 773 communication with another UE, EID-to-RLOC mapping database of a 774 Mapping System and the tables of the xTR and the peered xTR must be 775 updated. Unless some of the mechanism described below are in place, 776 the xTRs can't send packets to the appropriate xTR during the 777 updating, and thus packet drop or stalling may occur. 779 For example, a mechanism that immediately advertise the update of 780 location of UEs to Mapping System and the appropriate xTRs depending 781 on movement of each UE might be required. Some documents (e.g., 782 [I-D.ietf-lisp-eid-mobility], [I-D.ietf-lisp-pubsub]) discuss such 783 mechanisms. Alternatively, a mechanism that replicates packets to 784 both the old and new location while the UE is in transit could also 785 be used. This approach is discussed in detail in 786 [I-D.ietf-lisp-predictive-rlocs]. 788 A.2. UE-to-dDN Communication 790 The UE-to-dDN communications basically correspond the communication 791 between a UE and neighbor dDN (Case3). On the other hand, if a UE 792 moved under another dUPF during usage of a stateful application, or 793 the application is not uniformly deployed in every dDN, the UE needs 794 to continue to communicate with the previous dDN (Case4). 796 In such cases, in the current architecture, all packets are needed to 797 go through the anchor point or dynamic GTP tunnel reconfiguration 798 between dUPF is required. The former solution causes additional 799 communication delay and inefficient resource usage. The latter 800 solution increase the cost of 5GS control plane to dynamically update 801 the GTP tunnel with multiple UPFs and their ULCL filter tables along 802 with the movement of the UE. The proposed approach achieves 803 appropriate packet transfer in such cases. 805 In this section, the detailed procedures of communications between a 806 UE and neighbor dDN and communications between a UE and non-neighbor 807 dDN 809 A.2.1. Case A-3: UE communicates with neighbor dDN 810 +-------+ 811 |Mapping| 812 |System | 813 +-------+ 814 . 815 . 816 . 817 (3) . 818 . 819 . 820 +-------+ +-------+ +-------+ +-------+ 821 | dUPF#1| (6) | xTR#1 | | dUPF#2| | xTR#2 | 822 |+------|<----- | RLOC=X| | | | RLOC=Y| 823 || [UL]| | | | [UL]| | | 824 |v [CL]|------>| | | [CL]| | | 825 +-------+ (2) +-------+ +-------+ +-------+ 826 | ^ | ^ 827 (7) | | (1) (4)| | (5) 828 v | v | 829 ,-------. 830 [UE#1] / dDN#B \ 831 EID=a1 | | ^ | 832 | v | | 833 | [APL#1] | 834 \ EID=b-1 / 835 `-------' 837 Figure 7: Procedure in Case A-3 839 (0) Within this network, UEs are assigned their addresses from an 840 address space [A]. These addresses are described as a-n 841 (n=1,2,...). Also, applications in dDN#B are assigned their 842 addresses from a address space [B]. These addresses are described 843 as b-n (n=1,2,..). EID=a-1 and b-1 assigned to UE#1 and APL#1 844 which is located in dDN#B. 846 [Uplink Processes] 848 (1) UE#1 sends packets to dDN#B with setting EID=b-1 as the 849 destination IP address. 851 (2) dUPF#1 monitors inner of received GTP-U packets and divert it to 852 xTR#1 with decapsulation if the destination IP address is one of 853 address space [B]. 855 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 856 Mapping System (if needed). Or xTR#1 may update its own cache by 857 a Map-Notify message when an APL is deployed or deleted in dDB#B. 859 (4) Since xTR#1 serves dDN#B, it locally routes the traffic for 860 EID=b-1. xTR#1 sends the packets to the dDN#B. 862 [Downlink Processes] 864 (5) APL#1 in dDN#B sends packets to UE#1 with setting EID=a-1 as the 865 destination IP address. 867 (6) Since xTR#1 serves UE#1, it locally routes the traffic for 868 EID=a-1. xTR#1 sends packets to dUPF#1. 870 (7) dUPF#2 encapsulates packets with GTP-U, and sends them to UE#1. 872 A.2.2. Case A-4: UE communicates with non-neighbor dDN 874 +-------+ 875 |Mapping| 876 |System | 877 +-------+ 878 . 879 . (7) 880 . #==============================# 881 (3) . # #==========================# # 882 . # # (4) # # 883 . V # V # 884 +-------+ +-------+ +-------+ +-------+ 885 | dUPF#1| (8) | xTR#1 | | dUPF#2| | xTR#2 | 886 |+------|<------| RLOC=X| | | (0) | RLOC=Y| 887 || [UL]| | | | [UL]|<---->| | 888 |v [CL]|------>| | | [CL]| | | 889 +-------+ (2) +-------+ +-------+ +-------+ 890 | ^ ^ | ^ 891 (9) | | (1) | (0) (5)| | (6) 892 v | | v | 893 (0) v ,-------. 894 [UE#1] <= = = = = = = = = = = =[UE#1] / dDN#C \ 895 EID=a-1 UE#1 moves to the serving area of | | ^ | 896 dUPF#1 from the serving area of UPF#2 | v | | 897 | [APL#2] | 898 \ EID=c-1 / 899 `-------' 901 Figure 8: Procedure in Case A-4 903 (0) Within this network, UEs are assigned their addresses from an 904 address space [A]. These addresses are described as a-n 905 (n=1,2,..). And applications in dDN#C are assigned their 906 addresses from an address space [C]. These addresses are 907 described as c-n (n=1,2,..). EID=a-1 and c-1 assigned to UE#1 and 908 APL#2 which is located in dDN#C. UE#1 has moved to the serving 909 area of dUPF#1 from the serving area of UPF#2 while communicating 910 to APL#2. 912 [Uplink Processes] 914 (1) UE#1 sends packets to APL#2 with setting EID=c-1 as the 915 destination IP address. 917 (2) dUPF#1 monitors each inner packet of received GTP-U traffic and 918 divert it to xTR#1 with decapsulation if the destination address 919 is one of address space [C]. 921 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 922 Mapping System (if needed). 924 (4) xTR#1 obtains RLOC(=Y) of EID=c-1 from the EID-to-RLOC mapping 925 cache, and sends the packet to the xTR#2 with a tunnel with RLOC=Y 926 as the destination address. 928 (5) xTR#2 decapsulates the packets received from xTR#1, and sends 929 them to dDN#C depending on its forwarding table. 931 [Downlink Processes] 933 (6) APL#2 sends packets to UE#1 with setting EID=a-1 as the 934 destination IP address. 936 (7) xTR#2 obtains RLOC(=X) of EID=a-1 from the EID-to-RLOC mapping 937 cache, and sends the packets to the xTR#1 with a tunnel with 938 RLOC=X as the destination address. 940 (8) xTR#1 decapsulates the packets received from xTR#2m and sends 941 them to the dUPF#1 depending on its forwarding table. 943 (9) dUPF#1 encapsulates the packets with GTP-U and sends packets to 944 UE#1. 946 A.3. UE-to-cDN/Internet Communication 948 UE-to-cDN/Internet communication is achieved by GTP-U mechanism 949 originally equipped in 3GPP 5GS architecture. In this section, we 950 describe processes of UE-to-cDN communication in the proposal 951 architecture as an example. 953 A.3.1. Case A-5: UE communicates with cDN 955 ,------------. 956 / cDN \ 957 | | 958 | EID=d-1 | 959 | [APL#3] | 960 | | ^ | 961 \ | | / 962 `------------' 963 (4) | | (3) 964 v | 965 +-----------+ 966 | cUPF | 967 +-----------+ 968 | ^ 969 (5) | | 970 +--------------------+ | 971 | +--------------------+ 972 | | (2) 973 V | 974 +-------+ +-------+ 975 | dUPF#1| | xTR#1 | 976 | | | RLOC=X| 977 | [UL]| | | 978 | [CL]| | | 979 +-------+ +-------+ 980 | ^ 981 (6) | | (1) 982 v | 984 [UE#1] 985 EID=a-1 987 Figure 9: Procedure in Case A-5 989 (0) Within this network, UEs are assigned their addresses from an 990 address space [A]. These addresses are described as a-n 991 (n=1,2,..). And applications in cDN are assigned their addresses 992 from an address space [D]. These addresses are described as d-n 993 (n=1,2,..). EID=a-1 and d-1 assigned to UE#1 and APL#3 which is 994 located in cDN. 996 [Uplink Processes] 998 (1) UE#1 sends packets to cDN with setting EID=d-1 as the 999 destination IP address. 1001 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 1002 destination IP address (EID=d-1) does not hit the filter of ULCL, 1003 dUPF#1 re-encapsulates the packet to another GTP-U connecting to 1004 cUPF and forwards to cUPF. 1006 (3) cUPF decapusalates GTP-U packets and forwards them to APL#3 in 1007 cDN depending on its own forwarding table. 1009 [Downlink Processes] 1011 (4) APL#3 in cDN sends packets to UE#1 with setting EID=a-1 as the 1012 destination IP address. 1014 (5) cUPF encapsulates the packets received from APL#3 and forwards 1015 them to dUPF#1 depending on its own forwarding table. 1017 (6) dUPF re-encapsulates the packets to another GTP-U and forwards 1018 to UE#1. 1020 Appendix B. Case Studies on Use of ILA 1022 This Appendix describes detailed processes of the proposal approach 1023 with ILA mechanism in the following types of communications. 1025 1. UE-to-UE Communication 1027 2. UE-to-dDN Communication 1029 3. UE-to-cDN/Internet Communication 1031 Each ILA node has ID-to-LOC mapping table. Mappings are propagated 1032 amongst ILA routers or hosts in a network using mapping propagation 1033 protocols. 1035 In the following description of case studies, a mapping system, 1036 called ILA resolver in ILA terms, has the master of ID-to-LOC mapping 1037 database, and each ILA node obtains mappings from the mapping system. 1038 In some cases, each ILA node has an ID-to-LOC mapping database. 1040 In ILA, an SIR address expressed by composition of SIR prefix and 1041 identifier is assigned to each UE or VM instance. An SIR prefix and 1042 an identifier are described SIR_prefix_n and id_m (n=1,2,..., 1043 m=1,2,...), and an SIR address is expressed as SIR_addr_x =[n,m] 1044 (x=1,2,...) in the following description. Also, each ILA-Nodes are 1045 assigned unique Locators, which is a network prefix that routes to a 1046 host. Locators are described as loc_n (n=1,2,..). 1048 B.1. UE-to-UE Communications 1050 The overview of this communication type is described in A.1. 1052 B.1.1. Case B-1: UEs allocated different dUPF 1054 +-------+ 1055 |Mapping| 1056 |System | 1057 +-------+ 1058 . 1059 . 1060 . 1061 (3) . #==========================# 1062 . # (4) # 1063 . # V 1064 +-------+ +-------+ +-------+ +-------+ 1065 | dUPF#1| | ILA- | | dUPF#2| | ILA- | 1066 | | | Node#1| |+------|<-----| Node#2| 1067 | [UL]| | | || [UL]| (5) | | 1068 | [CL]|------>| loc_1 | |v [CL]| | loc_2 | 1069 +-------+ (2) +-------+ +-------+ +-------+ 1070 ^ | 1071 | (1) |(6) 1072 | v 1074 [UE#1] [UE#2] 1075 SIR_addr_1=[1,1] SIR_addr_2=[1,2] 1077 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1079 Figure 10: Procedure in Case B-1 1081 (0) Within this network, UEs are belonged to the same ILA domain, 1082 and the same SIR prefix is assigned to UEs. SIR_addr_1=[1,1] and 1083 SIR_addr_2=[1,2] are assigned to UE#1 and UE#2. 1085 (1) UE#1 sends packets to UE#2 with setting SIR_addr_2 as the 1086 destination IP address. 1088 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1089 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1090 destination address is SIR_prefix_1. 1092 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1093 with the mapping system (if needed). 1095 (4) ILA-Node#1 obtains loc_2 as Locator of the ILA node#2 from the 1096 ID-to-LOC mapping table. ILA-Node#1 converts the prefixes of the 1097 source and destination addresses to loc_1 (Locator of id_1) and 1098 loc_2 (Locator of id_2). ILA-Node#1 sends the packet to the ILA- 1099 Node#2. 1101 (5) ILA-Node#2 receives the packet and converts the prefixes of the 1102 source and destination addresses to SIR_prefix_1, and then sends 1103 packets to dUPF#2. 1105 (6) dUPF#2 encapsulate packets with GTP-U header, and sends them to 1106 UE#2. 1108 B.1.2. Case B-2: UEs allocated the same ILA node 1109 +-------+ 1110 |Mapping| 1111 |System | 1112 +-------+ 1113 . 1114 . 1115 . 1116 (3) . 1117 . 1118 . 1119 +-------+ +-------+ +-------+ +-------+ 1120 | dUPF#1| (4) | ILA- | | dUPF#2| | ILA- | 1121 |+------|<----- | Node#1| | | | Node#2| 1122 || [UL]| | | | [UL]| | | 1123 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1124 +-------+ (2) +-------+ +-------+ +-------+ 1125 | ^ 1126 (5) | | (1) 1127 v | 1129 [UE#2] [UE#1] 1130 SIR_addr_2 SIR_addr_1 1131 =[1,2] =[1,1] 1133 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1135 Figure 11: Procedure in Case B-2 1137 (0) Within this network, UEs are belonged to the same ILA domain, 1138 and the same SIR prefix is assigned to UEs. SIR_addr_1=[1,1] and 1139 SIR_addr_2=[1,2] are assigned to UE#1 and UE#2. 1141 (1) UE#1 sends packets to UE#2 with setting SIR_addr_2 as the 1142 destination IP address. 1144 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1145 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1146 destination address is SIR_prefix_1. 1148 (3) ILA-node#1 updates own ID-to-LOC mapping table by interaction 1149 with Mapping System (if needed). 1151 (4) ILA-Node#1 obtains loc_1 as Locator of ILA node#2 from the ID- 1152 to-LOC mapping table. Since loc_1 indicates itself, ILA-Node#1 1153 sends the packets back to dUPF#1. 1155 (5) dUPF#1 encapsulate packets with GTP-U, and sends them to UE#2. 1157 B.2. UE-to-dDN Communication 1159 The overview of this communication type is described in A.2. 1161 B.2.1. Case B-3: UE communicates with neighbor dDN 1162 +-------+ 1163 |Mapping| 1164 |System | 1165 +-------+ 1166 . 1167 . 1168 . 1169 (3) . 1170 . 1171 . 1172 +-------+ +-------+ +-------+ +-------+ 1173 | dUPF#1| (6) | ILA- | | dUPF#2| | ILA- | 1174 |+------|<----- | Node#1| | | | Node#2| 1175 || [UL]| | | | [UL]| | | 1176 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1177 +-------+ (2) +-------+ +-------+ +-------+ 1178 | ^ | ^ 1179 (7) | | (1) (4)| | (5) 1180 v | v | 1181 ,---------. 1182 [UE#1] / dDN#B \ 1183 SIR_addr_1=[1,1] | | ^ | 1184 | v | | 1185 | [APL#1] | 1186 |SIR_addr_2 | 1187 \ =[2,2] / 1188 `---------' 1190 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1192 Figure 12: Procedure in Case B-3 1194 (0) Within this network, UEs are belonged to the same ILA domain, 1195 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1196 Applications in dDN#B are belonged to different ILA domain. and 1197 different SIR prefix (SIR_prefix_2) is assigned to these 1198 applications. SIR_addr_1=[1,1] and SIR_addr_2=[2,2] are assigned 1199 to UE#1 and APL#1. APL#1 is located in dDN#B. 1201 Uplink Processes 1203 (1) UE#1 sends packets to APL#1 with setting SIR_addr_2 as the 1204 destination IP address. 1206 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1207 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1208 destination address is SIR_prefix_2. 1210 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1211 with a mapping system (if needed). Or ILA-Node#1 may update its 1212 own table by a Map-Notify message when an APL is deployed or 1213 deleted in dDB#B. 1215 (4) ILA-Node#1 obtains loc_1 as Locator of id_2 from the ID-to-LOC 1216 mapping table. Since loc_1 indicates itself, ILA-Node#1 sends the 1217 packets to the dDN#B. 1219 Downlink Processes 1221 (5) APL#1 in dDN#B sends packets to UE#1 with setting SIR_address_1 1222 as the destination IP address. 1224 (6) ILA-Node#1 obtains loc_1 as Locator of id_1 from the ID-to-LOC 1225 mapping table. Since loc=1 indicates itself, ILA-Node#1 sends 1226 packets to dUPF#1. 1228 (7) dUPF#2 encapsulates packets with GTP-U, and sends them to UE#1. 1230 B.2.2. Case B-4: UE communicates with non-neighbor dDN 1231 +-------+ 1232 |Mapping| 1233 |System | 1234 +-------+ 1235 . 1236 . (7) 1237 . #================================# 1238 (3) . # #============================# # 1239 . # # (4) # # 1240 . V # V # 1241 +-------+ +-------+ +-------+ +-------+ 1242 | dUPF#1| (8) | ILA- | | dUPF#2| | ILA- | 1243 |+------|<------| Node#1| | | (0) | Node#2| 1244 || [UL]| | | | [UL]|<---->| | 1245 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1246 +-------+ (2) +-------+ +-------+ +-------+ 1247 | ^ ^ | ^ 1248 (9) | | (1) | (0) (5)| | (6) 1249 v | | v | 1250 (0) v ,--------. 1251 [UE#1] <= = = = = = = = = = = = =[UE#1] / dDN#C \ 1252 SIR_addr_1 UE#1 moves to the serving area of | | ^ | 1253 =[1,1] dUPF#1 from the serving area of UPF#2 | v | | 1254 | [APL#2] | 1255 |SIR_adrr_3| 1256 \ =[3,3] / 1257 `--------' 1259 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1261 Figure 13: Procedure in Case B-4 1263 (0) Within this network, UEs are belonged to the same ILA domain, 1264 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1265 Applications in dDN#C are belonged to different ILA domain. and 1266 different SIR prefix (SIR_prefix_3) is assigned to these 1267 applications. SIR_addr_1=[1,1] and SIR_addr_3=[3,3] are assigned 1268 to UE#1 and APL#2. APL#2 is located in dDN#C. UE#1 has moved to 1269 the serving area of dUPF#1 from the serving area of UPF#2 while 1270 communicating to APL#2. 1272 Uplink Processes 1274 (1) UE#1 sends packets to APL#2 with setting SIR_addr_3 as the 1275 destination IP address. 1277 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1278 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1279 destination address is SIR_prefix_3. 1281 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1282 with Mapping System (if needed). 1284 (4) ILA-Node#1 obtains loc_2 as Locator of id_3 from the ID-to-LOC 1285 mapping table. ILA-Node#1 converts the prefix of the source 1286 address to loc_1 (Locator of id_1), and the prefix of the 1287 destination address to loc_2 (Locator of id_3). ILA-Node#1 sends 1288 the packet to the ILA-Node#2. 1290 (5) ILA-Node#2 converts the prefix of the source address to 1291 SIR_prefix_1, and the prefix of the destination address to 1292 SIR_prefix_3, and then sends packets to dDN#C depending on its 1293 forwarding table. 1295 Downlink Processes 1297 (6) APL#2 sends packets to UE#1 with setting SIR_address_1 as the 1298 destination IP address. 1300 (7) ILA-Node#2 obtains loc_1 as Locator of id_1 from the ID-to-LOC 1301 mapping table. ILA-Node#2 converts the prefix of the source 1302 address to loc_2 (Locator of id_3), and the prefix of the 1303 destination address to loc_1 (Locator of id_1). ILA-Node#1 sends 1304 the packet to the ILA-Node#1. 1306 (8) ILA-Node#1 converts the prefix of the source address to 1307 SIR_prefix_3, and the prefix of the destination address to 1308 SIR_prefix_1, and then sends packets to d#UPF1 depending on its 1309 forwarding table. 1311 (9) dUPF#1 encapsulates the packets with GTP-U and sends packets to 1312 UE#1. 1314 B.3. UE-to-cDN/Internet Communication 1316 UE-to-cDN/Internet communication are basically achieved by GTP-U 1317 mechanism originally equipped in 3GPP 5GS architecture. ILA causes 1318 some limitation on IP addressing to UEs (e.g., all UEs in an ILA 1319 domain have the same SIR prefix), and thus some IP translation node 1320 such as NAT (Network Address Translation) may be required to enable 1321 UEs to access to external network. In this section, we describe 1322 processes of UE-to-cDN/Internet communication in the proposal 1323 architecture. In Internet communication, from aspect of privacy or 1324 routing with external network, SIR addresses assigned to UEs are 1325 translated by NAT function deployed between dUPF and connection 1326 point. 1328 B.3.1. Case B-5: Internet Communication 1330 ,------------. 1331 / cDN \ 1332 | | 1333 |SIR_addr_4=[4,4] 1334 | [APL#3] | 1335 | | ^ | 1336 \ | | / 1337 `------------' 1338 (4) | | (3) 1339 v | 1340 +-----------+ 1341 | cUPF | 1342 +-----------+ 1343 | ^ 1344 (5) | | 1345 +--------------------+ | 1346 | +--------------------+ 1347 | | (2) 1348 v | 1349 +-------+ +-------+ 1350 | dUPF#1| | ILA- | 1351 | | | Node#1| 1352 | [UL]| | | 1353 | [CL]| | loc_1 | 1354 +-------+ +-------+ 1355 | ^ 1356 (6) | | (1) 1357 v | 1359 [UE#1] 1360 SIR_addr_1=[1,1] 1362 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1364 Figure 14: Procedure in Case B-5 1366 (0) Within this network, UEs are belonged to the same ILA domain, 1367 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1368 Applications in cDN are belonged to different ILA domain. and 1369 different SIR prefix (SIR_prefix_4) is assigned to these 1370 applications. SIR_addr_1=[1,1] and SIR_addr_4=[4,4] are assigned 1371 to UE#1 and APL#3. APL#3 is located in cDN. 1373 Uplink Processes 1375 (1) UE#1 sends packets to APL#3 with setting SIR_adrr_4 as the 1376 destination IP address. 1378 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 1379 destination IP address (SIR_adder_4) does not hit the filter of 1380 ULCL, dUPF#1 re-encapsulates the packet to another GTP-U 1381 connecting to cUPF and forwards to cUPF. 1383 (3) cUPF decapusalates GTP-U packets and forwards them to APL#3 in 1384 cDN depending on its own forwarding table. 1386 Downlink Processes 1388 (4) APL#3 in cDN sends packets to UE#1 with setting SIR_addr_1 as 1389 the destination IP address. 1391 (5) cUPF encapsulates the packets received from APL#3 and forwards 1392 them to dUPF#1 with GTP-U encapsulation depending on its own 1393 forwarding table. 1395 (6) dUPF re-encapsulates the packets to another GTP-U and forwards 1396 to UE#1. 1398 B.3.2. Case B-6: Internet Communication 1399 IP_Addr_5 1400 [Server#1] 1401 | ^ 1402 (5) v | (4) 1403 .--. 1404 ( )-. 1405 .' ' 1406 ( Internet ) 1407 ( -' 1408 '-( ) 1409 '---' 1410 (5) | ^ (4) 1411 v | 1412 +-----------+ 1413 | NAT | SIR_Addr_1 <-> IP_Addr_10 1414 +----+-+----+ 1415 | | 1416 (6) v | (3) 1417 +-----------+ 1418 | cUPF | 1419 +-----------+ 1420 | ^ 1421 (7) | | 1422 +--------------------+ | 1423 | +--------------------+ 1424 | | (2) 1425 v | 1426 +-------+ +-------+ 1427 | dUPF#1| | ILA- | 1428 | | | Node#1| 1429 | [UL]| | | 1430 | [CL]| | loc_1 | 1431 +-------+ +-------+ 1432 | ^ 1433 (8) | | (1) 1434 v | 1436 [UE#1] 1437 SIR_addr_1=[1,1] 1439 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1441 Figure 15: Procedure in Case B-6 1443 (0) Within this network, UEs are belonged to the same ILA domain, 1444 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1445 SIR_addr_1=[1,1] assigned to UE#1 and server#1 has IP_addr_5. 1446 UE#1 communicate with server#1 over Internet. 1448 Uplink Processes 1450 (1) UE#1 sends packets to server#1 with setting IP_adrr_5 as the 1451 destination IP address. 1453 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 1454 destination IP address (SIR_adder_4) does not hit the filter of 1455 ULCL, dUPF#1 re-encapsulates the packet to another GTP-U 1456 connecting to cUPF and forwards to cUPF. 1458 (3) cUPF decapusalates GTP-U packets and forwards them to Internet 1459 depending on its own forwarding table. 1461 (4) NAT translates SIR_addr_1 of received packets to IP_addr_10 and 1462 the packets are forwarded to server#1 over Internet. 1464 Downlink Processes 1466 (5) Server#1 sends packets to UE#1 with setting IP_addr_1 as the 1467 destination IP address. 1469 (6) NAT translates IP_addr_10 of received packets to SIR_addr_1, and 1470 packets are sent to cUPF. 1472 (7) cUPF encapsulates the packets with GTP-U and sends them to 1473 dUPF#1 depending on its own forwarding table. 1475 (8) dUPF re-encapsulates the packets to another GTP-U and forwards 1476 to UE#1. 1478 Authors' Addresses 1480 Shunsuke Homma 1481 NTT 1482 3-9-11, Midori-cho 1483 Musashino-shi, Tokyo 180-8585 1484 Japan 1486 Email: shunsuke.homma.fp@hco.ntt.co.jp 1487 Kenta Kawakami 1488 NTT 1489 3-9-11, Midori-cho 1490 Musashino-shi, Tokyo 180-8585 1491 Japan 1493 Email: kawakami.kenta@lab.ntt.co.jp 1495 Arashmid Akhavain 1496 Huawei Canada Research Centre 1497 Canada 1499 Email: arashmid.akhavain@huawei.com 1501 Alberto Rodriguez-Natal 1502 Cisco Systems Inc. 1503 USA 1505 Email: natal@cisco.com 1507 Ravi Shekhar 1508 Cisco Systems Inc. 1509 India 1511 Email: ravishek@cisco.com