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

[Uma Chunduri <[e-mail]>]

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[e-mail]]
Sent: Wednesday, May 10, 2017 5:58 PM
To: Uma Chunduri <[e-mail]>
Cc: Behcet Sarikaya <[e-mail]>; Lorenzo Colitti <[e-mail]>; [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 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.

[Uma]: I don't see any confusion.
               I was just saying the solution you described here https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
               doesn't solve IP address change case (UPF change) but only addresses (R)AN mobility.

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.

[Uma]: Precisely  and I don't see how you get that stable identifier in ILA where you split Identity and Locator (ILA) logically  in the same UE address where your host on the other end is communicating to (in your example https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )


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