[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 draft-irtf-icnrg-5gc-icn

ICNRG                                                       R. Ravindran
Internet-Draft                                                    Huawei
Intended status: Informational                                 P. Suthar
Expires: September 7, 2019                                         Cisco
                                                              D. Trossen
                                                                 C. Wang
                                                       InterDigital Inc.
                                                                G. White
                                                               CableLabs
                                                           March 6, 2019


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

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, followed by extensions to 5GC's control and user plane
   to support Packet Data Unit (PDU) sessions from Information-Centric
   Networks (ICN).  The value of enabling ICN in 5GC is discussed using
   IP-based service scenarios in the context of 5G Local Area Networks
   (5GLAN).

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 September 7, 2019.







Ravindran, et al.       Expires September 7, 2019               [Page 1]


Internet-Draft                 ICN in 5GC                     March 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  5G NextGen Core Design Principles . . . . . . . . . . . . . .   5
   4.  5G NextGen Core Architecture  . . . . . . . . . . . . . . . .   6
   5.  5GC Architecture with ICN Support . . . . . . . . . . . . . .   8
     5.1.  Control Plane Extensions  . . . . . . . . . . . . . . . .  10
       5.1.1.  Normative Interface Extensions  . . . . . . . . . . .  12
     5.2.  User Plane Extensions . . . . . . . . . . . . . . . . . .  13
       5.2.1.  Normative Interface Extensions  . . . . . . . . . . .  14
       5.2.2.  ICN over non-IP PDU . . . . . . . . . . . . . . . . .  14
       5.2.3.  Dual Stack ICN Deployment . . . . . . . . . . . . . .  16
   6.  5GC Architecture with 5GLAN Support . . . . . . . . . . . . .  23
     6.1.  Background: LAN-based End-to-End Packet Forwarding in 5G   23
       6.1.1.  Realization in Existing Transport Networks  . . . . .  25
     6.2.  IP-based Service over ICN over 5GLAN  . . . . . . . . . .  26
       6.2.1.  General Operations  . . . . . . . . . . . . . . . . .  28
       6.2.2.  ICN API to Upper Layers . . . . . . . . . . . . . . .  29
       6.2.3.  HTTP over ICN . . . . . . . . . . . . . . . . . . . .  30
       6.2.4.  Ad-Hoc Multicast for HTTP over ICN  . . . . . . . . .  30
       6.2.5.  Service Proxy Operations  . . . . . . . . . . . . . .  31
       6.2.6.  ICN Flow Management . . . . . . . . . . . . . . . . .  31
       6.2.7.  NR Operations . . . . . . . . . . . . . . . . . . . .  31
       6.2.8.  Mobility Handling . . . . . . . . . . . . . . . . . .  32
       6.2.9.  Dual Stack Device Support . . . . . . . . . . . . . .  32
     6.3.  ICN over 5GLAN  . . . . . . . . . . . . . . . . . . . . .  32
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  32
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  33
   11. Informative References  . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36



Ravindran, et al.       Expires September 7, 2019               [Page 2]


Internet-Draft                 ICN in 5GC                     March 2019


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.rahman-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:

   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 realtime and
      non-realtime 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.

   o  Session Mobility: Existing long-term evolution (LTE) deployments
      handle session mobility using centralized routing using the 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 tunnel between radio
      edge (eNodeB) and PDN-GW for each mobile device attached to
      network.  This design fails when service instances are replicated



Ravindran, et al.       Expires September 7, 2019               [Page 3]


Internet-Draft                 ICN in 5GC                     March 2019


      close to radio access network (RAN) instances, requiring new
      techniques to handle session mobility.  In contrast, application-
      bound identifier and name resolution split principle considered
      for the ICN is shown to handle host mobility quite efficiently
      [ICNMOB].

   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.  We then discuss specific
   network services enabled using ICN data networks, specifically MEC
   use case scenarios and ICN session mobility with aid from the 5GC
   control plane.

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 role, 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 September 7, 2019               [Page 4]


Internet-Draft                 ICN in 5GC                     March 2019


      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.

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/
      extending the existing ones to manage the new user plane
      realizations.





Ravindran, et al.       Expires September 7, 2019               [Page 5]


Internet-Draft                 ICN in 5GC                     March 2019


   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 5.2.2.

   o  Service Centric Design: 5GC's service orchestration and control
      functions, such as naming, addressing, registration/authentication
      and mobility, will utilize 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 6.

4.  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 5.  More exhaustive discussions on the various
   architecture functions, such as registration, connection and
   subscription management, can be found in[TS23.501][TS23.502].







Ravindran, et al.       Expires September 7, 2019               [Page 6]


Internet-Draft                 ICN in 5GC                     March 2019


                                 +------+
   +-----+ +-------+  +------+   | 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).

   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



