US Software Capstone Design Project
GNAT - Graphical Network Analysis Tool
Specifications Document
Design Team:
Matt Ericson
John Kobinski
Matt Petro
Rob Waltz
Client:
Rich Ames, US Software
v1.7
January 1, 1998
Last revision: 1/5/98
TABLE OF CONTENTS
EXECUTIVE SUMMARY *
FUNCTIONAL SPECIFICATIONS *
NON-FUNCTIONAL SPECIFICATIONS *
FEASIBILITY ISSUES *
REFERENCES *
EXECUTIVE SUMMARY
This document explicitly describes the workings of a network analyzing software package. This package is to be developed by an NAU senior design team for the use of their sponsor, US Software. It will meet the listed specifications and perform all designated tasks. The software has four main requirements:
- Packet Disassembly
– The software must interpret TCP, IP, and Ethernet headers from a network packet log file in the Snoop2 format.
- Statistical Analysis
– Compile statistics from parsed packet.
- Graphical Interpretation
– Display results of statistics in readily interpretable from.
- GUI
– Provide an easy-to-use graphical interface.
FUNCTIONAL SPECIFICATIONS
Packet Disassembly - The software will disassemble network packets and compile a list of packet attributes (to be graphically displayed, see 1.2 below). As the lists of these attributes will be held in a data structure(s), system limits will determine the size of log file that can be disassembled. The following fields will be obtained from the TCP and IP headers (stored in the Snoop2 log file) to allow for the necessary statistical compilation:
- Sequence number
- Acknowledge number
- Time stamp
- Sending and receiving socket
- Size of TCP payload
- Window size (in bytes)
- Packet checksums
- The disassembled elements of each packet will be made available in a standard graphical "form," with the element names constituting field headers, and element values filling in the field body.
- Statistical Compilation
- The aforementioned packet elements will be used to compile statistics for a given Snoop2 log file. These statistics will be used to understand and troubleshoot network operation and traffic flow. The statistics to be compiled fall into three major categories:
- Retransmission – The software package will view retransmissions from two angles, the number of retransmissions and the character of retransmitted packets.
- Number of retransmissions
- The number of retransmissions per log file will be tallied in a 32-bit integer.
- The percentage of retransmissions/(total transmissions) in a log file will be computed.
- Both of these numbers will be displayed in a typical Windows screen at the user’s request.
- Characteristics of retransmissions
- The average size (in bytes) of retransmitted TCP packets will be computed from the disassembled list of packet sizes.
- The time environment of retransmission (i.e. burstiness, measured in retransmitted bytes sent/speed (in bytes/sec) - see references – TCP Packet Trace Analysis by Shepard).
- The average window size (in bytes) of retransmitted packets will be computed from the disassembled list of window sizes.
- Sockets which generate and receive retransmissions will be listed, along with the number of retransmissions generated, in one of several orders. The order will be determined by the user’s choice a list of options:
- By descending IP address
- By descending number of retransmissions generated
- Retransmissions will be categorized as lost vs. corrupted.
- Retransmission characteristics will be displayed on in a typical Windows screen at the user’s request.
- Check sums – The packets in a log file, individually or as an entire file, will have their check sums verified. The IP checksum will be verified, as will the TCP or UDP checksum.
- If the user desires to verify an individual packet’s checksum result, the packet can be displayed (see 1.2) and the "Check sum verification" option selected. The results of the verification will be displayed below the option button.
- If the user selects the entire file for check sum verification, the results will be displayed in a typical Windows screen.
- General Statistics – The following general statistics will be computed from disassembled packet lists:
- Network traffic, in bytes/sec.
- Network throughput, in bytes/sec. This will be computed using network bytes and subtracting any retransmissions.
- Network burstiness, in bytes/(bytes/sec) (see 2.1.2.2).
- Network packet sequence number/time (this is a graph developed by Timothy J. Shepard and explained at length in his thesis on TCP packet trace analysis. See references).
- Average network delay time between send and acknowledge. This can be determined for the network as a whole, or from two IP addresses that the user inputs.
- All general statistics will be displayed in a typical Windows screen.
- Also, upon opening a Snoop2 file, the program will analyze the file and present a screen of the following summary statistics and unusual activity.
- Summary Statistics
- 32-bit integer number of Ethernet frames in the Snoop2 file.
- Time stamp in microsecond resolution of first and last frame in the file.
- Average frame rate in frames/sec.
- Time of maximum frame rate in microsecond resolution (timestamp of frame transmitted at time of maximum rate).
- 32-bit integer number of connections detected.
- For each connection:
- Time the connection was established and terminated in microsecond resolution.
- Amount of application data transferred in each direction in bytes.
- Average throughput in each direction in bytes/sec.
- Unusual Activity
- For each connection:
- 32-bit integer number of retransmissions.
- 32-bit integer number of zero window packets.
- 32-bit integer number of delayed acknowledgement.
- The user will be able to generate graphs of sequence number versus time.
- The user will be able to graphically specify an arbitrary frame and display this frame and the surrounding frames in details.
- The user will be able to load a new log file and displace any file which is currently loaded.
- GUI
– All graphical display options will be accessed through a simple graphical interface. This interface will allow a user to step through a log file packet by packet and/or display any of the statistical graphics pages. The GUI will be modeled on the looks-like prototype which has been demonstrated to Rich Ames at US Software. The prototype features a standard windows interface with pull-down menus. It also has rudimentary graphical display features.
- Output
– The software will generate a text file of the concatenated disassembled packets, in ascending order of the Snoop2 time stamp.
NON-FUNCTIONAL SPECIFICATIONS
Must be built on a 32-bit architecture.
Must be able to run on the Java Virtual Machine.
Software must accept input in Snoop 2 format (RFC 1761, see references).
FEASIBILITY ISSUES
Programmers intend to follow US Software coding conventions, but acceptance of any restrictions and/or recommendations awaits review of the coding convention documents.
The software packet should accept the output of a network sniffer program, to be provided by US Software. This output is assumed to be in the Snoop2 format, and will be simulated with log files until the sniffer is available.
The design team would like the software to run in an "auto" mode, where the software analyzes the log file and suggests areas of interest to the user. This option will be built in to the product once it meets all the above specification, and if time permits.
REFERENCES
InterNIC – Network Information Center; URL: http://ds.internic.net/
RFC 791 – Internet Protocol specification; URL: http://ds.internic.net/rfc/rfc791.txt
RFC 792 – Internet Control Message Protocol specification; URL: http://ds.internic.net/rfc/rfc792.txt
RFC 793 – Transmission Control Protocol specification; URL: http://ds.internic.net/rfc/rfc793.txt
RFC 826 – Address Routing Protocol specification; URL: http://ds.internic.net/rfc/rfc826.txt
RFC 1761 – Snoop 2 specification; URL: http://ds.internic.net/rfc/rfc1761.txt
TCP Packet Trace Analysis by Timothy J. Shepard; URL: http://ana-www.lcs.mit.edu/anaweb/pdf-papers/_TR_494.pdf
Sun Microsystems – Java Home Page; URL: http://java.sun.com