Network Working Group L. Blunk
Internet-Draft M. Karir
Intended status: Standards Track Merit Network
Expires: January 14, 2010 C. Labovitz
Arbor Networks
July 13, 2009
MRT routing information export format
draft-ietf-grow-mrt-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Blunk, et al. Expires January 14, 2010 [Page 1]
Internet-Draft MRT Format July 2009
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.
Blunk, et al. Expires January 14, 2010 [Page 2]
Internet-Draft MRT Format July 2009
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6
4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9
5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14
5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15
5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15
5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16
5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17
5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17
5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17
5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22
A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22
A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22
A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22
A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22
A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22
A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22
A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25
A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25
A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25
A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26
A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Blunk, et al. Expires January 14, 2010 [Page 3]
Internet-Draft MRT Format July 2009
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].
Blunk, et al. Expires January 14, 2010 [Page 4]
Internet-Draft MRT Format July 2009
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.
A number of MRT message types have been documented in some references
but are not known to have been implemented. Further, several types
were employed in early MRT implementations, but are no longer
actively being used. These types are considered to be deprecated and
are documented in a separate appendix at the end of this document.
Some of the deprecated types may of interest to researchers examining
historical MRT archives.
Fields which contain multi-octet numeric values are encoded in
network octet order from most significant octet to least significant
octet. Fields which contain routing message fields are encoded in
the same order as they appear in the packet contents.
Blunk, et al. Expires January 14, 2010 [Page 5]
Internet-Draft MRT Format July 2009
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 octets within the message. The length field does not
include the length of the MRT common header.
Blunk, et al. Expires January 14, 2010 [Page 6]
Internet-Draft MRT Format July 2009
Message:
A variable length message. The contents of this field are
context dependent upon the Type and Subtype fields.
Blunk, et al. Expires January 14, 2010 [Page 7]
Internet-Draft MRT Format July 2009
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.
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 time reference is obtained from the Timestamp field in
the MRT message header.
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:
1 START
3 I_AM_DEAD
4.1. START Type
The START Type indicates a collector is about to begin generating MRT
messages.
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.
Blunk, et al. Expires January 14, 2010 [Page 8]
Internet-Draft MRT Format July 2009
5. MRT Routing Information Types
The following Types are currently defined for the MRT format. Types
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). 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. OSPF Type
This Type supports the OSPF Protocol as defined in RFC 2328
[RFC2328]. The Subtype field may contain two possible values:
0 OSPF_STATE_CHANGE
1 OSPF_LSA_UPDATE
The format of the MRT Message field for 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. TABLE_DUMP Type
The TABLE_DUMP Type is used to encode the contents of a BGP Routing
Information Base (RIB). Each RIB entry is encoded in a distinct
sequential MRT record. The Subtype field is used to encode whether
the RIB entry contains IPv4 or IPv6 addresses. There are two
possible values for the Subtype as shown below.
Blunk, et al. Expires January 14, 2010 [Page 9]
Internet-Draft MRT Format July 2009
1 AFI_IPv4
2 AFI_IPv6
The format of the TABLE_DUMP Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (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 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 counter in such cases.
The Prefix field contains the IP address of a particular RIB entry.
The size of this field is dependent on the value 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 Length field indicates the length
in bits of the prefix mask for the preceding Prefix field.
The Status octet is not used in the TABLE_DUMP Type and SHOULD be set
to 1.
The Originated Time contains the 4-octet time at which this prefix
was heard. The value represents the time in seconds since 1 January
1970 00:00:00 UTC.
The Peer IP field is the IP address of the peer which provided the
update for this RIB entry. As with the Prefix field, the size of
this field is dependent on the 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 AS
Blunk, et al. Expires January 14, 2010 [Page 10]
Internet-Draft MRT Format July 2009
number of the peer.
Attribute length is the length of Attribute field and is 2-octets.
The Attribute field contains the attribute information for the RIB
entry.
5.3. TABLE_DUMP_V2 Type
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 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 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 | View Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the peer entries is shown below. The PEER_INDEX_TABLE
record contains Peer Count peer entries.
Blunk, et al. Expires January 14, 2010 [Page 11]
Internet-Draft MRT Format July 2009
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 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated
as indicated by the Peer Count field. The position of the Peer in
the PEER_INDEX_TABLE is used as an index in the subsequent
TABLE_DUMP_V2 MRT records. The index number begins with 0.
The Peer Type field is a bit field which encodes the type of the AS
and IP address as follows:
Bit 0 - unset for IPv4 Peer IP address, set for IPv6
Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits
The records which follow the PEER_INDEX_TABLE record constitute the
RIB entries and include a header which specifies a sequence number,
NLRI, and a count of the number of RIB entries which follow.
The format for 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 encoded in the same manner as
the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix
field contains address prefixes followed by enough trailing bits to
make the end of the field fall on an octet boundary. Note that the
value of trailing bits is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RIB_GENERIC header is shown below. It includes Address Family
Blunk, et al. Expires January 14, 2010 [Page 12]
Internet-Draft MRT Format July 2009
Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI
information is specific 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.
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 number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier |Subsequent AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Layer Reachability Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attributes... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There is one exception to the encoding of BGP attributes for the BGP
MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the
AFI, SAFI, and NLRI information is already encoded in the
MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop
Address fields are included. The Reserved field is omitted. The
attribute length is also adjusted to reflect only the length of the
Next Hop Address Length and Next Hop Address fields.
5.4. BGP4MP Type
This Type was initially defined in the Zebra software package for the
BGP protocol with multiprotocol extension support as defined by RFC
Blunk, et al. Expires January 14, 2010 [Page 13]
Internet-Draft MRT Format July 2009
4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
The BGP4MP Type has six Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE
4 BGP4MP_MESSAGE_AS4
5 BGP4MP_STATE_CHANGE_AS4
5.4.1. BGP4MP_STATE_CHANGE Subtype
This record is used to encode state changes in the BGP finite state
machine. 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 IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2.
Both the 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 BGP4MP_STATE_CHANGE message also includes interface index and
Address Family fields. The interface index provides the interface
number of the peering session. The index value 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, the
following AFI Types are supported:
Blunk, et al. Expires January 14, 2010 [Page 14]
Internet-Draft MRT Format July 2009
1 AFI_IPv4
2 AFI_IPv6
5.4.2. BGP4MP_MESSAGE Subtype
This Subtype is used to encode BGP Messages. It can be used to
encode any Type of BGP message. In order to determine the BGP
message Type, the entire BGP message is included in the BGP Message
field. This includes the 16-octet marker, the 2-octet length, and
the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does
not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates
the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. 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 is OPTIONAL and MAY be zero if unknown or
unsupported. The Address Family indicates what types of addresses
are in the the subsequent address fields. At present, the following
AFI Types are supported:
1 AFI_IPv4
2 AFI_IPv6
Note that the Address Family value only applies to the IP addresses
contained 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 be encoded in
the BGP4MP_MESSAGE Subtype.
5.4.3. BGP4MP_MESSAGE_AS4 Subtype
This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
otherwise identical to the BGP4MP_MESSAGE Subtype. The
Blunk, et al. Expires January 14, 2010 [Page 15]
Internet-Draft MRT Format July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.4. 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 FSM states are encoded in the Old State and New State fields
to indicate the previous and current state. Aside from the extension
of the peer and local AS fields to 32 bits, this subtype is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Blunk, et al. Expires January 14, 2010 [Page 16]
Internet-Draft MRT Format July 2009
5.5. BGP4MP_ET Type
This Type was initially defined in the Sprint Labs Python Routing
Toolkit (PyRT). It extends the MRT common header field to include a
32BIT microsecond timestamp field. The type and subtype field
definitions remain as defined for the BGP4MP Type. The 32BIT
microsecond timestamp immediately follows the length field in the MRT
common header and precedes all other fields in the message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 no Type specific header for the ISIS Type. The Subtype code
for this Type is undefined. The ISIS PDU directly follows the MRT
common header fields.
5.7. 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.8. OSPFv3 Type
The OSPFv3 Type extends the original OSPF Type to support IPv6
addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340].
The format of the MRT Message field for the OSPFv3 Type is as
follows:
Blunk, et al. Expires January 14, 2010 [Page 17]
Internet-Draft MRT Format July 2009
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9. OSPFv3_ET Type
The OSPFv3_ET Type extends the OSPFv3 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 and its length is included in the calculation of the length
field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
Type.
Blunk, et al. Expires January 14, 2010 [Page 18]
Internet-Draft MRT Format July 2009
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the MRT
specification, in accordance with BCP 26, RFC 5226 [RFC5226].
There are two name spaces in MRT that require registration: Type
Codes and Subtype Codes.
MRT is not intended 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, 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. 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 Subtype
belongs. As Subtype Codes are specific to Type Codes, new numbers
must be unique for the particular Type Code to which the Subtype
applies. Subtype Codes specific to the Type Codes 0 - 32767 are
assigned by IETF Consensus. Subtype Codes specific to Type Codes
32768 - 65535 are assigned based on Specification Required.
Blunk, et al. Expires January 14, 2010 [Page 19]
Internet-Draft MRT Format July 2009
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 provide information that is useful to
facilitate the analysis of routing data. As such, the fields
currently defined in the MRT specification do not in themselves
create additional security risks, since the fields are not used to
induce any particular behavior by the recipient application.
Blunk, et al. Expires January 14, 2010 [Page 20]
Internet-Draft MRT Format July 2009
8. References
8.1. Normative References
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1195] Callon, R., "Use of 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 Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
8.2. Informative References
[MRT PROG GUIDE]
Labovitz, C., "MRT Programmer's Guide", November 1999,
<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
Blunk, et al. Expires January 14, 2010 [Page 21]
Internet-Draft MRT Format July 2009
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 have been generally implemented.
A.1. Deprecated MRT Informational Types
The deprecated MRT Informational Types are defined below:
0 NULL
2 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.
Blunk, et al. Expires January 14, 2010 [Page 22]
Internet-Draft MRT Format July 2009
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVE
A.2.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype.
A.2.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE Contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not
included. The Peer AS number and IP address fields contain the AS
number and IP address of the remote system which are generating the
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.
A.2.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined.
A.2.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states are defined in RFC 4271
Blunk, et al. Expires January 14, 2010 [Page 23]
Internet-Draft MRT Format July 2009
[RFC4271], Section 8.2.2. Both the 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 Message field 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 IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype was intended to convey a system file name where
BGP Table Dump messages should be recorded. The View # was to
correspond to the View # provided in the TABLE_DUMP Type messages.
There are no known implementations of this subtype and it SHOULD be
ignored. The following format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The File Name is terminated with a NULL (0) character.
A.2.1.6. BGP_OPEN Subtype
The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format
of the MRT Message field for this Subtype is the same as the
BGP_UPDATE, however, the last field contains the contents of the BGP
OPEN message.
Blunk, et al. Expires January 14, 2010 [Page 24]
Internet-Draft MRT Format July 2009
A.2.1.7. BGP_NOTIFY Subtype
The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages.
The format of the MRT Message field for this Subtype is the same as
the BGP_UPDATE, however, the last field contains the contents of the
BGP NOTIFICATION message.
A.2.1.8. BGP_KEEPALIVE Subtype
The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages.
The format of the MRT Message field for this Subtype is the same as
the BGP_UPDATE, however, the last field contains no information.
A.2.2. RIP Type
The RIP Type is used to export RIP protocol packets as defined in RFC
1058 [RFC1058]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0.
The format of the MRT Message field for the RIP 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 IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.3. IDRP Type
The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
protocol information as defined in the ISO/IEC 10747 standard. The
Subtype field is unused. This Type is deprecated due to lack of
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 RIP protocol to
support IPv6. The Subtype field is currently reserved for this Type
and SHOULD be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows:
Blunk, et al. Expires January 14, 2010 [Page 25]
Internet-Draft MRT Format July 2009
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 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 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
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 BGP_STATE_CHANGE Subtype messages are extended to
16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
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.
Blunk, et al. Expires January 14, 2010 [Page 26]
Internet-Draft MRT Format July 2009
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Blunk, et al. Expires January 14, 2010 [Page 27]
Internet-Draft MRT Format July 2009
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
Blunk, et al. Expires January 14, 2010 [Page 28]