Network Working Group                                           L. Blunk
Internet-Draft                                                  M. Karir
Intended status: Standards Track                           Merit Network
Expires: August 28, 2008 January 15, 2009                                    C. Labovitz
                                                          Arbor Networks
                                                       February 25,
                                                           July 14, 2008

                 MRT routing information export format
                       draft-ietf-grow-mrt-07.txt
                       draft-ietf-grow-mrt-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008. January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes the MRT format for routing information
   export.  This format was developed in concert with the Multi-threaded
   Routing Toolkit (MRT) from whence the format takes it name.  The
   format can be used to export routing protocol messages, state
   changes, and routing information base contents.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  MRT Informational Types  . . . . . . . . . . . . . . . . . . .  8
     4.1.  NULL  START Type . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  START  I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  DIE Type . . . . . . .
   5.  MRT Routing Information Types  . . . . . . . . . . . . . . . .  9
     5.1.  OSPF Type  . .  8
     4.4.  I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  PEER_DOWN  9
     5.2.  TABLE_DUMP Type  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  MRT Routing Information Types  .
     5.3.  TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . 10
     5.1.  BGP Type . . . . . 11
     5.4.  BGP4MP Type  . . . . . . . . . . . . . . . . . . . . 10
       5.1.1.  BGP_NULL Subtype . . . 13
       5.4.1.  BGP4MP_STATE_CHANGE Subtype  . . . . . . . . . . . . . 14
       5.4.2.  BGP4MP_MESSAGE Subtype . . . 10
       5.1.2.  BGP_UPDATE Subtype . . . . . . . . . . . . . 15
       5.4.3.  BGP4MP_STATE_CHANGE_AS4 Subtype  . . . . . 11
       5.1.3.  BGP_PREF_UPDATE Subtype . . . . . . 15
       5.4.4.  BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . 11
       5.1.4.  BGP_STATE_CHANGE Subtype . . . . . 16
     5.5.  BGP4MP_ET Type . . . . . . . . . . 11
       5.1.5.  BGP_SYNC Subtype . . . . . . . . . . . . 17
     5.6.  ISIS Type  . . . . . . . 12
       5.1.6.  BGP_OPEN Subtype . . . . . . . . . . . . . . . . . 17
     5.7.  ISIS_ET Type . . 12
       5.1.7.  BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12
       5.1.8.  BGP_KEEPALIVE Subtype . . . 17
     5.8.  OSPFv3 Type  . . . . . . . . . . . . . 12
     5.2.  RIP Type . . . . . . . . . . 17
     5.9.  OSPFv3_ET Type . . . . . . . . . . . . . . . 13
     5.3.  IDRP Type . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . 13
     5.4.  RIPNG Type . . . . 19
     6.1.  Type Codes . . . . . . . . . . . . . . . . . . . . 13
     5.5.  BGP4PLUS and BGP4PLUS_01 Types . . . . 19
     6.2.  Subtype Codes  . . . . . . . . . . 13
     5.6.  OSPF Type . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . 14
     5.7.  TABLE_DUMP Type . . . . . . . 20
   8.  References . . . . . . . . . . . . . . 14
     5.8.  TABLE_DUMP_V2 Type . . . . . . . . . . . . 21
     8.1.  Normative References . . . . . . . . 16
     5.9.  BGP4MP Type . . . . . . . . . . . 21
     8.2.  Informative References . . . . . . . . . . . . 18
       5.9.1.  BGP4MP_STATE_CHANGE Subtype . . . . . . 21
   Appendix A.  Deprecated MRT types  . . . . . . . 19
       5.9.2.  BGP4MP_MESSAGE Subtype . . . . . . . . . 22
     A.1.  Deprecated MRT Informational Types . . . . . . . 20
       5.9.3.  BGP4MP_ENTRY Subtype . . . . . 22
       A.1.1.  NULL Type  . . . . . . . . . . . . 20
       5.9.4.  BGP4MP_SNAPSHOT Subtype . . . . . . . . . . 22
       A.1.2.  DIE Type . . . . . 21
       5.9.5.  BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 22
       5.9.6.  BGP4MP_MESSAGE_AS4 Subtype . . . . . . . 22
       A.1.3.  PEER_DOWN Type . . . . . . . 22
     5.10. BGP4MP_ET Type . . . . . . . . . . . . . 22
     A.2.  Deprecated MRT Routing Information Types . . . . . . . . . 23
     5.11. ISIS 22
       A.2.1.  BGP Type . . . . . . . . . . . . . . . . . . . . . . . . 23
     5.12. ISIS_ET 22
       A.2.2.  RIP Type . . . . . . . . . . . . . . . . . . . . . . . 23
     5.13. OSPFv3 25
       A.2.3.  IDRP Type  . . . . . . . . . . . . . . . . . . . . . . . 23
     5.14. OSPFv3_ET 25
       A.2.4.  RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 24
   6.  IANA Considerations  . . . 25
       A.2.5.  BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26
       A.2.6.  Deprecated BGP4MP Subtypes . . . . . . 25
     6.1.  Type Codes . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . 25
     6.2.  Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Researchers and engineers often wish to analyze network behavior by
   studying routing protocol transactions and routing information base
   snapshots.  To this end, the MRT format was developed to encapsulate,
   export, and archive this information in a standardized data
   representation.  The BGP routing protocol, in particular, has been
   the subject of extensive study and analysis which has been
   significantly aided by the availability of the MRT format.  The MRT
   format was initially defined in the MRT Programmer's Guide [MRT PROG
   GUIDE].

   This memo serves to document the MRT format as currently implemented
   in publicly available software.  The format has been extended since
   it's original introduction in the MRT toolset and these extensions
   are also included in this memo.  Further extensions may be introduced
   at a later date through additional definitions of the MRT Type field
   and Subtype fields.

   Fields which contain multi-byte numeric values are encoded in network
   byte order from most significant byte to least significant byte.
   Fields which contain routing message fields are encoded in the same
   order as they appear in the packet contents.

