The hop-by-hop solution provides very basic interoperability between multiple MCA domains. The solution is attractive because of its simplicity but for the same reason limited in its usefulness.
The main problem is that the signalling gateways reduce all possible interconnection to the lowest common denominator in terms of MCA functionality. Consider, for example, the case of two Sandman domains, connected by one or more P-NNI domains, such as between Sandman-1 and Sandman-3 in Figure . Although both Sandman MCAs support the use of future reservations, it is impossible to make use of this functionality in an inter-domain connection. This is because at the control gateway between Sandman-1 and MCA-X (P-NNI), the future reservation request is translated into the type of request that P-NNI understands, e.g. immediate setup. After that it will never be `promoted' to future reservation again. Instead, at the boundary between MCA-X and Sandman-3, the immediate setup request is translated into a Sandman immediate setup request. In other words, all functionality is reduced to the simplest common service on the path between Sandman-1 and Sandman-3. We call this the problem of functionality degradation.
An additional problem is that the nature of the interoperation between two domains is fixed. This makes it hard to exploit application-specific knowledge. Again taking the example of future reservations, consider the case where endpoint 1 in Sandman-1 wants to reserve in advance for a connection from itself to endpoint 4 in MCA-X. The Sandman domain first makes all local future reservations for an interval [Tstart, Tend] and then injects the request into the MCA-X domain via the control gateway.
The control gateway has to translate the request into control operations that MCA-X understands. One option would be to simply allocate the resources (i.e. setup the connection) in the MCA-X domain immediately and keep it in place, so that at least the future reservation is guaranteed. This is the right solution if the guarantees regarding the availability of resources in [Tstart, Tend] are important and the resources in MCA-X are scarce. Alternatively, it may decide not to allocate any resources in MCA-X at all and simply try to set up the connection when it is needed at Tstart. This may be the right solution if there is little risk of some other application using the required resources in the meantime. The point is that the gateway has to choose how the request is translated, while the chosen solution may be optimal in certain situations but not in others. It would be preferable if the application itself was able to specify the nature of the interoperation between two domains, allowing it to exploit application-specific knowledge that is impossible to support otherwise. We call this the problem of fixed interaction.