idnits 2.17.1 draft-suthar-icnrg-icn-lte-4g-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 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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 126, but not defined == Missing Reference: 'RFC5213' is mentioned on line 187, but not defined == Missing Reference: 'H2020' is mentioned on line 721, but not defined == Missing Reference: 'IPICN' is mentioned on line 731, but not defined == Missing Reference: 'Fig 4' is mentioned on line 808, but not defined == Unused Reference: 'IPSEC1' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'RFC7476' is defined on line 1319, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'NDNTLV' is defined on line 1330, but no explicit reference was found in the text == Unused Reference: 'NDNPUB' is defined on line 1337, but no explicit reference was found in the text == Unused Reference: 'NDN' is defined on line 1343, but no explicit reference was found in the text == Unused Reference: 'VNIIDX' is defined on line 1350, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 14 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 5 Cisco Systems 6 Dirk Trossen 7 InterDigital Inc. 8 Expires: March 23, 2018 September 19 2017 10 Native Deployment of ICN in LTE, 4G Mobile Networks 11 draft-suthar-icnrg-icn-lte-4g-03 13 Abstract 15 LTE, 4G mobile networks use IP based transport for control plane to 16 establish the data session and user plane for actual data delivery. 17 In existing architecture, IP transport used in user plane is not 18 optimized for data transport, which leads to an inefficient data 19 delivery. IP unicast routing from server to clients is used for 20 delivery of multimedia content to User Equipment (UE), where each 21 user gets a separate stream. From bandwidth and routing perspective 22 this approach is inefficient. Multicast and broadcast technologies 23 have emerged recently for mobile networks, but their deployments are 24 very limited or at an experimental stage due to complex architecture 25 and radio spectrum issues. ICN is a rapidly emerging technology with 26 built-in features for efficient multimedia data delivery, however 27 majority of the work is focused on fixed networks. The main focus of 28 this draft is on native deployment of ICN in cellular mobile networks 29 by using ICN in 3GPP protocol stack. ICN has an inherent capability 30 for multicast, anchorless mobility, security and it is optimized for 31 data delivery using local caching at the edge. The native ICN (it 32 runs directly on cellular layer 2 protocols like PDCP/RLC/MAC/L1) or 33 dual stack (along with IP) deployment will bring all inherent 34 benefits and help in optimizing mobile networks. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as 44 Internet-Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress". 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 Copyright and License Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2 3GPP Terminology and Concepts . . . . . . . . . . . . . . . 4 77 2. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . . 8 78 2.1 Network Overview . . . . . . . . . . . . . . . . . . . . . 8 79 2.2 QoS Challenges . . . . . . . . . . . . . . . . . . . . . . 10 80 2.3 Data Transport Using IP . . . . . . . . . . . . . . . . . . 11 81 2.4 Virtualizing Mobile Networks . . . . . . . . . . . . . . . 11 82 3. Data Transport Using ICN . . . . . . . . . . . . . . . . . . . 12 83 4. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 14 84 4.1 General ICN Deployment Considerations . . . . . . . . . . . 14 85 4.2 ICN Deployment Scenarios . . . . . . . . . . . . . . . . . . 14 86 4.3 ICN Deployment in LTE Control Plane . . . . . . . . . . . . 17 87 4.4 ICN Deployment in LTE User Plane . . . . . . . . . . . . . 18 88 4.4.1 Dual stack ICN Deployments in UE . . . . . . . . . . . 19 89 4.4.2 Native ICN Deployments in UE . . . . . . . . . . . . . 22 90 4.5 ICN Deployment in eNodeB . . . . . . . . . . . . . . . . . 23 91 4.6 ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . . 24 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 26 93 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 7.1 Normative References . . . . . . . . . . . . . . . . . . . 29 96 7.2 Informative References . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 99 1 Introduction 101 LTE mobile technology is built as all-IP network. It uses IP routing 102 protocols such as OSPF, ISIS, BGP etc. to establish network routes to 103 route the data traffic to end user's device. Stickiness of IP address 104 to a device is the key to get connected to a mobile network and the 105 same IP address is maintained through the session until the device 106 gets detached or moves to another network. 108 One of the key protocols used in 4G and LTE networks is GPRS 109 Tunneling protocol (GTP). GTP, DIAMETER and other protocols are built 110 on top of IP. One of the biggest challenges with IP based routing is 111 that it is not optimized for data transport although it is the most 112 efficient communication protocol. By native implementation of 113 Information Centric Networking (ICN) in 3GPP, we can re-architect 114 mobile network and optimize its design for efficient data transport 115 by leveraging the caching feature of ICN. ICN also offers an 116 opportunity to leverage inherent capabilities of multicast, 117 anchorless mobility management, and authentication. This draft 118 provides insight into different options for deploying ICN in mobile 119 networks and how they impact mobile providers and end-users. 121 1.1 Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 1.2 3GPP Terminology and Concepts 129 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 network. 133 APN identifies the packet data network (PDN) that a mobile data 134 user wants to communicate with. In addition to identifying a PDN, 135 an APN may also be used to define the type of service, QoS and 136 other logical entities inside GGSN, PGW. 138 Control Plane 140 The control plane carries signaling traffic and is responsible for 141 routing between eNodeB and MME, MME and HSS, MME and SGW, SGW and 142 PGW etc. Control plane signaling is required to authenticate and 143 authorize UE and establish mobility session with mobile gateways 144 (SGW/PGW). Functions of the control plane also include system 145 configuration and management. 147 Dual Address PDN/PDP Type 149 The dual address Packet Data Network/Packet Data Protocol 150 (PDN/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 serving 152 both IPv4 and IPv6 simultaneously. 154 eNodeB 156 The eNodeB is a base station entity that supports the Long-Term 157 Evolution (LTE) air interface. 159 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, packet- 163 optimized system. The EPC comprises some of the sub components of 164 the EPS core such as Mobility Management Entity (MME), Serving 165 Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home 166 Subscriber Server (HSS). 168 Evolved Packet System 170 The Evolved Packet System (EPS) is an evolution of the 3GPP 171 GPRSsystem 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 the 174 Evolved Universal Terrestrial Radio Access (E-UTRA) and the 175 Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 177 Evolved UTRAN The Evolved UTRAN (E-UTRAN) is a communications 178 network, sometimes referred to as 4G, and consists of eNodeBs (4G 179 base stations). The E-UTRAN allows connectivity between the User 180 Equipment and the core network. 182 GPRS Tunnelling Protocol 184 The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] 185 [TS.29281] is a tunnelling protocol defined by 3GPP. It is a 186 network-based mobility protocol and is similar to Proxy Mobile 187 IPv6 (PMIPv6) [RFC5213]. However, GTP also provides functionality 188 beyond mobility, such as in-band signaling related to Quality of 189 Service (QoS) and charging, among others. 191 Gateway GPRS Support Node 193 The Gateway GPRS Support Node (GGSN) is a gateway function in the 194 GPRS and 3G network that provides connectivity to the Internet or 195 other PDNs. The host attaches to a GGSN identified by an APN 196 assigned to it by an operator. The GGSN also serves as the 197 topological anchor for addresses/prefixes assigned to the User 198 Equipment. 200 General Packet Radio Service 202 The General Packet Radio Service (GPRS) is a packet-oriented 203 mobile data service available to users of the 2G and 3G cellular 204 communication systems -- the GSM -- specified by 3GPP. 206 Home Location Register 208 The Home Location Register (HLR) is a pre-Release-5 database (but 209 is also used in Release-5 and later networks in real deployments) 210 that contains subscriber data and information related to call 211 routing. All subscribers of an operator, and the subscribers' 212 enabled services, are provisioned in the HLR. 214 Home Subscriber Server 216 The Home Subscriber Server (HSS) is a database for a given 217 subscriber and was introduced in 3GPP Release-5. It is the entity 218 containing the subscription-related information to support the 219 network entities actually handling calls/sessions. 221 Mobility Management Entity 223 The Mobility Management Entity (MME) is a network element that is 224 responsible for control-plane functionalities, including 225 authentication, authorization, bearer management, layer-2 226 mobility, etc. The MME is essentially the control-plane part of 227 the SGSN in the GPRS. The user-plane traffic bypasses the MME. 229 Public Land Mobile Network 231 The Public Land Mobile Network (PLMN) is a network that is 232 operated by a single administration. A PLMN (and therefore also an 233 operator) is identified by the Mobile Country Code (MCC) and the 234 Mobile Network Code (MNC). Each (telecommunications) operator 235 providing mobile services has its own PLMN. 237 Policy and Charging Control 239 The Policy and Charging Control (PCC) framework is used for QoS 240 policy and charging control. It has two main functions: flow- 241 based charging, including online credit control and policy control 242 (e.g., gating control, QoS control, and QoS signaling). It is 243 optional to 3GPP EPS but needed if dynamic policy and charging 244 control by means of PCC rules based on user and services are 245 desired. 247 Packet Data Network 249 The Packet Data Network (PDN) is a packet-based network that 250 either belongs to the operator or is an external network such as 251 the Internet or a corporate intranet. The user eventually accesses 252 services in one or more PDNs. The operator's packet core networks 253 are separated from packet data networks either by GGSNs or PDN 254 Gateways (PGWs). 256 Serving Gateway 258 The Serving Gateway (SGW) is a gateway function in the EPS, which 259 terminates the interface towards the E-UTRAN. The SGW is the 260 Mobility Anchor point for layer-2 mobility (inter-eNodeB 261 handovers). For each UE connected with the EPS, at any given 262 point in time, there is only one SGW. The SGW is essentially the 263 user-plane part of the GPRS's SGSN. 265 Packet Data Network Gateway 267 The Packet Data Network Gateway (PGW) is a gateway function in the 268 Evolved Packet System (EPS), which provides connectivity to the 269 Internet or other PDNs. The host attaches to a PGW identified by 270 an APN assigned to it by an operator. The PGW also serves as the 271 topological anchor for addresses/prefixes assigned to the User 272 Equipment. 274 Packet Data Protocol Context 276 A Packet Data Protocol (PDP) context is the equivalent of a 277 virtual connection between the User Equipment (UE) and a PDN using 278 a specific gateway. 280 Packet Data Protocol Type 282 A Packet Data Protocol Type (PDP Type) identifies the used/allowed 283 protocols within the PDP context. Examples are IPv4, IPv6, and 284 IPv4v6 (dual-stack). 286 Serving GPRS Support Node 288 The Serving GPRS Support Node (SGSN) is a network element that is 289 located between the radio access network (RAN) and the gateway 290 (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and 291 SGSN transports the packets between the UE and the gateway. 293 Terminal Equipment 295 The Terminal Equipment (TE) is any device/host connected to the 296 Mobile Terminal (MT) offering services to the user. A TE may 297 communicate to an MT, for example, over the Point to Point 298 Protocol (PPP). 300 UE, MS, MN, and Mobile 302 The terms UE (User Equipment), MS (Mobile Station), MN (Mobile 303 Node), and mobile refer to the devices that are hosts with the 304 ability to obtain Internet connectivity via a 3GPP network. A MS 305 is comprised of the Terminal Equipment (TE) and a Mobile Terminal 306 (MT). The terms UE, MS, MN, and mobile are used interchangeably 307 within this document. 309 UMTS Terrestrial Radio Access Network 311 The Universal Mobile Telecommunications System (UMTS) Terrestrial 312 Radio Access Network (UTRAN) is a communications network, commonly 313 referred to as 3G, and consists of NodeBs (3G base stations) and 314 Radio Network Controllers (RNCs), which make up the UMTS radio 315 access network. The UTRAN allows connectivity between the UE and 316 the core network. The UTRAN is comprised of WCDMA, HSPA, and 317 HSPA+ radio technologies. 319 User Plane 321 The user plane refers to data traffic and the required bearers for 322 the data traffic. In practice, IP is the only data traffic 323 protocol used in the user plane. 325 2. LTE, 4G Mobile Network 327 2.1 Network Overview 329 With the introduction of LTE, mobile networks moved to all-IP 330 transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, 331 routing and switching etc. Although LTE network is data-centric, it 332 has support for legacy Circuit Switch features like voice and SMS 333 through transitional CS fallback and flexible IMS deployment 334 [GRAYSON]. For each mobile device attached to the radio (eNodeB) 335 there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) 336 between eNodeB and Mobile gateways (i.e. SGW, PGW). 338 The GTP tunnel is used to carry user traffic between gateways and 339 mobile devices so the data can only be distributed using unicast 340 mechanism. It is also important to understand the overhead of a GTP 341 and IPSec protocols because it has impact on the carried user data 342 traffic. All mobile backhaul traffic is encapsulated using GTP 343 tunnel, which has overhead of 8 bytes on top of IP and UDP [NGMN]. 344 Additionally, if IPSec is used for security (which is often required 345 if the Service provider is using a shared backhaul), it adds overhead 346 based upon IPSec tunneling model (tunnel or transport), and 347 encryption and authentication header algorithm used. If we factor 348 Advanced Encryption Standard (AES) encryption with packet size the 349 overhead can vary significantly [IPSEC2]. 351 +-------+ Diameter +-------+ 352 | HSS |------------| SPR | 353 +-------+ +-------+ 354 | | 355 +------+ +------+ S4 | +-------+ 356 | 3G |---| SGSN |----------------|------+ +------| PCRF | 357 ^ |NodeB | | |---------+ +---+ | | +-------+ 358 +-+ | +------+ +------+ S3 | | S6a | |Gxc | 359 | | | +-------+ | | |Gx 360 +-+ | +------------------| MME |------+ | | | 361 UE v | S1MME +-------+ S11 | | | | 362 +----+-+ +-------+ +-------+ 363 |4G/LTE|------------------------------| SGW |-----| PGW | 364 |eNodeB| S1U +-------+ +--| | 365 +------+ | +-------+ 366 +---------------------+ | | 367 S1U GTP Tunnel traffic | +-------+ | | 368 S2a GRE Tunnel traffic |S2A | ePDG |-------+ | 369 S2b GRE Tunnel traffic | +-------+ S2B |SGi 370 SGi IP traffic | | | 371 +---------+ +---------+ +-----+ 372 | Trusted | |Untrusted| | CDN | 373 |non-3GPP | |non-3GPP | +-----+ 374 +---------+ +---------+ 375 | | 376 +-+ +-+ 377 | | | | 378 +-+ +-+ 379 UE UE 381 Figure-1: LTE, 4G Mobile Network Overview 383 When any UE is powered up, it attaches to a mobile network based on 384 its configuration and subscription. After successful attach 385 procedure, UE registers with the mobile core network and IPv4 and/or 386 IPv6 address is assigned. A default bearer is created for each UE and 387 it is assigned to default Access Point Name (APN). 389 The data delivered to mobile devices is unicast inside GTP tunnel. If 390 we consider combined impact of GTP, IPSec and unicast traffic, the 391 data delivery is not efficient. IETF has developed various header 392 compression algorithms to reduce the overhead associated with IP 393 packets. Some of techniques are robust header compression (ROHC) and 394 enhanced compression of the real-time transport protocol (ECRTP) so 395 that impact of overhead created by GTP, IPsec etc. is reduced to some 396 extent [BROWER]. For commercial mobile networks, 3GPP has adopted 397 different mechanisms for header compression to achieve efficiency in 398 data delivery [TS25.323], and can be used in ICN as well. 400 2.2 QoS Challenges 402 During attach procedure, default bearer is created for each UE and it 403 is assigned to the default Access Point Name (APN). The QoS values 404 uplink and downlink bandwidth assigned during initial attach are 405 minimal. Additional dedicated bearer(s) with enhanced QoS parameters 406 is established depending on the specific application needs. 408 While all traffic within a certain bearer gets the same treatment, 409 QoS parameters supporting these requirements can be very granular in 410 different bearers. These values vary for the control, management and 411 user traffic, and depending on the application key parameters, such 412 as latency, jitter (important for voice and other real-time 413 applications), packet loss and queuing mechanism (strict priority, 414 low-latency, fair etc.) can be very different. 416 Implementation of QoS for mobile networks is done at two stages: at 417 content prioritization/marking and transport marking, and congestion 418 management. From the transport perspective, QoS is defined at layer 2 419 as class of service (CoS) and at layer 3 either as DiffServ code 420 point (DSCP) or type of service (ToS). The mapping of CoS to DSCP 421 takes place at layer 2/3 switching and routing elements. 3GPP has 422 specified QoS Class Identifier (QCI) which represents different types 423 of content and equivalent mapping to DSCP at transport layer 424 [TS23.203] [TS23.401]; however, this again requires manual 425 configuration at different elements and if there is misconfiguration 426 at any place in the path it will not work properly. 428 In summary QoS configuration for mobile network for user plane (for 429 user traffic) and transport in IP based mobile network is complex and 430 it require synchronization of parameters among different platforms. 431 Any misconfiguration in IP QoS can result in poor subscriber 432 experience. By deploying ICN, we intend to enhance the subscriber 433 experience using its inherent capabilities. 435 2.3 Data Transport Using IP 437 The data delivered to mobile devices is unicast inside GTP tunnel 438 from a eNodeB to a PDN gateway (PGW), as described in 3GPP 439 specifications [TS23.401]. While the technology exists to address the 440 issue of possible multicast delivery, there are many difficulties 441 related to multicast protocol implementation on the RAN side of the 442 network. Transport networks in the backhaul and core have addressed 443 the multicast delivery long time ago and have implemented it in most 444 cases in their multi-purpose integrated transport, but the RAN part 445 of the network is still lagging behind due to complexities related to 446 mobility of the clients, handovers, and the fact that the potential 447 gain to the Service Providers may not justify the investment. With 448 that said, the data delivery in the mobility remains greatly unicast. 450 To ease the burden on the bandwidth of the SGi interface, caching is 451 introduced in a similar manner as with many Enterprises. In the 452 mobile networks, whenever possible, a cached data is delivered. 453 Caching servers are placed at a centralized location, typically in 454 the Service Provider's Data Center, or in some cases lightly 455 distributed in the Packet Core locations with the PGW nodes close to 456 the Internet and IP services access (SGi interface). This is a very 457 inefficient concept because traffic has to traverse the entire 458 backhaul path for the data to be delivered to the end-user. Other 459 issues, such as out-of-order delivery contribute to this complexity 460 and inefficiency but could be addressed at the IP transport level. 462 The data delivered to mobile devices is unicast inside a GTP tunnel. 463 If we consider combined impact of GTP, IPSec and unicast traffic, the 464 data delivery is not efficient. By deploying ICN, we intend to either 465 terminate GTP tunnel at the edge by leveraging control and user plane 466 separation or replace it with the native ICN protocols. 468 2.4 Virtualizing Mobile Networks 470 The Mobile packet core deployed in a major service provider network 471 is either based on dedicated hardware or large capacity x86 platforms 472 in some cases. With adoption of Mobile Virtual Network Operators 473 (MVNO), public safety network, and enterprise mobility network, we 474 need elastic mobile core architecture. By deploying mobile packet 475 core on a commercially off the shelf (COTS) platform using 476 virtualized infrastructure (NFVI) framework and end-to-end 477 orchestration, we can simplify new deployments and provide optimized 478 total cost of ownership (TCO). 480 While virtualization is growing and many mobile providers use hybrid 481 architecture consisting of dedicated and virtualized infrastructures, 482 the control and data delivery planes are still the same. There is 483 also work underway to separate control plane and user plane so that 484 the network can scale better. Virtualized mobile networks and network 485 slicing with control and user plane separation provide mechanism to 486 evolve GTP-based architecture to open-flow SDN-based signaling for 487 LTE and proposed 5G. Some of early architecture work for 5G mobile 488 technologies provides mechanism for control and user plane separation 489 and simplifies mobility call flow by introduction of open-flow based 490 signaling is described in [TS23.501] and [TS23.214]. 492 3. Data Transport Using ICN 494 For mobile devices, the edge connectivity to the network is between 495 radio and a router or mobile edge computing (MEC) [MECSPEC] element. 496 MEC has the capability of processing client requests and segregating 497 control and user traffic at the edge of radio rather than sending all 498 requests to the mobile gateway. 500 +----------+ 501 | Content +----------------------------------------+ 502 | Publisher| | 503 +---+---+--+ | 504 | | +--+ +--+ +--+ | 505 | +--->|R1|------------>|R2|---------->|R4| | 506 | +--+ +--+ +--+ | 507 | | Cached | 508 | v content | 509 | +--+ at R3 | 510 | +========|R3|---+ | 511 | # +--+ | | 512 | # | | 513 | v v | 514 | +-+ +-+ | 515 +---------------| |-------------| |-------------+ 516 +-+ +-+ 517 Consumer-1 Consumer-2 518 UE UE 520 ===> Content flow from cache 521 ---> Content flow from publisher 523 Fig. 2. ICN Architecture 525 MEC transforms radio into an intelligent service edge that is capable 526 of delivering services directly from the edge of the network, while 527 providing the best possible performance to the client. MEC can be an 528 ideal candidate for ICN forwarder in addition to its usual function 529 of managing mobile termination. In addition to MEC, other transport 530 elements, such as routers, can work as ICN forwarders. 532 Data transport using ICN is different compared to IP-based transport. 533 It evolves the Internet infrastructure by introducing uniquely named 534 data as a core Internet principle. Communication in ICN takes place 535 between content provider (producer) and end user (consumer) as 536 described in figure 2. 538 Every node in a physical path between a client and a content provider 539 is called ICN forwarder or router, and it has the ability to route 540 the request intelligently and also cache the content so that it can 541 be delivered locally for subsequent request from any other client. 542 For mobile network, transport between a client and a content provider 543 consists of radio network + mobile backhaul and IP core transport + 544 Mobile Gateways + Internet + content data network (CDN). 546 In order to understand suitability of ICN for mobile networks, we 547 will discuss the ICN framework describing protocols architecture and 548 different types of messages, and then consider how we can use this in 549 a mobile network for delivering content more efficiently. ICN uses 550 two types of packets called "interest packet" and "data packet" as 551 described in figure 3. 553 +------------------------------------+ 554 Interest | +------+ +------+ +------+ | +-----+ 555 +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | 556 | | | +------+ +------+ +------+ | +-----+ 557 +-+ | | Add | Drop | | Forward 558 UE <--------+ Intf v Nack v | 559 Data | | 560 +------------------------------------+ 562 +------------------------------------+ 563 +-+ | Forward +------+ | +-----+ 564 | | <-------------------------------------| PIT |<---------| CDN | 565 +-+ | | Cache +--+---+ | Data +-----+ 566 UE | +--v---+ | | 567 | | CS | v | 568 | +------+ Discard | 569 +------------------------------------+ 571 Fig. 3. ICN Interest, Data Packet and Forwarder 573 For LTE network, when a mobile device wants to get certain content, 574 it will send an Interest message to the closest eNodeB. Interest 575 packet follows the TLV format [CCNxTLV] and contains mandatory fields 576 such as name of the content and nonce. Name and nonce together 577 uniquely identify an Interest packet. Nonce is also used to detect 578 looping Interest messages. Interest packet also contains optional 579 fields such as selector and guider fields. Selectors provides a 580 specific filtering action during matching and selection of the name 581 prefixes. Guiders provides specific set of rules on how the Interest 582 packet can be processed at the forwarder. 584 First ICN router will receive Interest packet and perform lookup if 585 request for such content has come earlier from any other client. If 586 yes, it is served from the local cache, otherwise request is 587 forwarded to the next-hop ICN router. Each ICN router maintains three 588 data structures, namely Pending Interest Table (PIT), Forwarding 589 Information Base (FIB), and Content Store (CS). The Interest packet 590 travels hop-by-hop towards content provider. Once the Interest 591 reaches the content provider it will return a Data packet containing 592 information such as content name, signature, signed key and data. 594 Data packet travels in reverse direction following the same path 595 taken by the interest packet so routing symmetry is maintained. 596 Details about algorithms used in PIT, FIB, CS and security trust 597 models are described in various resources [CCN], here we explained 598 the concept and its applicability to the LTE network. 600 4. ICN Deployment in 4G and LTE Networks 602 4.1 General ICN Deployment Considerations 604 In LTE/4G mobile networks, both user and control plane traffic have 605 to be transported from the edge to the mobile packet core via IP 606 transport. The evolution of existing mobile packet core using CUPS 607 [TS23.714] enables flexible network deployment and operation, by 608 distributed deployment and the independent scaling between control 609 plane and user plane functions - while not affecting the 610 functionality of the existing nodes subject to this split. 612 In the CUPS architecture, there is an opportunity to shorten the path 613 for user plane traffic by deploying offload nodes closer to the edge. 614 This optimization allows for the introduction of ICN and amplifies 615 its advantages. This section analyzes the potential impact of ICN on 616 control and user plane traffic for centralized and disaggregate CUPS 617 based mobile network architecture. 619 4.2 ICN Deployment Scenarios 621 Deployment of ICN provides an opportunity to further optimize the 622 existing data transport in LTE/4G mobile networks. The various 623 deployment options that ICN and IP provide are somewhat analogous to 624 the deployment scenarios when IPv6 was introduced to inter operate 625 with IPv4, except with ICN the whole IP stack is being replaced. 627 Authors in [RFC6459] have described the deployment scenarios for 628 LTE/4G mobile network using IP (IPv4 and IPv6) transport and analyzed 629 the impact of ICN for control plane signaling and user plane data 630 delivery. In general ICN can be deployed natively replacing IP 631 transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 632 describes a modified protocol stack to support ICN deployment 633 scenarios. 635 +----------------+ +-----------------+ 636 | ICN App (new) | |IP App (existing)| 637 +---------+------+ +-------+---------+ 638 | | 639 +---------+----------------+---------+ 640 | Transport Convergence Layer (new) | 641 +------+---------------------+-------+ 642 | | 643 +------+------+ +------+-------+ 644 |ICN function | | IP function | 645 | (New) | | (Existing) | 646 +------+------+ +------+-------+ 647 | | 648 (```). (```). 649 ( ICN '`. ( IP '`. 650 ( Cloud ) ( Cloud ) 651 ` __..'+' ` __..'+' 653 Fig. 4. IP/ICN Convergence and Deployment Scenarios 655 As shown in figure 4, for applications running either in UE or in 656 content provider system to use the new transport option, we propose a 657 new transport convergence layer (TCL). This transport convergence 658 layer helps determine what type of transport (e.g. ICN or IP), as 659 well as type of radio interface (e.g. LTE or WiFi or both), is used 660 to send and receive the traffic based on preference e.g. content 661 location, content type, content publisher, congestion, cost, quality 662 of service etc. It helps to configure and decide the type of 663 connection as well as the overlay mode (ICNoIP or IPoICN) between 664 application and the protocol stack (IP or ICN) to be used. 666 TCL can use a number of mechanisms for the selection of transport. It 667 can use a per application configuration through a management 668 interface, possibly even a user-facing setting realized through a 669 user interface, similar to those used today that select cellular over 670 WiFi being used for selected applications. In another option, it 671 might use a software API, which an adapted IP application could use 672 to specify e.g. an ICN transport for obtaining its benefits. 674 Another potential application of TCL is in implementation of network 675 slicing, where it can have a slice management capability locally or 676 it can interface to an external slice manager through an API [GALIS]. 677 This solution can enable network slicing for IP and ICN transport 678 selection from the UE itself. The TCL could apply slice settings to 679 direct certain traffic (or applications) over one slice and others 680 over another slice, determined by some form of 'slicing policy'. 681 Slicing policy can be obtained externally from slice manager or 682 configured locally on UE. 684 From the perspective of the applications either on UE or content 685 provider, four different options are possible for the deployment of 686 ICN natively and/or with IP. 688 1. IP over IP 690 In this scenario UE uses applications tightly integrated with 691 the existing IP transport infrastructure. In this option, the 692 TCL has no additional function since the packets are directly 693 forwarded using IP protocol stack, which in turn sends the 694 packets over the IP transport. 696 2. ICN over ICN 698 Similar to case 1 above, ICN applications tightly integrate 699 with the ICN transport infrastructure. The TCL has no 700 additional responsibility since the packets are directly 701 forwarded using ICN protocol stack, which in turn sends the 702 packets over the ICN transport. 704 3. ICN over IP (ICNoIP) 706 In ICN over IP scenario, the underlying IP transport 707 infrastructure is not impacted; however, ICN is implemented 708 between user equipment (UE), the Radio Access Network (eNodeB) 709 and Mobile Gateway (SGW/PGW) for user plane data communication. 711 An alternative approach to implement ICN over IP is provided in 712 Hybrid ICN [HICN], which implements ICN over IP by mapping of 713 ICN names to the IPv4/IPv6 addresses. 715 Detailed deployment of use cases is described in section 4.4. 716 Application conveys the preference to the TCL, which in turn 717 sends the ICN data packets using the IP transport. 719 4. IP over ICN (IPoICN) 721 H2020 project [H2020] provides an architectural framework for 722 deployment of IP as an overlay over ICN protocol [IPICN]. 723 Implementing IP services over ICN provides an opportunity 724 leveraging benefit of ICN in the transport infrastructure and 725 there is no impact on end devices (UE and access network) as 726 they continue to use IP. IPoICN however, will require an inter- 727 working function (IWF/Border Gateway) to translate various 728 transport primitives such as transport of tunnel mode. IWF 729 function will provide a mechanism for protocol translation 730 between IPoICN and native IP deployment for mobile network. 731 After reviewing [IPICN], we understand and interpret that ICN 732 is implemented in the transport natively; however, IP is 733 implemented in UE, eNodeB, and Mobile gateway (SGW/PGW), which 734 is also called as network attach point (NAP). 736 4.3 ICN Deployment in LTE Control Plane 738 In this section we analyze signaling messages which are required for 739 different procedures, such as attach, handover, tracking area update 740 etc. The goal of analysis is to see if there is any benefit to 741 replace IP-based protocols with ICN for LTE signaling in the current 742 architecture. It is important to understand the concept of point of 743 attachment (POA). When UE connects to a network it has at least three 744 POAs: 746 1. eNodeb managing location or physical POA 748 2. Authentication and Authorization (MME, HSS) managing identity 749 or authentication POA 751 3. Mobile Gateways (SGW, PGW) managing logical or session 752 management POA. 754 In current architecture IP transport is used for all the messages 755 associated with Control Plane for mobility and session management. IP 756 is embedded very deeply into these messages and TLV carrying 757 additional attributes as a layer 3 transport . Physical POA in eNodeB 758 handles both mobility and session management for any UE attached to 759 4G, LTE network. The number of mobility management messages between 760 different nodes in an LTE network per signaling procedure are given 761 below in figure 5. 763 Normally two types of UE devices attach to LTE network: SIM based 764 (need 3GPP mobility protocol for authentication) or non-SIM based 765 (which connect to WiFi network), and authentication is required for 766 both of these device types. For non-SIM based devices, AAA is used 767 for authentication. We do not propose to change UE authentication 768 procedures for user data transport using ICN, or any other mobility 769 management messaging. A separate study would be required to analyze 770 impact of ICN on mobility management messages structures and flows. 771 We are merely analyzing the viability of implementing ICN as a 772 transport for Control plane messages. 774 +---------------------------+-------+-------+-------+-------+------+ 775 | LTE Signaling Procedures | MME | HSS | SGW | PGW | PCRF | 776 +------------------------------------------------------------------+ 777 | Attach | 10 | 2 | 3 | 2 | 1 | 778 | Additional default bearer | 4 | 0 | 3 | 2 | 1 | 779 | Dedicated bearer | 2 | 0 | 2 | 2 | 1 | 780 | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | 781 | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | 782 | X2 handover | 2 | 0 | 1 | 0 | 0 | 783 | S1 handover | 8 | 0 | 3 | 0 | 0 | 784 | Tracking area update | 2 | 0 | 0 | 0 | 0 | 785 | Total | 34 | 2 | 14 | 6 | 3 | 786 +---------------------------+-------+-------+-------+-------+------+ 788 Fig. 5. Signaling Messages in LTE Gateways 790 It is important to note that even if we don't implement ICN in MME 791 and HSS, they still need to support either dual stack or native ICN 792 UE capabilities. When UE initiates attach request using the identity 793 as ICN, MME must be able to parse that message and create a session. 794 MME forwards UE authentication to HSS so HSS must be able to 795 authenticate an ICN capable UE and authorize create session 796 [TS23.401]. 798 Anchorless mobility [ALM] has made some important comments on how 799 mobility management is done in ICN. Author comments about handling 800 mobility without having a dependency on the core network function 801 e.g. MME. However, location update to the core network would still be 802 required to support some of the legal compliance requirements such as 803 lawful intercept and emergency services. 805 The main advantage of ICN is in caching and reusing the content, 806 which does not apply to the transactional signaling exchange. After 807 analyzing LTE signaling call flows [TS23.401] and messages inter- 808 dependencies [Fig 4], our recommendation is that it is not beneficial 809 to deploy ICN for control plane and mobility management functions. 811 4.4 ICN Deployment in LTE User Plane 813 We will consider figure 1 to discuss different mechanisms to deploy 814 ICN in mobile networks. We consider the following options: 816 1. Dual stack ICN deployment in UE 817 2. Native ICN Deployments in UE 819 3. ICN Deployment in eNodeB 821 4. ICN Deployment in mobile gateways (SGW/PGW) 823 4.4.1 Dual stack ICN Deployments in UE 825 The control and user plane communications in LTE, 4G mobile networks 826 are specified in 3GPP documents [TS23.323] [TS23.203] [TS23.401]. It 827 is important to understand that UE can be either consumer (receiving 828 content) or publisher (pushing content for other clients). The 829 protocol stack inside mobile device (UE) is complex as it has to 830 support multiple radio connectivity access to eNodeB(s). 832 Figure 5 below provides high level description of a protocol stack, 833 where IP is defined at two layers: (1) at user plane communication, 834 (2) Transport layer. User plane communication takes place between 835 Packet Data Convergence Protocol (PDCP) and Application layer, 836 whereas transport layer is at GTP protocol stack. 838 +--------+ +--------+ 839 | App | | CDN | 840 +--------+ +--------+ +--------+ 841 |Transp. | | | | |Transp. | | |Transp. | 842 |Converg.| |..............|...............|.|Converge|.|.|Converge| 843 +--------+ | | | +--------+ | +--------+ 844 | |.|..............|...............|.| |.|.| | 845 | ICN/IP | | | | | ICN/IP | | | ICN/IP| 846 | | | | | | | | | | 847 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 848 | |.|.| | |.|.| | |.|.| | | | | | 849 | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | 850 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 851 | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | 852 +--------+ | +----------+ | +-----------+ | +-----+ | | | | 853 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 854 +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ 855 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 856 +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ 857 UE | BS(enodeB) | SGW | PGW | 858 Uu S1U S5/S8 SGi 860 Fig. 6. Dual stack ICN Deployment in UE 862 The protocol interactions and impact of supporting tunneling of ICN 863 packet into IP or to support ICN natively are described in figure 6 864 and figure 7 respectively. 866 The protocols and software stack used inside LTE capable UE support 867 both 3G and LTE software interworking and handover. Latest 3GPP 868 Rel.13 onward specification describes the use of IP and non-IP 869 protocols to establish logical/session connectivity. We intend to 870 leverage the non-IP protocol based mechanism to deploy ICN protocol 871 stack in UE as well as in eNodeB and mobile gateways (SGW, PGW). 873 +----------------+ +-----------------+ 874 | ICN App (new) | |IP App (existing)| 875 +---------+------+ +-------+---------+ 876 | | 877 +---------+----------------+---------+ 878 | Transport Convergence Layer (new) | 879 +------+---------------------+-------+ 880 | | 881 +------+------+ +------+-------+ 882 |ICN function | | IP function | 883 | (New) | | (Existing) | 884 +------+------+ +------+-------+ 885 | | 886 +------+---------------------+-------+ 887 | PDCP (updated to support ICN) | 888 +-----------------+------------------+ 889 | 890 +-----------------+------------------+ 891 | RLC (Existing) | 892 +-----------------+------------------+ 893 | 894 +-----------------+------------------+ 895 | MAC Layer (Existing) | 896 +-----------------+------------------+ 897 | 898 +-----------------+------------------+ 899 | Physical L1 (Existing) | 900 +------------------------------------+ 902 Fig. 7. Dual stack ICN protocol interactions 904 1. Existing application layer can be modified to provide options 905 for new ICN based application and existing IP based 906 applications. UE can continue to support existing IP based 907 applications or host new applications developed either to 908 support native ICN as transport, ICNoIP or IPoICN based 909 transport. Application layer has the option of selecting either 910 ICN or IP transport layer as well as radio interface to send 911 and receive data traffic. 913 Our proposal is to provide a common Application Programming 914 Interface (API) to the application developers such that there 915 is no impact on the application development when they choose 916 either ICN or IP transport for exchanging the traffic with the 917 network. As mentioned in section 4.2, the transport convergence 918 layer (TCL) function handles the interaction of application 919 with the multiple transport options. 921 2. The transport convergence layer helps determine what type of 922 transport (e.g. ICN or IP) as well as type of radio interface 923 (e.g. LTE or WiFi or both), is used to send and receive the 924 traffic. Application layer can make the decision to select a 925 specific transport based on preference e.g. content location, 926 content type, content publisher, congestion, cost, quality of 927 service etc. There can be an Application Programming Interface 928 (API) to exchange parameters required for transport selection. 929 The southbound interactions of Transport Convergence Layer 930 (TCL) will be either to IP or ICN at the network layer. 932 3. ICN function (forwarder) is introduced in parallel to the 933 existing IP layer. ICN forwarder contains functional 934 capabilities to forward ICN packets, e.g. Interest packet to 935 eNodeB or response "data packet" from eNodeB to the 936 application. 938 4. For dual stack scenario, when UE is not supporting ICN at 939 transport layer, we use IP underlay to transport ICN packets. 940 ICN function will use IP interface to send Interest and Data 941 packets for fetching or sending data using ICN protocol 942 function. This interface will use ICN overlay over IP using any 943 overlay tunneling mechanism. 945 5. To support ICN at network layer in UE, PDCP layer has to be 946 aware of ICN capabilities and parameters. PDCP is located in 947 the Radio Protocol Stack in the LTE Air interface, between IP 948 (Network layer) and Radio Link Control Layer (RLC). PDCP 949 performs following functions [TS36.323]: 951 a) Data transport by listening to upper layer, formatting and 952 pushing down to Radio Link Layer (RLC) 954 b) Header compression and decompression using ROHC (Robust 955 Header Compression) 957 c) Security protections such as ciphering, deciphering and 958 integrity protection 960 d) Radio layer messages associated with sequencing, packet drop 961 detection and re-transmission etc. 963 6. No changes are required for lower layer such as RLC, MAC and 964 Physical (L1) because they are not IP aware. 966 One key point to understand in this scenario is that ICN is deployed 967 as an overlay on top of IP. 969 4.4.2 Native ICN Deployments in UE 971 We propose to implement ICN natively in UE by modifying PDCP layer in 972 3GPP protocols. Figure 7 below provides a high-level protocol stack 973 description where ICN is used at two different layers: 975 1. at user plane communication 977 2. at transport layer 979 User plane communication takes place between PDCP and application 980 layer, whereas transport layer is a substitute of GTP protocol. 981 Removal of GTP protocol stack is significant change in mobile 982 architecture because GTP is used not just for routing but for 983 mobility management functions such as billing, mediation, policy 984 enforcement etc. 986 +--------+ +--------+ 987 | App | | CDN | 988 +--------+ +--------+ 989 |Transp. | | | | | |Transp. | 990 |Converge|.|..............|..............|..............|.|COnverge| 991 +--------+ | | | | +--------+ 992 | |.|..............|..............|..............|.| | 993 | ICN/IP | | | | | | | 994 | | | | | | | | 995 +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | 996 | |.|.| | | | | | | | | | | | 997 | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | 998 +--------+ | +----+ | | | | | | | | | | 999 | RLC |.|.|RLC | | | | | | | | | | | 1000 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1001 | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | 1002 +--------+ | +----------+ | +----------+ | +----------+ | +--------+ 1003 | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | 1004 +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ 1005 UE | BS(enodeB) | SGW | PGW | 1006 Uu S1u S5/S8 SGi 1008 Fig. 8. Native ICN Deployment in UE 1010 If we implement ICN natively in UE, communication between UE and 1011 eNodeB will change and also we will not need to tunnel user plane 1012 traffic from eNodeB to mobile packet core (SGW, PGW) using GTP 1013 tunnel. 1015 For native ICN deployment, Application is configured to use ICN 1016 forwarder so there is no need for Transport Convergence. Also to 1017 support ICN at network layer in UE, we need to modify existing PDCP 1018 layer. PDCP layer has to be aware of ICN capabilities and parameters. 1020 Native implementation will also provide opportunities to develop new 1021 use cases leveraging ICN capabilities such as seamless mobility, UE 1022 to UE content delivery using radio network without interactions with 1023 mobile gateways, etc. 1025 4.5 ICN Deployment in eNodeB 1027 eNodeB is physical point of attachment for UE, where radio protocols 1028 are converted into IP transport protocol as depicted in figure 7 and 1029 figure 8 for dual stack/overlay and native ICN respectively. When UE 1030 performs attach procedures, it is assigned an identity either as IP, 1031 dual stack (IP and ICN), or ICN. UE can initiate data traffic using 1032 any of three different options: 1034 1. Native IP (IPv4 or IPv6) 1036 2. Native ICN 1038 3. Dual stack IP (IPv4/IPv6) or ICN 1040 UE encapsulates user data transport request into PDCP layer and sends 1041 the information on air interface to eNodeB. eNodeB receives the 1042 information and using PDCP [TS 36.323], de-encapsulates air-interface 1043 messages and converts them to forward to core mobile gateways (SGW, 1044 PGW). In order to support ICN natively in eNodeB, it is proposed to 1045 provide transport convergence layer (TCL) capabilities in eNodeB 1046 (similar as provided in UE), which provides following functions: 1048 1. It decides the forwarding strategy for user data request coming 1049 from UE. The strategy can make decision based on preference 1050 indicated by the application such as congestion, cost, quality 1051 of service, etc. 1053 2. eNodeB to provide open Application Programming Interface (API) 1054 to external management systems, to provide capability to eNodeB 1055 to program the forwarding strategies. 1057 3. eNodeB shall be upgraded to support three different types of 1058 transport: IP, ICN, and dual stack IP+ICN towards mobile 1059 gateways, as depicted in figure 9. It is also recommended to 1060 deploy IP and/or ICN forwarding capabilities into eNodeB for 1061 efficient transfer of data between eNodeB and mobile gateways. 1062 There can be four choices for forwarding data request towards 1063 mobile gateways: 1065 a) Assuming eNodeB is IP-enabled and UE requests IP transfer, 1066 eNodeB forwards data over IP. 1068 b) Assuming eNodeB is ICN-enabled and UE requests ICN transfer, 1069 eNodeB forwards data over ICN. 1071 c) Assuming eNodeB is IP-enabled and UE requests ICN, eNodeB 1072 overlays ICN on IP and forwards the user plane traffic over 1073 IP. 1075 d) Assuming eNodeB is ICN-enabled and UE requests IP, eNodeB 1076 overlays IP on ICN and forwards the user plane traffic over 1077 ICN [IPoICN]. 1079 +---------------+ | 1080 | UE request | | ICN +---------+ 1081 +---> | content using |--+--- transport -->| | 1082 | |ICN protocol | | | | 1083 | +---------------+ | | | 1084 | | | | 1085 | +---------------+ | | | 1086 +-+ | | UE request | | IP |To mobile| 1087 | |---+---> | content using |--+--- transport -->| GW | 1088 +-+ | | IP protocol | | |(SGW,PGW)| 1089 UE | +---------------+ | | | 1090 | | | | 1091 | +---------------+ | | | 1092 | | UE request | | Dual stack | | 1093 +---> | content using |--+--- IP+ICN -->| | 1094 |IP/ICN protocol| | transport +---------+ 1095 +---------------+ | 1096 eNodeB S1u 1098 Fig. 9. Native ICN Deployment in eNodeB 1100 4.6 ICN Deployment in Packet Core (SGW, PGW) Gateways 1102 Mobile gateways a.k.a. Evolved Packet Core (EPC) include SGW, PGW, 1103 which perform session management for UE from the initial attach to 1104 disconnection. When UE is powered on, it performs NAS signaling and 1105 after successful authentication it attaches to PGW. PGW is an 1106 anchoring point for UE and responsible for service creations, 1107 authorization, maintenance etc. Entire functionality is managed using 1108 IP address(es) for UE. 1110 In order to implement ICN in EPC, the following functions are needed. 1112 1. Insert ICN function at session management layer as additional 1113 functionality with IP stack. Session management layer is used 1114 for performing attach procedures and assigning logical identity 1115 to user. After successful authentication by HSS, MME sends 1116 create session request (CSR) to SGW and SGW to PGW. 1118 2. When MME sends Create Session Request message (step 12 in 1119 [TS23.401]) to SGW or PGW, it contains Protocol Configuration 1120 Option Information Element (PCO IE) containing UE capabilities. 1121 We can use PCO IE to carry ICN related capabilities information 1122 from UE to PGW. This information is received from UE during the 1123 initial attach request in MME. Details of available TLV, which 1124 can be used for ICN are given in subsequent sections. UE can 1125 support either native IP, or ICN+IP, or native ICN. IP is 1126 referred to as both IPv4 and IPv6 protocols. 1128 3. For ICN+IP capable UE, PGW assigns the UE both IP address and 1129 ICN identity. UE selects either of the identities during the 1130 initial attach procedures and registers with network for 1131 session management. For ICN-capable UE it will provide only ICN 1132 attachment. For native IP-capable UE there is no change. 1134 4. In order to support ICN-capable attach procedures and use ICN 1135 for user plane traffic, PGW needs to have full ICN protocol 1136 stack functionalities. Typical ICN capabilities include 1137 functions such as content store (CS), Pending Interest Table 1138 (PIT), Forwarding Information Base (FIB) capabilities etc. If 1139 UE requests ICN in PCO IE, then PGW registers UE with ICN 1140 names. For ICN forwarding, PGW caches content locally using CS 1141 functionality. 1143 5. Protocol configuration options information elements described 1144 in [TS24.008] (see Figure 10.5.136 on page 598) and [TS24.008] 1145 (see Table 10.5.154 on page 599) provide details for different 1146 fields. 1148 - Octet 3 (configuration protocols defines PDN types) which 1149 contains details about IPv4, IPv6, both or ICN. 1151 - Any combination of Octet 4 to Z can be used to provide 1152 additional information related to ICN capability. It is most 1153 important that PCO IE parameters are matched between UE and 1154 mobile gateways (SGW, PGW) so that they can be interpreted 1155 properly and UE can attach successfully. 1157 6. Deployment of ICN functionalities in SGW and PGW should be 1158 matched with UE and eNodeB because they will exchange ICN 1159 protocols and parameters. 1161 7. Mobile gateways SGW, PGW will also need ICN forwarding and 1162 caching capability. 1164 8. The transport between PGW and CDN provider can be either IP or 1165 ICN. When UE is attached to PGW with ICN identity and 1166 communicates with an ICN-enabled CDN provider, it will use ICN 1167 primitives to fetch the data. On other hand, for an UE attached 1168 with an ICN identity, if PGW has to communicate with an IP- 1169 enabled CDN provider, it will have to use an ICN-IP 1170 interworking gateway to perform conversion between ICN and IP 1171 primitives for data retrieval. Further study is required to 1172 understand how this ICN to IP (and vice versa) interworking 1173 gateway would function. 1175 5. Security Considerations 1177 To ensure only authenticated UEs are connected to the network, LTE 1178 mobile network implements various security mechanisms. From 1179 perspective of ICN deployment in user plane, it needs to take care of 1180 the following security aspects: 1182 1. UE authentication and authorization 1184 2. Radio or air interface security 1186 3. Denial of service attacks on mobile gateway, services 1188 4. Content positioning either in transport or servers 1190 5. Content cache pollution attacks 1192 6. Secure naming, routing, and forwarding 1194 7. Application security 1196 Security over the LTE air interface is provided through cryptographic 1197 technique. When UE is powered up, it performs key exchange between 1198 UE's USIM and HSS/Authentication Center using NAS messages including 1199 ciphering and integrity protections between UE and MME. Details of 1200 secure UE authentication, key exchange, ciphering and integrity 1201 protections messages are given in 3GPP call flow [TS23.401]. 1203 LTE is an all-IP network and uses IP transport in its mobile backhaul 1204 (e.g. between eNodeB and core network). In case of provider owned 1205 backhaul, it may not implement security mechanisms; however, they are 1206 necessary in case it uses shared or a leased network. The native IP 1207 transport continues to leverage security mechanism such as Internet 1208 key exchange (IKE) and the IP security protocol (IPsec). More details 1209 of mobile backhaul security are provided in 3GPP network security 1210 [TS33.310] and [TS33.320]. When mobile backhaul is upgraded to 1211 support dual stack (IP+ICN) or native ICN, it is required to 1212 implement security techniques which are deployed in mobile backhaul. 1213 When ICN forwarding is enabled on mobile transport routers, we need 1214 to deploy security practices based on RFC7476 and RFC7927. 1216 Some of the key functions supported by LTE mobile gateway (SGW, PGW) 1217 are content based billing, deep packet inspection (DPI), and lawful 1218 intercept (LI). For ICN-based user plane traffic, it is required to 1219 integrate ICN security for session between UE and gateway; however, 1220 in ICN network, since only consumers who are in possession of 1221 decryption keys can access the content, some of the services provided 1222 by mobile gateways mentioned above may not work. Further research in 1223 this area is needed. 1225 6. Summary 1227 In this draft, we have discussed complexities of LTE network and key 1228 dependencies for deploying ICN in user plane data transport. 1229 Different deployment options described cover aspects such as inter- 1230 operability and multi-technology, which is a reality for any service 1231 provider. We are currently evaluating the ICN deployment options, 1232 described in section 4, using LTE gateway software and ICN simulator. 1233 One can deploy ICN for data transport in user plane either as an 1234 overlay, dual stack (IP + ICN) or natively (by integrating ICN with 1235 CDN, eNodeB, SGW, PGW and transport network etc.). It is important to 1236 understand that for above discussed deployment scenarios, additional 1237 study is required for lawful interception, billing/mediation, network 1238 slicing, and provisioning APIs. 1240 Based on our study of control plane signaling it is not beneficial to 1241 deploy ICN with existing protocols unless further changes are 1242 introduced in the control protocol stack itself. As mentioned in 1243 [TS23.501], 5G network architecture proposes simplification of 1244 control plane messages and can be a candidate for use of ICN. 1246 As a starting step towards ICN user plane deployment, it is 1247 recommended to incorporate protocol changes in UE, eNodeB, SGW/PGW 1248 for data transport. ICN has inherent capabilities for mobility and 1249 content caching, which can improve the efficiency of data transport 1250 for unicast and multicast delivery. 1252 Mobile Edge Computing (MEC) [CHENG] provides capabilities to deploy 1253 functionalities such as Content Delivery Network (CDN) caching and 1254 mobile user plane functions (UPF) [TS23.501]. Recent research for 1255 delivering real-time video content using ICN has also been proven to 1256 be efficient [NDNRTC] and can be used towards realizing the benefits 1257 of ICN deployment in eNodeB, MEC, mobile gateways (SGW, PGW) and CDN. 1258 The key aspect for ICN is in its seamless integration in LTE and 5G 1259 networks with tangible benefits so that we can optimize content 1260 delivery using simple and scalable architecture. Authors will 1261 continue to explore how ICN forwarding in MEC could be used in 1262 efficient data delivery from mobile edge. 1264 7 References 1266 7.1 Normative References 1268 [GRAYSON] Grayson M, Shatzkamer K, Wainner S.; Cisco Press book "IP 1269 Design for Mobile Networks" by. page 108-112. 1271 [IPSEC1] Cisco IPSec overhead calculator tool 1272 . 1275 [IPSEC2] IPSec Bandwidth Overhead Using AES 1276 . 1279 [BROWER] Brower, E.; Jeffress, L.; Pezeshki, J.; Jasani, R.; 1280 Ertekin, E. "Integrating Header Compression with IPsec", 1281 Military Communications Conference, 2006. MILCOM 2006. 1282 IEEE, On page(s): 1 - 6. 1284 [TS25.323] 3GPP TS25.323 Rel. 14 (2017-03) Packet Data Convergence 1285 Protocol (PDCP) specification. 1287 [TS23.501] 3GPP TS23.501 Rel. 15 (2017-06) System Architecture for 1288 the 5G System. 1290 [TS23.203] 3GPP TS23.203 Rel. 14 (2017-03) Policy and charging 1291 control and QoS architecture 1293 [TS23.401] 3GPP TS23.401 Rel. 14 (2017-03) E-UTRAN Access procedures 1294 architecture 1296 [TS33.310] 3GPP TS33.310 Rel. 14 (2016-12) LTE Network Domain 1297 Security (NDS); Authentication Framework (AF) 1299 [TS33.320] 3GPP TS33.320 Rel. 14 (2016-12) Security of Home Node B 1300 (HNB) / Home evolved Node B (HeNB) 1302 [TS24.008] 3GPP TS24.008 Rel. 14 (2017-06) Mobile radio interface 1303 Layer 3 specification. 1305 [TS23.501] 3GPP TS23.501 Rel. 14 (2017-06) System Architecture for 1306 the 5G System 1308 [TS23.214] 3GPP TS23.214 Rel. 14 (2017-06) Architecture enhancements 1309 for control and user plane separation of EPC nodes 1311 [TS36.323] 3GPP TS36.323 Rel. 14 (2017-06) Evolved Universal 1312 Terrestrial Radio Access (E-UTRA); Packet Data Convergence 1313 Protocol (PDCP) specification 1315 [TS23.714] 3GPP TS23.714 Rel. 14 (2016-06) Technical Specification 1316 Group Services and System Aspects: Study on control and 1317 user plane separation of EPC nodes 1319 [RFC7476] Information-Centric Networking: Baseline Scenarios 1321 [RFC7927] Information-Centric Networking (ICN) Research Challenges 1323 [RFC6459] IPv6 in 3GPP Evolved Packet System (EPS) 1325 7.2 Informative References 1327 [MECSPEC] European Telecommunication Standards Institute (ETSI) MEC 1328 specification ETSI-GS-MEC-IEG-001 V1.1.1 (2015-11). 1330 [NDNTLV] NDN Interest Packet Format Specification 0.2-2. 1331 https://named-data. net/doc/ndn-tlv/interest.html. 1333 [CCNxTLV] CCNx Messages in TLV Format 1334 https://datatracker.ietf.org/doc/draft-irtf-icnrg- 1335 ccnxmessages/ 1337 [NDNPUB] Named Data Networking . 1340 [CCN] Content Centric Networking . 1343 [NDN] Lixia Z., Lan W. et al. SIGCOMM Named Data Networking 1345 [ALM] J. Aug'e, G. Carofiglio et al. "Anchor-less producer 1346 mobility in icn," in Proceedings of the 2Nd ACM Conference 1347 on Information-Centric Networking, ACM-ICN '15, pp. 189- 1348 190, ACM, 2015. 1350 [VNIIDX] Cisco Visual Networking Index (VNI) dated 16 Feb 2016, 1351 . 1354 [NDNRTC] Peter Gusev,Zhehao Wang, Jeff Burke, Lixia Zhang et. All, 1355 IEICE Trans Communication, RealtimeStreaming Data Delivery 1356 over Named Data Networking, Vol E99-B, No.5 May 2016. 1358 [CHENG] Chengchao L., F. Richard Yu, Information-centric network 1359 fucntion virtualization over 5G mobile wireless networks, 1360 IEEE network (Volume:29, Issue:3), page 68-74, 01 June 1361 2015. 1363 [NGMN] Backhaul Provisioning for LTE-Advanced & Small Cells 1364 1367 [IPoICN] IP Over ICN - The Better IP? 1368 1370 [HICN] Cisco Hybrid ICN 1374 [GALIS] Autonomic Slice Networking-Requirements and Reference 1375 Model 1378 Authors' Addresses 1380 Prakash Suthar 1381 9501 Technology Blvd. 1382 Rosemont, Illinois 50618 1384 EMail: psuthar@cisco.com 1386 Milan Stolic 1387 9501 Technology Blvd. 1388 Rosemont, Illinois 50618 1390 EMail: mistolic@cisco.com 1392 Anil Jangam 1393 3625 Cisco Way 1394 San Jose, CA 95134 1395 USA 1397 Email: anjangam@cisco.com 1399 Dirk Trossen 1400 InterDigital Inc. 1401 64 Great Eastern Street, 1st Floor 1402 London EC2A 3QR 1403 United Kingdom 1405 Email: Dirk.Trossen@InterDigital.com