Ad01 Ee Sna

IBM Power Systems Technical University
October 18–22, 2010 — Las Vegas, NV
Implementing Enterprise Extender –

SNA for the 21st Century
Session ID: AD01

Fant Steele
fant@us.ibm.com
Certified I/T Specialist – Advanced Technical Skills
© 2010 IBM Corporation
IBM Power Systems
The announcement:
http://www-03.ibm.com/servers/eserver/iseries/support/planning/v5r3planning.html
•WAN, LAN, Token Ring, Twinax, April 2005
The i5/OS operating system has long term support and development plans for many key industry WAN and LAN protocols. These include TCP/IP,
PPP, Async, Bisync, Ethernet, and APPN via Enterprise Extender. i5/OS has both short-term and mid-term support plans for SDLC, SNA, X.25 and
Frame Relay. IBM plans to continue providing i5/OS support for SDLC (switched and non-switched), , SNA, X.25 and Frame Relay in V5R3 and in the
release after V5R3. IBM recommends that customers start moving off these protocols prior to IBM's eventual withdrawal of support. i5/OS releases
introduced after mid-2007 may not include support for these protocols.
The withdrawal of SNA support is focused upon the sending of SNA traffic directly over LAN and WAN adapters. The various APPC based SNA
applications including SNADS, DDM, Display Station passthrough, and other user supplied applications will continue to be supported using the future
Enterprise Extender support and the existing AnyNet support. In addition, Enterprise Extender will also support dependent LU traffic when
communicating with mainframe systems. This includes host devices (3270 DE, RJE, and program-to-program), DSNX, DHCF, NRF print and display
devices, and SNA upstream passthrough devices, when used in conjunction with Dependent LU Requester support. Enterprise Extender will also
support the sending and receiving of Alerts using the SNA/Management Services Transport support. Both AnyNet and Enterprise Extender allow this
SNA traffic to be encapsulated and sent over an IP network.
Though i5/OS V5R3 and the following release will continue to support SDLC, SNA, X.25 and Frame Relay protocols, new hardware WAN and LAN
adapters announced starting in 2005 will not support these protocols. Either OEM protocol converters or earlier generation IBM WAN and LAN
adapters may have to be obtained by the customer if these protocols are important to the customer. For example, you may not be able to continue to
purchase new WAN and LAN adapters from IBM that would allow you to attach 5250 remote controllers such as a 5294, 5394 or 5494 which use the
SDLC or X.25 protocol.
The i5/OS operating system will continue to support twinaxial controllers, but IBM plans to withdraw from marketing the sale of new twinax controllers
in mid-2006. IBM recommends that new workstations and printers be attached via LAN or WAN and not via twinaxial workstation controllers.
Attachment of existing twinaxial devices will be available through existing IBM twinaxial controllers, OEM protocol converters, or replaced by LAN-
attached technology. There should be no impact to application programs using the 5250 data stream.
i5/OS will continue to support token ring network (TRN) adapters, but IBM plans to withdraw from marketing the sale of new TRN adapters in mid-
2006. IBM recommends that customers move from TRN to Ethernet, which has become an industry standard.
Suggested Alternatives:
See this page for suggested Alternatives for WAN, LAN, Token Ring, Twinax, April 2005
http://www-03.ibm.com/servers/eserver/iseries/support/planning/v5r3suggested_alternatives.html
2 © 2010 IBM Corporation

IBM Power Systems
So Where does this leave me?

• What options are available to me?
• Are Hardware based options still available to me?
• What SNA based functions am I using now?
• Do I have custom programs that run across SNA?
• Do I have the source code for the programs?
• Are there TCP/IP based alternatives for these functions?
• Do I have remote users? If so, how do they connect?
• What kind of network line connections am I using?
Enterprise Extender is included at no charge in V5R4 of i5/OS. This is the first release of i5/OS
that supports EE.
AnyNet is no longer supported in the most current release of z/OS Communications Manager
IBM i 6.1 is the LAST release to support AnyNet
AnyNet is included in IBM i 7.1 and will continue to work BUT IS NOT
SUPPORTED.
NOTE: Call support and ask for the latest PTF recommendations for Enterprise Extender or
check the web at:
http://www-912.ibm.com/s_dir/slkbase.nsf/$$Search?openform
search for document 484227176 for V6R1 PTFs
IBM Power Systems
Hardware Based SNA

• Hardware based (“Native”) SNA REQUIRES an IOP to function in IBM i.
– There are still some IOP / IOA adapters that are supported in POWER6 based systems
– POWER6 CECs DO NOT support IOPs IOPs require an expansion drawer
– M15 systems do not support expansion drawers therefore IOPs are NOT available with
M15 systems
• LAN based SNA 2849 (3709) 10/100 Ethernet LAN adapter
– Supported on 9406-MMA, 9117-MMA, and 9119-FHA
– i-listed (restricted) RPQ #847227 provides TEMPORARY support for 2849 on 9408-M25
and 9409-M50 and converged POWER6 systems
• LAN based SNA 2744 Token Ring LAN adapter
– i-listed (restricted) RPQ #8A1708 provides TEMPORARY support for 2744
• SNA over SDLC
– Look for adapters that support multiple protocol communications (RVX) ports
• 2742 (6805) – PCI Two-Line WAN IOA
– Both ports are RVX and support Synchronous
Support for the RPQs is withdrawn as of July 31, 2010

Feature Codes in parentheses are the converged system feature codes
IOPs WILL NOT MOVE FORWARD to POWER7 based systems

