System for User Registering an Address Resolution Routine to Provide Address Resolution Procedure Which Is Used by Data Link Provider Interface for Resolving Address Conflicts

1. Field of the Invention

The present invention relates to information handling systems, and more particularly to information systems including networked stations each having a data link provider interface.

2. Prior Art

Prior art data link provider interface (DLPI) drivers were designed to operate with a single network interface, such as, token ring, FDDI, ethernet, etc. This limited flexibility and required that the interface drivers be modified for each different protocol with which the DLPI operated.

Therefore, it is a primary object of the present invention to operate a network connected DLPI with a ubiquitous driver capable of interfacing with a number of different protocols.

Accordingly, an information handling system includes a number of stations connected in a network configuration, each station including a processor, a storage and an I/O controller, where the processor operates under control of an operating system control program which is divided into a user (application) space and a kernel (system) space, the kernel may include a protocol layer interfacing the user application to a DLPI in the kernel, a DLPI which interfaces between the protocol module and a device driver interface, a device driver and a hardware device for connecting the station to the network. When data is to be received by a station from the network, the following steps are performed in the DLPI: recognize the network interface type (FDDI, Ethernet, Token Ring, etc.); recognize the protocol being used; format data according to the protocol; transmit to protocol module if address resolution is not required; if address resolution is required, test to determine if the protocol address resolution routine is registered; if registered, transmit data to protocol module; if not registered, call the default address resolution routine to resolve address and then transmit data to protocol module. When data is to be transmitted from a station to the network, the following steps are performed in the DLPI: recognize the network interface type (FDDI, Ethernet, Token Ring, etc.); recognize the protocol being used; test to determine if data is in a registered format; if not, call the default format routine, if yes, test for registered address resolution routine; if not registered, call the default address resolution routine; if registered, call the registered address resolution routine; and call the device driver to output the data to be transmitted to the network.

It is an advantage of the present invention that a network connected station can communicate with many different communications protocols without modification of DLPI code.

FIG. 1 is a block diagram of a communications network embodying the present invention;

FIG. 2 is a block diagram of major elements of a network connected station of FIG. 1;

FIG. 3 is a block diagram of interconnection of components of control software according to the present invention;

FIG. 4 is a flow diagram of the method of the present invention with respect to receiving data from the network; and

Fig. 5 is a flow diagram of the method of the present invention with respect to transmitting data from a station to the network.

Referring now to FIG. 1, a communications network embodying the present invention will be described.

An information handling system 100 includes a communications network 102 having a number of user stations 104 connected to network 102 for transmitting and receiving information between stations 104.

Network 102 may be implemented by any well known network technology, from an ethernet LAN (local area network) to the Internet.

Referring now to FIG. 2, stations 104 will be further described.

Each station 104 includes a processor 202, a storage 204, an I/O controller 208, and one or more communications adapters 210. An internal bus 206 connects the processor 202, the storage 204 and an I/O controller 208, to communicate instructions, addresses and data between the processor 202, the storage 204 and the I/O controller 208. I/O controller 208 is connected to the one or more communications adapters 210, each of which is connected to network 102. Each of the elements of station 104 referenced with respect to FIG. 2 is well known in the art and may be readily implemented by a number of commercially available devices. The operating system 300 is stored in an internal storage 220 in processor 202 during execution.

Referring now to FIG. 3, the operating system 300 controlling station 104 will be further described.

Application program interface 302 interfaces the user space libraries 304 and the streams kernel framework space 306. User space 304 is under control of user application programs and the kernel space is under the control of operating system 300. A Data Link Services Unit (DLS) 308 interfaces the protocols used in application program interface 302 and the DLPI 310. DLPI 310 is the interface between the DLS 308 and the device driver interface 312. Device driver interface 312 drives the physical adapter 314.

The DLPI 310 will now be described in greater detail. DLPI 310 supports Common Data Link Interface (CDLI) based network interfaces in a generic manner. This support is enabled by allowing the DLS 308 to specify the particular packet format necessary for the transmission medium over which the stream is created. Using an I/O Control (IOCTL) streams message, the DLS 308 can specify the packet format. A helpers structure and an output bundle structure is defined as follows:

If no format is specified, a default format PROTO is used. The packet formats are defined in an `include` file with the following format definitions:

PROTO DLS does not supply link level headers, DLPI fills in the link level headers, SNAP is not used. SNAP is an acronym for Sub-Network Access Protocol.

PROTO SNAP DLS does not supply link level headers, DLPI fills in the link level headers, including SNAP.

INCLUDE LLC DLS supplies LLC header. DLPI fills in the MAC header.

INCLUDE MAC DLS supplies all headers.

The DLS 308 is allowed one packet format specification per stream. This packet format should be specified after `attach` and before `bind` to avoid errors.

