Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing – Session/connection parameter setting
Reexamination Certificate
1998-10-30
2001-02-06
Maung, Zarni (Department: 2758)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
Session/connection parameter setting
C709S219000, C709S225000, C709S238000, C709S241000, C709S242000
Reexamination Certificate
active
06185618
ABSTRACT:
TECHNICAL FIELD
The invention relates to the fields of networking and route calculation, and specifically to the problem of allowing support of dependent logical units (DLU) in a SNA (System Network Architecture) Advanced-Peer-to-Peer Architecture (APPN) environment to be located downstream of a branch extender and still have the network function properly as to locating of the DLUs, route calculation to and communication with the DLUs.
BACKGROUND OF THE INVENTION
IBM's Advanced Peer-to-Peer Architecture (APPN) provides networking between nodes of a network on a peer-to-peer basis. That is, all nodes are able to communicate amongst themselves on an equal basis, without regard to any hierarchical network structure. An APPN network contains network nodes (NNs) and end nodes (Ens). A network node contains all of the functionality to initiate control point sessions with other network nodes, to locate resources within the network and to calculate routes to other nodes. Control point (CP) sessions are sessions over which control messages are passed between so-called network control points. Control points (CP) characterize the functionality in network nodes that provide network services, such as route calculation. Among other functions, network nodes serve end nodes for locating resources and calculating routes, among other things. End nodes are nodes of lesser capability and typically include such things as user workstations, printers, and the like.
Users of IBM's SNA architecture and APPN architecture have a large investment in a type of end node called a dependent logical unit (DLU). A DLU is an end node device that, unlike an independent logical unit, does not have the ability to initiate sessions and to manage log on requests to server nodes. Instead, DLUs rely on other nodes to provide these services on its behalf via the CP capability. Because of their limited capability, DLUs are cheaper than end nodes that have full capability to initiate and manage sessions to other nodes. DLUs are supported in APPN by a mechanism called a dependent LU requester (DLUR) and dependent LU server (DLUS). Essentially, a session pipe is established between a CP DLUS node (a network node) and a DLUR node that owns (serves) the DLUs. Once a communication pipe called a CP-SVR pipe has been activated between the DLUR and DLUS, DLU message flows are encapsulated over sessions contained within the CP-SVR pipe between the DLUR and the DLUS. Numerous IBM publications describe APPn and DLUS/DLUR operation in detail. Many of these publications are available at IBM's Redbook web site http://www.redbooks.ibm.com. At this site, see for example the Redbook SG24-4656-01, May 29, 1998, Subarea to APPN Migration: VTAM and APPN Implementation.
The APPN architecture also allows users to configure an APPN network as an upstream component connected by a wide area network (WAN) to downstream components. The downstream components are typically local area networks (LANs). The mechanism that allows this configuration is called a branch extender (BEX) node. The nodes downstream of the BEX are usually end nodes and are considered to be within the domain, or branch, of the BEX. To these domain nodes, the BEX node looks exactly like an APPN network node that serves the branch nodes. To upstream nodes, the BEX node looks exactly like an APPN end node. Thus, a BEX node has an upstream node that acts to it as a serving network node.
More detailed information regarding APPN branch extenders is also available at web site http://www.redbooks.ibm.com. See, for example, the Redpiece article BRAN-CHXX, Jun. 1, 1997, APPN Branch Extender (BX), and the Redbook article SG24-5232-00, Oct. 10, 1998, IBM eNetwork Communications Server for Windows NT Version 6.0 Enhancements, both available at this web site.
While a BEX node knows the topology of its branch, it knows nothing of the upstream network topology. When a BEX node can't resolve a request for network services locally, it refers the request to its network node. This can be thought of as default routing. As far as upstream nodes are concerned, everything in the branch of the BEX node resides in the BEX node. The BEX node, when necessary, provides pass-through to its branch nodes for locate requests, session binds and unbinds, and the like. A BEX node registers all branch resources with its serving network node, including those that reside on the BEX node itself as well as those that reside on served end nodes. When registering the branch resources, the BEX node indicates that it is the EN control point (CP) for all resources it registers, even when those resources actually reside on a different end node. When sending or responding to directory searches, the BEX node modifies the directory search so that it includes the BEX nodes trunk vectors prior to sending the directory search into the WAN.
A BEX node provides information to the upstream network consistent with its end node appearance in that network. For directory services purposes, a BEX appears to own all of its branch resources. For route selection purposes, the BEX appears to be the origin or destination of all sessions involving logical units (LUs) in the branch of the BEX. For session routing, the BEX modifies bind messages destined for an end node of the BEX branch before the branch node ever sees it, by inserting the missing hop between the BEX and the branch node.
Branch extenders are very useful, in ways not important for this discussion, to provide network users with a flexible and inexpensive way to connect LANs and WANs in an APPN environment. DLU support is also very important to network users. It is also important to users to combine the advantages of BEXs and DLUS/DLUR in a single network. However, this combination introduces a major obstacle to network users. In the prior art, the DLUR support for DLUs must reside in a BEX node. Because a BEX appears as an end node to the upstream network, it is required to provide the DLUR capability for all of its branch nodes. The result is that only the BEX that is closest to the upstream WAN may support DLUR. On the other hand, the advantages of DLUS/DLUR are optimized when the DLUR function is located as close to a supported DLU as possible. In many cases, this is downstream of a BEX. Customers that presently have the DLUR located near the DLUs and who wish to install an upstream BEX to obtain other advantages are required to change their network configuration to relocate the DLUR support to the BEX.
A number of other problems also exist in locating DLUR support downstream of a BEX. A DLUS ordinarily calculates routes to a DLUR during operations relating to DLU support. A DLUR ordinarily registers with a DLUS its trunk group (TG) vector information necessary to calculate the routes to its DLUs. TG vector information contains the link addresses for all DLUs connected to a DLUR. However, a BEX provides isolation between an upstream DLUS node and the branch nodes of the BEX. Because of this, the DLUS node cannot calculate routes to the branch end nodes of the BEX. This means that a DLUS cannot calculate routes to a DLUR that resides downstream of a BEX. Another problem occurs because all branch nodes of a BEX are considered by a BEX to reside on the BEX. However, in a DLUS/DLUR environment, a DLUR registers with the DLUS as the owner of DLUs. In response to a resource Locate search request in a network containing both a BEX and DLUS/DLUR support, then both the BEX and the DLUR may appear in different ways to the Locate request as the owner of the resource that is being located. This, of course, can cause major malfunction of the network.
SUMMARY OF THE INVENTION
The invention resides in a method and apparatus that allows the DLUR function to reside in an end node served by a branch extender node in an APPN network. Two problems are solved by the invention that allows the DLUR support to be located downstream of a BEX. First, in an APPN network, when the DLUS and the DLUR reside in the same APPN network (a network in which all network nodes share topology in
Herndon Jerry W.
International Business Machines Corp.
Maung Zarni
Najjar Saleh
LandOfFree
Method and apparatus for supporting dependent logical units... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for supporting dependent logical units..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for supporting dependent logical units... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2572910