Subject: Re: [DMM] New name for topic: Supporting both PMIP and MIP

From: "Moses, Danny" <[email-masked]>
Date: Wed, 21 Dec 2016 08:36:44 +0000

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-masked]]
Sent: Tuesday, December 20, 2016 16:35
To: Moses, Danny <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: [email-masked]; [email-masked]
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-masked]]
Sent: Monday, December 19, 2016 6:16 AM
To: Lorenzo Colitti; Dave Dolson
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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-masked]]
Sent: Monday, December 19, 2016 03:04
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Cc: Moses, Danny <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> 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.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 21 Dec 2016 16:05:58 +0000

Danny,
Your explanation is still too low-level for the API, since it requires driver-level knowledge at the IP stack.
As I understand it, tunnels are usually implemented as special interfaces, beneath which tunneling occurs.

So at the socket layer of abstraction, the operating system is aware of multiple interfaces, each having an IP address and subnet prefix.
(On some operating systems an interface may have multiple IP addresses/lengths.)

I imagine the operating system will require enhancement to assign properties of Non-persistent, Session-lasting & Fixed to each address in the system. These properties are access-agnostic.

I’m not clear on what mechanism would trigger obtaining a new address on-demand. This would be like establishing a VPN, usually requiring a process to bring up a new interface. (Seldom do applications bring up VPN interfaces.)

Also, it occurs to me that the device running the application might NOT be the device establishing the tunnel. A gateway router (e.g., WiFi hotspot) could join a mobile network and advertise two prefixes to the devices on the network, one being Fixed and the other being temporary. I imagine there could be a DHCP mechanism to convey which is which.

Considering also Lorenzo’s concern about changing non-blocking functions into blocking operations, I’m inclined to think the socket options should only express preference for addresses already obtained, not trigger a blocking operation. Provide a different mechanism to obtain an address on demand, like starting a VPN.

-Dave

From: Moses, Danny [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 3:37 AM
To: Dave Dolson; Lorenzo Colitti
Cc: [email-masked]; [email-masked]
Subject: RE: [DMM] New name for topic: Supporting both PMIP and MIP

Thanks,
Danny

Danny,

-Dave

OK, two is a crowd…

Danny

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 22 Dec 2016 11:25:30 +0000

Hi Dave,

I was not planning to add this explanation to the draft since, like you indicated, it is relevant to the TCP/IP stack implementation and does not concern the applications developers. I just wanted to make sure we are on the same page. Perhaps we should consider a different draft with guidelines to stack developers, but let’s first complete our current work.

As to the rest of the work, I recall three items I need to do:

1.      Fix some additional text – requested by Lorenzo regarding the request from the network (prefix stuff…)

2.      Provide a code example

3.      Discuss whether to move the OnDemand API to a separate function call (blocking) or not

I will be on vacation next week, but will try and complete (1) and (2) before the end of the year. I want to elaborate about (3) and discuss with you (and the WG).

I hope we can resolve all issues and release the final draft early January.

Best regards ad happy holidays,
Danny

Sent: Wednesday, December 21, 2016 18:06

Danny,

-Dave

Thanks,
Danny

To: Moses, Danny <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>

Danny,

-Dave

OK, two is a crowd…

Danny