WIMS> Proposal for WIMS Proxy Interfaces

WIMS> Proposal for WIMS Proxy Interfaces

McDonald, Ira imcdonald at sharplabs.com
Tue Feb 22 12:01:12 EST 2005


Hi Bill,

I withdraw this proposal - this is for WIMS/1.1, if that ever
happens - expanding the scope of WIMS requirements to actually
harmonize with existing/deployed network management systems
isn't practical. 

The standard network management behemoths (colorful phrase!)
have toolkits for 'access methods' - the protocol on the
outside of those access methods need not be SNMP or WBEM.
By standardizing the interface from a WIMS Proxy Agent to
an access method as WIMS protocol, the work is offloaded
from the WIMS Proxy Agent to the one or more WIMS Proxy
Managers in access methods.

If HP OpenView folks were still actively participating in
the WIMS working group, this would have seemed important.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

-----Original Message-----
From: A. Lynne Wagner [mailto:LynneWagner at comcast.net]
Sent: Monday, February 21, 2005 6:35 PM
To: 'McDonald, Ira'; wims at pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces


Ira,

Good point. However, there are a significant number of sites that do accept
an integrated WIMS/SNMP proxy independent of a more involved management
system that may or may not be in place. I agree that having a well
established interface to standard network management behemoths would be
advantageous.  But would the interface be the same for the various flavors?
Or would all systems accept an SNMP structured query (for example)? The
general idea of the proxy is that the proxy agent implements the schedule
and alert sense functions, but relies upon some other protocol to get or
send actual management information to the end-point managed entities.  A
statement as to how this information may be obtained via SNMP polls or alert
setups may be useful in explaining how a WIMS/SNMP proxy works, and may be a
justifiable effort if it could act as the proxy interface you reference. But
I would suggest postponing any more ambitious address of this interface
until there is both an indication of need and an understanding of what would
be necessary make this interface compatible with likely systems.

There are a significant number of people on this list. We would certainly be
interested in whether this additional interface pair is seen as a
requirement (and indeed, any other comments on WIMS objectives and current
definition).

Bill Wagner


-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of McDonald,
Ira
Sent: Monday, February 21, 2005 4:55 PM
To: 'A. Lynne Wagner'; wims at pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces

Hi Bill,

In actual customer deployments these are NOT 'internal
interfaces'.  In a typical large enterprise environment,
a WIMS Proxy Agent might be forwarding to/relaying from
existing system management applications using IETF SNMP,
OASIS WSDM, and DMTF WBEM.

Major system management applications are ALWAYS deployed
on dedicated systems with extremely high security.  And
single-system license cost of HP OmniView, CA Unicenter, 
and IBM Tivoli all start at US $50,000 and ascend rapidly 
to US $250,000 for a larger number of managed entities.  

All of these commercial system management stations have 
toolkits for writing "access methods" to/from other 
management protocols, but they ALL require that the 
"access method" runs on the same platform as the deployed
system management station (to avoid compromised security).

Even if a printer vendor was willing to spend the money
to imbed multiple native management protocols in a WIMS
Proxy Agent, no customer would be willing to deploy it.

So the remote WIMS Proxy Manager (on a different host
than the WIMS Proxy Agent) will be the dominant pattern.

If we leave these forwarding/relaying interfaces as an
exercise for the implementor, we make WIMS deployment
much less likely.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

-----Original Message-----
From: A. Lynne Wagner [mailto:LynneWagner at comcast.net]
Sent: Monday, February 21, 2005 2:58 PM
To: 'McDonald, Ira'; wims at pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces


Ira,

I sketched out what I understand you to be referring to. Assuming that I
understand correctly, I have been regarding these as "internal interfaces",
even if it were seen necessary to remote the proxy agent from the proxy
manager (which, to me, seems unlikely). That is, I would regard these
interfaces as implementation dependent and not necessary for WIMS to
specify, aside from the implicit requirement that they preserve as much of
the WIMS protocol information as possible. I also suggest that the form of
this interface would probably be different in the case of a WINS-to-SNMP
proxy versus a WIMS-to-WIMS proxy or a WIMS-to-HTTP Web page proxy, etc.

Bill Wagner

-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of McDonald,
Ira
Sent: Monday, February 21, 2005 11:43 AM
To: 'wims at pwg.org'
Subject: WIMS> Proposal for WIMS Proxy Interfaces

