________________________________________ From: dmm <dmm-boun...@ietf.org> on behalf of Tom Herbert <t...@quantonium.net> Sent: Wednesday, June 20, 2018 12:30 AM To: Luca Muscariello Cc: Luca Muscariello (lumuscar); dmm Subject: Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello <luca.muscarie...@gmail.com> 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. GC/ That is a misunderstanding here, hICN mobility management is not based on routing updates/host routes to be maintained. There is no routing of data back to the users, rather data packets follow reverse path of requests. Hopefully the publication of the yet-to-be-published hICN mobility draft will clarify that, but just to summarize here, the basic idea of hICN is 1) routing/forwarding based on location-independent identifiers (ICN's idea) encoded into IP addresses (the h in hICN) 2) connectionless request/reply transport model : only known end-point is the receiver, source(s) is(are) dynamically discovered, path is a priori unknown 3) richer forwarding exploiting lookup-by-name features in buffer (for caching, request aggregation,/multicast, in network congestion control etc) and dynamic hop-by-hop decisions based on name-based forwarding strategies Mobility advantages come from all three points above: consumer mobility is handled by design (no change to host routes, data flow back on the reverse path of requests), producer mobility can be handled through localized forwarding updates (MapMe protocol described in hICN drafts is one possibility) at a much faster timescale than that of routing updates and without requiring any UP/CP anchor. Since it does not rely on routing updates such approach can minimize latency and track producer (while cached copies are not enough) in realtime at network latency but also support infrastructure-less communication when needed. Name/location binding, route re-computation, tunneling, anchoring are not done here. Coexistance with existing CP and transparent interconnection with the rest of infrastructure is accounted by design in the h of hICN (described in the hICN draft), benefits/costs wrt hICN deployment penetration is discussed in the deployment options draft, but in all cases we assume 1)-2)-3) in hICN-enabled endpoints. Of course you could think about partial integration of ICN into IP that keep pieces of it (eg naming/forwarding) neglecting others (transport as you say): as explained in the draft that comes at the cost of losing many advantages as showed by previous work, so we do not recommend it. Hope it help clarify your doubts. Giovanna > IMO, the answers are no for both. > > Luca > > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <t...@quantonium.net> wrote: >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> <luca.muscarie...@gmail.com> wrote: >> > Hi all, >> > >> > the draft below has been posted and describes deployments options for >> > anchorless mobility management by using >> > the hicn network architecture that implements icn semantics in IPv6 >> > networks. >> > >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >> > >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> > >> > A background document has been posted to the internet area WG and >> > reported >> > here for your convenience. >> > The core principle behind hicn and mobility management is that data >> > sources >> > are named using location independent names >> > encoded in IPv6 addresses. The transport service sitting on top of the >> > hicn >> > architecture is not based on usual TCP/UDP sockets >> > but on a novel consumer/producer transport service that will be >> > described in >> > another draft. >> >> From the draft: "The transport end-point offers two kinds of services >> to applications: a producer and a consumer service. The service is >> instantiated in the application by opening communication sockets with >> an API to perform basic transport service operations: allocation, >> initialization, configuration, data transmission and reception." >> >> This seems like a pretty dramatic rethink of the transport layer just >> for the purposes of mobility management. Will there be a way to use >> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)? >> >> Thanks, >> Tom >> >> >> >> > The current document and a companion document that will be posted soon >> > describe the different deployment options >> > with special care to the 5G service based architecture. >> > Thanks for the comments already received that helped completing this -00 >> > draft. >> > >> > Luca >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > dmm mailing list >> > dmm@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmm >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
