--- 1/draft-ietf-grow-mrt-08.txt 2009-02-25 17:12:11.000000000 +0100 +++ 2/draft-ietf-grow-mrt-09.txt 2009-02-25 17:12:11.000000000 +0100 @@ -1,49 +1,54 @@ Network Working Group L. Blunk Internet-Draft M. Karir Intended status: Standards Track Merit Network -Expires: January 15, 2009 C. Labovitz +Expires: August 29, 2009 C. Labovitz Arbor Networks - July 14, 2008 + February 25, 2009 MRT routing information export format - draft-ietf-grow-mrt-08.txt + draft-ietf-grow-mrt-09.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. + 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 15, 2009. + This Internet-Draft will expire on August 29, 2009. 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 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 @@ -81,21 +86,20 @@ 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 - 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 @@ -108,24 +112,32 @@ 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. + 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -153,21 +165,21 @@ 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 + number of octets 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 @@ -175,21 +187,22 @@ 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. + 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 @@ -359,21 +372,21 @@ 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 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 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 @@ -490,25 +503,25 @@ following AFI Types are supported: 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 16-octet marker, 2-ocet length, and 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 these. The BGP4MP_MESSAGE - fields are shown below: + 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -618,21 +631,21 @@ 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 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -647,21 +660,21 @@ 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. 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 2434 [RFC2434]. + 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". @@ -705,34 +718,34 @@ 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. - [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. + [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, . Appendix A. Deprecated MRT types This Appendix lists deprecated MRT types. These types are documented for informational purposes only. While documented in some @@ -1022,55 +1035,10 @@ 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).