[comp.protocols.tcp-ip] Questions on MIL-STD-1778

jpcodes@TYCHO.ARPA (Jim P. Codespote) (01/27/88)

     I am trying to implement TCP in Ada.  I am following the Military
Standard 1778 and I am having trouble following some of the events and actions.

My problem is what happens in a "net deliver" in an established state? (9 

     I found that the decision table is switched with the "net deliver" table
in the close wait state.  Assuming I am useing the right table now, what should
happen when;  seq num status is valid, 	
OA
-------

jpcodes@TYCHO.ARPA (Jim P. Codespote) (01/27/88)

     I am trying to implement  TCP in Ada.  I am following the Military
Standard 1778 and I am having some trouble in understanding it.  My problem
is what happens in a "net deliver" in an established state? (9.4.6.1.5)

     I found that the decision table is switched with the "net deliver"
table in the close wait state.  Assuming I am using the right table now,
what should happen when;  seq num status is valid, rst is on, sec prec
match is yes, syn in window is no, and ack status test2 is none?  Does
this mean only data is being delivered?  If so, why does the standard
say "no action"?  Or, does this mean the only way data gets accepted is
if the segment contains an "ack"?

     Is the standard in error or am I just missing the point?  I would
greatly appreciate any suggestions.  Thank you.


     Please respond at jpcodes@TYCHO.ARPA


  Jim Codespote
-------

jonab@CAM.UNISYS.COM (Jonathan P. Biggar) (01/28/88)

>     I found that the decision table is switched with the "net deliver"
>table in the close wait state.  Assuming I am using the right table now,
>what should happen when;  seq num status is valid, rst is on, sec prec
>match is yes, syn in window is no, and ack status test2 is none?  Does
>this mean only data is being delivered?  If so, why does the standard
>say "no action"?  Or, does this mean the only way data gets accepted is
>if the segment contains an "ack"?

You are right about the tables being switched.

For your second question, I am assuming that you really mean rst is off.
(If you do mean rst is on, then the last line of the table should be
used and the connection should be reset and closed.)  In this case
what is happening is that the connection is probably receiving an old
duplicate SYN packet from the other end.  The only packets that do not
have ACK set are an SYN packet generated from an active open request, or
a RST packet in reponse to a SYN-ACK packet received on a closed connection.
Since RST is not on, the only valid packet that can be received here is
a duplicate SYN.  Note that even though this packet may contains a SYN, the
SYN is not in the window because the 'sv.rcv_next' variable was already
incremented past the SYN sequence number by the action procedure record_syn.
The proper response to a packet containing a duplicate SYN is just to ignore
it.

By the way, I have just completed a CRAD contract from DCA to develop
MIL-STD implementations of TCP and IP in Ada.  The code has been tested
for conformance to MIL_STD 1777 and 1778.  I believe that the code
is available for free from DCA.  If you are interested in it, let me know
and I will find out how you can acquire it.

Jon Biggar
jonab@cam.unisys.com

Distributed Architectures Branch
Unisys Defense Systems
Camarillo, CA