Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

[Behcet Sarikaya <[e-mail]>]

On Wed, May 10, 2017 at 7:58 PM, Tom Herbert <[e-mail]> wrote:

> On Wed, May 10, 2017 at 5:10 PM, Uma Chunduri <[e-mail]>
> wrote:
> > + IDEAS
> >
> > https://tools.ietf.org/html/draft-padma-ideas-use-cases-00
> >
> > Section 7 covers this use case - I saw you are part of this (may be this
> use case didn't come from you)
> >
> > This is being worked out  and solution would be put forth soon..
> >
> Okay, I think I see the confusion.
>
> In an Identifier/Locator split there are two addresses that are
> associate with a node. One is the identifier that expresses the
> logical and persistent address of the node ("who")-- this what
> applications see and what might returned from DNS if an addressed is
> looked by domain name. The other address is the locator, this
> expresses where the node is current at ("where"). As a mobile node
> moves from place to place it's location changes so it's locator
> changes. But, it's identifier address does not change-- that uniquely
> identifies the node regardless of where it's at. In order to send to a
> node (by it's identifier address, a some point in the path, someone
> needs to know to that to reach the addressed node the packet has to be
> sent to its locator address. So there is a mapping from identifier to
> locator and then packet is forwarded to locator address (by
> encapsulation, segment routing, ILA, etc.). This really equivalent to
> virtual to physical address mapping, or home address to mobile
> address.
>
> So it's really the locator address for a node that changes, not the
> the identifier. The system needs to ensure that packets delivered to
> the application always get the identifier address and that keeps
> source address persistent.
>
>
Folks, these are Tom's personal thinking. Those that are not mentioned in
the PS draft are not in scope.

Behcet

> Tom
>
> >
> > --
> > Uma C.
> >
> >
> > -----Original Message-----
> > From: Tom Herbert [mailto:[e-mail]]
> > Sent: Wednesday, May 10, 2017 5:00 PM
> > To: Uma Chunduri <[e-mail]>
> > Cc: Behcet Sarikaya <[e-mail]>; Lorenzo Colitti <
> [e-mail]>; [e-mail]; [e-mail]
> > Subject: Re: [5gangip] FW: New Version Notification for
> draft-xyx-5gip-ps-00.txt
> >
> > On Wed, May 10, 2017 at 4:47 PM, Uma Chunduri <[e-mail]>
> wrote:
> >>
> >>         >No, the source address does not change, TCP connections don't
> break.
> >>
> >> Source address can change if UE moves from UPF serving area.
> >> But, now I see your case is (R)AN mobility case (same UPF serving area).
> >>
> >>         >Please see my example I posted previously. Overlay networks
> (tunnels) are used between EnodeBs and gateways.
> >>                 >A distributed mapping service is run that these nodes
> share, so the Internet can communicate with mobile hosts and mobile hosts
> can communicate between themselves.
> >>                >This method is transparent to hosts including UEs and
> there are no changes need to transport layer. It's a fairly straightforward
> use of tunneling once an efficient mapping system is in place.
> >>
> >> I get that.
> >>
> >> Then this is may be good for 4G, but I guess we are talking about 5G
> here and I assumes PGW/UPF mobility and hence the Source IP address change
> is considered in your solution.
> >>
> > In that case the TCP connection would break regardless. Transport layer
> mobility, like QUIC, might then be solution.
> >
> >> --
> >> Uma C.
> >>
>