Re: Two new drafts

"Moses, Danny" <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <F0CF5715D3D1884BAC731EA1103AC281027F1957__13996.1636545651$1373981973$gmane$org@HASMSX106.ger.corp.intel.com>
Hi Alper,

Yes, we also were thinking in the same terms of enabling applications to select the appropriate IP address type to handle the use-case of a mobile node invoking applications that require long flows (hence requiring IP session continuity) and short flows (hence using the closest mobility anchor for IP address allocation). See scenario number 6 in section 4.2 of draft-aliahmed-dmm-anchor-selection.

In that scenario, there are cases where a mobility anchor that is not the topologically closest to the base-station might be the best candidate to be the service anchor for applications that require IP session continuity, but is not optimal for applications that do not require it (or actually even worse). Using different IP addresses (provided by different mobility anchors) resolve this conflict.

Let's discuss it further in Berlin.

Regards,
	/Danny

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Alper Yegin
Sent: Tuesday, July 16, 2013 13:31
To: Sri Gundavelli
Cc: [email protected]
Subject: Re: [DMM] Two new drafts

Hi Sri,

On Jul 9, 2013, at 8:22 AM, Sri Gundavelli (sgundave) wrote:

> Hi Alper,
> 
> Thanks for sharing the documents.
> 

Thank you for the feedback.

> I did a quick review of the dmm-ondemand draft. This is inline with my 
> thinking as well. IMO, the following base semantics will allow us to 
> realize some of the DMM deployment models.
> 
> - Prefix Coloring/ Coloring of IP addresses based on the properties
> 
> - Delivering the properties as meta-data in address assignment 
> procedures (ND, DHCP ..)
> - Evolving the source address selection Rules, allowing application to 
> pick source address based on the requirements
> 
> With these semantics, a UE can obtain multiple IP addresses with 
> different properties, bind applications to those addresses based on 
> the application requirements, roam within the network loosing some 
> local addresses and generating some new ones ...
> 
> 

Yes, we are on the same page.


> Slides from 2010 I think ..?
> 
> http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rule
> s-for
> -Mobility-Awareness-2.pdf
> 
> 
> Good to see this. Hope we make progress on these base work such as 
> prefix coloring Šwhich are the enablers ..
> 
> http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt
> http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/
> 
> 
> Your proposal can leverage the above work.
> 
> 

Our work and the above work are different parts of the same puzzle. Above work describes how the different types of IP addresses can be configured on the nodes, and our work describes how the applications running on the nodes can pick among those IP addresses. 

 
Cheers,

Alper



> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 7/8/13 8:30 AM, "Alper Yegin" <[email protected]> wrote:
> 
>> Hello dear DMM folks,
>> 
>> We published the following two new drafts which relate to the DMM WG.
>> 
>> http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt
>> 
>> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt
>> 
>> We'd appreciate if you can read and share your comments.
>> 
>> (Related IPR statements will be posted on the IETF site soon)
>> 
>> Cheers,
>> 
>> Alper
>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
> 

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
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.