ICNRG                                                       R. Ravindran
Internet-Draft                                                    Huawei
Intended status: Informational                                 P. Suthar
Expires: August 31, 2018                                           Cisco
                                                                 G. Wang
                                                              D. Trossen
                                                       InterDigital Inc.
                                                       February 27, 2018

          Enabling ICN in 3GPP's 5G NextGen Core Architecture


   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.  The value of enabling ICN in 5GC is discussed using
   multiple service scenarios in the context of mobile edge computing
   such as smart mobility and VR use case, and to enable network
   services such as seamless mobility for ICN sessions.

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 August 31, 2018.

Ravindran, et al.        Expires August 31, 2018                [Page 1]

Internet-Draft                 ICN in 5GC                  February 2018

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  5G NextGen Core Design Principles . . . . . . . . . . . . . .   5
   4.  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 . . . . . . . . . . . . . . . . .  15
   6.  5G/ICN Deployment Scenarios . . . . . . . . . . . . . . . . .  16
     6.1.  Smart Mobility  . . . . . . . . . . . . . . . . . . . . .  16
       6.1.1.  IP-MEC Scenario . . . . . . . . . . . . . . . . . . .  17
       6.1.2.  ICN-MEC Scenario  . . . . . . . . . . . . . . . . . .  17
       6.1.3.  IP-over-ICN MEC Scenario  . . . . . . . . . . . . . .  18
     6.2.  Multi-viewer Virtual Reality  . . . . . . . . . . . . . .  19
     6.3.  ICN Session Mobility  . . . . . . . . . . . . . . . . . .  19
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   11. Informative References  . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

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

Ravindran, et al.        Expires August 31, 2018                [Page 2]

Internet-Draft                 ICN in 5GC                  February 2018

   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).
   Following ICN features shall benefit MEC deployments in 5G:

   o  Edge Computing: Multi-access Edge Computing (MEC) is located at
      edge of network and aids several latency sensitive applications
      such as augmented and virtual reality (AR/VR) and 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

   o  Edge Storage and Caching : The principal entity for 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, where a set of users share the same
      content, thereby advantageous to both high-bandwidth and/or low-
      latency applications such as Video-on-Demand (VOD), AR/VR or low
      bandwidth IoT applications.

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

   To summarize the draft, we first discuss 5GC's design principals that
   allows the support of new network architectures.  Then we summarily

Ravindran, et al.        Expires August 31, 2018                [Page 3]

Internet-Draft                 ICN in 5GC                  February 2018

   discuss 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 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 [TS-5GNR].

      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

      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
      application etc.  UDM report subscriber related vital information
      e.g. virtual edge region, list of location visits, sessions active
      etc.  UDM work as subscriber anchor point that means OSS/BSS
      systems will have central monitoring/access of the system to get/
      set subscriber information.

      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): Perform session management
      functions for attached users equipment (UE) in 5G Core.  SMF can

Ravindran, et al.        Expires August 31, 2018                [Page 4]

Internet-Draft                 ICN in 5GC                  February 2018

      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

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

   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

Ravindran, et al.        Expires August 31, 2018                [Page 5]

Internet-Draft                 ICN in 5GC                  February 2018

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

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 August 31, 2018                [Page 6]

Internet-Draft                 ICN in 5GC                  February 2018

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

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

   o  Shared or slice specific control functions, which include the
      Authentication and Mobility Function (AMF), Session and Management
      Function (SMF) and the Application Function (AF).

Ravindran, et al.        Expires August 31, 2018                [Page 7]

Internet-Draft                 ICN in 5GC                  February 2018

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

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

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

   In the data plane, UE's PDUs are tunneled to the RAN using the 5G RAN
   protocol[TS-5GNR].  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 August 31, 2018                [Page 8]

Internet-Draft                 ICN in 5GC                  February 2018

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

Ravindran, et al.        Expires August 31, 2018                [Page 9]

Internet-Draft                 ICN in 5GC                  February 2018

   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 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 we
   elaborate in Section 5.2.2. 5G UE can also be non-mobile devices or
   an IOT device using radio specification which can operate based on

   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

