draft-ietf-grow-mrt-01.txt   draft-ietf-grow-mrt-02.txt 
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft M. Karir Internet-Draft M. Karir
Expires: April 27, 2006 Merit Network Expires: September 7, 2006 Merit Network
C. Labovitz C. Labovitz
Arbor Networks Arbor Networks
October 24, 2005 March 6, 2006
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-01.txt draft-ietf-grow-mrt-02.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 April 27, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 4 2. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 4
3. MRT Control Types . . . . . . . . . . . . . . . . . . . . . . 6 3. MRT Control Types . . . . . . . . . . . . . . . . . . . . . . 6
3.1 NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 START Type . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 6 3.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 6
3.5 PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 6 3.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 6
4. MRT Routing Information Types . . . . . . . . . . . . . . . . 7 4. MRT Routing Information Types . . . . . . . . . . . . . . . . 7
4.1 BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 7 4.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 7
4.1.2 BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 7 4.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 7
4.1.3 BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 8 4.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 8
4.1.4 BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 8 4.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 8
4.1.5 BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 8 4.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 8
4.1.6 BGP_OPEN . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.6. BGP_OPEN . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.7 BGP_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9 4.1.7. BGP_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9
4.1.8 BGP_KEEPALIVE . . . . . . . . . . . . . . . . . . . . 9 4.1.8. BGP_KEEPALIVE . . . . . . . . . . . . . . . . . . . . 9
4.2 RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 10 4.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 10
4.6 OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7 TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 11 4.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 11
4.8 BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 12 4.8. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.1 BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 12 4.8.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 12
4.8.2 BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 13 4.8.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 13
4.8.3 BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 14 4.8.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 14
4.8.4 BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 14 4.8.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 14
4.9 BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 14 4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype . . . . . . . . . . . 15
4.10 ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.9. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 15
4.11 ISIS_ET . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.10. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16
4.12 OSPF_ET . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.11. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.12. OSPF_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1 Normative References . . . . . . . . . . . . . . . . . . . 18 5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Informative References . . . . . . . . . . . . . . . . . . 18 5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
Researchers and engineers often wish to analyze network behavior by Researchers and engineers often wish to analyze network behavior by
studying routing protocol transactions and routing information base studying routing protocol transactions and routing information base
snapshots. To this end, the MRT format was developed to encapsulate, snapshots. To this end, the MRT format was developed to encapsulate,
export, and archive this information in a standardized data export, and archive this information in a standardized data
representation. The BGP routing protocol, in particular, has been representation. The BGP routing protocol, in particular, has been
the subject of extensive study and analysis which has been the subject of extensive study and analysis which has been
significantly aided by the availability of the MRT format. significantly aided by the availability of the MRT format.
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.
2. Basic MRT Format 2. 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 basic MRT format 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 4, line 31 skipping to change at page 4, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Field Descriptions: Header Field Descriptions:
Timestamp: Timestamp:
Time in seconds since 1 January 1970 00:00:00 UTC Time in seconds since 1 January 1970 00:00:00 UTC
Type: Type:
A 2-octet field that indicates the type of information A 2-octet field that indicates the Type of information
contained in the message field. Types 1 through 5 are used for contained in the message field. Types 1 through 5 are used for
MRT control information while Types 6 and higher are used for MRT control information while Types 6 and higher are used for
routing information. routing information.
Subtype: Subtype:
A 2-octet message subtype field A 2-octet message Subtype field
Length: Length:
A 4-octet message length field. The length does not include A 4-octet message length field. The length does not include
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.
3. MRT Control Types 3. 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 using to relay the current state of MRT message source. The
message field may contain an optional ASCII text string for message field may contain an optional ASCII text string for
diagnostic purposes. These control messages are unidirectional in diagnostic purposes. These control messages are unidirectional in
nature and there is no form of an acknowledgment or response from the 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 receiver to the sender. 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
3.1 NULL Type 3.1. NULL Type
The NULL Type message causes no operation, A sender may wish to send The NULL Type message causes no operation, A sender may wish to send
these for synchronization or keep-alive purposes. these for synchronization or keep-alive purposes.
3.2 START Type 3.2. START Type
The START Type indicates a sender is about to begin sending MRT The START Type indicates a sender is about to begin sending MRT
messages messages
3.3 DIE Type 3.3. DIE Type
A DIE Type signals that the receiver should shut down. A DIE Type signals that the receiver should shut down.
3.4 I_AM_DEAD Type 3.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.
3.5 PEER_DOWN Type 3.5. PEER_DOWN Type
A PEER_DOWN is sent when the sender's peer is down. In practice, a 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 will likely have multiple peers. It is recommended that the
sender use the Message field to convey the IP address of the peer sender use the Message field to convey the IP address of the peer
represented in US-ASCII. represented in US-ASCII.
4. MRT Routing Information Types 4. 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 defined in the Zebra routing software package. Type, number 16, was initially defined in the Zebra routing software
package.
5 BGP 5 BGP
6 RIP 6 RIP
7 IDRP 7 IDRP
8 RIPNG 8 RIPNG
9 BGP4PLUS 9 BGP4PLUS
10 BGP4PLUS_01 10 BGP4PLUS_01
11 OSPF 11 OSPF
12 TABLE_DUMP 12 TABLE_DUMP
16 BGP4MP 16 BGP4MP
17 BGP4MP_ET 17 BGP4MP_ET
32 ISIS 32 ISIS
33 ISIS_ET 33 ISIS_ET
64 OSPF_ET 64 OSPF_ET
4.1 BGP Type 4.1. BGP Type
The BGP Type indicates the Message field contains BGP routing The BGP Type indicates the Message field contains BGP routing
information. The BGP routing protocol is defined in RFC 1771 [1]. information. The BGP routing protocol is defined in RFC 1771 [1].
The information in the message is dependent on the Subtype value. The information in the message is dependent on the Subtype value.
The BGP Type is considered to be deprecated by the BGP4MP Type. The BGP Type is considered to be deprecated by the BGP4MP Type.
The following BGP subtypes are defined for the MRT BGP Type. The following BGP Subtypes are defined for the MRT BGP Type.
0 BGP_NULL 0 BGP_NULL
1 BGP_UPDATE 1 BGP_UPDATE
2 BGP_PREF_UPDATE 2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE 3 BGP_STATE_CHANGE
4 BGP_SYNC 4 BGP_SYNC
5 BGP_OPEN 5 BGP_OPEN
6 BGP_NOTIFY 6 BGP_NOTIFY
7 BGP_KEEPALIVE 7 BGP_KEEPALIVE
4.1.1 BGP_NULL Subtype 4.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved subtype. The BGP_NULL Subtype is a reserved Subtype.
4.1.2 BGP_UPDATE Subtype 4.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this subtype is as follows: format of the MRT Message field for this Subtype is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number | | Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable) | BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE contents include the entire BGP UPDATE message which The BGP UPDATE contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not follows the BGP Message Header. The BGP Message Header itself is not
included. included.
4.1.3 BGP_PREF_UPDATE Subtype 4.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined. The BGP_PREF_UPDATE Subtype is not defined.
4.1.4 BGP_STATE_CHANGE Subtype 4.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states and their numeric encodings finite state machine. These FSM states and their numeric encodings
are defined in RFC 1771 [1], Appendix 1. Both the old state value are defined in RFC 1771 [1], Appendix 1. Both the old state value
and the new state value are encoded as 2-octet numbers. The format and the new state value are encoded as 2-octet numbers. The format
of the MRT Message field is as follows: of the MRT Message field is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.5 BGP_SYNC Subtype 4.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype is used to indicate a File Name where BGP Table 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 Dump messages should be recorded. The View # corresponds to the View
# provided in the TABLE_DUMP Type messages. The following format # provided in the TABLE_DUMP Type messages. The following format
applies to this Subtype: applies to this Subtype:
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The File Name is terminated with a NULL (0) character. The File Name is terminated with a NULL (0) character.
4.1.6 BGP_OPEN 4.1.6. BGP_OPEN
The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format
of the MRT Message field for this subtype is the same as the of the MRT Message field for this Subtype is the same as the
BGP_UPDATE, however, the last field contains the contents of the BGP BGP_UPDATE, however, the last field contains the contents of the BGP
OPEN message. OPEN message.
4.1.7 BGP_NOTIFY 4.1.7. BGP_NOTIFY
The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages.
The format of the MRT Message field for this subtype is the same as The format of the MRT Message field for this Subtype is the same as
the BGP_UPDATE, however, the last field contains the contents of the the BGP_UPDATE, however, the last field contains the contents of the
BGP NOTIFICATION message. BGP NOTIFICATION message.
4.1.8 BGP_KEEPALIVE 4.1.8. BGP_KEEPALIVE
The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages.
The format of the MRT Message field for this subtype is the same as The format of the MRT Message field for this Subtype is the same as
the BGP_UPDATE, however, the last field contains no information. the BGP_UPDATE, however, the last field contains no information.
4.2 RIP Type 4.2. RIP Type
The RIP Type is used to export RIP protocol packets as defined in RFC The RIP Type is used to export RIP protocol packets as defined in RFC
1058 [2]. The Subtype field is currently reserved for this type and 1058 [2]. The Subtype field is currently reserved for this Type and
should be set to 0. should be set to 0.
The format of the MRT Message field for the RIP Type is as follows: The format of the MRT Message field for the RIP Type is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable) | RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 IDRP Type 4.3. IDRP Type
The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
protocol information as defined in the ISO/IEC 10747 standard. The protocol information as defined in the ISO/IEC 10747 standard. The
Subtype field is unused. This type is deprecated due to lack of Subtype field is unused. This Type is deprecated due to lack of
deployment of IDRP. deployment of IDRP.
4.4 RIPNG Type 4.4. RIPNG Type
The RIPNG Type is used to export RIPNG protocol packets as defined in The RIPNG Type is used to export RIPNG protocol packets as defined in
RFC 2080 [3]. The Subtype field is currently reserved for this type RFC 2080 [3]. The Subtype field is currently reserved for this Type
and should be set to 0. and should be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows: The format of the MRT Message field for the RIPNG Type is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable) | RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5 BGP4PLUS and BGP4PLUS_01 Types 4.5. BGP4PLUS and BGP4PLUS_01 Types
The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
routing information. The BGP4PLUS Type was specified based on the routing information. The BGP4PLUS Type was specified based on the
initial Internet Draft for Multiprotocol Extensions to BGP-4. The initial Internet Draft for Multiprotocol Extensions to BGP-4. The
BGP4PLUS_01 Type was specified to correspond to the -01 revision of BGP4PLUS_01 Type was specified to correspond to the -01 revision of
this Internet Draft. The two types share the same definitions in this Internet Draft. The two Types share the same definitions in
terms of their MRT format specifications. terms of their MRT format specifications.
The Subtype field definitions are shared with the BGP Type, however, The Subtype field definitions are shared with the BGP Type, however,
the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
BGP_KEEPALIVE, and BGP_STATE_CHANGE subtype messages are extended to BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to
16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP
Type. Type.
4.6 OSPF Type 4.6. OSPF Type
This type supports the OSPF Protocol as defined in RFC 2328 [4]. The This Type supports the OSPF Protocol as defined in RFC 2328 [4]. The
Subtype field may contain two possible values: Subtype field may contain two possible values:
0 OSPF_STATE_CHANGE 0 OSPF_STATE_CHANGE
1 OSPF_LSA_UPDATE 1 OSPF_LSA_UPDATE
The format of the MRT Message field for the OSPF Type is as follows: The format of the MRT Message field for the OSPF Type is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
skipping to change at page 11, line 18 skipping to change at page 11, line 16
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 IP address | | Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.7 TABLE_DUMP Type 4.7. TABLE_DUMP Type
The TABLE_DUMP Type is used to encode routing table dumps. The The TABLE_DUMP Type is used to encode routing table dumps. The
Subtype is used to encode whether the table entry contains IPv4 or Subtype is used to encode whether the table entry contains IPv4 or
IPv6 addresses. There are currently two possible values for the IPv6 addresses. There are currently two possible values for the
Subtype as shown below. 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.
skipping to change at page 12, line 31 skipping to change at page 12, line 28
update for this routing table entry. As with the Prefix field, the update for this routing table entry. As with the Prefix field, the
size of this field is dependent on the Subtype. AFI_IPv4 indicates a size of this field is dependent on the Subtype. AFI_IPv4 indicates a
4 octet field and an IPv4 address, while a Subtype of AFI_IPv6 4 octet field and an IPv4 address, while a Subtype of AFI_IPv6
requires a 16 octet field and an IPv6 address. The Peer AS field requires a 16 octet field and an IPv6 address. The Peer AS field
contains the AS number of the peer. contains the AS number of the peer.
Attribute length is the length of Attribute field and is 2-octets. Attribute length is the length of Attribute field and is 2-octets.
The Attribute field contains the attribute information for the route The Attribute field contains the attribute information for the route
table entry. table entry.
4.8 BGP4MP Type 4.8. BGP4MP Type
This type was initially defined in the Zebra software package for the This Type was initially defined in the Zebra software package for the
BGP protocol with multiprotocol extension support. It supersedes the BGP protocol with multiprotocol extension support as defined by RFC
BGP, BGP4PLUS, BGP4PLUS_01 Types. The BGP4MP Type has four subtypes 2858 [5]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The
which are defined as follows: BGP4MP Type has four Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
2 BGP4MP_ENTRY 2 BGP4MP_ENTRY
3 BGP4MP_SNAPSHOT 3 BGP4MP_SNAPSHOT
4 BGP4MP_MESSAGE_32BIT_AS
4.8.1 BGP4MP_STATE_CHANGE Subtype 4.8.1. BGP4MP_STATE_CHANGE Subtype
This record is used to encode state changes in the BGP finite state 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 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 are encoded in the Old State and New State fields to indicate the
previous and current state. The format is illustrated below: previous and current state. The format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Source AS number | Destination AS number |
skipping to change at page 13, line 20 skipping to change at page 13, line 20
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE
message, it also includes interface index and Address Family fields. message, however, it also includes interface index and Address Family
The interface index provides the interface number of the peering fields. As with the BGP_STATE_CHANGE message, the FSM states and
session and the Address Family indicates what types of addresses are their numeric encodings are defined in RFC 1771 [1], Appendix 1.
in the the address fields. At present, only the following AFI types Future updates to the BGP protocol specification will introduce a new
are supported: state machine and thus render this message Type obsolete. The
interface index provides the interface number of the peering session
and the Address Family indicates what Types of addresses are in the
the address fields. At present, only the following AFI Types are
supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
4.8.2 BGP4MP_MESSAGE Subtype 4.8.2. BGP4MP_MESSAGE Subtype
This Subtype is used to encode BGP Messages. It is similar to the This Subtype is used to encode BGP Messages. It is similar to the
BGP_UPDATE subtype, except that is can be used to encode any type of BGP_UPDATE Subtype, except that is can be used to encode any Type of
message (not just BGP UPDATES). In order to determine the BGP message (not just BGP UPDATES). In order to determine the BGP
message type, the entire BGP message, including the BGP header, is message Type, the entire BGP message, including the BGP header, is
included in the BGP Message field. The BGP4MP_MESSAGE fields are included in the BGP Message field. The BGP4MP_MESSAGE fields are
shown below: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Source AS number | Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.8.3 BGP4MP_ENTRY Subtype 4.8.3. BGP4MP_ENTRY Subtype
This Subtype is used to record routing table entries. It is similar This Subtype is used to record routing table entries. It is similar
to the TABLE_DUMP Type. The primary difference being that the to the TABLE_DUMP Type. The primary difference being that the
Address Family is encoded in the Message itself. Further, a Address Family is encoded in the Message itself. Further, a
Subsequence Address Family field (SAFI) is included as well. Subsequence Address Family field (SAFI) is included as well.
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 # | Status | | View # | Status |
skipping to change at page 14, line 32 skipping to change at page 14, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.8.4 BGP4MP_SNAPSHOT Subtype 4.8.4. BGP4MP_SNAPSHOT Subtype
This Subtype is used to indicate a filename containing BGP4MP_ENTRY This Subtype is used to indicate a filename containing BGP4MP_ENTRY
records. It is similar to the BGP_SYNC message subtype and shares records. It is similar to the BGP_SYNC message Subtype and shares
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.9 BGP4MP_ET 4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype
This type was initially defined in the Sprint Labs Python Routing This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
Autonomous System numbers. As the current 16 bit Autonomous System
number space nears exhaustion, the introduction of 32 bit numbers
will be required to support future Autonomous System number
allocations. The BGP4MP_MESSAGE_32BIT_AS 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.9. 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 Toolkit (PyRT). It extends the header field of the BGP4MP Type to
include a 32-bit microsecond timestamp field. The subtypes and other include a 32-bit microsecond timestamp field. The Subtypes and other
field definitions remain as defined for the BGP4MP Type. The 32-bit field 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
BGP4MP Type and precedes all other fields in the message. The header BGP4MP Type and precedes all other fields in the message. The header
modification is illustrated below. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| microsecond timestamp | | microsecond timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable) | Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.10 ISIS 4.10. ISIS Type
This type was initially defined in the Sprint Labs Python Routing and This Type was initially defined in the Sprint Labs Python Routing and
supports the IS-IS routing protocol as defined in RFC 1195 [5]. supports the IS-IS routing protocol as defined in RFC 1195 [6].
There is no type specific header for the ISIS Type. The subtype code There is no Type specific header for the ISIS Type. The Subtype code
for this type is undefined. The ISIS PDU directly follows the MRT for this Type is undefined. The ISIS PDU directly follows the MRT
common header fields. common header fields.
4.11 ISIS_ET 4.11. ISIS_ET Type
The ISIS_ET Type extends the the ISIS Type to support microsecond The ISIS_ET Type extends the the ISIS 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 ISIS_ET Type is otherwise identical to the ISIS Type. field. The ISIS_ET Type is otherwise identical to the ISIS Type.
4.12 OSPF_ET 4.12. OSPF_ET Type
The OSPF_ET Type extends the the OSPF Type to support microsecond The OSPF_ET Type extends the the OSPF Type to support microsecond
timestamps. As with the BGP4MP_ET and ISIS_ET Types, a 32-bit timestamps. As with the BGP4MP_ET and ISIS_ET Types, a 32-bit
microsecond timestamp field is appended to the MRT common header microsecond timestamp field is appended to the MRT common header
after the length field. The OSPF_ET Type also extends the OSPF Type after the length field. The OSPF_ET Type also extends the OSPF Type
to support IPv6 addresses for the OSPFv3 protocol as defined in RFC to support IPv6 addresses for the OSPFv3 protocol as defined in RFC
2740 [6]. The format of the MRT Message field for the OSPF_ET Type 2740 [7]. The format of the MRT Message field for the OSPF_ET Type
is as follows: is as 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Security Considerations 5. 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 [8].
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 terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in BCP
26: "First Come First Served", "Specification Required".
5.1. Type Codes
Type Codes have a range from 0 to 65535, of which 0-64 have been
allocated. New Type Codes should be allocated starting at 65 with
Specification Required.
5.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 with Specification Required for the Subtype code.
6. 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
induce any particular behavior by the recipient application. induce any particular behavior by the recipient application.
6. References 7. References
6.1 Normative References 7.1. Normative References
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[2] Hedrick, C., "Routing Information Protocol", RFC 1058, [2] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988. June 1988.
[3] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [3] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[5] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual [5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000.
[6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990. environments", RFC 1195, December 1990.
[6] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, [7] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999. December 1999.
[7] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Extensions for BGP-4", RFC 2858, June 2000. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
6.2 Informative References 7.2. Informative References
[8] "The MRT Programmers Manual", November 1999. [9] "The MRT Programmers Manual", November 1999.
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
skipping to change at page 19, line 41 skipping to change at page 22, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 77 change blocks. 
120 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/