Hi Alper and DMM folks, We have tried to refine the issue in the on-demand WG draft as forwarded. I hope the issue has been clearly defined through the elaborated texts. I'd like to get opinions on it.
Regards, Seil -----Original Message----- From: dmm issue tracker [mailto:[email protected]] Sent: Tuesday, June 09, 2015 4:34 PM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [dmm] #49 (ondemand-mobility): observation of on-demand mobility (was: full on-demand mobility support) #49: observation of on-demand mobility Changes (by [email protected]): * cc: [email protected] (added) Comment: The on-demand draft proposed three source IP address types, enabling applications to configure the required type in the IP stack, according to IP mobility requirements. Particularly, the sustained IP address is proposed to provide on-demand IP mobility, which aims at activating IP mobility support operation upon an MN's movement. Delivering the defined flag, IPV6_REQ_SUSTAINED_IP, from an application to the IP stack through the socket API does not ensure the observation of on- demand mobility principle where IP mobility is provided upon an MN’s movement, because an initiated application may be served with IP mobility even though the MN has not moved from the current serving network where the IP prefix/address was assigned for the application. As a result, IP mobility is activated before needed. An example scenario raising the aforementioned issue is as follows; 1. The MN is configured with one or more Nomadic IP addresses. 2. Once an application requests “sustained IP address” to the IP stack, it will obtain a sustained IP address through a protocol procedure between the MN and network. 3. Other application initiated over the same serving network will use the same sustained IP address while the MN remains connected at the same serving network. 4. The MN moves to another access network, and the previous (mobile) sessions are working. A new application requests a sustained IP address. The existing sustained IP address is assigned to the new application as a sustained IP address is already available in the IP stack. 5. As a consequence, the new session is served by a remote IP mobility anchor with necessary management functions, though the MN has not moved yet. Moreover, we can suppose an example over a different address assignment strategy, where each network assigns sustained IP addresses, i.e. sustained IP address assignment by default, enables an MN to have multiple sustained IP addresses. When a new application is initiated and needs a sustained IP address, the IP stack may or not select the locally assigned one in the context of the default source IP address selection mechanism [RFC6724][RFC5014], as the application has no means to explicitly request such a demand to the IP stack. For providing the full on-demand mobility when using sustained IP address, a new address preference flag will be needed, letting the IP stack select a sustained IP address assigned from the current serving network. If not available, it should request a sustained IP address from the serving network. -- -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-dmm-ondemand- [email protected] | [email protected] Type: defect | Status: new Priority: critical | Milestone: Component: ondemand- | Version: mobility | Resolution: Severity: Submitted | WG Document | Keywords: on-demand | mobility | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49#comment:1> dmm <http://tools.ietf.org/dmm/> _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
