Xinu7/contrib/ether.monitor/man/netmon.doc

.RP
.TL
A Network Moinitor
.AU
Chi-jiu Lin*  D. E. Comer
.FS
* A visiting scholar of the Department of Computer Sciences
.FE
.AI
Department of Computer Sciences
Purdue University
West Lafayette, IN 47907
U. S. A.
.nr VS 24pts
.AB
This article provides an introduction to a network monitor. It is primarily used to monitor activities on the Ethernet of the Department of Computer Sciences, Purdue University.
Emphasis is placed on its implementation and usage. Some of its limitations and modifications are discussed.
.AE
.NH
Introduction
.PP
In a network, like many systems, the issue of reliability is not only an important one but also a hard nut to crack. A reliable network requires techniques for monitoring data transmission errors and detecting erroneous states in the
system. A program, called monitor, provides an effective tool for keeping track
of packet transfers and debugging network operations on the Ethernet of the 
Department of Computer Sciences, Purdue University.
.PP
The monitor runs on a LSI11 microcomputer under the support of Xinu operating
system. Xinu is a small, elegant, Level-structured operating system that has 
embedded network software inside to support the DARPA internet protocols. The
Ethernet interface is a Digital Equipment Corporation DEQNA (Digital Equipment
Q-bus Network Adaptor).
.PP
The design decision to build this monitor mainly depends on the following two
aspects.
.PP
First, it should basically be able to meet the needs for monitoring data 
transmission on the Ethernet. It includes as follows:
.IP[1]
It should be able to display all kinds of packets such as EP packets, IP 
packets, ARP packets, RARP packets, UDP packets, ICMP packets, TCP packets.
.IP[2]
It should be able to display the expected packets either by machine/port name
or by address/port number.
.IP[3]
It should be able to display the data of a packet according to user's demand
for length.
.PP
Second, it should be easy to expand its capabilities without more and bigger
modifications of its structure. It implies that it should has a better 
extensibility.
.PP
Aiming at the above goal, the monitor divides into three parts: packet receiver
, shell, and command set. Section 2 describes the implementation of the packet
receiver. Section 3 focuses on the design of the shell. Section 4 places an 
emphasis on the implementation of the command set. Section 5 discusses the 
usage of commands.
.PP
In order to further improve the monitor in the future, the remainder of the 
article examines some current limitations and possible modifications in the
future.
.NH
Packet Receiver
.PP
When the monitor begins to run on the LSI11 microcomputer, it performs three 
chores. First, it initializes a table, called an address table, by which we can 
display a packet either by name or by address/number. Second, it initializes
the DEQNA Ethernet interface to set it to receive mode and leave it on line.
Third, invoking by the command a user enters, the monitor receives a arriving
packet and holds it in a buffer.
.PP
In the address table, there are various bindings, for example, the table contains machine
name-to-internet address binding, internet-to-physical address binding, port name-to-port number binding,
and protocol name-to-protocol number binding. Even though the contents of this table
has already been filled in beforehand, it is necessary to dynamically 
initialize it again so that it is still true to the present enviroment in which
the monitor runs in case some of the bindings have been changed. For example, 
if a DEQNA Ethernet interface fails and must be replaced, one need not worry 
about the change of its physical address because the monitor will change the 
machine name-to-internet address binding and internet-to-physical address binding of its own accord.
.PP
In the initialization of the address table, the monitor broadcasts a ARP 
request according to every internet address in the address table, waiting for
a ARP reply to obtain every physical address. This process continues until
every machine name-to-internet address binding and internet-to-physical address binding in the address
table has been updated.
.PP
To initialize the DEQNA interface, the monitor must reset the interface, and 
have the interface enter set-up mode. The set-up mode defines the DEQNA 
target addresses for the purpose that it can perform address filtering later
on. More detailed, after receiving a packet, decoding manchester-encoded data from
the transceiver, and stripping off the 64-bit preamble, the received packet's
destination address field is compared to the set of these target addresses.
The target addresses either are the node's physical address, the broadcast
address, and 12 multicast addresses, or all addresses (Promiscuous Mode).
To allow all packets to be received, the monitor must set the DEQNA interface
to the promiscuous mode. After that, it also needs to reset the interface 
again, disables the interrupt of the DEQNA interface to protect from the 
interfering of the network input daemon, and leaves the DEQNA interface ready
to receive packets from the network.
.PP
Before the monitor initiates packet receptions from the network, it must build 
a command list in memory, and then pass the address of the command list. So
the command list, called a buffer descriptor list, must be initialized by the
monitor at first. That is, in the initialization, the monitor must write 
the address and length of the buffer, which is used for holding arriving 
packets, into the buffer descriptor. It must also write "not using" status into 
the buffer descriptor to indicate that this buffer descriptor has not yet been 
used, and write initial value into the two status words of the buffer descriptor
and so on. When it passes the DEQNA interface the address of the buffer 
descriptor the packet reception occurs in three stages. First, the DEQNA  
interface performs a address filtering. Second, if there is an address match and
no errors occur, the packet continues to be stored in the Receive FIFO RAM of 
the DEQNA interface. Third, it writes "using" status into the buffer descriptor
, reads the buffer address and length from the buffer descriptor and empties
the received frames into the buffer from the Receive FIFO RAM, at last writes
the receive status into the buffer descriptor. When the monitor interrogates
the status of the first status word of the buffer descriptor and finds that 
the initial value has been changed, it implies that the packet has been stored 
in the buffer, and the packet reception has finished.
.NH
The Shell of the Monitor
.PP
Considering the extensibility of the monitor, a shell similar to but simpler
than the Xinu shell is built. This shell is the interface between users and the
monitor because it can accept input from a key board, then implement command 
interpretation, and output the execution result of a command to a  
character-oriented screen. The organization of the shell is relatively simple.
The interface is line-oriented. It means that each line represents a complete
unit of input to be recognized by the interface. At the same time, it expects 
users to provide imperatives to be carried out by the system instead of being
interrogative. To allow for the possibility of many concurrent activities, the
shell allows commands to execute as separate processes.
.NH 2
Command Syntax and Shell Semantics
.PP
Like Xinu shell, the syntax description is divided into two parts: a lexical
specification that describes how the shell collects characters into tokens and
a context specification that describes the ways how the tokens can be ordered
to form valid command lines.
.PP
At the lexical level, the shell parses input characters into tokens. It only
recognizes four possible token types, shown as figure 1, and records each 
token type and the characters that comprise the token.
.TS
lcl.
           Token Name	Input Symbol	Description
           OR	|	OR symbol
           ENDLINE	\en	end of line
           ENDSTRING	\e0	end of string
           OTHER	other	sequence of non-blanks
