[DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support

[Seil Jeon]

Hi DMM folks,

Yesterday, I created a ticket on the on-demand mobility issue. I believe this 
is critical to be essentially implemented in the on-demand WG draft.
We can start a discussion based on the raised description.

Best Regards,
Seil Jeon 


-Original Message-
From: dmm issue tracker [mailto:trac+...@tools.ietf.org] 
Sent: Tuesday, May 19, 2015 6:43 PM
To: draft-ietf-dmm-ondemand-mobil...@tools.ietf.org; seilj...@av.it.pt
Cc: dmm@ietf.org
Subject: [dmm] #49 (ondemand-mobility): full on-demand mobility support

#49: full on-demand mobility support

 The three proposed flags express a “type” of source IP address an  application 
wants to get to the IP stack. Particularly, the sustained IP  address is 
proposed to provide on-demand IP session continuity, which  activates IP 
mobility once the terminal moves across other access network.
 While the terminal stays at the same network where the session is  initiated, 
regular IP routing is applied.

 The on-demand draft does not assure provide the full on-demand mobility  for 
all scenarios by merely indicating the Socket API,  IPV6_REQ_SUSTAINED_IP. An 
example scenario raising the aforementioned  issue is as follows;

 0. The MN is configured with one or more Nomadic IP addresses.

 1. Once an app. requests “sustained IP address” to the IP stack, and it  will 
obtain a sustained IP address through a protocol procedure between  the 
terminal and network.

 2. Other app. initiated over the same access network will use the same  
sustained IP address while the terminal remains connected at the same  access 
network.

 3. The terminal moves to another access network and a new app. requests a  
sustained IP address with the Socket API to the IP stack. Since a  sustained IP 
address is already available in the IP stack, the sustained  IP address is 
assigned to the new app.

 Besides, in case sustained IP address allocation is used default, there  may 
be multiple sustained IP addresses including newly obtained sustained  IP 
address over the new access network in the IP stack. However, when an  app. is 
initiated, the IP stack may not select the new one in the context  of the 
default source IP address selection mechanism [RFC6724][RFC5014].

 For providing the full on-demand mobility, a new flag is needed, letting  the 
IP stack request a new sustained IP address or choose a sustained IP  address 
not requiring IP mobility anchoring when an application is  initiated, among 
the existing ones in the IP stack.

-- 
-+--
-+---
 Reporter:   |  Owner:  draft-ietf-dmm-ondemand-
  seilj...@av.it.pt  |  mobil...@tools.ietf.org
 Type:  defect   | Status:  new
 Priority:  critical |  Milestone:
Component:  ondemand-|Version:
  mobility   |   Keywords:  on-demand mobility
 Severity:  Submitted|
  WG Document|
-+--
-+---

Ticket URL: 
dmm 


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support

[Seil Jeon]

Hi Chairs,

 

We want to elaborate the issue created in the tracker for clarity. What
Action should I take in "Modify Ticket"?

 

- leave as new

- resolve as .

- reassign to .

 

 

Regards,

Seil

 

From: Alper Yegin [mailto:alper.ye...@yegin.org] 
Sent: Wednesday, June 03, 2015 11:34 AM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

 

OK, so now at least I fully understand what this is.

 

My recommendation is:

- Please refine the issue definition in the tracker, so that people can
understand this the same way,

- And then let's ask the WG members their opinion about the issue (whether
it's something worth tackling or not),

- And if they agree to the issue, then we move to the solution space
discussion.

 

Alper

 

 

On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote:





- A Sustained IP address that just got allocated from the currently serving
network (hence the "mobility is not activated" until the MN moves off link)?

> Yes. Thanks for your elaboration.

 

 

Regards,

Seil

 

 

From: Alper Yegin [mailto:alper.ye...@yegin.org] 
Sent: Wednesday, June 03, 2015 7:03 AM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

 

So, the idea is, when this flag is set along with a Sustained IP address
request from the app:

- if the host stack is already configured with a Sustained IP address
allocated from the serving network, then it gets selected (irrespective of
the presence or absence of any other Sustained IP address).

 

>> No. I said "one that does not activate IP mobility" over the serving
network, among the existing ones in the IP stack, gets selected. If no one
in the IP stack is not matched, it will make an attempt to get a new
sustained IP address from the serving network.

 

 

What exactly is "(an IP address) that does not activate IP mobility"? Please
elaborate.

 

Is it

- A nomadic IP address?

 

- A Sustained IP address that just got allocated from the currently serving
network (hence the "mobility is not activated" until the MN moves off link)?

 

- something else?

 

Alper

 

 

 

 

On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote:






Hi Alper,

 

Regards,

Seil

 

 

-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

 

> The point is that when the IP stack receives a flag with sustained IP

> address flag, it will check it has a sustained IP address, and if it

> has one or more, one that does not activate IP mobility will be

> selected. If not, the MN will be triggered to get a new IP sustained

> address not activing IP mobility.

 

So, the idea is, when this flag is set along with a Sustained IP address
request from the app:

- if the host stack is already configured with a Sustained IP address
allocated from the serving network, then it gets selected (irrespective of
the presence or absence of any other Sustained IP address).

 

>> No. I said "one that does not activate IP mobility" over the serving
network, among the existing ones in the IP stack, gets selected. If no one
in the IP stack is not matched, it will make an attempt to get a new
sustained IP address from the serving network.

 

- if the host stack is not already configured with a Sustained IP address
allocated from the serving network (irrespective of the presence or absence
of any Sustained IP address from any other network), then the host makes an
attempt to configure one with the serving network.

 

>> Yes.

 

-- if the configuration succeeds, then the newly configured IP address is
selected.

 

>> Yes.

 

-- if the configuration fails. then the call fails (?? or some other
behavior -- you can define here).

 

>> You mean the configuration fails when there is no sustained IP address,
right?

In my opinion, this issue belongs to address configuration mechanism based
on definition of the three DMM APIs. Those jobs are/will be asked on each
configuration mechanism, according to discussion of the previous
teleconference in the WT you're leading. At that time, if I see any
something related to our proposal, we will raise our voice.

 

 

 

 

Alper

 

 

 

 

 

 

>>> #49: full on-demand mobility support

>>> 

>>> The three proposed flags express a "type" of source IP address an

>> application wants to get to the IP stack. Particularly, the sustained

>> IP address is proposed to provide on-demand IP session continuity,

>> which activates IP mobility once the terminal moves across other

>> access

> network.

>>> While the terminal stays at the same network where the session is

>> initiated, regular IP routing is applied.

>>> 

>>> The on-demand draft does not assure provide the full on-demand

>>> mobility

>> for all scenarios by merely indicating the Socket API,

>> IPV6_REQ_SUSTAIN

Re: [DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support

[Jouni Korhonen]

Add your comments/modifiactions to "add a comment" box and modify ticket 
"leave as new".


- Jouni

6/8/2015, 8:56 AM, Seil Jeon kirjoitti:

Hi Chairs,

We want to elaborate the issue created in the tracker for clarity. What
Action should I take in “Modify Ticket”?

- leave as new

- resolve as …

- reassign to …

Regards,

Seil

*From:*Alper Yegin [mailto:alper.ye...@yegin.org]
*Sent:* Wednesday, June 03, 2015 11:34 AM
*To:* Seil Jeon
*Cc:* dmm@ietf.org
*Subject:* Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand
mobility support

OK, so now at least I fully understand what this is.

My recommendation is:

- Please refine the issue definition in the tracker, so that people can
understand this the same way,

- And then let's ask the WG members their opinion about the issue
(whether it's something worth tackling or not),

- And if they agree to the issue, then we move to the solution space
discussion.

Alper

On Jun 3, 2015, at 1:12 PM, Seil Jeon wrote:



- A Sustained IP address that just got allocated from the currently
serving network (hence the "mobility is not activated" until the MN
moves off link)?


Yes. Thanks for your elaboration.


Regards,

Seil

*From:*Alper Yegin [mailto:alper.ye...@yegin.org]
*Sent:*Wednesday, June 03, 2015 7:03 AM
*To:*Seil Jeon
*Cc:*dmm@ietf.org 
*Subject:*Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand
mobility support

So, the idea is, when this flag is set along with a Sustained IP
address request from the app:

- if the host stack is already configured with a Sustained IP
address allocated from the serving network, then it gets selected
(irrespective of the presence or absence of any other Sustained IP
address).

>> No. I said "one that does not activate IP mobility" over the serving 
network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is 
not matched, it will make an attempt to get a new sustained IP address from the serving network.

What exactly is "(an IP address) that does not activate IP mobility"?
Please elaborate.

Is it

- A nomadic IP address?

- A Sustained IP address that just got allocated from the currently
serving network (hence the "mobility is not activated" until the MN
moves off link)?

- something else?

Alper

On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote:




Hi Alper,

Regards,

Seil

-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc:dmm@ietf.org 
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand
mobility support


The point is that when the IP stack receives a flag with sustained IP



address flag, it will check it has a sustained IP address, and if it



has one or more, one that does not activate IP mobility will be



selected. If not, the MN will be triggered to get a new IP sustained



address not activing IP mobility.


So, the idea is, when this flag is set along with a Sustained IP address
request from the app:

- if the host stack is already configured with a Sustained IP address
allocated from the serving network, then it gets selected (irrespective
of the presence or absence of any other Sustained IP address).


No. I said "one that does not activate IP mobility" over the serving network, 
among the existing ones in the IP stack, gets selected. If no one in the IP stack is not 
matched, it will make an attempt to get a new sustained IP address from the serving 
network.


- if the host stack is not already configured with a Sustained IP
address allocated from the serving network (irrespective of the presence
or absence of any Sustained IP address from any other network), then the
host makes an attempt to configure one with the serving network.


Yes.


-- if the configuration succeeds, then the newly configured IP address
is selected.


Yes.


-- if the configuration fails. then the call fails (?? or some other
behavior -- you can define here).


You mean the configuration fails when there is no sustained IP address, right?


In my opinion, this issue belongs to address configuration mechanism
based on definition of the three DMM APIs. Those jobs are/will be asked
on each configuration mechanism, according to discussion of the previous
teleconference in the WT you’re leading. At that time, if I see any
something related to our proposal, we will raise our voice.

Alper


#49: full on-demand mobility support







The three proposed flags express a "type" of source IP address an



application wants to get to the IP stack. Particularly, the sustained



IP address is proposed to provide on-demand IP session continuity,



which activates IP mobility once the terminal moves across other



access



network.



While the terminal stays at the same network where the session is



initiated, regular IP routing is applied.







The on-demand draft does not assure provide the full on-demand



mobility



for all scenarios b