ICNRG R. Ravindran
Internet-Draft Futurewei
Intended status: Informational P. Suthar
Expires: December 2, 2019 Cisco
D. Trossen
C. Wang
InterDigital Inc.
G. White
CableLabs
May 31, 2019

Enabling ICN in 3GPP's 5G NextGen Core Architecture
draft-ravi-icnrg-5gc-icn-04

Abstract

The proposed 3GPP's 5G core nextgen architecture (5GC) offers flexibility to introduce new user and control plane function, considering the support for network slicing functions, that allows greater flexibility to handle heterogeneous devices and applications. In this draft, we provide a short description of the proposed 5GC architecture, including recent efforts to provide cellular Local Area Network (LAN) connectivity, followed by extensions to 5GC's control and user plane to support Packet Data Unit (PDU) sessions from Information-Centric Networks (ICN). In addition, ICN over 5GLAN is also described.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 2, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

The objective of this draft is to propose an architecture to enable information-centric networking (ICN) in the proposed 5G Next-generation Core network architecture (5GC) by leveraging its flexibility to allow new user and associated control plane functions. The reference architectural discussions in the 5G core network 3GPP specifications [TS23.501][TS23.502] form the basis of our discussions. This draft also complements the discussions related to various ICN deployment opportunities explored in [I-D.irtf-icnrg-deployment-guidelines], where 5G technology is considered as one of the promising alternatives.

Though ICN is a general networking technology, it would benefit 5G particularly from the perspective of mobile edge computing (MEC). The following ICN features shall benefit MEC deployments in 5G:

In this document, we first discuss 5GC's design principals that allows the support of new network architectures. Then we summarize the 5GC proposal, followed by control and user plane extensions required to support ICN PDU sessions. This is followed by discussions on enabling IP over ICN over 3GPP proposed 5GLAN service framework. We then discuss deployment considerations for both ICN over 5GC and IP over ICN over 5GLAN.

2. Terminology

Following are terminologies relevant to this draft:

3. 5G NextGen Core Design Principles

The 5GC architecture is based on the following design principles that allows it to support new service networks like ICN efficiently compared to LTE networks:

4. 5GC Architecture with ICN Support

4.1. 5G NextGen Core Architecture

In this section, for brevity purposes, we restrict the discussions to the control and user plane functions relevant to an ICN deployment discussion in Section 4.2. More exhaustive discussions on the various architecture functions, such as registration, connection and subscription management, can be found in[TS23.501][TS23.502].

  
                               +------+
 +-----+ +-------+  +------+   | AF-2 |
 |NSSF | |PCF/UDM|  | AF-1 |   +---+--+
 +--+--+ +--+----+  +--+---+       |
    |       |          |       +---+---+
 +--+-------+--+   +---+-----+ |       |
 |             |N11|         | | SMF-2 |
 |    AMF      +---+  SMF-1  | |       |
 |             |   |         | +---+---+
 +----+----+---+   +----+----+     |
      |    |            |------------------------+
  +---+    |            |          |N4           |N4
N1|        |N2          |N4        |  +----------+---------+
  |        |            |        +----+         UPF        | N6 +----+
+-+-+   +--+--+     +---+---+    | |  |(PDU Session Anchor)+----+ DN |
|   |   |     |     |       | N9 | |  |                    |    |    |
|UE |   | RAN | N3  |  UPF  +----+ |  +--------------------+    +----+
|   +---+     +-----+(UL-CL)|      |
|   |   |     |     |       +----+ +-------------+
+---+   +-----+     +-------+ N9 |               |
                                 |    +----------+---------+
                                 +----+         UPF        |    +----+
                                      |(PDU Session Anchor)| N6 | DN |
                                      |                    +----+    |
                                      +--------------------+    +----+                           
                     
  

Figure 1: 5G Next Generation Core Architecture

In Figure 1, we show one variant of a 5GC architecture from [TS23.501], for which the functions of UPF's branching point and PDU session anchoring are used to support inter-connection between a UE and the related service or packet data networks (or PDNs) managed by the signaling interactions with control plane functions. In 5GC, control plane functions can be categorized as follows:

AMF serves multiple purposes: (i) device authentication and authorization; (ii) security and integrity protection to non-access stratum (NAS) signaling; (iii) tracking UE registration in the operator's network and mobility management functions as the UE moves among different RANs, each of which might be using different radio access technologies (RAT).

