1 / 9

Standardizing the MRT format

Larry J. Blunk, Merit Network IETF 61 Washington, DC November 9, 2004. Standardizing the MRT format. Overview. MRT Background Why Standardize Basic Format Existing Type Definitions Implementations Issues. MRT Background.

aphrodite-harrington
Télécharger la présentation

Standardizing the MRT format

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Larry J. Blunk, Merit NetworkIETF 61 Washington, DC November 9, 2004 Standardizing the MRT format

  2. Overview • MRT Background • Why Standardize • Basic Format • Existing Type Definitions • Implementations • Issues

  3. MRT Background • MRT format developed as part of the Multi-threaded Routing Toolkit at Merit in mid-90's • Simple format to record routing information with timestamps • Routing messages/packets (e.g. BGP UPDATEs) • RIB table dumps • Primarily used for BGP information • Also can support other routing protocols (e.g. RIP, RIPng, OSPF, ISIS)

  4. Why standardize? • The MRT format is widely used by researchers studying BGP and Inter-domain routing • Employed by RIPE RIS and Routeviews BGP routing data collectors • Existing documentation of MRT format is limited • There are a now 9+ implementations • Some implementations have compatibility issues • Researchers and vendors have duplicated efforts in some cases to extend the format • Currently no method to avoid conflicts when extending • Standardizing routing information export format would seem to complement work in IPFIX for IP flows

  5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Basic MRT Format Initial draft - http://www.mrtd.net/doc/mrt-draft-00.html

  6. Existing Type Definitions • Control Types • NULL, START, DIE, I_AM_DEAD, PEER_DOWN • Provides indication/timestamps when a MRT data collection begins and ends, and loss of connectivity to a peer • No known implementation support • Routing Information Types • BGP, RIP, IDRP, RIPNG, BGP4PLUS, BGP4PLUS_01, OSPF, TABLE_DUMP • Zebra created new BGP4MP type which combines capabilities for BGP, BGP4PLUS, BGP4PLUS_01, and TABLE_DUMP types under a single type • Sprint Labs has created a type for ISIS information • Some undocumented vendor types – Arbor, Packet Design

  7. Implementations • Routing daemons • MRTd • Zebra/Quagga • OpenBSD BGPD • Tools • MRT routebtoa/routeatob – ascii dumper/undumper • libbgpdump – library package and bgpdump utility • zebra-dump-parser – perl based dumper • C-BGP – BGP decision process simulator • pyrt - Sprint Labs Python Routing Toolkit • Internal product implementations by vendors • Arbor Networks • Packet Design

  8. Issues • Existing MRT implementations rely on local storage of data • Transport mechanisms for devices without storage, like routers, have not been throughly addressed • The specification includes support for RIP, RIPng, and OSPF, but these formats have not been fully documented nor implemented – e.g., need should format include source/dest IP addresses • Some conflicts exist between implementations • Need mechanisms to extend format and avoid conflicts

  9. Issues (cont'd) • Existing format uses timing resolution of one second • Sprint and Packet Design have added support for sub-second resolution – may wish to standardize support • Possible new formats to aggregate or refine information • Summarization by prefix or AS may be useful • Should there be a requirements document? • Is the current basic format sufficient to meet future needs?

More Related