idnits 2.17.1 draft-homma-dmm-5gs-id-loc-coexistence-01.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 (May 15, 2018) is 2171 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 960, but not defined == Missing Reference: 'B' is mentioned on line 829, but not defined == Missing Reference: 'C' is mentioned on line 889, but not defined == Missing Reference: 'D' is mentioned on line 962, but not defined == Outdated reference: A later version (-01) exists of draft-bogineni-dmm-optimized-mobile-user-plane-00 == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-02 == Outdated reference: A later version (-01) exists of draft-herbert-intarea-ila-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-00 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). 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: November 16, 2018 A. Akhavain 6 Huawei Canada Research Centre 7 May 15, 2018 9 Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture 10 draft-homma-dmm-5gs-id-loc-coexistence-01 12 Abstract 14 This document describes an approach to introduce Identifier Locator 15 Separation architecture into 3GPP 5GS with low-impact on its 16 specification, and shows the features and considerations of this 17 approach. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 16, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms of ID-LOC Protocols . . . . . . . . . . . . . . . . 4 56 2.2. Terms of 5GS . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Mechanism on Data Plane . . . . . . . . . . . . . . . . . . . 5 58 4. Mechanisms on Control Plane . . . . . . . . . . . . . . . . . 10 59 4.1. Model 1: Independent Control Planes . . . . . . . . . . . 11 60 4.2. Model 2: Interworking Control Planes . . . . . . . . . . 11 61 4.3. Model 3: Integrated Control Planes . . . . . . . . . . . 12 62 5. Features Analysis . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 12 64 5.2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Informative References . . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Case Studies on Use of LISP . . . . . . . . . . . . 14 70 A.1. UE-to-UE Communication . . . . . . . . . . . . . . . . . 15 71 A.1.1. Case A-1: UEs allocated different dUPF . . . . . . . 15 72 A.1.2. Case A-2: UEs allocated the same xTR . . . . . . . . 17 73 A.1.3. Consideration of Case that UE Moves to under Another 74 xTR . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 A.2. UE-to-dDN Communication . . . . . . . . . . . . . . . . . 18 76 A.2.1. Case A-3: UE communicates with neighbor dDN . . . . . 18 77 A.2.2. Case A-4: UE communicates with non-neighbor dDN . . . 20 78 A.3. UE-to-cDN/Internet Communication . . . . . . . . . . . . 22 79 A.3.1. Case A-5: UE communicates with cDN . . . . . . . . . 22 80 Appendix B. Case Studies on Use of ILA . . . . . . . . . . . . . 24 81 B.1. UE-to-UE Communications . . . . . . . . . . . . . . . . . 25 82 B.1.1. Case B-1: UEs allocated different dUPF . . . . . . . 25 83 B.1.2. Case B-2: UEs allocated the same ILA node . . . . . . 26 84 B.2. UE-to-dDN Communication . . . . . . . . . . . . . . . . . 28 85 B.2.1. Case B-3: UE communicates with neighbor dDN . . . . . 28 86 B.2.2. Case B-4: UE communicates with non-neighbor dDN . . . 30 87 B.3. UE-to-cDN/Internet Communication . . . . . . . . . . . . 32 88 B.3.1. Case B-5: Internet Communication . . . . . . . . . . 33 89 B.3.2. Case B-6: Internet Communication . . . . . . . . . . 34 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 92 1. Introduction 94 Identifier Locator Separation (ID-LOC) architecture aims to simplify 95 management of network, devices, and sessions by employing two 96 namespaces: Identifier for device's identity, and Locator for its 97 location in the network. 99 ID-LOC architecture can be implemented by a dedicated protocol such 100 as LISP, ILA, ILNP, etc. The control plane of such ID-LOC protocols 101 can be combined with one of different encapsulation techniques such 102 as GTP-U, SRv6, MPLS, etc. at data plane to provide a customized 103 solution. Furthermore, regarding control plane of ID-LOC, it can 104 optionally even take advantage of enhanced PUB/SUB capable 105 distributed databases to circulate ID-LOC mapping relationships in 106 the network. 108 ID-LOC protocols are also expected to be used for optimizing user- 109 plane of mobile network 110 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Different 111 alternatives to introduce ID-LOC architecture into 3GPP 5GS(5th 112 Generation System), are under consideration in related IETF WG such 113 as DMM WG. 115 Introducing ID-LOC architecture into mobile network can involve 116 modifications to 5GS architecture and specifications that might span 117 over several 5GS releases. 119 Therefore, an approach that enables the introduction of ID-LOC 120 architecture into 5GS without change of its specifications and 121 supports migration path toward a native ID-LOC native network can be 122 useful to operators. Here, ID-LOC native network refers to a network 123 that employs the ID-LOC architecture as only mechanism for packet 124 forwarding. 126 The document aims to describe one such approach and clarify different 127 features, and benefits. 129 2. Definition of Terms 131 This section describes general terms of ID-LOC architecture. This 132 document also refers definitions of 3GPP 5GS [TS.23.501-3GPP], and 133 some of such terms which are used in this document are listed in this 134 section. 136 The detailed specifications of LISP are described in [RFC6830], 137 [RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061], and 138 [RFC8111]. Moreover, definitions and specifications of another 139 approach to introduce LISP into 3GPP 5GS is described in 140 [I-D.farinacci-lisp-mobile-network]. 142 The detailed specification of ILA are described in 143 [I-D.herbert-intarea-ila]. 145 The detailed specification of SRv6 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 architecture, IP or MAC address, as unique value, 153 is assigned to an end device. Values of the source and 154 destination IP/MAC address fields of packets sent from end points 155 are used as ID. 157 Locator (LOC): A LOC is an IPv4 or IPv6 address of a LOC-node. In 158 the case of SRv6 it can be the LOC-node's local SID representing 159 the segment for which the LOC-node is the segment termination 160 node. 162 LOC-node; A LOC-node is a node that has a unique locator within a 163 network domain, and has functionalities to obtain destination 164 locator and to forward packets to the LOC-node which has the 165 locator. This node has access to an ID-LOC mapping table and 166 obtains destination locator by looking up destination ID 167 (destination address of a data packet) from the mapping table. If 168 ID of the received packet is not registered in its own mapping 169 table, a LOC-node requests mapping information of the ID and the 170 assigned locator to ID-to-LOC mapping database. Also a LOC-node 171 forwards packet to a peered LOC node by encapsulation or 172 conversion of the IP header field such as IP address field, and 173 decapsulates or reconverts packets received from another LOC-node. 174 Different implementations of ID-LOC architecture use different 175 forwarding mechanisms. LISP, for example, uses IPv4/v6 header and 176 LISP header for encapsulation, whereas ILA tightly couples itself 177 with IPv6, and SRv6 uses IPv6 and SIDs (Segment Identifiers). 179 ID-to-LOC Mapping Database: An ID-to-LOC mapping database is a 180 database which contains all known ID-to-LOC mappings within an ID- 181 LOC domain. The mapping information is updated when an end point 182 moves to under another LOC-node. This database is either owned by 183 an individual system or each LOC-node. If an external system owns 184 the database, each LOC-node has an interface to the system to send 185 a request and receive mapping information. 187 ID-to-LOC Mapping Table: An ID-LOC mapping table is a table in a 188 LOC-node that stores ID-to-LOC mapping information and it is used 189 for obtaining destination LOC from ID of received packet. ID-to- 190 LOC mapping table typically contains a small piece of database. 191 The table is updated when the LOC-node receives a new ID-to-LOC 192 mapping information from ID-to-LOC mapping database or some of 5GS 193 system. 195 Mapping System: A mapping system is a function which stores ID-to- 196 LOC mapping database. This system has interfaces to receive a 197 request from a LOC-node and send an ID-to-LOC mapping to it. It 198 may be composed of multiple components. 200 2.2. Terms of 5GS 202 User Plane Function (UPF): An UPF handles the user plane paths. An 203 UPF is connected to SMF with N4 interface. More detailed 204 information is described in [TS.23.501-3GPP]. This document 205 defines two types of UPF, Central UPF (cUPF) and Distributed UPF 206 (dUPF). Their features are described in Section 3 208 Uplink Classifier (ULCL): An ULCL is an UPF functionality that aims 209 at diverting Uplink traffic, based on filter rules provided by 210 SMF, towards Data Network (DN). 212 Data Network (DN): A DN is a network where network functions and 213 entities, including operator or 3rd party services, are deployed. 214 This document defines two types of DN, Central DN (cDN) and 215 Distributed DN (dDN). Their features are described in Section 3. 217 Radio Access Network (RAN): A RAN is an access network where radio 218 bearer sent by UEs traverse. A RAN encapsulate users' packets 219 with GTP-U. 221 Session Management Function (SMF): An SMF is a function which 222 provides control plane functionalities for handling user traffic. 224 Application Function (AF): An AF is a control plane functionality 225 and connected to SMF with Naf interfaces. 227 3. Mechanism on Data Plane 229 This approach achieves traffic forwarding with optimized path and 230 session continuity by using ID-LOC and ULCL for particular 231 communication including UE-to-UE or MEC (Mobile Edge Computing) 232 communication. ULCL is one of fundamental functions of 5GC Rel.15 233 and it provides functionalities of packet filtering and divert for 234 uplink packets sent by UEs. 236 The overview of the assumed 5GC architecture of data plane where the 237 proposal approach works is shown in Figure 1. The details of 238 numbered interfaces in the figure are described in [TS.23.501-3GPP]. 240 .--. 241 ( )-. 242 .' cDN/ ' 243 ( Internet ) 244 ( -' 245 '-( ) 246 '---' 247 |N6 248 +-----+-----+ 249 | cUPF | === 250 +-----+-----+ ^ 251 |N9 | 252 ,-----------------------+-----------------------. | 253 / \ | 254 | Transport Network | | 255 \ / | 256 `----+---------------------------+--------------' 257 |N9 |N9 Connected 258 +-----+-----+ ,-----. +-----+-----+ ,-----. with 259 | dUPF#1 |N6 / \ | dUPF#2 |N6 / \ GTP-U 260 | [UL]+---| dDN#A | | [UL]+---| dDN#B |.. 261 | [CL]| \ / | [CL]| \ / | 262 +-----+-----+ `-----' +-----+-----+ `-----' | 263 |N3 |N3 | 264 | 265 (( o )) (( o )) | 266 A A v 267 /-\ RAN /-\ RAN === 268 /-|-\ /-|-\ 270 | | 272 [ UE ] .. [ UE ] .. 274 dUPF: Distributed UPF 275 cUPF: Central UPF 276 dDN: Distributed DN 277 cDN: Central DN 279 Figure 1: Assumed 5GC Network Architecture 281 This network has following features; 283 o A Central UPF (cUPF) is deployed at a connecting point to Central 284 DN (cDN). A cUPF becomes anchor point for UEs and it assigns IP 285 addresses (IDs) for each UE. The traffic transmitted from UEs are 286 basically sent to the cUPF. 288 o Distributed UPFs (dUPFs) and Distributed DNs (dDNs) are deployed 289 and geographically distributed at user edge side. A unique 290 address space (it's not necessarily globally unique) is assigned 291 to dDN. When a dUPF forwards an UE's uplink packet, and if the 292 subnet of the destination address is the same as the one assigned 293 to dDN at proximity, then dUPF, with the help of ULCL, may divert 294 the packet to that dDN. Here, the ULCL identifies each 295 encapsulated uplink packet to be diverted, by checking if the 296 destination of the inner packet is one of IP addresses assigned 297 the dDN. A dUPF removes GTP-U header from the packets, and sends 298 them to dDN via N6. When dUPF receives packets from dDN, dUPF 299 encapsulates them with GTP-U header, and merges them into downlink 300 packets from cUPF. An overview of behaviors of dUPF and ULCL is 301 shown in Figure 2. 303 o Network topology between RAN and dUPF/cUPF adopts tree structure 304 and the section between RAN and dUPF and the section between dUPF 305 and cUPF are connected with GTP-U. 307 GTP-U packets GTP-U packets 308 from cUPF to cUPF 310 | ^ 311 | N9 | 312 | | 313 +----|------------|-----+ 314 | | dUPF | | ,---------. 315 | v | | IP packet / \ 316 | o<-----------------------------| | 317 | | | | | | 318 | | | | N6 | dDN | 319 | | +------+ | | | 320 | | | ULCL |------------->| | 321 | | +------+ | IP packet | | 322 | | ^ | \ / 323 +----|------------|-----+ `---------' 324 | | 325 | | 326 | N3 | 327 v | 329 GTP-U packets GTP-U packets 330 to UE from UE 332 Figure 2: Behaviors of dUPF and ULCL 334 In the proposal approach, a LOC-node is installed between dUPF and 335 dDN. LOC-nodes are connected with a IP mechanism such as IP tunnels 336 or translation of destination IP field. As examples of such data 337 plane protocols for providing connectivity between LOC-nodes, IPv4/v6 338 header with LISP header or SRv6 339 ([I-D.ietf-6man-segment-routing-header]) can be used. In addition, 340 each LOC-node has connectivity with one or more Mapping Systems. The 341 overview is shown in Figure 3. 343 .--. 344 ( )-. 345 .' cDN/ ' 346 ( Internet ) 347 ( -' 348 '-( ) 349 '---' 350 |N6 ,---------. 351 +-----+-----+ | Mapping | 352 | cUPF | | System | 353 +-----+-----+ `---------' 354 |N9 . 355 ,-----------------------+----------------.---------. 356 / Transport Network . . . . . . . . . . . . . . . \ 357 | . . | 358 \ #===========================#=== / 359 `----+------------#--.-----------+------------#--.-' 360 |N9 # . |N9 # . 361 +-----+-----+ +-------+ +-----+-----+ +-------+ 362 | dUPF#1 |N6 | LOC- | | dUPF#2 |N6 | LOC- | 363 | [UL]+---+ Node#1| | [UL]+---| Node#2|.. 364 | [CL]| | | | [CL]| | | 365 +-----+-----+ +---+---+ +-----+-----+ +---+---+ 366 |N3 | |N3 | 367 ,-----. ,-----. 368 (( o )) / \ (( o )) / \ 369 A | dDN#A | A | dDN#B | 370 /-\ RAN \ / /-\ RAN \ / 371 /-|-\ `-----' /-|-\ `-----' 373 | | 375 [ UE ] .. [ UE ] .. 377 ===== : Connection between LOC nodes 378 . . . : IF to Mapping System 380 Figure 3: Proposal Network Architecture 382 Each dUPF has a filter table of ULCL. Each filter table is 383 configured to match addresses assigned within own network domain 384 (i.e., addresses for UEs assigned by cUPF) or assigned corresponding 385 with address space of some of dDN. UPFs monitor each uplink GTP-U 386 packet with its ULCL and divert it to the connected LOC-node with 387 decapsulation of GTP-U if the destination address of the inner packet 388 (payload) matches the filtering table. When LOC-node receives a 389 packet from the dUPF, it obtains LOC which the destination of the 390 packet (ID) belongs to by looking up its own ID-to-LOC mapping table 391 or querying it from the Mapping System according ID-LOC mechanism. 392 Then it sends the packet to peered LOC-node indicated by the LOC. 393 The peered LOC-node converts the received packet to appropriate form 394 and forwards them the destination by following its own forwarding 395 table. 397 From such processes, forwarding paths of user traffic diverted by 398 ULCL from 5GC to LOC-node are optimized. 400 A cUPF is connected with dUPFs via N9 interface and packets are 401 forwarded with GTP-U encapsulation between cUPF and dUPF. 403 Some case studies of ID-LOC protocols are described in Appendix A and 404 Appendix B. 406 4. Mechanisms on Control Plane 408 For ID-LOC mechanism in mobile networks, a control plane mechanism to 409 manage location information of UEs is required. There are mainly 410 three models to realize control plane mechanism for ID-LOC as 411 follows: 413 Model 1: Independent Control Planes 415 Model 2: Interworking Control Planes 417 Model 3: Integrated Control Planes 419 Some of models may require to use 5GS interfaces or add some 420 functionalities to functions of 5GC. 5GS architecture and the 421 service-based interfaces are shown in Figure 4. The details of 422 functions and interfaces are described in [TS.23.501-3GPP]. 424 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 425 |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 426 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 427 Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf 428 ---+--------+--+-----+--+--------+--+-----+--------+- 429 Nausf| Namf| Nsmf| 430 +--+--+ +--+--+ +--+--+ 431 |AUSR | | AMF | | SMF | 432 +-----+ +--+--+ +-----+ 433 /| | 434 C-plane N1/ |N2 |N4 436 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 437 D-plane / | | 438 N1 / |N2 |N4 439 / | | 440 +-+-+ +--+--+ N3 +--+--+ N6 +----+ 441 |UE +--+(R)AN+-----+ UPF +-----+ DN | 442 +---+ +-----+ +-----+ +----+ 444 Figure 4: 5GS Architecture and Service-based Interfaces 446 4.1. Model 1: Independent Control Planes 448 In this model, control plane of 5GC and ID-to-LOC mapping mechanism 449 are completely separated. Information of an UE and a LOC-node which 450 the UE is attached is sent to a mapping system and registered in the 451 mapping database only when the LOC-node receives a packet from the UE 452 and the UE is not registered yet. 454 This model does not cause any impacts on 5GC architecture. However, 455 in this model, an UE cannot be accessed from other UEs within the 456 same network domain until a packet from the UE is diverted to the 457 LOC-node by the UPF which the UE is located and the EID and RLOC are 458 registered to the Mapping System. 460 4.2. Model 2: Interworking Control Planes 462 In this model, a mapping system interworks with an SMF which manages 463 sessions of each UE. A scheme to inform, that an UE moves and is 464 relocated to another UPF, from SMF to AF via Naf interface is defined 465 in 5GS ([TS.23.502-3GPP])*. A Mapping System is installed as an AF 466 and obtains mobility information of UEs with the above scheme. 468 * The stage 3 of discussion of 5GS has not been fixed yet and the 469 specification may be changed. 471 This model would not cause any impacts on 5GS architecture, and a 472 mapping system can always keep the current mobility information of 473 each UE. 475 4.3. Model 3: Integrated Control Planes 477 In this model, SMF functionalities are integrated into a mapping 478 system. In other words, the mapping system becomes a part of 5GS. 479 In 5GS architecture, an SMF has a role of session management of UEs, 480 and it updates its own mapping database depending on movement of an 481 UE. 483 This approach enables to always keep mapping databases the latest 484 status, however, it obviously requires extension or replacement of 485 SMF actually deployed in 5GS network. 487 5. Features Analysis 489 5.1. Benefits 491 o This approach provides a mechanism for introducing ID-LOC 492 architecture into 5GS with no or nominal impact, and achieves 493 optimized forwarding with session continuity in the assumed use 494 cases such as UE-to-UE or UE-to-dDN communications. 496 o Regarding communication to the cDN, this approach can keep 497 scalability because it does not change the current mechanism of 498 5GS. (ID-LOC-native network or full-overlay approaches need to 499 deploy LOC-node at the cUPF, and thus the ID-to-LOC mapping table 500 may not scale up enough in that cases. Here, a full-overlay 501 approach means making an ID-LOC system run over the whole 5GC 502 network.) 504 5.2. Issues 506 o dUPF and LOC-node are separated, and thus an extra hop may occur 507 against the optimized forwarding. However, it can be resolved by 508 implementing dUPF and LOC-node within a same box or application. 510 6. Security Considerations 512 TBD 514 7. IANA Considerations 516 This memo includes no request to IANA. 518 8. Acknowledgement 520 The authors would like to thank Ryosuke Kurebayashi, Koji Tsubouchi, 521 Toru Okugawa, and Dino Farinacci for their kind reviews and technical 522 feedback. 524 9. Informative References 526 [I-D.bogineni-dmm-optimized-mobile-user-plane] 527 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 528 and A. Rodriguez-Natal, "Optimized Mobile User Plane 529 Solutions for 5G", draft-bogineni-dmm-optimized-mobile- 530 user-plane-00 (work in progress), March 2018. 532 [I-D.farinacci-lisp-mobile-network] 533 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 534 for the Mobile Network", draft-farinacci-lisp-mobile- 535 network-02 (work in progress), September 2017. 537 [I-D.herbert-intarea-ila] 538 Herbert, T. and P. Lapukhov, "Identifier-locator 539 addressing for IPv6", draft-herbert-intarea-ila-00 (work 540 in progress), October 2017. 542 [I-D.ietf-6man-segment-routing-header] 543 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 544 Field, B., daniel.voyer@bell.ca, d., 545 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 546 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 547 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 548 Header (SRH)", draft-ietf-6man-segment-routing-header-08 549 (work in progress), January 2018. 551 [I-D.ietf-lisp-eid-mobility] 552 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 553 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 554 Unified Control Plane", draft-ietf-lisp-eid-mobility-00 555 (work in progress), May 2017. 557 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 558 Locator/ID Separation Protocol (LISP)", RFC 6830, 559 DOI 10.17487/RFC6830, January 2013, 560 . 562 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 563 Locator/ID Separation Protocol (LISP) for Multicast 564 Environments", RFC 6831, DOI 10.17487/RFC6831, January 565 2013, . 567 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 568 "Interworking between Locator/ID Separation Protocol 569 (LISP) and Non-LISP Sites", RFC 6832, 570 DOI 10.17487/RFC6832, January 2013, 571 . 573 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 574 Protocol (LISP) Map-Server Interface", RFC 6833, 575 DOI 10.17487/RFC6833, January 2013, 576 . 578 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 579 "Locator/ID Separation Protocol Alternative Logical 580 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 581 January 2013, . 583 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 584 Pascual, J., and D. Lewis, "Locator/Identifier Separation 585 Protocol (LISP) Network Element Deployment 586 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 587 2014, . 589 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 590 (LISP) Data-Plane Confidentiality", RFC 8061, 591 DOI 10.17487/RFC8061, February 2017, 592 . 594 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 595 Smirnov, "Locator/ID Separation Protocol Delegated 596 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 597 May 2017, . 599 [TS.23.501-3GPP] 600 3rd Generation Partnership Project (3GPP), "3GPP TS 601 23.501", December 2017, 602 . 604 [TS.23.502-3GPP] 605 3rd Generation Partnership Project (3GPP), "3GPP TS 606 23.502", December 2017, 607 . 609 Appendix A. Case Studies on Use of LISP 611 This Appendix describes detailed processes of the proposal approach 612 with LISP mechanism in the following types of communications. 614 1. UE-to-UE Communication 615 2. UE-to-dDN Communication 617 3. UE-to-cDN/Internet Communication 619 In the following description of case studies, ID and Locator are 620 called EID (End-point Identifier) and RLOC (Routing Locator) in LISP 621 terms. Mapping Server has the master of EID-to-RLOC mapping 622 database, and each xTR (Ingress/Egress Tunnel Router) has EID-to-RLOC 623 mapping cache. An xTR obtains the destination RLOC from its own 624 cache by looking up the destination EID of received packet. They 625 obtain mappings from the mapping system if an EID looked up is not 626 registered in the cache. Packets are passed between xTRs with some 627 tunnel protocols. 629 A.1. UE-to-UE Communication 631 In the current architecture, a cUPF becomes an anchor point for UEs, 632 and all packets between UEs even those which are located to the same 633 dUPF are transferred through the anchor point. This may cause 634 communication delay and inefficient resource usage. In the proposed 635 procedure, packets can be transferred without going through an anchor 636 point, and low latency and efficient resource usage can be achieved. 638 The UE-to-UE communications include communications between UEs 639 located to different dUPFs (Case 1), and communication between UEs 640 located to the same dUPF (Case 2). In this section, the detailed 641 procedures of the cases are described. 643 Moreover, in a mobile network, an UE may move during communications. 644 This section describes problems and considerations about UE's 645 handover in such case. 647 A.1.1. Case A-1: UEs allocated different dUPF 648 +-------+ 649 |Mapping| 650 |System | 651 +-------+ 652 . 653 . 654 . 655 (3) . #==========================# 656 . # (4) # 657 . # V 658 +-------+ +-------+ +-------+ +-------+ 659 | dUPF#1| | xTR#1 | | dUPF#2| | xTR#2 | 660 | | | RLOC=X| |+------|<-----| RLOC=Y| 661 | [UL]| | | || [UL]| (5) | | 662 | [CL]|------>| | |v [CL]| | | 663 +-------+ (2) +-------+ +-------+ +-------+ 664 ^ | 665 | (1) |(6) 666 | v 668 [UE#1] [UE#2] 669 EID=a-1 EID=a-2 671 Figure 5: Procedure in Case A-1 673 (0) Within this network, addresses are assigned to UEs from a 674 address space [A]. These addresses are described as a-n 675 (n=1,2,..). EID=a-1 and a-2 are assigned to UE#1 and UE#2. 677 (1) UE#1 sends packets to UE#2 with setting EID=a-2 as the 678 destination IP address. 680 (2) dUPF#1 monitors inner packet of received GTP-U packet and divert 681 it to xTR#1 with decapsulation if the destination address is one 682 of address space [A]. 684 (3) xTR#1 updates own EID-to-RLOC mapping chace by interaction with 685 Mapping System (if needed). 687 (4) xTR#1 obtains the RLOC(=Y) of EID=a-2 from the EID-to-RLOC 688 mapping cache, and sends the packets to the xTR#2 with a tunnel 689 with RLOC=Y as the destination address. 691 (5) xTR#2 decapsulate the packets, and sends them to dUPF#2. 693 (6) dUPF#2 encapsulate packets with GTP-U header, and sends them to 694 UE#2. 696 A.1.2. Case A-2: UEs allocated the same xTR 698 +-------+ 699 |Mapping| 700 |System | 701 +-------+ 702 . 703 . 704 . 705 (3) . 706 . 707 . 708 +-------+ +-------+ +-------+ +-------+ 709 | dUPF#1| (4) | xTR#1 | | dUPF#2| | xTR#2 | 710 |+------|<----- | RLOC=X| | | | RLOC=Y| 711 || [UL]| | | | [UL]| | | 712 |v [CL]|------>| | | [CL]| | | 713 +-------+ (2) +-------+ +-------+ +-------+ 714 | ^ 715 (5) | | (1) 716 v | 718 [UE#2] [UE#1] 719 EID=a-2 EID=a-1 721 Figure 6: Procedure in Case A-2 723 (0) Within this network, addresses are assigned to UEs from a 724 address space [A] These addresses are described as a-n (n=1,2,..). 725 EID=a-1 and a-2 are assigned to UE#1 and UE#2. 727 (1) UE#1 sends packets to UE#2 with setting EID=a-2 as the 728 destination IP address. 730 (2) dUPF#1 monitors inner packets of received GTP-U traffic and 731 divert it to xTR#1 with decapsulation if the destination address 732 is one of address space [A]. 734 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 735 Mapping System (if needed). 737 (4) xTR#1 obtains the RLOC(=X) from the EID-to-RLOC mapping cache. 738 Since RLOC=X indicates itself, xTR#1 sends the packets back to 739 dUPF#1. 741 (5) dUPF#2 encapsulate packets with GTP-U, and sends them to UE#2. 743 A.1.3. Consideration of Case that UE Moves to under Another xTR 745 When an UE moves to a serving area of another dUPF during 746 communication with another UE, EID-to-RLOC mapping database of a 747 Mapping System and the tables of the xTR and the peered xTR must be 748 updated. The xTRs can't send packets to the appropriate xTR during 749 the updating, and thus packet drop or stalling may occur. 751 To mitigate this problem, further consideration is needed. For 752 example, a mechanism that immediately advertise the update of 753 location of UEs to Mapping System and the appropriate xTRs depending 754 on movement of each UE might be required. Also, some documents 755 (e.g., [I-D.ietf-lisp-eid-mobility]) discuss this problem. 757 A.2. UE-to-dDN Communication 759 The UE-to-dDN communications basically correspond the communication 760 between an UE and neighbor dDN (Case3). On the other hand, if an UE 761 moved under another dUPF during usage of a statefull application, or 762 the application is not uniformly deployed in every dDN, the UE needs 763 to continue to communicate with the previous dDN (Case4). 765 In such cases, in the current architecture, all packets are needed to 766 go through the anchor point or dynamic GTP tunnel reconfiguration 767 between dUPF is required. The former solution causes additional 768 communication delay and inefficient resource usage. The latter 769 solution increase the cost of 5GS control plane to dynamically update 770 the GTP tunnel with multiple UPFs and their ULCL filter tables along 771 with the movement of the UE. The propal approach achieves 772 appropriate packet transfer in such cases. 774 In this section, the detailed procedures of communications between an 775 UE and neighbor dDN and communications between an UE and non-neighbor 776 dDN 778 A.2.1. Case A-3: UE communicates with neighbor dDN 779 +-------+ 780 |Mapping| 781 |System | 782 +-------+ 783 . 784 . 785 . 786 (3) . 787 . 788 . 789 +-------+ +-------+ +-------+ +-------+ 790 | dUPF#1| (6) | xTR#1 | | dUPF#2| | xTR#2 | 791 |+------|<----- | RLOC=X| | | | RLOC=Y| 792 || [UL]| | | | [UL]| | | 793 |v [CL]|------>| | | [CL]| | | 794 +-------+ (2) +-------+ +-------+ +-------+ 795 | ^ | ^ 796 (7) | | (1) (4)| | (5) 797 v | v | 798 ,-------. 799 [UE#1] / dDN#B \ 800 EID=a1 | | ^ | 801 | v | | 802 | [APL#1] | 803 \ EID=b-1 / 804 `-------' 806 Figure 7: Procedure in Case A-3 808 (0) Within this network, UEs are assigned their addresses from an 809 address space [A]. These addresses are described as a-n 810 (n=1,2,...). Also, applications in dDN#B are assigned their 811 addresses from a address space [B]. These addresses are described 812 as b-n (n=1,2,..). EID=a-1 and b-1 assigned to UE#1 and APL#1 813 which is located in dDN#B. 815 [Uplink Processes] 817 (1) UE#1 sends packets to dDN#B with setting EID=b-1 as the 818 destination IP address. 820 (2) dUPF#1 monitors inner of received GTP-U packets and divert it to 821 xTR#1 with decapsulation if the destination IP address is one of 822 address space [B]. 824 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 825 Mapping System (if needed). Or xTR#1 may update its own cache by 826 a Map-Notify message when an APL is deployed or deleted in dDB#B. 828 (4) xTR#1 obtains RLOC(=X) of EID=b-1 from the EID-to-RLOC mapping 829 cache. Since RLOC=X indicates itself and EID=b-1 is within [B], 830 xTR#1 sends the packets to the dDN#B. 832 [Downlink Processes] 834 (5) APL#1 in dDN#B sends packets to UE#1 with setting EID=a-1 as the 835 destination IP address. 837 (6) xTR#1 obtains RLOC of EID=a-1 (i.e., RLOC=X) from the EID-to- 838 RLOC mapping cache. Since RLOC=X indicates xTR#1 itself, xTR#1 839 sends packets to dUPF#1. 841 (7) dUPF#2 encapsulates packets with GTP-U, and sends them to UE#1. 843 A.2.2. Case A-4: UE communicates with non-neighbor dDN 844 +-------+ 845 |Mapping| 846 |System | 847 +-------+ 848 . 849 . (7) 850 . #==============================# 851 (3) . # #==========================# # 852 . # # (4) # # 853 . V # V # 854 +-------+ +-------+ +-------+ +-------+ 855 | dUPF#1| (8) | xTR#1 | | dUPF#2| | xTR#2 | 856 |+------|<------| RLOC=X| | | (0) | RLOC=Y| 857 || [UL]| | | | [UL]|<---->| | 858 |v [CL]|------>| | | [CL]| | | 859 +-------+ (2) +-------+ +-------+ +-------+ 860 | ^ ^ | ^ 861 (9) | | (1) | (0) (5)| | (6) 862 v | | v | 863 (0) v ,-------. 864 [UE#1] <= = = = = = = = = = = =[UE#1] / dDN#C \ 865 EID=a-1 UE#1 moves to the serving area of | | ^ | 866 dUPF#1 from the serving area of UPF#2 | v | | 867 | [APL#2] | 868 \ EID=c-1 / 869 `-------' 871 Figure 8: Procedure in Case A-4 873 (0) Within this network, UEs are assigned their addresses from an 874 address space [A]. These addresses are described as a-n 875 (n=1,2,..). And applications in dDN#C are assigned their 876 addresses from an address space [C]. These addresses are 877 described as c-n (n=1,2,..). EID=a-1 and c-1 assigned to UE#1 and 878 APL#2 which is located in dDN#C. UE#1 has moved to the serving 879 area of dUPF#1 from the serving area of UPF#2 while communicating 880 to APL#2. 882 [Uplink Processes] 884 (1) UE#1 sends packets to APL#2 with setting EID=c-1 as the 885 destination IP address. 887 (2) dUPF#1 monitors each inner packet of received GTP-U traffic and 888 divert it to xTR#1 with decapsulation if the destination address 889 is one of address space [C]. 891 (3) xTR#1 updates own EID-to-RLOC mapping cache by interaction with 892 Mapping System (if needed). 894 (4) xTR#1 obtains RLOC(=Y) of EID=c-1 from the EID-to-RLOC mapping 895 cache, and sends the packet to the xTR#2 with a tunnel with RLOC=Y 896 as the destination address. 898 (5) xTR#2 decapsulates the packets received from xTR#1, and sends 899 them to dDN#C depending on its forwarding table. 901 [Downlink Processes] 903 (6) APL#2 sends packets to UE#1 with setting EID=a-1 as the 904 destination IP address. 906 (7) xTR#2 obtains RLOC(=X) of EID=a-1 from the EID-to-RLOC mapping 907 cache, and sends the packets to the xTR#1 with a tunnel with 908 RLOC=X as the destination address. 910 (8) xTR#1 decapsulates the packets received from xTR#2m and sends 911 them to the dUPF#1 depending on its forwarding table. 913 (9) dUPF#1 encapsulates the packets with GTP-U and sends packets to 914 UE#1. 916 A.3. UE-to-cDN/Internet Communication 918 UE-to-cDN/Internet communication is achieved by GTP-U mechanism 919 originally equipped in 3GPP 5GS architecture. In this section, we 920 describe processes of UE-to-cDN communication in the proposal 921 architecture as an example. 923 A.3.1. Case A-5: UE communicates with cDN 924 ,------------. 925 / cDN \ 926 | | 927 | EID=d-1 | 928 | [APL#3] | 929 | | ^ | 930 \ | | / 931 `------------' 932 (4) | | (3) 933 v | 934 +-----------+ 935 | cUPF | 936 +-----------+ 937 | ^ 938 (5) | | 939 +--------------------+ | 940 | | 941 | +--------------------+ 942 | | (2) 943 V | 944 +-------+ +-------+ 945 | dUPF#1| | xTR#1 | 946 | | | RLOC=X| 947 | [UL]| | | 948 | [CL]| | | 949 +-------+ +-------+ 950 | ^ 951 (6) | | (1) 952 v | 954 [UE#1] 955 EID=a-1 957 Figure 9: Procedure in Case A-5 959 (0) Within this network, UEs are assigned their addresses from an 960 address space [A]. These addresses are described as a-n 961 (n=1,2,..). And applications in cDN are assigned their addresses 962 from an address space [D]. These addresses are described as d-n 963 (n=1,2,..). EID=a-1 and d-1 assigned to UE#1 and APL#3 which is 964 located in cDN. 966 [Uplink Processes] 968 (1) UE#1 sends packets to cDN with setting EID=d-1 as the 969 destination IP address. 971 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 972 destination IP address (EID=d-1) does not hit the filter of ULCL, 973 dUPF#1 re-encapsulates the packet to another GTP-U connecting to 974 cUPF and forwards to cUPF. 976 (3) cUPF decapusalates GTP-U packets and forwards them to APL#3 in 977 cDN depending on its own forwarding table. 979 [Downlink Processes] 981 (4) APL#3 in cDN sends packets to UE#1 with setting EID=a-1 as the 982 destination IP address. 984 (5) cUPF encapsulates the packets received from APL#3 and forwards 985 them to dUPF#1 depending on its own forwarding table. 987 (6) dUPF re-encapsulates the packets to another GTP-U and forwards 988 to UE#1. 990 Appendix B. Case Studies on Use of ILA 992 This Appendix describes detailed processes of the proposal approach 993 with ILA mechanism in the following types of communications. 995 1. UE-to-UE Communication 997 2. UE-to-dDN Communication 999 3. UE-to-cDN/Internet Communication 1001 Each ILA node has ID-to-LOC mapping table. Mappings are propagated 1002 amongst ILA routers or hosts in a network using mapping propagation 1003 protocols. 1005 In the following description of case studies, a mapping system, 1006 called ILA resolver in ILA terms, has the master of ID-to-LOC mapping 1007 database, and each ILA node obtains mappings from the mapping system. 1008 In some cases, each ILA node has an ID-to-LOC mapping database. 1010 In ILA, an SIR address expressed by composition of SIR prefix and 1011 identifier is assigned to each UE or VM instance. An SIR prefix and 1012 an identifier are described SIR_prefix_n and id_m (n=1,2,..., 1013 m=1,2,...), and an SIR address is expressed as SIR_addr_x =[n,m] 1014 (x=1,2,...) in the following description. Also, each ILA- Nodes are 1015 assigned unique Locators, which is a network prefix that routes to a 1016 host. Locators are described as loc_n (n=1,2,..). 1018 B.1. UE-to-UE Communications 1020 The overview of this communication type is described in A.1. 1022 B.1.1. Case B-1: UEs allocated different dUPF 1024 +-------+ 1025 |Mapping| 1026 |System | 1027 +-------+ 1028 . 1029 . 1030 . 1031 (3) . #==========================# 1032 . # (4) # 1033 . # V 1034 +-------+ +-------+ +-------+ +-------+ 1035 | dUPF#1| | ILA- | | dUPF#2| | ILA- | 1036 | | | Node#1| |+------|<-----| Node#2| 1037 | [UL]| | | || [UL]| (5) | | 1038 | [CL]|------>| loc_1 | |v [CL]| | loc_2 | 1039 +-------+ (2) +-------+ +-------+ +-------+ 1040 ^ | 1041 | (1) |(6) 1042 | v 1044 [UE#1] [UE#2] 1045 SIR_addr_1=[1,1] SIR_addr_2=[1,2] 1047 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1049 Figure 10: Procedure in Case B-1 1051 (0) Within this network, UEs are belonged to the same ILA domain, 1052 and the same SIR prefix is assigned to UEs. SIR_addr_1=[1,1] and 1053 SIR_addr_2=[1,2] are assigned to UE#1 and UE#2. 1055 (1) UE#1 sends packets to UE#2 with setting SIR_addr_2 as the 1056 destination IP address. 1058 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1059 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1060 destination address is SIR_prefix_1. 1062 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1063 with the mapping system (if needed). 1065 (4) ILA-Node#1 obtains loc_2 as Locator of the ILA node#2 from the 1066 ID-to-LOC mapping table. ILA-Node#1 converts the prefixes of the 1067 source and destination addresses to loc_1 (Locator of id_1) and 1068 loc_2 (Locator of id_2). ILA-Node#1 sends the packet to the ILA- 1069 Node#2. 1071 (5) ILA-Node#2 receives the packet and converts the prefixes of the 1072 source and destination addresses to SIR_prefix_1, and then sends 1073 packets to dUPF#2. 1075 (6) dUPF#2 encapsulate packets with GTP-U header, and sends them to 1076 UE#2. 1078 B.1.2. Case B-2: UEs allocated the same ILA node 1079 +-------+ 1080 |Mapping| 1081 |System | 1082 +-------+ 1083 . 1084 . 1085 . 1086 (3) . 1087 . 1088 . 1089 +-------+ +-------+ +-------+ +-------+ 1090 | dUPF#1| (4) | ILA- | | dUPF#2| | ILA- | 1091 |+------|<----- | Node#1| | | | Node#2| 1092 || [UL]| | | | [UL]| | | 1093 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1094 +-------+ (2) +-------+ +-------+ +-------+ 1095 | ^ 1096 (5) | | (1) 1097 v | 1099 [UE#2] [UE#1] 1100 SIR_addr_2 SIR_addr_1 1101 =[1,2] =[1,1] 1103 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1105 Figure 11: Procedure in Case B-2 1107 (0) Within this network, UEs are belonged to the same ILA domain, 1108 and the same SIR prefix is assigned to UEs. SIR_addr_1=[1,1] and 1109 SIR_addr_2=[1,2] are assigned to UE#1 and UE#2. 1111 (1) UE#1 sends packets to UE#2 with setting SIR_addr_2 as the 1112 destination IP address. 1114 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1115 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1116 destination address is SIR_prefix_1. 1118 (3) ILA-node#1 updates own ID-to-LOC mapping table by interaction 1119 with Mapping System (if needed). 1121 (4) ILA-Node#1 obtains loc_1 as Locator of ILA node#2 from the ID- 1122 to-LOC mapping table. Since loc_1 indicates itself, ILA-Node#1 1123 sends the packets back to dUPF#1. 1125 (5) dUPF#1 encapsulate packets with GTP-U, and sends them to UE#2. 1127 B.2. UE-to-dDN Communication 1129 The overview of this communication type is described in A.2. 1131 B.2.1. Case B-3: UE communicates with neighbor dDN 1132 +-------+ 1133 |Mapping| 1134 |System | 1135 +-------+ 1136 . 1137 . 1138 . 1139 (3) . 1140 . 1141 . 1142 +-------+ +-------+ +-------+ +-------+ 1143 | dUPF#1| (6) | ILA- | | dUPF#2| | ILA- | 1144 |+------|<----- | Node#1| | | | Node#2| 1145 || [UL]| | | | [UL]| | | 1146 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1147 +-------+ (2) +-------+ +-------+ +-------+ 1148 | ^ | ^ 1149 (7) | | (1) (4)| | (5) 1150 v | v | 1151 ,---------. 1152 [UE#1] / dDN#B \ 1153 SIR_addr_1=[1,1] | | ^ | 1154 | v | | 1155 | [APL#1] | 1156 |SIR_addr_2 | 1157 \ =[2,2] / 1158 `---------' 1160 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1162 Figure 12: Procedure in Case B-3 1164 (0) Within this network, UEs are belonged to the same ILA domain, 1165 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1166 Applications in dDN#B are belonged to different ILA domain. and 1167 different SIR prefix (SIR_prefix_2) is assigned to these 1168 applications. SIR_addr_1=[1,1] and SIR_addr_2=[2,2] are assigned 1169 to UE#1 and APL#1. APL#1 is located in dDN#B. 1171 Uplink Processes 1173 (1) UE#1 sends packets to APL#1 with setting SIR_addr_2 as the 1174 destination IP address. 1176 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1177 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1178 destination address is SIR_prefix_2. 1180 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1181 with a mapping system (if needed). Or ILA-Node#1 may update its 1182 own table by a Map-Notify message when an APL is deployed or 1183 deleted in dDB#B. 1185 (4) ILA-Node#1 obtains loc_1 as Locator of id_2 from the ID-to-LOC 1186 mapping table. Since loc_1 indicates itself, ILA-Node#1 sends the 1187 packets to the dDN#B. 1189 Downlink Processes 1191 (5) APL#1 in dDN#B sends packets to UE#1 with setting SIR_address_1 1192 as the destination IP address. 1194 (6) ILA-Node#1 obtains loc_1 as Locator of id_1 from the ID-to-LOC 1195 mapping table. Since loc=1 indicates itself, ILA-Node#1 sends 1196 packets to dUPF#1. 1198 (7) dUPF#2 encapsulates packets with GTP-U, and sends them to UE#1. 1200 B.2.2. Case B-4: UE communicates with non-neighbor dDN 1201 +-------+ 1202 |Mapping| 1203 |System | 1204 +-------+ 1205 . 1206 . (7) 1207 . #================================# 1208 (3) . # #============================# # 1209 . # # (4) # # 1210 . V # V # 1211 +-------+ +-------+ +-------+ +-------+ 1212 | dUPF#1| (8) | ILA- | | dUPF#2| | ILA- | 1213 |+------|<------| Node#1| | | (0) | Node#2| 1214 || [UL]| | | | [UL]|<---->| | 1215 |v [CL]|------>| loc_1 | | [CL]| | loc_2 | 1216 +-------+ (2) +-------+ +-------+ +-------+ 1217 | ^ ^ | ^ 1218 (9) | | (1) | (0) (5)| | (6) 1219 v | | v | 1220 (0) v ,--------. 1221 [UE#1] <= = = = = = = = = = = = =[UE#1] / dDN#C \ 1222 SIR_addr_1 UE#1 moves to the serving area of | | ^ | 1223 =[1,1] dUPF#1 from the serving area of UPF#2 | v | | 1224 | [APL#2] | 1225 |SIR_adrr_3| 1226 \ =[3,3] / 1227 `--------' 1229 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1231 Figure 13: Procedure in Case B-4 1233 (0) Within this network, UEs are belonged to the same ILA domain, 1234 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1235 Applications in dDN#C are belonged to different ILA domain. and 1236 different SIR prefix (SIR_prefix_3) is assigned to these 1237 applications. SIR_addr_1=[1,1] and SIR_addr_3=[3,3] are assigned 1238 to UE#1 and APL#2. APL#2 is located in dDN#C. UE#1 has moved to 1239 the serving area of dUPF#1 from the serving area of UPF#2 while 1240 communicating to APL#2. 1242 Uplink Processes 1244 (1) UE#1 sends packets to APL#2 with setting SIR_addr_3 as the 1245 destination IP address. 1247 (2) dUPF#1 monitors inner packet of received GTP-U packet and 1248 diverts it to ILA-Node#1 with decapsulation if the prefix of the 1249 destination address is SIR_prefix_3. 1251 (3) ILA-Node#1 updates own ID-to-LOC mapping table by interaction 1252 with Mapping System (if needed). 1254 (4) ILA-Node#1 obtains loc_2 as Locator of id_3 from the ID-to-LOC 1255 mapping table. ILA-Node#1 converts the prefix of the source 1256 address to loc_1 (Locator of id_1), and the prefix of the 1257 destination address to loc_2 (Locator of id_3). ILA-Node#1 sends 1258 the packet to the ILA-Node#2. 1260 (5) ILA-Node#2 converts the prefix of the source address to 1261 SIR_prefix_1, and the prefix of the destination address to 1262 SIR_prefix_3, and then sends packets to dDN#C depending on its 1263 forwarding table. 1265 Downlink Processes 1267 (6) APL#2 sends packets to UE#1 with setting SIR_address_1 as the 1268 destination IP address. 1270 (7) ILA-Node#2 obtains loc_1 as Locator of id_1 from the ID-to-LOC 1271 mapping table. ILA-Node#2 converts the prefix of the source 1272 address to loc_2 (Locator of id_3), and the prefix of the 1273 destination address to loc_1 (Locator of id_1). ILA-Node#1 sends 1274 the packet to the ILA-Node#1. 1276 (8) ILA-Node#1 converts the prefix of the source address to 1277 SIR_prefix_3, and the prefix of the destination address to 1278 SIR_prefix_1, and then sends packets to d#UPF1 depending on its 1279 forwarding table. 1281 (9) dUPF#1 encapsulates the packets with GTP-U and sends packets to 1282 UE#1. 1284 B.3. UE-to-cDN/Internet Communication 1286 UE-to-cDN/Internet communication are basically achieved by GTP-U 1287 mechanism originally equipped in 3GPP 5GS architecture. ILA causes 1288 some limitation on IP addressing to UEs (e.g., all UEs in an ILA 1289 domain have the same SIR prefix), and thus some IP translation node 1290 such as NAT (Network Address Translation) may be required to enable 1291 UEs to access to external network. In this section, we describe 1292 processes of UE-to-cDN/Internet communication in the proposal 1293 architecture. In Internet communication, from aspect of privacy or 1294 routing with external network, SIR addresses assigned to UEs are 1295 translated by NAT function deployed between dUPF and connection 1296 point. 1298 B.3.1. Case B-5: Internet Communication 1300 ,------------. 1301 / cDN \ 1302 | | 1303 |SIR_addr_4=[4,4] 1304 | [APL#3] | 1305 | | ^ | 1306 \ | | / 1307 `------------' 1308 (4) | | (3) 1309 v | 1310 +-----------+ 1311 | cUPF | 1312 +-----------+ 1313 | ^ 1314 (5) | | 1315 +--------------------+ | 1316 | | 1317 | +--------------------+ 1318 | | (2) 1319 v | 1320 +-------+ +-------+ 1321 | dUPF#1| | ILA- | 1322 | | | Node#1| 1323 | [UL]| | | 1324 | [CL]| | loc_1 | 1325 +-------+ +-------+ 1326 | ^ 1327 (6) | | (1) 1328 v | 1330 [UE#1] 1331 SIR_addr_1=[1,1] 1333 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1335 Figure 14: Procedure in Case B-5 1337 (0) Within this network, UEs are belonged to the same ILA domain, 1338 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1340 Applications in cDN are belonged to different ILA domain. and 1341 different SIR prefix (SIR_prefix_4) is assigned to these 1342 applications. SIR_addr_1=[1,1] and SIR_addr_4=[4,4] are assigned 1343 to UE#1 and APL#3. APL#3 is located in cDN. 1345 Uplink Processes 1347 (1) UE#1 sends packets to APL#3 with setting SIR_adrr_4 as the 1348 destination IP address. 1350 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 1351 destination IP address (SIR_adder_4) does not hit the filter of 1352 ULCL, dUPF#1 re-encapsulates the packet to another GTP-U 1353 connecting to cUPF and forwards to cUPF. 1355 (3) cUPF decapusalates GTP-U packets and forwards them to APL#3 in 1356 cDN depending on its own forwarding table. 1358 Downlink Processes 1360 (4) APL#3 in cDN sends packets to UE#1 with setting SIR_addr_1 as 1361 the destination IP address. 1363 (5) cUPF encapsulates the packets received from APL#3 and forwards 1364 them to dUPF#1 with GTP-U encapsulation depending on its own 1365 forwarding table. 1367 (6) dUPF re-encapsulates the packets to another GTP-U and forwards 1368 to UE#1. 1370 B.3.2. Case B-6: Internet Communication 1371 IP_Addr_5 1372 [Server#1] 1373 | ^ 1374 (5) v | (4) 1375 .--. 1376 ( )-. 1377 .' ' 1378 ( Internet ) 1379 ( -' 1380 '-( ) 1381 '---' 1382 (5) | ^ (4) 1383 v | 1384 +-----------+ 1385 | NAT | SIR_Addr_1 <-> IP_Addr_10 1386 +----+-+----+ 1387 | | 1388 (6) v | (3) 1389 +-----------+ 1390 | cUPF | 1391 +-----------+ 1392 | ^ 1393 (7) | | 1394 +--------------------+ | 1395 | | 1396 | +--------------------+ 1397 | | (2) 1398 v | 1399 +-------+ +-------+ 1400 | dUPF#1| | ILA- | 1401 | | | Node#1| 1402 | [UL]| | | 1403 | [CL]| | loc_1 | 1404 +-------+ +-------+ 1405 | ^ 1406 (8) | | (1) 1407 v | 1409 [UE#1] 1410 SIR_addr_1=[1,1] 1412 Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)] 1414 Figure 15: Procedure in Case B-6 1416 (0) Within this network, UEs are belonged to the same ILA domain, 1417 and the same SIR prefix (SIR_prefix_1) are assigned to UEs. 1418 SIR_addr_1=[1,1] assigned to UE#1 and server#1 has IP_addr_5. 1419 UE#1 communicate with server#1 over Internet. 1421 Uplink Processes 1423 (1) UE#1 sends packets to server#1 with setting IP_adrr_5 as the 1424 destination IP address. 1426 (2) dUPF#1 monitors inner of received GTP-U packets. Since the 1427 destination IP address (SIR_adder_4) does not hit the filter of 1428 ULCL, dUPF#1 re-encapsulates the packet to another GTP-U 1429 connecting to cUPF and forwards to cUPF. 1431 (3) cUPF decapusalates GTP-U packets and forwards them to Internet 1432 depending on its own forwarding table. 1434 (4) NAT translates SIR_addr_1 of received packets to IP_addr_10 and 1435 the packets are forwarded to server#1 over Internet. 1437 Downlink Processes 1439 (5) Server#1 sends packets to UE#1 with setting IP_addr_1 as the 1440 destination IP address. 1442 (6) NAT translates IP_addr_10 of received packets to SIR_addr_1, and 1443 packets are sent to cUPF. 1445 (7) cUPF encapsulates the packets with GTP-U and sends them to 1446 dUPF#1 depending on its own forwarding table. 1448 (8) dUPF re-encapsulates the packets to another GTP-U and forwards 1449 to UE#1. 1451 Authors' Addresses 1453 Shunsuke Homma 1454 NTT, Corp. 1455 3-9-11, Midori-cho 1456 Musashino-shi, Tokyo 180-8585 1457 Japan 1459 Email: homma.shunsuke@lab.ntt.co.jp 1460 Kenta Kawakami 1461 NTT, Corp. 1462 3-9-11, Midori-cho 1463 Musashino-shi, Tokyo 180-8585 1464 Japan 1466 Email: kawakami.kenta@lab.ntt.co.jp 1468 Arashmid Akhavain 1469 Huawei Canada Research Centre 1470 Canada 1472 Email: arashmid.akhavain@huawei.com