NSSF handles the selection of a particular slice for the PDU session request from the user entity (UE) using the Network Slice Selection Assistance Information (NSSAI) parameters provided by the UE and the configured user subscription policies in PCF and UDM functions. Compared to LTE's evolved packet core (EPC), where PDU session states in RAN and core are synchronized with respect to management, 5GC decouples this using NSSF by allowing PDU sessions to be defined prior to a PDU session request by a UE (for other differences see [lteversus5g] ). This decoupling allows policy based inter-connection of RAN flows with slices provisioned in the core network. This functionality is useful particularly towards new use cases related to M2M and IOT devices requiring pre-provisioned network resources to ensure appropriate SLAs.

SMF is used to handle IP anchor point selection and addressing functionality, management of the user plane state in the UPFs (such as in uplink classifier (UL-CL), IP anchor point and branching point functions) during PDU session establishment, modification and termination, and interaction with RAN to allow PDU session forwarding in uplink/downlink (UL/DL) to the respective DNs. SMF decisions are also influenced by AF to serve application requirements, for e.g., actions related to introducing edge computing functions.

In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN protocol[TS38.300]. From the RAN, the PDU's five tuple header information (IP source/destination, port, protocol etc.) is used to map the flow to an appropriate tunnel from RAN to UPF. Though the current 5GC proposal[TS23.501] follows LTE on using GPRS tunneling protocol (GTP) tunnel from NR to the UPF to carry data PDUs and another one for the control messages to serve the control plane functions; there are ongoing discussions to arrive upon efficient alternatives to GTP.

4.2. ICN over 5GC

In this section, we focus on control and user plane enhancements required to enable ICN within 5GC, and identify the interfaces that require extensions to support ICN PDU sessions. Explicit support for ICN PDU sessions within access and 5GC networks will enable applications to leverage the core ICN features while offering it as a service to 5G users.

                                                                                                                                                                                                            
                           +------------+
                           |     5G     |
                           | Services   |
                           |   (NEF)    |       +----------------+
                           +-------+----+       |      ICN       |
                                   |   +--------+    Service     |
                                   |   |        |  Orchestrator  |
                                   |   |        +-------+--------+
+----+ +-------+  Npcf++/Nudm++  +-+---+-+              |
|NSSF| |PCF/UDM+-----------------+ ICN-AF|              |
+-+--+ +-+-----+                 +---+---+       +------+--------+
  |      |                           |           |      ICN      |
  |      |                           |       +---+Service/Network|
+-+------+-+      +-------+      +---+---+   |   |   Controller  |
|          |N11++ |       |Naf++ |       +---+   +-----------+---+
| AMF++    +------+ SMF++ +------+ICN-SMF|                   |
|          |      |       |      |       |                   |
+----+--+--+      +---+---+      +---+---+                   |
     |  |             |              |NIcn                   |
     |  +-------+     +-------+      +----------+            |
     |          |             |                 |            |
     |          |             |             +---+--+      +--+---+
     |N1++      |N2           |N4           |      |      |      |
     |          |             |        +----+ICN-GW+------+ICN-DN|
     |          |        +----+----+   | N9 | +UPF |  N6  |      |
+----+-+  +-----+----+   |         |   |    +------+      +------+
|      |  |RAN +----+|   | UL-CL/  +---+
|ICN-UE+--+    |UPF ||   |Branching|
|      |  |    +----++---+ Point   |
|      |  |  +------+| N3|         +---+    +------+
+------+  |  |ICN-GW||   +---------+   | N9 | Local|
          |  +------+|                 +----+ICN-DN|
          +----------+                      +------+
                     
  

Figure 2: 5G Next Generation Core Architecture with ICN support

For an ICN-enabled 5GC network, the assumption is that the UE may have applications that can run over ICN or IP, for instance, UE's operating system offering applications to operate over ICN [Jacobson] or IP-based networking sockets. There may also be cases where UE is exclusively based on ICN. In either case, we identify an ICN enabled UE as ICN-UE. Different options exist to implement ICN in UE as described in [I-D.irtf-icnrg-icn-lte-4g] which is also applicable for 5G UE to enable formal ICN session handling, such as, using a Transport Convergence Layer (TCL) above 5G-NR, through IP address assignment from 5GC or using 5GC provision of using unstructured PDU session mode during the PDU session establishment process, which is discussed in Section 4.2.2.2. Such convergence layer would implement necessary IP over ICN mappings, such as those described in [TROSSEN], for IP-based applications that are assigned to be transported over an ICN network. 5G UE can also be non-mobile devices or an IOT device using radio specification which can operate based on [TS38.300].

