Вы находитесь на странице: 1из 7

TENTANG PXE

Preboot Execution Environment


From Wikipedia, the free encyclopedia

A high-level PXE overview

In computing, the Preboot eXecution Environment (PXE, sometimes pronounced as pixie[1])


specification describes a standardized client-server environment that boots a software assembly,
retrieved from a network, on PXE-enabled clients. On the client side it requires only a PXE-
capable network interface controller (NIC), and uses a small set of industry-standard network
protocols such as DHCP and TFTP.

The concept behind the PXE originated in the early days of protocols like BOOTP/DHCP/TFTP,
and as of 2015 it forms part of the Unified Extensible Firmware Interface (UEFI) standard. In
modern data centers, PXE is the most frequent choice[2] for operating system booting, installation
and deployment.

Contents
1 Overview
2 Details
3 Integration
4 Availability
5 Acceptance
6 Sibling environments
7 Descendant environments
8 IETF standards documentation
9 See also
10 References
11 External links
Overview
Since the beginning of computer networks, there has been a persistent need for client systems
which can boot appropriate software images, with appropriate configuration parameters, both
retrieved at boot time from one or more network servers. This goal requires a client to use a set
of pre-boot services, based on industry standard network protocols. Additionally, the Network
Bootstrap Program (NBP) which is initially downloaded and run must be built using a client
firmware layer (at the device to be bootstrapped via PXE) providing a hardware independent
standardized way to interact with the surrounding network booting environment. In this case the
availability and subjection to standards are a key factor required to guarantee the network boot
process system interoperability.

One of the first attempts in this regard was the Bootstrap Loading using TFTP standard RFC
906, published in 1984, which established the 1981 published Trivial File Transfer Protocol
(TFTP) standard RFC 783 to be used as the standard file transfer protocol for bootstrap loading.
It was followed shortly after by the Bootstrap Protocol standard RFC 951 (BOOTP), published in
1985, which allowed a disk-less client machine to discover its own IP address, the address of a
TFTP server, and the name of an NBP to be loaded into memory and executed. Difficulties on
BOOTP implementation among other reasons eventually led to the development of the Dynamic
Host Configuration Protocol standard RFC 2131 (DHCP) published in 1997. This pioneer
TFTP/BOOTP/DHCP approach fell short because, at the time, it did not define the required
standardized client side of the provisioning environment.

The Preboot Execution Environment (PXE) was introduced as part of the Wired for
Management[3] framework by Intel and is described in the specification published by Intel and
SystemSoft. PXE version 2.0 was released in December 1998, and the update 2.1 was made
public in September 1999.[4] The PXE environment makes use of several standard client-server
protocols like DHCP and TFTP (now defined by the 1992 published RFC 1350). Within the PXE
schema the client side of the provisioning equation is now an integral part of the PXE standard
and it is implemented either as a Network Interface Card (NIC) BIOS extension or today in
modern devices as UEFI code. This distinctive firmware layer makes available at the client the
functions of a basic Universal Network Driver Interface (UNDI), a minimalistic UDP/IP stack, a
Preboot (DHCP) client module and a TFTP client module, together forming the PXE application
programming interfaces (APIs) used by the NBP when needing to interact with the services
offered by the server counterpart of the PXE environment. TFTP's low throughput, especially
when used over high-latency links, has been initially mitigated by the TFTP Blocksize Option
RFC 2348 published in May 1998, and later by the TFTP Windowsize Option RFC 7440
published in January 2015.

Details
The PXE environment relies on a combination of industry-standard Internet protocols, namely
UDP/IP, DHCP and TFTP. These protocols have been selected because they are easily
implemented in the client's NIC firmware, resulting in standardized small-footprint PXE ROMs.
Standardization, small size of PXE firmware images and their low use of resources are some of
the primary design goals, allowing the client side of the PXE standard to be identically
implemented on a wide variety of systems, ranging from powerful client computers to resource-
limited single-board computers (SBC) and system-on-a-chip (SoC) computers.

DHCP is used to provide the appropriate client network parameters and specifically the location
(IP address) of the TFTP server hosting, ready for download, the initial bootstrap program (NBP)
and complementary files. To initiate a PXE bootstrap session the DHCP component of the
client's PXE firmware broadcasts a DHCPDISCOVER packet containing PXE-specific options
to port 67/UDP (DHCP server port); it asks for the required network configuration and network
booting parameters. The PXE-specific options identify the initiated DHCP transaction as a PXE
transaction. Standard DHCP servers (non PXE enabled) will be able to answer with a regular
DHCPOFFER carrying networking information (i.e. IP address) but not the PXE specific
parameters. A PXE client will not be able to boot if it only receives an answer from a non PXE
enabled DHCP server.

