Bindings for Network Components

For the networking software in a computer to operate properly, several different pieces of software must be loaded, and their relationships with other components must be established. These relationships are often called bindings. To determine the complete set of optimal bindings among an ensemble of configured network components, the system checks the following information in the Registry:

• The set of network components to be configured

• The types of network components in this set

• The constraining parameters for the network components and their bindings

• The possible bindings that could occur

• The proper way to inform each network component about its bindings

During system startup, the CurrentControlSet\Services subkey is checked for binding information for each service. If any is found, a Linkage subkey is created, and values are stored. For example, these two strings might appear in a value entry under the CurrentControlSet\Services\LanmanWorkstation\Linkage subkey:

Bind = \Device\Nbf_Elnkii01  \Device\Nbf_Elnkii02

This entry describes the binding information used by the Windows NT Redirector when two separate network cards are present. Each network card's symbolic name is suffixed with a network card index number. This name is joined to the name of the transport through which the network card is accessed. The names are generated by the system according to the constraints defined by the network component's rules.

Bindings have a usability requirement that means the binding must terminate either at an adapter (that is, a physical device) or at a logical endpoint, which is simply a software component that manages all further interconnection information internally. This requirement avoids loading software components that can never be of actual use. For example, a user might have a running network and then choose to remove the adapter card. Without the usability restriction, the bindings still connect components and prepare them for loading even though the network is entirely unusable.

The following example uses Nbf.sys and Srv.sys in an ensemble with two Etherlink II network cards and an IBM Token Ring card. First, in the values in the CurrentControlSet\Services\Nbf\Linkage subkey are the following:

Bind=    "\Device\ElnkII1"
        "\Device\ElnkII2"
        "\Device\IbmTok1"
Export=    "\Device\Nbf\ElnkII1"
        "\Device\Nbf\ElnkII2"
        "\Device\Nbf\IbmTok1"
Route=    "ElnkIISys ElnkII1"
        "ElnkIISys ElnkII2"
        "IbmtokSys IbmTok1"

Under the CurrentControlSet\Services\Srv\Linkage subkey, the following might appear:

Bind=    "\Device\Nbf\ElnkII1"
         "\Device\Nbf\ElnkII2"
         "\Device\Nbf\IbmTok1"
Export=   "\Device\Srv\Nbf\ElnkII1"
         "\Device\Srv\Nbf\ElnkII2"
         "\Device\Srv\Nbf\IbmTok1"
Route=   "Nbf ElnkIISys ElnkII1"
         "Nbf ElnkIISys ElnkII2"
         "Nbf IbmtokSys IbmTok1"

The names in the Bind and Export entries are based upon the object names defined in the component's NetRules subkey; these value entries can therefore be different from the actual names of the services, although in the previous example, for the sake of clarity, they are not. The names in the Route entry are the names of the Services subkeys comprising the full downward route through the bindings protocol.

When the system finishes computing the bindings for network components and the results are stored in the Registry, some network components might need to be informed of changes that occurred. For example, TCP/IP must prompt the user for an IP address for any network adapter that has been newly configured. If the NetRules subkey for a network component has a value entry named Review set to a nonzero value, the .inf file for the network component will be checked every time the bindings are changed.