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

From: Luca Muscariello <[email-masked]>
Date: Tue, 19 Jun 2018 11:46:31 +0200

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.
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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Jun 2018 12:26:41 -0700

On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello
<[email-masked]> wrote:
> 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

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Luca Muscariello <[email-masked]>
Date: Tue, 19 Jun 2018 22:50:42 +0200

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?

IMO, the answers are no for both.

Luca

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Jun 2018 15:30:22 -0700

> 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

---

From: "Giovanna Carofiglio (gcarofig)" <[email-masked]>
Date: Tue, 19 Jun 2018 23:05:36 +0000

________________________________________
From: dmm <[email-masked]> on behalf of Tom Herbert <[email-masked]>
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

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

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 20 Jun 2018 01:21:03 +0200

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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Jun 2018 09:18:46 -0500

On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello <
[email-masked]> wrote:

> The label is the identifier itself that is stored in the SRC address of
> the reply,

Hi,

My humble question is: are you supporting SRv6 or hICN?

Regards
Behcet

>> >> > encoded in IPv6 addresses. The transport service sitting on top of
>> the
>> >> > hicn

---

From: "Giovanna Carofiglio (gcarofig)" <[email-masked]>
Date: Wed, 20 Jun 2018 14:33:41 +0000

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 <[email-masked]> on behalf of Behcet Sarikaya <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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,

Regards
Behcet

On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello

Tom

> On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> <[email-masked]<mailto:[email-masked]>> wrote:
>> > Hi all,
>> >
>> > [email-masked]<mailto:[email-masked]>

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 20 Jun 2018 16:48:49 +0200

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) <
[email-masked]> 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 <[email-masked]> on behalf of Behcet Sarikaya
> <[email-masked]>
> *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
>
>
>
>> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Jun 2018 09:53:59 -0500

> 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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Jun 2018 08:13:11 -0700

>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)
> <[email-masked]> wrote:
>>
>> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility
>> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 20 Jun 2018 18:06:16 +0200

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 <[email-masked]> wrote:

> >>> of forwarding requests or replies.This ends up in the transport layer
> as
> >>> a unidirectional
> >>>> > 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 core principle behind hicn and mobility management is that
> data
> >>>> >> > sources

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 20 Jun 2018 18:38:47 +0200

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 <[email-masked]>
wrote:

>> 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.
>> *From:* Int-area <[email-masked]> on behalf of Behcet
>> Sarikaya <[email-masked]>
>>> The forwarding path of the requests is very close to unmodified IPv6
>>> with the DST address carrying the identifier.
>>>> updates to

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Jun 2018 10:18:20 -0700

On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello
<[email-masked]> wrote:
> hICN allows to implement ICN features with less changes than using ICN as an
> overlay.
> 1) The answer to the first question is something that I wanted to discuss in
> the transport area

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.

> services running for RTC apps? The answer is up to the application. It is

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.

> transport protocol with the consumer/producer

Okay, but these protocols still need to work in mobile networks, which
means in hICN enabled network you still need a mobile infrastructure
to handle these "legacy" protocols. That means there are two distinct
mobility models needed-- hICN is not simplifying matters in this
regard.

To me, the hICN story would be a lot more compelling if the transport
and network layer are decoupled so there was one solution that
provided seamless mobility for everyone in the network regardless of
type of transport protocol they use or application that they wish to
run. Beyond that, there might be opportunities to improve
communications by some coordinated interaction with the network (like
we propose in FAST), but these are strictly optimization and not
requirements to make basic communications work.

Tom

>> >> hICN
>> >>>> > To clarify, the draft on hICN mobility deployment options focuses
>> >>>> > on
>> >>>> > the 5G
>> >>>> >> > the draft below has been posted and describes deployments
>> >>>> >> > options
>> >>>> >> > for
>> >>>> >> > A background document has been posted to the internet area WG
>> >>>> >> > and
>> >>>> >> > reported
>> >>>> >> > The current document and a companion document that will be
>> >>>> >> > posted
>> >>>> >> > soon

---

From: Luca Muscariello <[email-masked]>
Date: Thu, 21 Jun 2018 12:29:32 +0200

There are several points raised here:
1) Alleged protocol layering violations and the e2e principle.
2) Relationship between the OS and transport services.

1) Many see the e2e principle as another instance of Occam's razor applied
to communication
protocols function placement, I think it is even written in the first paper
that talks about it (Reed, Clark...).
It's all about design patters for the development of distributed
applications.
Placement of function vertically in a layered architecture and horizontally
in the network path between end-points.

In this respect, hICN, but I should say CCN and NDN realise that principle
with a new way to look at networking.
Essentially naming data sources with location-independent identifiers.
I am far from going to claim credits to the design principles behind
CCN/NDN as it is Van Jacobson and team
who fundamentally designed that system. hICN is a convenient implementation
of CCN into IPv6 to make that
design available in IPv6 now.

Other attempts have introduced networking of location-independent
identifiers in the Internet and the most notable
one is LISP even if it is still the host to be identified.
I would avoid to quote in full Brian Carpenter about this topic so I just
report a reference. It's all in there.

Brian E. Carpenter. 2014. IP addresses considered harmful. *SIGCOMM Comput.
Commun. Rev.* 44, 2 (April 2014), 65-69. DOI:
http://dx.doi.org/10.1145/2602204.2602215

If we look at LISP for instance, the placement of protocol functions
requires to have a mapping system.
It is not exactly an instance of the Occam's razor though. But it is
probably the best solution to a very
specific problem formulation.

The fact that the network has to support all transport protocols is clearly
false. The Internet is also IP multicast,
among other things,
and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only will
never work over IP multicast but
have never been meant to at design time.

