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

[Tom Herbert <[e-mail]>]

On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello
<[e-mail]> 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)
> <[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.
>>
>>
>> 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-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
>>>> >> > [e-mail]
>>>> >> > https://www.ietf.org/mailman/listinfo/dmm
>>>> >> >
>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>