The inbound admission policy is used to control the connection requests coming into your network.
The inbound policy is used to restrict traffic that is attempting to connect to your system. You can restrict access by client, Uniform Resource Identifier (URI), application, or local interface on your system. In addition, you can enhance system performance by applying a class of service to inbound traffic. You define this policy through the Inbound Admission wizard in iSeries™ Navigator.
There are three components to an inbound policy that require more information. They include URIs to restrict traffic, connection rates defined in a class of service, and priority queues to order successful connections. For more information, see URI, Connection rate, and Weighted priority queues.
You might consider using an inbound policy to restrict HTTP traffic connecting to your Web server. In this circumstance, you might create an inbound admission policy that restricts traffic by a specific URI. URI request rate is part of a solution to help protect servers against overload. Designating specific URIs applies admission controls, based on application- level information, to limit the URI requests accepted by the server. In industry, this is also referred to as header-based connection control, which uses URIs to set priorities.
Specifying a URI allows the inbound policy to examine content, not just packet headers. The content examined is a URI name. For the i5/OS® operating system, you can use the relative URI name (for example, /products/clothing ).
The relative URI is actually a subset of an absolute URI (similar to the old absolute URL). Consider this example: http://www.ibm.com/software. The http://www.ibm.com/software segment is considered the absolute URI. The /software segment is the relative URI. All relative URI values must begin with one forward slash (/). The following segments are valid relative URI examples:
Before you set up an inbound policy that uses URIs, ensure that the application port assigned for the URI matches the Listen directive enabled for Fast Response Cache Accelerator (FRCA) in the Apache Web Server configuration. To change or see the port for your HTTP server, see Manage addresses and ports for your HTTP server (powered by Apache).
As part of the inbound admission policy, you also must select a class of service. This class of service defines connection rates that act as admission control to limit the connections accepted by the system.
Connection rate limits acceptance or denial of a new packet, based on the average number of connections per second and the maximum number of instantaneous connections defined in the policy you create. These connection limits consist of an average rate and a burst limit, which you enter through iSeries Navigator wizards. When incoming connection requests reach the operating system, the system analyses the packet header information to determine whether this traffic is defined in a policy. The system verifies this information against the connection limits profile. If the packet is within the policy limits, it is placed into the queue.
Use the above information as you complete the Inbound admission wizard. In iSeries Navigator, you can also use the associated Help to see similar information as you complete the policy.
As part of inbound control, you can specify the priority in which connection requests are handled after they have been evaluated by the policies. By assigning a weight to a priority queue, you are essentially controlling the queue's response time after a connection has arrived. If queued, the connection is handled in order of queue priority (high, medium, low, or best effort). If you are unsure of what weights to assign, use the default values. The sum of all the weights must equal 100. For example, if 25 is specified for all priorities, then all queues are treated equally. Suppose that you specify the following weights: High (50), Medium (30), Low (15), and Best effort (5). The accepted connections include:
Related concepts
Class of service Average connection rate and burst limits