Method for using logical link control (LLC) to route traffic within a router

A method for controlling communications between link stations locally attached to a router and served by the same single thread Logical Link Control (LLC) stack. LLC generates a table for identifying all of the locally attached link stations served by the LLC and upon request from a locally attached source link station to establish a session with another destination link station, the LLC examines the table to determine if the destination link station is locally attached and served by it. If the destination link station is locally attached and served by the same LLC, the LLC deletes all standard LLC protocols normally used to inform a partner LLC concerning the state of the communication.

FIELD OF THE INVENTION 
The invention relates to data communications and more particularly to 
communication between devices directly connected to a router or the like. 
BACKGROUND 
Communications between devices have been by and large specified by a number 
of standards organizations. These standards specify protocols which 
devices connected to a network must observe in order to communicate over 
the network. The standards also impose similar restraints on network 
components which interconnect the communication devices. 
One standard, IEEE 802.2, specifies the protocols executed by the LLC 
layer. These protocols must be observed by the devices or users of the 
network. In turn the network components must also observe these same 
protocols as far as they can impact the user. In general the IEEE 802.2 
standard (as well as others) assumes that a calling and a called station 
will be using separate LLC's (one associated with each user) 
interconnected by a transmission media. 
SUMMARY OF THE INVENTION 
The invention contemplates a method for controlling communications between 
link stations locally attached to a router or the like and served by the 
same single thread Logical Link Control (LLC) stack. A table is generated 
for identifying all of the locally attached link stations served by the 
single thread LLC and upon request from a locally attached source link 
station to establish a session with another destination link station the 
LLC examines the table to determine if the destination link station is 
locally attached and served by it. If the destination link station is 
locally attached and served by the same single thread LLC, the LLC omits 
selected LLC protocols normally used to inform a partner LLC concerning 
the state of the communication.

