idnits 2.17.1 draft-auge-dmm-hicn-mobility-deployment-options-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 July 2020) is 1388 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group J. Auge 3 Internet-Draft G. Carofiglio 4 Intended status: Informational L. Muscariello 5 Expires: 9 January 2021 M. Papalini 6 Cisco 7 8 July 2020 9 Anchorless mobility management through hICN (hICN-AMM): Deployment 10 options 11 draft-auge-dmm-hicn-mobility-deployment-options-04 13 Abstract 15 A novel mobility management approach has been proposed, that 16 leverages routable location-independent identifiers (IDs) and an 17 Information-Centric Networking (ICN) communication model integrated 18 in IPv6, also referred to as Hybrid ICN (hICN). In virtue of its 19 anchorless property, we denote this approach as hICN-AMM (hICN 20 Anchorless Mobility Management) hereinafter. 22 Such approach belongs to the category of pure ID-based mobility 23 management schemes whose objective is (i) to overcome the limitations 24 of traditional locator-based solutions like Mobile IP, (ii) to remove 25 the need for a global mapping system as the one required by locator- 26 identifier separation solutions like LISP or ILA. 28 ID-based networking as proposed by ICN architectures allows to 29 disentangle forwarding operations from changes of network location, 30 hence removing tunnels and user plane or control plane anchors. 32 This document discusses hICN-AMM deployment options and related 33 tradeoffs in terms of cost/benefits. Particular attention is devoted 34 to the insertion in the recently proposed 5G Service Based 35 Architecture under study at 3GPP where an hICN-AMM solution might 36 present a more efficient alternative to the traditional tunnel-based 37 mobility architecture through GTP-U. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 9 January 2021. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Overview of a mobile access network and the 5G 74 architecture . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Transparent integration (option #1) . . . . . . . . . . . . . 7 76 3.1. MEC deployment (option #1a) . . . . . . . . . . . . . . . 7 77 3.2. hICN deployment as a UPF (option #1b) . . . . . . . . . . 10 78 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4. "Integrated" approaches: data-plane alternatives to GTP-U 80 (option #2) . . . . . . . . . . . . . . . . . . . . . . . 12 81 4.1. hICN insertion at N9 interface only (option #2a) . . . . 13 82 4.2. hICN deployment at both N9 and N3 interfaces (option 83 #2b) . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.3. Control plane considerations . . . . . . . . . . . . . . 16 85 5. Deployment considerations . . . . . . . . . . . . . . . . . . 16 86 5.1. hICN in a slice . . . . . . . . . . . . . . . . . . . . . 17 87 5.2. End-to-end deployment . . . . . . . . . . . . . . . . . . 17 88 5.3. Network-contained deployment . . . . . . . . . . . . . . 18 89 5.4. Alternative data planes: joint hICN/SRv6 deployment . . . 18 90 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 7.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 The steady increase in mobile traffic observed in the recent years 99 has come with a growing expectation from next generation 5G networks 100 of a seamless latency-minimal service experience over multiple 101 heterogeneous access networks. Motivated by stringent next- 102 generation applications requirements and by the convergence of 103 diverse wireless radio accesses, 5G standardization bodies have 104 encouraged re-consideration of the existing Mobile IP and GTP-based 105 architecture aiming at a simplified and sustainable mobility 106 solution. 108 Specifically, enhanced user plane solutions are currently 109 investigated where GTP-U tunnels would be replaced by more flexible 110 and dynamic forwarding schemes tailored to application needs and 111 enabling novel use cases such as caching/computing at the edge (MEC/ 112 FOG), coordinated use of multiple network accesses in parallel, etc. 114 It is commonly accepted that the inefficiencies of tunnels in terms 115 of state and network overhead, as well as the presence of anchors in 116 the data plane are a direct consequence of using locators as 117 identifiers of mobile nodes/services. This has motivated the 118 introduction of a class of approaches distinguishing locators and 119 identifiers, known as Loc/ID split, and more recently of pure ID- 120 based approaches inspired from name-based Information-Centric 121 Networking (ICN) architectures. 123 The focus of this document is on the latter category of solutions and 124 more precisely on the hICN-AMM proposal in 125 [I-D.auge-dmm-hicn-mobility], that aims at a simplified anchorless 126 mobility management through Hybrid ICN (hICN), a fully-fledged ICN 127 architecture in IPv6 [I-D.muscariello-intarea-hicn]. 129 hICN-AMM benefits result both from the flexibility of pure ID-based 130 mobility solutions, that completely decouple data delivery from 131 underlying network connectivity, and from the native mobility support 132 of ICN architectures. 134 Forwarding operations are performed directly based on location- 135 independent IDs stored in routers' FIBs and no mapping of ID into 136 locators is required. In this way, purely ID-based architectures 137 remove the need to maintain a global mapping system at scale, and its 138 intrinsic management complexity. 140 Additional benefits brought by ICN communication model include: 142 * the flexibility of multi-source/multi-path connectionless pull- 143 based transport. An example is the native support for consumer 144 mobility, i.e. the transparent emission of data requests over 145 multiple and varying available network interfaces during node 146 mobility; 148 * the opportunity to define fine-grained per-application forwarding 149 and security policies. 151 An overview of ICN principles and advantages for a simplified 152 mobility management resulting from name-based forwarding can be found 153 in [RFC7476], while a detailed description of the proposal is 154 presented in [I-D.auge-dmm-hicn-mobility]. 156 In this document, we discuss the integration of hICN-AMM proposal 157 within an existing mobile network architecture and analyze the 158 resulting tradeoffs in terms of cost/benefits. The 3GPP 5G 159 architecture is used here as a reference as the envisaged target for 160 hICN-AMM insertion. 162 After a short overview of 5G architecture, we first discuss hICN-AMM 163 insertion with no modification to the existing 3GPP architecture. We 164 then consider the additional benefits emerging from a tighter 165 integration involving optimization of data plane interfaces. 166 Finally, we consider the impact of different degrees of hICN 167 penetration, ranging from end-to-end to fully network-contained 168 deployments. 170 2. Overview of a mobile access network and the 5G architecture 172 Figure 1 schematizes a typical mobile network composed of edge, 173 backhaul and core network segments. In the rest of this document, we 174 assume an IPv6-based network. 176 , - , , - , , - , 177 Cell site , ' ' , , ' ' , , ' ' , 178 __ , ,__, ,__, , 179 __/ A\ , /X/| /X/| , 180 / A\__/ __ IP edge |_|/ IP backhaul |_|/ IP core __ 181 \__/ A\ /X/| , , , , /X/| 182 / A\__/ |_|/ network ,__ network ,__ network |_|/ 183 \__/ A\ |, /X/| /X/| | 184 \__/ | , |_|/, |_|/, | 185 | , , ' | , , '' | , , '| 186 | ' - , ' | ' - , ' | ' - , ' | 187 +-+-+ +-+-+ +-+-+ +-+-+ 188 | | | | | | | | 189 |DDC| |DDC| |DDC| |DDC| 190 | | | | | | | | 191 +---+ +---+ +---+ +---+ 193 Figure 1: Overview of a typical mobile network architecture 195 With the adoption of virtualization and softwarization technologies, 196 services are increasingly hosted in Distributed Data Centers (DDC) 197 deployed at the network edge (Mobile Edge Computing, MEC). 199 5G network has been designed around such evolved Service Based 200 Architecture (SBA) [TS.23.501-3GPP], exploiting SDN and NFV 201 capabilities. It consists in a set of modular functions with 202 separation of user and control planes. Figure 2 gives the 203 traditional representation of this architecture (as of Release 15) in 204 its service-based representation. 206 Service Based Interfaces 207 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 208 | NSSF | | NRF | | DSF | | UDM | | NEF | | PCF | | AUSF | 209 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 210 | | | | | | | 211 ----+------+--+---------+---------+-------+-+---------+---------+---- 212 | | 213 +--------+---------+ +---------+--------+ MOBILITY 214 | AMF | | SMF | MANAGEMENT 215 +-+--------------+-+ +++--------------+-+ 216 | | | | control 217 | N1 | N2 | N4 | N4 plane 218 ...|..............|..............|..............|................... 219 | | | | user plane 220 | | | | 221 +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ 222 | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | 223 +-------+ +-------+ +---+---+ +-------+ +-------+ 224 Figure 2: 5G reference architecture 226 The mobility management subsystem corresponds to the bottom part of 227 the picture and distinguishes user and control planes. 229 * the *user plane* (UP) represents the path followed by user 230 traffic, between the mobile node or User Equipment (UE), and the 231 Data Network (DN) corresponding to the egress point interfacing 232 the ISP network and the Internet. The UP consists of the Radio 233 Access Network (RAN), terminated by the gNB function, and of a 234 series of User Plane Functions (UPFs) which are generic functions 235 to transport/ process the traffic up to the egress point. In 236 particular, UPFs serve as Layer 2 and Layer 3 anchors respectively 237 in the RAN, and at the interface with the DN (to advertise IP 238 prefixes). The interfaces between gNB and UPF (N3), and in- 239 between UPFs (N9) are those where GTP tunnels are currently 240 established, and where there are opportunities for optimization. 242 * the principal *control plane* functions are the Access Management 243 Function (AMF) which is responsible for the radio access, and the 244 Session Management Function (SMF) which is taking care of the 245 sessions established between a UE and a DN. 247 The resulting protocol stack between user plane components is 248 represented in Figure 3. It illustrates the encapsulation overhead 249 of this solution at the various UPFs, and well as tunnel 250 inefficiencies due to the transport of all mobile traffic up to the 251 anchor in the core (N6), the latter preventing convergence with non- 252 3GPP network accesses. 254 UE 5G-AN N3 UPF N9 UPF N6 255 | | | 256 +--------+ | | | 257 | App. |--------------------------------------------------------| 258 +--------+ | | +--------+ | 259 | IP PDU |---------------------------------------------| IP PDU | | 260 +--------+ +-----------------+ | +-----------------+ | +--------+ | 261 | | |\ relay /| | |\ relay /| | | | | 262 | | | \_____________/ |-|-| \_____________/ |-|-| | | 263 | | | | GTP-U | | | GTP-U | GTP-U | | | GTP-U | | 264 | | | +--------+ | +--------+--------+ | +--------+ | 265 | 5G | | 5G | UDP |-|-| UDP | UDP |-|-| UDP | | 266 | AN |-| AN +--------+ | +--------+--------+ | +--------+ | 267 |protocol| |protocol| IP |-|-| IP | IP |-|-| IP | | 268 | layers | | layers +--------+ | +--------+--------+ | +--------+ | 269 | | | | L2 |-|-| L2 | L2 |-|-| L2 | | 270 | | | +--------+ | +--------+--------+ | +--------+ | 271 | | | | L1 |-|-| L1 | L1 |-|-| L1 | | 272 +--------+ +-----------------+ | +-----------------+ | +--------+ | 273 | | | 275 Figure 3: 5G protocol stack 277 3. Transparent integration (option #1) 279 This section discusses the insertion of hICN-AMM in an unmodified 280 3GPP 5G reference architecture, where GTP tunnels are preserved. As 281 previously stated, maintaining GTP tunnels does not allow to overcome 282 limitations of anchor-based approaches. However, a transparent 283 integration of hICN-AMM limits to the minimum deployment costs and 284 already brings advantages over the baseline architecture. We 285 consider two cases: a) hICN-AMM deployment within Mobile Edge 286 Computing (MEC) platforms, exploiting the local breakout capabilities 287 of 5G networks, b) hICN-AMM deployment as User Plane Function (UPF) 288 inside mobile user plane. 290 3.1. MEC deployment (option #1a) 292 Option #1a refers to the deployment of an hICN forwarder within 293 Mobile Edge Computing platforms. It relies on the local breakout 294 capability introduced in 5G, i.e. a specific UPF denoted UL/CL 295 (uplink classifier) that locally diverts specific flows to an 296 alternative DN, filtering packets based for instance on information 297 carried in packet headers. 299 In the hICN-AMM case, this function is used to realize the hICN 300 punting function described in [I-D.muscariello-intarea-hicn], i.e. to 301 identify hICN traffic (Interest and Data packets) and forward it to 302 the local MEC hICN instance. 304 The MEC deployment is illustrated in Figure 4. It is worth noticing 305 that option #1a shares similarities with the deployment approach for 306 ID/Loc solutions proposed in [I-D.homma-dmm-5gs-id-loc-coexistence]. 308 +-----------------+ +------------------+ 309 | AMF | | SMF | 310 +-+-------------+-+ +++--------------+-+ 311 | | .| | 312 | N1 | N2 N4 .| N4 | N4 313 | | .| | 314 +---+--+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ 315 | UE +-----+ gNB +------+ UL/CL +------+ UPF +------+ DN | 316 +------+ +-------+ +---+---+ +-------+ +-------+ 317 .| 318 .| N9 319 .| _ 320 +--++---+ N9 +-------+ MEC _( )___ 321 | UPF +------+ DN +------( hICN )_ 322 +-------+ +-------+ (_________) 323 ^ ^ ^ 324 |_______________| | 325 local breakout hICN insertion 327 Figure 4: hICN insertion in MEC 329 Although it preserves tunnels and anchor points, option #1a permits 330 an early termination of tunnels and the distribution of hICN 331 capabilities close to the edge like in path caching and rate/loss/ 332 congestion control which may be leveraged for efficient low-latency 333 content distribution, especially in presence of consumer mobility. 334 Let us analyze more in details such advantages. 336 *Pro: Benefits of edge caching* 338 The ability for the UE to communicate with an endpoint close to the 339 access is a pre-requisite of latency-sensitive and interactive 340 applications such as AR/VR. Option #1a avoids forwarding of high- 341 throughput traffic into the core, when it can be terminated locally 342 at MEC. 344 hICN ability to take dynamic hop-by-hop forwarding decisions 345 facilitates edge/core traffic load-balancing. In addition, the pull- 346 based transport model enables request aggregation removing traffic 347 redundancy and facilitates the use of dynamically discovered sources. 348 This is the case of requests directly satisfied from locally buffered 349 temporary copies. In this way, hICN implicitly realizes 350 opportunistic multicast distribution of popular content with benefits 351 for improved users' QoE for services such as VoD or live streaming as 352 well as reduced traffic cost by offloading the mobile core. 354 We remark that for caching of data or of requests to be effective, a 355 sufficient level of aggregation is required: one can thus expect hICN 356 instances to be useful in the backhaul and core locations (with an 357 eventual hierarchy of caches), while low-latency applications will 358 benefit from deployments close to the cell site. 360 *Pro: Consumer mobility improvements* 362 Consumer mobility is natively supported in ICN. It is sufficient for 363 a mobile UE to keep sending interests as soon as it connects to a new 364 network interface. The combined use of identifiers and of a pull- 365 model in hICN-AMM allows for seamless mobility across heterogeneous 366 wired and wireless networks, as well as their simultaneous use for 367 multi-homing and bandwidth aggregation. 369 Figure 5 illustrates a mobility scenario considering a 3GPP access 370 and a non-3GPP WiFi access tunneled to a N3 Inter-networking Function 371 (N3IWF) offering a N3 interface for connection to the first UPF. In 372 this setting, both wireless accesses are assumed to be connected 373 through the same backhaul link, and thus to converge into the same 374 first UPF. 376 Placing an hICN instance at the aggregation of the two accesses would 377 be beneficial both in terms of mobility and of local loss recovery, 378 as a lost packet would be fast retransmitted directly from local hICN 379 instance. 381 tunnelled non-3GPP radio 382 (eg. WiFi) +------+ N3 383 +----+ N3IWF+-------+ hICN 384 / +------+ \ + 385 / \ | 386 +---+---+ +-------+ N3 +---+---+ N9 +---+---+ N6 +---+---+ 387 | UE +---+ gNB +----+ UL/CL +----+ UPF +----+ DN +---+ hICN 388 +-------+ +-------+ +---+---+ +-------+ +-------+ 390 Figure 5: Example of a UE connection to two local radio accesses 392 *Pro: Multihoming and multi-source communications* 393 A specific feature of hICN transport is to control the use of 394 multiple path/sources of content at the same time, for instance 395 caches located at the edge of different fixed/mobile network 396 accesses. The consumer is able to use both network accesses in 397 parallel adapting load-balancing on a per-packet granularity, based 398 on network conditions in order to exploit the full aggregated 399 bandwidth and/or to compensate variations induced by UE mobility or 400 by random fluctuations of individual radio channel conditions. 402 Figure 6 presents the case of a mobile consumer fetching data 403 simultaneously from two distinct sources, for instance local caches 404 behind each radio access. 406 tunnelled non-3GPP radio 407 (eg. WiFi) +-------+ N3 +-------+ N9 +-------+ N6 +-------+ 408 +---+ N3IWF +----| UL/CL +----+ UPF +----+ DN +----+ hICN 409 / +-------+ +-------+ +-------+ +-------+ 410 / 411 +---+---+ +-------+ N3 +-------+ N9 +---+---+ N6 +---+---+ 412 | UE +--+ gNB +----+ UL/CL +----+ UPF +----+ DN +----+ hICN 413 +-------+ +-------+ +---+---+ +-------+ +-------+ 415 Figure 6: Multi-source communication with hICN 417 *Con: Remaining IP anchors hinder producer mobility* 419 hICN-AMM MEC deployments are not suitable for handling producer 420 mobility effectively due to the presence of an anchor node in the 421 core at the N6 interface which traffic has to pass through. An 422 alternative would be to put in place dedicated control mechanisms to 423 update routers FIB following mobility events, but such coordination 424 between hICN forwarders would involve interaction with SMF. 426 *Con: Loss of 3GPP control plane* 428 More generally, traffic in between forwarders in the MEC will be out 429 of reach for the mobile core. At the time of this writing, MEC 430 interfaces are not well standardized; slicing and QoS functions will 431 only be available up to the breakout point. 433 3.2. hICN deployment as a UPF (option #1b) 435 The design of hICN makes it a good candidate for being deployed as a 436 UPF in NFV environments, for instance within a container (see 437 Figure 7. This solution has the advantage of preserving the 438 interface with the 3GPP control plane, including support for slicing 439 or QoS. 441 +------------------+ +------------------+ 442 | AMF | | SMF | 443 +-+--------------+-+ +-+--------------+-+ 444 | | | | 445 | N1 | N2 | N4 | N4 446 | | | | 447 +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ 448 | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | 449 +-------+ +-------+ +-------+ +-------+ +-------+ 450 ^ ^ 451 |________________| 452 hICN insertion 454 Figure 7 456 *Improved traffic engineering* 458 On-path deployments of hICN-AMM, as early as at the first UPF, bring 459 additional advantages in terms of opportunities to optimize traffic 460 engineering, including multipath and load balancing support. 462 As an example, one may consider hICN deployment at the PDU Session 463 Anchor, with dynamic congestion-aware and per-application control of 464 multiple downstream paths to the edge. 466 *Network-assisted transport* 468 hICN ability to provide in-network assistance for rate/loss/ 469 congestion control is an additional advantage, e.g. to support rate 470 adaptation in the case of dynamic adaptive streaming, or to improve 471 reliability of WiFi communications via local wireless detection and 472 recovery [WLDR]. 474 We illustrate the latter case in Figure 8, where an hICN UPF is 475 deployed as the first UPF following the WiFi access. hICN UPF can 476 exploit network buffers to realize loss detection and recovery of the 477 packet transiting on the unreliable radio access, thus offering 478 superior performance for WiFi traffic with respect to a traditional 479 end-to-end recovery approach. Such feature could be fundamental for 480 low-latency reliable services. 482 +-- Loss Detection and Recovey 483 V 484 +-------+ N3 +-------+ 485 +----+ N3IWF +----| hICN | 486 / +-------+ +---+---+ 487 / N9 | 488 +---+---+ +-------+ N3 +---+---+ N9 +---+---+ N6 +---+---+ 489 | UE +---+ gNB +----+ UPF +----+ UPF +----+ DN +---+ hICN 490 +-------+ +-------+ +---+---+ +-------+ +-------+ 492 Figure 8: In-network loss detection and recovery with hICN 494 *Producer mobility* 496 Option #1b is appropriate for handling producer mobility; however, it 497 would be supported through traditional DMM approaches for identifier- 498 based mobility. 500 3.3. Summary 502 This section has reviewed various insertion strategies for hICN, 503 including overlay deployments using local breakout to hICN instances 504 situated in MEC, or hICN forwarders deployed within an UPF. While 505 those approaches have the merit of allowing an easy or early 506 integration of hICN and exploiting some of its benefits, they do not 507 fully exploit purely ID-based capabilities nor the dynamic hICN 508 forwarding. 510 4. "Integrated" approaches: data-plane alternatives to GTP-U (option 511 #2) 513 The section describes more integrated hICN-AMM/3GPP 5G approaches 514 leveraging hICN capabilities in the mobile backhaul network in 515 alternative to GTP-U tunnels over N9 (and possibly N3) interface(s), 516 as shown in Figure 2 and Figure 3. 518 It is proposed to replace GTP tunnels at N9 and optionally at N3 519 interfaces by an hICN-enabled data plane operating on location- 520 independent identifiers advertised by the routing protocol and whose 521 forwarding information is stored/updated in routers' FIBs according 522 to the hICN-AMM approach. 524 We remind that an hICN data plane does not require the presence of a 525 mapping system nor the enablement of all routers, since hICN traffic 526 is transparently forwarded by regular hICN-unaware IP routers. 528 4.1. hICN insertion at N9 interface only (option #2a) 530 Option #2a answers the question of the ongoing 3GPP study of 531 alternative technologies for the N9 interface [TR.29.892-3GPP]. with 532 no impact on gNB as illustrated in Figure 9. The corresponding 533 protocol layering is shown in Figure 10 where we assume hICN- 534 enablement of the end-points (an alternative in-network hICN 535 enablement via proxies is possible but not considered by this 536 document). In the protocol layer, hICN is associated to IPv6 PDU 537 layer, transported over N9 directly over L2. 539 +------------------+ +------------------+ 540 | AMF | | SMF | 541 +-+--------------+-+ +-+--------------+-+ 542 | | | | 543 | N1 | N2 | N4 | N4 544 | | | | 545 +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ 546 | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | 547 +-------+ +-------+ +-------+ +-------+ +-------+ 548 ^ 549 | 550 hICN insertion 552 Figure 9: Replacement of N9 interface 554 UE 5G-AN N3 UPF N9 UPF N6 555 | | | 556 +--------+ | | | 557 | App. |--------------------------------------------------------| 558 +--------+ | | +--------+ | 559 | IP PDU | | | | IP PDU | | 560 | (hICN) |---------------------------------------------| (hICN) | | 561 +--------+ +-----------------+ | +-----------------+ | | | | 562 | | |\ relay /| | |\ decap / | | | | 563 | | | \_____________/ |-|-| \_____________/ | | | | 564 | | | | GTP-U | | | GTP-U | | | | | 565 | | | +--------+ | +--------+ | | | | 566 | 5G | | 5G | UDP |-|-| UDP | | | | | 567 | AN |-| AN +--------+ | +--------+ | | | | 568 |protocol| |protocol| IP |-|-| IP | | | | | 569 | layers | | layers +--------+ | +--------+--------+ | +--------+ | 570 | | | | L2 |-|-| L2 | L2 |-|-| L2 | | 571 | | | +--------+ | +--------+--------+ | +--------+ | 572 | | | | L1 |-|-| L1 | L1 |-|-| L1 | | 573 +--------+ +-----------------+ | +-----------------+ | +--------+ | 574 | | | 576 Figure 10: Replacement of N9 interface - Protocol layers 578 *Anchorless consumer and producer mobility* 580 Option #2a realizes a fully anchorless solution as the traffic does 581 not need to go up to the anchor point in the core, nor to depend on 582 the resolution performed by a mapping node. As illustrated in 583 Figure 11, communication between two UEs can take place by forwarding 584 traffic between their first UPFs, and thus avoids unnecessarily 585 overload of links up to the core. In this way option #2a provides an 586 effective traffic offloading and increased resiliency of network 587 operations in the event of a failure that would disconnect the edge 588 from the mobile core (e.g. disaster recovery scenario). 590 +---+---+ +---+---+ N3 +-------+ 591 | UE +------+ gNB +------+ UPF +------ ... 592 +-------+ +-------+ +---+---+ 593 | N9 hICN domain 594 +---+---+ +---+---+ N3 +-------+ 595 | UE +------+ gNB +------+ UPF +------ ... 596 +-------+ +-------+ +---+---+ 598 Figure 11: Offloading of inter-UE communications 600 *Low state and signaling overhead* 602 Unlike traditional 3GPP GTP-based mobility management, hICN-AMM does 603 not involve signaling/ additional state to be maintained to handle 604 static consumers/producers or mobile consumers. Forwarding updates 605 are required only in the event of producer mobility to guarantee 606 real-time re-direction of consumer requests without triggering 607 routing updates. 609 *Dynamic forwarding strategies / UPF selection* 611 Dynamic selection of next hop or exit point is simplified by hICN-AMM 612 as it can be performed locally based on names and/or name-based 613 locally available information (e.g. measurements of congestion status 614 or residual latency up to the first data source). 616 4.2. hICN deployment at both N9 and N3 interfaces (option #2b) 618 Option #2b proposes to additionally remove GTP tunnels between the 619 RAN and the first UPF (N3 interface). It is illustrated in Figure 12 620 and Figure 13. 622 +------------------+ +------------------+ 623 | AMF | | SMF | 624 +-+--------------+-+ +-+--------------+-+ 625 | | | | 626 | N1 | N2 | N4 | N4 627 | | | | 628 +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ 629 | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | 630 +-------+ +-------+ ^ +-------+ ^ +-------+ +-------+ 631 | | 632 | | 633 hICN insertion 635 Figure 12: Replacement of N3 and N9 interfaces 637 UE 5G-AN N3 UPF N9 UPF N6 638 | | | 639 +--------+ | | | 640 | App. |--------------------------------------------------------| 641 +--------+ | +--------+--------+ | +--------+ | 642 | IP PDU | | | IP PDU | IP PDU | | | IP PDU | | 643 | (hICN) |-----------------------| (hICN) | (hICN) |-|-| (hICN) | | 644 +--------+ +-----------------+ | | | | | | | | 645 | | |\ decap / | | | | | | | | 646 | | | \_____________/ | | | | | | | | 647 | | | | | | | | | | | | 648 | | | | | | | | | | | | 649 | 5G | | 5G | | | | | | | | | 650 | AN |-| AN | | | | | | | | | 651 |protocol| |protocol| | | | | | | | | 652 | layers | | layers +--------+ | +--------+--------+ | +--------+ | 653 | | | | L2 |-|-| L2 | L2 |-|-| L2 | | 654 | | | +--------+ | +--------+--------+ | +--------+ | 655 | | | | L1 |-|-| L1 | L1 |-|-| L1 | | 656 +--------+ +-----------------+ | +-----------------+ | +--------+ | 657 | | | 659 Figure 13: Replacement of N3 and N9 interfaces : Protocol layers 661 *Full tunnel removal; No internetworking between N3 and N9* 663 A clear advantage is the elimination of all GTP tunnels and a similar 664 specification of both N3 and N9 interfaces as recommended by 3GPP, so 665 removing challenges of inter-networking between N3 and N9. Also, it 666 leads to a flat and simpler architecture, allowing convergence with 667 other non-3GPP accesses (and related management and monitoring 668 tools). 670 *State and signaling reduction* 672 A direct consequence is the extension to N3 of the property of hICN- 673 AMM above described, namely the absence of signaling and additional 674 state to be maintained to handle static consumers/producers or mobile 675 consumers. 677 *Dynamic first UPF selection* 679 Dynamic forwarding capabilities are extended to the selection of the 680 first UPF, hence closer to the edge w.r.t. option #2a. 682 The advantage can be significant in the case of dense deployments 683 scenarios: here hICN-AMM makes possible to isolate the core network 684 from local edge mobility (a design objective of 5G mobile 685 architecture), while still permitting distributed selection of 686 ingress UPFs, and load-balancing of traffic across them. 688 4.3. Control plane considerations 690 By operating directly on router FIBs for mobility updates and for 691 dynamic policy-based forwarding strategies etc., hICN inherits the 692 simplicity of IP forwarding and can reuse legacy IP routing protocols 693 to advertise/route ID prefixes. In this way it remains compatible 694 with the exiting control plane architecture as proposed in the 3GPP 695 standard, with no change required to N1, N2 or N4. 697 hICN-AMM producer mobility management does not require SMF 698 interaction, but could be implemented by means of SMF signaling, at 699 the condition to follow the same procedure described for MAP-Me 700 protocol in hICN-AMM. In the analysis of pros and cons of SMF 701 interaction, it is worth noticing that the absence of SMF interaction 702 might be beneficial in case of dense deployments or of failure of the 703 central control entities (infrastructure-less communication 704 scenarios) to empower distributed control of local mobility within an 705 area. 707 5. Deployment considerations 709 The benefits previously described can be obtained by an upgrade of 710 only a few selected routers at the network edge. The design of hICN 711 allows the rest of the infrastructure to remain unmodified, and to 712 leverage existing management and monitoring tools. 714 5.1. hICN in a slice 716 The use of hICN does not impose any specific slicing of the network 717 as the architecture uses regular IPv6 packets, and is designed to 718 coexist with regular traffic. In that, hICN contrasts with previous 719 approaches integrating ICN in IP networks by using separate slices 720 and/or different PDU formats as reviewed in 721 [I-D.irtf-icnrg-deployment-guidelines]. 723 Although not required, slicing can ease a transition of services 724 towards hICN, and/or the coexistence of different mobility management 725 solutions with hICN-AMM or of different hICN deployment options. 727 An example use of slicing would be to create multiple slices for 728 optimizing the delivery of services having different requirements 729 such as a low-latency communication slice with hICN instances 730 deployed very close to the edge, and a video delivery service with 731 caches deployed in locations aggregating a sufficient number of users 732 to be effective. 734 5.2. End-to-end deployment 736 Deployment of the hICN stack in the endpoints is the preferred 737 insertion option and offers the full range of benefits. hICN client 738 and network stacks are available through two reference 739 implementations based on the CICN project [CICN]. They share the 740 objective of smooth deployment in existing devices, and are fully 741 user-space based. 743 The first one is built on top of existing IP primitives and proposed 744 as an application/library for all major OS vendors including iOS, 745 Android, Linux, macOS and Windows. The second one targets high- 746 performance routers and servers, and leverages the VPP technology 747 [VPP]. 749 5.3. Network-contained deployment 751 In case it is not possible to insert hICN stack at endpoints, an hICN 752 deployment fully contained in the network can be envisaged through 753 the deployment of proxies. An overview of different options 754 implemented at the network, transport or application level is 755 provided in [I-D.irtf-icnrg-deployment-guidelines]. An example would 756 be the deployment of HTTP (or RTP) proxies (as made available through 757 the CICN project) at the ingress and egress (resp. first and last 758 UPFs), in order to benefit from content awareness in the network. 759 Such configuration however reduces the flexibility and dynamic 760 forwarding capabilities in endpoints. In particular, existing 761 transport protocols have limited support for dynamically changing 762 paths/discovered sources or network conditions. 764 In such configuration, traffic that is not handled through hICN-AMM 765 mechanisms can still benefit from the lower overhead and anchorless 766 mobility capabilities coming from the removal of GTP tunnels, as well 767 as dynamic forwarding capabilities that are inherent to the 768 forwarding pipeline. This results from the ability to assign 769 location-independent identifiers to endpoints even without the 770 deployment of a full hICN stack. The advantages of removed 771 identifier/location mapping and of a lightweight FIB update process 772 are maintained. No encapsulation is required and packet headers are 773 not modified, which may allow the network to have visibility of the 774 source and/or destination identifiers. 776 5.4. Alternative data planes: joint hICN/SRv6 deployment 778 hICN is designed to operate inside an IPv6 network by means of an 779 enriched communication layer supporting ICN primitives. The targeted 780 deployment of a few hICN-empowered nodes leads to the tradeoff 781 between incremental deployment and benefits which are proportionally 782 related to the degree of hICN penetration. The association of hICN 783 with other data planes technologies is investigated as a possibility 784 to overcome the above-mentioned tradeoff yielding to a selective, yet 785 fully beneficial insertion of hICN in IP networks. 787 To this aim, we focus on hICN insertion in a Segment Routing (SR) 788 enhanced data plane, specifically considering SRv6 instantiation of 789 SR [I-D.ietf-spring-segment-routing]. 791 hICN/SRv6 combination inherits all SRv6 advantages presented in SR- 792 dedicated section of this document, namely "underlay" management 793 (fast reroute, etc.), service chaining or fine-grained TE, for 794 instance. 796 In addition, it allows extending the reach of hICN on regular IP 797 routers with SRv6 functionality. One realization being to create 798 SRv6 domains in between hICN nodes. The hICN router (through 799 forwarding strategies) would then act as a control plane for SRv6 by 800 specifying the list of SIDs to insert in the packet. 802 SRv6 forwarding of packets between hICN hops would permit to enforce 803 dynamic per-application hICN forwarding strategies and their 804 objectives (path steering, QoS, etc.), which would be otherwise not 805 possible over not hICN-enabled IP network segments. It would also 806 allow dynamic multi-path and load balancing in hICN-unaware IP 807 network segments and enforcing the symmetry of the request/reply path 808 for more accurate round trip delay measurements and rate/congestion 809 control). 811 6. Summary 813 hICN proposes a general purpose architecture that combines the 814 benefits of a pure-ID (name-based) architecture with those of ICN. 816 An hICN enabled network offers native offloading capabilities in 817 virtue of the anchorless properties resulting from the pure-ID 818 communication scheme. It does so without the need for a mapping 819 system, and further requires no change in the 5G architecture nor in 820 its control plane. The architecture will further leverage the 821 incremental insertion of Information-Centric functionalities through 822 proxies or direct insertion in user devices as the technology gets 823 adopted and deployed. 825 While a full deployment is recommended to make efficient use of 826 available network resources, it is still possible to opt for a 827 partial or phased deployment, with the associated tradeoffs that we 828 summarize in Figure 14. 830 This table reviews the various insertion options in the 3GPP 831 architecture earlier introduced - namely options #1a (MEC), #1b 832 (UPF), #2a (N9) and #2b (N9/N3) -, assuming endpoints are hICN- 833 enabled. Various levels of hICN penetration are then considered : 834 (UE) the UE is hICN-enabled, (proxy) hICN processing is available 835 through proxies, (None) no hICN function, the traffic is purely 836 forwarded using endpoint identifiers rather than content identifiers. 838 +-----------------------+------+ 839 hICN penetration: | UE | Proxy | None | 840 Benefit: Deployment option: | 1a 1b | 2a 2b | 2b | 2b | 841 +------------------------------------+-------+-------+-------+------+ 842 | Additional state for static cons. | Y Y | Y N | N | N | 843 | Additional state for static prod. | Y Y | Y N | N | N | 844 | Additional state for mobile cons. | Y Y | Y N | N | N | 845 | Additional state for mobile prod. | Y Y | Y N | N | N | 846 +------------------------------------+-------+-------+-------+------+ 847 | Signalization for static consumer | Y Y | N N | N | N | 848 | Signalization for static producer | Y Y | N N | N | N | 849 | Signalization for mobile consumer | Y Y | N N | N | N | 850 | Signalization for mobile producer | Y Y | Y Y | Y | Y | 851 +------------------------------------+-------+-------+-------+------+ 852 | Removed tunnel/encap overhead | N N | P Y | Y | Y | 853 | Preserve perf. of ongoing flows | N N | Y Y | Y | Y | 854 +------------------------------------+-------+-------+-------+------+ 855 | Local offload | P N | Y Y | Y | Y | 856 | Anchorless for UP | N N | Y Y | Y | Y | 857 | Anchorless for CP | N N | Y Y | Y | Y | 858 | Dynamic egress UPF selection | N N | Y Y | Y | Y | 859 | Dynamic ingress UPF selection | N N | N Y | Y | Y | 860 +------------------------------------+-------+-------+-------+------+ 861 | Edge caching : low-latency | Y Y | Y Y | P | N | 862 | Edge caching : multicast | Y Y | Y Y | P | N | 863 | Seamless mobility across het. RAT | Y Y | Y Y | Y | P | 864 | Multi-homing : bw aggregation | Y Y | Y Y | Y | P | 865 | Multi-source | Y Y | Y Y | Y | N | 866 | In-network assistance | N Y | Y Y | P | N | 867 +------------------------------------+-------+-------+-------+------+ 868 | Integration with 3GPP CP | N Y | Y Y | Y | Y | 869 +------------------------------------+-------+-------+-------+------+ 871 LEGEND: (Y) Yes - (N) No - (P) Partial 873 Figure 14 875 7. References 877 7.1. Normative References 879 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 880 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 881 "Information-Centric Networking: Baseline Scenarios", 882 RFC 7476, DOI 10.17487/RFC7476, March 2015, 883 . 885 7.2. Informative References 887 [CICN] io, Linux Foundation fd., "CICN project", 2018. 889 [I-D.auge-dmm-hicn-mobility] 890 Auge, J., Carofiglio, G., Muscariello, L., and M. 891 Papalini, "Anchorless mobility through hICN", Work in 892 Progress, Internet-Draft, draft-auge-dmm-hicn-mobility-03, 893 6 January 2020, . 896 [I-D.homma-dmm-5gs-id-loc-coexistence] 897 Homma, S., Kawakami, K., Akhavain, A., Rodriguez-Natal, 898 A., and R. Shekhar, "Co-existence of 3GPP 5GS and 899 Identifier-Locator Separation Architecture", Work in 900 Progress, Internet-Draft, draft-homma-dmm-5gs-id-loc- 901 coexistence-03, 23 April 2019, . 905 [I-D.ietf-spring-segment-routing] 906 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 907 Litkowski, S., and R. Shakir, "Segment Routing 908 Architecture", Work in Progress, Internet-Draft, draft- 909 ietf-spring-segment-routing-15, 25 January 2018, 910 . 913 [I-D.irtf-icnrg-deployment-guidelines] 914 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 915 "Deployment Considerations for Information-Centric 916 Networking (ICN)", Work in Progress, Internet-Draft, 917 draft-irtf-icnrg-deployment-guidelines-07, 3 September 918 2019, . 921 [I-D.muscariello-intarea-hicn] 922 Muscariello, L., Carofiglio, G., Auge, J., Papalini, M., 923 and M. Sardara, "Hybrid Information-Centric Networking", 924 Work in Progress, Internet-Draft, draft-muscariello- 925 intarea-hicn-04, 20 May 2020, . 928 [TR.29.892-3GPP] 929 3rd Generation Partnership Project (3GPP), "Study on User 930 Plane Protocol in 5GC, 3GPP TR 29.892 (study item)", 2017. 932 [TS.23.501-3GPP] 933 3rd Generation Partnership Project (3GPP), "System 934 Architecture for 5G System; Stage 2, 3GPP TS 23.501 935 v2.0.1", December 2017. 937 [VPP] io (Linux Foundation), FD., "Vector Packet Processing 938 (VPP)", url https://wiki.fd.io/view/VPP, n.d.. 940 [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 941 N., and X. Zeng, "Leveraging ICN In-network Control for 942 Loss Detection and Recovery in Wireless Mobile networks", 943 DOI 10.1145/2984356.2984361, Proceedings of the 2016 944 conference on 3rd ACM Conference on Information-Centric 945 Networking - ACM-ICN '16, 2016, 946 . 948 Authors' Addresses 950 Jordan Auge 951 Cisco Systems 952 11, rue Camille Desmoulins 953 92130 Issy-les-Moulineaux 954 France 956 Email: augjorda@cisco.com 958 Giovanna Carofiglio 959 Cisco Systems 960 11, rue Camille Desmoulins 961 92130 Issy-les-Moulineaux 962 France 964 Email: gcarofig@cisco.com 966 Luca Muscariello 967 Cisco Systems 968 11, rue Camille Desmoulins 969 92130 Issy-les-Moulineaux 970 France 972 Email: lumuscar@cisco.com 974 Michele Papalini 975 Cisco Systems 976 11, rue Camille Desmoulins 977 92130 Issy-les-Moulineaux 978 France 980 Email: micpapal@cisco.com