3.  Basic MRT Format

   All MRT format messages have a common header which includes a
   timestamp, Type, Subtype, and length field.  The header is followed
   by a message field.  The MRT common header is illustrated below.

        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)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Header Field Descriptions:

      Timestamp:

         Time in seconds since 1 January 1970 00:00:00 UTC

      Type:

         A 2-octet field that indicates the Type of information
         contained in the message field.  Types 0 through 4 are
         informational messages pertaining to the state of an MRT
         collector, while Types 5 and higher are used to convey routing
         information.

      Subtype:

         A 2-octet field that is used to further distinguish message
         information within a particular message Type.

      Length:

         A 4-octet message length field.  The length field contains the
         number of bytes within the message.  The length field does not
         include the length of the MRT common header.

      Message:

         A variable length message.  The contents of this field are
         context dependent upon the Type and Subtype fields.

4.  MRT Informational Types

   The MRT format defines five Informational Type messages.  These
   messages are intended to signal the state of an MRT data collector
   and do not contain routing information.  These messages are OPTIONAL
   and were largely intended for use when MRT messages are sent over a
   network to a remote repository store.  However, MRT message
   repository stores have traditionally resided on the same device as
   the collector and these Informational Types have seen limited
   implementation.  Further, transport mechanisms for MRT messages are
   considered to be outside the scope of this document.

   Two of these messages are considered potentially useful in
   implementations with a local repository.  In particular, the

   The START and I_AM_DEAD messages MAY be used to provide a time
   reference when a data collector begins and ends the collection
   process.

   The message field MAY contain an OPTIONAL message string for
   diagnostic purposes.  The message string encoding MUST follow the
   UTF-8 transformation format.  The Subtype field is unused for these
   Types and SHOULD be set to 0.

   The MRT Informational Types are defined below:

       0    NULL         *DEPRECATED*

       1    START
       2    DIE          *DEPRECATED*
       3    I_AM_DEAD
       4    PEER_DOWN    *DEPRECATED*

4.1.  NULL Type

   The NULL Type message causes no operation and is deprecated.

4.2.  START Type

   The START Type indicates a collector is about to begin generating MRT
   messages.

4.3.  DIE Type

   The DIE Type signals a remote MRT repository it should stop accepting
   messages.  This Type is deprecated.

4.4.

4.2.  I_AM_DEAD Type

   An I_AM_DEAD MRT message indicates that a collector has shut down and
   has stopped generating MRT messages.

4.5.  PEER_DOWN Type

   The PEER_DOWN message was intended to indicate that a collector had
   lost association with a BGP peer.  However, the MRT format provides
   BGP state change message types which duplicate this functionality.
   This Type is deprecated.

5.  MRT Routing Information Types

   The following Types are currently defined for the MRT format.  Types
   5-12
   11 and 12 were defined in the MRT Toolkit package.  The BGP4MP Type,
   number 16, was initially defined in the Zebra routing software
   package.  The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
   defined in the Sprint Labs Python Routing Toolkit (PyRT).

       5    BGP          *DEPRECATED*
       6    RIP
       7    IDRP         *DEPRECATED*
       8    RIPNG
       9    BGP4PLUS     *DEPRECATED*
       10   BGP4PLUS_01  *DEPRECATED*
       11   OSPF
       12   TABLE_DUMP
       13   TABLE_DUMP_V2
       16   BGP4MP
       17   BGP4MP_ET  The OSPFv3
   and OSPFv3_ET Types are newly defined types created for the OSPFv3
   routing protocol.

       11   OSPF
       12   TABLE_DUMP
       13   TABLE_DUMP_V2
       16   BGP4MP
       17   BGP4MP_ET
       32   ISIS
       33   ISIS_ET
       48   OSPFv3
       49   OSPFv3_ET

5.1.  BGP  OSPF Type

   The BGP

   This Type indicates supports the Message field contains BGP routing
   information.  The BGP routing protocol is OSPF Protocol as defined in RFC 4271
   [RFC4271]. 2328
   [RFC2328].  The information in the message is dependent on the Subtype value.  The BGP Type and all associated Subtypes are
   considered to be DEPRECATED by the BGP4MP Type.

   The following BGP Subtypes are defined for the MRT BGP Type. field may contain two possible values:

       0    BGP_NULL    OSPF_STATE_CHANGE
       1    BGP_UPDATE
       2    BGP_PREF_UPDATE
       3    BGP_STATE_CHANGE
       4    BGP_SYNC
       5    BGP_OPEN
       6    BGP_NOTIFY
       7    BGP_KEEPALIVE

5.1.1.  BGP_NULL Subtype

   The BGP_NULL Subtype is a reserved Subtype.

5.1.2.  BGP_UPDATE Subtype

   The BGP_UPDATE Subtype is used to encode BGP UPDATE messages.    OSPF_LSA_UPDATE

   The format of the MRT Message field for this Subtype the OSPF Type is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Peer                         Remote IP address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Local IP address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP UPDATE                  OSPF Message Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  TABLE_DUMP Type

   The BGP UPDATE Contents include the entire BGP UPDATE message which
   follows the BGP Message Header.  The BGP Message Header itself TABLE_DUMP Type is not
   included.  The Peer AS number and IP address fields contain used to encode the AS
   number and IP address contents of the remote system which are generating the a BGP UPDATE messages.  The Local AS number and IP address fields
   contain the AS number and IP address of the local collector system
   which is archiving the messages.

5.1.3.  BGP_PREF_UPDATE Subtype

   The BGP_PREF_UPDATE Subtype Routing
   Information Base (RIB).  Each RIB entry is not defined.

