Thus far we described SNA as a robust and reliable protocol. So why is it that Enterprise Extender transports SNA over IP packets using UDP, which by definition is unreliable and whose transmission is based on best effort?

The designers of Enterprise Extender had the task of architecting the way in which SNA and IP-based protocols would be layered to transport SNA data over the IP network. They had three choices for encapsulating SNA data units: raw IP datagrams, UDP packets, or a TCP connection. Let's take a closer look at each choice in more detail:

• Raw IP datagrams

Datagrams are completely compatible with the HPR principles because they flow through the network with minimal overhead and provide no error recovery of any sort. However, raw IP provides no means of multiplexing, particularly with no Internet Engineering Task Force (IETF)-designated protocol value for HPR. Using a non-designated protocol value can lead to inconsistencies with security measures that filter IP packets based on this value.

Additionally, although raw IP allows priority and type of service to be specified, in practice not all networks or routers are, or can be, configured to support this.

• UDP packets
• These packets provide the multiplexing required because they contain UDP port numbers, which allows Enterprise Extender packets to be distinguished from other IP packets. UDP also permits a priority scheme to be implemented independent of the type of service bits, because many routers can prioritize traffic based on the received port number.

UDP also has low overhead because it does not concern itself with error recovery or flow control.

• TCP connection

A TCP connection also provides multiplexing through port numbers, but it incurs a significantly higher overhead than raw IP or UDP. A TCP connection handles error recovery, retransmission, and flow control. None of these is required for an HPR connection because the RTP endpoints are responsible for all of them.