Browse Prior Art Database

Load Balancing for Multiple Interfaces for Transmission Control Protocol/ Internet Protocol for VM/MVS

IP.com Disclosure Number: IPCOM000116340D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 141K

Publishing Venue

IBM

Related People

Barton, DM: AUTHOR

Abstract

Since Transmission Control Protocol/Internet Protocol (TCP/IP) applications do not know which interface their data arrives on, it is impossible to guarantee that traffic arriving on a given interface will be sent back out on the same interface. As a result, the problems of inbound load balancing and outbound load balancing can be treated as two separate problems, each with distinct problems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 40% of the total text.

Load Balancing for Multiple Interfaces for Transmission Control Protocol/
Internet Protocol for VM/MVS

      Since Transmission Control Protocol/Internet Protocol (TCP/IP)
applications do not know which interface their data arrives on, it is
impossible to guarantee that traffic arriving on a given interface
will be sent back out on the same interface.  As a result, the
problems of inbound load balancing and outbound load balancing can be
treated as two separate problems, each with distinct problems.

      In today's VM and MVS implementations of TCP/IP, there is no
way to assign the same IP address to multiple adapters and have
inbound traffic automatically load balanced between them.  The same
IP address can be assigned to multiple adapters, and traffic can be
received on any of the adapters, but when a remote host ARPs the
VM/MVS host only one of the interface's MAC addresses will ever be
returned.  A host can hard code the MAC address of one of the other
adapters, but if that adapter failed they would be out of luck.
Also, configuring all the remote hosts could be a monumental task.

      Another option is to give each of the adapters a different IP
address on the same subnet, such as x.x.x.1 and x.x.x.2.  Each
interface would then respond to ARP requests independently.  However,
it would be up to the remote hosts to pick which interface to connect
to perform the load balancing.  This can be performed by using two
different host names for the two interfaces, having the remote hosts
use the IP address instead of a host name, or somehow rigging the
name server to return the IP addresses in a different order for
different hosts.  The disadvantages are relying on the remote host to
choose the correct interface, and if the interface fails the remote
hosts would not automatically switch to another interface.

      The solution that is needed is the ability to give multiple
interfaces with unique MAC addresses the same IP address.  Remote
hosts would always use the same IP address, but not know (or care)
which interface they were using.  Two problems must be overcome in
order for this to occur.  When the remote host ARPs the IP address of
the host, the server must select the MAC address of one of the
available interfaces and return it to the client.  A number of
schemes could be used to select the interface, from simple round
robin to monitoring traffic loads and selecting the least used
interface.  The method of selecting the interface is not important.

      The second problem is to overcome the problem of an interface
failing.  If any one interface fails, all the remote hosts that have
that MAC address in their ARP cache will lose connectivity with the
host.  The problem is simple, the ARP caches on the remote hosts must
be updated.  It is assumed that anybody that has an ARP cache entry
for the VM/MVS host is also in the VM/MVS host ARP cache.  The ARP
cache timeout on the host would need to be set to...