--- 1/draft-ietf-grow-mrt-05.txt 2007-11-19 16:16:53.000000000 +0100 +++ 2/draft-ietf-grow-mrt-06.txt 2007-11-19 16:16:53.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group L. Blunk Internet-Draft M. Karir Intended status: Standards Track Merit Network -Expires: May 19, 2008 C. Labovitz +Expires: May 22, 2008 C. Labovitz Arbor Networks - November 16, 2007 + November 19, 2007 MRT routing information export format - draft-ietf-grow-mrt-05.txt + draft-ietf-grow-mrt-06.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 @@ -25,83 +25,83 @@ 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 May 19, 2008. + This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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 Control Types . . . . . . . . . . . . . . . . . . . . . . 8 + 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 - 4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 8 - 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 - 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 9 - 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 10 - 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 10 - 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 10 - 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 11 - 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 11 - 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 11 - 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 11 - 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 12 - 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 13 - 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 15 - 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 18 - 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 19 - 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 19 - 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 20 - 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 20 - 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 21 - 5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 21 - 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 22 - 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 22 - 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 22 - 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 23 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 24 - 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 24 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 - Intellectual Property and Copyright Statements . . . . . . . . . . 28 + 4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 9 + 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10 + 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10 + 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11 + 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11 + 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11 + 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12 + 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12 + 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12 + 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12 + 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13 + 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14 + 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14 + 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16 + 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19 + 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20 + 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20 + 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21 + 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 21 + 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22 + 5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23 + 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23 + 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23 + 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 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 @@ -141,85 +141,102 @@ 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 1 through 5 are used for - MRT control information while Types 6 and higher are used for - routing 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 message Subtype field + 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 does not include - the header. + 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 on the Type and Subtype fields. + context dependent upon the Type and Subtype fields. -4. MRT Control Types +4. MRT Informational Types - The MRT format defines five Control Type messages. These messages - are OPTIONAL and MAY be used to communicate the state of the MRT - message source and it's peering sessions. 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 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 MRT Control Types are defined below: + Two of these messages are considered potentially useful in + implementations with a local repository. In particular, 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. - 0 NULL + 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 + 2 DIE *DEPRECATED* 3 I_AM_DEAD - 4 PEER_DOWN + 4 PEER_DOWN *DEPRECATED* 4.1. NULL Type - The NULL Type message causes no operation, A sender may wish to send - these for synchronization or keep-alive purposes. + The NULL Type message causes no operation and is deprecated. 4.2. START Type - The START Type indicates a sender is about to begin sending MRT - messages + The START Type indicates a collector is about to begin generating MRT + messages. 4.3. DIE Type - A DIE Type signals that the receiver should shut down. + The DIE Type signals a remote MRT repository it should stop accepting + messages. This Type is deprecated. 4.4. I_AM_DEAD Type - A I_AM_DEAD indicates that the sender is shutting down. + An I_AM_DEAD MRT message indicates that a collector has shut down and + has stopped generating MRT messages. 4.5. PEER_DOWN Type - A PEER_DOWN indicates when one of the sender's peers is down. In - practice, a sender will likely have multiple peers. The sender - SHOULD use the Message field to convey the IP address of the peer - represented in UTF-8. + 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 were defined in the initial MRT Toolkit package. The BGP4MP - Type, number 16, was initially defined in the Zebra routing software + 5-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 @@ -239,21 +256,21 @@ [RFC4271]. 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. 0 BGP_NULL 1 BGP_UPDATE 2 BGP_PREF_UPDATE 3 BGP_STATE_CHANGE - 4 BGP_SYNC + 4 BGP_SYNC *DEPRECATED* 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 @@ -295,23 +312,24 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.5. BGP_SYNC Subtype - The BGP_SYNC Subtype is used to indicate a File Name where BGP Table - Dump messages should be recorded. The View # corresponds to the View - # provided in the TABLE_DUMP Type messages. The following format + 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. + This Type is considered to be deprecated. 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) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -474,26 +492,26 @@ 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 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.8. TABLE_DUMP_V2 Type - The TABLE_DUMP_V2 type updates the TABLE_DUMP type to include 32-bit + The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32-bit ASN support and full support for BGP Multiprotocol extensions. It - also improves upon the space efficiency of the TABLE_DUMP type by + 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. + 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. @@ -611,21 +629,21 @@ 5.9. BGP4MP Type This Type was initially defined in the Zebra software package for the BGP protocol with multiprotocol extension support as defined by RFC 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The BGP4MP Type has four Subtypes which are defined as follows: 0 BGP4MP_STATE_CHANGE 1 BGP4MP_MESSAGE 2 BGP4MP_ENTRY *DEPRECATED* - 3 BGP4MP_SNAPSHOT + 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: @@ -691,22 +709,22 @@ 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.9.3. 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 32-bit AS - numbers and has not been widely implemented. This type is deprecated + multiprotocol support. However, this Type does not support 32-bit AS + numbers and has not been widely implemented. This Type is deprecated in favor of the TABLE_DUMP_V2 which includes 32-bit 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -726,23 +744,23 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attribute... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.9.4. BGP4MP_SNAPSHOT Subtype - This Subtype is used to indicate a filename containing BGP4MP_ENTRY - records. It is similar to the BGP_SYNC message Subtype and shares - the same fields. + 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