Printing in Multiprotocol Network Environments

The HP JetDirect Multiprotocol Network Interface

As the widespread installation of departmental and workgroup LANs continues, it is becoming commonplace to find a mixture of computers and operating systems sharing the same physical network wiring. Where once a network may have comprised a number of homogeneous personal computers all running a single network operating system, say, Novell NetWare, today it is not unusual to find Unix and Apple Macintosh workstations and servers also sharing the network cabling.

The result is a single physical network over which computers are communicating using several different, and incompatible, network operating systems and network protocols. The computers running NetWare use Novell's SPX/IPX protocol, while Unix systems (such as HP-UX, SunOS, Solaris and SCO Unix) use the TCP/IP protocol and Apple Macintosh computers use the EtherTalk protocol. In addition, other personal computers may be using IBM's LAN Server, Microsoft's LAN Manager, Windows for Workgroups or Windows NT, all of which typically use yet another protocol, DLC/LLC. That's 10 different network operating systems using four different network protocols.

While all the equipment running on a single-protocol network will have no trouble communicating with each other, a multiprotocol network does pose a challenge when it comes to printing. A network administrator could attach a printer to each server running a different operating system, but this gets very expensive and is limited in throughput by the server's relatively slow parallel printer interface. Attaching separate printers for each network operating system directly to the network overcomes the throughput problem, but this, too, is very costly.

Printing in Multiprotocol Networks

The best solution to printing in a multiprotocol environment is a single, high-performance printer that attaches directly to the network and simultaneously communicates with several different network operating systems using the appropriate protocols. In this way, each operating system appears to have a dedicated printer, data gets to the printer at network speeds, and tremendous savings are realized by eliminating unnecessary equipment duplication.

But network printing, even in a single operating system environment, is not a straightforward proposition. Unlike a stand-alone, single-user system where a printer can be dedicated to only that computer, a network printer is required to handle several users' jobs simultaneously. As a result, some way is needed to indicate a job boundary so the printer knows when one user's print job is finished and another's begins.

If a printer is receiving jobs not only from several users but also from several operating systems, there is an additional complication. Each network operating system believes the printer is dedicated to it, and has no way of communicating with the other network operating systems using the same printer to manage the flow of print jobs. What's more, each operating system handles job boundaries in a different way. Thus the function of network traffic cop falls by default to the printer, which must determine when a job coming from one network operating system is finished so it can switch to a job from another.

The primary question then is how best to implement a printer/network-interface system capable of reliably separating the print jobs it receives simultaneously from multiple operating systems. This multiprotocol job switching capability requires a knowledge and understanding of the page description language being used -- PCL or PostScript -- to achieve the highest degree of reliability.

Building the capability to determine job boundaries into the interface card connecting the printer to the network is one possible way. But to do this, the interface card would need to examine the data stream on a byte-by-byte basis, limiting performance and reliability because the interface has no knowledge of the structure of the data stream it is receiving -- it doesn't know PCL from PostScript. That knowledge resides in the printer.

The fastest, most reliable way to determine job boundaries and switch between jobs is in the printer itself where the page description languages reside. The interface card can accept jobs from each network operating system in a manner specific to that operating system, feed multiple data streams simultaneously to the printer, and let the printer select which data stream to process, determine job boundaries and decide when to switch to another data stream. The interface card and the printer, therefore, work together to handle the servicing of print jobs from the various network operating system environments.

HP JetDirect Multiprotocol Interface

Hewlett-Packard has adopted this two-part approach to network printing. It is producing interface cards capable of interacting with multiple network operating systems and printers capable of determining job boundaries and switching among multiple data streams.

The new HP JetDirect multiprotocol interface for Ethernet LANs provides printers and other peripherals with connectivity to ten popular network operating systems: Novell NetWare; Microsoft LAN Manager, Windows for Workgroups and Windows NT; SCO Unix, SunOS, HP-UX and Solaris implementations of Unix; IBM LAN Server; and Apple EtherTalk. A Token Ring version supports five operating systems, including Novell NetWare; Microsoft LAN Manager, Windows for Workgroups and Windows NT; and IBM LAN Server. Based on a Motorola 68000 microprocessor running at 10 megahertz, the HP JetDirect interface card functions as a multichannel pipe that simultaneously delivers print job data from multiple network operating system environments to the printer.

