Subject: [icnrg] ICN over LTE Draft comments

From: Ravi Ravindran <[email-masked]>
Date: Mon, 23 Oct 2017 21:17:36 +0000

In the last IETF/ICNRG meeting, I had volunteered to review https://tools.ietf.org/html/draft-suthar-icnrg-icn-lte-4g-03

Here are my comments:

Section 1: There is an exhaustive list of 3gpp definitions, good to reduce to those that are more relevant for the draft.

Section 2.2: There is a comment on ICN able to address QoS configuration and enforcement challenges, elaboration on this will be interesting

Section 2.3 : Content Delivery using IP
1. On multicast system being efficient in the core network - Current solutions are good to handle pre-planned multicast like broadcasting live TV using eMBMS mechanisms, but not for handling demands of dynamic multicast, such as content distribution to serve IoT applications (e.g. connected car), VoD, Conferencing, or AR/VR applications, which is what LTE or 5G should be able to deliver.

Section 2.4: "Some of early architecture work for 5G mobile
   technologies provides mechanism for control and user plane separation
   and simplifies mobility call flow by introduction of open-flow based
   signaling is described in [TS23.501]" - This has to be verified, in my knowledge going through the 23.501 spec, there is no reference to OF based signaling, probably 23.214/23.799 might have some proposals on that,  if so the text should be reworded.

Section 3 on ICN
- There is mention of 'guiders' used to identify how an ICN packet has to be processed  - it will be good to elaborate on this.

Section 4.2:
1. "Authors in [RFC6459] have described the deployment scenarios for
   LTE/4G mobile network using IP (IPv4 and IPv6) transport and analyzed
   the impact of ICN for control plane signaling and user plane data
   delivery " - the draft is on enabling IPV6, not sure about the ICN related statement in the quoted text.

2. In Fig. 4, a transport convergence layer is shown for ICN and IP applications, the main function seems to be mux/demux IP/ICN PDU to the layer above and below, to avoid confusion with flow/congestion control functions, this may be called 'Traffic Selector layer'

3. It is not clear how the proposed IPoICN integrates with LTE in terms of IP termination and ICN state in the EPC.

Section 4.3

1. "It is important to note that even if we don't implement ICN in MME
  and HSS, they still need to support either dual stack or native ICN
   UE capabilities " - Couldn't understand this statement, any control plane would be applications over ICN, so not sure what this is trying to imply.

Section 4.4.1
- Some of the discussion seems to be a repeat from Section 4.2, good to add new details here if possible.

Section 4.4.2
- The discussion refers to Fig.7, looks like it intended to be Fig.8

- "For native ICN deployment, Application is configured to use ICN
   forwarder so there is no need for Transport Convergence." - why ?, what is the difference in the UE from the architecture presented in Fig.7, looks like the same layering at the UE end.

Section 4.5
- The difference between this deployment model and the previous one is not clear, as Fig.8 shows ICN in the eNodeB as well.

Regards,
Ravi