LAN "gateways": does the char MIB apply?

courtenay_j_m@bt-web.bt.co.uk Fri, 01 January 1993 01:00 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06004; 31 Dec 92 20:00 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06000; 31 Dec 92 20:00 EST
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa26819; 31 Dec 92 20:00 EST
Received: by inet-gw-2.pa.dec.com; id AA23629; Thu, 31 Dec 92 17:00:09 -0800
Received: by nsl.pa.dec.com; id AA02404; Thu, 31 Dec 92 16:07:11 -0800
Received: by nsl.pa.dec.com; id AA02386; Thu, 31 Dec 92 16:07:09 -0800
Received: by inet-gw-1.pa.dec.com; id AA29021; Thu, 31 Dec 92 16:07:06 -0800
Message-Id: <9301010007.AA29021@inet-gw-1.pa.dec.com>
Received: from bt-web.bt.co.uk by zaphod.axion.bt.co.uk via DECnet inbound channel id <24147-0@zaphod.axion.bt.co.uk>; Fri, 1 Jan 1993 00:06:49 +0000
X-Vms-To: R11F::PA.DEC.COM::CHAR-MIB
To: char-mib@pa.dec.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: courtenay_j_m@bt-web.bt.co.uk
Subject: LAN "gateways": does the char MIB apply?
Date: Fri, 1 Jan 1993 00:06:49 +0000

From:	NAME: J Mark Courtenay      [DAT33 ]
	FUNC: DAT33                           
	TEL: 0473-645423                      <COURTENAY J M AT WEB AT WEBCS>
To:	CHAR-MIB@PA.DEC.COM@UNET


The recent discussion of Draft Standard status for the RFC 1316 char
MIB and people reporting implementations of same, has prompted me to
ask something which has been bothering me for ages.

The question is: does the char MIB apply to the virtual "character
ports" to be found (I believe) of LAN communications servers
("gateways") of various types?

By these I mean boxes which provide, effectively, the functionality
of 2 terminal servers back to back:

                           RS-232
                          character
                            ports
                              |
                  _______     v    ________
                 |       |________|        |
                 |       |________|        |
                 |       |________|        |
                 | TS1   |________|  TS2   |
                 |       |________|        |
                 |       |________|        |
                 |       |________|        |
                 |       |________|        |
                 |_______|        |________|
                    |                 |
    ____Network 1___|___             _|___Network 2__


I hope this configuration will be familiar to some readers at least.
It's not a desirable thing to do, but in my experience it is quite
common. For example, TS1 (Network 1) could be TCP/IP/Telnet based
and TS2 could be some proprietary protocol, eg. XNS, LAT; this site
still has a large presence of Sytek LocalNet 20 on broadband - the
only interfaces available to that network are RS-232 character
ports, so these things abound.

Another example could be that TS2 is a X.25/XXX (X.3, X.28, X.29)
PAD. Of course, ports would need to be configured differently
depending on whether they are "incoming" or "outgoing" ports. TS2
could even be a bank of modems.

Both of the terminal servers would, in an ideal world, support the
char MIB in the normal way.

What a number of vendors have done is provide this functionality
into a single box (a "gateway"). Eg. 3Com, Xyplex among others, I
believe. While there is potential to do lots of clever things (eg.
eliminate the command interpreter and provide seamless connection,
automatic "profile" selection, etc), it seems to me that there are
still virtual character ports which need to be managed by the char
MIB. These ports may only exist when there is an established
connection across both interfaces of the "gateway", and for every
such connection there are 2 character ports (connected
back-to-back).

Of course if the box is also performing some other "gateway"
function, such as a transport or mail gateway, the char mib will not
apply to these (non character-based) connections. Ditto if it is
also functioning as a router.

I would be interested to know whether anyone disagrees with this
view. Particularly, are the members of the working group who have
implemented the char mib for their terminal servers also looking to
implement it on their X.25/XXX based comms servers?

If there is general agreement that this model does apply, I think
there may be a need to take a fresh look at the char mib to ensure
that it manages this sort of virtual port satisfactorily.

I eagerly await responses from the working group.

Mark
--
J Mark Courtenay                    tel. +44 473 645423
B81 261 51                          fax. +44 473 642163
BT Labs, Martlesham Heath
Ipswich, UK IP5 7RE                 courtenay_j_m@bt-web.bt.co.uk