AD01_EE_SNA

© 2010 IBM Corporation

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 [email protected] I/T Specialist – Advanced Technical Skills

IBM Power Systems

© 2010 IBM Corporation2

•WAN, LAN, Token Ring, Twinax, April 2005The 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

The announcement:http://www-03.ibm.com/servers/eserver/iseries/support/planning/v5r3planning.html

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 AnyNetAnyNet 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 PTFssearch for document 23030736 for V5R4 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 IOPsIOPs 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 systemshttps://www-947.ibm.com/systems/support/i/planning/upgrade/v6r1/planstmts.htmlhttp://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 iSeriessystems 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.– You can use the same card you recognize as #2793 on a 9117-MMA or 9119-FHA. But you need to call it a #6833.– You can use the same card you recognize as #2849 on a 9117-MMA or 9119-FHA. But you need to call it a #3709.

IBM Power Systems


Previous SNA over IP network options

SNA SNAIPDLSw Router

IP

AnyNet

• 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

• Network is not aware of SNA traffic, thus no trafficprioritization possible

• AnyNet only supports Low Entry Networking (LEN)• no APPN or HPR

• No end-to-end non-disruptive session recovery

Data Link Switching (DLSw)DLSw Router

AnyNet

AnyNet

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

HPR TCP/IPParallel HPR

- TCP/IP networks

SNA over TCP/IP using

AnyNet

Pros

Very reliable, Large installed base, Trillions ofLoC in APPC applications available.

High scalability, lower TCO, becoming standard.

Can use newer TCP/IP apps while keeping legacy applications.

Has the combined strengths of the other three choices.

ConsSome

required HW reaching end of life. High TCO

Can not run critical legacy applications.

Very expensive and labor intensive to maintain.

Very high overhead. Difficult 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 AnyNetenvironment, IP routers are not aware of different SNA priorities.

IBM Power Systems


Enterprise Extender Introduction

• 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

IP NetworkUDP/IP

DLC

SNA Appl

EE/HPR

UDP/IP

DLC

SNA Appl

EE/HPR

IBM Power Systems


Notes:

• 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). 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:

• 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) 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 (APPN / HPR) traffic across an IP network

– AnyNet used TCP• error detection and retransmission services

provided by TCP– no application end-to-end protection

– SNA data sent as UDP payload

HPR packet

LDLC Hdr

SNA Appl

HPR packet

3 bytes

LDLC Hdr HPR packetUDP Hdr

8 bytes

n bytes

LDLC Hdr HPR packetUDP HdrIP Hdr

20 + bytes

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

B’001’HPR#BATCHLow12004

B’010’HPR#CONNECTMedium12003

B’100’HPR#INTERHigh12002

B’110’HPRN/ANetwork12001

B’110’LDLCN/AXID exchange12000

Precedence bits

TrafficDefault CoSCoS transmissionpriority

UDP Port

• 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

HdrLenVersionprec TOS

Service Type

Res

0 314 8 16

Total LengthPart of IP header (3) (4) (1)

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

IP Network

System: RCHSYSALocation name: RCHSYSAAPPN Network ID: APPNIP Address: 10.5.92.48

System: RCHSYSBLocation name: RCHSYSBAPPN Network ID: APPNIP 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

Network attribute ALWHPRTWR set to *YESon all systems where a HPR connection is established to

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 . . . . . . . . . . . . : *HPRIPOnline at IPL . . . . . . . . . . : *YES Remote internet address . . . . . : 10.5.92.32Local 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 . . . . . . . : 05600001Data 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

CFGTCP(1)INTNETADR(10.5.92.48)

CRTCTLAPPCCTLD(EEHPRB) LINKTYPE(*HPRIP) RMTINTNETA(10.5.92.32)LCLINTNETA(10.5.92.48)LDLCTMR(3 15 10)LDLCLNKSPD(*CAMPUS)MAXFRAME(1461) RMTNETID(APPN) RMTCPNAME(RCHSYSB) EXCHID(05600001)DSAP(04)SSAP(04)TMSGRPNBR(*CALC)

CHGNETA (or DSPNETA)LCLNETID(APPN)LCLCPNAME(RCHSYSA)ALWHPRTWR(*YES)

System: RCHSYSAMatching Parameters between two IBM i systems

CFGTCP(1)INTNETADR(10.5.92.32)

