Transmission of token-ring packets over ethernet by tunneling

Token Ring network packet having a header and an information field is prepared for transmission over an Ethernet network by the steps of removing the header information from the Token Ring packet, and associating a second header with the information field of the Token Ring packet, wherein the second header is compatible with the Ethernet network. More particularly, to prepare an IEEE 802.5 Token Ring network packet for transmission on an Ethernet network the Access Control ("AC") and Frame Control ("FC") fields are removed, the order of the destination address ("DA") field is reversed, the order of the source address ("SA") field is reversed, a Virtual Local Area Network ("VLAN") type field is added, a VLAN identification ("ID") field is added, and a length value field is added. The information field from the Token Ring packet is retained. However, if the newly formed tunneled packet would otherwise be smaller than the minimum size for an Ethernet packet the information field may be padded with null bits until the minimum size for an Ethernet packet is achieved.

BACKGROUND OF THE INVENTION 
The present invention is generally related to telecommunications, and in 
particular to data transmission across different types of computer 
networks. 
A need exists to efficiently transmit Token Ring packets on an Ethernet 
network. Token Ring is a well established protocol which enjoys wide 
usage. One drawback of Token Ring networks compliant with the IEEE 802.5 
standard is lack of bandwidth. In particular, Token Ring networks operate 
at 4 or 16 Mbps in comparison with more recent technologies such as Fast 
Ethernet, Fiber Distributed Data Interface ("FDDI") and Asynchronous 
Transfer Mode ("ATM") networks. One way to extend the useful life of 
existing Token Ring networks is to integrate such networks with other 
networks such as Fast Ethernet, FDDI and ATM in a manner which takes 
advantage of the increased bandwidth of those other networks. 
Technology for transmission of data across different types of computer 
networks is known. For example, U.S. Pat. No. 5,535,373, entitled 
PROTOCOL-TO-PROTOCOL TRANSLATOR FOR INTERFACING DISATE SERIAL NETWORK 
NODES TO A COMMON ALLEL SWITCHING NETWORK, issued to Olnowich describes 
translation of data units from a first network protocol to a second 
network protocol. Initially, the network operating system protocol of the 
sending network is identified. The data unit is then modified based upon 
known characteristics of the sending network operating system protocol 
such that the data unit is placed in a format that can be handled by 
equipment in the receiving network. However, such data unit translation 
requires intensive computations, and hence necessitates the use of 
relatively sophisticated and costly electronic hardware. Further, since 
some network operating system protocols are proprietary, the technique for 
making the translation may change each time the operating system protocol 
is changed, thereby necessitating development and distribution of updated 
translation tools. 
It is also known to encapsulate a first data unit of a first protocol 
inside a second data unit of a second protocol. To encapsulate a Token 
Ring packet in an Ethernet packet, the entire Token Ring packet including 
both header information and payload is stored in the information field of 
the Ethernet packet. Header information for the Ethernet packet, such as 
source and destination addresses, must then be determined for the Ethernet 
packet. However, encapsulation has the disadvantage of producing a 
relatively large packet because a minimum of 16 bytes are added. 
With regard to transmission of Token Ring packets on an Ethernet network, a 
commercially available product known as "VG-AnyLAN" supplied by the 
Hewlett-Packard Corporation is known to exist. However, VG-AnyLAN does not 
allow coexistence of Token Ring packets and Ethernet packets on the same 
network segment. 
BRIEF SUMMARY OF THE INVENTION 
In accordance with the present invention, a first network packet having a 
header and an information field is prepared for transmission over a second 
network by the steps of removing the header information from the first 
network packet, and associating a second header with the information field 
of the first packet, wherein the second header is compatible with the 
second network. To prepare an IEEE 802.5 Token Ring network packet for 
transmission on an Ethernet network the Access Control ("AC") and Frame 
Control ("FC") fields are removed, the order of the destination address 
("DA") field is reversed, the order of the source address ("SA") field is 
reversed, a Virtual Local Area Network ("VLAN") type field is added, a 
VLAN identification ("ID") field is optionally added, and a length value 
field is added. The information field from the Token Ring packet is 
retained. However, if the newly formed tunneled packet would otherwise be 
smaller than the minimum size for an Ethernet packet, i.e., 64 bytes, the 
information field may be padded with null bits until the minimum size for 
an Ethernet packet is achieved. The resulting tunneled packet has the 
desirable qualities of requiring less computation than complete 
translation and not increasing the packet size as in encapsulation. 
One advantage of the tunneled Token Ring packets is compatibility with 
native Ethernet packets. In particular, the fields of the tunneled Token 
Ring packet function similarly to corresponding fields in native Ethernet 
packets. Tunneled Token Ring packets can therefore coexist with native 
Ethernet packets on a network segment, and can be efficiently handled by 
Ethernet networking equipment. 
Another advantage of the tunneled Token Ring packets is retention of source 
routing ability. The Token Ring protocol supports source routing. However, 
the Ethernet protocol does not support source routing. Tunneled Token Ring 
packets retain the information necessary to implement source routing. 
Hence, when a native Token Ring packet is created from a tunneled Token 
Ring packet, the original source routing information may be employed.

