idnits 2.17.1 draft-ravi-icnrg-5gc-icn-02.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 : ---------------------------------------------------------------------------- ** There are 55 instances of too long lines in the document, the longest one being 43 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 date (July 2, 2018) is 2118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7927' is defined on line 1084, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-white-icnrg-ipoc-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG R. Ravindran 3 Internet-Draft Huawei 4 Intended status: Informational P. Suthar 5 Expires: January 3, 2019 Cisco 6 D. Trossen 7 InterDigital Inc. 8 G. White 9 CableLabs 10 July 2, 2018 12 Enabling ICN in 3GPP's 5G NextGen Core Architecture 13 draft-ravi-icnrg-5gc-icn-02 15 Abstract 17 The proposed 3GPP's 5G core nextgen architecture (5GC) offers 18 flexibility to introduce new user and control plane function, 19 considering the support for network slicing functions, that allows 20 greater flexibility to handle heterogeneous devices and applications. 21 In this draft, we provide a short description of the proposed 5GC 22 architecture, followed by extensions to 5GC's control and user plane 23 to support packet data unit (PDU) sessions from information-centric 24 networks. The value of enabling ICN in 5GC is discussed using 25 multiple service scenarios in the context of mobile edge computing 26 such as smart mobility and VR use case, and to enable network 27 services such as seamless mobility for ICN sessions. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 3, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. 5G NextGen Core Design Principles . . . . . . . . . . . . . . 5 66 4. 5G NextGen Core Architecture . . . . . . . . . . . . . . . . 6 67 5. 5GC Architecture with ICN Support . . . . . . . . . . . . . . 8 68 5.1. Control Plane Extensions . . . . . . . . . . . . . . . . 10 69 5.1.1. Normative Interface Extensions . . . . . . . . . . . 12 70 5.2. User Plane Extensions . . . . . . . . . . . . . . . . . . 13 71 5.2.1. Normative Interface Extensions . . . . . . . . . . . 14 72 5.2.2. ICN over non-IP PDU . . . . . . . . . . . . . . . . . 15 73 6. 5G/ICN Deployment Scenarios . . . . . . . . . . . . . . . . . 16 74 6.1. Smart Mobility . . . . . . . . . . . . . . . . . . . . . 16 75 6.1.1. IP-MEC Scenario . . . . . . . . . . . . . . . . . . . 17 76 6.1.2. ICN-MEC Scenario . . . . . . . . . . . . . . . . . . 18 77 6.1.3. IP-over-ICN MEC Scenario . . . . . . . . . . . . . . 18 78 6.2. Multi-viewer Virtual Reality . . . . . . . . . . . . . . 19 79 6.3. ICN Session Mobility . . . . . . . . . . . . . . . . . . 20 80 6.4. Cloud-native (mobile) Operator Environments . . . . . . . 22 81 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 85 11. Informative References . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 The objective of this draft is to propose an architecture to enable 91 information-centric networking (ICN) in the proposed 5G Next- 92 generation Core network architecture (5GC) by leveraging its 93 flexibility to allow new user and associated control plane functions. 95 The reference architectural discussions in the 5G core network 3GPP 96 specifications [TS23.501][TS23.502] form the basis of our 97 discussions. This draft also complements the discussions related to 98 various ICN deployment opportunities explored in 99 [I-D.rahman-icnrg-deployment-guidelines], where 5G technology is 100 considered as one of the promising alternatives. 102 Though ICN is a general networking technology, it would benefit 5G 103 particularly from the perspective of mobile edge computing (MEC). 104 The following ICN features shall benefit MEC deployments in 5G: 106 o Edge Computing: Multi-access Edge Computing (MEC) is located at 107 the edge of the network and aids several latency sensitive 108 applications such as augmented and virtual reality (AR/VR), as 109 well as the ultra reliable and low latency class (URLLC) of 110 applications such as autonomous vehicles. Enabling edge computing 111 over an IP converged 5GC comes with the challenge of application 112 level reconfiguration required to re-initialize a session whenever 113 it is being served by a non-optimal service instance 114 topologically. In contrast, named-based networking, as considered 115 by ICN, naturally supports service-centric networking, which 116 minimizes network related configuration for applications and 117 allows fast resolution for named service instances. 119 o Edge Storage and Caching : A principal design feature of ICN is 120 the secured content (or named-data) object, which allows location 121 independent data replication at strategic storage points in the 122 network, or data dissemination through ICN routers by means of 123 opportunistic caching. These features benefit both realtime and 124 non-realtime applications whenever there is spatial and temporal 125 correlation among content accessed by these users, thereby 126 advantageous to both high-bandwidth and low-latency applications 127 such as conferencing, AR/VR, and non-real time applications such 128 as Video-on-Demand (VOD) and IoT transactions. 130 o Session Mobility: Existing long-term evolution (LTE) deployments 131 handle session mobility using centralized routing using the MME 132 function, IP anchor points at Packet Data Network Gateway (PDN-GW) 133 and service anchor point called Access Point Name (APN) 134 functionality hosted in PDN-GW. LTE uses tunnel between radio 135 edge (eNodeB) and PDN-GW for each mobile device attached to 136 network. This design fails when service instances are replicated 137 close to radio access network (RAN) instances, requiring new 138 techniques to handle session mobility. In contrast, application- 139 bound identifier and name resolution split principle considered 140 for the ICN is shown to handle host mobility quite efficiently 141 [ICNMOB]. 143 In this document, we first discuss 5GC's design principals that 144 allows the support of new network architectures. Then we summarize 145 the 5GC proposal, followed by control and user plane extensions 146 required to support ICN PDU sessions. We then discuss specific 147 network services enabled using ICN data networks, specifically MEC 148 use case scenarios and ICN session mobility with aid from the 5GC 149 control plane. 151 2. Terminology 153 Following are terminologies relevant to this draft: 155 5G-NextGen Core (5GC): Refers to the new 5G core network 156 architecture being developed by 3GPP, we specifically refer to the 157 architectural discussions in [TS23.501][TS23.502]. 159 5G-New Radio (5G-NR): This refers to the new radio access 160 interface developed to support 5G wireless interface [TS-5GNR]. 162 User Plane Function (UPF): UPF is the generalized logical data 163 plane function with context of the UE PDU session. UPFs can play 164 many role, such as, being an flow classifier (UL-CL) (defined 165 next), a PDU session anchoring point, or a branching point. 167 Uplink Classifier (UL-CL): This is a functionality supported by an 168 UPF that aims at diverting traffic (locally) to local data 169 networks based on traffic matching filters applied to the UE 170 traffic. 172 Packet Data Network (PDN or DN): This refers to service networks 173 that belong to the operator or third party offered as a service to 174 the UE. 176 Unified Data Management (UDM): Manages unified data management for 177 wireless, wireline and any other types of subscribers for M2M, IOT 178 applications, etc. UDM reports subscriber related vital 179 information e.g. virtual edge region, list of location visits, 180 sessions active etc. UDM works as a subscriber anchor point so 181 that means OSS/BSS systems will have centralized monitoring-of/ 182 access-to of the system to get/set subscriber information. 184 Authentication Server Function (AUSF): Provides mechanism for 185 unified authentication for subscribers related to wireless, 186 wireline and any other types of subscribers such as M2M and IOT 187 applications. The functions performed by AUSF are similar to HSS 188 with additional functionalities to related to 5G. 190 Session Management Function (SMF): Performs session management 191 functions for attached users equipment (UE) in the 5G Core. SMF 192 can thus be formed by leveraging the CUPS (discussed in the next 193 section) feature with control plane session management. 195 Access Mobility Function (AMF): Perform access mobility management 196 for attached user equipment (UE) to the 5G core network. The 197 function includes, network access stratus (NAS) mobility functions 198 such as authentication and authorization. 200 Application Function (AF): Helps with influencing the user plane 201 routing state in 5GC considering service requirements. 203 Network Slicing: This conceptualizes the grouping for a set of 204 logical or physical network functions with its own or shared 205 control, data and service plane to meet specific service 206 requirements. 208 3. 5G NextGen Core Design Principles 210 The 5GC architecture is based on the following design principles that 211 allows it to support new service networks like ICN efficiently 212 compared to LTE networks:. 214 o Control and User plane split (CUPS): This design principle moves 215 away from LTE's vertically integrated control/user plane design 216 (i.e., Serving Gateway, S-GW, and Packet Data Network Gateway, 217 P-GW) to one espousing an NFV framework with network functions 218 separated from the hardware for service-centricity, scalability, 219 flexibility and programmability. In doing so, network functions 220 can be implemented both physically and virtually, while allowing 221 each to be customized and scaled based on their individual 222 requirements, also allowing the realization of multi-slice co- 223 existence. This feature also allows the introduction of new user 224 plane functions (UPF) in 5GC. UPFs can play many roles, such as, 225 being an uplink flow classifier (UL-CL), a PDU session anchor 226 point, a branching point function, or one based on new network 227 architectures like ICN with new control functions, or re-using/ 228 extending the existing ones to manage the new user plane 229 realizations. 231 o Decoupling of RAT and Core Network : Unlike LTE's unified control 232 plane for access and the core, 5GC offers control plane separation 233 of the RAN from the core network. This allows the introduction of 234 new radio access technologies (RAT) along with slices based on new 235 network architectures, offering the ability to map heterogeneous 236 RAN flows to arbitrary core network slices based on service 237 requirements. 239 o Non-IP PDU Session Support : A PDU session is defined as the 240 logical connection between the UE and the data network (DN). 5GC 241 offers a scope to support both IP and non-IP PDU (termed as 242 "unstructured" payload), and this feature can potentially allow 243 the support for ICN PDUs by extending or re-using the existing 244 control functions. More discussions on taking advantage of this 245 feature in ICN's context is presented in Section 5.2.2. 247 o Service Centric Design: 5GC's service orchestration and control 248 functions, such as naming, addressing, registration/authentication 249 and mobility, will utilize API design similar to those used in 250 cloud technologies. Doing so enables opening up interfaces for 251 authorized service function interaction and creating service level 252 extensions to support new network architectures. These APIs 253 include the well accepted Get/Response and Pub/Sub approaches, 254 while not precluding the use of point-to-point procedural approach 255 among 5GC functional units (where necessary). 257 4. 5G NextGen Core Architecture 259 In this section, for brevity purposes, we restrict the discussions to 260 the control and user plane functions relevant to an ICN deployment 261 discussion in Section 5. More exhaustive discussions on the various 262 architecture functions, such as registration, connection and 263 subscription management, can be found in[TS23.501][TS23.502]. 265 +---------+ +--------+ 266 +--------+ | PCF/UDM | +------+ | AF-2 | 267 | NSSF | | | | AF-1 | +-----+--+ 268 +---+----+ +-----+---+ +--+---+ | 269 | | | +--+--------+ 270 +---+------------+-+ +-----+------+ | | 271 | |N11| | | SMF-2 | 272 | AMF +---+ SMF-1 | | | 273 | | | | +---------+-+ 274 +--------+-+-------+ +----+-------+ | 275 | | |-----------------------------------+ 276 +------------------+ | | |N4 |N4 277 N1 | |N2 |N4 | +--------+-----------+ 278 | | | +---------+ UPF | N6 +------+ 279 +-------------+-+ +----------+------+ +---+-----------+ | | |(PDU Session Anchor)+----+ DN | 280 | | | | | | N9 | | | | | | 281 | UE | | RAN | N3 | UL-CL +----+ | +--------------------+ +------+ 282 | +-------+ +-----+ | | 283 | | | | | +----+ +-----------------+ 284 +---------------+ +-----------------+ +---------------+ N9 | | 285 | +----------+---------+ 286 +---------+ | +--------+ 287 | UPF | N6 | DN | 288 |(PDU Session Anchor)+----+ | 289 | | +--------+ 290 +--------------------+ 292 Figure 1: 5G Next Generation Core Architecture 294 In Figure 1, we show one variant of a 5GC architecture from 295 [TS23.501], for which the functions of UPF's branching point and PDU 296 session anchoring are used to support inter-connection between a UE 297 and the related service or packet data networks (or PDNs) managed by 298 the signaling interactions with control plane functions. In 5GC, 299 control plane functions can be categorized as follows: 301 o Common control plane functions that are common to all slices and 302 which include the Network Slice Selection Function (NSSF), Policy 303 Control Function (PCF), and Unified Data Management (UDM) among 304 others. 306 o Shared or slice specific control functions, which include the 307 Access and Mobility Function (AMF), Session and Management 308 Function (SMF) and the Application Function (AF). 310 AMF serves multiple purposes: (i) device authentication and 311 authorization; (ii) security and integrity protection to non-access 312 stratum (NAS) signaling; (iii) tracking UE registration in the 313 operator's network and mobility management functions as the UE moves 314 among different RANs, each of which might be using different radio 315 access technologies (RAT). 317 NSSF handles the selection of a particular slice for the PDU session 318 request from the user entity (UE) using the Network Slice Selection 319 Assistance Information (NSSAI) parameters provided by the UE and the 320 configured user subscription policies in PCF and UDM functions. 321 Compared to LTE's evolved packet core (EPC), where PDU session states 322 in RAN and core are synchronized with respect to management, 5GC 323 decouples this using NSSF by allowing PDU sessions to be defined 324 prior to a PDU session request by a UE (for other differences see 325 [lteversus5g] ). This decoupling allows policy based inter- 326 connection of RAN flows with slices provisioned in the core network. 327 This functionality is useful particularly towards new use cases 328 related to M2M and IOT devices requiring pre-provisioned network 329 resources to ensure appropriate SLAs. 331 SMF is used to handle IP anchor point selection and addressing 332 functionality, management of the user plane state in the UPFs (such 333 as in uplink classifier (UL-CL), IP anchor point and branching point 334 functions) during PDU session establishment, modification and 335 termination, and interaction with RAN to allow PDU session forwarding 336 in uplink/downlink (UL/DL) to the respective DNs. SMF decisions are 337 also influenced by AF to serve application requirements, for e.g., 338 actions related to introducing edge computing functions. 340 In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN 341 protocol[TS-5GNR]. From the RAN, the PDU's five tuple header 342 information (IP source/destination, port, protocol etc.) is used to 343 map the flow to an appropriate tunnel from RAN to UPF. Though the 344 current 5GC proposal[TS23.501] follows LTE on using GPRS tunneling 345 protocol (GTP) tunnel from NR to the UPF to carry data PDUs and 346 another one for the control messages to serve the control plane 347 functions; there are ongoing discussions to arrive upon efficient 348 alternatives to GTP. 350 5. 5GC Architecture with ICN Support 352 In this section, we focus on control and user plane enhancements 353 required to enable ICN within 5GC, and identify the interfaces that 354 require extensions to support ICN PDU sessions. Explicit support for 355 ICN PDU sessions within access and 5GC networks will enable 356 applications to leverage the core ICN features while offering it as a 357 service to 5G users. 359 +------------+ 360 | 5G | 361 | Services | 362 | (NEF) | +----------------+ 363 +-------+----+ | ICN | 364 | +----------+ Service | 365 | | | Orchestrator | 366 | | +-----------+----++ 367 +-------+ +---------+ Npcf++/Nudm++ ++------+ | 368 | NSSF | | PCF/UDM +---------------------------------+ ICN-AF| | 369 +----+--+ | | | | +---+--------------+ 370 | +--+------+ +---+---+ | ICN | 371 | | | +------+ Service/Network | 372 +-+--------+--+ +---------------+ +------+-------+ | | Controller | 373 | | N11++ | |Naf++ | +----+ +------------+-----+ 374 | AMF++ +-----------+ SMF++ +------+ ICN-SMF | | 375 | | | | | | | 376 +------+-+----+ +----+-----+----+ +------------+-+ | 377 | | | | NIcn | 378 +-----------------+ | | +----------+ | 379 | | | | | 380 | +------+ N4 | | | 381 N1++ | | | | | 382 | | N2 | +------------+-+ +----+-----+ 383 | | | +----------+ | | | 384 | | | | N9 | ICN-GW +--------+ ICN-DN | 385 | | +-----+-----+ | | + UPF | N6 | | 386 +------+--+ +---------+--+ | | | +---+----------+ +----------+ 387 | | |RAN +-----+ | | UL-CL/ +-----+ 388 | ICN-UE +-------------+ |UPF | | | Branching | 389 | | | +-----+ +-----------+ Point | 390 | | | +-------+ | N3 | +-----+ +------------+ 391 +---------+ | | ICN-GW| | +-----------+ | | Local | 392 | +-------+ | | N9 | ICN-DN | 393 +------------+ +-----------+ | 394 +------------+ 396 Figure 2: 5G Next Generation Core Architecture with ICN support 398 For an ICN-enabled 5GC network, the assumption is that the UE may 399 have applications that can run over ICN or IP, for instance, UE's 400 operating system offering applications to operate over ICN [Jacobson] 401 or IP-based networking sockets. There may also be cases where UE is 402 exclusively based on ICN. In either case, we identify an ICN enabled 403 UE as ICN-UE. Different options exist to implement ICN in UE as 404 described in [I-D.suthar-icnrg-icn-lte-4g] which is also applicable 405 for 5G UE to enable formal ICN session handling, such as, using a 406 transport convergence layer above 5G-NR, through IP address 407 assignment from 5GC or using 5GC provision of using unstructured PDU 408 session mode during the PDU session establishment process, which is 409 discussed in Section 5.2.2. Such convergence layer would implement 410 necessary IP over ICN mappings, such as those described in [TROSSEN], 411 for IP-based applications that are assigned to be transported over an 412 ICN network. 5G UE can also be non-mobile devices or an IOT device 413 using radio specification which can operate based on [TS-5GNR]. 415 5GC will take advantage of network slicing function to instantiate 416 heterogeneous slices, the same framework can be extended to create 417 ICN slices as well [Ravindran]. This discussion also borrows ideas 418 from[TS23.799], which offers a wide range of architectural 419 discussions and proposals on enabling slices and managing multiple 420 PDU sessions with local networks (with MEC) and its associated 421 architectural support (in the service, control and data planes) and 422 procedures within the context of 5GC. 424 Figure 2 shows the proposed ICN-enabled 5GC architecture. In the 425 figure, the new and modified functional components are identified 426 that interconnects an ICN-DN with 5GC. The interfaces and functions 427 that require extensions to enable ICN as a service in 5GC can be 428 identified in the figure with a '++' symbol. We next summarize the 429 control, user plane and normative interface extensions that help with 430 the formal ICN support. 432 5.1. Control Plane Extensions 434 To support interconnection between ICN UEs and the appropriate ICN DN 435 instances, we consider the following additional control plane 436 extensions to orchestrate ICN services in coordination with 5GC's 437 control components. 439 o Authentication and Mobility Function (AMF++): ICN applications in 440 the UEs have to be authorized to access ICN DNs. For this 441 purpose, as in [TS23.501], operator enables ICN as a DN offering 442 ICN services. As a network service, ICN-UE should also be 443 subscribed to it and this is imposed using the PCF and UDM, which 444 may interface with the ICN Application Function (ICN-AF) for 445 subscription and session policy management of ICN PDU sessions. 446 To enable ICN stack in the UE, AMF++ function has to be enabled 447 with the capability of authenticating UE's attach request for ICN 448 resources in 5GC. The request can be incorporated in NSSI 449 parameter to request either ICN specific slice or using ICN in 450 existing IP network slice when the UE is dual stacked. AMF++ can 451 potentially be extended to also support ICN specific bootstrapping 452 (such as naming and security) and forwarding functions to 453 configure UE's ICN layer. These functions can also be handled by 454 the ICN-AF and ICN control function in the UE after setting PDU 455 session state in 5GC. Here, the recommendation is not about 456 redefining the 5G UE attach procedures, but to extend the attach 457 procedures messages to carry ICN capabilities extensions in 458 addition to supporting existing IP based services. The extensions 459 should allow a 5G UE to request authentication to 5GC either in 460 ICN, IP or dual-stack (IP and ICN) modes. Further research is 461 required to optimize 5G attach procedures so that an ICN capable 462 UE can be bootstrapped by minimizing the number of control plane 463 messages. One possibility is to leverage existing 5G UE attach 464 procedures as described in 3GPP's [TS23.502], where the UE can 465 provide ICN identity in the LTE equivalent protocol configuration 466 option information element (PCO-IE) message during the attach 467 request as described in [I-D.suthar-icnrg-icn-lte-4g]. In 468 addition, such requirement can be also be provided by the UE in 469 NSSI parameters during initial attach procedures. Alternately, 470 ICN paradigm offers name-based control plane messaging and 471 security which one can leverage during the 5G UE attach 472 procedures, however this requires further research. 474 o Session Management Function (SMF++): Once a UE is authenticated to 475 access ICN service in network, SMF manages to connect UE's ICN PDU 476 sessions to the ICN DN in the UL/DL. SMF++ should be capable to 477 manage both IP, ICN or dual stack UE with IP and ICN capabilities. 478 To support ICN sessions, SMF++ creates appropriate PDU session 479 policies in the UPF, which include UL-CL and ICN gateway (ICN-GW) 480 (discussed in Section 5.2) through the ICN-SMF. For centrally 481 delivered services, ICN-GW could also multiplex as an IP anchor 482 point for IP applications. If MEC is enabled, these two functions 483 would be distributed, as the UL-CL will re-route the flow to a 484 local ICN-DN. 3GPP has defined IP based session management 485 procedures to handle UE PDU sessions in TS23.502. For ICN UE we 486 can either leverage same procedures when ICN is deployed as an 487 overlay protocol. Towards this, SMF++ interfaces with AMF++ over 488 N11++ to enable ICN specific user plane functions, which include 489 tunnel configuration and traffic filter policy to inter-connect UE 490 with the appropriate radio and the core slice. Furthermore, AMF++ 491 sets appropriate state in the RAN and the UE that directs ICN 492 flows to the chosen ICN UL-CL in the core network, and towards the 493 right UE in the downlink. 495 o ICN Session Management Function (ICN-SMF): ICN-SMF serves as 496 control plane for the ICN state managed in ICN-GW. This function 497 can be either incorporated as part of SMF++ or as a stand-alone 498 one. This function interacts with SMF++ to obtain and also push 499 ICN PDU session management information for the creation, 500 modification and deletion of ICN PDU sessions in ICN-GW. For 501 instance, when new ICN slices are provisioned by the ICN service 502 orchestrator, ICN-SMF requests a new PDU session to the SMF that 503 extends to the RAN. While SMF++ manages the tunnels to 504 interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate 505 forwarding state in ICN-GW (using the forwarding information base 506 or FIB) to enable ICN flows over appropriate tunnel interfaces 507 managed by the SMF++. In addition, it also signals resource 508 management rules to share compute, bandwidth, storage/cache 509 resources among multiple slice instances co-located in the ICN-GW. 511 o ICN Application Function (ICN-AF): ICN-AF represents the 512 application controller function that interfaces with ICN-SMF and 513 PCF/UDM function in 5GC. In addition to transferring ICN 514 forwarding rules to ICN-SMF, ICN-AF also interfaces with PCF/UDM 515 to transfer user profile and subscription policies along with 516 session management requirement to UE's ICN PDU session in the 5GC 517 network. ICN-AF is an extension of the ICN service orchestration 518 function, which can influence both ICN-SMF and in-directly SMF++ 519 to steer traffic based on ICN service requirements. ICN-AF can 520 also interact with the northbound 5G operator's service functions, 521 such as network exposure function(NEF) that exposes network 522 capabilities, for e.g. location based services, that can be used 523 by ICN-AF for proactive ICN PDU session and slice management and 524 offer additional capabilities to the ICN slices. 526 5.1.1. Normative Interface Extensions 528 o N1++/N11++: This extension enables ICN specific control functions 529 to support ICN authentication, configuration and programmability 530 of an ICN-UE via AMF++ and SMF++, and also impose QoS 531 requirements, handle mobility management of an ICN PDU session in 532 5GC based on service requirements. 534 o N4: Though this signaling is service agnostic, as discussed in 535 Section 5.2, future extensions may include signaling to enable ICN 536 user plane features in these network functions. The extension of 537 N4 to RAN is to handle the case when UPF function collocates with 538 the RAN instance to enable localized ICN DNs. 540 o NIcn: This extension shall support two functions: (i) control 541 plane programmability to enable ICN PDU sessions applicable to 5GC 542 to map to name based forwarding rules in ICN-GW; (ii)control plane 543 extensions to enable ICN mobility anchoring at ICN-GW, in which 544 case it also acts as POA for ICN flows. Features such as ICN 545 mobility as a service can be supported with this extension 546 [ICNMOB]. 548 o Naf++: This extension supports 5GC control functions such as 549 naming, addressing, mobility, and tunnel management for ICN PDU 550 sessions to interact with SMF++ and AMF++. 552 o Npcf++/Nudm++: This extension creates an interface to push ICN 553 service and PDU session requirements to PCF and UDM functions that 554 interact with the ICN-AF function for ICN slice specific 555 configuration. These requirements are enforced at various steps, 556 for instance, during ICN application registration, authentication, 557 slice mapping, and provisioning of resources for these PDU 558 sessions in the UPF. 560 5.2. User Plane Extensions 562 The interconnection of a UE to an ICN-DN comprises of two segments, 563 one from RAN to UL-CL and the other from UL-CL to ICN-GW. These 564 segments use IP tunneling constructs, where the service semantic 565 check at UL-CL is performed using IP's five tuples to determine both 566 UL and DL tunnel mappings. We summarize the relevant UPFs and the 567 interfaces for handling ICN PDU sessions as follows. 569 o ICN Gateway (ICN-GW): ICN-GW is where the 5GC PDU sessions 570 terminate and ICN service network begins. Compared to the 571 traditional anchor points as in PGW, the ICN-GW is also a service 572 gateway as it can host services or cache content enabled through 573 the ICN architecture. The ICN-GW also includes the UPF functions 574 to manage multiple tunnel interfaces enabling the relay of ICN PDU 575 flows to appropriate UL-CL instances in the DL. Note that there 576 may be multiple ICN-GWs serving different ICN services or slices. 577 ICN-GW also manages other ICN functions such as enforcing the 578 dynamic name based forwarding state, mobility state, in-network 579 service function management, resource management with respect to 580 sharing caching, storage, and compute resources among multiple 581 services[Ravindran]. 583 o ICN Packet Data Network (ICN-(P)DN): ICN-DN represents a set of 584 ICN nodes used for ICN networking and with heterogeneous service 585 resources such as storage and computing points. An ICN network 586 enables both network and application services, with network 587 services including caching, mobility, multicast, multi-path 588 routing (and possibly network layer computing), and application 589 services including network resources (such as cache, storage, 590 network state resources) dedicated to the application. 592 * Considering multiple ICN architecture proposals and multiple 593 ICN deployment models discussed in 594 [I-D.rahman-icnrg-deployment-guidelines], an alternate backward 595 compatible (IP-over-)ICN solution is proposed in [TROSSEN]. 597 Such an ICN-(P)DN can simply consist of SDN forwarding nodes 598 and a logically centralized path computation entity (PCE), 599 where the PCE is used to determine suitable forwarding 600 identifiers being used for the path-based forwarding in the 601 SDN-based transport network. In addition, the PCE is 602 responsible for maintaining the appropriate forwarding rules in 603 the SDN switches. For interconnection to IP-based peering 604 networks, a packet gateway is being utilized that mirrors the 605 convergence layer functionality to map incoming ICN traffic 606 back in to outgoing IP traffic and vice versa. This form of 607 deployment would require minimal changes to the 5GC's user and 608 control plane procedures, as the applications on these IP end 609 points are not exposed (or minimally exposed) to any ICN state 610 or configuration. 612 o Uplink Classifier (UL-CL): UL-CL enables classification of flows 613 based on source or destination IP address and steers the traffic 614 to an appropriate network or service function anchor point. If 615 the ICN-GW is identified based on service IP address associated 616 with the ICN-UE's flows, UL-CL checks the source or destination 617 address to direct traffic to an appropriate ICN-GW. For native 618 ICN UE, ICN shall be deployed over 5G-NR; here, there may not be 619 any IP association. For such packet flows new classification 620 schema shall be required, such as, using 5G-NR protocol extensions 621 to determine the tunnel interface to forward the ICN payload on, 622 towards the next ICN-GW. 624 5.2.1. Normative Interface Extensions 626 o N3: Though the current architecture supports heterogeneous service 627 PDU handling, future extensions can include user plane interface 628 extensions to offer explicit support to ICN PDU session traffic, 629 for instance, an incremental caching and computing function in RAN 630 or UL-CL to aid with content distribution. 632 o N9: Extensions to this interface can consider UPFs to enable 633 richer service functions, for instance to aid context processing. 634 In addition extensions to enable ICN specific encapsulation to 635 piggyback ICN specific attributes such as traffic or mobility data 636 between the UPF branching point and the ICN-GW. 638 o N6: This interface is established between the ICN-GW and the ICN- 639 DN, whose networking elements in this segment can be deployed as 640 an overlay or as a native Layer-3 network. 642 5.2.2. ICN over non-IP PDU 644 5GC accommodates non-IP PDU support which is defined for Ethernet or 645 any unstructured data[TS23.501]. This feature allows native support 646 of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS 647 itself as shown in Figure 2. Formalizing this feature to recognize 648 ICN PDUs has many considerations: 650 o Attach Procedures for UE with Non-IP PDN: Assuming a 5GC can 651 support both IP and non-IP PDN, this requires control plane 652 support, as discussed in Section 5. In a typical scenario, when 653 UE sends an attach message to 5GC, the type of PDU connection is 654 indicated in the PCO-IE field, for e.g. in this case as being non- 655 IP PDN to invoke related control plane session management tasks. 656 ICN over non-IP PDU session will allow the UE to attach to 5GC 657 without any IP configuration. 5GC attach procedures specified 658 [TS23.501] can be used to support authentication of UE with PDN 659 type set to non-IP, using existing AUSF/UDM functions in 660 coordination with the ICN-AF function discussed earlier if 661 required. 663 o User Plane for UE with Non-IP PDN: Without any IP tunnel 664 configuration and ICN's default consumer agnostic mode of 665 operation requires ways to identify the ICN-UE in the user plane, 666 this can be enabled by introducing network identifier in the lower 667 layers such as in the PDCP or MAC layer, that can assist for 668 functions such as policy and charging at the BS and related 669 session management tasks. These identifiers can also be used to 670 demultiplex the DL traffic from the ICN-GW in the BS to the 671 respective ICN-UEs. Also, ICN extensions can be incorporated in 672 control plane signaling to identify an ICN-UE device and these 673 parameters can be used by SMF to conduct non-IP routing. The 674 policing and charging functions can be enforced by the UPF 675 function in the BS which obtains the traffic filtering rules from 676 the SMF. To enable flat ICN network from the BS requires 677 distributed policy, charging and legal intercept which requires 678 further research. Further ICN slice multiplexing can be realized 679 by also piggybacking slice-ID (NSSI) along with device ID to 680 differentiate handover to multiple ICN slices at the base station. 681 Inter-working function (IWF) is required if services based on non- 682 IP UE has to transact or communicate with transport, applications 683 functions or other UE based on IP services. This also has 684 implications on how mobility is managed for such PDU sessions. 686 o Mobility Handling: Considering mobility can be support by ICN, it 687 is inefficient to traverse other intermediate IP networks between 688 the BS and the next ICN hop. This requires ICN PDU to be handled 689 by an ICN instance in the BS itself, in association with UL-CL 690 function local to the BS as shown in Figure 2. Control plane 691 extensions discussed in Section 5 can be used in tandem with 692 distributed mobility protocols to handle ICN mobility, one such 693 solution for producer mobility is proposed in [ICNMOB] 695 o Routing Considerations: Flat ICN network realizations also offers 696 the advantage of optimal routing, compared to anchor point based 697 realization in LTE. This also leads to optimal realization of the 698 data plane considering the absence of overhead due to tunneling 699 while forwarding ICN traffic. However, developing a routing 700 control plane in to handle the ICN PDU sessions either leveraging 701 SMF functions or a distributed realization requires more 702 investigation. In the centralized approach the SMF could interact 703 with ICN-SMF to set the forwarding rules in the ICN-GW in the BS 704 and other ICN-UPFs, however this may also lead to scalability 705 issues if a flat ICN network is to be realized. This also has 706 implications to route the non-IP PDU sessions efficiently to the 707 closest ICN-MEC instance of the service. 709 o IP over ICN: Native support of ICN in the RAN raises the 710 possibility of leveraging the mobility functions in ICN protocols 711 as a replacement for GTP tunneling in the 5GC, as described in 712 [I-D.white-icnrg-ipoc]. 714 o Mobile Edge Computing: Another significant advantage is with 715 respect to service-centric edge computing at the ICN-GW or other 716 ICN points, either through explicit hosting of service 717 functions[VSER] in ICN or in-network computing based on NFN 718 proposal[NFN]. A certain level of orchestration, as discussed in 719 Section 5, is required to ensure service interconnection and its 720 placement with appropriate compute resources and inter-connected 721 with bandwidth resources so that the desired SLA is offered. 723 6. 5G/ICN Deployment Scenarios 725 Here we discuss two relevant network services enabled using ICN in 726 5G. 728 6.1. Smart Mobility 730 We consider here a radio edge service requiring low latency, high 731 capacity and strict quality of service. For the discussion in this 732 draft, we analyze connected vehicle scenario, where the car's 733 navigation system (CNS) uses data from the edge traffic monitoring 734 (TM-E) service instance to offer rich and critical insights on the 735 road conditions (such as real-time congestion assisted with media 736 feeds). This is aided using traffic sensing (TS) information 737 collected through vehicle-to-vehicle (V2V) communication over 738 dedicated short-range communications (DSRC) radio by the TS-E, or 739 using road-side sensor units (RSU) from which this information can be 740 obtained. The TS-E instances then push this information to a central 741 traffic sensing instance (TS-C). This information is used by the 742 central traffic monitoring service (TM-C) to generate useable 743 navigation information, which can then be periodically pushed to or 744 pulled by the edge traffic monitoring service (TM-E) to respond to 745 requests from vehicle's CNS. For this scenario, our objective is to 746 compare advantages of offering this service over an IP based MEC 747 versus one based on ICN. We can generalize the following discussion 748 to other MEC applications as well. 750 6.1.1. IP-MEC Scenario 752 Considering the above scenario, when a vehicle's networking system 753 comes online, it first undergoes an attachment process with the 5G- 754 RAN, which includes authentication, IP address assignment and DNS 755 discovery. The attachment process is followed by PDU session 756 establishment, which is managed by SMF signaling to UL-CL and the UPF 757 instance. When the CNS application initializes, it assumes this IP 758 address as its own ID and tries to discover the closest service 759 instance. Local DNS then resolves the service name to a local MEC 760 service instance. Accordingly, CNS learns the IP service point 761 address and uses that to coordinate between traffic sensing and 762 monitoring applications. 764 CNS is a mission critical application requiring instant actions which 765 is accurate and reliable all the time. Delay of microsecond or non- 766 response could result in fatalities. Following are main challenges 767 with the IP-MEC design: 769 o At the CNS level, non-standardization of the naming schema results 770 in introducing an application level gateway to adapt the sensing 771 data obtained from DSRC system to IP networks, which becomes 772 mandatory if the applications are from different vendors. 774 o As the mobility results in handover between RAN instances, 775 service-level or 5GC networking-level mechanisms need to be 776 initiated to discover a better TM-E instance, which may affect the 777 service continuity and result in session reestablishment that 778 introduces additional control/user plane overheads. 780 o Data confidentiality among multiple CNS attached 5G RAN, 781 authentication and privacy control are offered through an SSL/TLS 782 mechanism over the transport channel, which has to be re- 783 established whenever the network layer attributes are reset. 785 6.1.2. ICN-MEC Scenario 787 If the CNS application is developed over ICN either natively or as an 788 overlay over IP, ICN shall allows the same named data logic to 789 operate over heterogeneous interfaces (such as DSRC radio, and IP 790 transport-over-5G, unlicensed radio over WiFi etc. link), thereby 791 avoiding the need for application layer adaptations. 793 We can list the advantages of using ICN-based MEC as follows: 795 o Compared to IP, ICN is unique in supporting both infrastructure 796 and ad hoc communication. This makes it suitable to support 797 communication in vehicular ad hoc networks (VANETS) [Guilio], 798 along with communication to the infrastructure components like the 799 road side units to serve the needs of several smart mobility 800 applications. ICN's name based APIs enables it to operate over 801 multiple heterogeneous radio interfaces simultaneously in 802 broadcast, unicast or anycast modes of communication that can be 803 taken advantage of in a given context. 805 o As vehicles within a single road segment are likely to seek the 806 same data, ICN-based MEC allows to leverage opportunistic caching 807 and storage enabled at ICN-GW, thereby avoiding service level 808 unicast transmissions. 810 o Processed and stored traffic data can be easily contextualized to 811 different user requirements. 813 o Appropriate mobility handling functions can be used depending on 814 mobility type (as consumer or producer), specifically, when an 815 ICN-UE moves from one RAN instance to another, the next IP hop, 816 which identifies the ICN-GW function, has to be re-discovered. 817 Unlike the IP-MEC scenario, this association is not exposed to the 818 applications. As discussed earlier, control plane extensions to 819 AMF and SMF can enable re-programmability of the ICN layer in the 820 vehicle to direct it towards a new ICN-GW, or to remain with the 821 same ICN-GW, based on optimization requirements. 823 o As ICN offers content-based security, produced content can be 824 consumed while authenticating it at the same time (i.e., allowing 825 any data produced to diffuse to its point of use through named 826 data networking). 828 6.1.3. IP-over-ICN MEC Scenario 830 The above application can also be realized in the context of an IP- 831 over-ICN deployment scenario discussed in Section 5.2. In this case, 832 we assume the operation of the IP-based MEC application over the ICN 833 bearer. The ICN-based methods being used for service registration 834 ensure that routing of CNS service requests reach the 'nearest' 835 service instance (near in topological distance), while utilizing path 836 updates at the CNS endpoint to handle mobility of the vehicle. If 837 assuming HTTP-level (or similar CoAP-level) access to the sensing 838 data, the same TM-E instance can return a single Layer 2 level 839 multicast (assuming a SDN-based L2 sub-system) response to all CNS of 840 passing car that have been requesting the sensing data within a 841 configurable time interval. The ICN-based registration of the TM-E 842 service also allows for secure content delegation being implemented 843 where secured content is being diffused to in-network caching points 844 while the original HTTP/CoAP-level sensing request is directed to the 845 secure content server rather than the origin server, avoiding 846 inefficient triangular routing when doing so. 848 6.2. Multi-viewer Virtual Reality 850 VR services are nowadays implemented as HTTP-based file chunk 851 retrieval systems where the file chunk is determined by the viewing 852 angle of the VR headset. Hence, within the same content scenario, 853 consumers exhibiting the same viewing angle relative to the content 854 will exhibit the same access patterns towards the content storage. 855 Nonetheless, IP-based delivery of the VR service will result in 856 separate HTTP unicast sessions being established to each VR headset. 857 When running instead the headset in IP-over-ICN mode (with a dual- 858 stack realization or a single stack UE with the convergence layer as 859 outlined in [I-D.suthar-icnrg-icn-lte-4g], we can now utilize the 860 multicast capabilities of the underlying ICN system to deliver any 861 access to the same file chunk as a multicast message from the content 862 storage to the individual headset UEs using L2 multicast. When 863 viewing angles diverge among headsets, the degree of overlap will do 864 the same and the multicast efficiency will change accordingly albeit 865 in an ad-hoc, instantaneous manner, i.e., not requiring any 866 reconfiguration of underlying transport resources (such as multicast 867 groups). Such multi-viewer VR capability can be utilized in a number 868 of use cases, such as for events at specific site, e.g., stadiums, in 869 an MEC-like deployment. Other use cases could foresee utilizing such 870 capability for remote education scenarios from a single VR server, 871 e.g., provisioned by a school, towards a class of students located at 872 5G-connected homes or premises This capability of improving on 873 existing HTTP-based VR services via such convergence layer based IP- 874 over-ICN mechanisms has been successfully demonstrated at trade-shows 875 in 2017. 877 6.3. ICN Session Mobility 879 Mobility scenario assumes a general ICN-UE handover from S-RAN to 880 T-RAN, where each of them is served by different UPFs, i.e., UL-CL-1 881 and UL-CL-2. We also assume that UL-CL-1 and UL-CL-2 use different 882 gateways, referred to as ICN-GW-1 and ICN-GW-2. From an ICN 883 perspective, we discuss here the producer mobility case, which can be 884 handled in multiple ways, one of which is proposed in 885 [ICNMOB].However, the details of the ICN mobility solution are 886 orthogonal to this discussion. Here, ICN-UE refers to an application 887 producer (e.g., video conferencing application, from which ICN 888 consumers request real-time content. Here we also assume the absence 889 of any direct physical interface, Xn, between the two RANs. The 890 current scenario follows the handover procedures discussed in 891 [TS23.502], with focus here on integrating it with an ICN-GW and ICN- 892 DN, where mobility state of the ICN sessions are handled. 894 The overall signaling overhead to handle seamless mobility also 895 depends on the deployment models discussed in Section 4. Here we 896 consider the case when RAN, UL-CL and ICN-GW are physically disjoint; 897 however in the case where RAN and UL-CL are co-located then a part of 898 the signaling to manage the tunnel state between the RAN and UL-CL is 899 localized, which then improves the overall signaling efficiency. 900 This can be further extended to the case when ICN-GWs are co-located 901 with the RAN and UL-CL, leading to further simplification of the 902 mobility signaling. 904 Next, we discuss the high-level steps involved during handover. 906 o Step 1: When the ICN-UE decides to handover from S-RAN to T-RAN, 907 ICN-UE signals the S-RAN with a handover-request indicating the 908 new T-RAN it is willing to connect. This message includes the 909 affected PDU session IDs from the 5GC perspective, along with the 910 ICN names that require mobility support. 912 o Step 2: S-RAN then signals the AMF serving the ICN-UE about the 913 handover request. The request includes the T-RAN details, along 914 with the affected ICN PDU sessions. 916 o Step 3: Here, when SMF receives the ICN-UE's and the T-RAN 917 information, it identifies UL-CL-2 as the better candidate to 918 handle the ICN PDU sessions to T-RAN. In addition, it also 919 identifies ICN-GW-2 as the appropriate gateway for the affected 920 ICN PDU sessions. 922 o Step 4: SMF signals the details of the affected PDU sessions along 923 with the traffic filter rules to switch the UL traffic from UL- 924 CL-2 to ICN-GW-2 and DL flows from UL-CL-2 to T-RAN. 926 o Step 5: SMF then signals ICN-SMF about the PDU session mobility 927 change along with the information on UL-CL-2 for it to provision 928 the tunnel between ICN-GW-2 and UL-CL-2. 930 o Step 6: Based on the signaling received on the ICN PDU session, 931 ICN-SMF identifies the affected gateways, i.e., ICN-GW-1 and ICN- 932 GW-2: (i) ICN-SMF signals ICN-GW-2 about the affected PDU session 933 information to update its DL tunnel information to UL-CL-2. Then, 934 based on the ICN mobility solution, appropriate ICN mobility state 935 to switch the future incoming Interests from ICN-GW-1 to UL-CL-2; 936 (ii) ICN-SMF also signals ICN-GW-1 with the new forwarding 937 label[ICNMOB] to forward the incoming Interest traffic to ICN-GW- 938 2. This immediately causes the new Interest payload for the ICN- 939 UE to be send to the new ICN gateway in a proactive manner. 941 o Step 7: ICN-SMF then acknowledges SMF about the successful 942 mobility update. Upon this, the SMF then acknowledges AMF about 943 the state changes related to mobility request along with the 944 tunnel information that is required to inter-connect T-RAN with 945 UL-CL-2. 947 o Step 8: AMF then updates the T-RAN PDU session state in order to 948 tunnel ICN-UE's PDU sessions from T-RAN to UL-CL-2. This is 949 followed by initiating the RAN resource management functions to 950 reserve appropriate resources to handle the new PDU session 951 traffic from the ICN-UE. 953 o Step 9: AMF then signals the handover-ack message to the UE, 954 signaling it to handover to the T-RAN. 956 o Step 10: UE then issues a handover-confirm message to T-RAN. At 957 this point, all the states along the new path comprising the 958 T-RAN, UL-CL-2 and ICN-GW-2 is set to handle UL-DL traffic between 959 the ICN-UE and the ICN-DN. 961 o Step 11: T-RAN then signals the AMF on its successful connection 962 to the ICN-UE. AMF then signals S-RAN to remove the allocated 963 resources to the PDU session from the RAN and the tunnel state 964 between S-RAN and UL-CL-1. 966 o Step 12: AMF then signals SMF about the successful handover, upon 967 which SMF removes the tunnel states from UL-CL-1. SMF then 968 signals the ICN-SMF, which then removes the ICN mobility state 969 related to the PDU session from ICN-GW-1. Also at this point, 970 ICN-SMF can signal the ICN-NRS (directly or through ICN-GW-2) to 971 update the UE-ID resolution information, which now points to ICN- 972 GW-2 [ICNMOB]. 974 Note that, inter-RAN handover mapping to the same UL-CL represents a 975 special case of the above scenario. 977 6.4. Cloud-native (mobile) Operator Environments 979 At the recent NGMN (next generation mobile networks) Forum in Paris 980 in April 2018, a so-called 'cloud-native environment' for mobile 981 operators was presented. This view on the realization of both the 982 control and eventually also the data plane in 5G networks foresees 983 the use of regionalized data centres over a software-defined wide 984 area network. Here, traditional network control functions are re- 985 interpreted as 'services' over an HTTP application layer protocol, 986 i.e., moving the network function view (based on peer relations) to a 987 fully fledged service-based architecture. The NGMN presentation 988 included a demonstration of a first fully SDN-based realization of 989 such view, utilizing IP-over-ICN [TROSSEN] routing capabilities for 990 HTTP-based control plane service invocations. The benefits of 991 utilizing such capabilities lie in the flexible and fast redirection 992 capability to the nearest service instance, for which the demo used 993 container-based virtualization techniques. Although the demo itself 994 was not (yet) integrated into the 5G sub-system according to 995 Figure 2, it showed the capabilities of utilizing ICN as an underlay. 996 Although the focus of the demonstration lied on control plane 997 service, the same solution has successfully demonstrated data plane 998 services, such as those discussed in Section 6.1.3 and Section 6.2. 1000 7. Conclusion 1002 In this draft, we explore the feasibility of realizing future 1003 networking architectures like ICN within the proposed 3GPP's 5GC 1004 architecture. Towards this, we summarized the design principles that 1005 offer 5GC the flexibility to enable new network architectures. We 1006 then discuss 5GC architecture along with the user/control plane 1007 extensions required to handle ICN PDU sessions formally. We then 1008 apply the proposed architecture to two relevant services that ICN 1009 networks can enable: first, mobile edge computing over ICN versus the 1010 traditional IP approach considering a connected car scenario, and 1011 argue based on architectural benefits; second, handling ICN PDU 1012 session mobility in ICN-DN rather than using IP anchor points, with 1013 minimal support from 5GC. 1015 8. IANA Considerations 1017 This document requests no IANA actions. 1019 9. Security Considerations 1021 This draft proposes extensions to support ICN in 5G's next generation 1022 core architecture. ICN being name based networking opens up new 1023 security and privacy considerations which have to be studied in the 1024 context of 5GC. This is in addition to other security considerations 1025 of 5GC for IP or non-IP based services considered in [TS33.899]. 1027 10. Acknowledgments 1029 ... 1031 11. Informative References 1033 [Guilio] Grassi, G., Pesavento, D., Pau, G., Vayyuru, R., Wakikawa, 1034 Ryuji., Wakikawa, Ryuji., and Lixia. Zhang, "Vehicular 1035 Inter-Networking via Named Data", ACM Hot Mobile (Poster), 1036 2013. 1038 [I-D.rahman-icnrg-deployment-guidelines] 1039 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1040 "Deployment Considerations for Information-Centric 1041 Networking (ICN)", draft-rahman-icnrg-deployment- 1042 guidelines-05 (work in progress), January 2018. 1044 [I-D.suthar-icnrg-icn-lte-4g] 1045 suthar, P., Stolic, M., Jangam, A., and D. Trossen, 1046 "Native Deployment of ICN in LTE, 4G Mobile Networks", 1047 draft-suthar-icnrg-icn-lte-4g-04 (work in progress), 1048 November 2017. 1050 [I-D.white-icnrg-ipoc] 1051 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 1052 Tunneling over Content Centric Mobile Networks", draft- 1053 white-icnrg-ipoc-01 (work in progress), June 2018. 1055 [ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 1056 "Seamless Producer Mobility as a Service in Information 1057 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 1058 2016. 1060 [IEEE_Communications] 1061 Trossen, D. and G. Parisis, "Designing and Realizing an 1062 Information-Centric Internet", Information-Centric 1063 Networking, IEEE Communications Magazine Special Issue, 1064 2012. 1066 [Jacobson] 1067 Jacobson, V. and et al., "Networking Named Content", 1068 Proceedings of ACM Context, , 2009. 1070 [lteversus5g] 1071 Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and 1072 functions for 5G mobile communication system.", ICT 1073 Express 2017, 2017. 1075 [NFN] Sifalakis, M., Kohler, B., Christopher, C., and C. 1076 Tschudin, "An information centric network for computing 1077 the distribution of computations", ACM, ICN Sigcomm, 2014. 1079 [Ravindran] 1080 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1081 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1082 Network Slicing", IEEE Communication Magazine, May, 2016. 1084 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1085 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1086 "Information-Centric Networking (ICN) Research 1087 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1088 . 1090 [TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M., and 1091 G. Xylomenos, "IP Over ICN - The Better IP ?", EuCNC, 1092 European Conference on Networks and Communications , July, 1093 2015. 1095 [TS-5GNR] 3GPP-38-xxx, "Technical Specification series on 5G-NR 1096 (Rel.15)", 3GPP , 2017. 1098 [TS23.501] 1099 3gpp-23.501, "Technical Specification Group Services and 1100 System Aspects; System Architecture for the 5G System 1101 (Rel.15)", 3GPP , 2017. 1103 [TS23.502] 1104 3gpp-23.502, "Technical Specification Group Services and 1105 System Aspects; Procedures for the 5G System(Rel. 15)", 1106 3GPP , 2017. 1108 [TS23.799] 1109 3gpp-23.799, "3rd Generation Partnership Project; 1110 Technical Specification Group Services and System Aspects; 1111 Study on Architecture for Next Generation System (Rel. 1112 14)", 3GPP , 2017. 1114 [TS33.899] 1115 3gpp-33.899, "Study on the security aspects of the next 1116 generation system", 3GPP , 2017. 1118 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1119 Wang, "Towards software defined ICN based edge-cloud 1120 services", CloudNetworking(CloudNet), IEEE Internation 1121 Conference on, IEEE Internation Conference on 1122 CloudNetworking(CloudNet), 2013. 1124 Authors' Addresses 1126 Ravi Ravindran 1127 Huawei Research Center 1128 2330 Central Expressway 1129 Santa Clara 95050 1130 USA 1132 Email: ravi.ravindran@huawei.com 1133 URI: http://www.Huawei.com/ 1135 Prakash Suthar 1136 Cisco Systems 1137 9501 Technology Blvd. 1138 Rosemont 50618 1139 USA 1141 Email: psuthar@cisco.com 1142 URI: http://www.cisco.com/ 1144 Dirk Trossen 1145 InterDigital Inc. 1146 64 Great Eastern Street, 1st Floor 1147 London EC2A 3QR 1148 United Kingdom 1150 Email: Dirk.Trossen@InterDigital.com 1151 URI: http://www.InterDigital.com/ 1152 Greg White 1153 InterDigital Inc. 1154 858 Coal Creek Circle 1155 Louisville CO 80027 1156 USA 1158 Email: g.white@cablelabs.com