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