Ravindran, et al.        Expires August 31, 2018               [Page 10]

Internet-Draft                 ICN in 5GC                  February 2018

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

Ravindran, et al.        Expires August 31, 2018               [Page 11]

Internet-Draft                 ICN in 5GC                  February 2018

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

Ravindran, et al.        Expires August 31, 2018               [Page 12]

Internet-Draft                 ICN in 5GC                  February 2018

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

   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

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

Ravindran, et al.        Expires August 31, 2018               [Page 13]

Internet-Draft                 ICN in 5GC                  February 2018

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

   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.

Ravindran, et al.        Expires August 31, 2018               [Page 14]

Internet-Draft                 ICN in 5GC                  February 2018

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:

   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

   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.  Alternately, 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

   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

Ravindran, et al.        Expires August 31, 2018               [Page 15]

Internet-Draft                 ICN in 5GC                  February 2018

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

6.  5G/ICN Deployment Scenarios

   Here we discuss two relevant network services enabled using ICN in

6.1.  Smart Mobility

   We consider here a radio edge service requiring low latency, high
   capacity and strict quality of service.  For the discussion in this
   draft, we analyze connected vehicle scenario, where the car's
   navigation system (CNS) uses data from the edge traffic monitoring
   (TM-E) service instance to offer rich and critical insights on the
   road conditions (such as real-time congestion assisted with media
   feeds).  This is aided using traffic sensing (TS) information
   collected through vehicle-to-vehicle (V2V) communication over
   dedicated short-range communications (DSRC) radio by the TS-E, or
   using road-side sensor units (RSU) from which this information can be
   obtained.  The TS-E instances then push this information to a central
   traffic sensing instance (TS-C).  This information is used by the

Ravindran, et al.        Expires August 31, 2018               [Page 16]

Internet-Draft                 ICN in 5GC                  February 2018

   central traffic monitoring service (TM-C) to generate useable
   navigation information, which can then be periodically pushed to or
   pulled by the edge traffic monitoring service (TM-E) to respond to
   requests from vehicle's CNS.  For this scenario, our objective is to
   compare advantages of offering this service over an IP based MEC
   versus one based on ICN.  We can generalize the following discussion
   to other MEC applications as well.

6.1.1.  IP-MEC Scenario

   Considering the above scenario, when a vehicle's networking system
   comes online, it first undergoes an attachment process with the 5G-
   RAN, which includes authentication, IP address assignment and DNS
   discovery.  The attachment process is followed by PDU session
   establishment, which is managed by SMF signaling to UL-CL and the UPF
   instance.  When the CNS application initializes, it assumes this IP
   address as its own ID and tries to discover the closest service
   instance.  Local DNS then resolves the service name to a local MEC
   service instance.  Accordingly, CNS learns the IP service point
   address and uses that to coordinate between traffic sensing and
   monitoring applications.

   CNS is a mission critical application requiring instant actions which
   is accurate and reliable all the time.  Delay of microsecond or non-
   response could result in fatalities.  Following are main challenges
   with the IP-MEC design:

   o  At the CNS level, non-standardization of the naming schema results
      in introducing an application level gateway to adapt the sensing
      data obtained from DSRC system to IP networks, which becomes
      mandatory if the applications are from different vendors.

   o  As the mobility results in handover between RAN instances,
      service-level or 5GC networking-level mechanisms need to be
      initiated to discover a better TM-E instance, which may affect the
      service continuity and result in session reestablishment that
      introduces additional control/user plane overheads.

   o  Data confidentiality among multiple CNS attached 5G RAN,
      authentication and privacy control are offered through an SSL/TLS
      mechanism over the transport channel, which has to be re-
      established whenever the network layer attributes are reset.

