Conference azur::mcc

    ALL Ethernet stations, whether DEC or non-DEC, are supposed to support
either Ethernet V2 loopback or IEEE 802 XID & TEST.  If the station does
XID & TEST, then both the "TEST STATION" and the "SHOW STATION <id> ALL
CHARACTERISTICS" commands will work.  If only Ethernet V2 loopback is
supported, then only the "TEST STATION" command will respond.  In practice,
we've seen some third party stations which don't support the required
functions (mostly Ethernet V2 ones).
    Bottom line:  Yes, there is a lot of DEC specific (i.e. - MOP) testing
done in the ETHERNET AM, but we also provide the generic tests which
everyone is supposed to support.  If the third parties don't respond to
THOSE, then they're breaking the rules, and there's not much we can do to
support them.  Now, it's possible that there are some quirks in either the
station or the ETHERNET AM that cause us not to interoperate properly in
some cases, and we should try to rule this out before laying the blame on
the third party vendor.

						Wayne

Thanks for taking the time to test the Ethernet AM against these devices!!!

RE: Point #1.
-------------
 The Ethernet AM requires that a Station AT LEAST respond to the IEEE802 XID
 and/or IEEE802 TEST functions (or the Ethernet V2 Loop function). I believe
 stations must implement the XID/TEST functions if they claim to be IEEE802
 compliant (i.e. not an optional function). However, we have no control over
 what 3rd parties actually implement.

 If an entity on the wire does not respond to one of these requests, we do not
 consider it being of Class STATION.

 I disagree with your statement branding the Ethernet AM as "useless", but
 then some expect the Ethernet AM to speak ANY PROTOCOL THAT COULD EXIST ON
 AN ETHERNET LAN to be branded as "useful".

RE: Point #2.
------------
 Yes, requiring any entity to be accessible at the time of Registration is
 a pretty severe limitation. Note that this limitation applies to ALL ENTITIES
 managed by MCC, not just the Ethernet AM. This limitation does, however,
 prevent junk from finding its way into the namespace (e.g. Non-STATION
 entities Registered as STATIONs).

 A partial solution to this problem might be to incorporate some ETHERnim
 functionality into DECmcc BMS:

	1. Ethernet Station Events (i.e. New Station Discovered) with
	2. Automatic Registration using said Events

 Implementing EVENTS in the Ethernet AM is being seriously considered for
 DECmcc V1.2.

RE: "In the future, will we be able to register an entity not yet reachable ?"

 I believe this functionality is being considered for an upcoming MCC release.

    Having been dealing with Ethernet devices since DEC started field
    testing the H4000, experience shows that not all vendors are as
    rigorous about building to standards as we are.  This will become
    a problem as the Ethernet station AM attempts to manage more 3rd
    party devices.
    
    .1 reply hit the problem directly: we need a way to determine if
    the target device is non-compliant or if the AM has a "quirk" of
    some kind.
    
    Would it be possible to maintain a list of 3rd party devices that
    have been seen to work with our AM's?  This would almost certainly
    save all of us a lot of grief.
    
    Regards,
    
    Glen R.
    

    What about using "ping" (UCX LOOP mynode) to determine whether or not a
    node is "alive".  Why can't this be used for TCP/IP nodes (SUN, etc)? 
    
    I would also like to register a node as I do in ETHERnim, and then do a
    REQID or "ping" to check to see if the node is alive.
    
    -Dan

 RE: 694.4 (ping, etc)

>   What about using "ping" (UCX LOOP mynode) to determine whether or not a
>   node is "alive".  Why can't this be used for TCP/IP nodes (SUN, etc)? 

I'm not sure whether you're responding to note 694.3, or asking for new
functionality in the Ethernet (Station) AM.

ICMP echo (aka "ping") will be supported in the TCP/IP Diagnostic Assistant
for DECmcc V1.2, and *possibly* in the TCP/IP SNMP AM as well (maybe mapped
to the TEST directive). Ping is currently not supported in DECmcc V1.1.

Ethernet AM works at the Ethernet Datalink level and uses Ethernet Address
as (real) identifiers. Support includes things not specific to DEC (e.g.,
802.2 TEST and XID, Ethernet V2.0 Loopback). We have no plans to expand
this to support higher level protocols and (real) identifiers besides
Ethernet Address (e.g., no ping or DECnet mirror for Ethernet Station).
    
>   I would also like to register a node as I do in ETHERnim, and then do a
>   REQID or "ping" to check to see if the node is alive.

The "partial registration" feature in DECmcc V1.2 might help (a little) 
here: you'll be able to register a Node4 even if it isn't currently
responding.

Note that ETHERnim combines DECmcc's NODE4 and STATION (and BRIDGE, and...)
classes into one.

						Chris Brienen
						ex-ENIM PL


 

    Allow me to provide a less "scribbled" version of note 694.4:
    
    RE: .0   One of my requirements is to be able to register anything and
    everything connected to the network via an Ethernet Interface.  I must
    also be able to register soon-to-be-attached nodes.  Nodes are
    constantly being taken down, moved, re-named (booted multiple times in
    a single day with different names and IP & DECnet addresses), upgraded
    (SUNs get their Ethernet 08-00-20-xx-xx-xx address from the CPU, so a
    CPU board swap-out or upgrade changes the address).
    
    We would like to also be able to register a node and then test it later
    to see when it is operational.  V1.1 doesn't allow us to do that now. 
    It is a must for us.
    
    RE: .1   SUN does not support ENETV2 loopback.  I can't register any of
    the SUNs (old or new) using the STATION AM since they apparently do not
    support IEEE802_Only either.  We do have an ENETV2 agent which we put
    on certain nodes, and it seems to work, but brand new nodes without
    SNMP or ENETV2 agents can be seen only after they boot, and then only
    via the ICMP "ping".
    
    RE: .2   I know that you are trying to modularize and standardize, but
    I am one of those who would like to see a "catch-all" global entity
    class AM supporting rudimentary protocols of all types so I could
    manage anything until I got an SNMP agent on it.  Then I would register
    it as a TCPIP_SNMP entity.
    
    I wonder how Auto-Discover will classify odd-ball network devices? 
    When a new address is seen on the network, what will determine to which
    global entity class it belongs?
    
    RE: .5  How will ICMP ping work with unregisterable nodes that have IP
    addresses, assuming ICMP is part of TCPIP_AM or Diagnosis module?
    
    RE: .6  I just finished installing the PING_AM from obtained from
    Jean-Marc Moser's group, but haven't had a chance to test it yet.  I'll keep
    you posted and may have more ideas regarding .5 and TCPIP.
    
    -Dan