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