Multiplex communications – Data flow congestion prevention or control – Flow control of data transmission through a network
Reexamination Certificate
1997-11-26
2001-04-10
Vu, Huy D. (Department: 2664)
Multiplex communications
Data flow congestion prevention or control
Flow control of data transmission through a network
C370S231000, C370S410000, C709S224000, C709S233000
Reexamination Certificate
active
06215772
ABSTRACT:
FIELD OF THE INVENTION
This invention is directed to the field of computer communication networks. It is more particularly directed to inter-operation among different types of communication networks.
BACKGROUND OF THE INVENTION
The computer communication network in a typical enterprise has changed substantially over the last two decades. Until the middle 80's most enterprise networks were based on IBM's SNA architecture. Such networks connected database servers, usually IBM mainframes, to several client terminals. However, since the late 80's, the use of IP in the enterprise network has become more prevalent. However, the applications in the client and the mainframe are largely the original SNA-based ones. In such an environment, one needs to transport SNA application data over an IP network efficiently. The typical communication occurs between two SNA networks, which are connected by an intermediary IP network.
These computer communications networks in the enterprise interconnect these different terminals, work-stations, personal computers, servers and host and enable them to inter-operate. The inter-operation between these machines is obtained by using a common communication protocols and architecture. An architecture developed by IBM, called SNA (Systems Networking Architecture) is a very common networking architecture in an enterprise.
Over the years, SNA architecture has evolved into several versions. The initial version of SNA networks was relatively static, and machine communication had to be pre-configured. This version is commonly known as the subarea SNA. The next version of an SNA network provided dynamic configuration of communication among different machines, and is known as APPN (Advanced Peer to Peer Networking). A further enhancement to APPN is known as HPR (High Performance Routing). HPR augments APPN by providing two functional enhancements, a flexible routing mode called ANR (Automatic Network Routing) and a transport protocol called RTP. While subarea SNA required that each of the links in the network be reliable, HPR does not have such a requirement. ANR links may be unreliable, and RTP provides end-to-end reliability by retransmitting packets.
Another architecture, based on the Internet Protocol, or IP, is commonly used in an enterprise. IP provides a connectionless network on top of which two transport protocols are commonly supported, TCP, which provides a reliable byte-stream transport of data end-to-end, and UDP which provides an unreliable datagram service end-to-end. Due to historical reasons, many enterprises have evolved to have a structure in which clusters of SNA networks are inter-connected with an intervening IP network. Communication in these networks usually tend to be from a client SNA network which supports different terminals, to a SNA network containing a mainframe server. The client networks are connected to the server networks by an intermediate IP network. To the SNA network, the entire IP network appears to be a set of SNA links that connect the different sites together. SNA protocols operate transparently over these virtual links.
One way for transport of SNA traffic over IP network is using a protocol called DLSW (Data Link Switching). This protocol terminates the SNA connection at the boundary of the SNA and the IP networks. And splices the two resulting SNA connections by means of a TCP connection. The splicing imposes a significant load on the computer implementing DLSW due to the need to maintain the connection state and protocol for both SNA and TCP sides of the connection. The DLSW scheme consists of encapsulating an SNA packet into a TCP packet for carrying across the IP network. It is well-suited for sub-area SNA, but performs poorly when it is used for HPR networks. The congestion control used by RTP and TCP, the transport protocol used by DLSW, do not operate well together.
An alternative way is to encapsulate SNA data over the Internet UDP protocol. UDP is a unreliable connection-less protocol and the encapsulation process can be done very efficiently. However, SNA requires that the intermediate links provide reliable connectivity. This problem is addressed by replacing the core SNA protocol in the mainframe by the HPR (High Performance Routing) protocol, which has been developed as an adjunct to APPN (Advanced Peer to Peer Networking), an enhanced form of SNA protocol.
HPR provides reliability by using a reliable transport protocol called RTP. RTP operates over unreliable links, and uses a congestion control policy called ARB (adaptive rate-based control). The ARB protocol sends out packets at a regular spacing, increasing the spacing when it detects that the network is congested, and decreasing the spacing when it senses that the network is lightly loaded.
ARB was designed to operate on links which are used exclusively for HPR traffic. HPR assumes that each link on the network is a constant-delay fixed-bandwidth point-to-point link, on which all the traffic originates from competing HPR sources. The characteristics of all links are determined when the link is brought up, and distributed to all other nodes in the HPR network. When part of the network is carried on an IP backbone, the entire IP network is made to appear like a single SNA link to the HPR/ARB algorithm. This is done by encapsulating HPR packets into UDP packets and tunnelling them through the IP network.
ARB fails to perform adequately in IP-based networks. ARB assumes that it is operating over a link with a fixed delay and bandwidth. In reality, this virtual link consists of several links with competing traffic from other protocols such as TCP sharing the link bandwidth. The characteristics of the link change over time. The performance of ARB is adversely affected when the link characteristics it assumes differ substantially from the instant link characteristics.
While the creation of logical links is used in various networking infrastructures, the performance of logical links is generally poor. The key to good performance of HPR networks is the performance of its transport protocol RTP. RTP bases its operation on the behaviour of the intermediate links along the path of a pair of communicating hosts, and assumes that all the links in the network are used exclusively by RTP sources. In an HPR over IP environment, the logical links over the IP network carry a variety of non-RTP traffic which alters the characteristics of the logical link significantly. In this invention, we describe a solution which would cause RTP performance to improve when operating over an IP backbone
A solution to the dynamic link configuration problem is to determine the right characteristics of the virtual link at different times and distributing them to the network. However, such a dynamic distribution can cause a significant overhead on the network. Furthermore, it will require changes to the HPR topology distribution protocol.
SUMMARY OF THE INVENTION
The current invention describes a scheme by which the dynamic characteristics of the virtual links provided to the HPR network are fed back to the RTP protocol, and used to improve the performance of RTP traffic across the IP backbone. The invention provides this feedback using the mechanisms provided by the HPR networking architecture, and thus can inter-operate with HPR networks that do not support this invention.
In the present invention the link characteristics are determined by programs running on both end of the IP network. These link characteristics are sent to the HPR end-node when an HPR connection is established. The HPR end-node obtains the information as appropriate fields in the Route-Setup Control Vector that is exchanged among different HPR nodes during the connection establishment phase.
During the initiation of a connection, the HPR connection establishment protocols send out route-setup messages hop by hop along the desired path of the connection. When the message is received by the node along the path, it is required to send its fixed bandwidth and delay in the route-setup control vector, a compone
Harper Kevin C.
Herzberg Louis P.
International Business Machines - Corporation
Vu Huy D.
LandOfFree
Dynamic parameter estimation for efficient transport of HPR... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic parameter estimation for efficient transport of HPR..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic parameter estimation for efficient transport of HPR... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2441037