draft-ietf-grow-mrt-08.txt   draft-ietf-grow-mrt-09.txt 
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft M. Karir Internet-Draft M. Karir
Intended status: Standards Track Merit Network Intended status: Standards Track Merit Network
Expires: January 15, 2009 C. Labovitz Expires: August 29, 2009 C. Labovitz
Arbor Networks Arbor Networks
July 14, 2008 February 25, 2009
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-08.txt draft-ietf-grow-mrt-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on August 29, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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.
Abstract Abstract
This document describes the MRT format for routing information This document describes the MRT format for routing information
export. This format was developed in concert with the Multi-threaded export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state format can be used to export routing protocol messages, state
changes, and routing information base contents. changes, and routing information base contents.
Table of Contents Table of Contents
skipping to change at page 3, line 47 skipping to change at page 4, line 4
A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22
A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22
A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22
A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22
A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25
A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25
A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25
A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26
A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Researchers and engineers often wish to analyze network behavior by Researchers and engineers often wish to analyze network behavior by
skipping to change at page 5, line 24 skipping to change at page 5, line 24
format was initially defined in the MRT Programmer's Guide [MRT PROG format was initially defined in the MRT Programmer's Guide [MRT PROG
GUIDE]. GUIDE].
This memo serves to document the MRT format as currently implemented This memo serves to document the MRT format as currently implemented
in publicly available software. The format has been extended since in publicly available software. The format has been extended since
it's original introduction in the MRT toolset and these extensions it's original introduction in the MRT toolset and these extensions
are also included in this memo. Further extensions may be introduced are also included in this memo. Further extensions may be introduced
at a later date through additional definitions of the MRT Type field at a later date through additional definitions of the MRT Type field
and Subtype fields. and Subtype fields.
Fields which contain multi-byte numeric values are encoded in network A number of MRT message types have been documented in some references
byte order from most significant byte to least significant byte. but are not known to have been implemented. Further, several types
Fields which contain routing message fields are encoded in the same were employed in early MRT implementations, but are no longer
order as they appear in the packet contents. 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.
3. Basic MRT Format 3. Basic MRT Format
All MRT format messages have a common header which includes a All MRT format messages have a common header which includes a
timestamp, Type, Subtype, and length field. The header is followed timestamp, Type, Subtype, and length field. The header is followed
by a message field. The MRT common header is illustrated below. by a message field. The MRT common header is illustrated below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 45 skipping to change at page 6, line 45
information. information.
Subtype: Subtype:
A 2-octet field that is used to further distinguish message A 2-octet field that is used to further distinguish message
information within a particular message Type. information within a particular message Type.
Length: Length:
A 4-octet message length field. The length field contains the A 4-octet message length field. The length field contains the
number of bytes within the message. The length field does not number of octets within the message. The length field does not
include the length of the MRT common header. include the length of the MRT common header.
Message: Message:
A variable length message. The contents of this field are A variable length message. The contents of this field are
context dependent upon the Type and Subtype fields. context dependent upon the Type and Subtype fields.
4. MRT Informational Types 4. MRT Informational Types
The MRT format defines five Informational Type messages. These The MRT format defines five Informational Type messages. These
skipping to change at page 8, line 19 skipping to change at page 8, line 19
and do not contain routing information. These messages are OPTIONAL and do not contain routing information. These messages are OPTIONAL
and were largely intended for use when MRT messages are sent over a and were largely intended for use when MRT messages are sent over a
network to a remote repository store. However, MRT message network to a remote repository store. However, MRT message
repository stores have traditionally resided on the same device as repository stores have traditionally resided on the same device as
the collector and these Informational Types have seen limited the collector and these Informational Types have seen limited
implementation. Further, transport mechanisms for MRT messages are implementation. Further, transport mechanisms for MRT messages are
considered to be outside the scope of this document. considered to be outside the scope of this document.
The START and I_AM_DEAD messages MAY be used to provide a time The START and I_AM_DEAD messages MAY be used to provide a time
reference when a data collector begins and ends the collection reference when a data collector begins and ends the collection
process. 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 The message field MAY contain an OPTIONAL message string for
diagnostic purposes. The message string encoding MUST follow the diagnostic purposes. The message string encoding MUST follow the
UTF-8 transformation format. The Subtype field is unused for these UTF-8 transformation format. The Subtype field is unused for these
Types and SHOULD be set to 0. Types and SHOULD be set to 0.
The MRT Informational Types are defined below: The MRT Informational Types are defined below:
1 START 1 START
3 I_AM_DEAD 3 I_AM_DEAD
skipping to change at page 12, line 26 skipping to change at page 12, line 26
The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 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 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 the PEER_INDEX_TABLE is used as an index in the subsequent
TABLE_DUMP_V2 MRT records. The index number begins with 0. 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 The Peer Type field is a bit field which encodes the type of the AS
and IP address as follows: and IP address as follows:
Bit 0 - unset for IPv4 Peer IP address, set for IPv6 Bit 0 - unset for IPv4 Peer IP address, set for IPv6
Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits 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 The records which follow the PEER_INDEX_TABLE record constitute the
RIB entries and include a header which specifies a sequence number, RIB entries and include a header which specifies a sequence number,
NLRI, and a count of the number of RIB entries which follow. NLRI, and a count of the number of RIB entries which follow.
The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 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 Prefix Length and Prefix fields are encoded in the same manner as
the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix
field contains address prefixes followed by enough trailing bits to field contains address prefixes followed by enough trailing bits to
skipping to change at page 15, line 13 skipping to change at page 15, line 13
following AFI Types are supported: following AFI Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
5.4.2. BGP4MP_MESSAGE Subtype 5.4.2. BGP4MP_MESSAGE Subtype
This Subtype is used to encode BGP Messages. It can be used to 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 encode any Type of BGP message. In order to determine the BGP
message Type, the entire BGP message is included in the BGP Message message Type, the entire BGP message is included in the BGP Message
field. This includes 16-octet marker, 2-ocet length, and 1-octet field. This includes the 16-octet marker, the 2-octet length, and
type fields. Note that the BGP4MP_MESSAGE Subtype does not support the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does
32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates
BGP4MP_MESSAGE Subtype in order to support these. The BGP4MP_MESSAGE the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The
fields are shown below: BGP4MP_MESSAGE fields are shown below:
0 1 2 3 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 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 | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 49 skipping to change at page 17, line 49
5.7. ISIS_ET Type 5.7. ISIS_ET Type
The ISIS_ET Type extends the ISIS Type to support microsecond The ISIS_ET Type extends the ISIS Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
timestamp field is appended to the MRT common header after the length timestamp field is appended to the MRT common header after the length
field. The ISIS_ET Type is otherwise identical to the ISIS Type. field. The ISIS_ET Type is otherwise identical to the ISIS Type.
5.8. OSPFv3 Type 5.8. OSPFv3 Type
The OSPFv3 Type extends the original OSPF Type to support IPv6 The OSPFv3 Type extends the original OSPF Type to support IPv6
addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340].
The format of the MRT Message field for the OSPFv3 Type is as The format of the MRT Message field for the OSPFv3 Type is as
follows: follows:
0 1 2 3 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 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 | | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address (variable) | | Remote IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 9 skipping to change at page 19, line 9
timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
timestamp field is appended to the MRT common header after the length 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 and its length is included in the calculation of the length
field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
Type. Type.
6. IANA Considerations 6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the MRT Authority (IANA) regarding registration of values related to the MRT
specification, in accordance with BCP 26, RFC 2434 [RFC2434]. specification, in accordance with BCP 26, RFC 5226 [RFC5226].
There are two name spaces in MRT that require registration: Type There are two name spaces in MRT that require registration: Type
Codes and Subtype Codes. Codes and Subtype Codes.
MRT is not intended as a general-purpose specification for protocol MRT is not intended as a general-purpose specification for protocol
information export, and allocations should not be made for purposes information export, and allocations should not be made for purposes
unrelated to routing protocol information export. unrelated to routing protocol information export.
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Specification Required", "IETF Consensus". 26: "Specification Required", "IETF Consensus".
skipping to change at page 21, line 23 skipping to change at page 21, line 23
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [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 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. 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 8.2. Informative References
[MRT PROG GUIDE] [MRT PROG GUIDE]
Labovitz, C., "MRT Programmer's Guide", November 1999, Labovitz, C., "MRT Programmer's Guide", November 1999,
<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
Appendix A. Deprecated MRT types Appendix A. Deprecated MRT types
This Appendix lists deprecated MRT types. These types are documented This Appendix lists deprecated MRT types. These types are documented
for informational purposes only. While documented in some for informational purposes only. While documented in some
skipping to change at page 29, line 4 skipping to change at line 1045
Manish Karir Manish Karir
Merit Network Merit Network
Email: mkarir@merit.edu Email: mkarir@merit.edu
Craig Labovitz Craig Labovitz
Arbor Networks Arbor Networks
Email: labovit@arbor.net 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).
 End of changes. 17 change blocks. 
31 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/