2 Feb 1995

NETID (Organizing Large Peer Networks)

Summary: If a subarea SNA network spans the entire country, it is centrally controlled and administered on the mainframe. Those who configure the VTAM parameter dataset can insure that every LUNAME is unique. However, a nationwide network of AS/400, RS/6000, and OS/2 machines will be largely configured by end users. This makes a global directory almost impossible to administer. More importantly, the APPN design locates servers by broadcasting a query to all Network Nodes. This becomes impossible in a network that spans the country. The solution is to break the network up into geographical areas. Each area administers its own name space. Requests to servers in another area go through a gateway machine.

In the mainframe-managed subarea network, every terminal, printer, or application is assigned a unique 8 character LUNAME. In the APPN peer network, programs are identified by an 8 character Network ID (NETID) and an 8 character LUNAME. The LUNAME need only be unique within the cluster of machines that share the same NETID.

A NETID is created from any natural cluster of machines. They could be in the same area (CHICAGO), or in the same department (ACCOUNT). Alternately, you split up into NETIDs when there is a significant delay in communication between groups of nodes or where there would be difficulty administering a common name space. Different NETIDs are connected by links established through gateway machines.

In this example, two networks are created named MTV and PBS. The gateway between them is a link between MVT.BEAVIS and PBS.LEHRER. The machines in the MTV network do not know the names of any machines in the PBS network. They are configured, however, to send all PBS.* traffic to BEAVIS so that it can be forwarded across the link.

At least, that is how the architecture says that things are supposed to work. The AS/400 computers play this game somewhat loosely. They allow a single machine to appear to be part of both networks. This allows the gateway machine to use the fully APPN distributed directory protocol to learn LUNAMEs in both networks and to process traffic more intelligently. However, this is simply a "hack" for AS/400 machines and is not part of the architecture.

A client program on MVT.BUTTHEAD needs to request information from a server on PBS.BUCKLEY. First, it must establish a session between the two machines. It builds a BIND request with the destination "PBS.BUCKLEY" in the header. Now BUTTHEAD does not know where BUCKLEY is, but it has been configured to send all PBS.* request to BEAVIS. BEAVIS receives the BIND. It also does not know about BUCKLEY, but simply forwards the BIND through the link to LEHRER. When the BIND for PBS.BUCKELY arrives at PBS.LEHRER, this is the first time that the NETID of the destination has matched the NETID of the node processing the message. LEHRER responds by generating an APPN query to search the PBS network to find the BUCKLEY name. It then forwards the BIND to the proper node.

As with all APPN requests, as the BIND flows through the network it leaves behind a trail of breadcrumbs. At each hop, the BIND message has a unique numerical ID. Each machine through which it passes (BEAVIS, LEHRER) adds an entry to a table, remembering this ID and associating it with routing. If the BIND is accepted, then subsequent data will flow through the path for which the BIND acted as trailblazer. If the BIND is rejected, or when the session terminates, then these entries are released as the session is torn down. The APPN routing of subsequent messages on a session established between NETID's is no different from the routing within a network.

The mainframe, however, poses a special problem. VTAM Version 3 does not provide a NETID field to mainframe application programs, and the subarea network is very limited in its APPN participation. The entire mainframe subarea network is generally given a single NETID, and isolated workstations that do not participate in serious APPN activity generally join the mainframe network by configuring the same name as their own NETID when they configure their own node. VTAM Version 4, however, provides more complete APPN support. Over time, organizations may prefer to move all workstations to their own NETID separate from that configured for mainframe applications.

Return to SNA Crossroad

Copyright 1995 PCLT -- NETID (Organizing Large Peer Networks) -- H. Gilbert