Hi folks,                                      Monday (21 February 2005)

After recent work on the WIMS Object Model, I see a need for two more
WIMS interfaces:

(1) Proxy Agent Interface - operation requests forwarded by a WIMS Proxy
    Agent to a (local or remote) subordinate WIMS Proxy Manager and
    subsequently delivered to subordinate Agent(s) registered with that
    Proxy Manager

(2) Proxy Manager Interface - operation requests relayed by a WIMS Proxy
    Manager to a (local or remote) superior WIMS Proxy Agent, based on
    operation requests received from subordinate Agent(s) registered
    with that Proxy Manager

Comments?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
------------------------------------------------------------------------


There are two possible network topologies for a WIMS Proxy:


            Integrated WIMS Proxy

{DomainA}   {............DomainB............}
*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
 (HostA)     (......HostB......)    (HostC)


            Distributed WIMS Proxy

{DomainA}   {............DomainB............}
*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
 (HostA)     (HostB)     (HostC)     (HostD)


Notes:

(1) If DomainA and DomainB are different, then this is fleet management
    and firewalls constrain the origin of connections.

(2) If DomainA and DomainB are the same, this is enterprise management.

(3) In all cases, Proxy Agent, Proxy Manager, and End Agent MUST be in
    the same domain for any practical implementation.

(4) In the 'Integrated WIMS Proxy' case, Proxy Agent to Proxy Manager
    communications MAY be proprietary.

(5) In the 'Distributed WIMS Proxy' case, Proxy Agent to Proxy Manager
    communications MUST be standardized (so these new interfaces should
    be CONDITIONALLY MANDATORY to support).

(6) These topologies are recursive, that is, the End Agent may in fact
    be a Proxy Agent with further subordinate Proxy Managers.

------------------------------------------------------------------------


Proxy Agent Interface operations:

(1) ForwardAction
    - forwarded ExecuteAction received from a superior WIMS Manager
    - triggered Action in a current Schedule on the Proxy Agent

(2) ForwardSchedule
    - forwarded SetSchedule received from a superior WIMS Manager and
      possibly decomposed by the Proxy Agent

------------------------------------------------------------------------


Proxy Manager Interface operations:

(1) RegisterForProxy
    - registers Proxy Manager with superior Proxy Agent
      based on prior configuration (NOT dynamic discovery)

(2) UnregisterForProxy
    - unregisters Proxy Manager with superior Proxy Agent

(3) RelayRegister
    - relayed RegisterForManagement received from a subordinate WIMS
      Agent and possibly aggregated or delayed by the Proxy Manager

(4) RelayUnregister
    - relayed UnregisterForManagement received from a subordinate WIMS
      Agent and possibly aggregated or delayed by the Proxy Manager

(5) RelayAlerts
    - relayed SendAlerts received from a subordinate WIMS Agent
      and possibly aggregated or delayed by the Proxy Manager

(6) RelayReports
    - relayed SendReports received from a subordinate WIMS Agent
      and possibly aggregated or delayed by the Proxy Manager

(7) RelayGetSchedule
    - relayed GetSchedule received from a subordinate WIMS Agent

------------------------------------------------------------------------


Example Sequences of Operations:


*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
                         RegisterForProxy
                <-----------/

             RegisterForProxy.response
                \----------->


*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
                                     RegisterForManagement
                            <-----------/
                         RelayRegister
                <-----------/
             RegisterForManagement
    <-----------/

 RegisterForManagement.response
    \----------->
             RelayRegister.response
                \----------->
                         RegisterForManagement.response
                            \----------->


*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
 ExecuteAction
    \----------->
             ForwardAction
                \----------->
                         ExecuteAction
                            \----------->

                                     ExecuteAction.response
                            <-----------/
                         ForwardAction.response
                <-----------/
             ExecuteAction.response
    <-----------/


*-------*   *-------*   *-------*   *-------*
|  Top  |   | Proxy |   | Proxy |   |  End  |
|Manager|   | Agent |   |Manager|   | Agent |
*-------*   *-------*   *-------*   *-------*
                                     GetSchedule
                            <-----------/
                         RelayGetSchedule
                <-----------/
             GetSchedule
    <-----------/

 GetSchedule.response
    \----------->
             RelayGetSchedule.response
                \----------->
                         GetSchedule.response
                            \----------->

------------------------------------------------------------------------



More information about the Wims mailing list