################################################################################### # README file for QualNet.3.9 SCTP module release_2.0 #################################################################################### Outline ------------- I. How to Install QualNet(3.9) SCTP module II. Which environments QualNet SCTP module works III. How to use QualNet SCTP module IV. How much of SCTP protocol(RFC 2960) is implemented V. Which extensions of SCTP protocol is implemented VI. Where/how to report the bugs I. How to Install QualNet(3.9) SCTP module ------------------------------------------------------------ QualNet(3.9) SCTP module is provided as a patch to the QualNet(3.9) source files. The patch should be applied following the steps below. 1. First obtain/download QualNet(3.9) source files from Scalable Networks: http://www.scalable-networks.com/ 2. untar QualNet(3.9) source files: % gtar zxvf qualnet-3.9-university-MANET-QoS.tar.gz 2. Request the patch (by email from aydin@cis.udel.edu) qualnet3.9_sctp_module_release_2.0_apr_17_06.patch 3. At the parent directory of the untar'd QualNet(3.9) source files, do: % patch -p0 < qualnet3.9_sctp_module_release_2.0_apr_17_06.patch 4. Follow QualNet instructions on how to do 'make' and run QualNet. II. Which environments QualNet SCTP module works ------------------------------------------------------------ QualNet SCTP module has been compiled and tested under in Linux Redhat 9 with gcc3.2 and glibc2.3.2. III. How to use QualNet SCTP module ------------------------------------------------------------ There are sample .config and .app files for single and multi-homed sctp end points under QUALNET_HOME/bin/ directory. You can use these sample files to create your own .app and .config files. Sample .config file includes SCTP parameters to be tuned. Sample .app file runs simple application(s) called GENERIC/FTP/SCTP (or GENERIC/FTP/PRSCTP). The source file(s) for GENERIC/FTP/SCTP (and GENERIC/FTP/PRSCTP) is located under QUALNET_HOME/application directory. IV. How much of SCTP protocol(RFC 2960) is implemented ------------------------------------------------------------ QualNet SCTP module is implemented based on RFC 2960 and Stream Control Transmission Protocol (SCTP) Implementor's Guide, draft-ietf-tsvwg-sctpimpguide-10.txt. QualNet SCTP module supports the following parts of the RFC 2960. - Normal Establishment of an Association: Mostly Section 5.1 of the RFC including Associate API (Section 10.1.B) - User Data Transfer: Section 6 of the RFC, assuming mostly for one-way application data traffic. Send API (Section 10.1.E) is implemented. Receive API (Section 10.1.G) is not implemented. Instead, the SCTP receiver assumes that receiving application is always ready to consume data and drops the data chunks. The Fragmentation (Section 6.9) and Bundling (Section 6.10) of multiple data chunks are not considered. - Congestion Control: Section 7 of the RFC including Fast Recovery algorithm (i.e., Section 2.8 of draft-ietf-tsvwg-sctpimpguide-10.txt) - Path MTU Discovery (Section 7.3) is not included. - Fault Management: Most of Section 8 of the RFC for endpoint and path failure detection with heartbeats. - Termination of Association: Only Section 9.1 of the RFC with Abort API (Section 10.1.D) is implemented. In addition, QualNet SCTP module is compared and corrected against the related sections of draft-ietf-tsvwg-sctpimpguide-10.txt. In particular, - Sections 2.5, 2.7, 2.8, 2.9, 2.10, 2.13, 2.17, 2.19, 2.20, 2.24, 2.25, 2.30, and 2.31 are included. - Section 2.14 on the Max Burst parameter is not considered yet. - Section 2.15 regarding window probes is under consideration. some other notes: - Multi-homing: "To be able to use multi-homing, make sure all networks are reachable from all the sources" (see rule 7-2 in p223 of SCTP book on the affect of source address selection). In this implementation, SCTP sender always puts the first ip address in the list of sender's ip addresses as the source address of the ip packet from (data) sender to the (data) receiver. - Fragmentation and re-assembly are not implemented. For now, if a data chunk bigger than the association path mtu is handed to SCTP by the application layer, SCTP aborts. - Though both ends of the association "can" send data chunks, QualNet SCTP module assumes a one-way data traffic. Hence, the code may "break-down" for two-way traffic. - Bundling: is implemented for rtxed data chunks, but bundling of new data chunks and bundling of a sack chunk with data chunks (for two-way data traffic) are not implemented. "No Bundling" option is not considered either. - Unordered data transmission is not implemented. V. Which extensions of SCTP protocol is implemented ------------------------------------------------------------ - "Dynamic Address Reconfiguration" (addip09.txt) extension is implemented to allow dynamic add/delete/set primary ip address(es) after association setup. - Partial Reliable SCTP (PR-SCTP, RFC 3758) is also implemented. - section 3.5.C4 is not implemented exactly. i.e. the checking to see if Forward Tsn Chunk exceeds the path mtu is not done.. but this should be a OK, considering max. (feasible) streams an application would use, is not too much (hence forward TSN chunk size would not be too big). - PR-SCTP with infinite Data source is not supported. VI. Where/how to report the bugs ------------------------------------------------------------ QualNet SCTP module is developed and maintained by Ilknur Aydin Degas Networking Group Dept. of Computer & Information Sciences University of Delaware Newark, DE 19716 U.S.A email: aydin@cis.udel.edu web: http://www.cis.udel.edu/~aydin The web site for the QualNet SCTP module is at ************************************ http://degas.cis.udel.edu/SCTP/ ************************************ There is a mailing list to communicate the bugs reports, comments, support, and release information. To subscribe to the mailing list and/or view the archives please visit: https://udel.edu/mailman/listinfo/sctp-qualnet-module You can send your bug reports/comments to sctp-qualnet-module@UDel.Edu. We appreciate and value your help. Thanks! ################################################################################### # README file for QualNet.3.6.1 SCTP module release_1.1 #################################################################################### Outline ------------- I. How much of SCTP protocol is implemented II. Which extensions of SCTP protocol is implemented III. How to use QualNet SCTP module IV. Where/how to report the bugs I. How much of SCTP protocol is implemented ------------------------------------------------------------ QualNet SCTP module is implemented based on RFC 2960 and Stream Control Transmission Protocol (SCTP) Implementor's Guide, draft-ietf-tsvwg-sctpimpguide-10.txt. QualNet SCTP module supports the following parts of the RFC 2960. - Normal Establishment of an Association: Mostly Section 5.1 of the RFC including Associate API (Section 10.1.B) - User Data Transfer: Section 6 of the RFC, assuming mostly for one-way application data traffic. Send API (Section 10.1.E) is implemented. Receive API (Section 10.1.G) is not implemented. Instead, the sctp receiver assumes that receiving application is always ready to consume data and drops the data chunks. The Fragmentation (Section 6.9) and Bundling (Section 6.10) of multiple data chunks are not considered. - Congestion Control: Section 7 of the RFC including Fast Recovery algorithm (i.e., Section 2.8 of draft-ietf-tsvwg-sctpimpguide-10.txt) - Path MTU Discovery (Section 7.3) is not included. - Fault Management: Most of Section 8 of the RFC for endpoint and path failure detection with heartbeats. - Termination of Association: Only Section 9.1 of the RFC with Abort API (Section 10.1.D) is implemented. In addition, QualNet SCTP module is compared and corrected against the related sections of draft-ietf-tsvwg-sctpimpguide-10.txt. In particular, - Sections 2.5, 2.7, 2.8, 2.9, 2.10, 2.13, 2.17, 2.19, 2.20, 2.24, 2.25, 2.30, and 2.31 are included. - Section 2.14 on the Max Burst parameter is not considered yet. - Section 2.15 regarding window probes is under consideration. some other notes: - Multi-homing: "To be able to use multi-homing, make sure all networks are reachable from all the sources" (see rule 7-2 in p223 of SCTP book on the affect of source address selection). In this implementation, SCTP sender always puts the first ip address in the list of sender's ip addresses as the source address of the ip packet from (data) sender to the (data) receiver. - Fragmentation and re-assembly are not implemented. For now, if a data chunk bigger than the association path mtu is handed to SCTP by the application layer, SCTP aborts. - Though both ends of the association "can" send data chunks, QualNet sctp module assumes a one-way data traffic. Hence, the code may "break-down" for two-way traffic. - Bundling: is implemented for rtxed data chunks, but bundling of new data chunks and bundling of a sack chunk with data chunks (for two-way data traffic) are not implemented. "No Bundling" option is not considered either. - Unordered data transmission is not implemented. II. Which extensions of SCTP protocol is implemented ------------------------------------------------------------ - "Dynamic Address Reconfiguration" (addip09.txt) extension is implemented to allow dynamic add/delete/set primary ip address(es) after association setup. III. How to use QualNet SCTP module ------------------------------------------------------------ There are sample .config and .app files for single and multi-homed sctp end points under QUALNET_HOME/bin/ directory. You can use these sample files to create your own .app and .config files. Sample .config file includes SCTP parameters to be tuned. Sample .app file runs a simple application called GENERIC/FTP/SCTP, the source file for GENERIC/FTP/SCTP is under QUALNET_HOME/application directory. IV. Where/how to report the bugs ------------------------------------------------------------ QualNet SCTP module is developed and maintained by Ilknur Aydin Degas Networking Group Dept. of Computer & Information Sciences University of Delaware Newark, DE 19716 U.S.A email: aydin@cis.udel.edu web: http://www.cis.udel.edu/~aydin There is a mailing list to communicate the bugs reports, comments, support, and release information. To subscribe to the mailing list and/or view the archives please visit: https://udel.edu/mailman/listinfo/sctp-qualnet-module You can send your bug reports/comments to sctp-qualnet-module@UDel.Edu. We appreciate and value your help. Thanks! ################################################################################### # README file for QualNet.3.6.1 SCTP module release_1.0 #################################################################################### Outline ------------- I. How much of SCTP protocol is implemented II. Which extensions of SCTP protocol is implemented III. How to use QualNet SCTP module IV. Where/how to report the bugs ? I. How much of SCTP protocol is implemented ------------------------------------------------------------ QualNet SCTP module is implemented based on RFC 2960 and Stream Control Transmission Protocol (SCTP) Implementor's Guide, draft-ietf-tsvwg-sctpimpguide-10.txt. QualNet SCTP module supports the following parts of the RFC 2960. - Normal Establishment of an Association: Mostly Section 5.1 of the RFC including Associate API (Section 10.1.B) - User Data Transfer: Section 6 of the RFC, assuming mostly for one-way application data traffic. Send API (Section 10.1.E) is implemented. Receive API (Section 10.1.G) is not implemented. Instead, the sctp receiver assumes that receiving application is always ready to consume data and drops the data chunks. The Fragmentation (Section 6.9) and Bundling (Section 6.10) of multiple data chunks are not considered. - Congestion Control: Section 7 of the RFC including Fast Recovery algorithm (i.e., Section 2.8 of draft-ietf-tsvwg-sctpimpguide-10.txt) - Path MTU Discovery (Section 7.3) is not included. - Fault Management: Most of Section 8 of the RFC for endpoint and path failure detection with heartbeats. - Termination of Association: Only Section 9.1 of the RFC with Abort API (Section 10.1.D) is implemented. In addition, QualNet SCTP module is compared and corrected against the related sections of draft-ietf-tsvwg-sctpimpguide-10.txt. In particular, - Sections 2.5, 2.7, 2.8, 2.9, 2.10, 2.13, 2.17, 2.19, 2.20, 2.24, 2.25, 2.30, and 2.31 are included. - Section 2.14 on the Max Burst parameter is not considered yet. - Section 2.15 regarding window probes is under consideration. some other notes: - Fragmentation and re-assembly are not implemented. For now, if a data chunk bigger than the association path mtu is handed to SCTP by the application layer, SCTP aborts. - Though both ends of the association "can" send data chunks, QualNet sctp module assumes a one-way data traffic. Hence, the code may "break-down" for two-way traffic. - Bundling: is implemented for rtxed data chunks, but bundling of new data chunks and bundling of a sack chunk with data chunks (for two-way data traffic) are not implemented. "No Bundling" option is not considered either. - Unordered data transmission is not implemented. II. Which extensions of SCTP protocol is implemented ------------------------------------------------------------ - "Dynamic Address Reconfiguration" (addip09.txt) extension is implemented to allow dynamic add/delete/set primary ip address(es) after association setup. III. How to use QualNet SCTP module ------------------------------------------------------------ There are sample .config and .app files for single and multi-homed sctp end points under QUALNET_HOME/bin/ directory. You can use these sample files to create your own .app and .config files. Sample .config file includes SCTP parameters to be tuned. Sample .app file runs a simple application called GENERIC/FTP/SCTP, the source file for GENERIC/FTP/SCTP is under QUALNET_HOME/application directory. IV. Where/how to report the bugs ? ------------------------------------------------------------ QualNet sctp module is developed and maintained by Ilknur Aydin Dept. of Computer & Information Sciences University of Delaware Newark, DE 19716 USA email: aydin@cis.udel.edu web: http://www.cis.udel.edu/~aydin We appreciate and value your help. Please report any bugs to aydin@cis.udel.edu. Thanks!