After parsing a PXE enabled DHCP server DHCPOFFER, the client will be able to set its own
network IP address, IP Mask, etc., and to point to the network located booting resources, based
on the received TFTP Server IP address and the name of the NBP. The client next transfers the
NBP into its own random-access memory (RAM) using TFTP, possibly verifies it (i.e. UEFI
Secure Boot), and finally boots from it. NBPs are just the first link in the boot chain process and
they generally request via TFTP a small set of complementary files in order to get running a
minimalistic OS executive (i.e. WindowsPE, or a basic Linux kernel+initrd). The small OS
executive loads its own network drivers and TCP/IP stack. At this point, the remaining
instructions required to boot or install a full OS are provided not over TFTP, but using a robust
transfer protocol (such as HTTP, CIFS, or NFS).

Integration

DHCP vs proxyDHCP Server

The PXE Client/Server environment was designed so it can be seamlessly integrated with an
already in place DHCP and TFTP server infrastructure. This design goal presented a challenge
when dealing with the classic DHCP protocol. Corporate DHCP servers are usually subject to
strict policies that are designed to prevent easily adding the additional parameters and rules
required to support a PXE environment. For this reason the PXE standard developed the concept
of DHCP redirection or "proxyDHCP". The idea behind a proxyDHCP is to split the PXE DHCP
requirements in two independently run and administered server units:

1. The classic DHCP server providing IP address, IP mask, etc. to all booting DHCP clients.
2. The proxyDHCP server providing TFTP server IP address and name of the NBP only to
PXE identified booting clients.

In a DHCP plus proxyDHCP server environment[4]:18 the PXE client initially broadcasts a single
PXE DHCPDISCOVER packet and receives two complementary DHCPOFFERs; one from the
regular non PXE enabled DHCP server and a second one from the proxyDHCP server. Both
answers together provide the required information to allow the PXE client to continue with its
booting process. This non-intrusive approach allows setting a PXE environment without
touching the configuration of an already working DHCP server. The proxyDHCP service may
also run on the same host as the standard DHCP service but even in this case they are both two
independently run and administered applications. Since two services cannot use the same port
67/UDP on the same host, the proxyDHCP runs on port 4011/UDP. The proxyDHCP approach
has proved to be extremely useful in a wide range of PXE scenarios going from corporate to
home environments.

Availability
PXE was conceived considering several system architectures. The version 2.1 of the
specification defined architecture identifiers for six system types, including IA-64 and DEC
Alpha. However, PXE v2.1 only completely covered IA-32. Despite this apparent lack of
completeness Intel has recently decided to widely support PXE within the new UEFI
specification extending the PXE functionality to all EFI/UEFI environments. Current Unified
Extensible Firmware Interface Specification 2.4A, Section 21 Network Protocols SNP, PXE,
and BIS defines the protocols that provide access to network devices while executing in the
UEFI boot services environment. These protocols include the Simple Network Protocol (SNP),
the PXE Base Code Protocol (PXE), and the Boot Integrity services Protocol (BIS).[5][6] Today in
a PXE environment the client architecture detection is rarely based on the identifiers originally
included with the PXE v2.1 specification, instead each computer that will be booting from the
network should have set DHCP option 93 to indicate the clients architecture. This enables a
PXE server to know (at boot time) the exact architecture of the client from the first network boot
packet. The client system architecture values are listed (among other PXE parameters) within the
2006 published RFC 4578 (Dynamic Host Configuration Protocol (DHCP) Options for the Intel
Preboot eXecution Environment (PXE)).

With the advent of IPv6 DHCP has evolved into DHCPv6; the need for options supporting PXE
within the new DHCP protocol has been addressed by the 2010 published RFC 5970 (DHCPv6
Options for Network Boot).

The original PXE client firmware extension was designed as an Option ROM for the IA-32
BIOS, so a personal computer (PC) was originally made PXE-capable by installing a network
interface controller (NIC) that provided a PXE Option ROM. Today the client PXE code is
directly included within the NIC's own firmware and also as part of the UEFI firmware on UEFI
hardware.

Even when the original client PXE firmware has been written by Intel and always provided at no
cost as a linkable IA32 object code format module included in their Product Development Kit
(PDK), the open source world has produced over the years non-standard derivative projects like
gPXE/iPXE offering their own ROMs. While Intel based ROMs have always been rock solid
implementing the client side of the PXE standard[citation needed] some people were willing to trade
extra features for stability and PXE standard conformance.

Acceptance
PXE acceptance since v2.1 has been ubiquitous; today it is virtually impossible to find a network
card without PXE firmware on it. The availability of inexpensive Gigabit Ethernet hardware
(NICs, switches, routers, etc.) has made PXE the fastest method available for installing an
operating system on a client when competing against the classic CD, DVD, and USB flash drive
alternatives.

Over the years several major projects have included PXE support, including:

All the major Linux distributions.


HP OpenVMS on Itanium hardware.
Microsoft Remote Installation Services (RIS)
Microsoft Windows Deployment Services (WDS)
Microsoft Deployment Toolkit (MDT)
Microsoft System Center Configuration Manager (SCCM)

