Subject: Re: [icnrg] ICN over LTE Draft comments

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Mon, 13 Nov 2017 06:54:56 +0000

Hello Everyone,
In last IETF-99 ICNRG meeting at Prague I had presented V2.0 of this draft. Chair requested dedicated
 Review and Trossen, Dirk [email-masked]<mailto:[email-masked]> ; Rahman, Akbar [email-masked]<mailto:[email-masked]> ; Ravi Ravindran [email-masked]<mailto:[email-masked]> took ownership to review and provide comments. We got detailed feedback from above reviewer and also from Chair. Authors have followed with above reviewed and spend lot of time in incorporating feedback and made enhancements to the draft.

We have released version 4 for this draft
Native Deployment of ICN in LTE, 4G Mobile Networks https://www.ietf.org/internet-drafts/draft-suthar-icnrg-icn-lte-4g-04.txt

I will present the changes in this document on next ICNRG meeting this week on 15 Nov.
If you have any additional comments please let us know.

Best regards,
Prakash Suthar

From: Anil Jangam <[email-masked]>
Date: Monday, November 13, 2017 at 2:50 PM
To: Prakash Suthar <[email-masked]>
Subject: Re: [icnrg] ICN over LTE Draft comments

Section 1: There is an exhaustive list of 3gpp definitions, good to reduce to those that are more relevant for the draft.
<<Authors>> Made necessary changes to remove 3G related references because this draft mainly focus on LTE, 4G

Section 2.2: There is a comment on ICN able to address QoS configuration and enforcement challenges, elaboration on this will be interesting
<<Authors>> Provided detailed explanation for QoS intricacies in IP base network and how we can leverage policy based configuration on ICN forwarder to provide consistent QoS.

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.
<<Authors>> We can deliver contents to requesting client/UE from closest ICN forwarder provided content is cached. There many not be need to traditional eMBMS features with native ICN protocols based mobile network.

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.
<<Authors>> Use of open-flow based signaling is still under discussions in 3GPP, however TS23.501 does cover GTP based signaling. We have provided additional reference to CUPS architecture based on open-flow which is trialed by many vendors including Cisco. We will continue reviewing how open-flow evolves for control plane signaling in 5G core.

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.
<<Authors>> We have reviewed the comments and how we can leverage guider/forwarding strategies
For LTE network, when a mobile device wants to get certain content, it will send an Interest message to the closest eNodeB. Interest packet follows the TLV format [CCNxTLV] and contains mandatory fields such as name of the content and nonce. Name and nonce together uniquely identify an Interest packet. Nonce is also used to detect looping Interest messages. Interest packet also contains optional fields such as selector and guider fields. Selectors provides a specific filtering action during matching and selection of the name prefixes. Guiders provides specific set of rules on how the Interest packet can be processed at the forwarder. Section 3 is very high-level overview of ICN and we do not intend to provide a detailed protocol discussion in this section. We can find more details in CCNx Messages in TLV https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-06#section-3.4 , which we have provided reference to this draft.

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.
<<Authors>> We have reviewed and corrected related the comment. We believe this section provide details explanation so no changes are required in this section.

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'
<<Need to add response here>>

3. It is not clear how the proposed IPoICN integrates with LTE in terms of IP termination and ICN state in the EPC.
<<Authors>>
Implementing IP services over ICN provides an opportunity leveraging benefit of ICN in the transport infrastructure and there is no impact on end devices (UE and access network) as they continue to use IP. IPoICN however, will require an inter-working function (IWF/Border Gateway) to translate various transport primitives such as transport of tunnel mode. IWF function will provide a mechanism for protocol translation between IPoICN and native IP deployment for mobile network. After reviewing H2020 IPoICN, we understand and interpret that ICN is implemented in the transport natively; however, IP is implemented in UE, eNodeB, and Mobile gateway (SGW/PGW), which is also called as network attach point (NAP).

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.
<<Authors>> We have reviewed and made following changes to the section
It is important to note that even if MME and HSS do not support ICN transport, they still need to support UE capable of dual stack or native ICN. When UE initiates attach request using the identity as ICN, MME must be able to parse that message and create session. MME forwards UE authentication to HSS so HSS must be able to authenticate an ICN capable UE.

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.
 <<Authors>> Section 4.2 covers generic ICN deployment scenario. Section 4.4.1 provides specific deployment use case of ICN in UE as dual-stack in UE. There is no repeat of information.

