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