Preboot Execution Environment

From Wikipedia, the free encyclopedia

The Preboot eXecution Environment (PXE, aka Pre-Execution Environment, or 'pixie') is an environment to boot computers using a network interface independently of available data storage devices (like hard disks) or installed operating systems.

For a high-level overview of network booting, see Network booting.

PXE was introduced as part of the Wired for Management framework by Intel and is described in the specification (v2.1) published by Intel and Systemsoft on September 20, 1999. It makes use of several network protocols like IP, UDP, DHCP and TFTP and of concepts like GUID/UUID and Universal Network Device Interface and extends the firmware of the PXE client (the computer to be bootstrapped via PXE) with a set of predefined APIs.

The term PXE client only refers to the role that the machine takes in the PXE boot process. A PXE client can be a server, desktop, laptop or any other machine that is equipped with a PXE boot code.

Contents

[edit] Chain

The firmware tries to locate a PXE redirection service (Proxy DHCP) in order to receive information about available PXE boot servers. After parsing the answer, the firmware will ask an appropriate boot server for the file path of a network bootstrap program (NBP), download it into the computer's RAM using TFTP, possibly verify, and finally execute it. If only one NBP is used among all PXE Clients, it could be downloaded using BOOTP without any need of a proxy DHCP or boot server.

[edit] Availability

PXE was designed to be applicable to many system architectures. The v2.1 specification assigns architecture identifiers to six system types, including ones for the IA64 Itanium architecture and Alpha architecture. However the specification only completely covers Intel's 32 Bit computer architecture (IA-32). Intel included PXE in the Extensible Firmware Interface for its IA-64, creating a de facto standard with the implementation.

[edit] PXE Client/Server Protocol

The PXE protocol is approximately a combination of DHCP and TFTP, albeit with subtle modifications to both. DHCP is used to locate the appropriate boot server or servers, with TFTP used to download the initial bootstrap program and additional files.

To initiate a PXE bootstrap session the PXE firmware broadcasts a DHCPDISCOVER packet extended with PXE-specific options (extended DHCPDISCOVER) to port 67/UDP (DHCP server port). The PXE options identify the firmware as capable of PXE, but they will be ignored by standard DHCP servers. If the firmware receives DHCPOFFERs from such servers, it may configure itself by requesting one of the offered configurations.

[edit] Proxy DHCP

If a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies by broadcasting a DHCPOFFER packet extended with PXE-specific options (extended DHCPOFFER) to port 68/UDP (DHCP client port). This packet has to be broadcast, since most PXE clients will configure themselves by DHCP and cannot provide their IP address in the extended DHCPDISCOVER. Therefore the client is identified by its GUID/UUID.

An extended DHCPOFFER contains mainly:

  • a PXE Discovery Control field to decide whether Multicasting, Broadcasting or Unicasting is to be used for contacting PXE boot servers
  • a list of IP addresses of each available PXE Boot Server Type
  • a PXE Boot Menu with each entry representing a PXE Boot Server Type
  • a PXE Boot Prompt telling the user to press <F8> to see the boot menu
  • a timeout to launch the first boot menu entry if it expires.

The Proxy DHCP service may also be run on the same host as the standard DHCP service. Since both services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs. The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a Proxy DHCP on the same host, port 4011/UDP.

[edit] Boot Server

To contact any PXE Boot Server the firmware must have an IP address and has to consider all information from exactly one extended DHCPOFFER. After choosing an appropriate PXE Boot Server Type the firmware multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet mainly contains the PXE Boot Server Type and the PXE Boot Layer, allowing to run many boot server types with one boot server daemon (or 'program'). The extended DHCPREQUEST may also be a DHCPINFORM.

If a PXE Boot Server receives an extended DHCPREQUEST as described above and if the boot server is configured for the requested PXE Boot Server Type and client architecture, it must respond by sending back an extended DHCPACK - a DHCPACK-packet extended with PXE-specific options - to the extended DHCPREQUEST's source port.

An extended DHCPACK contains mainly:

  • the complete file path to download the NBP via TFTP.
  • PXE Boot Server Type and PXE Boot Layer the boot server answered to
  • the multicast TFTP configuration, if MTFTP as described in the PXE specification should be used.

A PXE Boot Server as described in version 2.1 of the PXE specification should support the Boot Integrity Services (BIS) as described in the BIS specification v1.0 published by Intel. The BIS allow a PXE Client to verify downloaded NBPs using a checksum file which is downloaded from the same boot server as the NBP was. To get the file path of this credentials file another exchange of extended DHCPREQUEST and extended DHCPACK is required.

[edit] Network Bootstrap Program

After receiving the requested extended DHCPACK, the Network Bootstrap Program is downloaded into the RAM and if it was verified or verification was not required, the NBP will be executed. It has access to the APIs of the PXE firmware extension (Pre-boot, UDP, TFTP, UNDI). Its functions or tasks are not described in the PXE specification.

[edit] Integration

The PXE Client/Server Protocol was designed so:

  • it can be used in the same network as an existing DHCP environment without interference
  • it can be integrated completely into standard DHCP services
  • it can be easily extended at the most important points without a call for papers
  • every service (DHCP, Proxy DHCP, Boot Server) can be implemented standalone or in any combination of them.

Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so you can get a PC PXE-capable by installing a NIC that provides a PXE Option ROM.

The design goal of utilizing existing DHCP and TFTP servers cannot be achieved in a strictly conforming implementation. Some aspects of the PXE protocol require that the DHCP and TFTP servers be modified and communicate. One specific example is using multicast, where DHCP packets provide the multicast group information rather than an opening RFC-2090 multicast TFTP exchange. The impact of this is minimal as the most common PXE client implementation (written by Intel and provided at no cost as a linkable IA32 binary module) interoperates with a combination of isolated DHCP and unicast TFTP servers.

[edit] See also

[edit] References

[edit] Resources

Specifications, RFCs and other documents about PXE:

[edit] External links