![[Contents]](TOC.GIF){kind=small}
![[Prev. Chapter]](REW.GIF){kind=small}
![[Next Section]](NEXT.GIF){kind=small}
![[Next Chapter]](FF.GIF){kind=small}
![[Index]](INDEX.GIF){kind=small}
![[Help]](HELP.GIF){kind=small}
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/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 A 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.
![[Prev. Section]](PREV.GIF){kind=small}
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 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.
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.
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.
| 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).