Introduction
Under the DCI, network device drivers must announce their presence through Service_DCIDriverStatus. It is assumed that devices announcing themselves in this way are available for use. The device may become unavailable, most likely due to link loss (such as a cable being disconnected) or memory shortage. No indication is available to the user as to the state of the device from the driver.
In order to allow notifications of such states to be provided to the user (and to other clients who may need to be aware of network infrastructure changes), it is proposed that the service call be extended. Authors should consult the DCI driver specification or the Internet chapter within PRM 5a for more details of the current interface. In summary, Service_DCIDriverStatus is issued by drivers to announce startup (reason 0) and shutdown (reason 1) of a driver and its associated DIB (Device Information Block).
This has been extended to include announcement of link status changes (Service_DCIDriverStatus 2). Two new reason codes are to be used for this purpose.
Service calls
| R0 | = | Pointer to Device Information Block |
| R1 | = | &9D (reason code) |
| R2 | = | 2 (sub-reason code) |
| R3 | = | DCI version supported |
| R0 - R3 | preserved | |
This service is issued to announce changes to a Device Driver. An 'active link' indicates that the device driver is capable of sending and receiving data. An 'inactive link' will never send or receive data. This mirrors the use of the DCI statistics flag. For compatibility with devices which are not aware of these new reason codes, all modules should assume that a newly started device driver has an active link. It follows that any device which starts up and is aware of these new reason codes must issue the 'link inactive' (reason code 3) service if its link is not available.
Expected uses for this service:
- Dynamic address configuration in presence of new network infrastructure (eg ZeroConf address re-announcement, DHCP lease renewal)
- User notification of network absence (eg Notifier protocol)
Non-module clients, and module clients wishing to obtain more information about the state of the link should query the statistics for the DCI driver in the usual manner.
Drivers may, but are not required to, defer announcement of inactive links if their physical state is such that transient failures (in the order of seconds) may occur. Drivers which can detect the physical nature of the network to which they are connected must signal a link state change when they detect such a change (eg configuration changes to a wireless network SSID, encryption key, channel, etc).
Clients should expect that any 'link inactive' notification may indicate that the previous network connection is invalid. On 'link active' notification, clients may attempt to re-establish connections to remote systems.
Clients should attempt to use the existing connections before restarting a lengthy negotiation or configuration process. Where confidential information is involved, clients should not attempt to re-establish any connection without first confirming the action with the user.