5.1.4.  BGP_STATE_CHANGE Subtype encoded in a distinct
   sequential MRT record.  The BGP_STATE_CHANGE Subtype field is used to record changes in the BGP
   finite state machine.  These FSM states are defined in RFC 4271
   [RFC4271], Section 8.2.2.  Both the old state value and encode whether
   the new state
   value RIB entry contains IPv4 or IPv6 addresses.  There are encoded as 2-octet numbers.  The state two
   possible values are defined
   numerically for the Subtype as follows: shown below.

       1    Idle    AFI_IPv4
       2    Connect
       3    Active
       4    OpenSent
       5    OpenConfirm
       6    Established    AFI_IPv6

   The format of the MRT Message field TABLE_DUMP Type is as follows: illustrated below.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS           View #              |       Sequence number         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix (variable)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    Status     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Originated Time                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Peer IP address (variable)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Old State           Peer AS             |          New State       Attribute Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.5.  BGP_SYNC Subtype
       |                   BGP Attribute... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The BGP_SYNC Subtype was View field is normally 0 and is intended to convey a system file name for cases where
   BGP Table Dump messages should be recorded. an
   implementation may have multiple RIB views (such as a route server).
   The View # was to
   correspond Sequence field is a simple incremental counter for each RIB
   entry.  A typical RIB dump will exceed the 16-bit bounds of this
   counter and implementation should simply wrap back to zero and
   continue incrementing the View # provided counter in such cases.

   The Prefix field contains the TABLE_DUMP Type messages.
   There are no known implementations IP address of this subtype and it SHOULD be
   ignored. a particular RIB entry.
   The following format applies to size of this Subtype:

        0                   1                   2                   3
        0 1 2 3 field is dependent on the value of the Subtype for
   this message.  For AFI_IPv4, this field is 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        View #                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            File Name... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The File Name is terminated with a NULL (0) character.

5.1.6.  BGP_OPEN Subtype

   The BGP_OPEN Subtype octets, for AFI_IPv6, it
   is used to encode BGP OPEN messages. 16 octets in length.  The format Prefix Length field indicates the length
   in bits of the MRT Message field prefix mask for this Subtype is the same as the
   BGP_UPDATE, however, preceding Prefix field.

   The Status octet is not used in the last field TABLE_DUMP Type and SHOULD be set
   to 1.

   The Originated Time contains the contents of 4-octet time at which this prefix
   was heard.  The value represents the BGP
   OPEN message.

5.1.7.  BGP_NOTIFY Subtype time in seconds since 1 January
   1970 00:00:00 UTC.

   The BGP_NOTIFY Subtype Peer IP field is used to encode BGP NOTIFICATION messages.
   The format the IP address of the MRT Message field peer which provided the
   update for this Subtype is RIB entry.  As with the same as Prefix field, the BGP_UPDATE, however, size of
   this field is dependent on the last Subtype.  AFI_IPv4 indicates a 4 octet
   field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
   octet field and an IPv6 address.  The Peer AS field contains the contents AS
   number of the
   BGP NOTIFICATION message.

5.1.8.  BGP_KEEPALIVE Subtype

   The BGP_KEEPALIVE Subtype peer.

   Attribute length is used to encode BGP KEEPALIVE messages.
   The format of the MRT Message length of Attribute field for this Subtype and is the same as
   the BGP_UPDATE, however, the last 2-octets.
   The Attribute field contains no information.

5.2.  RIP Type

   The RIP the attribute information for the RIB
   entry.

5.3.  TABLE_DUMP_V2 Type is

   The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT
   ASN support and full support for BGP Multiprotocol extensions.  It
   also improves upon the space efficiency of the TABLE_DUMP Type by
   employing an index table for peers and permitting a single MRT record
   per NLRI entry.  The following subtypes are used with the
   TABLE_DUMP_V2 Type.

       1    PEER_INDEX_TABLE
       2    RIB_IPV4_UNICAST
       3    RIB_IPV4_MULTICAST
       4    RIB_IPV6_UNICAST
       5    RIB_IPV6_MULTICAST
       6    RIB_GENERIC

   An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
   collector, an optional view name, and a list of indexed peers.
   Following the PEER_INDEX_TABLE MRT record, a series of MRT records
   are used to export RIP protocol packets as defined in RFC
   1058 [RFC1058]. encode RIB table entries.  This series of MRT records use
   subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record
   itself and include full MRT record headers.  The header of the
   PEER_INDEX_TABLE Subtype field is currently reserved for this
   Type and SHOULD shown below.  The View Name is optional
   and, if not present, the View Name Length MUST be set to 0.  The format of the MRT Message field for View
   Name encoding MUST follow the RIP Type is as follows: UTF-8 transformation format.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Peer IP address                      Collector BGP ID                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local IP address       View Name Length        |     View Name (variable)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    RIP Message Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  IDRP Type          Peer Count           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
   protocol information as defined in format of the ISO/IEC 10747 standard.  The
   Subtype field is unused.  This Type peer entries is deprecated due to lack of
   deployment of IDRP.

