Hello Seil, > >> >> #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. >> 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? >> 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? Alper > Alper > > > >> -- >> -------------------------+---------------------------------------------- >> -------------------------+--- >> 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: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> >> dmm <http://tools.ietf.org/dmm/> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
