Conference netcad::hub_mgnt

1355.0. "FDDI ring map request from CERN" by NPSS::MDLYONS (Michael D. Lyons - Young enough and dumb enough) Fri Aug 26 1994 17:42

From:	US1RMC::"[email protected]" "GIGAswitch Notes Daemon - entry by [email protected]" 15-AUG-1994 09:42:14.86
To:	<cern::jrs>
CC:	
Subj:	Making ringmaps without ELMS

         <<< AXPVMS::SYS$SYSDEVICE:[NOTES$LIBRARY]GIGASWITCH.NOTE;1 >>>
                     -< CERN GIGAswitch Notes Conference >-
================================================================================
Note 118.0                Making ringmaps without ELMS                No replies
AXPVMS::GIGASWITCH                                   39 lines  15-AUG-1994 15:23
--------------------------------------------------------------------------------
Date Of Receipt: 	15-AUG-1994 15:06:55.77
From: 	DXMINT::"[email protected]"
To: 	axpvms::GIGAswitch
CC: 	
Subj: 	Making ringmaps without ELMS

With the advent of the GIGAswitch and the demise of ELMS to make
ringmaps, we need to have other means to produce maps of the
rings connected to the GIGAswitch and/or behind IP routers.

Although it is true that the fddimib gives values for
"fddimibMACUpstreamNbr" and "fddimibMACDownstreamNbr", many
systems on FDDI have not implemented these and will probably
never have it.

The only solution to this problem seems to be a "proxy agent" that
is addressed with SNMP and that collects the relevant information
via SMT.

So our question is if you have envisaged a solution to this problem
Moreover, a solution implemented in the GIGAswitch would be really
good (leaving the problem to be solved for a ring behind a router).

I am not aware of a "standard" solution for this, although I know
at least one manufacturer who has got it (proprietary solution).

Your advice, ideas and plans will be greatly appreciated.

================== RFC 822 Headers ==================
Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA14321; Mon, 15 Aug 1994 15:07:25 +0200
Message-Id: <[email protected]>
Date: Mon, 15 Aug 1994 15:07:24 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 916       


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from inet-gw-3.pa.dec.com by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA05046; Mon, 15 Aug 94 09:41:34 -040
% Received: from dxmint.cern.ch by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26528; Mon, 15 Aug 94 06:25:53 -070
% Received: from AXPVMS.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17868; Mon, 15 Aug 1994 15:24:23 +020
% Date: Mon, 15 Aug 1994 15:24:23 +0200
% Message-Id: <[email protected]>
% From: [email protected] (GIGAswitch Notes Daemon - entry by [email protected])
% X-Vms-To: DXMINT::[email protected],DXMINT::[email protected],DXMINT::[email protected],DXMINT::[email protected],DXMINT::[email protected],DXMINT::jmj@dxcoms
% Subject: Making ringmaps without ELMS
% X-Mail11-Ostype: VAX/VMS
% Apparently-To: <[email protected]>
% Apparently-To: <npss::mdlyons>
% Apparently-To: <npss::renda>
% Apparently-To: <school::gstest>
% Apparently-To: <cern::bothner>
% Apparently-To: <cern::jrs>

Ring maps (both FDDI and Token Ring) are planned for HUBwatch V4.0.

Tom Hood
HUBwatch

Yes, we've recognized the problem and have begun implementing a
solution.

An SMT (FDDI Station Management) gateway is planed for the 
DECconcentrator900MX.  The gateway works like the "proxy agent" 
you describe.  The gateway can be easily ported to the DECbridge900 
series products as well, though that activity is not scheduled.  
No such activity is scheduled for the GigaSwitch either.

>I am not aware of a "standard" solution for this, although I know
>at least one manufacturer who has got it (proprietary solution).

I'm not aware of a standard solution either.  I'm interested in any
details you have on the other manufacturer's solution.  Please contact
me if you have any details.

						-Shawn

        How would this be implemented in HUBwatch without the proxy SMT
    agent?
    
    ...Thanks
    
    MDL

I'm not sure I understand the question.  If you're questioning the difference
between an "SMT Gateway" and an "SMT/SNMP Proxy Agent" - there's very little
difference.

A HUBwatch application like FDDI ring map is invoked.  HUBwatch packages 
up an SMT frame, with the appropriate padding for source informations.  It 
then issues a set to the device, setting an object like, say, "smtGwRequest-
Frame".  The device takes the data (the SMT request frame), overwrites the 
source information with its source address, etc., and sends the frame.  
The device puts the response SMT frame(s) into "smtGwRespFrame".  HUBwatch 
reads "smtGwRespFrame", interprets the results, updates the map, and repeats 
until the ring configuration is known.  (Of course, other objects are involved
to provide synchronization, make the solution more generic, etc.)

							-Shawn

Sorry for the confusion.  The FDDI ring map that we hope will be in HUBwatch
V4.0 will require a DEChub-based ring.  GIGAswitch-based rings (without a
DEChub connection) will not be supported

Tom Hood

     Re: .5  Thanks, that's what I was asking...

    Note that you will only need one DEChub FDDI module that supports
    the SNMP-SMT gateway.   The rest of the ring can consist of any vendors
    FDDI devices as long as the conform to the ANSI standard.
    
    Regards,
    
    Bob