Verilink 9000 Series (34-00271) Product Manual - Manual (Page 25)

Principles and Concepts 3
Establishing a
Connection
As stated earlier, each device establishes a logical connection with a destination
within the network. This is done with the help of the operating system (OS). Each
time a device signals that a connection is desired, the task sends a connect request
to the OS. This request contains the device’s address as well as the name of the
location to connect. The OS then locates that destination and forwards the request
to that port’s task. If the receiving port can accept the connection, a connect
confirmation is returned to the OS and forwarded to the requesting task. A logical
pathway is now established along which data can flow. This pathway establishment
only happens once and remains intact until either endpoint breaks the connection
or the unit is reset.
A device can signal the platform for a connection in one of two ways: The first
and more common method is for the configuration of the unit to specify a default
destination for the device. Once the terminal port polls the device and receives a
response, a logical connection is automatically established on behalf of the device.
Automatic connections may also be established from a host port if desired. The
second method is for the device to send a command with the name of the desired
destination to the unit. Any existing pathway for the device is torn down and a new
one established. A device may only have one connection at a time.
Figure 1-1 shows a device on a terminal port connecting to a host port on different
units. Many times the final destination is not on the same card as the device, but is
located at another location. If the protocol used on the leased circuit is a transport
protocol, (X.25, Frame Relay, etc.) then additional steps must be taken to establish
the complete logical connection for the device. All of the MultiPro unit’s transport
protocols utilize Layer 3 of X.25 for the network layer of the OSI model. This
means that any connection request to be carried across a transport link uses
standard call request, call clear, and call accept packets. When a transport task
receives a connection request from the OS, it generates a call request packet on the
link. The address of the requesting station and its destination are placed in the user
data field of the packet since this remains unchanged by any public network. A
transport task receiving a call request in turn generates its own connect request to
the OS. Once this connection is confirmed by the final destination, the transport
task sends a call accept packet to the initiating unit. When the call accept packet is
finally received by the original unit, the unit generates a connect confirmation to
the OS that informs the task which originally requested the connection. Figure 1-2
shows this process. Keep in mind that the requests flow all the way to the right
before confirmations begin flowing back to the left.