%
% $Log: simfddi.tex,v $
% Revision 1.2  1997/06/04 22:37:00  llp
% cleanup for Jun97 release
%
% Revision 1.1  1996/02/02  00:03:23  slm
% Initial revision
%
% Revision 1.1  1995/07/28  21:20:31  slm
% Initial revision
%
% Revision 1.1.1.3.1.1  1994/10/21  00:00:27  hkaram
% New branch
%
% Revision 1.1.1.3  1994/08/02  23:55:43  davidm
% Sectioning commands now use \protspec and \topic so latex2html has
% an easier time.
%
% Revision 1.1.1.2  1994/07/05  00:42:34  ho
% Indexed.
%
% Revision 1.1.1.1  1994/03/30  20:39:05  menze
% syntax problems
%
% Revision 1.1  1994/03/14  18:53:53  umass
% Initial revision
%

\subsection{SIMFDDI}
\index{simfddi}

\topic{NAME}
SIMFDDI (Simulated FDDI Driver (IRIX platform))

\topic{SPECIFICATION}

\noindent
SIMFDDI simulates an {\xk} FDDI driver by sending and receiving
messages using Unix UDP sockets. 

\topic{SYNOPSIS}

\noindent 
Each instantiation of SIMFDDI is associated with a specific Unix UDP
port and simulates an FDDI driver for a single interface.  SIMFDDI
transmits outgoing messages by sending to other UDP ports and presents
UDP messages received on its port as incoming FDDI packets.  Note that
since messages sent from one IRIX {\xk} to another are encapsulated
within Unix UDP packets, it is only possible to communicate with
another peer running the {\xk} with this same driver.  Communication
with ``native'' peers is not possible with this driver.

The mapping between Unix UDP ports and SIMFDDI fddi addresses is
very simple.  The six bytes of SIMFDDI fddi address are formed by
the concatenation of the four byte IP host number for the Unix host on
which the simulator is running and the two byte UDP port used
by the SIMFDDI instantiation.  Note that this is the {\em real} IP host
number, not the {\em simulated} IP host number.  See the CONFIGURATION
section below.

Note that an {\xk} may be configured with multiple instantiations of
SIMFDDI, each with its own UDP port, to simulate a multihomed host.

SIMFDDI can awkwardly simulate FDDI broadcast messages.  When an
outgoing broadcast message is sent to SIMFDDI, SIMFDDI asks its
corresponding ARP protocol for a dump of all hosts in its table.
SIMFDDI then sends the message to each of these hosts in a
point-to-point fashion.  Note that for a reasonable simulation of FDDI
broadcast, all {\xk}s in communication should have the same ARP table
(see ARP).

\topic{REALM}

\noindent
SIMFDDI is in the ANCHOR realm, supporting the FDDI driver interface
described in FDDI.

\topic{PARTICIPANTS}

\noindent
SIMFDDI supports the FDDI driver interface rather than a standard
xkernel UPI interface and thus makes no use of participant stacks.

\topic{CONTROL OPERATIONS}

\begin{description}

\item[{\tt MAC\_REGISTER\_ARP:}]
Used by an ARP instantiation to register itself with its corresponding
SIMFDDI driver.  This is used to simulate fddi broadcasts as
described above.  If no ARP protocol registers with a SIMFDDI
instantiation, broadcasts on that instantiation will not be
possible. 
\begin{description}
\item[{\rm Input:}] {\tt XObj /* ARP protocol object */ }
\item[{\rm Output:}] none
\end{description}

\item[{\tt MAC\_DUMP\_STATS:}]
If SIMFDDI\_STATS or PACKET\_STATS have been defined when the module is
compiled (the default), this causes the driver to print out relevant
statistics such as packets sent and received, broadcasts sent, errors, etc.
\begin{description}
\item[{\rm Input:}] none
\item[{\rm Output:}] none
\end{description}

\end{description}

\topic{EXTERNAL INTERFACE}

\noindent
SIMFDDI adheres to the external interface defined by FDDI.

\topic{CONFIGURATION}

\noindent
SIMFDDI requires no lower protocol.  It can be configured in either
the driver section or the protocol section of graph.comp.

\medskip
\noindent
SIMFDDI recognizes the following ROM options:

\smallskip
{\tt simfddi nnnn}:
This instantiation of simfddi should use UDP port nnnn.  There must be
such a line for each instantiation of SIMFDDI in the \xk{}.

\topic{AUTHORS}

\noindent David Yates and Erich Nahum