draft-ietf-grow-mrt-04.txt   draft-ietf-grow-mrt-05.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: September 6, 2007 C. Labovitz Expires: May 19, 2008 C. Labovitz
Arbor Networks Arbor Networks
March 5, 2007 November 16, 2007
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-04.txt draft-ietf-grow-mrt-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 6, 2007. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 11 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 11
5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 12 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 12
5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 13 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 13
5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 15 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 15
5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 17 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 17
5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 18 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.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 19
5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 20 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.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 21
5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 21 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 22
5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 22 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 22
5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 22 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 22
5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 22 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
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 6, line 9 skipping to change at page 6, line 9
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.
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 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 8 skipping to change at page 8, line 8
the header. the 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 on the Type and Subtype fields. context dependent on the Type and Subtype fields.
4. MRT Control Types 4. MRT Control Types
The MRT format defines five Control Type messages. These messages The MRT format defines five Control Type messages. These messages
are using to relay the current state of MRT message source. The are OPTIONAL and MAY be used to communicate the state of the MRT
message field MAY contain an OPTIONAL ASCII text string for message source and it's peering sessions. The message field MAY
diagnostic purposes. These control messages are unidirectional in contain an OPTIONAL message string for diagnostic purposes. The
nature and there is no form of an acknowledgment or response from the message string encoding MUST follow the UTF-8 transformation format.
receiver to the sender. The Subtype field is unused for these Types The Subtype field is unused for these Types and SHOULD be set to 0.
and SHOULD be set to 0.
The MRT Control Types are defined below: The MRT Control Types are defined below:
0 NULL 0 NULL
1 START 1 START
2 DIE 2 DIE
3 I_AM_DEAD 3 I_AM_DEAD
4 PEER_DOWN 4 PEER_DOWN
4.1. NULL Type 4.1. NULL Type
skipping to change at page 8, line 43 skipping to change at page 8, line 42
4.3. DIE Type 4.3. DIE Type
A DIE Type signals that the receiver should shut down. A DIE Type signals that the receiver should shut down.
4.4. I_AM_DEAD Type 4.4. I_AM_DEAD Type
A I_AM_DEAD indicates that the sender is shutting down. A I_AM_DEAD indicates that the sender is shutting down.
4.5. PEER_DOWN Type 4.5. PEER_DOWN Type
A PEER_DOWN is sent when the sender's peer is down. In practice, a A PEER_DOWN indicates when one of the sender's peers is down. In
sender will likely have multiple peers. It is RECOMMENDED that the practice, a sender will likely have multiple peers. The sender
sender use the Message field to convey the IP address of the peer SHOULD use the Message field to convey the IP address of the peer
represented in US-ASCII. represented in UTF-8.
5. MRT Routing Information Types 5. MRT Routing Information Types
The following Types are currently defined for the MRT format. Types The following Types are currently defined for the MRT format. Types
5-12 were defined in the initial MRT Toolkit package. The BGP4MP 5-12 were defined in the initial MRT Toolkit package. The BGP4MP
Type, number 16, was initially defined in the Zebra routing software Type, number 16, was initially defined in the Zebra routing software
package. The ISIS Type was initially defined in the Sprint Labs package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
Python Routing Toolkit (PyRT). defined in the Sprint Labs Python Routing Toolkit (PyRT).
5 BGP *DEPRECATED* 5 BGP *DEPRECATED*
6 RIP 6 RIP
7 IDRP *DEPRECATED* 7 IDRP *DEPRECATED*
8 RIPNG 8 RIPNG
9 BGP4PLUS *DEPRECATED* 9 BGP4PLUS *DEPRECATED*
10 BGP4PLUS_01 *DEPRECATED* 10 BGP4PLUS_01 *DEPRECATED*
11 OSPF 11 OSPF
12 TABLE_DUMP 12 TABLE_DUMP
13 TABLE_DUMP_V2 13 TABLE_DUMP_V2
skipping to change at page 13, line 32 skipping to change at page 13, line 32
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. TABLE_DUMP Type 5.7. TABLE_DUMP Type
The TABLE_DUMP Type is used to encode the contents of a BGP Routing 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 Information Base (RIB). Each RIB entry is encoded in a distinct
sequential MRT record. The Subtype field is used to encode whether sequential MRT record. The Subtype field is used to encode whether
the RIB entry contains IPv4 or IPv6 addresses. There are currently the RIB entry contains IPv4 or IPv6 addresses. There are two
two possible values for the Subtype as shown below. possible values for the Subtype as shown below.
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
The format of the TABLE_DUMP Type is illustrated below. The format of the TABLE_DUMP Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Sequence number | | View # | Sequence number |
skipping to change at page 15, line 15 skipping to change at page 15, line 15
5.8. TABLE_DUMP_V2 Type 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 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 employing an index table for peers and permitting a single MRT record
per NLRI entry. The following subtypes are used with the per NLRI entry. The following subtypes are used with the
TABLE_DUMP_V2 type. TABLE_DUMP_V2 type.
1 INDEX_TABLE 1 PEER_INDEX_TABLE
2 RIB_IPV4_UNICAST 2 RIB_IPV4_UNICAST
3 RIB_IPV4_MULTICAST 3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST 4 RIB_IPV6_UNICAST
5 RIB_IPV6_MULTICAST 5 RIB_IPV6_MULTICAST
6 RIB_GENERIC 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. collector, an optional view name, and a list of indexed peers.
Following the INDEX_TABLE MRT record, a series of MRT records are Following the PEER_INDEX_TABLE MRT record, a series of MRT records
used to encode RIB table entries. The header of the INDEX_TABLE are used to encode RIB table entries. The header of the
Subtype is shown below. The View Name is optional and if not PEER_INDEX_TABLE Subtype is shown below. The View Name is optional
present, the View Name Length MUST be set to 0. 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID | | Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length | View Name (variable) | | View Name Length | View Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | | Peer Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Peer Type field is a bit field which encodes the type of the AS The format of the peer entries is shown below. The PEER_INDEX_TABLE
and IP address as follows: 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
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 Type | | Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS (variable) | | Peer AS (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 INDEX_TABLE is used as an index in the subsequent TABLE_DUMP_V2 the PEER_INDEX_TABLE is used as an index in the subsequent
MRT records. The index number begins with 0. TABLE_DUMP_V2 MRT records. The index number begins with 0.
The records which follow the INDEX_TABLE record constitute the RIB The Peer Type field is a bit field which encodes the type of the AS
entries and include a header which specify a sequence number, NLRI, and IP address as follows:
and a count of the number of RIB entries which follow.
The RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and Bit 0 - unset for IPv4 Peer IP address, set for IPv6
RIB_IPV6_MULTICAST headers are shown below. The Prefix Length and Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits
Prefix fields are encoded in the same manner as the BGP NLRI encoding
for IPV4 and IPV6 prefixes. Namely, the Prefix field contains The records which follow the PEER_INDEX_TABLE record constitute the
address prefixes followed by enough trailing bits to make the end of RIB entries and include a header which specifies a sequence number,
the field fall on an octet boundary. Note that the value of trailing NLRI, and a count of the number of RIB entries which follow.
bits is irrelevant.
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) | | Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 19 skipping to change at page 17, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier |Subsequent AFI | | Address Family Identifier |Subsequent AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Layer Reachability Information (variable) | | Network Layer Reachability Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | | Entry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RIB entry headers are followed by a series of RIB entries which The RIB entry headers are followed by a series of RIB entries which
are repeated Entry Count times. These entries share a common format are repeated Entry Count times. These entries share a common format
as shown below. They include a Peer Index from the INDEX_TABLE MRT as shown below. They include a Peer Index from the PEER_INDEX_TABLE
record, an originated time for the RIB entry, and the BGP path MRT record, an originated time for the RIB entry, and the BGP path
attribute length and attributes encoded as provided in a BGP Update attribute length and attributes encoded as provided in a BGP Update
message. message.
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 Index | | Peer Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time | | Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 47 skipping to change at page 20, line 47
the same fields. the same fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | | View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | 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 This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown
below: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 24 skipping to change at page 21, line 49
| Source IP address (variable) | | Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.10. BGP4MP_ET 5.10. BGP4MP_ET
This Type was initially defined in the Sprint Labs Python Routing This Type was initially defined in the Sprint Labs Python Routing
Toolkit (PyRT). It extends the header field of the BGP4MP Type to Toolkit (PyRT). It extends the MRT common header field to include a
include a 32-bit microsecond timestamp field. The Subtypes and other 32-bit microsecond timestamp field. The type and subtype field
field definitions remain as defined for the BGP4MP Type. The 32-bit definitions remain as defined for the BGP4MP Type. The 32-bit
microsecond timestamp immediately follows the length field in the microsecond timestamp immediately follows the length field in the MRT
BGP4MP Type and precedes all other fields in the message. The header common header and precedes all other fields in the message. The 32-
modification is illustrated below. 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 36 skipping to change at page 23, line 22
| Destination IP address (variable) | | Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.14. OSPFv3_ET Type 5.14. OSPFv3_ET Type
The OSPFv3_ET Type extends the the OSPFv3 Type to support microsecond The OSPFv3_ET Type extends the the OSPFv3 Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond timestamps. As with the BGP4MP_ET Type, a 32-bit 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 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 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 2434 [RFC2434].
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.
skipping to change at page 23, line 36 skipping to change at page 24, line 36
32768 - 65535 are assigned based on Specification Required. 32768 - 65535 are assigned based on Specification Required.
6.2. Subtype Codes 6.2. Subtype Codes
Subtype Codes have a range from 0 to 65535. Subtype definitions are Subtype Codes have a range from 0 to 65535. Subtype definitions are
specific to a particular Type Code definition. New Subtype Code specific to a particular Type Code definition. New Subtype Code
definition must reference an existing Type Code to which the Subtype definition must reference an existing Type Code to which the Subtype
belongs. As Subtype Codes are specific to Type Codes, new numbers belongs. As Subtype Codes are specific to Type Codes, new numbers
must be unique for the particular Type Code to which the Subtype must be unique for the particular Type Code to which the Subtype
applies. Subtype Codes specific to the Type Codes 0 - 32767 are 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. 32768 - 65535 are assigned based on Specification Required.
7. Security Considerations 7. Security Considerations
The MRT Format utilizes a structure which can store routing protocol The MRT Format utilizes a structure which can store routing protocol
information data. The fields defined in the MRT specification are of information data. The fields defined in the MRT specification are of
a descriptive nature and provide information that is useful to a descriptive nature and provide information that is useful to
facilitate the analysis of routing data. As such, the fields facilitate the analysis of routing data. As such, the fields
currently defined in the MRT specification do not in themselves currently defined in the MRT specification do not in themselves
create additional security risks, since the fields are not used to create additional security risks, since the fields are not used to
skipping to change at page 25, line 41 skipping to change at page 26, line 41
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.
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/nrd/resources/mrtprogrammer.pdf>. <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
Authors' Addresses Authors' Addresses
Larry Blunk Larry Blunk
Merit Network Merit Network
Email: ljb@merit.edu Email: ljb@merit.edu
Manish Karir Manish Karir
Merit Network Merit Network
 End of changes. 27 change blocks. 
66 lines changed or deleted 101 lines changed or added

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