The DLS 308 communicates with the DLPI 310 via primitive commands defined in the UNIX International specifications OSI Work Group Version 2. For a primitive command identified as DL.sub.-- UNITDATA.sub.-- IND, the DLPI 310 will provide header information in the dl.sub.-- unitdata.sub.-- ind.sub.-- t structure. If the packet format specified is PROTO or PROTO.sub.--v SNAP, the MAC (machine access control) and LLC (Logical level control) (See IEEE Standard 802.2 Information Processing Systems-LAN Part 2 Logical level controls, which is incorporated by reference herein) are included in the DLPI header, and the data portions of the message will contain only data. If the packet format is PROTO, the DLPI header includes the MAC and LLC without the SNAP. If the packet format is PROTO.sub.-- SNAP, the DLPI header includes the MAC, LLC, and SNAP. If the packet format specified is INCLUDE.sub.-- LLC or INCLUDE.sub.-- MAC, the DLPI header will contain only the destination and source addresses. If the packet format is INCLUDE.sub.-- LLC, only the LLC will be placed in the data portion of the message. If the packet format is INCLUDE.sub.-- MAC, the MAC and LLC are both placed in the data portion of the message. Thus, the DLS 308 must have knowledge of the MAC header and LLC architecture for that interface in order to retrieve the MAC header and LLC from the data portion of the message.

For the DL.sub.-- UNITDATAKREQ primitive, if the DLS 308 had specified either the PROTO, PROTO.sub.-- SNAP or INCLUDE.sub.-- LLC formats, the DLS 308 must provide the destination address and an optional DSAP (Destination Service Access Pointer) in the DLPI header. If the DLS 308 does not specify the DSAP, the DSAP specified at bind time will be used. If the DLS 308 specifies the INCLUDE.sub.-- LLC packet format, the DLS 308 must include only the LLC in the data portion. If the DLS 308 specifies the INCLUDE.sub.-- MAC packet format, the DLS 308 must provide full MAC header including the LLC in the data portion of the message.

The DLS user specifies the packet format via the STREAMS I.sub.-- STR IOCTL system call.

The following is a sample routine to specify packet format:

Address Resolution

The CLDI has been improved to allow users to configure a network demultiplexer to use specific address routines. This capability improves the performance of the DLPI.

The CLDI network services keeps track of the MAC level routing information. When a packet comes into the network services demultiplexer, the demultiplexer address resolution routine stores the routing information for token ring and FDDI. Address resolution routines are operating system kernel extensions and are registered with the demultiplexer. Thus, users can supply their own address resolution routines without changes to the operating system.

In order for the DLPI 310 to generically support all interface types, the DLPI has been implemented to allow the DLS 308 the capability of specifying address resolution routines.

The DLS 308 can provide an address resolution procedure for input and output using the STREAMS I.sub.-- STR, or the user can rely on the system default address resolution routines. The IBM AIX operating system provides default address resolution routines that are interface specific.

The DLPI 310 calls the input address resolution routine with a pointer to the MAC header (and optionally to the LLC header) and a pointer to an MBUF structure containing data. The contents of the data depend on which packet format was specified by the user.

The DLPI assigns the destination address to key.sub.-- 2 .sub.-- find and copies the packet format and bind time LLC into a helpers structure. If the user has provided a different DSAP/type, than what was set at bind time, then the DLPI copies those values into helpers. The DLPI then calls the output address resolution routine with a pointer to an output bundle structure, an MBUF structure, and an NDD structure. It is the output resolution routine's responsibility to complete the MAC header and call NDDIoutput.

The following routine is a sample routine to specify the input and/or output address resolution routine.

Referring now to FIG. 4, the method of the present invention with respect to receiving data from the network will be described.

At DLS Open 402, the user may define a protocol. The DLS 308 then defines a data packet format and register an address resolution routine.

At some later time when data is to be received by station 104, operating system 300 must recognize an interface type at step 404, recognize the protocol of the information to be received at step 406 and format the data according to the recognized protocol at step 408. The data is then transmitted to the DLS 308 step 410, and concurrently, a test is made to determine whether the protocol address resolution is registered in step 412. If the address resolution routine has been registered at the initialization step 402, the registered address resolution routine is called in step 414 and address resolution proceeds accordingly. If the address resolution routine has not been registered, the default address resolution routine specified by the operating system 300 is called in step 416 and address resolution proceeds accordingly.

Referring now to FIG. 5, the method according to the present invention with respect to transmitting data from a station 104 to network 102 will be further described.

As described above with respect to FIG. 4, at DLS Open time, a protocol is defined and may be registered. A packet format is defined and an address resolution routine may be registered at step 502. Note that step 402 and step 502 are basically the same.

At some later time, when station 104 is to transmit information to another station 104 across network 102, the following steps must be executed. The interface type must be recognized at step 504 and the DLS 308 must be recognized at step 506. Next, the format must be recognized at step 508. Then a test is made to determine if the address resolution routine is registered at step 510. If the address resolution routine is registered, the address resolution routine is called at step 512 to fill in the header information. Next, the device driver is called at step 514 to output the information to be transmitted to network 102. If the address resolution routine is not registered as indicated in step 510, the default address resolution routine is called at step 518 to fill in header information and then again device driver is called in step 514 as above.

Although the invention has been described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various modifications and alterations may be made without departing from the spirit or scope of the invention which is defined in the appended claims.