![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This chapter describes the Advanced Peer-to-Peer Networking (APPN) class of service (COS) and how it is used to calculate routes in an APPN network.
The class of service database exists in all APPN network nodes and helps determine how traffic is routed within the APPN network. This database determines how sessions are routed based on such characteristics as transmission priority, security levels, line speed, propagation delay, and resistance (the desirability of routing on the node).
Levels of class of service are used because different applications have different response time and throughput requirements. For example, interactive applications (such as a session between a terminal user and a host) normally require faster data transmission and consistent response times, while batch file transfers require high throughput and are not response-time oriented.
The same method of calculating routes based on class of service is used for both Intermediate Session Routing (ISR) and High Performance Routing (HPR) traffic. However, using the default class of service tables, no special priority is given for HPR links over ISR links.
IBM has created a set of Systems Network Architecture (SNA)-defined mode names and corresponding class of service names that are applicable to the vast majority of user environments. When end stations issue a session request to the network node using the IBM defaults, the network node maps the mode name to one of the default classes of service. The default COS definitions are preconfigured in your bridge/router so you do not need to perform any configuration to use them.
Table 40 lists the IBM default mode names and corresponding class of service names. In the table, the pound character (#) is equivalent to the hex value X'7B' as defined in the IBM architecture documents. For more information on this value, see the IBM documents, Systems Network Architecture Type 2.1 Node Reference and Systems Network Architecture LU 6.2 Reference: Peer Protocols. For the contents of the default SNA class of service tables, see "Default Class of Service Tables" later in this chapter.
| 1
This mode is used only for the CP-SVR pipe for sessions between a DLUr and DLUs.
|
A session request may include a Class of Service/Transmission Priority Field (COS/TPF). If a session request includes a COS/TPF and the network node knows about it (if it is one of the IBM defaults or has been defined on the network node), the network node processes the request with the COS specified in the COS/TPF. If the network node does not know the COS, then it uses the mode name to map one. If the network node does not know about the mode name, the session request will be rejected. Some implementations default to #CONNECT if the network node does not know the mode name. If the session request does not have the COS/TPF, then the network node tries to map it; if the network node cannot map it, the session request will be rejected.
To accept nonstandard modes from the end node, a class of service name must be mapped to the mode name. For information on mapping mode names to customized class of service names and creating customized class of service tables to meet specialized needs, see "Creating Customized Class of Service Tables" next.
When you use customized class of service tables, you have more flexibility in determining how your network handles load balancing among different paths. You can also set prioritization of sessions and control response time. Customized COS definitions can also be useful for larger networks handling greater numbers of sessions. If a customized class of service mode name has been created on one of your end stations, then you also want to define the class of service on the network node.
If an end station issues a session request with a nonstandard mode, then a customized class of service must be created to handle that mode. If the nonstandard mode is not defined on the network node, the network node will use the default class of service for unknown mode names, which is #CONNECT.
To add a customized class of service to the bridge/router, follow these steps:
1 . Determine the transmission needs of the class of service, and the specific sessions the class of service will be used for.
2 . Create the customized class of service, specifying in order the class of service name, mode name, and transmission priority using:
ADD -APPN ConfigCOS <cos name> <transmit priority> [SNA defined COS name]
3 . Configure class of service node rows, specifying the class of service name and the other attributes of the node row, using:
ADD -APPN COSNodeRow <cos name> <weight>(0-255) [Congestion=min (Yes|No),max (Yes|No)] [Resistance=min,max]
4 . Configure transmission group rows, specifying the class of service name and other attributes of the transmission group using:
ADD -APPN COSTgRow <cos name> <weight>(0-255) [ConnectCost=min,max] [ByteCost=min,max] [Security=min,max] [PropDelay=min,max] [EffectCap=min,max] [Usd1=min,max] [Us2=min,max] [Usd3=min,max]
5 . To define the newly created class of service to the system, use:
SET -APPN COSDef = <cos name>
To map a class of service name to one or more mode names, use:
ADD -APPN ModetoCosMap <cos_name> <mode_name> [mode_name ...]
Use this command to map any mode names to a customized COS name you have created. An incoming session with the specific mode name will be able to map the mode name to the customized COS. You can also map mode names to default SNA classes of service.
To display a list of available classes of service, enter:
SHow -APPN COS
To display a list of all class of service node rows, including IBM default node tables, enter:
SHow -APPN COSNodeChar
To display a list of all class of service transmission group rows, including IBM default transmission group (TG) tables, enter:
SHow -APPN COSTgChar
To display a list of available modes, enter:
SHow -APPN Mode
To display a list of mode names that are mapped to class of service names, enter:
SHow -APPN ModetoCosMap
For more information about these parameters, see the APPN Service Parameters chapter in Reference for Enterprise OS Software.
To display a cached tree for a class of service showing the route to a destination node, including the weight of intermediate nodes, enter:
SHow -APPN TreeCache
The display shows all classes of service in the cache. Optionally, you can specify a class of service with this command.
To delete a customized class of service table, use
DELete -APPN ConfigCOS <cos name>
To delete a class of service node row, enter the DELete -APPN COSNodeRow command and specify the class of service name and row number to be deleted. For example, to delete node row 8 in the customized class of service "SanJose," enter:
DELete -APPN COSNodeRow SanJose 8
To delete a class of service transmission group row, enter the DELete -APPN COSTgRow command, and specify the class of service name and row number to be deleted. For example, to delete transmission group row 8 in the customized class of service "SanJose," enter:
DELete -APPN COSTgRow SanJose 8
The APPN class of service database determines the best routing path by comparing the various factors that make some paths more desirable than others. Among the factors considered are the congestion of nodes along the path, the resistance (desirability of routing) for the nodes along the path, and the characteristics of the transmission groups (such as byte cost and connection cost) between the nodes along the path.
Figure 178 is an example of an APPN network. In this example, the class of service tables are used to calculate the best path between the network node in San Jose and the network node in New York. This example shows a simple scenario with a single transmission group between each node. However, two TGs (also known as parallel TGs) are supported between network nodes.
There are several possible paths. For this example, the paths are designated as follows:
All nodes in the example are APPN network nodes.
Figure 178 
COS Example (Network Topology)
The first step in how routing and topology services determine the best path is by adding the weight of the nodes along the path. The weight of the individual nodes is determined by calculating such factors as node congestion and the resistance (desirability of routing) for each node.
Figure 179 shows the node characteristics of the nodes in the network. The figure shows the congestion and resistance values set for each node. The weight shown for each node is calculated by adding the relative factors of congestion and resistance. The lower the resistance, the more desirable the node is to route traffic through. For example, a resistance value of 0 indicates the node is highly desirable to route traffic through, a value of 128 indicates the median, meaning the node is neither highly desirable nor highly undesirable. A resistance value of 255 indicates the node is not desirable to route through.
The resistance plus the congestion value indicates the relative weight of the node. The lower the node weight, the more desirable the node is to route traffic through.
For example, the node in Seattle is uncongested while it has a resistance of 0, indicating it is a desirable node to route traffic through. In contrast, the node in Los Angeles is congested and has a rate of 200, indicating the node is less desirable for routing traffic through.
Figure 179 
COS Example (Calculating Node Weights)
The weight for a given path is calculated by determining the requirements of each path. The requirements are then measured against the class of service node table. The weight of the first node row that meets the requirement of the node is assigned to that node. To check the default node table for the IBM-defined class of service named #CONNECT, see Table 47.
To calculate the weight of a node, the resistance and congestion levels of that node are checked. The node table is then checked to determine the first node row in the table that would accept the requirements of that node; the weight assigned to the node is the weight of that node row. The lower the node row, the lower the weight assigned to the row; the lower the weight, the greater precedence that row has.
For example, the node in Denver has a resistance of 128 and is congested. A network node is congested if it has reached 90 percent of the maximum number of ISR sessions configured for that node. In the node row table, a node is considered either congested ("yes") or uncongested ("no").
When the node row table is used, each row is checked to find the first row that will accept the conditions. The process is as follows:
1 . Node row 1 is checked. The conditions are not satisfied because the maximum resistance allowed is 31.
2 . Node row 2 is checked. The conditions are not satisfied because the maximum resistance allowed is 63.
3 . Node rows 3 and 4 are checked and are also rejected because the maximum resistance values allowed are still lower than Denver's resistance value of 128.
4 . Node row 5 is checked, and because the maximum resistance allowed is 159, this is the first row that will accept all the conditions. Because the weight of row 5 is 60, that is the weight assigned to the Denver node.
In this example, if the Denver node were congested, the first node row that would satisfy all conditions would be row 7, which would then assign a weight of 120, changing the total weight of the path.
Using this formula, the appropriate weights of each node are calculated. Table 41 lists the correct weights for each node in the figure based on this class of service mode table. (If a different class of service mode is used, a different node table is used, which changes the various calculations.)
After the weight of each node is determined, then the weights of all nodes on a path are added together; this determines the total node weight of a given path. Based on the weight calculations in Table 41, the total node weight of each path is shown in Table 42.
|
Path |
Total Node Weight |
|---|---|
|
PATH A |
185 |
|
PATH B |
285 |
|
PATH C |
240 |
|
PATH D |
340 |
|
PATH E |
380 |
The table indicates that of the four paths, path A has the lowest weight, which does not mean that path A is the best path. Calculating the weight of the nodes along a path is only the first step. The weights of the transmission groups for each path are then calculated. Proceed to the next section.
The second factor determining the weight of a path is the weight of all the TGs along the path. The TG consists of the path between two adjacent network nodes. The number of TGs on a path is determined by the number of network nodes on the path; the more nodes on the path, the more TGs there are on the path. For example, on Path A, there are four TGs from the San Jose node to the New York node. On Path E, there are five TGs because Path E includes an additional node. Figure 180 shows the different transmission groups.
Figure 180 
COS Example (Configuring TG Weights)
Table 43 lists the same information contained in the figure. It lists the attributes of each TG used in calculating the weight of each TG. These attributes are for the example only. No user-defined parameters are used in the example.
To determine the weight of each TG, the class of service TG table is checked. The first row in the TG table that meets the requirements of that TG is used to calculate the weight of the TG.
For example, the TG between San Jose and Seattle has a connection cost of 255 and a byte cost of 128. It has an encoding capacity of 9,600. Table 47 shows the default TG values for the default class of service "#CONNECT."
When the TG row table is used, each row is checked to find the first row that will accept the conditions. The process is as follows:
1 . TG row 1 is checked. The conditions are not satisfied because both the connection cost and byte cost exceed the maximum in TG row 1. (If only one of the attributes exceeded the maximum, that would have been enough to reject TG row 1.)
2 . TG rows 2 through 5 are checked and are rejected because the TG's connection cost and byte cost exceed the maximums in those rows.
3 . TG row 6 is checked, and the TG's byte cost of 128 matches the maximum allowed in the TG row. The row does not satisfy all the conditions because the TG's connection cost is 255, and the maximum connection cost allowed in row 6 is 128.
4 . TG row 7 is checked and is again rejected because the maximum connection cost allowed is not high enough.
5 . TG row 8 is checked, and because it allows a maximum connection cost of 255, TG row 8 is the row assigned to the TG. Because the weight for TG row 8 is 240, this is the weight assigned for the TG between San Jose and Seattle.
After the weights of all the TGs are calculated, the weights of the four paths are calculated by adding the weights of each TG on the path. Table 45 lists the total TG weights for the four paths in the example.
|
Path |
Total TG Weight |
|---|---|
|
PATH A |
750 |
|
PATH B |
750 |
|
PATH C |
690 |
|
PATH D |
690 |
|
PATH E |
720 |
After the total TG weight for each path is calculated, this total TG weight is added to the total node weight to calculate the total weight for each path. Proceed to the next section.
To calculate the total weight of each path, the total node weight is added to the total TG weight. Table 46 lists the weight values for the four paths.
After calculating the total path weight, the class of service determines that the best route from the network node in San Jose to the network node in New York is Path C (San Jose DenverChicagoPhiladelphiaNew York) because Path C has the lowest weight.
Dynamic network conditions can affect the weight of a node. For example, if a node that is congested becomes uncongested, then the weight of the node will be lower. The changed node weight will affect the calculation of total path weights and change which is the best route. The APPN class of service calculates the best route at the time of the session request.
This section lists the default SNA class of service tables that are used for calculating routes. In all tables, the user-defined values are not shown; the minimum user-defined value is 0 and the maximum is 255.
Table 47 lists the default node table that applies to the different modes. The same node table is used regardless of the mode; it is the mode that determines the transmission priority that differentiates the calculation for node tables. See Table 40 for a list of the default modes and corresponding class of service names.
This section lists the default TG tables for each class of service.
Table 48 lists the default TG table for the default class of service #CONNECT. The corresponding mode name is blank (that is, no characters are entered), and the transmission priority is medium.
Table 49 lists the default TG table for the default class of service #BATCH. The corresponding mode name is #BATCH, and the transmission priority is low.
Table 50 lists the default TG table for the default class of service #BATCHSC. The corresponding mode name is #BATCHSC, and the transmission priority is low.
Table 51 lists the default TG table for the default class of service #INTER. The corresponding mode name is #INTER, and the transmission priority is high.
Table 52 lists the default TG table for the default class of service #INTERSC. The corresponding mode name is #INTERSC, and the transmission priority is high.
Table 53 lists the default TG table for the default class of service CPSVCMG. The corresponding mode name is CPSVCMG, and the transmission priority is network.
Table 54 lists the default TG table for the default class of service SNASVCMG. The corresponding mode name is either SNASVCMG or CPSVRMG, and the transmission priority in both cases is network.