5GC will take advantage of network slicing function to instantiate heterogeneous slices, the same framework can be extended to create ICN slices as well [Ravindran]. This discussion also borrows ideas from[TS23.799], which offers a wide range of architectural discussions and proposals on enabling slices and managing multiple PDU sessions with local networks (with MEC) and its associated architectural support (in the service, control and data planes) and procedures within the context of 5GC.

Figure 2 shows the proposed ICN-enabled 5GC architecture. In the figure, the new and modified functional components are identified that interconnects an ICN-DN with 5GC. The interfaces and functions that require extensions to enable ICN as a service in 5GC can be identified in the figure with a '++' symbol. We next summarize the control, user plane and normative interface extensions that help with the formal ICN support.

4.2.1. Control Plane Extensions

To support interconnection between ICN UEs and the appropriate ICN DN instances, we consider the following additional control plane extensions to orchestrate ICN services in coordination with 5GC's control components.

4.2.1.1. Normative Interface Extensions

4.2.2. User Plane Extensions

The interconnection of a UE to an ICN-DN comprises of two segments, one from RAN to UL-CL and the other from UL-CL to ICN-GW. These segments use IP tunneling constructs, where the service semantic check at UL-CL is performed using IP's five tuples to determine both UL and DL tunnel mappings. We summarize the relevant UPFs and the interfaces for handling ICN PDU sessions as follows.

4.2.2.1. Normative Interface Extensions

4.2.2.2. ICN over non-IP PDU

5GC accommodates non-IP PDU support which is defined for Ethernet or any unstructured data[TS23.501]. This feature allows native support of ICN over 5G RAN, with the potential enablement of ICN-GW in the BS itself as shown in Figure 2. Formalizing this feature to recognize ICN PDUs has many considerations:

4.2.3. Dual Stack ICN Deployment

4.2.3.1. 5G User Plane Protocol Stack

It is important to understand that a User Equipment (UE) can be either consumer (receiving content) or publisher (pushing content for other clients). The protocol stack inside mobile device (UE) is complex as it has to support multiple radio connectivity access to gNB(s).

                                                                                                                                                                                                            
+--------+                                                   +--------+
|  App   |                                                   |  APP   |
+--------+                                     +---------+   +--------+
|   IP   |.....................................|    IP   |.|.|   IP   |
+--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+
|  PDCP  |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U |  | | |        |
+--------+ | +-----------+ | +-------------+ | +------+  | | |        |
|  RLC   |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.|   L2   |
+--------+ | +-----------+ | +-------------+ | +------+  | | |        |
|  MAC   |.|.| MAC|  L2  |.|.| L2   |  L2  |.|.|  L2  |  | | |        |
+--------+ | +-----------+ | +-------------+ | +---------+ | +--------+
|  L1    |.|.| L1 |  L1  |.|.| L1   |  L1  |.|.|  L1  |L1|.|.|   L1   |
+--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+
    UE     |    gNB/RAN    |       UPF       |     UPF     |     DN
           |               |     (UL-CL)     | (PDU Anchor)|
          Uu               N3                N9            N6 
                    
  

Figure 3: 5G User Plane Protocol Stack

Figure 3 provides high level description of a 5G user plane protocol stack, where: 1) the lower 4 layers (i.e. L1, MAC, RLC, PDCP) at UE is for radio access and air interface to gNB; 2) the IP layer (i.e. PDU layer) at UE is used for providing IP transport infrastructure to support PDU session between UE and UPF (PDU Anchor); 3) GTP-U provides tunneling between gNB and UPF, or between two UPFs. Although UDP/IP exists under GTP-U, IP mainly refers to “IP” between UE and UPF (PDU Anchor) for the rest of this document, unless explicitly clarified; 4) UL-CL is only for uplink traffic and UPF (UL-CL) shall not be needed for downlink traffic towards UE.

