--- 1/draft-ietf-grow-mrt-04.txt 2007-11-17 01:12:07.000000000 +0100 +++ 2/draft-ietf-grow-mrt-05.txt 2007-11-17 01:12:07.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group L. Blunk Internet-Draft M. Karir Intended status: Standards Track Merit Network -Expires: September 6, 2007 C. Labovitz +Expires: May 19, 2008 C. Labovitz Arbor Networks - March 5, 2007 + November 16, 2007 MRT routing information export format - draft-ietf-grow-mrt-04.txt + draft-ietf-grow-mrt-05.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,21 +25,21 @@ 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 September 6, 2007. + This Internet-Draft will expire on May 19, 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 @@ -69,38 +69,39 @@ 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 . . . . . . . . . . . . . . . . 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_MESSAGE_AS4 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 22 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 22 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 22 - 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 22 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 - Intellectual Property and Copyright Statements . . . . . . . . . . 27 + 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 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 @@ -117,21 +118,21 @@ 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. 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 basic MRT format is illustrated below. + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -161,26 +162,25 @@ the header. Message: A variable length message. The contents of this field are context dependent on the Type and Subtype fields. 4. MRT Control Types The MRT format defines five Control Type messages. These messages - are using to relay the current state of MRT message source. The - message field MAY contain an OPTIONAL ASCII text string for - diagnostic purposes. These control messages are unidirectional in - nature and there is no form of an acknowledgment or response from the - receiver to the sender. The Subtype field is unused for these Types - and SHOULD be set to 0. + 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 Control Types are defined below: 0 NULL 1 START 2 DIE 3 I_AM_DEAD 4 PEER_DOWN 4.1. NULL Type @@ -196,32 +196,32 @@ 4.3. DIE Type A DIE Type signals that the receiver should shut down. 4.4. I_AM_DEAD Type A I_AM_DEAD indicates that the sender is shutting down. 4.5. PEER_DOWN Type - A PEER_DOWN is sent when the sender's peer is down. In practice, a - sender will likely have multiple peers. It is RECOMMENDED that the - sender use the Message field to convey the IP address of the peer - represented in US-ASCII. + 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. 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 - package. The ISIS Type was initially defined in the Sprint Labs - Python Routing Toolkit (PyRT). + package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially + defined in the Sprint Labs Python Routing Toolkit (PyRT). 5 BGP *DEPRECATED* 6 RIP 7 IDRP *DEPRECATED* 8 RIPNG 9 BGP4PLUS *DEPRECATED* 10 BGP4PLUS_01 *DEPRECATED* 11 OSPF 12 TABLE_DUMP 13 TABLE_DUMP_V2 @@ -414,22 +414,22 @@ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.7. 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 currently - two possible values for the Subtype as shown below. + the RIB entry contains IPv4 or IPv6 addresses. There are two + possible values for the Subtype as shown below. 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 | @@ -481,77 +481,82 @@ 5.8. TABLE_DUMP_V2 Type 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 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 INDEX_TABLE + 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 INDEX_TABLE MRT record provides the BGP ID of the + 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 INDEX_TABLE MRT record, a series of MRT records are - used to encode RIB table entries. The header of the INDEX_TABLE - Subtype is shown below. The View Name is optional and if not - present, the View Name Length MUST be set to 0. + Following the PEER_INDEX_TABLE MRT record, a series of MRT records + are used to encode RIB table entries. 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 Peer Type field is a bit field which encodes the type of the AS - and IP address as follows: + The format of the peer entries is shown below. The PEER_INDEX_TABLE + record contains Peer Count peer entries. - Bit 0 - unset for IPv4 Peer IP address, set of IPv6 - Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits 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 INDEX_TABLE is used as an index in the subsequent TABLE_DUMP_V2 - MRT records. The index number begins with 0. + the PEER_INDEX_TABLE is used as an index in the subsequent + TABLE_DUMP_V2 MRT records. The index number begins with 0. - The records which follow the INDEX_TABLE record constitute the RIB - entries and include a header which specify a sequence number, NLRI, - and a count of the number of RIB entries which follow. + The Peer Type field is a bit field which encodes the type of the AS + and IP address as follows: - 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. + 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 + + 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -571,22 +576,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 INDEX_TABLE MRT - record, an originated time for the RIB entry, and the BGP path + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -733,21 +738,47 @@ the same fields. 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_MESSAGE_AS4 Subtype +5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype + + This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT + Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, + 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 source and destination 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface Index | Address Family | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old State | New State | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5.9.6. BGP4MP_MESSAGE_AS4 Subtype This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -758,26 +789,28 @@ | Source IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.10. BGP4MP_ET This Type was initially defined in the Sprint Labs Python Routing - Toolkit (PyRT). It extends the header field of the BGP4MP Type to - include a 32-bit microsecond timestamp field. The Subtypes and other - field definitions remain as defined for the BGP4MP Type. The 32-bit - microsecond timestamp immediately follows the length field in the - BGP4MP Type and precedes all other fields in the message. The header - modification is illustrated below. + Toolkit (PyRT). It extends the MRT common header field to include a + 32-bit microsecond timestamp field. The type and subtype field + definitions remain as defined for the BGP4MP Type. The 32-bit + microsecond timestamp immediately follows the length field in the MRT + common header and precedes all other fields in the message. The 32- + bit 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -818,21 +851,23 @@ | Destination IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.14. OSPFv3_ET Type The OSPFv3_ET Type extends the the OSPFv3 Type to support microsecond timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond timestamp field is appended to the MRT common header after the length - field. The OSPFv3_ET Type is otherwise identical to the OSPFv3 Type. + 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]. There are two name spaces in MRT that require registration: Type Codes and Subtype Codes. @@ -851,21 +886,21 @@ 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. Suptype Codes specific to Type Codes + assigned by IETF Consensus. Subtype Codes specific to Type Codes 32768 - 65535 are assigned based on Specification Required. 7. Security Considerations The MRT Format utilizes a structure which can store routing protocol information data. The fields defined in the MRT specification are of a descriptive nature and 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 @@ -900,21 +935,21 @@ Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 8.2. Informative References [MRT PROG GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999, - . + . Authors' Addresses Larry Blunk Merit Network Email: ljb@merit.edu Manish Karir Merit Network