idnits 2.17.1 draft-irtf-icnrg-5gc-icn-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2019) is 1663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-04 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-02 Summary: 0 errors (**), 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 Consultant 4 Intended status: Informational P. Suthar 5 Expires: April 9, 2020 Cisco 6 D. Trossen 7 C. Wang 8 InterDigital Inc. 9 G. White 10 CableLabs 11 October 7, 2019 13 Enabling ICN in 3GPP's 5G NextGen Core Architecture 14 draft-irtf-icnrg-5gc-icn-00 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, including recent efforts to provide cellular Local Area 24 Network (LAN) connectivity, followed by extensions to 5GC's control 25 and user plane to support Packet Data Unit (PDU) sessions from 26 Information-Centric Networks (ICN). In addition, ICN over 5GLAN is 27 also described. 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 April 9, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. 5G NextGen Core Design Principles . . . . . . . . . . . . . . 5 66 4. 5GC Architecture with ICN Support . . . . . . . . . . . . . . 6 67 4.1. 5G NextGen Core Architecture . . . . . . . . . . . . . . 6 68 4.2. ICN over 5GC . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.1. Control Plane Extensions . . . . . . . . . . . . . . 10 70 4.2.2. User Plane Extensions . . . . . . . . . . . . . . . . 13 71 4.2.3. Dual Stack ICN Deployment . . . . . . . . . . . . . . 16 72 5. 5GLAN Architecture with ICN Support . . . . . . . . . . . . . 23 73 5.1. 5GC Architecture Extensions for 5GLAN Support . . . . . . 23 74 5.1.1. Realization of Nx Interface . . . . . . . . . . . . . 24 75 5.1.2. Bitfield-based Forwarding in Existing Transport 76 Networks . . . . . . . . . . . . . . . . . . . . . . 25 77 5.2. ICN over 5GLAN . . . . . . . . . . . . . . . . . . . . . 26 78 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 27 79 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 83 11. Informative References . . . . . . . . . . . . . . . . . . . 29 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 86 1. Introduction 88 The objective of this draft is to propose an architecture to enable 89 information-centric networking (ICN) in the proposed 5G Next- 90 generation Core network architecture (5GC) by leveraging its 91 flexibility to allow new user and associated control plane functions. 92 The reference architectural discussions in the 5G core network 3GPP 93 specifications [TS23.501][TS23.502] form the basis of our 94 discussions. This draft also complements the discussions related to 95 various ICN deployment opportunities explored in 96 [I-D.irtf-icnrg-deployment-guidelines], where 5G technology is 97 considered as one of the promising alternatives for internet 98 connectivity. 100 Though ICN is a general networking technology, it would benefit 5G 101 particularly from the perspective of mobile edge computing (MEC). 102 The following ICN features shall benefit MEC deployments in 5G: 104 o Edge Computing: Multi-access Edge Computing (MEC) is located at 105 the edge of the network and aids several latency sensitive 106 applications such as augmented and virtual reality (AR/VR), as 107 well as the ultra reliable and low latency class (URLLC) of 108 applications such as autonomous vehicles. Enabling edge computing 109 over an IP converged 5GC comes with the challenge of application 110 level reconfiguration required to re-initialize a session whenever 111 it is being served by a non-optimal service instance 112 topologically. In contrast, named-based networking, as considered 113 by ICN, naturally supports service-centric networking, which 114 minimizes network related configuration for applications and 115 allows fast resolution for named service instances. 117 o Edge Storage and Caching : A principal design feature of ICN is 118 the secured content (or named-data) object, which allows location 119 independent data replication at strategic storage points in the 120 network, or data dissemination through ICN routers by means of 121 opportunistic caching. These features benefit both real-time and 122 non-real-time applications whenever there is spatial and temporal 123 correlation among content accessed by these users, thereby 124 advantageous to both high-bandwidth and low-latency applications 125 such as conferencing, AR/VR, and non-real time applications such 126 as Video-on-Demand (VOD) and IoT transactions. 128 o Session Mobility: Existing long-term evolution (LTE) deployments 129 handle session mobility using centralized routing with the Mobile 130 Management Entity (MME) function, IP anchor points at Packet Data 131 Network Gateway (PDN-GW) and service anchor point called Access 132 Point Name (APN) functionality hosted in PDN-GW. LTE uses tunnels 133 between radio edge (eNodeB) and PDN-GW for each mobile device 134 attached to network. This design fails when service instances are 135 replicated close to radio access network (RAN) instances, 136 requiring new techniques to handle session mobility. In contrast, 137 ICN uses a split between the application identifier and the name 138 resolution that is known to handle host mobility efficiently 139 [ICNMOB]. 141 In this document, we first discuss 5GC's design principles that allow 142 the support of new network architectures. Then we summarize the 5GC 143 proposal, followed by control and user plane extensions required to 144 support ICN PDU sessions. This is followed by discussions on 145 enabling IP over ICN over 3GPP proposed 5GLAN service framework. We 146 then discuss deployment considerations for both ICN over 5GC and IP 147 over ICN over 5GLAN. 149 2. Terminology 151 Following are terminologies relevant to this draft: 153 5G-NextGen Core (5GC): Refers to the new 5G core network 154 architecture being developed by 3GPP, we specifically refer to the 155 architectural discussions in [TS23.501][TS23.502]. 157 5G-New Radio (5G-NR): This refers to the new radio access 158 interface developed to support 5G wireless interface [TS38.300]. 160 User Plane Function (UPF): UPF is the generalized logical data 161 plane function with context of the UE PDU session. UPFs can play 162 many role, such as, being an flow classifier (UL-CL) (defined 163 next), a PDU session anchoring point, or a branching point. 165 Uplink Classifier (UL-CL): This is a functionality supported by an 166 UPF that aims at diverting traffic (locally) to local data 167 networks based on traffic matching filters applied to the UE 168 traffic. 170 Packet Data Network (PDN or DN): This refers to service networks 171 that belong to the operator or third party offered as a service to 172 the UE. 174 Unified Data Management (UDM): Manages unified data management for 175 wireless, wireline and any other types of subscribers for M2M, IOT 176 applications, etc. UDM reports subscriber related vital 177 information e.g. virtual edge region, list of location visits, 178 sessions active etc. UDM works as a subscriber anchor point so 179 that means OSS/BSS systems will have centralized monitoring-of/ 180 access-to of the system to get/set subscriber information. 182 Authentication Server Function (AUSF): Provides mechanism for 183 unified authentication for subscribers related to wireless, 184 wireline and any other types of subscribers such as M2M and IOT 185 applications. The functions performed by AUSF are similar to HSS 186 with additional functionalities to related to 5G. 188 Session Management Function (SMF): Performs session management 189 functions for attached users equipment (UE) in the 5G Core. SMF 190 can thus be formed by leveraging the CUPS (discussed in the next 191 section) feature with control plane session management. 193 Access Mobility Function (AMF): Perform access mobility management 194 for attached user equipment (UE) to the 5G core network. The 195 function includes, network access stratus (NAS) mobility functions 196 such as authentication and authorization. 198 Application Function (AF): Helps with influencing the user plane 199 routing state in 5GC considering service requirements. 201 Network Slicing: This conceptualizes the grouping for a set of 202 logical or physical network functions with its own or shared 203 control, data and service plane to meet specific service 204 requirements. 206 5GLAN Service: A service over the 5G system offering private 207 communication using IP and/or non-IP type communications. 209 3. 5G NextGen Core Design Principles 211 The 5GC architecture is based on the following design principles that 212 allows it to support new service networks like ICN efficiently 213 compared to LTE networks: 215 o Control and User plane split (CUPS): This design principle moves 216 away from LTE's vertically integrated control/user plane design 217 (i.e., Serving Gateway, S-GW, and Packet Data Network Gateway, 218 P-GW) to one espousing an NFV framework with network functions 219 separated from the hardware for service-centricity, scalability, 220 flexibility and programmability. In doing so, network functions 221 can be implemented both physically and virtually, while allowing 222 each to be customized and scaled based on their individual 223 requirements, also allowing the realization of multi-slice co- 224 existence. This feature also allows the introduction of new user 225 plane functions (UPF) in 5GC. UPFs can play many roles, such as, 226 being an uplink flow classifier (UL-CL), a PDU session anchor 227 point, a branching point function, or one based on new network 228 architectures like ICN with new control functions, or re-using/ 229 extending the existing ones to manage the new user plane 230 realizations. 232 o Decoupling of RAT and Core Network : Unlike LTE's unified control 233 plane for access and the core, 5GC offers control plane separation 234 of the RAN from the core network. This allows the introduction of 235 new radio access technologies (RAT) along with slices based on new 236 network architectures, offering the ability to map heterogeneous 237 RAN flows to arbitrary core network slices based on service 238 requirements. 240 o Non-IP PDU Session Support : A PDU session is defined as the 241 logical connection between the UE and the data network (DN). 5GC 242 offers a scope to support both IP and non-IP PDU (termed as 243 "unstructured" payload), and this feature can potentially allow 244 the support for ICN PDUs by extending or re-using the existing 245 control functions. More discussions on taking advantage of this 246 feature in ICN's context is presented in Section 4.2.2.2. 248 o Service Centric Design: 5GC's service orchestration and control 249 functions, such as naming, addressing, registration/authentication 250 and mobility, will utilize an API design similar to those used in 251 cloud technologies. Doing so enables opening up interfaces for 252 authorized service function interaction and creating service level 253 extensions to support new network architectures. These APIs 254 include the well accepted Get/Response and Pub/Sub approaches, 255 while not precluding the use of point-to-point procedural approach 256 among 5GC functional units (where necessary). 258 o Distributed LAN Support: utilizing the aforementioned unstructured 259 PDU session support, 5GC offers the capability to expose a Layer 2 260 LAN service to cellular user equipment. Such distributed LAN 261 targets to complement those in fixed broadband, including local 262 WLAN fanouts. Through such LAN capability, services can be 263 realized by being virtually embedded into an intranet deployment 264 with dedicated Internet-facing packet gateway functionality. 265 Examples for such services, among others, are those related to 266 Industrial IoT, smart city services and others. Utilizing this 267 capability for ICN-based services is presented in Section 5.1. 269 4. 5GC Architecture with ICN Support 271 4.1. 5G NextGen Core Architecture 273 In this section, for brevity purposes, we restrict the discussions to 274 the control and user plane functions relevant to an ICN deployment 275 discussion in Section 4.2. More exhaustive discussions on the 276 various architecture functions, such as registration, connection and 277 subscription management, can be found in[TS23.501][TS23.502]. 279 +------+ 280 +-----+ +-------+ +------+ | AF-2 | 281 |NSSF | |PCF/UDM| | AF-1 | +---+--+ 282 +--+--+ +--+----+ +--+---+ | 283 | | | +---+---+ 284 +--+-------+--+ +---+-----+ | | 285 | |N11| | | SMF-2 | 286 | AMF +---+ SMF-1 | | | 287 | | | | +---+---+ 288 +----+----+---+ +----+----+ | 289 | | |------------------------+ 290 +---+ | | |N4 |N4 291 N1| |N2 |N4 | +----------+---------+ 292 | | | +----+ UPF | N6 +----+ 293 +-+-+ +--+--+ +---+---+ | | |(PDU Session Anchor)+----+ DN | 294 | | | | | | N9 | | | | | | 295 |UE | | RAN | N3 | UPF +----+ | +--------------------+ +----+ 296 | +---+ +-----+(UL-CL)| | 297 | | | | | +----+ +-------------+ 298 +---+ +-----+ +-------+ N9 | | 299 | +----------+---------+ 300 +----+ UPF | +----+ 301 |(PDU Session Anchor)| N6 | DN | 302 | +----+ | 303 +--------------------+ +----+ 305 Figure 1: 5G Next Generation Core Architecture 307 In Figure 1, we show one variant of a 5GC architecture from 308 [TS23.501], for which the functions of UPF's branching point and PDU 309 session anchoring are used to support inter-connection between a UE 310 and the related service or packet data networks (or PDNs) managed by 311 the signaling interactions with control plane functions. In 5GC, 312 control plane functions can be categorized as follows: 314 o Common control plane functions that are common to all slices and 315 which include the Network Slice Selection Function (NSSF), Policy 316 Control Function (PCF), and Unified Data Management (UDM) among 317 others. 319 o Shared or slice specific control functions, which include the 320 Access and Mobility Function (AMF), Session and Management 321 Function (SMF) and the Application Function (AF). 323 AMF serves multiple purposes: (i) device authentication and 324 authorization; (ii) security and integrity protection to non-access 325 stratum (NAS) signaling; (iii) tracking UE registration in the 326 operator's network and mobility management functions as the UE moves 327 among different RANs, each of which might be using different radio 328 access technologies (RAT). 330 NSSF handles the selection of a particular slice for the PDU session 331 request from the user entity (UE) using the Network Slice Selection 332 Assistance Information (NSSAI) parameters provided by the UE and the 333 configured user subscription policies in PCF and UDM functions. 334 Compared to LTE's evolved packet core (EPC), where PDU session states 335 in RAN and core are synchronized with respect to management, 5GC 336 decouples this using NSSF by allowing PDU sessions to be defined 337 prior to a PDU session request by a UE (for other differences see 338 [lteversus5g] ). This decoupling allows policy based inter- 339 connection of RAN flows with slices provisioned in the core network. 340 This functionality is useful particularly towards new use cases 341 related to M2M and IOT devices requiring pre-provisioned network 342 resources to ensure appropriate SLAs. 344 SMF is used to handle IP anchor point selection and addressing 345 functionality, management of the user plane state in the UPFs (such 346 as in uplink classifier (UL-CL), IP anchor point and branching point 347 functions) during PDU session establishment, modification and 348 termination, and interaction with RAN to allow PDU session forwarding 349 in uplink/downlink (UL/DL) to the respective DNs. SMF decisions are 350 also influenced by AF to serve application requirements, for e.g., 351 actions related to introducing edge computing functions. 353 In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN 354 protocol[TS38.300]. From the RAN, the PDU's five tuple header 355 information (IP source/destination, port, protocol etc.) is used to 356 map the flow to an appropriate tunnel from RAN to UPF. Though the 357 current 5GC proposal[TS23.501] follows LTE on using GPRS tunneling 358 protocol (GTP) tunnel from NR to the UPF to carry data PDUs and 359 another one for the control messages to serve the control plane 360 functions; there are ongoing discussions to arrive upon efficient 361 alternatives to GTP. 363 4.2. ICN over 5GC 365 In this section, we focus on control and user plane enhancements 366 required to enable ICN within 5GC, and identify the interfaces that 367 require extensions to support ICN PDU sessions. Explicit support for 368 ICN PDU sessions within access and 5GC networks will enable 369 applications to leverage the core ICN features while offering it as a 370 service to 5G users. 372 +------------+ 373 | 5G | 374 | Services | 375 | (NEF) | +----------------+ 376 +-------+----+ | ICN | 377 | +--------+ Service | 378 | | | Orchestrator | 379 | | +-------+--------+ 380 +----+ +-------+ Npcf++/Nudm++ +-+---+-+ | 381 |NSSF| |PCF/UDM+-----------------+ ICN-AF| | 382 +-+--+ +-+-----+ +---+---+ +------+--------+ 383 | | | | ICN | 384 | | | +---+Service/Network| 385 +-+------+-+ +-------+ +---+---+ | | Controller | 386 | |N11++ | |Naf++ | +---+ +-----------+---+ 387 | AMF++ +------+ SMF++ +------+ICN-SMF| | 388 | | | | | | | 389 +----+--+--+ +---+---+ +---+---+ | 390 | | | |NIcn | 391 | +-------+ +-------+ +----------+ | 392 | | | | | 393 | | | +---+--+ +--+---+ 394 |N1++ |N2 |N4 | | | | 395 | | | +----+ICN-GW+------+ICN-DN| 396 | | +----+----+ | N9 | +UPF | N6 | | 397 +----+-+ +-----+----+ | | | +------+ +------+ 398 | | |RAN +----+| | UL-CL/ +---+ 399 |ICN-UE+--+ |UPF || |Branching| 400 | | | +----++---+ Point | 401 | | | +------+| N3| +---+ +------+ 402 +------+ | |ICN-GW|| +---------+ | N9 | Local| 403 | +------+| +----+ICN-DN| 404 +----------+ +------+ 406 Figure 2: 5G Next Generation Core Architecture with ICN support 408 For an ICN-enabled 5GC network, the assumption is that the UE may 409 have applications that can run over ICN or IP, for instance, UE's 410 operating system offering applications to operate over ICN [Jacobson] 411 or IP-based networking sockets. There may also be cases where UE is 412 exclusively based on ICN. In either case, we identify an ICN enabled 413 UE as ICN-UE. Different options exist to implement ICN in UE as 414 described in [I-D.irtf-icnrg-icn-lte-4g] which is also applicable for 415 5G UE to enable formal ICN session handling, such as, using a 416 Transport Convergence Layer (TCL) above 5G-NR, through IP address 417 assignment from 5GC or using 5GC provision of using unstructured PDU 418 session mode during the PDU session establishment process, which is 419 discussed in Section 4.2.2.2. Such convergence layer would implement 420 necessary IP over ICN mappings, such as those described in [TROSSEN], 421 for IP-based applications that are assigned to be transported over an 422 ICN network. 5G UE can also be non-mobile devices or an IOT device 423 using radio specification which can operate based on [TS38.300]. 425 5GC will take advantage of network slicing function to instantiate 426 heterogeneous slices, the same framework can be extended to create 427 ICN slices as well [Ravindran]. This discussion also borrows ideas 428 from[TS23.799], which offers a wide range of architectural 429 discussions and proposals on enabling slices and managing multiple 430 PDU sessions with local networks (with MEC) and its associated 431 architectural support (in the service, control and data planes) and 432 procedures within the context of 5GC. 434 Figure 2 shows the proposed ICN-enabled 5GC architecture. In the 435 figure, the new and modified functional components are identified 436 that interconnects an ICN-DN with 5GC. The interfaces and functions 437 that require extensions to enable ICN as a service in 5GC can be 438 identified in the figure with a '++' symbol. We next summarize the 439 control, user plane and normative interface extensions that help with 440 the formal ICN support. 442 4.2.1. Control Plane Extensions 444 To support interconnection between ICN UEs and the appropriate ICN DN 445 instances, we consider the following additional control plane 446 extensions to orchestrate ICN services in coordination with 5GC's 447 control components. 449 o Authentication and Mobility Function (AMF++): ICN applications in 450 the UEs have to be authorized to access ICN DNs. For this 451 purpose, as in [TS23.501], operator enables ICN as a DN offering 452 ICN services. As a network service, ICN-UE should also be 453 subscribed to it and this is imposed using the PCF and UDM, which 454 may interface with the ICN Application Function (ICN-AF) for 455 subscription and session policy management of ICN PDU sessions. 456 To enable ICN stack in the UE, AMF++ function has to be enabled 457 with the capability of authenticating UE's attach request for ICN 458 resources in 5GC. The request can be incorporated in NSSI 459 parameter to request either ICN specific slice or using ICN in 460 existing IP network slice when the UE is dual stacked. AMF++ can 461 potentially be extended to also support ICN specific bootstrapping 462 (such as naming and security) and forwarding functions to 463 configure UE's ICN layer. These functions can also be handled by 464 the ICN-AF and ICN control function in the UE after setting PDU 465 session state in 5GC. Here, the recommendation is not about 466 redefining the 5G UE attach procedures, but to extend the attach 467 procedures messages to carry ICN capabilities extensions in 468 addition to supporting existing IP based services. The extensions 469 should allow a 5G UE to request authentication to 5GC either in 470 ICN, IP or dual-stack (IP and ICN) modes. Further research is 471 required to optimize 5G attach procedures so that an ICN capable 472 UE can be bootstrapped by minimizing the number of control plane 473 messages. One possibility is to leverage existing 5G UE attach 474 procedures as described in 3GPP's [TS23.502], where the UE can 475 provide ICN identity in the LTE equivalent protocol configuration 476 option information element (PCO-IE) message during the attach 477 request as described in [I-D.irtf-icnrg-icn-lte-4g]. In addition, 478 such requirement can be also be provided by the UE in NSSI 479 parameters during initial attach procedures. Alternately, ICN 480 paradigm offers name-based control plane messaging and security 481 which one can leverage during the 5G UE attach procedures, however 482 this requires further research. 484 o Session Management Function (SMF++): Once a UE is authenticated to 485 access ICN service in network, SMF manages to connect UE's ICN PDU 486 sessions to the ICN DN in the UL/DL. SMF++ should be capable to 487 manage both IP, ICN or dual stack UE with IP and ICN capabilities. 488 To support ICN sessions, SMF++ creates appropriate PDU session 489 policies in the UPF, which include UL-CL and ICN gateway (ICN-GW) 490 (discussed in Section 4.2.2) through the ICN-SMF. For centrally 491 delivered services, ICN-GW could also multiplex as an IP anchor 492 point for IP applications. If MEC is enabled, these two functions 493 would be distributed, as the UL-CL will re-route the flow to a 494 local ICN-DN. 3GPP has defined IP based session management 495 procedures to handle UE PDU sessions in TS23.502. For ICN UE we 496 can either leverage same procedures when ICN is deployed as an 497 overlay protocol. Towards this, SMF++ interfaces with AMF++ over 498 N11++ to enable ICN specific user plane functions, which include 499 tunnel configuration and traffic filter policy to inter-connect UE 500 with the appropriate radio and the core slice. Furthermore, AMF++ 501 sets appropriate state in the RAN and the UE that directs ICN 502 flows to the chosen ICN UL-CL in the core network, and towards the 503 right UE in the downlink. 505 o ICN Session Management Function (ICN-SMF): ICN-SMF serves as 506 control plane for the ICN state managed in ICN-GW. This function 507 can be either incorporated as part of SMF++ or as a stand-alone 508 one. This function interacts with SMF++ to obtain and also push 509 ICN PDU session management information for the creation, 510 modification and deletion of ICN PDU sessions in ICN-GW. For 511 instance, when new ICN slices are provisioned by the ICN service 512 orchestrator, ICN-SMF requests a new PDU session to the SMF that 513 extends to the RAN. While SMF++ manages the tunnels to 514 interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate 515 forwarding state in ICN-GW (using the forwarding information base 516 or FIB) to enable ICN flows over appropriate tunnel interfaces 517 managed by the SMF++. In addition, it also signals resource 518 management rules to share compute, bandwidth, storage/cache 519 resources among multiple slice instances co-located in the ICN-GW. 521 o ICN Application Function (ICN-AF): ICN-AF represents the 522 application controller function that interfaces with ICN-SMF and 523 PCF/UDM function in 5GC. In addition to transferring ICN 524 forwarding rules to ICN-SMF, ICN-AF also interfaces with PCF/UDM 525 to transfer user profile and subscription policies along with 526 session management requirement to UE's ICN PDU session in the 5GC 527 network. ICN-AF is an extension of the ICN service orchestration 528 function, which can influence both ICN-SMF and in-directly SMF++ 529 to steer traffic based on ICN service requirements. ICN-AF can 530 also interact with the northbound 5G operator's service functions, 531 such as network exposure function(NEF) that exposes network 532 capabilities, for e.g. location based services, that can be used 533 by ICN-AF for proactive ICN PDU session and slice management and 534 offer additional capabilities to the ICN slices. 536 4.2.1.1. Normative Interface Extensions 538 o N1++/N11++: This extension enables ICN specific control functions 539 to support ICN authentication, configuration and programmability 540 of an ICN-UE via AMF++ and SMF++, and also impose QoS 541 requirements, handle mobility management of an ICN PDU session in 542 5GC based on service requirements. 544 o N4: Though this signaling is service agnostic, as discussed in 545 Section 4.2.2, future extensions may include signaling to enable 546 ICN user plane features in these network functions. The extension 547 of N4 to RAN is to handle the case when UPF function collocates 548 with the RAN instance to enable localized ICN DNs. 550 o NIcn: This extension shall support two functions: (i) control 551 plane programmability to enable ICN PDU sessions applicable to 5GC 552 to map to name based forwarding rules in ICN-GW; (ii)control plane 553 extensions to enable ICN mobility anchoring at ICN-GW, in which 554 case it also acts as POA for ICN flows. Features such as ICN 555 mobility as a service can be supported with this extension 556 [ICNMOB]. 558 o Naf++: This extension supports 5GC control functions such as 559 naming, addressing, mobility, and tunnel management for ICN PDU 560 sessions to interact with SMF++ and AMF++. 562 o Npcf++/Nudm++: This extension creates an interface to push ICN 563 service and PDU session requirements to PCF and UDM functions that 564 interact with the ICN-AF function for ICN slice specific 565 configuration. These requirements are enforced at various steps, 566 for instance, during ICN application registration, authentication, 567 slice mapping, and provisioning of resources for these PDU 568 sessions in the UPF. 570 4.2.2. User Plane Extensions 572 The interconnection of a UE to an ICN-DN comprises of two segments, 573 one from RAN to UL-CL and the other from UL-CL to ICN-GW. These 574 segments use IP tunneling constructs, where the service semantic 575 check at UL-CL is performed using IP's five tuples to determine both 576 UL and DL tunnel mappings. We summarize the relevant UPFs and the 577 interfaces for handling ICN PDU sessions as follows. 579 o ICN Gateway (ICN-GW): ICN-GW is where the 5GC PDU sessions 580 terminate and ICN service network begins. Compared to the 581 traditional anchor points as in PGW, the ICN-GW is also a service 582 gateway as it can host services or cache content enabled through 583 the ICN architecture. The ICN-GW also includes the UPF functions 584 to manage multiple tunnel interfaces enabling the relay of ICN PDU 585 flows to appropriate UL-CL instances in the DL. Note that there 586 may be multiple ICN-GWs serving different ICN services or slices. 587 ICN-GW also manages other ICN functions such as enforcing the 588 dynamic name based forwarding state, mobility state, in-network 589 service function management, resource management with respect to 590 sharing caching, storage, and compute resources among multiple 591 services[Ravindran]. 593 o ICN Data Network (ICN-DN): ICN-DN represents a set of ICN nodes 594 used for ICN networking and with heterogeneous service resources 595 such as storage and computing points. An ICN network enables both 596 network and application services, with network services including 597 caching, mobility, multicast, multi-path routing (and possibly 598 network layer computing), and application services including 599 network resources (such as cache, storage, network state 600 resources) dedicated to the application. 602 * Considering multiple ICN architecture proposals and multiple 603 ICN deployment models discussed in 604 [I-D.irtf-icnrg-deployment-guidelines], an alternate backward 605 compatible (IP-over-)ICN solution is proposed in [TROSSEN]. 606 Such an ICN-DN can simply consist of SDN forwarding nodes and a 607 logically centralized path computation entity (PCE), where the 608 PCE is used to determine suitable forwarding identifiers being 609 used for the path-based forwarding in the SDN-based transport 610 network. In addition, the PCE is responsible for maintaining 611 the appropriate forwarding rules in the SDN switches. For 612 interconnection to IP-based peering networks, a packet gateway 613 is being utilized that mirrors the convergence layer 614 functionality to map incoming ICN traffic back in to outgoing 615 IP traffic and vice versa. This form of deployment would 616 require minimal changes to the 5GC's user and control plane 617 procedures, as the applications on these IP end points are not 618 exposed (or minimally exposed) to any ICN state or 619 configuration. 621 o Uplink Classifier (UL-CL): UL-CL enables classification of flows 622 based on source or destination IP address and steers the traffic 623 to an appropriate network or service function anchor point. If 624 the ICN-GW is identified based on service IP address associated 625 with the ICN-UE's flows, UL-CL checks the source or destination 626 address to direct traffic to an appropriate ICN-GW. For native 627 ICN UE, ICN shall be deployed over 5G-NR; here, there may not be 628 any IP association. For such packet flows new classification 629 schema shall be required, such as, using 5G-NR protocol extensions 630 to determine the tunnel interface to forward the ICN payload on, 631 towards the next ICN-GW. 633 4.2.2.1. Normative Interface Extensions 635 o N3: Though the current architecture supports heterogeneous service 636 PDU handling, future extensions can include user plane interface 637 extensions to offer explicit support to ICN PDU session traffic, 638 for instance, an incremental caching and computing function in RAN 639 or UL-CL to aid with content distribution. 641 o N9: Extensions to this interface can consider UPFs to enable 642 richer service functions, for instance to aid context processing. 643 In addition extensions to enable ICN specific encapsulation to 644 piggyback ICN specific attributes such as traffic or mobility data 645 between the UPF branching point and the ICN-GW. 647 o N6: This interface is established between the ICN-GW and the ICN- 648 DN, whose networking elements in this segment can be deployed as 649 an overlay or as a native Layer-3 network. 651 4.2.2.2. ICN over non-IP PDU 653 5GC accommodates non-IP PDU support which is defined for Ethernet or 654 any unstructured data[TS23.501]. This feature allows native support 655 of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS 656 itself as shown in Figure 2. Formalizing this feature to recognize 657 ICN PDUs has many considerations: 659 o Attach Procedures for UE with Non-IP PDN: Assuming a 5GC can 660 support both IP and non-IP PDN, this requires control plane 661 support. In a typical scenario, when UE sends an attach message 662 to 5GC, the type of PDU connection is indicated in the PCO-IE 663 field, for e.g. in this case as being non-IP PDN to invoke related 664 control plane session management tasks. ICN over non-IP PDU 665 session will allow the UE to attach to 5GC without any IP 666 configuration. 5GC attach procedures specified [TS23.501] can be 667 used to support authentication of UE with PDN type set to non-IP, 668 using existing AUSF/UDM functions in coordination with the ICN-AF 669 function discussed earlier if required. 671 o User Plane for UE with Non-IP PDN: Without any IP tunnel 672 configuration and ICN's default consumer agnostic mode of 673 operation requires ways to identify the ICN-UE in the user plane, 674 this can be enabled by introducing network identifier in the lower 675 layers such as in the PDCP or MAC layer, that can assist for 676 functions such as policy and charging at the BS and related 677 session management tasks. These identifiers can also be used to 678 demultiplex the DL traffic from the ICN-GW in the BS to the 679 respective ICN-UEs. Also, ICN extensions can be incorporated in 680 control plane signaling to identify an ICN-UE device and these 681 parameters can be used by SMF to conduct non-IP routing. The 682 policing and charging functions can be enforced by the UPF 683 function in the BS which obtains the traffic filtering rules from 684 the SMF. To enable flat ICN network from the BS requires 685 distributed policy, charging and legal intercept which requires 686 further research. Further ICN slice multiplexing can be realized 687 by also piggybacking slice-ID (NSSI) along with device ID to 688 differentiate handover to multiple ICN slices at the base station. 689 Inter-working function (IWF) is required if services based on non- 690 IP UE has to transact or communicate with transport, applications 691 functions or other UE based on IP services. This also has 692 implications on how mobility is managed for such PDU sessions. 694 o Mobility Handling: Considering mobility can be support by ICN, it 695 is inefficient to traverse other intermediate IP networks between 696 the BS and the next ICN hop. This requires ICN PDU to be handled 697 by an ICN instance in the BS itself, in association with UL-CL 698 function local to the BS as shown in Figure 2. Control plane 699 extensions discussed in Section 4.2.1 can be used in tandem with 700 distributed mobility protocols to handle ICN mobility, one such 701 solution for producer mobility is proposed in [ICNMOB] 703 o Routing Considerations: Flat ICN network realizations also offers 704 the advantage of optimal routing, compared to anchor point based 705 realization in LTE. This also leads to optimal realization of the 706 data plane considering the absence of overhead due to tunneling 707 while forwarding ICN traffic. However, developing a routing 708 control plane in to handle the ICN PDU sessions either leveraging 709 SMF functions or a distributed realization requires more 710 investigation. In the centralized approach the SMF could interact 711 with ICN-SMF to set the forwarding rules in the ICN-GW in the BS 712 and other ICN-UPFs, however this may also lead to scalability 713 issues if a flat ICN network is to be realized. This also has 714 implications to route the non-IP PDU sessions efficiently to the 715 closest ICN-MEC instance of the service. 717 o IP over ICN: Native support of ICN in the RAN raises the 718 possibility of leveraging the mobility functions in ICN protocols 719 as a replacement for GTP tunneling in the 5GC, as described in 720 [I-D.white-icnrg-ipoc] and [TROSSEN]. 722 o Mobile Edge Computing: Another significant advantage is with 723 respect to service-centric edge computing at the ICN-GW or other 724 ICN points, either through explicit hosting of service 725 functions[VSER] in ICN or in-network computing based on NFN 726 proposal[NFN]. A certain level of orchestration is required to 727 ensure service interconnection and its placement with appropriate 728 compute resources and inter-connected with bandwidth resources so 729 that the desired SLA is offered. 731 4.2.3. Dual Stack ICN Deployment 733 4.2.3.1. 5G User Plane Protocol Stack 735 It is important to understand that a User Equipment (UE) can be 736 either consumer (receiving content) or publisher (pushing content for 737 other clients). The protocol stack inside mobile device (UE) is 738 complex as it has to support multiple radio connectivity access to 739 gNB(s). 741 +--------+ +--------+ 742 | App | | APP | 743 +--------+ +---------+ +--------+ 744 | IP |.....................................| IP |.|.| IP | 745 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 746 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 747 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 748 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 749 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 750 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 751 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 752 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 753 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 754 UE | gNB/RAN | UPF | UPF | DN 755 | | (UL-CL) | (PDU Anchor)| 756 Uu N3 N9 N6 758 Figure 3: 5G User Plane Protocol Stack 760 Figure 3 provides high level description of a 5G user plane protocol 761 stack, where: 1) the lower 4 layers (i.e. L1, MAC, RLC, PDCP) at UE 762 is for radio access and air interface to gNB; 2) the IP layer (i.e. 763 PDU layer) at UE is used for providing IP transport infrastructure to 764 support PDU session between UE and UPF (PDU Anchor); 3) GTP-U 765 provides tunneling between gNB and UPF, or between two UPFs. 766 Although UDP/IP exists under GTP-U, IP mainly refers to "IP" between 767 UE and UPF (PDU Anchor) for the rest of this document, unless 768 explicitly clarified; 4) UL-CL is only for uplink traffic and UPF 769 (UL-CL) shall not be needed for downlink traffic towards UE. 771 4.2.3.2. Protocol Stack for ICN Deployment in 5G 772 +--------+ +--------+ 773 | App | | APP | 774 +--------+ +---------+ +--------+ 775 | TCL |.....................................| TCL |.|.| TCL | 776 +--------+ +---------+ | +--------+ 777 | ICN&IP |.....................................| ICN&IP |.|.| ICN&IP | 778 | | | | | | | 779 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 780 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 781 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 782 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 783 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 784 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 785 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 786 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 787 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 788 UE | gNB/RAN | UPF | UPF | DN 789 | | (UL-CL) | (PDU Anchor)| 790 Uu N3 N9 N6 792 Figure 4: Dual Stack ICN Deployment 794 ICN can be deployed in dual stack model for 5G user plane as 795 illustrated in Figure 4, where: 1) both ICN and IP (i.e. dual stack) 796 can reside between TCL and PDCP to provide transport infrastructure 797 from UE to UPF (PDU Anchor); 2) in order to support the dual ICN&IP 798 transport layer, PDCP needs some enhancements; 3) a new Transport 799 Convergence Layer (TCL) is introduced to coordinate between 800 applications and ICN&IP transport layer; 4) Applications on top of 801 TCL could be ICN applications or IP applications. 803 With this dual stack model, four different cases are possible for the 804 deployment of ICN natively and/or with IP dependent on which types of 805 applications (ICN or IP) uses which types of underline transport (ICN 806 or IP), from the perspective of the applications either on UE (or 807 content provider). 809 Case 1. IP over IP (IPoIP) 811 In this scenario UE uses applications tightly integrated with the 812 existing IP transport infrastructure. In this option, the TCL has no 813 additional function since the packets are directly forwarded using IP 814 protocol stack, which in turn sends the packets over the IP 815 transport. 817 Case 2. ICN over ICN (ICNoICN) 818 Similar to case 1 above, ICN applications tightly integrate with the 819 ICN transport infrastructure. The TCL has no additional 820 responsibility since the packets are directly forwarded using ICN 821 protocol stack, which in turn sends the packets over the ICN 822 transport. 824 Case 3. ICN over IP (ICNoIP) 826 In ICN over IP scenario, the underlying IP transport infrastructure 827 is not impacted (i.e., ICN is implemented as an overlay over IP 828 between UE and content provider). IP routing is used from Radio 829 Access Network (gNB) to mobile backhaul, IP core and UPF. UE 830 attaches to UPF (PDU Anchor) using IP address. Content provider in 831 DN is capable of serving content either using IP or ICN, based on UE 832 request. 834 An alternative approach to implement ICN over IP is provided in 835 Hybrid ICN [I-D.muscariello-intarea-hicn], which implements ICN over 836 IP by mapping of ICN names to the IPv4/IPv6 addresses. 838 Case 4. IP over ICN (IPoICN) 840 In IP over ICN scenario, IP applications utilize an ICN-based routing 841 while preserving the overall IP protocol semantics, as shown, e.g., 842 in H2020 project [H2020]. Implementing IP services over ICN provides 843 an opportunity leveraging benefit of ICN in the transport 844 infrastructure. 846 Note that the IP over ICN case could be supported for pure IP (over 847 IP) UEs through introducing a Network Attachment Point (NAP) to 848 interface to an ICN network. Here, the UPF (PDU Anchor) interfaces 849 to said NAP in the northbound; alternatively, the NAP can be 850 integrated as a part of UPF (PDU Anchor). For this scheme, the NAP 851 provides a standard IP network interface towards the IP-enabled UE 852 via UPF (PDU Anchor), encapsulates any received IP service (e.g. 853 HTTP) request into an appropriate ICN packet which is then published 854 as an appropriately formed named information item. Conversely, the 855 NAP subscribes to any appropriately formed named information items, 856 where the information identifier represents any IP-exposed service 857 that is exposed at any IP-level UE locally connected to the NAP. Any 858 received ICN packet is then forwarded to the appropriate local IP- 859 enabled UE after being appropriately decapsulated, recovering the 860 original IP service (e.g. HTTP) request. 862 In a dual-stack UE that supports the above cases, the TCL helps 863 determine what type of transport (e.g. ICN or IP), as well as type 864 of radio interface (e.g. 5G or WiFi or both), is used to send and 865 receive the traffic based on preference e.g. content location, 866 content type, content publisher, congestion, cost, quality of service 867 etc. It helps to configure and decide the type of connection as well 868 as the overlay mode (ICNoIP or IPoICN, explained above) between 869 application and the protocol stack (IP or ICN) to be used. 871 TCL can use a number of mechanisms for the selection of transport 872 (i.e. ICN or IP). It can use a per application configuration 873 through a management interface, possibly even a user-facing setting 874 realized through a user interface, similar to those used today that 875 select cellular over WiFi being used for selected applications. In 876 another option, it might use a software API, which an adapted IP 877 application could use to specify e.g. an ICN transport for obtaining 878 its benefits. 880 Another potential application of TCL is in implementation of network 881 slicing, where it can have a slice management capability locally or 882 it can interface to an external slice manager through an API 883 [I-D.galis-anima-autonomic-slice-networking]. This solution can 884 enable network slicing for IP and ICN transport selection from the UE 885 itself. The TCL could apply slice settings to direct certain traffic 886 (or applications) over one slice and others over another slice, 887 determined by some form of 'slicing policy'. Slicing policy can be 888 obtained externally from slice manager or configured locally on UE. 890 4.2.3.3. Protocol Interactions and Impacts 891 +----------------+ +-----------------+ 892 | ICN App (New) | |IP App (Existing)| 893 +---------+------+ +-------+---------+ 894 | | 895 +---------+----------------+---------+ 896 | TCL (New) | 897 +------+---------------------+-------+ 898 | | 899 +------+------+ +------+-------+ 900 |ICN Function | | IP Function | 901 | (New) | | (Existing) | 902 +------+------+ +------+-------+ 903 | | 904 +------+---------------------+-------+ 905 | PDCP (Updated to Support ICN) | 906 +-----------------+------------------+ 907 | 908 +-----------------+------------------+ 909 | RLC (Existing) | 910 +-----------------+------------------+ 911 | 912 +-----------------+------------------+ 913 | MAC Layer (Existing) | 914 +-----------------+------------------+ 915 | 916 +-----------------+------------------+ 917 | Physical L1 (Existing) | 918 +------------------------------------+ 920 Figure 5: Dual Stack ICN Protocol Interactions at UE 922 The protocol interactions and impact of supporting tunneling of ICN 923 packet into IP or to support ICN natively are described in Figure 5. 925 o Existing application layer can be modified to provide options for 926 new ICN based application and existing IP based applications. UE 927 can continue to support existing IP based applications or host new 928 applications developed either to support native ICN as transport, 929 ICNoIP or IPoICN based transport. Application layer has the 930 option of selecting either ICN or IP transport layer as well as 931 radio interface to send and receive data traffic. Our proposal is 932 to provide a common Application Programming Interface (API) to the 933 application developers such that there is no impact on the 934 application development when they choose either ICN or IP 935 transport for exchanging the traffic with the network. TCL 936 function handles the interaction of application with the multiple 937 transport options. 939 o The TCL helps determine what type of transport (e.g. ICN or IP) 940 as well as type of radio interface (e.g. 5G NR or WiFi or both), 941 is used to send and receive the traffic. Application layer can 942 make the decision to select a specific transport based on 943 preference e.g. content location, content type, content publisher, 944 congestion, cost, quality of service etc. There can be an 945 Application Programming Interface (API) to exchange parameters 946 required for transport selection. The southbound interactions of 947 TCL will be either to IP or ICN at the network layer. When 948 selecting the IPoICN [TROSSEN] mode, the TCL is responsible for 949 receiving an incoming IP or HTTP packet and publishing the packet 950 under a suitable ICN name (i.e. the hash over the destination IP 951 address for an IP packet or the hash over the FQDN of the HTTP 952 request for an HTTP packet) to the ICN network. In the HTTP case, 953 the TCL maintains a pending request mapping table to map returning 954 responses to the originating HTTP request. The common API will 955 provide a common 'connection' abstraction for this HTTP mode of 956 operation, returning the response over said connection 957 abstraction, akin to the TCP socket interface, while implementing 958 a reliable transport connection semantic over the ICN from the UE 959 to the receiving UE or the PGW. If the HTTP protocol stack 960 remains unchanged, therefore utilizing the TCP protocol for 961 transfer, the TCL operates in local TCP termination mode, 962 retrieving the HTTP packet through said local termination. The 963 southbound interactions of the Transport Convergence Layer (TCL) 964 will be either to IP or ICN at the network layer. 966 o ICN function (forwarder) is introduced in parallel to the existing 967 IP layer. ICN forwarder contains functional capabilities to 968 forward ICN packets, e.g. Interest packet to gNB or response 969 "data packet" from gNB to the application. 971 o For dual stack scenario, when UE is not supporting ICN at network 972 layer, we use IP underlay to transport ICN packets. ICN function 973 will use IP interface to send Interest and Data packets for 974 fetching or sending data using ICN protocol function. This 975 interface will use ICN overlay over IP using any overlay tunneling 976 mechanism. 978 o To support ICN at network layer in UE, PDCP layer has to be aware 979 of ICN capabilities and parameters. PDCP is located in the Radio 980 Protocol Stack in the 5G Air interface, between IP (Network layer) 981 and Radio Link Control Layer (RLC). PDCP performs following 982 functions [TS36.323]: 984 * Data transport by listening to upper layer, formatting and 985 pushing down to Radio Link Layer (RLC). 987 * Header compression and decompression using Robust Header 988 Compression (ROHC). 990 * Security protections such as ciphering, deciphering and 991 integrity protection. 993 * Radio layer messages associated with sequencing, packet drop 994 detection and re-transmission etc. 996 o No changes are required for lower layer such as RLC, MAC and 997 Physical (L1) because they are not IP aware. 999 5. 5GLAN Architecture with ICN Support 1001 5.1. 5GC Architecture Extensions for 5GLAN Support 1003 In this section, we present an overview of ongoing work to provide 1004 cellular LAN connectivity over a 5GC compliant network for Release 16 1005 and above deployments. 1007 +------+ +------+ +-----+ +-----+ +-----+ +-----+ 1008 | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 1009 +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ 1010 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 1011 -----+-------+-+---------+--+------+-------+-+---------+--------- 1012 Nausf| Namf| Nsmf| 1013 +--o--+ +--o--+ +--o--+ 1014 | AUSF| | AMF | | SMF | 1015 +-----+ +-+-+-+ +--+--+ 1016 / | | 1017 +---------+ | | 1018 N1 / |N2 N4| +-N9/Nx-+ 1019 +------+ | | | | 1020 / | | | V 1021 +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ 1022 | UE +----------------+ (R)AN +------+ UPF +----->+ DN | 1023 +----+ +---------+ +---------------+ +----+ 1025 Figure 6: 5G Core Network with Vertical_LAN (5GLAN) Extensions 1027 Figure 6 shows the current 5G Core Network Architecture being 1028 discussed within the scope of the normative work addressing 5GLAN 1029 Type services in the 3GPP System Architecture Working Group 2 (3GPP 1030 SA2), referred formally as "5GS Enhanced support of Vertical and LAN 1031 Services" [SA2-5GLAN]. The goal of this work item is to provide 1032 distributed LAN-based connectivity between two or more terminals or 1033 User Equipment entities (UEs) connected to the 5G network. The 1034 Session Management Function (SMF) provides a registration and 1035 discovery protocol that allows UEs wanting to communicate via a 1036 relevant 5GLAN group towards one or more UEs also members of this 1037 5GLAN group, to determine the suitable forwarding information after 1038 each UE previously registered suitable identifier information with 1039 the SMF responsible to manage the paths across UEs in a 5GLAN group. 1040 UEs register and discover (obtain) suitable identifiers during the 1041 establishment of a Protocol Data Unit (PDU) Session or PDU Session 1042 Modification procedure. Suitable identifier information, according 1043 to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses 1044 (the latter is usually assigned during the session setup through the 1045 SMF). 1047 The SMF that manages the path across UEs in a 5GLAN group, then 1048 establishes the suitable procedures to ensure the forwarding between 1049 the required UPFs (user plane functions) to ensure the LAN 1050 connectivity between the UEs (user equipments) provided in the 1051 original request to the SMF. When using the N9 interface to the UPF, 1052 this forwarding will rely on a tunnel-based approach between the UPFs 1053 along the path, while the Nx interface uses path-based forwarding 1054 between UPFs, while LAN-based forwarding is utilized between the 1055 final UPF and the UE (utilizing the N3 interface towards the 1056 destination UE). 1058 5.1.1. Realization of Nx Interface 1060 In the following, we discuss ongoing work to realize the Nx 1061 interface, i.e., path-based forwarding is assumed with the 1062 utilization of a path identifier for the end-to-end LAN 1063 communication. Here, the path between the source and destination 1064 UPFs is encoded through a bitfield, provided in the packet header. 1065 Each bitposition in said bitfield represents a unique link in the 1066 network. Upon receiving an incoming packet, each UPF inspects said 1067 bitfield for the presence of any local link that is being served by 1068 one of its output ports. Such presence check is implemented via a 1069 simple binary AND and CMP operation. If no link is being found, the 1070 packet is dropped. Such bitfield-based path representation also 1071 allows for creating multicast relations in an ad-hoc manner by 1072 combining two or more path identifiers through a binary OR operation. 1073 Note that due to the assignment of a bitposition to a link, path 1074 identifiers are bidirectional and can therefore be used for request/ 1075 response communication without incurring any need for path 1076 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 receiving 1088 device, the end source MAC address is restored as the source MAC, 1089 creating the perception of a link-local L2 communication between the 1090 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 and the PATH_ID is the bitfield- 1102 based path identifier for the path-based forwarding. 1104 5.1.2. Bitfield-based Forwarding in Existing Transport Networks 1106 An emerging technology for Layer 2 forwarding that suits the 5GLAN 1107 architecture in Figure 6 is that of Software-defined networking (SDN) 1108 [SDNDef], which allows for programmatically forwarding packets at 1109 Layer 2. Switch-based rules are being executed with such rules being 1110 populated by the SDN controller. Rules can act upon so-called 1111 matching fields, as defined by the OpenFlow protocol specification 1112 [OpenFlowSwitch]. Those fields include Ethernet MAC addresses, 1113 IPv4/6 source and destination addresses and other well-known Layer 3 1114 and even 4 transport fields. 1116 As shown in [Reed], efficient path-based forwarding can be realized 1117 in SDN networks by placing the aforementioned path identifiers into 1118 the IPv6 source/destination fields of a forwarded packet . Utilizing 1119 the IPv6 source/destination fields allows for natively supporting 256 1120 links in a transport network. Larger topologies can be supported by 1121 extension schemes but are left out of this paper for brevity of the 1122 presentation. During network bootstrapping, each link at each switch 1123 is assigned a unique bitnumber in the bitfield (through the SMF 1124 function of the 5GC). In order to forward based on such bitfield 1125 path information, the NR instructs the SDN controller to insert a 1126 suitable wildcard matching rule into the SDN switch. This wildcard 1127 at a given switch is defined by the bitnumber that has been assigned 1128 to a particular link at that switch during bootstrapping. Wildcard 1129 matching as a generalization of longest prefix matching is natively 1130 supported since the OpenFlow v1.3 specification, efficiently 1131 implemented through TCAM based operations. With that, SDN forwarding 1132 actions only depend on the switch-local number of output ports, while 1133 being able to transport any number of higher-layer flows over the 1134 same transport network without specific flow rules being necessary. 1135 This results in a constant forwarding table size while no controller- 1136 switch interaction is necessary for any flow setup; only changes in 1137 forwarding topology (resulting in a change of port to bitnumber 1138 assignment) will require suitable changes of forwarding rules in 1139 switches. 1141 Although we focus the methods in this draft on Layer 2 forwarding 1142 approaches, path-based transport networks can also be established as 1143 an overlay over otherwise Layer 2 networks. For instance, the BIER 1144 (Bit Indexed Explicit Replication) [RFC8279] efforts within the 1145 Internet Engineer Task Force (IETF) establish such path-based 1146 forwarding transport as an overlay over existing, e.g., MPLS 1147 networks. The path-based forwarding identification is similar to the 1148 aforementioned SDN realization although the bitfield represents 1149 ingress/egress information rather than links along the path. 1151 Yet another transport network example is presented in [Khalili], 1152 utilizing flow aggregation over SDN networks. The flow aggregation 1153 again results in a path representation that is independent from the 1154 specific flows traversing the network. 1156 5.2. ICN over 5GLAN 1158 ICN aims at replacing the routing functionality of the Internet 1159 Protocol (IP). It is therefore natively supported over a Layer 2 1160 transport network, such as Ethernet-based networks. Deployments 1161 exists over WiFi and local LAN networks, while usually overlaying 1162 (over IP) is being used for connectivity beyond localized edge 1163 networks. 1165 With the emergence of the 5GLAN capability in (future) Release 16 1166 based 5G networks, such cellular LAN connectivity to provide pure ICN 1167 could be utilized for pure ICN-based deployments, i.e. without the 1168 dual stack capability outlined in Section 4.2.3.2. With this, the 1169 entire 5G network would be interpreted as a local LAN, providing the 1170 necessary Layer 2 connectivity between the ICN network components. 1171 With the support of roaming in 5GLAN, such '5G network' can span 1172 several operators and therefore large geographies. 1174 Such deployment, however, comes without any core network integration, 1175 similar to the one outlined in Section 4.1, and therefore does not 1176 utilize ICN capabilities within the overall 5G core and access 1177 network. Benefits such as those outlined in the introduction, e.g., 1178 caching, would only exist at the endpoint level (from a 5GLAN 1179 perspective). 1181 However, ICN components could be provided as SW components in a 1182 network slice at the endpoints of such 5GLAN connectivity, utilizing 1183 in-network compute facilities, e.g., for caching, CCN routing 1184 capabilities and others. Such endpoint-driven realization of a 1185 specific ICN deployment scenario is described in more detail in [I- 1186 D.trossen-icnrg-IP-over-icn], focusing on the provisioning of IP- 1187 based services over an ICN, which in turn is provided over a LAN (and 1188 therefore also 5GLAN) based transport network. 1190 6. Deployment Considerations 1192 The work in [I-D.irtf-icnrg-deployment-guidelines] outlines a 1193 comprehensive set of considerations related to the deployment of ICN. 1194 We now relate the solutions proposed in this draft to the two main 1195 aspects covered in the deployment considerations draft, namely the 1196 'deployment configuration' (covered in Section 4 of 1197 [I-D.irtf-icnrg-deployment-guidelines]) that is being realized and 1198 the 'deployment migration paths' (covered in Section 5 of 1199 [I-D.irtf-icnrg-deployment-guidelines]) that are being provided. 1201 The solutions proposed in this draft relate to those 'deployment 1202 configuration' as follows: 1204 o The integration with the 5GC, as proposed in Section 4.2, follows 1205 the 'Clean-slate ICN' deployment configuration, i.e., integrating 1206 the ICN capabilities natively into the 5GC through appropriate 1207 extensions at the control and user plane level. 1209 o The utilization of the 5GLAN capabilities, as proposed in 1210 Section 5.2, follows the 'ICN-as-an-Overlay', interpreting the 1211 5GLAN as an overlay capability with no 5GC integration being 1212 considered (as in the 'Clean-slate ICN' configuration). 1214 o The deployment of 5GLAN based ICN capabilities can be realized 1215 following the 'ICN-as-a-Slice' deployment configuration, i.e., the 1216 5GLAN connectivity is provided to a 'vertical 5G customer' which 1217 in turn provides the ICN capability over 5GLAN within said network 1218 (and compute) slice at the endpoints of the 5GLAN connectivity, as 1219 proposed in Section 5.2. 1221 In relation of the 'deployment migration paths', the solutions in 1222 this draft relate as follows: 1224 o The integration with the 5GC, as proposed in Section 4.2, 1225 facilitates 'edge network migration' (interpreting the cellular 1226 sub-system here as an edge network albeit a possibly 1227 geographically large one). 1229 o The dual-stack deployment, as proposed in Section 4.2.3, 1230 facilitates 'application and services migration' through not only 1231 supporting ICN applications but also IP-based applications through 1232 the proposed IP-over-ICN mapping in the terminal. 1234 o The ICN over 5GLAN deployment, possibly combined with an ICN-as- 1235 a-Slice deployment, facilitates the 'content delivery networks 1236 migration' through a deployment of ICN-based 5GLAN connected CDN 1237 elements in (virtualized) edge network nodes or POP locations in 1238 the customer (5G) network. 1240 7. Conclusion 1242 In this draft, we explore the feasibility of realizing future 1243 networking architectures like ICN within the proposed 3GPP's 5GC 1244 architecture. Towards this, we summarized the design principles that 1245 offer 5GC the flexibility to enable new network architectures. We 1246 then discuss 5GC architecture aspects along with the user/control 1247 plane extensions required to handle ICN PDU sessions formally to 1248 realize ICN with 5GC integration as well as ICN over a pure 5GLAN 1249 connectivity. 1251 8. IANA Considerations 1253 This document requests no IANA actions. 1255 9. Security Considerations 1257 This draft proposes extensions to support ICN in 5G's next generation 1258 core architecture. ICN being name based networking opens up new 1259 security and privacy considerations which have to be studied in the 1260 context of 5GC. This is in addition to other security considerations 1261 of 5GC for IP or non-IP based services considered in [TS33.899]. 1263 10. Acknowledgments 1265 ... 1267 11. Informative References 1269 [H2020] H2020, "The POINT Project", https://www.point-h2020.eu/ . 1271 [I-D.galis-anima-autonomic-slice-networking] 1272 Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1273 Slice Networking", draft-galis-anima-autonomic-slice- 1274 networking-05 (work in progress), September 2018. 1276 [I-D.irtf-icnrg-deployment-guidelines] 1277 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1278 "Deployment Considerations for Information-Centric 1279 Networking (ICN)", draft-irtf-icnrg-deployment- 1280 guidelines-07 (work in progress), September 2019. 1282 [I-D.irtf-icnrg-icn-lte-4g] 1283 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1284 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1285 Networks", draft-irtf-icnrg-icn-lte-4g-04 (work in 1286 progress), September 2019. 1288 [I-D.muscariello-intarea-hicn] 1289 Muscariello, L., Carofiglio, G., Auge, J., and M. 1290 Papalini, "Hybrid Information-Centric Networking", draft- 1291 muscariello-intarea-hicn-02 (work in progress), June 2019. 1293 [I-D.white-icnrg-ipoc] 1294 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 1295 Tunneling over Content Centric Mobile Networks", draft- 1296 white-icnrg-ipoc-02 (work in progress), June 2019. 1298 [ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 1299 "Seamless Producer Mobility as a Service in Information 1300 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 1301 2016. 1303 [Jacobson] 1304 Jacobson, V. and et al., "Networking Named Content", 1305 Proceedings of ACM Context, , 2009. 1307 [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, 1308 "Reducing State of SDN Switches in Mobile Core Networks by 1309 Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, 1310 August 2016. 1312 [lteversus5g] 1313 Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and 1314 functions for 5G mobile communication system.", ICT 1315 Express 2017, 2017. 1317 [NFN] Sifalakis, M., Kohler, B., Christopher, C., and C. 1318 Tschudin, "An information centric network for computing 1319 the distribution of computations", ACM, ICN Sigcomm, 2014. 1321 [OpenFlowSwitch] 1322 Open Networking Foundation, available at 1323 https://www.opennetworking.org/wp-content/uploads/2014/10/ 1324 openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification 1325 V1.5.1", 2018. 1327 [Ravindran] 1328 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1329 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1330 Network Slicing", IEEE Communication Magazine, May, 2016. 1332 [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., 1333 Petropoulos, G., and S. Spirou, "Stateless Multicast 1334 Switching in Software Defined Networks", IEEE ICC 2016, 1335 Kuala Lumpur, Maylaysia, 2016. 1337 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1338 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1339 Explicit Replication (BIER)", RFC 8279, 1340 DOI 10.17487/RFC8279, November 2017, 1341 . 1343 [SA2-5GLAN] 1344 3gpp-5glan, "SP-181129, Work Item Description, 1345 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 1346 LAN Services", 3GPP , 1347 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 1348 181120.zip. 1350 [SDNDef] Open Networking Foundation, available at 1351 https://www.opennetworking.org/sdn-definition/, "Software- 1352 Defined Networking (SDN) Definition", 2018. 1354 [TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M., and 1355 G. Xylomenos, "IP Over ICN - The Better IP ?", EuCNC, 1356 European Conference on Networks and Communications , July, 1357 2015. 1359 [TS23.501] 1360 3gpp-23.501, "Technical Specification Group Services and 1361 System Aspects; System Architecture for the 5G System; 1362 Stage 2 (Rel.15)", 3GPP , December 2018. 1364 [TS23.502] 1365 3gpp-23.502, "Technical Specification Group Services and 1366 System Aspects; Procedures for the 5G System; Stage 2 1367 (Rel. 15)", 3GPP , January 2019. 1369 [TS23.799] 1370 3gpp-23.799, "Technical Specification Group Services and 1371 System Aspects; Study on Architecture for Next Generation 1372 System (Rel. 14)", 3GPP , 2017. 1374 [TS33.899] 1375 3gpp-33.899, "Study on the security aspects of the next 1376 generation system", 3GPP , 2017. 1378 [TS36.323] 1379 3gpp-36.323, "Technical Specification Group Radio Access 1380 Network; Evolved Universal Terrestrial Radio Access 1381 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1382 specification (Rel. 15)", 3GPP , January 2019. 1384 [TS38.300] 1385 3gpp-38-300, "Technical Specification Group Radio Access 1386 Network; NR; NR and NG-RAN Overall Description; Stage 2 1387 (Rel.15)", 3GPP , January 2019. 1389 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1390 Wang, "Towards software defined ICN based edge-cloud 1391 services", CloudNetworking(CloudNet), IEEE Internation 1392 Conference on, IEEE Internation Conference on 1393 CloudNetworking(CloudNet), 2013. 1395 Authors' Addresses 1397 Ravi Ravindran 1398 Consultant 1400 Email: ravi.ravindran@gmail.com 1401 Prakash Suthar 1402 Cisco Systems 1403 9501 Technology Blvd. 1404 Rosemont 50618 1405 USA 1407 Email: psuthar@cisco.com 1408 URI: http://www.cisco.com/ 1410 Dirk Trossen 1411 InterDigital Inc. 1412 64 Great Eastern Street, 1st Floor 1413 London EC2A 3QR 1414 United Kingdom 1416 Email: Dirk.Trossen@InterDigital.com 1417 URI: http://www.InterDigital.com/ 1419 Chonggang Wang 1420 InterDigital Inc. 1421 1001 E Hector St, Suite 300 1422 Conshohocken PA 19428 1423 United States 1425 Email: Chonggang.Wang@InterDigital.com 1426 URI: http://www.InterDigital.com/ 1428 Greg White 1429 CableLabs 1430 858 Coal Creek Circle 1431 Louisville CO 80027 1432 USA 1434 Email: g.white@cablelabs.com