4.2.3.2. Protocol Stack for ICN Deployment in 5G

                                                                                                                                                                                                            
+--------+                                                   +--------+
|  App   |                                                   |  APP   |
+--------+                                     +---------+   +--------+
|  TCL   |.....................................|  TCL    |.|.|  TCL   |
+--------+                                     +---------+ | +--------+
| ICN&IP |.....................................| ICN&IP  |.|.| ICN&IP |
|        |                                     |         | | |        |
+--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+
|  PDCP  |.|.|PDCP|GTP-U |.|.|GTP-U | GTP-U|.|.|GTP-U |  | | |        |
+--------+ | +-----------+ | +-------------+ | +------+  | | |        |
|  RLC   |.|.|RLC |UDP/IP|.|.|UDP/IP|UDP/IP|.|.|UDP/IP|L2|.|.|   L2   |
+--------+ | +-----------+ | +-------------+ | +------+  | | |        |
|  MAC   |.|.| MAC|  L2  |.|.| L2   |  L2  |.|.|  L2  |  | | |        |
+--------+ | +-----------+ | +-------------+ | +---------+ | +--------+
|  L1    |.|.| L1 |  L1  |.|.| L1   |  L1  |.|.|  L1  |L1|.|.|   L1   |
+--------+ | +----+------+ | +------+------+ | +------+--+ | +--------+
    UE     |    gNB/RAN    |       UPF       |     UPF     |     DN
           |               |     (UL-CL)     | (PDU Anchor)|
          Uu               N3                N9            N6 
                    
  

Figure 4: Dual Stack ICN Deployment

ICN can be deployed in dual stack model for 5G user plane as illustrated in Figure 4, where: 1) both ICN and IP (i.e. dual stack) can reside between TCL and PDCP to provide transport infrastructure from UE to UPF (PDU Anchor); 2) in order to support the dual ICN&IP transport layer, PDCP needs some enhancements; 3) a new Transport Convergence Layer (TCL) is introduced to coordinate between applications and ICN&IP transport layer; 4) Applications on top of TCL could be ICN applications or IP applications.

With this dual stack model, four different cases are possible for the deployment of ICN natively and/or with IP dependent on which types of applications (ICN or IP) uses which types of underline transport (ICN or IP), from the perspective of the applications either on UE (or content provider).

Case 1. IP over IP (IPoIP)

In this scenario UE uses applications tightly integrated with the existing IP transport infrastructure. In this option, the TCL has no additional function since the packets are directly forwarded using IP protocol stack, which in turn sends the packets over the IP transport.

Case 2. ICN over ICN (ICNoICN)

Similar to case 1 above, ICN applications tightly integrate with the ICN transport infrastructure. The TCL has no additional responsibility since the packets are directly forwarded using ICN protocol stack, which in turn sends the packets over the ICN transport.

Case 3. ICN over IP (ICNoIP)

In ICN over IP scenario, the underlying IP transport infrastructure is not impacted (i.e., ICN is implemented as an overlay over IP between UE and content provider). IP routing is used from Radio Access Network (gNB) to mobile backhaul, IP core and UPF. UE attaches to UPF (PDU Anchor) using IP address. Content provider in DN is capable of serving content either using IP or ICN, based on UE request.

An alternative approach to implement ICN over IP is provided in Hybrid ICN [I-D.muscariello-intarea-hicn], which implements ICN over IP by mapping of ICN names to the IPv4/IPv6 addresses.

Case 4. IP over ICN (IPoICN)

In IP over ICN scenario, IP application utilize an ICN-based routing while preserving the overall IP protocol semantics, as shown, e.g., in H2020 project [H2020]. Implementing IP services over ICN provides an opportunity leveraging benefit of ICN in the transport infrastructure.

Note that the IP over ICN case could be supported for pure IP (over IP) UEs through introducing a Network Attachment Point (NAP) to interface to an ICN network. Here, the UPF (PDU Anchor) interfaces to said NAP in the northbound; alternatively, the NAP can be integrated as a part of UPF (PDU Anchor). For this scheme, the NAP provides a standard IP network interface towards the IP-enabled UE via UPF (PDU Anchor), encapsulates any received IP service (e.g. HTTP) request into an appropriate ICN packet which is then published as an appropriately formed named information item. Conversely, the NAP subscribes to any appropriately formed named information items, where the information identifier represents any IP-exposed service that is exposed at any IP-level UE locally connected to the NAP. Any received ICN packet is then forwarded to the appropriate local IP-enabled UE after being appropriately decapsulated, recovering the original IP service (e.g. HTTP) request.

