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