![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This chapter describes how to configure your 3Com bridge/router to perform Advanced Peer-to-Peer Networking (APPN) High Performance Routing (HPR).
High Performance Routing is an advanced method of routing APPN sessions that provides greater scalability and performance than Intermediate Session Routing (ISR), the original APPN routing method. The improvements that HPR provides over ISR include:
You can configure ports on the NETBuilder II bridge/router to perform either ISR or HPR. By default, HPR is enabled on APPN ports and adjacent link stations. If you want to configure specific ports or link stations for ISR, you must disable HPR on those ports or link stations. For more information about configuring the bridge/router as an APPN network node for ISR, see the Configuring APPN Intermediate Session Routing chapter.
For conceptual information about HPR, see "How HPR Works" later in this chapter.
HPR networks operate over network nodes and end nodes like ISR networks. The NETBuilder II bridge/router can be configured as a network node only; because the bridge/router does not provide any application programs on the SNA network, it cannot act as an end node or LEN end node.
When you configure the NETBuilder II bridge/router as an HPR network node, it can function as a Rapid Transport Protocol (RTP) tower node. For an explanation of RTP tower nodes and the other types of HPR network nodes, see "HPR Node Types"later in this chapter.
Before beginning this procedure, complete the following tasks:
APPN routing is supported only on NETBuilder II bridge/routers with DPE modules.
Configuring the Network Node to Perform HPR
Prerequisites
You must perform this configuration before starting APPN. For more information on configuring LAA, see the Configuring LAN Address Administration chapter.
To set up the bridge/router network node to perform HPR, follow these steps:
1 . Set your APPN ports to support HPR by performing one of the following steps:
SETDefault !<port> -APPN PortDef = <DLC type> (LLC2|FR|PPP|DLSW|SDLC|UNdef) <max_btu_size>(99-8192) [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)]
Make sure to specify HPR=Yes, and specify whether you want the port to provide link level error recovery. You can specify the other optional values of the PortDef parameter as desired.
Setting ErrorRecovery to Yes provides link-level error recovery for the incoming connection only. If you want link-level error recovery for the outgoing connection, then you must specify Yes for the ErrorRecovery value when setting the AdjLinkSta or SdlcAdjLinkSta parameter. If you set the port data link control (DLC) type to DLSW or SDLC, then link-level error recovery is enabled by default. If you set the port DLC type to LLC2, FR, or PPP, then you must specify error recovery support if desired.
If you use error recovery, it will create additional overhead on the link.
To configure port 7 for Frame Relay at a maximum basic transmission unit (BTU) size of 1033 and to enable support for HPR and error recovery, enter:
SETDefault !7 -APPN PortDef = FR 1033 HPR=Yes ErrorRecovery=Yes
2 . Define adjacent link stations for HPR by performing one of the following steps:
ADD !<port> -APPN AdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) [[Cmac|Ncmac] dest media addr] [Sap=<num>] [CPName=[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)] [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)]
Make sure to specify the adjacent link station as an HPR node by specifying HPR=Yes. If you want link level error recovery for the outgoing connection, specify ErrorRecovery=Yes. You can specify the other optional values as desired.
ADD !<port> -APPN SdlcAdjLinkSta <type>(NN|EN|Learn) <max_btu_size>(99-8912) <station addr>(Hex 1-FE) [CPName=<[netid.]cpname] [Nodeid=<ID>] [LinkName=<name>] [TGprof=<name>] [AutoStart=(Yes|No)] [CPSess=(Yes|No)] [HPR=(Yes|No)] [ErrorRecovery=(Yes|No)] [SendWindow=<num>] [ContactTimer=<num>] [NoRspTimer=<num>] [NoRspTimRetry=<num>]
Make sure to specify the adjacent link station as an HPR node by specifying HPR=Yes. If you want link level error recovery for the outgoing connection, specify ErrorRecovery=Yes. You can specify the other optional values as desired.
When you configure HPR over SDLC connections, HPR must be enabled on both sides of the SDLC connection.
For more information on the full syntax of these parameters, see the APPN Service Parameters chapter in Reference for Enterprise OS Software.
APPN over SDLC connections is supported on the NETBuilder II HSS-3-Port V.35 module only.
3 . If you have not done so already, define the link characteristics using:
SETDefault -APPN LinkStaCHar = <LinkStation name> [EffectCap=<string>] [ConnectCost=<0-255>] [ByteCost=<0-255>] [Security=<string>] [PropDelay=<string>] [Usd1=<0-255>] [Usd2=<0-255>] [Usd3=<0-255>]
4 . To enable the bridge/router to function as an APPN network node, enter:
SETDefault -APPN CONTrol = Enable
After HPR has been configured on the network node and the node has been enabled, the network node can participate in the HPR network. If the network node is part of an ISR environment, an HPR subnet can be created. Depending on how you set up your network, the network node can be either an HPR endpoint (for Rapid Transport Protocol (RTP) connections) or an HPR intermediate node (for Automatic Network Routing). An HPR node does not become an RTP endpoint until it accepts a session through it.
Not all devices that support APPN support HPR. If you configure an adjacent link station to a device that does not support HPR, RTP connections cannot take place, but ISR sessions can.
After you have configured two adjacent network nodes for HPR, and they have established the appropriate RTP connection, an HPR subnet is created, even if the two nodes reside within an APPN ISR network. When you create a mixed HPR and ISR environment, you only gain the benefits HPR provides on those links where both partner nodes support HPR. On links where one node is HPR-capable and the partner node is not, the link defaults to normal APPN ISR operation.
Figure 169 is an example in which two network nodes within an APPN ISR network have been upgraded to support HPR. In this example, only the links between the HPR-capable nodes support HPR operation, including RTP connections. Since there are alternate paths that are ISR only, you will not gain the benefits that HPR provides because the topology routing services and class of service used to calculate routes do not provide greater weight to the HPR paths over ISR paths. As a result, mixing HPR nodes and ISR nodes in this type of configuration is not recommended.
You can create customized class of service tables to prioritize HPR paths over ISR paths, but you will need to do extra configuration. For more information on customizing class of service, see the Configuring APPN Class of Service chapter.
Figure 169 
HPR Subnet within APPN ISR Network
Figure 170 is an example in which HPR nodes and ISR nodes are mixed over a path. In the top example, two HPR nodes form an HPR subnet, and an ISR node is between two HPR nodes. The result is that the third HPR node is isolated, and the benefits of HPR are limited to only the HPR subnet. In the bottom example, the ISR node is converted to support HPR, which chains all four HPR nodes together to form a larger HPR subnet, extending the benefits of HPR over a larger portion of the network.
Figure 170 
Chaining HPR Nodes to Form HPR Subnet
3Com recommends that you design your network so that HPR nodes reside either:
By configuring HPR nodes within a larger HPR subnet on the network backbone, you gain the high-speed benefits and processing efficiencies that HPR provides. Figure 171 is an example of an HPR subnet used on a network backbone connecting multiple ISR networks.
Figure 171 
HPR Subnet on a Network Backbone
You can configure HPR with Boundary Routing so that the NETBuilder II bridge/router acting as an HPR node is also acting as the central node in the Boundary Routing topology. Because the Superstack II NETBuilder bridge/router, acting as the leaf node at the remote site, does not support APPN in either ISR or HPR mode, the NETBuilder II bridge/router at the central site provides the HPR boundary function (to translate ISR traffic to HPR and vice-versa).
Figure 172 is an example in which HPR is configured with Boundary Routing at a remote site where an APPN connection network has also been configured. In the example, network node A (the central node) is an RTP tower node for HPR and is maintaining RTP connections with network node B. The central node is also providing the boundary function to the APPN end nodes at the remote site. For more information about Boundary Routing system architecture, see the Configuring Boundary Routing System Architecture chapter.
Figure 172 
HPR and Boundary Routing
After the network node has been configured for HPR, you can perform tasks such as setting RTP connection timers and initiating nondisruptive path switching.
To set the timers for RTP connections, use:
SetDefault -APPN HprTimer = [AliveTimer=<30-600>] [PathSwitchTimerLow=<240-960>][PathSwitchTimerMed=<120-480>] [PathSwitchTimerHigh=<60-240>][PathSwitchTimerNtwk=<30-120>]
Using this command, you set the timer settings for the RTP connection. Changing this parameter only affects new RTP connections, and has no effect on existing RTP connections. The options allow you to set the path switch timer for connections with low, medium, high, or network priority.
To display a list of RTP connections, use:
SHow -APPN RTP [name]
To display statistical information regarding RTP connections, use:
SHow -APPN RTPStats [name]
For information about the contents of these displays, see the APPN Service Parameters chapter in Reference for Enterprise OS Software.
A nondisruptive path switch can be triggered for several reasons, such as a local or remote link failure, or an RTP connection failure detection. When one of these failures occurs, the system initiates the path switch to try to determine if an alternate path is available. Normally, this nondisruptive path switching occurs automatically.
Using the PathSwitch command, you can request that the system switch an RTP connection to an alternate path. When a path switch is initiated, the system checks all available paths in the HPR topology to determine if a more desirable path is available. If a more desirable path is available, the RTP connection switches to that path; if the current path is the most desirable, then the system remains at the current path.
To initiate a nondisruptive path switch, enter:
PathSwitch <RTP name>
You must specify the RTP connection name that you want the system to switch.
To obtain a list of RTP connection names, enter:
SHow -APPN RTP
You cannot specify the new path to switch to; the system determines which path to switch to.
You can only switch paths from one HPR path to another; you cannot switch an RTP connection to a path running APPN ISR traffic.
For more information about nondisruptive path switching, see "Nondisruptive Path Switching" later in this chapter.
High Performance Routing is designed to work in conjunction with APPN Intermediate Session Routing (ISR) network nodes. HPR nodes perform many of the same functions as ISR nodes. For example, HPR nodes use the same method of calculating routes based on the Topology Routing Service database and class of service tables. HPR nodes also supports such APPN features as connection networks and support for parallel transmission groups (TGs).
In the HPR architecture, both partner nodes must support HPR for RTP connections to take place between the nodes. If one node supports HPR and the partner node does not, then the link will support ISR functionality only.
For more complete information regarding HPR, see the IBM document APPN Architecture and Product Implementations Tutorial (GG24-3669-92).
There are two different levels of HPR node functionality:
Base HPR nodes support Automatic Network Routing (ANR) and can only act as intermediate nodes in an RTP connection. Base HPR nodes cannot be the endpoint of an RTP connection. The 3Com bridge/router cannot act as a base HPR node.
RTP tower nodes can be either RTP endpoints or RTP connection intermediate nodes performing the ANR function. When acting as RTP endpoints, RTP tower nodes perform adaptive-rate-based flow control. If the RTP tower node is connected to an APPN ISR subset, then it performs the boundary function, which joins a session in the HPR subnet with a session in the APPN ISR subnet. The 3Com bridge/router network node acts as an RTP tower node in the HPR network.
Figure 173 shows the relationship of the different node types in an HPR network.
Figure 173 HPR Node Types
For the APPN HPR network node to provide HPR functionality on a link, the partner node device must also support HPR. IBM devices that support HPR include:
This list is not complete, and other devices may support HPR in the future. HPR can be supported on APPN network nodes and end nodes.
Automatic Network Routing is a source routing protocol used to route LU6.2 session and control traffic from node-to-node through an HPR network or subnet. ANR operates at the lower end of the SNA Path Control layer.
Unlike most SNA traffic, which is normally connection-oriented, ANR packets are connectionless, and HPR routes these network layer packets independently. These packets contain a network layer header that carries routing information. Because the routing information is processed at the network layer, this processing is more efficient than the processing for ISR packets.
The routing information is contained in the ANR routing field, which consists of a string of ANR labels. Each label describes the path from one node to the next immediate node; the ANR label string describes the path from the source HPR node to the destination HPR node of the RTP connection.
When an HPR node receives an ANR packet, it checks the first label of the ANR routing field and uses that label to determine which link to send the outgoing packet over. That label is then stripped from the ANR routing field, so the receiving node can check the next label in the ANR routing string.
Figure 174 shows how ANR routes network layer packets and how ANR labels are used to route the packets from node-to-node, and then are stripped when they are no longer needed. In the figure, the ANR label from network node A to network node D is A0-A0-85, and at each intermediate node the first part of the label is stripped from the packet.
Figure 174 
ANR Label Processing
The ANR label is from 1 to 8 bytes long and is of local significance on the node only. ANR labels only need to be unique on the local node, not on the larger network. In the figure, the label A0 is used several places, but the duplication is acceptable as long as the A0 label is unique on each node. In addition, ANR labels can be of different sizes within a node.
Rapid Transport Protocol is a reliable connection-oriented protocol that HPR uses to carry session traffic through an HPR network. It routes logical unit-to-logical unit (LU-LU) session traffic flows between the two RTP connection endpoints using the ANR routing method. RTP provides the following features:
RTP connections are logical connections between two nodes over a specific path in an HPR network. These logical connections are used to transport full-duplex session traffic end-to-end between the two nodes. RTP connections support a single class of service on each connection, enabling all traffic on the connection to use the same transmission priority. You can multiplex multiple sessions of the same class of service over one RTP connection, but all traffic on a given session must flow on the same RTP connection. If you have multiple sessions with different classes of service, then the bridge/router uses different RTP connections for each class of service.
Figure 175 is an example of an RTP connection across several nodes in an HPR subnet. LUa on EN1 is connected to LUb on EN2. In between the two end nodes is an HPR subnet, with the RTP connection spanning across it.
You can have multiple sessions with the same class of service on an RTP connection. All traffic using a specific class of service travels on the same RTP connection (the 3Com HPR implementation does not support sending traffic of the same class of service over different RTP connections). The figure also shows the ANR routing packets being forwarded from node-to-node.
Figure 175 
RTP Connection Across HPR Subnet
You can have multiple RTP connections between HPR nodes, with each RTP connection handling a different class of service. In Figure 176, there are multiple RTP connections. One RTP connection is used for batch sessions (using the BATCH class of service), and one RTP connection is used for interactive sessions (using the INTERACTIVE class of service).
Figure 176 
Multiple RTP Connections Using Different Classes of Service
Through RTP, HPR provides nondisruptive path switching, which enables the node to switch an RTP connection to a new path if the current path fails or the link fails. When the system initiates a path switch, it attempts to switch the RTP connection to the most desirable path at the time. This process enables dynamic rerouting in case of link failure, and the rerouting takes place fast enough not to disrupt the active sessions. The most desirable path at the time is the HPR-only route with the lowest weight. Even if there is an alternative ISR-only path that has a lower weight than the lowest-weight HPR route, the lowest weight HPR route is chosen.
The node can trigger a path switch in one of the following situations:
When an RTP endpoint periodically sends out a status request to its partner, if a reply is not received within the specified time set by the HprTimer parameter, the RTP endpoint sends a state exchange request to determine the status. If this state exchange fails after several retries, then the RTP endpoint determines that the RTP connection failed and triggers a path switch.
If a local link associated with an RTP connection fails, the system can initiate a path switch faster than relying on the RTP connection failure detection.
When a user initiates a path switch, the system checks to determine the most desirable path to switch the RTP connection to. If the current path is the most desirable path, the system remains at the current path.
Figure 177 is an example where nondisruptive path switching takes place. In the figure, all network nodes shown are in an HPR network. There is an RTP connection between network node A and network node F, and network node C serves as an intermediate node on the path. When the link between node C and node F goes down and the connection times out, a nondisruptive path switch is triggered from network node A. Network node A uses Topology Routing Services (TRS) to determine the best alternate path. The least cost alternate path is the one that goes to network node C, then through network nodes D and E, and then to node F. The logical RTP connection remains up, even though one of the original links failed.
Figure 177 
Nondisruptive Path Switching (Example)
Adaptive-rate-based congestion and flow control is a mechanism for RTP endpoints to regulate the amount of traffic entering the HPR network. This method determines if the network is congested based on the rate of traffic entering the network, the rate of traffic leaving the network, and the buffer situation of the receiving RTP endpoint. Attempts are made to allocate equal bandwidth to all RTP connections over a link that is shared by the RTP connections. However, sessions sharing one RTP connection require individual session pacing to ensure that any one session does not occupy the whole RTP connection.
Table 39 lists APPN features supported on ISR nodes (base APPN) and features supported on HPR-capable nodes. This information applies to the 3Com implementation of both HPR and ISR.
| 1
Route calculation operates the same for both ISR and HPR nodes. By default, no priority is given to paths
between HPR nodes vs. paths between ISR nodes.
|