Participation in Mantra

Importance of cooperation from the community:

• Most monitoring data that Mantra uses is collected by capturing various state tables from multicast routers. Mantra in fact relates a snapshot of the multicast infrastructure from the point of view of the routers Mantra collects from. The proximity of the results from Mantra to that of the global view of the multicast infrastructure relies on the diversity of the set of routers from which data is collected, that is, the differences in their topological and geographical locations, multicast routing protocols, amount and type of traffic they generate, etc. The inherent nature of multicast prohibits derivation of a global picture via capturing the state information from just a few routers. Interdomain protocols such as MBGP and sparse mode protocols such as PIM-SM further hinder the generation of a global snapshot without monitoring information from multiple multicast sites/networks.

What kind of participation would help:

• Sites willing to participate in Mantra monitoring can best help the effort by regulrarly providing routing tables from their local multicast routers to the central Mantra site. Currently, the tables are captured regularly via expect scripts to the routers, which requires appropriate access. Eventually we want to support access via SNMP, although at this time not all the protocols have corresponding MIB support.

Privacy issues:

• Many route tables, e.g., MBGP, DVMRP, MSDP, depict global multicast state; there is generally no problem in sharing suchinformation. On the other hand, some information, e.g., statistics about the data flow, intranet activities, might be too sensitive for some participating sites to share. In the latter case, sites may choose to filter such information before passing it to us or may not give us access to it at all. Although the more information provided, the greater the contribution toward efficient monitoring; even partial information can be of considerable significance.
• In any case, irrespective of the sensitivity of the information, almost all results displayed on the Mantra pages are the result of aggregation of data collected from multiple sources. Consequently, data from individual routers are camouflaged by the aggregate view.

Access to routers:

• As mentioned above, until we have SNMP support, data collection currently requires read-only access to the router. Participating sites can either give us read-access to the relevant routers or they can collect data locally and transfer it to the central Mantra site. The former method allows Mantra to do better error checking, more accurate estimation of time values and better aggregation of information from multiple routers, but does require (read-only) access that might ISPs uncomfortable. The latter method prevents this security issue, and further gives the site the opportunity to filter out sensitive information if desired.

Why should sites invest resources in a global monitoring effort?:

• In contrast to unicast routing, debugging multicast routing relies extensively on cognizance of the global state of multicast. Participation in a global monitoring effort by multiple sites will not only help improve the accuracy of the *global* view but will also provide participating sites with mechanisms to easily compare their performance/problems with those of the global multicast setup.
• All the graphs on Mantra's main pages reflect the results from aggregated data. However, similar results for individual routers are also available in the section Routers that we Monitor. Currently, results from all the routers are world-accessible, but if necessary/desirable results from different routers could be made individually password protected.