5 Signaling Module Interface

The Digital UNIX ATM subsystem signaling module interface enables signaling protocol modules to communicate with the ATM subsystem for connection management only. The primary signaling module provided with the base system is the UNI 3.0-compliant signaling module. However, you can add new signaling modules if the modules do not conflict with each other (such as in the use of well-known virtual circuits (VCs)). Once configured, any convergence module can use a signaling module on a per-call basis.

Note
New signaling modules should make no assumptions about which convergence modules use them, though the convergence modules may need to know about specific signaling modules.

The signaling module interface does not provide functions that allow the signaling module to exchange data with an ATM switch. To exchange data, signaling modules must also register as convergence modules for purposes of creating signaling VCs, usually permanent virtual circuits (PVCs), and of exchanging signaling data with the network.

The ATM signaling module interface enables signaling modules to:

This chapter describes each task, the function calls involved, and the relevant data structures that signaling module writers can use. Appendix A contains a reference page for each signaling module interface routine.

5.1 Registering the Signaling Module

When a signaling module is initialized, the module must use the atm_cmm_register_sig function call to register with the Connection Management Module (CMM). Once registered, the CMM can use the signaling module and make it available to convergence modules.

Signaling modules should register as both signaling and convergence modules. When registering as a convergence module, a signaling module must set up its signaling VCs to send and receive signaling messages. The CMM does not provide special facilities for signaling VCs, but treats them like any other VC. See Section 7.6 for a description of signaling VC initialization.

5.2 Receiving a New Call

When a signaling module receives a new call, it uses the atm_cmm_new_call function call to notify the CMM of the new call. The CMM determines whether the call should be accepted. This CMM function call is nonblocking and returns with an indication about the disposition of the call.

5.3 Reporting a VC Activation

When a signaling module receives notification from the switch that a new connection has been completed and a new VC activated or ready to carry data, the signaling protocol module uses the atm_cmm_reply function call to notify the CMM. The CMM passes the notification to the device driver and protocol convergence module.

This call notifies the CMM of both the activation of point-to-point connections and of the addition of endpoints in point-to-multipoint connections.

5.4 Activating a Connection

When a signaling module receives the necessary indication from the network that the circuit is connected, the signaling module uses the atm_cmm_activate_con function call to inform the CMM that the connection is ready to carry data. The CMM enables the VC locally.

Note
Do not make this call before circuit connection.

5.5 Reporting a Connection Failure

When the CMM makes a connection request to a signaling module, the call to the remote system might fail for some reason. Since call creation is an asynchronous operation, the signaling module might encounter errors during call processing after the xxx_setup call has returned. In these cases, the signaling module uses the atm_cmm_con_failed function call to notify the CMM of the call failure and the reason for the failure.

5.6 Releasing a Connection

When a signaling module receives a request to tear down a connection from the network or endpoint, the module uses the atm_cmm_con_release function call to notify the CMM that the connection will be released. The CMM makes the connection unavailable for transmission, initiates the teardown of the referenced connection and all associated endpoints, and awaits notification that the VC has been torn down.

5.7 Dropping an Endpoint

When a signaling module receives a request to drop an endpoint from a connection, the module uses the atm_cmm_ep_dropped function call to notify the CMM that the endpoint must be dropped. The CMM then notifies the convergence module that owns the endpoint's VC that the endpoint has been dropped and deletes the endpoint. If the last endpoint associated with a VC is dropped, the CMM initiates the release of the VC.

5.8 Deleting a Connection

When a signaling module receives confirmation of a connection's release from the switch, the module uses the atm_cmm_con_deleted function call to notify the CMM that the connection no longer exists. The CMM holds the resources associated with the connection for a brief period of time, then releases them, giving all incoming queues time to clear. The CMM also notifies convergence modules that the connection has been released.

5.9 Restarting a Virtual Circuit

When a signaling module receives a RESTART request, the module uses the atm_cmm_restart function call to pass all the appropriate information to the CMM. The CMM then initiates a restart of the indicated VC(s) before returning to the signaling module.

5.10 Reporting a Completed Restart

After the CMM requests a restart, the signaling module uses the atm_cmm_restart_ack function call to notify the CMM when the restart has completed. Once notified, the CMM returns the indicated VCs to the NULL state and frees their resources.

5.11 Reporting a Completed Status Enquiry

After the CMM requests a status enquiry of a VC, the signaling module uses the atm_cmm_status_done function call to notify the CMM when the enquiry is complete. Once notified, the CMM either examines the enquiry data itself or passes it to the convergence module that requested the enquiry.

5.12 Requesting Endpoint Information

Since signaling modules can receive messages for existing VCs at any time, the modules use the atm_cmm_findaddr function call to request endpoint and VC information from the CMM. The CMM maintains all state information about each VC and calls (endpoints) associated with the VC.

Signaling modules can call this routine at any time to resolve a reference to a connection endpoint. Once the reference is resolved, the signaling module can access and modify structures as necessary as long as locking conventions are followed.

5.13 Adding a PPA

Signaling protocols usually perform some protocol registration-specific registration with the switch, including registering local addresses. When a signaling module creates a new address (creating a new PPA), the module uses the atm_cmm_new_ppa function call to inform the CMM that this new PPA exists. A convergence module can use the PPA to make and receive calls.

For example, when a UNI 3.0 signaling module is informed of a new address prefix, through the Interim Local Management Interface (ILMI), that has been created on the switch, the module combines the new prefix with existing end system identifiers (ESIs) to form a new set of addresses for the new prefix. Then, the signaling module tells the CMM about each of these new addresses.

5.14 Deleting a PPA

When a signaling protocol, in cooperation with a switch, deletes an address from the list of recognized addresses on an interface, it uses the atm_cmm_del_ppa function call to inform the CMM that the deleted PPA associated with the address is no longer valid. The CMM then informs convergence modules bound to the PPA that the address is no longer valid and initiates a teardown of all VCs associated with the address.

All PPAs, except for the PVC PPAs, are owned by a signaling module. That is, a signaling module is always responsible for the creation and deletion of a PPA. This is required since the registration of addresses with a switch is handled entirely by signaling protocols. Also, PPAs can be deleted because of actions on the network that are completely unrelated to the local system. Because of this, the CMM does not automatically delete PPAs when an interface is taken down or loses its connection to the switch. The CMM responds to an interface shutdown by deleting the PVC PPA. Signaling modules will delete PPAs when it is appropriate for their protocols to do so (such as when they lose communications with the switch).

See Section 3.6.1 for more information on PVC PPAs.

5.15 Reporting Completed MIB Access

Sometimes a signaling module's Management Information Base (MIB) access function call can block because of the need to contact some other network management entity. When the signaling module returns from the MIB access call, it uses the atm_cmm_mib_response function call to notify the CMM of the completion of a MIB access and report any retrieved values.

5.16 Requesting VC Status

When a signaling module needs to access status information about a VC that is currently in service, based on the virtual path identifier (VPI) and virtual channel identifier (VCI), it calls the atm_cmm_vc_get function call. The call returns a reference to a VC.

5.17 Using the atm_oid Structure

The ATM signaling module interface uses the atm_oid structure exclusively to communicate MIB objects and object instances between signaling modules and the CMM. Table 5-1 lists those members of the atm_oid structure, with their associated data types, that signaling modules might reference.

Table 5-1: The atm_oid Structure Members

Member Name	Data Type
`len`	`int`
`id[1]`	`int`

The len member specifies the length of the id member. The id member specifies the Object ID (OID).