Prioritized classes: How to classify network traffic

 

Differentiated service identifies traffic as classes. The most common classes are defined using client IP addresses, application ports, server types, protocols, local IP addresses, and schedules. All the traffic that conforms to the same class is treated equally.

For more advanced classification, you can specify the application data to set different levels of service for some of your i5/OS® applications. Using application data is optional, but might be helpful when you want to classify at a lower level. There are two types of application data: application token or Uniform Resource Identifier (URI). If the traffic matches the token or URI that you specify in the policy, the policy is applied to the outbound response, thus giving the outbound traffic whatever priority is specified in the differentiated service policy.

 

Using application token with differentiated service policies

Using application data enables the policy to respond to the specific parameters (token and priority) passed by the application to the operating system through the sendmsg() application programming interface (API). This setting is optional. If you do not need this level of granularity in your outbound policies, select All tokens in the wizard. You can match an application's token and priority with a specific token and priority that are set in the outbound policy. In the policy, there are two parts to set the application data: the token and the priority.

When you specify application token as the application data type, the application providing this information to the operation system must be specifically coded to use the sendmsg() API. This is done by the application programmer. The application's documentation should provide valid values (token and priority) that the QoS administrator uses in the differentiated service policy. The differentiated service policy then applies its own priority and classification to traffic that matches the token set in the policy. If the application does not have the values that match the values set in the policy, either update the application or use different application data parameters for the differentiated service policy.

 

Using a URI with differentiated service policies

When you create a differentiated service policy, the wizard allows you to set system data information, as discussed in the "Using application token with differentiated service policies" section. Although the fields in the wizard prompt you for an application token, you can instead specify a relative URI. Again, this is optional. If you do not need this level of granularity in your outbound policies, select All tokens in the wizard. You can match a specific URI set in the outbound policy.

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 a differentiated service policy that uses URIs, ensure that the application port assigned for the URI matches the Listen directive enabled for the fast response cache accelerator (FRCA) in the Apache Web Server configuration. To change or view the port for your HTTP server, see Manage addresses and ports for HTTP Server (powered by Apache).

FRCA identifies the URI for each outbound HTTP response. It compares the URI related to the outbound response to the URI defined in each differentiated service policy. The first policy with a token string (URI) that best matches the URI identified by FRCA is applied to all responses for the URI.

 

Parent topic:

Differentiated service

Related concepts
QoS sendmsg() API extensions