ECE 407

due April 23rd


The product development cycle for networking software and/or hardware has commonly thee phases:


The goal of this project is

  1. to extract 10 functional requirements of a protocol starting from a published standard,
  2. to produce a test plan that will establish the conformance of an implementation with the functional requirements in part 1,
  3. using the test plan, check for compliance a captured packet trace - only 5 tests need to be checked for this part.

Due to time limitation and in order to maximize the learning to work ratio, the students are not asked to actually implement the protocol, but rather to go through the relevant steps that would lead to a conforming implementation of a protocol.


For this project, any protocol for which you can obtain a trace acceptable. The more uncommon the better, although normal traces are acceptable.


Functional Requirements (FRs)

Generally speaking, the functional requirements of a protocol are the statements in the protocol standard that require you to write some piece of code in the implementation in order to satisfy them (comments do not qualify as lines of code in this definition).

For example, FTP - the file transfer protocol (RFC 959) has many statements that are just for the reader's information, examples, words of wisdom, etc. For example, the first statement in the standard reads:

The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.

Other statements clearly ask for specific functionality of the implementation:

Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished (FR76-XR)

The students are asked to identify the functional requirements of the standard, highlight them and number them consecutively using the format (FRnnn-[X][R]) where nnn is the number of the requirement. All networking protocols eventually transmit and receive packets. If the FR applies to the part of the software that transmits a packet, mark it with an X. If it applies to the receiving side of the software, mark it with an R. If it applies to both, mark it with XR. The first functional requirement can be, for example, (FR1-X), the second (FR2-R), etc.

To further clarify the sender (X) and the receiver (R) part of an application, let us consider the example of a "ping" utility that sends a message to a user specified destination and receives a reply from the destination. The client side will have FRs related to sending (X) the ping message (e.g., lookup the destination's IP address, construct the packet to be sent, etc.) and will also have FRs related to receiving (R) the reply from the destination (checking that is indeed the intended destination, stopping the time counter and displaying the results for the user). Similarly, the ping daemon at the destination will have a receiving (R) part that receives and processes the initial message and then it sends (X) a reply. Details on the format of the message (e.g., how many bytes for the sequence number) concern both the sending (X) and receiving (R) side (as an appropriate variable to store it has to be defined).

The standard can require the same functionality several times throughout the standard. In this case you are to highlight the functional requirement every time it appears, but mark it as a duplicate every time it repeats: use (FRnnn-[X][R]) to label the FR the first time you encounter it and (mmmDFRnnn[X][R]) for each of the duplicates (where mmm=1 for the first duplicate, mmm=2 for the second, etc.).

The following commands specify access control identifiers (command codes are shown in parentheses):...

Since password information is quite sensitive, it is desirable in general to "mask" it or suppress typeout (1DFR33-XR). It appears that the server has no foolproof way to achieve this. It is therefore the responsibility of the user-FTP process to hide the sensitive password information (2DFR33-XR).

The last class of functional requirements are the General Functional Requirements (GFRs) that imply that some lines of code should be written, but are not specific enough to define exactly the task to be accomplished. In general the GFRs are further clarified by other more specific functional requirements. Example:

In this model, every client is a server, and vice versa. (GFR1)

The protocol thus requires every compliant implementation to have both the client and the server side of the protocol, but it is to vague to actually result in a line of code. Highlight the GFRs with a different color from the FRs and number them separately from the normal FRs.


Have a look at one of previous year's projects on FTP (doc) (pdf) for an example of the functional specification handout. The green highlights are from the students, the yellow highlights are from the instructor.

Test Plan

After the functional specifications are identified, the programmer has to implement each requirement in the server/client implementation of the protocol. Unfortunately the programmers are (still) human, and, hence, they inevitably make errors (aka bugs). The best method to test the conformance of an implementation with a published standard is to test each of the functional requirements of the standard. If each functional requirement is satisfied, the implementation conforms with the standard.

In the second part of the project you are required to produce a systematic test plan that will test each functional requirement identified in the first half of the project. The test plan will employ an input/output (also known as black box) testing procedure.

You should use an Excel spreadsheet with six columns.

  1. The first column will contain the functional requirement number (FRnnn)[X][R] corresponding to the functional requirement document developed in the first part of this project.
  2. The second column will have a brief description of the functional requirement.
  3. The third column represents the input that is expected to produce a certain output in order to test the functional requirement on transmitter's part of the software. To have an entry in the third and fourth column, the FR should have an "X" in its label.
  4. The fourth column represents the expected output corresponding to the input according to the functional requirement on the transmitter's side.
  5. The fifth column represents the input expected to produce a certain output on the receiver's side of the protocol. To have an entry in the fifth and sixth column, the FR should have an "R" in its label.
  6. The sixth column represents the expected output to the input in column five on the receiving side of a protocol.
Some functional requirements apply only to the sending side, others only to the receiving side, and others apply to both. If a FR applies only to one side of the implementation (i.e., only to the sending or only to the receiving), leave the other columns empty. For each functional specification a single line should exist in the test plan.

Have a look at an example of the test plan for FTP (xls) (pdf). Notice that the test plan example comes from a different student than the functional requirement example (and hence the FR numbers do not correspond). Furthermore, in the provided example the fifth and the sixth column are merged with the third and the fourth column (making for a messier testing).

Compliance Checking

For the third and last part of the project you are asked to use a packet trace to verify the tests you devised out in the second part pass. Unfortunately, not all tests can be simply verified by a packet trace, so you have to carefully choose the tests that can be tested using a simple packet capture.

For this last part turn in the trace you used and explain for each of the five tests what packets and fields in the packets you used for the check; also include the relevant packet(s).


The project must be submitted electronically. Students are expected to work individually. Due to the freedom in choosing both the protocol and the functional requirements to be checked, I expect that no two project reports will be similar.