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:
- Diskette boot over the LAN.
- Boot over the LAN from the hard drive.
This feature requires no re-partitioning of the hard drive,
in most cases.
- The ability to override the burned-in MAC address.
- The choice, at boot time, to boot from the network or the
hard drive.
- Does not require BIOS level changes to implement.
- 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.
Dennis@TheFrontgate.com
|
