Enterprise Extender

Enterprise Extender (EE) has provided a useful solution to the dilemma of running SNA applications over IP networks. "Extending the enterprise" is an appropriate description.

Enterprise Extender is a standard created by the Internet Engineering Task Force (IETF) and APPN Implementers' Workshop (AIW). It is documented in RFC 2353.

The Enterprise Extender architecture carries the SNA high performance routing (HPR) traffic of any logical unit type over an IP infrastructure without requiring changes to that infrastructure. It treats the IP network as a particular type of SNA logical connection. In this manner, the SNA protocols act as transport protocols on top of IP, as does any other transport protocol such as Transmission Control Protocol.

An important aspect of Enterprise Extender is the ability to view the IP network as an APPN connection network. In this case, the benefit comes from the ability to establish dynamically a single one-hop HPR link to any host to which IP connectivity is enabled, provided that the host implements Enterprise Extender. In general, this allows the routing function to be handled entirely within IP. IP routers serve as the only routing nodes (hosts) in the network.

Figure 1 pictures two backbone networks, an SNA network and an IP network. The SNA network connects SNA devices without encapsulating the data to the mainframe. The IP network connects IP devices like TN3270 clients and TCP clients implementing web browsers directly to the TCP stack in the mainframe.

Devices that implement Enterprise Extender are located on the border of the IP and SNA network. These devices are connected on one side to the SNA network and on the other side to the IP network. The IP network transports the Enterprise Extender traffic over the IP backbone. The routers inside the IP backbone are pure IP routers not requiring any additional software, as in the case of DLSw.

Figure 1. TCP and Enterprise Extender backbone network

In the branch side, where the SNA clients exist, special hardware and software converts the SNA packets to IP packets. Figure 1 lists either the IBM Communication Server for NT or the Cisco SNA Switching (SNASw), a special version of Cisco's Internetworking Operating System (IOS) that implements branch extender.

To the SNA HPR network, the IP network appears to be a logical link; to the IP network, the SNA traffic appears as UDP datagrams. The UDP datagrams are routed without any changes to the IP network.

Figure 2 shows how the two mainframes connected via the IP network cloud. The path that carried the Enterprise Extender IP/UDP datagrams through the IP cloud is the logical link that connects the two mainframes. The rapid transport protocol (RTP), which is a logical connection, uses the IP network as an HPR link.

Figure 2. SNA HPR over the IP network

In a "mixed" Enterprise Extender and HPR connection, a single RTP pipe connects the two endpoints. The single RTP pipe is made up of two hops:

A HPR hop of unspecified type
An Enterprise Extender connection

A two-hop mixed HPR and Enterprise Extender is depicted in Figure 3.

Figure 3. Combined HPR and Enterprise Extender connection

Enterprise Extender has been designed to run over existing IP networks without requiring any change to applications or to IP routers. SNA applications see the same SNA network interfaces as before, while IP routers continue to see familiar UDP packets.

Session availability in mixed EE and HPR

In a mixed EE and HPR connection, as shown in Figure 3, the rerouting of SNA sessions takes place by the protocol where the failure is identified.

IP has always had the ability to reroute packets around failing components, without disrupting the connection, by means of the connectionless property of IP. More recently HPR has implemented non-disruptive path switching, which provides the same function as an IP network, although in a different fashion.

The HPR extension to SNA is connection-oriented, which has always been a characteristic of SNA. However, when it detects a failure, it moves an existing connection around a failing component. The use of HPR transport over an IP network provides nondisruptive rerouting around failed network components using either IP or HPR methods, depending on the location of the failure.

If the failure occurs in the IP network, the rerouting is handled by the IP network. If the failure is the HPR portion, HPR's non-disruptive path switching reroutes the session to an alternative path.