Additional IPSec assist using System z Integrated Information Processor (zIIP IP security)

On a System z9® or later server, an additional assist for IPSec protocol traffic is available with the System z® Integrated Information Processor (zIIP). To enable zIIP IP security in Communications Server, specify ZIIP IPSECURITY on the GLOBALCONFIG statement. With zIIP IP security enabled, traffic using the AH and ESP protocols can be processed on available zIIPs. When enabled on a z9® or later z/OS® image that includes zIIPs, the zIIP IP security function can reduce the IPSec processing load on general purpose central processors, beyond what is achievable using just CPACF or the Cryptographic Coprocessor.

When zIIP IP security is enabled, you might have to modify some Workload Manager (WLM) definitions. The IPSec traffic that can be processed on available zIIP processors is assigned to an independent WLM enclave. The WLM independent enclave encapsulates the IPSec workload as execution units that are separately classified and managed in a WLM service class. See the following considerations:

• All WLM independent enclaves that are not classified are assigned WLM service class SYSOTHER (with a goal of discretionary). In many cases, enclave workload using this service class can result in performance degradation if the workload is left unclassified in the service definition. Also, service that is accumulating in the SYSOTHER service class is an indication that you have unclassified workload in your system.
• Examine the IIPHONORPRIORITY parameter located in the IEAOPTxx member of SYS1.PARMLIB. When this parameter is specified as NO, general purpose central processors do not process zIIP-eligible workload when zIIPs are online. Omitting the IIPHONORPRIORITY parameter or specifying IIPHONORPRIORTY=YES allows zIIPs to request help from general-purpose central processors when the zIIPs can not complete all zIIP-eligible workload within a reasonable period of time (see ZIIPAWT in z/OS MVS Initialization and Tuning Reference).
• If there are any other workloads that are eligible to run on your zIIPs, analyze your current WLM workload goals and make any necessary adjustments. For example, if you are operating a workload that is more latency-sensitive than the typically longer running IPSec workloads, such as Db2® Distributed Relational Database Architecture™ (DRDA) workload, consider classifying the IPSec workload to make it less preferable than the workload that is more latency-sensitive.
  Guideline: Make these two performance goal settings for the IPSec independent enclave:

  • Set the WLM service class associated with the IPSec independent enclave to a lower execution velocity goal than that which is being assigned to the more latency-sensitive workload (such as Db2 DRDA). The lower execution velocity goal is chosen because the IPSec independent enclave has no associated transactions.
  • Set the WLM service class associated with the IPSec independent enclave to a greater importance level value (importance is defined in five levels, 1 to 5, with 1 indicating highest importance) than that which is being assigned to the more latency-sensitive workload (such as Db2 DRDA). Each WLM service class is associated with an importance level that specifies how important it is to your business that this workload is meeting its goal. The importance level defines how work is treated by the system. Achieving the velocity goal for IPSec traffic that can be processed on available zIIP processors is less important than the more latency-sensitive workload.

Because an independent enclave enables WLM to manage the priority of all workload in the enclave, you should classify the workload for IPSec traffic. To classify the independent enclave used for IPSec workload, make the following WLM service definitions using the WLM ISPF panels:

1. Create a workload for the IPSec traffic that will be operating on the independent enclave.

   From the primary WLM ISPF panel, select option 2 Workloads.

2. Create a service class that contains an appropriate performance goal for the IPSec independent enclave.

   On the primary WLM ISPF panel, select option 4 Service Classes. From this panel, define your new service class and associate it with the workload you previously defined. When you define the BASE GOAL information for your single defined period, choose the goal type Execution velocity. After this is selected, define a velocity and importance for the service class that you are defining. Set a value that takes into account other traffic that might be competing for zIIP or general central processor resources. (General central processors become a factor when you have set the IIPHONORPRIORITY parameter to the value YES in the IEAOPTxx member of SYS1.PARMLIB.)

3. Create a WLM subsystem type for TCP/IP.

   You must specify the subsystem type name as TCP; define it by using the WLM ISPF application. On the primary WLM ISPF panel, select option 6 Classification Rules; the Subsystem Type Selection List for Rules panel is displayed. Move your cursor to the field Subsystem-Type and press the Enter key. When you are prompted for the type of operation that you want to perform, select option 1 Create, because you want to create a new subsystem type. On the Create Rules for the Subsystem Type panel, specify the subsystem type TCP and a description for this new subsystem type.

4. Create a classification rule for the subsystem type TCP on the Create Rules for the Subsystem Type panel of the WLM ISPF application.
   Define a classification rule for the subsystem type. This rule determines what workload is associated with a service class for this subsystem type. You can use the following workload qualifiers for the new independent enclave for IPSec workload:

   • Subsystem Instance (SI) will be set to the job name of the TCP/IP stack
   • Transaction Name will be set to a value of TCPENC01

To verify that the new independent enclave is being used with an appropriate WLM service class, use the System Display and Search Facility (SDSF) ENC command or view the RMF Monitor III ENCLAVE report (or use any other method to interactively view RMF data).

For a more detailed description of defining Workload Manager (WLM) service definitions (workloads, service classifications, classification rules, subsystem type, and so on) and WLM in general, see System Programmer’s Guide to: Workload Manager (IBM® Redbooks®) and z/OS MVS Planning: Workload Management. For information about configuring the IIPHONORPRIORITY parameter in the IEAOPTxx member of SYS1.PARMLIB, see z/OS MVS Initialization and Tuning Reference. For more information about viewing enclaves using SDSF, see z/OS SDSF Operation and Customization. For additional information about the RMF workload activity report, see z/OS RMF Report Analysis.

On system models with no zIIPs (z990, or a z9 or later with no zIIPs configured), you can enable zIIP IP security so that you can project the percentage of existing IPSec workload (running on central processors) that would be eligible to run on zIIPs, if zIIPs were available on the z/OS image. To perform projection analysis, specify ZIIP IPSECURITY on the GLOBALCONFIG statement, and specify PROJECTCPU=YES in the IEAOPTxx member of SYS1.PARMLIB. Run your IPSec workload, and SMF provides accounting information regarding workload that is eligible to run on zIIPs. For information about configuring the PROJECTCPU parameter in the IEAOPTxx member of SYS1.PARMLIB, see z/OS MVS Initialization and Tuning Reference. For information about accounting for zIIP eligibility in SMF record types 30 and 7x, see z/OS MVS System Management Facilities (SMF). For information about zIIP-related reporting updates, see z/OS RMF Report Analysis.