Network Boot Protocols.
As mentioned last time, now we’re talking PXE. Well, that and all the other Network Boot Protocols.
There are several types of protocols that form the network boot. The most common form is Preboot Execution Environment (PXE). Remote Program Load (RPL) is older, but still common. SAN and EFI are emerging technologies. Each will be covered, with others like EFI being last since they are close relatives of the PXE.
PXE is based on several existing IPv4 protocols, including BOOTP/DHCP and TFTP. The development of the specification was initiated by Intel Corporation‘s Intel Architectural Labs, along with a number of third party contributors. Called IAL for short, this lab is a think tank of new technologies. The specification for PXE has through several revisions since its inception. The earliest widely deployed version was 0.99, and was originally developed to run in conjunction with the LANDesk product. The current version is revision 2.1. Since the PXE group inside IAL has moved onto EFI development, this will most likely be the last revision of the specification, at least for 16-bit IPv4 environments. Work is currently underway to extend the DHCPv6 protocol to support remote boot protocols such as PXE, but it is expected this will be for the UEFI and similar environments and not for legacy BIOS implementations.
At its core, there are two parts to the PXE image. The base code handles the TCP/IP, DHCP and other protocols, while the Universal Network Driver Interface or UNDI does the hardware work. The figure below shows the slices of the image.
Initializing Intel(R) Boot Agent Version FE v4.2.03
PXE 2.1 Build 083 (WfM 2.0)
A typical boot agent running PXE will show a sign-on message that will look something like this. This particular sign-on displays all you would need to know about the PXE version information. This particular version tells its from the last IAL-released build (083), and is the most current specification (2.1).
Once the boot agent is running, a stronger copyright message comes up, with the TCP/IP information from the DHCP transactions as well as the Media Access Control address for the hardware that the PXE is running on.
Intel(R) Boot Agent Version FE v4.2.03
Copyright (C) 1997-2010, Intel Corporation
CLIENT MAC ADDR 00AA00123456
CLIENT IP: 184.108.40.206 MASK 255.255.255.0 DHCP IP: 220.127.116.11
IBM* originally developed Remote Program Load (RPL) for its Token Ring adapters. Novell* later added NetWare* support for it and extended it to support Ethernet adapters as well.
The Intel RPL option ROM code is based on the DOS Open Data-Link Interface (DOSODI) specification. RPL is simpler than the PXE specification but is also less flexible; for example, it does not support routing boot requests between networks It does have a smaller transaction profile on the network, using just 4 frames before starting the download. The first frame is a directed packet to a multicast address supported by any server that supports the RPL format. The bootstrap code that is loaded from a NetWare server must use the DOSODI interface to talk to the driver and is typically limited to only booting from NetWare servers. Some very old versions of Windows server software also supported the original IBM-style RPL but it was difficult to configure and still had the limitations of the RPL protocol itself. RPL is pretty much done now, but it’s still worth talking about.
Extensible Firmware Interface is a new technology initiative from the same IAL that made PXE. EFI is a BIOS replacement technology that boots the system directly into protected mode. This allows for memory mapping of devices as well as the full use of the 32-bit address space. The legacy PXE/RPL environment runs the CPU in what’s known as real mode, which limits the address space to 1MB (as in the original IBM PC) and requires I/O mapping of the LAN hardware. The main goal of EFI is to make the system preboot environment as similar to the operating system as possible. Since the base code part of the boot agent is hardware-independent, it was decided to include the base code in the EFI network protocol stack. This way the only part that is truly variable, the network interface hardware, would need to bring a driver. The hardware interface is conceptually similar to the 16-bit UNDI driver, and is also referred to as an UNDI driver in the UEFI nomenclature.
iSCSIBoot allows for a remote network-attached iSCSI disk to be booted from over the network. It mimics a normal SCSI option ROM, but instead of using a local device, it uses information stored on-board to connect to the network-attached storage. This on-board information must be configured before use, so unlike PXE which can operate almost straight out of the box, it needs some extra configuration before it can be used.
This doesn’t even cover some of the other implementations such as EtherBoot, and others. Maybe we’ll save that for another post.
Time for the review.
1) Intel has created and currently supports a variety of network boot technologies
2) PXE, iSCSI and EFI are all currently supported
3) Thanks for using wired Intel® Ethernet products