idnits 2.17.1 draft-irtf-icnrg-icn-lte-4g-07.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 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 (May 25, 2020) is 1432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-01 == Outdated reference: A later version (-04) exists of draft-ravi-icnrg-5gc-icn-02 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icnlowpan-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Prakash Suthar 3 Internet-Draft Milan Stolic 4 Intended status: Informational Anil Jangam, Ed. 5 Expires: November 26, 2020 Cisco Systems Inc. 6 Dirk Trossen 7 Huawei Technologies 8 Ravishankar Ravindran 9 Sterlite Technologies 10 May 25, 2020 12 Native Deployment of ICN in LTE, 4G Mobile Networks 13 draft-irtf-icnrg-icn-lte-4g-07 15 Abstract 17 LTE, 4G mobile networks use IP-based transport for control plane to 18 establish the data session and user plane for actual data delivery. 19 In existing architecture, IP transport used in the user plane is not 20 optimized for data transport, which leads to an inefficient data 21 delivery. IP unicast routing from server to clients is used for 22 delivery of multimedia content to User Equipment (UE), where each 23 user gets a separate stream. From a bandwidth and routing 24 perspective, this approach is inefficient. Multicast and broadcast 25 technologies have emerged recently for mobile networks, but their 26 deployments are very limited or at an experimental stage due to 27 complex architecture and radio spectrum issues. ICN is a rapidly 28 emerging technology with built-in features for efficient multimedia 29 data delivery. However much of the work is focused on fixed 30 networks. The focus of this draft is on native deployment of ICN in 31 cellular mobile networks by using ICN in a 3GPP protocol stack. ICN 32 has an inherent capability for multicast, anchorless mobility and 33 security, and it is optimized for data delivery using local caching 34 at the edge. The proposed approaches in this draft allow ICN to be 35 enabled natively over the current LTE stack comprising PDCP/RLC/MAC/ 36 PHY, or in a dual stack mode (along with IP). These approaches can 37 help optimize the mobile networks by leveraging the inherent benefits 38 of ICN. This document is a product of the Information-Centric 39 Networking Research Group (ICNRG). 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 November 26, 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. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 3 77 3. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . 7 78 3.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7 79 3.2. QoS Challenges . . . . . . . . . . . . . . . . . . . . . 9 80 3.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10 81 3.4. Virtualizing Mobile Networks . . . . . . . . . . . . . . 10 82 4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11 83 5. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 14 84 5.1. General ICN Deployment Considerations . . . . . . . . . . 14 85 5.2. ICN Deployment Scenarios . . . . . . . . . . . . . . . . 14 86 5.3. ICN Deployment in LTE Control Plane . . . . . . . . . . . 18 87 5.4. ICN Deployment in LTE User Plane . . . . . . . . . . . . 19 88 5.4.1. Dual stack ICN deployments in UE . . . . . . . . . . 20 89 5.4.2. Native ICN Deployments in UE . . . . . . . . . . . . 24 90 5.5. ICN Deployment in eNodeB . . . . . . . . . . . . . . . . 25 91 5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . 27 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 97 9.2. Informative References . . . . . . . . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 100 1. Introduction 102 LTE mobile technology is built as an all-IP network. It uses IP 103 routing protocols (OSPF, ISIS, BGP, etc.) to establish network routes 104 to route data traffic to the end user's device. Stickiness of an IP 105 address to a device is the key to get connected to a mobile network. 106 The same IP address is maintained through the session until the 107 device gets detached or moves to another network. 109 One of the key protocols used in 4G and LTE networks is GPRS 110 Tunneling protocol (GTP). GTP, DIAMETER and other protocols are 111 built on top of IP. One of the biggest challenges with IP-based 112 routing is that it is not optimized for data transport, although it 113 is the most efficient communication protocol. By native 114 implementation of Information Centric Networking (ICN) in 3GPP, we 115 can re-architect a mobile network and optimize its design for 116 efficient data transport by leveraging ICN's caching feature. ICN 117 also offers an opportunity to leverage inherent capabilities of 118 multicast, anchorless mobility management, and authentication. This 119 draft proposes options for deploying ICN in mobile networks, and how 120 they affect mobile providers and end users. 122 This document represents the consensus of the Information-Centric 123 Networking Research Group (ICNRG). It has been reviewed extensively 124 by the Research Group (RG) members active in the specific areas of 125 work covered by the document. 127 2. 3GPP Terminology and Concepts 129 1. Access Point Name 131 The Access Point Name (APN) is a Fully Qualified Domain Name 132 (FQDN) and resolves to a set of gateways in an operator's 133 network. APN identifies the packet data network (PDN) with 134 which a mobile data user wants to communicate. In addition to 135 identifying a PDN, an APN may also be used to define the type of 136 service, QoS, and other logical entities inside GGSN, PGW. 138 2. Control Plane 140 The control plane carries signaling traffic and is responsible 141 for routing between eNodeB and MME, MME and HSS, MME and SGW, 142 SGW and PGW, etc. Control plane signaling is required to 143 authenticate and authorize UE and establish a mobility session 144 with mobile gateways (SGW/PGW). Control plane functions also 145 include system configuration and management. 147 3. Dual Address PDN/PDP Type 149 The dual address Packet Data Network/Packet Data Protocol (PDN/ 150 PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a 151 synonym for dual stack; i.e., a connection type capable of 152 serving IPv4 and IPv6 simultaneously. 154 4. eNodeB 156 The eNodeB is a base station entity that supports the Long-Term 157 Evolution (LTE) air interface. 159 5. Evolved Packet Core 161 The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS 162 system characterized by a higher-data-rate, lower-latency, 163 packet-optimized system. The EPC comprises some sub components 164 of the EPS core such as Mobility Management Entity (MME), 165 Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and 166 Home Subscriber Server (HSS). 168 6. Evolved Packet System 170 The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS 171 system characterized by a higher-data-rate, lower-latency, 172 packet-optimized system that supports multiple Radio Access 173 Technologies (RATs). The EPS comprises the EPC together with 174 the Evolved Universal Terrestrial Radio Access (E-UTRA) and the 175 Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 177 7. Evolved UTRAN 179 The E-UTRAN is a communications network sometimes referred to as 180 4G, and consists of eNodeB (4G base stations). The E-UTRAN 181 allows connectivity between the User Equipment and the core 182 network. 184 8. GPRS Tunneling Protocol 186 The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] 187 [TS29.281] is a tunneling protocol defined by 3GPP. It is a 188 network-based mobility protocol and is like Proxy Mobile IPv6 189 (PMIPv6). However, GTP also provides functionality beyond 190 mobility, such as in-band signaling related to QoS and charging, 191 among others. 193 9. Gateway GPRS Support Node 195 The Gateway GPRS Support Node (GGSN) is a gateway function in 196 the GPRS and 3G network that provides connectivity to the 197 Internet or other PDNs. The host attaches to a GGSN identified 198 by an APN assigned to it by an operator. The GGSN also serves 199 as the topological anchor for addresses/prefixes assigned to the 200 User Equipment. 202 10. General Packet Radio Service 204 The General Packet Radio Service (GPRS) is a packet-oriented 205 mobile data service available to users of the 2G and 3G cellular 206 communication systems--the GSM--specified by 3GPP. 208 11. Home Subscriber Server 210 The Home Subscriber Server (HSS) is a database for a given 211 subscriber and was introduced in 3GPP Release-5. It is the 212 entity containing subscription-related information to support 213 the network entities that handle calls/sessions. 215 12. Mobility Management Entity 217 The Mobility Management Entity (MME) is a network element 218 responsible for control-plane functionalities, including 219 authentication, authorization, bearer management, layer-2 220 mobility, and so on. The MME is essentially the control-plane 221 part of the SGSN in the GPRS. The user-plane traffic bypasses 222 the MME. 224 13. Public Land Mobile Network 226 The Public Land Mobile Network (PLMN) is a network operated by a 227 single administration. A PLMN (and, therefore, also an 228 operator) is identified by the Mobile Country Code (MCC) and the 229 Mobile Network Code (MNC). Each (telecommunications) operator 230 providing mobile services has its own PLMN. 232 14. Policy and Charging Control 234 The Policy and Charging Control (PCC) framework is used for QoS 235 policy and charging control. It has two main functions: flow- 236 based charging (including online credit control), and policy 237 control (for example, gating control, QoS control, and QoS 238 signaling). It is optional to 3GPP EPS but needed if dynamic 239 policy and charging control by means of PCC rules based on user 240 and services are desired. 242 15. Packet Data Network 244 The Packet Data Network (PDN) is a packet-based network that 245 either belongs to the operator or is an external network such as 246 the Internet or a corporate intranet. The user eventually 247 accesses services in one or more PDNs. The operator's packet 248 core networks are separated from packet data networks either by 249 GGSNs or PDN Gateways (PGWs). 251 16. Serving Gateway 253 The Serving Gateway (SGW) is a gateway function in the EPS, 254 which terminates the interface towards the E-UTRAN. The SGW is 255 the Mobility Anchor point for layer-2 mobility (inter-eNodeB 256 handovers). For each UE connected with the EPS, there is only 257 one SGW at any given point in time. The SGW is essentially the 258 user-plane part of the GPRS's SGSN. 260 17. Packet Data Network Gateway 262 The Packet Data Network Gateway (PGW) is a gateway function in 263 the Evolved Packet System (EPS), which provides connectivity to 264 the Internet or other PDNs. The host attaches to a PGW 265 identified by an APN assigned to it by an operator. The PGW 266 also serves as the topological anchor for addresses/prefixes 267 assigned to the User Equipment. 269 18. Packet Data Protocol Context 271 A Packet Data Protocol (PDP) context is the equivalent of a 272 virtual connection between the User Equipment (UE) and a PDN 273 using a specific gateway. 275 19. Packet Data Protocol Type 277 A Packet Data Protocol Type (PDP Type) identifies the used/ 278 allowed protocols within the PDP context. Examples are IPv4, 279 IPv6, and IPv4v6 (dual-stack). 281 20. Serving GPRS Support Node 283 The Serving GPRS Support Node (SGSN) is a network element 284 located between the radio access network (RAN) and the gateway 285 (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN 286 and SGSN transports the packets between the UE and the gateway. 288 21. Terminal Equipment 289 The Terminal Equipment (TE) is any device/host connected to the 290 Mobile Terminal (MT) offering services to the user. A TE may 291 communicate to an MT, for example, over the Point-to-Point 292 Protocol (PPP). 294 22. UE, MS, MN, and Mobile 296 The terms User Equipment (UE), Mobile Station (MS), Mobile Node 297 (MN), and mobile refer to the devices that are hosts with the 298 ability to obtain Internet connectivity via a 3GPP network. An 299 MS comprises the Terminal Equipment (TE) and a Mobile Terminal 300 (MT). The terms UE, MS, MN, and mobile are used interchangeably 301 within this document. 303 23. User Plane 305 The user plane refers to data traffic and the required bearers 306 for the data traffic. In practice, IP is the only data traffic 307 protocol used in the user plane. 309 3. LTE, 4G Mobile Network 311 3.1. Network Overview 313 With the introduction of LTE, mobile networks moved to all-IP 314 transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, 315 routing and switching, etc. Although LTE network is data-centric, it 316 has support for legacy Circuit Switch features such as voice and SMS 317 through transitional CS fallback and flexible IMS deployment 318 [GRAYSON]. For each mobile device attached to the radio (eNodeB), 319 there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) 320 between eNodeB and Mobile gateways (i.e., SGW, PGW). 322 The GTP tunnel is used to carry user traffic between gateways and 323 mobile devices. This forces data to be distributed only by using 324 unicast mechanism. It is also important to understand the overhead 325 of a GTP and IPSec protocols because it has impact on the carried 326 user data traffic. All mobile backhaul traffic is encapsulated using 327 GTP tunnel, which has overhead of 8 bytes on top of IP and UDP 328 [NGMN]. Additionally, if IPSec is used for security (which is often 329 required if the Service Provider is using a shared backhaul), it adds 330 overhead based on the IPSec tunneling model (tunnel or transport), 331 and the encryption and authentication header algorithm used. If we 332 factor Advanced Encryption Standard (AES) encryption with the packet 333 size, the overhead can be significant [OLTEANU], particularly for the 334 smaller payloads. 336 When any UE is powered up, it attaches to a mobile network based on 337 its configuration and subscription. After a successful attach 338 procedure, UE registers with the mobile core network, and an IPv4 339 and/or IPv6 address is assigned. A default bearer is created for 340 each UE and it is assigned to default Access Point Name (APN). 342 +-------+ Diameter +-------+ 343 | HSS |------------| SPR | 344 +-------+ +-------+ 345 | | 346 +------+ +------+ S4 | +-------+ 347 | 3G |---| SGSN |----------------|------+ +------| PCRF | 348 ^ |NodeB | | |---------+ +---+ | | +-------+ 349 +-+ | +------+ +------+ S3 | | S6a | |Gxc | 350 | | | +-------+ | | |Gx 351 +-+ | +------------------| MME |------+ | | | 352 UE v | S1MME +-------+ S11 | | | | 353 +----+-+ +-------+ +-------+ 354 |4G/LTE|------------------------------| SGW |-----| PGW | 355 |eNodeB| S1U +-------+ +--| | 356 +------+ | +-------+ 357 +---------------------+ | | 358 S1U GTP Tunnel traffic | +-------+ | | 359 S2a GRE Tunnel traffic |S2A | ePDG |-------+ | 360 S2b GRE Tunnel traffic | +-------+ S2B |SGi 361 SGi IP traffic | | | 362 +---------+ +---------+ +-----+ 363 | Trusted | |Untrusted| | CDN | 364 |non-3GPP | |non-3GPP | +-----+ 365 +---------+ +---------+ 366 | | 367 +-+ +-+ 368 | | | | 369 +-+ +-+ 370 UE UE 372 Figure 1: LTE, 4G Mobile Network Overview 374 The data delivered to mobile devices is unicast inside the GTP 375 tunnel. If we consider the combined impact of GTP, IPSec and unicast 376 traffic, the data delivery is not efficient. IETF has developed 377 various header compression algorithms to reduce overhead associated 378 with IP packets. Some techniques are robust header compression 379 (ROHC) and enhanced compression of the real-time transport protocol 380 (ECRTP) so that impact of overhead created by GTP, IPsec, etc., is 381 reduced to some extent [BROWER]. For commercial mobile networks, 382 3GPP has adopted different mechanisms for header compression to 383 achieve efficiency in data delivery [TS25.323], and can be adapted to 384 ICN, as well [ICNLOWPAN] [TLVCOMP]. 386 3.2. QoS Challenges 388 During the attach procedure, a default bearer is created for each UE 389 and it is assigned to the default Access Point Name (APN). The QoS 390 values that uplink and downlink bandwidth assigned during the initial 391 attach are minimal. Additional dedicated bearer(s) with enhanced QoS 392 parameters are established depending on specific application needs. 394 While all traffic within a certain bearer gets the same treatment, 395 QoS parameters supporting these requirements can be very granular in 396 different bearers. These values vary for the control, management and 397 user traffic, and can be very different depending on application key 398 parameters such as latency, jitter (important for voice and other 399 real-time applications), packet loss, and queuing mechanism (strict 400 priority, low-latency, fair, and so on). 402 Implementation of QoS for mobile networks is done at two stages: at 403 content prioritization/marking and transport marking, and congestion 404 management. From the transport perspective, QoS is defined at layer 405 2 as class of service (CoS) and at layer 3 either as DiffServ code 406 point (DSCP) or type of service (ToS). The mapping of DSCP to CoS 407 takes place at layer 2/3 switching and routing elements. 3GPP has a 408 specified QoS Class Identifier (QCI), which represents different 409 types of content and equivalent mapping to DSCP at transport layer 410 [TS23.401]. However, this requires manual configuration at different 411 elements and, if there are misconfigurations at any place in the 412 path, it will not work properly. 414 In summary, QoS configuration for mobile networks for user plane (for 415 user traffic) and transport in an IP-based mobile network is complex 416 requires synchronization of parameters among different platforms. 417 Normally, QoS in IP is implemented using DiffServ, which uses hop-by- 418 hop QoS configuration at each router. Any inconsistency in IP QoS 419 configuration at routers in the forwarding path can result in a poor 420 subscriber experience (e.g., packet classified as high-priority can 421 go to a lower priority queue). By deploying ICN, we intend to 422 enhance the subscriber experience using policy-based configuration, 423 which can be associated with the named contents [ICNQoS] at the ICN 424 forwarder. Further investigation is needed to understand how QoS in 425 ICN can be implemented to meet the IP QoS requirements [RFC4594]. 427 Research papers published so far explore the possibility of 428 classifications based on name prefixes (thus addressing the problem 429 of IP QoS not being information aware), or on popularity or placement 430 (looking at a distance of a content from a requester). However, 431 focus of these research efforts is on faster routing of Interest 432 requests towards the content rather than content delivery. 434 3.3. Data Transport Using IP 436 The data delivered to mobile devices is unicast inside GTP tunnel 437 from an eNodeB to a PDN gateway (PGW), as described in 3GPP 438 specifications [TS23.401]. While the technology exists to address 439 the issue of possible multicast delivery, there are many difficulties 440 related to multicast protocol implementation on the RAN side of the 441 network. Transport networks in the backhaul and core addressed the 442 multicast delivery long ago and have implemented it in most cases in 443 their multi-purpose integrated transport. But the RAN part of the 444 network is still lagging behind due to complexities related to client 445 mobility, handovers, and the fact that the potential gain to Service 446 Providers may not justify the investment. With that said, the data 447 delivery in the mobility remains greatly unicast. Techniques to 448 handle multicast (such as LTE-B or eMBMS) have been designed to 449 handle pre-planned content delivery, such as live content, which 450 contrasts user behavior today, largely based on content (or video) on 451 demand model. 453 To ease the burden on the bandwidth of the SGi interface, caching is 454 introduced in a similar manner as with many Enterprises. In the 455 mobile networks, whenever possible, cached data is delivered. 456 Caching servers are placed at a centralized location, typically in 457 the Service Provider's Data Center, or in some cases lightly 458 distributed in Packet Core locations with the PGW nodes close to the 459 Internet and IP services access (SGi interface). This is a very 460 inefficient concept because traffic must traverse the entire backhaul 461 path for the data to be delivered to the end user. Other issues, 462 such as out-of-order delivery, contribute to this complexity and 463 inefficiency, which needs to be addressed at the application level. 465 Data delivered to mobile devices is unicast inside a GTP tunnel. If 466 we consider the combined impact of GTP, IPSec, and unicast traffic, 467 the end-to-end data delivery is not efficient. By deploying ICN, we 468 intend to either terminate the GTP tunnel at the mobility anchoring 469 point by leveraging control and user-plane separation, or replace it 470 with native ICN protocols. 472 3.4. Virtualizing Mobile Networks 474 The Mobile packet core deployed in a major Service Provider network 475 is either based on dedicated hardware or, in some cases, large 476 capacity x86 platforms. With adoption of Mobile Virtual Network 477 Operators (MVNO), public safety network, and enterprise mobility 478 network, we need elastic mobile core architecture. By deploying 479 mobile packet core on a commercially off-the-shelf (COTS) platform 480 using virtualized infrastructure (NFVI) framework and end-to-end 481 orchestration, we can simplify new deployments and provide optimized 482 TCO. 484 While virtualization is growing, and many mobile providers use hybrid 485 architecture consisting of dedicated and virtualized infrastructures, 486 the control and data delivery planes are still the same. There is 487 also work under way to separate the control plane and user plane so 488 the network can scale better. Virtualized mobile networks and 489 network slicing with control and user plane separation provide 490 mechanism to evolve GTP-based architecture to open-flow SDN-based 491 signaling for LTE and proposed 5G core. Some early architecture work 492 for 5G mobile technologies provides a mechanism for control and user 493 plane separation and simplifies mobility call flow by introduction of 494 open-flow-based signaling [ICN5G]. This has been considered by 3GPP 495 [EPCCUPS] and is also described in [SDN5G]. 497 4. Data Transport Using ICN 499 For mobile devices, the edge connectivity to the network is between 500 radio and a router or mobile edge computing (MEC) [MECSPEC] element. 501 MEC has the capability of processing client requests and segregating 502 control and user traffic at the edge of radio, rather than sending 503 all requests to the mobile gateway. 505 +----------+ 506 | Content +----------------------------------------+ 507 | Publisher| | 508 +---+---+--+ | 509 | | +--+ +--+ +--+ | 510 | +--->|R1|------------>|R2|---------->|R4| | 511 | +--+ +--+ +--+ | 512 | | Cached | 513 | v content | 514 | +--+ at R3 | 515 | +========|R3|---+ | 516 | # +--+ | | 517 | # | | 518 | v v | 519 | +-+ +-+ | 520 +---------------| |-------------| |-------------+ 521 +-+ +-+ 522 Consumer-1 Consumer-2 523 UE UE 525 ===> Content flow from cache 526 ---> Content flow from publisher 528 Figure 2: ICN Architecture 530 MEC transforms radio into an intelligent service edge capable of 531 delivering services directly from the edge of the network, while 532 providing the best possible performance to the client. MEC can be an 533 ideal candidate for ICN forwarder in addition to its usual function 534 of managing mobile termination. In addition to MEC, other transport 535 elements, such as routers, can work as ICN forwarders. 537 Data transport using ICN is different compared to IP-based transport. 538 It evolves the Internet infrastructure by introducing uniquely named 539 data as a core Internet principle. Communication in ICN takes place 540 between the content provider (producer) and the end user (consumer), 541 as described in Figure 2. 543 Every node in a physical path between a client and a content provider 544 is called the ICN forwarder or router. It can route the request 545 intelligently and to cache the content so it can be delivered locally 546 for subsequent request from any other client. For mobile network, 547 transport between a client and a content provider consists of radio 548 network + mobile backhaul and IP core transport + Mobile Gateways + 549 Internet + content data network (CDN). 551 To understand the suitability of ICN for mobile networks, we will 552 discuss the ICN framework describing protocols architecture and 553 different types of messages, and then consider how we can use this in 554 a mobile network for delivering content more efficiently. ICN uses 555 two types of packets called "interest packet" and "data packet" as 556 described in Figure 3. 558 +------------------------------------+ 559 Interest | +------+ +------+ +------+ | +-----+ 560 +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | 561 | | | +------+ +------+ +------+ | +-----+ 562 +-+ | | Add | Drop | | Forward 563 UE <--------+ Intf v Nack v | 564 Data | | 565 +------------------------------------+ 567 +------------------------------------+ 568 +-+ | Forward +------+ | +-----+ 569 | | <-------------------------------------| PIT |<---------| CDN | 570 +-+ | | Cache +--+---+ | Data +-----+ 571 UE | +--v---+ | | 572 | | CS | v | 573 | +------+ Discard | 574 +------------------------------------+ 576 Figure 3: ICN Interest, Data Packet and Forwarder 578 In an LTE network, when a mobile device wants to get certain content, 579 it will send an Interest message to the closest eNodeB. Interest 580 packet follows the TLV format [RFC8609] and contains mandatory fields 581 such as name of the content and content matching restrictions 582 (KeyIdRestr and ContentObjectHashRestr) forming the tuple [RFC8569]. 583 The content matching tuple uniquely identifies the matching data 584 packet for the given Interest packet. Another attribute called 585 HopLimit is used to detect looping Interest messages. 587 An ICN router will receive an Interest packet and perform lookup if a 588 request for such content has come earlier from another client. If 589 yes, it is served from the local cache; otherwise, the request is 590 forwarded to the next-hop ICN router. Each ICN router maintains 591 three data structures: Pending Interest Table (PIT), Forwarding 592 Information Base (FIB), and Content Store (CS). The Interest packet 593 travels hop-by-hop towards the content provider. Once the Interest 594 reaches the content provider, it will return a Data packet containing 595 information such as content name, signature, and data. 597 Data packet travels in reverse direction following the same path 598 taken by the Interest packet, which maintains routing symmetry. 599 Details about algorithms used in PIT, FIB, CS, and security trust 600 models are described in various resources [CCN]; here, we have 601 explained the concept and its applicability to the LTE network. 603 5. ICN Deployment in 4G and LTE Networks 605 5.1. General ICN Deployment Considerations 607 In LTE/4G mobile networks, both user and control plane traffic have 608 to be transported from the edge to the mobile packet core via IP 609 transport. The evolution of existing mobile packet core using 610 Control and User Plane Separation (CUPS) [TS23.714] enables flexible 611 network deployment and operation, by distributed deployment and the 612 independent scaling between control plane and user plane functions - 613 while not affecting the functionality of existing nodes subject to 614 this split. 616 In the CUPS architecture, there is an opportunity to shorten the path 617 for user plane traffic by deploying offload nodes closer to the edge 618 [OFFLOAD]. With this major architecture change, a User Plane 619 Function (UPF) node is placed close to the edge so traffic no longer 620 needs to traverse the entire backhaul path to reach the EPC. In many 621 cases, where feasible, UPF can be collocated with the eNodeB, which 622 is also a business decision based on user demand. Placing a 623 Publisher close to the offload site, or at the offload site, provides 624 for a significant improvement in user experience, especially with 625 latency-sensitive applications. This optimization allows for the 626 introduction of ICN and amplifies its advantages. This section 627 analyzes the potential impact of ICN on control and user plane 628 traffic for centralized and disaggregate CUPS-based mobile network 629 architecture. 631 5.2. ICN Deployment Scenarios 633 Deployment of ICN provides an opportunity to further optimize the 634 existing data transport in LTE/4G mobile networks. The various 635 deployment options that ICN and IP provide are somewhat analogous to 636 the deployment scenarios when IPv6 was introduced to interoperate 637 with IPv4 except, with ICN, the whole IP stack is being replaced. We 638 have reviewed [RFC6459] and analyzed the impact of ICN on control 639 plane signaling and user plane data delivery. In general, ICN can be 640 deployed by natively replacing IP transport (IPv4 and IPv6) or as an 641 overlay protocol. Figure 4 describes a modified protocol stack to 642 support ICN deployment scenarios. 644 +----------------+ +-----------------+ 645 | ICN App (new) | |IP App (existing)| 646 +---------+------+ +-------+---------+ 647 | | 648 +---------+----------------+---------+ 649 | Transport Convergence Layer (new) | 650 +------+---------------------+-------+ 651 | | 652 +------+------+ +------+-------+ 653 |ICN function | | IP function | 654 | (New) | | (Existing) | 655 +------+------+ +------+-------+ 656 | | 657 (```). (```). 658 ( ICN '`. ( IP '`. 659 ( Cloud ) ( Cloud ) 660 ` __..'+' ` __..'+' 662 Figure 4: IP/ICN Convergence and Deployment Scenarios 664 As shown in Figure 4, for applications running either in UE or in 665 content provider system to use the new transport option, we propose a 666 new transport convergence layer (TCL). This transport convergence 667 layer helps determine the type of transport (such as ICN or IP), as 668 well as the type of radio interface (LTE or WiFi or both) used to 669 send and receive traffic based on preference (e.g., content location, 670 content type, content publisher, congestion, cost, QoS). It helps 671 configure and determine the type of connection, as well as the 672 overlay mode (ICNoIP or IPoICN) between application and the protocol 673 stack (IP or ICN), to be used. 675 Combined with the existing IP function, the ICN function provides 676 support for either native ICN and/or the dual stack (ICN/IP) 677 transport functionality. See Section 5.4.1 for elaborate 678 descriptions of these functional layers. 680 The TCL can use several mechanisms for transport selection . It can 681 use a per-application configuration through a management interface, 682 possibly even a user-facing setting realized through a user 683 interface, like those used today that select cellular over WiFi being 684 used for selected applications. In another option, it might use a 685 software API, which an adapted IP application could use to specify 686 (such as an ICN transport) for obtaining its benefits. 688 Another potential application of TCL is in implementation of network 689 slicing, where it can have a slice management capability locally or 690 it can interface to an external slice manager through an API [GALIS]. 692 This solution can enable network slicing for IP and ICN transport 693 selection from the UE itself. The TCL could apply slice settings to 694 direct certain traffic (or applications) over one slice and others 695 over another slice, determined by some form of 'slicing policy'. 696 Slicing policy can be obtained externally from the slice manager or 697 configured locally on UE. 699 From the perspective of applications either on UE or a content 700 provider, the following options are possible for ICN deployment 701 natively and/or with IP. 703 1. IP over IP 705 In this scenario, UE uses applications tightly integrated with 706 the existing IP transport infrastructure. In this option, the 707 TCL has no additional function because packets are forwarded 708 directly using an IP protocol stack, which sends packets over the 709 IP transport. 711 2. ICN over ICN 713 Similar to case 1, ICN applications integrate tightly with the 714 ICN transport infrastructure. The TCL has no additional 715 responsibility because packets are forwarded directly using ICN 716 protocol stack, which sends packets over the ICN transport. 718 3. ICN over IP (ICNoIP) 720 In this scenario, the underlying IP transport infrastructure is 721 not impacted (that is, ICN is implemented as an IP overlay 722 between user equipment (UE) and content provider). IP routing is 723 used from Radio Access Network (eNodeB) to mobile backhaul, IP 724 core, and Mobile Gateway (SGW/PGW). UE attaches to Mobile 725 Gateway (SGW/PGW) using IP address. Also, the data transport 726 between Mobile Gateway (SGW/PGW) and content publisher uses IP. 727 Content provider can serve content either using IP or ICN, based 728 on the UE request. 730 An approach to implement ICN in mobile backhaul networks is 731 described in [MBICN]. It implements a GTP-U extension header 732 option to encapsulate ICN payload in GTP tunnel. However, as 733 this design runs ICN as an IP overlay, the mobile backhaul can be 734 deployed using native IP. The proposal describes a mechanism 735 where GTP-U tunnel can be terminated by hairpinning the packet 736 before it reaches SGW, if an ICN-enabled node is deployed in the 737 mobile backhaul (that is, between eNodeB and SGW). This could be 738 useful when an ICN data packet is stored in the ICN node (such as 739 repos, caches) in the tunnel path; it can reply right away 740 without going all the way through the mobile core. While GTP-U 741 extension header is used to carry UE specific ICN payload, they 742 are not visible to the transport, including SGW. On the other 743 hand, the PGW can use the UE-specific ICN header extension and 744 ICN payload to set up an uplink transport towards content 745 provider in the Internet. In addition, the design assumes a 746 proxy function at the edge, to perform ICN data retrieval on 747 behalf of a non-ICN end device. 749 4. IP over ICN (IPoICN) 751 H2020 project [H2020] provides an architectural framework for 752 deployment of IP as an overlay over ICN protocol [IPoICN]. 753 Implementing IP services over ICN provides an opportunity 754 leveraging benefit of ICN in the transport infrastructure and 755 there is no impact on end devices (UE and access network) as they 756 continue to use IP. IPoICN however, will require an inter- 757 working function (IWF/Border Gateway) to translate various 758 transport primitives. The IWF function will provide a mechanism 759 for protocol translation between IPoICN and native IP deployment 760 for mobile network. After reviewing [IPoICN], we understand and 761 interpret that ICN is implemented in the transport natively; 762 however, IP is implemented in UE, eNodeB, and Mobile gateway 763 (SGW/PGW), which is also called as a network attach point (NAP). 765 For this, said NAP receives an incoming IP or HTTP packet (the 766 latter through TCP connection termination) and publishes the 767 packet under a suitable ICN name (i.e., the hash over the 768 destination IP address for an IP packet or the hash over the FQDN 769 of the HTTP request for an HTTP packet) to the ICN network. In 770 the HTTP case, the NAP maintains a pending request mapping table 771 to map returning responses to the terminated TCP connection. 773 5. Hybrid ICN (hICN) 775 An alternative approach to implement ICN over IP is provided in 776 Hybrid ICN [HICN]. It describes a novel approach to integrate 777 ICN into IPv6 without creating overlays with a new packet format 778 as an encapsulation. hICN addresses the content by encoding a 779 location-independent name in an IPv6 address. It uses two name 780 components--name prefix and name suffix--that identify the source 781 of data and the data segment within the scope of the name prefix, 782 respectively. 784 At application layer, hICN maps the name into an IPv6 prefix and, 785 thus, uses IP as transport. As long as the name prefixes, which 786 are routable IP prefixes, point towards a mobile GW (PGW or local 787 breakout, such as CUPS), there are potentially no updates 788 required to any of the mobile core gateways (for example, SGW/ 789 PGW). The IPv6 backhaul routes the packets within the mobile 790 core. hICN can run in the UE, in the eNodeB, in the mobile 791 backhaul, or in the mobile core. Finally, as hICN itself uses 792 IPv6, it cannot be considered as an alternative transport layer. 794 5.3. ICN Deployment in LTE Control Plane 796 In this section, we analyze signaling messages that are required for 797 different procedures, such as attach, handover, tracking area update, 798 and so on. The goal of this analysis is to see if there are any 799 benefits to replacing IP-based protocols with ICN for LTE signaling 800 in the current architecture. It is important to understand the 801 concept of point of attachment (POA). When UE connects to a network, 802 it has the following POAs: 804 1. eNodeB managing location or physical POA 806 2. Authentication and Authorization (MME, HSS) managing identity or 807 authentication POA 809 3. Mobile Gateways (SGW, PGW) managing logical or session management 810 POA 812 In the current architecture, IP transport is used for all messages 813 associated with the control plane for mobility and session 814 management. IP is embedded very deeply into these messages and TLV, 815 carrying additional attributes such as a layer 3 transport. Physical 816 POA in eNodeB handles both mobility and session management for any UE 817 attached to 4G, LTE network. The number of mobility management 818 messages between different nodes in an LTE network per signaling 819 procedure are shown in Table 1. 821 Normally, two types of UE devices attach to the LTE network: SIM 822 based (need 3GPP mobility protocol for authentication) or non-SIM 823 based (which connect to WiFi network). Both device types require 824 authentication . For non-SIM based devices, AAA is used for 825 authentication. We do not propose to change UE authentication or 826 mobility management messaging for user data transport using ICN. A 827 separate study would be required to analyze the impact of ICN on 828 mobility management messages structures and flows. We are merely 829 analyzing the viability of implementing ICN as a transport for 830 control plane messages. 832 It is important to note that, if MME and HSS do not support ICN 833 transport, they still need to support UE capable of dual stack or 834 native ICN. When UE initiates an attach request using the identity 835 as ICN, MME must be able to parse that message and create a session. 837 MME forwards UE authentication to HSS, so HSS must be able to 838 authenticate an ICN-capable UE and authorize create session 839 [TS23.401]. 841 +---------------------------+-----+-----+-----+-----+------+ 842 | LTE Signaling Procedures | MME | HSS | SGW | PGW | PCRF | 843 +---------------------------+-----+-----+-----+-----+------+ 844 | Attach | 10 | 2 | 3 | 2 | 1 | 845 | Additional default bearer | 4 | 0 | 3 | 2 | 1 | 846 | Dedicated bearer | 2 | 0 | 2 | 2 | 0 | 847 | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | 848 | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | 849 | X2 handover | 2 | 0 | 1 | 0 | 0 | 850 | S1 handover | 8 | 0 | 3 | 0 | 0 | 851 | Tracking area update | 2 | 2 | 0 | 0 | 0 | 852 | Total | 34 | 2 | 14 | 6 | 3 | 853 +---------------------------+-----+-----+-----+-----+------+ 855 Table 1: Signaling Messages in LTE Gateways 857 Anchorless mobility [ALM] provides a fully decentralized, control- 858 plane agnostic solution to handle producer mobility in ICN. Mobility 859 management at layer-3 level makes it access agnostic and transparent 860 to the end device or the application. The solution discusses 861 handling mobility without having to depend on core network functions 862 (e.g. MME); however, a location update to the core network may still 863 be required to support legal compliance requirements such as lawful 864 intercept and emergency services. These aspects are open for further 865 study. 867 One of the advantages of ICN is in the caching and reusing of the 868 content, which does not apply to the transactional signaling 869 exchange. After analyzing LTE signaling call flows [TS23.401] and 870 messages inter-dependencies (see Table 1), our recommendation is that 871 it is not beneficial to deploy ICN for control plane and mobility 872 management functions. Among the features of ICN design, Interest 873 aggregation and content caching are not applicable to control plane 874 signaling messages. Control plane messages are originated and 875 consumed by the applications and they cannot be shared. 877 5.4. ICN Deployment in LTE User Plane 879 We will consider Figure 1 to discuss different mechanisms to deploy 880 ICN in mobile networks. In Section 5.2, we discussed generic 881 deployment scenarios of ICN. In this section, we discuss the 882 specific use cases of native ICN deployment in LTE user plane. We 883 consider the following options: 885 1. Dual stack ICN deployment in UE 887 2. Native ICN deployments in UE 889 3. ICN deployment in eNodeB 891 4. ICN deployment in mobile gateways (SGW/PGW) 893 5.4.1. Dual stack ICN deployments in UE 895 The control and user plane communications in LTE, 4G mobile networks 896 are specified in 3GPP documents [TS23.203] and [TS23.401]. It is 897 important to understand that UE can be either consumer (receiving 898 content) or publisher (pushing content for other clients). The 899 protocol stack inside mobile device (UE) is complex because it has to 900 support multiple radio connectivity access to eNodeB(s). 902 Figure 5 provides a high-level description of a protocol stack, where 903 IP is defined at two layers: (1) user plane communication and (2) UDP 904 encapsulation. User plane communication takes place between Packet 905 Data Convergence Protocol (PDCP) and Application layer, whereas UDP 906 encapsulation is at GTP protocol stack. 908 The protocol interactions and impact of supporting tunneling of ICN 909 packet into IP or to support ICN natively are described in Figure 5 910 and Figure 6, respectively. 912 +--------+ +--------+ 913 | App | | CDN | 914 +--------+ +--------+ 915 |Transp. | | | | |Transp. | 916 |Converg.|.|..............|...............|............|.|Converge| 917 +--------+ | | | +--------+ | +--------+ 918 | |.|..............|...............|.| |.|.| | 919 | ICN/IP | | | | | ICN/IP | | | ICN/IP| 920 | | | | | | | | | | 921 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 922 | |.|.| | |.|.| | |.|.| | | | | | 923 | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 924 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 925 | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | 926 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 927 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 928 +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ 929 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 930 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 931 UE | BS(eNodeB) | SGW | PGW | 932 Uu S1U S5/S8 SGi 934 Figure 5: Dual Stack ICN Deployment in UE 936 The protocols and software stack used inside LTE capable UE support 937 both 3G and LTE software interworking and handover. Latest 3GPP 938 Rel.13 onward specification describes the use of IP and non-IP 939 protocols to establish logical/session connectivity. We intend to 940 leverage the non-IP protocol-based mechanism to deploy ICN protocol 941 stack in UE, as well as in eNodeB and mobile gateways (SGW, PGW). 943 1. Existing application layer can be modified to provide options for 944 a new ICN-based application and existing IP-based applications. 945 UE can continue to support existing IP-based applications or host 946 new applications developed to support native ICN as transport, 947 ICNoIP, or IPoICN-based transport. Application layer has the 948 option of selecting either ICN or IP transport, as well as radio 949 interface, to send and receive data traffic. 951 Our proposal is to provide an Application Programming Interface 952 (API) to the application developers so they can choose either ICN 953 or IP transport for exchanging the traffic with the network. As 954 mentioned in Section 5.2, the transport convergence layer (TCL) 955 function handles the interaction of applications with multiple 956 transport options. 958 2. The transport convergence layer helps determine the type of 959 transport (such as ICN, hICN, or IP) and type of radio interface 960 (LTE or WiFi, or both) used to send and receive traffic. 961 Application layer can make the decision to select a specific 962 transport based on preference, such as content location, content 963 type, content publisher, congestion, cost, QoS, and so on. There 964 can be an Application Programming Interface (API) to exchange 965 parameters required for transport selection. Southbound 966 interactions of Transport Convergence Layer (TCL) will be either 967 to IP or ICN at the network layer. 969 When selecting the IPoICN mode, the TCL is responsible for 970 receiving an incoming IP or HTTP packet and publishing the packet 971 to the ICN network under a suitable ICN name (that is, the hash 972 over the destination IP address for an IP packet, or the hash 973 over the FQDN of the HTTP request for an HTTP packet). In the 974 HTTP case, the TCL maintains a pending request mapping table to 975 map returning responses to the originating HTTP request. The 976 common API will provide a common 'connection' abstraction for 977 this HTTP mode of operation, returning the response over said 978 connection abstraction, akin to the TCP socket interface, while 979 implementing a reliable transport connection semantic over the 980 ICN from the UE to the receiving UE or the PGW. If the HTTP 981 protocol stack remains unchanged, therefore utilizing the TCP 982 protocol for transfer, the TCL operates in local TCP termination 983 mode, retrieving the HTTP packet through said local termination. 985 +----------------+ +-----------------+ 986 | ICN App (new) | |IP App (existing)| 987 +---------+------+ +-------+---------+ 988 | | 989 +---------+----------------+---------+ 990 | Transport Convergence Layer (new) | 991 +------+---------------------+-------+ 992 | | 993 +------+------+ +------+-------+ 994 |ICN function | | IP function | 995 | (New) | | (Existing) | 996 +------+------+ +------+-------+ 997 | | 998 +------+---------------------+-------+ 999 | PDCP (updated to support ICN) | 1000 +-----------------+------------------+ 1001 | 1002 +-----------------+------------------+ 1003 | RLC (Existing) | 1004 +-----------------+------------------+ 1005 | 1006 +-----------------+------------------+ 1007 | MAC Layer (Existing) | 1008 +-----------------+------------------+ 1009 | 1010 +-----------------+------------------+ 1011 | Physical L1 (Existing) | 1012 +------------------------------------+ 1014 Figure 6: Dual Stack ICN Protocol Interactions 1016 3. ICN function (forwarder) is introduced in parallel to the 1017 existing IP layer. ICN forwarder contains functional 1018 capabilities to forward ICN packets, such as Interest packet to 1019 eNodeB or response "data packet" from eNodeB to the application. 1021 4. For the dual-stack scenario, when UE is not supporting ICN as 1022 transport, we use IP underlay to transport ICN packets. ICN 1023 function will use IP interface to send Interest and Data packets 1024 for fetching or sending data using ICN protocol function. This 1025 interface will use ICN overlay over IP using any overlay 1026 tunneling mechanism. 1028 5. To support ICN at network layer in UE, PDCP layer has to be aware 1029 of ICN capabilities and parameters. PDCP is located in the Radio 1030 Protocol Stack in the LTE Air interface, between IP (Network 1031 layer) and Radio Link Control Layer (RLC). PDCP performs the 1032 following functions [TS36.323]: 1034 1. Data transport by listening to upper layer, formatting and 1035 pushing down to Radio Link Layer (RLC) 1037 2. Header compression and decompression using Robust Header 1038 Compression (ROHC) 1040 3. Security protections such as ciphering, deciphering, and 1041 integrity protection 1043 4. Radio layer messages associated with sequencing, packet drop 1044 detection and re-transmission, and so on. 1046 6. No changes are required for lower layer such as RLC, MAC, and 1047 Physical (L1) because they are not IP aware. 1049 One key point to understand in this scenario is that ICN is deployed 1050 as an overlay on top of IP. 1052 5.4.2. Native ICN Deployments in UE 1054 We propose to implement ICN natively in UE by modifying the PDCP 1055 layer in 3GPP protocols. Figure 7 provides a high-level protocol 1056 stack description where ICN is used at the following different 1057 layers: 1059 1. User plane communication 1061 2. Transport layer 1063 User plane communication takes place between PDCP and application 1064 layer, whereas ICN transport is a substitute of GTP protocol. 1065 Removal of GTP protocol stack is a significant change in mobile 1066 architecture because GTP is used not just for routing but for 1067 mobility management functions, such as billing, mediation, and policy 1068 enforcement. 1070 If we implement ICN natively in UE, communication between UE and 1071 eNodeB will change. Also, this will avoid tunneling the user plane 1072 traffic from eNodeB to the mobile packet core (SGW, PGW) using GTP 1073 tunnel. 1075 For native ICN deployment, an application will be configured to use 1076 ICN forwarder so there is no need for Transport Convergence. Also, 1077 to support ICN at the network layer in UE, we need to modify the 1078 existing PDCP layer. PDCP layer must be aware of ICN capabilities 1079 and parameters. 1081 Native implementation will also provide opportunities to develop new 1082 use cases leveraging ICN capabilities, such as seamless mobility, UE 1083 to UE content delivery using radio network without traversing the 1084 mobile gateways, and more. 1086 +--------+ +--------+ 1087 | App | | CDN | 1088 +--------+ +--------+ 1089 |Transp. | | | | | |Transp. | 1090 |Converge|.|..............|..............|..............|.|Converge| 1091 +--------+ | | | | +--------+ 1092 | |.|..............|..............|..............|.| | 1093 | ICN/IP | | | | | | | 1094 | | | | | | | | 1095 +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | 1096 | |.|.| | | | | | | | | | | | 1097 | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | 1098 +--------+ | +----+ | | | | | | | | | | 1099 | RLC |.|.|RLC | | | | | | | | | | | 1100 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1101 | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | 1102 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1103 | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | 1104 +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ 1105 UE | BS(eNodeB) | SGW | PGW | 1106 Uu S1u S5/S8 SGi 1108 Figure 7: Native ICN Deployment in UE 1110 5.5. ICN Deployment in eNodeB 1112 eNodeB is a physical point of attachment for UE, where radio 1113 protocols are converted into IP transport protocol for dual stack/ 1114 overlay and native ICN, respectively (see Figure 6 and Figure 7). 1115 When UE performs attach procedures, it is assigned an identity either 1116 as IP or dual stack (IP and ICN), or ICN. UE can initiate data 1117 traffic using any of the following options: 1119 1. Native IP (IPv4 or IPv6) 1121 2. Native ICN 1123 3. Dual stack IP (IPv4/IPv6) or ICN 1124 UE encapsulates user data transport request into PDCP layer and sends 1125 the information on air interface to eNodeB. eNodeB receives the 1126 information and, using PDCP [TS36.323], de-encapsulates air-interface 1127 messages and converts them to forward to core mobile gateways (SGW, 1128 PGW). As shown in Figure 8, to support ICN natively in eNodeB, it is 1129 proposed to provide transport convergence layer (TCL) capabilities in 1130 eNodeB (similar to as provided in UE), which provides the following 1131 functions: 1133 1. It decides the forwarding strategy for a user data request coming 1134 from UE. The strategy can decide based on preference indicated 1135 by the application, such as congestion, cost, QoS, and so on. 1137 2. eNodeB to provide open Application Programming Interface (API) to 1138 external management systems, to provide capability to eNodeB to 1139 program the forwarding strategies. 1141 +---------------+ | 1142 | UE request | | ICN +---------+ 1143 +---> | content using |--+--- transport -->| | 1144 | |ICN protocol | | | | 1145 | +---------------+ | | | 1146 | | | | 1147 | +---------------+ | | | 1148 +-+ | | UE request | | IP |To mobile| 1149 | |---+---> | content using |--+--- transport -->| GW | 1150 +-+ | | IP protocol | | |(SGW,PGW)| 1151 UE | +---------------+ | | | 1152 | | | | 1153 | +---------------+ | | | 1154 | | UE request | | Dual stack | | 1155 +---> | content using |--+--- IP+ICN -->| | 1156 |IP/ICN protocol| | transport +---------+ 1157 +---------------+ | 1158 eNodeB S1u 1160 Figure 8: Native ICN Deployment in eNodeB 1162 3. eNodeB can be upgraded to support three different types of 1163 transport: IP, ICN, and dual stack IP+ICN towards mobile 1164 gateways, as depicted in Figure 8. It is also proposed to deploy 1165 IP and/or ICN forwarding capabilities into eNodeB, for efficient 1166 transfer of data between eNodeB and mobile gateways. Following 1167 are choices for forwarding a data request towards mobile 1168 gateways: 1170 1. Assuming eNodeB is IP enabled and UE requests IP transfer, 1171 eNodeB forwards data over IP. 1173 2. Assuming eNodeB is ICN enabled and UE requests ICN transfer, 1174 eNodeB forwards data over ICN. 1176 3. Assuming eNodeB is IP enabled and UE requests ICN, eNodeB 1177 overlays ICN on IP and forwards user plane traffic over IP. 1179 4. Assuming eNodeB is ICN enabled and UE requests IP, eNodeB 1180 overlays IP on ICN and forwards user plane traffic over ICN 1181 [IPoICN]. 1183 5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways 1185 Mobile gateways---also known as Evolved Packet Core (EPC)--include 1186 SGW, PGW, which perform session management for UE from the initial 1187 attach to disconnection. When UE is powered on, it performs NAS 1188 signaling and attaches to PGW after successful authentication. PGW 1189 is an anchoring point for UE and responsible for service creations, 1190 authorization, maintenance, and so on. The Entire functionality is 1191 managed using IP address(es) for UE. 1193 To implement ICN in EPC, the following functions are proposed: 1195 1. Insert ICN attributes in session management layer as additional 1196 functionality with IP stack. Session management layer is used 1197 for performing attach procedures and assigning logical identity 1198 to user. After successful authentication by HSS, MME sends a 1199 create session request (CSR) to SGW and SGW to PGW. 1201 2. When MME sends Create Session Request message (Step 12 in 1202 [TS23.401]) to SGW or PGW, it includes a Protocol Configuration 1203 Option Information Element (PCO IE) containing UE capabilities. 1204 We can use PCO IE to carry ICN-related capabilities information 1205 from UE to PGW. This information is received from UE during the 1206 initial attach request in MME. Details of available TLV, which 1207 can be used for ICN, are given in subsequent sections. UE can 1208 support either native IP, ICN+IP, or native ICN. IP is referred 1209 to as both IPv4 and IPv6 protocols. 1211 3. For ICN+IP-capable UE, PGW assigns the UE both an IP address and 1212 ICN identity. UE selects either of the identities during the 1213 initial attach procedures and registers with the network for 1214 session management. For ICN-capable UE, it will provide only ICN 1215 attachment. For native IP-capable UE, there is no change. 1217 4. To support ICN-capable attach procedures and use ICN for user 1218 plane traffic, PGW needs to have full ICN protocol stack 1219 functionalities. Typical ICN capabilities include functions such 1220 as content store (CS), Pending Interest Table (PIT), Forwarding 1221 Information Base (FIB) capabilities, and so on. If UE requests 1222 ICN in PCO IE, then PGW registers UE with ICN names. For ICN 1223 forwarding, PGW caches content locally using CS functionality. 1225 5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598) 1226 and [TS24.008] (see Table 10.5.154 on page 599) provide details 1227 for different fields. 1229 1. Octet 3 (configuration protocols define PDN types), which 1230 contains details about IPv4, IPv6, both or ICN. 1232 2. Any combination of Octet 4 to Z can be used to provide 1233 additional information related to ICN capability. It is most 1234 important that PCO IE parameters are matched between UE and 1235 mobile gateways (SGW, PGW) so they can be interpreted 1236 properly and the UE can attach successfully. 1238 6. Deployment of ICN functionalities in SGW and PGW should be 1239 matched with UE and eNodeB because they will exchange ICN 1240 protocols and parameters. 1242 7. Mobile gateways SGW, PGW will also need ICN forwarding and 1243 caching capability. This is especially important if CUPS is 1244 implemented. User Plane Function (UPF), comprising the SGW and 1245 PGW user plane, will be located at the edge of the network and 1246 close to the end user. ICN-enabled gateway means that this UPF 1247 would serve as a forwarder and should be capable of caching, as 1248 is the case with any other ICN-enabled node. 1250 8. The transport between PGW and CDN provider can be either IP or 1251 ICN. When UE is attached to PGW with ICN identity and 1252 communicates with an ICN-enabled CDN provider, it will use ICN 1253 primitives to fetch the data. On the other hand, for a UE 1254 attached with an ICN identity, if PGW has to communicate with an 1255 IP- enabled CDN provider, it will have to use an ICN-IP 1256 interworking gateway to perform conversion between ICN and IP 1257 primitives for data retrieval. In the case of CUPS 1258 implementation with an offload close to the edge, this 1259 interworking gateway can be collocated with the UPF at the 1260 offload site to maximize the path optimization. Further study is 1261 required to understand how this ICN-to-IP (and vice versa) 1262 interworking gateway would function. 1264 6. Security Considerations 1266 To ensure only authenticated UEs are connected to the network, LTE 1267 mobile network implements various security mechanisms. From the 1268 perspective of ICN deployment in the user plane, it needs to take 1269 care of the following security aspects: 1271 1. UE authentication and authorization 1273 2. Radio or air interface security 1275 3. Denial of service attacks on mobile gateway, services 1277 4. Content positioning either in transport or servers 1279 5. Content cache pollution attacks 1281 6. Secure naming, routing, and forwarding 1283 7. Application security 1285 Security over the LTE air interface is provided through cryptographic 1286 technique. When UE is powered up, it performs key exchange between 1287 UE's USIM and HSS/Authentication Center using NAS messages, including 1288 ciphering and integrity protections between UE and MME. Details of 1289 secure UE authentication, key exchange, ciphering, and integrity 1290 protections messages are given in the 3GPP call flow [TS23.401]. 1292 LTE is an all-IP network and uses IP transport in its mobile backhaul 1293 (between eNodeB and core network). In case of provider-owned 1294 backhaul, it may not implement security mechanisms; however, they are 1295 necessary in case it uses a shared or leased network. The native IP 1296 transport continues to leverage security mechanism such as Internet 1297 key exchange (IKE) and the IP security protocol (IPsec). More 1298 details of mobile backhaul security are provided in 3GPP network 1299 security [TS33.310] and [TS33.320]. When mobile backhaul is upgraded 1300 to support dual stack (IP+ICN) or native ICN, it is required to 1301 implement security techniques that are deployed in mobile backhaul. 1302 When ICN forwarding is enabled on mobile transport routers, we need 1303 to deploy security practices based on [RFC7476] and [RFC7927]. 1305 Some key functions supported by LTE mobile gateway (SGW, PGW) are 1306 content based billing, deep packet inspection (DPI), and lawful 1307 intercept (LI). For ICN-based user plane traffic, it is required to 1308 integrate ICN security for sessions between UE and gateway. However, 1309 in the ICN network, some of the services provided by mobile gateways 1310 mentioned above may not work because only consumers who have 1311 decryption keys can access the content. Further research in this 1312 area is needed. 1314 7. Summary 1316 In this draft, we have discussed complexities of LTE network and key 1317 dependencies for deploying ICN in user plane data transport. 1318 Different deployment options described cover aspects such as inter 1319 operability and multi-technology, which is a reality for any Service 1320 Provider. One can use LTE gateway software and ICN simulator and 1321 deploy ICN data transport in user plane as an overlay, dual stack (IP 1322 + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, 1323 PGW and transport network). Notice that, for deployment scenarios 1324 discussed above, additional study is required for lawful 1325 interception, billing/mediation, network slicing, and provisioning 1326 APIs. 1328 Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy 1329 functionalities such as Content Delivery Network (CDN) caching and 1330 mobile user plane functions (UPF) [TS23.501]. Recent research for 1331 delivering real-time video content [MPVCICN] using ICN has also been 1332 proven to be efficient [NDNRTC] and can be used towards realizing the 1333 benefits of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW) 1334 and CDN. The key aspect for ICN is in its seamless integration in 1335 LTE and 5G networks with tangible benefits so we can optimize content 1336 delivery using simple and scalable architecture. Authors will 1337 continue to explore how ICN forwarding in MEC could be used in 1338 efficient data delivery from the mobile edge. 1340 Based on our study of control plane signaling, it is not beneficial 1341 to deploy ICN with existing protocols unless further changes are 1342 introduced in the control protocol stack itself. As mentioned in 1343 [TS23.501], 5G network architecture proposes simplification of 1344 control plane messages and can be a candidate for use of ICN. 1346 As a starting step towards ICN user plane deployment, it is proposed 1347 to incorporate protocol changes in UE, eNodeB, SGW/PGW for data 1348 transport. ICN has inherent capabilities for mobility and content 1349 caching, which can improve the efficiency of data transport for 1350 unicast and multicast delivery. Authors welcome contributions and 1351 suggestions, including those related to further validations of the 1352 principles by implementing prototype and/or proof of concept in the 1353 lab and in the production environment. 1355 8. Acknowledgements 1357 We thank all contributors, reviewers, and the chairs for the valuable 1358 time in providing comments and feedback that helped improve this 1359 draft. We specially want to mention the following members of the 1360 IRTF Information-Centric Networking Research Group (ICNRG), listed in 1361 alphabetical order: Thomas Jagodits, Luca Muscariello, David R. 1362 Oran, Akbar Rahman, Martin J. Reed, and Thomas C. Schmidt. 1364 The IRSG review was provided by Colin Perkins. 1366 9. References 1368 9.1. Normative References 1370 [TS24.008] 1371 3GPP, "Mobile radio interface Layer 3 specification; Core 1372 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 1373 December 2005, 1374 . 1376 [TS25.323] 1377 3GPP, "Packet Data Convergence Protocol (PDCP) 1378 specification", 3GPP TS 25.323 3.10.0, September 2002, 1379 . 1381 [TS29.274] 1382 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1383 Packet Radio Service (GPRS) Tunneling Protocol for Control 1384 plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 1385 2013, . 1387 [TS29.281] 1388 3GPP, "General Packet Radio System (GPRS) Tunneling 1389 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1390 September 2011, 1391 . 1393 [TS36.323] 1394 3GPP, "Evolved Universal Terrestrial Radio Access 1395 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1396 specification", 3GPP TS 36.323 10.2.0, January 2013, 1397 . 1399 9.2. Informative References 1401 [ALM] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 1402 Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in 1403 ICN", Proceedings of the 2Nd ACM Conference on 1404 Information-Centric Networking, ACM-ICN'15, ACM DL, 1405 pp.189-190, September 2013, 1406 . 1408 [BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. 1409 Ertekin, "Integrating Header Compression with IPsec", 1410 MILCOM 2006 - 2006 IEEE Military Communications 1411 conference IEEE Xplore DL, pp.1-6, October 2006, 1412 . 1414 [CCN] "Content Centric Networking", . 1416 [CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric 1417 network function virtualization over 5g mobile wireless 1418 networks", IEEE Network Journal vol. 29, number 3, pp. 1419 68-74, June 2015, 1420 . 1422 [EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and 1423 User Plane Separation of EPC nodes (CUPS)", 3GPP The 1424 Mobile Broadband Standard, July 2017, 1425 . 1427 [GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1428 Slice Networking", draft-galis-anima-autonomic-slice- 1429 networking-05 (work in progress), September 2018. 1431 [GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press 1432 book "IP Design for Mobile Networks"", Cisco 1433 Press Networking Technology series, June 2009, 1434 . 1437 [H2020] H2020, "The POINT Project", . 1439 [HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. 1440 Papalini, "Hybrid Information-Centric Networking", draft- 1441 muscariello-intarea-hicn-01 (work in progress), December 1442 2018. 1444 [ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White, 1445 "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 1446 draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018. 1448 [ICNLOWPAN] 1449 Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., 1450 Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN 1451 Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-02 1452 (work in progress), March 2019. 1454 [ICNQoS] Al-Naday, M., Bontozoglou, A., Vassilakis, G., and M. 1455 Reed, "Quality of Service in an Information-Centric 1456 Network", 2014 IEEE Global Communications Conference IEEE 1457 Xplore DL, pp. 1861-1866, December 2014, 1458 . 1460 [IPoICN] Trossen, D., Read, M., Riihijarvi, J., Georgiades, M., 1461 Fotiou, N., and G. Xylomenos, "IP over ICN - The better 1462 IP?", 2015 European Conference on Networks and 1463 Communications (EuCNC) IEEE Xplore DL, pp. 413-417, June 1464 2015, . 1466 [MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, 1467 "Scalable mobile backhauling via information-centric 1468 networking", The 21st IEEE International Workshop on Local 1469 and Metropolitan Area Networks, Beijing, pp. 1-6, April 1470 2015, . 1472 [MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference 1473 Architecture", ETSI European Telecommunication Standards 1474 Institute (ETSI) MEC specification, March 2016, 1475 . 1478 [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and 1479 G. Wang, "Realtime multi-party video conferencing service 1480 over information centric network", IEEE International 1481 Conference on Multimedia and Expo Workshops (ICMEW) Turin, 1482 Italy, pp. 1-6, June 2015, 1483 . 1485 [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., 1486 Ohnishi, R., and E. Muramoto, "Real-time Streaming Data 1487 Delivery over Named Data Networking,", IEICE Transactions 1488 on Communications vol. E99.B, pp. 974-991, May 2016, 1489 . 1491 [NGMN] Robson, J., "Data Offloading Techniques in Cellular 1492 Networks: A Survey", Next Generation Mobile Networks, LTE- 1493 Advanced Transport Provisioning, V0.0.14, October 2015, 1494 . 1497 [OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, 1498 A., Bruno, R., and M. Conti, "Data Offloading Techniques 1499 in Cellular Networks: A Survey", IEEE Communications 1500 Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2, 1501 pp.580-603, November 2014, 1502 . 1504 [OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption 1505 Overhead in Very High-speed Wireless LANs", Proceedings of 1506 the 2009 IEEE International Conference on Communications 1507 ICC'09, ACM DL, pp.575-579, June 2009, 1508 . 1510 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1511 Guidelines for DiffServ Service Classes", RFC 4594, 1512 DOI 10.17487/RFC4594, August 2006, 1513 . 1515 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1516 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1517 Partnership Project (3GPP) Evolved Packet System (EPS)", 1518 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1519 . 1521 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1522 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1523 "Information-Centric Networking: Baseline Scenarios", 1524 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1525 . 1527 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1528 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1529 "Information-Centric Networking (ICN) Research 1530 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1531 . 1533 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1534 Networking (CCNx) Semantics", RFC 8569, 1535 DOI 10.17487/RFC8569, July 2019, 1536 . 1538 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1539 Networking (CCNx) Messages in TLV Format", RFC 8609, 1540 DOI 10.17487/RFC8609, July 2019, 1541 . 1543 [SDN5G] Page, J. and J. Dricot, "Software-defined networking for 1544 low-latency 5G core network", 2016 International 1545 Conference on Military Communications and Information 1546 Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016, 1547 . 1549 [TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", 1550 ICNRG Buenos Aires IETF 95, April 2016, 1551 . 1554 [TS23.203] 1555 3GPP, "Policy and charging control architecture", 3GPP 1556 TS 23.203 10.9.0, September 2013, 1557 . 1559 [TS23.401] 1560 3GPP, "General Packet Radio Service (GPRS) enhancements 1561 for Evolved Universal Terrestrial Radio Access Network 1562 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013, 1563 . 1565 [TS23.501] 1566 3GPP, "System Architecture for the 5G System", 3GPP 1567 TS 23.501 15.2.0, June 2018, 1568 . 1570 [TS23.714] 1571 3GPP, "Technical Specification Group Services and System 1572 Aspects: Study on control and user plane separation of EPC 1573 nodes", 3GPP TS 23.714 0.2.2, June 2016, 1574 . 1576 [TS29.060] 1577 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling 1578 Protocol (GTP) across the Gn and Gp interface", 3GPP 1579 TS 29.060 3.19.0, March 2004, 1580 . 1582 [TS33.310] 1583 3GPP, "Network Domain Security (NDS); Authentication 1584 Framework (AF)", 3GPP TS 33.310 10.7.0, December 2012, 1585 . 1587 [TS33.320] 1588 3GPP, "Security of Home Node B (HNB) / Home evolved Node B 1589 (HeNB)", 3GPP TS 33.320 10.5.0, June 2012, 1590 . 1592 Authors' Addresses 1594 Prakash Suthar 1595 Cisco Systems Inc. 1596 Rosemont, Illinois 60018 1597 USA 1599 Email: psuthar@cisco.com 1601 Milan Stolic 1602 Cisco Systems Inc. 1603 Rosemont, Illinois 60018 1604 USA 1606 Email: mistolic@cisco.com 1608 Anil Jangam (editor) 1609 Cisco Systems Inc. 1610 San Jose, California 95134 1611 USA 1613 Email: anjangam@cisco.com 1615 Dirk Trossen 1616 Huawei Technologies 1617 Riesstrasse 25 1618 Munich 80992 1619 Germany 1621 Email: dirk.trossen@huawei.com 1623 Ravishankar Ravindran 1624 Sterlite Technologies 1625 5201 Greatamerica Pkwy 1626 Santa Clara, California 95054 1627 USA 1629 Email: ravishankar.ravindran@sterlite.com