Re: Two new drafts

Hi Sri,

In the sense that NAT-based solutions have not been documented in the 3GPP
standards and the NATing with single PDN connection would give complexities
much in handling the flows and dynamically applying policies, I agree with
your opinions. Additionally, I took the potential of putting mobility
properties to prefixes into my head, though it needs to be reviewed more in
the way.

Regards,
Seil


-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email protected]] 
Sent: Tuesday, July 09, 2013 8:46 PM
To: Seil Jeon
Cc: 'Alper Yegin'; [email protected]
Subject: Re: [DMM] Two new drafts

Hi Seil,

In one abstraction, that middleware is the socket layer performing address
binding. The key point is that we need to add additional meta-data to a
prefix and carry them in ND/DHCP from the network to the host. So, the host
has awareness on different types of IP addresses for use and with the
corresponding properties. This helps in DMM solution, also for supporting
SIPTO in WLAN-EPC integrated solutions. We don't have to deal with monster
NAT's in case of IPv6-based flow offload.



Regards
Sri




 

On 7/9/13 3:02 AM, "Seil Jeon" <[email protected]> wrote:

>Hi Sri,
>
>Picking source address by an application would be the right way to go?
>I've
>known that's the work of the middleware.
>The middleware needs to be aware of the applications and thus to act 
>properly.
>
>Regards
>Seil
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On Behalf Of 
>Sri Gundavelli (sgundave)
>Sent: Tuesday, July 09, 2013 6:23 AM
>To: Alper Yegin; [email protected]
>Subject: Re: [DMM] Two new drafts
>
>Hi Alper,
>
>Thanks for sharing the documents.
>
>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 ...
> 
>
>Slides from 2010 I think ..?
>
>http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules
>-fo
>r
>-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.
>
>
>
>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
>