Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / protocols / mstd-1778-tests.doc < prev next >

Wrap

Text File | 1991-07-11 | 97.8 KB | 2,373 lines

[ PROTOCOLS:MSTD-1778-TESTS.DOC ] [ 4/88 ] UNISYS Corporation 6 February 1987 -1- TM-WD-8801/206/00 DCEC PROTOCOL LABORATORY TRANSMISSION CONTROL PROTOCOL (TCP) MIL-STD-1778 TRACEABILITY MATRIX This Traceability Index provides information on the derivation, organization, and function of tests specified for TCP within the DCEC Protocol Laboratory. This document is divided into five sections: TCP TRACEABILITY INDEX; TCP TESTS INDEX; TCP TEST SCENARIOS INDEX; TCP SCENARIOS AND TESTS DESCRIPTIONS. ------------- TCP TRACEABILITY INDEX: TCP TEST NUMBERS VERSUS TCP MIL-STD-1778 References... The table indicates the cross reference between the Test Scenarios and the applicable section in MIL-STD-1778 regarding each required function, operation, option, mode, response, or state. ------------- TCP TESTS INDEX: TCP TEST NUMBERS versus TCP Commands/Primitives/Options/Modes... The table shows the TCP Test Numbers which may be regarded as the "principle tests" of each TCP Command or Primitive and/or Option or Mode. ------------- TCP TEST SCENARIOS INDEX: TCP TEST SCENARIO FILES versus TCP TEST NUMBERS... The table shows, for each TCP Test Number, the UNIX filenames of the TCP Test Scenario Files in which it appears. ------------- TCP SCENARIOS AND TESTS DESCRIPTIONS... This section provides a brief narrative of the scope and objectives of each TCP Test Scenario File and a narrative or graphic operational description of each TCP Test Number. UNISYS Corporation 6 February 1987 -2- TM-WD-8801/206/00 TCP TRACEABILITY MATRIX TCP TEST NUMBERS versus TCP MIL-STD-1778 References The table indicates the cross reference between the TCP tests and the applicable section in MIL-STD 1778. The TCP Test Numbers may be regarded as the "principal tests" of the applicable section in MIL STD-1778 regarding each required function, operation, option, mode, response, or state. Reference Test Number --------- ---------- TCP Service Request Primitives ------------------------------ 6.4.1 Unspecified Passive Open 1, 39, 57 6.4.2 Fully Specified Passive Open 9, 10, 40 6.4.3 Active Open 2, 38, 55 6.4.4 Active Open with Data 11, 12 6.4.5 Send 3, 14, 15, 16, 56 6.4.6 Allocate 51 6.4.7 Close 6, 7, 14, 15, 16 6.4.8 Abort 17, 18, 19, 20 6.4.9 Status 24 TCP Service Response Primitives ------------------------------- 6.4.10.1 Open Id 1, 2, 9, 10, 11 6.4.10.2 Open Failure 35, 371, 41, 42, 49, 63 6.4.10.3 Open Success 1, 2, 66 6.4.10.4 Deliver 3, 6 6.4.10.5 Closing 6, 7 6.4.10.6 Terminate 6, 7, 17, 18, 19, 20, 21, 44, 45, 46, 50, 55 56, 57, 58, 67 6.4.10.7 Status Response 24 6.4.10.8 Error 4, 5, 31, 38, 40, 73 TCP Mechanisms Tested --------------------- 9.2.3 Flow Control Window 59, 61 9.2.4 Duplicate/Order Detection 25, 26, 27, 29, 32 9.2.5 Acks and Retransmission 27, 52, 53, 54 9.2.6 Checksum 28 9.2.7 Push 63, 64 9.2.8 Urgent 60, 61, 62 9.2.9 ULP Timeout/Action 55, 56, 57, 58 9.2.10 Security 38, 39, 40, 41, 42, 43 44, 45, 46, 47, 48, 49, 50 UNISYS Corporation 6 February 1987 -3- TM-WD-8801/206/00 9.2.11 Precedence Level 21, 22, 23 9.2.12 Multiplexing 30, 31, 32, 33, 34, 36 9.2.13 Connection Opening 35, 37 9.2.14 Connection Closing 14, 15, 16, 17 9.2.15 Resets 35, 50, 65, 66, 67, 68, 69, 70, 71, 72 9.3.1 Source Port Address Range 13 9.3.2 Destination Port Address Range 13 TCP Options Tested ------------------ 9.3.11.1.3 Maximum Segment Size 52 UNISYS Corporation 6 February 1987 -4- TM-WD-8801/206/00 TCP TESTS INDEX TCP TEST NUMBERS versus TCP Commands/Primitives/Options/Modes... The table shows the TCP Test Numbers which may be regarded as the "principle tests" of each TCP Command or Primitive and/or Option or Mode. TEST NUMBER PURPOSE ---- ------ ------ 1 Unspecified Passive Open Request 2 Active Open Request 3 Basic Data Transfer 4 Remote Driver Interpretation of command LCN 5 Determine IUT Standard Send Buffer 6 Closing Handshake - IUT initiates close 7 Closing Handshake - IUT peer initiates close 8 Ability to reconnect Remote Driver command channel 9 Fully Specified Passive Open Request 10 Illegal Fully Specified Passive Open Request 11 Active Open with Data 12 Active Open with Data 13 Port Number Range 14 Graceful Closing - completion of data transfer after ULP close 15 Graceful Closing - data transfer after receipt of peer's FIN 16 Graceful Closing - peer data transfer after IUT initiates close 17 ULP Abort 18 Peer Abort 19 ULP Abort - data queued for sending 20 Peer Abort - data queued for sending 21 Precedence - mismatched 22 Precedence - matched 23 Precedence Negotiation 24 Status 25 Out of order data 26 Overlapping data 27 Lost data 28 Bad Checksum detection 29 Sequence number wraparound 30 Multiplexing - two connections with unique 4-tuple IUT opens passively 31 Multiplexing - common destination port in 4-tuple common IUT port 32 Multiplexing - common destination port in 4-tuple common REF port 33 Multiplexing - two connections with unique 4-tuple IUT opens actively 34 Multiplexing - three connections with common IUT port in 4-tuple UNISYS Corporation 6 February 1987 -5- TM-WD-8801/206/00 TEST NUMBER PURPOSE ---- ------ ------- 35 Duplicate connection attempt - IUT passive 36 Multiplexing - Same sequence numbers on two connections. 37 Duplicate connection attempt - IUT active 38 Setting security in Active Open 39 Setting security in Passive Open 40 Setting security in Fully Specified Passive Open 41 Secure IUT rejecting connection to unsecured peer 42 Secure IUT rejecting connection from unsecured peer 43 Security option placement in sending data 44 Response to data with mismatched security class 45 Response to data with mismatched security protection authority 46 Response to data with extra protection authority 47 Use of security option for unclassified connections 48 Recognition of UNCLASS and GENSER as unsecured 49 Unsecured IUT response to connection attempt by secured host 50 Unsecured IUT response to data marked with classified security 51 Alloc 52 Maximum segment size option 53 Retransmission after acknowledgment of data 54 Retransmission after acknowledgment of SYN and FIN 55 ULP timeout service in Active Open 56 ULP timeout service in Send 57 ULP timeout service in Passive Open 58 ULP timeout notify action tested. 59 TCP in window mechanism 60 Urgent service 61 Urgent service when peer has zero window 62 Urgent data delivery 63 Push Service - Service not requested 64 Push service - Service requested 65 Reset - as response to connection refusal 66 Reset - partial reset prior to connection establishment 67 Reset - response to reset received while sending data 68 Reset segment format on receipt of Active Open with no listening port 69 Reset segment format on receipt of Active Open with data with no listening port 70 Reset segment format on receipt of invalid segment with ACK set 71 Reset segment format on receipt of invalid segment with SYN and ACK set 72 Reset - no reset sent on receipt of segment with bad acknowledgment number 73 Determine number of connections resources will allow UNISYS Corporation 6 February 1987 -6- TM-WD-8801/206/00 TCP TEST SCENARIOS INDEX TCP TEST SCENARIO FILES versus TCP TEST NUMBERS... The table shows, for each TCP Test Number, the UNIX filenames of the TCP test Scenario Files in which it appears. TEST NUMBER SCENARIO NAME ----------- ------------- 1 INIT1 2 INIT1 3 INIT1 4 INIT1 5 INIT1 6 INIT1 7 INIT1 8 INIT1 9 BASIC1 10 BASIC1 11 BASIC1 12 BASIC1 13 BASIC1 14 BASIC2 15 BASIC2 16 BASIC2 17 BASIC2 18 BASIC2 19 BASIC2 20 BASIC2 21 BASIC2 22 BASIC2 23 BASIC2 24 BASIC2 25 BASIC3 26 BASIC3 27 BASIC3 28 BASIC3 29 BASIC3 UNISYS Corporation 6 February 1987 -7- TM-WD-8801/206/00 TEST NUMBER SCENARIO NAME ----------- ------------- 30 BASIC4 31 BASIC4 32 BASIC4 33 BASIC4 34 BASIC4 35 BASIC4 36 BASIC4 37 BASIC4 38 BASIC5 39 BASIC5 40 BASIC5 41 BASIC5 42 BASIC5 43 BASIC5 44 BASIC5 45 BASIC5 46 BASIC5 47 BASIC5 48 BASIC5 49 BASIC5 50 BASIC5 51 BASIC6 52 FULL1 53 FULL1 54 FULL1 55 FULL1 56 FULL1 57 FULL1 58 FULL1 59 FULL2 60 FULL2 61 FULL2 62 FULL2 63 FULL2 64 FULL2 65 FULL3 66 FULL3 67 FULL3 68 FULL3 69 FULL3 70 FULL3 71 FULL3 72 FULL3 73 QUAL1 UNISYS Corporation 6 February 1987 -8- TM-WD-8801/206/00 TCP SCENARIOS AND TESTS DESCRIPTIONS This section provides a brief narrative of the scope and objectives of each TCP test Scenario File and a narrative of each individual test in that scenario. ======================================================================== Scenario INIT1 -------------- Scenario INIT1 is the first test of a test session. This scenario tests the most basic TCP functions of the TCP Implementation Under Test (IUT) and the compliance of the IUT Remote Driver to the DCA Protocol Laboratory TCP Remote Driver Specification. If the IUT and the Remote Driver do not receive good results on the first run of this scenario, further testing should be abandoned until the problems exhibited are corrected. INIT1 tests the TCP implementation for its ability to perform the most basic TCP functions: Active Open, Passive Open, transfer of data and closing. The scenario determines that the Remote Driver interprets Central Driver commands correctly, acknowledges the receipt of a command from the Central Driver and correctly formats IUT responses that it sends to the Central Driver. ____________________________________ Test 1: UNSPECIFIED PASSIVE OPEN ------ - Does the Implementation Under Test (IUT) implement a Passive Open which accepts an Active Open request? - Action: Remote Driver (RD) performs a Specified Passive Open. Laboratory Slave Driver (LSD) does an Active Open to it. - Verification: Determine that a connection is made by finding an OPEN SUCCESS response from the LSD. Ensure that the RD acknowledges all commands received from the Central Driver (CD). Determine that all RD responses are correctly formatted. Success: The connection is made. The RD correctly interprets CD commands, acknowledges CD commands and formats IUT responses. Failure: Connection is not made or the RD does not correctly interpret CD commands, acknowledge CD commands, or format IUT responses. UNISYS Corporation 6 February 1987 -9- TM-WD-8801/206/00 Test 2: ACTIVE OPEN ------ - Can the Implementation Under Test (IUT) implement an Active Open? - Action: Laboratory Slave Driver (LSD) performs a Passive Open. The Remote Driver (RD) does an Active Open to the listening port. - Verification: Determine that a connection is made by finding an OPEN SUCCESS response from the RD. Ensure that the RD acknowledges all commands received from the Central Driver. Determine that all RD responses are correctly formatted. Success: The connection is made. The RD correctly interprets CD commands, acknowledges CD commands and formats IUT responses. Failure: Connection is not made or the RD does not correctly interpret CD commands, acknowledge CD commands, or format IUT responses. Test 3: BASIC DATA TRANSFER ------ - Does the Implementation Under Test (IUT) send and deliver data correctly? - Action: The Laboratory Slave Driver (LSD) sends data to the Remote Driver (RD). The RD sends data to the LSD. - Verification: Ensure that all the data the IUT is directed to send to the LSD is received by the Laboratory Reference Implementation (REF). Check that all the data sent by the LSD is delivered to the RD by the IUT. Ensure that the RD acknowledges all commands received from the Central Driver. Determine that all RD responses are correctly formatted. Success: The IUT sends all the data it is requested to send and delivers all the data it receives. The RD correctly interprets CD commands, acknowledges CD commands and formats IUT responses. Failure: The IUT does not send all the data it is requested to send or does not deliver all the data it receives. Also that the RD does not correctly interpret CD commands, acknowledges CD commands or format IUT responses. UNISYS Corporation 6 February 1987 -10- TM-WD-8801/206/00 Test 4: SIGNIFICANCE OF COMMAND LCN TO REMOTE DRIVER AND IUT ------ - Do the Implementation Under Test (IUT) and the IUT Remote Driver (RD) correctly interpret the local connection name (lcn) specified in the commands the RD receives from the Central Driver (CD). - Action: The Central Driver (CD) sends a Send command to the Remote Driver (RD) which contains an lcn for a connection that is not established. The RD requests the IUT to send data to the LSD over this connection. - Verification: Ensure that the RD reports in correct format that the IUT reponds to the incorrect lcn with TCP ERROR: CONNECTION DOES NOT EXIST. Success: The IUT recognizes an invalid lcn. The RD correctly interprets CD commands, acknowledges CD commands and formats IUT responses. Failure: The IUT does not recognize an invalid lcn. Also, the RD does not correctly interpret CD commands, acknowledge CD commands or format IUT responses. Test 5: DETERMINE IUT STANDARD SEND BUFFER FOR TESTING PURPOSES ------ - Determine the standard size buffer that the Implementation Under Test (IUT) requires to guarantee that the IUT will output at least two segments without delay. - Action: The Remote Driver issues a series of Send commands. each command requests a larger increment of data to be sent. After each Send command, the LSD waits for the data to be delivered. Once the data is delivered, check the TCP segments collected by the Laboratory Reference Implementation (REF) to determine if more than one segment was required to send the data. When more than one segment is used to send the data or the response TCP ERROR: INSUFFICIENT RESOURCES is returned by the IUT, the test is ended. - Verification: When a Send command data length requires the IUT to send the data in more than one segment, that data length is noted. If the response TCP ERROR: INSUFFICIENT RESOURCES has been reported, the data length of the Send command immediately preceding the command that caused that response is noted. - Observation: The IUT standard send buffer is noted for the test operator. UNISYS Corporation 6 February 1987 -11- TM-WD-8801/206/00 Test 6: CLOSING HANDSHAKE WHEN IUT INITIATES CLOSE ------ - Does the Implementation Under Test (IUT) correctly perform the closing handshake when it initiates closing. - Action: The Remote Driver (RD) performs a close. When the Laboratory Slave Driver (LSD) receives the indication of peer closing from the Laboratory ReferenceImplementation (REF), it performs a close. - Verification: Ensure that the RD reports TERMINATE: CONNECTION CLOSED or TERMINATE: ULP CLOSE when the IUT indicates the connection closed. Check the TCP segments collected by the REF to determine that the IUT acknowledged the FIN from the REF before it terminated. Success: The IUT acknowledges the FIN of the REF. The IUT reports its connection closed. The RD correctly interprets Central Driver (CD) commands, acknowledges CD commands and formats IUT responses. Failure: The IUT does not acknowledge the FIN of the REF or the IUT does not report its connection closed. The IUT reports its connection closed before the REF closes. The RD does not correctly interpret CD commands, acknowledge CD commands or format IUT responses. Test 7: CLOSING HANDSHAKE WHEN IUT PEER INITIATES CLOSE ------ - Does the Implementation Under Test (IUT) correctly perform the closing handshake when its peer initiates closing. - Action: The Laboratory Slave Driver (LSD) performs a close. When the IUT reports receiving the Laboratory Reference Implementation (REF) closing, it performs a close. - Verification: Ensure that the RP correctly reports CLOSING and TERMINATE: CONNECTION CLOSED when it receives these responses from the IUT for the REF's closing and the final closing of the connection. Check the TCP segments collected by the REF to determine that the IUT did not send its FIN before being instructed to close by the RD. Also check that the IUT sends a FIN to the REF once it has been instructed to close. UNISYS Corporation 6 February 1987 -12- TM-WD-8801/206/00 Success: The IUT waits to be instructed to close before it sends a FIN. It sends a FIN when it is instructed to close. The IUT correctly reports its peer's closing and the closing of the connection. The RD correctly interprets Central Driver (CD) commands, acknowledges CD commands and formats IUT responses. Failure: The IUT sends a FIN in response to a peer's FIN before it is instructed to close or the IUT does not send a FIN when it is instructed to close. Failure also occurs when the IUT does not report a peer's closing or the closing of the connection. Other reasons for failure are when the RD does not correctly interpret CD commands, acknowledge CD commands or format IUT responses. Test 8: ABILITY TO RECONNECT TO COMMAND CHANNEL AFTER CLOSURE ------ - Does the Implementation Under Test Remote Driver remain listening after the Central Driver closes the command channel? - Action: The Central Driver instructs the Remote Driver to kill itself. After waiting five seconds to allow the connection to be cleared, the Central Driver attempts to reconnect the command channel to the Remote Driver. - Verification: If the scenario aborts when the Central Driver attempts to reconnect the command channel to the Remote Driver, the Remote Driver is no longer listening. If the Central Driver is able to reconnect the command channel, a Remote Driver is left listening after the command channel is closed. Success: A Remote Driver is left listening when the Central Driver (CD) closes the command channel to the Remote Driver, and reconnection to the Central Driver occurs. Failure: A Remote Driver is not left listening when the Central Driver closes the command channel to the Remote Driver. The Remote Driver does not correctly interpret CD commands, acknowledge CD commands or format IUT responses. UNISYS Corporation 6 February 1987 -13- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC1 --------------- Scenario BASIC1 tests the TCP implementation of Fully Specified Passive Open, and Active Open with Data. _____________________________________ Test 9: FULLY SPECIFIED PASSIVE OPEN ------ - Does the Implementation Under Test (IUT) implement a passive open which accepts an Active Open request only from a specified addresss - Action: Remote Driver (RD) performs a fully Specified Passive Open. Laboratory Slave Driver (LSD) does an Active Open to it from a socket bound with the specified address. - Verification: Determine that a connection was made by finding an OPEN SUCCESS response from the LSD. Success: The connection was made. Failure: Connection was not made. Test 10: FULLY SPECIFIED PASSIVE OPEN ------- - Will the the Implementation Under Test (IUT) fully Specified passive Open accept an Active Open request from an unspecified port? - Action: Remote Driver (RD) performs a fully Specified Passive Open. Laboratory Slave Driver (LSD) does an Active Open to it from a socket with a different port number than the one specified in the fully Specified Passive Open. - Verification: Determine that a connection was made by checking that the Laboratory Reference Implementation (REF) sent an OPEN FAILURE response. Success: Connection was not made. Failure: Connection was made. UNISYS Corporation 6 February 1987 -14- TM-WD-8801/206/00 Test 11: ACTIVE OPEN WITH DATA ------- - Does the Implementation Under Test (IUT) send data on its SYN segment on an Active Open with Data. - Action: Remote Driver (RD) performs an Active 0pen with Data. - Verification: Check the IUT's SYN segment to see if data was sent on that segment. Success: The IUT sends data on its SYN segment. Failure: The IUT does not send data on its SYN segment. Test 12: ACTIVE OPEN WITH DATA ------- - Does the Implementation Under Test (IUT) acknowledge data received on the SYN segment in its SYN ACK (before connection establishment)s - Action: Laboratory Slave Driver (LSD) performs an Active Open with Data. - Verification: Check the IUT SYN ACK segment to ensure that it does not acknowledge data. Success: Data is not acknowledged on the IUT SYN ACK segment. Failure: Data is acknowledged on the IUT SYN ACK segment. Test 13: PORT NUMBER RANGE ------- - Can the Implementation Under Test (IUT) assign a range of local port numbers? - Action: Remote Driver (RD) does two Passive Open requests: one specifies source port 1 and the other specifies source port 65535. The RD also does an Active Open to destination port 65534. - Verification: Determine whether the IUT returns SYSTEM ERROR: REQUESTED SOURCE PORT NOT PERMITTED or the OPEN ID from the Passive Open requests. Ensure that a connection was made when destination port 65534 was specified in the Active Open. Observation: Result is to indicate the range of port numbers that the IUT allows to be assigned. UNISYS Corporation 6 February 1987 -15- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC2 --------------- Scenario BASIC2 tests the TCP implementation of graceful closings, its handling of aborts, precedence, and status. _______________________________________ TEST 14: DATA TRANSFER IN CLOSING STATES ------- - Does the Implementation Under Test (IUT) provide graceful closing by completing data transfer after its Upper Level Protocol has initiated closings - Action: The Remote Driver (RD) sends a large amount of data and immediately closes. - Verification: Determine that the Laboratory Reference Implementation (REF) receives all the data the IUT was requested to send. Success: All expected data was received by the REF. Failure: All expected data not received by REF. TEST 15: DATA TRANSFER IN CLOSING STATES ------- - Does the Implementation Under Test (IUT) provide graceful closing by continuing to send data after receiving peer's FIN segments - Action: The IUT is instructed to send data after it has received its peer's closing FIN segment. - Verification: Determine that the IUT sends the data by checking that all expected data is received by the Laboratory Reference Implementation (REF). Success: REF receives all data IUT was asked to send. Failure: REF does not receive all data IUT was asked to send. UNISYS Corporation 6 February 1987 -16- TM-WD-8801/206/00 TEST 16: DATA TRANSFER IN CLOSING STATES ------- - Does the Implementation Under Test (IUT) deliver data sent after it has initiated closings - Action: Remote Driver tells IUT to close. On receiving the IUT's close, the Laboratory Slave Driver (LSD) requests the Laboratory Reference Implementation (REF) to send data to the IUT. - Verification: Determine that the IUT delivers all the data sent by the REF. Success: IUT delivers all data sent by REF. Failure: IUT does not deliver all data sent by REF. TEST 17: UPPER LAYER PROTOCOL ABORT ------- - Does the Implementation Under Test (IUT) perform an abort by sending a correct reset segments - Action: Remote Driver (RD) aborts the connection. - Verification: Check that the Laboratory Slave Driver (LSD) reports a TERMINATE: REMOTE ABORT response and the RD reports TERMINATE: ULP ABORT or TERMINATE: USER ABORT. Success: The IUT sends a reset segment and the correct terminate response. Failure: The IUT does not send a reset segment or correct terminate response. Test 18: PEER ABORT ------- - Can the Implementation Under Test (IUT) detect its peer's aborts - Action: The Laboratory Slave Driver (LSD) instructs its Laboratory Reference Implementation (REF) to abort connection. - Verification: Check that the IUT reports TERMINATE: REMOTE ABORT. Success: IUT correctly reports REMOTE ABORT. Failure: IUT does not correctly report its peer's abort. UNISYS Corporation 6 February 1987 -17- TM-WD-8801/206/00 TEST 19: UPPER LAYER PROCESS ABORT ------- - Does the Implementation Under Test (IUT) discard data queued for sending when it performs a ULP aborts - Action: Remote Driver (RD) sends data to its peer and then immediately aborts the connection. - Verification: Check that the Laboratory Slave Driver (LSD) reports a TERMINATE: REMOTE ABORT response and the RD reports TERMINATE: ULP ABORT. Examine the IUT reset segment for correctness and determine if all data sent by the RD was received by the LSD. Success: The IUT sends the correct terminate response, its reset segment is correctly formatted, and not all data sent by the IUT is received by the Laboratory Reference Implementation (REF). Failure: The IUT sends an incorrect terminate response or an incorrect reset segment. If all data is received by the LSD, this particular result is inconclusive as the data may already be sent before the Central Driver command to abort is received by the IUT. Test 20: PEER ABORT ------- - Does the Implementation Under Test (IUT) detect its peer's abort and then discard data queued for sendings - Action: The Laboratory Slave Driver (LSD) instructs its Laboratory Reference Implementation (REF) to abort while the IUT is sending data. - Verification: Check that the IUT reports TERMINATE: REMOTE ABORT and that the IUT stops sending data after receiving the peer's abort. Success: IUT correctly reports REMOTE ABORT and stops sending data after receiving its peer's reset. Failure: IUT does not correctly report its peer's abort. If all the data sent is received by the LSD, that particular result is inconclusive as all the data may be delivered before the Central Driver command to abort is received. UNISYS Corporation 6 February 1987 -18- TM-WD-8801/206/00 Test 21: MISMATCHED PRECEDENCE ------- - Does the Implementation Under Test (IUT) provide the option to set a precedence value for the connection and make correct hecks of the precedence of incoming segments to the connections - Action: Remote Driver (RD) passively opens a connection with maximum precedence. Laboratory Slave Driver (LSD) actively opens at a less than maximum precedence and Laboratory Reference Implementation (REF) does not raise its precedence. - Verification: Determine that IUT sets the precedence option by checking the segments output by the IUT. Ensure that IUT aborts the connection when REF does not match precedence by looking for TERMINATE: REMOTE ABORT from the LSD or an OPEN FAILURE from the LSD connection. Success: IUT sets precedence option and aborts connection when peer's precedence does not match. Failure: IUT does not set precedence option or makes connection when precedence does not match. Test 22: PRECEDENCE ------- - Does the Implementation Under Test (IUT) provide the option to set precedence for the connection and make correct checks on the incoming segments to the connection? - Action: Remote Driver (RD) passively opens a connection with maximum precedence. Laboratory Slave Driver (LSD) actively opens at a less than maximum precedence. The Laboratory Reference Implementation (REF) raises its precedence during the opening handshake. - Verification: Determine that the connection is made by checking that the LSD reports an OPEN SUCCESS. Check the IUT segments to ensure that precedence was set. Success: The IUT makes the connection and sets-precedence. Failure: The IUT does not set precedence or does not make the connection even though the REF matched its precedence. UNISYS Corporation 6 February 1987 -19- TM-WD-8801/206/00 Test 23: PRECEDENCE NEGOTIATION ------- - Does the Implementation Under Test (IUT) provide the option to set precedence for the connection and raise its precedence to match its peer's precedences - Action: Laboratory Slave Driver (LSD) passively opens a connection with a given precedence. The Remote Driver opens with a zero precedence. - Verification: Determine that the connection is made by checking that the LSD reports an OPEN SUCCESS. Check the IUT segments to ensure that precedence was raised. Success: The IUT makes the connection and sets precedence. Failure: The IUT does not raise precedence to match the precedence of the REF. Test 24: STATUS ------- - Does the Implementation Under Test (IUT) in its status response correctly report a connection's source port, destination port, destination address, window, precedence and states (These fields were selected to represent both static and dynamic internal information). - Action: The Remote Driver (RD) asks the IUT to give the status of a connection. - Verification: Ensure that the status response given matches the true status of the connection. Success: The IUT reports the status of the connection correctly. Failure: The IUT does not report the status of the connection correctly. UNISYS Corporation 6 February 1987 -20- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC3 --------------- Scenario BASIC3 tests the TCP implementation's ability to maintain data integrity: out of order data, overlapping data, lost data, segments with bad checksums and segments with sequence number wraparound. ________________________________________ Test 25: OUT OF ORDER DATA - Can the Implementation Under Test (IUT) correctly handle segments which arrive out of order, as indicated by their sequence number? - Action: The Laboratory Slave Driver (LSD) sends data to the IUT. The Laboratory Reference Implementation (REF) divides the data into segments and outputs them out of order. - Verification: Determine if the IUT delivers the data in the correct order. Success: The IUT correctly reorders the data. Failure: The IUT does not correctly reorder the data. Test 26: OVERLAPPING DATA ------- - Can the Implementation Under Test (IUT) clean up overlapping datas - Action: The Laboratory Slave Driver (LAB) sends data to the IUT. The Laboratory Reference Implementation (REF) repackages the data for retransmission so that some segments contain both new data and data already sent. - Verification: Determine that IUT accepts the data and correctly delivers it. Success: The IUT is able to accept the overlapping data and deliver it correctly. Failure: The IUT does not deliver the data on segments after the first arrival or delivers the data incorrectly. UNISYS Corporation 6 February 1987 -21- TM-WD-8801/206/00 Test 27: LOST DATA ------- - Can the Implementation Under Test (IUT) detect that data is losts - Action: The Laboratory Slave Driver (LSD) sends data to the Remote Driver. The Laboratory Reference Implementation (REF) divides the data into several segments and sends data, omitting a segment. The missing segment is not sent until the last segment sent is retransmitted several times. - Verification: Determine that the IUT does not acknowledge anything sent after this missing segment until the missing segment is transmitted. Success: The IUT does not acknowledge any data received after the last correctly ordered segment, until the missing segment is sent. Failure: The IUT acknowledges data sent after the missing segment before the missing segment is sent. TEST 28: CHECKSUM ------- - Does the Implementation Under Test (IUT) detect a segment with a bad checksum and discard it? - - Action: Laboratory Slave Driver (LSD) sends data to the IUT. The Reference Implementation (REF) sends out a segment with a bad checksum and retransmits it incorrectly several times before transmitting it correctly. Verification: Determine that the IUT acknowledges only the segments sent with a good checksum by checking segment data collected by the REF. Success: The IUT only acknowledges segments sent with good checksums. Failure: REF acknowledges segments sent with bad checksums. UNlSYS Corporation 6 February 1987 -22- TM-WD-8801/206/00 Test 29: SEQUENCE NUMBER WRAPAROUND ------- - Does the Implementation Under Test (IUT) use correct module arithmetic when comparing sequence numberss - Action: The Laboratory Slave Driver (LSD) sends data to the IUT. The Laboratory Reference Implementation (REF) uses as its initial sequence number a number guaranteed to cause wraparound from 2**32-1 to 0 on the data segments. - Verification: Determine if the IUT acknowledges all data sent by the REF. Success: The IUT acknowledges the data sent by the REF. Failure: The IUT does not acknowledge any data sent by the REF after the sequence number wraparound occurs. UNISYS Corporation 6 February 1987 -23- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC4 --------------- Scenario basic 4 test how well the TCP implementation can establish multiple connections and demultiplex data sent over these connections. A TCP connection is defined by the source port, source address, destination port and destination address of the connection. This four element identification is known as a 4-tuple. This scenario tests by opening multiple connections with different combinations in the 4 tuple (from the viewpoint of the IUT). _________________________________________ Test 30: MULTIPLEX DATA OVER 2 CONNECTIONS WITH UNIQUE 4-TUPLES. ------- - Can the Implementation Under Test (IUT) correctly deliver data sent over two connections it actively opened with no 4-tuple element in common? - Action: The Remote Driver (RD) opens two connections to the Laboratory Slave Driver(LSD). The LSD then sends unique data over each connection. - Verification: Determine that the IUT keeps the data sent on each connection separate and delivers it correctly. Success: The IUT delivers the data sent over each connection correctly. Failure: The IUT does not deliver the data sent over each connection correctly. UNISYS Corporation 6 February 1987 -24- TM-WD-8801/206/00 Test 31: MULTIPLEX OVER 2 CONNECTIONS WITH COMMON DEST. PORT IN 4-TUPLE. ------- - Can the Implementation Under Test (IUT) multiplex data over two connections which share a common destination port in their 4-tuples. - Action: Two connections are opened which have the same destination port on the Laboratory Reference Implementation (REF). The LSD sends unique data over each connection. - Verification: Determine that the IUT keeps the data received over connection separate and delivers it correctly. Success: The IUT delivers the data sent over each connection correctly. Failure: The IUT does not deliver the data sent over each connection correctly. Test 32: MULTIPLEX WITH 2 CONNECTIONS HAVING SAME REF SRC PORT IN 4-TUPLES. ------- - Can the Implementation Under Test multiplex data over two connections that have the same destination port in their 4-tuples? - Action: The Laboratory Slave Driver (LSD) actively opens two connections from the same source port to distinct listening ports on the IUT. The LSD then sends unique data to the Remote Driver (RD) over each,connection. - Verification: Determine that all the data sent by the LSD is delivered correctly to the RD. Success: All sent data is delivered correctly to the RD. Failure: Data is not delivered correctly to the RD. Test 33: MULTIPLEX DATA OVER 2 CONNECTIONS WITH UNIQUE 4-TUPLES. ------- - Can the Implementation Under Test (IUT) correctly deliver data sent over two connections that the IUT passively opens, that have no 4-tuple elements in commons - Action: The Laboratory Slave Driver (LSD) opens two connections to the Remote Driver (RD). The LSD then sends unique data data over each connection. UNISYS Corporation 6 February 1987 -25- TM-WD-8801/206/00 - Verification: Determine that the IUT keeps the data sent on each connection separate and delivers it correctly. Success: The IUT delivers the data sent over each connection correctly. Failure: The IUT does not deliver the data sent over each connection correctly. TEST 34: MULTIPLEX DATA OVER 3 CONNECTIONS WITH SAME SRC PORT IN 4-TUPLE ------- - Can the Implementation Under Test (IUT) correctly establish connections and demultiplex data when the same IUT source port is in the 4-tuple of 3 connectionss - Action: The Laboratory Slave Driver (LSD) actively opens 3 connections to the same IUT port. The LSD then sends unique data to the Remote Driver (RD) over each connection. - Verification: Determine that all three connections are opened and that the all the data sent over each connection is correctly delivered. Success: All the data sent over the 3 connections is correctly delivered. Failure: The data sent over the 3 connections is not correctly delivered. TEST 35: IUT REJECTS DUPLICATE CONNECTION ------- - Does the Implementation Under Test (IUT) reject an attempt to make a duplicate connection to its listening ports - Action: The Laboratory Slave Driver (LSD) actively opens 2 connections to the IUT from different ports. LSD then attempts to make a third connection using the same source and destination port used in the second connection. - Verification: Determine that IUT resets the original of the duplicate connections, refuses to make the duplicate connection (OPEN FAILURE response received by LSD) and does not enter into the opening handshake for the duplicate connection. Success: IUT rejects the duplicate connection and does not enter into the opening handshake for that connection. Failure: The IUT fails to reject the duplicate connection. UNISYS Corporation 6 February 1987 -26- TM-WD-8801/206/00 TEST 36: MULTIPLEX DATA OVER CONNECTIONS USING THE SAME SEQUENCE NUMBERS ------- - Can the Implementation Under Test (IUT) multiplex data when the REF uses the same sequence number on two connections s - Action: The Laboratory Slave Driver opens three connections to the IUT and sends unique data over the three connections to the Remote Driver (RD). The Laborory Reference Implementation (REF) ensures that the the TCP segments on two of the connections have the same sequence numbers. - Verification: Determine that all the data sent over each connection is correctly delivered to the RD. Success: All the data sent over each connection is correctly delivered. Failure: The data sent over each connection is not correctly delivered. Test 37: IUT'S REFUSAL TO MAKE DUPLICATE CONNECTION ------- - Does the Implementation Under Test refuse to make a duplicate connection when it is actively opening? - Action: The Remote Driver (RD) makes a connection to the Laboratory Slave Driver (LSD). RD then attempts to open a second connection with the same 4-tuple (same source and destination ports). - Verification: Verify that the IUT refuses to make the duplicate connection by responding with TCP ERROR: CONNECTION ALREADY EXISTS or SYSTEM ERROR: REQUESTED SOURCE PORT IN USE. Success: IUT does not make a duplicate connection and does not allocate resources for a duplicate connection. Failure: IUT allocates resources for a duplicate connection or does not give proper response to the attempt to open the duplicate connection. UNISYS Corporation 6 February 1987 -27- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC5 --------------- Scenario BASIC5 tests the TCP Implementation Under Test (IUT) for basic and default security. It tests that the IUT: - allows the security of the connection to be set by the use of parameters in the open service requests - rejects a connection request with a wrong security level, - aborts the connection if a segment arrives with any mismatch of the security option. Tests 38 through 46 test basic security. Tests 47 through 50 test default security. Default security checks are those checks which both classified and unclassified hosts should perform. If the IUT does not pass Test 38 or Test 39 (the setting of security in the IUT Active Open and the IUT Passive Open), tests 40 through 46 are not executed. Test 38: IUT'S ABILITY TO SET SECURITY IN ITS ACTIVE OPEN ------- - Is the Implementation Under Test (IUT) able to set security in its Active Open s - Action: The Remote Driver (RD) opens a connection with the classification and protection parameters supplied for the IUT Active Open. The Laboratory Slave Driver (LSD) opens with the same security in its Passive Open. - Verification: Determine if the connection is opened success fully. If the connection is opened, determine that the security parameters have been set correctly. If the open service request does not return an OPEN ID, the response TCP ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED must be found. Success: Connection is successfully opened showing that the security parameters have been set correctly. If the connection is not established the response TCE ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED is found. Failure: Connection is not established and neither the response TCP ERROR: SEC/PREC NOT ALLOWED nor SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED is returned from the IUT. Connection is established but the parameters have not been set correctly. UNISYS Corporation 6 February 1987 -28- TM-WD-8801/206/00 Test 39: IUT'S ABILITY TO SET SECURITY PARAMETERS IN ITS PASSIVE OPEN ------- - Is the Implementation Under Test (IUT) able to set security in its Passive Open ? - Action: The Remote Driver (RD) uses the classification and protection parameters that it is given for an IUT Passive Open. The Laboratory Slave Driver (LSD) sets the same parameters in its Active Open and attempts to open a connection. - Verification: Determine that the connection is established. If a connection is opened successfully, then security fields in the TCP segments are checked to make sure that the IUT is setting the security from its input parameter. The Laboratory Reference Implementation (REF) collects these segments. If a connection is not established, check that the IUT open service response returned the response TCP ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED. Success: The connection is established. Analysis determines that the security parameters were set in the IUT Passive Open. Also, the connection is not established but the IUT returns either TCP ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED in response to the open service request. Failure: Although the connection is established, analysis reveals that the IUT is not setting security but merely matching peer's security. Also, the connection is not established but no proper security related response is received to the open service request. Test 40: IUT'S ABILITY TO SET SECURITY IN ITS SPECIFIED PASSIVE OPEN ------- - Is the Implementation Under Test (IUT) able to set security in its Specified Passive Opens - Action: The Remote Driver (RD) uses the classification CONFID and protection DIA as the parameters for an IUT Passive Open. The Laboratory Slave Driver (LSD) sets the same parameters in its Active Open and attempts to open a connection. - Verification: Determine that the connection is established. If a connection is opened successfully, the security fields in the TCP segments are checked to make sure that the IUT is setting security from its input parameter. The Laboratory Reference Implementation (REF) collects these segments. If a connection is not established, check that the IUT UNISYS Corporation 6 February 1987 -29- TM-WD-8801/206/00 open service reponse returned the response TCP ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED. Success: The connection is established and analysis deter mines that the security parameters were set in the IUT specified passive open. Also, the connection is not established but the IUT returns either TCP ERROR: SEC/PREC NOT ALLOWED or SYSTEM ERROR: REQUESTED PARAMETER NOT IMPLEMENTED in response to the open service request. Failure: Connection is established but analysis reveals that the IUT is not setting security but merely matching peer's security. Also, connection is not established and no proper security related response is received to the open service request. Test 41: SECURE IUT REJECTS CONNECTION TO UNSECURED PEER ------- - Does the secured Implementation Under Test (IUT) reject a connection to an unsecured peers - Action: The Remote Driver (RD) with security set in its Active Open opens to the Laboratory Reference Implementation (REF). The REF has passively opened without security set. - Verification: Check that the IUT returns an OPEN EAILURE and that the connection is not established. Success: The IUT successfully gets an OPEN FAILURE. Failure: The IUT-fails to get an OPEN FAILURE. Test 42: SECURE IUT REJECTS CONNECTION ATTEMPT OF UNSECURED PEER ------- - Does the secured Implementation Under Test (IUT) reject connection attempt of an unsecured host ? - Action: Laboratory Slave Driver (LSP) with no security actively opens to the IUT. The IUT has passively opened with security set. - Verification: Determine that no connection is established by checking for an OPEN FAILURE response from the Laboratory Reference Implementation (REF). Success: The REF gets an OPEN FAILURE or the IUT can not set security parameters. Failure: The connection is established. UNISYS Corporation 6 February 1987 -30- TM-WD-8801/206/00 Test 43: SECURITY OPTION PLACEMENT IN DATA SEGMENTS ------- - Is the Implementation Under Test (IUT) consistent in its security option placement when sending datas - Action: A secure connection is opened. Both the Laboratory Slave Driver (LSD) and the Remote Driver (RD) send data. - Verification: Determine that all the data sent by the LSD and the RD is correctly delivered by the other peer. Check the segment information collected by the Laboratory Reference Implementation (REF) to ensure that the correct security was placed on every segment. Success: All data is delivered and the security is correctly placed on each TCP segment. Failure: All data is not correctly delivered or the security fields are not correctly placed on every TCP segment. TEST 44: RESPONSE TO DATA WITH MISMATCHED SECURITY CLASS ------- - Does the Implementation Under Test (IUT) reset a connection on receiving data with a mismatched security class? - Action: A secure connection is established. The Laboratory Slave Driver (LSD) sends data to the Remote Driver (RD). The Laboratory Reference Implementation (REF) places a wrong security class on the data segments. - Verification: Determine that the IUT resets the connection by checking that the REF reports REMOTE ABORT. Check that the IUT reports SEC/PREC MISMATCH. Success: The IUT resets the connection and reports SEC/PREC MISMATCH. Failure: IUT fails to reset connection or does not report SEC/PREC MISMATCH. UNISYS Corporation 6 February 1987 -31- TM-WD-8801/206/00 TEST 45: RESPONSE TO DATA WITH MISMATCHED PROTECTION AUTHORITY ------- - Does the Implementation Under Test (IUT) reset a connection on receiving data with a mismatched security authority? - Action: A secure connection is established. The Laboratory Slave Driver (LSD) sends data to the Remote Driver (RD). The Laboratory Reference Implementation (REF) places an incorrect protection authority on the data segments. - Verification: Determine that the IUT resets the connection by checking that the REF reports REMOTE ABORT. Check that the IUT reports SEC/PREC MISMATCH. Success: The IUT resets the connection and reports SEC/PREC MIS MATCH. Failure: IUT fails to reset connection or does not report SEC/PREC MISMATCH. TEST 46: RESPONSE TO DATA WITH AN EXTRA PROTECTION AUTHORITY ------- - Does the Implementation Under Test (IUT) reset a connection on receiving data with an extra security protection authority? - Action: A secure connection is established. The Laboratory Slave Driver (LSD) sends data to the Remote Driver (RD). The Laboratory Reference Implementation (REF) places an extra protection authority on the data segments. - Verification: Determine that the IUT resets the connection by checking that the REF reports REMOTE ABORT. Check that the IUT reports SEC/PREC MISMATCH. Success: The IUT resets the connection and reports SEC/PREC MISMATCH. Failure: IUT fails to reset connection or does not report SEC/PREC MISMATCH. UNISYS Corporation 6 February 1987 -32- TM-WD-8801/206/00 TEST 47: USE OF SECURITY OPTION FOR UNCLASSIFIED CONNECTIONS ------- - Does the Implementation Under Test (IUT) use the security option for unclassified connection ? - Action: Laboratory Slave Driver (LSD) does a Passive Open with security set. The Remote Driver (RD) does an Active Open with no security set. - Verification: Check TCP segments collected by the Laboratory Reference Implementation (REF) to determine if IUT uses the security option at a default level for an unsecured connection. Ensure that the connection is not opened by looking for the OPEN FAILURE response from the IUT. Observation: IUT does or does not use the security option for unclassified connections. Failure: Test connection opened. TEST 48: RECOGNITION OF UNCLASS AND GENSER AS EQUIVALENT TO UNSECURE ------- - Does the unsecured Implementation Under Test (IUT) connect with peer with security of UNCLASS and GENSERs - Action: Laboratory Slave Driver (LSD) does a passive open with security set to UNCLASS and GENSER. The Remote Driver (RD) does an active open with no security setting. - Verification: Determine that the connection is opened by looking for OPEN SUCCESS response from the IUT. Success: Connection established. Failure: Connection not established. UNISYS Corporation 6 February 1987 -33- TM-WD-8801/206/00 TEST 49: UNSECURED IUT RESPONSE TO CONNECTION ATTEMPT BY SECURE HOST ------- - Does the IUT with no security reject an Active Open from a peer with security sets - Action: Remote Driver (RD) does a Passive Open with no security set. The Laboratory Slave Driver (LSD) does an Active Open with security set to CONFID and DIA. - Verification: Determine that the IUT rejects the connection by searching for OPEN FAILURE response reported by LSD. Success: Connection is not established. Failure: Connection established. TEST 50: UNSECURED IUT RESPONSE TO DATA MARKED WITH CLASSIFIED SECURITY ------- - Does the Implementation Under Test (IUT) reset connection when finding data marked with security higher than unclassifieds - Actions: A connection is established with no security settings. The Laboratory Slave Driver (LSD) sends data to the Remote Driver (RD). The Laboratory Reference Implementation (REF) places a classified security option on a data segment. - Verification: Determine that the IUT resets the connection and reports SEC/PREC MISMATCH to the Remote Driver. Success: The IUT correctly resets connection on finding incorrectly marked security on data. Failure: The IUT fails to recognize wrong security marking on data and does not reset the connection. UNISYS Corporation 6 February 1987 -34- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario BASIC6 --------------- Scenario BASIC6 tests the TCP implementation for its ability to perform the ALLOC service request correctly in the EXPLICIT mode under control of the Central Driver. ________________________________________ TEST 51: ALLOC ------- - Can the Implementation Under Test (IUT) perform the ALLOC service request correctly ? - Action: Remote Driver (RD) and Laboratory Slave Driver (LSD) establish a connection. The RD instructs the IUT it has allocated a specified buffer size for data. Then the LSD sends data equal to twice that buffer size to the RD. - Verification: Determine that the amount of data delivered to the RD by the IUT is not greater than that specified in the ALLOC request. If all the sent data is acknowledged prior to the RD sending another ALLOC, the amount of data delivered must be equal to or less than the buffer size specified in the ALLOC. If it is necessary for the RD to send a second ALLOC for all the sent data to be acknowledged, then results are determined by examining the TCP segments collected by the Laboratory Reference Implementation (REF). The segments are analyzed to make sure that no more data than was specified in the ALLOC was acknowledged before the IUT receive window was set to zero. Success: The IUT delivers data equal to or less than the ALLOC request. Failure: The IUT delivers more data than ALLOC specifies. Inconclusive: Analysis cannot be done to determine IUT's performance. UNISYS Corporation 6 February 1987 -35- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario FULL1 -------------- Scenario FULL1 tests the TCP implementation of maximum segment size option, basic retransmission and ULP timeout. ________________________________________ Test 52: MAXIMUM SEGMENT SIZE OPTION ------- - Does the Implementation Under Test (IUT) use the maximum segment size (MSS) option and respond correctly to its peer's maximum transmission units - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The Laboratory Reference Implementation (REF) places a low MSS on its opening segment. The RD sends data. - Verification: Check segment data collected by the REF to see if IUT uses the MSS option. Examine the segment data to see if the IUT sends any data segment with a length greater than the MSS specified by the REF. Success: The IUT sends segments which do not exceed the maximum segment size specified by the REF. Failure: IUT sends segments which exceed the maximum segment size specified by the REF. Observation: Observation is made as to whether the IUT uses the MSS-option. TEST 53: RETRANSMISSION AFTER ACKNOWLEDGMENT OF DATA. ------- - Does the Implementation Under Test (IUT) stop retransmitting promptly after receiving acknowledgment of datas - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends data. The Laboratory Slave Driver (LSD) withholds acknowledgments until it has received several transmissions of the oldest data. - Verification: Examine the TCP segments collected by the REF. Count the number of retransmissions of data sent after the data is acknowledged. Ensure that the REF receives no more than two retransmissions after it has acknowledged data. Success: The IUT does not retransmit after data is acknowledged. UNISYS Corporation 6 February 1987 -36- TM-WD-8801/206/00 Failure: IUT does not stop retransmitting promptly after data is acknowledged. Test 54: RETRANSMISSION AFTER ACKNOWLEDGMENT OF SYN AND FIN ------- - Does the Implementation Under Test (IUT) stop retransmitting promptly after its SYN and FIN are acknowledgeds - Action: The Laboratory Slave Driver (LSD) actively opens a connection to the Remote Driver (RD). The Laboratory Reference Implementation (REF) withholds acknowledgments of the IUT's SYN segment until it is transmitted several times. Then the RD closes the connection. The REF withholds retransmissions until the IUT's FIN segment is transmitted several times. - Verification: Examine the TCP segments collected by the REF. Count the number of times the IUT SYN segment is retransmitted after it is acknowledged. Count the number of times the IUT FIN segment is retrans mitted after it is acknowledged. Ensure that the REF receives no more than two retransmissions after it acknowledges SYN or FIN. Success: The IUT does not retransmit its SYN and FIN segments after they are acknowledged. Failure: The IUT does not stop retransmitting its SYN and FIN segments promptly after they are acknowledged. TEST 55: IMPLEMENTATION OF ULP TIMEOUT SERVICE IN ACTIVE OPEN ------- - Does the Implementation Under Test (IUT) implement ULP timeout when timeout is specified in its Active Open ? - Action: Find the number of retransmissions by the IUT when the IUT's default ULP timeout occurs or when the default timeout of two minutes suggested by MIL-STD 1778 is reached. This is done by opening a connection and having the Remote Driver (RD) send data. The Laboratory Reference Implementation (REF) does not acknowledge the data. When the connection is aborted (or after 2 minutes), check the TCE segments collected by the REF and count the number of retransmissions for one data element. This becomes the default number of retransmissions. The Remote Driver (RD) does an Active Open with a small ULP timeout and a timeout action of terminate set. The RD then sends data. The Laboratory Reference Implementation (REF) withholds acknowledgments. The test continues until the connection terminates or 2 minutes pass. UNISYS Corporation 6 February 1987 -37- TM-WD-8801/206/00 - Verification: Check the TCP segments collected by the REF. Count the number of times a data element is retransmitted. The number of retransmissions must be significantly smaller than the default number of retransmissions. Success: IUT implements ULP timeout if it resets the connection and the number of data retransmissions is significantly smaller than the default number of retransmissions. Failure: IUT does not implement ULP timeout. The IUT does not reset the connection or, if the connection is reset, the number of IUT retransmissions indicate that the abort was caused by the TCP default rather than the prescribed ULP timeout. TEST 56: IMPLEMENTATION OF ULP TIMEOUT SERVICE IN SEND ------- - Does the Implementation Under Test (IUT) implement ULP timeout when timeout specified in its Sends - Action: The Remote Driver (RD) and the Laboratory Slave Driver (LSD) establish a connection. The RD sends data with a small ULP timeout and a timeout action of terminate set. The Laboratory Reference Implementation (REF) withholds acknowledgments. The test continues until the connection terminates or 2 minutes pass. - Verification: Check the TCP segments collected by the REF. Count the number of times a data element is retransmitted. The number of retransmissions must be significantly smaller than the default number of retransmissions (determined in Test 55). Success: IUT implements ULP timeout if it resets the connections and the number of data retransmissions is significantly smaller than the default number of retransmissions. Failure: IUT does not implement ULP timeout. The IUT does not reset the connection or, if the connection is reset, the number of IUT retransmissions indicate that the abort was caused by the TCP default rather than the prescribed ULP timeout. UNISYS Corporation 6 February 1987 -38- TM-WD-8801/206/00 TEST 57: IMPLEMENTATION OF ULP TIMEOUT SERVICE IN PASSIVE OPEN ------- - Does the Implementation Under Test (IUT) implement ULP timeout when timeout specified in its Passive Opens - Action: The Remote Driver (RD) does a Passive Open with a ULP timeout set. The Laboratory Slave Driver (LSD) performs an Active Open and a connection is established. The RD then sends data. The Laboratory Reference Implementation (REF) withholds acknowledgments. The test continues until the connection terminates or 2 minutes pass. - Verification: Check the TCP segments collected by the REF. Count the number of times a data element is retransmitted. The number of data retransmissions must be significantly smaller than the default number of retransmissions (determined in Test 55). Success: IUT implements ULP timeout if it resets the connections and the number of data retransmissions is significantly smaller than the default number of retransmissions. Failure: IUT does not implement ULP timeout. The IUT does not reset the connection or, if the connection is reset, the number of IUT retransmissions indicate that the abort was caused by the TCP default rather than the prescribed ULP timeout. TEST 58: IMPLEMENTATION OF ULP TIMEOUT NOTIFY SERVICE ------- - Does the Implementation Under Test (IUT) implement a ULP timeout where the timeout action is notifys - Action: The Remote Driver (RD) does an Active Open with an ULP notify timeout set and establishes a connection with the Laboratory Slave Driver (LSD). The RD sends data. The Laboratory Reference Implementation (REF) withholds acknowledgments on the data. The test continues until the connection terminates or 2 minutes pass. - Verification: Check that the RD reports the TCP ERROR message ULP NOTIFY Success: IUT implements ULP notify. Failure: IUT does not implements ULP notify. UNISYS Corporation 6 February 1987 -39- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario FULL2 -------------- Tests the TCP implementation of zero window, urgent data, and pushed data. ------------------------------------------ Test 59: RESPONSE TO ZERO WINDOW ------- - Does the Implementation Under Test (IUT) correctly respond to a peer's zero windows - Action: A connection is established between the Laboratory Slave Driver (LSD) and the Remote Driver (RD). The RD sends data to the LSD. The Laboratory Reference Implementation (REF) acknowledges the first data segment but announces a zero window in this acknowledgment. - Verification: Check the TCP segments collected by the REF for the amount of data sent by the IUT while the REF had a zero window. The IUT should not send more than one byte of data while the REF has a zero window. Success: The IUT sends no segment of-length greater than 1 while its peer has a zero window. Failure: The IUT sends a segment of length greater than 1 while its peer has a zero window. TEST 60: IMPLEMENTATION OF URGENT SERVICE ------- - Does the Implementation Under Test (IUT) set the urgent flag and urgent pointer when requested to send urgent datas - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends urgent data to the LSD. - Verification: Check the TCP segment information collected by the Laboratory Reference Implementation (REF) to ensure that the IUT sets the urgent flag on every segment of the data. Also check that the value of the urgent pointer on these segments equals the amount of urgent data that exists between the first sequence number of the segment to the end of the urgent data. UNISYS Corporation 6 February 1987 -40- TM-WD-8801/206/00 Success: The IUT correctly sets the urgent flag and urgent pointer on urgent data. Failure: The IUT does not set the urgent flag or urgent pointer correctly on urgent data. Test 61: URGENT SERVICE WHEN PEER HAS ZERO WINDOW ------- - Does the Implementation Under Test (IUT) handle urgent correctly when its peer has a zero window s - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends normal data and then urgent data to the LSD. The Laboratory Reference Implementation (REF) sets its receive window to zero when it acknowledges the first IUT segment. The REF opens its window again later in the data transfer. - Verification: Check the TCP segments collected by the REF. Ensure that IUT sends segment while the REF is showing a zero window with the urgent flag set, the value of the urgent pointer set to the number of bytes of urgent data to be sent, and a length no longer than 1. Success: The IUT sends one byte probe segmensts and sets the urgent flag and urgent pointer correctly in them. Failure: The IUT does not send one byte probe segments although urgent data is present, or it does not set the urgent flag or urgent pointer correctly in the probe segments it sends. Test 62: DIFFERENTIATION BETWEEN URGENT AND NON-URGENT DATA ------- - Is the Implementation Under Test (IUT) able to deliver urgent data? - Action: To make sure that the IUT can differentiate and deliver urgent and non-urgent data. The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The LSD sends 1 byte of urgent data to the RD. It then sends the RD some bytes of non-urgent data. - Verification: Evaluate the DELIVER responses from the RD. The urgent data must be delivered in a separate DELIVER from the non-urgent data. UNISYS Corporation 6 February 1987 -41- TM-WD- 801/206/00 Success: The RD DELIVER responses show the 1 byte of urgent data delivered separately from the subsequent non urgent data. Failure: The RD DELIVER responses do not show the 1 byte of urgent data delivered separately from the subsequent non-urgent data. Test 63: PUSH SERVICE WHEN NOT REQUESTED ------- - Does the Implementation Under Test (IUT) push data when not requested to do so? - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends data to the LSD. lt does not request that the data be pushed. - Verification: Examine the TCP segments collected by the REF. The Push flag should not be set on any segments sent by the IUT except possibly the last data segment. (It is permissible for the IUT to set a push flag on the very last data segment sent). Success: The IUT correctly does not push any data or IUT only pushes the last data segment. Failure: The IUT incorrectly sets push flags on data not requested to be pushed. Test 64: PUSH SERVICE ON REQUEST ------- - Is the Implementation Under Test (IUT) able to push data on requests - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends some bytes of data with a push indication. It then sends data without the push indication. - Verification: Examine the TCP segments collected by the Laboratory Reference Implementation (REF). The first data segment the IUT sends should have the push flag set and should contain at least the number of bytes of data sent with the push indication. The only other segment which could have a valid push flag is the last data segment. Success: The IUT correctly sets push flag only on pushed data and possibly the last data segment. Failure: The IUT fails to set push flag on pushed data or sets push flag on unpushed data. UNISYS Corporation 6 February 1987 -42- TM-WD-8801/206/00 Observation: The IUT allows it Upper Level Protocol to request rather than command push service. This observation is made when the segment with the push flag carries more than the pushed data. UNISYS Corporation 6 February 1987 -43- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario FULL3 -------------- Tests whether the TCP implementation does correct reset processing. It tests the common reset conditions. ________________________________________ Test 65: RESPONSE TO CONNECTION REFUSAL ------- - Does the Implementation Under Test (IUT) respond correctly to connection refusals - Action: The Remote Driver (RD) actively opens. There is no listening process at the destination port of its Active Open. - Verification: Determine that the RD receives an OPEN FAILURE response from the IUT. Success: The IUT reports an OPEN FAILURE. Failure: The IUT does not report an OPEN FAILURE . Test 66: PARTIAL RESET PRIOR TO CONNECTION ESTABLISHMENT ------- - Does the Implementation Under Test (IUT) continue listening after receiving a reset during connection establishments - Action: The Remote Driver (RD) initiates a Passive Open. The Laboratory Slave Driver (LSD) actively opens. On receipt of the IUT's SYN ACK, the Laboratory Reference Implementation (REF) resets the connection. The LSD attempts to open the connection again. - Verification: Determine that the LSD reports an OPEN SUCCESS response from the REF on the second connection. Success: The second connection is established. Failure: The second connection cannot be established. UNISYS Corporation 6 February 1987 -44- TM-WD-8801/206/00 Test 67: RESPONSE TO RESET RCVD WHILE SENDING DATA OVER CONNECTION ------- - Does the IUT abort with the correct responses when its peer aborts while the IUT is sending data over a connections - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The RD sends data. When the Laboratory Reference Implementa tion (REF) receives the first IUT data segment, the REF resets the connection. - Verification: Determine that after the reset, the RD reports the response TERMINATE: REMOTE ABORT from the IUT and the LSD reports the response TERMINATE: SERVICE FAILURE from the REF. Success: The correct TERMINATE responses are reported from the IUT and the REF. Failure: The correct TERMINATE responses are not received from the IUT and the REF. TEST 68: RESET FORMAT RESPONDING TO ACTIVE OPEN WITHOUT LISTENING PORT ------- - Does the Implementation Under Test (IUT) send a correct reset segment on receipt of a SYN for a non-existent ports - Action: The Laboratory Slave Driver (LSD) initiates an Active Open to a port on the IUT without a listening process. - Verification: Check the TCP segments collected by the Laboratory Reference Implementation (REF). The IUT reset segment must have the format: sequence number = 0, acknowledgment number = the sequence number of the REF's SYN(segment<s+1>s),and the ACK and RESET flags set. Success: IUT uses correct reset segment format. Failure: The IUT uses incorrect reset segment format. UNISYS Corporation 6 February 1987 -45- TM-WD-8801/206/00 TEST 69: RESET FORMAT RESPONDING TO ACTIVE OPEN WITH DATA WITHOUT ------- LISTENING PORT - Does the Implementation Under Test (IUT) send a correct reset when it receives the SYN of an Active Open with Data for a non-existent ports - Action: The Laboratory Slave Driver (LSD) initiates an Active Open with Data to a port on the IUT without a list process. - Verification: Check the TCP segments collected by the Laboratory Reference Implementation (REF). The IUT reset segment must have the format: sequence number = 0; acknowledgment number = the sequence number of the last byte of data on the REF's syn segment, and the ACK and RESET flags set. If the IUT has not passed the Active Open with Data test, the reset segment must have the expected format of Test 68. Success: IUT uses correct reset segment format. Failure: IUT uses incorrect reset segment format. TEST 70: RESET FORMAT ON RECEIPT OF INVALID SEGMENT WITH ACK SET ------- - Does the Implementation Under Test (IUT) send the correct reset format on receiving a segment with ACK set for a non-existent port? - Action: The Laboratory Slave Driver (LSD) initiates an Active Open to a port on the IUT without a listening process. The Laboratory Reference Implementation (REF) omits the SYN from its initial segment but sets the acknowledgment flag and puts a value in the acknowledgment number. - Verification: Check the TCP segments collected by the Laboratory Reference Implementation. The IUT's reset must have the format: sequence number = acknowledgment number on the REF's initial segment, and the RESET flag set. The ACK flag must not be set. Success: IUT uses correct reset segment format. Failure: The IUT uses incorrect reset segment format. UNISYS Corporation 6 February 1987 -46- TM-WD-8801/206/00 TEST 71: RESET FORMAT ON RECEIPT OF INVALID SEGMENT WITH SYN AND ACK SET ------- - Does the Implementation Under Test (IUT) send a correct reset on receiving a SYN segment with ACK set for a port in LISTEN state? - Action: The Remote Driver (RD) does a Passive Open. The Laboratory Slave Driver (LSD) does an Active Open. The Laboratory Reference Implementation (REF) places an acknowledgment on its SYN segment. - Verification: Determine that no connection is established. Check that an OPEN FAILURE is reported from the REF. If the connection attempt correctly fails, check the TCP segments collected by the REF. The IUT reset must have the following format: sequence number = acknowledgment number on the REF's initial segment, and the RESET flag set. The ACK flag must not be set. Success: IUT resets and uses correct reset format. Failure: The IUT establishes connection after receiving invalid SYN segment or the IUT uses incorrect reset segment format. Test 72: NO RESET ON RECEIPT OF SEGMENT WITH BAD ACK ------- - Does the Implementation Under Test (IUT) erroneously perform a reset on receiving a segment with a bad acknowledgment number? - Action: The Laboratory Slave Driver (LSD) and the Remote Driver (RD) establish a connection. The LSD sends data to the the RD. The Laboratory Reference Implementation (REF) places an incorrect acknowledgment number on an outgoing segment. The REF retransmits the bad segment three times and then corrects it. - Verification: Determine that the IUT does not terminate the connection. If the connection is not terminated, check the TCP segments collected by the REF to determine that the IUT has transmitted empty acknowledgments. These acknowledgments must have the format: sequence number = IUT's current segment sequence number, acknowledgment number = the sequence number of the REF's segment (not incremented to acknowledge any of the data on the bad segment) and the ACK flag set. UNISYS Corporation 6 February 1987 -47- TM-WD-8801/206/00 Success: The IUT sends empty acknowledgments until it receives the corrected segment. The connection is not reset. Failure: The IUT resets the connection on receiving the bad data segment or the IUT acknowledges data segments with bad acknowledgment number. UNISYS Corporation 6 February 1987 -48- TM-WD-8801/206/00 TCP SCENARIOS AND TEST DESCRIPTIONS Scenario QUAL1 -------------- QUAL1 tests the TCP implementation to determine how many TCE it is able to provide. The scenario tests up to 145 ____________________________ Test 73: NUMBER OF TCP CONNECTIONS RESOURCES CAN SUPPORT ------- - Determine the maximum number of TCP connections provided by the Implementation Under Test(IUT). - Action: The Laboratory Slave Driver (LSD) performs 12 passive opens. The Remote Driver (RD) is instructed to consecutively open 12 active connections to each of these ports until it runs out of resources. - Verification: Count every connection where an OPEN SUCCESS is the response received on the IUT Active Open Request. When the response TCP ERROR: INSUFFICIENT RESOURCES is found or 144 connections are opened, the test is ended. The total number of connections the IUT can support equals the number of connections the RD has opened plus the connection for the command channel. Observation: The total number of connections the IUT is able to support is noted. If the IUT is able to support more than 145 connections (it does not run out of resources), this observation is noted.