5.4.  RIPNG Type

   The RIPNG Type is used to export RIPNG protocol packets as defined in
   RFC 2080 [RFC2080].  The Subtype field is currently reserved for this
   Type and SHOULD be set to 0. shown below.  The format of the MRT Message field for the RIPNG Type is as follows: PEER_INDEX_TABLE
   record contains Peer Count peer entries.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Peer IP address Type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local                         Peer BGP ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Peer IP address (variable)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  RIPNG Message Contents                        Peer AS (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.5.  BGP4PLUS and BGP4PLUS_01 Types                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 Peer Type, Peer BGP
   routing information.  The BGP4PLUS Type was specified based on ID, Peer IP, and Peer AS fields are repeated
   as indicated by the
   initial Internet Draft for Multiprotocol Extensions to BGP-4. Peer Count field.  The
   BGP4PLUS_01 Type was specified to correspond to the -01 revision position of
   this Internet Draft.  The two Types share the same definitions Peer in
   terms of their
   the PEER_INDEX_TABLE is used as an index in the subsequent
   TABLE_DUMP_V2 MRT format specifications. records.  The Subtype field definitions are shared index number begins with 0.

   The Peer Type field is a bit field which encodes the BGP Type, however,
   the address fields in type of the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
   BGP_KEEPALIVE, AS
   and BGP_STATE_CHANGE Subtype messages are extended to
   16 octets IP address as follows:

      Bit 0 - unset for IPv4 Peer IP address, set for IPv6 addresses.  As with
      Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits

   The records which follow the BGP Type, PEER_INDEX_TABLE record constitute the BGP4PLUS
   RIB entries and
   BGP4PLUS_01 Types are deprecated as they superseded by include a header which specifies a sequence number,
   NLRI, and a count of the BGP4MP
   Type.

5.6.  OSPF Type

   This Type supports number of RIB entries which follow.

   The format for the OSPF Protocol as defined in RFC 2328
   [RFC2328]. RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
   RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.
   The Subtype Prefix Length and Prefix fields are encoded in the same manner as
   the BGP NLRI encoding for IPV4 and IPV6 prefixes.  Namely, the Prefix
   field may contain two possible values:

       0    OSPF_STATE_CHANGE
       1    OSPF_LSA_UPDATE

   The format contains address prefixes followed by enough trailing bits to
   make the end of the MRT Message field for fall on an octet boundary.  Note that the OSPF Type
   value of trailing bits is as follows: irrelevant.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Remote IP address                         Sequence number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local IP address Prefix Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  OSPF Message Contents                        Prefix (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.7.  TABLE_DUMP Type                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Entry Count           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TABLE_DUMP Type is used to encode the contents of a BGP Routing
   Information Base (RIB).  Each RIB entry RIB_GENERIC header is encoded in shown below.  It includes Address Family
   Identifier (AFI), Subsequent AFI and a distinct
   sequential MRT record. single NLRI entry.  The Subtype field NLRI
   information is used specific to encode whether the RIB entry contains IPv4 or IPv6 addresses.  There are two
   possible AFI and SAFI values.  An
   implementation which does not recognize particular AFI and SAFI
   values for SHOULD discard the Subtype as shown below.

       1    AFI_IPv4
       2    AFI_IPv6

   The format remainder of the TABLE_DUMP Type is illustrated below. MRT record.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           View #              |                         Sequence number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix (variable)    Address Family Identifier  |Subsequent AFI |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    Status     Network Layer Reachability Information (variable)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Originated Time         Entry Count           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RIB entry headers are followed by a series of RIB entries which
   are repeated Entry Count times.  These entries share a common format
   as shown below.  They include a Peer Index from the PEER_INDEX_TABLE
   MRT record, an originated time for the RIB entry, and the BGP path
   attribute length and attributes encoded as provided in a BGP Update
   message.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer IP address (variable) Index            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Peer AS                         Originated Time                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Attribute Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Attribute... Attributes... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The View field is normally 0 and is intended for cases where an
   implementation may have multiple RIB views (such as a route server).
   The Sequence field

   There is a simple incremental counter for each RIB
   entry.  A typical RIB dump will exceed one exception to the 16-bit bounds encoding of this
   counter and implementation should simply wrap back to zero and
   continue incrementing BGP attributes for the counter BGP
   MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760].  Since the
   AFI, SAFI, and NLRI information is already encoded in such cases.

   The Prefix field contains the IP address of a particular RIB entry.
   MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop
   Address fields are included.  The size of this Reserved field is dependent on omitted.  The
   attribute length is also adjusted to reflect only the value length of the Subtype for
   this message.  For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
   is 16 octets in length.  The Prefix
   Next Hop Address Length field indicates the length and Next Hop Address fields.

5.4.  BGP4MP Type

   This Type was initially defined in bits of the prefix mask Zebra software package for the preceding Prefix field.
   BGP protocol with multiprotocol extension support as defined by RFC
   4760 [RFC4760].  It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
   The Status octet BGP4MP Type has six Subtypes which are defined as follows:

       0    BGP4MP_STATE_CHANGE
       1    BGP4MP_MESSAGE
       4    BGP4MP_STATE_CHANGE_AS4
       5    BGP4MP_MESSAGE_AS4

5.4.1.  BGP4MP_STATE_CHANGE Subtype

   This record is not used to encode state changes in the TABLE_DUMP Type BGP finite state
   machine.  The BGP FSM states are encoded in the Old State and SHOULD be set New
   State fields to 1.

   The Originated Time contains indicate the 4-octet time at which this prefix
   was heard. previous and current state.  The value represents the time in seconds since format
   is illustrated below:

        0                   1 January
   1970 00:00:00 UTC.

   The                   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP field is the address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address of the peer which provided the
   update for this RIB entry.  As with (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Old State          |          New State            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2.
   Both the Prefix field, old state value and the size of
   this field is dependent on the Subtype.  AFI_IPv4 indicates a new state value are encoded as
   2-octet numbers.  The state values are defined numerically as
   follows:

       1    Idle
       2    Connect
       3    Active
       4 octet
   field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
   octet field    OpenSent
       5    OpenConfirm
       6    Established

   The BGP4MP_STATE_CHANGE message also includes interface index and an IPv6 address.
   Address Family fields.  The Peer AS field contains interface index provides the AS interface
   number of the peer.

   Attribute length peering session.  The index value is the length of Attribute field OPTIONAL and is 2-octets. MAY
   be zero if unknown or unsupported.  The Attribute field contains Address Family indicates what
   types of addresses are in the attribute information for the RIB
   entry.

5.8.  TABLE_DUMP_V2 Type

   The TABLE_DUMP_V2 Type updates address fields.  At present, the TABLE_DUMP Type
   following AFI Types are supported:

       1    AFI_IPv4
       2    AFI_IPv6

5.4.2.  BGP4MP_MESSAGE Subtype

   This Subtype is used to include 32BIT
   ASN support and full support for encode BGP Multiprotocol extensions. Messages.  It
   also improves upon the space efficiency can be used to
   encode any Type of BGP message.  In order to determine the TABLE_DUMP Type by
   employing an index table for peers BGP
   message Type, the entire BGP message is included in the BGP Message
   field.  This includes 16-octet marker, 2-ocet length, and permitting a single MRT record
   per NLRI entry. 1-octet
   type fields.  Note that the BGP4MP_MESSAGE Subtype does not support
   32BIT AS numbers.  The following subtypes are used with BGP4MP_MESSAGE_AS4 Subtype updates the
   TABLE_DUMP_V2 Type.

       1    PEER_INDEX_TABLE
       2    RIB_IPV4_UNICAST
       3    RIB_IPV4_MULTICAST
       4    RIB_IPV6_UNICAST
       5    RIB_IPV6_MULTICAST
       6    RIB_GENERIC

   An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
   collector, an optional view name, and a list of indexed peers.
   Following the PEER_INDEX_TABLE MRT record, a series of MRT records
   are used to encode RIB table entries.  This series of MRT records use
   subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record
   itself and include full MRT record headers.  The header of the
   PEER_INDEX_TABLE Subtype is shown below.  The View Name is optional
   and, if not present, the View Name Length MUST be set to 0.  The View
   Name encoding MUST follow the UTF-8 transformation format.

        0                   1                   2                   3
        0
   BGP4MP_MESSAGE Subtype in order to support these.  The BGP4MP_MESSAGE
   fields are shown below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Collector BGP ID                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       View Name Length         Peer AS number        |     View Name (variable)        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Peer Count           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the peer entries is shown below.  The PEER_INDEX_TABLE
   record contains Peer Count peer entries.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        Interface Index        |   Peer Type        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer BGP ID IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Peer                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Peer AS                    BGP Message... (variable)                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated
   as indicated by interface index provides the Peer Count field.  The position interface number of the Peer in
   the PEER_INDEX_TABLE is used as an index in the subsequent
   TABLE_DUMP_V2 MRT records. peering
   session.  The index number begins with 0.

   The Peer Type field value is a bit field which encodes the type OPTIONAL and MAY be zero if unknown or
   unsupported.  The Address Family indicates what types of addresses
   are in the AS
   and IP the subsequent address as follows:

      Bit 0 - unset for IPv4 Peer IP address, set for IPv6
      Bit fields.  At present, the following
   AFI Types are supported:

       1 - unset when Peer AS field is 16 bits, set when it's 32 bits

   The records which follow    AFI_IPv4
       2    AFI_IPv6

   Note that the PEER_INDEX_TABLE record constitute Address Family value only applies to the
   RIB entries and include a header which specifies a sequence number,
   NLRI, and a count of IP addresses
   contained in the number of RIB entries which follow. MRT header.  The format for BGP4MP_MESSAGE Subtype is otherwise
   transparent to the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
   RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.
   The Prefix Length and Prefix fields are contents of the actual message which may contain
   any valid AFI/SAFI values.  Only one BGP message may be encoded in
   the same manner as BGP4MP_MESSAGE Subtype.

5.4.3.  BGP4MP_STATE_CHANGE_AS4 Subtype

   This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT
   Autonomous System numbers.  As with the BGP4MP_STATE_CHANGE Subtype,
   the BGP NLRI encoding for IPV4 and IPV6 prefixes.  Namely, FSM states are encoded in the Prefix
   field contains address prefixes followed by enough trailing bits Old State and New State fields
   to
   make the end of indicate the field fall on an octet boundary.  Note that previous and current state.  Aside from the
   value extension
   of trailing bits the peer and local AS fields to 32 bits, this subtype is irrelevant. otherwise
   identical to the BGP4MP_STATE_CHANGE Subtype.  The
   BGP4MP_STATE_CHANGE_AS4 fields are shown below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Sequence                         Peer AS number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length                         Local AS number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Entry Count                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RIB_GENERIC header is shown below.  It includes Address Family
   Identifier (AFI), Subsequent AFI and a single NLRI entry.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Old State          |          New State            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.4.  BGP4MP_MESSAGE_AS4 Subtype

   This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
   Autonomous System numbers.  The NLRI
   information BGP4MP_MESSAGE_AS4 Subtype is specific
   otherwise identical to the AFI and SAFI values.  An
   implementation which does not recognize particular AFI and SAFI
   values SHOULD discard the remainder of the MRT record. BGP4MP_MESSAGE Subtype.  The
   BGP4MP_MESSAGE_AS4 fields are shown below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Sequence                         Peer AS number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local AS number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family Identifier  |Subsequent AFI         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Network Layer Reachability Information                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Entry Count                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RIB entry headers are followed by a series of RIB entries which
   are repeated Entry Count times.  These entries share a
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Message... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.5.  BGP4MP_ET Type

   This Type was initially defined in the Sprint Labs Python Routing
   Toolkit (PyRT).  It extends the MRT common format
   as shown below.  They header field to include a Peer Index from the PEER_INDEX_TABLE
   MRT record, an originated time
   32BIT microsecond timestamp field.  The type and subtype field
   definitions remain as defined for the RIB entry, and BGP4MP Type.  The 32BIT
   microsecond timestamp immediately follows the BGP path
   attribute length field in the MRT
   common header and attributes encoded as provided precedes all other fields in a BGP Update the message.

        0                   1                   2                   3
        0 1 2 3 4  The
   32BIT microsecond field is included in the computation of the length
   field value.  The MRT common header modification is illustrated
   below.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer Index                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Originated Time             Type              |            Subtype            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Attribute                             Length                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Attributes...                      microsecond timestamp                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Message... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.6.  ISIS Type

   This Type was initially defined in the Sprint Labs Python Routing and
   supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195].
   There is one exception to the encoding of BGP attributes no Type specific header for the BGP
   MP_REACH_NLRI attribute (BGP ISIS Type.  The Subtype code
   for this Type Code 14) [RFC 4760].  Since the
   AFI, SAFI, and NLRI information is already encoded in the
   MULTIPROTOCOL header, only undefined.  The ISIS PDU directly follows the Next Hop Address Length and Next Hop
   Address fields are included. MRT
   common header fields.

5.7.  ISIS_ET Type

   The Reserved ISIS_ET Type extends the ISIS Type to support microsecond
   timestamps.  As with the BGP4MP_ET Type, a 32BIT microsecond
   timestamp field is omitted.  The
   attribute length is also adjusted appended to reflect only the MRT common header after the length of
   field.  The ISIS_ET Type is otherwise identical to the
   Next Hop Address Length and Next Hop Address fields.

5.9.  BGP4MP ISIS Type.

5.8.  OSPFv3 Type

   This

   The OSPFv3 Type was initially defined in extends the Zebra software package original OSPF Type to support IPv6
   addresses for the
   BGP OSPFv3 protocol with multiprotocol extension support as defined by in RFC
   4760 [RFC4760].  It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 2740 [RFC2740].
   The BGP4MP format of the MRT Message field for the OSPFv3 Type has six Subtypes which are defined is as
   follows:

        0    BGP4MP_STATE_CHANGE
       1    BGP4MP_MESSAGE
       2    BGP4MP_ENTRY                  *DEPRECATED*
       3    BGP4MP_SNAPSHOT               *DEPRECATED*
       4    BGP4MP_STATE_CHANGE_AS4
       5    BGP4MP_MESSAGE_AS4

5.9.1.  BGP4MP_STATE_CHANGE Subtype

   This record is used to encode state changes in the BGP finite state
   machine.  As with the BGP_STATE_CHANGE Subtype, the BGP FSM states
   are encoded in the Old State and New State fields to indicate the
   previous and current state.  The format is illustrated below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer                     Remote IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Old State          |          New State            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   While BGP4MP_STATE_CHANGE message is similar to                  OSPF Message Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.9.  OSPFv3_ET Type

   The OSPFv3_ET Type extends the BGP_STATE_CHANGE
   message, it also includes interface index and Address Family fields. OSPFv3 Type to support microsecond
   timestamps.  As with the BGP_STATE_CHANGE message, BGP4MP_ET Type, a 32BIT microsecond
   timestamp field is appended to the FSM states are defined in
   RFC 4271 [RFC4271], Section 8.2.2 with MRT common header after the numeric values for these
   states defined inthe BGP_STATE_CHANGE section.  The interface index
   provides length
   field and its length is included in the interface number calculation of the peering session. length
   field value.  The index
   value OSPFv3_ET Type is OPTIONAL and MAY be zero if unknown or unsupported.  The
   Address Family indicates what types of addresses are in the the
   address fields.  At present, otherwise identical to the following AFI Types are supported:

       1    AFI_IPv4
       2    AFI_IPv6

5.9.2.  BGP4MP_MESSAGE Subtype OSPFv3
   Type.

6.  IANA Considerations

   This Subtype is used to encode BGP Messages.  It is similar section provides guidance to the
   BGP_UPDATE Subtype, except that is can be used to encode any Type Internet Assigned Numbers
   Authority (IANA) regarding registration of
   message (not simply BGP UPDATES).  In order values related to determine the BGP
   message Type, the entire BGP message is included MRT
   specification, in the BGP Message
   field.  This includes 16-octet marker, 2-ocet length, and 1-octet
   type fields.  Note accordance with BCP 26, RFC 2434 [RFC2434].

   There are two name spaces in MRT that the BGP4MP_MESSAGE Subtype does not support
   32BIT AS numbers nor IPv6 addresses.  The BGP4MP_MESSAGE_AS4 Subtype
   updates the BGP4MP_MESSAGE require registration: Type
   Codes and Subtype in order to support these.  The
   BGP4MP_MESSAGE fields are shown below:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Message... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The interface index provides the interface number of the peering
   session.  The index value Codes.

   MRT is OPTIONAL not intended as a general-purpose specification for protocol
   information export, and MAY allocations should not be zero if unknown or
   unsupported. made for purposes
   unrelated to routing protocol information export.

   The Address Family indicates what types of addresses
   are in the the subsequent address fields.  At present, the following
   AFI Types policies are supported:

       1    AFI_IPv4
       2    AFI_IPv6

   Note that the Address Family value only applies to used here with the IP addresses
   contained meanings defined in the MRT header.  The BGP4MP_MESSAGE Subtype is otherwise
   transparent to the contents of the actual message which may contain
   any valid AFI/SAFI values.  Only one BGP message may BCP
   26: "Specification Required", "IETF Consensus".

6.1.  Type Codes

   Type Codes have a range from 0 to 65535, of which 0-64 have been
   allocated.  New Type Codes MUST be encoded in allocated starting at 65.  Type
   Codes 65 - 32767 are to be assigned by IETF Consensus.  Type Codes
   32768 - 65535 are assigned based on Specification Required.

6.2.  Subtype Codes

   Subtype Codes have a range from 0 to 65535.  Subtype definitions are
   specific to a particular Type Code definition.  New Subtype Code
   definition must reference an existing Type Code to which the BGP4MP_MESSAGE Subtype.

5.9.3.  BGP4MP_ENTRY Subtype

   This
   belongs.  As Subtype is similar Codes are specific to Type Codes, new numbers
   must be unique for the TABLE_DUMP particular Type and is used Code to which the Subtype
   applies.  Subtype Codes specific to record
   RIB table entries.  It extends the TABLE_DUMP Type Codes 0 - 32767 are
   assigned by IETF Consensus.  Subtype Codes specific to include true
   multiprotocol support.  However, this Type does not support 32BIT AS
   numbers Codes
   32768 - 65535 are assigned based on Specification Required.

7.  Security Considerations

   The MRT Format utilizes a structure which can store routing protocol
   information data.  The fields defined in the MRT specification are of
   a descriptive nature and has not been widely implemented.  This Type provide information that is deprecated
   in favor useful to
   facilitate the analysis of routing data.  As such, the TABLE_DUMP_V2 which includes 32BIT AS number support
   and a more compact format.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           View #              |             Status            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Time last change                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         |    SAFI       | Next-Hop-Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Next Hop Address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Address Prefix (variable)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Attribute Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Attribute... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.9.4.  BGP4MP_SNAPSHOT Subtype

   This Subtype was intended to convey a system file name where
   BGP4MP_ENTRY messages should be recorded.  It is similar to the
   BGP_SYNC message Subtype and is deprecated.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        View #                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            File Name... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.9.5.  BGP4MP_STATE_CHANGE_AS4 Subtype

   This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT
   Autonomous System numbers.  As with the BGP4MP_STATE_CHANGE Subtype, fields
   currently defined in the BGP FSM states are encoded MRT specification do not in themselves
   create additional security risks, since the Old State and New State fields are not used to indicate the previous and current state.  Aside from
   induce any particular behavior by the extension recipient application.

8.  References

8.1.  Normative References

   [RFC1058]  Hedrick, C., "Routing Information Protocol", RFC 1058,
              June 1988.

   [RFC1195]  Callon, R., "Use of the peer and local AS fields OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to 32 bits, this subtype is otherwise
   identical Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

8.2.  Informative References

   [MRT PROG GUIDE]
              Labovitz, C., "MRT Programmer's Guide", November 1999,
              <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.

Appendix A.  Deprecated MRT types

   This Appendix lists deprecated MRT types.  These types are documented
   for informational purposes only.  While documented in some
   references, they are not known to the BGP4MP_STATE_CHANGE Subtype. have been generally implemented.

A.1.  Deprecated MRT Informational Types

   The
   BGP4MP_STATE_CHANGE_AS4 fields deprecated MRT Informational Types are shown defined below:

       0                   1                   2                   3
        0 1    NULL
       2 3 4 5 6 7 8 9 0 1 2 3    DIE
       4    PEER_DOWN

A.1.1.  NULL Type

   The NULL Type message causes no operation.

A.1.2.  DIE Type

   The DIE Type signals a remote MRT repository it should stop accepting
   messages.

A.1.3.  PEER_DOWN Type

   The PEER_DOWN message was intended to indicate that a collector had
   lost association with a BGP peer.  However, the MRT format provides
   BGP state change message types which duplicate this functionality.

A.2.  Deprecated MRT Routing Information Types

       5    BGP
       6    RIP
       7    IDRP
       8    RIPNG
       9    BGP4PLUS
       10   BGP4PLUS_01

A.2.1.  BGP Type

   The BGP Type indicates the Message field contains BGP routing
   information.  The BGP routing protocol is defined in RFC 4271
   [RFC4271].  The information in the message is dependent on the
   Subtype value.  The BGP Type and all associated Subtypes below are
   considered to be deprecated by the BGP4MP Type.

   The following BGP Subtypes are defined for the MRT BGP Type.  As with
   the BGP Type itself, they are all considered to be deprecated.

       0    BGP_NULL
       1    BGP_UPDATE
       2    BGP_PREF_UPDATE
       3    BGP_STATE_CHANGE
       4    BGP_SYNC
       5    BGP_OPEN
       6    BGP_NOTIFY
       7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Peer AS number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local AS number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Old State          |          New State            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.9.6.  BGP4MP_MESSAGE_AS4    BGP_KEEPALIVE

A.2.1.1.  BGP_NULL Subtype

   This

   The BGP_NULL Subtype updates the BGP4MP_MESSAGE is a reserved Subtype.

A.2.1.2.  BGP_UPDATE Subtype to support 32BIT
   Autonomous System numbers.

   The BGP4MP_MESSAGE_AS4 BGP_UPDATE Subtype is
   otherwise identical used to the BGP4MP_MESSAGE Subtype. encode BGP UPDATE messages.  The
   BGP4MP_MESSAGE_AS4 fields are shown below:
   format of the MRT Message field for this Subtype is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local AS number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Peer IP address (variable)                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Local IP address (variable)                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Message... UPDATE Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.10.  BGP4MP_ET Type

   This Type was initially defined in
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The BGP UPDATE Contents include the Sprint Labs Python Routing
   Toolkit (PyRT).  It extends entire BGP UPDATE message which
   follows the MRT common header field to include a
   32BIT microsecond timestamp field. BGP Message Header.  The type BGP Message Header itself is not
   included.  The Peer AS number and subtype field
   definitions remain as defined for IP address fields contain the BGP4MP Type.  The 32BIT
   microsecond timestamp immediately follows AS
   number and IP address of the length field in remote system which are generating the MRT
   common header
   BGP UPDATE messages.  The Local AS number and precedes all other IP address fields in
   contain the message. AS number and IP address of the local collector system
   which is archiving the messages.

A.2.1.3.  BGP_PREF_UPDATE Subtype

   The
   32BIT microsecond field BGP_PREF_UPDATE Subtype is included not defined.

A.2.1.4.  BGP_STATE_CHANGE Subtype

   The BGP_STATE_CHANGE Subtype is used to record changes in the computation of BGP
   finite state machine.  These FSM states are defined in RFC 4271
   [RFC4271], Section 8.2.2.  Both the length
   field value. old state value and the new state
   value are encoded as 2-octet numbers.  The state values are defined
   numerically as follows:

       1    Idle
       2    Connect
       3    Active
       4    OpenSent
       5    OpenConfirm
       6    Established

   The format of the MRT common header modification Message field is illustrated
   below. as follows:

        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         Peer AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |            Subtype                        Peer IP address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Length                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Old State          |                      microsecond timestamp          New State            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Message... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.11.  ISIS Type

   This Type

A.2.1.5.  BGP_SYNC Subtype

   The BGP_SYNC Subtype was initially defined in the Sprint Labs Python Routing and
   supports intended to convey a system file name where
   BGP Table Dump messages should be recorded.  The View # was to
   correspond to the IS-IS routing protocol as defined View # provided in RFC 1195 [RFC1195]. the TABLE_DUMP Type messages.
   There is are no Type specific header for the ISIS Type.  The Subtype code
   for known implementations of this Type is undefined.  The ISIS PDU directly follows the MRT
   common header fields.

5.12.  ISIS_ET Type

   The ISIS_ET Type extends the ISIS Type to support microsecond
   timestamps.  As with the BGP4MP_ET Type, a 32BIT microsecond
   timestamp field is appended to the MRT common header after the length
   field.  The ISIS_ET Type is otherwise identical to the ISIS Type.

5.13.  OSPFv3 Type

   The OSPFv3 Type extends the original OSPF Type to support IPv6
   addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. subtype and it SHOULD be
   ignored.  The following format of the MRT Message field for the OSPFv3 Type is as
   follows: applies to this Subtype:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Remote IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)        View #                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  OSPF Message Contents            File Name... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.14.  OSPFv3_ET Type
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond
   timestamps.  As File Name is terminated with the BGP4MP_ET Type, a 32BIT microsecond
   timestamp field NULL (0) character.