The JetDirect card can establish connections with servers for each operating system it supports, and each system sees the JetDirect card as a dedicated peripheral. When a data packet addressed to the JetDirect card by one of the supported network operating systems is received, the interface determines from the packet header which operating system and protocol generated it. Then, through firmware contained on the JetDirect card, it accepts each print job in the manner specific to that operating system, and feeds the data stream in parallel with any others it has already established to the printer for further processing. The JetDirect card can handle up to four simultaneous data streams, one for each of the protocol stacks it supports. The HP JetDirect card for Ethernet LANs supports SPX/IPX, DLC/LLC, TCP/IP and EtherTalk, while the HP JetDirect card for Token Ring LANs supports SPX/IPX and DLC/LLC.

In the case of Unix printing, for example, the Unix print spooler first opens a standard TCP socket connection to the JetDirect card, and then transfers print data over the network to the card. When the print job is done, the print spooler closes the connection. The HP JetDirect card handles Novell NetWare print jobs differently, however. To handle Novell NetWare print jobs in Queue Server mode, the JetDirect card polls Novell NetWare print queues for pending print jobs. When found, the JetDirect card accesses the NetWare server to transfer the print data to the card using NCP (NetWare Core Protocols) to complete the job.

Although the JetDirect card is capable of receiving the information simultaneously from several different operating systems and separating it into individual data streams, it still must have a way to pass this information on to the printer or other peripheral it's installed in. The interface between the JetDirect card and the peripheral, therefore, must be capable of handling simultaneous data streams, too.

Modular Input/Output

The HP JetDirect interface card is modular. That is, the same JetDirect card can be installed in a number of different HP peripherals to connect them to a network. A modular interface provides much greater flexibility since a single interface card can be used by many kinds of peripherals to establish a particular kind of host connectivity (like IEEE-488 or Ethernet).

To ensure that all the interface cards can work with all the peripherals, HP developed an interface specification that clearly defines the boundary between the two. Over the years, this specification has evolved, providing greater communications capabilities between the interface card and the peripheral. For example, the first specification, called Extended I/O (XIO), provided a simple modular interface to fulfill the need for direct LAN connectivity for LaserJet II and III printers. It enabled a single stream of data to pass from the interface to the peripheral.

With the introduction of the LaserJet IIISi printer in early 1991, a new Modular I/O (MIO) specification was developed. It was designed to provide bidirectional communication between the peripheral and the interface, while also increasing data throughput to handle the higher printing volumes encountered in network environments. As a result, the printer's front panel could now be used to configure the interface card, and the interface card could report problems it was experiencing through the printer's front panel display or print them out.

The advent of multiprotocol environments and the need for even greater performance to handle higher-resolution graphics prompted HP to enhance the MIO specification. While a full page graphic at 300 dot-per-inch resolution required about one megabyte of data, at 600 dots per inch, this figure jumps to four megabytes. The latest specification, called MIO 5.1, has the increased throughput to handle higher-resolution graphics, and for the first time provides the ability to simultaneously pass multiple data streams between the interface card and the peripheral, a critical requirement for printing in a multiprotocol environment.

Putting it All Together

At this point, two key components are in place. The HP JetDirect card is capable of receiving and separating multiple data streams, and the MIO interface is capable of delivering them to the peripheral. All that's required now is a peripheral that can accept them and switch among them as needed. That requirement is met by the new HP LaserJet 4Si printer.

The HP LaserJet 4Si and the HP JetDirect card work together to handle the servicing of print jobs from the various network operating systems. The LaserJet 4Si has considerable knowledge about where job boundaries occur in the incoming data streams and when it is most appropriate to switch to another data stream. For example, PostScript data streams contain job boundary information, as do the job boundary markers in printer job language (PJL). In addition to this internally generated job boundary information, the LaserJet 4Si is provided with job boundary indications from the JetDirect card to further enhance its job switching algorithm. The JetDirect card can detect network operating system generated job boundaries, such as those provided by NetWare and EtherTalk print service protocols, as well as the connection events encountered while processing Unix jobs.