In a dual-stack UE that supports the above cases, the TCL helps determine what type of transport (e.g. ICN or IP), as well as type of radio interface (e.g. 5G or WiFi or both), is used to send and receive the traffic based on preference e.g. content location, content type, content publisher, congestion, cost, quality of service etc. It helps to configure and decide the type of connection as well as the overlay mode (ICNoIP or IPoICN, explained above) between application and the protocol stack (IP or ICN) to be used.

TCL can use a number of mechanisms for the selection of transport (i.e. ICN or IP). It can use a per application configuration through a management interface, possibly even a user-facing setting realized through a user interface, similar to those used today that select cellular over WiFi being used for selected applications. In another option, it might use a software API, which an adapted IP application could use to specify e.g. an ICN transport for obtaining its benefits.

Another potential application of TCL is in implementation of network slicing, where it can have a slice management capability locally or it can interface to an external slice manager through an API [I-D.galis-anima-autonomic-slice-networking]. This solution can enable network slicing for IP and ICN transport selection from the UE itself. The TCL could apply slice settings to direct certain traffic (or applications) over one slice and others over another slice, determined by some form of 'slicing policy'. Slicing policy can be obtained externally from slice manager or configured locally on UE.

4.2.3.3. Protocol Interactions and Impacts

                                                                                                                                                                                                            
+----------------+ +-----------------+
| ICN App (New)  | |IP App (Existing)|
+---------+------+ +-------+---------+
          |                |
+---------+----------------+---------+
|             TCL (New)              |
+------+---------------------+-------+
       |                     |
+------+------+       +------+-------+
|ICN Function |       | IP Function  |
|   (New)     |       | (Existing)   |
+------+------+       +------+-------+
       |                     |
+------+---------------------+-------+
| PDCP (Updated to Support ICN)      |
+-----------------+------------------+
                  |
+-----------------+------------------+
|          RLC (Existing)            |
+-----------------+------------------+
                  |
+-----------------+------------------+
|        MAC Layer (Existing)        |
+-----------------+------------------+
                  |
+-----------------+------------------+
|       Physical L1 (Existing)       |
+------------------------------------+
                   
  

Figure 5: Dual Stack ICN Protocol Interactions at UE

The protocol interactions and impact of supporting tunneling of ICN packet into IP or to support ICN natively are described in Figure 5.

5. 5GLAN Architecture with ICN Support

5.1. 5GC Architecture Extensions for 5GLAN Support

In this section, we present an overview of ongoing work to provide cellular LAN connectivity over a 5GC compliant network for Release 16 and above deployments.

                                                                                                                                                                                                           
  +------+  +------+  +-----+   +-----+   +-----+   +-----+   
  | NSSF |  | NEF  |  | NRF |   | PCF |   | UDM |   | AF  |   
  +--o---+  +--o---+  +--o--+   +--o--+   +--o--+   +--o--+    
Nnssf|     Nnef|     Nnrf|     Npcf|     Nudm|      Naf|         
-----+-------+-+---------+--+------+-------+-+---------+---------
        Nausf|          Namf|          Nsmf|                
          +--o--+        +--o--+        +--o--+         
          | AUSF|        | AMF |        | SMF |          
          +-----+        +-+-+-+        +--+--+          
                          /  |             |
               +---------+   |             |    
          N1  /              |N2         N4|  +-N9/Nx-+
      +------+               |             |  |       |
     /                       |             |  |       V
  +-+--+                +----+----+  N3  +-+--+-------+--+  N6  +----+   
  | UE +----------------+  (R)AN  +------+      UPF      +----->+ DN |
  +----+                +---------+      +---------------+      +----+
                   
  

Figure 6: 5G Core Network with Vertical_LAN (5GLAN) Extensions

Figure 6 shows the current 5G Core Network Architecture being discussed within the scope of the normative work addressing 5GLAN Type services in the 3GPP System Architecture Working Group 2 (3GPP SA2), referred formally as "5GS Enhanced support of Vertical and LAN Services" [SA2-5GLAN]. The goal of this work item is to provide distributed LAN-based connectivity between two or more terminals or User Equipment entities (UEs) connected to the 5G network. The Session Management Function (SMF) provides a registration and discovery protocol that allows UEs wanting to communicate via a relevant 5GLAN group towards one or more UEs also members of this 5GLAN group, to determine the suitable forwarding information after each UE previously registered suitable identifier information with the SMF responsible to manage the paths across UEs in a 5GLAN group. UEs register and discover (obtain) suitable identifiers during the establishment of a Protocol Data Unit (PDU) Session or PDU Session Modification procedure. Suitable identifier information, according to [SA2-5GLAN], are Ethernet MAC addresses as well as IP addresses (the latter is usually assigned during the session setup through the SMF).