A.2.1.6.  BGP_OPEN Subtype

   The BGP_OPEN Subtype is appended used to encode BGP OPEN messages.  The format
   of the MRT common header after the length Message field and its length for this Subtype is included in the calculation of same as the length
   BGP_UPDATE, however, the last field value. contains the contents of the BGP
   OPEN message.

A.2.1.7.  BGP_NOTIFY Subtype

   The OSPFv3_ET Type BGP_NOTIFY Subtype is otherwise identical to the OSPFv3
   Type.

6.  IANA Considerations

   This section provides guidance used to the Internet Assigned Numbers
   Authority (IANA) regarding registration encode BGP NOTIFICATION messages.
   The format of values related to the MRT
   specification, in accordance with BCP 26, RFC 2434 [RFC2434].

   There are two name spaces in MRT that require registration: Type
   Codes and Message field for this Subtype Codes.

   MRT is not intended the same as a general-purpose specification for protocol
   information export, and allocations should not be made for purposes
   unrelated to routing protocol information export.

   The following policies are used here with
   the meanings defined in BCP
   26: "Specification Required", "IETF Consensus".

6.1.  Type Codes

   Type Codes have a range from 0 to 65535, BGP_UPDATE, however, the last field contains the contents of which 0-64 have been
   allocated.  New Type Codes MUST be allocated starting at 65.  Type
   Codes 65 - 32767 are to be assigned by IETF Consensus.  Type Codes
   32768 - 65535 are assigned based on Specification Required.

