[bit.listserv.ibmtcp-l] SNA over IP?

C0298@UNIVSCVM.BITNET (Arthur Yeh) (02/09/90)

We have installed a PRONET-80 network supporting IP, DECNET, IPX, and
XNS.  Unfortunately, SNA and NETBIOS are not supported by Proteon.
We have a large administrative 3270 network and are searching for
strategies that will give people using Personal Communications/3270,
and other such packages, on a LAN good service.

Preferably, we would not assign IP addresses to every workstation solely
for tn3270 access nor do we wish to invest heavily in SNA gateway boxes.
I would like other people's ideas on alternatives especially if they
are currently available somewhere.  We have even been kicking around the idea
of 'tunnel' gateways to allow SNA transport via IP.

     Arthur C. Yeh
     Systems Programmer
     University of South Carolina
     803/777-4409  (C0298@UNIVSCVM)

DIXON@OHSTVMA.BITNET (Bob Dixon) (02/09/90)

Why use sna at all? Could you not run a good tcp/ip package on your IBM
mainframes and have people use tn3270 from their workstations?

                                 Bob Dixon
                                 Ohio State University

C0298@UNIVSCVM.BITNET (Arthur Yeh) (02/10/90)

My use of the term 'tunnel' gateway refers to the function of passing
data composed on one protocol stack and transporting it, or them, across
another.  This would allow us to, for instance, encapsulate all SNA
traffic on a LAN within IP packets, transport it across our IP backbone,
and then unencapsulate it for use by a T-R 3174 or T-R 37X5.  Reverse
traffic follows the same logic.  I wonder if such a thing exists and
how feasible it might be to develop the software.

In response to suggestions to use telnet or tn3270,  my concern is for the
functionality provided by native 3270 services(e.g. local copy printing and
multiple logical terminal support), the effort in maintaining a, therefore,
greatly enlarged IP network, and the learning curve imposed on staff and
administrators that, must now, learn something about TCP/IP to get their
jobs done.  Of course, this is still an alternative, albeit a somewhat
distasteful one.

     Arthur C. Yeh
     Systems Programmer
     University of South Carolina
     803/777-4409  (C0298@UNIVSCVM)

U0359@WVNVM.BITNET (Justice, James E.) (02/10/90)

>My use of the term 'tunnel' gateway refers to the function of passing
>data composed on one protocol stack and transporting it, or them, across
>another.  This would allow us to, for instance, encapsulate all SNA
>traffic on a LAN within IP packets, transport it across our IP backbone,
>and then unencapsulate it for use by a T-R 3174 or T-R 37X5.  Reverse
>traffic follows the same logic.  I wonder if such a thing exists and
>how feasible it might be to develop the software.

Vitalink had a box called a TransSDLC.  It didn't use IP, but it did
transport 3274 traffic to a 37X5 box.  We are using several of the boxes
on our Ethernet and they work well.  They are more efficient then 3274
direct connect because they don't pass the line poll.  They answer at the
box tied to the 37X5.  They have been replaced with a new box that I
don't know the details of but it can do similiar things, perhaps more.

In our case we run Vitalink boxes to tie Ethernets all over West Virginia
together into one WAN.  The TranSDLC boxes set on the Ethernet at remote
locations and a 3274 or 3274's are plugged into them.  On our side we
TransSDLC boxes that run in reverse into our 3745.  Each TransSDLC
supported 4 lines (coaxes).  Each line (coax) going in or coming out
could be multi-dropped.  If you want all the details about the IBM side
of the box talk to Allen Daughtery <U0E60@WVNVM>.  For Ethernet side
and Vitalink information, I refer you to George Cook <CC00700@WVNVMS>.

SNSTR@TTUVM1.BITNET (Steve Strickland) (02/12/90)

>>My use of the term 'tunnel' gateway refers to the function of passing
>>data composed on one protocol stack and transporting it, or them, across
>>another.  This would allow us to, for instance, encapsulate all SNA
>>traffic on a LAN within IP packets, transport it across our IP backbone,
>>and then unencapsulate it for use by a T-R 3174 or T-R 37X5.  Reverse
>>traffic follows the same logic.  I wonder if such a thing exists and
>>how feasible it might be to develop the software.
>
>Vitalink had a box called a TransSDLC.  It didn't use IP, but it did
>transport 3274 traffic to a 37X5 box.

We've been looking for a box like this... I called VitaLink and
discovered that they discontinued this box about a year ago.  Are
there any similar products available??
strick

U0359@WVNVM.BITNET (Justice, James E.) (02/13/90)

>>>My use of the term 'tunnel' gateway refers to the function of passing
>>>data composed on one protocol stack and transporting it, or them, across
>>>another.  This would allow us to, for instance, encapsulate all SNA
>>>traffic on a LAN within IP packets, transport it across our IP backbone,
>>>and then unencapsulate it for use by a T-R 3174 or T-R 37X5.  Reverse
>>>traffic follows the same logic.  I wonder if such a thing exists and
>>>how feasible it might be to develop the software.
>>
>>Vitalink had a box called a TransSDLC.  It didn't use IP, but it did
>>transport 3274 traffic to a 37X5 box.

>We've been looking for a box like this... I called VitaLink and
>discovered that they discontinued this box about a year ago.  Are
>there any similar products available??
>strick

I know of nothing else that does what this box does.  Vitalink has a
new box that may replace it.  I am not sure and can't remember what they
called it.  The unforturate thing is that the box is just the standard
Vitalink box running different software.  At one point Vitalink told us
that since we were a customer who had bought TransSDLC before the product
was dropped, we could buy their standard box and run the TransSDLC soft-
ware on it.