CRTCTLAPPCCTLD(EEHPRA) LINKTYPE(*HPRIP) RMTINTNETA(10.5.92.48)LCLINTNETA(10.5.92.32)LDLCTMR(3 15 10)LDLCLNKSPD(*CAMPUS)MAXFRAME(1461) RMTNETID(APPN) RMTCPNAME(RCHSYSA) EXCHID(05600001)DSAP(04)SSAP(04)TMSGRPNBR(*CALC)

CHGNETA (or CHGNETA)LCLNETID(APPN)LCLCPNAME(RCHSYSB)ALWHPRTWR(*YES)

System: RCHSYSB

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 configurationLCLEXCHID will match to the values IDBLK and IDNUM in the SWITCHED MAJOR NODE of VTAM for this locationLOCADDR 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

• When all *HPRIP controllers are varied on, use SNA applications–Example: STRPASTHR RMTLOCNAME(RCHSYSB)

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

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

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

IP Network(AnyNet)

LANSDLC

SYSA SYSB

SYSC

SYSD

APPN(HW)

LAN

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 migrate to HPRIP, do the following:

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

• 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

OpenUDP1200012001120021200312004

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


10.1.1.10 193.20.1.1

10.1.1.11 193.20.1.2

Source Addr Dest. Addr. SP DP

10.1.1.10 192.10.1.5 12002 12002


192.10.1.5 10.1.1.10 12002 12002


193.20.1.1 192.10.1.5 12002 12002


192.10.1.5 193.20.1.1 12002 12002

Outbound traffic Inbound traffic

10.1.1.10

192.10.1.5

Public Interface

Masquerading Function

193.20.1.1

Static NAT

TRUSTEDBORDER

UNTRUSTED

LAN or PPP link

Internet

CRTCTLAPPCCTLD(EEHPRB) LINKTYPE(*HPRIP) RMTINTNETA(192.10.1.5)LCLINTNETA(10.1.1.10)

CRTCTLAPPCCTLD(EEHPRB) LINKTYPE(*HPRIP) RMTINTNETA(193.20.1.1)LCLINTNETA(192.10.1.5)

Static NAT

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 : 040403NHDR : 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'XRH : ('0B9120'X) REQ FMD, FI, BCI, ECI, DR1, ERI, PI, CDI

RU Command . : FMH- 5=0C0502FF0003D000000206F1RU 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) - RFC4304http://www.rfc-editor.org/rfcsearch.html

– UDP Encapsulation of IPsec ESP Packets – RFC3948http://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

search for document 484227176 for V6R1 PTFssearch for document 23030736 for V5R4 PTFs

IBM Power Systems


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

Special notices

IBM Power Systems


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

Special notices (cont.)

IBM Power Systems


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.orgSPEC http://www.spec.orgLINPACK http://www.netlib.org/benchmark/performance.pdfPro/E http://www.proe.comGPC http://www.spec.org/gpcVolanoMark http://www.volano.comSTREAM 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.shtmBaan http://www.ssaglobal.comFluent http://www.fluent.com/software/fluent/index.htmTOP500 Supercomputers http://www.top500.org/Ideas International http://www.ideasinternational.com/benchmark/bench.htmlStorage Performance Council http://www.storageperformance.org/results

Revised March 12, 2009

Notes on benchmarks and values

IBM Power Systems


Revised March 12, 2009

Notes on HPC benchmarks and valuesThe 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.orgLINPACK http://www.netlib.org/benchmark/performance.pdfPro/E http://www.proe.comGPC http://www.spec.org/gpcSTREAM http://www.cs.virginia.edu/stream/Fluent http://www.fluent.com/software/fluent/index.htmTOP500 Supercomputers http://www.top500.org/AMBER http://amber.scripps.edu/FLUENT http://www.fluent.com/software/fluent/fl5bench/index.htmGAMESS http://www.msg.chem.iastate.edu/gamessGAUSSIAN http://www.gaussian.comANSYS 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.phpECLIPSE 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.cfmSTAR-CD www.cd-adapco.com/products/STAR-CD/performance/320/index/htmlNAMD http://www.ks.uiuc.edu/Research/namdHMMER http://hmmer.janelia.org/

http://powerdev.osuosl.org/project/hmmerAltivecGen2mod

IBM Power Systems


Revised April 2, 2007

Notes on performance estimatesrPerf 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 systemannouncement. 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

AD01_EE_SNA

Documents

Transcript of AD01_EE_SNA