6.1.2.  ICN-MEC Scenario

   If the CNS application is developed over ICN either natively or as an
   overlay over IP, ICN shall allows the same named data logic to
   operate over heterogeneous interfaces (such as DSRC radio, and IP

Ravindran, et al.        Expires August 31, 2018               [Page 17]

Internet-Draft                 ICN in 5GC                  February 2018

   transport-over-5G, unlicensed radio over WiFi etc. link), thereby
   avoiding the need for application layer adaptations.

   We can list the advantages of using ICN-based MEC as follows:

   o  Compared to IP, ICN is unique in supporting both infrastructure
      and ad hoc communication.  This makes it suitable to support
      communication in vehicular ad hoc networks (VANETS) [Guilio],
      along with communication to the infrastructure components like the
      road side units to serve the needs of several smart mobility
      applications.  ICN's name based APIs enables it to operate over
      multiple heterogeneous radio interfaces simultaneously in
      broadcast, unicast or anycast modes of communication that can be
      taken advantage of in a given context.

   o  As vehicles within a single road segment are likely to seek the
      same data, ICN-based MEC allows to leverage opportunistic caching
      and storage enabled at ICN-GW, thereby avoiding service level
      unicast transmissions.

   o  Processed and stored traffic data can be easily contextualized to
      different user requirements.

   o  Appropriate mobility handling functions can be used depending on
      mobility type (as consumer or producer), specifically, when an
      ICN-UE moves from one RAN instance to another, the next IP hop,
      which identifies the ICN-GW function, has to be re-discovered.
      Unlike the IP-MEC scenario, this association is not exposed to the
      applications.  As discussed earlier, control plane extensions to
      AMF and SMF can enable re-programmability of the ICN layer in the
      vehicle to direct it towards a new ICN-GW, or to remain with the
      same ICN-GW, based on optimization requirements.

   o  As ICN offers content-based security, produced content can be
      consumed while authenticating it at the same time (i.e., allowing
      any data produced to diffuse to its point of use through named
      data networking).

6.1.3.  IP-over-ICN MEC Scenario

   The above application can also be realized in the context of an IP-
   over-ICN deployment scenario discussed in Section 5.2.  In this case,
   we assume the operation of the IP-based MEC application over the ICN
   bearer.  The ICN-based methods being used for service registration
   ensure that routing of CNS service requests reach the 'nearest'
   service instance (near in topological distance), while utilizing path
   updates at the CNS endpoint to handle mobility of the vehicle.  If
   assuming HTTP-level (or similar CoAP-level) access to the sensing

Ravindran, et al.        Expires August 31, 2018               [Page 18]

Internet-Draft                 ICN in 5GC                  February 2018

   data, the same TM-E instance can return a single Layer 2 level
   multicast (assuming a SDN-based L2 sub-system) response to all CNS of
   passing car that have been requesting the sensing data within a
   configurable time interval.  The ICN-based registration of the TM-E
   service also allows for secure content delegation being implemented
   where secured content is being diffused to in-network caching points
   while the original HTTP/CoAP-level sensing request is directed to the
   secure content server rather than the origin server, avoiding
   inefficient triangular routing when doing so.