6.2. the
   BGP NOTIFICATION message.

A.2.1.8.  BGP_KEEPALIVE Subtype Codes

   The BGP_KEEPALIVE Subtype Codes have a range from 0 is used to 65535. encode BGP KEEPALIVE messages.
   The format of the MRT Message field for this Subtype definitions are
   specific to a particular is the same as
   the BGP_UPDATE, however, the last field contains no information.

A.2.2.  RIP Type Code definition.  New Subtype Code
   definition must reference an existing

   The RIP Type Code is used to which the Subtype
   belongs.  As export RIP protocol packets as defined in RFC
   1058 [RFC1058].  The Subtype Codes are specific to Type Codes, new numbers
   must be unique field is currently reserved for the particular this
   Type Code and SHOULD be set to which 0.

   The format of the Subtype
   applies.  Subtype Codes specific to MRT Message field for the RIP Type Codes is as follows:

        0 - 32767 are
   assigned by IETF Consensus.  Subtype Codes specific to Type Codes
   32768 - 65535 are assigned based on Specification Required.

7.  Security Considerations                   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Peer IP address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Local IP address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    RIP Message Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.3.  IDRP Type

   The MRT Format utilizes a structure which can store routing IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
   protocol information data.  The fields as defined in the MRT specification are of
   a descriptive nature and provide information that ISO/IEC 10747 standard.  The
   Subtype field is useful unused.  This Type is deprecated due to
   facilitate the analysis lack of routing data.  As such, the fields
   currently
   deployment of IDRP.

