On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello <luca.muscarie...@gmail.com> 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) > <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 <int-area-boun...@ietf.org> on behalf of Behcet Sarikaya >> <sarikaya2...@gmail.com> >> 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 <t...@quantonium.net> wrote: >>>> >>>> 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. 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 network overlays, but then >>>> I'm completely lost as to why this would require any changes in the >>>> transport layer. >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>>> > 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 >>>> >> > d...@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/dmm >>>> >> > >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> d...@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
