U.S. patent number 5,699,350 [Application Number 08/540,227] was granted by the patent office on 1997-12-16 for reconfiguration of protocol stacks and/or frame type assignments in a network interface device.
This patent grant is currently assigned to Canon Kabushiki Kaisha. Invention is credited to Andrew J. Kraslavsky.
United States Patent |
5,699,350 |
Kraslavsky |
December 16, 1997 |
Reconfiguration of protocol stacks and/or frame type assignments in
a network interface device
Abstract
A network interface device which can communicate with other
devices via a local area network (LAN) using various protocols and
frame types, and which can be remotely reconfigured to use
different protocols and frame types. The network interface device
includes a LAN interface that receives packets including address
and data information from the LAN and transmits packets to the LAN.
The network interface device also includes a processor that (i)
executes an initialization routine to load protocol stack modules
and to assign a frame type for each of the loaded protocol stack
modules based on configuration information regarding the protocols
and frame types used on the LAN, (ii) determines whether a packet
received from the LAN is a configuration packet by detecting
whether the received packet is addressed to a predetermined
address, and (iii) alters the configuration information using the
data in the configuration packet, in response to a determination
that the received packet is a configuration packet, and changes the
configuration of at least one of (i) the loaded protocol stacks and
(ii) the frame type assignments based on the altered configuration
information.
Inventors: |
Kraslavsky; Andrew J. (Rancho
Santa Margarita, CA) |
Assignee: |
Canon Kabushiki Kaisha (Tokyo,
JP)
|
Family
ID: |
24154546 |
Appl.
No.: |
08/540,227 |
Filed: |
October 6, 1995 |
Current U.S.
Class: |
370/254; 370/389;
370/420; 710/10; 714/4.2 |
Current CPC
Class: |
H04L
29/06 (20130101); H04L 69/18 (20130101) |
Current International
Class: |
H04L
29/06 (20060101); G06F 013/14 (); H04J
003/26 () |
Field of
Search: |
;340/825.06,825.08,825.22,825.5,825.51
;395/181,182.01,182.02,200.02,200.1,200.11,200.12,200.15,200.2,500,800,828,830
;370/241,250,254,389,400,401,420,449,465,469 |
References Cited
[Referenced By]
U.S. Patent Documents
Primary Examiner: Hsu; Alpus H.
Attorney, Agent or Firm: Fitzpatrick, Cella, Harper &
Scinto
Claims
What is claimed is:
1. A method of using configuration packets received from a local
area network (LAN) to reconfigure a network interface device on the
LAN, said method comprising the steps of:
executing an initialization process which loads protocol stack
modules and assigns frame types to each of the loaded protocol
stack modules based on configuration information in the network
interface device regarding the protocols and frame types used on
the LAN;
receiving packets including data and address information from the
LAN;
determining whether a received packet is a configuration packet by
detecting whether the packet is addressed to a predetermined
address;
altering the configuration information using the data in the packet
in response to a determination that the received packet is a
configuration packet; and
changing the configuration of at least one of (i) the loaded
protocol stack modules and (ii) the frame type assignments for the
network interface device based on the altered configuration
information.
2. A method according to claim 1, wherein the predetermined address
comprises a protocol-specific identifying stamp, and wherein said
determining step includes detecting whether a received packet is
addressed to the protocol-specific identifying stamp.
3. A method according to claim 2, wherein the protocol-specific
identifying stamp comprises (i) a predetermined socket when the
configuration packet uses an IPX/SPX protocol, (ii) a predetermined
port when the configuration packet uses a TCP/IP protocol, and
(iii) a predetermined DDP type when the configuration packet uses
an AppleTalk protocol, and wherein said determining step includes
detecting whether a received packet is addressed to any of the
predetermined socket, the predetermined port, or the predetermined
DDP type.
4. A method according to claim 1, wherein the configuration
information indicates which protocol stack modules should be
loaded, and wherein the data in the configuration packet can alter
the configuration information so that different protocol stack
modules are loaded when the initialization process is
reexecuted.
5. A method according to claim 1, wherein the data in the
configuration packet indicates whether the configuration packet
corresponds to a query packet, and wherein said method further
comprises determining whether a configuration packet is a query
packet and, in response to a determination that the configuration
packet is a query packet, transmitting to the LAN a response packet
including data indicating current protocol stack module status and
current frame type assignments.
6. A method according to claim 1, wherein the network interface
device includes a peripheral server, and wherein said method
further comprises determining whether a received packet is
addressed to the peripheral server and, in response to a
determination that the received packet is addressed to the
peripheral server, routing the received packet to the peripheral
server and servicing the data in the packet.
7. A method according to claim 1, wherein the configuration packet
includes data indicating whether or not an immediate reboot is
desired, and said changing step comprises reexecuting the
initialization process using the altered configuration information
when the configuration packet data indicates that an immediate
reboot is desired.
8. A network interface device which can communicate with other
devices via a local area network (LAN) using various protocols and
frame types, and which can be remotely reconfigured to use
different protocols and frame types based on configuration packets
received from the LAN, said network device comprising:
a LAN interface over which packets including address and data
information are received from the LAN, and over which packets to
the LAN are transmitted; and
a processor that (i) executes an initialization routine to load
protocol stack modules and to assign a frame type for each of the
loaded protocol stack modules based on configuration information
regarding the protocols and frame types used on the LAN, (ii)
determines whether a packet received from the LAN is a
configuration packet by detecting whether the received packet is
addressed to a predetermined address comprising a media access
control address of said network interface device and a
predetermined identifying stamp, (iii) alters the configuration
information using the data in the configuration packet in response
to a determination that the received packet is a configuration
packet, and (iv) changes the configuration of at least one of (a)
the loaded protocol stack modules, and (b) the frame type
assignments, based on the altered configuration information.
9. A network interface device according to claim 8, wherein the
configuration packet includes data indicating whether or not an
immediate reboot is desired, and said processor determines whether
an immediate reboot is desired and, when said processor determines
that an immediate reboot is desired, changes the configuration of
the network interface device by reexecuting the initialization
routine using the altered configuration information.
10. A network interface device according to claim 8, wherein said
network interface device further comprises a storage device that
stores the configuration information regarding which protocols and
frame types are used on the LAN, and wherein said processor
executes the initialization process based on the stored
configuration information and alters the stored configuration
information in response to a determination that a received packet
is a configuration packet.
11. A network interface device according to claim 8, wherein the
predetermined address comprises a protocol-specific identifying
stamp, and wherein said processor detects whether a received packet
is addressed to the protocol-specific identifying stamp.
12. A network device according to claim 11, wherein the
protocol-specific identifying stamp comprises (i) a predetermined
socket when the configuration packet uses an IPX/SPX protocol, (ii)
a predetermined port when the configuration packet uses a TCP/IP
protocol, and (iii) a predetermined DDP type when the configuration
packet uses an AppleTalk protocol, and wherein said processor
detects whether a received packet is addressed to any of the
predetermined socket, the predetermined port, or the predetermined
DDP type.
13. A network interface device according to claim 8, wherein the
data in the configuration packet indicates whether the
configuration packet corresponds to a query packet, and wherein
said processor also determines whether a configuration packet is a
query packet and, in response to a determination that the
configuration packet is a query packet, transmits a response packet
including data indicating current protocol stack module status and
current frame type assignments to the LAN.
14. A network device according to claim 8, wherein said processor
also (i) executes a peripheral server software module, (ii)
determines whether a received packet is addressed to the peripheral
server software module, and (iii) services the data in the received
packet in response to a determination that the received packet is
addressed to the peripheral server module.
15. A method for transmitting configuration packets comprising
configuration information regarding active protocols and frame type
assignments to a network interface device connected to a local area
network (LAN) from a computer which is connected to the LAN and
which has a display device, said method comprising the steps
of:
inputting to the computer new configuration information indicating
protocol stacks to be loaded on the network interface device and
frame type assignments for each of the loaded protocol stacks;
forming a communication packet including destination address
information identifying the network interface device, address data
identifying the packet as a configuration packet, and the input
configuration information; and
transmitting the configuration packet to the network interface
device via the LAN.
16. A method according to claim 15, further comprising the steps
of:
transmitting from the computer to the network interface device via
the LAN a query packet including destination address information
identifying the network interface device, address data identifying
the packet as a configuration packet, and data indicating a request
for current configuration information;
receiving from the network interface device a response packet
including current configuration information indicating the current
active protocol stacks and the current frame type assignments for
the network interface device; and
displaying the current configuration information received from the
network interface device on the display device of the computer.
17. A method according to claim 15, wherein the computer uses a
predetermined protocol, and wherein the address data identifying
the packet formed in said forming step as a configuration packet is
a protocol-specific identifying stamp corresponding to the
predetermined protocol.
18. A method according to claim 17, wherein the computer uses one
of an IPX/SPX protocol, a TCP/IP protocol, and an AppleTalk
protocol, and wherein the address data identifying the packet
formed in said forming step as a configuration packet is (i) a
predetermined socket, when the computer uses an IPX/SPX protocol,
(ii) a predetermined port, when the computer uses a TCP/IP
protocol, and (iii) a predetermined DDP type, when the computer
uses an AppleTalk protocol.
19. A method according to claim 15, wherein said inputting step
includes inputting data indicating whether the new configuration
information should be implemented immediately or at the next
initialization of the network interface device and, when the input
data indicates that the new configuration information should be
implemented immediately, said forming step includes setting data in
the configuration packet indicating that the network interface
device should execute an initialization process using the
configuration information in the configuration packet.
20. A method according to claim 15, wherein the network interface
device includes a peripheral server; and
wherein said method further comprises the steps of:
forming a packet including destination address information
identifying the network interface device, address data identifying
the peripheral server, and data to be serviced by the peripheral
server; and
transmitting the packet to the network interface device via the
LAN.
21. A computer which is connected to a local area network (LAN) and
which transmits, to a network interface device connected to the
LAN, configuration packets including configuration information
regarding protocol stacks to be loaded in the network interface
device and frame type assignments for the loaded protocol stacks,
said computer comprising:
a LAN interface over which communication packets are transmitted to
and received from the LAN;
an inputting device for inputting to the computer new configuration
information indicating protocol stacks to be loaded in the network
interface device and frame type assignments for each of the loaded
protocol stacks; and
a processor that (i) forms a communication packet including
destination address information identifying the network interface
device, address data identifying the packet as a configuration
packet, and the input configuration information, and (ii) transmits
the communication packet to the network interface device via said
LAN interface.
22. A computer according to claim 21, wherein said computer further
comprises a display device and wherein said processor (i) transmits
to the network interface device via said LAN interface a query
packet including destination address information identifying the
network interface device, address data identifying the packet as a
configuration packet, and data indicating a request for current
configuration information, (ii) processes a response packet which
is received from the network interface device via said LAN
interface and which includes current configuration information
indicating currently-loaded protocol stacks and current frame type
assignments for the network interface device, and (iii) displays
the current configuration information received from the network
interface device on the display device of the computer.
23. A computer according to claim 21, wherein said computer uses a
predetermined protocol, and wherein the address data identifying
the packet formed by said processor as a configuration packet is a
protocol-specific identifying stamp corresponding to the
predetermined protocol.
24. A computer according to claim 23, wherein said computer uses
one of an IPX/SPX protocol, a TCP/IP protocol, and an AppleTalk
protocol, and wherein the address data identifying the packet
formed by said processor as a configuration packet is (i) a
predetermined socket, if said computer uses an IPX/SPX protocol,
(ii) a predetermined port, if said computer uses a TCP/IP protocol,
and (iii) a predetermined DDP type,if said computer uses an
AppleTalk protocol.
25. A local area network system comprising:
a plurality of network devices interfaced to a local area network
(LAN);
a peripheral which can process data received from the local area
network; and
a network interface device which interfaces the peripheral to the
LAN, and which can be remotely reconfigured to use different
protocols and frame types based on configuration packets received
from the LAN, the network device comprising:
a LAN interface over which packets including address and data
information are received from the LAN, and over which packets to
the LAN are transmitted; and
a processor that (i) executes an initialization routine to load
protocol stack modules and to assign a frame type for each of the
loaded protocol stack modules based on configuration information
regarding the protocols and frame types used on the LAN, (ii)
determines whether a packet received from the LAN is a
configuration packet by detecting whether the received packet is
addressed to a predetermined address comprising a media access
control address of the network interface device and a predetermined
identifying stamp, (iii) alters the configuration information using
the data in the configuration packet in response to a determination
that the received packet is a configuration packet, and (iv)
changes the configuration of at least one of (a) the loaded
protocol stack modules, and (b) the frame type assignments, based
on the altered configuration information.
26. A local area network system comprising:
a plurality of network devices interfaced to a local area network
(LAN);
a network interface device connected to the LAN which interfaces
one of the plurality of network devices to the LAN; and
a computer which is connected to the LAN and which transmits, to
the network interface device connected to the LAN, configuration
packets including configuration information regarding protocol
stacks to be loaded in the network interface device and frame type
assignments for the loaded protocol stacks, the computer
comprising:
a LAN interface over which communication packets are transmitted to
and received from the LAN;
an inputting device for inputting to the computer new configuration
information indicating protocol stacks to be loaded in the network
interface device and frame type assignments for each of the loaded
protocol stacks; and
a processor that (i) forms a communication packet including
destination address information identifying the network interface
device, address data identifying the packet as a configuration
packet, and the input configuration information, and (ii) transmits
the communication packet to the network interface device via the
LAN interface.
27. A computer-readable memory medium for storing
computer-executable process steps to use configuration packets
received from a local area network (LAN) to reconfigure a network
interface device on the LAN, the computer-executable process steps
comprising:
an executing step to execute an initialization process which loads
protocol stack modules and assigns frame types to each of the
loaded protocol stack modules based on configuration information in
the network interface device regarding the protocols and frame
types used on the LAN;
a receiving step to receive packets including data and address
information from the LAN;
a determining step to determine whether a received packet is a
configuration packet by detecting whether the packet is addressed
to a predetermined address;
an altering step to alter the configuration information using the
data in the packet in response to a determination that the received
packet is a configuration packet; and
a changing step to change the configuration of at least one of (i)
the loaded protocol stack modules and (ii) the frame type
assignments for the network interface device based on the altered
configuration information.
28. A computer-readable memory medium according to claim 27,
wherein the predetermined address comprises a protocol-specific
identifying stamp, and wherein the determining step includes
detecting whether a received packet is addressed to the
protocol-specific identifying stamp.
29. A computer-readable memory medium according to claim 28,
wherein the protocol-specific identifying stamp comprises (i) a
predetermined socket when the configuration packet uses an IPX/SPX
protocol, (ii) a predetermined port when the configuration packet
uses a TCP/IP protocol, and (iii) a predetermined DDP type when the
configuration packet uses an AppleTalk protocol, and wherein the
determining step includes detecting whether a received packet is
addressed to any of the predetermined socket, the predetermined
port, or the predetermined DDP type.
30. A computer-readable memory medium according to claim 27,
wherein the configuration information indicates which protocol
stack modules should be loaded, and wherein the data in the
configuration packet can alter the configuration information so
that different protocol stack modules are loaded when the
initialization process is reexecuted.
31. A computer-readable memory medium according to claim 27,
wherein the data in the configuration packet indicates whether the
configuration packet corresponds to a query packet, and wherein the
computer-executable process steps further comprise a determining
step to determine whether a configuration packet is a query packet
and, in response to a determination that the configuration packet
is a query packet, a transmitting step to transmit to the LAN a
response packet including data indicating current protocol stack
module status and current frame type assignments.
32. A computer-readable memory medium according to claim 27,
wherein the network interface device includes a peripheral server,
and wherein the computer-executable process steps further comprise
a determining step to determine whether a received packet is
addressed to the peripheral server and, in response to a
determination that the received packet is addressed to the
peripheral server, a routing step to route the received packet to
the peripheral server and servicing the data in the packet.
33. A computer-readable memory medium according to claim 27,
wherein the configuration packet includes data indicating whether
or not an immediate reboot is desired, and the changing step
comprises reexecuting the initialization process using the altered
configuration information when the configuration packet data
indicates that an immediate reboot is desired.
34. Computer-executable process steps stored in a computer-readable
medium, the process steps to use configuration packets received
from a local area network (LAN) to reconfigure a network interface
device on the LAN, the process steps comprising:
code to execute an initialization process which loads protocol
stack modules and assigns frame types to each of the loaded
protocol stack modules based on configuration information in the
network interface device regarding the protocols and frame types
used on the LAN;
code to receive packets including data and address information from
the LAN;
code to determine whether a received packet is a configuration
packet by detecting whether the packet is addressed to a
predetermined address;
code to alter the configuration information using the data in the
packet in response to a determination that the received packet is a
configuration packet; and
code to change the configuration of at least one of (i) the loaded
protocol stack modules and (ii) the frame type assignments for the
network interface device based on the altered configuration
information.
35. Computer-executable process steps according to claim 34,
wherein the predetermined address comprises a protocol-specific
identifying stamp, and wherein the determining code includes code
to detect whether a received packet is addressed to the
protocol-specific identifying stamp.
36. Computer-executable process steps according to claim 34,
wherein the protocol-specific identifying stamp comprises (i) a
predetermined socket when the configuration packet uses an IPX/SPX
protocol, (ii) a predetermined port when the configuration packet
uses a TCP/IP protocol, and (iii) a predetermined DDP type when the
configuration packet uses an AppleTalk protocol, and wherein the
determining code includes code to detect whether a received packet
is addressed to any of the predetermined socket, the predetermined
port, or the predetermined DDP type.
37. Computer-executable process steps according to claim 34,
wherein the configuration information indicates which protocol
stack modules should be loaded, and wherein the data in the
configuration packet can alter the configuration information so
that different protocol stack modules are loaded when the
initialization process is reexecuted.
38. Computer-executable process steps according to claim 34,
wherein the data in the configuration packet indicates whether the
configuration packet corresponds to a query packet, and wherein the
computer-executable process steps further comprise code to
determine whether a configuration packet is a query packet and, in
response to a determination that the configuration packet is a
query packet, code to transmit to the LAN a response packet
including data indicating current protocol stack module status and
current frame type assignments.
39. Computer-executable process steps according to claim 34,
wherein the network interface device includes a peripheral server,
and wherein the computer-executable process steps further comprise
code to determine whether a received packet is addressed to the
peripheral server and, in response to a determination that the
received packet is addressed to the peripheral server, code to
route the received packet to the peripheral server and to service
the data in the packet.
40. Computer-executable process steps according to claim 34,
wherein the configuration packet includes data indicating whether
or not an immediate reboot is desired, and the changing code
comprises reexecuting the initialization process using the altered
configuration information when the configuration packet data
indicates that an immediate reboot is desired.
41. A computer-readable memory medium for storing
computer-executable process steps to transmit configuration packets
comprising configuration information regarding active protocols and
frame type assignments to a network interface device connected to a
local area network (LAN) from a computer which is connected to the
LAN and which has a display device, the computer-executable process
steps comprising:
an inputting step to input to the computer new configuration
information indicating protocol stacks to be loaded on the network
interface device and frame type assignments for each of the loaded
protocol stacks;
a forming step to form a communication packet including destination
address information identifying the network interface device,
address data identifying the packet as a configuration packet, and
the input configuration information; and
a transmitting step to transmit the configuration packet to the
network interface device via the LAN.
42. A computer-readable memory medium according to claim 41,
further comprising:
a transmitting step to transmit from the computer to the network
interface device via the LAN a query packet including destination
address information identifying the network interface device,
address data identifying the packet as a configuration packet, and
data indicating a request for current configuration
information;
a receiving step to receive from the network interface device a
response packet including current configuration information
indicating the current active protocol stacks and the current frame
type assignments for the network interface device; and
a displaying step to display the current configuration information
received form the network interface device on the display device of
the computer.
43. A computer-readable memory medium according to claim 42,
wherein the computer uses a predetermined protocol, and wherein the
address data identifying the packet formed in the forming step as a
configuration packet is a protocol-specific identifying stamp
corresponding to the predetermined protocol.
44. A computer-readable memory medium according to claim 43,
wherein the computer uses one of an IPX/SPX protocol, a TCP/IP
protocol, and an AppleTalk protocol, and wherein the address data
identifying the packet formed in the forming step as a
configuration packet is (i) a predetermined socket, when the
computer uses an IPX/SPX protocol, (ii) a predetermined port, when
the computer uses a TCP/IP protocol, and (iii) a predetermined DDP
type, when the computer uses an AppleTalk protocol.
45. A computer-readable memory medium according to claim 42,
wherein the inputting step includes inputting data indicating
whether the new configuration information should be implemented
immediately or at the next initialization of the network interface
device and, when the input data indicates that the new
configuration information should be implemented immediately, the
forming step includes setting data in the configuration packet
indicating that the network interface device should execute an
initialization process using the configuration information in the
configuration packet.
46. A computer-readable memory medium according to claim 42,
wherein the network interface device includes a peripheral server;
and
wherein the computer-executable process steps further comprise:
a forming step to form a packet including destination address
information identifying the network interface device, address data
identifying the peripheral server, and data to be serviced by the
peripheral server; and
a transmitting step to transmit the packet to the network interface
device via the LAN.
47. Computer-executable process steps stored in a computer-readable
medium, the process steps to transmit configuration packets
comprising configuration information regarding active protocols and
frame type assignments to a network interface device connected to a
local area network (LAN) from a computer which is connected to the
LAN and which has a display device, the process steps
comprising:
code to input to the computer new configuration information
indicating protocol stacks to be loaded on the network interface
device and frame type assignments for each of the loaded protocol
stacks;
code to form a communication packet including destination address
information identifying the network interface device, address data
identifying the packet as a configuration packet, and the input
configuration information; and
code to transmit the configuration packet to the network interface
device via the LAN.
48. Computer-executable process steps according to claim 47,
further comprising:
code to transmit from the computer to the network interface device
via the LAN a query packet including destination address
information identifying the network interface device, address data
identifying the packet as a configuration packet, and data
indicating a request for current configuration information;
code to receive from the network interface device a response packet
including current configuration information indicating the current
active protocol stacks and the current frame type assignments for
the network interface device; and
code to display the current configuration information received form
the network interface device on the display device of the
computer.
49. Computer-executable process steps according to claim 47,
wherein the computer uses a predetermined protocol, and wherein the
address data identifying the packet formed by the forming code as a
configuration packet is a protocol-specific identifying stamp
corresponding to the predetermined protocol.
50. Computer-executable process steps according to claim 49,
wherein the computer uses one of an IPX/SPX protocol, a TCP/IP
protocol, and an AppleTalk protocol, and wherein the address data
identifying the packet formed by the forming code as a
configuration packet is (i) a predetermined socket, when the
computer uses an IPX/SPX protocol, (ii) a predetermined port, when
the computer uses a TCP/IP protocol, and (iii) a predetermined DDP
type, when the computer uses an AppleTalk protocol.
51. Computer-executable process steps according to claim 47,
wherein the inputting code includes code to input data indicating
whether the new configuration information should be implemented
immediately or at the next initialization of the network interface
device and, when the input data indicates that the new
configuration information should be implemented immediately, the
forming code sets data in the configuration packet indicating that
the network interface device should execute an initialization
process using the configuration information in the configuration
packet.
52. Computer-executable process steps according to claim 47,
wherein the network interface device includes a peripheral server;
and
wherein the computer-executable process steps further comprise:
code to form a packet including destination address information
identifying the network interface device, address data identifying
the peripheral server, and data to be serviced by the peripheral
server; and
code to transmit the packet to the network interface device via the
LAN.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention concerns a network interface device by which
the functionality of a peripheral is made available to users of a
computerized local or wide area network. More particularly, the
present invention is a network interface device which communicates
with other network devices using a plurality of different protocol
stacks and which can dynamically reconfigure which protocol stacks
are loaded in the network device and which frame type is assigned
to each loaded protocol stack.
2. Description of the Related Art
Computerized local area networks (LAN's) are in widespread use for
interconnecting many different computers and peripherals so as to
allow users of the computers to communicate with one another and
also to allow those users shared access to the peripherals. LAN's
today are ordinarily organized into two different media types or
architectures, Ethernet or token ring. Ethernet is a bus
architecture in which each device can transmit messages to and
receive messages from the LAN; token ring is a circular
architecture in which a token is passed sequentially to each device
and only the device with the token can transmit a message onto the
LAN. Because of fundamental differences in communications and in
electrical connectivity, a token ring device cannot operate on an
Ethernet medium, and vice versa.
Recent developments in LAN's have seen the introduction of
so-called "heterogeneous" LAN's, i.e., LAN's on which many
different communication protocols are carried on a single Ethernet
or token ring medium. Examples of different protocols are IPX/SPX,
which is used by DOS-based PC's, TCP/IP, which is used by
UNIX-based workstations, and AppleTalk, which is used by Macintosh
computers.
In order for a peripheral to be shared on a heterogeneous LAN, the
peripheral must have an appropriate protocol stack for each of the
different protocols carried on the LAN. A protocol stack is a
software module that processes packets of data which are received
from or are transmitted to the LAN using the corresponding
protocol. Each protocol has fixed rules that govern the exchange of
information between two communicating devices, and the protocol
stack ensures compliance with those rules.
Complicating an already difficult situation, each of the different
protocols can use any one of several different frame types. A frame
type defines the format of a communication packet, i.e., the
location and order in which information such as address data,
protocol information, and data to be serviced by a peripheral
server are presented in the packet. Thus, on an Ethernet medium,
the protocols can use any of 802.2, 802.3, Ethernet.sub.-- II, or
Ethernet.sub.-- Snap frame types, whereas on a token ring medium,
the protocols can use either a Token-Ring or Token-Ring.sub.-- SNAP
frame type.
Thus, before a peripheral can provide shared access to itself from
any one of different users on a heterogeneous LAN, the peripheral
must know the protocols in use and the frame type used for each
protocol. This information is necessary so that the peripheral can
load the appropriate protocol stacks and route packets to and from
the proper protocol stack using their assigned frame type.
Conventionally, the peripheral or an interface device connected to
the peripheral may include a configuration file. For example, a DOS
PC operating in a Novell NetWare environment often includes a file
commonly named NET.CFG, in which such information is stored. The
information in the NET.CFG file is read during an initialization
process and is used to determine which protocol stacks to load and
which frame type to assign to each protocol. The configuration
information can be changed only by editing the NET.CFG file at the
peripheral.
There are several difficulties with the conventional approach. In
many cases, a peripheral does not provide any way to edit the
NET.CFG file. This is particularly true where the peripheral is a
device that is not associated with a dedicated computer because the
peripheral does not have any way to input new configuration or to
access and change the stored configuration information.
Moreover, even if the NET.CFG file can be edited at the peripheral,
it is often desirable to reconfigure the loaded status of protocol
stacks and the frame type assignments for the peripheral from a
remote computer at another location, e.g., a system administrator's
computer at a central station. For example, the frame type used
with a certain protocol may be changed, and each peripheral must be
reconfigured to assign the new frame type to that protocol.
Alternatively, a new computer may be added to the network which
uses a protocol not previously used on the network, and each
peripheral that the new computer needs to communicate with must be
reconfigured to load a protocol stack for the new protocol. In
either case, it would be much more preferable and convenient to
reconfigure the peripherals from a single remote location.
Otherwise, each peripheral site must be visited to perform
reconfiguration.
Accordingly, a way is needed to remotely reconfigure the frame type
assignments and the loaded protocol stacks for a peripheral, and
the reconfiguration must be possible regardless of the protocol and
frame type currently in use by the device from which the
reconfiguration is performed.
SUMMARY OF THE INVENTION
These needs are addressed by the present invention, in which the
protocol stacks loaded in a network device and/or the frame type
assigned to each loaded protocol stack can be dynamically
reconfigured from a remote device regardless of the protocol used
by the remote device.
In a first aspect, the present invention is a method for
reconfiguring frame type assignments for protocol stack modules in
a network interface device which is interfaced to a local area
network (LAN). An initialization process is executed which loads
protocol stack modules and assigns frame types to each of the
loaded protocol stack modules based on configuration information
regarding the protocols and frame types used on the LAN. The
network interface device receives packets including data and
address information from the LAN and determines whether a received
packet is a configuration packet by detecting whether the packet is
addressed to the predetermined address assigned to the network
interface. In particular, the device first detects if the packet is
addressed and, if so, detects whether an identifying "stamp"
corresponds to a predetermined address (e.g., a reserved IPX socket
number). In response to a determination that the received packet is
a configuration packet, the configuration information is altered
using the data in the configuration packet. The configuration of at
least one of (i) the loaded protocol stacks and (ii) the frame type
assignments is then changed using the altered configuration
information. For example, the initialization process may be
reexecuted using the altered configuration information. In the
preferred form, a query request is received first before new
configuration data is received, and a response to the query is sent
to let a user at a remote computer know what the current settings
are. Further, in the preferred form, the configuration information
may be altered to load different protocol stacks in addition to
assigning different frame types.
By virtue of this arrangement, configuration information can be
altered without editing a configuration file at the peripheral.
Accordingly, the configuration information can be conveniently
changed from a remote location, and can be altered even when a
peripheral does not provide any way to edit the NET.CFG file. In
particular, the present invention provides a user with the ability
to send a configuration packet from any platform, e.g., PC,
Macintosh, UNIX workstation, etc., using any protocol and frame
type combination. The network interface device does not have to be
pre-configured to allow such access.
In another aspect, the present invention is a network interface
device which can communicate with other devices via a local area
network (LAN) using various protocols and frame types, and which
can be remotely reconfigured to use different protocols and frame
types. The network interface device includes a LAN interface that
receives packets including address and data information from the
LAN and transmits packets to the LAN. The network interface device
also includes a processor that (i) executes an initialization
routine to load protocol stack modules and to assign a frame type
for each of the loaded protocol stack modules based on
configuration information regarding the protocols and frame types
used on the LAN, (ii) determines whether a packet received from the
LAN is a configuration packet by detecting whether the received
packet is addressed to a predetermined address (e.g., by
determining if a packet is addressed and, if so, whether the
address includes an identifying stamp, such as a reserved IPX
socket), and (iii) alters the configuration information using the
data in the configuration packet, in response to a determination
that the received packet is a configuration packet, and changes the
configuration of at least one of (i) the loaded protocol stacks and
(ii) the frame type assignments based on the altered configuration
information. In the preferred form, the predetermined address is a
configurator "stamp" which is a specific socket number for IPX/SPX,
a specific port for TCP/IP, a specific DDP type for AppleTalk, or
the like. A configuration packet is detected by verifying the
configurator "stamp".
By virtue of this arrangement, a network device is provided which
can be reconfigured upon receiving special communication packets
from the LAN, without a need to edit a configuration file at the
location of the device.
In yet another aspect, the present invention is a method for
transmitting new configuration information regarding active
protocols (i.e., which protocol stacks are loaded) and frame type
assignments to a network interface device connected to a local area
network (LAN) from a computer which is connected to the LAN and
which has a display device. New configuration information is input
to the computer which indicates protocol stacks to be loaded on the
network interface device and frame type assignments for each of the
loaded protocol stacks. A communication packet is then formed which
includes destination address information identifying the network
interface device, address data identifying the packet as a
configuration packet, and the input configuration information. The
configuration packet is transmitted to the network interface device
via the LAN. In the preferred form, a query packet is formed and
transmitted first, before new configuration information is sent.
This enables a user to view the current configuration before
entering new configuration information.
By virtue of this arrangement, a method is provided for
transmitting new configuration information to a network interface
device that does not require visiting the site of the device and
editing a configuration file. Accordingly, a new computer added to
the LAN can transmit configuration information so that peripherals
can communicate with the new computer, even if the new computer
uses a protocol not previously used on the LAN. Further, an
existing computer can inform peripherals of changes in the frame
type used by any protocol.
In still another aspect, the present invention is a computer which
is connected to a local area network (LAN) and which transmits, to
a network interface device connected to the LAN, new configuration
information regarding protocol stacks to be loaded in the network
interface device and frame type assignments for the loaded protocol
stacks. The computer includes a LAN interface for transmitting and
receiving communication packets to and from the LAN and an
inputting device for inputting to the computer new configuration
information indicating protocol stacks to be loaded in the network
interface device and frame type assignments for each of the loaded
protocol stacks. The computer also includes a processor that (i)
forms a communication packet including destination address
information identifying the network interface device, address data
identifying the packet as a configuration packet, and the input
configuration information, and (ii) transmits the communication
packet to the network interface device via the LAN interface.
By virtue of this arrangement, a computer can transmit
reconfiguration information to peripherals when a frame type used
with a particular protocol is changed or when the computer is added
to the LAN and uses a protocol not previously used on the LAN.
This brief summary has been provided so that the nature of the
invention may be understood quickly. A more complete understanding
of the invention can be obtained by reference to the following
detailed description of the preferred embodiment thereof in
connection with the attached drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an overall system view of a local area network using an
Ethernet medium;
FIG. 2 is an overall system view of a local area network using a
token ring medium;
FIG. 3 is a view of a cut-away section of a local area network
which shows a network interface board installed in a multi-device
controller (MDC) which includes a core board for controlling a
digital copier;
FIG. 4 is a block diagram of the network interface board;
FIG. 5 is a view illustrating program modules stored in persistent
storage on the network interface board;
FIG. 6 is a flow diagram for explaining the general operation of
the network interface board;
FIGS. 7A and 7B are diagrams showing the network communication
software architecture on the network during frame type scanning and
after protocol stacks are loaded;
FIG. 8 is a flow diagram showing a process for autosensing of a
frame type used for a protocol;
FIGS. 9(a) through 9(d) are diagrams for an example in which a
frame type pre-scanning program registers with IPX on 802.2, which
shows relationships of various network software modules during
autosensing of frame types;
FIG. 10 is a flow diagram showing a process for receiving a packet
from a network;
FIG. 11 shows a format of an event control block used in receiving
and transmitting packets;
FIG. 12 is a flow diagram showing a process for transmitting a
packet to a network;
FIG. 13 is a flow diagram showing a process for dynamically
determining a network media type;
FIGS. 14(a) and 14(b) are flow diagrams showing a process for
reconfiguring which protocol stacks are loaded and/or which frame
types are assigned for loaded protocol stacks;
FIGS. 15(a) through 15(d) illustrate formats for different packet
types used in connection with reconfiguration; and
FIG. 16 is a flow diagram showing a process for transmitting new
configuration information to a network device from a computer via a
LAN.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[1. System Description]
Generally, the present invention is applicable to any device which
communicates with other devices via a network. Preferably, the
invention is used in an embedded device such as a network interface
board (NIB) for connecting a copier to a network. The invention can
also be used in a network expansion board (NEB) or a network
expansion device (NED) for connecting a printer or other
peripheral, such as a scanner, to a network. The present invention
also has utility for computers connected to a network.
FIG. 1 is an overall system view of a network. The network includes
LAN 1000, a plurality of computers, and a plurality of peripherals
to which the computers share access. The computers shown in FIG. 1
include a PC 1500 which serves as a system administrator's
computer, a PC 1530 which serves as a print server for printers
1550 and 1540, a Macintosh-type computer 1525, a Unix-type
workstation 1535, and a generalized workstation 1536 which has a
central processing unit 1537 and a display 1538. A file server 1510
allows shared access to a network disk 1520. Also, NED 1600 allows
shared access to a printer 1560 and NEB 1700 allows shared access
to a printer 1570. As depicted in FIG. 1, LAN 1000 is an Ethernet
medium having a bus-type architecture.
Alternatively, as shown in FIG. 2, LAN 1000 can be a token ring
medium having a ring-shaped architecture. A token ring medium uses
a different type of physical wire, different electrical
connections, and different communication techniques than an
Ethernet medium. Therefore, operation of a device on a token ring
medium is mutually exclusive of operation on an Ethernet
medium.
FIG. 3 illustrates a cut-away section of LAN 1000 which includes a
network interface board (hereinafter "NIB") 50 installed in a
multi-device controller 20 which also controls a digital copier 10.
LAN 1000 as depicted in FIG. 3 can be either an Ethernet or a token
ring medium.
As seen in FIG. 3, a digital copier 10 includes a document feed
section 11, a paper supply storage section 12, and a sorter/stacker
14. A suitable digital copier for use in the present invention is a
Canon GP55F digital copier. As is known, such digital copiers
operate to feed documents in document feed section 11 past a
digital scanner so as to obtain a digital image of the scanned-in
document. An unshown internal printer prints the scanned-in digital
image onto paper supplied from paper supply storage section 12 and
ejects the printed image to sorter/stacker 14.
A multi-device controller (hereinafter "MDC") 20 accesses an
interface bus (not shown) of digital copier 10 so as to break out
the functionality of the scanner section and the printer section.
MDC 20 includes a core board 24 (not shown) which accesses the
interface bus of digital copier 10 and which provides access to
that interface bus for plural option boards which are connectable
to the core board. The option boards communicate with the core
board via master/slave communication through dual port RAM on each
option board. Most typically, one of the option boards will include
an interface board so as to permit connection to MDC 20 by a
stand-alone computer such as computer 21. Option boards may also
include a facsimile board so as to permit connection to a facsimile
device via a telephone line 22, rasterizer boards so as to permit
rasterization of page description language commands such as PCL5,
LIPS, Postscript, and the like, and image processor boards which
perform advanced image processing functions.
Most notably, according to the present invention one of the option
boards is a network interface board (NIB) 50 connectable to the
core board in MDC 20 so as to permit access to a local area network
such as LAN 1000.
In operation, digital copier 10 is operable in a stand-alone mode
as a standard digital copier. In addition, it is operable as a
scanner or as a printer to local users via personal computer 21.
Most typically, via NIB 50, and in coordination with MDC 20,
digital copier 10 is operable as a multi-functional network device
accessible via a LAN 1000 by any of multiple network users who may
desire concurrent use of the scanner in copier 10, the printer in
copier 10, or one of the option boards in MDC 20 such as the
aforementioned facsimile option board, rasterizer option board, or
image processing option board.
[2. Network Interface Board]
FIG. 4 is a functional block diagram of NIB 50. Broadly speaking,
NIB 50 is an interactive network circuit board which couples copier
10 to LAN 1000, making copier 10 a responsive and interactive
network member. In this way, the printing and scanning functions of
copier 10 can be utilized by users at other network devices. NIB 50
receives print data, status requests, and control commands from LAN
1000, transmits print data, status requests, and control commands
to copier 10 for execution, and transmits status information back
to LAN 100. Thus, NIB 50 can perform not only LAN "print services",
e.g., RPRINTER remote printer services and PSERVER print server
functionalities, but can also offer to network members whatever
status and control features are available from the peripheral
interface.
Power for all circuits is supplied to NIB 50 from a +5V power
source 398. Power is provided from power source 398 to power
converter 396 which provides -9V power to a transceiver 390 and to
power converter 397 which provides +12V power to a flash EPROM 350
for "flashing" (i.e., reprogramming of the EPROM). Network and
network interface control logic 340 is preferably a single 144-pin
application specific integrated circuit (ASIC) that includes a
network controller 330 and interface control logic 320. Network
controller 330 is an NCR macro-cell compatible with a National
DP83902A "ST-NIC" Ethernet controller, the details of which can be
found in National Semiconductor's Local Area Networks Databook,
National Semiconductor p/n 400055, National Semiconductor, 1993.
Network controller 330 is designed to interface with CSMA/CD-type
(carrier sense multiple access with collision detection) local area
networks.
Network controller 330 connects with RJ-45 connector 385 directly
and with coaxial connector 395 through transceiver 390, which is
preferably a National Semiconductor DP8392C coaxial transceiver
interface, the details of which can also be found in National's
Local Area Networks Databook. Network controller 330 also connects
with AUI (Attachment Unit Interface) connector 386. AUI connector
386 is the most shielded, i.e., has the greatest noise immunity, of
the three connectors. Network controller 330 is also coupled to an
8 KB SRAM 380 that is used as an input/output packet buffer for
Ethernet data. This memory should preferably have an access time of
about 70 ns or less.
Interface control logic 320 provides an interface between network
controller 330, microprocessor 300, and memory devices EPROM 350
and DRAM 360. Interface control logic 320 also interfaces with
non-volatile random access memory (NVRAM) 370, which preferrably is
a 1 KB (1024 byte) serial electrically erasable/programmable memory
used for initialization data storage during power cycling of copier
10. Network and peripheral configuration parameters are written
into NVRAM 370 when copier 10 is first installed onto the network
to allow NIB software to repair the installation parameters after
MDC power has been cycled off and on.
Interface control logic 320 also couples with serial port connector
325, which comprises a receive data pin 326 and a transmit data pin
327 that can respectively receive and transmit serial data streams
for debugging purposes. Interface control logic 320 senses data
present at the receive data line and samples the serial bits at
regular intervals.
The central controller of NIB 50 is microprocessor 300, which is
preferably an NEC uPD70236 (V53) 16-bit processor, the details of
which can be found in the NEC V53 User's Manual, NEC, Inc. This
processor is a 16-bit processor with direct memory access (DMA),
interrupts, timers, and a DRAM refresh control. Other
microprocessors, such as an AMD 80C188-20 16-bit microprocessor,
might alternatively be used. 256 KB flash EPROM 350 and 512 KB DRAM
360 are coupled to microprocessor 300 via interface control logic
320. A 40 MHz, 50 ppm crystal oscillator 310 provides
microprocessor 300 with a clock signal that is wholly separate from
and asynchronous with the clock signal of MDC 20 or that of copier
10. All communication between NIB 50 and MDC 20 occurs over a
special bus 405 via an 8 KB dual port RAM (DPRAM) 400. Special bus
405 has a 96 pin connector and carries sixteen data bits, sixteen
address bits, a chip select signal, memory read and write signals,
buffer enable and read signals, a clock input signal, and the
like.
Microprocessor 300 executes instructions stored in flash EPROM 350,
which stores control firmware and printing application software.
After power-on self-test (POST), code from EPROM 350 is selectively
moved to the higher performance 512 KB DRAM 360, which should
preferably have an access time of about 80 ns, for actual
execution.
All software modules executed by microprocessor 300 are stored in
flash EPROM 350. Those modules that are needed are selectively
loaded from EPROM 350 into DRAM 360 and are executed from DRAM.
This permits flexible configuration of NIB 50 by selection of which
modules are to be loaded. Alternatively, software modules can be
downloaded via the LAN or a serial port.
A configuration file 75 is stored in, for example, NVRAM 370 which
is processed by microprocessor 300 upon power on or receipt of a
boot-up command. The configuration file ordinarily directs
processor 300 as to how to partition memory, what memory-resident
programs are to be loaded from EPROM 350 into which areas of
memory, what application programs are to be started as concurrently
executed tasks, and the like. For example, configuration file 75
may include instructions to microprocessor 300 to dedicate certain
areas of DRAM 360 for network communication protocol. Further, the
modules to be loaded may be indicated by using a bit mask which has
a bit corresponding to each module stored in EPROM 350. A "loader"
module stored in EPROM 350 which executes after the above-mentioned
POST routine checks the state of each bit in the mask and, if the
bit is "1", loads the corresponding module from EPROM 350.
FIG. 5 illustrates an example of software modules (or programs),
that are stored in flash EPROM 350. XPSERVER is a module that
provides a standardized interface between NIB 50 and MDC 20. MLID
(Multi-Link Interface Driver) 186 serves as a network interface
driver, while LSL (Link Support Layer) 187 serves as a multiplexer
software module which multiplexes between MLID and the protocol
stack modules. An IPX protocol stack module 1701 for supporting
IPX/SPX protocol used by NetWare (Novell's network software) is
also contained in EPROM 350. Since NIB 50 can support multiple
protocols, it can include protocol stacks for other modules, such
as a TCP/IP protocol stack module 1702 and an AppleTalk protocol
stack module 1703, for example. Other protocols such as
NetBIOS/NETBEUI also may be supported.
In the preferred form of the invention, the network interface
driver, multiplexer, and protocol stack modules conform to the Open
Data-Link Interface (ODI) specification described in "Open
Data-Link Interface Developer's Guide for DOS Workstation Protocol
Stacks", Version 1.10, Released by Novell, Inc., Mar. 18, 1992.
Particularly, MLID 186 is the lowest level of network connection
software and handles sending and receiving of packets to and from
the network by adding or stripping off frame headers. MLID 186
includes a separate board for processing each frame type that may
be used on the network. The boards may be logical boards or
physical boards, but logical boards are used in the preferred
embodiment. In an Ethernet device, there are four logical boards,
with logical boards 0 through 3 respectively processing frame types
802.3, 802.2, Ethernet.sub.-- II, and Ethernet.sub.-- SNAP. A token
ring device has only two logical boards for respectively processing
Token-Ring and Token-Ring.sub.-- SNAP frame types.
For each logical board, MLID 186 has a configuration table that
stores configuration information for the logical board, such as the
information indicated in the MLID configuration table format of the
above-referenced ODI specification. For example, this information
includes the configuration table version, node address, board
number, maximum packet size, best data size, worst data size, frame
type ID, transport time, source route handler, line speed, queue
depth, number of send retries, default base memory address, memory
size, etc.
The frame type ID is a value identifying the frame type processed
by the logical board corresponding to the configuration table. In
an Ethernet device, the frame type ID values shown in Table 1 are
used, and in a token ring device, the frame type ID values shown in
Table 2 are used:
TABLE 1 ______________________________________ Frame Type ID Value
______________________________________ Ethernet.sub.-- II 2 802.2 3
802.3 5 Ethernet.sub.-- SNAP 10
______________________________________
TABLE 2 ______________________________________ Frame Type ID Value
______________________________________ Token-Ring 4
Token-Ring.sub.-- SNAP 11
______________________________________
LSL 187 (link support layer) comprises software code that acts as a
multiplexer between the lowest level MLID 186 functionality and
network protocol stacks above. Since several different protocols
can be used on LAN 1000, and some may even use the same frame type,
some provision is needed to route packets from MLID 186 to the
correct protocol stack. LSL 187 performs that function. In
particular, LSL 187 assigns a Protocol ID (PID) to each loaded
protocol stack. The PID is included in a packet and is used by LSL
187 in conjunction with the frame type to route a received packet
to a protocol stack. In particular, LSL 187 accepts registrations
of any of the various frame types with which frame packets may be
carried on the network. Thus, for example, in an Ethernet
environment, LSL 187 will accept registrations of 802.2, 802.3,
Ethernet.sub.-- II, and Ethernet.sub.-- SNAP, and in a token ring
environment LSL 187 will accept registrations for Token-Ring and
Token-Ring.sub.-- SNAP. By registering a frame type with LSL 187, a
software module above LSL 187 instructs LSL 187 to provide the
module with all frame packets that match the registered frame type.
Other multiplexer software modules that perform the same function
may be used.
The protocol stacks 1701-1703 perform the function of receiving
packets for the respective protocols, determining what needs to be
done with the packets, and sending the packets to the necessary
destination, e.g., a print server module or a scan server
module.
CNETX is customized code that turns local DOS-like function calls
into network function calls, providing file functions like OPEN,
READ, WRITE, and CLOSE. CNETX also provides NCP (NetWare Core
Protocol) for NetWare server modules. The pre-scanning program 84
is responsible for identifying what frame types are associated with
the various possible protocol stacks. Because NIB 50 supports
multiple protocol stacks, this module exists as long as NIB 50 is
running.
Pre-scanning program 84 performs a so-called "autosensing" (AS)
function to identify what frame types (such as 802.2, 802.3,
Ethernet.sub.-- II or Ethernet.sub.-- SNAP for an Ethernet medium)
are associated with what protocol stack (for example, IPX/SPX or
TCP/IP). The operation of pre-scanning program 84 is described in
detail below. Pre-scanning program 84 includes a portion which
performs a so-called "configurator" function, which is also
described in detail below. The configurator function allows
reconfiguration of loaded protocol stacks and frame type
assignments from a remote computer.
EPROM 350 also includes software to export the functionality of
copier 10 onto the LAN. CPSERVER (PSE) 79 is a custom
implementation (or emulation) of a Novell NetWare printer server
application. This module provides self-generated print banners,
user notification of completion and exception status, and
transmission of print data and status commands to copier 10 when
serving as a printer. This differs from the Novell print server in
that CPSERVER is dedicated to driving the local printer (i.e.,
copier 10 to which NIB 50 is coupled) and cannot drive any remote
RPRINTERs. This program owns the print data lines for the duration
of a print job. CRPRINTER is a custom implementation of a Novell
RPRINTER print application. This module is a slave application that
is sent data by a Novell printer server application elsewhere on
LAN 10. EPROM 350 also includes an LPD (Line Printer Daemon)
module, which is a print application for UNIX, and an APS (Apple
Print Server) module, which is a print application for
Macintosh.
EPROM 350 can also include other servers, such as an FSC task which
handles fax status and control tasks, an FSR task which handles fax
send and receive tasks for a facsimile board present in MDC 20, a
scan server, and an image processing server. Those other servers
operate to export functionality of other option boards connected to
MDC 20.
The CPSOCKET program runs for all protocol stacks. The program
responds to requests for remote utilities connection, requests for
data download, or requests for services from remote utilities, and
provides status and control to other tasks via interprocess
communication. Because CPSOCKET typically owns the status and
control lines between NIB 50 and MDC 20, it is the only task that
has the ability to obtain status data from copier 10 via the status
lines. CPSOCKET is responsible for the network connection and
packet contents between, for example, the Novell-oriented status
and control utilities, between the UNIX-oriented status and control
utilities, or between Macintosh-oriented status and control
utilities.
MONITOR is a customized multi-tasking kernel which performs task
creation, task destruction and microprocessor dispatch. MONITOR
also has memory management sub-modules MEMGET and MEMFREE. RESIDENT
is a block of routines that provides generic services such as read
and write to flash EPROM 350, FLASH code, ROM based debugger,
hardware timer tick and other basic features. POST is the power-on
self-test module that checks the integrity of NIB hardware and
software at power-up.
A network identification file (NIF) data block is also provided
which stores board-invariant information, which is unique for every
network board (e.g., a MAC (media access control) address),
hardware configuration data, board revision number and the like, as
well as changeable information such as software version number. On
the NIB, the NIF is stored in a separate ROM. On other interface
boards, such as NEBs and NEDs, the NIF may be stored in EPROM 350.
The information in the NIF data block is used, among other things,
to ensure that flash EPROM 350 is not reprogrammed with an
incompatible firmware image.
Specifically, EPROM 350 stores "board" information such as model
number, firmware level, and board revision number, as well as
"network" information such as Media Access Control (MAC) address,
which is unique for every network board, board name, primary file
server identification, queues serviced, sampling frequency, PSERVER
name, zone-name, and the like.
[3. Operation]
Operation of the network interface board will now be explained with
reference to the flow diagram shown in FIG. 6. The process steps
shown in FIG. 6 are executed by microprocessor 300 by loading the
software modules shown in FIG. 5 into DRAM 360 and executing the
process steps from DRAM.
In step S601, upon application of power or suitable logic reset,
CPU 52 initiates boot-up processing by reference to configuration
file 75. The configuration file, as mentioned above, can include
various options fixing the configuration of NIB 50, such as memory
allocation, operating system, etc. Ordinarily, configuration file
75 configures NIB 50 as a network interface board interfacing
between the network and MDC 20. In that instance, configuration
file 75, as mentioned above, includes configuration of memory,
allocation of memory space for various memory-resident programs
such as a network communication stack, and initiation and loading
of various program modules.
As shown in FIG. 6, in step S602, microprocessor 300 loads its
network communication software. Specifically, microprocessor 300
loads MLID 186 and LSL 187 into memory allocated for them
(typically high memory), and in addition loads whatever network
communication stacks are needed for participating in network
communications in the network environment that NIB 50 is installed
in, as indicated by default configuration information in
configuration file 75. For example, in a situation where a Novell
NetWare network environment has been established, microprocessor
300 would load an IPX/SPX network communication stack into memory.
Likewise, in a situation where a UNIX network operating system is
in place, microprocessor 300 would load a TCP/IP network
communication stack into memory. Whether to load IPX/SPX, TCP/IP,
AppleTalk, or any combination, is stored as part of the default
start-up script in configuration file 75.
As mentioned above, pre-scanning program 84 can detect what frame
type is being used on the network for each protocol. However,
default data in configuration file 75 can alternatively be used to
assign a frame type to each loaded protocol stack. In the preferred
form of the invention, configuration file 75 contains data for a
default configuration in which a TCP/IP protocol stack is loaded
and assigned an Ethernet.sub.-- II frame type, an AppleTalk
protocol stack is loaded and assigned a Phase 2 (Ethernet.sub.--
SNAP) frame type, and an IPX/SPX protocol stack is loaded and
assigned a frame type by autosensing using pre-scanning program
84.
In step S603 the needed network servers (such as CPSERVER 79 and
the like) are all loaded. Then, in step S604, NIB 50 waits for a
request for network services. Until a request for network services
is received, NIB 50 stands by in an idle state, responding to
access inquiry commands from core board 24 with simple
acknowledgement ("ACK"). On the other hand, as soon as a request
for network services is received, either from the network or from a
local user such as a user operating digital copier 10, flow
advances to step S605.
In steps S605 and S606, after a request for network services has
been received, the request is serviced. In particular, in step
S605, microprocessor 300 initiates execution of the appropriate
network server. For example, in a situation where a request for
print services is requested, microprocessor 300 initiates execution
of CPSERVER 79.
In step S606, microprocessor 300 continues execution of the needed
server so as to service the request. Then, flow returns to step
S604 to wait for additional requests for network services.
Meanwhile, services already being processed in step S606 continue
until they are complete. Should additional requests be received,
then microprocessor 300 initiates execution of the appropriate
server (step S605) and begins servicing the request (step S606).
Concurrent network processing, to the extent physically supported
by devices controlled by NIB 50, is then carried out.
[3.1 Autosensing Frame Types and Configurator Function]
As mentioned above, the present invention includes a configurator
function that allows the protocol stacks which are loaded in a
peripheral and the frame type assignments for each loaded protocol
stack to be reconfigured from a computer at a remote location. In
the preferred embodiment, the configurator function is encoded as
part of pre-scanning program 84 and relies in part upon the
operational relationship between pre-scanning program 84 and LSL
187 to receive packets from the remote computer which contain new
configuration information.
FIG. 7A shows the software architecture in NIB 50 during
initialization, while pre-scanning program 84 is determining frame
types and before any of protocol stacks 1701-1703 are loaded. In
that situation, MLID 186 interfaces with LAN 1000, LSL 187 is on
top of MLID 186, and pre-scanning program 84 is on top of LSL 187.
FIG. 7B shows the software architecture after protocol stacks have
been loaded. In this case, protocol stacks 1701-1703 are loaded on
top of LSL 187, but pre-scanning program 84 remains resident for
reasons described below and is also on top of LSL 187. CPSOCKET is
on top of all protocol stacks to receive network requests for
services or status. Print (or other service) application modules
also load on top of the protocol stacks.
As mentioned above, pre-scanning program 84 performs a function of
monitoring network broadcast traffic in detecting what frame type
is used for a particular protocol or protocols, and assigning the
detected frame type to the associated protocol. As such,
pre-scanning program 84 receives all packets that are not wanted by
any protocols that have registered with LSL 187 for each frame
type. The reception of packets in this manner is important to the
autosensing function, which is described next, and is also
important to the configurator function. described below. It should
be noted that autosensing of frame type/protocol assignment is a
configurable option, because the frame type/protocol assignments
can be pre-assigned, for example, using a configuration file. The
configurator function, on the other hand, is always active.
FIGS. 8 and 9(a) through 9(d) illustrate one implementation for
performing autosensing. FIG. 8 is a flow diagram showing process
steps which are executed by NIB microprocessor 300 in accordance
with an exemplary embodiment of pre-scanning program 84 loaded from
EPROM 350. Specifically, the process steps of FIG. 8 illustrate a
method for loading a network communication stack in accordance with
step S602 of FIG. 6.
FIGS. 9(a) through 9(d) show the functional relationships between
different software modules during autosensing. In particular, those
figures show an example of autosensing in which pre-scanning
program 84 assigns frame type 802.2 to IPX. The actual
structure-that implements the process of FIGS. 8 and creates the
functional relationships can be understood with reference to FIG.
4. Software modules stored EPROM 350 are loaded into DRAM 360 under
the control of microprocessor 300. The needed software modules are
then executed by the microprocessor 300. Assuming an Ethernet
medium, packets are received over a physical wire at RJ45 connector
385 and are routed to network controller 330. Packets that are
intended for NIB 50 are then stored in DRAM 360 under the control
of microprocessor 300, and packets are routed between software
modules bypassing the memory address where the packet is
stored.
Referring now to FIG. 8, in step S801, microprocessor 300 loads LSL
187 (link support layer) and begins executing LSL 187. As discussed
above, LSL 187 acts as a multiplexer between the low level MLID 186
(multi-link interface driver) and various protocol stacks which may
be loaded above it.
In step S802, microprocessor 300 loads MLID 186. As described
above, MLID 186 is the lowest level of software that communicates
to the network. MLID 186 thus acts as the direct software interface
to the network frame packets which are carried on the network wire.
Other network interface drivers that perform the same function may
be used.
In step S803, microprocessor 300 loads prescanning program 84 on
top of LSL 187. As mentioned above, pre-scanning program 84 is
responsible for identifying, if so configured, what frame types are
associated with the various protocols in which NIB 50 is adapted to
communicate. In step S804, prescanning program 84 registers to
receive from LSL 187 all frame types that are supported by MLID
186, thereby instructing LSL 187 to provide pre-scanning program 84
with all frame packets which match any of the registered frame
types and are not wanted by any protocol stacks also registered for
the frame type.
Flow then advances to step S805 in which MLID 186 and LSL 187
monitor the network for any traffic. Specifically, in step S805,
the network is monitored for packets addressed to the NIB's MAC
address and for broadcast traffic, meaning that the destination of
the traffic is unspecified (i.e., "to anyone"). Ordinarily,
broadcast traffic is identified by a global specification for the
destination media access control (MAC) address, for example 12
hexadecimal F's in sequence. Until LAN broadcast traffic is
detected, pre-scanning program 84 does nothing.
At this point in pre-scanning program 84's execution, the
relationship of the various software modules is as depicted in FIG.
9(a). As seen there, it is possible for multiple network devices,
such as devices 182, 183, 184, and 185, each of which runs a
different protocol, all to be connected to a single LAN 1000. The
devices may use the same or different frame types. In FIG. 9(a),
device 182 is a Novell device running an IPX/SPX protocol using an
802.2 frame type; device 183 is a UNIX network device running a
TCP/IP protocol using an Ethernet.sub.-- II frame type; device 184
is a Macintosh device running an Ethernet protocol using an
Ethernet.sub.-- SNAP frame type; and network device 185 is an
unidentified frame and protocol device using an 802.3 frame type.
Of course, the combinations shown in FIG. 9(a) are illustrative
only.
NIB 50 is also connected to LAN 1000 and includes LSL 187 loaded on
top of MLID 186. Pre-scanning program 84 is shown as having
registered each of the different frame types which may be exchanged
on LAN 1000. Thus, as shown in FIG. 9(a), which depicts an Ethernet
environment, pre-scanning program 84 has registered 802.2 at 189,
Ethernet.sub.-- II at 190, Ethernet.sub.-- SNAP at 191, and 802.3
at 192.
When LAN broadcast or NIB-directed traffic is detected, flow
advances to step S806 of FIG. 8 in which LSL 187 provides the frame
packet to pre-scanning program 84. In step S807, pre-scanning
program 84 decodes the frame's protocol header so as to identify
the protocol in use by that frame packet. This header varies
depending on the frame type the protocol is using.
FIG. 9(b) illustrates this sequence. As seen in FIG. 9(b), network
device 182 has issued a broadcast frame packet using an 802.2 frame
type. Since pre-scanning program 84 has registered 802.2 with LSL
187, at 189 as shown in FIG. 9(a), LSL 187 provides the frame
packet to pre-scanning program 84. Pre-scanning program 84 decodes
the frame's protocol header using the above table so as to
determine the protocol in use on that frame type.
Examples of allowable frame types for IPX/SPX, TCP/IP, and
AppleTalk are as shown in the following Table 3:
TABLE 3 ______________________________________ IPX/SPX TCP/IP
AppleTalk ______________________________________ Ethernet.sub.-- II
Ethernet.sub.-- II Ethernet.sub.-- II (Phase 1) Ethernet.sub.--
SNAP Ethernet.sub.-- SNAP Ethernet.sub.-- SNAP (Phase 2) 802.2
802.3 ______________________________________
As is evident from the above list, it is possible for two of the
frame types (Ethernet.sub.-- II and Ethernet.sub.-- SNAP) to be
used by different protocols. It should also be noted that it is
permissible for the same frame type to be used by different
protocols on the same LAN. Since pre-scanning program 84 remains
registered with LSL 187 for all frame types, detection is possible
even for frame types for a protocol different from those already
registered by pre-scanning program 84 and is required in connection
with a configurator function described below. By this arrangement,
NIB 50 can be reconfigured by a device communicating on the network
using a protocol for which no protocol stack is loaded in NIB 50 or
a protocol/frame type combination which NIB 50 is not
pre-configured to receive.
In step S808, pre-scanning program 84 determines whether
autosensing is complete, i.e., whether all protocols for which
autosensing is to be performed have been assigned a frame type. If
not, flow returns to step S805 to monitor LAN broadcast traffic. On
the other hand, if all protocols requiring autosensing have been
assigned a frame type, flow proceeds to step S809. In step S809,
pre-scanning program 84 terminates its pre-scan operation but
remains resident in DRAM 360 to perform the configurator operation
discussed below. Pre-scanning program 84 also issues a command to
cause the required protocol stacks to be loaded. The configurator
function described below is performed before, during, and after any
autosensing.
In step S810, the newly-loaded protocol stacks register with LSL
187, as shown, for example, in FIG. 9(c). As seen there, the
IPX/SPX protocol stack registers 802.2 with LSL 187. By
registering, and as described above, IPX/SPX informs LSL 187 to
provide all frame packets matching the registered frame type (here,
802.2) to the newly-loaded protocol stack. Further, the
configurator always stays registered to all frame types. Thus, in
the example for 802.2 frame packets, any packet the IPX protocol
stack doesn't want will be passed on to the pre-scanning program
84/configurator module.
When a protocol stack is loaded, a software interrupt is performed
to obtain a table of entry points into various service routines
provided by LSL 187. Thereafter, when the protocol stack wishes to
utilize an LSL service routine, it merely performs a call to the
memory address serving as the entry point to the desired
routine.
As shown in FIG. 9(d), once a protocol stack has been loaded, it
begins to operate on the network. Specifically, whereas
pre-scanning program 84 was completely passive and did not
broadcast any network communications, protocol stacks broadcast
their associated requests. For example, IPX/SPX broadcasts its
associated SAP requests, and TCP/IP broadcasts its associated
RARP's so as to obtain its address from the nearest network
server.
[3.2 Processing Of Received Packets]
FIG. 10 is a flow diagram showing a process for receiving a packet
from LAN 1000. In step S1001, a packet is received by a network
interface chip, such as network controller 330 in an Ethernet
environment. network controller 330 determines in step S1002
whether the packet is addressed to NIB 50. Every packet transmitted
on LAN 1000 has a header including network destination information.
For example, the network destination may be the MAC address of a
specific device, i.e., a direct transmission, or the destination
may be all devices, i.e., a broadcast to hexadecimal address
FFFFFFFFFFFF.sub.H, for example. Generally, the destination address
information is processed at the hardware level, e.g., by network
controller 330, to determine if the packet is intended for
reception by NIB 50. Accordingly, packets that are not intended for
NIB 50 are never passed to the software executed on processor 300.
Rather, only packets intended for NIB 50, such as broadcast or
multicast or specifically-addressed packets, are passed on for
further software processing.
If the packet is not addressed to NIB 50, either specifically or as
part of a group (e.g., broadcast or multicast), flow returns to
step S1001 and the packet is discarded. If the packet is addressed
to NIB 50, the packet is passed to MLID 186 in step S1003. As
described above, MLID 186 is the lowest level software that
communicates with the network.
In step S1004, after MLID 186 receives a packet from network
controller 330, each of the logical boards determines if the packet
frame type is the type processed by that board. The board that
processes the matching frame type strips off the frame header and
passes the packet to LSL 187. Flow proceeds then to step S1005. In
step S1005, LSL 187 uses the board number of the logical board
which forwards the packet and the Protocol ID (PID) to route the
packet to the appropriate protocol stack, and flow advances to step
S1006. In step S1006, the protocol stack processes the packet and
routes the packet to a peripheral server, such as CPSERVER 79, for
servicing. Flow then returns to step S1001. Of course, different
packets can be at different stages of the process in FIG. 10 at the
same time.
Referring to FIG. 11, when a protocol stack wishes to transmit a
packet on LAN 1000, it does so using an Event Control Block (ECB)
1750. As shown in FIG. 11, ECB 1750 includes the following
information fields, as described in the abovementioned ODI
specification: EventServiceRoutine, StackID, BoardNumber,
ProtocolID, ImmediateAddress, DataLength, FragmentCount, and
FragmentDescriptors.
BoardNumber is the number of the logical board in MLID 186 that
handles the frame type used by the protocol stack. The logical
board to which a protocol stack is bound, i.e., to which it sends
data packets and from which it receives data packets, can be set in
a configuration file, e.g., NET.CFG. In the preferred embodiment,
since the order of logical boards is known, the board number to
which each protocol stack should be bound is also known and is hard
coded into the protocol stack software modules. Alternatively, the
protocol stack can determine the board number of the board to which
it should be bound, i.e., the board which handles the frame type
used by the protocol stack, by examining the frame type ID values
in the configuration table for each board.
Using the service routines provided by LSL 187, the protocol stack
can obtain an entry point to a service routine of MLID 186, which
is then used to obtain the locations of the configuration tables.
The protocol stack then can examine the frame type ID values from
the configuration tables to determine which board handles the frame
type used by the protocol stack. The number of that board is then
used in ECB 1750. Since LSL 187 and MLID 186 do not alter ECB 1750,
the board number does not have to be redetermined each time a
packet is sent, but instead can be set in ECB 1750 once during
initialization.
The ImmediateAddress field of ECB 1750 contains the destination
address that specifies to which node on LAN 1000 the packet should
be sent. This can be a direct, multicast, or broadcast address. A
multicast involves sending a packet to each member of a group,
instead of sending the packet to every device on the network using
a broadcast. The format of Ethernet multicast addresses differs
from that of token ring multicast addresses. Thus, in contrast. to
direct transmissions or broadcasts, multicasts require that the
protocol stack be aware of the network media type, in order to
provide the appropriate multicast address format to MLID 186. The
protocol stack can, for example, obtain the network media type, or
a specific address format for multicast use, from a configuration
file, e.g., NET.CFG, as in a conventional approach. The present
invention provides an alternative method, as discussed below.
FIG. 12 is a flow diagram illustrating a process for transmitting a
packet on LAN 1000. In step S1201, the protocol stack determines
what board number should send the packet, if necessary because the
board number is not hard coded, in the manner discussed above. In
step S1202, the protocol stack determines whether the transmission
is a multicast. If it is not a multicast, the process skips ahead
to step S1204. If the transmission is for a multicast, flow
advances to step S1203. In step S1203, the appropriate address
format for the multicast is determined. This may involve retrieving
a multicast address format from a configuration file or determining
the media type. Since the media type will not change, it need only
be determined once. Appropriate data can then be stored so that the
protocol stack knows the media type the next time a multicast is
transmitted. Flow then advances to step S1204.
In step S1204, the protocol stack forms an ECB 1750 having the
information mentioned above. Flow then advances to step S1205, in
which the protocol stack calls LSL 187 with a pointer to the memory
location of the ECB. Flow then advances to step S1206, in which LSL
187 calls the board of MLID 186 designated by the ECB. Flow then
advances to step S1207, in which the MLID board transmits the
packet on LAN 1000. Flow then advances to step S1208 to continue
with other processing.
[3.3 Dynamic Detection Of Media Type]
The present invention provides a method for dynamically detecting
the network media type so that a protocol stack can be written
generically to execute in either an Ethernet or a token ring
environment.
FIG. 13 is a flow diagram illustrating a process for dynamically
determining a media type of a local area network (LAN) to which a
network device is connected. Briefly, a network interface driver
software module is executed which is the lowest level of software
to communicate with the LAN and which handles the sending and
receiving of communication packets to and from the LAN by appending
or stripping off packet frame headers. The network interface driver
software module has one or more logical boards for processing
communication packets having different respective frame types and
has one or more configuration tables, each respectively associated
with one of the logical boards, which each include a frame type
identifying value that identifies a combination of frame type and
media type for packets processed by the corresponding logical
board. The network interface driver software module also has a
service routine which can be accessed via an entry point. One or
more protocol stack modules are executed for processing packets
that use different respective protocols, and a multiplexer software
module is executed which interfaces between the network interface
driver software module and the one or more protocol stack modules
and which routes packets from the network interface driver software
module to the respective protocol stack modules according to the
protocol used by the packets. The entry point of the network
interface driver service routine is obtained via the multiplexer
module. A location of one of the configuration tables is then
obtained via the service routine. The frame type identifying value
in the one configuration table is then read, and the network media
type is determined by comparing the frame type identifying value
read from the one configuration table to one or more values that
correspond to a predetermined media type.
More specifically, in steps S1301, S1302, and S1303, microprocessor
300 loads and executes LSL 187, MLID 186, and one or more protocol
stack modules as shown in steps S801, S802, S809, and S810 of FIG.
8. Process steps S1304 through S1307 then can be performed to
determine the media type dynamically at any point after a protocol
stack has obtained the entry points into service routines of LSL
187, either as part of the initial loading and execution of the
protocol stack or at a later time.
In step S1304, the frame type ID value is read from the
configuration table corresponding to logical board 0 in MLID 186,
then flow advances to step S1305. The frame type ID value is read
by calling a service routine of LSL 187 which provides the entry
point for a service routine of MLID 186. The service routine of
MLID 186 is then called to obtain the location, i.e., starting
memory address, of the configuration table. The frame type ID value
is then read directly from the configuration table.
In step S1305, the frame type ID value is compared to the value 5.
As shown above in Tables 1 and 2, the standard frame type ID values
are assigned in such a way that the value is unique for each
different frame type and media type. In the preferred embodiment,
when an Ethernet medium is used, the four logical boards are
arranged so that logical board 0 is the 802.3 frame type board. As
shown in Table 1, the frame type ID value for that board is 5. On
the other hand, if a token ring medium is used, the first logical
board is for a Token-Ring frame type and has a frame type ID value
of 4.
Thus, if the frame type ID value read from logical board 0 is
determined to be equal to the value 5 in step S1305, flow advances
to step S1306 which makes a determination that the media type is
Ethernet. That information may be stored in configuration file 75
or in DRAM 360. Flow then advances to step S1308 and microprocessor
300 continues with other processing.
If the frame type ID value is not equal to the value 5 in step
S1305, flow advances to step S1307 which makes a determination that
the media type is token ring. Flow then advances to step S1308 to
continue with other processing.
There are, of course, many variations on the above process. For
example, the frame type ID value for a different logical board can
be read and compared to a value other than 5. Also, if the frame
type ID value is not equal to 5 in step S1305, it can be expressly
compared to the value 4 to verify that logical board 0 is for a
token ring medium. If the frame type ID value for logical board 0
does not equal either 4 or 5, the protocol stack can recognize that
a problem exists, e.g., the logical boards are incorrectly
configured or a proprietary network that is neither Ethernet nor
token ring is being used.
Further, the frame type ID value for a logical board can be
compared to the entire set of values that a board may have for a
given media type. For example, Table 1 indicates that the frame
type ID value for boards on an Ethernet medium will be either 2, 3,
5, or 10. If a frame type ID value read from a board is not in that
set, a token ring medium can be assumed. Likewise, the frame type
ID value for boards on a token ring network will be either 4 or 11.
Thus, if the frame type ID value is not in that set, an Ethernet
medium can be assumed.
In this way, a protocol stack can determine the media type
dynamically without having any knowledge beforehand concerning the
arrangement of logical boards, and without any special interaction
with the network interface driver module. All that is necessary is
a multiplexer module and network interface driver module which
conform to the ODI specification, or which at least have an
ODI-conforming configuration table and a way to access the
information in it. Accordingly, the protocol stack can be written
generically, including code to perform steps S1304 through S1308,
and can be loaded into any network device meeting the above
conditions regardless of media type.
[3.4 Reconfiguring Frame Type Assignments/Protocols]
As mentioned above, a portion of pre-scanning program 84 provides a
so-called configurator function which allows changes to be made to
configuration information regarding which protocol stacks are
loaded and which frame type is assigned to each loaded protocol
stack.
FIGS. 14(a) and 14(b) show a flow diagram which illustrates a
process for reconfiguring frame type assignments for protocol stack
modules in a network interface device which is interfaced to a
local area network (LAN). Briefly, an initialization process is
executed which loads protocol stack modules and assigns frame types
to each of the loaded protocol stack modules based on configuration
information regarding the protocols and frame types used on the
LAN. Packets are received which include data and address
information from the LAN, and a determination is made whether a
received packet is a configuration packet by detecting whether the
packet is addressed to the NIB by using a predetermined address,
e.g., the packet is addressed to the NIB's specific assigned
address and has the correct validation stamp. In response to a
determination that the received packet is a configuration packet,
the configuration information is altered using the data in the
configuration packet. The initialization process is subsequently
reexecuted using the altered configuration information.
In more detail, in step S1401 a packet is received by LSL 187. The
packet has been routed to this point based on header information
including destination address information, which is identical in a
configuration packet to the header information in a packet
containing data to be serviced. Thus, LSL 187 cannot distinguish a
configuration packet from other packets and determines the protocol
stack to which the packet should be routed in the same manner as
for other packets. In step S1402, a determination is made whether
the appropriate protocol stack is loaded. If the protocol stack is
loaded, flow advances to step S1403 in which the packet is routed
to the appropriate protocol stack, then flow advances to step
S1404. If the protocol stack is not loaded, flow advances to step
S1408 in which the packet is routed to pre-scanning program 84. In
addition, as described below, the packet is also routed to
pre-scanning program 84 if the protocol stack declines the
packet.
In the preferred form presently described, a packet for a loaded
protocol stack is first routed to the protocol stack even when the
packet is a configuration packet. However, since the protocol stack
does not know anything about the configuration packet, it declines
it. Handling of the configuration packet then passes to
pre-scanning program 84. It is possible to modify LSL 187 to
distinguish configuration packets and avoid routing them to a
protocol stack. However, since relatively few packets are likely to
be configuration packets, it is preferable not to modify LSL 187
but instead to have a protocol stack determine whether a packet is
a configuration packet. In this way, if a protocol stack is
registered to receive the frame type used by a packet, the protocol
stack gets the first chance to accept and process the packet, and
most of the time that is what happens. Only if the protocol stack
declines the packet is it passed to the configurator.
Accordingly, in step S1404 a determination is made whether a packet
is a configuration packet by determining whether the protocol stack
will accept or decline the packet. A decision to accept or decline
the packet is made based on detection of whether address data in
the packet indicates the NIB's assigned MAC address and whether it
includes an identifying "stamp". FIG. 15(a) shows a format of a
configuration packet 1800 in the preferred embodiment. 1801
designates frame header information including the destination
address information used to route the packet over LAN 1000 to the
appropriate node, NIB 50 in this case. 1802 designates protocol
header information which includes the information used by LSL 187
to route the packet to an appropriate protocol stack. 1803
designates data which will be discussed below.
The protocol information 1802 differs in form for different
protocols. For example, an IPX/SPX packet will include address data
that designates a socket, a TCP/IP packet will include address data
that designates a port, and an AppleTalk packet will include
address data that designates a DDP type. A predetermined socket,
port, and DDP type are each reserved for designating configuration
packets. Accordingly, the determination in step S1404 of whether
the packet is a configuration packet 1800 is performed by detecting
whether the packet contains a protocol-specific "stamp" (such as a
predetermined socket for IPX/SPX, a predetermined port for TCP/IP,
or a predetermined DDP type for AppleTalk) identifying it as a
configuration packet. In other words, it is determined whether the
packet is addressed to any of the predetermined socket, port, or
DDP type. If the packet does not contain any of the predetermined
addresses, flow advances to step S1405 in which the packet data is
serviced, and then flow advances to step S1406 to continue with
other processing.
If it is determined in step S1404 that the protocol stack does not
want the packet, e.g., the packet is addressed to one of the
predetermined addresses, flow advances to step S1407 in which the
packet is routed to pre-scanning program 84. Flow then advances to
step S1412 shown in FIG. 14(b). Thus, configuration packets are
routed to pre-scanning program 84/configurator if (a) no protocol
stack is bound for the frame type used by the packet, or (b) all
protocol stacks bound to the frame type reject the packet (based on
a port, socket, DDP type, etc., to which the packet is
addressed).
As mentioned above, the packet is routed to pre-scanning program 84
in step S1408 if it is determined by LSL 187 in step S1402 that a
protocol stack is not loaded for the protocol used by the packet.
Since in the preferred embodiment pre-scanning program 84 does not
de-register frame types which may be used by a protocol for which
no frame type is assigned, as discussed above, all possible frame
types on LAN1000 are bound to a loaded protocol stack and/or
pre-scanning program 84. Accordingly, a configuration packet 1800
can be received and processed even if it is sent by a device using
a protocol and frame type for which NIB 50 has no loaded protocol
stack.
After the packet is routed to pre-scanning program 84 in step
S1408, flow advances to step S1409 in which a determination is made
whether the packet is addressed to the predetermined socket, port,
or DDP type. This step is like step S1404 discussed above. If the
packet is not addressed to one of the predetermined addresses used
to designate a configuration packet 1800, flow advances to step
S1410 in which the received frame type is assigned to a protocol as
in steps S807 through S810, and flow advances to step S1411 to
continue with other processing. If it is determined in step S1409
that the packet is a configuration packet 1800, i.e., it is
addressed to the predetermined socket, port, or DDP type, then flow
advances to step S1412.
In step S1412, a validation stamp 1804 which is part of the data
1803 of the configuration packet 1800 is checked to confirm that
the configuration packet is valid. The validation stamp 1804 is an
optional feature for added security which may be omitted. The
validation stamp is preferably a sequence of alphanumeric
characters such as an abbreviation of the software provider's name.
Alternatively, the validation stamp can be a code sequence of
characters. If the validation stamp is not correct, the process
skips ahead to step S1415 to continue with other processing. If a
correct validation stamp is present, flow proceeds to step S1413 in
which a determination is made whether the configuration packet is a
query packet 1810. FIG. 15(b) shows the format of a query packet
1810, and FIG. 15(c) shows the format of a set packet 1815. Both
query packet 1810 and set packet 1815 have a set/query field 1805
in data 1803 of the packet. This field preferably has just one bit
that is 1 if the packet is a set packet and is 0 if the packet is a
querypacket. As shown in FIG. 15(b), set/query field 1805 is the
last item in query packet 1815.
If the packet is a query packet, flow advances to step S1414 in
which a response packet 1820 is sent. FIG. 15(d) shows the format
of response packet 1820. Response packet 1820 includes frame header
information 1806, protocol data 1807, and response data 1808. Frame
header information 1806 and protocol data 1807 can be formed by
swapping source and destination data in query packet 1810, to send
response packet 1820 back to the device that sent query packet
1810. Response data 1808 indicates the protocol stacks that are
currently loaded, and the frame type assignments for each loaded
protocol stack. This data can be obtained, for example, from
configuration file 75 or from LSL 187. After sending the response
packet, flow proceeds to step S1415 to continue with other
processing. In the preferred form, a query packet is received
first, before any set packet, so that the current configuration
information can be provided to a user, e.g., the system
administrator, who wishes to change a protocol or frame type
configuration.
If the received packet is not a query packet, it is deemed to be a
set packet and flow advances to step S1416. Set packet 1815
includes configuration data 1809 as shown in FIG. 15(c).
Configuration data 1809 preferably includes an indication for each
protocol stack of whether that stack should be loaded and includes
a frame type to be used with each loaded protocol stack.
Configuration data 1809 may also include other information, such as
data identifying the media type or an IP address which is a
software defined address similar in concept to the hardware defined
MAC address. In step S1416, configuration data 1809 is used to
alter the configuration information in configuration file 75. Flow
then advances to step S1417.
In step S1417, a determination is made whether an immediate re-boot
is desired. This determination is made based on re-boot data 1811
in data 1803 of set packet 1815. Re-boot data 1811 is preferably a
one bit field which is 1 when immediate re-boot is desired and is 0
otherwise. If immediate re-boot is desired, flow advances to step
S1418 in which the initialization process of FIG. 8 is reexecuted
using the altered configuration information in configuration file
75. Flow then advances to step S1415 to continue other
processing.
If re-boot data 1811 indicates that an immediate re-boot is not
desired, flow proceeds from step S1417 to step S1415 to continue
other processing. The altered configuration information will then
be used in the initialization process the next time NIB 50 is
powered-up or re-booted. It should be noted that, in some cases,
the configuration of NIB 50 can be changed based on the altered
configuration information without executing the initialization
process. For example, if the altered configuration information
merely requires the loading of an additional protocol stack that is
not already loaded, it is possible to load that protocol stack into
DRAM without reinitializing the device.
As described above, LSL 187 sends packets to pre-scanning program
84 if any appropriate protocol stack that has been loaded declines
the packet because the packet is addressed to a predetermined
socket, port, or DDP type. Thus, pre-scanning program 84 can
receive a configuration packet at any time after it has been loaded
and registered with LSL 187, whether or not any protocol stacks
have been loaded. This means that a configuration packet can be
received and used to alter the configuration information when the
initialization process of FIG. 8 has executed only partly, for
example through step S805, and before any protocol stacks are
loaded. On the other hand, a configuration packet may be received
and processed long after the initialization process of FIG. 8 has
completed execution.
As described above, the present invention provides a configurator
feature that has the ability to handle a configuration packet
having any protocol and frame type combination, even if the network
device is not configured to send and receive packets having that
protocol/frame type combination.
FIG. 16 is a flow diagram showing a process for transmitting new
configuration information to NIB 50 from another network device,
such as computer 1500, via LAN 1000. Typically, at least one
networked computer runs software that allows it to obtain and
display information regarding other devices on the network. For
example, Novell NetWare may be running on a PC under an IPX/SPX
protocol. According to the present invention, a software program
runs on a computer and extends the functions of NetWare software.
The version of the program, called MPINIT, that runs on a DOS-based
PC using an IPX/SPX protocol is a DOS MPINIT. There are other
versions of MPINIT for other platforms. Thus, there is a UNIX
MPINIT that runs on a UNIX-based system using a TCP/IP protocol and
a Macintosh MPINIT that runs on a Macintosh-based system using an
AppleTalk protocol.
One extended function that MPINIT provides is a menu-selected
option to set or query the configuration information of a
particular network device. In step S1601 of FIG. 16, a MAC address
of a device is input along with a command to QUERY or SET the
configuration information for the designated device. This may not
be necessary for some network configurations where the NIB can
advertise its presence using a protocol and frame that the computer
is set up for. Flow then proceeds to step S1602 in which a
determination is made whether the command is a SET command. If the
command is not a SET command, flow advances to step S1603. If the
command is a SET command, flow advances to step S1607.
In step S1603, since a SET command was not detected in step S1602,
processing is performed for a QUERY command. In a preferred
embodiment, an initial query packet is sent by MPINIT without a
user's specific request, in order to present a list of current NIB
configuration information. The user may then cause a SET packet to
be issued as desired. A query packet 1810 is formed using the MAC
address input in step S1601 as the destination address information.
Flow then advances to step S1604 in which query packet 1810 is
transmitted to the designated network device, NIB 50 in this case,
via LAN 1000 using whatever protocol and frame type is in use by
computer 1500 executing MPINIT, which in the case of a DOS-based PC
is IPX/SPX over the assigned frame type. In step S1605, the process
waits until a response packet 1820 is received. When response
packet 1820 is received, flow advances to step S1606 in which the
current configuration information contained in response packet 1820
is displayed on a display device of the computer. Flow then returns
to step S1601 to await another command.
In step S1607, if a SET command is detected in step S1602, new
configuration information is input. The new configuration
information can be input by keyboard and, if current configuration
information of a designated device is being displayed in response
to a QUERY command, the new configuration information can be input
by editing the displayed information. Alternatively, the new
configuration information can be input from a configuration file in
computer 1500. After inputting the new configuration information,
flow advances to step S1608.
In step S1608, a set packet 1815 is formed using the MAC address
input in step S1601 and the new configuration information input in
step S1607. MPINIT can be configured to set re-boot data 1811 to
always request immediate re-boot by default, or a user can be
prompted by the software to input re-boot data 1811. Flow then
advances to step S1609 in which set packet 1815 is transmitted to
the designated network device with the protocol used by computer
1500 executing MPINIT. Flow then returns to step S1601 to await
another command.
As described above, pre-scanning program 84 processes packets in
all frame types allowed on LAN 1000 in the most preferred
embodiment. Accordingly, a Macintosh computer using AppleTalk can
send a configuration packet to NIB 50 even if NIB 50 only has
protocol stacks loaded for IPX/SPX and TCP/IP protocols.
Pre-scanning program 84 will receive and process the configuration
packet, and NIB 50 can be reconfigured to load an AppleTalk
protocol stack and communicate with the Macintosh computer.
Further, the present invention is not limited to use only with
peripherals. A configuration packet 1800 can also be sent to a
computer if the computer includes the appropriate software to
detect and process the configuration packet according to the
above-described process. In this manner, a system administrator's
computer can reconfigure other computers on LAN 1000 if a frame
type used for a protocol is changed.
[4. Other Embodiments]
Although a preferred form of the present invention is described
above in the context of NIB 50 for interfacing a digital copier to
LAN 1000, the present invention is applicable to other network
interface devices for interfacing other peripherals, such as
printers, scanners, and facsimile devices, to LAN 1000. For
example, the present invention can be used with the Network
Expansion Board (NEB) described in U.S. Pat. No. 5,323,393 entitled
"Method And Apparatus For Obtaining And For Controlling The Status
Of A Networked Peripheral", hereby incorporated by reference. That
patent discloses a PRESCAN module which performs autosensing of
frame types, then terminates and causes protocol stacks to load.
That PRESCAN module can be modified to perform the configurator
function described in connection with FIG. 14, if the PRESCAN
module is also modified to remain resident after completing its
pre-scanning operation.
Further, the present invention can be used with Network Expansion
Board disclosed in U.S. patent application Ser. No. 08/336,062,
entitled "Network Protocol Sensor", hereby incorporated by
reference. The PRETASK module disclosed in that application remains
resident after completing its pre-scanning operation. Therefore,
PRETASK need only be modified to perform the configurator function
described with respect to FIG. 14.
In addition, the present invention can be used with the Network
Expansion Device disclosed in U.S. patent application Ser. No.
08/489,283, filed on Jun. 9, 1995, and entitled "Network Device
Which Responds To Status Changes Of Its Installed Peripheral By
Generating A Testpage". The PRESCAN software module disclosed in
that application would require modification like the
above-mentioned PRESCAN module. Further, that device has no NVRAM.
Accordingly, both the software modules and configuration
information must be stored in EPROM.
While the present invention has been described with respect to a
particular illustrative embodiment, it is to be understood that the
invention is not limited to the above described embodiment and that
various changes and modifications may be made by those of ordinary
skill in the art without departing from the spirit and scope of the
invention.
* * * * *