Subject: Re: TCP Support for LU6.2 Applications

From: Ronnie Sarkar <[email-masked]>
Date: Wed, 17 Dec 1997 18:57:09 -0500

Derek,
 Actually there are two cases.

Case 1:
 There is a single physical network (say, a LAN), where some nodes are running
APPC/APPN only, others are running both APPC and TCP/IP (and TCP62). In that
case, all we need is some configuration in the "dual stack" node which tells it
whether LU6.2 connection requests should be tried over both the APPC stack as
well as the TCP62 code, and the order in which the connections should be tried.
IBM implementations of TCP62 have this feature, and this avoids getting a third
node involved.

Case 2:
 There are two logically (and physically) different networks, one running
TCP/IP and another running APPN. In that case, we need a node in the middle,
that the RFC refers to as a TCP62 GATEWAY.

 TCP62
TCP62                                                          node
 access --------------------------------- gateway
--------------------------------------------- running
 node           TCP/IP n/w                 (NN)                    APPN
n/w                       LU6.2 only

In the above configuration, the TCP62 gateway communicates with the access node
using TCP62 protocols on the TCP/IP network and uses APPN to communicate with
the node running LU6.2 only, allowing applications on the TCP62 access node to
communicate with applications on the native node.

A BIND from the TCP62 access node to the native node, which flows on the
MPTN_CONNECT, is picked up by the gateway as a LEN BIND, and it performs APPN
LOCATE protocols to find the partner in the APPN network. The MPTN_CONNECT is
sent to the gateway because, as you mentioned, every LU name in the APPN
network is mapped to the IP address of the gateway. Wildcard entries in the
DNS, based on the netid of the LU name, can be used to reduce the number of DNS
entries.

Similarly, if the gateway receives an APPN LOCATE from the APPN network for an
LU on the TCP/IP network, in addition to forwarding the LOCATE on APPN, it also
searches the TCP/IP network by querying the DNS, and if it finds a match, it
responds to the APPN LOCATE. The subsequent BIND from the native node is
forwarded to the TCP62 access node using an MPTN_CONNECT.

Implementations of these gateway nodes exist on a number of platforms.

Soumitra (Ronnie) Sarkar
IBM Corporation
Dept. J28A/Bldg. 502
4205 S. Miami Blvd.
Research Triangle Park, NC 27709

Telephone: (919) 254-6561, Tie Line: 444-6461
Fax: (919) 254-4029, Tie Line: 444-4029
email: [email-masked], [email-masked]

------------------------------- Referenced Note ---------------------------
Received: from list.nih.gov by VNET.IBM.COM (IBM VM SMTP V2R4) with TCP;
   Wed, 17 Dec 97 00:19:26 EST
Received: from list.nih.gov (terrific.net.nih.gov *ó165.112.130.6*y)
*by list.nih.gov (8.8.5/8.8.5) with ESMTP id AAA24240;
*Wed, 17 Dec 1997 00:11:01 -0500 (EST)
From: "Derek W. Bolton" <[email-masked]>
Subject: Re: TCP Support for LU6.2 Applications
To: [email-masked] (James Carmichael)
Date: Wed, 17 Dec 1997 16:09:48 +1100 (EST)
Cc: [email-masked]
Sender: [email-masked]

James,

On a quick read of your TCP62 proposal, there seems to be
an omission which would be a barrier to acceptance by
many customers.  They will need a migration path, or
perhaps even a long-term mix of straight APPN and TCP62.

I think it's easy to provide.  The DNS could be set up to
map the LU name to an IP addrehout actually using
the 8-character LU name piece.  The mapping is to the IP
address of an NN server that supports TCP62.  It could be
any NN server in the subnet.

When the TCP62 end point sends the Bind to the NN server,
the NN server extracts the target LU name from the Bind
and generates Locate etc., as today for a LEN.

That's why I said there 'seems' to be an omission.  Your
architecture covers this important case - it just doesn't say so.

Regards,
  Derek

Receive