rfc9269.original   rfc9269.txt 
ICN Research Group Prakash Suthar Internet Research Task Force (IRTF) P. Suthar
Internet-Draft Google Inc. Request for Comments: 9269 Google Inc.
Intended status: Experimental Milan Stolic Category: Informational M. Stolic
Expires: 22 September 2022 Anil Jangam, Ed. ISSN: 2070-1721 A. Jangam, Ed.
Cisco Systems Inc. Cisco Systems Inc.
Dirk Trossen D. Trossen
Huawei Technologies Huawei Technologies
Ravi Ravindran R. Ravindran
F5 Networks F5 Networks
21 March 2022 August 2022
Experimental Scenarios of ICN Integration in 4G Mobile Networks Experimental Scenarios of Information-Centric Networking (ICN)
draft-irtf-icnrg-icn-lte-4g-12 Integration in 4G Mobile Networks
Abstract Abstract
4G mobile network uses IP-based transport for the control plane to A 4G mobile network uses IP-based transport for the control plane to
establish the data session at the user plane for the actual data establish the data session at the user plane for the actual data
delivery. In the existing architecture, IP-based unicast is used for delivery. In the existing architecture, IP-based unicast is used for
the delivery of multimedia content to a mobile terminal, where each the delivery of multimedia content to a mobile terminal, where each
user is receiving a separate stream from the server. From a user is receiving a separate stream from the server. From a
bandwidth and routing perspective, this approach is inefficient. bandwidth and routing perspective, this approach is inefficient.
Evolved multimedia broadcast and multicast service (eMBMS) provides Evolved multimedia broadcast and multicast service (eMBMS) provides
capabilities for delivering contents to multiple users capabilities for delivering contents to multiple users
simultaneously, but its deployment is very limited or at an simultaneously, but its deployment is very limited or at an
experimental stage due to numerous challenges. The focus of this experimental stage due to numerous challenges. The focus of this
draft is to list the options for use of Information centric document is to list the options for using Information-Centric
technology (ICN) in 4G mobile networks and elaborate the experimental Networking (ICN) in 4G mobile networks and elaborate the experimental
setups for its further evaluation. The experimental setups discussed setups for its further evaluation. The experimental setups discussed
provide for using ICN either natively or with existing mobility provide guidance for using ICN either natively or with an existing
protocol stack. With further investigations based on the listed mobility protocol stack. With further investigations based on the
experiments, ICN with its inherent capabilities such as, network- listed experiments, ICN with its inherent capabilities such as
layer multicast, anchorless mobility, security, and optimized data network-layer multicast, anchorless mobility, security, and optimized
delivery using local caching at the edge may provide a viable data delivery using local caching at the edge may provide a viable
alternative to IP transport in 4G mobile networks. alternative to IP transport in 4G mobile networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Information-
Centric Networking Research Group of the Internet Research Task Force
(IRTF). Documents approved for publication by the IRSG are not
candidates for any level of Internet Standard; see Section 2 of RFC
7841.
This Internet-Draft will expire on 22 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9269.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 3 2. 3GPP Terminology and Concepts
3. 4G Mobile Network Architecture . . . . . . . . . . . . . . . 7 3. 4G Mobile Network Architecture
3.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Network Overview
3.2. Mobile Network Quality of Service . . . . . . . . . . . . 9 3.2. Mobile Network Quality of Service
3.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10 3.3. Data Transport Using IP
3.4. Virtualized Mobile Networks . . . . . . . . . . . . . . . 11 3.4. Virtualized Mobile Networks
4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11 4. Data Transport Using ICN
5. Experimental Scenarios for ICN Deployment . . . . . . . . . . 14 5. Experimental Scenarios for ICN Deployment
5.1. General Considerations . . . . . . . . . . . . . . . . . 14 5.1. General Considerations
5.2. Scenarios of ICN Integration . . . . . . . . . . . . . . 15 5.2. Scenarios of ICN Integration
5.3. Integration of ICN in 4G Control Plane . . . . . . . . . 18 5.3. Integration of ICN in 4G Control Plane
5.4. Integration of ICN in 4G User Plane . . . . . . . . . . . 20 5.4. Integration of ICN in 4G User Plane
5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal . . . 20 5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal
5.4.2. Using ICN in Mobile Terminal . . . . . . . . . . . . 24 5.4.2. Using ICN in Mobile Terminal
5.4.3. Using ICN in eNodeB . . . . . . . . . . . . . . . . . 25 5.4.3. Using ICN in eNodeB
5.4.4. Using ICN in Packet Core (SGW, PGW) Gateways . . . . 27 5.4.4. Using ICN in Packet Core Gateways (SGW/PGW)
5.5. An Experimental Test Setup . . . . . . . . . . . . . . . 29 5.5. An Experimental Test Setup
6. Expected Outcomes from Experimentation . . . . . . . . . . . 30 6. Expected Outcomes from Experimentation
6.1. Feeding into ICN Research . . . . . . . . . . . . . . . . 30 6.1. Feeding into ICN Research
6.2. Use of Results Beyond Research . . . . . . . . . . . . . 31 6.2. Use of Results Beyond Research
7. Security and Privacy Considerations . . . . . . . . . . . . . 31 7. IANA Considerations
7.1. Security Considerations . . . . . . . . . . . . . . . . . 32 8. Security and Privacy Considerations
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 33 8.1. Security Considerations
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Privacy Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 9. Summary
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 36 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 37 10.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
4G mobile technology is built as an all-IP network using routing 4G mobile technology is built as an all-IP network using routing
protocols (OSPF, ISIS, BGP, etc.) to establish network routes. protocols (OSPF, IS-IS, BGP, etc.) to establish network routes. The
Stickiness of an IP address to a device is the key to get connected stickiness of an IP address to a device is the key to getting
to a mobile network. The same IP address is maintained through the connected to a mobile network. The same IP address is maintained
session until the device gets detached or moves to another network. through the session until the device gets detached or moves to
another network.
Key protocols used in 4G networks are GPRS Tunneling protocol (GTP), Key protocols used in 4G networks are the General Packet Radio
DIAMETER, and other protocols that are built on top of IP. One of Service Tunneling Protocol (GTP), DIAMETER, and other protocols that
the biggest challenges with IP-based routing in 4G is that it is not are built on top of IP. One of the biggest challenges with IP-based
optimized for data transport. As an alternative to IP routing, this routing in 4G is that it is not optimized for data transport. As an
draft presents and list the possible options for integration of alternative to IP routing, this document presents and lists the
Information Centric Networking (ICN) in 3GPP 4G mobile network, possible options for integration of Information-Centric Networking
offering an opportunity to leverage inherent ICN capabilities such as (ICN) in 3GPP 4G mobile networks, offering an opportunity to leverage
in-network caching, multicast, anchorless mobility management, and inherent ICN capabilities such as in-network caching, multicast,
authentication. This draft also discuss how those options affect anchorless mobility management, and authentication. This document
mobile providers and end users. also discusses how those options affect mobile providers and end
users.
The goal of the proposed experiments is to present possibilities to The goal of the proposed experiments is to present possibilities to
create simulated environments for evaluation of the benefits of ICN create simulated environments for evaluation of the benefits of ICN
protocol deployment in a 4G mobile network in different scenarios protocol deployment in a 4G mobile network in different scenarios
that have been analyzed in this document. The consensus of the that have been analyzed in this document. The consensus of the
Information-Centric Networking Research Group (ICNRG) is to publish Information-Centric Networking Research Group (ICNRG) is to publish
this document in order to facilitate experiments to show deployment this document in order to facilitate experiments to show deployment
options and qualitative and quantitative benefits of ICN protocol options and qualitative and quantitative benefits of ICN protocol
deployment in 4G mobile networks. deployment in 4G mobile networks.
2. 3GPP Terminology and Concepts 2. 3GPP Terminology and Concepts
1. Access Point Name Access Point Name: The Access Point Name (APN) is a Fully Qualified
Domain Name (FQDN) and resolves to a set of gateways in an
The Access Point Name (APN) is a Fully Qualified Domain Name operator's network. An APN identifies the packet data network
(FQDN) and resolves to a set of gateways in an operator's (PDN) with which a mobile data user wants to communicate. In
network. APN identifies the packet data network (PDN) with addition to identifying a PDN, an APN may also be used to define
which a mobile data user wants to communicate. In addition to the type of service, QoS, and other logical entities inside a
identifying a PDN, an APN may also be used to define the type of Gateway General Packet Radio Service Support Node (GGSN) or a
service, QoS, and other logical entities inside GGSN, PGW. Packet Data Network Gateway (PGW).
2. Control Plane
The control plane carries signaling traffic and is responsible
for routing between eNodeB and MME, MME and HSS, MME and SGW,
SGW and PGW, etc. Control plane signaling is required to
authenticate and authorize the mobile terminal and establish a
mobility session with mobile gateways (SGW/PGW). Control plane
functions also include system configuration and management.
3. Dual Address PDN/PDP Type
The dual address Packet Data Network/Packet Data Protocol (PDN/
PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a
synonym for dual stack, i.e., a connection type capable of
serving IPv4 and IPv6 simultaneously.
4. eNodeB
The eNodeB is a base station entity that supports the Long-Term
Evolution (LTE) air interface.
5. Evolved Packet Core
The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS
system characterized by a higher-data-rate, lower-latency,
packet-optimized system. The EPC comprises some sub components
of the EPS core such as Mobility Management Entity (MME),
Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and
Home Subscriber Server (HSS).
6. Evolved Packet System
The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS
system characterized by a higher-data-rate, lower-latency,
packet-optimized system that supports multiple Radio Access
Technologies (RATs). The EPS comprises the EPC together with
the Evolved Universal Terrestrial Radio Access (E-UTRA) and the
Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
7. Evolved UTRAN
The E-UTRAN is a communications network sometimes referred to as
4G, and consists of eNodeB (4G base stations). The E-UTRAN
allows connectivity between the User Equipment and the core
network.
8. GPRS Tunneling Protocol
The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274]
[TS29.281] is a tunneling protocol defined by 3GPP. It is a
network-based mobility protocol, working similar to Proxy Mobile
IPv6 (PMIPv6). However, GTP also provides functionality beyond
mobility, such as in-band signaling related to QoS and charging,
among others.
9. Gateway GPRS Support Node
The Gateway GPRS Support Node (GGSN) is a gateway function in
the GPRS and 3G network that provides connectivity to the
Internet or other PDNs. The host attaches to a GGSN identified
by an APN assigned to it by an operator. The GGSN also serves
as the topological anchor for addresses/prefixes assigned to the
User Equipment.
10. General Packet Radio Service
The General Packet Radio Service (GPRS) is a packet-oriented
mobile data service available to users of the 2G and 3G cellular
communication systems--the GSM--specified by 3GPP.
11. Home Subscriber Server
The Home Subscriber Server (HSS) is a database for a given Control Plane: The control plane carries signaling traffic and is
subscriber and was introduced in 3GPP Release-5. It is the responsible for routing between the eNodeB and the Mobile
entity containing subscription-related information to support Management Entity (MME), the MME and the Home Subscriber Server
the network entities that handle calls/sessions. (HSS), the MME and the Mobile Gateways (SGW/PGW), etc. Control
plane signaling is required to authenticate and authorize the
mobile terminal and establish a mobility session with Mobile
Gateways (SGW/PGW). Control plane functions also include system
configuration and management.
12. Mobility Management Entity Dual Address PDN/PDP Type: The dual address Packet Data Network /
Packet Data Protocol (PDN/PDP) Type (IPv4v6) is used in 3GPP
context, in many cases as a synonym for dual stack, i.e., a
connection type capable of serving IPv4 and IPv6 simultaneously.
The Mobility Management Entity (MME) is a network element eNodeB: The eNodeB is a base station entity that supports the Long
responsible for control plane functionalities, including Term Evolution (LTE) air interface.
authentication, authorization, bearer management, layer-2
mobility, and so on. The MME is essentially the control plane
part of the SGSN in the GPRS. The user plane traffic bypasses
the MME.
13. Public Land Mobile Network Evolved Packet Core: The Evolved Packet Core (EPC) is an evolution
of the 3GPP GPRS system characterized by a higher-data-rate,
lower-latency, packet-optimized system. The EPC comprises some
subcomponents of the EPS core such as MME, Mobile Gateways (SGW/
PGW), and HSS.
The Public Land Mobile Network (PLMN) is a network operated by a Evolved Packet System: The Evolved Packet System (EPS) is an
single administration. A PLMN (and, therefore, also an evolution of the 3GPP GPRS system characterized by a higher-data-
operator) is identified by the Mobile Country Code (MCC) and the rate, lower-latency, packet-optimized system that supports
Mobile Network Code (MNC). Each (telecommunications) operator multiple Radio Access Technologies (RATs). The EPS comprises the
providing mobile services has its own PLMN. EPC together with Evolved Universal Terrestrial Radio Access
(E-UTRA) and the Evolved Universal Terrestrial Radio Access
Network (E-UTRAN).
14. Policy and Charging Control Evolved UTRAN: The Evolved UTRAN (E-UTRAN) is a communications
The Policy and Charging Control (PCC) framework is used for QoS network sometimes referred to as 4G, and it consists of an eNodeB
policy and charging control. It has two main functions: flow- (4G base stations). The E-UTRAN allows connectivity between the
based charging (including online credit control), and policy User Equipment and the core network.
control (for example, gating control, QoS control, and QoS
signaling). It is optional to 3GPP EPS but needed if dynamic
policy and charging control by means of PCC rules based on user
and services are desired.
15. Packet Data Network Gateway GPRS Support Node: The Gateway GPRS Support Node (GGSN) is a
gateway function in the GPRS and 3G network that provides
connectivity to the Internet or other PDNs. The host attaches to
a GGSN identified by an APN that is assigned to it by an operator.
The GGSN also serves as the topological anchor for addresses/
prefixes assigned to the User Equipment.
The Packet Data Network (PDN) is a packet-based network that General Packet Radio Service: The General Packet Radio Service
either belongs to the operator or is an external network such as (GPRS) is a packet-oriented mobile data service available to users
the Internet or a corporate intranet. The user eventually of the 2G and 3G cellular communication systems (the GSM)
accesses services in one or more PDNs. The operator's packet specified by 3GPP.
core networks are separated from packet data networks either by
GGSNs or PDN Gateways (PGWs).
16. Serving Gateway GPRS Tunneling Protocol: The GPRS Tunneling Protocol (GTP)
[TS29.060] [TS29.274] [TS29.281] is a tunneling protocol defined
by 3GPP. It is a network-based mobility protocol that works
similarly to Proxy Mobile IPv6 (PMIPv6). However, GTP also
provides functionality beyond mobility, such as in-band signaling
related to QoS and charging, among others.
The Serving Gateway (SGW) is a gateway function in the EPS, Home Subscriber Server: The Home Subscriber Server (HSS) [TS29.336]
which terminates the interface towards the E-UTRAN. The SGW is is a database for a given subscriber and was introduced in 3GPP
the Mobility Anchor point for layer-2 mobility (inter-eNodeB Release 5. It is the entity containing subscription-related
handovers). For each mobile terminal connected with the EPS, information to support the network entities that handle calls/
there is only one SGW at any given point in time. The SGW is sessions.
essentially the user plane part of the GPRS's SGSN.
17. Packet Data Network Gateway Mobile Terminal/User Equipment: The terms User Equipment (UE),
Mobile Station (MS), Mobile Node (MN), and mobile refer to the
devices that are hosts with the ability to obtain Internet
connectivity via a 3GPP network. An MS comprises the Terminal
Equipment (TE) and an MT. The terms MT, MS, MN, and mobile are
used interchangeably within this document.
The Packet Data Network Gateway (PGW) is a gateway function in Mobility Management Entity: The Mobility Management Entity (MME) is
the Evolved Packet System (EPS), which provides connectivity to a network element responsible for control plane functionalities,
the Internet or other PDNs. The host attaches to a PGW including authentication, authorization, bearer management, Layer
identified by an APN assigned to it by an operator. The PGW 2 mobility, and so on. The MME is essentially the control plane
also serves as the topological anchor for addresses/prefixes part of the SGSN in the GPRS. The user-plane traffic bypasses the
assigned to the User Equipment. MME.
18. Packet Data Protocol Context Packet Data Network: The Packet Data Network (PDN) is a packet-based
network that either belongs to the operator or is an external
network such as the Internet or a corporate intranet. The user
eventually accesses services in one or more PDNs. The operator's
packet core networks are separated from packet data networks by
either GGSNs or PGWs.
A Packet Data Protocol (PDP) context is the equivalent of a Packet Data Network Gateway: The Packet Data Network Gateway (PGW)
virtual connection between the mobile terminal (MT) and a PDN is a gateway function in the EPS, which provides connectivity to
using a specific gateway. the Internet or other PDNs. The host attaches to a PGW identified
by an APN that is assigned to it by an operator. The PGW also
serves as the topological anchor for addresses/prefixes assigned
to the User Equipment.
19. Packet Data Protocol Type Packet Data Protocol Context: A Packet Data Protocol (PDP) context
is the equivalent of a virtual connection between the mobile
terminal (MT) and a PDN using a specific gateway.
A Packet Data Protocol Type (PDP Type) identifies the used/ Packet Data Protocol Type: A Packet Data Protocol Type (PDP Type)
allowed protocols within the PDP context. Examples are IPv4, identifies the used/allowed protocols within the PDP context.
IPv6, and IPv4v6 (dual-stack). Examples are IPv4, IPv6, and IPv4v6 (dual stack).
20. Serving GPRS Support Node Policy and Charging Control: The Policy and Charging Control (PCC)
The Serving GPRS Support Node (SGSN) is a network element framework is used for QoS policy and charging control. It has two
located between the radio access network (RAN) and the gateway main functions: flow-based charging (including online credit
(GGSN). A per-MT point-to-point (p2p) tunnel between the GGSN control) and policy control (for example, gating control, QoS
and SGSN transports the packets between the mobile terminal and control, and QoS signaling). It is optional to 3GPP EPS but
the gateway. needed if dynamic policy and charging control by means of PCC
rules based on user and services are desired.
21. Mobile Terminal/User Equipment Public Land Mobile Network: The Public Land Mobile Network (PLMN) is
a network operated by a single administration. A PLMN (and
therefore also an operator) is identified by the Mobile Country
Code (MCC) and the Mobile Network Code (MNC). Each
(telecommunications) operator providing mobile services has its
own PLMN.
The terms User Equipment (UE), Mobile Station (MS), Mobile Node Serving Gateway: The Serving Gateway (SGW) is a gateway function in
(MN), and mobile refer to the devices that are hosts with the the EPS, which terminates the interface towards the E-UTRAN. The
ability to obtain Internet connectivity via a 3GPP network. An SGW is the Mobility Anchor point for Layer 2 mobility (inter-
MS comprises the Terminal Equipment (TE) and a Mobile Terminal eNodeB handovers). For each mobile terminal connected with the
(MT). The terms MT, MS, MN, and mobile are used interchangeably EPS, there is only one SGW at any given point in time. The SGW is
within this document. essentially the user-plane part of the GPRS's SGSN.
22. User Plane Serving GPRS Support Node: The Serving GPRS Support Node (SGSN) is a
network element located between the Radio Access Network (RAN) and
the gateway (GGSN). A per-MT point-to-point (P2P) tunnel between
the GGSN and SGSN transports the packets between the mobile
terminal and the gateway.
The user plane refers to data traffic and the required bearers User Plane: The user plane refers to data traffic and the required
for the data traffic. In practice, IP is the only data traffic bearers for the data traffic. In practice, IP is the only data
protocol used in the user plane. traffic protocol used in the user plane.
3. 4G Mobile Network Architecture 3. 4G Mobile Network Architecture
This section provide a high-level overview of typical 4G mobile This section provides a high-level overview of typical 4G mobile
network architecture and their key functions related to a possibility network architecture and the key functions related to the possibility
of using of ICN technology. of its use with ICN technology.
3.1. Network Overview 3.1. Network Overview
4G mobile networks are designed to use IP transport for communication 4G mobile networks are designed to use IP transport for communication
among different elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, among different elements such as the eNodeB, MME, SGW, PGW, HSS,
etc. [GRAYSON]. For backward compatibility with 3G, it has support Policy and Charging Rule Function (PCRF), etc. [GRAYSON]. For
for legacy Circuit Switch features such as voice and SMS through backward compatibility with 3G, it has support for legacy circuit
transitional CS fallback and flexible IMS deployment. For each switch features such as voice and SMS through transitional CS
mobile device attached to the radio (eNodeB), there is a separate fallback and flexible IP Multimedia Subsystems (IMS) deployment. For
overlay tunnel (GPRS Tunneling Protocol, GTP) between eNodeB and each mobile device attached to the radio (eNodeB), there is a
Mobile gateways (i.e., SGW, PGW). separate overlay tunnel (GTP) between the eNodeB and Mobile Gateways
(i.e., SGW/PGW).
When any mobile terminal is powered up, it attaches to a mobile When any mobile terminal is powered up, it attaches to a mobile
network based on its configuration and subscription. After a network based on its configuration and subscription. After a
successful attachment procedure, the mobile terminal registers with successful attachment procedure, the mobile terminal registers with
the mobile core network using IPv4 and/or IPv6 address based on the mobile core network using IPv4 and/or IPv6 addresses based on
request and capabilities offered by mobile gateways. request and capabilities offered by Mobile Gateways.
The GTP tunnel is used to carry user traffic between gateways and The GTP tunnel is used to carry user traffic between gateways and
mobile terminal, therefore using the unicast delivery for any data mobile terminals, therefore using the unicast delivery for any data
transfer. It is also important to understand the overhead of GTP and transfer. It is also important to understand the overhead of GTP and
IPSec protocols. All mobile backhaul traffic is encapsulated using a IPsec protocols. All mobile backhaul traffic is encapsulated using a
GTP tunnel, which has overhead of 8 bytes on top of IP and UDP GTP tunnel, which has overhead of 8 bytes on top of IP and UDP
[NGMN]. Additionally, if IPSec is used for security (which is often [NGMN]. Additionally, if IPsec is used for security (which is often
required if the Service Provider is using a shared backhaul), it adds required if the Service Provider is using a shared backhaul), it adds
overhead based on the IPSec tunneling model (tunnel or transport) as overhead based on the IPsec tunneling model (tunnel or transport) as
well as the encryption and authentication header algorithm used. If well as the encryption and authentication header algorithm used. If
we consider as an example an Advanced Encryption Standard (AES) we consider an Advanced Encryption Standard (AES) encryption as an
encryption, the overhead can be significant [OLTEANU], particularly example, the overhead can be significant [OLTEANU], particularly for
for smaller payloads. smaller payloads.
+-------+ Diameter +-------+ +-------+ Diameter +-------+
| HSS |------------| SPR | | HSS |------------| SPR |
+-------+ +-------+ +-------+ +-------+
| | | |
+------+ +------+ S4 | +-------+ +------+ +------+ S4 | +-------+
| 3G |---| SGSN |----------------|------+ +------| PCRF | | 3G |---| SGSN |----------------|------+ +------| PCRF |
^ |NodeB | | |---------+ +---+ | | +-------+ ^ |NodeB | | |---------+ +---+ | | +-------+
+-+ | +------+ +------+ S3 | | S6a | |Gxc | +-+ | +------+ +------+ S3 | | S6a | |Gxc |
| | | +-------+ | | |Gx | | | +-------+ | | |Gx
skipping to change at page 8, line 45 skipping to change at line 341
|non-3GPP | |non-3GPP | +-----+ |non-3GPP | |non-3GPP | +-----+
+---------+ +---------+ +---------+ +---------+
| | | |
+-+ +-+ +-+ +-+
| | | | | | | |
+-+ +-+ +-+ +-+
MT MT MT MT
Figure 1: 4G Mobile Network Overview Figure 1: 4G Mobile Network Overview
If we consider the combined impact of GTP, IPSec and unicast traffic, If we consider the combined impact of GTP, IPsec, and unicast
the data delivery is not efficient because of overhead. The IETF has traffic, the data delivery is not efficient because of overhead. The
developed various header compression algorithms to reduce the IETF has developed various header compression algorithms to reduce
overhead associated with IP packets. Some techniques are robust the overhead associated with IP packets. Some techniques are RObust
header compression (ROHC) and enhanced compression of the real-time Header Compression (ROHC) and Enhanced Compression RTP (ECRTP) so
transport protocol (ECRTP) so that the impact of overhead created by that the impact of overhead created by GTP, IPsec, etc., is reduced
GTP, IPsec, etc., is reduced to some extent [BROWER]. For commercial to some extent [BROWER]. For commercial mobile networks, 3GPP has
mobile networks, 3GPP has adopted different mechanisms for header adopted different mechanisms for header compression to achieve
compression to achieve efficiency in data delivery [TS25.323]; those efficiency in data delivery [TS25.323]; those solutions can be
solutions can be adapted to other data protocols, such as ICN, too adapted to other data protocols too such as ICN [RFC9139] [TLVCOMP].
[ICNLOWPAN] [TLVCOMP].
3.2. Mobile Network Quality of Service 3.2. Mobile Network Quality of Service
During the mobile terminal attachment procedure, a default bearer is During the mobile terminal attachment procedure, a default bearer is
created for each mobile terminal and it is assigned to the default created for each mobile terminal and it is assigned to the default
Access Point Name (APN), which provides the default transport. For Access Point Name (APN), which provides the default transport. For
any QoS-aware application, one or more new dedicated bearers are any QoS-aware application, one or more new dedicated bearers are
established between eNodeB and Mobile Gateway. Dedicated bearer can established between an eNodeB and a Mobile Gateway. A dedicated
be requested either by mobile terminal or mobile gateway based on bearer can be requested by either a mobile terminal or a Mobile
direction of first data flow. There are many bearers (logical paths) Gateway based on the direction of the first data flow. There are
established between eNodeB and mobile gateway for each mobile many bearers (logical paths) established between an eNodeB and a
terminal catering to different data flow simultaneously. Mobile Gateway for each mobile terminal catering to a different data
flow simultaneously.
While all traffic within a certain bearer receives the same While all traffic within a certain bearer receives the same
treatment, QoS parameters supporting these requirements can be very treatment, QoS parameters supporting these requirements can be very
granular in different bearers. These values vary for the control, granular in different bearers. These values vary for the control,
management and user traffic, and can be very different depending on management, and user traffic, and can be very different depending on
application key parameters such as latency, jitter (important for application key parameters such as latency, jitter (important for
voice and other real-time applications), packet loss, and queuing voice and other real-time applications), packet loss, and queuing
mechanism (strict priority, low-latency, fair, and so on). mechanism (strict priority, low latency, fair, and so on).
Implementation of QoS for mobile networks is done at two stages: at Implementation of QoS for mobile networks is done at two stages: 1)
content prioritization/marking and transport marking, and congestion content prioritization/marking and transport marking and 2)
management. From the transport perspective, QoS is defined at layer congestion management. From the transport perspective, QoS is
2 as class of service (CoS) and at layer 3 as Differentiated Services defined at Layer 2 as Class of Service (CoS) and at Layer 3 as
(DS). The mapping of DSCP to CoS takes place at layer 2/3 switching Differentiated Services (DS). The mapping of the Differentiated
and routing elements. 3GPP has a specified a QoS Class Identifier Services Code Point (DSCP) to CoS takes place at Layer 2/3 switching
and routing elements. 3GPP has a specified QoS Class Identifier
(QCI), which represents different types of content and equivalent (QCI), which represents different types of content and equivalent
mappings to the DSCP at transport layer [TS23.401]. However, this mappings to the DSCP at the transport layer [TS23.401]. However,
requires manual configuration at different elements and is therefore this requires manual configuration at different elements and is
prone to possible misconfigurations. therefore prone to possible misconfigurations.
In summary, QoS configuration in mobile networks for user plane In summary, QoS configuration in mobile networks for user-plane
traffic requires synchronization of parameters among different traffic requires synchronization of parameters among different
platforms. Normally, QoS in IP is implemented using DiffServ, which platforms. Normally, QoS in IP is implemented using DiffServ, which
uses hop-by-hop QoS configuration at each router. Any inconsistency uses hop-by-hop QoS configuration at each router. Any inconsistency
in IP QoS configuration at routers in the forwarding path can result in IP QoS configuration at routers in the forwarding path can result
in a poor subscriber experience (e.g., packet classified as high in a poor subscriber experience (e.g., a packet classified as high
priority can go to a lower priority queue). By deploying ICN, we priority can go to a lower-priority queue). By deploying ICN, we
intend to enhance the subscriber experience using policy-based intend to enhance the subscriber experience using policy-based
configuration, which can be associated with the named contents configuration, which can be associated with the named contents
[ICNQoS] at the ICN forwarder. Further investigation is underway to [ICNQoS] at the ICN forwarder. Further investigation is underway to
understand how QoS in ICN [I-D.anilj-icnrg-dnc-qos-icn] can be understand how QoS in ICN [QoS-ICN] can be implemented with reference
implemented with reference to the ICN QoS guidelines [RFC9064] to to the ICN QoS guidelines [RFC9064] to meet the QoS requirements
meet the QoS requirements [RFC4594]. [RFC4594].
3.3. Data Transport Using IP 3.3. Data Transport Using IP
The data delivered to mobile devices is sent in unicast semantic The data delivered to mobile devices is sent in unicast semantic
inside the GTP tunnel from an eNodeB to a PDN gateway (PGW), as inside the GTP tunnel from an eNodeB to a PDN gateway (PGW) as
described in 3GPP specifications [TS23.401]. While the technology described in 3GPP specifications [TS23.401]. While the technology
exists to address the issue of possible multicast delivery, there are exists to address the issue of possible multicast delivery, there are
many difficulties related to multicast protocol implementations on many difficulties related to multicast protocol implementations on
the RAN side of the network. By using eMBMS [EMBMS], multicast the RAN side of the network. By using eMBMS [EMBMS], multicast
routing can be enabled in mobile backhaul between eNodeB and Mobile routing can be enabled in mobile backhaul between an eNodeB and
Gateways (SGW) however for radio interface it requires broadcast Mobile Gateways (SGW/PGW); however, for radio interface it requires
which implies that we need dedicated radio channel. Implementation broadcast, which implies that we need a dedicated radio channel.
of eMBMS in RAN is still lagging behind due to complexities related Implementation of eMBMS in RAN is still lagging behind due to
to client mobility, handovers, and the fact that the potential gain complexities related to client mobility, handovers, and the fact that
to Service Providers may not justify the investment, which explains the potential gain to Service Providers may not justify the
the prevalence of unicast delivery in mobile networks. Techniques to investment, which explains the prevalence of unicast delivery in
handle multicast (such as LTE-B or eMBMS) have been designed to mobile networks. Techniques to handle multicast (such as LTE-B or
handle pre-planned content delivery, such as live content, which eMBMS) have been designed to handle pre-planned content delivery,
contrasts user behavior today, largely based on content (or video) on such as live content, which contrasts user behavior today, largely
demand model. based on a content (or video) on-demand model.
To ease the burden on the bandwidth of the SGi interface, caching is To ease the burden on the bandwidth of the Service Gateway interface
introduced in a similar manner as with many Enterprises. In mobile (SGi), caching is introduced in a similar manner as with many
networks, whenever possible, cached data is delivered. Caching enterprises. In mobile networks, whenever possible, cached data is
servers are placed at a centralized location, typically in the delivered. Caching servers are placed at a centralized location,
Service Provider's Data Center, or in some cases lightly distributed typically in the Service Provider's Data Center, or in some cases
in Packet Core locations with the PGW nodes close to the Internet and lightly distributed in packet core locations with the PGW nodes close
IP services access (SGi interface). This is a very inefficient to the Internet and IP services access (SGi). This is a very
concept because traffic must traverse the entire backhaul path for inefficient concept because traffic must traverse the entire backhaul
the data to be delivered to the end user. Other issues, such as out- path for the data to be delivered to the end user. Other issues,
of-order delivery, contribute to this complexity and inefficiency, such as out-of-order delivery, contribute to this complexity and
which needs to be addressed at the application level. inefficiency, which needs to be addressed at the application level.
3.4. Virtualized Mobile Networks 3.4. Virtualized Mobile Networks
The Mobile gateways deployed in a major Service Provider network are The Mobile Gateways deployed in a major Service Provider network are
either based on dedicated hardware or, commercially off the shelf based on either dedicated hardware or commercial off-the-shelf (COTS)
(COTS) based x86 technology. With the adoption of Mobile Virtual x86 technology. With the adoption of Mobile Virtual Network
Network Operators (MVNO), public safety networks, and enterprise Operators (MVNOs), public safety networks, and enterprise mobility
mobility networks, elastic mobile core architecture are needed. By networks, elastic mobile core architecture is needed. By deploying
deploying the mobile packet core on COTS platform, using a the mobile packet core on a COTS platform, using a Network Function
virtualized infrastructure (NFVI) framework and end-to-end Virtualization Infrastructure (NFVI) framework and end-to-end
orchestration, new deployments can be simplified to provide optimized orchestration, new deployments can be simplified to provide optimized
total cost of ownership (TCO). total cost of ownership (TCO).
While virtualization is growing, and many mobile providers use a While virtualization is growing, and many mobile providers use a
hybrid architecture that consists of dedicated and virtualized hybrid architecture that consists of dedicated and virtualized
infrastructures, the control, and data planes are still the same. infrastructures, the control and data planes are still the same.
There is also work under way to separate the control and user plane There is also work underway to separate the control and user plane
for the network to scale better. Virtualized mobile networks and for the network to scale better. Virtualized mobile networks and
network slicing with control and user plane separation provide a network slicing with control and user-plane separation provide a
mechanism to evolve the GTP-based architecture towards an OpenFlow mechanism to evolve the GTP-based architecture towards an OpenFlow
SDN-based signaling for 4G and proposed 5G core. Some early with signaling based on Software-Defined Networking (SDN) for 4G and
architecture work for 5G mobile technologies provides a mechanism for proposed 5G core. Some early architecture work for 5G mobile
control and user plane separation and simplifies the mobility call technologies provides a mechanism for control and user-plane
flow by introducing OpenFlow-based signaling [ICN5G]. This has been separation and simplifies the mobility call flow by introducing
considered by 3GPP [EPCCUPS] and is also described in [SDN5G]. OpenFlow-based signaling [ICN5G]. This has been considered by 3GPP
[EPCCUPS] and is also described in [SDN5G].
4. Data Transport Using ICN 4. Data Transport Using ICN
For mobile devices, the edge connectivity is between mobile terminal For mobile devices, the edge connectivity is between a mobile
and a router or mobile edge computing (MEC) [MECSPEC] element. Edge terminal and a router or mobile edge computing (MEC) [MECSPEC]
computing has the capability of processing client requests and element. Edge computing has the capability of processing client
segregating control and user traffic at the edge of radio, rather requests and segregating control and user traffic at the edge of
than sending all requests to the mobile gateway. radio rather than sending all requests to the Mobile Gateway.
+----------+ +----------+
| Content +----------------------------------------+ | Content +----------------------------------------+
| Publisher| | | Publisher| |
+---+---+--+ | +---+---+--+ |
| | +--+ +--+ +--+ | | | +--+ +--+ +--+ |
| +--->|R1|------------>|R2|---------->|R4| | | +--->|R1|------------>|R2|---------->|R4| |
| +--+ +--+ +--+ | | +--+ +--+ +--+ |
| | Cached | | | Cached |
| v content | | v content |
skipping to change at page 12, line 30 skipping to change at line 490
+---------------| |-------------| |-------------+ +---------------| |-------------| |-------------+
+-+ +-+ +-+ +-+
Consumer-1 Consumer-2 Consumer-1 Consumer-2
Mobile Terminal Mobile Terminal Mobile Terminal Mobile Terminal
===> Content flow from cache ===> Content flow from cache
---> Content flow from publisher ---> Content flow from publisher
Figure 2: ICN Architecture Figure 2: ICN Architecture
Edge computing transforms radio access network into an intelligent Edge computing transforms a Radio Access Network into an intelligent
service edge capable of delivering services directly from the edge of service edge capable of delivering services directly from the edge of
the network, while providing the best possible performance to the the network while providing the best possible performance to the
client. Edge computing can be an ideal candidate for implementing client. Edge computing can be an ideal candidate for implementing
ICN forwarders in addition to its usual function of managing mobile ICN forwarders in addition to its usual function of managing mobile
termination. In addition to edge computing, other transport termination. In addition to edge computing, other transport
elements, such as routers, can work as ICN forwarders. elements, such as routers, can work as ICN forwarders.
Data transport using ICN is different to IP-based transport by Data transport using ICN is different than IP-based transport as it
introducing uniquely named-data as a core design principle. introduces uniquely named-data as a core design principle.
Communication in ICN takes place between the content provider Communication in ICN takes place between the content provider
(producer) and the end user (consumer), as described in Figure 2. (producer) and the end user (consumer), as described in Figure 2.
Every node in a physical path between a client and a content provider Every node in a physical path between a client and a content provider
is called the ICN forwarder or router. It can route the request is called the ICN forwarder or router. It can route the request
intelligently and cache content so it can be delivered locally for intelligently and cache content so it can be delivered locally for
subsequent requests from any other client. For mobile networks, subsequent requests from any other client. For mobile networks,
transport between a client and a content provider consists of radio transport between a client and a content provider consists of a radio
network + mobile backhaul and IP core transport + Mobile Gateways + network + mobile backhaul and IP core transport + Mobile Gateways +
Internet + content data network (CDN). Internet + Content Delivery Network (CDN).
To understand the suitability of ICN for mobile networks, we will To understand the suitability of ICN for mobile networks, we will
discuss the ICN framework by describing its protocols architecture discuss the ICN framework by describing its protocol architecture and
and different types of messages to then consider how we can use this different types of messages; this will be helpful when considering
in mobile networks for delivering content more efficiently. ICN uses how to use ICN in mobile networks to deliver content more
two types of packets called "interest packet" and "data packet" as efficiently. ICN uses two types of packets called "interest packet"
described in Figure 3. and "data packet" as described in Figure 3.
+------------------------------------+ +------------------------------------+
Interest | +------+ +------+ +------+ | +-----+ Interest | +------+ +------+ +------+ | +-----+
+-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN |
| | | +------+ +------+ +------+ | +-----+ | | | +------+ +------+ +------+ | +-----+
+-+ | | Add | Drop | | Forward +-+ | | Add | Drop | | Forward
MT <--------+ Intf v Nack v | MT <--------+ Intf v Nack v |
Data | | Data | |
+------------------------------------+ +------------------------------------+
+------------------------------------+ +------------------------------------+
+-+ | Forward +------+ | +-----+ +-+ | Forward +------+ | +-----+
| | <-------------------------------------| PIT |<---------| CDN | | | <-------------------------------------| PIT |<---------| CDN |
+-+ | | Cache +--+---+ | Data +-----+ +-+ | | Cache +--+---+ | Data +-----+
MT | +--v---+ | | MT | +--v---+ | |
| | CS | v | | | CS | v |
| +------+ Discard | | +------+ Discard |
+------------------------------------+ +------------------------------------+
Figure 3: ICN Interest, Data Packet and Forwarder Figure 3: ICN Interest, Data Packet, and Forwarder
In an 4G network, when a mobile device wants to receive certain In a 4G network, when a mobile device wants to receive certain
content, it will send an Interest message to the closest eNodeB. content, it will send an Interest message to the closest eNodeB.
Interest packets follow the TLV format [RFC8609] and contain Interest packets follow the TLV format [RFC8609] and contain
mandatory fields, such as name of the content and content matching mandatory fields such as the name of the content and content-matching
restrictions (KeyIdRestr and ContentObjectHashRestr), expressed as a restrictions (KeyIdRestr and ContentObjectHashRestr) expressed as a
tuple [RFC8569]. The content matching tuple uniquely identifies the tuple [RFC8569]. The content-matching tuple uniquely identifies the
matching data packet for the given Interest packet. Another matching data packet for the given Interest packet. Another
attribute called HopLimit is used to detect looping Interest attribute called "HopLimit" is used to detect looping Interest
messages. messages.
An ICN router will receive an Interest packet and lookup if a request An ICN router will receive an Interest packet and lookup if a request
for such content has arrived earlier from another client. If so, it for such content has arrived earlier from another client. If so, it
may be served from the local cache; otherwise, the request is may be served from the local cache; otherwise, the request is
forwarded to the next-hop ICN router. Each ICN router maintains forwarded to the next-hop ICN router. Each ICN router maintains
three data structures: Pending Interest Table (PIT), Forwarding three data structures: Pending Interest Table (PIT), Forwarding
Information Base (FIB), and Content Store (CS). The Interest packet Information Base (FIB), and Content Store (CS). The Interest packet
travels hop-by-hop towards the content provider. Once the Interest travels hop by hop towards the content provider. Once the Interest
packet reaches the content provider, it will return a Data packet packet reaches the content provider, it will return a data packet
containing information such as content name, signature, and the containing information such as content name, signature, and the
actual data. actual data.
The data packet travels in reverse direction following the same path The data packet travels in reverse direction following the same path
taken by the Interest packet, maintaining routing symmetry. Details taken by the Interest packet, maintaining routing symmetry. Details
about algorithms used in PIT, FIB, CS, and security trust models are about algorithms used in PIT, FIB, CS, and security trust models are
described in various resources [CCN]; here, we have explained the described in various resources [CCN]; here, we have explained the
concept and its applicability to the 4G network. concept and its applicability to the 4G network.
5. Experimental Scenarios for ICN Deployment 5. Experimental Scenarios for ICN Deployment
In 4G mobile networks, both user and control plane traffic have to be In 4G mobile networks, both user and control plane traffic have to be
transported from the edge to the mobile packet core via IP transport. transported from the edge to the mobile packet core via IP transport.
The evolution of the existing mobile packet core using Control and The evolution of the existing mobile packet core using Control and
User Plane Separation (CUPS) [TS23.714] enables flexible network and User Plane Separation (CUPS) [TS23.714] enables flexible networking
operations by distributed deployment and the independent scaling of and operations by distributed deployment and the independent scaling
control plane and user plane functions - while not affecting the of control plane and user-plane functions while not affecting the
functionality of existing nodes subject to this split. functionality of existing nodes subject to this split.
In this section, we analyze the potential impact of ICN on control In this section, we analyze the potential impact of ICN on control
and user plane traffic for centralized and disaggregated CUPS-based and user-plane traffic for centralized and disaggregated CUPS-based
mobile network architecture. We list various experimental options mobile network architecture. We list various experimental options
and opportunities to study the feasibility of the deployment of ICN and opportunities to study the feasibility of the deployment of ICN
in 4G networks. The proposed experiments would help the network and in 4G networks. The proposed experiments would help the network and
OEM designers to understand various issues, optimizations, and original equipment manufacturer (OEM) designers to understand various
advantages of deployment of ICN in 4G networks. issues, optimizations, and advantages of the deployment of ICN in 4G
networks.
5.1. General Considerations 5.1. General Considerations
In the CUPS architecture, there is an opportunity to shorten the path In the CUPS architecture, there is an opportunity to shorten the path
for user plane traffic by deploying offload nodes closer to the edge for user-plane traffic by deploying offload nodes closer to the edge
[OFFLOAD]. With this major architecture change, a User Plane [OFFLOAD]. With this major architecture change, a User Plane
Function (UPF) node is placed close to the edge so traffic no longer Function (UPF) node is placed close to the edge so traffic no longer
needs to traverse the entire backhaul path to reach the EPC. In many needs to traverse the entire backhaul path to reach the EPC. In many
cases, where feasible, the UPF can be collocated with the eNodeB, cases, where feasible, the UPF can be collocated with the eNodeB,
which is also a business decision based on user demand. Placing a which is also a business decision based on user demand. Placing a
Publisher close to the offload site, or at the offload site, provides Publisher close to the offload site, or at the offload site, provides
for a significant improvement in user experience, especially with for a significant improvement in user experience, especially with
latency-sensitive applications. This capability allows for the latency-sensitive applications. This capability allows for the
introduction of ICN and amplifies its advantages. introduction of ICN and amplifies its advantages.
5.2. Scenarios of ICN Integration 5.2. Scenarios of ICN Integration
The integration of ICN provides an opportunity to further optimize The integration of ICN provides an opportunity to further optimize
the existing data transport in 4G mobile networks. The various the existing data transport in 4G mobile networks. The various
opportunities from the coexistence of ICN and IP transport in the opportunities from the coexistence of ICN and IP transport in the
mobile network are somewhat analogous to the deployment scenarios mobile network are somewhat analogous to the deployment scenarios
when IPv6 was introduced to interoperate with IPv4 except, with ICN, when IPv6 was introduced to interoperate with IPv4 except, with ICN,
the whole IP stack can be replaced. We have reviewed [RFC6459] and the whole IP stack can be replaced. We have reviewed [RFC6459] and
analyzed the impact of ICN on control plane signaling and user plane analyzed the impact of ICN on control plane signaling and user-plane
data delivery. In general, ICN can be used natively by replacing IP data delivery. In general, ICN can be used natively by replacing IP
transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 transport (IPv4 and IPv6) or as an overlay protocol. Figure 4
describes a proposal to modify the existing transport protocol stack describes a proposal to modify the existing transport protocol stack
to support ICN in 4G mobile network. to support ICN in a 4G mobile network.
+----------------+ +-----------------+ +----------------+ +-----------------+
| ICN App (new) | |IP App (existing)| | ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+ +---------+------+ +-------+---------+
| | | |
+---------+----------------+---------+ +---------+----------------+---------+
| Transport Convergence Layer (new) | | Transport Convergence Layer (new) |
+------+---------------------+-------+ +------+---------------------+-------+
| | | |
+------+------+ +------+-------+ +------+------+ +------+-------+
skipping to change at page 15, line 39 skipping to change at line 632
| (New) | | (Existing) | | (New) | | (Existing) |
+------+------+ +------+-------+ +------+------+ +------+-------+
| | | |
(```). (```). (```). (```).
( ICN '`. ( IP '`. ( ICN '`. ( IP '`.
( Cloud ) ( Cloud ) ( Cloud ) ( Cloud )
` __..'+' ` __..'+' ` __..'+' ` __..'+'
Figure 4: IP/ICN Convergence Scenarios Figure 4: IP/ICN Convergence Scenarios
As shown in Figure 4, for applications - running either in the mobile As shown in Figure 4, for applications (running either in the mobile
terminal or in the content provider system - to use the ICN transport terminal or in the content provider system) to use the ICN transport
option, we propose a new transport convergence layer (TCL). The TCL option, we propose a new transport convergence layer (TCL). The TCL
helps determine the type of transport (such as ICN or IP), as well as helps determine the type of transport (such as ICN or IP) as well as
the type of radio interface (LTE or WiFi or both) used to send and the type of radio interface (LTE, Wi-Fi, or both) used to send and
receive traffic based on preference (e.g., content location, content receive traffic based on preference (e.g., content location, content
type, content publisher, congestion, cost, QoS). It helps configure type, content publisher, congestion, cost, or QoS). It helps
and determine the type of connection (native IP or ICN) or the configure and determine the type of connection (native IP or ICN) or
overlay mode (ICNoIP or IPoICN) between application and the protocol the overlay mode (ICNoIP or IPoICN) between application and the
stack (IP or ICN). protocol stack (IP or ICN).
Combined with the existing IP function, the ICN function provides Combined with the existing IP function, the ICN function provides
support for either native ICN and/or the dual transport (ICN/IP) support for native ICN and/or the dual transport (ICN/IP)
transport functionality. See Section 5.4.1 for elaborate functionality. See Section 5.4.1 for elaborate descriptions of these
descriptions of these functional layers. functional layers.
The TCL can use several mechanisms for transport selection. It can The TCL can use several mechanisms for transport selection. It can
use a per-application configuration through a management interface, use a per-application configuration through a management interface,
possibly a user-facing setting realized through a user interface, possibly a user-facing setting realized through a user interface,
like those used to select cellular over WiFi. In another option, it like those used to select cellular over Wi-Fi. In another option, it
might use a software API, which an adapted IP application could use might use a software API, which an adapted IP application could use
to specify the type of transport option (such as ICN) to take to specify the type of transport option (such as ICN) to take
advantage of its benefits. advantage of its benefits.
Another potential application of TCL is in implementation of network Another potential application of TCL is in an implementation of
slicing, with a slice management capability locally or through an network slicing with a local slice management capability or through
interface to an external slice manager via an API [GALIS]. This an interface to an external slice manager via an API [GALIS]. This
solution can enable network slicing for IP and ICN transport solution can enable network slicing for IP and ICN transport
selection from the mobile terminal itself. The TCL could apply slice selection from the mobile terminal itself. The TCL could apply slice
settings to direct certain applications traffic over one slice and settings to direct certain applications traffic over one slice and
others over another slice, determined by some form of 'slicing others over another slice, determined by some form of a 'slicing
policy'. Slicing policy can be obtained externally from the slice policy'. The slicing policy can be obtained externally from the
manager or configured locally on the mobile terminal. slice manager or configured locally on the mobile terminal.
From the perspective of applications either on the mobile terminal or From the perspective of applications either on the mobile terminal or
at a content provider, the following options are possible for at a content provider, the following options are possible for
potential use of ICN natively and/or with IP. potential use of ICN natively and/or with IP.
1. IP over IP IP over IP (IPoIP): In this scenario, the mobile terminal
applications are tightly integrated with the existing IP transport
In this scenario, the mobile terminal applications are tightly infrastructure. The TCL has no additional function because
integrated with the existing IP transport infrastructure. The packets are forwarded directly using an IP protocol stack, which
TCL has no additional function because packets are forwarded sends packets over the IP transport.
directly using an IP protocol stack, which sends packets over the
IP transport.
2. ICN over ICN
Similar to case 1, ICN applications tightly integrate with the
ICN transport infrastructure. The TCL has no additional
responsibility because packets are forwarded directly using the
native ICN protocol stack, which sends packets over the ICN
transport.
3. ICN over IP (ICNoIP)
In this scenario, the underlying IP transport infrastructure is
not impacted (that is, ICN is implemented as an IP overlay
between mobile terminal and content provider). IP routing is
used from the Radio Access Network (eNodeB) to the mobile
backhaul, the IP core, and the Mobile Gateway (SGW/PGW). The
mobile terminal attaches to the Mobile Gateway (SGW/PGW) using an
IP address. Also, the data transport between Mobile Gateway
(SGW/PGW) and content publisher uses IP. The content provider
can serve content either using IP or ICN, based on the mobile
terminal request.
One of the approaches to implement ICN in mobile backhaul ICN over ICN (ICNoICN): Similar to case 1, ICN applications tightly
networks is described in [MBICN]. It implements a GTP-U integrate with the ICN transport infrastructure. The TCL has no
extension header option to encapsulate ICN payload in a GTP additional responsibility because packets are forwarded directly
tunnel. However, as this design runs ICN as an IP overlay, the using the native ICN protocol stack, which sends packets over the
mobile backhaul can be deployed using native IP. The proposal ICN transport.
describes a mechanism where the GTP-U tunnel can be terminated by
hairpinning the packet before it reaches SGW, if an ICN-enabled
node is deployed in the mobile backhaul (that is, between eNodeB
and SGW). This could be useful when an ICN data packet is stored
in the ICN node (such as repositories, caches) in the tunnel path
so that the ICN node can reply without going all the way through
the mobile core. While a GTP-U extension header is used to carry
mobile terminal specific ICN payload, they are not visible to the
transport, including SGW. On the other hand, the PGW can use the
mobile terminal-specific ICN header extension and ICN payload to
set up an uplink transport towards a content provider in the
Internet. In addition, the design assumes a proxy function at
the edge, to perform ICN data retrieval on behalf of a non-ICN
end device.
4. IP over ICN (IPoICN) ICN over IP (ICNoIP): In this scenario, the underlying IP transport
infrastructure is not impacted (that is, ICN is implemented as an
IP overlay between mobile terminal and content provider). IP
routing is used from the Radio Access Network (eNodeB) to the
mobile backhaul, the IP core, and the Mobile Gateway (SGW/PGW).
The mobile terminal attaches to the Mobile Gateway (SGW/PGW) using
an IP address. Also, the data transport between Mobile Gateway
(SGW/PGW) and content publisher uses IP. The content provider can
serve content using either IP or ICN, based on the mobile terminal
request.
[IPoICN] provides an architectural framework for running IP as an One of the approaches to implement ICN in mobile backhaul networks
overlay over ICN protocol. Implementing IP services over ICN is described in [MBICN]. It implements a General Tunneling
provides an opportunity to leverage the benefits of ICN in the Protocol - User Plane (GTP-U) extension header option to
transport infrastructure while there is no impact on end devices encapsulate ICN payload in a GTP tunnel. However, as this design
(MT and access network) as they continue to use IP. IPoICN runs ICN as an IP overlay, the mobile backhaul can be deployed
however, will require an inter-working function (IWF/Border using native IP. The proposal describes a mechanism where the
Gateway) to translate various transport primitives. The IWF GTP-U tunnel can be terminated by hairpinning the packet before it
function will provide a mechanism for protocol translation reaches the SGW if an ICN-enabled node is deployed in the mobile
between IPoICN and the native IP. After reviewing [IPoICN], we backhaul (that is, between eNodeB and SGW). This could be useful
understand and interpret that ICN is implemented in the transport when an ICN data packet is stored in the ICN node (such as
natively, however, IP is implemented in MT, eNodeB, and Mobile repositories and caches) in the tunnel path so that the ICN node
gateway (SGW/PGW), which is also called as a network attach point can reply without going all the way through the mobile core.
(NAP). While a GTP-U extension header is used to carry mobile-terminal-
specific ICN payload, they are not visible to the transport,
including the SGW. On the other hand, the PGW can use the mobile
terminal-specific ICN header extension and ICN payload to set up
an uplink transport towards a content provider in the Internet.
In addition, the design assumes a proxy function at the edge to
perform ICN data retrieval on behalf of a non-ICN end device.
For this, said NAP receives an incoming IP or HTTP packet (the IP over ICN (IPoICN): [IPoICN] provides an architectural framework
latter through TCP connection termination) and publishes the for running IP as an overlay over the ICN protocol. Implementing
packet under a suitable ICN name (i.e., the hash over the IP services over ICN provides an opportunity to leverage the
destination IP address for an IP packet or the hash over the FQDN benefits of ICN in the transport infrastructure while there is no
of the HTTP request for an HTTP packet) to the ICN network. In impact on end devices (MT and access network) as they continue to
the HTTP case, the NAP maintains a pending request mapping table use IP. IPoICN, however, will require an interworking function
to map returning responses to the terminated TCP connection. (IWF) (and Border Gateway) to translate various transport
primitives. The IWF function will provide a mechanism for
protocol translation between IPoICN and the native IP. After
reviewing [IPoICN], we understand and interpret that ICN is
implemented in the transport natively; however, IP is implemented
in MT, the eNodeB, and the Mobile Gateway (SGW/PGW), which is also
called a network attach point (NAP).
5. Hybrid ICN (hICN) For this, said NAP receives an incoming IP or HTTP packet (the
latter through TCP connection termination) and publishes 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 NAP maintains a pending request mapping table
to map returning responses to the terminated TCP connection.
An alternative approach to implement ICN over IP is provided in Hybrid ICN (hICN): An alternative approach to implement ICN over IP
Hybrid ICN [HICN]. It describes a novel approach to integrate is provided in Hybrid ICN [HICN]. It describes a novel approach
ICN into IPv6 without creating overlays with a new packet format to integrate ICN into IPv6 without creating overlays with a new
as an encapsulation. hICN addresses the content by encoding a packet format as an encapsulation. hICN addresses the content by
location-independent name in an IPv6 address. It uses two name encoding a location-independent name in an IPv6 address. It uses
components--name prefix and name suffix--that identify the source two name components, name prefix and name suffix, that identify
of data and the data segment within the scope of the name prefix, the source of data and the data segment within the scope of the
respectively. name prefix, respectively.
At application layer, hICN maps the name into an IPv6 prefix and, At the application layer, hICN maps the name into an IPv6 prefix
thus, uses IP as transport. As long as the name prefixes, which and, thus, uses IP as transport. As long as the name prefixes,
are routable IP prefixes, point towards a mobile GW (PGW or local which are routable IP prefixes, point towards a mobile GW (PGW or
breakout, such as CUPS), there are potentially no updates local breakout, such as CUPS), there are potentially no updates
required to any of the mobile core gateways (for example, SGW/ required to any of the mobile core gateways (for example, SGW/
PGW). The IPv6 backhaul routes the packets within the mobile PGW). The IPv6 backhaul routes the packets within the mobile
core. hICN can run in the mobile terminal, in the eNodeB, in the core. hICN can run in the mobile terminal, the eNodeB, the mobile
mobile backhaul, or in the mobile core. Finally, as hICN itself backhaul, or the mobile core. Finally, as hICN itself uses IPv6,
uses IPv6, it cannot be considered as an alternative transport it cannot be considered as an alternative transport layer.
layer.
5.3. Integration of ICN in 4G Control Plane 5.3. Integration of ICN in 4G Control Plane
In this section, we analyze signaling messages that are required for In this section, we analyze signaling messages that are required for
different procedures, such as attach, handover, tracking area update, different procedures, such as attach, handover, tracking area update,
and so on. The goal of this analysis is to see if there are any and so on. The goal of this analysis is to see if there are any
benefits to replacing IP-based protocols with ICN for 4G signaling in benefits to replacing IP-based protocols with ICN for 4G signaling in
the current architecture. It is important to understand the concept the current architecture. It is important to understand the concept
of point of attachment (POA). When mobile terminal connects to a of point of attachment (POA). When a mobile terminal connects to a
network, it has the following POAs: network, it has the following POAs:
1. eNodeB managing location or physical POA 1. eNodeB managing location or physical POA
2. Authentication and Authorization (MME, HSS) managing identity or 2. Authentication and Authorization (MME, HSS) managing identity or
authentication POA authentication POA
3. Mobile Gateways (SGW, PGW) managing logical or session management 3. Mobile Gateways (SGW/PGW) managing logical or session management
POA POA
In the current architecture, IP transport is used for all messages In the current architecture, IP transport is used for all messages
associated with the control plane for mobility and session associated with the control plane for mobility and session
management. IP is embedded very deeply into these messages utilizing management. IP is embedded very deeply into these messages utilizing
TLV syntax for carrying additional attributes such as a layer 3 TLV syntax for carrying additional attributes such as a Layer 3
transport. The physical POA in the eNodeB handles both mobility and transport. The physical POA in the eNodeB handles both mobility and
session management for any mobile terminal attached to 4G network. session management for any mobile terminal attached to a 4G network.
The number of mobility management messages between different nodes in The number of mobility management messages between different nodes in
an 4G network per signaling procedure is shown in Table 1. a 4G network per the signaling procedure is shown in Table 1.
Normally, two types of mobile terminals attach to the 4G network: SIM Normally, two types of mobile terminals attach to the 4G network: SIM
based (need 3GPP mobility protocol for authentication) or non-SIM based (which needs a 3GPP mobility protocol for authentication) or
based (which connect to WiFi network). Both device types require non-SIM based (which connects to Wi-Fi networks). Both device types
authentication. For non-SIM based devices, AAA is used for require authentication. For non-SIM based devices, Authentication,
authentication. We do not propose to change mobile terminal Authorization, and Accounting (AAA) is used for authentication. We
authentication or mobility management messaging for user data do not propose to change mobile terminal authentication or mobility
transport using ICN. A separate study would be required to analyze management messaging for user data transport using ICN. A separate
the impact of ICN on mobility management messages structures and study would be required to analyze the impact of ICN on mobility
flows. We are merely analyzing the viability of implementing ICN as management messages, structures, and flows. We are merely analyzing
a transport for control plane messages. the viability of implementing ICN as a transport for control plane
messages.
It is important to note that if MME and HSS do not support ICN It is important to note that if MME and HSS do not support ICN
transport, they still need to support mobile terminal capable of dual transport, they still need to support a mobile terminal capable of
transport or native ICN. When mobile terminal initiates an attach dual transport or native ICN. When a mobile terminal initiates an
request using the identity as ICN, MME must be able to parse that attach request using the identity as ICN, MME must be able to parse
message and create a session. MME forwards mobile terminal that message and create a session. MME forwards mobile terminal
authentication to HSS, so HSS must be able to authenticate an ICN- authentication to HSS, so HSS must be able to authenticate an ICN-
capable mobile terminal and authorize create session [TS23.401]. capable mobile terminal and authorize Create Session [TS23.401].
+===========================+=====+=====+=====+=====+======+ +===========================+=====+=====+=====+=====+======+
| 4G Signaling Procedures | MME | HSS | SGW | PGW | PCRF | | 4G Signaling Procedures | MME | HSS | SGW | PGW | PCRF |
+===========================+=====+=====+=====+=====+======+ +===========================+=====+=====+=====+=====+======+
| Attach | 10 | 2 | 3 | 2 | 1 | | Attach | 10 | 2 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
| Additional default bearer | 4 | 0 | 3 | 2 | 1 | | Additional default bearer | 4 | 0 | 3 | 2 | 1 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
| Dedicated bearer | 2 | 0 | 2 | 2 | 0 | | Dedicated bearer | 2 | 0 | 2 | 2 | 0 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
skipping to change at page 20, line 5 skipping to change at line 825
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
| S1 handover | 8 | 0 | 3 | 0 | 0 | | S1 handover | 8 | 0 | 3 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
| Tracking area update | 2 | 2 | 0 | 0 | 0 | | Tracking area update | 2 | 2 | 0 | 0 | 0 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
| Total | 34 | 2 | 14 | 6 | 3 | | Total | 34 | 2 | 14 | 6 | 3 |
+---------------------------+-----+-----+-----+-----+------+ +---------------------------+-----+-----+-----+-----+------+
Table 1: Signaling Messages in 4G Gateways Table 1: Signaling Messages in 4G Gateways
Anchorless mobility [ALM] provides a fully decentralized, control- Anchorless mobility [ALM] provides a fully decentralized solution
plane agnostic solution to handle producer mobility in ICN. Mobility that is control plane agnostic to handle producer mobility in ICN.
management at layer-3 level makes it access agnostic and transparent Mobility management at the Layer 3 makes its access agnostic and
to the end device or the application. The solution discusses transparent to the end device or the application. The solution
handling mobility without having to depend on core network functions discusses handling mobility without having to depend on core network
(e.g. MME); however, a location update to the core network may still functions (e.g., MME); however, a location update to the core network
be required to support legal compliance requirements such as lawful may still be required to support legal compliance requirements such
intercept and emergency services. These aspects are open for further as lawful intercept and emergency services. These aspects are open
study. for further study.
One of the advantages of ICN is in the caching and reusing of the One of the advantages of ICN is in the caching and reusing of the
content, which does not apply to the transactional signaling content, which does not apply to the transactional signaling
exchange. After analyzing 4G signaling call flows [TS23.401] and exchange. After analyzing 4G signaling call flows [TS23.401] and
messages inter-dependencies (see Table 1), our recommendation is that message interdependencies (see Table 1), our recommendation is that
it is not beneficial to use ICN for control plane and mobility it is not beneficial to use ICN for control plane and mobility
management functions. Among the features of ICN design, Interest management functions. Among the features of ICN design, Interest
aggregation and content caching are not applicable to control plane aggregation and content caching are not applicable to control plane
signaling messages. Control plane messages are originated and signaling messages. Control plane messages are originated and
consumed by the applications and they cannot be shared. consumed by the applications, and they cannot be shared.
5.4. Integration of ICN in 4G User Plane 5.4. Integration of ICN in 4G User Plane
We will consider Figure 1 to discuss different mechanisms to We will consider Figure 1 when discussing different mechanisms to
integrate ICN in mobile networks. In Section 5.2, we discussed integrate ICN in mobile networks. In Section 5.2, we discussed
generic experimental setups of ICN integration. In this section, we generic experimental setups of ICN integration. In this section, we
discuss the specific options of possible use of native ICN in 4G user discuss the specific options of possible use of native ICN in the 4G
plane. We consider the following options: user plane. The following options are considered:
1. Dual transport (IP/ICN) mode in Mobile Terminal 1. Using Dual transport (IP/ICN) mode in mobile terminal
2. Using ICN in Mobile Terminal 2. Using ICN in mobile terminal
3. Using ICN in eNodeB 3. Using ICN in eNodeB
4. Using ICN in mobile gateways (SGW/PGW) 4. Using ICN in Mobile Gateways (SGW/PGW)
5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal 5.4.1. Dual Transport (IP/ICN) Mode in Mobile Terminal
The control and user plane communications in 4G mobile networks are The control and user-plane communications in 4G mobile networks are
specified in 3GPP documents [TS23.203] and [TS23.401]. It is specified in 3GPP documents [TS23.203] and [TS23.401]. It is
important to understand that mobile terminal can be either consumer important to understand that a mobile terminal can be either consumer
(receiving content) or publisher (pushing content for other clients). (receiving content) or publisher (pushing content for other clients).
The protocol stack inside the mobile terminal (MT) is complex because The protocol stack inside the mobile terminal (MT) is complex because
it must support multiple radio connectivity access to eNodeB(s). it must support multiple radio connectivity access to eNodeB(s).
Figure 5 provides a high-level description of a protocol stack, where Figure 5 provides a high-level description of a protocol stack, where
IP is used at two layers: (1) user plane communication and (2) UDP IP is used at two layers: (1) user-plane communication and (2) UDP
encapsulation. User plane communication takes place between Packet encapsulation. User-plane communication takes place between the
Data Convergence Protocol (PDCP) and Application layer, whereas UDP Packet Data Convergence Protocol (PDCP) and Application layer,
encapsulation is at GTP protocol stack. whereas UDP encapsulation is at the GTP protocol stack.
The protocol interactions and impact of supporting tunneling of ICN The protocol interactions and impact of supporting the tunneling of
packet into IP or to support ICN natively are described in Figure 5 an ICN packet into IP or supporting ICN natively are described in
and Figure 6, respectively. Figures 5 and 6, respectively.
+--------+ +--------+ +--------+ +--------+
| App | | CDN | | App | | CDN |
+--------+ +--------+ +--------+ +--------+
|Transp. | | | | |Transp. | |Transp. | | | | |Transp. |
|Converg.|.|..............|...............|............|.|Converge| |Converg.|.|..............|...............|............|.|Converge|
+--------+ | | | +--------+ | +--------+ +--------+ | | | +--------+ | +--------+
| |.|..............|...............|.| |.|.| | | |.|..............|...............|.| |.|.| |
| ICN/IP | | | | | ICN/IP | | | ICN/IP| | ICN/IP | | | | | ICN/IP | | | ICN/IP|
| | | | | | | | | | | | | | | | | | | |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
| |.|.| | |.|.| | |.|.| | | | | | | |.|.| | |.|.| | |.|.| | | | | |
| PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 |
+--------+ | +----------+ | +-----------+ | +-----+ | | | | +--------+ | +----------+ | +-----------+ | +-----+ | | | |
| RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| |
+--------+ | +----------+ | +-----------+ | +-----+ | | | | +--------+ | +----------+ | +-----------+ | +-----+ | | | |
| MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | |
+--------+ | +----------+ | +-----------+ | +--------+ | +--------+ +--------+ | +----------+ | +-----------+ | +--------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 |
+--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+
MT | BS(eNodeB) | SGW | PGW | MT | BS (eNodeB) | SGW | PGW |
Uu S1U S5/S8 SGi Uu S1U S5/S8 SGi
Figure 5: Dual Transport (IP/ICN) mode in Mobile Terminal Figure 5: Dual Transport (IP/ICN) Mode in a Mobile Terminal
The protocols and software stack used inside 4G capable mobile The protocols and software stack used inside 4G-capable mobile
terminal support both 3G and 4G software interworking and handover. terminals support both 3G and 4G software interworking and handover.
3GPP Rel.13 onward specifications describe the use of IP and non-IP 3GPP Rel.13 specifications and onward describe the use of IP and non-
protocols to establish logical/session connectivity. We can leverage IP protocols to establish logical/session connectivity. We can
the non-IP protocol-based mechanism to deploy ICN protocol stack in leverage the non-IP protocol-based mechanism to deploy an ICN
the mobile terminal, as well as in eNodeB and mobile gateways (SGW, protocol stack in the mobile terminal as well as in an eNodeB and
PGW). The following paragraphs describe per-layer considerations of Mobile Gateways (SGW/PGW). The following paragraphs describe per-
supporting tunneling of ICN packet into IP or to support ICN layer considerations of supporting the tunneling of ICN packets into
natively. IP or supporting ICN natively.
1. An existing application layer can be modified to provide options 1. An existing application layer can be modified to provide options
for a new ICN-based application and existing IP-based for a new ICN-based application and existing IP-based
applications. The mobile terminal can continue to support applications. The mobile terminal can continue to support
existing IP-based applications or can develop new applications to existing IP-based applications or can develop new applications to
support native ICN, ICNoIP, or IPoICN-based transport. The support native ICN, ICNoIP, or IPoICN-based transport. The
application layer can be provided with an option of selecting application layer can be provided with an option of selecting
either ICN or IP transport, as well as radio interface, to send either ICN or IP transport, as well as radio interface, to send
and receive data traffic. and receive data traffic.
Our proposal is to provide an Application Programming Interface Our proposal is to provide an Application Programming Interface
(API) to the application developers so they can choose either ICN (API) to the application developers so they can choose either ICN
or IP transport for exchanging the traffic with the network. As or IP transport for exchanging the traffic with the network. As
mentioned in Section 5.2, the transport convergence layer (TCL) mentioned in Section 5.2, the TCL function handles the
function handles the interaction of applications with multiple interaction of applications with multiple transport options.
transport options.
2. The transport convergence layer helps determine the type of 2. The transport convergence layer helps determine the type of
transport (such as ICN, hICN, or IP) and type of radio interface transport (such as ICN, hICN, or IP) and type of radio interface
(LTE or WiFi, or both) used to send and receive traffic. (LTE, Wi-Fi, or both) used to send and receive traffic. The
Application layer can make the decision to select a specific application layer can make the decision to select a specific
transport based on preference, such as content location, content transport based on preference such as content location, content
type, content publisher, congestion, cost, QoS, and so on. There type, content publisher, congestion, cost, QoS, and so on. There
can be an Application Programming Interface (API) to exchange can be an API to exchange parameters required for transport
parameters required for transport selection. Southbound selection. Southbound interactions of the TCL will be either to
interactions of Transport Convergence Layer (TCL) will be either IP or to ICN at the network layer.
to IP or ICN at the network layer.
When selecting the IPoICN mode, the TCL is responsible for When selecting the IPoICN mode, the TCL is responsible for
receiving an incoming IP or HTTP packet and publishing the packet receiving an incoming IP or HTTP packet and publishing the packet
to the ICN network under a suitable ICN name (that is, the hash to the ICN network under a suitable ICN name (that is, the hash
over the destination IP address for an IP packet, or the hash over the destination IP address for an IP packet or the hash over
over the FQDN of the HTTP request for an HTTP packet). the FQDN of the HTTP request for an HTTP packet).
In the HTTP case, the TCL can maintain a pending request mapping In the HTTP case, the TCL can maintain a pending request mapping
table to map returning responses to the originating HTTP request. table to map, returning responses to the originating HTTP
The common API will provide a 'connection' abstraction for this request. The common API will provide a "connection" abstraction
HTTP mode of operation, returning the response over said for this HTTP mode of operation, returning the response over said
connection abstraction, akin to the TCP socket interface, while connection abstraction (akin to the TCP socket interface) while
implementing a reliable transport connection semantic over the implementing a reliable transport connection semantic over the
ICN from the mobile terminal to the receiving mobile terminal or ICN from the mobile terminal to the receiving mobile terminal or
the PGW. If the HTTP protocol stack remains unchanged, therefore the PGW. If the HTTP protocol stack remains unchanged, therefore
utilizing the TCP protocol for transfer, the TCL operates in utilizing the TCP protocol for transfer, the TCL operates in
local TCP termination mode, retrieving the HTTP packet through local TCP termination mode, retrieving the HTTP packet through
said local termination. said local termination.
+----------------+ +-----------------+ +----------------+ +-----------------+
| ICN App (new) | |IP App (existing)| | ICN App (new) | |IP App (existing)|
+---------+------+ +-------+---------+ +---------+------+ +-------+---------+
skipping to change at page 23, line 38 skipping to change at line 990
+-----------------+------------------+ +-----------------+------------------+
| |
+-----------------+------------------+ +-----------------+------------------+
| Physical L1 (Existing) | | Physical L1 (Existing) |
+------------------------------------+ +------------------------------------+
Figure 6: Dual Stack ICN Protocol Interactions Figure 6: Dual Stack ICN Protocol Interactions
3. The ICN function (forwarder) is proposed to run in parallel to 3. The ICN function (forwarder) is proposed to run in parallel to
the existing IP layer. The ICN forwarder forwards the ICN the existing IP layer. The ICN forwarder forwards the ICN
packets, such as an Interest packet to eNodeB or a response "data packets such as an Interest packet to an eNodeB or a response
packet" from eNodeB to the application. "data packet" from an eNodeB to the application.
4. For the dual-transport scenario, when mobile terminal is not 4. For the dual-transport scenario, when a mobile terminal is not
supporting ICN as transport, the TCL can use the IP underlay to supporting ICN as transport, the TCL can use the IP underlay to
tunnel the ICN packets. The ICN function can use the IP tunnel the ICN packets. The ICN function can use the IP
interface to send Interest and Data packets for fetching or interface to send Interest and Data packets for fetching or
sending data respectively. This interface can use the ICN sending data, respectively. This interface can use the ICN
overlay over IP. overlay over IP.
5. To support ICN at network layer in mobile terminal, the PDCP 5. To support ICN at the network layer in the mobile terminal, the
layer should be aware of ICN capabilities and parameters. PDCP PDCP layer should be aware of ICN capabilities and parameters.
is located in the Radio Protocol Stack in the LTE Air interface, PDCP is located in the Radio Protocol Stack in the LTE Air
between IP (Network layer) and Radio Link Control Layer (RLC). interface, between the IP (Network layer) and Radio Link Control
PDCP performs the following functions [TS36.323]: Layer (RLC). PDCP performs the following functions [TS36.323]:
1. Data transport by listening to upper layer, formatting and 1. Data transport by listening to the upper layer, formatting,
pushing down to Radio Link Layer (RLC) and pushing down to the RLC
2. Header compression and decompression using Robust Header 2. Header compression and decompression using ROHC
Compression (ROHC)
3. Security protections such as ciphering, deciphering, and 3. Security protections such as ciphering, deciphering, and
integrity protection integrity protection
4. Radio layer messages associated with sequencing, packet drop 4. Radio layer messages associated with sequencing, packet drop
detection and re-transmission, and so on. detection and retransmission, and so on.
6. No changes are required for lower layer such as RLC, MAC, and 6. No changes are required for the lower layer such as RLC, Media
Physical (L1) as they are not IP aware. Access Control (MAC), and Physical (L1) as they are not IP aware.
One key point to understand in this scenario is that ICN is deployed One key point to understand in this scenario is that ICN is deployed
as an overlay on top of IP. as an overlay on top of IP.
5.4.2. Using ICN in Mobile Terminal 5.4.2. Using ICN in Mobile Terminal
We can implement ICN natively in mobile terminal by modifying the We can implement ICN natively in the mobile terminal by modifying the
PDCP layer in 3GPP protocols. Figure 7 provides a high-level PDCP layer in 3GPP protocols. Figure 7 provides a high-level
protocol stack description where ICN can be used at the following protocol stack description where ICN can be used at the following
different layers: different layers:
1. User plane communication 1. User-plane communication
2. Transport layer 2. Transport layer
ICN transport would be a substitute of the GTP protocol. The removal ICN transport would be a substitute for the GTP protocol. The
of the GTP protocol stack is a significant change in the mobile removal of the GTP protocol stack is a significant change in the
architecture and requires a thorough study mainly because it is used mobile architecture and requires a thorough study mainly because it
not just for routing but for mobility management functions, such as is used not just for routing but for mobility management functions
billing, mediation, and policy enforcement. such as billing, mediation, and policy enforcement.
The implementation of ICN natively in the mobile terminal leads to a The implementation of ICN natively in the mobile terminal leads to a
changed communication model between mobile terminal and eNodeB. changed communication model between the mobile terminal and eNodeB.
Also, we can avoid tunneling the user plane traffic from eNodeB to Also, we can avoid tunneling the user-plane traffic from an eNodeB to
the mobile packet core (SGW, PGW) through a GTP tunnel. the mobile packet core (SGW/PGW) through a GTP tunnel.
For native ICN use, an application can be configured to use ICN For native ICN use, an application can be configured to use an ICN
forwarder and it does not need the TCL layer. Also, to support ICN forwarder, and it does not need the TCL layer. Also, to support ICN
at the network layer, the existing PDCP layer may need to be changed at the network layer, the existing PDCP layer may need to be changed
to be aware of ICN capabilities and parameters. to be aware of ICN capabilities and parameters.
The native implementation can provide new opportunities to develop The native implementation can provide new opportunities to develop
new use cases leveraging ICN capabilities, such as seamless mobility, new use cases leveraging ICN capabilities such as seamless mobility,
mobile terminal to mobile terminal content delivery using radio mobile terminal to mobile terminal content delivery using a radio
network without traversing the mobile gateways, and more. network without traversing the Mobile Gateways, and more.
+--------+ +--------+ +--------+ +--------+
| App | | CDN | | App | | CDN |
+--------+ +--------+ +--------+ +--------+
|Transp. | | | | | |Transp. | |Transp. | | | | | |Transp. |
|Converge|.|..............|..............|..............|.|Converge| |Converge|.|..............|..............|..............|.|Converge|
+--------+ | | | | +--------+ +--------+ | | | | +--------+
| |.|..............|..............|..............|.| | | |.|..............|..............|..............|.| |
| ICN/IP | | | | | | | | ICN/IP | | | | | | |
| | | | | | | | | | | | | | | |
skipping to change at page 25, line 41 skipping to change at line 1081
+--------+ | +----------+ | +----------+ | +----------+ | +--------+ +--------+ | +----------+ | +----------+ | +----------+ | +--------+
| L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 |
+--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+
MT | BS(eNodeB) | SGW | PGW | MT | BS(eNodeB) | SGW | PGW |
Uu S1u S5/S8 SGi Uu S1u S5/S8 SGi
Figure 7: Using Native ICN in Mobile Terminal Figure 7: Using Native ICN in Mobile Terminal
5.4.3. Using ICN in eNodeB 5.4.3. Using ICN in eNodeB
The eNodeB is a physical point of attachment for the mobile terminal, The eNodeB is a physical point of attachment for the mobile terminal
where radio protocols are converted into IP transport protocol for where radio protocols are converted into IP transport protocols for
dual transport/overlay and native ICN, respectively (see Figure 6 and dual transport/overlay and native ICN, respectively (see Figures 6
Figure 7). When a mobile terminal performs an attach procedure, it and 7). When a mobile terminal performs an attach procedure, it will
would be assigned an identity either as IP or dual transport (IP and be assigned an identity as either IP or dual transport (IP and ICN)
ICN), or ICN endpoint. Mobile terminal can initiate data traffic or ICN endpoint. A mobile terminal can initiate data traffic using
using any of the following options: any of the following options:
1. Native IP (IPv4 or IPv6) 1. Native IP (IPv4 or IPv6)
2. Native ICN 2. Native ICN
3. Dual transport IP (IPv4/IPv6) and ICN 3. Dual transport IP (IPv4/IPv6) and ICN
The mobile terminal encapsulates a user data transport request into The mobile terminal encapsulates a user data transport request into
PDCP layer and sends the information on the air interface to eNodeB, the PDCP layer and sends the information on the air interface to the
which in turn receives the information and, using PDCP [TS36.323], eNodeB, which in turn receives the information and, using PDCP
de-encapsulates the air-interface messages and converts them to [TS36.323], de-encapsulates the air-interface messages and converts
forward to core mobile gateways (SGW, PGW). As shown in Figure 8, to them to forward-to-core Mobile Gateways (SGW/PGW). As shown in
support ICN natively in eNodeB, it is proposed to provide transport Figure 8, to support ICN natively in an eNodeB, it is proposed to
convergence layer (TCL) capabilities in eNodeB (similar to as provide TCL capabilities in an eNodeB (similar to as provided in MT),
provided in MT), which provides the following functions: which provides the following functions:
1. It decides the forwarding strategy for a user data request coming 1. It decides the forwarding strategy for a user data request coming
from mobile terminal. The strategy can decide based on from the mobile terminal. The strategy can decide based on
preference indicated by the application, such as congestion, preference indicated by the application, such as congestion,
cost, QoS, and so on. cost, QoS, and so on.
2. eNodeB to provide open Application Programming Interface (API) to 2. It uses an eNodeB to provide an open API to external management
external management systems, to provide capability to eNodeB to systems in order to provide eNodeB the capability to program the
program the forwarding strategies. forwarding strategies.
+---------------+ | +---------------+ |
| MT request | | ICN +---------+ | MT request | | ICN +---------+
+---->| content using |--+--- transport -->| | +---->| content using |--+--- transport -->| |
| |ICN protocol | | | | | |ICN protocol | | | |
| +---------------+ | | | | +---------------+ | | |
| | | | | | | |
| +---------------+ | | | | +---------------+ | | |
+-+ | | MT request | | IP |To mobile| +-+ | | MT request | | IP |To mobile|
| |-+---->| content using |--+--- transport -->| GW | | |-+---->| content using |--+--- transport -->| GW |
+-+ | | IP protocol | | |(SGW,PGW)| +-+ | | IP protocol | | |(SGW/PGW)|
MT | +---------------+ | | | MT | +---------------+ | | |
| | | | | | | |
| +---------------+ | | | | +---------------+ | | |
| | MT request | | Dual stack | | | | MT request | | Dual stack | |
+---->| content using |--+--- IP+ICN -->| | +---->| content using |--+--- IP+ICN -->| |
|IP/ICN protocol| | transport +---------+ |IP/ICN protocol| | transport +---------+
+---------------+ | +---------------+ |
eNodeB S1u eNodeB S1u
Figure 8: Integration of Native ICN in eNodeB Figure 8: Integration of Native ICN in eNodeB
3. eNodeB can be upgraded to support three different types of 3. The eNodeB can be upgraded to support three different types of
transport: IP, ICN, and dual transport IP+ICN towards mobile transport: IP, ICN, and dual transport IP+ICN towards Mobile
gateways, as depicted in Figure 8. It is also proposed to deploy Gateways, as depicted in Figure 8. It is also proposed to deploy
IP and/or ICN forwarding capabilities into eNodeB, for efficient IP and/or ICN forwarding capabilities into an eNodeB for
transfer of data between eNodeB and mobile gateways. Following efficient transfer of data between the eNodeB and Mobile
are choices for forwarding a data request towards mobile Gateways. The following are choices for forwarding a data
gateways: request towards Mobile Gateways:
1. Assuming eNodeB is IP enabled and the MT requests an IP 1. Assuming the eNodeB is IP enabled and the MT requests an IP
transfer, eNodeB forwards data over IP. transfer, the eNodeB forwards data over IP.
2. Assuming eNodeB is ICN enabled and the MT requests an ICN 2. Assuming the eNodeB is ICN enabled and the MT requests an ICN
transfer, eNodeB forwards data over ICN. transfer, the eNodeB forwards data over ICN.
3. Assuming eNodeB is IP enabled and the MT requests an ICN 3. Assuming the eNodeB is IP enabled and the MT requests an ICN
transfer, eNodeB overlays ICN on IP and forwards user plane transfer, the eNodeB overlays ICN on IP and forwards user-
traffic over IP. plane traffic over IP.
4. Assuming eNodeB is ICN enabled and the MT requests an IP 4. Assuming the eNodeB is ICN enabled and the MT requests an IP
transfer, eNodeB overlays IP on ICN and forwards user plane transfer, the eNodeB overlays IP on ICN and forwards user-
traffic over ICN [IPoICN]. plane traffic over ICN [IPoICN].
5.4.4. Using ICN in Packet Core (SGW, PGW) Gateways 5.4.4. Using ICN in Packet Core Gateways (SGW/PGW)
Mobile gateways (a.k.a. Evolved Packet Core (EPC)) include SGW, PGW, Mobile Gateways (a.k.a. Evolved Packet Core (EPC)) include SGW and
which perform session management for MT from the initial attach to PGW, which perform session management for MT from the initial attach
disconnection. When MT is powered on, it performs NAS signaling and to disconnection. When MT is powered on, it performs Network-Access-
attaches to PGW after successful authentication. PGW is an anchoring Stratum (NAS) signaling and attaches to PGW after successful
point for MT and responsible for service creations, authorization, authentication. PGW is an anchoring point for MT and is responsible
maintenance, and so on. The Entire functionality is managed using IP for service creations, authorization, maintenance, and so on. The
address(es) for MT. entire functionality is managed using an IP address(es) for MT.
To implement ICN in EPC, the following functions are proposed: To implement ICN in EPC, the following functions are proposed:
1. Insert ICN attributes in session management layer as additional 1. Insert ICN attributes in the session management layer for
functionality with IP stack. Session management layer is used additional functionality with IP stack. The session management
for performing attach procedures and assigning logical identity layer is used for performing attach procedures and assigning
to user. After successful authentication by HSS, MME sends a logical identity to users. After successful authentication by
create session request (CSR) to SGW and SGW to PGW. HSS, MME sends a Create Session Request (CSR) to SGW and SGW to
PGW.
2. When MME sends Create Session Request message (Step 12 in 2. When MME sends a Create Session Request message (Step 12 in
[TS23.401]) to SGW or PGW, it includes a Protocol Configuration [TS23.401]) to SGW or PGW, it includes a Protocol Configuration
Option Information Element (PCO IE) containing MT capabilities. Option (PCO) Information Element (IE) containing MT capabilities.
We can use PCO IE to carry ICN-related capabilities information We can use PCO IE to carry ICN-related capabilities information
from MT to PGW. This information is received from MT during the from MT to PGW. This information is received from MT during the
initial attach request in MME. Details of available TLV, which initial attach request in MME. Details of available TLV, which
can be used for ICN, are given in subsequent sections. MT can can be used for ICN, are given in subsequent sections. MT can
support either native IP, ICN+IP, or native ICN. IP is referred support native IP, ICN+IP, or native ICN. IP is referred to as
to as both IPv4 and IPv6 protocols. both IPv4 and IPv6 protocols.
3. For ICN+IP-capable MT, PGW assigns the MT both an IP address and 3. For ICN+IP-capable MT, PGW assigns the MT both an IP address and
ICN identity. MT selects either of the identities during the ICN identity. MT selects either of the identities during the
initial attach procedures and registers with the network for initial attach procedures and registers with the network for
session management. For ICN-capable MT, it will provide only ICN session management. For ICN-capable MT, it will provide only ICN
attachment. For native IP-capable MT, there is no change. attachment. For native IP-capable MT, there is no change.
4. To support ICN-capable attach procedures and use ICN for user 4. To support ICN-capable attach procedures and use ICN for user-
plane traffic, PGW needs to have full ICN protocol stack plane traffic, PGW needs to have full ICN protocol stack
functionalities. Typical ICN capabilities include functions such functionalities. Typical ICN capabilities include functions such
as content store (CS), Pending Interest Table (PIT), Forwarding as CS, PIT, FIB capabilities, and so on. If MT requests ICN in
Information Base (FIB) capabilities, and so on. If MT requests PCO IE, then PGW registers MT with ICN names. For ICN
ICN in PCO IE, then PGW registers MT with ICN names. For ICN
forwarding, PGW caches content locally using CS functionality. forwarding, PGW caches content locally using CS functionality.
5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598) 5. PCO IE as described in [TS24.008] (see Figure 10.5.136 on page
and [TS24.008] (see Table 10.5.154 on page 599) provide details 656 and Table 10.5.154 on page 659) provides details for
for different fields. different fields.
1. Octet 3 (configuration protocols define PDN types), which 1. Octet 3 (configuration protocols define PDN types), which
contains details about IPv4, IPv6, both or ICN. contains details about IPv4, IPv6, both IPv4 and IPv6, or
ICN.
2. Any combination of Octet 4 to Z can be used to provide 2. Any combination of Octet 4 to Z can be used to provide
additional information related to ICN capability. It is most additional information related to ICN capability. It is most
important that PCO IE parameters are matched between MT and important that PCO IE parameters are matched between MT and
mobile gateways (SGW, PGW) so they can be interpreted Mobile Gateways (SGW/PGW) so they can be interpreted properly
properly and the MT can attach successfully. and the MT can attach successfully.
6. The ICN functionalities in SGW and PGW should be matched with MT 6. The ICN functionalities in SGW and PGW should be matched with MT
and eNodeB because they will exchange ICN protocols and and the eNodeB because they will exchange ICN protocols and
parameters. parameters.
7. Mobile gateways SGW, PGW will also need ICN forwarding and 7. Mobile Gateways (SGW/PGW) will also need ICN forwarding and
caching capability. This is especially important if CUPS is caching capability. This is especially important if CUPS is
implemented. User Plane Function (UPF), comprising the SGW and implemented. User Plane Function (UPF), comprising the SGW and
PGW user plane, will be located at the edge of the network and PGW user plane, will be located at the edge of the network and
close to the end user. ICN-enabled gateway means that this UPF close to the end user. ICN-enabled gateway means that this UPF
would serve as a forwarder and should be capable of caching, as would serve as a forwarder and should be capable of caching, as
is the case with any other ICN-enabled node. is the case with any other ICN-enabled node.
8. The transport between PGW and CDN provider can be either IP or 8. The transport between PGW and CDN provider can be either IP or
ICN. When MT is attached to PGW with ICN identity and ICN. When MT is attached to PGW with ICN identity and
communicates with an ICN-enabled CDN provider, it will use ICN communicates with an ICN-enabled CDN provider, it will use ICN
primitives to fetch the data. On the other hand, for a MT primitives to fetch the data. On the other hand, for an MT
attached with an ICN identity, if PGW must communicate with an IP attached with an ICN identity, if PGW must communicate with an
enabled CDN provider, it will have to use an ICN-IP interworking IP-enabled CDN provider, it will have to use an ICN-IP
gateway to perform conversion between ICN and IP primitives for interworking gateway to perform conversion between ICN and IP
data retrieval. In the case of CUPS implementation with an primitives for data retrieval. In the case of CUPS
offload close to the edge, this interworking gateway can be implementation with an offload close to the edge, this
collocated with the UPF at the offload site to maximize the path interworking gateway can be collocated with the UPF at the
optimization. Further study is required to understand how this offload site to maximize the path optimization. Further study is
ICN-to-IP (and vice versa) interworking gateway would function. required to understand how this ICN-to-IP (and vice versa)
interworking gateway would function.
5.5. An Experimental Test Setup 5.5. An Experimental Test Setup
This section proposes an experimental lab setup and discusses the This section proposes an experimental lab setup and discusses the
open issues and questions that use of ICN protocol is intended to open issues and questions that use of the ICN protocol is intended to
address. To further test the modifications proposed in different address. To further test the modifications proposed in different
scenarios, a simple lab can be set up, as shown in Figure 9. scenarios, a simple lab can be set up, as shown in Figure 9.
+------------------------------------------+ +------------------------------------------+
| +-----+ +------+ (```). +------+ | (````). +-----+ | +-----+ +------+ (```). +------+ | (````). +-----+
| | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN | | | SUB |-->| EMU |--(x-haul'.-->| EPC |--->( PDN ).-->| CDN |
| +-----+ +------+ `__..'' +------+ | `__...' +-----+ | +-----+ +------+ `__..'' +------+ | `__...' +-----+
+------------------------------------------+ +------------------------------------------+
4G Mobile Network Functions 4G Mobile Network Functions
Figure 9: Native ICN Deployment Lab Setup Figure 9: Native ICN Deployment Lab Setup
The following test scenarios can be set up with VM-based deployment: The following test scenarios can be set up with deployment based on
Virtual Machine (VM):
1. SUB: ICN simulated client (using ndnSIM), a client application on 1. SUB: An ICN-simulated client (using ndnSIM) - a client
workstation requesting content. application on a workstation requesting content.
2. EMU: test unit emulating eNodeB. This will be a test node 2. EMU: Test unit emulating an eNodeB. This is a test node allowing
allowing for UE attachment and routing traffic subsequently from for UE attachment and routing traffic subsequently from the
the Subscriber to the Publisher. Subscriber to the Publisher.
3. EPC: Evolved Packet Core in a single instance (such as 5GOpenCore 3. EPC: Evolved Packet Core in a single instance (such as Open5GCore
[Open5GCore]). [Open5GCore]).
4. CDN: content delivery by a Publisher server. 4. CDN: Content delivery by a Publisher server.
For the purpose of this testing, ICN emulating code can be inserted For the purpose of this testing, ICN-emulating code can be inserted
in the test code in EMU to emulate ICN-capable eNodeB. An example of in the test code in EMU to emulate an ICN-capable eNodeB. An example
the code to be used is NS3 in its LTE model. Effect of such traffic of the code to be used is NS3 in its LTE model. The effect of such
on EPC and CDN can be observed and documented. In a subsequent traffic on EPC and CDN can be observed and documented. In a
phase, EPC code supporting ICN can be tested when available. subsequent phase, EPC code supporting ICN can be tested when
available.
Another option is to simulate the UE/eNodeB and EPC functions using Another option is to simulate the UE/eNodeB and EPC functions using
NS3's LTE [NS3LTE] and EPC [NS3EPC] models respectively. LTE model NS3's LTE [NS3LTE] and EPC [NS3EPC] models, respectively. The LTE
includes the LTE Radio Protocol stack, which resides entirely within model includes the LTE Radio Protocol stack, which resides entirely
the UE and the eNodeB nodes. This capability provides the simulation within the UE and the eNodeB nodes. This capability provides the
of UE and eNodeB deployment use cases. Similarly, EPC model includes simulation of UE and eNodeB deployment use cases. Similarly, the EPC
core network interfaces, protocols, and entities, which reside within model includes core network interfaces, protocols, and entities,
the SGW, PGW and MME nodes, and partially within the eNodeB nodes. which reside within the Mobile Gateways (SGW/PGW), and MME nodes and
partially within the eNodeB nodes.
Even with its current limitations (such as IPv4 only, lack of Even with its current limitations (such as IPv4 only, lack of
integration with ndnSIM, no support for UE idle state), LTE integration with ndnSIM, and no support for UE idle state), LTE
simulation may be a very useful tool. In any case, both control and simulation may be a very useful tool. In any case, both control and
user plane traffic should be tested independently according to the user-plane traffic should be tested independently according to the
deployment model discussed in Section 5.4. deployment model discussed in Section 5.4.
6. Expected Outcomes from Experimentation 6. Expected Outcomes from Experimentation
The experimentations explained in Section 5 can be categorized in The experimentation explained in Section 5 can be categorized in
three broader scopes as follows. Note that, a further research and three broader scopes as follows. Note that further research and
study is required to fully understand and document the impact. study is required to fully understand and document the impact.
1. Architecture scope: to study the aspect of use of ICN at user Architecture scope: to study the aspect of use of ICN at the user
plane to reduce the complexities in current transport protocols, plane to reduce the complexities in current transport protocols
while also evaluating its use in the control plane. while also evaluating its use in the control plane.
2. Performance scope: to evaluate the gains through multicast, Performance scope: to evaluate the gains through multicast, caching,
caching, and other ICN features. and other ICN features.
3. Deployment scope: to check the viability of the ICN inclusion in Deployment scope: to check the viability of ICN inclusion in the
3GPP protocol stack and its viability in real-world deployments. 3GPP protocol stack and in real-world deployments.
6.1. Feeding into ICN Research 6.1. Feeding into ICN Research
Specifically, we have identified the following open questions, from Specifically, we have identified the following open questions, from
the architectural and performance perspective, that the proposed the architectural and performance perspective, that the proposed
experiments with ICN implementation scenarios in 4G mobile networks experiments with ICN implementation scenarios in 4G mobile networks
could address in further research: could address in further research:
1. Efficiency gains in terms of the amount of traffic in multicast 1. Efficiency gains in terms of the amount of traffic in multicast
scenarios (i.e., quantify the possible gains along different use scenarios (i.e., quantify the possible gains along different use
cases) and the efficiency gained in terms of latency for cached cases) and latency for cached content, mainly in the CDN use
content, mainly in the CDN use case. case.
2. How the new transport would coexist or replace the legacy 2. How the new transport would coexist or replace the legacy
transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and transport protocols (e.g., IPv4, IPv6, MPLS, RSVP, etc.) and
related services (e.g., bandwidth management, QoS handling, related services (e.g., bandwidth management, QoS handling,
etc.). etc.).
3. To what extent the simplification in the IP-based transport 3. To what extent the simplification in the IP-based transport
protocols will be achieved. The multiple overlays (e.g., the protocols will be achieved. The multiple overlays (e.g., the
MPLS, VPN, VPLS, Ethernet VPN, etc.) of services in the current MPLS, VPN, Virtual Private LAN Service (VPLS), Ethernet VPN,
IP-based transport adds to the complexity on top of basic IP etc.) of services in the current IP-based transport adds to the
transport. This makes the troubleshooting extremely challenging. complexity on top of basic IP transport. This makes the
troubleshooting extremely challenging.
4. How the new transport can become service-aware such that it 4. How the new transport can become service aware such that it
brings in more simplicity in the system. brings in more simplicity in the system.
5. Confirm how (in)adequate would be ICN implementation in control 5. Confirm how (in)adequate ICN implementation would be in the
plane (which this draft discourages). Given that the 5G system, control plane (which this document discourages). Given that the
as specified in [TS23.501] (Appendix G.4), encourages the use of 5G system, as specified in [TS23.501] (Appendix G.4), encourages
name-based routing in (5G) control plane for realizing the 5G- the use of name-based routing in the (5G) control plane for
specific service-based architecture for control plane services realizing the 5G-specific service-based architecture for control
(so-called network function service), it would be worthwhile to plane services (so-called network function service), it would be
investigate whether the 4G control plane would benefit similarly worthwhile to investigate whether the 4G control plane would
from such use or whether specific 4G architectural constraints benefit similarly from such use or whether specific 4G
would prevent ICN from providing any notable benefit. architectural constraints would prevent ICN from providing any
notable benefit.
6.2. Use of Results Beyond Research 6.2. Use of Results Beyond Research
With the experiments and their outcomes outlined in this draft, we With the experiments and their outcomes outlined in this document, we
believe that this technology is ready for a wider use and adoption, believe that this technology is ready for a wider use and adoption,
providing additional insights. Specifically, we expect to study the providing additional insights. Specifically, we expect to study the
following: following:
1. Viability of ICN inclusion in the 3GPP protocol stack, i.e., 1. Viability of ICN inclusion in the 3GPP protocol stack, i.e.,
investigate how realistic it would be to modify the stack, investigating how realistic it would be to modify the stack,
considering the scenarios explained in Section 5.4, and complete considering the scenarios explained in Section 5.4, and
the user session without feature degradation? completing the user session without feature degradation.
2. Viability of utilizing solutions in greenfield deployments, i.e., 2. Viability of utilizing solutions in greenfield deployments, i.e.,
deploying the ICN-based extensions and solutions proposed in this deploying the ICN-based extensions and solutions proposed in this
draft in greenfield 4G deployments in order to assess real-world document in greenfield 4G deployments in order to assess real-
benefits when doing so. world benefits when doing so.
7. Security and Privacy Considerations 7. IANA Considerations
This document has no IANA actions.
8. Security and Privacy Considerations
This section will cover some security and privacy considerations in This section will cover some security and privacy considerations in
mobile and 4G network because of introduction of ICN. mobile and 4G networks because of the introduction of ICN.
7.1. Security Considerations 8.1. Security Considerations
To ensure only authenticated mobile terminals are connected to the To ensure only authenticated mobile terminals are connected to the
network, 4G mobile network implements various security mechanisms. network, 4G mobile networks implement various security mechanisms.
From the perspective of using ICN in the user plane, it needs to take From the perspective of using ICN in the user plane, the following
care of the following security aspects: security aspects need to be taken care of:
1. MT authentication and authorization 1. MT authentication and authorization
2. Radio or air interface security 2. Radio or air interface security
3. Denial of service attacks on the mobile gateway, services either 3. Denial-of-service attacks on the Mobile Gateway; services are
by the MT or by external entities in the Internet either by the MT or by external entities in the Internet
4. Content poisoning either in transport or servers 4. Content poisoning in either transport or servers
5. Content cache pollution attacks 5. Content cache pollution attacks
6. Secure naming, routing, and forwarding 6. Secure naming, routing, and forwarding
7. Application security 7. Application security
Security over the LTE air interface is provided through cryptographic Security over the LTE air interface is provided through cryptographic
techniques. When MT is powered up, it performs a key exchange techniques. When MT is powered up, it performs a key exchange
between MT's USIM and HSS/Authentication Center using NAS messages, between the MT's Universal Mobile Telecommunications System
including ciphering and integrity protections between MT and MME. Subscriber Identity Module (USIM) and HSS/Authentication Center using
Details for secure MT authentication, key exchange, ciphering, and NAS messages, including ciphering and integrity protections between
integrity protections messages are given in the 3GPP call flow MT and MME. Details for secure MT authentication, key exchange,
[TS23.401]. With ICN we are modifying protocol stack for user plane ciphering, and integrity protection messages are given in the 3GPP
and not control plane. The NAS signaling is exchanged between MT and call flow [TS23.401]. With ICN, we are modifying the protocol stack
mobile gateways e.g. MME, using control plane, therefore there is no for the user plane and not the control plane. The NAS signaling is
adverse impact of ICN on MT. exchanged between MT and Mobile Gateways, e.g., MME, using the
control plane; therefore, there is no adverse impact of ICN on MT.
4G uses IP transport in its mobile backhaul (between eNodeB and core 4G uses IP transport in its mobile backhaul (between an eNodeB and
network). In case of provider-owned backhaul, service provider may the core network). In case of provider-owned backhaul, the Service
require implementing a security mechanism in the backhaul network. Provider may require implementing a security mechanism in the
The native IP transport continues to leverage security mechanism such backhaul network. The native IP transport continues to leverage
as Internet key exchange (IKE) and the IP security protocol (IPsec). security mechanisms such as Internet Key Exchange (IKE) and the IP
More details of mobile backhaul security are provided in 3GPP network Security (IPsec) protocol. More details of mobile backhaul security
security specifications [TS33.310] and [TS33.320]. When mobile are provided in 3GPP network security specifications [TS33.310] and
backhaul is upgraded to support dual transport (IP+ICN) or native [TS33.320]. When a mobile backhaul is upgraded to support dual
ICN, it is required to implement security techniques that are transport (IP+ICN) or native ICN, it is required to implement
deployed in the mobile backhaul. When ICN forwarding is enabled on security techniques that are deployed in the mobile backhaul. When
mobile transport routers, we need to deploy security practices based ICN forwarding is enabled on mobile transport routers, we need to
on [RFC7476] and [RFC7927]. deploy security practices based on [RFC7476] and [RFC7927].
4G mobile gateways (SGW, PGW) perform some of key functions such as 4G Mobile Gateways (SGW/PGW) perform some key functions such as
content based online/offline billing and accounting, deep packet content-based online/offline billing and accounting, deep packet
inspection (DPI), and lawful interception (LI). When ICN is deployed inspection (DPI), and lawful interception (LI). When ICN is deployed
in user plane , we need to integrate ICN security for sessions in the user plane, we need to integrate ICN security for sessions
between MT and gateway. If we encrypt user plane payload metadata between MT and the gateway. If we encrypt user-plane payload
then it might be difficult to perform routing based on contents and metadata, then it might be difficult to perform routing based on
it may not work because we need decryption keys at every forwarder to contents and it may not work because we need decryption keys at every
route the content. The content itself can be encrypted between forwarder to route the content. The content itself can be encrypted
publisher and consumer to ensure privacy. Only the user with right between publisher and consumer to ensure privacy. Only the user with
decryption key shall be able to access the content. We need further the right decryption key shall be able to access the content. We
research for ICN impact on LI, online/offline charging and need further research for ICN impact on LI, online/offline charging,
accounting. and accounting.
7.2. Privacy Considerations 8.2. Privacy Considerations
In 4G networks, two main privacy issues are [MUTHANA] In 4G networks, there are two main privacy issues [MUTHANA]:
1. User Identity Privacy Issues. The main privacy issue within the 1. User Identity Privacy Issues. The main privacy issue within 4G
4G is the exposure of the IMSI. The IMSI can be intercepted by is the exposure of the International Mobile Subscriber Identity
adversaries. Such attacks are commonly referred to as "IMSI (IMSI). The IMSI can be intercepted by adversaries. Such
catching". attacks are commonly referred to as "IMSI catching".
2. Location Privacy Issues. IMSI Catching is closely related to the 2. Location Privacy Issues. IMSI catching is closely related to the
issue of location privacy. Knowing IMSI of user allows the issue of location privacy. Knowing the IMSI of a user allows the
attacker to track the user's movements and create profile about attacker to track the user's movements and create a profile about
the user and thus breaches the user's location privacy. the user and thus breach the user's location privacy.
In any network, caching implies a trade-off between network In any network, caching implies a trade-off between network
efficiency and privacy. The activity of users is exposed to the efficiency and privacy. The activity of users is exposed to the
scrutiny of cache owners with whom they may not have any scrutiny of cache owners with whom they may not have any
relationship. By monitoring the cache transactions, an attacker relationship. By monitoring the cache transactions, an attacker
could obtain significant information related to the objects accessed, could obtain significant information related to the objects accessed,
topology and timing of the requests [RFC7945]. Privacy concerns are topology, and timing of the requests [RFC7945]. Privacy concerns are
amplified by the introduction of new network functions such as amplified by the introduction of new network functions such as
Information lookup and Network storage, and different forms of information lookup and network storage, and different forms of
communication [FOTIOU]. Privacy risks in ICN can be broadly divided communication [FOTIOU]. Privacy risks in ICN can be broadly divided
in the following categories [TOURANI]: in the following categories [TOURANI]:
1. Timing attack 1. Timing attack
2. Communication monitoring attack 2. Communication monitoring attack
3. Censorship and anonymity attack 3. Censorship and anonymity attack
4. Protocol attack 4. Protocol attack
5. Naming-signature privacy 5. Naming-signature privacy
Introduction of TCL effectively enables ICN at the application and/or
transport layer, depending on the scenario described in section 5.
Enabling ICN in 4G networks is expected to increase efficiency by
taking advantage of ICN's inherent characteristics. This approach
would potentially leave some of the above-mentioned privacy concerns
open as a consequence of using ICN transport and ICN inherent privacy
vulnerabilities.
1. IPoIP Section 5.2 would not be affected as TCL has no role in it The introduction of TCL effectively enables ICN at the application
and ICN does not apply and/or transport layer depending on the scenario described in
Section 5. Enabling ICN in 4G networks is expected to increase
efficiency by taking advantage of ICN's inherent characteristics.
This approach would potentially leave some of the above-mentioned
privacy concerns open as a consequence of using ICN transport and ICN
inherent privacy vulnerabilities.
2. ICNoICN scenario Section 5.2 has increased risk of a privacy 1. IPoIP (Section 5.2) would not be affected as TCL has no role in
attack, and that risk is applicable to ICN protocol in general it, and ICN does not apply.
rather than specifically to the 4G implementation. Since this
scenario describes communication over ICN transport, every
forwarder in the path could be a potential risk for privacy
attack
3. ICNoIP scenario Section 5.2 uses IP for transport, so the only 2. The ICNoICN scenario (Section 5.2) has increased risk of a
additional ICN-related potential privacy risk areas are the privacy attack, and that risk is applicable to the ICN protocol
in general rather than specifically to the 4G implementation.
Since this scenario describes communication over ICN transport,
every forwarder in the path could be a potential risk for a
privacy attack.
3. The ICNoIP scenario (Section 5.2) uses IP for transport, so the
only additional ICN-related potential privacy risk areas are the
endpoints (consumer and publisher) where, at the application endpoints (consumer and publisher) where, at the application
layer, content is being served layer, content is being served.
4. IPoICN scenario Section 5.2 could have potentially increased risk 4. The IPoICN scenario (Section 5.2) could have potentially
due to possible vulnerability of the forwarders in the path of increased risk due to possible vulnerability of the forwarders in
ICN transport the path of ICN transport.
Privacy issues already identified in 4G remain a concern if ICN is Privacy issues already identified in 4G remain a concern if ICN is
introduced in any of the scenarios described earlier and compound to introduced in any of the scenarios described earlier and compounds to
the new, ICN-related privacy issues. Many research papers have been the new ICN-related privacy issues. Many research papers have been
published proposing solutions to the privacy issues listed above. published that propose solutions to the privacy issues listed above.
For LTE-specific privacy issues, some of the proposed solutions For LTE-specific privacy issues, some of the proposed solutions
[MUTHANA] are IMSI encryption by a MT, mutual authentication, [MUTHANA] are IMSI encryption by an MT; mutual authentication;
concealing the real IMSI within a random bit stream of certain size concealing the real IMSI within a random bit stream of certain size
where only the subscriber and HSS could extract the respective IMSI, where only the subscriber and HSS could extract the respective IMSI;
IMSI replacement with a changing pseudonym that only the HSS server IMSI replacement with a changing pseudonym that only the HSS server
can map it the UE's IMSI, and others. Similarly, some of the can map to the UE's IMSI; and others. Similarly, some of the
proposed ICN-specific privacy concerns mitigation methods, applicable proposed ICN-specific privacy concerns mitigation methods, applicable
where ICN transport is introduced as specified earlier in this where ICN transport is introduced as specified earlier in this
section, include [FOTIOU]: section, include the following [FOTIOU]:
* Delay for the first, or first k interests on edge routers (timing * Delay for the first, or first k, interests on edge routers (timing
attack) attack)
* Creating a secure tunnel or clients flagging the requests as non- * Creating a secure tunnel or clients flagging the requests as non-
cacheable for privacy (communication monitoring attack) cacheable for privacy (communication monitoring attack)
* Encoding interest by mixing content and cover file or using * Encoding interest by mixing the content and cover file or using a
hierarchical DNS-based brokering model (censorship and anonymity hierarchical DNS-based brokering model (censorship and anonymity
attack) attack)
* Use of rate-limiting requests for a specific namespace (protocol * Use of rate-limiting requests for a specific namespace (protocol
attack) attack)
* Cryptographic content hash-based naming or digital identity in an * Cryptographic content hash-based naming or digital identity in an
overlay network (naming-signature privacy) overlay network (naming-signature privacy)
Further research in this area is needed. Detailed discussion of Further research in this area is needed. Detailed discussion of
privacy is beyond the scope of this document. privacy is beyond the scope of this document.
8. Summary 9. Summary
In this draft, we have discussed the 4G networks and the experimental In this document, we have discussed 4G networks and the experimental
setups to study the advantages of potential use of ICN for efficient setups to study the advantages of the potential use of ICN for
delivery of contents to mobile terminals. We have discussed efficient delivery of contents to mobile terminals. We have
different options to try and test the ICN and dependencies such as discussed different options to try and test ICN and dependencies such
ICN functionalities and changes required in different 4G network as ICN functionalities and changes required in different 4G network
elements. In order to further explore potential use of ICN one can elements. In order to further explore potential use of ICN, one can
devise an experimental set-up consisting of 4G network elements and devise an experimental setup consisting of 4G network elements and
deploy ICN data transport in user plane. Different options can be deploy ICN data transport in the user plane. Different options can
either overlay, dual transport (IP + ICN), hICN, or natively (by be overlay, dual transport (IP + ICN), hICN, or natively (by
integrating ICN with CDN, eNodeB, SGW, PGW and transport network). integrating ICN with CDN, eNodeB, SGW, PGW, and a transport network).
Note that, for the scenarios discussed above, additional study is Note that, for the scenarios discussed above, additional study is
required for lawful interception, billing/mediation, network slicing, required for lawful interception, billing/mediation, network slicing,
and provisioning APIs. and provisioning APIs.
Edge Computing [CHENG] provides capabilities to deploy Edge Computing [CHENG] provides capabilities to deploy
functionalities such as Content Delivery Network (CDN) caching and functionalities such as CDN caching and mobile user plane functions
mobile user plane functions (UPF) [TS23.501]. Recent research for (UPFs) [TS23.501]. Recent research for delivering real-time video
delivering real-time video content [MPVCICN] using ICN has also been content [MPVCICN] using ICN has also been proven to be efficient
proven to be efficient [NDNRTC] and can be used towards realizing the [NDNRTC] and can be used towards realizing the benefits of using ICN
benefits of using ICN in eNodeB, edge computing, mobile gateways in an eNodeB, edge computing, Mobile Gateways (SGW/PGW), and CDN.
(SGW, PGW) and CDN. The key aspect for ICN is in its seamless The key aspect for ICN is in its seamless integration in 4G and 5G
integration in 4G and 5G networks with tangible benefits so we can networks with tangible benefits so we can optimize content delivery
optimize content delivery using a simple and scalable architecture. using a simple and scalable architecture. The authors will continue
The authors will continue to explore how ICN forwarding in edge to explore how ICN forwarding in edge computing could be used for
computing could be used for efficient data delivery from the mobile efficient data delivery from the mobile edge.
edge.
Based on our study of control plane signaling, it is not beneficial Based on our study of control plane signaling, it is not beneficial
to deploy ICN with existing protocols unless further changes are to deploy ICN with existing protocols unless further changes are
introduced in the control protocol stack itself. introduced in the control protocol stack itself.
As a starting step towards use of ICN in user plane, it is proposed As a starting step towards use of ICN in the user plane, it is
to incorporate protocol changes in MT, eNodeB, SGW/PGW for data proposed to incorporate protocol changes in MT, an eNodeB, and SGW/
transport. ICN has inherent capabilities for mobility and content PGW for data transport. ICN has inherent capabilities for mobility
caching, which can improve the efficiency of data transport for and content caching, which can improve the efficiency of data
unicast and multicast delivery. The authors welcome contributions transport for unicast and multicast delivery. The authors welcome
and suggestions, including those related to further validations of contributions and suggestions, including those related to further
the principles by implementing prototype and/or proof of concept in validations of the principles by implementing prototypes and/or proof
the lab and in the production environment. of concepts in the lab and in the production environment.
9. Acknowledgements
We thank all contributors, reviewers, and the chairs for the valuable
time in providing comments and feedback that helped improve this
draft. We specially want to mention the following members of the
IRTF Information-Centric Networking Research Group (ICNRG), listed in
alphabetical order: Kashif Islam, Thomas Jagodits, Luca Muscariello,
David R. Oran, Akbar Rahman, Martin J. Reed, Thomas C. Schmidt,
and Randy Zhang.
The IRSG review was provided by Colin Perkins.
10. References 10. References
10.1. Normative References 10.1. Normative References
[TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core [TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 15 network protocols; Stage 3", 3GPP TS 24.008 17.7.0, June
December 2005, 2022,
<http://www.3gpp.org/ftp/Specs/html-info/24008.htm>. <https://www.3gpp.org/ftp/Specs/html-info/24008.htm>.
[TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP) [TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 25.323 3.10.0, 18 September 2002, specification", 3GPP TS 25.323 17.0.0, April 2022,
<http://www.3gpp.org/ftp/Specs/html-info/25323.htm>. <https://www.3gpp.org/ftp/Specs/html-info/25323.htm>.
[TS29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General [TS29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunneling Protocol for Control Packet Radio Service (GPRS) Tunnelling Protocol for
plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 25 June Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 17.6.0,
2013, <http://www.3gpp.org/ftp/Specs/html-info/29274.htm>. June 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29274.htm>.
[TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunneling [TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 26 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 17.3.0,
September 2011, June 2022,
<http://www.3gpp.org/ftp/Specs/html-info/29281.htm>. <https://www.3gpp.org/ftp/Specs/html-info/29281.htm>.
[TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Packet Data Convergence Protocol (PDCP) (E-UTRA); Packet Data Convergence Protocol (PDCP)
specification", 3GPP TS 36.323 10.2.0, 3 January 2013, specification", 3GPP TS 36.323 17.1.0, July 2022,
<http://www.3gpp.org/ftp/Specs/html-info/36323.htm>. <https://www.3gpp.org/ftp/Specs/html-info/36323.htm>.
10.2. Informative References 10.2. Informative References
[ALM] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., [ALM] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L.,
Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in
ICN", Proceedings of the 2Nd ACM Conference on ICN", ACM-ICN '15: Proceedings of the 2nd ACM Conference
Information-Centric Networking, ACM-ICN'15, ACM DL, on Information-Centric Networking, pp. 189-190,
pp.189-190, 30 September 2013, DOI 10.1145/2810156.2812601, September 2015,
<https://dl.acm.org/citation.cfm?id=2812601>. <https://dl.acm.org/citation.cfm?id=2812601>.
[BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. [BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E.
Ertekin, "Integrating Header Compression with IPsec", Ertekin, "Integrating Header Compression with IPsec",
MILCOM 2006 - 2006 IEEE Military Communications MILCOM 2006 - 2006 IEEE Military Communications
conference IEEE Xplore DL, pp.1-6, 23 October 2006, conference, pp. 1-6, DOI 10.1109/MILCOM.2006.302503,
October 2006,
<https://ieeexplore.ieee.org/document/4086687>. <https://ieeexplore.ieee.org/document/4086687>.
[CCN] "Content Centric Networking", <http://www.ccnx.org>. [CCN] FD.io, "Cicn", January 2020,
<https://wiki.fd.io/index.php?title=Cicn&oldid=10316>.
[CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric [CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric
network function virtualization over 5g mobile wireless network function virtualization over 5g mobile wireless
networks", IEEE Network Journal vol. 29, number 3, pp. networks", IEEE Network, Vol. 29, Issue 3, pp. 68-74, June
68-74, 1 June 2015, 2015, <https://ieeexplore.ieee.org/document/7113228>.
<https://ieeexplore.ieee.org/document/7113228>.
[EMBMS] Zahoor, K., Bilal, K., Erbad, A., and A. Mohamed, [EMBMS] Zahoor, K., Bilal, K., Erbad, A., and A. Mohamed,
"Service-Less Video Multicast in 5G: Enablers and "Service-Less Video Multicast in 5G: Enablers and
Challenges", IEEE Network vol. 34, no. 3, pp. 270-276, May Challenges", IEEE Network, Vol. 34, Issue 3, pp. 270-276,
2020, <https://ieeexplore.ieee.org/document/9105941>. DOI 10.1109/MNET.001.1900435, June 2020,
<https://ieeexplore.ieee.org/document/9105941>.
[EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and [EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and
User Plane Separation of EPC nodes (CUPS)", 3GPP The User Plane Separation of EPC nodes (CUPS)", 3GPP, The
Mobile Broadband Standard, 3 July 2017, Mobile Broadband Standard, July 2017,
<http://www.3gpp.org/news-events/3gpp-news/1882-cups>. <https://www.3gpp.org/news-events/3gpp-news/1882-cups>.
[FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based [FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based
security", ACM-ICN '14: Proceedings of the 1st ACM security", ACM-ICN '14: Proceedings of the 1st ACM
Conference on Information-Centric Networking ACM Digitial Conference on Information-Centric Networking, pp. 5-6,
Library, pp. 5-6, September 2014, DOI 10.1145/2660129.2666711, September 2014,
<https://dl.acm.org/doi/10.1145/2660129.2666711>. <https://dl.acm.org/doi/10.1145/2660129.2666711>.
[GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic [GALIS] Galis, A., Ed., Makhijani, K., Yu, D., and B. Liu,
Slice Networking", Work in Progress, Internet-Draft, "Autonomic Slice Networking", Work in Progress, Internet-
draft-galis-anima-autonomic-slice-networking-05, 26 Draft, draft-galis-anima-autonomic-slice-networking-05, 26
September 2018, <http://www.ietf.org/internet-drafts/ September 2018, <https://datatracker.ietf.org/doc/html/
draft-galis-anima-autonomic-slice-networking-05.txt>. draft-galis-anima-autonomic-slice-networking-05>.
[GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press [GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "IP Design
book "IP Design for Mobile Networks"", Cisco for Mobile Networks", Cisco Press, Networking Technology
Press Networking Technology series, 15 June 2009, series, ISBN 1-58705-826-X, June 2009,
<http://www.ciscopress.com/store/ip-design-for-mobile- <https://www.ciscopress.com/store/ip-design-for-mobile-
networks-9781587058264>. networks-9781587058264>.
[HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. [HICN] Muscariello, L., Carofiglio, G., Auge, J., and M.
Papalini, "Hybrid Information-Centric Networking", Work in Papalini, "Hybrid Information-Centric Networking", Work in
Progress, Internet-Draft, draft-muscariello-intarea-hicn- Progress, Internet-Draft, draft-muscariello-intarea-hicn-
04, 20 May 2020, <https://www.ietf.org/id/draft- 04, 20 May 2020, <https://datatracker.ietf.org/doc/html/
muscariello-intarea-hicn-04.txt>. draft-muscariello-intarea-hicn-04>.
[I-D.anilj-icnrg-dnc-qos-icn]
Jangam, A., suthar, P., and M. Stolic, "QoS Treatments in
ICN using Disaggregated Name Components", Work in
Progress, Internet-Draft, draft-anilj-icnrg-dnc-qos-icn-
02, 9 March 2020, <http://www.ietf.org/internet-drafts/
draft-anilj-icnrg-dnc-qos-icn-02.txt>.
[ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White,
"Enabling ICN in 3GPP's 5G NextGen Core Architecture",
Work in Progress, Internet-Draft, draft-ravi-icnrg-5gc-
icn-04, 10 January 2021,
<https://www.ietf.org/id/draft-irtf-icnrg-5gc-icn-04.txt>.
[ICNLOWPAN] [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., White, "Enabling ICN in 3GPP's 5G NextGen Core
Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN Architecture", Work in Progress, Internet-Draft, draft-
Networks (ICN LoWPAN)", Work in Progress, Internet-Draft, irtf-icnrg-5gc-icn-04, 10 January 2021,
draft-irtf-icnrg-icnlowpan-10, 10 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
<https://www.ietf.org/id/draft-irtf-icnrg-icnlowpan- 5gc-icn-04>.
10.txt>.
[ICNQoS] Al-Naday, M.F., Bontozoglou, A., Vassilakis, G., and M. J. [ICNQoS] Al-Naday, M.F., Bontozoglou, A., Vassilakis, G., and M. J.
Reed, "Quality of Service in an Information-Centric Reed, "Quality of service in an information-centric
Network", 2014 IEEE Global Communications Conference IEEE network", 2014 IEEE Global Communications Conference, pp.
Xplore DL, pp. 1861-1866, 8 December 2014, 1861-1866, DOI 10.1109/GLOCOM.2014.7037079, December 2014,
<https://ieeexplore.ieee.org/document/7037079>. <https://ieeexplore.ieee.org/document/7037079>.
[IPoICN] Trossen, D., Read, M J., Riihijarvi, J., Georgiades, M., [IPoICN] Trossen, D., Read, M. J., Riihijarvi, J., Georgiades, M.,
Fotiou, N., and G. Xylomenos, "IP over ICN - The better Fotiou, N., and G. Xylomenos, "IP over ICN - The better
IP?", 2015 European Conference on Networks and IP?", 2015 European Conference on Networks and
Communications (EuCNC) IEEE Xplore DL, pp. 413-417, 29 Communications (EuCNC), pp. 413-417,
June 2015, <https://ieeexplore.ieee.org/document/7194109>. DOI 10.1109/EuCNC.2015.7194109, June 2015,
<https://ieeexplore.ieee.org/document/7194109>.
[MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, [MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino,
"Scalable mobile backhauling via information-centric "Scalable mobile backhauling via information-centric
networking", The 21st IEEE International Workshop on Local networking", The 21st IEEE International Workshop on Local
and Metropolitan Area Networks, Beijing, pp. 1-6, 22 April and Metropolitan Area Networks, Beijing, pp. 1-6,
2015, <https://ieeexplore.ieee.org/document/7114719>. DOI 10.1109/LANMAN.2015.7114719, April 2015,
<https://ieeexplore.ieee.org/document/7114719>.
[MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference [MECSPEC] ETSI, "Mobile Edge Computing (MEC); Framework and
Architecture", ETSI European Telecommunication Standards Reference Architecture", ETSI GS MEC 003, Version 1.1.1,
Institute (ETSI) MEC specification, March 2016, March 2016, <https://www.etsi.org/deliver/etsi_gs/
<https://www.etsi.org/deliver/etsi_gs/
MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf>. MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf>.
[MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and
G. Wang, "Realtime multi-party video conferencing service G. Wang, "Realtime multi-party video conferencing service
over information centric network", IEEE International over information centric network", IEEE International
Conference on Multimedia and Expo Workshops (ICMEW) Turin, Conference on Multimedia and Expo Workshops (ICMEW),
Italy, pp. 1-6, 29 June 2015, Turin, Italy, pp. 1-6, DOI 10.1109/ICMEW.2015.7169810,
<https://ieeexplore.ieee.org/document/7169810>. June 2015, <https://ieeexplore.ieee.org/document/7169810>.
[MUTHANA] Muthana, A. and M. Saeed, "Analysis of User Identity [MUTHANA] Muthana, A. and M. Saeed, "Analysis of User Identity
Privacy in LTE and Proposed Solution", International Privacy in LTE and Proposed Solution", International
Journal of Computer Network and Information Journal of Computer Network and Information
Security(IJCNIS) MECS Press, pp. 54-63, January 2017, Security(IJCNIS), Vol. 9, Issue 1, pp. 54-63,
<http://www.mecs-press.org/ijcnis/ijcnis-v9-n1/ DOI 10.5815/ijcnis.2017.01.07, January 2017,
<https://www.mecs-press.org/ijcnis/ijcnis-v9-n1/
v9n1-7.html>. v9n1-7.html>.
[NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T.,
Ohnishi, R., and E. Muramoto, "Real-time Streaming Data Ohnishi, R., and E. Muramoto, "Real-Time Streaming Data
Delivery over Named Data Networking,", IEICE Transactions Delivery over Named Data Networking", IEICE Transactions
on Communications vol. E99.B, pp. 974-991, 1 May 2016, on Communications, Vol. E99.B, Issue 5, pp.
974-991, 10.5815/ijcnis.2017.01.07, May 2016,
<https://doi.org/10.1587/transcom.2015AMI0002>. <https://doi.org/10.1587/transcom.2015AMI0002>.
[NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced and [NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced &
Small Cells", Next Generation Mobile Networks, LTE- Small Cells", Next Generation Mobile Networks, LTE-
Advanced Transport Provisioning, V0.0.14, 20 October 2015, Advanced Transport Provisioning, Version 0.0.14, October
<https://www.ngmn.org/wp-content/uploads/ 2015, <https://www.ngmn.org/wp-content/uploads/
Publications/2015/150929_NGMN_P- Publications/2015/150929_NGMN_P-
SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>. SmallCells_Backhaul_for_LTE-Advanced_and_Small_Cells.pdf>.
[NS3EPC] Baldo, N., "The ns-3 EPC module", NS3 EPC Model, [NS3EPC] ns-3, "The EPC Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte- <https://www.nsnam.org/docs/models/html/lte-
design.html#epc-model>. design.html#epc-model>.
[NS3LTE] Baldo, N., "The ns-3 LTE module", NS3 LTE Model, [NS3LTE] ns-3, "The LTE Model", July 2022,
<https://www.nsnam.org/docs/models/html/lte- <https://www.nsnam.org/docs/models/html/lte-
design.html#lte-model>. design.html#lte-model>.
[OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, [OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella,
A., Bruno, R., and M. Conti, "Data Offloading Techniques A., Bruno, R., and M. Conti, "Data Offloading Techniques
in Cellular Networks: A Survey", IEEE Communications in Cellular Networks: A Survey", IEEE Communications
Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2, Surveys and Tutorials, Vol. 17, Issue 2, pp.580-603,
pp.580-603, 11 November 2014, DOI 10.1109/COMST.2014.2369742, November 2014,
<https://ieeexplore.ieee.org/document/6953022>. <https://ieeexplore.ieee.org/document/6953022>.
[OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption [OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES encryption
Overhead in Very High-speed Wireless LANs", Proceedings of overhead in very high-speed wireless LANs", Proceedings of
the 2009 IEEE International Conference on Communications the 2009 IEEE International Conference on Communications
ICC'09, ACM DL, pp.575-579, 14 June 2009, ICC'09, pp. 575-579, June 2009,
<http://dl.acm.org/citation.cfm?id=1817271.1817379>. <https://dl.acm.org/doi/10.5555/1817271.1817379>.
[Open5GCore] [Open5GCore]
Open5GCore, M., "Open5GCore - Fundamental 4G Core Network Open5GCore, "Open5GCore - 5G Core Network for Research,
Functionality", Open5GCore, <https://www.open5gcore.org>. Testbeds and Trials", <https://www.open5gcore.org>.
[QoS-ICN] Jangam, A., Ed., Suthar, P., and M. Stolic, "QoS
Treatments in ICN using Disaggregated Name Components",
Work in Progress, Internet-Draft, draft-anilj-icnrg-dnc-
qos-icn-02, 9 March 2020,
<https://datatracker.ietf.org/doc/html/draft-anilj-icnrg-
dnc-qos-icn-02>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012, RFC 6459, DOI 10.17487/RFC6459, January 2012,
skipping to change at page 41, line 20 skipping to change at line 1792
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609, Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>. <https://www.rfc-editor.org/info/rfc8609>.
[RFC9064] Oran, D., "Considerations in the Development of a QoS [RFC9064] Oran, D., "Considerations in the Development of a QoS
Architecture for CCNx-Like Information-Centric Networking Architecture for CCNx-Like Information-Centric Networking
Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021, Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021,
<https://www.rfc-editor.org/info/rfc9064>. <https://www.rfc-editor.org/info/rfc9064>.
[RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C.,
Marxer, C., and C. Tschudin, "Information-Centric
Networking (ICN) Adaptation to Low-Power Wireless Personal
Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139,
November 2021, <https://www.rfc-editor.org/info/rfc9139>.
[SDN5G] Page, J. and J. Dricot, "Software-defined networking for [SDN5G] Page, J. and J. Dricot, "Software-defined networking for
low-latency 5G core network", 2016 International low-latency 5G core network", 2016 International
Conference on Military Communications and Information Conference on Military Communications and Information
Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016, Systems (ICMCIS), pp. 1-7,
DOI 10.1109/ICMCIS.2016.7496561, May 2016,
<https://ieeexplore.ieee.org/document/7496561>. <https://ieeexplore.ieee.org/document/7496561>.
[TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", [TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets",
ICNRG Buenos Aires IETF 95, 3 April 2016, ICNRG, Buenos Aires, IETF 95, April 2016,
<https://datatracker.ietf.org/meeting/interim-2016-icnrg- <https://datatracker.ietf.org/meeting/interim-2016-icnrg-
02/materials/slides-interim-2016-icnrg-2-7>. 02/materials/slides-interim-2016-icnrg-2-7>.
[TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar, [TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar,
"Security, Privacy, and Access Control in Information- "Security, Privacy, and Access Control in Information-
Centric Networking: A Survey", IEEE Communications Surveys Centric Networking: A Survey", IEEE Communications Surveys
and Tutorials Volume 20, Issue 1, pp 566-600, September and Tutorials, Vol. 20, Issue 1, pp. 566-600,
2017, <https://ieeexplore.ieee.org/document/8027034>. DOI 10.1109/COMST.2017.2749508, September 2017,
<https://ieeexplore.ieee.org/document/8027034>.
[TS23.203] 3GPP, "Policy and charging control architecture", 3GPP [TS23.203] 3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 10.9.0, 12 September 2013, TS 23.203 17.2.0, December 2021,
<http://www.3gpp.org/ftp/Specs/html-info/23203.htm>. <https://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
[TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements [TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, 7 March 2013, (E-UTRAN) access", 3GPP TS 23.401 17.5.0, June 2022,
<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>. <https://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS23.501] 3GPP, "System Architecture for the 5G System", 3GPP [TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501 15.2.0, 15 June 2018, TS 23.501 17.5.0, June 2022,
<http://www.3gpp.org/ftp/Specs/html-info/23501.htm>. <https://www.3gpp.org/ftp/Specs/html-info/23501.htm>.
[TS23.714] 3GPP, "Technical Specification Group Services and System [TS23.714] 3GPP, "Study on Control Plane (CP) and User Plane (UP)
Aspects: Study on control and user plane separation of EPC separation of Evolved Packet Core (EPC) nodes", 3GPP
nodes", 3GPP TS 23.714 0.2.2, 4 June 2016, TS 23.714 14.0.0, June 2016,
<http://www.3gpp.org/ftp/Specs/html-info/23714.htm>. <https://www.3gpp.org/ftp/Specs/html-info/23714.htm>.
[TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling [TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling
Protocol (GTP) across the Gn and Gp interface", 3GPP Protocol (GTP) across the Gn and Gp interface", 3GPP
TS 29.060 3.19.0, 24 March 2004, TS 29.060 17.3.0, June 2022,
<http://www.3gpp.org/ftp/Specs/html-info/29060.htm>. <https://www.3gpp.org/ftp/Specs/html-info/29060.htm>.
[TS29.336] 3GPP, "Home Subscriber Server (HSS) diameter interfaces
for interworking with packet data networks and
applications", 3GPP TS 29.336 17.13.1, March 2022,
<https://www.3gpp.org/ftp/Specs/html-info/29336.htm>.
[TS33.310] 3GPP, "Network Domain Security (NDS); Authentication [TS33.310] 3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 10.7.0, 21 December 2012, Framework (AF)", 3GPP TS 33.310 17.3.0, June 2022,
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>. <https://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B [TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B
(HeNB)", 3GPP TS 33.320 10.5.0, 29 June 2012, (HeNB)", 3GPP TS 33.320 17.0.0, March 2022,
<http://www.3gpp.org/ftp/Specs/html-info/33320.htm>. <https://www.3gpp.org/ftp/Specs/html-info/33320.htm>.
Acknowledgements
We thank all contributors, reviewers, and the chairs for their
valuable time in providing comments and feedback that helped improve
this document. We especially want to mention the following members
of the IRTF Information-Centric Networking Research Group (ICNRG),
listed in alphabetical order: Kashif Islam, Thomas Jagodits, Luca
Muscariello, David R. Oran, Akbar Rahman, Martin J. Reed, Thomas
C. Schmidt, and Randy Zhang.
The IRSG review was provided by Colin Perkins.
Authors' Addresses Authors' Addresses
Prakash Suthar Prakash Suthar
Google Inc. Google Inc.
Mountain View, California 94043 Mountain View, California 94043
United States of America United States of America
Email: psuthar@google.com Email: psuthar@google.com
Milan Stolic Milan Stolic
skipping to change at page 43, line 4 skipping to change at line 1891
San Jose, California 95134 San Jose, California 95134
United States of America United States of America
Email: anjangam@cisco.com Email: anjangam@cisco.com
Dirk Trossen Dirk Trossen
Huawei Technologies Huawei Technologies
Riesstrasse 25 Riesstrasse 25
80992 Munich 80992 Munich
Germany Germany
Email: dirk.trossen@huawei.com Email: dirk.trossen@huawei.com
Ravi Ravindran Ravi Ravindran
F5 Networks F5 Networks
3545 North First Street 3545 North First Street
San Jose, 95134 San Jose, California 95134
United States of America United States of America
Email: r.ravindran@f5.com Email: r.ravindran@f5.com
 End of changes. 260 change blocks. 
925 lines changed or deleted 911 lines changed or added

This html diff was produced by rfcdiff 1.48.