Hello Sergio, On May 22, 2015, at 6:24 PM, FIGUEIREDO Sergio wrote:
> 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. A non-anchored (local) address is called Nomadic IP Address. If the app needs one such address, then it can ask one and get one. API already supports that. > 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. > Alper > 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