DETAILED DESCRIPTION OF THE INVENTION 
FIG. 1 illustrates an exemplary architecture in which an Ethernet Local 
Area Network ("LAN") facilitates communication between Token Ring LANs 12, 
14. A 16 Mbps Token Ring LAN 12 including a Token Ring switch 16 is 
connected to a 100 Mbps Fast Ethernet LAN 10 including a server 17 and a 
switch 18 through an Ethernet link 20. The Ethernet switch is connected to 
a second 16 Mbps Token Ring LAN 14 by a second Ethernet link 22. In order 
for a client computer 24 connected to the Token Ring switch 16 to 
communicate with a server 26 connected to the second Token Ring switch 28, 
Token Ring packets generated by the client 24 must be prepared for 
transmission on the Ethernet LAN 10. The Token Ring packets are preferably 
prepared by placing the packets in a form which can coexist with native 
Ethernet packets. The modified packets are then transmitted over the 
Ethernet LAN and modified a second time to place the packets back in 
native Token Ring format for transmission on the second Token Ring LAN 14. 
FIG. 2 illustrates a native Token Ring packet 30 and a tunneled Token Ring 
packet 32 generated therefrom. The native Token Ring packet 30 includes an 
access control ("AC") field 34 (1 octet), a frame control ("FC") field 36 
(1 octet), a non-canonical destination address ("nDA") field 38 (2 or 6 
octets), a non-canonical source address ("nSA") field 40 (2 or 6 octets), 
an information field 42, and a frame-check sequence ("FCS") field 44 (4 
octets). The information field holds the data payload of the packet, and 
all other fields are referred to collectively as the packet "header." The 
FC field 36 includes at least three priority bits PPP 46 and the nSA field 
40 includes a routing information indicator RII 48. If the native Token 
Ring packet 30 is source routed, the RII 48 will be set and the packet 
will also include a route information field 50 ("RIF"). The RIF 50 
includes a Route Control ("RC") field 52 (2 bytes) and Route Descriptor 
("RD") fields 54 (2 bytes each). If the packet is not source routed, the 
RIF 50 is not present. 
The tunneled Token Ring packet 32, which can coexist with native Ethernet 
packets, includes a canonical DA field 56, a canonical SA field 58, a 
virtual local area network ("VLAN") type field 60 (2 bytes), a VLAN 
identification ("ID") field 62 (2 bytes), a length field 64, a route 
control field 66, a route descriptor field 68, an information field 70 and 
an FCS field 72. The VLAN type field 60 is employed as an indicator that 
the packet is a tunneled Token Ring packet. The VLAN ID field 62 includes 
the three priority bits PPP 46, a token ring bit T 74, a reserved bit R 76 
and eleven bits of VLAN ID 78. The length field 64 is employed to indicate 
the size of the native Token Ring packet. The route control field 66 
includes three broadcast indicator bits BBB 80, a direction bit D 82, 
three max frame size bits FFF 84 and four reserved bits rrrr 86. It should 
be noted that six max frame size bits could be employed and accommodated. 
In order to modify the native IEEE 802.5 Token Ring packet 30 to create the 
tunneled Token Ring packet 32, the 30 header is removed from the native 
Token Ring packet and a new header is associated with the information 
field of the native Token Ring packet, such that the new header is 
compatible with the Ethernet protocol. In particular, the AC field 34 and 
FC field 36 are removed, the bits of the DA field 38 within each byte are 
reversed in order, the bits of the SA field 40 within each byte are 
reversed in order, the VLAN type field 60 is added, the VLAN ID field 62 
is added, and the length field 64 is added. The information field 42 from 
the Token Ring packet is retained. 
Referring now to FIGS. 2 and 3, to create a tunneled Token Ring packet from 
a native Token Ring packet the AC field is initially removed in step 100. 
The FC field contains three priority bits which are temporarily stored for 
subsequent placement in the VLAN ID field in step 102. The remaining bits 
of the FC field are then removed in step 104. The position of the 
remaining DA bits are then reversed in step 108, one byte at a time, until 
the order of the DA field is reversed. The SA field contains a routing 
information indicator RII which is extracted in step 110 and employed to 
set bits BBB in the Route Control field. If the RII is set, then the RIF 
field is present. Contemporaneously with step 110, the position of the 
remaining SA bits are reversed in step 112, one byte at a time, until the 
order of the SA field is reversed. The VLAN type field is then added in 
step 114 by inserting a predetermined value such as 3C20 (hex). The 
predetermined value serves as an indicator to network devices that the 
packet is a tunneled Token Ring packet, and that the VLAN ID field should 
be examined. The VLAN ID field is then optionally added in step 116 by 
storing the three FC priority bits PPP as the first three bits, followed 
by the Token Ring indicating bit T and the reserved bit R, followed by 11 
bits of VLAN identification. Alternatively, the three priority bits may be 
stored in the route control field. In step 118 the length field is added 
to indicate the size of the native Token Ring packet, and hence which data 
in the Information field is valid. In particular, a value is entered in 
the length field indicating the size of the RIF field plus the Information 
field. The length value is salient because the Information field may be 
padded with null bits. Next, the native Token Ring packet is determined to 
be either source routed or non-source routed in step 120. 
If the native Token Ring packet is source routed, the RIF field is entered 
in the Route Control and Route Descriptor fields in step 122. The 
broadcast indicators BBB are set as follows: 00x indicates a specifically 
routed packet, 10x indicates an all routes explorer, and 11x indicates a 
spanning tree explorer/single route broadcast. If the Native Token Ring 
packet is not source routed, route control bytes are generated in step 130 
to indicate that the packet is not source routed. The broadcast indicators 
BBB are set as follows: 01x The native Token Ring information field is 
then used in step 124, unchanged, as the information field in the tunneled 
Token Ring packet. 
In step 132 the size of the resulting tunneled Token Ring packet is 
determined. If the resulting tunneled Token Ring packet is at least as 
large as the minimum Ethernet packet size, the process is complete and 
flow ends. If the resulting tunneled Token Ring packet is smaller than the 
minimum allowable Ethernet packet size, the information field is padded in 
step 134 with null bits such that the tunneled Token Ring packet becomes 
at least as large as the minimum Ethernet packet size. The padding routine 
operates as follows: 
______________________________________ 
If (source routed) 
If (TR length &lt; 60) 
padding = 60 - TR length 
Else 
padding = 0 
Else 
If (TR length &lt; 58) 
padding = 58 - TR length 
Else 
padding = 0 
______________________________________ 
If the length of a source routed Token Ring packet is less than 60 bytes, 
the length field is padded with (60--Token Ring length) null bytes. 
Otherwise, if the length of the source routed Token Ring packet is greater 
than or equal to 60 then the length field is not padded. If the length of 
a non-source routed Token Ring packet is less than 58 bytes, the length 
field is padded with (58--Token Ring length) null bytes. Otherwise, if the 
length of the non-source routed Token Ring packet is greater than or equal 
to 58 then the length field is not padded. Since a four byte cyclic 
redundancy check ("CRC") is included, the result is the minimum Ethernet 
packet size of 64 bytes. 
The native Token Ring FCS is then discarded in step 126, and a new FCS 
field is calculated for the tunneled Token Ring packet in step 128. 
The steps for generating a native Token Ring packet from the tunneled Token 
Ring packet are illustrated in FIG. 4. Initially, an AC field and an FC 
field are added to the packet in steps 140, 142, respectively. The order 
of the Destination Address field is reversed in step 146. The order of the 
Source Address field is reversed in step 148. The VLAN Type field is then 
removed in step 150. The priority bits in the VLAN ID field are then 
temporarily stored in step 152, and the remaining portion of the VLAN ID 
field are removed in step 154. The priority bits are then written into the 
FC field in step 156. The length field is then removed and temporarily 
stored in step 158, following which the RC field is examined in step 160. 
If the RC field indicates that the packet is not source routed, then the 
RC field is removed in step 162. If the RC field indicates that the packet 
is source routed, the RC field is employed in step 164 as the RC field of 
the RIF of the Token Ring packet. The RII bit is then set to logic 1 in 
step 166 and the RD is written to the RIF in step 168. The information 
field of the tunneled Token Ring packet is utilized as the information 
field of the native Token Ring packet in step 170. The length field is 
then examined in step 172 to determine if the information field was 
padded. If the information field was padded, the padding bits are removed. 
If the information field was not padded, the information field is left 
intact. Finally, a new FCS is calculated for the native Token Ring packet 
in step 174. 
Having described the preferred embodiments of the invention, other 
embodiments which incorporate the concepts of the invention will now 
become apparent to one of skill in the art. Therefore, the invention 
should not be viewed as limited to the disclosed embodiments but rather 
should viewed as limited only by the spirit and scope of the appended 
claims.