This message flow is intended to generate simple IPv4 or IPv6 FTP traffic between the MN and the Network Host node. The flow simulates an FTP session that retrieves a file from a server using active mode.
When control plane protocols are used, the initial TCP connection for the FTP control messages is established after Data Start Delay timer expires. The MN initiates the TCP connection, using the Client Port and Server Port defined in the message flow.
The message flow begins to execute the following steps as soon as the TCP connection is established.
The server begins the message sequence by notifying the client that it is ready to receive requests.
The client issues a USER request to begin the login, and the server responds with a request for the password.
The client responds with a PASS and the password, and the server responds with a confirmation that the login succeeded.
The client issues a PWD command, and the server responds with the current directory. See the FTP Mainflow RETR Command with PWD on server side message flow for an example of using a command to respond to a PWD command from a device other than the MN.
The client issues an EPRT request with the protocol, IP address, and specified port to force the server into active mode. The server responds with an acknowledgement that active mode will be used.
NOTE: The protocol, IP address, and port included in the EPRT command can be defined in the response message as shown in the diagram. This information, however, will be overwritten during test execution by the IP version used in the test, the IP address of the MN, and the Client Port defined in the subflow. |
The client issues a RETR request to begin the file retrieval, and the server responds with a confirmation. It is assumed that the client is presented with the correct directory at login.
At this point in the message flow, the FTP Data Transfer Subflow is executed. It establishes the TCP connection for the data transfer using the ports defined in the subflow (see step 5), and sends one 78-byte packet to the client: a payload of 76 Zs terminated with a CR-LF pair. The mainflow waits for a TRANS_COMPLETE event from the subflow, indicating that the subflow transaction completed, before continuing.
The server notifies the client that the transfer is complete, and that the data connection will be closed.
The Stop Subflow control is inserted at this point to release the TCP connection used for the data transfer.
The client issues a QUIT request to terminate the control session, the server responds with a confirmation, and the initial TCP connection is closed.
In the default configuration, the message flow will repeat once per second while the MN session is active. This assumes that the entire flow can be completed in one second. The flow must complete before the next iteration can begin, even if this results in a slower transaction rate.
Since FTP is a text-based protocol, you can easily modify the request and response messages. You can also modify the data transfer payload or import a file to be used in the data transfer.
You can specify that random port numbers, in the IANA specified dynamic range of 49152 — 65535, be used by the client for the FTP control session by entering a 0 for the Client Port. Random port numbers can be used for both the client and server in the FTP Data Transfer Subflow.