Next Meeting: Sat, TBD
Meeting Directions

Be a Member


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Mr. Know-It-All



Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats


Past Presentations



Contact SCOUG

Copyright SCOUG

warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

SCOUG was there!

Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
WSoD Remote Client Connection & Pre-Execution Services
Dennis Sposato, IBM Corporation

I. Introduction

Over the past few years, our industry has been experimenting with various types of "thin client" machines. The major appeal of thin client machines, is in the area of centralized administration. While it's true that thinner systems can reduce the cost of hardware ownership by eliminating hard drives, the true cost savings is in lower administration. In fact, most so called thin clients have hard drives as well as floppies, and are not very thin at all. The main feature of this concept, is the ability to boot a machine directly from a Server. Up to now, in order to boot from the network, an additional piece of hardware was required. This new hardware is an additional EPROM that can be added to Network Interface Cards (NICs). These chips are in two forms, the Remote (Initial) Program Load (RPL or RIPL) or the Pre-Execution Environment (PXE) chips. The difference in the two is that RIPL uses IEEE 802.2 technology and PXE is used in TCP/IP environments. Having to upgrade legacy NICs to boot over the LAN, causes additional administrative problems instead of reducing them. A technician must be sent to each machine to replace older cards. The BIOS settings in many machines must be set to boot from the network as the first bootable device. Each machine will have a unique NIC hardware address, known as the Media Access Control (MAC) address, that must be controlled. The MAC address is how the server identifies the client for boot purposes. These things all contribute to increase the cost of ownership instead of lowering it.

After looking closely at the problems mentioned above and gathering a wish list of features we thought would have interest to WSoD users, the members of IBM's Rapid Deployment Team (RDT), designed a system we call "Pre-Execution Services". These are services that execute in the pre-boot environment, without having any dependencies on an operating system.

II. Pre-Execution Services

A. Remote Client Connection (Boot).

The flagship service of PE Services is "The Work Space on Demand Feature for Remote Client Connection", which we call Remote Client Boot (RCB). This service, allows a client PC to boot over the network without the hardware requirement of a RIPL/PXE chip on the NIC. This can eliminate much of the difficulty in implementation and rollout of a WSoD solution. Remote Boot has the following capabilities:

  1. Diskette boot over the LAN.
  2. Boot over the LAN from the hard drive. This feature requires no re-partitioning of the hard drive, in most cases.
  3. The ability to override the burned-in MAC address.
  4. The choice, at boot time, to boot from the network or the hard drive.
  5. Does not require BIOS level changes to implement.
  6. A administrator defined boot menu directing the client to boot from various sources, ie; Main Server, Backup Server, Local drive, etc.

In many ways, Remote Boot is superior to the use of an EPROM. The only disadvantage is the fact that it cannot be used in a completely diskless system.

B. Pre-Execution Logon.

Pre Execution Logon (PEL) allows a server in a LAN environment to validate a user's ID and Password prior to booting a client system. When the client system is started, PEL will present a logon screen to the user. The logon information will be sent to a server application that will validate the information and either allow a boot, on the client, or not. In addition, in a RIPL/PXE boot environment, PEL can provide a specific system "personality" to the user regardless of which physical client machine he is using.

PEL augments LAN system security by preventing client systems from booting when the user is unknown to the server. Other security systems require an operating system to be loaded in the client machine before a logon can be started. PEL reverses this order, allowing the logon to precede the loading of an operating system. PEL can also provide specific work station environments to client machines, when used in a RIPL/PXE environment, based on user ID. For example, if a user is a bank teller, anytime he boots a system, regardless of which physical system it is, he would receive a "tellers" system. If the user is recognized as an administrator, he would receive an administrator desktop, etc.

C. Dynamic MAC Allocation and Configuration (DMAC)

In the server-managed client environment, there currently does not exist a way to automatically assign and configure a client's MAC address. The client's MAC address is the key factor that determines many characteristics of the boot process. For example, what server to boot from, what operating system to boot, client's configuration, etc. DMAC will provide an automatic way of configuring and distributing a Locally Administered Address (LAA) thus providing a seamless solution in dynamically changing a client's boot environment.

