Actually this is an interesting point. I would like to add some details to make sure we are in sync:
Since applications may be running on mobile nodes with mobility services either provided by proxy by the network, or co-handled by terminating tunnels (MIP), the implementation of the local IP stack is different (but transparent to the applications). If, the mobile node is receiving mobility services by proxy, the service request will be forwarded to the network (as described in the current version of the draft). If, however, the mobile node is handling the termination point of the tunnel, e.g. encapsulating outgoing packets and decapsulating incoming packets, the service request is handled differently: · If an application requests a Non-persistent IP address, the IP stack will provide a CoA to it (either from an existing one or by requesting a prefix from the network). Packets generated by this application will not be encapsulated by the IP stack before being transmitted. · If an application requests a Session-lasting IP address, the IP stack will provide the HOME address and will encapsulate each generated packet with an outer IP header using a CoA as the source IP address. The IP stack will also decapsulate incoming packets for this application. · If an application requests a Fixed IP address, the IP stack, similar to the Session-lasting case, will provide a HOME address and perform the encapsulation/decapsulation service. But the HOME address will be generated from an IP prefix with a network guarantee to be fixed. Does this text describe accurately your intention? Thanks, Danny From: Dave Dolson [mailto:[email protected]] Sent: Tuesday, December 20, 2016 16:35 To: Moses, Danny <[email protected]>; Lorenzo Colitti <[email protected]> Cc: [email protected]; [email protected] Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 -- Danny, Thank you for explaining. I read this draft without knowing the back story, and I did not glean the explanation below from the draft. If you want the explanation recorded for posterity, it should be in the draft. Having said that, it would be better, in my opinion, if this API is NOT specific to proxy-based architectures. An application programmer is concerned with whether it needs a long-lasting address or whether an ephemeral address is acceptable. (i.e., am I a client or a server?) I don’t see many application programmers concerned with on-demand DMM per se. -Dave From: Moses, Danny [mailto:[email protected]] Sent: Monday, December 19, 2016 6:16 AM To: Lorenzo Colitti; Dave Dolson Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 -- OK, two is a crowd… I am thinking of the appropriate example and will send a draft for review. I think there might be a confusion regarding the HOME and CoA flags. Although they are also related to mobility and enable applications a selection between two types of source IP addresses, they are very different and should not be discussed in the context of OnDemand. The HOME and CoA flags are defined to enable an application to select between a HOME address and a Care-of address. This is in the context of Mobile IP (no Proxy Mobile IP) in which the network allocates both a Home Address and a Care-of Address to the mobile host. These flags enable applications to select the type of IP session continuity in this context (where the host is one termination point of the tunnel). The context of the OnDemand draft is PMIP (or any proxy-based architecture, like GTP). In this context, the mobile host does not have a Home Address and a Care-of-Address since the tunnel is terminated by a proxy agent. So an application cannot specify its preference regarding Home or CoA. Danny From: Lorenzo Colitti [mailto:[email protected]] Sent: Monday, December 19, 2016 03:04 To: Dave Dolson <[email protected]<mailto:[email protected]>> Cc: Moses, Danny <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 -- rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson <[email protected]<mailto:[email protected]>> wrote: 5. Are there new errors from bind(), listen() or connect(), etc.? E.g., socket option is FIXED, but user explicitly specified a COA address to bind to? +1. An implementer would probably choose to return EADDRNOTAVAIL if an API requested a type of address that is not available, but the draft makes no mention of that. The draft also fails to mention which of the APIs will result in a request to the network (which can block for a long period of time) and which will not. It will be quite unexpected to app developers if system calls such as bind() and setsockopt(), which always return immediately, can suddenly block for whole seconds. It would also be highly unexpected if connect() on a UDP socket took a long time since it currently returns immediately. I don't think it's a good idea to overload these existing system calls with new "obtain an prefix from the network" semantics. It's better to add a new system call for that. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
