Conference azur::mcc

>>Can somebody give us more information concerning the "internals" of the SNMP AM,
>>in particular the way it manage proxied entities 
(can a TRAP come from a proxied
>>entity ?, how does the AM know the entity is proxied, ...)

	Christophe,
		
		In the SNMP AM proxies are modelled in the following manner.
	The entity which is acting as a proxy for the "foreign" devices has at
	least an internet address as an identifier, while the foreign device
	entity does not have any identifiers, but has a proxy agent address. 
	The proxy agent address should be the same as the ip address of the
	proxy agent entity.	   -----------------
				   | foreign device |
				  /.-----------------
		---------------- / .
	 SNMP	|	       |/  ------------------ 
	<------>| Proxy agent  |---| foreign device |
		|	       |\   ------------------
		---------------- \ ------------------
				/ \| foreign device |
	    Some other protocol/   ------------------

	So to manage the above configuration in DECmcc using the SNMP AM,
	you will have to register the proxy agent with the address of the
	node where the agent resides. The foreign devices will have to 
	be registered with the appropriate fullname, but with no other
	identifiers. However, they should be provided with a proxy agent
	agent address and read & write community names. When an SNMP request
	is made on any of the foreign devices, the request PDU's are actually
	sent to the proxy agent. The proxy agent decides which foreign device
	the request is intended for based on the community name.

>>can a TRAP come from a proxied entity ?, 

	Traps may originate at any of the foreign devices, but since the
	proxy agent is the one finally issuing the SNMP trap, the SNMP
	AM delivers the trap under the proxy agent entity, and not under
	the foreign device. This is a restriction which is present at least
	in this version.

>>how does the AM know the entity is proxied, ...)

	The AM knows that an entity is proxied from the presence of the
	proxy agent address and the absence of the internet name and
	address identifiers.


	I guess your other questions can be answered by someone else who
	is more conversant with OSI events.

	Rahul.

    note that even though the traps are received via the proxy agent,
    you can still make use of the notification targetting functions
    to reassign the trap back to the original "foreign" device.
    

After some discussions with people used to OSI standards and the reading of the
TEMIP reference guide, we contemplate developping the solution described 
below. However, could some of you check that our DECmcc assumptions are correct?
Thanks in advance.

TEMIP can only handle alarms if their format is compliant to the OSI definitions
(mainly described in OSI 10164 part 4 & 5 DIS documents). 
The way TEMIP gets an OSI event or alarm (in OSI terminology there are two kinds
of DECmcc events, OSI events and OSI alarms) is to send a mcc_call_function 
request to the DECmcc Notification FM that in turn calls the DECmcc Domain FM 
to know the entities belonging to the selected domain before issuing a GETEVENT 
(mcc_call_access) requests to the appropriate DECmcc AM which eventually issues 
a mcc_event_get call to the DECmcc Event Manager (in our case the SNMP AM would
issue this mcc_event_get request to the Event Manager by starting a process, 
let's say process A).

The following figure describes this process :

			
			TEMIP MM
			   |
			   | mcc_call_function(notify)
			   |
			Notif FM <-------> Domain FM
			   |
			   | mcc_call_access(get_event,SNMP * XYZ)
			   |				
			SNMP AM  <--------------------> Event Manager 
			          mcc_event_get
				  (process A)			    
			

When the DECmcc AM or sink process receives an event from one of the related
network entities, it sends this event to the DECmcc Event Manager with an
mcc_event_put call so that processes that asked for this event through a
mcc_event_get call can get it (in our case the SNMP receives this event, sends
it to the Event Manager so that process A can get the event).


			TEMIP MM
			   ^
			   |
			Notify FM
			   ^
			   | trap (SNMP format) 
			   |
			   |		trap (SNMP format)
			process A  <-------------------------.
							     |
							     |
			SNMP AM (sink) -------------------> Event Manager
			   ^		trap (SNMP format)
			   |
			Event

The solution we are thinking about consists in redirecting the mcc_call_access
(get_event) call to a pseudo-AM that would issue the mcc_event_get on behalf of
the SNMP AM.
When an event (trap) would arrive, the SNMP AM would still send it to the Event
Manager but this time it is the pseudo-AM which would get it. The next step 
would be to turn this trap into an OSI format before feeding the Notify FM
which asked initially for the event.

fisrt :
			TEMIP MM
			   |
			   | mcc_call_function(notify)
			   |
			Notif FM   <-------> Domain FM
			   |
			   | mcc_call_access(get_event,SNMP * XYZ)
			   |				
			pseudo_AM  <--------------------> Event Manager 
			              mcc_event_get
				      (process B)			    
			

and then :
			TEMIP MM
			   ^
			   |
			Notify FM
			   ^
			   | OSI event or alarm
			   |
			   |		trap (SNMP format)
			process B  <--------------------------.
							      |
							      |
			SNMP AM (sink) -------------------> Event Manager
			   ^		trap (SNMP format)
			   |
			Event


Could someone confirm these 2 assumptions :

1) the mcc_call_function issued by the Notify FM (GETEVENT SNMP * XYZ)
   can be redirected to our pseudo-AM provided the dispath table entry for
   GETEVENT SNMP * XYZ is modified to point now at a routine of this pseudo_AM 
   (this implis and update of the current dispatch table).

