Re: regarding the re-chartering..

Alexandru Petrescu <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <[email protected]>
Le 05/09/2014 14:45, Alper Yegin a écrit :
> Hi Alex,
>
> On Sep 5, 2014, at 3:32 PM, Alexandru Petrescu wrote:
>
>> Le 05/09/2014 10:48, Alper Yegin a écrit :
>>> Alex,
>>>
>>> DMM is not meant to be only about a bunch of MIP-based
>>> solutions. There are various components in DMM solution space
>>> that'd also work with GTP-based architectures. For example,
>>> identifying the mobility needs of flows. Or, conveying the
>>> mobility characteristic of a prefix to the UE.
>>
>> Alper - thanks for the reply.
>>
>> Identifying the mobility needs of flows assumes that IP flows _can_
>> be characterized, and then distinguished as mobile - or non-mobile.
>> I think this is very hard to do, given the difficulty to write good
>> firewall rules, and the difficulty of analyzing traffic dumps.
>>
>> For example, Netalyzr was written to tell whether or not one's
>> computer is connected to the Internet.  That report page has so
>> many lines that it is hard to tell which part of it really means
>> 'connected to the Internet'.
>>
>> The same problem may arise when trying to identify a particular
>> 'flow'.
>>
>
> The most robust way is to let the application tell the IP stack.
>
> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt

Sounds reasonable.

A complimentary means is to look at this as a source address selection 
problem: given two addresses configured on an interface (an IP address, 
and an IP address designated as CoA), the application selects the src 
address as the IP address if its flows are brief query/response (http), 
or it selects the src address as the CoA if its flows are longer timed 
(request of UDP stream, or TCP download).

This would need a means to designate to the stack an IP address as to be 
a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by 
deduction any address differing be the CoA.

Alex

>
> Alper
>
>
>
>> Alex
>>
>>
>>
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:
>>>
>>>> Le 03/09/2014 20:53, Brian Haberman a écrit :
>>>>> Behcet,
>>>>>
>>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote:
>>>>>>
>>>>>> You don't seem to understand my points.
>>>>>
>>>>> That is quite possible.  Your comment on the list was "I am
>>>>> against any deployment work before we decide on a
>>>>> solution..."
>>>>>
>>>>> I read that as an objection to having the deployment models
>>>>> work item on the agenda.  Please do tell me what I am
>>>>> missing.
>>>>>
>>>>> Regards, Brian
>>>>
>>>> Hi,
>>>>
>>>> I am following the discussion and me too I do not quite
>>>> understand what is the complain.
>>>>
>>>> I am happy to learn that a if a WG is to be formed then it
>>>> would be around a solution rather than just requirements or
>>>> architecture.
>>>>
>>>> That said, I would like to express a worry along similar
>>>> lines.
>>>>
>>>> In DMM, precedents and the keen NETEXT, there seems to be a
>>>> hard-rooted disconnect between the product developped -
>>>> (P)Mobile IP - and the deployments.  We know for a fact that
>>>> 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP.  We also
>>>> know that 3GPP specs do mention Mobile IP. To such a point that
>>>> I wonder whether 3GPP has not the same disconnect as here.
>>>>
>>>> On another hand, we do have indications of where (P)Mobile IP
>>>> is used - the trials, the projects, the kernel code, and not
>>>> least the slideware attracting real customers.
>>>>
>>>> The worry: develop DMM protocol while continuing the
>>>> disconnect.
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ dmm mailing
>>>>> list [email protected] https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>>>
>>>> _______________________________________________ dmm mailing
>>>> list [email protected] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>>
>>
>>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.