Browse Prior Art Database

Server Redundancy Mechanisms in Asynchronous Transfer Mode Networks with Distributed Classical Internet Protocol Servers

IP.com Disclosure Number: IPCOM000123352D
Original Publication Date: 1998-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 231K

Publishing Venue

IBM

Related People

Alexander, C: AUTHOR [+4]

Abstract

Disclosed is a system which enhances the redundancy characteristics of the system described in a disclosure entitled "Redundancy Mechanisms for Classical Internet Protocol Over Asynchronous Transfer Mode Networks" by IBM. Distributed servers can be used together with the mentioned redundancy mechanisms in order to provide backup and redundancy for all types of Classical IP clients.

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

Server Redundancy Mechanisms in Asynchronous Transfer Mode Networks
with Distributed Classical Internet Protocol Servers

      Disclosed is a system which enhances the redundancy
characteristics of the system described in a disclosure entitled
"Redundancy Mechanisms for Classical Internet Protocol Over
Asynchronous Transfer Mode Networks"  by IBM.  Distributed servers
can be used together with the mentioned redundancy mechanisms in
order to provide backup and redundancy for all types of Classical IP
clients.

   Classical IP is specified in Request for Comments (RFC)
1577.  This RFC does not specify mechanisms for providing a backup
Asynchronous Transfer Mode Address Resolution Protocol (ATMARP)
Server.  The role of the ATMARP Server is to provide IP-to-ATM
address mappings to requesting ATMARP Clients.  If the ATMARP Server
fails, ATMARP Clients will no longer be able to resolve IP addresses
to ATM addresses, and therefore will not be able to establish new
Virtual Channel Connections (VCCs).  Furthermore, ATMARP Clients will
not be able to refresh existing mappings via the ATMARP Server.
Thus, failure of the ATMARP Server can cripple communication
capabilities on the associated Logical IP Subnet (LIS).

   The single point of failure represented by the ATMARP
Server is a significant problem because it impacts the ability to
deploy Classical IP equipment in networks carrying mission-critical
traffic.

   Consequently, a solution providing ATMARP Server redundancy
was developed and documented in a previous invention disclosure
"Redundancy Mechanisms  for Classical Internet Protocol Over
Asynchronous Transfer Mode Networks."  This solution is sufficient
for networks where a single ATMARP Server is capable of handling all
the requests for the Logical IP Subnet (LIS).  However, it is not
sufficient in networks where the scalability benefits of a
distributed ATMARP Server are required.

      The Internet Engineering Task Force (IETF) is currently
in the final stages of standardizing two specifications supporting
distributed ATMARP Servers.  The specifications are the Server Cache
Synchronization Protocol (SCSP), as described in RFC 2334, and RFC
2225, which is the follow-on to RFC 1577.  SCSP specifies the
mechanisms used to synchronize multiple ATMARP Servers that are
servicing the same LIS, while RFC 2225 defines new ATMARP Client
behavior.  One significant facet of 2225 is that ATMARP Clients
maintain a list of ATMARP Server ATM addresses for redundancy
purposes.  This allows the ATMARP Client to locate a new ATMARP
Server if its current ATMARP Server should fail.

   While implementations of these new specifications will
undoubtedly prove to be very useful, a migration problem exists.  The
problem is that all of the ATMARP Clients on a given LIS must be
upgraded to RFC 2225 simultaneously, at the time when the ATMARP
Servers are distributed with SCSP, in order to preserve the
redundancy benefits.  This invention di...