idnits 2.17.1 draft-ravi-icnrg-5gc-icn-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 : ---------------------------------------------------------------------------- ** There are 6 instances 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 date (March 6, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Guilio' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 1543, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-01 == Outdated reference: A later version (-02) exists of draft-white-icnrg-ipoc-01 Summary: 1 error (**), 0 flaws (~~), 5 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: September 7, 2019 Cisco 6 D. Trossen 7 C. Wang 8 InterDigital Inc. 9 G. White 10 CableLabs 11 March 6, 2019 13 Enabling ICN in 3GPP's 5G NextGen Core Architecture 14 draft-ravi-icnrg-5gc-icn-03 16 Abstract 18 The proposed 3GPP's 5G core nextgen architecture (5GC) offers 19 flexibility to introduce new user and control plane function, 20 considering the support for network slicing functions, that allows 21 greater flexibility to handle heterogeneous devices and applications. 22 In this draft, we provide a short description of the proposed 5GC 23 architecture, followed by extensions to 5GC's control and user plane 24 to support Packet Data Unit (PDU) sessions from Information-Centric 25 Networks (ICN). The value of enabling ICN in 5GC is discussed using 26 IP-based service scenarios in the context of 5G Local Area Networks 27 (5GLAN). 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 September 7, 2019. 46 Copyright Notice 48 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 14 73 5.2.3. Dual Stack ICN Deployment . . . . . . . . . . . . . . 16 74 6. 5GC Architecture with 5GLAN Support . . . . . . . . . . . . . 23 75 6.1. Background: LAN-based End-to-End Packet Forwarding in 5G 23 76 6.1.1. Realization in Existing Transport Networks . . . . . 25 77 6.2. IP-based Service over ICN over 5GLAN . . . . . . . . . . 26 78 6.2.1. General Operations . . . . . . . . . . . . . . . . . 28 79 6.2.2. ICN API to Upper Layers . . . . . . . . . . . . . . . 29 80 6.2.3. HTTP over ICN . . . . . . . . . . . . . . . . . . . . 30 81 6.2.4. Ad-Hoc Multicast for HTTP over ICN . . . . . . . . . 30 82 6.2.5. Service Proxy Operations . . . . . . . . . . . . . . 31 83 6.2.6. ICN Flow Management . . . . . . . . . . . . . . . . . 31 84 6.2.7. NR Operations . . . . . . . . . . . . . . . . . . . . 31 85 6.2.8. Mobility Handling . . . . . . . . . . . . . . . . . . 32 86 6.2.9. Dual Stack Device Support . . . . . . . . . . . . . . 32 87 6.3. ICN over 5GLAN . . . . . . . . . . . . . . . . . . . . . 32 88 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 92 11. Informative References . . . . . . . . . . . . . . . . . . . 33 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 95 1. Introduction 97 The objective of this draft is to propose an architecture to enable 98 information-centric networking (ICN) in the proposed 5G Next- 99 generation Core network architecture (5GC) by leveraging its 100 flexibility to allow new user and associated control plane functions. 101 The reference architectural discussions in the 5G core network 3GPP 102 specifications [TS23.501][TS23.502] form the basis of our 103 discussions. This draft also complements the discussions related to 104 various ICN deployment opportunities explored in 105 [I-D.rahman-icnrg-deployment-guidelines], where 5G technology is 106 considered as one of the promising alternatives. 108 Though ICN is a general networking technology, it would benefit 5G 109 particularly from the perspective of mobile edge computing (MEC). 110 The following ICN features shall benefit MEC deployments in 5G: 112 o Edge Computing: Multi-access Edge Computing (MEC) is located at 113 the edge of the network and aids several latency sensitive 114 applications such as augmented and virtual reality (AR/VR), as 115 well as the ultra reliable and low latency class (URLLC) of 116 applications such as autonomous vehicles. Enabling edge computing 117 over an IP converged 5GC comes with the challenge of application 118 level reconfiguration required to re-initialize a session whenever 119 it is being served by a non-optimal service instance 120 topologically. In contrast, named-based networking, as considered 121 by ICN, naturally supports service-centric networking, which 122 minimizes network related configuration for applications and 123 allows fast resolution for named service instances. 125 o Edge Storage and Caching : A principal design feature of ICN is 126 the secured content (or named-data) object, which allows location 127 independent data replication at strategic storage points in the 128 network, or data dissemination through ICN routers by means of 129 opportunistic caching. These features benefit both realtime and 130 non-realtime applications whenever there is spatial and temporal 131 correlation among content accessed by these users, thereby 132 advantageous to both high-bandwidth and low-latency applications 133 such as conferencing, AR/VR, and non-real time applications such 134 as Video-on-Demand (VOD) and IoT transactions. 136 o Session Mobility: Existing long-term evolution (LTE) deployments 137 handle session mobility using centralized routing using the MME 138 function, IP anchor points at Packet Data Network Gateway (PDN-GW) 139 and service anchor point called Access Point Name (APN) 140 functionality hosted in PDN-GW. LTE uses tunnel between radio 141 edge (eNodeB) and PDN-GW for each mobile device attached to 142 network. This design fails when service instances are replicated 143 close to radio access network (RAN) instances, requiring new 144 techniques to handle session mobility. In contrast, application- 145 bound identifier and name resolution split principle considered 146 for the ICN is shown to handle host mobility quite efficiently 147 [ICNMOB]. 149 In this document, we first discuss 5GC's design principals that 150 allows the support of new network architectures. Then we summarize 151 the 5GC proposal, followed by control and user plane extensions 152 required to support ICN PDU sessions. We then discuss specific 153 network services enabled using ICN data networks, specifically MEC 154 use case scenarios and ICN session mobility with aid from the 5GC 155 control plane. 157 2. Terminology 159 Following are terminologies relevant to this draft: 161 5G-NextGen Core (5GC): Refers to the new 5G core network 162 architecture being developed by 3GPP, we specifically refer to the 163 architectural discussions in [TS23.501][TS23.502]. 165 5G-New Radio (5G-NR): This refers to the new radio access 166 interface developed to support 5G wireless interface [TS38.300]. 168 User Plane Function (UPF): UPF is the generalized logical data 169 plane function with context of the UE PDU session. UPFs can play 170 many role, such as, being an flow classifier (UL-CL) (defined 171 next), a PDU session anchoring point, or a branching point. 173 Uplink Classifier (UL-CL): This is a functionality supported by an 174 UPF that aims at diverting traffic (locally) to local data 175 networks based on traffic matching filters applied to the UE 176 traffic. 178 Packet Data Network (PDN or DN): This refers to service networks 179 that belong to the operator or third party offered as a service to 180 the UE. 182 Unified Data Management (UDM): Manages unified data management for 183 wireless, wireline and any other types of subscribers for M2M, IOT 184 applications, etc. UDM reports subscriber related vital 185 information e.g. virtual edge region, list of location visits, 186 sessions active etc. UDM works as a subscriber anchor point so 187 that means OSS/BSS systems will have centralized monitoring-of/ 188 access-to of the system to get/set subscriber information. 190 Authentication Server Function (AUSF): Provides mechanism for 191 unified authentication for subscribers related to wireless, 192 wireline and any other types of subscribers such as M2M and IOT 193 applications. The functions performed by AUSF are similar to HSS 194 with additional functionalities to related to 5G. 196 Session Management Function (SMF): Performs session management 197 functions for attached users equipment (UE) in the 5G Core. SMF 198 can thus be formed by leveraging the CUPS (discussed in the next 199 section) feature with control plane session management. 201 Access Mobility Function (AMF): Perform access mobility management 202 for attached user equipment (UE) to the 5G core network. The 203 function includes, network access stratus (NAS) mobility functions 204 such as authentication and authorization. 206 Application Function (AF): Helps with influencing the user plane 207 routing state in 5GC considering service requirements. 209 Network Slicing: This conceptualizes the grouping for a set of 210 logical or physical network functions with its own or shared 211 control, data and service plane to meet specific service 212 requirements. 214 3. 5G NextGen Core Design Principles 216 The 5GC architecture is based on the following design principles that 217 allows it to support new service networks like ICN efficiently 218 compared to LTE networks: 220 o Control and User plane split (CUPS): This design principle moves 221 away from LTE's vertically integrated control/user plane design 222 (i.e., Serving Gateway, S-GW, and Packet Data Network Gateway, 223 P-GW) to one espousing an NFV framework with network functions 224 separated from the hardware for service-centricity, scalability, 225 flexibility and programmability. In doing so, network functions 226 can be implemented both physically and virtually, while allowing 227 each to be customized and scaled based on their individual 228 requirements, also allowing the realization of multi-slice co- 229 existence. This feature also allows the introduction of new user 230 plane functions (UPF) in 5GC. UPFs can play many roles, such as, 231 being an uplink flow classifier (UL-CL), a PDU session anchor 232 point, a branching point function, or one based on new network 233 architectures like ICN with new control functions, or re-using/ 234 extending the existing ones to manage the new user plane 235 realizations. 237 o Decoupling of RAT and Core Network : Unlike LTE's unified control 238 plane for access and the core, 5GC offers control plane separation 239 of the RAN from the core network. This allows the introduction of 240 new radio access technologies (RAT) along with slices based on new 241 network architectures, offering the ability to map heterogeneous 242 RAN flows to arbitrary core network slices based on service 243 requirements. 245 o Non-IP PDU Session Support : A PDU session is defined as the 246 logical connection between the UE and the data network (DN). 5GC 247 offers a scope to support both IP and non-IP PDU (termed as 248 "unstructured" payload), and this feature can potentially allow 249 the support for ICN PDUs by extending or re-using the existing 250 control functions. More discussions on taking advantage of this 251 feature in ICN's context is presented in Section 5.2.2. 253 o Service Centric Design: 5GC's service orchestration and control 254 functions, such as naming, addressing, registration/authentication 255 and mobility, will utilize API design similar to those used in 256 cloud technologies. Doing so enables opening up interfaces for 257 authorized service function interaction and creating service level 258 extensions to support new network architectures. These APIs 259 include the well accepted Get/Response and Pub/Sub approaches, 260 while not precluding the use of point-to-point procedural approach 261 among 5GC functional units (where necessary). 263 o Distributed LAN Support: utilizing the aforementioned unstructured 264 PDU session support, 5GC offers the capability to expose a Layer 2 265 LAN service to cellular user equipment. Such distributed LAN 266 targets to complement those in fixed broadband, including local 267 WLAN fanouts. Through such LAN capability, services can be 268 realized by being virtually embedded into an intranet deployment 269 with dedicated Internet-facing packet gateway functionality. 270 Examples for such services, among others, are those related to 271 Industrial IoT, smart city services and others. Utilizing this 272 capability for ICN-based services is presented in Section 6. 274 4. 5G NextGen Core Architecture 276 In this section, for brevity purposes, we restrict the discussions to 277 the control and user plane functions relevant to an ICN deployment 278 discussion in Section 5. More exhaustive discussions on the various 279 architecture functions, such as registration, connection and 280 subscription management, can be found in[TS23.501][TS23.502]. 282 +------+ 283 +-----+ +-------+ +------+ | AF-2 | 284 |NSSF | |PCF/UDM| | AF-1 | +---+--+ 285 +--+--+ +--+----+ +--+---+ | 286 | | | +---+---+ 287 +--+-------+--+ +---+-----+ | | 288 | |N11| | | SMF-2 | 289 | AMF +---+ SMF-1 | | | 290 | | | | +---+---+ 291 +----+----+---+ +----+----+ | 292 | | |------------------------+ 293 +---+ | | |N4 |N4 294 N1| |N2 |N4 | +----------+---------+ 295 | | | +----+ UPF | N6 +----+ 296 +-+-+ +--+--+ +---+---+ | | |(PDU Session Anchor)+----+ DN | 297 | | | | | | N9 | | | | | | 298 |UE | | RAN | N3 | UPF +----+ | +--------------------+ +----+ 299 | +---+ +-----+(UL-CL)| | 300 | | | | | +----+ +-------------+ 301 +---+ +-----+ +-------+ N9 | | 302 | +----------+---------+ 303 +----+ UPF | +----+ 304 |(PDU Session Anchor)| N6 | DN | 305 | +----+ | 306 +--------------------+ +----+ 308 Figure 1: 5G Next Generation Core Architecture 310 In Figure 1, we show one variant of a 5GC architecture from 311 [TS23.501], for which the functions of UPF's branching point and PDU 312 session anchoring are used to support inter-connection between a UE 313 and the related service or packet data networks (or PDNs) managed by 314 the signaling interactions with control plane functions. In 5GC, 315 control plane functions can be categorized as follows: 317 o Common control plane functions that are common to all slices and 318 which include the Network Slice Selection Function (NSSF), Policy 319 Control Function (PCF), and Unified Data Management (UDM) among 320 others. 322 o Shared or slice specific control functions, which include the 323 Access and Mobility Function (AMF), Session and Management 324 Function (SMF) and the Application Function (AF). 326 AMF serves multiple purposes: (i) device authentication and 327 authorization; (ii) security and integrity protection to non-access 328 stratum (NAS) signaling; (iii) tracking UE registration in the 329 operator's network and mobility management functions as the UE moves 330 among different RANs, each of which might be using different radio 331 access technologies (RAT). 333 NSSF handles the selection of a particular slice for the PDU session 334 request from the user entity (UE) using the Network Slice Selection 335 Assistance Information (NSSAI) parameters provided by the UE and the 336 configured user subscription policies in PCF and UDM functions. 337 Compared to LTE's evolved packet core (EPC), where PDU session states 338 in RAN and core are synchronized with respect to management, 5GC 339 decouples this using NSSF by allowing PDU sessions to be defined 340 prior to a PDU session request by a UE (for other differences see 341 [lteversus5g] ). This decoupling allows policy based inter- 342 connection of RAN flows with slices provisioned in the core network. 343 This functionality is useful particularly towards new use cases 344 related to M2M and IOT devices requiring pre-provisioned network 345 resources to ensure appropriate SLAs. 347 SMF is used to handle IP anchor point selection and addressing 348 functionality, management of the user plane state in the UPFs (such 349 as in uplink classifier (UL-CL), IP anchor point and branching point 350 functions) during PDU session establishment, modification and 351 termination, and interaction with RAN to allow PDU session forwarding 352 in uplink/downlink (UL/DL) to the respective DNs. SMF decisions are 353 also influenced by AF to serve application requirements, for e.g., 354 actions related to introducing edge computing functions. 356 In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN 357 protocol[TS38.300]. From the RAN, the PDU's five tuple header 358 information (IP source/destination, port, protocol etc.) is used to 359 map the flow to an appropriate tunnel from RAN to UPF. Though the 360 current 5GC proposal[TS23.501] follows LTE on using GPRS tunneling 361 protocol (GTP) tunnel from NR to the UPF to carry data PDUs and 362 another one for the control messages to serve the control plane 363 functions; there are ongoing discussions to arrive upon efficient 364 alternatives to GTP. 366 5. 5GC Architecture with ICN Support 368 In this section, we focus on control and user plane enhancements 369 required to enable ICN within 5GC, and identify the interfaces that 370 require extensions to support ICN PDU sessions. Explicit support for 371 ICN PDU sessions within access and 5GC networks will enable 372 applications to leverage the core ICN features while offering it as a 373 service to 5G users. 375 +------------+ 376 | 5G | 377 | Services | 378 | (NEF) | +----------------+ 379 +-------+----+ | ICN | 380 | +--------+ Service | 381 | | | Orchestrator | 382 | | +-------+--------+ 383 +----+ +-------+ Npcf++/Nudm++ +-+---+-+ | 384 |NSSF| |PCF/UDM+-----------------+ ICN-AF| | 385 +-+--+ +-+-----+ +---+---+ +------+--------+ 386 | | | | ICN | 387 | | | +---+Service/Network| 388 +-+------+-+ +-------+ +---+---+ | | Controller | 389 | |N11++ | |Naf++ | +---+ +-----------+---+ 390 | AMF++ +------+ SMF++ +------+ICN-SMF| | 391 | | | | | | | 392 +----+--+--+ +---+---+ +---+---+ | 393 | | | |NIcn | 394 | +-------+ +-------+ +----------+ | 395 | | | | | 396 | | | +---+--+ +--+---+ 397 |N1++ |N2 |N4 | | | | 398 | | | +----+ICN-GW+------+ICN-DN| 399 | | +----+----+ | N9 | +UPF | N6 | | 400 +----+-+ +-----+----+ | | | +------+ +------+ 401 | | |RAN +----+| | UL-CL/ +---+ 402 |ICN-UE+--+ |UPF || |Branching| 403 | | | +----++---+ Point | 404 | | | +------+| N3| +---+ +------+ 405 +------+ | |ICN-GW|| +---------+ | N9 | Local| 406 | +------+| +----+ICN-DN| 407 +----------+ +------+ 409 Figure 2: 5G Next Generation Core Architecture with ICN support 411 For an ICN-enabled 5GC network, the assumption is that the UE may 412 have applications that can run over ICN or IP, for instance, UE's 413 operating system offering applications to operate over ICN [Jacobson] 414 or IP-based networking sockets. There may also be cases where UE is 415 exclusively based on ICN. In either case, we identify an ICN enabled 416 UE as ICN-UE. Different options exist to implement ICN in UE as 417 described in [I-D.suthar-icnrg-icn-lte-4g] which is also applicable 418 for 5G UE to enable formal ICN session handling, such as, using a 419 Transport Convergence Layer (TCL) above 5G-NR, through IP address 420 assignment from 5GC or using 5GC provision of using unstructured PDU 421 session mode during the PDU session establishment process, which is 422 discussed in Section 5.2.2. Such convergence layer would implement 423 necessary IP over ICN mappings, such as those described in [TROSSEN], 424 for IP-based applications that are assigned to be transported over an 425 ICN network. 5G UE can also be non-mobile devices or an IOT device 426 using radio specification which can operate based on [TS38.300]. 428 5GC will take advantage of network slicing function to instantiate 429 heterogeneous slices, the same framework can be extended to create 430 ICN slices as well [Ravindran]. This discussion also borrows ideas 431 from[TS23.799], which offers a wide range of architectural 432 discussions and proposals on enabling slices and managing multiple 433 PDU sessions with local networks (with MEC) and its associated 434 architectural support (in the service, control and data planes) and 435 procedures within the context of 5GC. 437 Figure 2 shows the proposed ICN-enabled 5GC architecture. In the 438 figure, the new and modified functional components are identified 439 that interconnects an ICN-DN with 5GC. The interfaces and functions 440 that require extensions to enable ICN as a service in 5GC can be 441 identified in the figure with a '++' symbol. We next summarize the 442 control, user plane and normative interface extensions that help with 443 the formal ICN support. 445 5.1. Control Plane Extensions 447 To support interconnection between ICN UEs and the appropriate ICN DN 448 instances, we consider the following additional control plane 449 extensions to orchestrate ICN services in coordination with 5GC's 450 control components. 452 o Authentication and Mobility Function (AMF++): ICN applications in 453 the UEs have to be authorized to access ICN DNs. For this 454 purpose, as in [TS23.501], operator enables ICN as a DN offering 455 ICN services. As a network service, ICN-UE should also be 456 subscribed to it and this is imposed using the PCF and UDM, which 457 may interface with the ICN Application Function (ICN-AF) for 458 subscription and session policy management of ICN PDU sessions. 459 To enable ICN stack in the UE, AMF++ function has to be enabled 460 with the capability of authenticating UE's attach request for ICN 461 resources in 5GC. The request can be incorporated in NSSI 462 parameter to request either ICN specific slice or using ICN in 463 existing IP network slice when the UE is dual stacked. AMF++ can 464 potentially be extended to also support ICN specific bootstrapping 465 (such as naming and security) and forwarding functions to 466 configure UE's ICN layer. These functions can also be handled by 467 the ICN-AF and ICN control function in the UE after setting PDU 468 session state in 5GC. Here, the recommendation is not about 469 redefining the 5G UE attach procedures, but to extend the attach 470 procedures messages to carry ICN capabilities extensions in 471 addition to supporting existing IP based services. The extensions 472 should allow a 5G UE to request authentication to 5GC either in 473 ICN, IP or dual-stack (IP and ICN) modes. Further research is 474 required to optimize 5G attach procedures so that an ICN capable 475 UE can be bootstrapped by minimizing the number of control plane 476 messages. One possibility is to leverage existing 5G UE attach 477 procedures as described in 3GPP's [TS23.502], where the UE can 478 provide ICN identity in the LTE equivalent protocol configuration 479 option information element (PCO-IE) message during the attach 480 request as described in [I-D.suthar-icnrg-icn-lte-4g]. In 481 addition, such requirement can be also be provided by the UE in 482 NSSI parameters during initial attach procedures. Alternately, 483 ICN paradigm offers name-based control plane messaging and 484 security which one can leverage during the 5G UE attach 485 procedures, however this requires further research. 487 o Session Management Function (SMF++): Once a UE is authenticated to 488 access ICN service in network, SMF manages to connect UE's ICN PDU 489 sessions to the ICN DN in the UL/DL. SMF++ should be capable to 490 manage both IP, ICN or dual stack UE with IP and ICN capabilities. 491 To support ICN sessions, SMF++ creates appropriate PDU session 492 policies in the UPF, which include UL-CL and ICN gateway (ICN-GW) 493 (discussed in Section 5.2) through the ICN-SMF. For centrally 494 delivered services, ICN-GW could also multiplex as an IP anchor 495 point for IP applications. If MEC is enabled, these two functions 496 would be distributed, as the UL-CL will re-route the flow to a 497 local ICN-DN. 3GPP has defined IP based session management 498 procedures to handle UE PDU sessions in TS23.502. For ICN UE we 499 can either leverage same procedures when ICN is deployed as an 500 overlay protocol. Towards this, SMF++ interfaces with AMF++ over 501 N11++ to enable ICN specific user plane functions, which include 502 tunnel configuration and traffic filter policy to inter-connect UE 503 with the appropriate radio and the core slice. Furthermore, AMF++ 504 sets appropriate state in the RAN and the UE that directs ICN 505 flows to the chosen ICN UL-CL in the core network, and towards the 506 right UE in the downlink. 508 o ICN Session Management Function (ICN-SMF): ICN-SMF serves as 509 control plane for the ICN state managed in ICN-GW. This function 510 can be either incorporated as part of SMF++ or as a stand-alone 511 one. This function interacts with SMF++ to obtain and also push 512 ICN PDU session management information for the creation, 513 modification and deletion of ICN PDU sessions in ICN-GW. For 514 instance, when new ICN slices are provisioned by the ICN service 515 orchestrator, ICN-SMF requests a new PDU session to the SMF that 516 extends to the RAN. While SMF++ manages the tunnels to 517 interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate 518 forwarding state in ICN-GW (using the forwarding information base 519 or FIB) to enable ICN flows over appropriate tunnel interfaces 520 managed by the SMF++. In addition, it also signals resource 521 management rules to share compute, bandwidth, storage/cache 522 resources among multiple slice instances co-located in the ICN-GW. 524 o ICN Application Function (ICN-AF): ICN-AF represents the 525 application controller function that interfaces with ICN-SMF and 526 PCF/UDM function in 5GC. In addition to transferring ICN 527 forwarding rules to ICN-SMF, ICN-AF also interfaces with PCF/UDM 528 to transfer user profile and subscription policies along with 529 session management requirement to UE's ICN PDU session in the 5GC 530 network. ICN-AF is an extension of the ICN service orchestration 531 function, which can influence both ICN-SMF and in-directly SMF++ 532 to steer traffic based on ICN service requirements. ICN-AF can 533 also interact with the northbound 5G operator's service functions, 534 such as network exposure function(NEF) that exposes network 535 capabilities, for e.g. location based services, that can be used 536 by ICN-AF for proactive ICN PDU session and slice management and 537 offer additional capabilities to the ICN slices. 539 5.1.1. Normative Interface Extensions 541 o N1++/N11++: This extension enables ICN specific control functions 542 to support ICN authentication, configuration and programmability 543 of an ICN-UE via AMF++ and SMF++, and also impose QoS 544 requirements, handle mobility management of an ICN PDU session in 545 5GC based on service requirements. 547 o N4: Though this signaling is service agnostic, as discussed in 548 Section 5.2, future extensions may include signaling to enable ICN 549 user plane features in these network functions. The extension of 550 N4 to RAN is to handle the case when UPF function collocates with 551 the RAN instance to enable localized ICN DNs. 553 o NIcn: This extension shall support two functions: (i) control 554 plane programmability to enable ICN PDU sessions applicable to 5GC 555 to map to name based forwarding rules in ICN-GW; (ii)control plane 556 extensions to enable ICN mobility anchoring at ICN-GW, in which 557 case it also acts as POA for ICN flows. Features such as ICN 558 mobility as a service can be supported with this extension 559 [ICNMOB]. 561 o Naf++: This extension supports 5GC control functions such as 562 naming, addressing, mobility, and tunnel management for ICN PDU 563 sessions to interact with SMF++ and AMF++. 565 o Npcf++/Nudm++: This extension creates an interface to push ICN 566 service and PDU session requirements to PCF and UDM functions that 567 interact with the ICN-AF function for ICN slice specific 568 configuration. These requirements are enforced at various steps, 569 for instance, during ICN application registration, authentication, 570 slice mapping, and provisioning of resources for these PDU 571 sessions in the UPF. 573 5.2. User Plane Extensions 575 The interconnection of a UE to an ICN-DN comprises of two segments, 576 one from RAN to UL-CL and the other from UL-CL to ICN-GW. These 577 segments use IP tunneling constructs, where the service semantic 578 check at UL-CL is performed using IP's five tuples to determine both 579 UL and DL tunnel mappings. We summarize the relevant UPFs and the 580 interfaces for handling ICN PDU sessions as follows. 582 o ICN Gateway (ICN-GW): ICN-GW is where the 5GC PDU sessions 583 terminate and ICN service network begins. Compared to the 584 traditional anchor points as in PGW, the ICN-GW is also a service 585 gateway as it can host services or cache content enabled through 586 the ICN architecture. The ICN-GW also includes the UPF functions 587 to manage multiple tunnel interfaces enabling the relay of ICN PDU 588 flows to appropriate UL-CL instances in the DL. Note that there 589 may be multiple ICN-GWs serving different ICN services or slices. 590 ICN-GW also manages other ICN functions such as enforcing the 591 dynamic name based forwarding state, mobility state, in-network 592 service function management, resource management with respect to 593 sharing caching, storage, and compute resources among multiple 594 services[Ravindran]. 596 o ICN Packet Data Network (ICN-(P)DN): ICN-DN represents a set of 597 ICN nodes used for ICN networking and with heterogeneous service 598 resources such as storage and computing points. An ICN network 599 enables both network and application services, with network 600 services including caching, mobility, multicast, multi-path 601 routing (and possibly network layer computing), and application 602 services including network resources (such as cache, storage, 603 network state resources) dedicated to the application. 605 * Considering multiple ICN architecture proposals and multiple 606 ICN deployment models discussed in 607 [I-D.rahman-icnrg-deployment-guidelines], an alternate backward 608 compatible (IP-over-)ICN solution is proposed in [TROSSEN]. 609 Such an ICN-(P)DN can simply consist of SDN forwarding nodes 610 and a logically centralized path computation entity (PCE), 611 where the PCE is used to determine suitable forwarding 612 identifiers being used for the path-based forwarding in the 613 SDN-based transport network. In addition, the PCE is 614 responsible for maintaining the appropriate forwarding rules in 615 the SDN switches. For interconnection to IP-based peering 616 networks, a packet gateway is being utilized that mirrors the 617 convergence layer functionality to map incoming ICN traffic 618 back in to outgoing IP traffic and vice versa. This form of 619 deployment would require minimal changes to the 5GC's user and 620 control plane procedures, as the applications on these IP end 621 points are not exposed (or minimally exposed) to any ICN state 622 or configuration. 624 o Uplink Classifier (UL-CL): UL-CL enables classification of flows 625 based on source or destination IP address and steers the traffic 626 to an appropriate network or service function anchor point. If 627 the ICN-GW is identified based on service IP address associated 628 with the ICN-UE's flows, UL-CL checks the source or destination 629 address to direct traffic to an appropriate ICN-GW. For native 630 ICN UE, ICN shall be deployed over 5G-NR; here, there may not be 631 any IP association. For such packet flows new classification 632 schema shall be required, such as, using 5G-NR protocol extensions 633 to determine the tunnel interface to forward the ICN payload on, 634 towards the next ICN-GW. 636 5.2.1. Normative Interface Extensions 638 o N3: Though the current architecture supports heterogeneous service 639 PDU handling, future extensions can include user plane interface 640 extensions to offer explicit support to ICN PDU session traffic, 641 for instance, an incremental caching and computing function in RAN 642 or UL-CL to aid with content distribution. 644 o N9: Extensions to this interface can consider UPFs to enable 645 richer service functions, for instance to aid context processing. 646 In addition extensions to enable ICN specific encapsulation to 647 piggyback ICN specific attributes such as traffic or mobility data 648 between the UPF branching point and the ICN-GW. 650 o N6: This interface is established between the ICN-GW and the ICN- 651 DN, whose networking elements in this segment can be deployed as 652 an overlay or as a native Layer-3 network. 654 5.2.2. ICN over non-IP PDU 656 5GC accommodates non-IP PDU support which is defined for Ethernet or 657 any unstructured data[TS23.501]. This feature allows native support 658 of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS 659 itself as shown in Figure 2. Formalizing this feature to recognize 660 ICN PDUs has many considerations: 662 o Attach Procedures for UE with Non-IP PDN: Assuming a 5GC can 663 support both IP and non-IP PDN, this requires control plane 664 support, as discussed in Section 5. In a typical scenario, when 665 UE sends an attach message to 5GC, the type of PDU connection is 666 indicated in the PCO-IE field, for e.g. in this case as being non- 667 IP PDN to invoke related control plane session management tasks. 668 ICN over non-IP PDU session will allow the UE to attach to 5GC 669 without any IP configuration. 5GC attach procedures specified 670 [TS23.501] can be used to support authentication of UE with PDN 671 type set to non-IP, using existing AUSF/UDM functions in 672 coordination with the ICN-AF function discussed earlier if 673 required. 675 o User Plane for UE with Non-IP PDN: Without any IP tunnel 676 configuration and ICN's default consumer agnostic mode of 677 operation requires ways to identify the ICN-UE in the user plane, 678 this can be enabled by introducing network identifier in the lower 679 layers such as in the PDCP or MAC layer, that can assist for 680 functions such as policy and charging at the BS and related 681 session management tasks. These identifiers can also be used to 682 demultiplex the DL traffic from the ICN-GW in the BS to the 683 respective ICN-UEs. Also, ICN extensions can be incorporated in 684 control plane signaling to identify an ICN-UE device and these 685 parameters can be used by SMF to conduct non-IP routing. The 686 policing and charging functions can be enforced by the UPF 687 function in the BS which obtains the traffic filtering rules from 688 the SMF. To enable flat ICN network from the BS requires 689 distributed policy, charging and legal intercept which requires 690 further research. Further ICN slice multiplexing can be realized 691 by also piggybacking slice-ID (NSSI) along with device ID to 692 differentiate handover to multiple ICN slices at the base station. 693 Inter-working function (IWF) is required if services based on non- 694 IP UE has to transact or communicate with transport, applications 695 functions or other UE based on IP services. This also has 696 implications on how mobility is managed for such PDU sessions. 698 o Mobility Handling: Considering mobility can be support by ICN, it 699 is inefficient to traverse other intermediate IP networks between 700 the BS and the next ICN hop. This requires ICN PDU to be handled 701 by an ICN instance in the BS itself, in association with UL-CL 702 function local to the BS as shown in Figure 2. Control plane 703 extensions discussed in Section 5 can be used in tandem with 704 distributed mobility protocols to handle ICN mobility, one such 705 solution for producer mobility is proposed in [ICNMOB] 707 o Routing Considerations: Flat ICN network realizations also offers 708 the advantage of optimal routing, compared to anchor point based 709 realization in LTE. This also leads to optimal realization of the 710 data plane considering the absence of overhead due to tunneling 711 while forwarding ICN traffic. However, developing a routing 712 control plane in to handle the ICN PDU sessions either leveraging 713 SMF functions or a distributed realization requires more 714 investigation. In the centralized approach the SMF could interact 715 with ICN-SMF to set the forwarding rules in the ICN-GW in the BS 716 and other ICN-UPFs, however this may also lead to scalability 717 issues if a flat ICN network is to be realized. This also has 718 implications to route the non-IP PDU sessions efficiently to the 719 closest ICN-MEC instance of the service. 721 o IP over ICN: Native support of ICN in the RAN raises the 722 possibility of leveraging the mobility functions in ICN protocols 723 as a replacement for GTP tunneling in the 5GC, as described in 724 [I-D.white-icnrg-ipoc]. 726 o Mobile Edge Computing: Another significant advantage is with 727 respect to service-centric edge computing at the ICN-GW or other 728 ICN points, either through explicit hosting of service 729 functions[VSER] in ICN or in-network computing based on NFN 730 proposal[NFN]. A certain level of orchestration, as discussed in 731 Section 5, is required to ensure service interconnection and its 732 placement with appropriate compute resources and inter-connected 733 with bandwidth resources so that the desired SLA is offered. 735 5.2.3. Dual Stack ICN Deployment 737 5.2.3.1. 5G User Plane Protocol Stack 739 It is important to understand that a User Equipment (UE) can be 740 either consumer (receiving content) or publisher (pushing content for 741 other clients). The protocol stack inside mobile device (UE) is 742 complex as it has to support multiple radio connectivity access to 743 gNB(s). 745 +--------+ +--------+ 746 | App | | APP | 747 +--------+ +---------+ +--------+ 748 | IP |.....................................| IP |.|.| IP | 749 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 750 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 751 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 752 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 753 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 754 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 755 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 756 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 757 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 758 UE | gNB/RAN | UPF | UPF | DN 759 | | (UL-CL) | (PDU Anchor)| 760 Uu N3 N9 N6 762 Figure 3: 5G User Plane Protocol Stack 764 Figure 3 provides high level description of a 5G user plane protocol 765 stack, where: 1) the lower 4 layers (i.e. L1, MAC, RLC, PDCP) at UE 766 is for radio access and air interface to gNB; 2) the IP layer (i.e. 767 PDU layer) at UE is used for providing IP transport infrastructure to 768 support PDU session between UE and UPF (PDU Anchor); 3) GUP-U 769 provides tunneling between gNB and UPF, or between two UPFs. 770 Although UDP/IP exists under GTP-U, IP mainly refers to "IP" between 771 UE and UPF (PDU Anchor) for the rest of this document, unless 772 explicitly clarified; 4) UL-CL is only for uplink traffic and UPF 773 (UL-CL) shall not be needed for downlink traffic towards UE. 775 5.2.3.2. Protocol Stack for ICN Deployment in 5G 776 +--------+ +--------+ 777 | App | | APP | 778 +--------+ +---------+ +--------+ 779 | TCL |.....................................| TCL |.|.| TCL | 780 +--------+ +---------+ | +--------+ 781 | ICN&IP |.....................................| ICN&IP |.|.| ICN&IP | 782 | | | | | | | 783 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 784 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 785 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 786 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 787 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 788 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 789 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 790 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 791 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 792 UE | gNB/RAN | UPF | UPF | DN 793 | | (UL-CL) | (PDU Anchor)| 794 Uu N3 N9 N6 796 Figure 4: Dual Stack ICN Deployment 798 ICN can be deployed in dual stack model for 5G user plane as 799 illustrated in Figure 4, where: 1) both ICN and IP (i.e. dual stack) 800 can reside between TCL and PDCP to provide transport infrastructure 801 from UE to UPF (PDU Anchor); 2) in order to support the dual ICN&IP 802 transport layer, PDCP needs some enhancements; 3) a new Transport 803 Convergence Layer (TCL) is introduced to coordinate between 804 applications and ICN&IP transport layer; 4) Applications on top of 805 TCL could be ICN applications or IP applications. 807 With this dual stack model, four different cases are possible for the 808 deployment of ICN natively and/or with IP dependent on which types of 809 applications (ICN or IP) uses which types of underline transport (ICN 810 or IP), from the perspective of the applications either on UE (or 811 content provider). 813 Case 1. IP over IP (IPoIP) 815 In this scenario UE uses applications tightly integrated with the 816 existing IP transport infrastructure. In this option, the TCL has no 817 additional function since the packets are directly forwarded using IP 818 protocol stack, which in turn sends the packets over the IP 819 transport. 821 Case 2. ICN over ICN (ICNoICN) 822 Similar to case 1 above, ICN applications tightly integrate with the 823 ICN transport infrastructure. The TCL has no additional 824 responsibility since the packets are directly forwarded using ICN 825 protocol stack, which in turn sends the packets over the ICN 826 transport. 828 Case 3. ICN over IP (ICNoIP) 830 In ICN over IP scenario, the underlying IP transport infrastructure 831 is not impacted (i.e. ICN is implemented as an overlay over IP, 832 between UE and content provider). IP routing is used from Radio 833 Access Network (gNB) to mobile backhaul, IP core and UPF. UE 834 attaches to UPF (PDU Anchor) using IP address. Content provider in 835 DN is capable of serving content either using IP or ICN, based on UE 836 request. 838 An alternative approach to implement ICN over IP is provided in 839 Hybrid ICN [I-D.muscariello-intarea-hicn], which implements ICN over 840 IP by mapping of ICN names to the IPv4/IPv6 addresses. 842 Case 4. IP over ICN (IPoICN) 844 In IP over ICN scenario, IP application utilize an ICN-based routing 845 while preserving the overall IP protocol semantics, as shown, e.g., 846 in H2020 project [H2020]. Implementing IP services over ICN provides 847 an opportunity leveraging benefit of ICN in the transport 848 infrastructure. 850 Note that the IP over ICN case could be supported for pure IP (over 851 IP) UEs through introducing a Network Attachment Point (NAP) to 852 interface to an ICN network. Here, the UPF (PDU Anchor) interfaces 853 to said NAP in the northbound; alternatively, the NAP can be 854 integrated as a part of UPF (PDU Anchor). For this scheme, the NAP 855 provides a standard IP network interface towards the IP-enabled UE 856 via UPF (PDU Anchor), encapsulates any received IP service (e.g. 857 HTTP) request into an appropriate ICN packet which is then published 858 as an appropriately formed named information item. Conversely, the 859 NAP subscribes to any appropriately formed named information items, 860 where the information identifier represents any IP-exposed service 861 that is exposed at any IP-level UE locally connected to the NAP. Any 862 received ICN packet is then forwarded to the appropriate local IP- 863 enabled UE after being appropriately decapsulated, recovering the 864 original IP service (e.g. HTTP) request. 866 In a dual-stack UE that supports the above cases, the TCL helps 867 determine what type of transport (e.g. ICN or IP), as well as type 868 of radio interface (e.g. 5G or WiFi or both), is used to send and 869 receive the traffic based on preference e.g. content location, 870 content type, content publisher, congestion, cost, quality of service 871 etc. It helps to configure and decide the type of connection as well 872 as the overlay mode (ICNoIP or IPoICN, explained above) between 873 application and the protocol stack (IP or ICN) to be used. 875 TCL can use a number of mechanisms for the selection of transport 876 (i.e. ICN or IP). It can use a per application configuration 877 through a management interface, possibly even a user-facing setting 878 realized through a user interface, similar to those used today that 879 select cellular over WiFi being used for selected applications. In 880 another option, it might use a software API, which an adapted IP 881 application could use to specify e.g. an ICN transport for obtaining 882 its benefits. 884 Another potential application of TCL is in implementation of network 885 slicing, where it can have a slice management capability locally or 886 it can interface to an external slice manager through an API 887 [I-D.galis-anima-autonomic-slice-networking]. This solution can 888 enable network slicing for IP and ICN transport selection from the UE 889 itself. The TCL could apply slice settings to direct certain traffic 890 (or applications) over one slice and others over another slice, 891 determined by some form of 'slicing policy'. Slicing policy can be 892 obtained externally from slice manager or configured locally on UE. 894 5.2.3.3. Protocol Interactions and Impacts 895 +----------------+ +-----------------+ 896 | ICN App (New) | |IP App (Existing)| 897 +---------+------+ +-------+---------+ 898 | | 899 +---------+----------------+---------+ 900 | TCL (New) | 901 +------+---------------------+-------+ 902 | | 903 +------+------+ +------+-------+ 904 |ICN Function | | IP Function | 905 | (New) | | (Existing) | 906 +------+------+ +------+-------+ 907 | | 908 +------+---------------------+-------+ 909 | PDCP (Updated to Support ICN) | 910 +-----------------+------------------+ 911 | 912 +-----------------+------------------+ 913 | RLC (Existing) | 914 +-----------------+------------------+ 915 | 916 +-----------------+------------------+ 917 | MAC Layer (Existing) | 918 +-----------------+------------------+ 919 | 920 +-----------------+------------------+ 921 | Physical L1 (Existing) | 922 +------------------------------------+ 924 Figure 5: Dual Stack ICN Protocol Interactions at UE 926 The protocol interactions and impact of supporting tunneling of ICN 927 packet into IP or to support ICN natively are described in Figure 5. 929 o Existing application layer can be modified to provide options for 930 new ICN based application and existing IP based applications. UE 931 can continue to support existing IP based applications or host new 932 applications developed either to support native ICN as transport, 933 ICNoIP or IPoICN based transport. Application layer has the 934 option of selecting either ICN or IP transport layer as well as 935 radio interface to send and receive data traffic. Our proposal is 936 to provide a common Application Programming Interface (API) to the 937 application developers such that there is no impact on the 938 application development when they choose either ICN or IP 939 transport for exchanging the traffic with the network. TCL 940 function handles the interaction of application with the multiple 941 transport options. 943 o The TCL helps determine what type of transport (e.g. ICN or IP) 944 as well as type of radio interface (e.g. 5G NR or WiFi or both), 945 is used to send and receive the traffic. Application layer can 946 make the decision to select a specific transport based on 947 preference e.g. content location, content type, content publisher, 948 congestion, cost, quality of service etc. There can be an 949 Application Programming Interface (API) to exchange parameters 950 required for transport selection. The southbound interactions of 951 TCL will be either to IP or ICN at the network layer. When 952 selecting the IPoICN [TROSSEN] mode, the TCL is responsible for 953 receiving an incoming IP or HTTP packet and publishing the packet 954 under a suitable ICN name (i.e. the hash over the destination IP 955 address for an IP packet or the hash over the FQDN of the HTTP 956 request for an HTTP packet) to the ICN network. In the HTTP case, 957 the TCL maintains a pending request mapping table to map returning 958 responses to the originating HTTP request. The common API will 959 provide a common 'connection' abstraction for this HTTP mode of 960 operation, returning the response over said connection 961 abstraction, akin to the TCP socket interface, while implementing 962 a reliable transport connection semantic over the ICN from the UE 963 to the receiving UE or the PGW. If the HTTP protocol stack 964 remains unchanged, therefore utilizing the TCP protocol for 965 transfer, the TCL operates in local TCP termination mode, 966 retrieving the HTTP packet through said local termination. The 967 southbound interactions of the Transport Convergence Layer (TCL) 968 will be either to IP or ICN at the network layer. 970 o ICN function (forwarder) is introduced in parallel to the existing 971 IP layer. ICN forwarder contains functional capabilities to 972 forward ICN packets, e.g. Interest packet to gNB or response 973 "data packet" from gNB to the application. 975 o For dual stack scenario, when UE is not supporting ICN at network 976 layer, we use IP underlay to transport ICN packets. ICN function 977 will use IP interface to send Interest and Data packets for 978 fetching or sending data using ICN protocol function. This 979 interface will use ICN overlay over IP using any overlay tunneling 980 mechanism. 982 o To support ICN at network layer in UE, PDCP layer has to be aware 983 of ICN capabilities and parameters. PDCP is located in the Radio 984 Protocol Stack in the 5G Air interface, between IP (Network layer) 985 and Radio Link Control Layer (RLC). PDCP performs following 986 functions [TS36.323]: 988 * Data transport by listening to upper layer, formatting and 989 pushing down to Radio Link Layer (RLC). 991 * Header compression and decompression using Robust Header 992 Compression (ROHC). 994 * Security protections such as ciphering, deciphering and 995 integrity protection. 997 * Radio layer messages associated with sequencing, packet drop 998 detection and re-transmission etc. 1000 o No changes are required for lower layer such as RLC, MAC and 1001 Physical (L1) because they are not IP aware. 1003 6. 5GC Architecture with 5GLAN Support 1005 In this section, we focus on the implemention of ICN over 5GLAN 1006 architecture [SA2-5GLAN] 1008 6.1. Background: LAN-based End-to-End Packet Forwarding in 5G 1010 +------+ +------+ +-----+ +-----+ +-----+ +-----+ 1011 | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 1012 +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ 1013 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 1014 -----+-------+-+---------+--+------+-------+-+---------+--------- 1015 Nausf| Namf| Nsmf| 1016 +--o--+ +--o--+ +--o--+ 1017 | AUSF| | AMF | | SMF | 1018 +-----+ +-+-+-+ +--+--+ 1019 / | | 1020 +---------+ | | 1021 N1 / |N2 N4| +-N9/Nx-+ 1022 +------+ | | | | 1023 / | | | V 1024 +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ 1025 | UE +----------------+ (R)AN +------+ UPF +----->+ DN | 1026 +----+ +---------+ +---------------+ +----+ 1028 Figure 6: 5G Core Network with Vertical_LAN (5GLAN) Extensions 1030 Figure 6 shows the current 5G Core Network Architecture being 1031 discussed within the scope of the normative work addressing 5GLAN 1032 Type services in the 3GPP System Architecture Working Group 2 (3GPP 1033 SA2), referred formally as "5GS Enhanced support of Vertical and LAN 1034 Services" [SA2-5GLAN]. The goal of this work item is to provide 1035 distributed LAN-based connectivity between two or more terminals or 1036 User Equipment entities (UEs) connected to the 5G network. The SMF 1037 (session management function) provides a registration and discovery 1038 protocol that allows UEs wanting to communicate via a relevant 5GLAN 1039 group towards one or more UEs also members of this 5GLAN group, to 1040 determine the suitable forwarding information after each UE 1041 previously registered suitable identifier information with the SMF 1042 responsible to manage the paths across UEs in a 5GLAN group. UEs 1043 register and discover (obtain) suitable identifiers during the 1044 establishment of a Protocol Data Unit (PDU) Session or PDU Session 1045 Modification procedure. Suitable identifier information, according 1046 to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses 1047 (the latter is usually assigned during the session setup through the 1048 SMF, i.e., the session management function). 1050 The SMF that manages the path across UEs in a 5GLAN group, then 1051 establishes the suitable procedures to ensure the forwarding between 1052 the required UPFs (user plane functions) to ensure the LAN 1053 connectivity between the UEs (user equipments) provided in the 1054 original request to the SMF. When using the N9 interface to the UPF, 1055 this forwarding will rely on a tunnel-based approach between the UPFs 1056 along the path, while the Nx interface uses path-based forwarding 1057 between UPFs, while LAN-based forwarding is utilized between the 1058 final UPF and the UE (utilizing the N3 interface towards the 1059 destination UE). 1061 In the following, path-based forwarding is assumed, i.e., the usage 1062 of the Nx interface and the utilization of a path identifier for the 1063 end-to-end LAN communication. Here, the path between the source and 1064 destination UPFs is encoded through a bitfield, provided in the 1065 packet header. Each bitposition in said bitfield represents a unique 1066 link in the network. Upon receiving an incoming packet, each UPF 1067 inspects said bitfield for the presence of any local link that is 1068 being served by one of its output ports. Such presence check is 1069 implemented via a simple binary AND and CMP operation. If no link is 1070 being found, the packet is dropped. Such bitfield-based path 1071 representation also allows for creating multicast relations in an ad- 1072 hoc manner by combining two or more path identifiers through a binary 1073 OR operation. Note that due to the assignment of a bitposition to a 1074 link, path identifiers are bidirectional and can therefore be used 1075 for request/response communication without incurring any need for 1076 path computation on the return path. 1078 For sending a packet from one Layer 2 device (UE) connected to one 1079 UPF (via a RAN) to a device connected to another UPF, we provide the 1080 MAC address of the destination and perform a header re-write by 1081 providing the destination MAC address of the ingress UPF when sending 1082 from source device to ingress and placing the end destination MAC 1083 address in the payload. Upon arrival at the egress UPF, after having 1084 applied the path-based forwarding between ingress and egress UPF, the 1085 end destination address is restored while the end source MAC is 1086 placed in the payload with the egress L2 forwarder one being used as 1087 the L2 source MAC for the link-local transfer. At the flat device 1088 (or proxy device), the end source MAC address is restored as the 1089 source MAC, creating the perception of a link-local L2 communication 1090 between the end source and destination devices. 1092 +---------+---------+----------+-----------+-----------+ 1093 | Src MAC | Dst MAC | pathID | NAME_ID | Payload | 1094 +---------+---------+----------------------+-----------+ 1096 Figure 7: General Packet Structure 1098 For this end-to-end transfer, the general packet structure of 1099 Figure 7 is used. The Name_ID field is being used for the ICN 1100 operations, while the payload contains the information related to the 1101 transaction-based flow management described in Section 6.2.6 and the 1102 PATH_ID is the bitfield-based path identifier for the path-based 1103 forwarding. 1105 6.1.1. Realization in Existing Transport Networks 1107 An emerging technology for Layer 2 forwarding that suits the 5GLAN 1108 architecture in Figure 6 is that of Software-defined networking (SDN) 1109 [SDNDef], which allows for programmatically forwarding packets at 1110 Layer 2. Switch-based rules are being executed with such rules being 1111 populated by the SDN controller. Rules can act upon so-called 1112 matching fields, as defined by the OpenFlow protocol specification 1113 [OpenFlowSwitch]. Those fields include Ethernet MAC addresses, 1114 IPv4/6 source and destination addresses and other well-known Layer 3 1115 and even 4 transport fields. 1117 As shown in [Reed], efficient path-based forwarding can be realized 1118 in SDN networks by placing the aforementioned path identifiers into 1119 the IPv6 source/destination fields of a forwarded packet . Utilizing 1120 the IPv6 source/destination fields allows for natively supporting 256 1121 links in a transport network. Larger topologies can be supported by 1122 extension schemes but are left out of this paper for brevity of the 1123 presentation. During network bootstrapping, the Name Resolver (NR) 1124 assigns to each link at each switch a unique bitnumber in the 1125 bitfield. In order to forward based on such bitfield path 1126 information, the NR instructs the SDN controller to insert a suitable 1127 wildcard matching rule into the SDN switch. This wildcard at a given 1128 switch is defined by the bitnumber that has been assigned to a 1129 particular link at that switch during bootstrapping. Wildcard 1130 matching as a generalization of longest prefix matching is natively 1131 supported by SDN-based switches since the OpenFlow v1.3 1132 specification, efficiently implemented through TCAM based operations. 1133 With that, SDN forwarding actions only depend on the switch-local 1134 number of output ports, while being able to transport any number of 1135 higher-layer flows over the same transport network without specific 1136 flow rules being necessary. This results in a constant forwarding 1137 table size while no controller-switch interaction is necessary for 1138 any flow setup; only changes in forwarding topology (resulting in a 1139 change of port to bitnumber assignment) will require suitable changes 1140 of forwarding rules in switches. 1142 Although we focus the methods in this draft on Layer 2 forwarding 1143 approaches, path-based transport networks can also be established as 1144 an overlay over otherwise Layer 2 networks. For instance, the BIER 1145 (Bit Indexed Explicit Replication) [RFC8279] efforts within the 1146 Internet Engineer Task Force (IETF) establish such path-based 1147 forwarding transport as an overlay over existing, e.g., MPLS 1148 networks. The path-based forwarding identification is similar to the 1149 aforementioned SDN realization although the bitfield represents 1150 ingress/egress information rather than links along the path. 1152 Yet another transport network example is presented in [Khalili], 1153 utilizing flow aggregation over SDN networks. The flow aggregation 1154 again results in a path representation that is independent from the 1155 specific flows traversing the network. 1157 6.2. IP-based Service over ICN over 5GLAN 1158 +-------------------------------+ 1159 | Forwarding Network | .... Control 1160 | +--------------------------+ | 1161 | | . NR . | | **** Data 1162 | +-.----------------------.-+ | 1163 +--------------+ | . . | +--------------+ 1164 | App | | +-.---------+ +---------.-+ | | App | 1165 +-----+----+---+ | | . ******* | | ******* . | | +--------------+ 1166 |HTTP*|TCP*|IP.| | | . * UPF * | | * UPF * . | | |.IP|*TCP|*HTTP| 1167 +----*+---*+--.+ | +-.-*-----*-+ +-*-----*-.-+ | +.--+*---+*----+ 1168 |ICN * * .| | . * * * * . | |. * * ICN| 1169 +----*----*---.+ +---+ . * ******** * . +---+ +.---*----*----+ 1170 |L2 * * ....|RAN+.. * * ..+RAN|.... * * | 1171 | ********************** ********************** | 1172 +--------------+ +---+ . * * . +---+ +--------------+ 1173 | . * * . | 1174 | +-.-*-----+ +-----*-.+ | 1175 +--| . * RAN|------|RAN * .|--+ 1176 +-.-*-----+ +-----*-.+ 1177 . * * . 1178 . ******* ******* . 1179 Legacy Service ....... * * ....... Service 1180 Device Proxy . * * . Proxy 1181 +-----+ +-------------------+ . * * . +-------------------+ 1182 |APP *| | ********* | . * * . | ********** | 1183 +----*+ +----*+ * | . * * . | * +*----+ 1184 |HTTP*| |HTTP*|******* | . * * . | ********|*HTTP| 1185 +----*+ +----*-+ * | . * * . | * +*----+ 1186 |TCP *| |TCP * |****** | . * * . | *******| * TCP| 1187 +----*+ +----*--+ +*------+ . * * . +-----*+ +---*----+ +-------+ 1188 |IP *| |IP * |***|* ICN .| . * * . |.ICN *|***| * IP| | IP | 1189 +----*+ +----*--+---+*-----.+ . * * . +.----*+---+---*----+ |Peering| 1190 |L2 *| | * L2 * .... * * .... * * | |Network| 1191 | ********* ************ *********** ************ | 1192 +-----+ +-------------------+ +-------------------+ +-------+ 1194 Figure 8: IP-based Services over ICN over 5GLAN 1196 Figure 8 shows the protocol layering for realizing IP-based protocols 1197 over an ICN over 5GLAN transport, assuming an end-to-end LAN 1198 connectivity provided by solutions such as 5GLAN. 1200 Note that such LAN connectivity can also be found in environments 1201 such as localized LAN-based deployments in smart cities, enterprises 1202 and others. Hence, the solutions described in this section also 1203 applies to those deployments. 1205 Key to the approach is that Internet services are being interpreted 1206 as the main unit of transfer in the architecture shown in Figure 8. 1207 For this, any Internet service is treated as a Named Service 1208 Transaction (NST) which is in turn suitably routed over an ICN layer 1209 in one or more other devices. As a result of this name-based 1210 interpretation of any Internet service, the protocol stack in end 1211 devices flattens to four layers with Internet services and ICN, with 1212 ICN acting as a name-based routing layer for all IP protocol 1213 implemented atop, with Layer 1 and 2 realizing the end-to-end packet 1214 forwarding outlined in Section 6.1. 1216 The details of the mapping and the operations of the ICN layer are 1217 presented in Section 6.2.3 for the example of HTTP. As explained in 1218 that section, the ICN layer uses an interaction with the NR to 1219 register and discover HTTP-based services for determining the 1220 suitable end-to-end packet forwarding information. 1222 An important aspect of the architecture is the mapping of the end-to- 1223 end flow semantic established in many Internet services onto the flat 1224 protocol stack. Section 6.2.7 outlines the flow management that 1225 exists between the end devices. 1227 Interfaces to legacy devices and peering networks are preserved 1228 through service proxy devices, which terminate a traditional Internet 1229 protocol stack communication and translate it into a resulting flat 1230 protocol transaction based on the operations defined in 1231 Section 6.2.3. Termination here can be based on well-known port 1232 numbers for specific Internet protocols, ultimately falling back to 1233 the IP datagram service being the minimal service being mapped. 1235 6.2.1. General Operations 1237 The semantics of our name-based routing as that of a publish- 1238 subscribe system over a name. The intention to receive packets with 1239 a certain name is expressed through a subscription while sending 1240 packets to a name is expressed through a publication. The matching 1241 of a sender to a receiver is realized through NR in Figure 8. The 1242 exact nature of the matching is defined through the semantics of the 1243 service and, therefore, through the nature of the name provided. For 1244 instance, HTTP and raw IP services are matched to exactly one 1245 subscriber only, providing an anycast capability, while IP multicast 1246 services are matched against any subscriber (with the IP multicast 1247 address being the name). 1249 Structured names are used with the root specific to the (Internet) 1250 service name, such as URL, and therefore deriving the matching 1251 semantics directly from the name. 1253 The subscription to a name is realized through a registration 1254 protocol between end device and NR. Hence, any end device exposing a 1255 certain Internet service registers the suitable name with the NR, 1256 which in turn stores reachability information that is suitable for 1257 path calculation between the ingress and egress L2 forwarders between 1258 which the communication eventually will take place. In our current 1259 realization, we utilize shortest paths only although other link 1260 weights can be utilized for, e.g., delay-constrained and other 1261 policies. 1263 In our realization, we use network domain unique host identifiers 1264 that are being assigned to end devices during the connectivity setup. 1265 Sending a packet of a given Internet service is realized through a 1266 discovery protocol, which returns a suitable pathID, i.e., the 1267 forwarding information between ingress and egress L2 forwarder, and 1268 the destination MAC address of the hosting end device. It is this 1269 pathID and MAC address that is being used in the general packet 1270 structure of Figure 7 to forward the packet to the destination. 1272 To reduce latency in further communication, the forwarding 1273 information is locally cached at the end device, while the cached 1274 information is being maintained through path updates sent by the NR 1275 in case of hosting end devices having moved or de-registered, 1276 therefore avoiding stale forwarding information. 1278 6.2.2. ICN API to Upper Layers 1280 The pub/sub operations of the ICN layer are exposed through the 1281 following API calls: 1283 o conn = send(name, payload) 1285 o send(conn, payload) 1287 o conn = receive(name, &payload) 1289 o receive(conn, &payload) 1291 The first send() call is used for initiating a send operation to a 1292 name with a connection handle returned, while the second send() is 1293 used for return calls, using a connection parameters that is being 1294 received with the receive() call to an incoming connection or for 1295 subsequence outgoing calls after an initial request to a name has 1296 been made. A return send() is being received at the other (client) 1297 side through the second receive() call where the conn parameter is 1298 obtained by the corresponding send() call for the outgoing call. 1299 With these API functions, we provide means for providing name-based 1300 transactions with return responses association provided natively. 1302 The conn parameter represents the bitfield used for path-based 1303 forwarding in the remote host case or the hash of the local MAC 1304 address in case of link-local connections. 1306 6.2.3. HTTP over ICN 1308 To realize the flat device nature, Internet service layers, such as 1309 the HTTP protocol stack or the TCP protocol stack, will need to be 1310 adapted to run atop this new API, implementing the semantics of the 1311 respective Internet protocol through suitable transactions at the 1312 name level. In the example of HTTP, the standard operations of DNS 1313 resolution for the server to be contacted and opening of a TCP socket 1314 are altogether replaced by a single send(FQDN, HTTP request) call, 1315 while the response will be sent by the server, which received the 1316 request through a receive(FQDN, &payload) call, using the returned 1317 conn parameter to send the response with the second send() API call. 1318 Note that the use of bidirectional pathIDs, no NR lookup is performed 1319 at the HTTP serving endpoint. 1321 6.2.4. Ad-Hoc Multicast for HTTP over ICN 1323 The basis of a named service transaction allows to deliver the same 1324 HTTP responses to several requestees in efficient multicast (see 1325 [I-D.purkayastha-bier-multicast-http-response] for use cases in a 1326 BIER-based transport network environment). 1328 This opportunity is realized by sending the same payload (i.e., an 1329 HTTP response to the same resource across a number of pending 1330 requests) through a combination of several conn parameters received 1331 in the incoming requests via the receive() function. 1333 What is required in the HTTP stack implementation is a logic to 1334 decide that two or more outstanding requests are possible to be 1335 served by one response. For this, upon receiving an incoming 1336 request, the HTTP stack determines any outstanding request to the 1337 same resource. 'Same' here is defined as URI-specific combination of 1338 the request URI and URI-specific header fields, such as browsing 1339 agent or similar, called requestID in the following. 1341 Once such determination is made that two requests are relating to the 1342 same resource, i.e., are having the same request ID, the HTTP stack 1343 maintains a temporary mapping of the request ID to the respective 1344 conn parameters delivered by the receive() call. Upon receiving the 1345 HTTP response from its application-level logic, the HTTP stack will 1346 generate the suitable send(conn, payload) call where the provided 1347 conn parameter is bitwise OR of all previously stored conn parameters 1348 received in the receive() call. The ICN layer will recognize the use 1349 of those ad-hoc created conn parameters and set the destination MAC 1350 address in the general packet structure of Figure 8 to the Ethernet 1351 broadcast MAC address as the destination address, leading to sending 1352 the response to all end devices at the egress L2 forwarders to which 1353 the response will be forwarded based on the combined conn parameter. 1354 Alternatively, one could request IEEE assignment for a specific 1355 Ethernet multicast address for this scheme instead of using the 1356 broadcast address. For the local end device to determine the 1357 relevance of the response received at the broadcast channel, the HTTP 1358 stack of the serving endpoint includes the aforementioned requestID 1359 into the payload of the packet (see Figure 8), while the originating 1360 endpoint maintains an internal table with the requestID of pending 1361 requests and its associated conn handle. If no matching requestID is 1362 found, the packet is not being delivered to the NbR layer of the 1363 incoming device. If a request is found, the ICN layer delivers the 1364 response via the receive() call, using the conn handle stored in the 1365 pending request table. Note that this filtering mechanism can easily 1366 be implemented in hardware upon standardizing the appropriate payload 1367 and header fields. 1369 6.2.5. Service Proxy Operations 1371 The service proxy in Figure 8 serves the integration of legacy 1372 devices, i.e., with regular IP protocol stack, and the 1373 interconnection to IP-based peering networks. It registers suitable 1374 identifiers with the NR to ensure the reception of (ICN-packets) 1375 packet, while providing suitable protocol termination for the various 1376 supported protocols. For instance, for HTTP, the service proxy 1377 towards the peering network will register a wildcard name to the NR 1378 to receive any HTTP request not destined to a network-locally 1379 registered FQDN, operating as an HTTP proxy towards the peering 1380 network. 1382 6.2.6. ICN Flow Management 1384 EDITOR NOTE: left for future draft updates. 1386 6.2.7. NR Operations 1388 The NR in Figure 8 combines the operations of the SMF and the PMF in 1389 5GLAN (see Figure 6), by allowing for registering IP protocol 1390 identifiers for discovery and subsequent path computation by 1391 resolving the destination(s) to a suitable pathID and destination MAC 1392 address for forwarding. This will require extensions to the 1393 operations of the SMF to allow for such higher layer identifiers to 1394 be registered (and discovered), in addition to the already supported 1395 Ethernet and IP addresses. 1397 6.2.8. Mobility Handling 1399 EDITOR NOTE: left for future draft updates. 1401 6.2.9. Dual Stack Device Support 1403 [I-D.suthar-icnrg-icn-lte-4g] outlines the possibility of supporting 1404 dual-stack devices for 4G LTE networks by allowing IP as well as ICN 1405 protocol stacks to be deployed with the operation of IP and ICN based 1406 applications. For this, a convergence layer is described that 1407 selects the appropriate data path for each ICN or IP application, 1408 e.g., based on configuration per application (similar to selecting 1409 network interfaces such as WiFi over cellular). An appropriate data 1410 path, as outlined in [I-D.suthar-icnrg-icn-lte-4g], can be the 1411 routing over IP or ICN. As a possible datapath selection, 1412 [I-D.suthar-icnrg-icn-lte-4g] envisions the realization of IP-over- 1413 ICN (Section 4.2 in [I-D.suthar-icnrg-icn-lte-4g]) in which the 1414 convergence layer would realize similar mapping functions as 1415 described in this draft. Hence, we foresee the utilization of such 1416 dual-stack devices connected to an IP-based services over ICN over 1417 5GLAN environment. When utilizing the service proxy, IP applications 1418 that are configured to use the IP data path only could still utilize 1419 the ICN-based forwarding in the network. In that case, functionality 1420 such as the opportunistic multicast in Section 6.2.4 would only reach 1421 up to the service proxy with unicast traffic continuing along the 1422 datapath towards the user equipment. 1424 6.3. ICN over 5GLAN 1426 EDITOR NOTE: left for future draft updates. 1428 7. Conclusion 1430 In this draft, we explore the feasibility of realizing future 1431 networking architectures like ICN within the proposed 3GPP's 5GC 1432 architecture. Towards this, we summarized the design principles that 1433 offer 5GC the flexibility to enable new network architectures. We 1434 then discuss 5GC architecture along with the user/control plane 1435 extensions required to handle ICN PDU sessions formally. We then 1436 apply the proposed architecture to enabling IP-based services over an 1437 ICN network in the context of 5GLAN. 1439 8. IANA Considerations 1441 This document requests no IANA actions. 1443 9. Security Considerations 1445 This draft proposes extensions to support ICN in 5G's next generation 1446 core architecture. ICN being name based networking opens up new 1447 security and privacy considerations which have to be studied in the 1448 context of 5GC. This is in addition to other security considerations 1449 of 5GC for IP or non-IP based services considered in [TS33.899]. 1451 10. Acknowledgments 1453 ... 1455 11. Informative References 1457 [Guilio] Grassi, G., Pesavento, D., Pau, G., Vayyuru, R., Wakikawa, 1458 Ryuji., Wakikawa, Ryuji., and Lixia. Zhang, "Vehicular 1459 Inter-Networking via Named Data", ACM Hot Mobile (Poster), 1460 2013. 1462 [H2020] H2020, "The POINT Project", https://www.point-h2020.eu/ . 1464 [I-D.galis-anima-autonomic-slice-networking] 1465 Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1466 Slice Networking", draft-galis-anima-autonomic-slice- 1467 networking-05 (work in progress), September 2018. 1469 [I-D.muscariello-intarea-hicn] 1470 Muscariello, L., Carofiglio, G., Auge, J., and M. 1471 Papalini, "Hybrid Information-Centric Networking", draft- 1472 muscariello-intarea-hicn-01 (work in progress), December 1473 2018. 1475 [I-D.purkayastha-bier-multicast-http-response] 1476 Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert, 1477 "Applicability of BIER Multicast Overlay for Adaptive 1478 Streaming Services", draft-purkayastha-bier-multicast- 1479 http-response-01 (work in progress), October 2018. 1481 [I-D.rahman-icnrg-deployment-guidelines] 1482 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1483 "Deployment Considerations for Information-Centric 1484 Networking (ICN)", draft-rahman-icnrg-deployment- 1485 guidelines-05 (work in progress), January 2018. 1487 [I-D.suthar-icnrg-icn-lte-4g] 1488 suthar, P., Stolic, M., Jangam, A., and D. Trossen, 1489 "Native Deployment of ICN in LTE, 4G Mobile Networks", 1490 draft-suthar-icnrg-icn-lte-4g-04 (work in progress), 1491 November 2017. 1493 [I-D.white-icnrg-ipoc] 1494 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 1495 Tunneling over Content Centric Mobile Networks", draft- 1496 white-icnrg-ipoc-01 (work in progress), June 2018. 1498 [ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 1499 "Seamless Producer Mobility as a Service in Information 1500 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 1501 2016. 1503 [IEEE_Communications] 1504 Trossen, D. and G. Parisis, "Designing and Realizing an 1505 Information-Centric Internet", Information-Centric 1506 Networking, IEEE Communications Magazine Special Issue, 1507 2012. 1509 [Jacobson] 1510 Jacobson, V. and et al., "Networking Named Content", 1511 Proceedings of ACM Context, , 2009. 1513 [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, 1514 "Reducing State of SDN Switches in Mobile Core Networks by 1515 Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, 1516 August 2016. 1518 [lteversus5g] 1519 Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and 1520 functions for 5G mobile communication system.", ICT 1521 Express 2017, 2017. 1523 [NFN] Sifalakis, M., Kohler, B., Christopher, C., and C. 1524 Tschudin, "An information centric network for computing 1525 the distribution of computations", ACM, ICN Sigcomm, 2014. 1527 [OpenFlowSwitch] 1528 Open Networking Foundation, available at 1529 https://www.opennetworking.org/wp-content/uploads/2014/10/ 1530 openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification 1531 V1.5.1", 2018. 1533 [Ravindran] 1534 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1535 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1536 Network Slicing", IEEE Communication Magazine, May, 2016. 1538 [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., 1539 Petropoulos, G., and S. Spirou, "Stateless Multicast 1540 Switching in Software Defined Networks", IEEE ICC 2016, 1541 Kuala Lumpur, Maylaysia, 2016. 1543 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1544 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1545 "Information-Centric Networking (ICN) Research 1546 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1547 . 1549 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1550 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1551 Explicit Replication (BIER)", RFC 8279, 1552 DOI 10.17487/RFC8279, November 2017, 1553 . 1555 [SA2-5GLAN] 1556 3gpp-5glan, "SP-181129, Work Item Description, 1557 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 1558 LAN Services", 3GPP , 1559 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/ 1560 SP-181120.zip. 1562 [SDNDef] Open Networking Foundation, available at 1563 https://www.opennetworking.org/sdn-definition/, "Software- 1564 Defined Networking (SDN) Definition", 2018. 1566 [TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M., and 1567 G. Xylomenos, "IP Over ICN - The Better IP ?", EuCNC, 1568 European Conference on Networks and Communications , July, 1569 2015. 1571 [TS23.501] 1572 3gpp-23.501, "Technical Specification Group Services and 1573 System Aspects; System Architecture for the 5G System; 1574 Stage 2 (Rel.15)", 3GPP , December 2018. 1576 [TS23.502] 1577 3gpp-23.502, "Technical Specification Group Services and 1578 System Aspects; Procedures for the 5G System; Stage 2 1579 (Rel. 15)", 3GPP , January 2019. 1581 [TS23.799] 1582 3gpp-23.799, "Technical Specification Group Services and 1583 System Aspects; Study on Architecture for Next Generation 1584 System (Rel. 14)", 3GPP , 2017. 1586 [TS33.899] 1587 3gpp-33.899, "Study on the security aspects of the next 1588 generation system", 3GPP , 2017. 1590 [TS36.323] 1591 3gpp-36.323, "Technical Specification Group Radio Access 1592 Network; Evolved Universal Terrestrial Radio Access 1593 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1594 specification (Rel. 15)", 3GPP , January 2019. 1596 [TS38.300] 1597 3gpp-38-300, "Technical Specification Group Radio Access 1598 Network; NR; NR and NG-RAN Overall Description; Stage 2 1599 (Rel.15)", 3GPP , January 2019. 1601 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1602 Wang, "Towards software defined ICN based edge-cloud 1603 services", CloudNetworking(CloudNet), IEEE Internation 1604 Conference on, IEEE Internation Conference on 1605 CloudNetworking(CloudNet), 2013. 1607 Authors' Addresses 1609 Ravi Ravindran 1610 Huawei Research Center 1611 2330 Central Expressway 1612 Santa Clara 95050 1613 USA 1615 Email: ravi.ravindran@huawei.com 1616 URI: http://www.Huawei.com/ 1618 Prakash Suthar 1619 Cisco Systems 1620 9501 Technology Blvd. 1621 Rosemont 50618 1622 USA 1624 Email: psuthar@cisco.com 1625 URI: http://www.cisco.com/ 1626 Dirk Trossen 1627 InterDigital Inc. 1628 64 Great Eastern Street, 1st Floor 1629 London EC2A 3QR 1630 United Kingdom 1632 Email: Dirk.Trossen@InterDigital.com 1633 URI: http://www.InterDigital.com/ 1635 Chonggang Wang 1636 InterDigital Inc. 1637 1001 E Hector St, Suite 300 1638 Conshohocken PA 19428 1639 United States 1641 Email: Chonggang.Wang@InterDigital.com 1642 URI: http://www.InterDigital.com/ 1644 Greg White 1645 CableLabs 1646 858 Coal Creek Circle 1647 Louisville CO 80027 1648 USA 1650 Email: g.white@cablelabs.com