The Tru64 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/3.1-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:
Register the signaling module
Receive, reply to, activate, release, and delete connections
Restart a VC
Drop endpoints
Add and delete physical points of attachment (PPA)
Report a connection failure, a completed restart, a completed status enquiry, and Management Information Base (MIB) access
Request VC and endpoint status
This chapter describes each task, the function calls involved, and the relevant data structures that signaling module writers can use. Appendix B contains a reference page for each signaling module interface routine.
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.
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.
When
a signaling module receives notification from the switch that a new connection
has been completed and a new VC activated, 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.
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.
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.
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.
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.
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.
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.
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.
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 has completed.
Once notified, the CMM either examines the enquiry
data itself or passes it to the convergence module that requested the enquiry.
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.
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/3.1 signaling module is informed of a new address prefix, through the Integrated 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.
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.
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.
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.