SNALINK allows TCP⁄IP to send and receive packets using SNA sessions instead of dedicating physical network hardware (such as a channel-to-channel adapter or channel connection to a 3745/46 Communication Controller).
Prior to NCP V7R3, NCP did not support cross-channel native IP transmission of the transport PDUs associated with RIP traffic. NCP expects these PDUs to be carried in SNA frames. SNALINK is therefore still required for installations where dynamic routing is performed with the NCP (via NCPROUTE). See z/OS Communications Server: IP Configuration Reference for more information.
SNALINK allows an installation to multiplex SNA and IP traffic over the same I⁄O subchannels, rather than requiring separate subchannels dedicated to VTAM® and TCP⁄IP. While such multiplexing capability may be desirable at some installations, the native TCP⁄IP CTC and 3745/46 device drivers will likely outperform SNALINK connections. Interaction with the SNALINK address space is very CPU-intensive, and is not required with the native TCP⁄IP CTC and 3745⁄46 device drivers. (See the z/OS Communications Server: IP Configuration Reference for configuration information.) It is therefore important to weigh the multiplexing capability that SNALINK provides against its performance cost, in determining whether to use SNALINK or the native TCP⁄IP CTC or 3745/46 device drivers.