Ravindran, et al.       Expires September 7, 2019               [Page 7]


Internet-Draft                 ICN in 5GC                     March 2019


   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.

5.  5GC Architecture with ICN Support

   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 September 7, 2019               [Page 8]


Internet-Draft                 ICN in 5GC                     March 2019


                               +------------+
                               |     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.suthar-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 September 7, 2019               [Page 9]


Internet-Draft                 ICN in 5GC                     March 2019


   discussed in Section 5.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.

5.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 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 procedures, but to extend the attach



Ravindran, et al.       Expires September 7, 2019              [Page 10]


Internet-Draft                 ICN in 5GC                     March 2019


      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.suthar-icnrg-icn-lte-4g].  In
      addition, such requirement can be 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 5.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
      interconnect ICN-GW to UL-CL, ICN-SMF creates the appropriate



Ravindran, et al.       Expires September 7, 2019              [Page 11]


Internet-Draft                 ICN in 5GC                     March 2019


      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.

5.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 5.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 September 7, 2019              [Page 12]


Internet-Draft                 ICN in 5GC                     March 2019


   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.

5.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 Packet Data Network (ICN-(P)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.rahman-icnrg-deployment-guidelines], an alternate backward
         compatible (IP-over-)ICN solution is proposed in [TROSSEN].
         Such an ICN-(P)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



Ravindran, et al.       Expires September 7, 2019              [Page 13]


Internet-Draft                 ICN in 5GC                     March 2019


         SDN-based transport 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
         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.

5.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.

5.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 September 7, 2019              [Page 14]


Internet-Draft                 ICN in 5GC                     March 2019


   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, as discussed in Section 5.  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 5 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



Ravindran, et al.       Expires September 7, 2019              [Page 15]


Internet-Draft                 ICN in 5GC                     March 2019


      data plane considering the absence of overhead due to tunneling
      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].

   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, as discussed in
      Section 5, 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.

5.2.3.  Dual Stack ICN Deployment

5.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 September 7, 2019              [Page 16]


Internet-Draft                 ICN in 5GC                     March 2019


 +--------+                                                   +--------+
 |  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) GUP-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.

5.2.3.2.  Protocol Stack for ICN Deployment in 5G



















Ravindran, et al.       Expires September 7, 2019              [Page 17]


Internet-Draft                 ICN in 5GC                     March 2019


 +--------+                                                   +--------+
 |  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 September 7, 2019              [Page 18]


Internet-Draft                 ICN in 5GC                     March 2019


   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,



Ravindran, et al.       Expires September 7, 2019              [Page 19]


Internet-Draft                 ICN in 5GC                     March 2019


   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.

5.2.3.3.  Protocol Interactions and Impacts


























Ravindran, et al.       Expires September 7, 2019              [Page 20]


Internet-Draft                 ICN in 5GC                     March 2019


                  +----------------+ +-----------------+
                  | 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 September 7, 2019              [Page 21]


Internet-Draft                 ICN in 5GC                     March 2019


   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 September 7, 2019              [Page 22]


Internet-Draft                 ICN in 5GC                     March 2019


      *  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.

6.  5GC Architecture with 5GLAN Support

   In this section, we focus on the implemention of ICN over 5GLAN
   architecture [SA2-5GLAN]

6.1.  Background: LAN-based End-to-End Packet Forwarding in 5G


    +------+  +------+  +-----+   +-----+   +-----+   +-----+
    | 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 SMF



Ravindran, et al.       Expires September 7, 2019              [Page 23]


Internet-Draft                 ICN in 5GC                     March 2019


   (session management function) 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, i.e., the session management function).

   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).

   In the following, path-based forwarding is assumed, i.e., the usage
   of the Nx interface and 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



