Hi Alper, As Seil wrote, the problem which this ticket intends to reflect is that of non-optimal routing as a result of not being able to request a non-anchored (or local) source IP address. This might be a problem in any scenario where new Sustained IP addresses are not assigned by default at the new network. The intention of the flag is not to request a new prefix, but to assure a source address associated to a local network is used. Which, in cases where it is not available, leads to the configuration of a new one.
Best regards, Sergio 2, rue Paul Vaillant-Couturier 92300 Levallois-Perret FRANCE Tel. : +33 (0)1 46 17 46 17 -----Original Message----- From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin Sent: sexta-feira, 22 de Maio de 2015 12:08 To: Seil Jeon Cc: [email protected] Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support Hi Seil, Thanks for creating the ticket. Please see below. > > #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. > 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? > 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. Alper > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: | Owner: draft-ietf-dmm-ondemand- > [email protected] | [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