A.2.4.  RIPNG Type

   The RIPNG Type is used to export RIPNG protocol packets as defined in
   RFC 2080 [RFC2080].  The RIPNG protocol updates the MRT specification do not in themselves
   create additional security risks, since the fields are not used RIP protocol to
   induce any particular behavior by the recipient application.

8.  References

8.1.  Normative References

   [RFC1058]  Hedrick, C., "Routing Information Protocol", RFC 1058,
              June 1988.

   [RFC1195]  Callon, R., "Use of OSI IS-IS
   support IPv6.  The Subtype field is currently reserved for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2080]  Malkin, G. this Type
   and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs SHOULD be set to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2434]  Narten, T. 0.

   The format of the MRT Message field for the RIPNG Type is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                        Peer IPv6 address                      ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                        Local IPv6 address                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  RIPNG Message Contents (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.5.  BGP4PLUS and H. Alvestrand, "Guidelines BGP4PLUS_01 Types

   The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
   routing information.  The BGP4PLUS Type was specified based on the
   initial Internet Draft for Writing an
              IANA Considerations Section Multiprotocol Extensions to BGP-4.  The
   BGP4PLUS_01 Type was specified to correspond to the -01 revision of
   this Internet Draft.  The two Types share the same definitions in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2740]  Coltun, R., Ferguson, D.,
   terms of their MRT format specifications.

   The Subtype field definitions are shared with the BGP Type, however,
   the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
   BGP_KEEPALIVE, and J. Moy, "OSPF BGP_STATE_CHANGE Subtype messages are extended to
   16 octets for IPv6",
              RFC 2740, December 1999.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., IPv6 addresses.  As with the BGP Type, the BGP4PLUS and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

