Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Behcet Sarikaya <[e-mail]>]

On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) <
[e-mail]> 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 <[e-mail]> on behalf of Behcet Sarikaya
> <[e-mail]>
> *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 <
> [e-mail]> 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 <[e-mail]> wrote:
>>
>>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello
>>> <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>> >>
>>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
>>> >> <[e-mail]> 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-mobilit
>>> y-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
>>> >> > [e-mail]
>>> >> > https://www.ietf.org/mailman/listinfo/dmm
>>> >> >
>>>
>>
>> _______________________________________________
>> dmm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>