.TE
.DS
	Figure 1   The definition of tokens
.DE
.PP
Note that at least one blank must separate adjacent occurences of type OTHER
tokens.
.PP
Figure 2 lists the definition of command line syntax. In figure 2, the bracket
[] denotes an optional occurence, + denotes that one or more token occurences
follow. Thus, a command line is a OTHER followed by a sequence of words.
.TS
lcl
lcl
lcl.
        command	->	OTHER + [word] end
        word	->	OTHER || OR OTHER
        end	->	ENDLINE || ENDSTRING
.TE

.DS
Figure 2   the definition of the command line syntax.
.DE
.PP
Like the  Xinu shell , the command interpreter breaks the
input into words and takes the first word on each line to be a command name.
Words following the command name are passed to the command process as arguments
when it is invoked.
.NH 2
Implementation of the Shell  
.PP
The implementation of the shell is quite simple. During each iteration, the
shell begins a cycle of issuing a prompt to expect users to enter commands, 
reading a single command line, and breaking it into tokens, then checking the 
sequence of tokens to be sure the line is syntactically  correct. It is called lexical analysis. 
.PP
After lexical analysis, first the shell scans and handles OR symbol. If the 
next token following it is a command name, a flag is set to indicate that the  
next part of the command contains at least another command. Otherwise the shell
just set the OR mark to tell the command process that the relation between arguments is
OR relation. Second, the shell searches command list for the named command.    
Once a command name match has been found, the shell creates a process to excute
the command, and passes arguments of the command to the command process, then 
leaves its process identification (i.e. pid) at the command process table that
the command process knows which process it should inform when it completes.    
Third, the shell starts the command process executing, and awaits the completion of the command process. When the shell receives a termination message, it     
creates another process to execute the next part of the command if the flag has
been set. Otherwise it returns and starts the next iteration.
.PP
In addition, we build a mechanism that allows the user inform the shell by typing CONTROL-B that once the current command process completes, the shell should
continue its main loop immediately, instead of continuing to receive another packet. 
.PP
Before creating a process to execute  a command, the shell must register    
with the terminal device driver. The driver keeps only one process id, so when
a process registers to receive interrupt message, the previously registerd process loses control. Whenever the user types CONTROL-B, it will cause the terminal
device to send an interrupt message to the shell that is waiting a message     
arriving and urge it return as soon as possible.
.NH
Command Set
.PP
To simplify building commands and make adding new commands easy, each command
does only one thing . So we choose the orthogonal approach to build the command
set of the monitor. It implies that the set of commands available to users 
consists of a few of small relatively simple commands that each performs a 
well-defined task and it is necessary for users to invoke several to perform a complex computation.
.PP
Recall that the shell of the monitor dosen't interpret or check command arguments, but merely delivers each argument as a string to the command procss. Undoubtedly, it is indispensable for each command process by itself to pass and check 
each argument. In this command set, all commands, except command "help", have the same argument format. As a result, it is very convenient for each command process to further parse arguments, so we provide each command process with a same procedure,  called "argparse", to do that. When each command       
process calls the procedure "argparse", if the parsed argument is a name, it   
will be converted into a address or a number with the help of the address table.
Subsequently it will be once again converted into the same form as the address
or number of the received packet. Whenever the received packet meets the need
of all arguments of the command, the command process display the packet. Otherwise it will exit and the shell continues another  search for the packet expected
until it finds the packet expected or 500 packets have been searched.
.NH
The Usage of the Commands
.PP
To run the monitor on a LSI 11 microcomputer, you need to use the download command to load its memory image into the microcomputer from the host computer, for
example from host gwen (a VAX 785), then use command odt to connect your terminal
to the microcomputer so that you can display the arriving packets. Care should
be taken. Command download and odt are not the commands of the shell. After    
the shell issues the prompt " ## ", you can enter the command you want.
.PP
It is beneficial for users to choose good commad names. To make them easy to 
use and easy to remember, the names of all commands, except "help", are the same
as their protocol types. For instance, the command "udp" will display the udp
protocol packets. The commands take six kinds of arguments:
.TS
lcl
lcl
lcl
lcl
lcl
lcl.
sname	:	 source machine name or source port name.
saddress	:	 source machine address or source port number.
dname	:	 destination machine name or destination port name.
daddress	:	 destination machine address or destination port number.
length	:	 data length.
OR	:	 | symbol.

