Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
The adjective minor is used in a comparative way. At least I intended that way. hICN allows to implement ICN features with less changes than using ICN as an overlay. On an absolute scale, I don't think that hICN requires negligible changes. So I haven't used the adjective minor as a synonym of negligible. I do think that having those changes are worthy for many apps. Back to your questions that I understand this way: 1) What is the hICN socket API? 2) Does hICN imply that all hosts have to change transport stack? 3) Does hICN disrupt the TCP/IP stack in an end host? 1) The answer to the first question is something that I wanted to discuss in the transport area but repeating does good. In the current implementation we support two different APIs. The first one is a BSD socket API, the second one is a post-socket API that is currently under development in the TAPS WG with a first integration in iOS 12 beta. I'm not contributing to TAPS but I think it is worthy to keep our implementation updated with TAPS. I haven't finished to write a draft but I have a technical report that I could share right before next IETF. 2) An application developer may or may not want to change to use this API. But I would turn the question around to ask, is it worthy to change the application to exploit this new transport service and the underlying network service to get a certain number of benefits? IMO, yes. Is it worthy to implement a new transport service in user-space such as LEDBAT, QUIC or the variety of transport services running for RTC apps? The answer is up to the application. It is the app that decides. So, no, there is no need to change all hosts. IMO the answer is it depends. 3) when you enable hICN in an end host the local network configuration manages two distinct namespaces, one for locators and one for identifiers (intended as location independent names). An end-host can manage several locators because might be multi-homed and can manage several identifiers because it has been assigned identifiers to name data sources at the host: mic, camera, an app etc. This host continues to be able to open TCP or UDP sockets (but also SCTP or others) with the usual socket bindings. Just to give an example: We are using our hICN transport library for WebRTC, MPEG-DASH among other things. An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC or the consumer/producer socket. The video player can sequentially switch protocol to retrieve the segment. Not that it make any sense but it's just to explain that they live in the same end-host. If the app considers that one transport service can provide features that are advantageous it can optionally switch to it. There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other transport protocol with the consumer/producer sockets. Luca On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: > On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello > wrote: > > More on the mobility use case which also makes deployment options easier > to > > digest > > > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > > > > From the draft: > > "The goal of hICN is to ease ICN insertion in existing IP infrastructure > by: > ... > 3. minor modification to existing IP routers/endpoints;" > > Can you elaborate on this "minor modification"? Especially for > endpoints, which I assume means hosts, what is the scope, the > necessary modifications, and deployment model. Also, will applications > have to change or use a new API for hICN? > > If the implication of hICN is that all Internet hosts need to change > to support a new consumer/producer communications model, a new > transport protocol, and a new application API-- there's nothing minor > about that! > > Tom > > > > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > > wrote: > >> > >> This draft is about hICN and discusses various deployment options with > >> associated pros and cons, without supporting one specifically. Clearly, > >> depending on application requirements, on network constraints, on > phase of > >> deployment/transition etc. one option may be preferrable over another > one > >> (and different ones may coexist). > >> > >> > >> One of the described deployment options also discusses combination of > hICN > >> and SRv6, without opposing one approach to the other, rather exploiting > in > >> the combination the advantages of both ones. > >> > >> > >> Giovanna > >> > >> > >> From: Int-area on behalf of Behcet Sarikaya > >> > >> Sent: Wednesday, June 20, 2018 4:18 PM > >> To: Luca Muscariello > >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility > >> management through hICN (hICN-AMM): Deployment options > >> > >> > >> > >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello > >> wrote: > >>> > >>> I wonder whether this conversation should happen in the
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
I am sorry but I'm not sure I get your question right. I am not sure SRv6 is just a tunnelling technique but I am not right person to talk about that. We do mention SRv6 in the draft to show how hICN can use it to steer the next-hop path for the request carrying the ID in the DST addr field and for the reply to steer the next-hop path carrying the locator in the DST addr field. In the first place hICN makes use of the IPv6 FIB. This is the default. But there are several interoperable protocols that might be included in the next-hop pipeline processing. Does it clarify your doubts? Luca On Wed, Jun 20, 2018 at 4:54 PM Behcet Sarikaya wrote: > > > On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < > gcaro...@cisco.com> wrote: > >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of >> hICN and SRv6, without opposing one approach to the other, rather >> exploiting in the combination the advantages of both ones. >> >> >> > I don't understand. > SRv6 is tunneling technique while hICN is talking about anchoress mobility. > Did I get something wrong? > > Behcet > >> Giovanna >> -- >> *From:* Int-area on behalf of Behcet >> Sarikaya >> *Sent:* Wednesday, June 20, 2018 4:18 PM >> *To:* Luca Muscariello >> *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < >> luca.muscarie...@gmail.com> wrote: >> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating >>> from a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 >>> number which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 >>> with the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup >>> is made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued >>> requests for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in >>> the SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >>> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regards >> Behcet >> >> >>> >>> >>> >>> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello wrote: > The paragraph you reported is from the draft that describes hICN to enable > several use cases. > Mobility is one of those, not the only one. > To clarify, the draft on hICN mobility deployment options focuses on the 5G > service based architecture. > > You may be asking > 1) is it possible to get all the features provided by hICN w/o updates to > the transport layer? > 2) is changing the transport protocol unnecessary difficult to enable all > the use cases
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello wrote: > The adjective minor is used in a comparative way. At least I intended that > way. > hICN allows to implement ICN features with less changes than using ICN as an > overlay. > On an absolute scale, I don't think that hICN requires negligible changes. > So I haven't used the adjective minor as a synonym of negligible. > I do think that having those changes are worthy for many apps. > > Back to your questions that I understand this way: > 1) What is the hICN socket API? > 2) Does hICN imply that all hosts have to change transport stack? > 3) Does hICN disrupt the TCP/IP stack in an end host? > > > 1) The answer to the first question is something that I wanted to discuss in > the transport area > but repeating does good. In the current implementation we support two > different APIs. > The first one is a BSD socket API, the second one is a post-socket API that > is currently > under development in the TAPS WG with a first integration in iOS 12 beta. > I'm not > contributing to TAPS but I think it is worthy to keep our implementation > updated with TAPS. > I haven't finished to write a draft but I have a technical report that I > could share right before next IETF. > > 2) An application developer may or may not want to change to use this API. > But I would turn the question around to ask, is it worthy to change the > application to exploit > this new transport service and the underlying network service to get a > certain number of benefits? Luca, I would say the answer is no, unless you can prove beyond doubt that violating the protocol layering archictecure of the Internet and the E2E model is necessary to get those benefits. I don't believe that proof has yet been provided (for this proposal or any other similar ones and there have been several). The Internet is architectured such that any transport protocol can run over a common network layer. Mobility is a network layer concern and so should be part of the network layer. Therefore, a network mobility solution should work transparently with any transport layer (TCP, UCP, QUIC, SCTP, and new ones we may come up with). The network/transport separation is not maintained when we we see intermediate devices trying to participate the transport layer which entails DPI and inevitably leads to protocol ossification in the Internet. So we want middelboxes be less invasive in the transport layer, not more invasive! You may want to look at early PLUS/SPUD efforts that were attempting to turn UDP into a sort of of network layer protocol to carry path information read by the network (they choose UDP because of compatibility with existing HW instead of defining a new transport protocol). This even included encoding flow semantics for network to track (like the request/response tracking in hICN). These efforts got pushback in part because it violates protocol layer and encouraged DPI. In hindsight the answer now seems pretty simple: network layer information belongs in network layer headers. If you want to signal the network then just put information extension headers like HBH options. EH also permits data modification by intermediate devices which is useful for things like OAM. > IMO, yes. > > Is it worthy to implement a new transport service in user-space such as > LEDBAT, QUIC or the variety of transport > services running for RTC apps? The answer is up to the application. It is > the app that decides. It's not just up to the application. It's up the network operators, hardware vendors, as well as the OS vendors. The OS is a big problem. There is simply no concept of instantaneously changing all OS deployments to a support a new feature like this. It takes years to get significant traction. Look at a protocol like MPTCP: it's good protocol and shows a lot of value to many users, but deployment has been stymied by lack of OS support. We are trying to fix the situation, but it's not easy. > So, no, there is no need to change all hosts. IMO the answer is it depends. > > 3) when you enable hICN in an end host the local network configuration > manages two distinct namespaces, > one for locators and one for identifiers (intended as location independent > names). An end-host can manage several > locators because might be multi-homed and can manage several identifiers > because it has been assigned identifiers > to name data sources at the host: mic, camera, an app etc. > This host continues to be able to open TCP or UDP sockets (but also SCTP or > others) with the usual socket bindings. > > Just to give an example: We are using our hICN transport library for > WebRTC, MPEG-DASH among other things. > An MPEG-DASH segment can be retrieved by a video client using TCP, QUIC or > the consumer/producer socket. > The video player can sequentially switch protocol to retrieve the segment. > Not that it make any sense but it's just > to explain that they live in the same end-host. If the app considers that > one
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello wrote: > More on the mobility use case which also makes deployment options easier to > digest > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > >From the draft: "The goal of hICN is to ease ICN insertion in existing IP infrastructure by: 3. minor modification to existing IP routers/endpoints;" Can you elaborate on this "minor modification"? Especially for endpoints, which I assume means hosts, what is the scope, the necessary modifications, and deployment model. Also, will applications have to change or use a new API for hICN? If the implication of hICN is that all Internet hosts need to change to support a new consumer/producer communications model, a new transport protocol, and a new application API-- there's nothing minor about that! Tom > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > wrote: >> >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of hICN >> and SRv6, without opposing one approach to the other, rather exploiting in >> the combination the advantages of both ones. >> >> >> Giovanna >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> To: Luca Muscariello >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> wrote: >>> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating from >>> a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 number >>> which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 with >>> the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup is >>> made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued requests >>> for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in the >>> SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regards >> Behcet >> >>> >>> >>> >>> >>> >>> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello wrote: > The paragraph you reported is from the draft that describes hICN to > enable > several use cases. > Mobility is one of those, not the only one. > To clarify, the draft on hICN mobility deployment options focuses on > the 5G > service based architecture. > > You may be asking > 1) is it possible to get all the features provided by hICN w/o updates > to > the transport layer? > 2) is changing the transport protocol unnecessary difficult to enable > all > the use cases mentioned in
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
More on the mobility use case which also makes deployment options easier to digest https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) < gcaro...@cisco.com> wrote: > This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > Giovanna > -- > *From:* Int-area on behalf of Behcet Sarikaya > > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscarie...@gmail.com> wrote: > >> I wonder whether this conversation should happen in the intarea wg >> mailing list >> as the main draft was posted there in the first place. I don't know if >> cross posting is welcome >> but I take the risk. >> >> Going back to the question, the transport changes are related to the >> request/reply semantic >> of the architecture. The two distinct forwarding paths described in the >> draft take care >> of forwarding requests or replies.This ends up in the transport layer as >> a unidirectional >> channel to recv data or snd data. The replies carry data originating from >> a transport end-point (snd buffer) >> that binds to an identifier which is location independent, an IPv6 number >> which is not a locator. >> >> The forwarding path of the requests is very close to unmodified IPv6 with >> the DST address carrying the identifier. >> If you check in the draft an hICN node does one additional lookup in a >> local cache though. But you can ignore that >> for now for sake of clarity. What is important is the address rewrite >> operation made on the SRC address >> of the request. A copy of the request is stored in the local cache and >> the locator of the output interface is written in the >> SRC address before transmission. This is used by an upstream hICN or the >> final end-point to know the locator that >> will be used to reply. >> >> Replies coming from the snd end-point are label swapped but not like >> MPLS. >> The label is the identifier itself that is stored in the SRC address of >> the reply, >> whereas the DST address is a locator. In this forwarding path a lookup is >> made in the local cache to >> find a request (one or many) and the associated locator (one or many) >> that matches the identifier. >> The DST addr field of the replies is rewritten with the locator(s) just >> obtained from the lookup. >> This is how the reply is forwarded to the end-points that issued requests >> for this identifier. >> >> For the replies there is no FIB lookup on the identifier (as it is in the >> SRC addr field). >> There can be a lookup in the FIB on the locator stored in the DST of the >> reply to >> reach back the previous hICN node or eventually the original end-point. >> >> >> >> > > Hi, > > My humble question is: are you supporting SRv6 or hICN? > > Regards > Behcet > > >> >> >> >> >> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> wrote: >>> > The paragraph you reported is from the draft that describes hICN to >>> enable >>> > several use cases. >>> > Mobility is one of those, not the only one. >>> > To clarify, the draft on hICN mobility deployment options focuses on >>> the 5G >>> > service based architecture. >>> > >>> > You may be asking >>> > 1) is it possible to get all the features provided by hICN w/o updates >>> to >>> > the transport layer? >>> > 2) is changing the transport protocol unnecessary difficult to enable >>> all >>> > the use cases mentioned in the draft? >>> > >>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>> idea of hICN is to put routes in the local routing table and use >>> existing forwarding and routing to forward packets to mobile nodes. So >>> if a node changes location, then the routing tables need to be >>> updated. Effectively this is a bunch of host routes that need to be >>> maintained. At least this is what I gather from the draft: >>> >>> "hICN network layer is about using the IPv6 FIB to determine a next >>> hop router to forward requests or using a local packet cache to >>> determine if an incoming request can be satisfied locally." >>> >>> Is this correct? If it is, then I sort of understand how hICN could be >>> used for mobility or
Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < gcaro...@cisco.com> wrote: > This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > I don't understand. SRv6 is tunneling technique while hICN is talking about anchoress mobility. Did I get something wrong? Behcet > Giovanna > -- > *From:* Int-area on behalf of Behcet Sarikaya > > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscarie...@gmail.com> wrote: > >> I wonder whether this conversation should happen in the intarea wg >> mailing list >> as the main draft was posted there in the first place. I don't know if >> cross posting is welcome >> but I take the risk. >> >> Going back to the question, the transport changes are related to the >> request/reply semantic >> of the architecture. The two distinct forwarding paths described in the >> draft take care >> of forwarding requests or replies.This ends up in the transport layer as >> a unidirectional >> channel to recv data or snd data. The replies carry data originating from >> a transport end-point (snd buffer) >> that binds to an identifier which is location independent, an IPv6 number >> which is not a locator. >> >> The forwarding path of the requests is very close to unmodified IPv6 with >> the DST address carrying the identifier. >> If you check in the draft an hICN node does one additional lookup in a >> local cache though. But you can ignore that >> for now for sake of clarity. What is important is the address rewrite >> operation made on the SRC address >> of the request. A copy of the request is stored in the local cache and >> the locator of the output interface is written in the >> SRC address before transmission. This is used by an upstream hICN or the >> final end-point to know the locator that >> will be used to reply. >> >> Replies coming from the snd end-point are label swapped but not like >> MPLS. >> The label is the identifier itself that is stored in the SRC address of >> the reply, >> whereas the DST address is a locator. In this forwarding path a lookup is >> made in the local cache to >> find a request (one or many) and the associated locator (one or many) >> that matches the identifier. >> The DST addr field of the replies is rewritten with the locator(s) just >> obtained from the lookup. >> This is how the reply is forwarded to the end-points that issued requests >> for this identifier. >> >> For the replies there is no FIB lookup on the identifier (as it is in the >> SRC addr field). >> There can be a lookup in the FIB on the locator stored in the DST of the >> reply to >> reach back the previous hICN node or eventually the original end-point. >> >> >> >> > > Hi, > > My humble question is: are you supporting SRv6 or hICN? > > Regards > Behcet > > >> >> >> >> >> On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> wrote: >>> > The paragraph you reported is from the draft that describes hICN to >>> enable >>> > several use cases. >>> > Mobility is one of those, not the only one. >>> > To clarify, the draft on hICN mobility deployment options focuses on >>> the 5G >>> > service based architecture. >>> > >>> > You may be asking >>> > 1) is it possible to get all the features provided by hICN w/o updates >>> to >>> > the transport layer? >>> > 2) is changing the transport protocol unnecessary difficult to enable >>> all >>> > the use cases mentioned in the draft? >>> > >>> Sorry, but I'm still missing something fundamental here. AFAICT, the >>> idea of hICN is to put routes in the local routing table and use >>> existing forwarding and routing to forward packets to mobile nodes. So >>> if a node changes location, then the routing tables need to be >>> updated. Effectively this is a bunch of host routes that need to be >>> maintained. At least this is what I gather from the draft: >>> >>> "hICN network layer is about using the IPv6 FIB to determine a next >>> hop router to forward requests or using a local packet cache to >>> determine if an incoming request can be satisfied locally." >>> >>> Is this correct? If it is, then I sort of understand how hICN could be >>> used for mobility or virtualization without