While the LaserJet 4Si is processing and printing a job from a data stream from one network operating system, the JetDirect card still accepts print jobs from the other operating systems, passing the initial portions of these job data streams to the printer where it is buffered. Thus, while printing one job, the LaserJet 4Si will also have stored some data from other operating systems' print jobs that are waiting for printing. When the LaserJet 4Si determines is should switch, it selects another data stream from among those waiting and starts processing it. This causes the new data stream to reopen and the remainder of the print job data to commence flowing into the printer through the JetDirect card.

SNMP and Remote Status Feedback

The MIO channel is bidirectional, enabling not only print job data to flow into the printer from the network, but printer and job status information to be transmitted back over the network. Thus, PostScript status, PJL status readback responses, PJL USTATUS and other information about the print jobs being handled can be directed to the network operating system that generated the data via the JetDirect card in the manner required by the operating system.

But HP has taken advantage of this bidirectional capability to also provide a way to remotely view the status of the attached peripheral, as well as configure it, thus enabling the peripheral to be treated like any other device on the network. The JetDirect card makes this status information available through several mechanisms: SNMP and RCFG protocols, the NWCARE utility, PAP status and the SYSLOGservice in Unix.

The HP JetDirect card contains an SNMP agent accessible to network operating systems using either IPX (NetWare), UDP/IP (Unix) or 802.2 (LAN Manager, LAN Server, Windows). The card supports MIB-2, the standard TCP/IP management information base, and also implements a printer-specific MIB that provides access to peripheral status and identification information, per-protocol configuration information and per-protocol statistics.

For Novell NetWare networks, the HP JetDirect card can be configured using the RCFG (remote configuration) protocol over SPX. This protocol is also used by HP's JetAdmin and JetPrint utilities to obtain status information from the JetDirect card and configure it. The card also provides support for portions of the NetWare Care protocol.

AppleTalk places additional requirements on the interface card/peripheral system, requiring it to provide peripheral name and type support using the AppleTalk Name Binding Protocol, ASCII status support and job boundary support. MIO supports this extended functionality, but it is still up to the individual interface cards and peripherals to use it. The JetDirect card does support the AppleTalk PAP printer status string (based on the current status of the printer) to EtherTalk nodes via the PAP protocol. The peripheral, however, is responsible for providing the interface card with updated device and job name status after either changes, as well as the peripheral name and type support using the AppleTalk Name Binding Protocol. The HP LaserJet 4Si does provide this information.

Finally, the HP JetDirect card reports changes in peripheral status to Unix hosts using SYSLOG messages and the SYSLOG server protocol.

Special Support for NetWare and Windows

The HP JetDirect network interface ships with powerful software utilities for networks using Novell NetWare or Microsoft Windows for Workgroups or Windows NT. The HP JetAdmin utility lets NetWare network administrators remotely configure, monitor and manage all HP JetDirect connected printers, while the HP JetPrint utility allows NetWare clients running Windows 3.1 to easily select network printers, automatically install updated Windows printer drivers and obtain remote printer and job status. The HP Monitor utility provides Windows for Workgroup users with a mechanism for retrieving remote status information from a network printer, in addition to installing and configuring a JetDirect-connected printer. The standard Windows NT Print Manager will be all the software necessary to monitor, install and configure an HP network printer/JetDirect connection on a Windows NT network.

These utilities take advantage of the standard SNMP MIB contained on the JetDirect interface card. The HP JetAdmin and JetPrint utilities use both the SNMP protocol and RCFG remote configuration protocol over the SPX/IPX protocol stack to provide remote control and status across the network. The Monitor utility for Windows for Workgroups and the Print Manager utility for Windows NT use the SNMP protocol over the DLC/LLC protocol stack to provide remote status information across the network.

Setting the Standard

HP pioneered the direct connection of printers and other peripherals directly to networks. The HP JetDirect card's concurrent support for multiple network operating systems, SNMP network management and status, increased performance and printer location flexibility at a price considerably less than HP's first-generation products set a new price/performance standard for connecting HP LaserJet printers and other HP peripherals directly to a network.

# # #