https://www-947.ibm.com/systems/support/i/planning/upgrade/v6r1/planstmts.html
http://www-03.ibm.com/systems/power/support/
IBM Power Systems
Notes:
• The card ordered by feature code #2742 or feature code #6805 is the exact same card. The only difference is that when
ordered as a #2742 on a 9406 system it will be placed where it is logically under an IOP. If it is ordered as a #6805, it will be
placed such that it is not logically under an IOP. The #6805 is not a replacement card for the #2742 card ... it is the exact
same card. The converged systems are typically not configured with this card under an IOP and support for the feature code
(#2742) that is intended to force this card to be placed where it is logically subject to an IOP has not carried over to the
converged systems. Support for the same card exists (as feature code #6805) but it will be treated as an IOP-less card. Note
that on upgrades where the target system is a converged system, any #2742s that exist on the installed system will be
automatically RPOed off and an equivalent quantity of #6805s RPOed on to the installed system MTM just prior to the
upgrade. Note that RPO stands for 'Record Purpose Only' ... so these are only 'paper changes'. The feature code of the card
is #2742 on the old system, but the feature code for the exact same card is #6805 on the converged system, and it runs
without an IOP. There will never be any #2742s allowed on the 9117-MMA or 9119-FHA. The same card is supported as
#6805. Therefore, when dealing with a 9117-MMA or 9119-FHA, use #6805 where you want the card you know formerly as
#2742.
• Similar to the explanation above, the card ordered by feature code #2793 or feature code #6833 is the exact same card.
During the upgrade process, the #2793s will be removed from the records and #6833s will be added to the records in their
place. Therefore, when dealing with a 9117-MMA or 9119-FHA, use #6833 where you want the card you know formerly as
#2793.
• The #2849 (100/10MBPS Ethernet) is reaching end of life and customers need to consider its replacement. However, this
exact card will continue to be temporarily supported for 9117-MMA and 9119-FHA as feature code #3709. Note that feature
code #2849 is a display adapter on the converged systems ... do not be confused by the fact that the #2849 on iSeries
systems is not the same card as #2849 on converged systems. That is why the 100/10MBPS Ethernet adapter formerly
known as #2849 will be known as a new and different feature (#3709) on converged systems. The card ordered by feature
code #2849 on the older systems is the exact same card that is supported on a 9117-MMA or 9119-FHA as #3709. During
the upgrade process where the target system is a 9117-MMA or 9119-FHA, the #2849s will be removed from the records and
#3709s will be added to the records in their place. Therefore, when dealing with a 9117-MMA or 9119-FHA, use #3709 where
you want the card you know formerly as #2849.
• The long and short of this answer is:

– You can use the same card you recognize as #2742 on a 9117-MMA or 9119-FHA. But you need to call it a #6805.
IBM Power Systems
Previous SNA over IP network options

Data Link Switching (DLSw)
DLSw Router DLSw Router
SNA IP SNA
• End system requires SNA support

• not all network interface adapters support SNA anymore
• In case of a failure with Data Link Switching (DLSw),
non-disruptive routing cannot be guaranteed
• Both IP and SNA networks need to be managed
AnyNet
IP
AnyNet AnyNet
• Network is not aware of SNA traffic, thus no traffic
prioritization possible
• AnyNet only supports Low Entry Networking (LEN)
• no APPN or HPR
• No end-to-end non-disruptive session recovery

IBM Power Systems
Notes:
• Data Link Switching (DLSw)
– Data link switching (DLSw) is an IBM-architected extension to source route bridging that allows SNA and
NetBIOS frames to be routed through an intervening IP network. It is implemented as an extra feature in
several IP router products.
– To SNA users, a DLSw connection looks like a bridged LAN connection. In fact, DLSw is an extended
form of the LAN bridge function that interconnects local area networks across wide area networks
(WANs). DLSw utilizes a TCP connection between the DLSw routers to carry the SNA traffic. Remote
DLSw implementation requires at least two routers (with the DLSw feature) connected to each other via
an IP network. Routers within the IP network need not know anything about DLSw. The DLSw routers are
only needed at the edge of the IP network. WAN traffic is reduced in similar fashion for SDLC-attached
devices. Polling is done locally by the DLSw station, and only productive polling results in data
transmission over the IP network.
– Data link switching is fairly commonly used, as it was the first SNA over IP solution that became available.
It has some attractive features such as spoofing, and it is easy to understand and configure. DLSw, like
any other TCP connection, utilizes the dynamism and rerouting capabilities of the IP network.
– DLSw has also some disadvantages:
• It may require additional routers on each side of the TCP/IP network if performance and availability requirements are
to be met.
• Heavy workload demands may be placed on central (concentration point) routers implementing DLSw.
• DLSw as implemented in IBM products does not support HPR. DLSw is based on the use of LLC2 connections using
MAC and SAP addresses exchanged on TEST and XID frames. HPR does not require LLC2 connections, and
normally uses a SAP other than the one seen in the XID frames.
• When a DLSw router fails, session outages occur, even if backup routers are in place.
• There are no SNA-like class of service or management functions within the IP part of the network, although it is often
possible to distinguish between SNA and other types of IP traffic.
IBM Power Systems
No single solution is a clear winner
Parallel HPR SNA over

HPR TCP/IP - TCP/IP TCP/IP using
networks AnyNet
Very reliable,
Can use Has the
Large installed High
newer TCP/IP combined
base, Trillions of scalability, lower
Pros LoC in APPC TCO, becoming
apps while strengths of the
keeping legacy other three
applications standard.
applications. choices.
available.
Some Very Very high

Can not run
required HW expensive and overhead.
Cons reaching end of
critical legacy
labor intensive to Difficult
applications.
life. High TCO maintain. configuration.

IBM Power Systems
Notes:
• The Enterprise Extender technology was implemented on most of IBM’s networking platforms during 1998.
Its main objective is to provide SNA-over-IP integration that is significantly superior to its predecessors
such as data link switching and AnyNet.
• Enterprise Extender : High Performance Routing (HPR) over IP
• There are so many different networking schemes, possibilities, and protocols, so it could be difficult to
decide on the best setup for you and your business.
• Systems Network Architecture (SNA) includes layered logical structure, formats, protocols, and
operational sequences that are used for transmitting information units through networks. One example of
implementing SNA to connect the i5/OS™ or iSeries™ server with other systems, to connect remote
controllers and to maintain a high-level of security on your system, is through the use of APPC, APPN,
and HPR.
• Enterprise Extender is a networking architecture that allows Systems Network Architecture (SNA)
applications to run over Internet Protocol (IP) networks using High Performance Routing (HPR). This is
the preferred way to run SNA applications over IP networks with communications input/output adapters
(IOAs), such as Gigabit Ethernet, since these IOAs do not require an input/output processor (IOP).
Gigabit Ethernet adapters do not automatically support SNA traffic. Enterprise Extender (or AnyNet®) is
required to allow SNA data to flow over a Gigabit adapter. IBM® recommends that Enterprise Extender be
used in place of AnyNet. For more information, see the migration from AnyNet to Enterprise Extender in
V5R4, iSeries Information Center.
IBM Power Systems
Notes:
• AnyNet
– AnyNet products implement the IBM Multiprotocol Transport Networking (MPTN) architecture, which supports mixed
protocol networking. With AnyNet, application programs that were designed to operate over one transport networking
protocol, such as SNA, OSI, or TCP/IP, can run over a different transport network. Members of the AnyNet family
make it possible for these communications paths on various platforms:
• APPC over TCP/IP
• APPC over IPX
• SNA over TCP/IP
• Sockets over SNA
• Sockets over IPX
• Sockets over NetBIOS
• NetBEUI over SNA
– AnyNet products are based on the Multiprotocol Transport Networking (MPTN) architecture, which allows applications
to be enabled in mixed protocol networks. The industry standard MPTN solution is part of the Networking Blueprint
framework introduced in 1992 by IBM. MPTN is an architecture for the common boundary between the application
support and transport network layers. The common boundary can be used for application enablement and network
integration.
– AnyNet was first introduced in OS/400 V3R1. The advantage of AnyNet over DLSw is that the networking
infrastructure only needs to support one networking protocol, namely IP. End systems need to support AnyNet.
However, AnyNet does not support features like Advanced Peer-to-Peer Networking (APPN) or High Performance
Routing (HPR). It only supports Low Entry Networking (LEN) SNA functionality. Another disadvantage is the protocol
overhead of the MPTN architecture. For example, when SNA traffic needs to be sent over a non-native transport
network, such as IP, a MPTN header is added to the SNA Request Unit (RU) which in turn will be encapsulated in a
TCP frame in an IP datagram. One of the major drawbacks with AnyNet is the lack of traffic priorization support. In
typical SNA networks traffic is prioritized through transmission priorities in Class of Services (CoS). In an AnyNet
environment, IP routers are not aware of different SNA priorities.

IBM Power Systems
Enterprise Extender Introduction
SNA Appl SNA Appl
EE/HPR EE/HPR
UDP/IP UDP/IP
IP Network
DLC DLC
• The purpose of Enterprise Extender (EE) is to carry SNA traffic over an IP

network while maintaining the SNA class of service to the maximum
possible extent
• Enterprise Extender is an up-to-date replacement for data link switching
and AnyNet
• EE provides Advanced Peer-to-Peer Networking (APPN) and High
Performance Routing (HPR) support
• EE allows enablement of IP applications and convergence on a single
network transport while preserving SNA application and endpoint
investment
IBM Power Systems
Notes:
applications to run over Internet Protocol (IP) networks using High Performance Routing (HPR). This is
the preferred way to run SNA applications over IP networks with communications input/output adapters
(IOAs), such as Gigabit Ethernet, since these IOAs do not require an input/output processor (IOP).
Communications adapters that do not use an IOP do not support SNA, therefore, Enterprise Extender is
required to run SNA over these adapters. IBM® recommends that Enterprise Extender be used in place of
AnyNet®.
• In V5R4, the communications trace was improved to capture HPR data running over IP networks, allowing
you to troubleshoot Enterprise Extender communications problems.
• Since Enterprise Extender supports HPR, it provides the benefits of HPR all the way from the iSeries to
the furthest SNA-capable node in the network. It does this regardless of whether the underlying routing
network is SNA, IP, or a combination. Thus, for example, sessions using an SNA backbone can be
rerouted nondisruptively to a path over an IP backbone (or even the Internet) should a critical SNA
component fail. No other technology can provide this; data link switching is susceptible to failure of the
DLSw routers at the edges of the IP network.
• The other major benefit of Enterprise Extender is the ability to maintain the SNA class of service across
and within the IP network. Routers typically use either the precedence bits in the IP header, or the UDP
port number, to prioritize traffic. Enterprise Extender can use one or both of these to indicate the APPN
transmission priority to the network. Once again, this feature is unique to Enterprise Extender.
• The Enterprise Extender implementation from IBM complies with the Internet standard RFC2353.

IBM Power Systems
Enterprise Extender – Supported functions

• Full APPN support:
– Network Node
– End Node
– Branch Extender Node
• Enterprise Extender (EE) provides full APPC support:

– SNA Distribution Services (SNADS)
– Distributed Data Management
– Display Station Passthrough
– Nearly everything involving LU 6.2
• Support for dependent LU communications to mainframes over

Dependent Logical Unit Requester (DLUR) is a key function. DLUR over
EE will support the following:
– Host devices, including 3270 emulation (*EML), remote job entry (*RJE), and
program-to-program communications (*PGM)
– SNA Passthrough upstream devices
– DHCF display devices
– NRF display and printer devices
– SNUF devices (DSNX)
IBM Power Systems
Notes:
• The following services are supported by Enterprise Extender:

– SNADS : System Network Architecture (SNA) Distribution Service
– Distributed Data Management
– Display Station Passthrough
– Nearly everything involving LU 6.2
• Full APPN support is available:

– Path switch, and RTP are used to ensure communications reliability
– NN : Network node
– EN : End node
– BEX : Branch Extender
• Dependent LU Requester (DLUR) allows dependent secondary logical units (LU 0, 1, 2, and 3) an entry
point into the APPN network. DLUR support gives the appearance of having an adjacent connection to
Virtual Telecommunications Access Method (VTAM), but allows traversing the APPN network through
intermediate nodes to get the VTAM node.
– DHCF : Distributed Host Command Facility ( 3270 pass through)
– NRF : Network Routing Facility
– SNUF : SNA Upline Facility
– DSNX : Distributed Systems Node Executive

IBM Power Systems
Enterprise Extender – Functions not supported
• Enterprise Extender (EE) does not provide Remote Workstation support.

This could be an issue for:
– Remote workstation controllers (5294, 5394, 5494)
– Retail (retail controllers 4690, 468x, 3641, 3684)
– Financial
(Financial Branch System Services (FBSS) or 470x finance controllers)
– Any operation involving direct connection to remote hosts
• Third Party solutions exist to address this issue

– There are products from Perle, 10ZiG (formally BOSaNOVA), etc.
– However, they connect into the system via TCP/IP
• z/VSE and z/VM DO NOT support EE
IBM Power Systems
Notes:
• Enterprise Extender does not provide SNA based remote workstation support, such as 5294, 5394, or 5494
controllers. There are a number of OEM vendor solutions available that allow 5250 type workstations to
attach to eServer i5 systems across a TCP/IP network. The 5250 workstations attach to OEM controllers,
which encapsulate the workstation 5250 datastream into TCP/IP traffic. The telnet server handles the
communications on the i5/OS system (the 5250 workstations appear as telnet clients).
• There are multiple OEM vendors that provide this capability.
• There are products from Perle and BosCom that allow customers to keep using twin-ax devices, but they
connect into the system via TCP/IP. Here are a few good websites that describe some of this:
– http://www.e-twinaxcontroller.com/?source=adwords?adcopy=CtwinaxGsna1replacement20050713
– http://www.perle.com/products/prod_family/as_400/index.html
– http://www.affirmative.net/itwinax.html

IBM Power Systems
Reasons for moving to Enterprise Extender
• SNA still powers a majority of the financial transactions that traverse the Web
–Most businesses running a SNA network will also require a TCP/IP network.
But keeping parallel infrastructure is unnecessarily expensive.
–Even if only SNA traffic is required, running it on a TCP/IP network will have a
lower TCO
• The availability of TCP/IP equipment and staff is high, thus reducing costs
• Allows SNA applications to stay competitive in the Internet age
• Withdrawal of Support for AnyNet will happen in the next release after IBM i 6.1;
Users running SNA applications over IP will need an alternative
• IBM provided planning statement in April 2005 that discussed

eventual withdrawal of data link protocols and adapters that
support native SNA traffic over the wire
–NO IOP support in POWER7 based systems
IBM Power Systems
Notes:
• Even though IP networks are the de-facto standard for communications networks, many enterprises,
especially in the financial sector, still use SNA communications in their networks. These companies rely on
SNA’s reliability and availability. However, maintaining two network infrastructures at the same time can be
very costly. Therefore, it might be a good idea to move to a pure IP-based network infrastructure allowing
companies to reduce administration and operations cost. The reason behind lowering costs is that IP
administration staff is widely available and IP networking equipment is relatively cheap.
• Enterprise Extender technology can reduce the demands on the data center routing platforms such as
routers and front-end processors and thus provide a more cost-effective solution than other integration
technologies. The boundary nodes between the SNA and IP backbones have less work to do than, for
example, DLSw routers that must maintain TCP connections with their attendant flow control and error
recovery requirements. Enterprise Extender does all that at the HPR endpoints wherever they may be
located.
• Another reason for companies to move towards an IP-based network infrastructure is IBMs plan to
eventually remove native SNA data link protocol and adapter support. This direction can also be observed
when taking a look at all network adapters that were introduced in the last couple of years. They all support
the IP protocol only.

IBM Power Systems
Enterprise Extender Introduction – HPR Support

• High-Performance Routing (HPR) is the evolution of Advanced
Peer-to-Peer Networking (APPN)
–It enhances APPN data routing performance and reliability,
especially when using higher-speed lower-error links.
• HPR consists of two major components:

– Rapid Transport Protocol (RTP)
• Logical pipe between end points
• Error detection and retransmission
• Congestion control
• Prioritization
• Non disruptive reroute
–Automatic Network Routing (ANR)
• ANR label created at initiation
• Label contains all routing information
• SNA router strips label and forwards packet
IBM Power Systems
Enterprise Extender Introduction – HPR Support
• Enterprise Extender utilizes the following HPR option sets:

–1401 RTP Tower option
• this option can act as an endpoint and are able to transport logical-unit to logical-unit session
(LU-LU-session) session traffic across HPR networks by using Rapid Transport Protocol (RTP)
connections
–1402 Control Flows over RTP Tower option
• option causes control-point to control-point sessions (CP-CP sessions) and route setup
messages to flow over special RTP connections
–2006 Logical Data Link Control (LDLC) Support option
• LDLC is a Logical Link Control (LLC) type defined to be used with HPR networks in conjunction
with the Control Flows over RTP Tower option
• LDLC is only used for Enterprise Extender links
–2009 Native IP Data Link Control (DLC) option
• Native IP is a DLC option used with option sets 1400, 1401, 1402, and 2006 to allow you to take
advantage of APPN/HPR functions such as class of service (COS) and adaptive rate based
flow/congestion control in the IP environment
• contains the support for Enterprise Extender links

IBM Power Systems
Notes:
applications to run over Internet Protocol (IP) networks using High Performance Routing (HPR). This is the
preferred way to run SNA applications over IP networks with communications input/output adapters (IOAs),
such as Gigabit Ethernet, since these IOAs do not require an input/output processor (IOP) and, therefore,
do not natively support SNA. IBM recommends that Enterprise Extender be used in place of AnyNet.
• Enterprise Extender utilizes the following HPR option sets: 1401, 1402, 2006, and 2009. These option sets,
as well as 1400, are described below.
• The HPR function can operate under a base architecture, or can operate under the base architecture plus
options. There are performance capabilities available under the Tower RTP (Rapid Transport Protocol)
option not available with the base. See the following for a more thorough explanation of what architecture
option is appropriate for you.
• HPR-base option (option set 1400): Its primary function is to provide automatic network routing (ANR).
Products that only use this function can participate as intermediate nodes in one or more Rapid Transport
Protocol (RTP) connections. This type of implementation cannot be an endpoint of an RTP connection. An
addition to the base option is HPR link-level error recovery. A system that supports high-speed links does
not always require link-level error recovery. It is optional because when link-level error recovery is
eliminated, faster communications might occur when using high-quality data transmission.
IBM Power Systems
Notes:
• RTP Tower option (option set 1401): Implementations that support this option can act as an endpoint and
are able to transport logical-unit to logical-unit session (LU-LU-session) session traffic across HPR networks
by using Rapid Transport Protocol (RTP) connections. An RTP connection can only be made between two
systems that support RTP. That is, there can only be a mix of systems in a given RTP connection's path
through the network (systems that only support the HPR base option and systems that support the HPR
tower option). However, there is the stipulation that at least the two end points in the path support the HPR
tower option. Otherwise, APPN is used.
– Note: An implementation that has the RTP Tower option also supports the base option. These systems
can run as intermediate systems in the path.
• Control Flows over RTP Tower option (option set 1402): This option causes control-point to control-point
sessions (CP-CP sessions) and route setup messages to flow over special RTP connections. CP-CP
sessions are established between adjacent node pairs and are used to broadcast topology flows to the
entire network so that every node has the topology for the entire network stored in its topology database.
Route setup messages are request and reply messages that are used to obtain information about a route
over which an RTP connection will be established. The route setup request is sent by the origin node to the
destination node over the exact route that is to be used. It stops at each intermediate node along the way to
gather information associated with the forward path. The route setup reply is returned by the destination
node after receiving the route setup request. The reply follows the same path as the request (in the reverse
direction) and stops at each intermediate node along the way to gather information about the reverse path.
When the origin node receives the reply it uses the information to establish a new RTP connection or
reroute an existing one.

IBM Power Systems
Notes:
• Logical Data Link Control (LDLC) Support option (option set 2006): LDLC is a Logical Link Control (LLC)
type defined to be used with HPR networks in conjunction with the Control Flows over RTP Tower option
(option set 1402) over reliable links that do not require link-level error recovery. LDLC is only used for
Enterprise Extender links.
• Native IP Data Link Control (DLC) option (option set 2009): Native IP is a DLC option used with option sets
1400, 1401, 1402, and 2006 to allow you to take advantage of APPN/HPR functions such as class of
service (COS) and adaptive rate based flow/congestion control in the IP environment. This option set
contains the support for Enterprise Extender links.
IBM Power Systems
Enterprise Extender Introduction - Transport
• Enterprise Extender uses UDP packets to transport

SNA Appl
SNA (APPN / HPR) traffic across an IP network n bytes
– AnyNet used TCP
• error detection and retransmission services HPR packet
provided by TCP
– no application end-to-end protection 3 bytes
– SNA data sent as UDP payload
LDLC Hdr HPR packet
8 bytes
UDP Hdr LDLC Hdr HPR packet
20 + bytes
IP Hdr UDP Hdr LDLC Hdr HPR packet

IBM Power Systems
Notes:
• 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 network interface as before, whereas IP
routers see the same IP (UDP) packets as before. Only the HPR nodes at the edges of the IP network need
to be aware of Enterprise Extender.
• To the HPR network, the IP backbone is a logical link; to the IP network, the SNA traffic comprises UDP
datagrams that are routed without hardware or software changes to the IP backbone. There is no protocol
transformation, as UDP/IP is seen as just another type of SNA DLC. Nor is there the overhead of additional
transport functions, since TCP is not used
• Logical Data Link Control (LDLC) is used by the native IP Data Link Control. LDLC uses a subset of the
services defined by IEEE 802.2 LLC type 2 (LLC2). LDLC uses only the TEST, XID, DISC, DM, and UI
frames. LDLC was defined to be used in conjunction with HPR (with the HPR Control Flows over RTP
option set 1402) over reliable links that do not require link-level error recovery. The LDLC header is three
bytes long (1 byte DSAP, 1 byte SSAP, and 1 byte Control).
IBM Power Systems
Enterprise Extender Introduction – Prioritization

• SNA uses transmission priorities in a Class of Service (CoS) to prioritize traffic across an
SNA network
– 4 transmission priorities available (low, medium, high, network)
– fully supported by Enterprise Extender
• 4 UDP ports are used for different transmission priorities
– port 12000 represents a connection for Logical Data Link Control (LDLC) traffic (i.e.
XID, TEST, DISC)
• Transmission priority is also set as precedence bits in the IP header
0 4 8 16 31
Part of Service Type
IP header Version HdrLen (3) (4) (1) Total Length
prec TOS Res
UDP CoS transmission Default CoS Traffic Precedence

Port priority bits
12000 XID exchange N/A LDLC B’110’
12001 Network N/A HPR B’110’
12002 High #INTER HPR B’100’
12003 Medium #CONNECT HPR B’010’
12004 Low #BATCH HPR B’001’
IBM Power Systems
Notes:
• One of the biggest issues facing those who wish to transport SNA over an IP backbone is the question of
maintaining SNA’s class of service. In native SNA the class of service specified for a particular session is
used to determine both the route taken by the session and the transmission priority allotted to it. With an
IP backbone the route is essentially unpredictable because of IP’s connectionless transport. However, IP
provides for a transmission priority using the precedence bits in the IP header. Many routers support the
use of these bits, but in the past they have tended to use the TCP or UDP port number as a means of
assigning priorities to packets (QoS Differentiated Services).
The Enterprise Extender architecture supports the use of both the precedence bits and the port numbers
to inform the IP network of the transmission priority. Use of the precedence bits is recommended because
the UDP or TCP port numbers are carried inside the IP datagram, whereas the precedence bits are in the
IP header. Thus encrypted packets have unreadable port numbers and fragmented packets have no port
numbers after the first fragment; therefore, intermediate routers cannot determine the priority in these
cases.
• The UDP port number identifies the destination of the datagram as being the partner IP host’s ANR
routing function. Several UDP ports (12000-12004) have been registered with the Internet Assigned
Number Authority (IANA) for this purpose. Each of these default ports is mapped to one of the APPN
transmission priority values, with the fifth (12000) being used for XID exchange and other Logical Data
Link Control (LDLC) commands. An Enterprise Extender implementation may choose to alter these port
numbers, but by using the registered defaults you can be reasonably sure that no other application will
conflict with Enterprise Extender. ANR labels are mapped to the partner’s IP address.
• The SNA transmission priority is mapped to the UDP port number, which is why five UDP ports have been
registered for Enterprise Extender use. The main reason for this is that many IP routers can be configured
to prioritize traffic based on the port number. However, the Enterprise Extender architecture permits the
use of the precedence bits in the IP header for the same purpose. These bits are reserved in the TCP/IP
architecture for exactly this usage, but not all routers take account of them. The precedence bits are three
bits that are part of the Service Type field in the IP header. The precedence values only appear when the
QOS enablement value (IPQOSENB) in the CHGTCPA command is set to *TOS. If QOS is active the
values should be configured in QOS.
IBM Power Systems
Enterprise Extender - Configuration

• Example scenario
Network attribute ALWHPRTWR set to *YES
on all systems where a HPR connection is
established to
IP Network
System: RCHSYSA System: RCHSYSB

Location name: RCHSYSA Location name: RCHSYSB
APPN Network ID: APPN APPN Network ID: APPN
IP Address: 10.5.92.48 IP Address: 10.5.92.32
Required configuration objects:

1. Line Description (i.e. Ethernet)
2. IP interface (I recommend *virtualIP address)
3. APPC Controller
Steps to create a line description and IP interface are not shown

IBM Power Systems
Notes:
• The previous charts depicts an example scenario of two iSeries systems that are connected to an IP
network. SNA applications exists on both systems. The goal is to use Enterprise Extender to provide full
APPC support for the application and at the same time use an IP network for communications.
• Since Enterprise Extender uses UDP to convey SNA data, there is no special requirement on network
adapters. Any kind of adapters, such as Ethernet, Token Ring, or WAN adapters can be used to establish
network communications. From an IP networking point of view, regular IP interface and routing configuration
is used. No special hosts table entries are required.
• The configuration shown on the following charts does not include the creation of a line description nor the
creation of an IP interface.
• On every system that is a destination of a HPR connection, the network attribute ALWHPRTWR (Allow HPR
transport tower support) has to be set to *YES. Otherwise, the APPC controller will become active, but no
LU 6.2 session can be established.
IBM Power Systems
Enterprise Extender - Configuration

• Enterprise Extender requires an APPC controller of type *HPRIP
• Typical parameter for route selection (CoS) are defined in the APPC controller rather than a line
description
• Configuration pretty much the same as regular APPN/HPR configuration
• One *HPRIP controller per direct connection
Controller description . . . . . . : EEHPRA

Option . . . . . . . . . . . . . . : *BASIC
Category of controller . . . . . . : *APPC
Link type . . . . . . . . . . . . : *HPRIP
Online at IPL . . . . . . . . . . : *YES
Remote internet address . . . . . : 10.5.92.32
Local internet address . . . . . . : 10.5.92.48
LDLC timers:
LDLC retry count . . . . . . . . : 3
LDLC retry timer . . . . . . . . : 15
LDLC liveness timer . . . . . . : 10
LDLC link speed . . . . . . . . . : *CAMPUS
Maximum frame size . . . . . . . . : 1461
Remote network identifier . . . . : APPN
Remote control point . . . . . . . : RCHSYSB
Exchange identifier . . . . . . . : 05600001
Data link role . . . . . . . . . . : *NEG
LAN DSAP . . . . . . . . . . . . . : 04

IBM Power Systems
Notes:
• This chart shows some parameters of a *HPRIP controller description. The parameters will be discussed on
the next charts. Note that a *HPRIP controller does not have any relationship to a line description, because
communications is performed through IP.
IBM Power Systems
APPC Controller Parameters
• LINKTYPE(*HPRIP)
– Enterprise Extender controller type
• RMTINTNETA(10.5.92.48)
– Requires the remote IPv4 address
• LCLINTNETA(10.5.92.32)
– Requires the local IPv4 Address
– Local IP address specified will be set in outgoing packets
– *SYS special value cannot be used at this time
• LDLCTMR
• These values provide the LDLC behavior for XID negotiation, and for inactivity "keepalive" activity
– Retry Count
– Retry Timer
– Liveness Timer
• LDLCLNKSPD(*CAMPUS)
• This is the only way that HPR can determine the speed of the line at the beginning of the connection
– Values of *CAMPUS (4mbps), *WAN(56kbps)
• These values are adjusted to the real link speed by HPR's responsive ARB protocol, in high
throughput situations

IBM Power Systems
Notes:
• The LDLC liveness timer is used to make sure that both the other endpoint of an RTP (rapid transport
protocol) connection and the path between the endpoints are still operational after a period of inactivity.
LDLC liveness uses the LDLC TEST command and response and is required when the underlying
subnetwork does not provide notification of connection outage. Because UDP is connectionless, it does not
provide outage notification; as a result, LDLC liveness is required for HPR/IP links.
• HPR uses a function called Adaptive Rated Based (ARB) congestion control. ARB regulates the flow of
traffic by predicting congestion in the network and reducing the sending rate of a node into the network.
ARB then attempts to prevent congestion rather than reacting to it after it has occurred. If all of the traffic
occurring over a network was HPR, then ARB would be a fair way of sharing the bandwidth of a network.
ARB also allows high utilization of the networking resources. When HPR traffic mixes with straight APPN or
TCP/IP traffic, the HPR throughput may suffer because the other protocols do not practice similar
congestion control techniques.
IBM Power Systems
APPC Controller Parameters (cont’d)

• LDLCTMSGR
– Used by APPN to calculate the weight of the line
– Appear only if the link speed is changed from campus, else the default *CAMPUS
values will be used
• MAXFRAME
– Default value: 1461 (Ethernet Frame size - UDP size - LDLC header size)
– In case of Virtual IP addresses that use network interface with different speeds, a high
value can cause fragmentation
• RMTNETID/RMTCPNAME
– Required value, must match the remote system’s network attribute values
• EXCHID
– Optional value
– Must match to other iSeries (05600001). This information will be used on the XID frames
that are exchanged at Vary On time
– Can be used for other platforms
• In VTAM this matches to the IDBLK (056) and IDNUM (00001) in the PU. Should be unique in
VTAM.
• LAN DSAP, SSAP
– Can be changed to have different parallel Transmission Groups (TGs)
IBM Power Systems
Notes:
• MAXFRAME
– When IP datagrams are larger than the underlying physical links support, IP performs fragmentation. When HPR/IP links
are established, the default maximum frame size is 1461 bytes, which corresponds to the typical IP maximum
transmission unit (MTU) size of 1492 bytes supported by routers. 1461 is 1492 less 20 bytes for the IP header, 8 bytes
for the UDP header, and 3 bytes for the IEEE 802.2 LLC header. The IP header is larger than 20 bytes when optional
fields are included; smaller maximum frame sizes should be configured if optional IP header fields are used in the IP
network.
• EXCHID
– The Exchange ID parameter is optional. If not specified, zeros are used. On other platforms, such as the
Communications Server, the EXCHID can be configured and then the EXCHID in the controller description has to be set
to whatever value is configured on the remote system.
• LAN DSAP
– Specifies the destination service access point (DSAP). This is the logical address this system will send to when it
communicates with the remote controller. This address allows the controller to properly route the data that comes from
this system. The default value for the destination service access point is 04. The value must match the value specified
on the source service access point (SSAP) parameter in the remote controller's configuration record.
• LAN SSAP
– Specifies the source service access point (SSAP). This is the logical address the local system uses when it sends data
to the remote controller. This address allows the controller to properly route the data that comes from the local system.
The default value for the source service access point is 04. It must match the value assigned to the destination service
access point (DSAP) in the remote controller's configuration record.
IBM Power Systems
Enterprise Extender Configuration

Matching Parameters between two IBM i systems
System: RCHSYSA System: RCHSYSB
CFGTCP(1) CFGTCP(1)
INTNETADR(10.5.92.48) INTNETADR(10.5.92.32)
CRTCTLAPPC CRTCTLAPPC
CTLD(EEHPRB) CTLD(EEHPRA)
LINKTYPE(*HPRIP) LINKTYPE(*HPRIP)
RMTINTNETA(10.5.92.32) RMTINTNETA(10.5.92.48)
LCLINTNETA(10.5.92.48) LCLINTNETA(10.5.92.32)
LDLCTMR(3 15 10) LDLCTMR(3 15 10)
LDLCLNKSPD(*CAMPUS) LDLCLNKSPD(*CAMPUS)
MAXFRAME(1461) MAXFRAME(1461)
RMTNETID(APPN) RMTNETID(APPN)
RMTCPNAME(RCHSYSB) RMTCPNAME(RCHSYSA)
EXCHID(05600001) EXCHID(05600001)
DSAP(04) DSAP(04)
SSAP(04) SSAP(04)
TMSGRPNBR(*CALC) TMSGRPNBR(*CALC)
CHGNETA (or DSPNETA) CHGNETA (or CHGNETA)
LCLNETID(APPN) LCLNETID(APPN)
LCLCPNAME(RCHSYSA) LCLCPNAME(RCHSYSB)
ALWHPRTWR(*YES) ALWHPRTWR(*YES)
IBM Power Systems
Notes:
• The previous chart shows what parameters have to match when setting up an HPR connection between two
iSeries systems (i5/OS, IBM i ) when using Enterprise Extender. The configuration is basically the same as
a regular APPN/HPR configuration with an Ethernet LAN (MAC addresses are used to define the remote
system) connection or an SDLC link (station addresses are used to define the remote system). With
Enterprise Extender, the remote system is defined by an IPv4 address.
• Use the following commands on an IBM i command line to create the configuration:
– CFGTCP and use option 1
– CRTCTLAPPC
– CHGNETA to change the network attribute settings or DSPNETA to display and verify the network attribute settings.
• The network attributes may be changed if ALL SNA based lines, controllers and devices are varied off.
– Use the command WRKCFGSTS with the parameter *lin *ctl and *dev to list the lines, controllers, and devices on the system. Option 2 to verify
items off.
• TMSGRPNBR may be left as the default value of 1 between two IBM i systems, but if should be changed to
*CALC for connections to other systems such as z/OS. It does not hurt to use *CALC between two IBM i
systems, so we suggest for consistency that you specify *CALC
IBM Power Systems
Matching Parameters IBM i <> IBM i with EE

IBM Power Systems
Notes:
• The previous chart is a worksheet that may be used to document and create an Enterprise Extender
connection between two IBM i system.
• To use the worksheet
– 1. Fill in the values in the space provided in the center of the form.
– 2. Go to System 1 find the parameters keywords on the left side of the column and use the values from the center
column as you complete the create commands.
– 3. Go to System 2 find the parameters keywords on the right side of the column and use the values from the center
column as you complete the create commands.
– 4. Vary on the controllers and test the connection.
IBM Power Systems
Enterprise Extender Configuration –

Independent LU z/OS - VTAM
CRTCTLAPPC CTLD(EEHOST) LINKTYPE(*HPRIP) RMTINTNETA('10.2.1.1')

LCLINTNETA('10.1.1.1') RMTNETID(NETWORK) RMTCPNAME(CPNAME)
TMSGRPNBR(*CALC) TEXT('APPC Controller to Host')
Sample configuration. You must match the values to your VTAM configuration.
The dependant LU controller must have an independent controller defined as well.
Refer to redbook SG24-7359 Chapter 9 for additional details
Program changes may be needed to support the correct virtual device that is auto created
REMEMBER z/VSE and z/VM DO NOT support EE
The IBM i system may be configured as either an *ENDNODE or *NETNODE.

The Server network ID / Control point name values in the Network Node servers list of the
IBM i network attributes must match the value defined in the VTAM configuration. This is
in addition to matching in the CRTCTLAPPC command.

IBM Power Systems
Enterprise Extender Configuration –

Dependant LUs z/OS - VTAM
CRTCTLHOST CTLD(EEHOST) LINKTYPE(*DLUR) SWITCHED(*YES)
LCLEXCHID(05600002)
TEXT('DLUR Controller for Program, RJE and 3270 Emulation')
PRIDLUS(RMTCP NETID)
CRTDEVHOST DEVD(RJEDEVLU01) LOCADR(01) RMTLOCNAME(RMTCP)

CTL(EEHOST) APPTYPE(*RJE) TEXT('RJE LU')
CRTDEVHOST DEVD(EMLTERM) LOCADR(03) RMTLOCNAME(RMTCP)

CTL(EEHOST) APPTYPE(*EML) TEXT('Device for 3270 terminal emulation')
CRTDEVHOST DEVD(CICSLU04) LOCADR(04) RMTLOCNAME(CICSRGN)

CTL(EEHOST) APPTYPE(*PGM) TEXT('Device for lu6.2 to cics')
Sample configuration. You must match the values to your VTAM configuration
LCLEXCHID will match to the values IDBLK and IDNUM in the SWITCHED
MAJOR NODE of VTAM for this location
LOCADDR in VTAM = decimal  in IBM i is HEX eg VTAM 10 => IBM i 0A
Refer to redbook SG24-7359 Chapter 9 for additional details
IBM Power Systems
Enterprise Extender – Operations

• A *HPRIP controller is varied on and off just like any other controller
description
– VRYCFG command
– No dependency on a line description
• Enterprise Extender UDP ports listening
Remote Remote Local

Address Port Port Idle Time State
* * hprip-ctl 003:10:03 *UDP
* * hprip-network 580:39:40 *UDP
* * hprip-high 580:39:40 *UDP
* * hprip-med 580:39:40 *UDP
* * hprip-low 580:39:40 *UDP
• When all *HPRIP controllers are varied on, use SNA applications
– Example: STRPASTHR RMTLOCNAME(RCHSYSB)
IBM Power Systems
Notes:
• Before you can establish APPN/HPR connections with Enterprise Extender, you need to vary on the
*HPRIP controller description. This is done with the VRYCFG CL command. When an APPC device is
already configured under the controller, the status becomes ACTIVE. If no APPC device exists, the status is
VARIED ON.
• When you perform the NESTAT *CNN CL command, all UDP ports that are used by Enterprise Extender
should be listed as shown on the previous chart.
• Once all controllers are active, SNA applications can establish sessions.
IBM Power Systems
Enterprise Extender – Migration Considerations
• Simple migration of hardware based SNA configurations

– requires an IP connection to all destination systems and a *HPRIP controller per
direct connection
• AnyNet migration requires more configuration steps
– While AnyNet can handle multiple remote links with only one controller, one
HPRIP controller is needed for each remote node having a direct link
– Unlike AnyNet, Enterprise Extender HPRIP controller provides full APPN
functionality
– TCP host definition entries are not required for Enterprise Extender
• AnyNet requires host name (SNA.IBM.COM suffix) to IP address mapping
• With EE, mapping is done in *HPRIP controller description
– AnyNet and Enterprise Extender can coexist
• Customers can even have parallel configurations of AnyNet and Enterprise Extender
during the migration

IBM Power Systems
Notes:
• IBM recommends that Enterprise Extender be used in place of AnyNet. To do the conversion, you have to
migrate existing AnyNet configurations to the *HPRIP controllers. To do that, the previous considerations
should be taken into account.
IBM Power Systems
Migrating to Enterprise Extender

• Current configuration
SYSA SYSB SYSD
IP Network APPN
(AnyNet) (HW)
LAN
LAN
SDLC
The configuration has the following connections:

– AnyNet over a LAN TCP/IP between SYSB and SYSA
– Hardware based APPN connection over LAN between
SYSB and SYSD
– Switched SDLC link between SYSB and SYSC
SYSC

IBM Power Systems

• Current AnyNet configuration on SYSA and SYSB (on each system)
– One APPC controller of a type *ANYNW with a remote control point of TCPIP exists on
SYSA and SYSB
– Configuration list entries exist in QAPPNRMT for the remote system. One entry for each
remote node, defining the remote node and setting the Control point name to TCPIP
– One entry in the TCP host table added with the "SNA.IBM.COM" suffix, preceded by the
remote SNA host name, and the remote network ID
– The ALWANYNET Network attribute set to *YES
• New Enterprise Extender configuration SYSA and SYSB (on each system):
– Retrieve Configuration Source (RTVCFGSRC) to capture the existing configuration for the connection
– Delete the existing AnyNet controller
– For each directly attached (via IP) remote node, create one APPC controller with link type
of *HPRIP and the IP address of the remote node, using the CRTCTLAPPC CL command
• I recommend the use of Virtual IP addresses (VIPA) for the endpoints on the connection
– Delete the entry for the remote system on the QAPPNRMT configuration list, using the
RMVCFGLE command, or the WRKCFGL *APPNRMT CL command
– The host table entry can be deleted in the TCP/IP configuration
IBM Power Systems
Notes:
• Migration for a system that can start AnyNet connections

• Retrieve the existing configuration then delete them to clean up the existing
connection
• You should have the following network configuration items defined:
– One APPC controller of type *ANYNW, that has a remote control point value of
TCPIP.
– One entry on the QAPPNRMT configuration list for each remote node that
defines the remote node and sets the control point name as TCPIP.
– One entry on the TCP Host table that has the "SNA.IBM.COM" suffix, and the
remote SNA host name and remote network ID that has the same suffix.
– The ALWANYNET network attribute set to *YES.
– WRKDEVD DEVD(*LOC) RMTLOCNAME(locname) to find ALL the devices that may
be using the remote location name. Some configurations allowed multiple
devices to have the same remote location name. EE is APPN so only a single
device can exist for the remote location name. If a device is left on the system
the auto creation of the APPN device will fail and the connection will not be
successful
• To migrate to HPRIP do the following:
IBM Power Systems
• Direct LAN attachments

– SYSB and SYSD have a controller with LinkType of *LAN, connecting them
• The controller is associated to a LAN line description
• It has the MAC address of the remote, as well as the remote XID
– In the Enterprise Extender environment, SYSB, and SYSD have a controller of
type *HPRIP connecting them
• The controller is not associated to a LAN line description
• It has the remote IP address, instead of the MAC address
• SDLC link –SYSB to SYSC

– The system needs to use a switched line to communicate to the remote SYSC
• Currently SDLC Line and controller descriptions will provide the modem
communications parameters, as well as the dial information
– To use Enterprise Extender, a Point-to-Point (PPP) configuration needs to be
configured and used
IBM Power Systems
Notes:
Migration for a connection that is hardware based SNA

• Retrieve the existing configuration (RTVCFGSRC) then delete them to clean up the
existing connection
• You should have the following network configuration items defined:
– A Line, controller, and device description for the connection.
– The APPC controller has a type *LAN, that has a remote control point value of
the target system.
– The Device description is auto-created
– There are also auto-created devices under the QAPENDxxxx controller that
must be deleted
– WRKDEVD DEVD(*LOC) RMTLOCNAME(locname) to find ALL the devices that may
be using the remote location name. Some configurations allowed multiple
devices to have the same remote location name. EE is APPN so only a single
device can exist for the remote location name. If a device is left on the system
the auto creation of the APPN device will fail and the connection will not be
successful
• To
50 migrate to HPRIP, do the following: © 2010 IBM Corporation
We recommend the creation of a virtual IP address (VIPA) for each endpoint of

IBM Power Systems
Enterprise Extender – Network Security Considerations

• Firewalls
–Need to open UDP ports 12000-12004
Open
UDP
12000
12001
12002
12003
12004
• VPN
–Since Enterprise Extender uses UDP, and UDP traffic can flow over a
VPN, IPSec can be used to encrypt the EE traffic between partners
IBM Power Systems
Notes:
• When running Enterprise Extender connections between systems that traverse firewalls, you need to open
UDP ports 12000 – 12004 in the firewall to be able to successfully establish a connection.
• As HPR traffic via Enterprise Extender uses the IP network protocol, a virtual private network can be
established between to nodes exploiting the IPSec protocol framework. IPSec is implemented at the IP layer
and protects all IP traffic in a VPN tunnel regardless of the application.

IBM Power Systems
Network Address Translation - NAT

• NAT changes the source or destination IP address in the IP header
• NAT MUST be STATIC
• Use the IP address as it appears in the segment of the network in the
APPC controller description
–Typically the public address of the REMOTE system
–Typically the private address of the LOCAL system
–Actual configuration values depend on the location and definition of the
NAT rules
IBM Power Systems
Static NAT
TRUSTED UNTRUSTED
BORDER
10.1.1.10 193.20.1.1 Internet

Public
Interface
Outbound traffic Inbound traffic
LAN or PPP link

Masquerading Function
192.10.1.5
Static NAT
Source Addr Dest. Addr. SP DP
Source Addr Dest. Addr. SP DP 10.1.1.10 193.20.1.1 193.20.1.1 192.10.1.5 12002 12002
10.1.1.10 192.10.1.5 12002 12002
10.1.1.11 193.20.1.2

192.10.1.5 10.1.1.10 12002 12002
192.10.1.5 193.20.1.1 12002 12002
CRTCTLAPPC CRTCTLAPPC
CTLD(EEHPRB) CTLD(EEHPRB)
LINKTYPE(*HPRIP) LINKTYPE(*HPRIP)
RMTINTNETA(192.10.1.5) RMTINTNETA(193.20.1.1)
LCLINTNETA(10.1.1.10) LCLINTNETA(192.10.1.5)

IBM Power Systems
Enterprise Extender – Servicability

• Communications trace has been enhanced to format Enterprise Extender and HPR traffic
– STRCMNTRC can be issued with CMNTRCOPTS(*RMTIPADR) or
CMNTRCOPTS(*IPPCLNUM)
– PRTCMNTRC adds new parameters for HPR/IP formatting:
• Format HPR header - FMTHPRIP(*YES)
• Format LDLC IP - FMTLDLCIP(*YES)
Src Addr: 10.5.92.32 Dest Addr: 10.5.92.48

IP Header : 45000079A1E3000040110E3709055C2009055C30
IP Options : NONE
UDP . . . : Src Port: 12003,Unassigned Dest Port: 12003,Unassigned
UDP Header : 2EE32EE30065C363
LDLC SSAP : 04 LDLC DSAP : 04 LDLC Control : 03 LDLC Header : 040403
NHDR : TPF=MEDIUM TSPI ANRF=A400
THDR : TCID=00711D4D28000020 OFFSET/4=0008 DLF=00000034 BSN=00000099
('3C04'X) SOMI, EOMI, SRI, RASAPI, OSI
ARBSEG: 80000006918800000000
TH : FID=5, MPF=Only SNF'=0001, SA='01010100F0F10001'X
RH : ('0B9120'X) REQ FMD, FI, BCI, ECI, DR1, ERI, PI, CDI
RU Command . : FMH- 5=0C0502FF0003D000000206F1
RU Data . . : 0019121002000000 0000080004000400 0840404040404040 40B6F49AB4
IBM Power Systems
Notes:
• Communications trace is improved to capture HPR data running over IP networks, allowing you to
troubleshoot Enterprise Extender communications problems.
• The Start Communications Trace (STRCMNTRC) command initiates a communications trace for a specified
line, a network interface or a network server description. To use this command, you must have service
(*SERVICE) special authority
• Communications trace options (CMNTRCOPTS) :

– *IPPCLNUM
• The data within an Internet Protocol (IP) number is traced.
– *RMTIPADR
• The data traveling to and from a remote IP address is traced.

IBM Power Systems
Enterprise Extender Advantages
No changes to SNA applications

Can reduce APPN network complexity while exploiting IP alternate routing/redundancy
technologies
SNA traffic can exploit OSA Gigabit Ethernet
EE can use any IP network connection
Most EE platforms can define IP network as a "connection network", allowing fewer link
definitions, but direct routing
EE works with IPSEC
EE works with Network Address Translation (NAT)
IBM Power Systems
Additional Information
• IPv6 introduction and concepts
– iSeries Information Center -> Networking->TCP/IP setup->Internet Protocol version 6
– IBM Redbook: TCP/IP Tutorial and Technical Overview, GG24-3376
http://www.redbooks.ibm.com/abstracts/gg243376.html?Open
• Virtual Private Networking enhancements
– iSeries Information Center -> Networking->TCP/IP applications, protocols, and services
->Virtual Private Networking
– Extender Sequence Number (ESN) - RFC4304
http://www.rfc-editor.org/rfcsearch.html
– UDP Encapsulation of IPsec ESP Packets – RFC3948
http://www.rfc-editor.org/rfcsearch.html
• Virtual IP and Virtual Ethernet preferred interface list enhancements
– iSeries Information Center -> Networking-> TCP/IP applications, protocols, and services
->TCP/IP routing and workload balancing
• Enterprise Extender
– iSeries Information Center -> Networking->Network communications->APPC, APPN, and HPR
– Enterprise Extender Implementation Guide, SG24-7359
http://www.redbooks.ibm.com/abstracts/sg247359.html?Open
– IBM Redbook: Migrating Subarea Networks to an IP Infrastructure Using Enterprise Extender, SG24-
5957 (Enterprise Extender concepts)
http://www.redbooks.ibm.com/abstracts/sg245957.html?Open
• PTF recommendations for Enterprise Extender or check the web at:
– http://www-912.ibm.com/s_dir/slkbase.nsf/$$Search?openform

IBM Power Systems
Special notices
This document was developed for IBM offerings in the United States as of the date of publication. IBM may not make these offerings available in
other countries, and the information is subject to change without notice. Consult your local IBM business contact for information on the IBM
offerings available in your area.
Information in this document concerning non-IBM products was obtained from the suppliers of these products or other public sources. Questions
on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give
you any license to these patents. Send license inquires, in writing, to IBM Director of Licensing, IBM Corporation, New Castle Drive, Armonk, NY
10504-1785 USA.
All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives
only.
The information contained in this document has not been submitted to any formal IBM test and is provided "AS IS" with no warranties or
guarantees either expressed or implied.
All examples cited or described in this document are presented as illustrations of the manner in which some IBM products can be used and the
results that may be achieved. Actual environmental costs and performance characteristics will vary depending on individual client configurations
and conditions.
IBM Global Financing offerings are provided through IBM Credit Corporation in the United States and other IBM subsidiaries and divisions
worldwide to qualified commercial and government clients. Rates are based on a client's credit rating, financing terms, offering type, equipment
type and options, and may vary by country. Other restrictions may apply. Rates and offerings are subject to change, extension or withdrawal
without notice.
IBM is not responsible for printing errors in this document that result in pricing or information inaccuracies.
All prices shown are IBM's United States suggested list prices and are subject to change without notice; reseller prices may vary.
IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.
Any performance data contained in this document was determined in a controlled environment. Actual results may vary significantly and are
dependent on many factors including system hardware configuration and software design and configuration. Some measurements quoted in this
document may have been made on development-level systems. There is no guarantee these measurements will be the same on generally-
available systems. Some measurements quoted in this document may have been estimated through extrapolation. Users of this document
should verify the applicable data for their specific environment.
Revised September 26, 2006
IBM Power Systems
Special notices (cont.)

IBM, the IBM logo, ibm.com AIX, AIX (logo), AIX 6 (logo), AS/400, Active Memory, BladeCenter, Blue Gene, CacheFlow, ClusterProven, DB2, ESCON, i5/OS, i5/OS
(logo), IBM Business Partner (logo), IntelliStation, LoadLeveler, Lotus, Lotus Notes, Notes, Operating System/400, OS/400, PartnerLink, PartnerWorld, PowerPC, pSeries,
Rational, RISC System/6000, RS/6000, THINK, Tivoli, Tivoli (logo), Tivoli Management Environment, WebSphere, xSeries, z/OS, zSeries, AIX 5L, Chiphopper, Chipkill,
Cloudscape, DB2 Universal Database, DS4000, DS6000, DS8000, EnergyScale, Enterprise Workload Manager, General Purpose File System, , GPFS, HACMP,
HACMP/6000, HASM, IBM Systems Director Active Energy Manager, iSeries, Micro-Partitioning, POWER, PowerExecutive, PowerVM, PowerVM (logo), PowerHA, Power
Architecture, Power Everywhere, Power Family, POWER Hypervisor, Power Systems, Power Systems (logo), Power Systems Software, Power Systems Software (logo),
POWER2, POWER3, POWER4, POWER4+, POWER5, POWER5+, POWER6, POWER7, pureScale, System i, System p, System p5, System Storage, System z, Tivoli
Enterprise, TME 10, TurboCore, Workload Partitions Manager and X-Architecture are trademarks or registered trademarks of International Business Machines Corporation
in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (®
or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be
registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at
www.ibm.com/legal/copytrade.shtml
The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
UNIX is a registered trademark of The Open Group in the United States, other countries or both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries or both.
Microsoft, Windows and the Windows logo are registered trademarks of Microsoft Corporation in the United States, other countries or both.
Intel, Itanium, Pentium are registered trademarks and Xeon is a trademark of Intel Corporation or its subsidiaries in the United States, other countries or both.
AMD Opteron is a trademark of Advanced Micro Devices, Inc.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries or both.
TPC-C and TPC-H are trademarks of the Transaction Performance Processing Council (TPPC).
SPECint, SPECfp, SPECjbb, SPECweb, SPECjAppServer, SPEC OMP, SPECviewperf, SPECapc, SPEChpc, SPECjvm, SPECmail, SPECimap and SPECsfs are
trademarks of the Standard Performance Evaluation Corp (SPEC).
NetBench is a registered trademark of Ziff Davis Media in the United States, other countries or both.
AltiVec is a trademark of Freescale Semiconductor, Inc.
Cell Broadband Engine is a trademark of Sony Computer Entertainment Inc.
InfiniBand, InfiniBand Trade Association and the InfiniBand design marks are trademarks and/or service marks of the InfiniBand Trade Association.
Other company, product and service names may be trademarks or service marks of others.
Revised February 9, 2010

IBM Power Systems
Notes on benchmarks and values

The IBM benchmarks results shown herein were derived using particular, well configured, development-level and generally-available computer systems. Buyers should
consult other sources of information to evaluate the performance of systems they are considering buying and should consider conducting application oriented testing. For
additional information about the benchmarks, values and systems tested, contact your local IBM office or IBM authorized reseller or access the Web site of the benchmark
consortium or benchmark vendor.
IBM benchmark results can be found in the IBM Power Systems Performance Report at http://www.ibm.com/systems/p/hardware/system_perf.html .
All performance measurements were made with AIX or AIX 5L operating systems unless otherwise indicated to have used Linux. For new and upgraded systems, AIX
Version 4.3, AIX 5L or AIX 6 were used. All other systems used previous versions of AIX. The SPEC CPU2006, SPEC2000, LINPACK, and Technical Computing
benchmarks were compiled using IBM's high performance C, C++, and FORTRAN compilers for AIX 5L and Linux. For new and upgraded systems, the latest versions of
these compilers were used: XL C Enterprise Edition V7.0 for AIX, XL C/C++ Enterprise Edition V7.0 for AIX, XL FORTRAN Enterprise Edition V9.1 for AIX, XL C/C++
Advanced Edition V7.0 for Linux, and XL FORTRAN Advanced Edition V9.1 for Linux. The SPEC CPU95 (retired in 2000) tests used preprocessors, KAP 3.2 for FORTRAN
and KAP/C 1.4.2 from Kuck & Associates and VAST-2 v4.01X8 from Pacific-Sierra Research. The preprocessors were purchased separately from these vendors. Other
software packages like IBM ESSL for AIX, MASS for AIX and Kazushige Goto’s BLAS Library for Linux were also used in some benchmarks.
For a definition/explanation of each benchmark and the full list of detailed results, visit the Web site of the benchmark consortium or benchmark vendor.
TPC http://www.tpc.org
SPEC http://www.spec.org
LINPACK http://www.netlib.org/benchmark/performance.pdf
Pro/E http://www.proe.com
GPC http://www.spec.org/gpc
VolanoMark http://www.volano.com
STREAM http://www.cs.virginia.edu/stream/
SAP http://www.sap.com/benchmark/
Oracle Applications http://www.oracle.com/apps_benchmark/
PeopleSoft - To get information on PeopleSoft benchmarks, contact PeopleSoft directly
Siebel http://www.siebel.com/crm/performance_benchmark/index.shtm
Baan http://www.ssaglobal.com
Fluent http://www.fluent.com/software/fluent/index.htm
TOP500 Supercomputers http://www.top500.org/
Ideas International http://www.ideasinternational.com/benchmark/bench.html
Storage Performance Council http://www.storageperformance.org/results
Revised March 12, 2009
IBM Power Systems
Notes on HPC benchmarks and values

The IBM benchmarks results shown herein were derived using particular, well configured, development-level and generally-available computer systems. Buyers should
consult other sources of information to evaluate the performance of systems they are considering buying and should consider conducting application oriented testing. For
additional information about the benchmarks, values and systems tested, contact your local IBM office or IBM authorized reseller or access the Web site of the benchmark
consortium or benchmark vendor.
IBM benchmark results can be found in the IBM Power Systems Performance Report at http://www.ibm.com/systems/p/hardware/system_perf.html .
All performance measurements were made with AIX or AIX 5L operating systems unless otherwise indicated to have used Linux. For new and upgraded systems, AIX
Version 4.3 or AIX 5L were used. All other systems used previous versions of AIX. The SPEC CPU2000, LINPACK, and Technical Computing benchmarks were compiled
using IBM's high performance C, C++, and FORTRAN compilers for AIX 5L and Linux. For new and upgraded systems, the latest versions of these compilers were used: XL
C Enterprise Edition V7.0 for AIX, XL C/C++ Enterprise Edition V7.0 for AIX, XL FORTRAN Enterprise Edition V9.1 for AIX, XL C/C++ Advanced Edition V7.0 for Linux, and
XL FORTRAN Advanced Edition V9.1 for Linux. The SPEC CPU95 (retired in 2000) tests used preprocessors, KAP 3.2 for FORTRAN and KAP/C 1.4.2 from Kuck &
Associates and VAST-2 v4.01X8 from Pacific-Sierra Research. The preprocessors were purchased separately from these vendors. Other software packages like IBM ESSL
for AIX, MASS for AIX and Kazushige Goto’s BLAS Library for Linux were also used in some benchmarks.
For a definition/explanation of each benchmark and the full list of detailed results, visit the Web site of the benchmark consortium or benchmark vendor.
SPEC http://www.spec.org
LINPACK http://www.netlib.org/benchmark/performance.pdf
Pro/E http://www.proe.com
GPC http://www.spec.org/gpc
STREAM http://www.cs.virginia.edu/stream/
Fluent http://www.fluent.com/software/fluent/index.htm
TOP500 Supercomputers http://www.top500.org/
AMBER http://amber.scripps.edu/
FLUENT http://www.fluent.com/software/fluent/fl5bench/index.htm
GAMESS http://www.msg.chem.iastate.edu/gamess
GAUSSIAN http://www.gaussian.com
ANSYS http://www.ansys.com/services/hardware-support-db.htm
Click on the "Benchmarks" icon on the left hand side frame to expand. Click on "Benchmark Results in a Table" icon for benchmark results.
ABAQUS http://www.simulia.com/support/v68/v68_performance.php
ECLIPSE http://www.sis.slb.com/content/software/simulation/index.asp?seg=geoquest&
MM5 http://www.mmm.ucar.edu/mm5/
MSC.NASTRAN http://www.mscsoftware.com/support/prod%5Fsupport/nastran/performance/v04_sngl.cfm
STAR-CD www.cd-adapco.com/products/STAR-CD/performance/320/index/html
NAMD http://www.ks.uiuc.edu/Research/namd
HMMER http://hmmer.janelia.org/
http://powerdev.osuosl.org/project/hmmerAltivecGen2mod Revised March 12, 2009

IBM Power Systems
Notes on performance estimates

rPerf for AIX
rPerf (Relative Performance) is an estimate of commercial processing performance relative to other IBM UNIX systems. It is derived from an
IBM analytical model which uses characteristics from IBM internal workloads, TPC and SPEC benchmarks. The rPerf model is not
intended to represent any specific public benchmark results and should not be reasonably used in that way. The model simulates some of
the system operations such as CPU, cache and memory. However, the model does not simulate disk or network I/O operations.
• rPerf estimates are calculated based on systems with the latest levels of AIX and other pertinent software at the time of system
announcement. Actual performance will vary based on application and configuration specifics. The IBM eServer pSeries 640 is the
baseline reference system and has a value of 1.0. Although rPerf may be used to approximate relative IBM UNIX commercial processing
performance, actual system performance may vary and is dependent upon many factors including system hardware configuration and
software design and configuration. Note that the rPerf methodology used for the POWER6 systems is identical to that used for the
POWER5 systems. Variations in incremental system performance may be observed in commercial workloads due to changes in the
underlying system architecture.
All performance estimates are provided "AS IS" and no warranties or guarantees are expressed or implied by IBM. Buyers should consult
other sources of information, including system benchmarks, and application sizing guides to evaluate the performance of a system they are
considering buying. For additional information about rPerf, contact your local IBM office or IBM authorized reseller.
========================================================================
CPW for IBM i
Commercial Processing Workload (CPW) is a relative measure of performance of processors running the IBM i operating system.
Performance in customer environments may vary. The value is based on maximum configurations. More performance information is
available in the Performance Capabilities Reference at: www.ibm.com/systems/i/solutions/perfmgmt/resource.html
Revised April 2, 2007

Ad01 Ee Sna

Uploaded by

Copyright:

Available Formats

Ad01 Ee Sna

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ad01 Ee Sna

Uploaded by

Copyright:

Available Formats

IBM Power Systems Technical University

October 18–22, 2010 — Las Vegas, NV

Implementing Enterprise Extender –

Session ID: AD01

© 2010 IBM Corporation

IBM Power Systems

2 © 2010 IBM Corporation

So Where does this leave me?

IBM Power Systems

Hardware Based SNA

Support for the RPQs is withdrawn as of July 31, 2010

IOPs WILL NOT MOVE FORWARD to POWER7 based systems

• The long and short of this answer is:

5 © 2010 IBM Corporation

IBM Power Systems

Previous SNA over IP network options

• End system requires SNA support

6 © 2010 IBM Corporation

7 © 2010 IBM Corporation

IBM Power Systems

No single solution is a clear winner

Parallel HPR SNA over

Some Very Very high

8 © 2010 IBM Corporation

• Enterprise Extender : High Performance Routing (HPR) over IP

IBM Power Systems

10 © 2010 IBM Corporation

Enterprise Extender Introduction

SNA Appl SNA Appl

• The purpose of Enterprise Extender (EE) is to carry SNA traffic over an IP

11 © 2010 IBM Corporation

IBM Power Systems

12 © 2010 IBM Corporation

Enterprise Extender – Supported functions

• Enterprise Extender (EE) provides full APPC support:

• Support for dependent LU communications to mainframes over

13 © 2010 IBM Corporation

IBM Power Systems

• The following services are supported by Enterprise Extender:

• Full APPN support is available:

14 © 2010 IBM Corporation

Enterprise Extender – Functions not supported

• Enterprise Extender (EE) does not provide Remote Workstation support.

• Third Party solutions exist to address this issue

• z/VSE and z/VM DO NOT support EE

15 © 2010 IBM Corporation

IBM Power Systems

• There are multiple OEM vendors that provide this capability.

16 © 2010 IBM Corporation

Reasons for moving to Enterprise Extender

• Allows SNA applications to stay competitive in the Internet age

• IBM provided planning statement in April 2005 that discussed

17 © 2010 IBM Corporation

IBM Power Systems

18 © 2010 IBM Corporation

Enterprise Extender Introduction – HPR Support

• HPR consists of two major components:

19 © 2010 IBM Corporation

IBM Power Systems

The IBM i system may be configured as either an ENDNODE or NETNODE.