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

[Dapeng Liu <[e-mail]>]

Hi Seil,  

You can refer to this: http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTickets  

A simple way would be adding comment to the existing ticket.

--  
Dapeng Liu


在 2015年6月8日 星期一，下午11:56，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:[e-mail]]  
> Sent: Wednesday, June 03, 2015 11:34 AM
> To: Seil Jeon
> Cc: [e-mail] (mailto:[e-mail])
> 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:[e-mail]]  
> Sent: Wednesday, June 03, 2015 7:03 AM
> To: Seil Jeon
> Cc: [e-mail] (mailto:[e-mail])
> 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:[e-mail]]  
> Sent: Monday, June 01, 2015 8:50 PM
> To: Seil Jeon
> Cc: [e-mail] (mailto:[e-mail])
> 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_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.
>  
>  
> >>>  
>  
>  
> >>  
>  
>  
> >> Yes, that's what happens.
>  
>  
> >> You are not pointing to an issue up until this point, right? Because,
>  
>  
> >> you continuing your email with a "Besides" gives the impression that
>  
>  
> >> you are pointing to an issue, but I don't see any issue captured in
>  
>  
> >> the
>  
>  
> > above text.
>  
>  
> >>  
>  
>  
> >>>> There is an issue. Maybe, we need to be synchronized how have you
>  
>  
> >>>> thought
>  
>  
> >> and defined the meaning of "on-demand mobility". As far as I know,
>  
>  
> >> there are two meanings; one is that by imposing capability among IP
>  
>  
> >> address reachability and IP session continuity, needed for an
>  
>  
> >> application, into a source IP address, on-demand mobility could be
>  
>  
> >> achieved; as the other meaning, it can be rephrased and detailed with
>  
>  
> >> dynamic mobility, which should be applied in the use of sustained IP
>  
>  
> >> address. A new application needs to have non-anchored sustained IP
>  
>  
> >> address. This is our consistent claim. Non-optimal routing issue has
>  
>  
> >> been raised in DMM Requirement document in RFC 7333, which should be
>  
>  
> > critically considered in the solutions.
>  
>  
> >>  
>  
>  
> >  
>  
>  
> > Sorry, I don't understand what you meant here.
>  
>  
> >  
>  
>  
> >>>> You answer doesn't make us progress. Please specify where and what
>  
>  
> >>>> you
>  
>  
> > have understood.
>  
>  
> >  
>  
>  
> >  
>  
>  
> >>> 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].
>  
>  
> >>>  
>  
>  
> >>  
>  
>  
> >> OK, is the issue following: When there are multiple sustained IP
>  
>  
> >> addresses, how does the IP stack pick one among them? (*)
>  
>  
> >>  
>  
>  
> >>>> As mentioned and specified in our draft
>  
>  
> >> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,
>  
>  
> >> if there is no additional preference, we can leave selection to the
>  
>  
> >> default source address selection mechanism. BUT if we have specific
>  
>  
> >> preference among multiple sustained IP addresses and an initiated
>  
>  
> >> application wants to have non-anchored sustained IP address over
>  
>  
> >> currently attached access network, the proposed flag is essential.
>  
>  
> >>  
>  
>  
> >  
>  
>  
> > I think you are meaning the same thing as I said above (*).
>  
>  
> > Do you agree?
>  
>  
> >  
>  
>  
> >>>> Yes.
>  
>  
> >  
>  
>  
> >>> 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.
>  
>  
> >>>  
>  
>  
> >>  
>  
>  
> >> Your flag is not a solution to what I captured above. It does
>  
>  
> >> something
>  
>  
> >> else: Instruct the IP stack to go get a new sustained IP address
>  
>  
> >> whether there is already one or more configured on the stack or not.
>  
>  
> >> (**)
>  
>  
> >>  
>  
>  
> >>>> Answered in the above.
>  
>  
> >>  
>  
>  
> >  
>  
>  
> > There's a discrepancy between (*) and your solution (**).
>  
>  
> >  
>  
>  
> > Are we talking about (*), (**), or something else?
>  
>  
> >  
>  
>  
> >>>> There is no discrepancy between them. I said "a new flag", just an
>  
>  
> > additional flag not intending to get a new sustained IP address all
>  
>  
> > the time. And it should not request a new sustained IP address whether
>  
>  
> > there is already one or more configured on the stack or not. It is
>  
>  
> > given with the same expression in the ticket, though our draft is
>  
>  
> > saying the meaning of a new sustained IP address, which will be revised in next update.
>  
>  
> >  
>  
>  
> > 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.
>  
>  
> >  
>  
>  
> >  
>  
>  
> > Seil Jeon
>  
>  
> >  
>  
>  
> >  
>  
>  
> >  
>  
>  
> >  
>  
>  
> >> Alper
>  
>  
> >>  
>  
>  
> >>  
>  
>  
> >>  
>  
>  
> >>> --
>  
>  
> >>> -------------------------+------------------------------------------
>  
>  
> >>> -------------------------+-
>  
>  
> >>> -------------------------+---
>  
>  
> >>> -------------------------+---
>  
>  
> >>> Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
>  
>  
> >>> [e-mail] (mailto:[e-mail])      |  [e-mail] (mailto:[e-mail])
>  
>  
> >>>   Type:  defect       |     Status:  new
>  
>  
> >>> Priority:  critical     |  Milestone:
>  
>  
> >>> Component:  ondemand-    |    Version:
>  
>  
> >>> mobility               |   Keywords:  on-demand mobility
>  
>  
> >>> Severity:  Submitted    |
>  
>  
> >>> WG Document            |
>  
>  
> >>> -------------------------+------------------------------------------
>  
>  
> >>> -------------------------+-
>  
>  
> >>> -------------------------+---
>  
>  
> >>> -------------------------+---
>  
>  
> >>>  
>  
>  
> >>> Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>
>  
>  
> >>> dmm <http://tools.ietf.org/dmm/>
>  
>  
> >>>  
>  
>  
> >>>  
>  
>  
> >>> _______________________________________________
>  
>  
> >>> dmm mailing list
>  
>  
> >>> [e-mail] (mailto:[e-mail])
>  
>  
> >>> https://www.ietf.org/mailman/listinfo/dmm
>  
>  
> >>  
>  
>  
> >>  
>  
>  
> >  
>  
>  
> >  
>  
>  
>  
>  
>  
>  
>   
>  
>  
>  
> _______________________________________________
> dmm mailing list
> [e-mail] (mailto:[e-mail])
> https://www.ietf.org/mailman/listinfo/dmm
>  
>  
>