Hardware and software for the on demand operating environment
CCL is designed to help eliminate hardware dependencies, such as 3745/3746 Communication Controllers, ESCON channels, and Token-Ring LANs, by providing a software solution that allows the Network Control Program (NCP) to be run in Linux on System z. CCL helps preserve mission critical SNA functions, such as SNI, and z/OS applications workloads which depend upon these functions, allowing you to collapse SNA inside a zEC12, z196, z114, z10, or z9 system while exploiting and leveraging IP.
The OSA-Express4S 1000BASE-T Ethernet, OSA-Express3 and OSA-Express2 GbE and 1000BASE-T Ethernet features provide support for CCL with OSA-Express for NCP. This support is designed to require no changes to operating systems (does require a PTF to support CHPID type OSN) and also allows TPF to exploit CCL. If you continue to need SNA solutions that require NCP functions, you can now consider CCL as a migration strategy to replace your IBM Communication Controllers (374x).
OSA-Express for NCP can help to eliminate the requirement to have any form of external medium, and all related hardware, for communications between the host operating system and the CCL image. Traffic between the two images (operating system and CCL) is no longer required to flow on an external Local Area Network (LAN) or ESCON channel. CHPID type OSN supports both SNA PU Type 5 and PU Type 2.1 channel connectivity. Utilizing existing SNA support (multiple transmission groups), OSA for NCP support permits multiple connections between the same CCL image and the same host operating system image. It also allows multiple CCL images to communicate with multiple operating system images, supporting up to 180 connections (3745/3746 unit addresses) per CHPID type OSN. CHPID type OSN can also span logical channel subsystems. The CCL image connects to the OSA-Express4S, OSA-Express3, or OSA-Express2 feature using QDIO architecture and uses the Linux QDIO (qeth) support updated to support OSN device types. OSA-Express for NCP is supported on zEnterprise EC12, zEnteprise 196, zEnterprise 114, System z10, and System z9 using the OSA-Express4S 1000BASE-T Ethernet, OSA-Express3 and OSA-Express2 GbE SX, GbE LX, and 1000BASE-T Ethernet features, and requires the PCIe adapter to be configured as CHPID type OSN.
OSA-Express for NCP is for logical partition-to-logical partition connectivity. No external cables are required.
The Open Systems Adapter Integrated Console Controller function (OSA-ICC), which is supported by zEC12, z196, z114, z10 EC, z10 BC, z9 EC, z9 BC, z990, and z890, is supported by the OSA-Express4S, OSA-Express3, OSA-Express2, and OSA-Express 1000BASE-T Ethernet features. OSA-ICC supports the attachment of non-SNA 3270 terminals for operator console applications. With OSA-ICC, 3270 emulation for console session connections (TN3270E [RFC 2355] or non-SNA DFT 3270 emulation) is integrated in the System z platforms which can help eliminate the requirement for external console controllers (2074, 3174), helping to reduce cost and complexity. The OSA-ICC is enabled using CHPID type OSC.
The OSA-ICC supports up to 120 client console sessions per channel path identifier (CHPID) or PCIe adapter (OSA-Express4S, OSA-Express3) either locally or remotely. Support for this function is provided by z/OS, z/VM, VSE/ESA, z/VSE, and z/TPF.
The HiperSockets function, is an integrated capability of System z that provides users with high-speed "virtual" Local Area Network (LANs) attachments with minimal system and network overhead. It eliminates the need for any physical cabling or external networking connection between these virtual connections. Up to 32 HiperSockets are supported on zEC12, z196 and z114, and up to 16 HiperSockets on z10, z9, z990, and z890.
HiperSockets eliminates the need to utilize I/O subsystem operations and the need to traverse an external network connection to communicate between logical partitions in the same System z server. HiperSockets offers significant value in server consolidation connecting many virtual servers, and can be used instead of certain cross system coupling facility (XCF) link configurations in a Parallel Sysplex.
HiperSockets can be customized to accommodate varying traffic sizes. Since HiperSockets does not use an external network, it can free up system and network resources, eliminating attachment costs while improving availability, performance and security.
HiperSockets devices are protocol and Layer 3-independent. Each HiperSockets device (Layer 2 and Layer 3 mode) has its own MAC address designed to allow the use of applications that depend on the existence of Layer 2 addresses, such as DHCP servers and firewalls. Layer 2 support helps facilitate server consolidation, can reduce complexity, can simplify network configuration, and allows LAN administrators to maintain the mainframe network environment similarly as for non-mainframe environments.
Packet forwarding decisions are based on Layer 2 information instead of Layer 3. The HiperSockets device can perform automatic MAC address generation to create uniqueness within and across logical partitions and servers. The use of Group MAC addresses for multicast is supported as well as broadcasts to all other Layer 2 devices on the same HiperSockets networks.
Datagrams are delivered only between HiperSockets devices that use the same transport mode. A Layer 2 device cannot communicate directly to a Layer 3 device in another logical partition network. A HiperSockets device can filter inbound datagrams by VLAN identification, the destination MAC address, or both.
Analogous to the Layer 3 functions, HiperSockets Layer 2 devices can be configured as primary or secondary connectors or multicast routers. This enables the creation of high-performance and high-availability link layer switches between the internal HiperSockets network and an external Ethernet or to connect to the HiperSockets Layer 2 networks of different servers.
HiperSockets network traffic analyzer (HS NTA) for zEnterprise systems
Problem isolation and resolution is simpler using an enhancement to the HiperSockets architecture. This function is designed to allow tracing of Layer 2 and Layer 3 HiperSockets network traffic. HS NTA allows Linux on System z to control the trace for the internal virtual LAN to capture the records into host memory and storage (file systems) using Linux on System z tools to format, edit, and process the trace records for analysis by system programmers and network administrators. For more information refer to the HiperSockets Network Traffic Analyzer Frequently Asked Questions:
For additional information, consult IBM Redbooks, System z HiperSockets (SG24-6816) or IBM System z Connectivity Handbook (SG24-5444) at: http://www.redbooks.ibm.com.