draft-ietf-grow-mrt-11.txt   draft-ietf-grow-mrt-12.txt 
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft M. Karir Internet-Draft M. Karir
Intended status: Standards Track Merit Network Intended status: Standards Track Merit Network
Expires: September 9, 2010 C. Labovitz Expires: March 13, 2011 C. Labovitz
Arbor Networks Arbor Networks
March 8, 2010 September 9, 2010
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-11.txt draft-ietf-grow-mrt-12.txt
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on March 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9
5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 15
5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 16
5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 17
5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 17
5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 18
5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 18
5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 18
5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 19
5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 19
5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 19
5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 25
A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 25
A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 25
A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 25
A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 25
A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 28
A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 28
A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 29
A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Researchers and engineers often wish to analyze network behavior by Researchers and engineers often wish to analyze network behavior by
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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. The MRT significantly aided by the availability of the MRT format. The MRT
format was initially defined in the MRT Programmer's Guide [MRT PROG format was initially defined in the MRT Programmer's Guide [MRT PROG
GUIDE]. GUIDE].
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 its original introduction in the MRT toolset and these extensions are
are also included in this memo. Further extensions may be introduced also included in this memo. Further extensions may be introduced at
at a later date through additional definitions of the MRT Type field a later date through additional definitions of the MRT Type field and
and Subtype fields. Subtype fields.
A number of MRT message types have been documented in some references A number of MRT message types have been documented in some references
but are not known to have been implemented. Further, several types but are not known to have been implemented. Further, several types
were employed in early MRT implementations, but are no longer were employed in early MRT implementations, but are no longer
actively being used. These types are considered to be deprecated and actively being used. These types are considered to be deprecated and
are documented in a separate appendix at the end of this document. are documented in a separate appendix at the end of this document.
Some of the deprecated types may of interest to researchers examining Some of the deprecated types may of interest to researchers examining
historical MRT archives. historical MRT archives.
Fields which contain multi-octet numeric values are encoded in Fields which contain multi-octet numeric values are encoded in
skipping to change at page 6, line 23 skipping to change at page 6, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable) | Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Basic MRT Format
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 0 through 4 are contained in the message field. Types 0 through 4 are
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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.2. I_AM_DEAD Type 4.2. 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.
5. MRT Routing Information Types 5. MRT Routing Information Types
The following Types are currently defined for the MRT format. Types The following MRT Routing Information Types are currently defined for
11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type, the MRT format:
number 16, was initially defined in the Zebra routing software
package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3
and OSPFv3_ET Types are newly defined types created for the OSPFv3
routing protocol.
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
skipping to change at page 10, line 5 skipping to change at page 9, line 40
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OSPF Type
5.2. 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 10, line 36 skipping to change at page 10, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time | | Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | Attribute Length | | Peer AS | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TABLE_DUMP Type
The View field is normally 0 and is intended for cases where an The View field is normally 0 and is intended for cases where an
implementation may have multiple RIB views (such as a route server). implementation may have multiple RIB views (such as a route server).
In cases where multiple RIB views are present, an implementation may In cases where multiple RIB views are present, an implementation may
use the the view field to distinguish entries from each view. The use the the view field to distinguish entries from each view. The
Sequence field is a simple incremental counter for each RIB entry. A Sequence field is a simple incremental counter for each RIB entry. A
typical RIB dump will exceed the 16-bit bounds of this counter and typical RIB dump will exceed the 16-bit bounds of this counter and
implementation should simply wrap back to zero and continue implementation should simply wrap back to zero and continue
incrementing the counter in such cases. incrementing the counter in such cases.
The Prefix field contains the IP address of a particular RIB entry. The Prefix field contains the IP address of a particular RIB entry.
The size of this field is dependent on the value of the Subtype for The size of this field is dependent on the value of the Subtype for
this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
is 16 octets in length. The Prefix Length field indicates the length is 16 octets in length. The Prefix Length field indicates the length
in bits of the prefix mask for the preceding Prefix field. in bits of the prefix mask for the preceding Prefix field.
The Status octet is not used in the TABLE_DUMP Type and SHOULD be set The Status octet is unused in the TABLE_DUMP Type and SHOULD be set
to 1. to 1.
The Originated Time contains the 4-octet time at which this prefix The Originated Time contains the 4-octet time at which this prefix
was heard. The value represents the time in seconds since 1 January was heard. The value represents the time in seconds since 1 January
1970 00:00:00 UTC. 1970 00:00:00 UTC.
The Peer IP field is the IP address of the peer which provided the The Peer IP field is the IP address of the peer which provided the
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 2
number of the peer. octet AS number of the peer.
Attribute length is the length of Attribute field and is 2-octets. Note that the TABLE_DUMP Type does not permit 4-Byte Peer AS numbers.
The Attribute field contains the attribute information for the RIB Nor does it allow the AFI of the peer IP to differ from the AFI of
entry. the Prefix field. The TABLE_DUMP_V2 Type must be used in these
situations.
Attribute Length contains the length of Attribute field and is
2-octets. The BGP Attribute field contains the BGP attribute
information for the RIB entry.
5.3. TABLE_DUMP_V2 Type 5.3. TABLE_DUMP_V2 Type
The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte
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.
skipping to change at page 11, line 41 skipping to change at page 11, line 37
3 RIB_IPV4_MULTICAST 3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST 4 RIB_IPV6_UNICAST
5 RIB_IPV6_MULTICAST 5 RIB_IPV6_MULTICAST
6 RIB_GENERIC 6 RIB_GENERIC
An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
collector, an optional view name, and a list of indexed peers. collector, an optional view name, and a list of indexed peers.
Following the PEER_INDEX_TABLE MRT record, a series of MRT records Following the PEER_INDEX_TABLE MRT record, a series of MRT records
are used to encode RIB table entries. This series of MRT records use are used to encode RIB table entries. This series of MRT records use
subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record
itself and include full MRT record headers. The header of the itself and include full MRT record headers. Note that the RIB entry
PEER_INDEX_TABLE Subtype is shown below. The View Name is optional MRT records MUST immediately follow the PEER_INDEX_TABLE MRT record.
and, if not present, the View Name Length MUST be set to 0. The View
Name encoding MUST follow the UTF-8 transformation format. The header of the PEER_INDEX_TABLE Subtype is shown below. The View
Name is optional and, if not present, the View Name Length MUST be
set to 0. The View Name encoding MUST follow the UTF-8
transformation format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID | | Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length | View Name (variable) | | View Name Length | View Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | | Peer Count | Peer Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the peer entries is shown below. The PEER_INDEX_TABLE Figure 4: PEER_INDEX_TABLE Subtype
record contains Peer Count peer entries.
The format of the Peer Entries is shown below. The PEER_INDEX_TABLE
record contains Peer Count number of Peer Entries.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | | Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS (variable) | | Peer AS (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Peer Entries
The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated
as indicated by the Peer Count field. The position of the Peer in as indicated by the Peer Count field. The position of the Peer in
the PEER_INDEX_TABLE is used as an index in the subsequent the PEER_INDEX_TABLE is used as an index in the subsequent
TABLE_DUMP_V2 MRT records. The index number begins with 0. TABLE_DUMP_V2 MRT records. The index number begins with 0.
The Peer Type field is a bit field which encodes the type of the AS The Peer Type field is a bit field which encodes the type of the AS
and IP address as follows: and IP address as follows:
Bit 0 - unset for IPv4 Peer IP address, set for IPv6 Bit 0 - unset for IPv4 Peer IP address, set for IPv6
Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits
The records which follow the PEER_INDEX_TABLE record constitute the The MRT records which follow the PEER_INDEX_TABLE MRT record contain
RIB entries and include a header which specifies a sequence number, the RIB entries and include a header which specifies a sequence
NLRI, and a count of the number of RIB entries which follow. number, NLRI, and a count of the number of RIB entries which follow.
The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.
The Prefix Length and Prefix fields are encoded in the same manner as The Prefix Length and Prefix fields are encoded in the same manner as
the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix
field contains address prefixes followed by enough trailing bits to field contains address prefixes followed by enough trailing bits to
make the end of the field fall on an octet boundary. Note that the make the end of the field fall on an octet boundary. Note that the
value of trailing bits is irrelevant. value of trailing bits is irrelevant.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) | | Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | | Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RIB_GENERIC header is shown below. It includes Address Family Figure 6: RIB Entry Header
Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI
information is specific to the AFI and SAFI values. An The RIB_GENERIC header is shown below. It is used to cover RIB
implementation which does not recognize particular AFI and SAFI entries which do not fall under the common case entries defined
values SHOULD discard the remainder of the MRT record. above. It includes Address Family Identifier (AFI), Subsequent AFI
and a single NLRI entry. The NLRI information is specific to the AFI
and SAFI values. An implementation which does not recognize
particular AFI and SAFI values SHOULD discard the remainder of the
MRT record.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier |Subsequent AFI | | Address Family Identifier |Subsequent AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Layer Reachability Information (variable) | | Network Layer Reachability Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | | Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RIB entry headers are followed by a series of RIB entries which Figure 7: RIB_GENERIC Entry Header
are repeated Entry Count times. These entries share a common format
as shown below. They include a Peer Index from the PEER_INDEX_TABLE The RIB and RIB_GENERIC Entry Headers are followed by a series of RIB
MRT record, an originated time for the RIB entry, and the BGP path Entries which are repeated Entry Count times. These entries share a
attribute length and attributes encoded as provided in a BGP Update common format as shown below. They include a Peer Index from the
message. PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry,
and the BGP path attribute length and attributes encoded as provided
in a BGP Update message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index | | Peer Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time | | Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attributes... (variable) | BGP Attributes... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: RIB Entries
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 [RFC4760]. Since
AFI, SAFI, and NLRI information is already encoded in the 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.4. 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.
skipping to change at page 15, line 5 skipping to change at page 15, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: BGP4MP_STATE_CHANGE Subtype
The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. The 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 Both the old state value and the new state value are encoded as
2-octet numbers. The state values are defined numerically as 2-octet numbers. The state values are defined numerically as
follows: follows:
1 Idle 1 Idle
2 Connect 2 Connect
3 Active 3 Active
4 OpenSent 4 OpenSent
5 OpenConfirm 5 OpenConfirm
skipping to change at page 16, line 4 skipping to change at page 17, line 4
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: BGP4MP_MESSAGE Subtype
The interface index provides the interface number of the peering The interface index provides the interface number of the peering
session. The index value is OPTIONAL and MAY be zero if unknown or session. The index value is OPTIONAL and MAY be zero if unknown or
unsupported. The Address Family indicates what types of addresses unsupported. The Address Family indicates what types of addresses
are in the the subsequent address fields. At present, the following are in the the subsequent address fields. At present, the following
AFI Types are supported: AFI Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
skipping to change at page 16, line 44 skipping to change at page 17, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: BGP4MP_MESSAGE_AS4 Subtype
5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype
This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support
4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE
Subtype, the BGP FSM states are encoded in the Old State and New Subtype, the BGP FSM states are encoded in the Old State and New
State fields to indicate the previous and current state. Aside from State fields to indicate the previous and current state. Aside from
the extension of the peer and local AS fields to 4-Bytes, this the extension of the peer and local AS fields to 4-Bytes, this
subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype.
The BGP4MP_STATE_CHANGE_AS4 fields are shown below: The BGP4MP_STATE_CHANGE_AS4 fields are shown below:
skipping to change at page 17, line 21 skipping to change at page 18, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: BGP4MP_STATE_CHANGE_AS4 Subtype
5.4.5. BGP4MP_MESSAGE_LOCAL Subtype 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype
Implementations of MRT have largely focused on collecting remotely Implementations of MRT have largely focused on collecting remotely
generated BGP messages in a passive route collector role. However, generated BGP messages in a passive route collector role. However,
for active BGP implementations, it can be useful to archive locally for active BGP implementations, it can be useful to archive locally
generated BGP messages in addition to remote messages. This subtype generated BGP messages in addition to remote messages. This subtype
is added to indicated a locally generated BGP message. The fields is added to indicated a locally generated BGP message. The fields
remain identical to the BGP4MP_MESSAGE type including the Peer and remain identical to the BGP4MP_MESSAGE type including the Peer and
Local IP and AS fields. The Local fields continue to refer to the Local IP and AS fields. The Local fields continue to refer to the
local IP and AS number of the collector which generated the message local IP and AS number of the collector which generated the message
skipping to change at page 17, line 42 skipping to change at page 18, line 48
generated BGP messages. generated BGP messages.
5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype
As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally
generated messages. The fields are identical to the generated messages. The fields are identical to the
BGP4MP_MESSAGE_AS4 message type. BGP4MP_MESSAGE_AS4 message type.
5.5. BGP4MP_ET Type 5.5. BGP4MP_ET Type
This Type was initially defined in the Sprint Labs Python Routing This type extends the MRT common header field to include a 32BIT
Toolkit (PyRT). It extends the MRT common header field to include a microsecond timestamp field. The type and subtype field definitions
32BIT microsecond timestamp field. The type and subtype field remain as defined for the BGP4MP Type. The 32BIT microsecond
definitions remain as defined for the BGP4MP Type. The 32BIT timestamp immediately follows the length field in the MRT common
microsecond timestamp immediately follows the length field in the MRT header and precedes all other fields in the message. The 32BIT
common header and precedes all other fields in the message. The microsecond field is included in the computation of the length field
32BIT microsecond field is included in the computation of the length value. The MRT common header modification is illustrated below.
field value. The MRT common header modification is illustrated
below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| microsecond timestamp | | microsecond timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable) | Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: BGP4MP_ET Type
5.6. ISIS Type 5.6. ISIS Type
This Type was initially defined in the Sprint Labs Python Routing and This Type supports the IS-IS routing protocol as defined in RFC 1195
supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. [RFC1195]. There is no Type specific header for the ISIS Type. The
There is no Type specific header for the ISIS Type. The Subtype code Subtype code for this Type is undefined. The ISIS PDU directly
for this Type is undefined. The ISIS PDU directly follows the MRT follows the MRT common header fields.
common header fields.
5.7. 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.8. OSPFv3 Type 5.8. OSPFv3 Type
skipping to change at page 19, line 5 skipping to change at page 20, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: OSPFv3 Type
5.9. 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. Acknowledgements
The initial MRT specification was developed by Craig Labovitz for use
in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type
was introduced in the Zebra routing software project by Kunihiro
Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the
Python Routeing Toolkit (PyRT) developed by Richard Mortier while at
Sprint Advanced Technology Labs.
7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the MRT Authority (IANA) regarding registration of values related to the MRT
specification, in accordance with BCP 26, RFC 5226 [RFC5226]. specification, in accordance with BCP 26, RFC 5226 [RFC5226].
There are two name spaces in MRT that require registration: Type There are two name spaces in MRT that require registration: Type
Codes and Subtype Codes. Codes and Subtype Codes.
MRT is not intended as a general-purpose specification for protocol MRT is not intended as a general-purpose specification for protocol
information export, and allocations should not be made for purposes information export, and allocations should not be made for purposes
unrelated to routing protocol information export. unrelated to routing protocol information export.
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Specification Required", "IETF Consensus", "Experimental Use", 26: "Specification Required", "IETF Consensus", "Experimental Use",
"First Come First Served". "First Come First Served".
6.1. Type Codes 7.1. Type Codes
Type Codes have a range from 0 to 65535, of which 1-64 have been Type Codes have a range from 0 to 65535, of which 1-64 have been
allocated. New Type Codes MUST be allocated starting at 65. Type allocated. New Type Codes MUST be allocated starting at 65. Type
Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 - Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 -
2047 are assigned based on Specification Required. Type Codes 2048 - 2047 are assigned based on Specification Required. Type Codes 2048 -
64511 are available on a First Come First Served policy. Type Codes 64511 are available on a First Come First Served policy. Type Codes
64512 - 65534 are available for Experimental Use. The Type Code 64512 - 65534 are available for Experimental Use. The Type Code
Values of 0 and 65535 are reserved. Values of 0 and 65535 are reserved.
6.2. Subtype Codes 7.2. Subtype Codes
Subtype Codes have a range from 0 to 65535. Subtype definitions are Subtype Codes have a range from 0 to 65535. Subtype definitions are
specific to a particular Type Code definition. New Subtype Code specific to a particular Type Code definition. New Subtype Code
definition must reference an existing Type Code to which the Subtype definition must reference an existing Type Code to which the Subtype
belongs. Subtype assignmnents to Type Codes 0 - 511 are to be belongs. Subtype assignmnents to Type Codes 0 - 511 are to be
assigned by IETF Review. Subtype assignments for the remaning Type assigned by IETF Review. Subtype assignments for the remaning Type
Codes follow the assignment rules for the Type Codes to which they Codes follow the assignment rules for the Type Codes to which they
belong. belong.
7. Security Considerations 8. 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.
8. References 9. References
8.1. Normative References
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 9.1. Normative References
June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional
Information", STD 56, RFC 1723, November 1994.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
skipping to change at page 22, line 37 skipping to change at page 24, line 37
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
8.2. Informative References 9.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 Appendix A. Deprecated MRT types
This Appendix lists deprecated MRT types. These types are documented This Appendix lists deprecated MRT types. These types are documented
for informational purposes only. While documented in some for informational purposes only. While documented in some
references, they are not known to have been generally implemented. references, they are not known to have been generally implemented.
skipping to change at page 24, line 37 skipping to change at page 26, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS number | | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable) | BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: BGP_UPDATE Subtype
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. The Peer AS number and IP address fields contain the AS included. The Peer AS number and IP address fields contain the AS
number and IP address of the remote system which are generating the number and IP address of the remote system which are generating the
BGP UPDATE messages. The Local AS number and IP address fields BGP UPDATE messages. The Local AS number and IP address fields
contain the AS number and IP address of the local collector system contain the AS number and IP address of the local collector system
which is archiving the messages. which is archiving the messages.
A.2.1.3. BGP_PREF_UPDATE Subtype A.2.1.3. BGP_PREF_UPDATE Subtype
skipping to change at page 25, line 16 skipping to change at page 27, line 20
value are encoded as 2-octet numbers. The state values are defined value are encoded as 2-octet numbers. The state values are defined
numerically as follows: numerically as follows:
1 Idle 1 Idle
2 Connect 2 Connect
3 Active 3 Active
4 OpenSent 4 OpenSent
5 OpenConfirm 5 OpenConfirm
6 Established 6 Established
The format of the MRT Message field is as follows: The format of the BGP_STATE_CHANGE Subtype 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: BGP_STATE_CHANGE Subtype
A.2.1.5. BGP_SYNC Subtype A.2.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype was intended to convey a system file name where The BGP_SYNC Subtype was intended to convey a system file name where
BGP Table Dump messages should be recorded. The View # was to BGP Table Dump messages should be recorded. The View # was to
correspond to the View # provided in the TABLE_DUMP Type messages. correspond to the View # provided in the TABLE_DUMP Type messages.
There are no known implementations of this subtype and it SHOULD be There are no known implementations of this subtype and it SHOULD be
ignored. The following format applies to this Subtype: ignored. The following format 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: BGP_SYNC Subtype
The File Name is terminated with a NULL (0) character. The File Name is terminated with a NULL (0) character.
A.2.1.6. BGP_OPEN Subtype A.2.1.6. BGP_OPEN Subtype
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.
A.2.1.7. BGP_NOTIFY Subtype A.2.1.7. BGP_NOTIFY Subtype
skipping to change at page 26, line 21 skipping to change at page 28, line 30
A.2.1.8. BGP_KEEPALIVE Subtype A.2.1.8. BGP_KEEPALIVE Subtype
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.
A.2.2. RIP Type A.2.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 [RFC1058]. The Subtype field is currently reserved for this 1723 [RFC1723]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0. Type and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable) | RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: RIP Type
A.2.3. IDRP Type A.2.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.
A.2.4. RIPNG Type A.2.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
skipping to change at page 27, line 19 skipping to change at page 29, line 28
~ Peer IPv6 address ~ ~ Peer IPv6 address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Local IPv6 address ~ ~ Local IPv6 address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable) | RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: RIPNG Type
A.2.5. BGP4PLUS and BGP4PLUS_01 Types A.2.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,
skipping to change at page 28, line 33 skipping to change at page 30, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: BGP4MP_ENTRY Subtype
A.2.6.2. BGP4MP_SNAPSHOT Subtype A.2.6.2. BGP4MP_SNAPSHOT Subtype
This Subtype was intended to convey a system file name where This Subtype was intended to convey a system file name where
BGP4MP_ENTRY messages should be recorded. It is similar to the BGP4MP_ENTRY messages should be recorded. It is similar to the
BGP_SYNC message Subtype and is deprecated. BGP_SYNC message Subtype and is deprecated.
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BGP4MP_SNAPSHOT Subtype
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. 53 change blocks. 
118 lines changed or deleted 178 lines changed or added

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