Section 4.4.2
- The discussion refers to Fig.7, looks like it intended to be Fig.8
<<Authors>> Diagram numbering corrected. Thanks

- "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.
<<Authors>> Transport Layer Convergence (TCL) perform more functions than just ICN forwarder.
The transport convergence layer helps determine what type of transport (e.g. ICN or IP) as well as type of radio interface (e.g. LTE or WiFi or both), is used to send and receive the traffic. Even though this section covers specific use case of native ICN deployment (where IP is not involved and hence the original argument); however, use of TCL will be required from an architecture point of view.

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.
<<Authors>> We have reviewed this section and provided additional explanation as follows.
We can build ICN capabilities in eNodeB similar to UE with three different options – Native ICN, Native IP, Dual stack (IP and ICN). We also provides mechanism in eNodeB with open Application Programming Interface (API) to external management systems. This API can enable programming of forwarding strategies in eNodeB.

Regards,
Ravi

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 13 Nov 2017 15:20:52 +0800

Hi,

just a quick formal comment: Many of the references provided are 
incomplete or incorrect.

This needs fixing.

Best,
  Thomas

On 13/11/2017 14:54, Prakash Suthar (psuthar) wrote:
>   Review and Trossen, Dirk [email-masked] 
> <mailto:[email-masked]> ; Rahman, Akbar 
> [email-masked] <mailto:[email-masked]> ; 
> Ravi Ravindran [email-masked] 
> <mailto:[email-masked]> took ownership to review and provide 
> comments. We got detailed feedback from above reviewer and also from 
> Chair. Authors have followed with above reviewed and spend lot of time 
> in incorporating feedback and made enhancements to the draft.
> 
> *Native Deployment of ICN in LTE, 4G Mobile 
> Networks*https://www.ietf.org/internet-drafts/draft-suthar-icnrg-icn-lte-4g-04.txt 
> 
> 
> *From: *Anil Jangam <[email-masked]>
> *Date: *Monday, November 13, 2017 at 2:50 PM
> *To: *Prakash Suthar <[email-masked]>
> *Subject: *Re: [icnrg] ICN over LTE Draft comments
> 
> Section 1: There is an exhaustive list of 3gpp definitions, good to 
> reduce to those that are more relevant for the draft.
> 
> *<<Authors>> Made necessary changes to remove 3G related references 
> because this draft mainly focus on LTE, 4G*
> 
> Section 2.2: There is a comment on ICN able to address QoS configuration 
> and enforcement challenges, elaboration on this will be interesting
> 
> *<<Authors>> Provided detailed explanation for QoS intricacies in IP 
> base network and how we can leverage policy based configuration on ICN 
> forwarder to provide consistent QoS.*
> 
> 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.
> 
> *<<Authors>> We candelivercontents to requesting client/UE from 
> closestICNforwarder provided content is cached. There many not be need 
> to traditional eMBMS features with native ICN protocols based mobile 
> network.*
> 
>     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.
> 
> *<<Authors>> Use of open-flow based signaling is still under discussions 
> in 3GPP, however TS23.501 does cover GTP based signaling. We have 
> provided additionalreferenceto CUPS architecture based on open-flow 
> which is trialed by many vendors including Cisco. We will continue 
> reviewing how open-flow evolves for control plane signaling in 5G core.*
> 
> 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.
> 
> *<<Authors>> We have reviewed the comments and how we can leverage 
> guider/forwarding strategies *
> 
> For LTE network, when a mobile device wants to get certain content, it 
> will send an Interest message to the closest eNodeB. Interest packet 
> follows the TLV format [CCNxTLV] and contains mandatory fields such as 
> name of the content and nonce. Name and nonce together uniquely identify 
> an Interest packet. Nonce is also used to detect looping Interest 
> messages. Interest packet also contains optional fields such as selector 
> and guider fields. Selectors provides a specific filtering action during 
> matching and selection of the name prefixes. Guiders provides specific 
> set of rules on how the Interest packet can be processed at the 
> forwarder. Section 3 is very high-level overview of ICNand we do not 
> intend to provide a detailed protocol discussion in this section. We can 
> find more details in CCNx Messages in 
> TLVhttps://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-06#section-3.4,which 
> we have provided reference to this draft.
> 
> **
> 
> Section 4.2:
> 
> *<<Authors>> We havereviewed and corrected related the comment. We 
> believe this section provide details explanation so no changes are 
> required in this section.*
> 
> 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.
> 
> <<Authors>>
> 
> *Implementing IP services over ICN provides an opportunity leveraging 
> benefit of ICN in the transport infrastructure and there is no impact on 
> end devices (UE and access network) as they continue to use IP. IPoICN 
> however, will require an inter-working function (IWF/Border Gateway) to 
> translate various transport primitives such as transport of tunnel mode. 
> IWF function will provide a mechanism for protocol translation between 
> IPoICN and native IP deployment for mobile network. After reviewing 
> H2020 IPoICN, we understand and interpret that ICN is implemented in the 
> transport natively; however, IP is implemented in UE, eNodeB, and Mobile 
> gateway (SGW/PGW), which is also called as network attach point (NAP).*
> 
> Section 4.3
> 
>     UE capabilities " - Couldn't understand this statement, any control 
> plane would be applications over ICN, so not sure what this is trying to 
> imply.
> 
> *<<Authors>> We have reviewed and made following changes to the section*
> 
> *It is important to note that even if MME and HSS do not support ICN 
> transport, they still need to support UE capable of dual stack or native 
> ICN. When UE initiates attach request using the identity as ICN, MME 
> must be able to parse that message and create session. MME forwards UE 
> authentication to HSS so HSS must be able to authenticate an ICN capable 
> UE.*
> 
> Section 4.4.1
> 
> * <<Authors>> Section 4.2 covers generic ICN deployment scenario. 
> Section 4.4.1 providesspecificdeploymentuse case ofICN in UE as 
> dual-stack in UE. There is no repeat of information.*
> 
> Section 4.4.2
> 
> *<<Authors>> Diagram numbering corrected. Thanks*
> 
>     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.
> 
> *<<Authors>> Transport Layer Convergence (TCL) perform more functions 
> than just ICN forwarder.*
> 
> *The transport convergence layer helps determine what type of transport 
> (e.g. ICN or IP) as well as type of radio interface (e.g. LTE or WiFi or 
> both), is used to send and receive the traffic. Even though this 
> sectioncovers specific use case ofnative ICN deployment(where IP is not 
> involved and hence the original argument); however, use of TCL will be 
> required from an architecture point of view.*
> 
> 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.
> 
> *<<Authors>> We have reviewed this section and provided additional 
> explanation as follows.*
> 
> *We can build ICN capabilities in eNodeB similar to UE with three 
> different options – Native ICN, Native IP, Dual stack (IP and ICN). We 
> also provides mechanism in eNodeB with open Application Programming 
> Interface (API) to external management systems. This API can enable 
> programming of forwarding strategies in eNodeB.*
> 
> Regards,
> 
> Ravi
> 

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Tue, 14 Nov 2017 02:28:19 +0000

HI Thomas,
Greetings. 
The authors will really appreciate if you please be specific about your feedback. 
Which section need what changes?. 

We are open to have follow-up meeting with you if you can provide additional information about your feedback.

Thanks

Prakash Suthar
CCIE (DC, SP), RHCA, PMP, VCP
Principal Architect
Cisco System Inc.

On 11/13/17, 3:20 PM, "Thomas C. Schmidt" <[email-masked]> wrote:

    Hi,

    This needs fixing.
    
    Best,
      Thomas

    --