2) the Event Manager not only manages the event queues associated with the 
   different requests, but also verifies that the received event is compliant 
   with the definition in the MCC dictionnary. The Notify FM also performs 
   such a check.
   Thus we propose to modify the MCC dictionnary so as to create 2 definitions
   for each enterprise specific trap : the first would represent the current 
   SNMP definition associated with the trap whereas the second would describe 
   the same trap but with OSI compliant fields.
   This trick would allow the Event Manager to handle the trap in an SNMP 
   format, the pseudo-AM to turn the SNMP trap into an OSI event or alarm and
   the Notify FM to handle an OSI event or alarm.


The only drawback is that any specific trap received by the SNMP AM from this 
entity would be turned into and OSI format. Thus even the standard DECmcc
ALARM FM would received these traps in OSI format.
Of course this kind of solution could be extended to any enterprise specific
trap provided that the MCC dictionnary is modified accordingly (2 definitions
for each trap) and the MCC dispatch table updated.
One could even think about turning all traps (even the generic ones) into 
OSI format since the current MCC dictionnary definitions for the generic traps
can be augmented to contain 2 definitions for each generic trap.

Is DECmcc working this way. Are we missing something ?

Christophe.

>>>1) the mcc_call_function issued by the Notify FM (GETEVENT SNMP * XYZ)
>>>   can be redirected to our pseudo-AM provided the dispath table entry for
>>>   GETEVENT SNMP * XYZ is modified to point now at a routine of this pseudo_AM 
>>>   (this implis and update of the current dispatch table).

Seems this should work even it may not be recommended (provided than our
pseudo-AM is enrolled after the SNMP AM in order to replace the apt dispatch
entry).
Another way of capturing all the "GETEVENT SNMP * XYZ" mcc_calls would be
to modify the current SNMP AM by hardcoding in it something like "if the SNMP
subclass is XYZ then call ...". I guess this sort of workaround will not be
appreciated by the DECmcc SNMP's people.

>>>2) the Event Manager not only manages the event queues associated with the 
>>>   different requests, but also verifies that the received event is compliant 
>>>   with the definition in the MCC dictionnary. The Notify FM also performs 
>>>   such a check.

Seems to be wrong according to some people I've talked with. Could somebody
confirm ?

>>>   Thus we propose to modify the MCC dictionnary so as to create 2 definitions
>>>   for each enterprise specific trap : the first would represent the current 
>>>   SNMP definition associated with the trap whereas the second would describe 
>>>   the same trap but with OSI compliant fields.
>>>   This trick would allow the Event Manager to handle the trap in an SNMP 
>>>   format, the pseudo-AM to turn the SNMP trap into an OSI event or alarm and
>>>   the Notify FM to handle an OSI event or alarm.

This solution should work since it's possible to augment the SNMP's definition
in the DECmcc dictionnary in order to create the event group needed by TEMIP
and the OSI format of the traps.


>>>The only drawback is that any specific trap received by the SNMP AM from this 
>>>entity would be turned into and OSI format. Thus even the standard DECmcc
>>>ALARM FM would received these traps in OSI format.
>>>Of course this kind of solution could be extended to any enterprise specific
>>>trap provided that the MCC dictionnary is modified accordingly (2 definitions
>>>for each trap) and the MCC dispatch table updated.
>>>One could even think about turning all traps (even the generic ones) into 
>>>OSI format since the current MCC dictionnary definitions for the generic traps
>>>can be augmented to contain 2 definitions for each generic trap.

Have the DECmcc SNMP's gurus contemplated modifying the SNMP AM so that it 
could handle SNMP traps in an OSI fashion, namely to turn them into OSI events
or alarms ? We would be interested in knowing if some evaluations have been
carried out in this area.

Christophe

>>>2) the Event Manager not only manages the event queues associated with the 
>>>   different requests, but also verifies that the received event is compliant 
>>>   with the definition in the MCC dictionnary. The Notify FM also performs 
>>>   such a check.
    
    The MCC Event Manager does not perform any Dictionary calls.
    
    -Matt.

    simply add the new snmp * entry points in the function table
    instead of the access table and you should be all set.
    

    
    Can anyone tell me what the outcome of these investigations was ?  Was
    the proposed solution ever implemented ?
    
    I am currently investigating a similar problem - trying to map DECmcc
    events from several AMs (including the SNMP AM) into OSI alarms for
    TeMIP, and any further information anyone can give me about possible
    solutions to the problem would be very much appreciated.
    
    Thanks in advance,
    
    Lee.
    
                                             

Re .7:

Lee,

     Along with the port to OSF/1, we are (or will be) considering extending
     or converting as much as possible all events sent within MCC to the OSI
     format.

     SNMP AM will send OSI compatible reachability events in the first OSF/1
     version.
     Traps have not been considered yet, but may be soon.

     Anyway, since the Alarms FM emits OSI format events, you can as a
     workaround set-up OCCURS rule to make your events OSI compliant.

     Please send us a list of what events you need to handle within TeMIP, so
     that we study what we can do for them.

     Regards.

     Pierre.