The control plane functions are implemented by a set of co-operating services within each MD. Layer boundaries are preserved within each service, and access to the control plane is gained via control interfaces exported by each service. We describe each function in terms of the interface which it exports.
The MSNL protocol suite is supported by many operating platforms, each of which provides users with a different abstraction of (and interface to) the comunication facilities offered by MSNL. Any such system is by definition an entity in a MD. We define the the User Network Interface (UNI) to be the interface between a user wishing to use MSNL, and the MSNL control plane. Each operating platform must translate calls across its specific communication interface (the Platform Specific Interface, PSI) into calls across the UNI, on behalf of each of its MSNL users. The UNI defines the signalling protocol with which the user controls all aspects of the communication. This includes the allocation of MSNL SAPs and the set up and tear down of MSNL connections. On the user side of the UNI a state machine represents the user's view of the current state of a connection. On the network side (within the control plane) a similar state machine is used to control the connection. These control functions are implemented by a service known as the MSNL Master, and it is to this service that UNI signals are directed.
The MSNL Master maintains the state for every call within the MD. The UNI signalling protocol specifies the valid state transitions which can occur in response to user requests and network events. The UNI presents the user with an MSNL SAP, which is an 8 octet address which uniquely identifies the user service access point in the MSNL internetwork. A pair of SAPs uniquely identifies a connection, and is called a liaison. The user platform is responsible for some adiministrative tasks, such as ensuring that independent users (eg. programs) do not bind to the same MSNL SAP.
Consider the steps involved in connection set up between a user and a remote MSNL SAP. First the user must request a SAP for its end of the connection. It does so by signalling a request across the PSI. The platform supporting the user then signals the request across the UNI. The MSNL Master responds by returning a SAP bound to a call reference unique to the user and entity, which identifies the user access point to MSNL in the PSI. In Unix this call reference could be a socket identifier. Having been allocated a SAP the user can signal a request across the UNI (via the PSI) for a connection to the remote SAP. In response the MSNL Master takes steps to establish a communication path between the two SAPs. This may involve signalling between MDs distributed over the MSNL internetwork. It will also involve actions in the control plane to build each layer of the data path for the connection within the entity supporting the user. Each entity which supports UNI signalling, therefore, must export a control interface which the MSNL Master can use to direct the construction and destruction of MSNL data paths within the entity. This interface is called the MSNL Slave interface. When the path has been established the MSNL Master informs the user via the UNI that its request has been carried out and that the data path is available.
Note that the definition of an MD does not require the MSNL Master or any of its associated services to reside physically on an entity or entities within the MD. It would be perfectly feasible to locate many MSNL Masters for different MDs on different subnetworks on a single host, possibly within a single process, if required.
Before an entity can signal across the UNI to request communication facilities, it requires an MSNL connection (a signalling connection) on which to transmit the UNI signals. In order to obtain a signalling connection it transmits a request on a metasignalling circuit using the metasignalling protocol. The metasignalling circuit is a permanent virtual circuit (PVC) established by an entity for each of its network interfaces when it boots. The virtual circuit identifier for the metasignalling connection is defined per MSDL instance, and has a well known value. The metasignalling protocol is a primitive protocol for which each message is contained within one MSDL PDU. The format of the metasignalling messages differs per MSDL class.
The metasignalling protocol permits an entity to request a connection to a control plane function (the MSNL Master) to which it can direct UNI signals. For dumb entities which are incapable of signalling using the UNI and which do not export an MSNL Slave interface, the metasignalling protocol can be used as a full blown signalling protocol. In this case all signalling from and to the entity is achieved on the metasignalling virtual circuit. Each such entity is regarded as an independent MD. The metasignalling protocol is specified in [2], and is currently used in MSNL as an out of band signalling protocol. Incoming metasignalling requests are associated with the pod on which they were generated. Metasignalling requests are forwarded to a service known as the Metasignalling Service, which is implemented per MD, possibly in a distributed fashion. Metasignalling requests are translated from their MSDL dependent form into a standard format and forwarded to the MSNL Master.
Having obtained a signalling channel using the metasignalling protocol, an entity can signal its requests across the UNI. The signalling channel connects an entity to the MSNL connection control function for the MD, which is located in the MSNL Master. The MSNL Master is responsible for co-ordinating the management of communication resources within the MD. When a user signals a connection request across the UNI the MSNL Master must check whether sufficient resources are available within the entity, the MD and the destination entity to support the request. If not then the connection request will be refused. When a connection can be established, the MSNL Master controls the construction of the data paths within the entities involved in the connection, using the MSNL Slave interface. The UNI signalling protocol also permits resource management at the user level. The MSNL Master ultimately defers to the user in deciding whether or not to accept a connection.
The MSNL Master is also responsible for inter-MD signalling. When a user requests a connection to an MSNL SAP which is located on a remote MD, the MSNL Master of the user's MD must take steps to locate the remote SAP (routeing) and must engage in inter-MD signalling with the MSNL Master of the remote MD. If the remote MD is attached to a different network, or even several networks distant from the user's MD, then inter-MD signalling must take place for every ``hop'' which the connection will traverse. To accomplish inter-MD signalling, an MSNL Master uses a an inter-MD signalling circuit which connects it to the MD to which it wishes to signal. This circuit is obtained using the metasignalling protocol. The protocol used for inter-MD signalling is the Network-Network protocol, and it is specified in the Network-Network Interface (NNI). The definition of the NNI is independent of the definition of the UNI, however the NNI is expected to support the basic primitives required by the UNI. Dissociation of the NNI from the UNI permits each protocol to be independently implemented and modified.
The MSNL Master uses information from a number of control and managment functions, including:
The MSNL Master is responsible for the creation of an MSNL liaison between two SAPs. It must therefore instruct each entity to build the elements of the data path linking the network to the user SAPs. There are three types of liaisons: local, remote and forwarding liaisons. Local liaisons are those between two users on the same entity (platform). In this case the platform will in general provide an efficient and optimised mechanism for user-user communication. Remote liaisons are those which link a user (and its entity) to a different entity. The remote entity may be within or external to the MD. If it is within the MD then the MSNL Master for the MD is responsible for the setup of the entire data path and completion of the liaison. It is free to optimise this process. If the remote user is located on an entity external to the MD, then inter-MD signalling will be used to set up the elements of the data path which traverse other MDs and the destination MD. When A MD is traversed by a liaison which is not terminated in one of its entities then (for that MD) the liaison is a forwarding liaison. Such liaisons are implemented by simply building a data path which ensures that data transmitted over the liaison will be forwarded transparently through the entities in the MD. Such liaisons can frequently be very highly optimised.
To build the data path for a liaison of any type the MSNL Master exercises operations in the control plane of each layer of the MSNL protocol stack for the entity concerned. It does this via the MSNL Slave interface, which presents the MSNL Master with a mechanism for exerting control in the MSNL, MSDL and MS-Access layers within the entity. Every entity is required to support the MSNL Slave interface. Typical control actions include the creation and destruction of associations, assignment of associations to instances of MS-Access, and creation and destruction of liaison records. Figure 3 depicts a single entity and the control and data paths involved in constructing a data path. User and MSNL Master signal via the UNI, whilst the entity exports the MSNL Slave control interface to permit the MSNL Master to construct the data path within the entity. Examples of operations which are invoked across each interface are given. The MSNL Master makes use of other services, such as a router, to route requests. The diagram does not show all of the services and interfaces required to perform MSNL control and management, but illustrates the general principles.
Figure 3: MSNL Master and Slave
When a MD wishes to set up a connection to an MSNL SAP in a remote MD on behalf of a user supported by one of its entities, it needs to signal this to the remote MD. Each MD therefore supports the Network-Network signalling interface (NNI) which supports the required operations. The NNI is similar to, but far simpler than the UNI. The NNI is regarded as the MSNL network signalling protocol, and it replaces the current mechanism of signalling on the metasignalling channel between MDs.
In order to route requests between MDs, a routeing function will be implemented. Each MSNL Master will have an interface to a routeing function which is capable of determining the MD within whose control an MSNL SAP lies. In addition the MSNL SAP will be used to determine the route for the data path linking two SAPs within a MD. The interface to the routeing function will be defined in such a way that arbitrarily sophisticated routeing algorithms may be implemented without requiring the interface to change.