Browse Prior Art Database

Node Naming in AIX Distributed Services

IP.com Disclosure Number: IPCOM000034201D
Original Publication Date: 1989-Jan-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 3 page(s) / 15K

Publishing Venue

IBM

Related People

Johnson, DW: AUTHOR [+3]

Abstract

This article describes a way of handling node names in a distributed network. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. A method to identify the nodes on a network is described. The method must satisfy several requirements, among which are the following: - The underlying transport mechanism for Distributed Services is SNA LU_6.2. SNA identifies a network node by its LU_NAME (Logical Unit Name); Distributed Services must be able to generate the LU_NAME for each node it wishes to talk to.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 3

Node Naming in AIX Distributed Services

This article describes a way of handling node names in a distributed network. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. A method to identify the nodes on a network is described. The method must satisfy several requirements, among which are the following: - The underlying transport mechanism for Distributed

Services is SNA LU_6.2. SNA identifies a network

node by its LU_NAME (Logical Unit Name);

Distributed Services must be able to generate the

LU_NAME for each node it wishes to talk to.

An LU_NAME is an eight-character string (may be

chosen from the alphabetic characters, the digits,

and a few of the spec

ial characters) whose first character is a non-digit; the

string is case-insensitive.

- Since handling strings is inefficient in both

space and performance, Distributed Services uses a

32-bit integer (the NID or node id) to identify a

node within the kernel. There must be a way to

associate a NID with an LU_NAME. SNA, optionally,

uses a password exchange protocol to verify that a

remote node is in fact the LU_NAME that the caller

believes it is. SNA knows only about the LU_NAME;

it does not know about a NID. It is, therefore,

important that the method used to associate an

"external" LU_NAME with an "internal" NID be

secure and not prone to error.

_ There must be a way to insure that LU_NAMEs are

unique in the network. Selecting a unique LU_NAME

for a new node must not be difficult, and there

must be a strategy for managing potential name

collisions when two existing networks are merged.

_ Users must be able to refer to remote nodes by a

name which is not overly constrained in its syntax

or in its requirements of uniqueness. The base machine already contains a method for uniquely identifying a particular RT PC node; the ROS on the base planer contains a "machine type" which can be interrogated by a VRM SVC. At the AIX level this machine type is returned by uname(2) as the stsname.machine, and by uname(1), as a hex string, via the -m flag. The machine type is a 32- bit quantity, the high 8 bits identify the kind of machine (floor standing, desk top, and others in the future); the remaining 24 bits are unique for a particular set of ROS modules. Additionally, unamex(2) returns a long integer, called the nid, in the structure xutsname. Distributed Services uses the unique machine type to solve its naming problems. _ When, within the kernel, distributed services

calls SNA asking for a connection to a remote

node, it passes to SNA the name of a connection

1

Page 2 of 3

profile. This connection profile contains, among

other things, the LU_NAME of the remote node.

For distributed services connections, the hex form

of the ROS machine type value is used as the name

of the connection profile.

- The SNA LU_NAME, which is contained in the

connection profile, is constructed from the

machine type.

It woul...