Layer 2 transport mode is supported by z/VM and Linux on
System z.
OSA Layer 3 Virtual MAC for z/OS
To simplify the infrastructure and to facilitate load balanc-
ing when an LPAR is sharing the same OSA Media Access
Control (MAC) address with another LPAR, each operating
system instance can now have its own unique “logical” or
“virtual” MAC (VMAC) address. All IP addresses associ-
ated with a TCP/IP stack are accessible using their own
VMAC address, instead of sharing the MAC address of
an OSA port. This applies to Layer 3 mode and to an OSA
port shared among Logical Channel Subsystems.
This support is designed to:
• Improve IP workload balancing
• Dedicate a Layer 3 VMAC to a single TCP/IP stack
• Remove the dependency on Generic Routing Encapsu-
lation (GRE) tunnels
• Improve outbound routing
• Simplify confi guration setup
• Allow WebSphere Application Server content-based
routing to work with z/OS in an IPv6 network
• Allow z/OS to use a “standard” interface ID for IPv6
addresses
• Remove the need for PRIROUTER/SECROUTER function
in z/OS
OSA Layer 3 VMAC for z/OS is exclusive to System z, and
is applicable to OSA-Express3 and OSA-Express2 features
when confi gured as CHPID type OSD (QDIO).
Direct Memory Access (DMA)
OSA-Express3 and the operating systems share a
common storage area for memory-to-memory communi-
cation, reducing system overhead and improving perfor-
mance. There are no read or write channel programs for
data exchange. For write processing, no I/O interrupts
have to be handled. For read processing, the number of
I/O interrupts is minimized.
Hardware data router
With OSA-Express3, much of what was previously done in
fi rmware (packet construction, inspection, and routing) is
now performed in hardware. This allows packets to fl ow
directly from host memory to the LAN without fi rmware
intervention.
With the hardware data router, the “store and forward”
technique is no longer used, which enables true direct
memory access, a direct host memory-to-LAN fl ow, return-
ing CPU cycles for application use.
This avoids a “hop” and is designed to reduce latency and
to increase throughput for standard frames (1492 byte)
and jumbo frames (8992 byte).
IBM Communication Controller for Linux (CCL)
CCL is designed to help eliminate hardware dependen-
cies, 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 freeing up valuable
data center fl oor space.
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 z10 EC while exploiting and leveraging IP.
The OSA-Express3 and OSA-Express2 GbE and
1000BASE-T Ethernet features provide support for CCL.
This support is designed to require no changes to operat-
ing systems (does require a PTF to support CHPID type
OSN) and also allows TPF to exploit CCL. Supported by
z/VM for Linux and z/TPF guest environments.
OSA-Express3 and OSA-Express2 OSN (OSA for NCP)
OSA-Express for Network Control Program (NCP), Chan-
nel path identifi er (CHPID) type OSN, is now available for
use with the OSA-Express3 GbE features as well as the
OSA-Express3 1000BASE-T Ethernet features.
30