DETAILED DESCRIPTION OF THE INVENTION 
In FIG. 1 a plurality of user stations 10 are interconnected in a token 
ring network such as that specified in the IEEE 802.5 standard. Each user 
station has appropriate physical media and medium access control as 
specified in the standard. In addition each user station is provided with 
LLC code for executing the communication protocols specified in the IEEE 
802.2 standard. The user station have been designed to operate with the 
LLC interface specified in the standard. Deviations, if any, must be 
transparent to the user stations under all contemplated operating 
conditions. Any exceptions would be unacceptable. 
In FIG. 2 a router 20 has n ports (1-n) which are connected by network 
links to remote stations or other network components. In addition three 
user station 10 are locally connected to the router 20 and according to 
the invention share a common LLC which employs a novel protocol when the 
locally attached user stations communicate with each other using the 
common LLC. The novel protocol is transparent to the user stations and 
results in a substantial reduction of processing time thus expanding the 
overall capacity of the router 20 at no additional cost. In the 
descriptions which follow, it will be assumed that the locally connected 
stations 10 include all communication layers above the LLC layer described 
in this application. 
At initialization and/or as user stations are locally attached a table, 
including the addresses, of the locally attached stations is generated. 
How this table is used will be described below. The description below will 
be concerned with communications between locally attached user stations 
only since communications between locally attached user stations and 
remote user stations served by a different LLC will proceed using a 
protocol defined in the standard followed. 
In the description which follows, a locally attached user station which 
initiates a call to another locally attached user station will be referred 
to as the local link station and the called station will be referred to as 
the remote link station. 
The locally attached user stations 10 at any given time can reside in one 
of eight states. These include: 
01) LINK--CLOSED 
02) DISCONNECTED 
03) LINK--OPENING 
04) LINK--OPENED 
05) LOCAL--BUSY 
06) RESETTING 
07) REMOTE--BUSY 
08) LOCAL+REMOTE--BUSY. 
In state 01 the link station is inactive and the user must send an 
ACTIVATE--LS to enter state 02. 
In state 02 the link station is recognized by the LLC and can send and 
receive a limited number of commands which allows the station to go to 
state 03 or return to state 01. 
In state 03 the link stations exchange signals to establish a connection 
and if successful exit to state 04. 
In state 04 locally connected link stations communicate information. 
State 05 is entered when the local link station is busy and can no longer 
receive information frames. 
State 06 is entered when the remote link station wants to reset the line. 
State 07 is entered when the remote link station is busy. 
State 08 is entered when both the local and the remote link stations are 
busy. 
The finite state machine tables illustrated in FIGS. 3-10 define in detail 
all of the protocol steps under all possible operating conditions. 
Listed below are terms, abbreviations and definitions of terms used in the 
finite state machine tables illustrated in FIGS. 3-10. 
Inputs: 
ACTIVATE--LS (activate link station) 
this input from a user initiates activation of the link station 
DEACTIVATE--LS (deactivate link station) 
SET--ABME (set asynchronous balanced mode extended) 
TEST--LINK (test link connection) 
SEND--XID (exchange link station identification) 
SET--ADM (set asynchronous disconnect mode) 
ENTER--LCL--BUSY (enter local station busy condition) 
EXIT--LCL--BUSY (leave local station busy condition) 
SEND--BTU (send basic transmission unit) 
CONN--RSP (connection response). 
Variables: 
Vi (initialization state) 
Xs (exchange identification information status) 
Ts (link test status) 
Vb (busy state status) 
Predicate Conditions: 
For the variable Vi: 
Lip (local initialization pending) 
Rip (remote initialization pending) 
LRip (local and remote initialization pending) 
Op (operational mode pending) 
ISp (I/S format frame pending) 
For the variable Xs: 
IXp (incoming XID response pending) 
OXp (outgoing XID response pending) 
IOXp (incoming and outgoing XID response pending) 
For the variable Ts: 
ITp (incoming test response pending) 
OTp (outgoing test response pending) 
IOTp (incoming and outgoing test response pending) 
For the variable Vb: 
Lb (local busy) 
Rb (remote busy) 
LRb (local and remote busy) 
Other abbreviations used in the finite state machine tables: 
IH (inform higher authority) 
Pf (value of P bit in last received command, except XID or TEST commands 
Pt (value of P bit in last TEST command received) 
Px (value of P bit in last XID command received) 
Vc stacked command status. 
Inactive locally attached link stations are in state 01. If an inactive 
link station wants to establish a session with another locally attached 
link station it sends an ACTIVATE--LS input to the LLC. Also included with 
the input are the address (SA) of the link station, the address (DA) of 
the locally connected link station it wishes to establish a session with 
and the Service Access Point identities of the source (SSAP) and 
destination (DSAP) link stations. 
The addresses and the SAP's identify the link stations. With this 
information and the contents of the table described above the LLC can 
establish when both the "local" and "remote" link stations are in fact 
locally attached and served by the same LLC. In this instance, the 
protocol executed by the LLC will be in accordance with the invention and 
follow the sequences specified in the finite state machine tables. 
Each state has two tables one for internal events associated with the local 
link station and the other for received events associated with the remote 
link station. The tables have four columns. The first lists inputs, the 
second lists action taken as a result tables have four columns. The first 
lists inputs, the second lists action taken as a result of the input, the 
third lists notifications sent to the partner link station and the fourth 
lists the new state the link station goes to based on the input and 
predicates associated with the variables. 
For example, when the LLC receives the ACTIVATE--LS from a link station the 
station moves to state 02 where it is permitted to transmit and receive a 
limited number of items. Among these are the TEST and XID frames. These 
are preceded by the TEST--LINK and SEND--XID inputs to LLC. After the 
stations successfully complete this process (this process is the same as 
specified in the standard) one of the link stations will send LLC a 
SET--ABME input. 
It is at this point that the LLC deviates from the protocol specified in 
the standard. After receipt of SET--ABME, the LLC will send the partner 
link station either a Connect Indication or a Connect Response depending 
on the predicate of Vi. The predicate Rip indicates that a response to 
initialization is pending and the appropriate notification is Connect 
Response. If Vi is 0 then the Connect Indication is returned to the 
partner. At this time the link station providing the SET--ABME input moves 
to state 03. The return of Connect Indication causes Vi for the other 
station to go to Rip and receipt of SET--ABME from that station will cause 
a Connect Response to be sent to the first link station and both stations 
are now in state 03 LINK--OPENING (see tables 3 and 4). 
The link station leave LINK--OPENING state (03) and go to LINK--OPENED 
state (04) when each issues a CONN--RSP to the LLC. In this state the link 
stations can exchange information. In addition to the above the protocol 
differs from the standard in several significant areas. 
As the LLC receives blocks of information from one station for delivery to 
the other, they are passed directly to the destination station. Under 
conventional protocols these blocks would be encapsulated in a 
transmission frame by the source LLC before transmission to the 
destination LLC which includes a substantial amount of processing by the 
LLC's serving each end of the session. Since a single thread LLC serves 
both the source and destination link stations and the block of data does 
not leave the router the frame structure including block checks for error 
detection can be eliminated resulting in a substantial saving in 
processing at the router level. 
Another significant improvement occurs in the execution of flow control. If 
a link station can not accept additional data, it issues a 
ENTER--LCL--Busy to LLC which places the link station in the LOCAL--BUSY 
state 05. LLC sends a Flow off indication to the partner and this causes 
the partner to enter the REMOTE--BUSY state 07 (see tables 7 and 8 of the 
LINK--OPENED state 04. The LOCAL+REMOTE--BUSY state 08 is entered when 
both link stations cannot accept data. 
The RESETTING state 06 is entered when a Connect Indication is received in 
states 04, 05, 07 and 08. This takes place when a link station needs to 
restart the link.