hICN mobility for the 5G service based architecture is supposed to run in a
slice for the development of advanced
applications (IoT, AR/VR, MEC etc) but also to rethink current applications
with these new transport services.
This means that alternative solutions for mobility management in 5G, such
as GTP, LISP or derivations of it, are
required to exist.
In the current 5G standardisation effort there might be several mobility
models co-existing and slicing has been
designed in order to enable that.

2) This should probably be a whole new email thread and also other mailing
lists might be a better forum.

It is true that applications make use of a communication API provided by
the OS. But  that's quite generic.
Those functions can be place in different parts of the OS.
Our choice is to move communication functions, essentially the entire
stack, out of the kernel
and use a server stack based on VPP https://git.fd.io and install network
functions just like any application in an application store.
The client stack would also de deployed as a portable app.  iOS 12 is the
first mobile OS to adopt this kind of philosophy and we continue to adopt
that approach for the time being.

The fact that MPTCP encounters difficulties to be fully integrated in a
specific OS component is an implementation issue
that belongs to that particular component. The consequence of  that might
be that multiple  culturally different implementations
and deployment options of network functions  should exist in the future.
Not less.

On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert <[email-masked]> wrote:

> >> > More on the mobility use case which also makes deployment options
> easier
> >> > to
> >> > digest
> >> >
> >> >> deployment/transition  etc. one option may be preferrable over
> another
> >> >> one
> >> >> and SRv6, without opposing one approach to the other, rather
> exploiting
> >> >> in
> >> >> From: Int-area <[email-masked]> on behalf of Behcet
> Sarikaya
> >> >> <[email-masked]>
> >> >>> whereas the DST address is a locator. In this forwarding path a
> lookup
> >> >>> is
> >> >>> find a request (one or many) and the associated locator (one or
> many)
> >> >>> that matches the identifier.
> >> >>> For the replies there is no FIB lookup on the identifier (as it is
> in
> >> >>> the
> >> >>> SRC addr field).
> >> >>>> > The paragraph you reported is from the draft that describes hICN
> to
> >> >>>> > enable
> >> >>>> > several use cases.
> >> >>>> >> > encoded in IPv6 addresses. The transport service sitting on
> top
> >> >>>> >> > of
> >> >>>> >> > the
> >> >>>> >> > hicn
> >> >>>> >> > but on a novel consumer/producer transport service that will
> be
> >> >>>> >> > described in
> >> >>>> >> > another draft.
> >> >>>> >>
> >> >>>> >> > Thanks for the comments already received that helped
> completing
> >> >>>> >> > this -00
> >> >>>> >> > draft.
> >> >>>> >> >
> >> >>>> >> > Luca
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Jun 2018 11:47:00 -0700

> Essentially naming data sources with location-independent identifiers.

LISP, ILA, SRv6, and ILNP also do this. It's a core concept in
identifier locator separation protocols. ILNP requires changes to the
transport layer and endhosts to work, however ILA, SRv6, and LISP
don't-- these protocols operate strictly at the network layer as does
GTP. All of these have the goal to provide anchorless communication
(that could also be done in GTP as well given right changes to the
control plane). ILA and ILNP have they advantage that they don't have
any incur additional packet overhead, although I believe that ILNP
does use some extension headers which might be a convolution to use
over the Internet.

Tom

> I am far from going to claim credits to the design principles behind CCN/NDN
> as it is Van Jacobson and team
> Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM Comput.
> Commun. Rev. 44, 2 (April 2014), 65-69. DOI:
> This means that alternative solutions for mobility management in 5G, such as
> GTP, LISP or derivations of it, are
> required to exist.
> It is true that applications make use of a communication API provided by the
> OS. But  that's quite generic.
> Our choice is to move communication functions, essentially the entire stack,
> out of the kernel
> that belongs to that particular component. The consequence of  that might be
> that multiple  culturally different implementations
> and deployment options of network functions  should exist in the future. Not
> less.
>
>
>
>> >> "The goal of hICN is to ease ICN insertion in existing IP
>> >> infrastructure
>> >> by:
>> >> ...
>> >> >>> channel to recv data or snd data. The replies carry data
>> >> >>> originating
>> >> >>> from
>> >> >>> SRC address before transmission. This is used by an upstream hICN
>> >> >>> or
>> >> >>> the
>> >> >>> 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,
>> >> >>> There can be a lookup in the FIB on the locator stored in the DST
>> >> >>> of
>> >> >>> the
>> >> >>> reply to
>> >> >>>> existing forwarding and routing to forward packets to mobile
>> >> >>>> nodes.
>> >> >>>> So
>> >> >>>> Is this correct? If it is, then I sort of understand how hICN
>> >> >>>> could
>> >> >>>> be
>> >> >>>> >> > the hicn network architecture that implements icn semantics
>> >> >>>> >> > in
>> >> >>>> >> > IPv6
>> >> >>>> >> > networks.
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> instantiated in the application by opening communication
>> >> >>>> >> sockets
>> >> >>>> >> with
>> >> >>>> >> This seems like a pretty dramatic rethink of the transport
>> >> >>>> >> layer
>> >> >>>> >> just

---

From: Luca Muscariello <[email-masked]>
Date: Fri, 22 Jun 2018 10:46:26 +0200

These solutions are not all isomorphic and comparison requires some careful
taxonomy first.
The -01 version of the draft Kalyani is taking care of will include that
and will definitely help to
compare things.
https://datatracker.ietf.org/doc/draft-bogineni-dmm-optimized-mobile-user-plane

Let's wait for that work to be available to the list first, probably next
week.

Luca

On Thu, Jun 21, 2018 at 8:47 PM Tom Herbert <[email-masked]> wrote:

> stack,
> Not