Internet DRAFT - draft-viswanathan-remote_boot-protocol
draft-viswanathan-remote_boot-protocol
INTERNET DRAFT Vish Viswanathan
Intel Corp.
Feb 26, 1999
Intel PXE Remote Boot Protocol
<draft-viswanathan-remote_boot-protocol-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
Abstract
This document defines the protocol that is used for remote booting of
client systems in a Preboot eXecution Environment (PXE) as implemented in
Intel's Universal Network Boot [1], which is part of Intel's Wired for
Management initiative [2].
1.0 Introduction
PXE defines a wire protocol to standardize an environment for remote
booting of Intel architecture systems. This protocol makes heavy use of
the DHCP options fields to exchange configuration information, locate
different services etc.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Expires Aug 26, 1999 [Page 1]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
2. Protocol Details
The PXE wire protocol is a combination of an extension of DHCP [3](through
the use of several new DHCP option tags) and the definition of simple
packet transactions that use the DHCP packet format and options to pass
additional information between the client and the server. This added
complexity is introduced by the requirement to operate without disturbing
existing DHCP services.
A client provides the following configuration specific details to the
boot server during a remote boot session.
* Client system's ID (16 byte UUID - Universally Unique ID)
* Client system's architecture type (like X86PC, Alpha etc)
* Type of boot server from which the client is requesting a response.
2.1 Steps taken during a client boot in PXE
2.1.1 Step 1
The client, wishing to remote boot an operating system image, broadcasts a
DHCPDISCOVER packet as per the DHCP protocol. This packet is transmitted
to acquire an IP address. The client also sends PXE protocol specific
information along with this packet. The following PXE specific information is
transmitted as DHCP options.
* Client Machine Identifier - UUID (DHCP Option#61).
* PXE Client Class Identifier (DHCP option #60 -
"PXEClient:Arch:xxxxx:UNDI:yyyzzz")
2.1.2 Step 2
A DHCP server responds to the above DHCPDISCOVER packet by sending a
DHCPOFFER packet that contains the IP Address allocated to the client. In
a PXE remote boot, the DHCP server also sends a special tag (option 60,
with the value set to the string "PXEClient") to identify that it is
capable of configuring a PXE client.
Expires Aug 26, 1999 [Page 2]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
2.1.3 Step 3
At this time, the PXE client may receive DHCPOFFER messages from several
DHCP servers. However, the PXE client gives preference to servers whose
replies contain the option tag 60 ("PXEClient"). When the PXE client
receives such an offer, it implies that the PXE client has to engage in
more transactions with the DHCP server after completion of the dynamic IP
address acquisition. Once an IP address is acquired, the client contacts a
special service (known as "PXE service") running on the DHCP server. "PXE
service" is listening on the UDP port 4011 for such requests. The PXE
client sends a DHCPREQUEST packet along with the following DHCP option tags
(as specified in step 1).
* Client machine identifier - UUID (DHCP Option#61).
* PXE Client Class Identifier (DHCP option #60 -
"PXEClient:Arch:xxxxx:UNDI:yyyzzz")
2.1.4 Step 4
"PXE service" (that is running on the DHCP server) receives the above
DHCPREQUEST packet directed to port 4011. The response DHCP ACK packet for
this request includes the following information that the client needs to
access/locate the boot servers.
* Information on how to locate boot servers. This option specifies whether
the boot servers could be discovered by a broadcast DHCP packet, a
multicast packet or by unicasting a packet to the IP address from a
list.
* The multicast discovery address that the client can use to locate the
boot servers if the multicast discovery option is enabled through the
previous option.
* A menu prompt that the client displays to the user. Also, a timeout
value in seconds is included in this option. The client has to display
this menu for this timeout period before a default action is taken.
* A list of menu items, which describe the types of boot servers
available. The client typically displays this list to the user and lets
the user select the boot server of their choice.
* A list of boot server types and their IP addresses. This option is
useful if a boot server cannot be located by broadcast or multicast
discovery. In this case, the client is told the IP address(es) of the
boot server type that it wants.
The actual formats of all the option tags in this step are described in
Appendix A.
Expires Aug 26, 1999 [Page 3]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
2.1.5 Step 5
The client displays the menu prompt that it received from the previous
step and lets the user pick a boot server type. Once the user makes a
selection, the client tries to locate a boot server of that type. This is
done by sending a DHCPREQUEST packet with the same information as in Step
1 along with the type of the boot server it is trying to discover.
The discovery method by which this is done is determined by the option
received through the previous step. That option could specify a multicast
discovery, in which case, the client sends a multicast DHCP REQUEST packet to
port 4011. If there is no response to the multicast discovery, then the
client tries to broadcast the same request to the DHCP server port (port 67).
If there is no response to this request as well, then the client tries to
unicast the request to port 4011 using the list of IP addresses (one after
another) obtained through step 4.
The DHCPREQUEST packet that the client sends out contains the following
information.
* Client UUID (DHCP option #61)
* PXE Client Class Identifier Tag (DHCP option #60)
* PXE_BOOT_ITEM tag embedded in vendor specific information option (DHCP
option #43)
2.1.6 Step 6
Boot servers receiving the above mentioned packet MUST respond if
they have boot image files for the boot server type defined in the
PXE_BOOT_ITEM tag and the client system architecture defined in the
class identifier tag. If the above conditions are satisfied, the server
responds with a DHCPACK packet containing the following information.
* PXE Client Class Identifier (DHCP option #60 - "PXEClient")
* Several MTFTP related options embedded in vendor specific information
option #43. These are described more in detail in the internet
draft "Multicast TFTP in the Intel PXE Remote Boot Environment" [work in
progress]
* PXE_BOOT_ITEM tag embedded in vendor specific information option (DHCP
option #43)
* Boot file name specified in the fixed DHCP header bootfile portion
2.1.7 Step 7
The client, on receiving the response mentioned above, contacts the (m)TFTP
service on the boot server which sent the reply and downloads the boot
file. If the Multicast TFTP option is chosen by the client, then the
client follows the guidelines provided in the internet draft "Multicast TFTP
in the Intel PXE Remote Boot Environment"
Expires Aug 26, 1999 [Page 4]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
Appendix A. PXE Related DHCP Options Definitions
A.1 PXE Class Identifier
This option identifies PXE clients. This option also identifies the client
system's architecture and the version of the Universal Network Driver
Interface (UNDI) provided by the client.
The code for this option is 60 and its length is 32 octets long.
This option is of the form
"PXEClient:Arch:xxxxx:UNDI:yyyzzz", where
xxxxx = Client System Architecture (5 octets long, value 0 to 65535)
yyy = UNDI Major Version Number (3 octets long, value 0 to 255)
zzz = UNDI Minor Version Number (3 octets long, value 0 to 255)
Code Len 32-octet String
+-----+-----+-----+-----+-----+-----+-----+-----+
| 60 | 32 | PXEClient:Arch:xxxxx:UNDI:yyyzzz |
+-----+-----+-----+-----+-----+-----+-----+-----+
A.2 PXE Client Machine Identifier (UUID)
This option uniquely identifies a client machine. A 16-byte universally
unique identifier (UUID) is used for this purpose [5]. A server can uniquely
identify a client using this UUID and provide customized service.
The code for this option is 61 and its length is 17, including the type
identifier that appears before the UUID. PXE requires a type-identifier
value of zero.
Code Len Type 16-octet Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 17 | 0 | o1 | o2 | . . . . | o16 |
+-----+-----+-----+-----+-----+-----+-----+-----+
A.3 PXE Related DHCP options contained in DHCP Vendor specific information
Option
The DHCP vendor specific information option is used by clients and servers
to exchange vendor specific information. The information is an opaque
object of n octets. The Encapsulated vendor-specific options field MUST
be encoded as a sequence of code/length/value fields of identical syntax
to the DHCP options field.
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
Expires Aug 26, 1999 [Page 5]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
Within this vendor specific information, we have several code/length/value
fields to specify the PXE related configuration information.
A.3.1 PXE_DISCOVERY_CONTROL
This option specifies the different methods by which a client can discover
boot servers.
The code for this option is 6 and its length is 1.
Code Len PXE_DISCOVERY_CONTROL
+-----+-----+-----+
| 6 | 1 | b1 |
+-----+-----+-----+
The individual bits in this octet (bit 0 is the least significant bit) are
defined as follows:
Bit 0 - If set, broadcast discovery of servers is NOT allowed.
Bit 1 - If set, multicast discovery of servers is NOT allowed.
Bit 2 - If set, only use and/or accept replies from servers in the list
defined by PXE_BOOT_SERVERS tag (defined in A.3.3)
If this tag is not supplied, all bits are assumed to be 0.
A.3.2 DISCOVERY_MCAST_ADDR
This option specifies the multicast IP address that is used by the client
to discover boot servers. The client sends DHCPREQUEST packets to this
multicast address.
The code for this option is 7 and its length is 4.
Code Len DISCOVERY_MCAST_ADDR
+-----+-----+-----+-----+-----+-----+
| 7 | 4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+
A.3.3 PXE_BOOT_SERVERS
This option specifies a list of boot server types and their IP addresses.
The code for this option is 8 and its length is variable. It is basically
a list containing multiple entries of the following 3 elements.
* boot server type (2 octets long)
* number of IP addresses (1 octet long) supporting the above type.
* IP addresses of those servers ([4 * number of IP addresses] octets long).
Expires Aug 26, 1999 [Page 6]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
Code Len type1 count 'n1' IP addresses
+-----+-----+-----+-----+-----+-----..-----+-----..----+---
| 8 | v | t1 | t2 | n1 | IP addr 1 | IP addr 2 | . .
+-----+-----+-----+-----+-----+-----..-----+-----..----+---
type2 count 'n2' IP addresses
+-----+-----+-----+-----..-----+-----..----+---
| t1 | t2 | n2 | IP addr 1 | IP addr 2 | . .
+-----+-----+-----+-----..-----+-----..----+---
A.3.4 PXE_BOOT_MENU
This option specifies a string description for each boot server type
specified in option #8 above. The client MUST display this list to the user
on request to provide the user with descriptions of the boot server types.
The code for this option is 9 and its length is variable. It is a list
containing multiple entries of the following 3 elements.
* boot server type (2 octets long)
* length of the description string (1 octet long)
* string describing the boot server type ('n' octets long).
Code Len type1 str-len description
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 9 | v | t1 | t2 | n1 | n1 octets of description .. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
type2 str-len description
+-----+-----+-----+-----+-----+-----+-----+-----+
| t1 | t2 | n2 | n2 octets of description .. |
+-----+-----+-----+-----+-----+-----+-----+-----+
A.3.5 PXE_MENU_PROMPT
This option specifies the prompt message that the client can display to the
user before proceeding with the remote boot. This option controls how the
information obtained through the tag PXE_BOOT_MENU is presented to the user
and the duration for which it is displayed on the screen.
The code for this option is 10 and its length is variable.
Code Len timeout Prompt String
+-----+-----+-----+-----+-----+-----+-----+-----+
| 10 | v | t | prompt string ..
+-----+-----+-----+-----+-----+-----+-----+-----+
Expires Aug 26, 1999 [Page 7]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
If the user presses the key <F8>, the prompt string and the menu obtained
through tag #8 "PXE_BOOT_MENU" are displayed. The prompt is followed by the
number of seconds remaining before the first item in the "PXE_BOOT_MENU" is
automatically selected. If this option #10 is not returned, the menu will be
displayed without prompt and timeout. Similarly, if the timeout is 255, the
menu and the prompt will be displayed indefinitely till there is a user
interaction. If the timeout is zero, the client automatically selects the
first item in the menu.
A.3.6 PXE_BOOT_ITEM
This option specifies the boot server type that the client is discovering
and also the "layer" number of the boot image that is requested. "Layer 0"
always indicates the first bootfile for a particular boot server type.
The code for this option is 71 and its length is 4.
Code Len Boot Server Type Layer #
+-----+-----+--------+--------+-----+-----+
| 71 | 4 | t1 | t2 | n1 | n2 |
+-----+-----+--------+--------+-----+-----+
References:
[1] Preboot Execution Environment (PXE) Specification Version 2.0
ftp://download.intel.com/ial/wfm/pxespec.pdf
[2] Intel's Wired for Management Initiative,
URL:http://developer.intel.com/ial/wfm/index.htm
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[4] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extension", RFC 2132, March 1997.
[5] CAE Specification
DCE 1.1: Remote Procedure Call
Document Number: C706
Universal Unique Identifier Appendix
Copyright (c) 1997 The Open Group
http://www.opengroup.org/onlinepubs/9629399/toc.htm
Expires Aug 26, 1999 [Page 8]
<draft-viswanathan-remote_boot-protocol-01.txt > Feb 26, 1999
Author's Address
Vish Viswanathan
Intel Corporation, MS JF3-206
5200 NE Elam Young Pkwy
Hillsboro, OR 97124
Phone: (503) 264-9693
Email: vish.viswanathan@intel.com
Expires Aug 26, 1999 [Page 9]
