Internet DRAFT - draft-irtf-icnrg-5gc-icn
draft-irtf-icnrg-5gc-icn
ICNRG R. Ravindran
Internet-Draft Corning Incorporated
Intended status: Informational P. Suthar
Expires: July 14, 2021 Cisco
D. Trossen
Huawei
C. Wang
InterDigital Inc.
G. White
CableLabs
January 10, 2021
Enabling ICN in 3GPP's 5G NextGen Core Architecture
draft-irtf-icnrg-5gc-icn-04
Abstract
The proposed 3GPP's 5G core nextgen architecture (5GC) allows the
introduction of new user and control plane function, considering the
support for network slicing functions, that offers 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 over
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 July 14, 2021.
Ravindran, et al. Expires July 14, 2021 [Page 1]
Internet-Draft ICN in 5GC January 2021
Copyright Notice
Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 5G NextGen Core Design Principles . . . . . . . . . . . . . . 5
4. 5GC Architecture with ICN Support . . . . . . . . . . . . . . 6
4.1. 5G NextGen Core Architecture . . . . . . . . . . . . . . 6
4.2. ICN over 5GC . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Control Plane Extensions . . . . . . . . . . . . . . 10
4.2.2. User Plane Extensions . . . . . . . . . . . . . . . . 13
4.2.3. Dual Stack ICN Deployment . . . . . . . . . . . . . . 16
5. 5GLAN Architecture with ICN Support . . . . . . . . . . . . . 23
5.1. 5GC Architecture Extensions for 5GLAN Support . . . . . . 23
5.1.1. Realization of Nx Interface . . . . . . . . . . . . . 24
5.1.2. Bitfield-based Forwarding in Existing Transport
Networks . . . . . . . . . . . . . . . . . . . . . . 25
5.2. ICN over 5GLAN . . . . . . . . . . . . . . . . . . . . . 26
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 27
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The objective of this draft is to propose an architecture to enable
Information-Centric Networks (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
Ravindran, et al. Expires July 14, 2021 [Page 2]
Internet-Draft ICN in 5GC January 2021
also complements the discussions related to various ICN deployment
opportunities explored in [I-D.irtf-icnrg-deployment-guidelines],
where 5G technology promises to offer significantly better
throughput, latency and reliability performance than current LTE
system.
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:
o Edge Computing: Multi-access Edge Computing (MEC) is located at
the edge of the network and aids several latency sensitive
applications such as augmented and virtual reality (AR/VR), as
well as the ultra reliable and low latency class (URLLC) of
applications such as autonomous vehicles. Enabling edge computing
over an IP converged 5GC comes with the challenge of application
level reconfiguration required to re-initialize a session whenever
it is being served by a non-optimal service instance
topologically. In contrast, named-based networking, as considered
by ICN, naturally supports service-centric networking, which
minimizes network related configuration for applications and
allows fast resolution for named service instances.
o Edge Storage and Caching : A principal design feature of ICN is
the secured content (or named-data) object, which allows location
independent data replication at strategic storage points in the
network, or data dissemination through ICN routers by means of
opportunistic caching. These features benefit both real-time and
non-real-time applications whenever there is spatial and temporal
correlation among content accessed by these users, thereby
advantageous to both high-bandwidth and low-latency applications
such as conferencing, AR/VR, and non-real time applications such
as Video-on-Demand (VOD) and IoT transactions. Pervasive caching
as envisioned by ICN has implications on digital right management
(DRM) related to preserving privacy and copyright information of
consumer and content producer respectively. Solutions such as one
based on combining attribute based encryption (ABE) and DRM
[ABEDRM] has been proposed to address this challenge that strikes
a balance between securing content for a group of users (hence
avoiding per user based secure content dissimination) with similar
attributes and leveraging the distributed caches for efficient
delivery.
o Session Mobility: Existing long-term evolution (LTE) deployments
handle session mobility using centralized routing with the Mobile
Management Entity (MME) function, IP anchor points at Packet Data
Network Gateway (PDN-GW) and service anchor point called Access
Point Name (APN) functionality hosted in PDN-GW. LTE uses tunnels
Ravindran, et al. Expires July 14, 2021 [Page 3]
Internet-Draft ICN in 5GC January 2021
between radio edge (eNodeB) and PDN-GW for each mobile device
attached to network. This design fails when service instances are
replicated close to radio access network (RAN) instances,
requiring new techniques to handle session mobility [MEC5G]. In
contrast, ICN uses a split between the application identifier and
the name resolution that is known to handle host mobility
efficiently [ICNMOB].
In this document, we first discuss 5GC's design principles that allow
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:
5G-NextGen Core (5GC): Refers to the new 5G core network
architecture being developed by 3GPP, we specifically refer to the
architectural discussions in [TS23.501][TS23.502].
5G-New Radio (5G-NR): This refers to the new radio access
interface developed to support 5G wireless interface [TS38.300].
User Plane Function (UPF): UPF is the generalized logical data
plane function with context of the UE PDU session. UPFs can play
many roles, such as, being an flow classifier (UL-CL) (defined
next), a PDU session anchoring point, or a branching point.
Uplink Classifier (UL-CL): This is a functionality supported by an
UPF that aims at diverting traffic (locally) to local data
networks based on traffic matching filters applied to the UE
traffic.
Packet Data Network (PDN or DN): This refers to service networks
that belong to the operator or third party offered as a service to
the UE.
Unified Data Management (UDM): Manages unified data management for
wireless, wireline and any other types of subscribers for M2M, IOT
applications, etc. UDM reports subscriber related vital
information e.g. virtual edge region, list of location visits,
sessions active etc. UDM works as a subscriber anchor point so
that means OSS/BSS systems will have centralized monitoring-of/
access-to of the system to get/set subscriber information.
Ravindran, et al. Expires July 14, 2021 [Page 4]
Internet-Draft ICN in 5GC January 2021
Authentication Server Function (AUSF): Provides mechanism for
unified authentication for subscribers related to wireless,
wireline and any other types of subscribers such as M2M and IOT
applications. The functions performed by AUSF are similar to HSS
with additional functionalities to related to 5G.
Session Management Function (SMF): Performs session management
functions for attached users equipment (UE) in the 5G Core. SMF
can thus be formed by leveraging the CUPS (discussed in the next
section) feature with control plane session management.
Access Mobility Function (AMF): Perform access mobility management
for attached user equipment (UE) to the 5G core network. The
function includes, network access stratus (NAS) mobility functions
such as authentication and authorization.
Application Function (AF): Helps with influencing the user plane
routing state in 5GC considering service requirements.
Network Slicing: This conceptualizes the grouping for a set of
logical or physical network functions with its own or shared
control, data and service plane to meet specific service
requirements.
5GLAN Service: A service over the 5G system offering private
communication using IP and/or non-IP type communications.
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:
o Control and User plane split (CUPS): This design principle moves
away from LTE's vertically integrated control/user plane design
(i.e., Serving Gateway, S-GW, and Packet Data Network Gateway,
P-GW) to one espousing an NFV framework with network functions
separated from the hardware for service-centricity, scalability,
flexibility and programmability. In doing so, network functions
can be implemented both physically and virtually, while allowing
each to be customized and scaled based on their individual
requirements, also allowing the realization of multi-slice co-
existence. This feature also allows the introduction of new user
plane functions (UPF) in 5GC. UPFs can play many roles, such as,
being an uplink flow classifier (UL-CL), a PDU session anchor
point, a branching point function, or one based on new network
architectures like ICN with new control functions, or re-using/
Ravindran, et al. Expires July 14, 2021 [Page 5]
Internet-Draft ICN in 5GC January 2021
extending the existing ones to manage the new user plane
realizations.
o Decoupling of RAT and Core Network : Unlike LTE's unified control
plane for access and the core, 5GC offers control plane separation
of the RAN from the core network. This allows the introduction of
new radio access technologies (RAT) along with slices based on new
network architectures, offering the ability to map heterogeneous
RAN flows to arbitrary core network slices based on service
requirements.
o Non-IP PDU Session Support : A PDU session is defined as the
logical connection between the UE and the data network (DN). 5GC
offers a scope to support both IP and non-IP PDU (termed as
"unstructured" payload), and this feature can potentially allow
the support for ICN PDUs by extending or re-using the existing
control functions. More discussions on taking advantage of this
feature in ICN's context is presented in Section 4.2.2.2.
o Service Centric Design: 5GC's service orchestration and control
functions, such as naming, addressing, registration/authentication
and mobility, will utilize an API design similar to those used in
cloud technologies. Doing so enables opening up interfaces for
authorized service function interaction and creating service level
extensions to support new network architectures. These APIs
include the well accepted Get/Response and Pub/Sub approaches,
while not precluding the use of point-to-point procedural approach
among 5GC functional units (where necessary).
o Distributed LAN Support: utilizing the aforementioned unstructured
PDU session support, 5GC offers the capability to expose a Layer 2
LAN service to cellular user equipment. Such distributed LAN
targets to complement those in fixed broadband, including local
WLAN fanouts. Through such LAN capability, services can be
realized by being virtually embedded into an intranet deployment
with dedicated Internet-facing packet gateway functionality.
Examples for such services, among others, are those related to
Industrial IoT, smart city services and others. Utilizing this
capability for ICN-based services is presented in Section 5.1.
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
Ravindran, et al. Expires July 14, 2021 [Page 6]
Internet-Draft ICN in 5GC January 2021
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:
o Common control plane functions that are common to all slices and
which include the Network Slice Selection Function (NSSF), Policy
Control Function (PCF), and Unified Data Management (UDM) among
others.
o Shared or slice specific control functions, which include the
Access and Mobility Function (AMF), Session and Management
Function (SMF) and the Application Function (AF).
Ravindran, et al. Expires July 14, 2021 [Page 7]
Internet-Draft ICN in 5GC January 2021
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.
Ravindran, et al. Expires July 14, 2021 [Page 8]
Internet-Draft ICN in 5GC January 2021
+------------+
| 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
Ravindran, et al. Expires July 14, 2021 [Page 9]
Internet-Draft ICN in 5GC January 2021
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.
o Authentication and Mobility Function (AMF++): ICN applications in
the UEs have to be authorized to access ICN DNs. For this
purpose, as in [TS23.501], operator enables ICN as a DN offering
ICN services. As a network service, ICN-UE should also be
subscribed to it and this is imposed using the PCF and UDM, which
may interface with the ICN Application Function (ICN-AF) for
subscription and session policy management of ICN PDU sessions.
To enable ICN stack in the UE, AMF++ function has to be enabled
with the capability of authenticating UE's attach request for ICN
resources in 5GC. The request can be incorporated in Network
Slice Subnet Instance (NSSI) parameter to request either ICN
specific slice or using ICN in existing IP network slice when the
UE is dual stacked. AMF++ can potentially be extended to also
support ICN specific bootstrapping (such as naming and security)
and forwarding functions to configure UE's ICN layer. These
functions can also be handled by the ICN-AF and ICN control
function in the UE after setting PDU session state in 5GC. Here,
the recommendation is not about redefining the 5G UE attach
Ravindran, et al. Expires July 14, 2021 [Page 10]
Internet-Draft ICN in 5GC January 2021
procedures, but to extend the attach procedures messages to carry
ICN capabilities extensions in addition to supporting existing IP
based services. The extensions should allow a 5G UE to request
authentication to 5GC either in ICN, IP or dual-stack (IP and ICN)
modes. Further research is required to optimize 5G attach
procedures so that an ICN capable UE can be bootstrapped by
minimizing the number of control plane messages. One possibility
is to leverage existing 5G UE attach procedures as described in
3GPP's [TS23.502], where the UE can provide ICN identity in the
LTE equivalent protocol configuration option information element
(PCO-IE) message during the attach request as described in
[I-D.irtf-icnrg-icn-lte-4g]. In addition, such requirement can
also be provided by the UE in NSSI parameters during initial
attach procedures. Alternately, ICN paradigm offers name-based
control plane messaging and security which one can leverage during
the 5G UE attach procedures, however this requires further
research.
o Session Management Function (SMF++): Once a UE is authenticated to
access ICN service in network, SMF manages to connect UE's ICN PDU
sessions to the ICN DN in the UL/DL. SMF++ should be capable to
manage both IP, ICN or dual stack UE with IP and ICN capabilities.
To support ICN sessions, SMF++ creates appropriate PDU session
policies in the UPF, which include UL-CL and ICN gateway (ICN-GW)
(discussed in Section 4.2.2) through the ICN-SMF. For centrally
delivered services, ICN-GW could also multiplex as an IP anchor
point for IP applications. If MEC is enabled, these two functions
would be distributed, as the UL-CL will re-route the flow to a
local ICN-DN. 3GPP has defined IP based session management
procedures to handle UE PDU sessions in TS23.502. For ICN UE we
can either leverage same procedures when ICN is deployed as an
overlay protocol. Towards this, SMF++ interfaces with AMF++ over
N11++ to enable ICN specific user plane functions, which include
tunnel configuration and traffic filter policy to inter-connect UE
with the appropriate radio and the core slice. Furthermore, AMF++
sets appropriate state in the RAN and the UE that directs ICN
flows to the chosen ICN UL-CL in the core network, and towards the
right UE in the downlink.
o ICN Session Management Function (ICN-SMF): ICN-SMF serves as
control plane for the ICN state managed in ICN-GW. This function
can be either incorporated as part of SMF++ or as a stand-alone
one. This function interacts with SMF++ to obtain and also push
ICN PDU session management information for the creation,
modification and deletion of ICN PDU sessions in ICN-GW. For
instance, when new ICN slices are provisioned by the ICN service
orchestrator, ICN-SMF requests a new PDU session to the SMF that
extends to the RAN. While SMF++ manages the tunnels to
Ravindran, et al. Expires July 14, 2021 [Page 11]
Internet-Draft ICN in 5GC January 2021
interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate
forwarding state in ICN-GW (using the forwarding information base
or FIB) to enable ICN flows over appropriate tunnel interfaces
managed by the SMF++. In addition, it also signals resource
management rules to share compute, bandwidth, storage/cache
resources among multiple slice instances co-located in the ICN-GW.
o ICN Application Function (ICN-AF): ICN-AF represents the
application controller function that interfaces with ICN-SMF and
PCF/UDM function in 5GC. In addition to transferring ICN
forwarding rules to ICN-SMF, ICN-AF also interfaces with PCF/UDM
to transfer user profile and subscription policies along with
session management requirement to UE's ICN PDU session in the 5GC
network. ICN-AF is an extension of the ICN service orchestration
function, which can influence both ICN-SMF and in-directly SMF++
to steer traffic based on ICN service requirements. ICN-AF can
also interact with the northbound 5G operator's service functions,
such as network exposure function(NEF) that exposes network
capabilities, for e.g. location based services, that can be used
by ICN-AF for proactive ICN PDU session and slice management and
offer additional capabilities to the ICN slices.
4.2.1.1. Normative Interface Extensions
o N1++/N11++: This extension enables ICN specific control functions
to support ICN authentication, configuration and programmability
of an ICN-UE via AMF++ and SMF++, and also impose QoS
requirements, handle mobility management of an ICN PDU session in
5GC based on service requirements.
o N4: Though this signaling is service agnostic, as discussed in
Section 4.2.2, future extensions may include signaling to enable
ICN user plane features in these network functions. The extension
of N4 to RAN is to handle the case when UPF function collocates
with the RAN instance to enable localized ICN DNs.
o NIcn: This extension shall support two functions: (i) control
plane programmability to enable ICN PDU sessions applicable to 5GC
to map to name based forwarding rules in ICN-GW; (ii)control plane
extensions to enable ICN mobility anchoring at ICN-GW, in which
case it also acts as POA for ICN flows. Features such as ICN
mobility as a service can be supported with this extension
[ICNMOB].
o Naf++: This extension supports 5GC control functions such as
naming, addressing, mobility, and tunnel management for ICN PDU
sessions to interact with SMF++ and AMF++.
Ravindran, et al. Expires July 14, 2021 [Page 12]
Internet-Draft ICN in 5GC January 2021
o Npcf++/Nudm++: This extension creates an interface to push ICN
service and PDU session requirements to PCF and UDM functions that
interact with the ICN-AF function for ICN slice specific
configuration. These requirements are enforced at various steps,
for instance, during ICN application registration, authentication,
slice mapping, and provisioning of resources for these PDU
sessions in the UPF.
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.
o ICN Gateway (ICN-GW): ICN-GW is where the 5GC PDU sessions
terminate and ICN service network begins. Compared to the
traditional anchor points as in PGW, the ICN-GW is also a service
gateway as it can host services or cache content enabled through
the ICN architecture. The ICN-GW also includes the UPF functions
to manage multiple tunnel interfaces enabling the relay of ICN PDU
flows to appropriate UL-CL instances in the DL. Note that there
may be multiple ICN-GWs serving different ICN services or slices.
ICN-GW also manages other ICN functions such as enforcing the
dynamic name based forwarding state, mobility state, in-network
service function management, resource management with respect to
sharing caching, storage, and compute resources among multiple
services[Ravindran].
o ICN Data Network (ICN-DN): ICN-DN represents a set of ICN nodes
used for ICN networking and with heterogeneous service resources
such as storage and computing points. An ICN network enables both
network and application services, with network services including
caching, mobility, multicast, multi-path routing (and possibly
network layer computing), and application services including
network resources (such as cache, storage, network state
resources) dedicated to the application.
* Considering multiple ICN architecture proposals and multiple
ICN deployment models discussed in
[I-D.irtf-icnrg-deployment-guidelines], an alternate backward
compatible (IP-over-)ICN solution is proposed in [TROSSEN].
Such an ICN-DN can simply consist of SDN forwarding nodes and a
logically centralized path computation entity (PCE), where the
PCE is used to determine suitable forwarding identifiers being
used for the path-based forwarding in the SDN-based transport
Ravindran, et al. Expires July 14, 2021 [Page 13]
Internet-Draft ICN in 5GC January 2021
network. In addition, the PCE is responsible for maintaining
the appropriate forwarding rules in the SDN switches. For
interconnection to IP-based peering networks, a packet gateway
is being utilized that mirrors the transport convergence layer
functionality to map incoming ICN traffic back in to outgoing
IP traffic and vice versa. This form of deployment would
require minimal changes to the 5GC's user and control plane
procedures, as the applications on these IP end points are not
exposed (or minimally exposed) to any ICN state or
configuration.
o Uplink Classifier (UL-CL): UL-CL enables classification of flows
based on source or destination IP address and steers the traffic
to an appropriate network or service function anchor point. If
the ICN-GW is identified based on service IP address associated
with the ICN-UE's flows, UL-CL checks the source or destination
address to direct traffic to an appropriate ICN-GW. For native
ICN UE, ICN shall be deployed over 5G-NR; here, there may not be
any IP association. For such packet flows new classification
schema shall be required, such as, using 5G-NR protocol extensions
to determine the tunnel interface to forward the ICN payload on,
towards the next ICN-GW.
4.2.2.1. Normative Interface Extensions
o N3: Though the current architecture supports heterogeneous service
PDU handling, future extensions can include user plane interface
extensions to offer explicit support to ICN PDU session traffic,
for instance, an incremental caching and computing function in RAN
or UL-CL to aid with content distribution.
o N9: Extensions to this interface can consider UPFs to enable
richer service functions, for instance to aid context processing.
In addition extensions to enable ICN specific encapsulation to
piggyback ICN specific attributes such as traffic or mobility data
between the UPF branching point and the ICN-GW.
o N6: This interface is established between the ICN-GW and the ICN-
DN, whose networking elements in this segment can be deployed as
an overlay or as a native Layer-3 network.
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:
Ravindran, et al. Expires July 14, 2021 [Page 14]
Internet-Draft ICN in 5GC January 2021
o Attach Procedures for UE with Non-IP PDN: Assuming a 5GC can
support both IP and non-IP PDN, this requires control plane
support. In a typical scenario, when UE sends an attach message
to 5GC, the type of PDU connection is indicated in the PCO-IE
field, for e.g. in this case as being non-IP PDN to invoke related
control plane session management tasks. ICN over non-IP PDU
session will allow the UE to attach to 5GC without any IP
configuration. 5GC attach procedures specified [TS23.501] can be
used to support authentication of UE with PDN type set to non-IP,
using existing AUSF/UDM functions in coordination with the ICN-AF
function discussed earlier if required.
o User Plane for UE with Non-IP PDN: Without any IP tunnel
configuration and ICN's default consumer agnostic mode of
operation requires ways to identify the ICN-UE in the user plane,
this can be enabled by introducing network identifier in the lower
layers such as in the PDCP or MAC layer, that can assist for
functions such as policy and charging at the BS and related
session management tasks. These identifiers can also be used to
demultiplex the DL traffic from the ICN-GW in the BS to the
respective ICN-UEs. Also, ICN extensions can be incorporated in
control plane signaling to identify an ICN-UE device and these
parameters can be used by SMF to conduct non-IP routing. The
policing and charging functions can be enforced by the UPF
function in the BS which obtains the traffic filtering rules from
the SMF. To enable flat ICN network from the BS requires
distributed policy, charging and legal intercept which requires
further research. Further ICN slice multiplexing can be realized
by also piggybacking slice-ID (NSSI) along with device ID to
differentiate handover to multiple ICN slices at the base station.
Inter-working function (IWF) is required if services based on non-
IP UE has to transact or communicate with transport, applications
functions or other UE based on IP services. This also has
implications on how mobility is managed for such PDU sessions.
o Mobility Handling: Considering mobility can be support by ICN, it
is inefficient to traverse other intermediate IP networks between
the BS and the next ICN hop. This requires ICN PDU to be handled
by an ICN instance in the BS itself, in association with UL-CL
function local to the BS as shown in Figure 2. Control plane
extensions discussed in Section 4.2.1 can be used in tandem with
distributed mobility protocols to handle ICN mobility, one such
solution for producer mobility is proposed in [ICNMOB]
o Routing Considerations: Flat ICN network realizations also offers
the advantage of optimal routing, compared to anchor point based
realization in LTE. This also leads to optimal realization of the
data plane considering the absence of overhead due to tunneling
Ravindran, et al. Expires July 14, 2021 [Page 15]
Internet-Draft ICN in 5GC January 2021
while forwarding ICN traffic. However, developing a routing
control plane in to handle the ICN PDU sessions either leveraging
SMF functions or a distributed realization requires more
investigation. In the centralized approach the SMF could interact
with ICN-SMF to set the forwarding rules in the ICN-GW in the BS
and other ICN-UPFs, however this may also lead to scalability
issues if a flat ICN network is to be realized. This also has
implications to route the non-IP PDU sessions efficiently to the
closest ICN-MEC instance of the service.
o IP over ICN: Native support of ICN in the RAN raises the
possibility of leveraging the mobility functions in ICN protocols
as a replacement for GTP tunneling in the 5GC, as described in
[I-D.white-icnrg-ipoc] and [TROSSEN].
o Mobile Edge Computing: Another significant advantage is with
respect to service-centric edge computing at the ICN-GW or other
ICN points, either through explicit hosting of service
functions[VSER] in ICN or in-network computing based on NFN
proposal[NFN]. A certain level of orchestration is required to
ensure service interconnection and its placement with appropriate
compute resources and inter-connected with bandwidth resources so
that the desired SLA is offered.
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).
Ravindran, et al. Expires July 14, 2021 [Page 16]
Internet-Draft ICN in 5GC January 2021
+--------+ +--------+
| 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
Ravindran, et al. Expires July 14, 2021 [Page 17]
Internet-Draft ICN in 5GC January 2021
+--------+ +--------+
| 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)
Ravindran, et al. Expires July 14, 2021 [Page 18]
Internet-Draft ICN in 5GC January 2021
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 applications 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,
Ravindran, et al. Expires July 14, 2021 [Page 19]
Internet-Draft ICN in 5GC January 2021
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
Ravindran, et al. Expires July 14, 2021 [Page 20]
Internet-Draft ICN in 5GC January 2021
+----------------+ +-----------------+
| 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.
o Existing application layer can be modified to provide options for
new ICN based application and existing IP based applications. UE
can continue to support existing IP based applications or host new
applications developed either to support native ICN as transport,
ICNoIP or IPoICN based transport. Application layer has the
option of selecting either ICN or IP transport layer as well as
radio interface to send and receive data traffic. Our proposal is
to provide a common Application Programming Interface (API) to the
application developers such that there is no impact on the
application development when they choose either ICN or IP
transport for exchanging the traffic with the network. TCL
function handles the interaction of application with the multiple
transport options.
Ravindran, et al. Expires July 14, 2021 [Page 21]
Internet-Draft ICN in 5GC January 2021
o The TCL helps determine what type of transport (e.g. ICN or IP)
as well as type of radio interface (e.g. 5G NR or WiFi or both),
is used to send and receive the traffic. Application layer can
make the decision to select a specific transport based on
preference e.g. content location, content type, content publisher,
congestion, cost, quality of service etc. There can be an
Application Programming Interface (API) to exchange parameters
required for transport selection. The southbound interactions of
TCL will be either to IP or ICN at the network layer. When
selecting the IPoICN [TROSSEN] mode, the TCL is responsible for
receiving an incoming IP or HTTP packet and publishing the packet
under a suitable ICN name (i.e. the hash over the destination IP
address for an IP packet or the hash over the FQDN of the HTTP
request for an HTTP packet) to the ICN network. In the HTTP case,
the TCL maintains a pending request mapping table to map returning
responses to the originating HTTP request. The common API will
provide a common 'connection' abstraction for this HTTP mode of
operation, returning the response over said connection
abstraction, akin to the TCP socket interface, while implementing
a reliable transport connection semantic over the ICN from the UE
to the receiving UE or the PGW. If the HTTP protocol stack
remains unchanged, therefore utilizing the TCP protocol for
transfer, the TCL operates in local TCP termination mode,
retrieving the HTTP packet through said local termination. The
southbound interactions of the Transport Convergence Layer (TCL)
will be either to IP or ICN at the network layer.
o ICN function (forwarder) is introduced in parallel to the existing
IP layer. ICN forwarder contains functional capabilities to
forward ICN packets, e.g. Interest packet to gNB or response
"data packet" from gNB to the application.
o For dual stack scenario, when UE is not supporting ICN at network
layer, we use IP underlay to transport ICN packets. ICN function
will use IP interface to send Interest and Data packets for
fetching or sending data using ICN protocol function. This
interface will use ICN overlay over IP using any overlay tunneling
mechanism.
o To support ICN at network layer in UE, PDCP layer has to be aware
of ICN capabilities and parameters. PDCP is located in the Radio
Protocol Stack in the 5G Air interface, between IP (Network layer)
and Radio Link Control Layer (RLC). PDCP performs following
functions [TS36.323]:
* Data transport by listening to upper layer, formatting and
pushing down to Radio Link Layer (RLC).
Ravindran, et al. Expires July 14, 2021 [Page 22]
Internet-Draft ICN in 5GC January 2021
* Header compression and decompression using Robust Header
Compression (ROHC).
* Security protections such as ciphering, deciphering and
integrity protection.
* Radio layer messages associated with sequencing, packet drop
detection and re-transmission etc.
o No changes are required for lower layer such as RLC, MAC and
Physical (L1) because they are not IP aware.
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
Ravindran, et al. Expires July 14, 2021 [Page 23]
Internet-Draft ICN in 5GC January 2021
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
Ravindran, et al. Expires July 14, 2021 [Page 24]
Internet-Draft ICN in 5GC January 2021
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 Layer 4 transport fields such as source port and destination
port.
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
Ravindran, et al. Expires July 14, 2021 [Page 25]
Internet-Draft ICN in 5GC January 2021
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.
Ravindran, et al. Expires July 14, 2021 [Page 26]
Internet-Draft ICN in 5GC January 2021
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:
o The integration with the 5GC, as proposed in Section 4.2, follows
the 'Clean-slate ICN' deployment configuration, i.e., integrating
the ICN capabilities natively into the 5GC through appropriate
extensions at the control and user plane level.
o The utilization of the 5GLAN capabilities, as proposed in
Section 5.2, follows the 'ICN-as-an-Overlay', interpreting the
5GLAN as an overlay capability with no 5GC integration being
considered.
o The deployment of 5GLAN based ICN capabilities can be realized
following the 'ICN-as-a-Slice' deployment configuration, i.e., the
5GLAN connectivity is provided to a 'vertical 5G customer' which
in turn provides the ICN capability over 5GLAN within said network
(and compute) slice at the endpoints of the 5GLAN connectivity, as
proposed in Section 5.2.
Ravindran, et al. Expires July 14, 2021 [Page 27]
Internet-Draft ICN in 5GC January 2021
In relation of the 'deployment migration paths', the solutions in
this draft relate as follows:
o The integration with the 5GC, as proposed in Section 4.2,
facilitates 'edge network migration' (interpreting the cellular
sub-system here as an edge network albeit a possibly
geographically large one).
o The dual-stack deployment, as proposed in Section 4.2.3,
facilitates 'application and services migration' through not only
supporting ICN applications but also IP-based applications through
the proposed IP-over-ICN mapping in the terminal.
o The ICN over 5GLAN deployment, possibly combined with an ICN-as-
a-Slice deployment, facilitates the 'content delivery networks
migration' through a deployment of ICN-based 5GLAN connected CDN
elements in (virtualized) edge network nodes or point of presence
locations in the customer (5G) network.
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
...
Ravindran, et al. Expires July 14, 2021 [Page 28]
Internet-Draft ICN in 5GC January 2021
11. Informative References
[ABEDRM] Papanis, J., Papapanagiotou, S., Mousas, A., Lioudakis,
G., Kaklamani, D., and I. Venieris, "On the use of
Attribute-Based Encryption for multimedia content
protection over Information-Centric Networks",
ETT, Transaction on, Transaction on Emerging
Telecommunication Technologies, 2014.
[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", draft-galis-anima-autonomic-slice-
networking-05 (work in progress), September 2018.
[I-D.irtf-icnrg-deployment-guidelines]
Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", draft-irtf-icnrg-deployment-
guidelines-07 (work in progress), September 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", draft-irtf-icnrg-icn-lte-4g-08 (work in
progress), July 2020.
[I-D.muscariello-intarea-hicn]
Muscariello, L., Carofiglio, G., Auge, J., Papalini, M.,
and M. Sardara, "Hybrid Information-Centric Networking",
draft-muscariello-intarea-hicn-04 (work in progress), May
2020.
[I-D.white-icnrg-ipoc]
White, G., Shannigrahi, S., and C. Fan, "Internet Protocol
Tunneling over Content Centric Mobile Networks", draft-
white-icnrg-ipoc-02 (work in progress), June 2019.
[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.
Ravindran, et al. Expires July 14, 2021 [Page 29]
Internet-Draft ICN in 5GC January 2021
[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.
[MEC5G] ISBN-No-979-10-92620-22-1, "MEC in 5G", ETSI , June 2018.
[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., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[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.
Ravindran, et al. Expires July 14, 2021 [Page 30]
Internet-Draft ICN in 5GC January 2021
[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
Ravindran, et al. Expires July 14, 2021 [Page 31]
Internet-Draft ICN in 5GC January 2021
Ravi Ravindran
Corning Incorporated
680 W. Maude Ave.
Sunnyvale 94085
USA
Email: Ravindrar2@corning.com
Prakash Suthar
Cisco Systems
9501 Technology Blvd.
Rosemont 50618
USA
Email: psuthar@cisco.com
URI: http://www.cisco.com/
Dirk Trossen
Huawei Technologies Duesseldorf GmbH
205 Hansallee
Duesseldorf 40549
Germany
Email: dirk.trossen@huawei.com
URI: http://huawei-dialog.de/
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
Ravindran, et al. Expires July 14, 2021 [Page 32]
