Browse Prior Art Database

Self-Configuring Branch Backup

IP.com Disclosure Number: IPCOM000123179D
Original Publication Date: 1998-Jun-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 133K

Publishing Venue

IBM

Related People

Dudley, JG: AUTHOR

Abstract

Branch network nodes (BrNNs) are Advanced-Peer-to-Peer-Networking* (APPN*) network nodes with additional functions defined in (1). The APPN architecture is defined in (2). Disclosed is a method that allows two branch network nodes, if located on the same local-area network (LAN), to each become the network node server (NNS) for the other BrNN when the other BrNN loses its NNS. A BrNN may lose its NNS because either the NNS or the uplink to the NNS fails.

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

Self-Configuring Branch Backup

   Branch network nodes (BrNNs) are
Advanced-Peer-to-Peer-Networking* (APPN*) network nodes with
additional functions defined in (1).  The APPN architecture is
defined in (2).  Disclosed is a method that allows two branch
network nodes, if located on the same local-area network (LAN), to
each become the network node server (NNS) for the other BrNN when the
other BrNN loses its NNS.  A BrNN may lose its NNS because either the
NNS or the uplink to the NNS fails.

   When two branch network nodes are located in the same
branch and one or more defined links has been activated between
them, the BrNNs are either in a cascaded or parallel configuration
depending on how the links were configured (see the descriptions of
the cascaded and parallel configurations in section 4.2 of (1).)  Two
cascaded configurations are possible as either of the BrNNs may be in
the higher position.

   The Exchange Identification (XID) logic does not allow a
BrNN to have both an active uplink and an active downlink with the
same node; therefore, a BrNN cannot simultaneously be in both the
lower and higher cascaded positions with respect to another BrNN.
However, when two BrNNs are located on the same local-area network
(LAN), it is desirable that each of the BrNNs assume the higher
cascaded position at different times; this will enable each of the
BrNNs to become the network node server for the other BrNN when the
other BrNN loses its NNS.

   For each of a pair of BrNNs (BrNNa and BrNNb as shown in
the figure) to assume the higher position as needed requires the
definition of two links using predefined transmission group (TG)
numbers (e.g., TG numbers 1 and 2) between BrNNa and BrNNb.  BrNNa
defines one of the two links as an uplink, and BrNNb defines the
other link as an uplink.  It is not necessary that either of the
links be defined by both BrNNs; the logic for handling unconfigured
TGs will bring the link up as a downlink at the adjacent node.  When
one of the BrNNs loses its NNS, it activates its uplink to the other
BrNN (thus assuming the lower position in a cascaded relationship)
and activates CP-CP sessions over that link.  Therefore, the links
should be defined as supporting CP-CP sessions.

   The two links cannot be active simultaneously because an
incoming link activation is rejected by the XID logic if the other
link is active or pending active; thus, they must be
auto-activatable.  However, an incoming link activation should be
mapped based on the TG number to the correct defined link station
(or handled as an unconfigured TG if there is no matching defined
link station) and should not be rejected based on the local
definition for the other link.  If the higher BrNN loses its NNS, it
cannot activate an uplink to the lower BrNN; it should, however,
periodically check for the deactivation of the downlink to the lower
BrNN at which time activation of the uplink will succeed.  (The
higher BrNN can check for the p...