next up previous
Next: Sandman to Sandman Up: MCA interoperability Previous: Single domain connections

Simple interoperability between domains

We first discuss a simple solution for interoperability between domains which resembles the one proposed in [#!Rooney:98a!#], which is to associate gateway code with a pseudo-endpoint that corresponds to the link connecting the two MCAs. A pseudo-endpoint is a control gateway that translates signalling messages from one MCA into those of another MCA. In Sandman domains it takes the role of an endpoint, while to a neighbouring MCA-X domain, it may look like a native MCA-X switch controller.

Under normal operation, where both endpoints lie in the same domain, the Sandman MCA sets up a connection from one endpoint to another (or a number of others) and then notifies the endpoints that the connection is in place. Things are different if one (or more) of the endpoints lie outside the local domain. Without loss of generality, we take the example of a point-to-point connection connecting A, a local endpoint (i.e. within the Sandman's domain), with B, a remote endpoint (outside the domain), as illustrated for two interoperating Sandman domains in Figure [*]. When a request for such a connection arrives at the Sandman MCA, the pseudo-endpoint C of the appropriate outgoing link automatically takes on the role of the remote endpoint B. In other words, whenever a Sandman MCA tries to set up a connection to a remote endpoint, it really sets up a connection within its own domain, to the pseudo-endpoint corresponding to the outgoing link and then notifies the pseudo-endpoint that the connection is in place (and which vpi-vci values are associated with it).

Figure: Multiple MCA domains
Figure: Control gateway

Figure: Pseudo-endpoints as control gateways

Upon receiving the notification, the pseudo-endpoint translates the setup request to whatever signalling protocol is used in the neighbouring domain (this includes address translation if necessary). If the neighbouring domain is another Sandman domain, it simply repeats the connection request, this time assuming the role of endpoint A. If the neighbouring domain succeeds in setting up the rest of the connection, the pseudo-endpoint returns an acknowledgement to the first Sandman MCA. If not, the connection set up has failed and all actions taken so far in the first Sandman MCA are rolled back also (the resources are released and the client is notified).

Connections from MCA-X to the Sandman could be set up in the same way if such a control gateway is implemented in the MCA-X domain. Alternatively, it is possible to let the Sandman offer the same sort of interface to the MCA-X domain that would have been offered by another MCA-X domain. This is illustrated in Figure [*]. In this case, the MCA-X domain cannot tell that its is actually communicating with a different MCA. For example, many MCAs have well known channels for signalling. For example, ATMF UNI signalling uses a dedicated VC with VCI = 5 and VPI = 0. It is not difficult to direct this VC to the control gateway which then translates incoming signalling messages into Sandman requests.

Figure: Control gateway translates signalling messages

This solution covers all four cases of interoperability mentioned in section [*]. We call this the hop-by-hop solution for interoperability because each MCA only communicates with its immediate neighbour, translating each control message from its own domain directly into that of the neighbouring MCA.

What this means will be explained by looking at the various interoperability cases. We will call this approach a (simple) hop-by-hop solution (where each MCA domain constitutes a hop) because it simply translates the control messages of one MCA into the control messages of the next (neighbouring) MCA domain until it reaches the endpoint. In section [*] we will point out some of the problems of such an approach and in the next sections we will propose a new mechanism which does not exhit the same shortcomings.

Partial domain-level knowledge enables the Sandman to recognise an endpoint of communication as `external'. It internally translates every setup request to external endpoints into a similar operation which is aware of the location where the connection leaves the local domain (using the so-called `via' parameter). In other words, the request `connect (EP1, EP3, ...)' becomes: `connect (EP1, EP3,...) via L1'. We will see that for inter-domain connections the pseudo-endpoint takes on the role of via parameter.

next up previous
Next: Sandman to Sandman Up: MCA interoperability Previous: Single domain connections
Herbert Bos