The SMF that manages the path across UEs in a 5GLAN group, then establishes the suitable procedures to ensure the forwarding between the required UPFs (user plane functions) to ensure the LAN connectivity between the UEs (user equipments) provided in the original request to the SMF. When using the N9 interface to the UPF, this forwarding will rely on a tunnel-based approach between the UPFs along the path, while the Nx interface uses path-based forwarding between UPFs, while LAN-based forwarding is utilized between the final UPF and the UE (utilizing the N3 interface towards the destination UE).

5.1.1. Realization of Nx Interface

In the following, we discuss ongoing work to realize the Nx interface, i.e., path-based forwarding is assumed with the utilization of a path identifier for the end-to-end LAN communication. Here, the path between the source and destination UPFs is encoded through a bitfield, provided in the packet header. Each bitposition in said bitfield represents a unique link in the network. Upon receiving an incoming packet, each UPF inspects said bitfield for the presence of any local link that is being served by one of its output ports. Such presence check is implemented via a simple binary AND and CMP operation. If no link is being found, the packet is dropped. Such bitfield-based path representation also allows for creating multicast relations in an ad-hoc manner by combining two or more path identifiers through a binary OR operation. Note that due to the assignment of a bitposition to a link, path identifiers are bidirectional and can therefore be used for request/response communication without incurring any need for path computation on the return path.

For sending a packet from one Layer 2 device (UE) connected to one UPF (via a RAN) to a device connected to another UPF, we provide the MAC address of the destination and perform a header re-write by providing the destination MAC address of the ingress UPF when sending from source device to ingress and placing the end destination MAC address in the payload. Upon arrival at the egress UPF, after having applied the path-based forwarding between ingress and egress UPF, the end destination address is restored while the end source MAC is placed in the payload with the egress L2 forwarder one being used as the L2 source MAC for the link-local transfer. At the receiving device, the end source MAC address is restored as the source MAC, creating the perception of a link-local L2 communication between the end source and destination devices.

                                                                                                                                                                                                            
+---------+---------+----------+-----------+-----------+
| Src MAC | Dst MAC |  pathID  |  NAME_ID  |  Payload  |
+---------+---------+----------------------+-----------+
                   
  

Figure 7: General Packet Structure

For this end-to-end transfer, the general packet structure of Figure 7 is used. The Name_ID field is being used for the ICN operations, while the payload contains the information related to the transaction-based flow management and the PATH_ID is the bitfield-based path identifier for the path-based forwarding.

5.1.2. Bitfield-based Forwarding in Existing Transport Networks

An emerging technology for Layer 2 forwarding that suits the 5GLAN architecture in Figure 6 is that of Software-defined networking (SDN) [SDNDef], which allows for programmatically forwarding packets at Layer 2. Switch-based rules are being executed with such rules being populated by the SDN controller. Rules can act upon so-called matching fields, as defined by the OpenFlow protocol specification [OpenFlowSwitch]. Those fields include Ethernet MAC addresses, IPv4/6 source and destination addresses and other well-known Layer 3 and even 4 transport fields.

As shown in [Reed], efficient path-based forwarding can be realized in SDN networks by placing the aforementioned path identifiers into the IPv6 source/destination fields of a forwarded packet . Utilizing the IPv6 source/destination fields allows for natively supporting 256 links in a transport network. Larger topologies can be supported by extension schemes but are left out of this paper for brevity of the presentation. During network bootstrapping, each link at each switch is assigned a unique bitnumber in the bitfield (through the SMF function of the 5GC). In order to forward based on such bitfield path information, the NR instructs the SDN controller to insert a suitable wildcard matching rule into the SDN switch. This wildcard at a given switch is defined by the bitnumber that has been assigned to a particular link at that switch during bootstrapping. Wildcard matching as a generalization of longest prefix matching is natively supported since the OpenFlow v1.3 specification, efficiently implemented through TCAM based operations. With that, SDN forwarding actions only depend on the switch-local number of output ports, while being able to transport any number of higher-layer flows over the same transport network without specific flow rules being necessary. This results in a constant forwarding table size while no controller-switch interaction is necessary for any flow setup; only changes in forwarding topology (resulting in a change of port to bitnumber assignment) will require suitable changes of forwarding rules in switches.

