Bgpmon allows real-time monitoring of BGP messages in addition to capturing the messages and table dump information in files for later analysis. BGPMon also replaces the MRT format with a new XML format. MRT is not flexible enough to add new features such as labeling, peering security, and so forth. We introduce the BMF(BGPMon Format) for only internal use in BGPMon. BMF is defined based on the subset of MRT as we just need a part of MRT in BGPmon. Take bgp4mp of MRT as an example, we need most of infomation defined in bgp4mp of MRT and a new field 'label' for our purpose. In this way, BGPMon can provide flexible functionality with BMF. As of release 4, we only provide XML output to clients.

• Bgpmon monitors multiple BGP peers.
• Bgpmon requests the updates from other Bgpmons in order to acheive scalability.
• Bgpmon feeds a real-time stream to multiple clients via TCP connections.
• Bgpmon captures all open, update, keepalive, and notification BGP messages from monitored peers.
• Bgpmon captures state changes from the BGP finite state machine for each monitored peer.
• Bgpmon maintains a RIB-In table for each monitored peer.
• Bgpmon provides streams in XML formats.
• Bgpmon logs messages and RIB table information with GMT timestamps.

• BGPmon stores one RIB-IN for each pee
  • Updates are transient and written to logs/clients
  • RIB-IN dominates memory and limits scaling
• BGPmon chains distribute RIB-Ins
  • Each BGPmon provides update flow from each peer
  • Each BGPmon appears to provide RIB-IN for each peer
    • In fact only stores RIB-IN for directly connected peers

In this Figure, each leaf BGPMon only monitors some of the local BGP routers and maintains their rib tables. A root BGPMon
is configured as a reception to allow data access for various client applications. It does not monitor any BGP router.
It simply passes data from other connected BGPMons. In this way, all end users use the same interface
from one BGPMon to access all monitored routing information without knowledge of the internal structure. This flexibility
and simplicity allow regional deployment of BGPMons to support local routers and logs, while also allowing a consolidated global view.

Here the BGPMon data means two parts. One is the data of log and rib file which are generated periodicly by BGPMon itself. Another part is the data stream sent from BGPMon to it clients upon client requests. But both the two parts share the same XML format . Here is just a very brief description of the XML format, For the details, please refer to internet draft of this XML format which we are working on now. Currently there are two types of information which are included in BGPMon: BGP logs and BGP rib contents. Here are 2 samples for BGP logs and BGP rib contents.

• xml logs
• xml rib

Clearly we pay a storage cost for the XML format compared with MRT as compact binary message is expanded into ASCII with Tags. In order to find out how much we pay for XML format in terms of storage size, we conducted a experiment for XML, MRT and bgpdump format. Experiment results are promising using the default compression parameters for bzip2. As shown in the table below, the uncompressed XML requires more space, but the compressed XML require less space than MRT. Compared with bgpdump format, less storage will be used in compressed Xml format. Even compared with MRT binary format, XML almost consumes the same storage. This table shows the size of data used in the above comparison, using MRT as the baseline.