96 lines
6.7 KiB
HTML
96 lines
6.7 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="TFTP Subnet Broadcast option" />
|
||
|
|
<meta name="abstract" content="Broadcast storms are a performance problem that might occur when there are large numbers of systems that boot from the network." />
|
||
|
|
<meta name="description" content="Broadcast storms are a performance problem that might occur when there are large numbers of systems that boot from the network." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzal5overview.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzal5rrqoptions.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzal5oack.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzal5bdata.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzal5tftpsub" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>TFTP Subnet Broadcast option</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzal5tftpsub"><a name="rzal5tftpsub"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">TFTP Subnet Broadcast option</h1>
|
||
|
|
<div><p>Broadcast storms are a performance problem that might occur when
|
||
|
|
there are large numbers of systems that boot from the network.</p>
|
||
|
|
<p>These storms occur when large numbers of clients request their boot code
|
||
|
|
at the same time. When hundreds of systems are involved in booting, the same
|
||
|
|
data must be routed through each hop in the network between each system and
|
||
|
|
the server.</p>
|
||
|
|
<p>The TFTP Subnet Broadcast option provides a solution to this problem. It
|
||
|
|
allows the server to broadcast the boot code to systems on a subnet basis.
|
||
|
|
Using subnet-directed broadcast, Subnet Broadcast data packets are unicast
|
||
|
|
between routers until they reach the subnet on which the systems reside. At
|
||
|
|
this point, the router at the destination subnet broadcasts the data packets
|
||
|
|
to the systems on the subnet. Disinterested hosts on the subnet throw the
|
||
|
|
data packets away. The packets are usually thrown away by the host's IP layer
|
||
|
|
after it determines that no applications are interested in receiving data
|
||
|
|
on the port to which the broadcast was directed. See <a href="#rzal5tftpsub__bcsub">Figure 1</a> for
|
||
|
|
an illustration of a subnet-directed broadcast. This solution can drastically
|
||
|
|
reduce the network traffic as well as the time that it takes many systems
|
||
|
|
to boot (when booting simultaneously).</p>
|
||
|
|
<p>The TFTP Subnet Broadcast option enables clients to join a broadcasting
|
||
|
|
filegroup. It also allows clients to receive all subsequent blocks for a file
|
||
|
|
until the client becomes the master client. A client becomes the master client
|
||
|
|
when it receives an Option Acknowledge (OACK) packet from the TFTP server
|
||
|
|
that indicates that it is the master client. A client must keep track of blocks
|
||
|
|
that it receives. After a client becomes the master client, it can request
|
||
|
|
the blocks that it has not received. The master client requests blocks by
|
||
|
|
sending ACK packets that include the block number of the block prior to the
|
||
|
|
block that the master client requires. For example, if the client wants block
|
||
|
|
5, it sends an ACK with a block number of 4.</p>
|
||
|
|
<p>When a client receives an OACK packet that indicates that
|
||
|
|
it is the master client, the client must send an ACK that requests the first
|
||
|
|
block it requires. From then on, the client must request blocks in ascending
|
||
|
|
but not necessarily consecutive order. A master client continues to send ACK
|
||
|
|
packets to the server to indicate the next block that it requires. When the
|
||
|
|
master client receives all of the blocks it requires, it sends an ACK with
|
||
|
|
the number of the last block on the file being transferred. Once the server
|
||
|
|
receives an ACK with the last block number of the file being transferred,
|
||
|
|
the transfer to the client sending the ACK is considered complete. A client
|
||
|
|
can stop its transfer at any time by sending an ACK for the last block or
|
||
|
|
by sending an Error (ERR) packet. A client can end this transfer regardless
|
||
|
|
of whether it is the master client or not. </p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> This TFTP Subnet Broadcast option is designed to improve simultaneous
|
||
|
|
transfer of large files to multiple clients on a common subnet. This option
|
||
|
|
does not help with files that require only a few blocks to transfer or single
|
||
|
|
client transfers.</div>
|
||
|
|
<div class="fignone" id="rzal5tftpsub__bcsub"><a name="rzal5tftpsub__bcsub"><!-- --></a><span class="figcap">Figure 1. Example of Broadcasting
|
||
|
|
over Subnets</span><br /><div class="imagecenter"><img src="rv4e002.gif" alt="A sample diagram of broadcasting over subnets" /></div><br /></div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="rzal5rrqoptions.htm">Client-to-server TFTP Read Request options</a></strong><br />
|
||
|
|
This information includes the additional TFTP options that are supported and a description of their use.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzal5oack.htm">Server-to-client TFTP Option Acknowledgment</a></strong><br />
|
||
|
|
The TFTP server sends an Option Acknowledgment (OACK) to a client in response to either a read request or a write request that includes additional TFTP options as described in Client to server TFTP Read Request (RRQ) options.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzal5bdata.htm">Server-to-client Broadcast Data Packets</a></strong><br />
|
||
|
|
This information explains the fields in a Broadcast Data (BDATA) Packet in detail.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzal5overview.htm" title="Trivial File Transfer Protocol (TFTP) is a simple protocol that provides basic file transfer function with no user authentication.">Trivial File Transfer Protocol</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|