6.2.  Multi-viewer Virtual Reality

   VR services are nowadays implemented as HTTP-based file chunk
   retrieval systems where the file chunk is determined by the viewing
   angle of the VR headset.  Hence, within the same content scenario,
   consumers exhibiting the same viewing angle relative to the content
   will exhibit the same access patterns towards the content storage.
   Nonetheless, IP-based delivery of the VR service will result in
   separate HTTP unicast sessions being established to each VR headset.
   When running instead the headset in IP-over-ICN mode (with a dual-
   stack realization or a single stack UE with the convergence layer as
   outlined in [I-D.suthar-icnrg-icn-lte-4g], we can now utilize the
   multicast capabilities of the underlying ICN system to deliver any
   access to the same file chunk as a multicast message from the content
   storage to the individual headset UEs using L2 multicast.  When
   viewing angles diverge among headsets, the degree of overlap will do
   the same and the multicast efficiency will change accordingly albeit
   in an ad-hoc, instantaneous manner, i.e., not requiring any
   reconfiguration of underlying transport resources (such as multicast
   groups).  Such multi-viewer VR capability can be utilized in a number
   of use cases, such as for events at specific site, e.g., stadiums, in
   an MEC-like deployment.  Other use cases could foresee utilizing such
   capability for remote education scenarios from a single VR server,
   e.g., provisioned by a school, towards a class of students located at
   5G-connected homes or premises This capability of improving on
   existing HTTP-based VR services via such convergence layer based IP-
   over-ICN mechanisms has been successfully demonstrated at trade-shows
   in 2017.

6.3.  ICN Session Mobility

   Mobility scenario assumes a general ICN-UE handover from S-RAN to
   T-RAN, where each of them is served by different UPFs, i.e., UL-CL-1
   and UL-CL-2.  We also assume that UL-CL-1 and UL-CL-2 use different
   gateways, referred to as ICN-GW-1 and ICN-GW-2.  From an ICN
   perspective, we discuss here the producer mobility case, which can be
   handled in multiple ways, one of which is proposed in
   [ICNMOB].However, the details of the ICN mobility solution are

Ravindran, et al.        Expires August 31, 2018               [Page 19]

Internet-Draft                 ICN in 5GC                  February 2018

   orthogonal to this discussion.  Here, ICN-UE refers to an application
   producer (e.g., video conferencing application, from which ICN
   consumers request real-time content.  Here we also assume the absence
   of any direct physical interface, Xn, between the two RANs.  The
   current scenario follows the handover procedures discussed in
   [TS23.502], with focus here on integrating it with an ICN-GW and ICN-
   DN, where mobility state of the ICN sessions are handled.

   The overall signaling overhead to handle seamless mobility also
   depends on the deployment models discussed in Section 4.  Here we
   consider the case when RAN, UL-CL and ICN-GW are physically disjoint;
   however in the case where RAN and UL-CL are co-located then a part of
   the signaling to manage the tunnel state between the RAN and UL-CL is
   localized, which then improves the overall signaling efficiency.
   This can be further extended to the case when ICN-GWs are co-located
   with the RAN and UL-CL, leading to further simplification of the
   mobility signaling.

   Next, we discuss the high-level steps involved during handover.

   o  Step 1: When the ICN-UE decides to handover from S-RAN to T-RAN,
      ICN-UE signals the S-RAN with a handover-request indicating the
      new T-RAN it is willing to connect.  This message includes the
      affected PDU session IDs from the 5GC perspective, along with the
      ICN names that require mobility support.

   o  Step 2: S-RAN then signals the AMF serving the ICN-UE about the
      handover request.  The request includes the T-RAN details, along
      with the affected ICN PDU sessions.

   o  Step 3: Here, when SMF receives the ICN-UE's and the T-RAN
      information, it identifies UL-CL-2 as the better candidate to
      handle the ICN PDU sessions to T-RAN.  In addition, it also
      identifies ICN-GW-2 as the appropriate gateway for the affected
      ICN PDU sessions.

   o  Step 4: SMF signals the details of the affected PDU sessions along
      with the traffic filter rules to switch the UL traffic from UL-
      CL-2 to ICN-GW-2 and DL flows from UL-CL-2 to T-RAN.

   o  Step 5: SMF then signals ICN-SMF about the PDU session mobility
      change along with the information on UL-CL-2 for it to provision
      the tunnel between ICN-GW-2 and UL-CL-2.

   o  Step 6: Based on the signaling received on the ICN PDU session,
      ICN-SMF identifies the affected gateways, i.e., ICN-GW-1 and ICN-
      GW-2: (i) ICN-SMF signals ICN-GW-2 about the affected PDU session
      information to update its DL tunnel information to UL-CL-2.  Then,

Ravindran, et al.        Expires August 31, 2018               [Page 20]

Internet-Draft                 ICN in 5GC                  February 2018

      based on the ICN mobility solution, appropriate ICN mobility state
      to switch the future incoming Interests from ICN-GW-1 to UL-CL-2;
      (ii) ICN-SMF also signals ICN-GW-1 with the new forwarding
      label[ICNMOB] to forward the incoming Interest traffic to ICN-GW-
      2.  This immediately causes the new Interest payload for the ICN-
      UE to be send to the new ICN gateway in a proactive manner.

   o  Step 7: ICN-SMF then acknowledges SMF about the successful
      mobility update.  Upon this, the SMF then acknowledges AMF about
      the state changes related to mobility request along with the
      tunnel information that is required to inter-connect T-RAN with

   o  Step 8: AMF then updates the T-RAN PDU session state in order to
      tunnel ICN-UE's PDU sessions from T-RAN to UL-CL-2.  This is
      followed by initiating the RAN resource management functions to
      reserve appropriate resources to handle the new PDU session
      traffic from the ICN-UE.

   o  Step 9: AMF then signals the handover-ack message to the UE,
      signaling it to handover to the T-RAN.

   o  Step 10: UE then issues a handover-confirm message to T-RAN.  At
      this point, all the states along the new path comprising the
      T-RAN, UL-CL-2 and ICN-GW-2 is set to handle UL-DL traffic between
      the ICN-UE and the ICN-DN.

   o  Step 11: T-RAN then signals the AMF on its successful connection
      to the ICN-UE.  AMF then signals S-RAN to remove the allocated
      resources to the PDU session from the RAN and the tunnel state
      between S-RAN and UL-CL-1.

   o  Step 12: AMF then signals SMF about the successful handover, upon
      which SMF removes the tunnel states from UL-CL-1.  SMF then
      signals the ICN-SMF, which then removes the ICN mobility state
      related to the PDU session from ICN-GW-1.  Also at this point,
      ICN-SMF can signal the ICN-NRS (directly or through ICN-GW-2) to
      update the UE-ID resolution information, which now points to ICN-
      GW-2 [ICNMOB].

   Note that, inter-RAN handover mapping to the same UL-CL represents a
   special case of the above scenario.

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

Ravindran, et al.        Expires August 31, 2018               [Page 21]

Internet-Draft                 ICN in 5GC                  February 2018

   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 two relevant services that ICN
   networks can enable: first, mobile edge computing over ICN versus the
   traditional IP approach considering a connected car scenario, and
   argue based on architectural benefits; second, handling ICN PDU
   session mobility in ICN-DN rather than using IP anchor points, with
   minimal support from 5GC.

8.  IANA Considerations

   This document requests no IANA actions.

9.  Security Considerations

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

10.  Acknowledgments


11.  Informative References

   [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),

              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.

              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.

Ravindran, et al.        Expires August 31, 2018               [Page 22]

Internet-Draft                 ICN in 5GC                  February 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,

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

              Jacobson, V. and et al., "Networking Named Content",
              Proceedings of ACM Context, , 2009.

              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.

              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.

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

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

   [TS-5GNR]  3GPP-38-xxx, "Technical Specification series on 5G-NR
              (Rel.15)", 3GPP , 2017.

              3gpp-23.501, "Technical Specification Group Services and
              System Aspects; System Architecture for the 5G System
              (Rel.15)", 3GPP , 2017.

Ravindran, et al.        Expires August 31, 2018               [Page 23]

Internet-Draft                 ICN in 5GC                  February 2018

              3gpp-23.502, "Technical Specification Group Services and
              System Aspects; Procedures for the 5G System(Rel. 15)",
              3GPP , 2017.

              3gpp-23.799, "3rd Generation Partnership Project;
              Technical Specification Group Services and System Aspects;
              Study on Architecture for Next Generation System (Rel.
              14)", 3GPP , 2017.

              3gpp-33.899, "Study on the security aspects of the next
              generation system", 3GPP , 2017.

   [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

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

   Prakash Suthar
   Cisco Systems
   9501 Technology Blvd.
   Rosemont  50618

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

Ravindran, et al.        Expires August 31, 2018               [Page 24]

Internet-Draft                 ICN in 5GC                  February 2018

   Guoqiang Wang
   Huawei Research Center
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: gq.wang@huawei.com

   Dirk Trossen
   InterDigital Inc.
   64 Great Eastern Street, 1st Floor
   London  EC2A 3QR
   United Kingdom

   Email: Dirk.Trossen@InterDigital.com
   URI:   http://www.InterDigital.com/

Ravindran, et al.        Expires August 31, 2018               [Page 25]