Subject: [DMM] Two new drafts

From: Alper Yegin <[email-masked]>
Date: Mon, 8 Jul 2013 18:30:22 +0300

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Jul 2013 05:22:45 +0000

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

Regards
Sri

On 7/8/13 8:30 AM, "Alper Yegin" <[email-masked]> wrote:

>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 9 Jul 2013 11:02:53 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Sri
Gundavelli (sgundave)
Sent: Tuesday, July 09, 2013 6:23 AM
To: Alper Yegin; [email-masked]
Subject: Re: [DMM] Two new drafts

Hi Alper,

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.

- 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

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 9 Jul 2013 19:45:51 +0000

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

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 10 Jul 2013 13:33:28 +0100

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-masked]] 
Sent: Tuesday, July 09, 2013 8:46 PM
To: Seil Jeon
Cc: 'Alper Yegin'; [email-masked]
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-masked]> wrote:

>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>Sri Gundavelli (sgundave)
>- Delivering the properties as meta-data in address assignment 
>procedures (ND, DHCP ..)
>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 ...
> 
>
>http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules
>-fo
>r
>Good to see this. Hope we make progress on these base work such as 
>prefix coloring Šwhich are the enablers ..
>

---

From: Alper Yegin <[email-masked]>
Date: Tue, 16 Jul 2013 13:30:59 +0300

Hi Sri,

> Thanks for sharing the documents.

Thank you for the feedback.

> generating some new ones ...

Yes, we are on the same page.

> 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

---

From: "Moses, Danny" <[email-masked]>
Date: Tue, 16 Jul 2013 13:39:17 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Tuesday, July 16, 2013 13:31
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [DMM] Two new drafts

Hi Sri,

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

Cheers,

Alper

_______________________________________________
dmm mailing list
[email-masked]
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.