[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

302.0. "customer questions" by CIVAGE::FEARNOW (Bobbi Fearnow @WNP 427-5683) Thu Jul 18 1991 19:18

I'm trying to answer some FDDI questions from NIH and am stuck.  Could anyone
out there help?

1.  NIH would like to dual home DAS workstations to two concentrators.  They
    want to use our workstations (for high availability data).  Will we ever
    support a DAS controller for this situation?  Is there some technical 
    reason why this is not a good idea?

2.  NIH doesn't have any VMS systems (therefore no DECelms).  They really
    want to be able to manage the concentrators with SET SNMP commands (which
    won't be available till the end of the year?).  Until then the only other 
    choice for management is DECmcc MSU V1.1, right?  Also, is it
    possible to manually shutdown a concentrator port (sorry I've never seen
    one)?

3.  For some reason they want a roving MAC.  I know our concentrator doesn't
    support this.  They want to know if we don't have a roving MAC what 
    happens when a station is inserted or removed (what frames are sent around
    the ring)?

4.  When SET SNMP is available which MIB extensions will it support?
    Are there special fddi MIB extensions?  Will we support them?  Where
    can I get a list of those parameters?  Is there an RFC?

5.  Are there any plans to develop a concentrator with more than 8 ports,
    say something around 30?


6.  SMF is for the backbone and between concentrators, right?  It won't be
    employed from controller to concentrator, right?

Thanks for your time (and patience)!
Bobbi
T.RTitleUserPersonal
Name
DateLines
302.1Some answers, not all...KYOA::KOCHIt never hurts to ask...Thu Jul 18 1991 20:4850
>1.  NIH would like to dual home DAS workstations to two concentrators.  They
>    want to use our workstations (for high availability data).  Will we ever
>    support a DAS controller for this situation?  Is there some technical 
>    reason why this is not a good idea?

    You don't want to do this. Having workstations as DAS connects
    actually reduces availability. They are part of the ring and thus
    if powered off, the ring is broken. To get around this, you then have
    to put in optical bypass units, reducing the size of the ring. You
    don't want people able to affect the ring.
    
>2.  NIH doesn't have any VMS systems (therefore no DECelms).  They really
>    want to be able to manage the concentrators with SET SNMP commands (which
>    won't be available till the end of the year?).  Until then the only other 
>    choice for management is DECmcc MSU V1.1, right?  Also, is it
>    possible to manually shutdown a concentrator port (sorry I've never seen
>    one)?

    This is a good question. However, MSU is the Management Station for
    Ultrix. In all the presentations I have seen, MSU will be replaced by
    DECMCC for Ultrix, a different product. However, to manage the newer
    products, you need the Fiber Access Module for DECMCC. My suggestion is
    to lend them the hardware to manage this until DECMCC for Ultrix is
    available. Not the best answer, but you have limited options.
    
>3.  For some reason they want a roving MAC.  I know our concentrator doesn't
>    support this.  They want to know if we don't have a roving MAC what 
>    happens when a station is inserted or removed (what frames are sent around
>    the ring)?

    	No answer.
    
>4.  When SET SNMP is available which MIB extensions will it support?
>    Are there special fddi MIB extensions?  Will we support them?  Where
>    can I get a list of those parameters?  Is there an RFC?

    	No answer.
    
>5.  Are there any plans to develop a concentrator with more than 8 ports,
>    say something around 30?

    What are the distances involved? They can get higher concentrations
    using copper FDDI if the distance involved is < 100m. Other than this,
    you need to contact the product manager. Each copper board can support
    6 connections for copper vs. 4 connections for fiber.

>6.  SMF is for the backbone and between concentrators, right?  It won't be
>    employed from controller to concentrator, right?

    	No answer.
302.2Couple of more answersQUIVER::CIARFELLAWhen in doubt, mumble.Fri Jul 19 1991 10:3736
>2.  NIH doesn't have any VMS systems (therefore no DECelms).  They really
>    want to be able to manage the concentrators with SET SNMP commands (which
>    won't be available till the end of the year?).  Until then the only other 
>    choice for management is DECmcc MSU V1.1, right?  Also, is it
>    possible to manually shutdown a concentrator port (sorry I've never seen
>    one)?
    
    It is possible to enable and disable concentrator ports, in DECelms,
    DECmcc ELM, and in the future (when SET capability is available) 
    DECmcc SNMP, and MSU.
    
    As for SET capability, any SNMP implementation will be able to do
    'gets' and 'sets' on our FDDI products.
    
>3. For some reason they want a roving MAC.  I know our concentrator doesn't
>    support this.  They want to know if we don't have a roving MAC what 
>    happens when a station is inserted or removed (what frames are sent around
>    the ring)?
    
    This question does not make much sense to me.  
    
    Whenever a MAC leaves or enters the ring, it must scrub the ring for a
    certain period of time.  This scrubbing action (the sourcing of idle
    symbol pairs) will clean the ring of all packets and fragments.  After
    the scrubbing completes, the normal FDDI claim process begins.
    
>4.  When SET SNMP is available which MIB extensions will it support?
>    Are there special fddi MIB extensions?  Will we support them?  Where
>    can I get a list of those parameters?  Is there an RFC?
    
    The MIBs supported will be
    	MIB II - RFC 1158
    	FDDI MIB - currently under the experimental branch of the
    			IETF management model; no RFC number yet
    	DEC vendor extended MIB - under the vendor branch
    
302.3Some more answersJUMP4::JOYGet a life!Fri Jul 19 1991 11:3632
>1.  NIH would like to dual home DAS workstations to two concentrators.  They
>    want to use our workstations (for high availability data).  Will we ever
>    support a DAS controller for this situation?  Is there some technical 
>    reason why this is not a good idea?

    I believe there is also the question do the higher level
    protocols support dual- or multi-homing? The dual-homing concept allows
    a concentrator to have a hot-standby connection to another CON. A
    workstation would have to support this type of hot-standby DECnet or
    TCP/IP connection to make it feasible. Are they worried about the CON
    failing or the adapter board in the WS? If they have to shut down a
    DECnet circuit or TCP/IP circuit and then bring up the other one if the
    CON fails, it might be almost as fast to just swap the cable from one
    CON to another.
    

>3.  For some reason they want a roving MAC.  I know our concentrator doesn't
>   support this.  They want to know if we don't have a roving MAC what 
>    happens when a station is inserted or removed (what frames are sent around
>    the ring)?

    Not a good idea and also a proprietary implementation. See Paul
    Koning's comments in 239.1 and 288.1.
    

>6.  SMF is for the backbone and between concentrators, right?  It won't be
>    employed from controller to concentrator, right?

    So far there are no plans to offer an adapter with SMF. But check with
    the product managers to be sure (Geirge Nielsen, Sharon O'Neill)
    
302.4CIVAGE::FEARNOWBobbi Fearnow @WNP 427-5683Fri Jul 19 1991 15:3823

Thanks for all your responses, they are most helpful.

Just a couple of clarifications:

re .1
    My understanding is that a customer with MSU (and the upgrade service)
    will be ugraded to DECmcc for Ultrix when it is available.

    Also, NIH has several Ultrix Workstations.  They would prefer to have
    a single SNMP based management station (I think its ATT) rather than
    an SNMP management station and an Ultrix station running MSU (for the
    RBMS piece in V1.1).

re  .3
    NIH is concerned about the concentrator failing, not the adaptor.  We
    have discussed having a second concentrator and swapping cables as an
    option.  Your point about the higher level protocols needing to support
    dual homing is a good one, something I try to communicate to them.

Thanks again!
Bobbi
302.5KONING::KONINGEesti vabaks!Mon Jul 22 1991 11:5532
Re .1: careful with that answer about DAS.  You actually answered a different
question, which was "I want to connect my ws directly to the dual ring, what
can you do for me?"

1. To connect to the dual ring you MUST have a DAS.  However, for reasons
   explained in .1 and elsewhere, connecting things that are accessible to
   users to the dual ring is a bad idea.  The only thing connected to the
   dual ring should be tightly controlled "backbone" devices -- and not many
   of them.  Concentrators are the primary example; bridges can also be
   connected that way.

2. However, if you have a DAS that doesn't mean you have to connect it to
   the dual ring.  You can also connect it, dual-homed, to concentrators.
   That is a perfectly sensible thing to do!  This will give you redundancy
   to protect from a limited set of faults.
   We don't offer this configuration.  An alternative that will protect
   from a much larger set of faults is to use two FDDI (SAS) adapters.
   Subject to the rules of the higher layer protocols, you can connect them
   to the same FDDI (via concentrators).  Alternatively, it would be even
   better to connect them to SEPARATE FDDI LANs.  That way you're still
   in business even if an entire LAN goes down, which is possible.
   Before you propose this sort of approach, be sure to find out what higher
   layer protocols (e.g., IP, OSI) are to be used, and what the topology
   rules are that need to be followed.

Re roving MAC: see the earlier notes on this topic.  I'd suggest you ask
the customer "Roving MAC is a mechanism that may (or may not) do something
useful.  What service -- as opposed to mechanism -- are you looking for?"
Also discuss with them the ANSI standard station insertion rules we follow;
it's a good bet that this will be perfectly adequate for their needs.

	paul