8.2.  Informative References

   [MRT PROG GUIDE]
              Labovitz, C., "MRT Programmer's Guide", November 1999,
              <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
   BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP
   Type.

A.2.6.  Deprecated BGP4MP Subtypes

   The following two subtypes of the BGP4MP Type are considered to be
   deprecated.

       2    BGP4MP_ENTRY
       3    BGP4MP_SNAPSHOT

A.2.6.1.  BGP4MP_ENTRY Subtype

   This Subtype is similar to the TABLE_DUMP Type and is used to record
   RIB table entries.  It extends the TABLE_DUMP Type to include true
   multiprotocol support.  However, this Type does not support 32BIT AS
   numbers and has not been widely implemented.  This Type is deprecated
   in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support
   and a more compact format.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Peer AS number        |        Local AS number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Interface Index        |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Peer IP address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Local IP address (variable)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           View #              |             Status            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Time last change                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Address Family         |    SAFI       | Next-Hop-Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Next Hop Address (variable)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Address Prefix (variable)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Attribute Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    BGP Attribute... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.6.2.  BGP4MP_SNAPSHOT Subtype

   This Subtype was intended to convey a system file name where
   BGP4MP_ENTRY messages should be recorded.  It is similar to the
   BGP_SYNC message Subtype and is deprecated.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        View #                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            File Name... (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authors' Addresses

   Larry Blunk
   Merit Network

   Email: ljb@merit.edu

   Manish Karir
   Merit Network

   Email: mkarir@merit.edu

   Craig Labovitz
   Arbor Networks

   Email: labovit@arbor.net

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).