93 lines
6.4 KiB
HTML
93 lines
6.4 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-10-03" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>Optimize communications using high-performance routing</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="rzahjper-comhprfacts"></a>
|
||
|
|
<h3 id="rzahjper-comhprfacts">Optimize communications using high-performance routing</h3>
|
||
|
|
<p><span class="bold">High-performance routing</span> (HPR) is the next evolution
|
||
|
|
of Advanced Peer-to-Peer Networking® (APPN). HPR
|
||
|
|
is an extension of APPN and has many functional aspects common with APPN.
|
||
|
|
Configuring adjacent stations, search processing, and route computation are
|
||
|
|
the same in APPN and HPR. HPR differs from APPN in the areas of transport,
|
||
|
|
intermediate session routing, congestion control, and error recovery.</p>
|
||
|
|
<p>The following are the HPR protocol operational characteristics:</p>
|
||
|
|
<p>HPR supports a key availability enhancement that is called non-disruptive
|
||
|
|
path switching. This function provides the ability to recover from link or
|
||
|
|
node outages without having session failures. This makes the outage transparent
|
||
|
|
to the application. The application may experience a response time delay while
|
||
|
|
data traffic is being rerouted. On iSeries™, the amount of time the system takes
|
||
|
|
to establish a new path, or re-establish the original failed route path is
|
||
|
|
configurable. This error recovery feature is the key difference between APPN
|
||
|
|
and HPR.</p>
|
||
|
|
<p>HPR can support the non-disruptive path switching feature because of an
|
||
|
|
enhanced data transport mechanism that is called Rapid Transport Protocol
|
||
|
|
(RTP). RTP is the data transport protocol that is used between a pair of systems
|
||
|
|
that support the HPR RTP tower. This pair of systems establishes an RTP connection
|
||
|
|
which carries out APPN sessions (multiple APPN sessions can be multiplexed
|
||
|
|
over a single RTP connection). In order to establish an RTP connection between
|
||
|
|
a pair of HPR RTP tower systems, the following must be true:</p>
|
||
|
|
<ul>
|
||
|
|
<li>The set of nodes must support the HPR intermediate routing function.</li>
|
||
|
|
<li>The transmission groups (TGs) that exist between the two HPR RTP tower
|
||
|
|
systems must support the HPR intermediate routing function.</li></ul><p class="indatacontent"> This routing is known as Automatic Network Routing (ANR).</p>
|
||
|
|
<p>When an RTP node sends packets of data, it must keep those buffers until
|
||
|
|
the RTP node receives acknowledgment that its RTP partner has successfully
|
||
|
|
received the data. Maintaining detailed knowledge of data sent and received
|
||
|
|
is necessary in order to provide the additional value provided by HPR, the
|
||
|
|
non-disruptive path switching function. HPR does not rely on the data link
|
||
|
|
layer to provide data retransmission functions. HPR supports a function that
|
||
|
|
is called selective retransmission. With selective retransmission, only the
|
||
|
|
data which has not been acknowledged gets retransmitted. For example, if an
|
||
|
|
RTP node sends eight packets and all but the fourth packet is successfully
|
||
|
|
acknowledged, then only the fourth would retransmit. This differs from other
|
||
|
|
retransmission algorithms in which the first unsuccessful packet and all the
|
||
|
|
subsequent packets would transmit.</p>
|
||
|
|
<p>Nodes performing intermediate routing of HPR traffic or ANR, have no session
|
||
|
|
awareness. HPR uses source routing. The nodes performing ANR examine packets
|
||
|
|
as they receive them and determine the next hop of the route. The next hop
|
||
|
|
is based on something that is called the ANR label. All HPR packets contain
|
||
|
|
the ANR label. Any ANR that a network node is performing does <span class="bold">not</span> count as an APPN intermediate session. The maximum intermediate sessions
|
||
|
|
parameter that is configured by means of the Change Network Attribute (CHGNETA)
|
||
|
|
command has no effect on the ANR capacity of a system. Controlling the amount
|
||
|
|
of ANR that different systems will perform in a network is completely dependent
|
||
|
|
on the route selection phase of APPN session establishment.</p>
|
||
|
|
<p>When sessions are carried over RTP connections, any segmentation, or reassembly
|
||
|
|
is performed within the iSeries central processing unit (CPU). The
|
||
|
|
communications IOPs do not have the information required to perform the segmentation
|
||
|
|
and reassembly. The IOPs can not maintain the knowledge that is required by
|
||
|
|
HPR to perform the data retransmission and non-disruptive path switching function.</p>
|
||
|
|
<p>HPR uses a function called Adaptive Rated Based (ARB) congestion control.
|
||
|
|
ARB regulates the flow of traffic by predicting congestion in the network
|
||
|
|
and reducing the sending rate of a node into the network. ARB then attempts
|
||
|
|
to prevent congestion rather than reacting to it after it has occurred. If
|
||
|
|
all of the traffic occurring over a network was HPR, then ARB would be a fair
|
||
|
|
way of sharing the bandwidth of a network. ARB also allows high utilization
|
||
|
|
of the networking resources. When HPR traffic mixes with straight APPN or
|
||
|
|
TCP/IP traffic, the HPR throughput may suffer because the other protocols
|
||
|
|
do not practice similar congestion control techniques.</p>
|
||
|
|
<p>For more information about configuring HPR, see <a href="rzahjconappcpi.htm#rzahjconappc-pi">Configure APPC, APPN, and HPR</a>.</p>
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|