idnits 2.17.1 draft-irtf-icnrg-5gc-icn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (February 4, 2020) is 1540 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-05 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-03 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 Sterlite Technologies 4 Intended status: Informational P. Suthar 5 Expires: August 7, 2020 Cisco 6 D. Trossen 7 Huawei 8 C. Wang 9 InterDigital Inc. 10 G. White 11 CableLabs 12 February 4, 2020 14 Enabling ICN in 3GPP's 5G NextGen Core Architecture 15 draft-irtf-icnrg-5gc-icn-02 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 August 7, 2020. 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] 95 form the basis of our discussions. This draft also complements the 96 discussions related to various ICN deployment opportunities explored 97 in [I-D.irtf-icnrg-deployment-guidelines], where 5G technology 98 promises to offer significantly better throughput, latency and 99 reliability 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 NSSI 469 parameter to request either ICN specific slice or using ICN in 470 existing IP network slice when the UE is dual stacked. AMF++ can 471 potentially be extended to also support ICN specific bootstrapping 472 (such as naming and security) and forwarding functions to 473 configure UE's ICN layer. These functions can also be handled by 474 the ICN-AF and ICN control function in the UE after setting PDU 475 session state in 5GC. Here, the recommendation is not about 476 redefining the 5G UE attach procedures, but to extend the attach 477 procedures messages to carry ICN capabilities extensions in 478 addition to supporting existing IP based services. The extensions 479 should allow a 5G UE to request authentication to 5GC either in 480 ICN, IP or dual-stack (IP and ICN) modes. Further research is 481 required to optimize 5G attach procedures so that an ICN capable 482 UE can be bootstrapped by minimizing the number of control plane 483 messages. One possibility is to leverage existing 5G UE attach 484 procedures as described in 3GPP's [TS23.502], where the UE can 485 provide ICN identity in the LTE equivalent protocol configuration 486 option information element (PCO-IE) message during the attach 487 request as described in [I-D.irtf-icnrg-icn-lte-4g]. In addition, 488 such requirement can be also be provided by the UE in NSSI 489 parameters during initial attach procedures. Alternately, ICN 490 paradigm offers name-based control plane messaging and security 491 which one can leverage during the 5G UE attach procedures, however 492 this requires further research. 494 o Session Management Function (SMF++): Once a UE is authenticated to 495 access ICN service in network, SMF manages to connect UE's ICN PDU 496 sessions to the ICN DN in the UL/DL. SMF++ should be capable to 497 manage both IP, ICN or dual stack UE with IP and ICN capabilities. 498 To support ICN sessions, SMF++ creates appropriate PDU session 499 policies in the UPF, which include UL-CL and ICN gateway (ICN-GW) 500 (discussed in Section 4.2.2) through the ICN-SMF. For centrally 501 delivered services, ICN-GW could also multiplex as an IP anchor 502 point for IP applications. If MEC is enabled, these two functions 503 would be distributed, as the UL-CL will re-route the flow to a 504 local ICN-DN. 3GPP has defined IP based session management 505 procedures to handle UE PDU sessions in TS23.502. For ICN UE we 506 can either leverage same procedures when ICN is deployed as an 507 overlay protocol. Towards this, SMF++ interfaces with AMF++ over 508 N11++ to enable ICN specific user plane functions, which include 509 tunnel configuration and traffic filter policy to inter-connect UE 510 with the appropriate radio and the core slice. Furthermore, AMF++ 511 sets appropriate state in the RAN and the UE that directs ICN 512 flows to the chosen ICN UL-CL in the core network, and towards the 513 right UE in the downlink. 515 o ICN Session Management Function (ICN-SMF): ICN-SMF serves as 516 control plane for the ICN state managed in ICN-GW. This function 517 can be either incorporated as part of SMF++ or as a stand-alone 518 one. This function interacts with SMF++ to obtain and also push 519 ICN PDU session management information for the creation, 520 modification and deletion of ICN PDU sessions in ICN-GW. For 521 instance, when new ICN slices are provisioned by the ICN service 522 orchestrator, ICN-SMF requests a new PDU session to the SMF that 523 extends to the RAN. While SMF++ manages the tunnels to 524 interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate 525 forwarding state in ICN-GW (using the forwarding information base 526 or FIB) to enable ICN flows over appropriate tunnel interfaces 527 managed by the SMF++. In addition, it also signals resource 528 management rules to share compute, bandwidth, storage/cache 529 resources among multiple slice instances co-located in the ICN-GW. 531 o ICN Application Function (ICN-AF): ICN-AF represents the 532 application controller function that interfaces with ICN-SMF and 533 PCF/UDM function in 5GC. In addition to transferring ICN 534 forwarding rules to ICN-SMF, ICN-AF also interfaces with PCF/UDM 535 to transfer user profile and subscription policies along with 536 session management requirement to UE's ICN PDU session in the 5GC 537 network. ICN-AF is an extension of the ICN service orchestration 538 function, which can influence both ICN-SMF and in-directly SMF++ 539 to steer traffic based on ICN service requirements. ICN-AF can 540 also interact with the northbound 5G operator's service functions, 541 such as network exposure function(NEF) that exposes network 542 capabilities, for e.g. location based services, that can be used 543 by ICN-AF for proactive ICN PDU session and slice management and 544 offer additional capabilities to the ICN slices. 546 4.2.1.1. Normative Interface Extensions 548 o N1++/N11++: This extension enables ICN specific control functions 549 to support ICN authentication, configuration and programmability 550 of an ICN-UE via AMF++ and SMF++, and also impose QoS 551 requirements, handle mobility management of an ICN PDU session in 552 5GC based on service requirements. 554 o N4: Though this signaling is service agnostic, as discussed in 555 Section 4.2.2, future extensions may include signaling to enable 556 ICN user plane features in these network functions. The extension 557 of N4 to RAN is to handle the case when UPF function collocates 558 with the RAN instance to enable localized ICN DNs. 560 o NIcn: This extension shall support two functions: (i) control 561 plane programmability to enable ICN PDU sessions applicable to 5GC 562 to map to name based forwarding rules in ICN-GW; (ii)control plane 563 extensions to enable ICN mobility anchoring at ICN-GW, in which 564 case it also acts as POA for ICN flows. Features such as ICN 565 mobility as a service can be supported with this extension 566 [ICNMOB]. 568 o Naf++: This extension supports 5GC control functions such as 569 naming, addressing, mobility, and tunnel management for ICN PDU 570 sessions to interact with SMF++ and AMF++. 572 o Npcf++/Nudm++: This extension creates an interface to push ICN 573 service and PDU session requirements to PCF and UDM functions that 574 interact with the ICN-AF function for ICN slice specific 575 configuration. These requirements are enforced at various steps, 576 for instance, during ICN application registration, authentication, 577 slice mapping, and provisioning of resources for these PDU 578 sessions in the UPF. 580 4.2.2. User Plane Extensions 582 The interconnection of a UE to an ICN-DN comprises of two segments, 583 one from RAN to UL-CL and the other from UL-CL to ICN-GW. These 584 segments use IP tunneling constructs, where the service semantic 585 check at UL-CL is performed using IP's five tuples to determine both 586 UL and DL tunnel mappings. We summarize the relevant UPFs and the 587 interfaces for handling ICN PDU sessions as follows. 589 o ICN Gateway (ICN-GW): ICN-GW is where the 5GC PDU sessions 590 terminate and ICN service network begins. Compared to the 591 traditional anchor points as in PGW, the ICN-GW is also a service 592 gateway as it can host services or cache content enabled through 593 the ICN architecture. The ICN-GW also includes the UPF functions 594 to manage multiple tunnel interfaces enabling the relay of ICN PDU 595 flows to appropriate UL-CL instances in the DL. Note that there 596 may be multiple ICN-GWs serving different ICN services or slices. 597 ICN-GW also manages other ICN functions such as enforcing the 598 dynamic name based forwarding state, mobility state, in-network 599 service function management, resource management with respect to 600 sharing caching, storage, and compute resources among multiple 601 services[Ravindran]. 603 o ICN Data Network (ICN-DN): ICN-DN represents a set of ICN nodes 604 used for ICN networking and with heterogeneous service resources 605 such as storage and computing points. An ICN network enables both 606 network and application services, with network services including 607 caching, mobility, multicast, multi-path routing (and possibly 608 network layer computing), and application services including 609 network resources (such as cache, storage, network state 610 resources) dedicated to the application. 612 * Considering multiple ICN architecture proposals and multiple 613 ICN deployment models discussed in 614 [I-D.irtf-icnrg-deployment-guidelines], an alternate backward 615 compatible (IP-over-)ICN solution is proposed in [TROSSEN]. 616 Such an ICN-DN can simply consist of SDN forwarding nodes and a 617 logically centralized path computation entity (PCE), where the 618 PCE is used to determine suitable forwarding identifiers being 619 used for the path-based forwarding in the SDN-based transport 620 network. In addition, the PCE is responsible for maintaining 621 the appropriate forwarding rules in the SDN switches. For 622 interconnection to IP-based peering networks, a packet gateway 623 is being utilized that mirrors the convergence layer 624 functionality to map incoming ICN traffic back in to outgoing 625 IP traffic and vice versa. This form of deployment would 626 require minimal changes to the 5GC's user and control plane 627 procedures, as the applications on these IP end points are not 628 exposed (or minimally exposed) to any ICN state or 629 configuration. 631 o Uplink Classifier (UL-CL): UL-CL enables classification of flows 632 based on source or destination IP address and steers the traffic 633 to an appropriate network or service function anchor point. If 634 the ICN-GW is identified based on service IP address associated 635 with the ICN-UE's flows, UL-CL checks the source or destination 636 address to direct traffic to an appropriate ICN-GW. For native 637 ICN UE, ICN shall be deployed over 5G-NR; here, there may not be 638 any IP association. For such packet flows new classification 639 schema shall be required, such as, using 5G-NR protocol extensions 640 to determine the tunnel interface to forward the ICN payload on, 641 towards the next ICN-GW. 643 4.2.2.1. Normative Interface Extensions 645 o N3: Though the current architecture supports heterogeneous service 646 PDU handling, future extensions can include user plane interface 647 extensions to offer explicit support to ICN PDU session traffic, 648 for instance, an incremental caching and computing function in RAN 649 or UL-CL to aid with content distribution. 651 o N9: Extensions to this interface can consider UPFs to enable 652 richer service functions, for instance to aid context processing. 653 In addition extensions to enable ICN specific encapsulation to 654 piggyback ICN specific attributes such as traffic or mobility data 655 between the UPF branching point and the ICN-GW. 657 o N6: This interface is established between the ICN-GW and the ICN- 658 DN, whose networking elements in this segment can be deployed as 659 an overlay or as a native Layer-3 network. 661 4.2.2.2. ICN over non-IP PDU 663 5GC accommodates non-IP PDU support which is defined for Ethernet or 664 any unstructured data[TS23.501]. This feature allows native support 665 of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS 666 itself as shown in Figure 2. Formalizing this feature to recognize 667 ICN PDUs has many considerations: 669 o Attach Procedures for UE with Non-IP PDN: Assuming a 5GC can 670 support both IP and non-IP PDN, this requires control plane 671 support. In a typical scenario, when UE sends an attach message 672 to 5GC, the type of PDU connection is indicated in the PCO-IE 673 field, for e.g. in this case as being non-IP PDN to invoke related 674 control plane session management tasks. ICN over non-IP PDU 675 session will allow the UE to attach to 5GC without any IP 676 configuration. 5GC attach procedures specified [TS23.501] can be 677 used to support authentication of UE with PDN type set to non-IP, 678 using existing AUSF/UDM functions in coordination with the ICN-AF 679 function discussed earlier if required. 681 o User Plane for UE with Non-IP PDN: Without any IP tunnel 682 configuration and ICN's default consumer agnostic mode of 683 operation requires ways to identify the ICN-UE in the user plane, 684 this can be enabled by introducing network identifier in the lower 685 layers such as in the PDCP or MAC layer, that can assist for 686 functions such as policy and charging at the BS and related 687 session management tasks. These identifiers can also be used to 688 demultiplex the DL traffic from the ICN-GW in the BS to the 689 respective ICN-UEs. Also, ICN extensions can be incorporated in 690 control plane signaling to identify an ICN-UE device and these 691 parameters can be used by SMF to conduct non-IP routing. The 692 policing and charging functions can be enforced by the UPF 693 function in the BS which obtains the traffic filtering rules from 694 the SMF. To enable flat ICN network from the BS requires 695 distributed policy, charging and legal intercept which requires 696 further research. Further ICN slice multiplexing can be realized 697 by also piggybacking slice-ID (NSSI) along with device ID to 698 differentiate handover to multiple ICN slices at the base station. 699 Inter-working function (IWF) is required if services based on non- 700 IP UE has to transact or communicate with transport, applications 701 functions or other UE based on IP services. This also has 702 implications on how mobility is managed for such PDU sessions. 704 o Mobility Handling: Considering mobility can be support by ICN, it 705 is inefficient to traverse other intermediate IP networks between 706 the BS and the next ICN hop. This requires ICN PDU to be handled 707 by an ICN instance in the BS itself, in association with UL-CL 708 function local to the BS as shown in Figure 2. Control plane 709 extensions discussed in Section 4.2.1 can be used in tandem with 710 distributed mobility protocols to handle ICN mobility, one such 711 solution for producer mobility is proposed in [ICNMOB] 713 o Routing Considerations: Flat ICN network realizations also offers 714 the advantage of optimal routing, compared to anchor point based 715 realization in LTE. This also leads to optimal realization of the 716 data plane considering the absence of overhead due to tunneling 717 while forwarding ICN traffic. However, developing a routing 718 control plane in to handle the ICN PDU sessions either leveraging 719 SMF functions or a distributed realization requires more 720 investigation. In the centralized approach the SMF could interact 721 with ICN-SMF to set the forwarding rules in the ICN-GW in the BS 722 and other ICN-UPFs, however this may also lead to scalability 723 issues if a flat ICN network is to be realized. This also has 724 implications to route the non-IP PDU sessions efficiently to the 725 closest ICN-MEC instance of the service. 727 o IP over ICN: Native support of ICN in the RAN raises the 728 possibility of leveraging the mobility functions in ICN protocols 729 as a replacement for GTP tunneling in the 5GC, as described in 730 [I-D.white-icnrg-ipoc] and [TROSSEN]. 732 o Mobile Edge Computing: Another significant advantage is with 733 respect to service-centric edge computing at the ICN-GW or other 734 ICN points, either through explicit hosting of service 735 functions[VSER] in ICN or in-network computing based on NFN 736 proposal[NFN]. A certain level of orchestration is required to 737 ensure service interconnection and its placement with appropriate 738 compute resources and inter-connected with bandwidth resources so 739 that the desired SLA is offered. 741 4.2.3. Dual Stack ICN Deployment 743 4.2.3.1. 5G User Plane Protocol Stack 745 It is important to understand that a User Equipment (UE) can be 746 either consumer (receiving content) or publisher (pushing content for 747 other clients). The protocol stack inside mobile device (UE) is 748 complex as it has to support multiple radio connectivity access to 749 gNB(s). 751 +--------+ +--------+ 752 | App | | APP | 753 +--------+ +---------+ +--------+ 754 | IP |.....................................| IP |.|.| IP | 755 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 756 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 757 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 758 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 759 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 760 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 761 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 762 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 763 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 764 UE | gNB/RAN | UPF | UPF | DN 765 | | (UL-CL) | (PDU Anchor)| 766 Uu N3 N9 N6 768 Figure 3: 5G User Plane Protocol Stack 770 Figure 3 provides high level description of a 5G user plane protocol 771 stack, where: 1) the lower 4 layers (i.e. L1, MAC, RLC, PDCP) at UE 772 is for radio access and air interface to gNB; 2) the IP layer (i.e. 773 PDU layer) at UE is used for providing IP transport infrastructure to 774 support PDU session between UE and UPF (PDU Anchor); 3) GTP-U 775 provides tunneling between gNB and UPF, or between two UPFs. 776 Although UDP/IP exists under GTP-U, IP mainly refers to "IP" between 777 UE and UPF (PDU Anchor) for the rest of this document, unless 778 explicitly clarified; 4) UL-CL is only for uplink traffic and UPF 779 (UL-CL) shall not be needed for downlink traffic towards UE. 781 4.2.3.2. Protocol Stack for ICN Deployment in 5G 782 +--------+ +--------+ 783 | App | | APP | 784 +--------+ +---------+ +--------+ 785 | TCL |.....................................| TCL |.|.| TCL | 786 +--------+ +---------+ | +--------+ 787 | ICN&IP |.....................................| ICN&IP |.|.| ICN&IP | 788 | | | | | | | 789 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 790 | PDCP |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U | | | | | 791 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 792 | RLC |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.| L2 | 793 +--------+ | +-----------+ | +-------------+ | +------+ | | | | 794 | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | 795 +--------+ | +-----------+ | +-------------+ | +---------+ | +--------+ 796 | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | 797 +--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+ 798 UE | gNB/RAN | UPF | UPF | DN 799 | | (UL-CL) | (PDU Anchor)| 800 Uu N3 N9 N6 802 Figure 4: Dual Stack ICN Deployment 804 ICN can be deployed in dual stack model for 5G user plane as 805 illustrated in Figure 4, where: 1) both ICN and IP (i.e. dual stack) 806 can reside between TCL and PDCP to provide transport infrastructure 807 from UE to UPF (PDU Anchor); 2) in order to support the dual ICN&IP 808 transport layer, PDCP needs some enhancements; 3) a new Transport 809 Convergence Layer (TCL) is introduced to coordinate between 810 applications and ICN&IP transport layer; 4) Applications on top of 811 TCL could be ICN applications or IP applications. 813 With this dual stack model, four different cases are possible for the 814 deployment of ICN natively and/or with IP dependent on which types of 815 applications (ICN or IP) uses which types of underline transport (ICN 816 or IP), from the perspective of the applications either on UE (or 817 content provider). 819 Case 1. IP over IP (IPoIP) 821 In this scenario UE uses applications tightly integrated with the 822 existing IP transport infrastructure. In this option, the TCL has no 823 additional function since the packets are directly forwarded using IP 824 protocol stack, which in turn sends the packets over the IP 825 transport. 827 Case 2. ICN over ICN (ICNoICN) 828 Similar to case 1 above, ICN applications tightly integrate with the 829 ICN transport infrastructure. The TCL has no additional 830 responsibility since the packets are directly forwarded using ICN 831 protocol stack, which in turn sends the packets over the ICN 832 transport. 834 Case 3. ICN over IP (ICNoIP) 836 In ICN over IP scenario, the underlying IP transport infrastructure 837 is not impacted (i.e., ICN is implemented as an overlay over IP 838 between UE and content provider). IP routing is used from Radio 839 Access Network (gNB) to mobile backhaul, IP core and UPF. UE 840 attaches to UPF (PDU Anchor) using IP address. Content provider in 841 DN is capable of serving content either using IP or ICN, based on UE 842 request. 844 An alternative approach to implement ICN over IP is provided in 845 Hybrid ICN [I-D.muscariello-intarea-hicn], which implements ICN over 846 IP by mapping of ICN names to the IPv4/IPv6 addresses. 848 Case 4. IP over ICN (IPoICN) 850 In IP over ICN scenario, IP applications utilize an ICN-based routing 851 while preserving the overall IP protocol semantics, as shown, e.g., 852 in H2020 project [H2020]. Implementing IP services over ICN provides 853 an opportunity leveraging benefit of ICN in the transport 854 infrastructure. 856 Note that the IP over ICN case could be supported for pure IP (over 857 IP) UEs through introducing a Network Attachment Point (NAP) to 858 interface to an ICN network. Here, the UPF (PDU Anchor) interfaces 859 to said NAP in the northbound; alternatively, the NAP can be 860 integrated as a part of UPF (PDU Anchor). For this scheme, the NAP 861 provides a standard IP network interface towards the IP-enabled UE 862 via UPF (PDU Anchor), encapsulates any received IP service (e.g. 863 HTTP) request into an appropriate ICN packet which is then published 864 as an appropriately formed named information item. Conversely, the 865 NAP subscribes to any appropriately formed named information items, 866 where the information identifier represents any IP-exposed service 867 that is exposed at any IP-level UE locally connected to the NAP. Any 868 received ICN packet is then forwarded to the appropriate local IP- 869 enabled UE after being appropriately decapsulated, recovering the 870 original IP service (e.g. HTTP) request. 872 In a dual-stack UE that supports the above cases, the TCL helps 873 determine what type of transport (e.g. ICN or IP), as well as type 874 of radio interface (e.g. 5G or WiFi or both), is used to send and 875 receive the traffic based on preference e.g. content location, 876 content type, content publisher, congestion, cost, quality of service 877 etc. It helps to configure and decide the type of connection as well 878 as the overlay mode (ICNoIP or IPoICN, explained above) between 879 application and the protocol stack (IP or ICN) to be used. 881 TCL can use a number of mechanisms for the selection of transport 882 (i.e. ICN or IP). It can use a per application configuration 883 through a management interface, possibly even a user-facing setting 884 realized through a user interface, similar to those used today that 885 select cellular over WiFi being used for selected applications. In 886 another option, it might use a software API, which an adapted IP 887 application could use to specify e.g. an ICN transport for obtaining 888 its benefits. 890 Another potential application of TCL is in implementation of network 891 slicing, where it can have a slice management capability locally or 892 it can interface to an external slice manager through an API 893 [I-D.galis-anima-autonomic-slice-networking]. This solution can 894 enable network slicing for IP and ICN transport selection from the UE 895 itself. The TCL could apply slice settings to direct certain traffic 896 (or applications) over one slice and others over another slice, 897 determined by some form of 'slicing policy'. Slicing policy can be 898 obtained externally from slice manager or configured locally on UE. 900 4.2.3.3. Protocol Interactions and Impacts 901 +----------------+ +-----------------+ 902 | ICN App (New) | |IP App (Existing)| 903 +---------+------+ +-------+---------+ 904 | | 905 +---------+----------------+---------+ 906 | TCL (New) | 907 +------+---------------------+-------+ 908 | | 909 +------+------+ +------+-------+ 910 |ICN Function | | IP Function | 911 | (New) | | (Existing) | 912 +------+------+ +------+-------+ 913 | | 914 +------+---------------------+-------+ 915 | PDCP (Updated to Support ICN) | 916 +-----------------+------------------+ 917 | 918 +-----------------+------------------+ 919 | RLC (Existing) | 920 +-----------------+------------------+ 921 | 922 +-----------------+------------------+ 923 | MAC Layer (Existing) | 924 +-----------------+------------------+ 925 | 926 +-----------------+------------------+ 927 | Physical L1 (Existing) | 928 +------------------------------------+ 930 Figure 5: Dual Stack ICN Protocol Interactions at UE 932 The protocol interactions and impact of supporting tunneling of ICN 933 packet into IP or to support ICN natively are described in Figure 5. 935 o Existing application layer can be modified to provide options for 936 new ICN based application and existing IP based applications. UE 937 can continue to support existing IP based applications or host new 938 applications developed either to support native ICN as transport, 939 ICNoIP or IPoICN based transport. Application layer has the 940 option of selecting either ICN or IP transport layer as well as 941 radio interface to send and receive data traffic. Our proposal is 942 to provide a common Application Programming Interface (API) to the 943 application developers such that there is no impact on the 944 application development when they choose either ICN or IP 945 transport for exchanging the traffic with the network. TCL 946 function handles the interaction of application with the multiple 947 transport options. 949 o The TCL helps determine what type of transport (e.g. ICN or IP) 950 as well as type of radio interface (e.g. 5G NR or WiFi or both), 951 is used to send and receive the traffic. Application layer can 952 make the decision to select a specific transport based on 953 preference e.g. content location, content type, content publisher, 954 congestion, cost, quality of service etc. There can be an 955 Application Programming Interface (API) to exchange parameters 956 required for transport selection. The southbound interactions of 957 TCL will be either to IP or ICN at the network layer. When 958 selecting the IPoICN [TROSSEN] mode, the TCL is responsible for 959 receiving an incoming IP or HTTP packet and publishing the packet 960 under a suitable ICN name (i.e. the hash over the destination IP 961 address for an IP packet or the hash over the FQDN of the HTTP 962 request for an HTTP packet) to the ICN network. In the HTTP case, 963 the TCL maintains a pending request mapping table to map returning 964 responses to the originating HTTP request. The common API will 965 provide a common 'connection' abstraction for this HTTP mode of 966 operation, returning the response over said connection 967 abstraction, akin to the TCP socket interface, while implementing 968 a reliable transport connection semantic over the ICN from the UE 969 to the receiving UE or the PGW. If the HTTP protocol stack 970 remains unchanged, therefore utilizing the TCP protocol for 971 transfer, the TCL operates in local TCP termination mode, 972 retrieving the HTTP packet through said local termination. The 973 southbound interactions of the Transport Convergence Layer (TCL) 974 will be either to IP or ICN at the network layer. 976 o ICN function (forwarder) is introduced in parallel to the existing 977 IP layer. ICN forwarder contains functional capabilities to 978 forward ICN packets, e.g. Interest packet to gNB or response 979 "data packet" from gNB to the application. 981 o For dual stack scenario, when UE is not supporting ICN at network 982 layer, we use IP underlay to transport ICN packets. ICN function 983 will use IP interface to send Interest and Data packets for 984 fetching or sending data using ICN protocol function. This 985 interface will use ICN overlay over IP using any overlay tunneling 986 mechanism. 988 o To support ICN at network layer in UE, PDCP layer has to be aware 989 of ICN capabilities and parameters. PDCP is located in the Radio 990 Protocol Stack in the 5G Air interface, between IP (Network layer) 991 and Radio Link Control Layer (RLC). PDCP performs following 992 functions [TS36.323]: 994 * Data transport by listening to upper layer, formatting and 995 pushing down to Radio Link Layer (RLC). 997 * Header compression and decompression using Robust Header 998 Compression (ROHC). 1000 * Security protections such as ciphering, deciphering and 1001 integrity protection. 1003 * Radio layer messages associated with sequencing, packet drop 1004 detection and re-transmission etc. 1006 o No changes are required for lower layer such as RLC, MAC and 1007 Physical (L1) because they are not IP aware. 1009 5. 5GLAN Architecture with ICN Support 1011 5.1. 5GC Architecture Extensions for 5GLAN Support 1013 In this section, we present an overview of ongoing work to provide 1014 cellular LAN connectivity over a 5GC compliant network for Release 16 1015 and above deployments. 1017 +------+ +------+ +-----+ +-----+ +-----+ +-----+ 1018 | NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 1019 +--o---+ +--o---+ +--o--+ +--o--+ +--o--+ +--o--+ 1020 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 1021 -----+-------+-+---------+--+------+-------+-+---------+--------- 1022 Nausf| Namf| Nsmf| 1023 +--o--+ +--o--+ +--o--+ 1024 | AUSF| | AMF | | SMF | 1025 +-----+ +-+-+-+ +--+--+ 1026 / | | 1027 +---------+ | | 1028 N1 / |N2 N4| +-N9/Nx-+ 1029 +------+ | | | | 1030 / | | | V 1031 +-+--+ +----+----+ N3 +-+--+-------+--+ N6 +----+ 1032 | UE +----------------+ (R)AN +------+ UPF +----->+ DN | 1033 +----+ +---------+ +---------------+ +----+ 1035 Figure 6: 5G Core Network with Vertical_LAN (5GLAN) Extensions 1037 Figure 6 shows the current 5G Core Network Architecture being 1038 discussed within the scope of the normative work addressing 5GLAN 1039 Type services in the 3GPP System Architecture Working Group 2 (3GPP 1040 SA2), referred formally as "5GS Enhanced support of Vertical and LAN 1041 Services" [SA2-5GLAN]. The goal of this work item is to provide 1042 distributed LAN-based connectivity between two or more terminals or 1043 User Equipment entities (UEs) connected to the 5G network. The 1044 Session Management Function (SMF) provides a registration and 1045 discovery protocol that allows UEs wanting to communicate via a 1046 relevant 5GLAN group towards one or more UEs also members of this 1047 5GLAN group, to determine the suitable forwarding information after 1048 each UE previously registered suitable identifier information with 1049 the SMF responsible to manage the paths across UEs in a 5GLAN group. 1050 UEs register and discover (obtain) suitable identifiers during the 1051 establishment of a Protocol Data Unit (PDU) Session or PDU Session 1052 Modification procedure. Suitable identifier information, according 1053 to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses 1054 (the latter is usually assigned during the session setup through the 1055 SMF). 1057 The SMF that manages the path across UEs in a 5GLAN group, then 1058 establishes the suitable procedures to ensure the forwarding between 1059 the required UPFs (user plane functions) to ensure the LAN 1060 connectivity between the UEs (user equipments) provided in the 1061 original request to the SMF. When using the N9 interface to the UPF, 1062 this forwarding will rely on a tunnel-based approach between the UPFs 1063 along the path, while the Nx interface uses path-based forwarding 1064 between UPFs, while LAN-based forwarding is utilized between the 1065 final UPF and the UE (utilizing the N3 interface towards the 1066 destination UE). 1068 5.1.1. Realization of Nx Interface 1070 In the following, we discuss ongoing work to realize the Nx 1071 interface, i.e., path-based forwarding is assumed with the 1072 utilization of a path identifier for the end-to-end LAN 1073 communication. Here, the path between the source and destination 1074 UPFs is encoded through a bitfield, provided in the packet header. 1075 Each bitposition in said bitfield represents a unique link in the 1076 network. Upon receiving an incoming packet, each UPF inspects said 1077 bitfield for the presence of any local link that is being served by 1078 one of its output ports. Such presence check is implemented via a 1079 simple binary AND and CMP operation. If no link is being found, the 1080 packet is dropped. Such bitfield-based path representation also 1081 allows for creating multicast relations in an ad-hoc manner by 1082 combining two or more path identifiers through a binary OR operation. 1083 Note that due to the assignment of a bitposition to a link, path 1084 identifiers are bidirectional and can therefore be used for request/ 1085 response communication without incurring any need for path 1086 computation on the return path. 1088 For sending a packet from one Layer 2 device (UE) connected to one 1089 UPF (via a RAN) to a device connected to another UPF, we provide the 1090 MAC address of the destination and perform a header re-write by 1091 providing the destination MAC address of the ingress UPF when sending 1092 from source device to ingress and placing the end destination MAC 1093 address in the payload. Upon arrival at the egress UPF, after having 1094 applied the path-based forwarding between ingress and egress UPF, the 1095 end destination address is restored while the end source MAC is 1096 placed in the payload with the egress L2 forwarder one being used as 1097 the L2 source MAC for the link-local transfer. At the receiving 1098 device, the end source MAC address is restored as the source MAC, 1099 creating the perception of a link-local L2 communication between the 1100 end source and destination devices. 1102 +---------+---------+----------+-----------+-----------+ 1103 | Src MAC | Dst MAC | pathID | NAME_ID | Payload | 1104 +---------+---------+----------------------+-----------+ 1106 Figure 7: General Packet Structure 1108 For this end-to-end transfer, the general packet structure of 1109 Figure 7 is used. The Name_ID field is being used for the ICN 1110 operations, while the payload contains the information related to the 1111 transaction-based flow management and the PATH_ID is the bitfield- 1112 based path identifier for the path-based forwarding. 1114 5.1.2. Bitfield-based Forwarding in Existing Transport Networks 1116 An emerging technology for Layer 2 forwarding that suits the 5GLAN 1117 architecture in Figure 6 is that of Software-defined networking (SDN) 1118 [SDNDef], which allows for programmatically forwarding packets at 1119 Layer 2. Switch-based rules are being executed with such rules being 1120 populated by the SDN controller. Rules can act upon so-called 1121 matching fields, as defined by the OpenFlow protocol specification 1122 [OpenFlowSwitch]. Those fields include Ethernet MAC addresses, 1123 IPv4/6 source and destination addresses and other well-known Layer 3 1124 and even 4 transport fields. 1126 As shown in [Reed], efficient path-based forwarding can be realized 1127 in SDN networks by placing the aforementioned path identifiers into 1128 the IPv6 source/destination fields of a forwarded packet . Utilizing 1129 the IPv6 source/destination fields allows for natively supporting 256 1130 links in a transport network. Larger topologies can be supported by 1131 extension schemes but are left out of this paper for brevity of the 1132 presentation. During network bootstrapping, each link at each switch 1133 is assigned a unique bitnumber in the bitfield (through the SMF 1134 function of the 5GC). In order to forward based on such bitfield 1135 path information, the NR instructs the SDN controller to insert a 1136 suitable wildcard matching rule into the SDN switch. This wildcard 1137 at a given switch is defined by the bitnumber that has been assigned 1138 to a particular link at that switch during bootstrapping. Wildcard 1139 matching as a generalization of longest prefix matching is natively 1140 supported since the OpenFlow v1.3 specification, efficiently 1141 implemented through TCAM based operations. With that, SDN forwarding 1142 actions only depend on the switch-local number of output ports, while 1143 being able to transport any number of higher-layer flows over the 1144 same transport network without specific flow rules being necessary. 1145 This results in a constant forwarding table size while no controller- 1146 switch interaction is necessary for any flow setup; only changes in 1147 forwarding topology (resulting in a change of port to bitnumber 1148 assignment) will require suitable changes of forwarding rules in 1149 switches. 1151 Although we focus the methods in this draft on Layer 2 forwarding 1152 approaches, path-based transport networks can also be established as 1153 an overlay over otherwise Layer 2 networks. For instance, the BIER 1154 (Bit Indexed Explicit Replication) [RFC8279] efforts within the 1155 Internet Engineer Task Force (IETF) establish such path-based 1156 forwarding transport as an overlay over existing, e.g., MPLS 1157 networks. The path-based forwarding identification is similar to the 1158 aforementioned SDN realization although the bitfield represents 1159 ingress/egress information rather than links along the path. 1161 Yet another transport network example is presented in [Khalili], 1162 utilizing flow aggregation over SDN networks. The flow aggregation 1163 again results in a path representation that is independent from the 1164 specific flows traversing the network. 1166 5.2. ICN over 5GLAN 1168 ICN aims at replacing the routing functionality of the Internet 1169 Protocol (IP). It is therefore natively supported over a Layer 2 1170 transport network, such as Ethernet-based networks. Deployments 1171 exists over WiFi and local LAN networks, while usually overlaying 1172 (over IP) is being used for connectivity beyond localized edge 1173 networks. 1175 With the emergence of the 5GLAN capability in (future) Release 16 1176 based 5G networks, such cellular LAN connectivity to provide pure ICN 1177 could be utilized for pure ICN-based deployments, i.e. without the 1178 dual stack capability outlined in Section 4.2.3.2. With this, the 1179 entire 5G network would be interpreted as a local LAN, providing the 1180 necessary Layer 2 connectivity between the ICN network components. 1181 With the support of roaming in 5GLAN, such '5G network' can span 1182 several operators and therefore large geographies. 1184 Such deployment, however, comes without any core network integration, 1185 similar to the one outlined in Section 4.1, and therefore does not 1186 utilize ICN capabilities within the overall 5G core and access 1187 network. Benefits such as those outlined in the introduction, e.g., 1188 caching, would only exist at the endpoint level (from a 5GLAN 1189 perspective). 1191 However, ICN components could be provided as SW components in a 1192 network slice at the endpoints of such 5GLAN connectivity, utilizing 1193 in-network compute facilities, e.g., for caching, CCN routing 1194 capabilities and others. Such endpoint-driven realization of a 1195 specific ICN deployment scenario is described in more detail in [I- 1196 D.trossen-icnrg-IP-over-icn], focusing on the provisioning of IP- 1197 based services over an ICN, which in turn is provided over a LAN (and 1198 therefore also 5GLAN) based transport network. 1200 6. Deployment Considerations 1202 The work in [I-D.irtf-icnrg-deployment-guidelines] outlines a 1203 comprehensive set of considerations related to the deployment of ICN. 1204 We now relate the solutions proposed in this draft to the two main 1205 aspects covered in the deployment considerations draft, namely the 1206 'deployment configuration' (covered in Section 4 of 1207 [I-D.irtf-icnrg-deployment-guidelines]) that is being realized and 1208 the 'deployment migration paths' (covered in Section 5 of 1209 [I-D.irtf-icnrg-deployment-guidelines]) that are being provided. 1211 The solutions proposed in this draft relate to those 'deployment 1212 configuration' as follows: 1214 o The integration with the 5GC, as proposed in Section 4.2, follows 1215 the 'Clean-slate ICN' deployment configuration, i.e., integrating 1216 the ICN capabilities natively into the 5GC through appropriate 1217 extensions at the control and user plane level. 1219 o The utilization of the 5GLAN capabilities, as proposed in 1220 Section 5.2, follows the 'ICN-as-an-Overlay', interpreting the 1221 5GLAN as an overlay capability with no 5GC integration being 1222 considered (as in the 'Clean-slate ICN' configuration). 1224 o The deployment of 5GLAN based ICN capabilities can be realized 1225 following the 'ICN-as-a-Slice' deployment configuration, i.e., the 1226 5GLAN connectivity is provided to a 'vertical 5G customer' which 1227 in turn provides the ICN capability over 5GLAN within said network 1228 (and compute) slice at the endpoints of the 5GLAN connectivity, as 1229 proposed in Section 5.2. 1231 In relation of the 'deployment migration paths', the solutions in 1232 this draft relate as follows: 1234 o The integration with the 5GC, as proposed in Section 4.2, 1235 facilitates 'edge network migration' (interpreting the cellular 1236 sub-system here as an edge network albeit a possibly 1237 geographically large one). 1239 o The dual-stack deployment, as proposed in Section 4.2.3, 1240 facilitates 'application and services migration' through not only 1241 supporting ICN applications but also IP-based applications through 1242 the proposed IP-over-ICN mapping in the terminal. 1244 o The ICN over 5GLAN deployment, possibly combined with an ICN-as- 1245 a-Slice deployment, facilitates the 'content delivery networks 1246 migration' through a deployment of ICN-based 5GLAN connected CDN 1247 elements in (virtualized) edge network nodes or POP locations in 1248 the customer (5G) network. 1250 7. Conclusion 1252 In this draft, we explore the feasibility of realizing future 1253 networking architectures like ICN within the proposed 3GPP's 5GC 1254 architecture. Towards this, we summarized the design principles that 1255 offer 5GC the flexibility to enable new network architectures. We 1256 then discuss 5GC architecture aspects along with the user/control 1257 plane extensions required to handle ICN PDU sessions formally to 1258 realize ICN with 5GC integration as well as ICN over a pure 5GLAN 1259 connectivity. 1261 8. IANA Considerations 1263 This document requests no IANA actions. 1265 9. Security Considerations 1267 This draft proposes extensions to support ICN in 5G's next generation 1268 core architecture. ICN being name based networking opens up new 1269 security and privacy considerations which have to be studied in the 1270 context of 5GC. This is in addition to other security considerations 1271 of 5GC for IP or non-IP based services considered in [TS33.899]. 1273 10. Acknowledgments 1275 ... 1277 11. Informative References 1279 [ABEDRM] Papanis, J., Papapanagiotou, S., Mousas, A., Lioudakis, 1280 G., Kaklamani, D., and I. Venieris, "On the use of 1281 Attribute-Based Encryption for multimedia content 1282 protection over Information-Centric Networks", 1283 ETT, Transaction on, Transaction on Emerging 1284 Telecommunication Technologies, 2014. 1286 [H2020] H2020, "The POINT Project", https://www.point-h2020.eu/ . 1288 [I-D.galis-anima-autonomic-slice-networking] 1289 Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic 1290 Slice Networking", draft-galis-anima-autonomic-slice- 1291 networking-05 (work in progress), September 2018. 1293 [I-D.irtf-icnrg-deployment-guidelines] 1294 Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1295 "Deployment Considerations for Information-Centric 1296 Networking (ICN)", draft-irtf-icnrg-deployment- 1297 guidelines-07 (work in progress), September 2019. 1299 [I-D.irtf-icnrg-icn-lte-4g] 1300 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1301 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1302 Networks", draft-irtf-icnrg-icn-lte-4g-05 (work in 1303 progress), November 2019. 1305 [I-D.muscariello-intarea-hicn] 1306 Muscariello, L., Carofiglio, G., Auge, J., and M. 1307 Papalini, "Hybrid Information-Centric Networking", draft- 1308 muscariello-intarea-hicn-03 (work in progress), October 1309 2019. 1311 [I-D.white-icnrg-ipoc] 1312 White, G., Shannigrahi, S., and C. Fan, "Internet Protocol 1313 Tunneling over Content Centric Mobile Networks", draft- 1314 white-icnrg-ipoc-02 (work in progress), June 2019. 1316 [ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 1317 "Seamless Producer Mobility as a Service in Information 1318 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 1319 2016. 1321 [Jacobson] 1322 Jacobson, V. and et al., "Networking Named Content", 1323 Proceedings of ACM Context, , 2009. 1325 [Khalili] Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, 1326 "Reducing State of SDN Switches in Mobile Core Networks by 1327 Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, 1328 August 2016. 1330 [lteversus5g] 1331 Kim, J., Kim, D., and S. Choi, "3GPP SA2 architecture and 1332 functions for 5G mobile communication system.", ICT 1333 Express 2017, 2017. 1335 [MEC5G] ISBN-No-979-10-92620-22-1, "MEC in 5G", ETSI , June 2018. 1337 [NFN] Sifalakis, M., Kohler, B., Christopher, C., and C. 1338 Tschudin, "An information centric network for computing 1339 the distribution of computations", ACM, ICN Sigcomm, 2014. 1341 [OpenFlowSwitch] 1342 Open Networking Foundation, available at 1343 https://www.opennetworking.org/wp-content/uploads/2014/10/ 1344 openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification 1345 V1.5.1", 2018. 1347 [Ravindran] 1348 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1349 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1350 Network Slicing", IEEE Communication Magazine, May, 2016. 1352 [Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., 1353 Petropoulos, G., and S. Spirou, "Stateless Multicast 1354 Switching in Software Defined Networks", IEEE ICC 2016, 1355 Kuala Lumpur, Maylaysia, 2016. 1357 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1358 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1359 Explicit Replication (BIER)", RFC 8279, 1360 DOI 10.17487/RFC8279, November 2017, 1361 . 1363 [SA2-5GLAN] 1364 3gpp-5glan, "SP-181129, Work Item Description, 1365 Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and 1366 LAN Services", 3GPP , 1367 http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- 1368 181120.zip. 1370 [SDNDef] Open Networking Foundation, available at 1371 https://www.opennetworking.org/sdn-definition/, "Software- 1372 Defined Networking (SDN) Definition", 2018. 1374 [TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M., and 1375 G. Xylomenos, "IP Over ICN - The Better IP ?", EuCNC, 1376 European Conference on Networks and Communications , July, 1377 2015. 1379 [TS23.501] 1380 3gpp-23.501, "Technical Specification Group Services and 1381 System Aspects; System Architecture for the 5G System; 1382 Stage 2 (Rel.15)", 3GPP , December 2018. 1384 [TS23.502] 1385 3gpp-23.502, "Technical Specification Group Services and 1386 System Aspects; Procedures for the 5G System; Stage 2 1387 (Rel. 15)", 3GPP , January 2019. 1389 [TS23.799] 1390 3gpp-23.799, "Technical Specification Group Services and 1391 System Aspects; Study on Architecture for Next Generation 1392 System (Rel. 14)", 3GPP , 2017. 1394 [TS33.899] 1395 3gpp-33.899, "Study on the security aspects of the next 1396 generation system", 3GPP , 2017. 1398 [TS36.323] 1399 3gpp-36.323, "Technical Specification Group Radio Access 1400 Network; Evolved Universal Terrestrial Radio Access 1401 (E-UTRA); Packet Data Convergence Protocol (PDCP) 1402 specification (Rel. 15)", 3GPP , January 2019. 1404 [TS38.300] 1405 3gpp-38-300, "Technical Specification Group Radio Access 1406 Network; NR; NR and NG-RAN Overall Description; Stage 2 1407 (Rel.15)", 3GPP , January 2019. 1409 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1410 Wang, "Towards software defined ICN based edge-cloud 1411 services", CloudNetworking(CloudNet), IEEE Internation 1412 Conference on, IEEE Internation Conference on 1413 CloudNetworking(CloudNet), 2013. 1415 Authors' Addresses 1416 Ravi Ravindran 1417 Sterlite Technologies 1418 5201 Greatamerica Pkwy 1419 Santa Clara 95054 1420 USA 1422 Email: ravishankar.ravindran@sterlite.com 1424 Prakash Suthar 1425 Cisco Systems 1426 9501 Technology Blvd. 1427 Rosemont 50618 1428 USA 1430 Email: psuthar@cisco.com 1431 URI: http://www.cisco.com/ 1433 Dirk Trossen 1434 Huawei Technologies Duesseldorf GmbH 1435 205 Hansallee 1436 Duesseldorf 40549 1437 Germany 1439 Email: dirk.trossen@huawei.com 1440 URI: http://huawei-dialog.de/ 1442 Chonggang Wang 1443 InterDigital Inc. 1444 1001 E Hector St, Suite 300 1445 Conshohocken PA 19428 1446 United States 1448 Email: Chonggang.Wang@InterDigital.com 1449 URI: http://www.InterDigital.com/ 1451 Greg White 1452 CableLabs 1453 858 Coal Creek Circle 1454 Louisville CO 80027 1455 USA 1457 Email: g.white@cablelabs.com