draft-ietf-grow-mrt-07.txt   draft-ietf-grow-mrt-08.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: August 28, 2008 C. Labovitz Expires: January 15, 2009 C. Labovitz
Arbor Networks Arbor Networks
February 25, 2008 July 14, 2008
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-07.txt draft-ietf-grow-mrt-08.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 August 28, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6
4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 9 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14
5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15
5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11 5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15
5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11 5.4.4. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16
5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17
5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18
5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19
5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22
5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22
5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22
5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 22 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22
5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22
5.10. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 23 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22
5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25
5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25
5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25
5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 29
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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
The MRT format defines five Informational Type messages. These The MRT format defines five Informational Type messages. These
messages are intended to signal the state of an MRT data collector messages are intended to signal the state of an MRT data collector
and do not contain routing information. These messages are OPTIONAL and do not contain routing information. These messages are OPTIONAL
and were largely intended for use when MRT messages are sent over a and were largely intended for use when MRT messages are sent over a
network to a remote repository store. However, MRT message network to a remote repository store. However, MRT message
repository stores have traditionally resided on the same device as repository stores have traditionally resided on the same device as
the collector and these Informational Types have seen limited the collector and these Informational Types have seen limited
implementation. Further, transport mechanisms for MRT messages are implementation. Further, transport mechanisms for MRT messages are
considered to be outside the scope of this document. considered to be outside the scope of this document.
Two of these messages are considered potentially useful in The START and I_AM_DEAD messages MAY be used to provide a time
implementations with a local repository. In particular, the START reference when a data collector begins and ends the collection
and I_AM_DEAD messages MAY be used to provide a time reference when a process.
data collector begins and ends the collection process.
The message field MAY contain an OPTIONAL message string for The message field MAY contain an OPTIONAL message string for
diagnostic purposes. The message string encoding MUST follow the diagnostic purposes. The message string encoding MUST follow the
UTF-8 transformation format. The Subtype field is unused for these UTF-8 transformation format. The Subtype field is unused for these
Types and SHOULD be set to 0. Types and SHOULD be set to 0.
The MRT Informational Types are defined below: The MRT Informational Types are defined below:
0 NULL *DEPRECATED*
1 START 1 START
2 DIE *DEPRECATED*
3 I_AM_DEAD 3 I_AM_DEAD
4 PEER_DOWN *DEPRECATED*
4.1. NULL Type 4.1. START Type
The NULL Type message causes no operation and is deprecated.
4.2. START Type
The START Type indicates a collector is about to begin generating MRT The START Type indicates a collector is about to begin generating MRT
messages. messages.
4.3. DIE Type 4.2. I_AM_DEAD Type
The DIE Type signals a remote MRT repository it should stop accepting
messages. This Type is deprecated.
4.4. I_AM_DEAD Type
An I_AM_DEAD MRT message indicates that a collector has shut down and An I_AM_DEAD MRT message indicates that a collector has shut down and
has stopped generating MRT messages. has stopped generating MRT messages.
4.5. PEER_DOWN Type
The PEER_DOWN message was intended to indicate that a collector had
lost association with a BGP peer. However, the MRT format provides
BGP state change message types which duplicate this functionality.
This Type is deprecated.
5. MRT Routing Information Types 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 MRT Toolkit package. The BGP4MP Type, 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type,
number 16, was initially defined in the Zebra routing software number 16, was initially defined in the Zebra routing software
package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
defined in the Sprint Labs Python Routing Toolkit (PyRT). defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3
and OSPFv3_ET Types are newly defined types created for the OSPFv3
routing protocol.
5 BGP *DEPRECATED*
6 RIP
7 IDRP *DEPRECATED*
8 RIPNG
9 BGP4PLUS *DEPRECATED*
10 BGP4PLUS_01 *DEPRECATED*
11 OSPF 11 OSPF
12 TABLE_DUMP 12 TABLE_DUMP
13 TABLE_DUMP_V2 13 TABLE_DUMP_V2
16 BGP4MP 16 BGP4MP
17 BGP4MP_ET 17 BGP4MP_ET
32 ISIS 32 ISIS
33 ISIS_ET 33 ISIS_ET
48 OSPFv3 48 OSPFv3
49 OSPFv3_ET 49 OSPFv3_ET
5.1. BGP Type 5.1. OSPF Type
The BGP Type indicates the Message field contains BGP routing
information. The BGP routing protocol is defined in RFC 4271
[RFC4271]. The information in the message is dependent on the
Subtype value. The BGP Type and all associated Subtypes are
considered to be DEPRECATED by the BGP4MP Type.
The following BGP Subtypes are defined for the MRT BGP Type.
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVE
5.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype.
5.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this Subtype is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE Contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not
included. The Peer AS number and IP address fields contain the AS
number and IP address of the remote system which are generating the
BGP UPDATE messages. The Local AS number and IP address fields
contain the AS number and IP address of the local collector system
which is archiving the messages.
5.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined.
5.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states are defined in RFC 4271
[RFC4271], Section 8.2.2. Both the old state value and the new state
value are encoded as 2-octet numbers. The state values are defined
numerically as follows:
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Established
The format of the MRT Message field is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype was intended to convey a system file name where
BGP Table Dump messages should be recorded. The View # was to
correspond to the View # provided in the TABLE_DUMP Type messages.
There are no known implementations of this subtype and it SHOULD be
ignored. The following format applies to this Subtype:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The File Name is terminated with a NULL (0) character.
5.1.6. BGP_OPEN Subtype
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
BGP_UPDATE, however, the last field contains the contents of the BGP
OPEN message.
5.1.7. BGP_NOTIFY Subtype
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 BGP_UPDATE, however, the last field contains the contents of the
BGP NOTIFICATION message.
5.1.8. BGP_KEEPALIVE Subtype
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 BGP_UPDATE, however, the last field contains no information.
5.2. RIP Type
The RIP Type is used to export RIP protocol packets as defined in RFC
1058 [RFC1058]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0.
The format of the MRT Message field for the RIP Type is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. IDRP Type
The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
protocol information as defined in the ISO/IEC 10747 standard. The
Subtype field is unused. This Type is deprecated due to lack of
deployment of IDRP.
5.4. RIPNG Type
The RIPNG Type is used to export RIPNG protocol packets as defined in
RFC 2080 [RFC2080]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. BGP4PLUS and BGP4PLUS_01 Types
The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
routing information. The BGP4PLUS Type was specified based on the
initial Internet Draft for Multiprotocol Extensions to BGP-4. The
BGP4PLUS_01 Type was specified to correspond to the -01 revision of
this Internet Draft. The two Types share the same definitions in
terms of their MRT format specifications.
The Subtype field definitions are shared with the BGP Type, however,
the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to
16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP
Type.
5.6. OSPF Type
This Type supports the OSPF Protocol as defined in RFC 2328 This Type supports the OSPF Protocol as defined in RFC 2328
[RFC2328]. The Subtype field may contain two possible values: [RFC2328]. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address | | Remote IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. TABLE_DUMP Type 5.2. 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 two the RIB entry contains IPv4 or IPv6 addresses. There are 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
skipping to change at page 16, line 5 skipping to change at page 11, line 10
update for this RIB entry. As with the Prefix field, the size of update for this RIB entry. As with the Prefix field, the size of
this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet
field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
octet field and an IPv6 address. The Peer AS field contains the AS octet field and an IPv6 address. The Peer AS field contains the AS
number of the peer. 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 RIB The Attribute field contains the attribute information for the RIB
entry. entry.
5.8. TABLE_DUMP_V2 Type 5.3. TABLE_DUMP_V2 Type
The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT
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 PEER_INDEX_TABLE 1 PEER_INDEX_TABLE
2 RIB_IPV4_UNICAST 2 RIB_IPV4_UNICAST
skipping to change at page 18, line 48 skipping to change at page 13, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There is one exception to the encoding of BGP attributes for the BGP There is one exception to the encoding of BGP attributes for the BGP
MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the
AFI, SAFI, and NLRI information is already encoded in the AFI, SAFI, and NLRI information is already encoded in the
MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop
Address fields are included. The Reserved field is omitted. The Address fields are included. The Reserved field is omitted. The
attribute length is also adjusted to reflect only the length of the attribute length is also adjusted to reflect only the length of the
Next Hop Address Length and Next Hop Address fields. Next Hop Address Length and Next Hop Address fields.
5.9. BGP4MP Type 5.4. 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 as defined by RFC BGP protocol with multiprotocol extension support as defined by RFC
4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
The BGP4MP Type has six Subtypes which are defined as follows: The BGP4MP Type has six Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
2 BGP4MP_ENTRY *DEPRECATED*
3 BGP4MP_SNAPSHOT *DEPRECATED*
4 BGP4MP_STATE_CHANGE_AS4 4 BGP4MP_STATE_CHANGE_AS4
5 BGP4MP_MESSAGE_AS4 5 BGP4MP_MESSAGE_AS4
5.9.1. BGP4MP_STATE_CHANGE Subtype 5.4.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. The BGP FSM states are encoded in the Old State and New
are encoded in the Old State and New State fields to indicate the State fields to indicate the previous and current state. The format
previous and current state. The format is illustrated below: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2.
message, it also includes interface index and Address Family fields. Both the old state value and the new state value are encoded as
As with the BGP_STATE_CHANGE message, the FSM states are defined in 2-octet numbers. The state values are defined numerically as
RFC 4271 [RFC4271], Section 8.2.2 with the numeric values for these follows:
states defined inthe BGP_STATE_CHANGE section. The interface index
provides the interface number of the peering session. The index 1 Idle
value is OPTIONAL and MAY be zero if unknown or unsupported. The 2 Connect
Address Family indicates what types of addresses are in the the 3 Active
address fields. At present, the following AFI Types are supported: 4 OpenSent
5 OpenConfirm
6 Established
The BGP4MP_STATE_CHANGE message also includes interface index and
Address Family fields. The interface index provides the interface
number of the peering session. The index value is OPTIONAL and MAY
be zero if unknown or unsupported. The Address Family indicates what
types of addresses are in the the address fields. At present, the
following AFI Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
5.9.2. BGP4MP_MESSAGE Subtype 5.4.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 can be used to
BGP_UPDATE Subtype, except that is can be used to encode any Type of encode any Type of BGP message. In order to determine the BGP
message (not simply BGP UPDATES). In order to determine the BGP
message Type, the entire BGP message is included in the BGP Message message Type, the entire BGP message is included in the BGP Message
field. This includes 16-octet marker, 2-ocet length, and 1-octet field. This includes 16-octet marker, 2-ocet length, and 1-octet
type fields. Note that the BGP4MP_MESSAGE Subtype does not support type fields. Note that the BGP4MP_MESSAGE Subtype does not support
32BIT AS numbers nor IPv6 addresses. The BGP4MP_MESSAGE_AS4 Subtype 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the
updates the BGP4MP_MESSAGE Subtype in order to support these. The BGP4MP_MESSAGE Subtype in order to support these. The BGP4MP_MESSAGE
BGP4MP_MESSAGE fields are shown below: fields are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 46 skipping to change at page 15, line 48
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
Note that the Address Family value only applies to the IP addresses Note that the Address Family value only applies to the IP addresses
contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise
transparent to the contents of the actual message which may contain transparent to the contents of the actual message which may contain
any valid AFI/SAFI values. Only one BGP message may be encoded in any valid AFI/SAFI values. Only one BGP message may be encoded in
the BGP4MP_MESSAGE Subtype. the BGP4MP_MESSAGE Subtype.
5.9.3. BGP4MP_ENTRY Subtype 5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype
This Subtype is similar to the TABLE_DUMP Type and is used to record
RIB table entries. It extends the TABLE_DUMP Type to include true
multiprotocol support. However, this Type does not support 32BIT AS
numbers and has not been widely implemented. This Type is deprecated
in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support
and a more compact format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time last change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | SAFI | Next-Hop-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.4. BGP4MP_SNAPSHOT Subtype
This Subtype was intended to convey a system file name where
BGP4MP_ENTRY messages should be recorded. It is similar to the
BGP_SYNC message Subtype and is deprecated.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype
This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT
Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype,
the BGP FSM states are encoded in the Old State and New State fields 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 to indicate the previous and current state. Aside from the extension
of the peer and local AS fields to 32 bits, this subtype is otherwise of the peer and local AS fields to 32 bits, this subtype is otherwise
identical to the BGP4MP_STATE_CHANGE Subtype. The identical to the BGP4MP_STATE_CHANGE Subtype. The
BGP4MP_STATE_CHANGE_AS4 fields are shown below: BGP4MP_STATE_CHANGE_AS4 fields are shown below:
0 1 2 3 0 1 2 3
skipping to change at page 22, line 31 skipping to change at page 16, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.6. BGP4MP_MESSAGE_AS4 Subtype 5.4.4. 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 Subtype is Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
otherwise identical to the BGP4MP_MESSAGE Subtype. The otherwise identical to the BGP4MP_MESSAGE Subtype. The
BGP4MP_MESSAGE_AS4 fields are shown below: BGP4MP_MESSAGE_AS4 fields are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS number |
skipping to change at page 23, line 5 skipping to change at page 17, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.10. BGP4MP_ET Type 5.5. BGP4MP_ET Type
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 MRT common header field to include a Toolkit (PyRT). It extends the MRT common header field to include a
32BIT microsecond timestamp field. The type and subtype field 32BIT microsecond timestamp field. The type and subtype field
definitions remain as defined for the BGP4MP Type. The 32BIT definitions remain as defined for the BGP4MP Type. The 32BIT
microsecond timestamp immediately follows the length field in the MRT microsecond timestamp immediately follows the length field in the MRT
common header and precedes all other fields in the message. The common header and precedes all other fields in the message. The
32BIT microsecond field is included in the computation of the length 32BIT microsecond field is included in the computation of the length
field value. The MRT common header modification is illustrated field value. The MRT common header modification is illustrated
below. below.
skipping to change at page 23, line 31 skipping to change at page 17, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| microsecond timestamp | | microsecond timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable) | Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.11. ISIS Type 5.6. 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 [RFC1195]. supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195].
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.
5.12. ISIS_ET Type 5.7. ISIS_ET Type
The ISIS_ET Type extends the ISIS Type to support microsecond The ISIS_ET Type extends the ISIS Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT 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.
5.13. OSPFv3 Type 5.8. OSPFv3 Type
The OSPFv3 Type extends the original OSPF Type to support IPv6 The OSPFv3 Type extends the original OSPF Type to support IPv6
addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740].
The format of the MRT Message field for the OSPFv3 Type is as The format of the MRT Message field for the OSPFv3 Type is as
follows: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address (variable) | | Remote IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.14. OSPFv3_ET Type 5.9. OSPFv3_ET Type
The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT 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 and its length is included in the calculation of the length field and its length is included in the calculation of the length
field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
Type. Type.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 28, line 5 skipping to change at page 22, line 5
[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/networkresearch/mrtprogrammer.pdf>. <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
Appendix A. Deprecated MRT types
This Appendix lists deprecated MRT types. These types are documented
for informational purposes only. While documented in some
references, they are not known to have been generally implemented.
A.1. Deprecated MRT Informational Types
The deprecated MRT Informational Types are defined below:
0 NULL
2 DIE
4 PEER_DOWN
A.1.1. NULL Type
The NULL Type message causes no operation.
A.1.2. DIE Type
The DIE Type signals a remote MRT repository it should stop accepting
messages.
A.1.3. PEER_DOWN Type
The PEER_DOWN message was intended to indicate that a collector had
lost association with a BGP peer. However, the MRT format provides
BGP state change message types which duplicate this functionality.
A.2. Deprecated MRT Routing Information Types
5 BGP
6 RIP
7 IDRP
8 RIPNG
9 BGP4PLUS
10 BGP4PLUS_01
A.2.1. BGP Type
The BGP Type indicates the Message field contains BGP routing
information. The BGP routing protocol is defined in RFC 4271
[RFC4271]. The information in the message is dependent on the
Subtype value. The BGP Type and all associated Subtypes below are
considered to be deprecated by the BGP4MP Type.
The following BGP Subtypes are defined for the MRT BGP Type. As with
the BGP Type itself, they are all considered to be deprecated.
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVE
A.2.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype.
A.2.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this Subtype is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE Contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not
included. The Peer AS number and IP address fields contain the AS
number and IP address of the remote system which are generating the
BGP UPDATE messages. The Local AS number and IP address fields
contain the AS number and IP address of the local collector system
which is archiving the messages.
A.2.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined.
A.2.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states are defined in RFC 4271
[RFC4271], Section 8.2.2. Both the old state value and the new state
value are encoded as 2-octet numbers. The state values are defined
numerically as follows:
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Established
The format of the MRT Message field is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype was intended to convey a system file name where
BGP Table Dump messages should be recorded. The View # was to
correspond to the View # provided in the TABLE_DUMP Type messages.
There are no known implementations of this subtype and it SHOULD be
ignored. The following format applies to this Subtype:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The File Name is terminated with a NULL (0) character.
A.2.1.6. BGP_OPEN Subtype
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
BGP_UPDATE, however, the last field contains the contents of the BGP
OPEN message.
A.2.1.7. BGP_NOTIFY Subtype
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 BGP_UPDATE, however, the last field contains the contents of the
BGP NOTIFICATION message.
A.2.1.8. BGP_KEEPALIVE Subtype
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 BGP_UPDATE, however, the last field contains no information.
A.2.2. RIP Type
The RIP Type is used to export RIP protocol packets as defined in RFC
1058 [RFC1058]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0.
The format of the MRT Message field for the RIP Type is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.3. IDRP Type
The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
protocol information as defined in the ISO/IEC 10747 standard. The
Subtype field is unused. This Type is deprecated due to lack of
deployment of IDRP.
A.2.4. RIPNG Type
The RIPNG Type is used to export RIPNG protocol packets as defined in
RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to
support IPv6. The Subtype field is currently reserved for this Type
and SHOULD be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Peer IPv6 address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Local IPv6 address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.5. BGP4PLUS and BGP4PLUS_01 Types
The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
routing information. The BGP4PLUS Type was specified based on the
initial Internet Draft for Multiprotocol Extensions to BGP-4. The
BGP4PLUS_01 Type was specified to correspond to the -01 revision of
this Internet Draft. The two Types share the same definitions in
terms of their MRT format specifications.
The Subtype field definitions are shared with the BGP Type, however,
the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to
16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP
Type.
A.2.6. Deprecated BGP4MP Subtypes
The following two subtypes of the BGP4MP Type are considered to be
deprecated.
2 BGP4MP_ENTRY
3 BGP4MP_SNAPSHOT
A.2.6.1. BGP4MP_ENTRY Subtype
This Subtype is similar to the TABLE_DUMP Type and is used to record
RIB table entries. It extends the TABLE_DUMP Type to include true
multiprotocol support. However, this Type does not support 32BIT AS
numbers and has not been widely implemented. This Type is deprecated
in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support
and a more compact format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time last change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | SAFI | Next-Hop-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.6.2. BGP4MP_SNAPSHOT Subtype
This Subtype was intended to convey a system file name where
BGP4MP_ENTRY messages should be recorded. It is similar to the
BGP_SYNC message Subtype and is deprecated.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. 34 change blocks. 
340 lines changed or deleted 368 lines changed or added

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