IBM z13s Technical Manual page 201

Traffic can be IPv4 or IPv6, or non-IP, such as AppleTalk, DECnet, IPX, NetBIOS, or SNA.
HiperSockets devices are protocol-independent and Layer 3 independent. Each HiperSockets
device (Layer 2 and Layer 3 mode) has its own MAC address. This address allows the use of
applications that depend on the existence of Layer 2 addresses, such as Dynamic Host
Configuration Protocol (DHCP) servers and firewalls. Layer 2 support helps facilitate server
consolidation, and can reduce complexity and simplify network configuration. It also allows
LAN administrators to maintain the mainframe network environment similarly to
non-mainframe environments.
Packet forwarding decisions are based on Layer 2 information instead of Layer 3. The
HiperSockets device can run automatic MAC address generation to create uniqueness within
and across LPARs and servers. The use of Group MAC addresses for multicast is supported,
and broadcasts to all other Layer 2 devices on the same HiperSockets networks.
Datagram is 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 LPAR network. A
HiperSockets device can filter inbound dekagrams 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 configuration enables the creation
of high-performance and high-availability link layer switches between the internal
HiperSockets network and an external Ethernet network. It also can be used to connect to the
HiperSockets Layer 2 networks of different servers.
HiperSockets Layer 2 in the z13s server is supported by Linux on z Systems, and by z/VM for
Linux guest use.
z13s, z13, and the other zEnterprise CPCs (zEC12, zBC12, z196, and z114 servers), support
the HiperSockets Completion Queue function that is designed to allow HiperSockets to
transfer data synchronously if possible, and asynchronously if necessary. This feature
combines ultra-low latency with more tolerance for traffic peaks. With the asynchronous
support, during high volume situations, data can be temporarily held until the receiver has
buffers that are available in its inbound queue. The HiperSockets Completion Queue function
requires the following applications at a minimum:
z/OS V1.13
Linux on z Systems distributions:
– Red Hat Enterprise Linux (RHEL) 6.2
– SUSE Linux Enterprise Server (SLES) 11 SP2
z/VSE V5.1.1
z/VM V6.2 with maintenance
The z13s, z13, and the zEnterprise servers provide the capability to integrate HiperSockets
connectivity to the IEDN. This configuration extends the reach of the HiperSockets network
outside the CPC to the entire ensemble, which is displayed as a single Layer 2. Because
HiperSockets and IEDN are both internal z Systems networks, the combination allows
z Systems virtual servers to use the optimal path for communications.
In z/VM V6.2, the virtual switch function is enhanced to transparently bridge a guest virtual
machine network connection on a HiperSockets LAN segment. This bridge allows a single
HiperSockets guest virtual machine network connection to communicate directly with these
systems:
Other guest virtual machines on the virtual switch
External network hosts through the virtual switch OSA UPLINK port
Chapter 4. Central processor complex I/O system structure
173