We first address the problem of functionality degradation. We stress again the fact that the Sandman serves only as an example MCA--the exact same issues need to be addressed when interconnecting other types of MCA. Observe that functionality degradation occurs when multiple Sandman domains are on the paths between the endpoints and when these Sandman domains are separated by non-Sandman MCAs. If no other Sandman domains are involved, we can't do better than the hop-by-hop solution.
When multiple Sandman domains are involved, however, we propose to implement an inter-Sandman signalling channel (ISSC) between each two adjacent Sandman domains (possibly separated by a number of MCA-X domains). This is illustrated in Figure . As indicated in the figure, there is no need to dedicate a well-known vpi-vci value for the signalling channel. The channel can be set up simply using hop-by-hop inter-domain communication as described in section (lowest common denominator is good enough for setting up simple signalling channels). All intermediate domains simply pass on the Sandman control messages without even looking at them (tunnelling). As usual, the ISSC finds its endpoints in the control gateways of both Sandman domains (in other words, the control gateways are the entities that signal to each other).
Now, when Sandman-1 wants to communicate with Sandman-3 (Figure ), it sets up a data connection between the two MCA domains. Ostensibly, the data connections also find their endpoints in the pseudo-endpoints described in section , so that the pseudo-endpoints (i.e. the control gateways) get notified when connections are set up which allows them to handle these connections further (outside the local domain). The pseudo-endpoints take care of the administration and maintenance of these connections. Inside the two Sandman domains however, these inter-domain data channels can be connected in any way the MCA wants to. So the data channels are really data tunnels connecting two Sandman domains. The further connection of these data channels on the remote side is controlled by signalling over the ISSC. Note that it is still not necessary for one Sandman domain to have precise knowledge of the topology of the remote domain: all routing is local to the individual domains. Note also that it is possible to set up data channels in advance or leave them in place after a certain application is done with them. We call this tunnel caching.
So to take up the example again of a reservation in advance for a connection from endpoint 1 in Sandman-1 to endpoint 6 in Sandman-3 (in Figure ), this now becomes a matter of grabbing a data channel between the two Sandman domains and then making a local reservation in advance in Sandman-1 which is transferred over the ISSC to Sandman-3. Sandman-3's control gateway picks up the request and tries to make an advance reservation from link L3 to the eventual destination. If successful, it returns true. If not, the actions in Sandman-1 are also rolled back. At the start of the reservation interval, the connections are set up locally on both sides and connected to the VC of the chosen data channel.
We now have full interoperation between islands of Sandman domains, providing the full functionality of the MCA, while being interconnected by simple connections that act as tunnels. Note that we do not have to set up ISSCs from an originating Sandman domain to all other Sandman domains on a path between a source and destination. Instead, we again use hop-by-hop interconnectivity, albeit of a somewhat coarser granularity. Each hop is now a Sandman domain. Setting up connections end-to-end is done by sending the appropriate control message along the ISSCs from one Sandman hop to the next.