In regard to NBP development there are several projects implementing Boot Managers able to
offer boot menu extended features, scripting capabilities, etc.:

Syslinux PXELINUX
gPXE/iPXE

All the above-mentioned projects, when they are able to boot/install more than one OS, work
under a "Boot Manager - Boot Loader" paradigm. The initial NBP is a Boot Manager able to
retrieve its own configuration and deploy a menu of booting options. The user selects a booting
option and an OS dependent Boot Loader is downloaded and run in order to continue with the
selected specific booting procedure.

Sibling environments
Apple has come up with a very similar network boot approach under the umbrella of the Boot
Server Discovery Protocol (BSDP) specification. BSDP v0.1 was initially published by Apple in
August 1999[7] and its last v1.0.8 was published in September 2010.[8] The OS X Server includes
a system tool called NetBoot. A NetBoot client uses BSDP to dynamically acquire resources that
enable it to boot a suitable operating system. BSDP is crafted on top of DHCP using vendor-
specific information to provide the additional NetBoot functionality not present in standard
DHCP. The protocol is implemented in client firmware. At boot time, the client obtains an IP
address via DHCP then discovers boot servers using BSDP. Each BSDP server responds with
boot information consisting of:

A list of bootable operating system images


The default operating system image
The clients currently selected operating system image (if defined)

The client chooses an operating system from the list and sends a message to the server indicating
its selection. The selected boot server responds supplying the boot file and boot image, and any
other information needed to download and execute the selected operating system.

Descendant environments
Microsoft created a non-overlapping extension of the PXE environment with their Boot
Information Negotiation Layer (BINL). BINL is implemented as a server service and it is a key
component of their Remote Installation Services (RIS) and Windows Deployment Services
(WDS) strategies. It includes certain preparation processes and a network protocol that could be
somehow considered a Microsoft crafted DHCP extension. BINL is a Microsoft proprietary
technology that uses PXE standard client firmware. Currently there is not a publicly available
BINL specification.

IETF standards documentation


RFC # Title Published Author Obsolete and Update Information
RFC The TFTP Protocol
Jun-1981 K. Sollins Obsoleted by - RFC 1350
783 (Revision 2)
RFC Bootstrap Loading Ross
Jun-1984 -
906 using TFTP Finlayson
RFC Updated by RFC 1395, RFC 1497, RFC
Bootstrap Protocol Sep-1985 Bill Croft
951 1532, RFC 1542, RFC 5494
Updated by RFC 1782, RFC 1783, RFC
RFC The TFTP Protocol
Jul-1992 K. Sollins 1784, RFC 1785, RFC 2347, RFC 2348,
1350 (Revision 2)
RFC 2349
Dynamic Host
RFC Updated by RFC 3396, RFC 4361, RFC
Configuration Mar-1997 R. Droms
2131 5494, RFC 6842
Protocol
RFC TFTP Blocksize
May-1998 G. Malkin -
2348 Option
RFC DHCP Options for the M.
Nov-2006 -
4578 Intel PXE Johnston
RFC DHCPv6 Options for
Sep-2010 T. Huth -
5970 Network Boot
RFC TFTP Windowsize
Jan-2015 P. Masotta -
7440 Option

See also
Computer networking portal

Diskless nodes diskless computers


Boot Service Discovery Protocol Apple network boot protocol
Remote Initial Program Load (RIPL or RPL)
System Deployment Image (SDI) primarily with Microsoft products
Unified Extensible Firmware Interface UEFI network booting
Wake-on-LAN (WOL)
Windows Deployment Services PXE-based deployment for Microsoft Windows

References
1.

"Network-Booting Windows". Microsoft. July 2008. Retrieved 2015-10-30.


Avramov, Lucien (December 31, 2014). The Policy Driven Data Center with ACI:
Architecture, Concepts, and Methodology. Cisco Press. p. 43. ISBN 1587144905. In modern
data centers, administrators rarely install new software via removable media such as DVDs.
Instead, administrators rely on PXE (Preboot eXecution Environment) booting to image servers.
"Wired for Management Baseline - Version 2.0 Release" (PDF). Intel Corporation. 1998-12-
18. Retrieved 2014-02-08.
"Preboot Execution Environment (PXE) Specification - Version 2.1" (PDF). Intel
Corporation. 1999-09-20. Retrieved 2014-02-08.
"Unified Extensible Firmware Interface Specification" (PDF). UEFI. 2013-12-02. Retrieved
2014-04-04.
"UEFI PXE Boot Performance Analysis" (PDF). Intel Corporation. 2014-02-02. Retrieved
2014-04-04.
"NetBoot 2.0: Boot Server Discovery Protocol (BSDP) v0.1" (Doc). Apple Corporation.
2003-12-02. Retrieved 2014-04-04.
"NetBoot 2.0: Boot Server Discovery Protocol (BSDP) v1.08" (Doc). Apple Corporation. 2010-
09-17. Retrieved 2014-04-04.

Вам также может понравиться