Although we focus the methods in this draft on Layer 2 forwarding approaches, path-based transport networks can also be established as an overlay over otherwise Layer 2 networks. For instance, the BIER (Bit Indexed Explicit Replication) [RFC8279] efforts within the Internet Engineer Task Force (IETF) establish such path-based forwarding transport as an overlay over existing, e.g., MPLS networks. The path-based forwarding identification is similar to the aforementioned SDN realization although the bitfield represents ingress/egress information rather than links along the path.

Yet another transport network example is presented in [Khalili], utilizing flow aggregation over SDN networks. The flow aggregation again results in a path representation that is independent from the specific flows traversing the network.

5.2. ICN over 5GLAN

ICN aims at replacing the routing functionality of the Internet Protocol (IP). It is therefore natively supported over a Layer 2 transport network, such as Ethernet-based networks. Deployments exists over WiFi and local LAN networks, while usually overlaying (over IP) is being used for connectivity beyond localized edge networks.

With the emergence of the 5GLAN capability in (future) Release 16 based 5G networks, such cellular LAN connectivity to provide pure ICN could be utilized for pure ICN-based deployments, i.e. without the dual stack capability outlined in Section 4.2.3.2. With this, the entire 5G network would be interpreted as a local LAN, providing the necessary Layer 2 connectivity between the ICN network components. With the support of roaming in 5GLAN, such ‘5G network’ can span several operators and therefore large geographies.

Such deployment, however, comes without any core network integration, similar to the one outlined in Section 4.1, and therefore does not utilize ICN capabilities within the overall 5G core and access network. Benefits such as those outlined in the introduction, e.g., caching, would only exist at the endpoint level (from a 5GLAN perspective).

However, ICN components could be provided as SW components in a network slice at the endpoints of such 5GLAN connectivity, utilizing in-network compute facilities, e.g., for caching, CCN routing capabilities and others. Such endpoint-driven realization of a specific ICN deployment scenario is described in more detail in [I-D.trossen-icnrg-IP-over-icn], focusing on the provisioning of IP-based services over an ICN, which in turn is provided over a LAN (and therefore also 5GLAN) based transport network.

6. Deployment Considerations

The work in [I-D.irtf-icnrg-deployment-guidelines] outlines a comprehensive set of considerations related to the deployment of ICN. We now relate the solutions proposed in this draft to the two main aspects covered in the deployment considerations draft, namely the ‘deployment configuration’ (covered in Section 4 of [I-D.irtf-icnrg-deployment-guidelines]) that is being realized and the ‘deployment migration paths’ (covered in Section 5 of [I-D.irtf-icnrg-deployment-guidelines]) that are being provided.

The solutions proposed in this draft relate to those ‘deployment configuration’ as follows:

In relation of the ‘deployment migration paths’, the solutions in this draft relate as follows:

7. Conclusion

In this draft, we explore the feasibility of realizing future networking architectures like ICN within the proposed 3GPP's 5GC architecture. Towards this, we summarized the design principles that offer 5GC the flexibility to enable new network architectures. We then discuss 5GC architecture aspects along with the user/control plane extensions required to handle ICN PDU sessions formally to realize ICN with 5GC integration as well as ICN over a pure 5GLAN connectivity.

8. IANA Considerations

This document requests no IANA actions.

9. Security Considerations

This draft proposes extensions to support ICN in 5G's next generation core architecture. ICN being name based networking opens up new security and privacy considerations which have to be studied in the context of 5GC. This is in addition to other security considerations of 5GC for IP or non-IP based services considered in [TS33.899].

10. Acknowledgments

...

11. Informative References