Ravindran, et al.       Expires September 7, 2019              [Page 24]


Internet-Draft                 ICN in 5GC                     March 2019


   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 flat device
   (or proxy 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 described in Section 6.2.6 and the
   PATH_ID is the bitfield-based path identifier for the path-based
   forwarding.

6.1.1.  Realization 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, the Name Resolver (NR)
   assigns to each link at each switch a unique bitnumber in the
   bitfield.  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



Ravindran, et al.       Expires September 7, 2019              [Page 25]


Internet-Draft                 ICN in 5GC                     March 2019


   supported by SDN-based switches 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.

6.2.  IP-based Service over ICN over 5GLAN
























Ravindran, et al.       Expires September 7, 2019              [Page 26]


Internet-Draft                 ICN in 5GC                     March 2019


                   +-------------------------------+
                   |       Forwarding Network      |     .... Control
                   |  +--------------------------+ |
                   |  | .          NR          . | |     **** Data
                   |  +-.----------------------.-+ |
+--------------+   |    .                      .   |    +--------------+
|     App      |   |  +-.---------+  +---------.-+ |    |      App     |
+-----+----+---+   |  | . ******* |  | ******* . | |    +--------------+
|HTTP*|TCP*|IP.|   |  | . * UPF * |  | * UPF * . | |    |.IP|*TCP|*HTTP|
+----*+---*+--.+   |  +-.-*-----*-+  +-*-----*-.-+ |    +.--+*---+*----+
|ICN *    *   .|   |    . *     *      *     * .   |    |.   *    * ICN|
+----*----*---.+  +---+ . *     ********     * . +---+  +.---*----*----+
|L2  *    *   ....|RAN+.. *                  * ..+RAN|....   *    *    |
|    **********************                  **********************    |
+--------------+  +---+ . *                  * . +---+  +--------------+
                   |    . *                  * .   |
                   |  +-.-*-----+      +-----*-.+  |
                   +--| . *  RAN|------|RAN  * .|--+
                      +-.-*-----+      +-----*-.+
                        . *                  * .
                        . *******      ******* .
Legacy    Service       ....... *      * .......   Service
Device    Proxy               . *      * .         Proxy
+-----+ +-------------------+ . *      * . +-------------------+
|APP *| |    *********      | . *      * . |     **********    |
+----*+ +----*+      *      | . *      * . |     *       +*----+
|HTTP*| |HTTP*|*******      | . *      * . |     ********|*HTTP|
+----*+ +----*-+     *      | . *      * . |     *       +*----+
|TCP *| |TCP * |******      | . *      * . |     *******| * TCP|
+----*+ +----*--+   +*------+ . *      * . +-----*+   +---*----+  +-------+
|IP  *| |IP  *  |***|* ICN .| . *      * . |.ICN *|***|   *  IP|  | IP    |
+----*+ +----*--+---+*-----.+ . *      * . +.----*+---+---*----+  |Peering|
|L2  *| |    *   L2  *     .... *      * ....    *        *    |  |Network|
|    *********       ************      ***********        ************    |
+-----+ +-------------------+              +-------------------+  +-------+


              Figure 8: IP-based Services over ICN over 5GLAN

   Figure 8 shows the protocol layering for realizing IP-based protocols
   over an ICN over 5GLAN transport, assuming an end-to-end LAN
   connectivity provided by solutions such as 5GLAN.

   Note that such LAN connectivity can also be found in environments
   such as localized LAN-based deployments in smart cities, enterprises
   and others.  Hence, the solutions described in this section also
   applies to those deployments.




Ravindran, et al.       Expires September 7, 2019              [Page 27]


Internet-Draft                 ICN in 5GC                     March 2019


   Key to the approach is that Internet services are being interpreted
   as the main unit of transfer in the architecture shown in Figure 8.
   For this, any Internet service is treated as a Named Service
   Transaction (NST) which is in turn suitably routed over an ICN layer
   in one or more other devices.  As a result of this name-based
   interpretation of any Internet service, the protocol stack in end
   devices flattens to four layers with Internet services and ICN, with
   ICN acting as a name-based routing layer for all IP protocol
   implemented atop, with Layer 1 and 2 realizing the end-to-end packet
   forwarding outlined in Section 6.1.

   The details of the mapping and the operations of the ICN layer are
   presented in Section 6.2.3 for the example of HTTP.  As explained in
   that section, the ICN layer uses an interaction with the NR to
   register and discover HTTP-based services for determining the
   suitable end-to-end packet forwarding information.

   An important aspect of the architecture is the mapping of the end-to-
   end flow semantic established in many Internet services onto the flat
   protocol stack.  Section 6.2.7 outlines the flow management that
   exists between the end devices.

   Interfaces to legacy devices and peering networks are preserved
   through service proxy devices, which terminate a traditional Internet
   protocol stack communication and translate it into a resulting flat
   protocol transaction based on the operations defined in
   Section 6.2.3.  Termination here can be based on well-known port
   numbers for specific Internet protocols, ultimately falling back to
   the IP datagram service being the minimal service being mapped.

6.2.1.  General Operations

   The semantics of our name-based routing as that of a publish-
   subscribe system over a name.  The intention to receive packets with
   a certain name is expressed through a subscription while sending
   packets to a name is expressed through a publication.  The matching
   of a sender to a receiver is realized through NR in Figure 8.  The
   exact nature of the matching is defined through the semantics of the
   service and, therefore, through the nature of the name provided.  For
   instance, HTTP and raw IP services are matched to exactly one
   subscriber only, providing an anycast capability, while IP multicast
   services are matched against any subscriber (with the IP multicast
   address being the name).

   Structured names are used with the root specific to the (Internet)
   service name, such as URL, and therefore deriving the matching
   semantics directly from the name.




Ravindran, et al.       Expires September 7, 2019              [Page 28]


Internet-Draft                 ICN in 5GC                     March 2019


   The subscription to a name is realized through a registration
   protocol between end device and NR.  Hence, any end device exposing a
   certain Internet service registers the suitable name with the NR,
   which in turn stores reachability information that is suitable for
   path calculation between the ingress and egress L2 forwarders between
   which the communication eventually will take place.  In our current
   realization, we utilize shortest paths only although other link
   weights can be utilized for, e.g., delay-constrained and other
   policies.

   In our realization, we use network domain unique host identifiers
   that are being assigned to end devices during the connectivity setup.
   Sending a packet of a given Internet service is realized through a
   discovery protocol, which returns a suitable pathID, i.e., the
   forwarding information between ingress and egress L2 forwarder, and
   the destination MAC address of the hosting end device.  It is this
   pathID and MAC address that is being used in the general packet
   structure of Figure 7 to forward the packet to the destination.

   To reduce latency in further communication, the forwarding
   information is locally cached at the end device, while the cached
   information is being maintained through path updates sent by the NR
   in case of hosting end devices having moved or de-registered,
   therefore avoiding stale forwarding information.

6.2.2.  ICN API to Upper Layers

   The pub/sub operations of the ICN layer are exposed through the
   following API calls:

   o  conn = send(name, payload)

   o  send(conn, payload)

   o  conn = receive(name, &payload)

   o  receive(conn, &payload)

   The first send() call is used for initiating a send operation to a
   name with a connection handle returned, while the second send() is
   used for return calls, using a connection parameters that is being
   received with the receive() call to an incoming connection or for
   subsequence outgoing calls after an initial request to a name has
   been made.  A return send() is being received at the other (client)
   side through the second receive() call where the conn parameter is
   obtained by the corresponding send() call for the outgoing call.
   With these API functions, we provide means for providing name-based
   transactions with return responses association provided natively.



Ravindran, et al.       Expires September 7, 2019              [Page 29]


Internet-Draft                 ICN in 5GC                     March 2019


   The conn parameter represents the bitfield used for path-based
   forwarding in the remote host case or the hash of the local MAC
   address in case of link-local connections.

6.2.3.  HTTP over ICN

   To realize the flat device nature, Internet service layers, such as
   the HTTP protocol stack or the TCP protocol stack, will need to be
   adapted to run atop this new API, implementing the semantics of the
   respective Internet protocol through suitable transactions at the
   name level.  In the example of HTTP, the standard operations of DNS
   resolution for the server to be contacted and opening of a TCP socket
   are altogether replaced by a single send(FQDN, HTTP request) call,
   while the response will be sent by the server, which received the
   request through a receive(FQDN, &payload) call, using the returned
   conn parameter to send the response with the second send() API call.
   Note that the use of bidirectional pathIDs, no NR lookup is performed
   at the HTTP serving endpoint.

6.2.4.  Ad-Hoc Multicast for HTTP over ICN

   The basis of a named service transaction allows to deliver the same
   HTTP responses to several requestees in efficient multicast (see
   [I-D.purkayastha-bier-multicast-http-response] for use cases in a
   BIER-based transport network environment).

   This opportunity is realized by sending the same payload (i.e., an
   HTTP response to the same resource across a number of pending
   requests) through a combination of several conn parameters received
   in the incoming requests via the receive() function.

   What is required in the HTTP stack implementation is a logic to
   decide that two or more outstanding requests are possible to be
   served by one response.  For this, upon receiving an incoming
   request, the HTTP stack determines any outstanding request to the
   same resource.  'Same' here is defined as URI-specific combination of
   the request URI and URI-specific header fields, such as browsing
   agent or similar, called requestID in the following.

   Once such determination is made that two requests are relating to the
   same resource, i.e., are having the same request ID, the HTTP stack
   maintains a temporary mapping of the request ID to the respective
   conn parameters delivered by the receive() call.  Upon receiving the
   HTTP response from its application-level logic, the HTTP stack will
   generate the suitable send(conn, payload) call where the provided
   conn parameter is bitwise OR of all previously stored conn parameters
   received in the receive() call.  The ICN layer will recognize the use
   of those ad-hoc created conn parameters and set the destination MAC



Ravindran, et al.       Expires September 7, 2019              [Page 30]


Internet-Draft                 ICN in 5GC                     March 2019


   address in the general packet structure of Figure 8 to the Ethernet
   broadcast MAC address as the destination address, leading to sending
   the response to all end devices at the egress L2 forwarders to which
   the response will be forwarded based on the combined conn parameter.
   Alternatively, one could request IEEE assignment for a specific
   Ethernet multicast address for this scheme instead of using the
   broadcast address.  For the local end device to determine the
   relevance of the response received at the broadcast channel, the HTTP
   stack of the serving endpoint includes the aforementioned requestID
   into the payload of the packet (see Figure 8), while the originating
   endpoint maintains an internal table with the requestID of pending
   requests and its associated conn handle.  If no matching requestID is
   found, the packet is not being delivered to the NbR layer of the
   incoming device.  If a request is found, the ICN layer delivers the
   response via the receive() call, using the conn handle stored in the
   pending request table.  Note that this filtering mechanism can easily
   be implemented in hardware upon standardizing the appropriate payload
   and header fields.

6.2.5.  Service Proxy Operations

   The service proxy in Figure 8 serves the integration of legacy
   devices, i.e., with regular IP protocol stack, and the
   interconnection to IP-based peering networks.  It registers suitable
   identifiers with the NR to ensure the reception of (ICN-packets)
   packet, while providing suitable protocol termination for the various
   supported protocols.  For instance, for HTTP, the service proxy
   towards the peering network will register a wildcard name to the NR
   to receive any HTTP request not destined to a network-locally
   registered FQDN, operating as an HTTP proxy towards the peering
   network.

6.2.6.  ICN Flow Management

   EDITOR NOTE: left for future draft updates.

6.2.7.  NR Operations

   The NR in Figure 8 combines the operations of the SMF and the PMF in
   5GLAN (see Figure 6), by allowing for registering IP protocol
   identifiers for discovery and subsequent path computation by
   resolving the destination(s) to a suitable pathID and destination MAC
   address for forwarding.  This will require extensions to the
   operations of the SMF to allow for such higher layer identifiers to
   be registered (and discovered), in addition to the already supported
   Ethernet and IP addresses.





Ravindran, et al.       Expires September 7, 2019              [Page 31]


Internet-Draft                 ICN in 5GC                     March 2019


6.2.8.  Mobility Handling

   EDITOR NOTE: left for future draft updates.

6.2.9.  Dual Stack Device Support

   [I-D.suthar-icnrg-icn-lte-4g] outlines the possibility of supporting
   dual-stack devices for 4G LTE networks by allowing IP as well as ICN
   protocol stacks to be deployed with the operation of IP and ICN based
   applications.  For this, a convergence layer is described that
   selects the appropriate data path for each ICN or IP application,
   e.g., based on configuration per application (similar to selecting
   network interfaces such as WiFi over cellular).  An appropriate data
   path, as outlined in [I-D.suthar-icnrg-icn-lte-4g], can be the
   routing over IP or ICN.  As a possible datapath selection,
   [I-D.suthar-icnrg-icn-lte-4g] envisions the realization of IP-over-
   ICN (Section 4.2 in [I-D.suthar-icnrg-icn-lte-4g]) in which the
   convergence layer would realize similar mapping functions as
   described in this draft.  Hence, we foresee the utilization of such
   dual-stack devices connected to an IP-based services over ICN over
   5GLAN environment.  When utilizing the service proxy, IP applications
   that are configured to use the IP data path only could still utilize
   the ICN-based forwarding in the network.  In that case, functionality
   such as the opportunistic multicast in Section 6.2.4 would only reach
   up to the service proxy with unicast traffic continuing along the
   datapath towards the user equipment.

6.3.  ICN over 5GLAN

   EDITOR NOTE: left for future draft updates.

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 along with the user/control plane
   extensions required to handle ICN PDU sessions formally.  We then
   apply the proposed architecture to enabling IP-based services over an
   ICN network in the context of 5GLAN.

8.  IANA Considerations

   This document requests no IANA actions.






Ravindran, et al.       Expires September 7, 2019              [Page 32]


Internet-Draft                 ICN in 5GC                     March 2019


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

   [Guilio]   Grassi, G., Pesavento, D., Pau, G., Vayyuru, R., Wakikawa,
              Ryuji., Wakikawa, Ryuji., and Lixia. Zhang, "Vehicular
              Inter-Networking via Named Data", ACM Hot Mobile (Poster),
              2013.

   [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.muscariello-intarea-hicn]
              Muscariello, L., Carofiglio, G., Auge, J., and M.
              Papalini, "Hybrid Information-Centric Networking", draft-
              muscariello-intarea-hicn-01 (work in progress), December
              2018.

   [I-D.purkayastha-bier-multicast-http-response]
              Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert,
              "Applicability of BIER Multicast Overlay for Adaptive
              Streaming Services", draft-purkayastha-bier-multicast-
              http-response-01 (work in progress), October 2018.

   [I-D.rahman-icnrg-deployment-guidelines]
              Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
              "Deployment Considerations for Information-Centric
              Networking (ICN)", draft-rahman-icnrg-deployment-
              guidelines-05 (work in progress), January 2018.








Ravindran, et al.       Expires September 7, 2019              [Page 33]


Internet-Draft                 ICN in 5GC                     March 2019


   [I-D.suthar-icnrg-icn-lte-4g]
              suthar, P., Stolic, M., Jangam, A., and D. Trossen,
              "Native Deployment of ICN in LTE, 4G Mobile Networks",
              draft-suthar-icnrg-icn-lte-4g-04 (work in progress),
              November 2017.

   [I-D.white-icnrg-ipoc]
              White, G., Shannigrahi, S., and C. Fan, "Internet Protocol
              Tunneling over Content Centric Mobile Networks", draft-
              white-icnrg-ipoc-01 (work in progress), 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.

   [IEEE_Communications]
              Trossen, D. and G. Parisis, "Designing and Realizing an
              Information-Centric Internet", Information-Centric
              Networking, IEEE Communications Magazine Special Issue,
              2012.

   [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, et al.       Expires September 7, 2019              [Page 34]


Internet-Draft                 ICN in 5GC                     March 2019


   [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.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [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.

   [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.




Ravindran, et al.       Expires September 7, 2019              [Page 35]


Internet-Draft                 ICN in 5GC                     March 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
   Huawei Research Center
   2330 Central Expressway
   Santa Clara  95050
   USA

   Email: ravi.ravindran@huawei.com
   URI:   http://www.Huawei.com/


   Prakash Suthar
   Cisco Systems
   9501 Technology Blvd.
   Rosemont  50618
   USA

   Email: psuthar@cisco.com
   URI:   http://www.cisco.com/





Ravindran, et al.       Expires September 7, 2019              [Page 36]


Internet-Draft                 ICN in 5GC                     March 2019


   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
























Ravindran, et al.       Expires September 7, 2019              [Page 37]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/