As mentioned before, we do not intend the Sandman to replace any existing MCAs. Instead, we expect it to run alongside instantiations of Q.2931, IP switching, other instantiations of Sandman, etc. This makes interoperability an important issue. In this section we show how to achieve this. We stress that the issues are not specific to the Sandman MCA. Instead, they apply to interoperation between any two MCA domains. Consider Figure . In the figure, we see four different MCA domains, three of which are controlled by instantiations of the Sandman, while the one in the middle is controlled by some other MCA, e.g. P-NNI. We call this the MCA-X domain. The figure illustrates all four types of inter-domain interaction:
Note that it is sufficient to consider only the cases where communication originates in Sandman-1 and MCA-X. We assume that the Sandman MCA has only partial domain-level knowledge about the topology (or at least about that part of the total network that is of interest to it). By this we mean that Sandman-1 knows that endpoint 2 is connected to Sandman-2, but not what the exact topology within Sandman-2 is. Similarly, it knows that endpoint 6 is connected to the network controlled by Sandman-3 and that it can be reached through MCA-X.
The dashed line L3 between the Sandman-3 and the MCA-X domain indicates that there might be other domains between Sandman-3 and MCA-X of which Sandman-1 has no knowledge. When communication originates in MCA-X, we do not require the MCA to have even this knowledge. We will show that to MCA-X, Sandman-1 exhibits exactly the same behaviour as another instantiation of MCA-X, so that MCA-X can use its own proprietary signalling to set up connections to endpoints in Sandman-1.