This solution provides greater flexibility, control and automation than any solution that exists today. The client machine would send out a DMAC Discovery Frame. The server's DMAC process, would analyze the Discovery Frame. Several options would exist at this point. For example, the server might detect that this is the first time the client machine has been booted and it will run a "Initialization" script. Another scenario would be that the DMAC process analyzes the frame, queries specific servers that can handle the boot request and sends a specific LAA to the client. From the end user's perspective, no intervention is required and from the system administrator's perspective, the client's boot environment can be centrally controlled and dynamically changed.

III. Technical Considerations

The delivery system for all pre-execution services including RCB, is a small collection of self supporting, self loading, Intel 80x86 Real Mode architecture, programs, that provide limited emulation of DOS operating system functionality, such that Media Access Control (MAC) device drivers can execute, according to the 3Com/Microsoft LAN Manager Network Driver Interface Specification (NDIS).

The rest of these comments will concentrate on RCB as this service is currently available. While the other PE Services are still in development.

Two of the RCB modules are parameter driven through the use of initialization (.INI) files. The basic purpose of these files, is to tell RCB which modules to load and in what order.

The LAN conversational components of RCB, that is, the modules that "talk" over the LAN, are located in the highest part of a machine's real memory. Their task is to conduct a very brief conversation with a server. This dialog consists of only two messages from RCB. They are; "Find" and "Get File". RCB sends the Find message repeatedly, until a network server recognizes it. The server sends a "Found" message back to RCB, who. in turn, sends the Get File message to the server. This file is commonly called RIPLBOOT.SYS. Upon receipt of this message, the server sends a stream of file segments to RCB. When the last segment of this file has been processed, RCB then gives it control at an entry point dictated by the last segment message. At this point, RCB's job is done. and RIPLBOOT.SYS is free to execute in a completely pristine environment.

A key element in RCB is the RIPL Message Formatter (RIPLMF). This is a program that was developed as a hybrid application program and NDIS protocol device driver. It follows the NDIS spec in its dealings with both PROTMAN and the MAC driver. RIPLMF's relationship to these two other programs is that of a protocol driver, however its real task is to "format" messages and present them to the MAC for delivery "on the wire". Since the other drivers must be made to believe they are working in an NDIS environment, the MF also does some emulation of his own. "BindAndStart" and "InitiateBind", are two areas in which this emulation performed. According to NDIS, a protocol driver must be bound to a MAC driver. Therefore MF must bind to the MAC such that the MAC cannot tell the difference between the MF or a DOS NDIS protocol driver.

Once bound together, the MF enters into a conversation with the MAC. This dialog is very simple in that, there are only two outgoing messages the MF asks the MAC to send. They are "Find" and "GetFile". The find is replied to by a "Found" from the server. Once the MF knows the client system has been found it sends out the getfile message. The server responds by sending the RIPLBOOT.SYS file to the client. When all segments of RIPLBOOT.SYS have been received, MF resets any vectors that may have been used by RCP and the other drivers, and gives the system over to RIPLBOOT.SYS. At this point no components of RCP are required, nor can they be found in the system.

The find/found dialog is based on an address that NDIS calls the Permanent Station Address. This address, which is hard wired into the NIC itself, becomes part of the outgoing message and this is the field the server uses to decide which RIPLBOOT image to send to the client. RCP, through the use of the RCP.INI file, allows the user to specify a different Station Address to the MAC. The use of this feature of RCB, could prove to be superior to the RIPL chip in that the user can select which environment to download from the server. For example, WsoD can be booted one time and JavaOS the next. The RIPL chip, of course, offers no such capability and must use the Permanent Station Address in its communication with the LAN.

IV. Conclusion

PE Services has proven that it can be used to boot WsoD without a RIPL chip. This has been done on a limited set of NICs, but there is no reason to believe that it cannot accommodate many additional cards. It is also a superior technology to a RIPL chip, in that selectability can be added which is not supported by the hardware solution. As the potential of the Pre-Execution Environment becomes realized, PE Services can be used to add more functionality than hardware, without the overhead of an operating system.

Send questions or comments to: Dennis Sposato, IBM Austin. (512) 823-3608.