.TE
.TS
l.
The format of a simple command is as follows:
     command [Ssname] [OR] [ssaddress] [OR] [Ddname] [OR] [ddaddress] [OR] [llength]
The format of a complex command that is complex of at least two 
simple commands and OR is as follows:
     command1 OR command2 ...... OR commandn
.TE
.TS
lss
lcl.
The commands the shell recognizes are:
help	-	display help information for the user.
ep	-	display Ethernet EP packets.
ip	-	display IP protocol packets.
arp	-	display ARP protocol packets.
rarp	-	displsy RARP protocol packets. 
udp	-	display UDP protocol packets.
icmp	-	display ICMP protocol packets.
tcp	-	display TCP protocol packets.
.TE
.NH
Some Limitations and Modifications
.PP
Analysing the limitations of the current monitor and  exploring the        
posibility of making some modifications in the future will be helpful to       
improve the organization of network monitors. This section will discuss these 
two aspects.
.IP[1]
When downloading, the current load sequence includes the Xinu operating system.
It occupies a lot of memory spaces. Little memory space remains available
for users and it is impossible to add new functions to the monitor before  
solving this problem. Thus, the best way to solve this problem is that the load
sequence only includes the standalone startup routine in preparation for       
downloading without the Xinu operating system. It saves memory, making it possible   
to extend the command set and makes the monitor smaller and elegant.
.IP[2]
At present, the set-up mode of the DEQNA is set to the promiscuous mode.   
Namely, the DEQNA receives all packets, independent of whether they are
necesarry. If we can modify the DEQNA so that it can receive only the
packets we need and filter unwanted packets under the control of the monitor, it
will improve the receive rate and avoid doing unnecessary work and packet     
overflow.
.IP[3]
Presently, we provide only one buffer to store the received packet. In high
traffic situation, if packets arrive faster than the display rate, then some   
packets will be lost. Providing more buffers enable us to improve 
this situation, but it demands that the computer system have sufficient memory. 
.IP[4]
The existing monitor just functions as a "monitor". It can only keeps track
of data transmission,  it cannot detect and locate the errors         
automatically. The main limitation is its limited command set. 
To add more functionality, such as error filtering, sending test packets, and
so on, it is essential to expand the command set.
.NH
Conclusion
.PP
This paper introduces the design and implementation of a network monitor.
Even though it can meet the needs right now, it has some limitations and need  
to be improved later on. Once these limitations are  broken through, the       
monitor will become more powerful and elegant.     
.SH
References
.DS
[1] D. E. Comer, Operating System Design: The Xinu Approach,
    Prentice - Hall, 1983.
[2] D. E. Comer, Operating System Design Vol. II, Internetworking with Xinu,
    Prentice - Hall, 1986.
[3] DEQNA User's Guide,
    Digital Equipment corporation, 1984.
.DE