SNMPv1 (Simple Network Management Protocol) and SNMPv2c, along with the associated Management Information Base (MIB), encourage trap-directed notification.
The idea behind trap-directed notification is as follows: if a manager is responsible for a large number of devices, and each device has a large number of objects, it is impractical for him to poll or request information from every object on every device. The solution is for each agent on the managed device to notify the manager without solicitation. It does this by sending a message known as a trap of the event.
After receiving the event, the manager displays it and may choose to take an action based on the event. For instance, the manager can poll the agent directly, or poll other associated device agents to get a better understanding of the event.
Trap-directed notification can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests. However, it is not possible to totally eliminate SNMP polling. SNMP requests are required for discovery and topology changes. In addition, a managed device agent can not send a trap, if the device has had a catastrophic outage.
You want to generate traps based on the rtr fields? I don't think it will do it directly but they have added many things in 12.4T
It can be done but you will have to do it yourself.
Biggest issue is finding the SNMP MiBS. RTR is a table and if you delete or add them your mibs change slighly.
I use MRTG to montior these but it took a lot on digging with a mib browser to find them.
Once you have located the mibs that match the field you want to monitor you can use the RMON command to generate the traps. RMON can montior just about any mib in the router.
Please compile the MIB "CISCO-RTTMON" on your NMS. Then enable "snmp-server enable traps rtr" on your router, running IP SLA / RTR. You can send traps for jitter, rtd or other vialoations on IP SLA / RTR tests by setting a threshold and configuring "reaction-trigger" as "send traps". Thi can be defined as part of your IP SLA / RTR test definition on the router.
Over and abive this simple solution, some NMS id capable of using the RTTMON configuration MIBs to even write (need snmp RW string) RTR or IP SLA test configurations onto the router and then retrieve the collected information using RTTMON statistics MIB definitions.