We still have to address the problem of fixed interaction. For example, in the example of making a future reservation from a Sandman-1 endpoint to a Sandman-3 endpoint in section it was assumed that the data channel between the two domains was set up immediately. This may be the right solution in certain cases but not necessarily in others (as shown in section ). We now propose a very simple solution to this shortcoming.
Essentially, we allow applications to define their own pseudo-endpoints (if necessary with their own ISSC and data channels). For this we use DLAs, as discussed in section . So, users are allowed to load up their own gateway code dynamically. Of course, there have to be restrictions on this, as we don't want application-specific and maybe faulty pseudo-endpoint code to become the only available option for all applications. A simple solution is to enable users to associate their own pseudo-endpoint with a particular netlet (assuming the netlet owns capacity on the outgoing link). Now, whenever a connection to a remote endpoint is made in this netlet, the netlet gateway is used to communicate with the neighbouring MCA (as well as with the remote Sandman, using the netlet ISSC).
This allows applications to specify exactly the mapping between Sandman operations and the operations supported by the neighbouring domain. For example, a netlet gateway may decide not to map a future reservation onto an immediate connection in the neighbouring domain, choosing instead to wait until the start of the reservation interval (e.g., because it knows that bandwidth is unlimited in MCA-X).
The implementation of the application-defined netlet gateway feature is currently under way.