[H2020] H2020, "The POINT Project", https://www.point-h2020.eu/
[I-D.galis-anima-autonomic-slice-networking] Galis, A., Makhijani, K., Yu, D. and B. Liu, "Autonomic Slice Networking", Internet-Draft draft-galis-anima-autonomic-slice-networking-05, September 2018.
[I-D.irtf-icnrg-deployment-guidelines] Rahman, A., Trossen, D., Kutscher, D. and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", Internet-Draft draft-irtf-icnrg-deployment-guidelines-06, May 2019.
[I-D.irtf-icnrg-icn-lte-4g] suthar, P., Stolic, M., Jangam, A., Trossen, D. and R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile Networks", Internet-Draft draft-irtf-icnrg-icn-lte-4g-03, March 2019.
[I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J. and M. Papalini, "Hybrid Information-Centric Networking", Internet-Draft draft-muscariello-intarea-hicn-01, December 2018.
[I-D.white-icnrg-ipoc] White, G., Shannigrahi, S. and C. Fan, "Internet Protocol Tunneling over Content Centric Mobile Networks", Internet-Draft draft-white-icnrg-ipoc-01, June 2018.
[ICNMOB] Azgin, A., Ravidran, R., Chakraborti, A. and G. Wang, "Seamless Producer Mobility as a Service in Information Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 2016.
[Jacobson] Jacobson, V. and et al., "Networking Named Content", Proceedings of ACM Context, , 2009.
[Khalili] Khalili, R., Poe, W., Despotovic, Z. and A. Hecker, "Reducing State of SDN Switches in Mobile Core Networks by Flow Rule Aggregation", IEEE ICCCN 2016, Hawaii, USA, August 2016.
[lteversus5g] Kim, J., Kim, D. and S. Choi, "3GPP SA2 architecture and functions for 5G mobile communication system.", ICT Express 2017, 2017.
[NFN] Sifalakis, M., Kohler, B., Christopher, C. and C. Tschudin, "An information centric network for computing the distribution of computations", ACM, ICN Sigcomm, 2014.
[OpenFlowSwitch] Open Networking Foundation, available at https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf, "OpenFlow Switch Specification V1.5.1", 2018.
[Ravindran] Ravindran, R., Chakraborti, A., Amin, S., Azgin, A. and G. Wang, "5G-ICN : Delivering ICN Services over 5G using Network Slicing", IEEE Communication Magazine, May, 2016.
[Reed] Reed, M., AI-Naday, M., Thomos, N., Trossen, D., Petropoulos, G. and S. Spirou, "Stateless Multicast Switching in Software Defined Networks", IEEE ICC 2016, Kuala Lumpur, Maylaysia, 2016.
[RFC8279] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017.
[SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and LAN Services", 3GPP , http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip.
[SDNDef] Open Networking Foundation, available at https://www.opennetworking.org/sdn-definition/, "Software-Defined Networking (SDN) Definition", 2018.
[TROSSEN] Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M. and G. Xylomenos, "IP Over ICN – The Better IP ?", EuCNC, European Conference on Networks and Communications , July, 2015.
[TS23.501] 3gpp-23.501, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Rel.15)", 3GPP , December 2018.
[TS23.502] 3gpp-23.502, "Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Rel. 15)", 3GPP , January 2019.
[TS23.799] 3gpp-23.799, "Technical Specification Group Services and System Aspects; Study on Architecture for Next Generation System (Rel. 14)", 3GPP , 2017.
[TS33.899] 3gpp-33.899, "Study on the security aspects of the next generation system", 3GPP , 2017.
[TS36.323] 3gpp-36.323, "Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Rel. 15)", 3GPP , January 2019.
[TS38.300] 3gpp-38-300, "Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Rel.15)", 3GPP , January 2019.
[VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X. and G. Wang, "Towards software defined ICN based edge-cloud services", CloudNetworking(CloudNet), IEEE Internation Conference on, IEEE Internation Conference on CloudNetworking(CloudNet), 2013.

Authors' Addresses

Ravi Ravindran Futurewei Technologies 2330 Central Expressway Santa Clara, 95050 USA EMail: ravi.ravindran@futurewei.com
Prakash Suthar Cisco Systems 9501 Technology Blvd. Rosemont, 50618 USA EMail: psuthar@cisco.com URI: http://www.cisco.com/
Dirk Trossen InterDigital Inc. 64 Great Eastern Street, 1st Floor London, EC2A 3QR United Kingdom EMail: Dirk.Trossen@InterDigital.com URI: http://www.InterDigital.com/
Chonggang Wang InterDigital Inc. 1001 E Hector St, Suite 300 Conshohocken, PA 19428 United States EMail: Chonggang.Wang@InterDigital.com URI: http://www.InterDigital.com/
Greg White CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: g.white@cablelabs.com