draft-ietf-grow-mrt-17.txt   rfc6396.txt 
Network Working Group L. Blunk Internet Engineering Task Force (IETF) L. Blunk
Internet-Draft M. Karir Request for Comments: 6396 M. Karir
Intended status: Standards Track Merit Network Category: Standards Track Merit Network
Expires: February 18, 2012 C. Labovitz ISSN: 2070-1721 C. Labovitz
Deepfield Networks Deepfield Networks
August 17, 2011 October 2011
MRT routing information export format Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
draft-ietf-grow-mrt-17.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 in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 18, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6396.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 21 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 5 2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 7 3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 5
4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 7
4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 10 4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 9
4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 11 4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 9
4.3.2. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . 12 4.3.2. AFI/SAFI-Specific RIB Subtypes . . . . . . . . . . . . 11
4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 13 4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 11
4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 12
4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 15 4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 13
4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 16 4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 14
4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 17 4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15
4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 17 4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15
4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 18 4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 16
4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 18 4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 16
4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 19 4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Defined Type Codes . . . . . . . . . . . . . . . . . . . . 20 5.3. Defined Type Codes . . . . . . . . . . . . . . . . . . . . 18
5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes . . . 21 5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes . . . 19
5.5. Defined TABLE_DUMP Subtype Codes . . . . . . . . . . . . . 21 5.5. Defined TABLE_DUMP Subtype Codes . . . . . . . . . . . . . 19
5.6. Defined TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . 22 5.6. Defined TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . 19
5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes . . . . . . . . 22 5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 26
Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 29 Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 23
B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 29 Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 26
B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 29 B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 26
B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 29 B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 26
B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 29 B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 27
B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 29 B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 30 B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 27
B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 30 B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 27
B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 30 B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 27
B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 33 B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 33 B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 33 B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 30
B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 34 B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 31
B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 34 B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 31
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 36 B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Researchers and engineers often wish to analyze network behavior by Researchers and engineers often wish to analyze network behavior by
studying routing protocol transactions and routing information base studying routing protocol transactions and routing information base
snapshots. To this end, the MRT record format was developed to snapshots. To this end, the MRT record format was developed to
encapsulate, export, and archive this information in a standardized encapsulate, export, and archive this information in a standardized
data representation. data representation.
The BGP routing protocol, in particular, has been the subject of The BGP routing protocol, in particular, has been the subject of
extensive study and analysis which has been significantly aided by extensive study and analysis, which have been significantly aided by
the availability of the MRT format. Two examples of large-scale MRT the availability of the MRT format. Two examples of large-scale MRT-
based BGP archival projects include the University of Oregon Route based BGP archival projects include the University of Oregon Route
Views Project and the RIPE NCC Routing Information Service (RIS). Views Project and the RIPE NCC Routing Information Service (RIS).
The MRT format was initially defined in the MRT Programmer's Guide The MRT format was initially defined in the MRT Programmer's Guide
[MRT PROG GUIDE]. Subsequent extensions were made in the the GNU [MRT_PROG_GUIDE]. Subsequent extensions were made in the GNU Zebra
Zebra software routing suite and the Sprint Advanced Technology Labs software routing suite and the Sprint Advanced Technology Labs Python
Python Routing Toolkit (PyRT). Further extensions may be introduced Routing Toolkit (PyRT). Further extensions may be introduced at a
at a later date through additional definitions of the MRT Type field later date through additional definitions of the MRT Type field and
and Subtype fields. Subtype fields.
A number of MRT record types listed in the MRT Programmer's Guide A number of MRT record types listed in the MRT Programmer's Guide
[MRT PROG GUIDE] are not known to have been implemented and, in some [MRT_PROG_GUIDE] are not known to have been implemented and, in some
cases, were incompletely specified. Further, several types were cases, were incompletely specified. Further, several types were
employed in early MRT implementations, but saw limited use and were employed in early MRT implementations, but saw limited use and were
updated by improved versions. These types are considered to be updated by improved versions. These types are considered to be
deprecated and are documented in the Deprecated MRT Types deprecated and are documented in the Deprecated MRT Types
(Appendix B) section at the end of this document. The deprecated (Appendix B) section at the end of this document. The deprecated
types consist of codes 0 through 10 inclusive. Some of the types consist of codes 0 through 10 inclusive. Some of the
deprecated types may be of interest to researchers examining deprecated types may be of interest to researchers examining
historical MRT format archives. historical MRT format archives.
Fields which contain multi-octet numeric values are encoded in Fields which contain multi-octet numeric values are encoded in
network octet order from most significant octet to least significant network octet order from most significant octet to least significant
octet. Fields which contain routing message fields are encoded in octet. Fields that contain routing message fields are encoded in the
the same order as they appear in the packet contents. same order as they appear in the packet contents.
1.1. Specification of Requirements 1.1. Specification of Requirements
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. MRT Common Header 2. MRT Common Header
All MRT format records have a Common Header which consists of a All MRT format records have a Common Header that consists of a
Timestamp, Type, Subtype, and Length field. The header is followed Timestamp, Type, Subtype, and Length field. The header is followed
by a Message field. The MRT Common Header is illustrated below. by a Message field. The MRT Common Header is illustrated below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 32 skipping to change at page 4, line 43
Figure 1: MRT Common Header Figure 1: MRT Common Header
Header Field Descriptions: Header Field Descriptions:
Timestamp: Timestamp:
A 4-octet field whose integer value is the number of seconds, A 4-octet field whose integer value is the number of seconds,
excluding leap seconds, elapsed since midnight proleptic excluding leap seconds, elapsed since midnight proleptic
Coordinated Universal Time (UTC). This representation of time Coordinated Universal Time (UTC). This representation of time
is sometimes called "UNIX time" POSIX [IEEE.P1003.1-1990]. is sometimes called "UNIX time" [POSIX]. This time format
This time format cannot represent time values prior to January cannot represent time values prior to January 1, 1970. The
1, 1970. The latest UTC time value that can be represented by latest UTC time value that can be represented by a 4-octet
a four-octet integer value is 03:14:07 on January 19, 2038, integer value is 03:14:07 on January 19, 2038, which is
which is represented by the hexadecimal value 7FFFFFFF. represented by the hexadecimal value 7FFFFFFF. Implementations
Implementations which wish to create MRT records after this that wish to create MRT records after this date will need to
date will need to provide an alternate EPOCH time base for the provide an alternate EPOCH time base for the Timestamp field.
Timestamp field. Mechanisms for indicating this alternate Mechanisms for indicating this alternate EPOCH are currently
EPOCH are currently outside the scope of this document. outside the scope of this document.
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
informational messages pertaining to the state of an MRT informational messages pertaining to the state of an MRT
collector, while Types 5 and higher are used to convey routing collector, while Types 5 and higher are used to convey routing
information. information.
Subtype: Subtype:
A 2-octet field that is used to further distinguish message A 2-octet field that is used to further distinguish message
information within a particular record Type. information within a particular record Type.
Length: Length:
A 4-octet message length field. The length field contains the A 4-octet message length field. The Length field contains the
number of octets within the message. The length field does not number of octets within the message. The Length field does not
include the length of the MRT Common Header. include the length of the MRT Common Header.
Message: Message:
A variable length message. The contents of this field are A variable-length message. The contents of this field are
context dependent upon the Type and Subtype fields. context dependent upon the Type and Subtype fields.
3. Extended Timestamp MRT Header 3. Extended Timestamp MRT Header
Several MRT format record types support a variant type with an Several MRT format record types support a variant type with an
extended timestamp field. The purpose of this field is to support extended timestamp field. The purpose of this field is to support
measurements at sub-second resolutions. This field, Microsecond measurements at sub-second resolutions. This field, Microsecond
Timestamp, contains an unsigned 32BIT offset value in microseconds Timestamp, contains an unsigned 32BIT offset value in microseconds,
which is added to the Timestamp field value. The Timestamp field which is added to the Timestamp field value. The Timestamp field
remains as defined in the MRT Common Header. The Microsecond remains as defined in the MRT Common Header. The Microsecond
Timestamp immediately follows the length field in the MRT Common Timestamp immediately follows the Length field in the MRT Common
Header and precedes all other fields in the message. The Microsecond Header and precedes all other fields in the message. The Microsecond
Timestamp is included in the computation of the length field value. Timestamp is included in the computation of the Length field value.
The Extended Timestamp MRT Header is illustrated below. The Extended Timestamp MRT Header is illustrated below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | | Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
skipping to change at page 8, line 8 skipping to change at page 6, line 24
| Microsecond Timestamp | | Microsecond Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable) | Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Timestamp MRT Header Figure 2: Extended Timestamp MRT Header
4. MRT Types 4. MRT Types
The following MRT Types are currently defined for the MRT format. The following MRT Types are currently defined for the MRT format.
The MRT Types which contain the "_ET" suffix in their names identify The MRT Types that contain the "_ET" suffix in their names identify
those types which use an Extended Timestamp MRT Header. The subtype those types that use an Extended Timestamp MRT Header. The Subtype
and message fields in these types remain as defined for the MRT Types and Message fields in these types remain as defined for the MRT Types
of the same name without the "_ET" suffix. of the same name without the "_ET" suffix.
11 OSPFv2 11 OSPFv2
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
4.1. OSPFv2 Type 4.1. OSPFv2 Type
This Type supports the OSPFv2 Protocol as defined in RFC 2328 This type supports the OSPFv2 protocol as defined in RFC 2328
[RFC2328]. It is used to encode the exchange of OSPF protocol [RFC2328]. It is used to encode the exchange of OSPF protocol
packets. packets.
The format of the MRT Message field for the OSPFv2 Type is as The format of the MRT Message field for the OSPFv2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address | | Remote IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address | | Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: OSPFv2 Type Figure 3: OSPFv2 Type
The Remote IP address field contains Source IPv4 [RFC0791] address The Remote IP Address field contains the Source IPv4 [RFC0791]
from the IP header of the OSPF message. The Local IP address address from the IP header of the OSPF message. The Local IP Address
contains the Destination IPv4 address from the IP header. The OSPF contains the Destination IPv4 address from the IP header. The OSPF
Message Contents field contains the complete contents of the OSPF Message Contents field contains the complete contents of the OSPF
packet following the IP header. packet following the IP header.
4.2. TABLE_DUMP Type 4.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. It is RECOMMENDED that new MRT encoding sequential MRT record. It is RECOMMENDED that new MRT encoding
implementations use the TABLE_DUMP_V2 Type (see below) instead of the implementations use the TABLE_DUMP_V2 Type (see below) instead of the
skipping to change at page 9, line 27 skipping to change at page 8, line 10
the Subtype as shown below. the Subtype as shown below.
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
The format of the TABLE_DUMP Type is illustrated below. The format of the TABLE_DUMP Type is illustrated below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Sequence number | | View Number | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) | | Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Status | | Prefix Length | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 4: TABLE_DUMP Type Figure 4: TABLE_DUMP Type
The View field is normally 0 and is intended for cases where an The View Number field is normally 0 and is intended for cases where
implementation may have multiple RIB views (such as a route server). an implementation may have multiple RIB views (such as a route
In cases where multiple RIB views are present, an implementation MAY server). In cases where multiple RIB views are present, an
use the the view field to distinguish entries from each view. The implementation MAY use the View Number field to distinguish entries
Sequence field is a simple incremental counter for each RIB entry. A from each view. The Sequence Number field is a simple incremental
typical RIB dump will exceed the 16-bit bounds of this counter and counter for each RIB entry. A typical RIB dump will exceed the
implementation SHOULD simply wrap back to zero and continue 16-bit bounds of this counter, and an implementation SHOULD simply
incrementing the counter in such cases. wrap back to zero and continue 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 record. The AFI_IPv4 Subtype value specifies an Address Family this record. The AFI_IPv4 Subtype value specifies an Address Family
[IANA-AF] Identifier (AFI) type of IPv4. It specifies a prefix field Identifier (AFI) type of IPv4 [IANA-AF]. It specifies a Prefix field
length of 4 octets. For AFI_IPv6, it is 16 octets in length. The length of 4 octets. For AFI_IPv6, it is 16 octets in length. The
Prefix Length field indicates the length in bits of the prefix mask Prefix Length field indicates the length in bits of the prefix mask
for the preceding Prefix field. for the preceding Prefix field.
The Status octet is unused 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 Address field is the IP address of the peer that provided
update for this RIB entry. As with the Prefix field, the size of the 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
octet field and an IPv6 address. The Peer AS field contains the 2 16-octet field and an IPv6 address. The Peer AS field contains the
octet Autonomous System (AS) number of the peer. 2-octet Autonomous System (AS) number of the peer.
The TABLE_DUMP Type does not permit 4-Byte Peer AS numbers. Nor does The TABLE_DUMP Type does not permit 4-byte Peer AS numbers, nor does
it allow the AFI of the peer IP to differ from the AFI of the Prefix it allow the AFI of the peer IP to differ from the AFI of the Prefix
field. The TABLE_DUMP_V2 Type MUST be used in these situations. field. The TABLE_DUMP_V2 Type MUST be used in these situations.
Attribute Length contains the length of Attribute field and is Attribute Length contains the length of the Attribute field and is 2
2-octets. The BGP Attribute field contains the BGP attribute octets. The BGP Attribute field contains the BGP attribute
information for the RIB entry. The AS_PATH attribute MUST only information for the RIB entry. The AS_PATH attribute MUST only
consist of 2-Byte AS numbers. The TABLE_DUMP_V2 supports 4-Byte AS consist of 2-byte AS numbers. The TABLE_DUMP_V2 supports 4-byte AS
numbers in the AS_PATH attribute. numbers in the AS_PATH attribute.
4.3. TABLE_DUMP_V2 Type 4.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
Autonomous System Number (ASN) support and full support for BGP Autonomous System Number (ASN) support and full support for BGP
Multiprotocol extensions. It also improves upon the space efficiency multiprotocol extensions. It also improves upon the space efficiency
of the TABLE_DUMP Type by employing an index table for peers and of the TABLE_DUMP Type by employing an index table for peers and
permitting a single MRT record per Network Layer Reachability permitting a single MRT record per Network Layer Reachability
Information (NLRI) entry. The following subtypes are used with the Information (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
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
4.3.1. PEER_INDEX_TABLE Subtype 4.3.1. PEER_INDEX_TABLE Subtype
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 is
are used to encode RIB table entries. This series of MRT records use used to encode RIB table entries. This series of MRT records uses
subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record subtypes 2-6 and is separate from the PEER_INDEX_TABLE MRT record
itself and include full MRT record headers. The RIB entry MRT itself and includes full MRT record headers. The RIB entry MRT
records MUST immediately follow the PEER_INDEX_TABLE MRT record. records MUST immediately follow the PEER_INDEX_TABLE MRT record.
The header of the PEER_INDEX_TABLE Subtype is shown below. The View 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 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 set to 0. The View Name encoding MUST follow the UTF-8
transformation format [RFC3629]. transformation format [RFC3629].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 42 skipping to change at page 10, line 27
The format of the Peer Entries is shown below. The PEER_INDEX_TABLE The format of the Peer Entries is shown below. The PEER_INDEX_TABLE
record contains Peer Count number of Peer Entries. 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 6: Peer Entries Figure 6: Peer Entries
The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated The Peer Type, Peer BGP ID, Peer IP Address, and Peer AS fields are
as indicated by the Peer Count field. The position of the Peer in repeated as indicated by the Peer Count field. The position of the
the PEER_INDEX_TABLE is used as an index in the subsequent peer in 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 that encodes the type of the AS
and IP address as identified by the A and I bits, respectively, and IP address as identified by the A and I bits, respectively,
below. below.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | | | | |A|I| | | | | | | |A|I|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits
Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6 Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6
Figure 7: Peer Type Field Figure 7: Peer Type Field
The MRT records which follow the PEER_INDEX_TABLE MRT record consist The MRT records that follow the PEER_INDEX_TABLE MRT record consist
of the subtypes listed below and contain the actual RIB table of the subtypes listed below and contain the actual RIB table
entries. They include a header which specifies a sequence number, a entries. They include a header that specifies a sequence number, an
NLRI field, and a count of the number of RIB entries contained within NLRI field, and a count of the number of RIB entries contained within
the record. the record.
4.3.2. AFI/SAFI specific RIB Subtypes 4.3.2. AFI/SAFI-Specific RIB Subtypes
The AFI/SAFI specific RIB Subtypes consist of the RIB_IPV4_UNICAST, The AFI/SAFI-specific RIB Subtypes consist of the RIB_IPV4_UNICAST,
RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST
Subtypes. These specific RIB table entries are given their own MRT Subtypes. These specific RIB table entries are given their own MRT
TABLE_DUMP_V2 subtypes as they are the most common type of RIB table TABLE_DUMP_V2 subtypes as they are the most common type of RIB table
instances and providing specific MRT subtypes for them permits more instances, and providing specific MRT subtypes for them permits more
compact encodings. These subtypes permit a single MRT record to compact encodings. These subtypes permit a single MRT record to
encode multiple RIB table entries for a single prefix. The Prefix encode multiple RIB table entries for a single prefix. The Prefix
Length and Prefix fields are encoded in the same manner as the BGP Length and Prefix fields are encoded in the same manner as the BGP
NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix field NLRI encoding for IPv4 and IPv6 prefixes. Namely, the Prefix field
contains address prefixes followed by enough trailing bits to make contains address prefixes followed by enough trailing bits to make
the end of the field fall on an octet boundary. The value of the end of the field fall on an octet boundary. The value of
trailing bits is irrelevant. 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 | RIB Entries (variable) | Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: RIB Entry Header Figure 8: RIB Entry Header
4.3.3. RIB_GENERIC Subtype 4.3.3. RIB_GENERIC Subtype
The RIB_GENERIC header is shown below. It is used to cover RIB The RIB_GENERIC header is shown below. It is used to cover RIB
entries which do not fall under the common case entries defined entries that do not fall under the common case entries defined above.
above. It consists of an AFI, Subsequent AFI (SAFI) and a single It consists of an AFI, Subsequent AFI (SAFI), and a single NLRI
NLRI entry. The NLRI information is specific to the AFI and SAFI entry. The NLRI information is specific to the AFI and SAFI values.
values. An implementation which does not recognize particular AFI An implementation that does not recognize particular AFI and SAFI
and SAFI values SHOULD discard the remainder of the MRT record. 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 | RIB Entries (variable) | Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: RIB_GENERIC Entry Header Figure 9: RIB_GENERIC Entry Header
4.3.4. RIB Entries 4.3.4. RIB Entries
The RIB Entries are repeated Entry Count times. These entries share The RIB Entries are repeated Entry Count times. These entries share
a common format as shown below. They include a Peer Index from the a common format as shown below. They include a Peer Index from the
PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry,
and the BGP path attribute length and attributes. All AS numbers in and the BGP path attribute length and attributes. All AS numbers in
the AS_PATH attribute MUST be encoded as 4-Byte AS numbers. the AS_PATH attribute MUST be encoded as 4-byte AS numbers.
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 10: RIB Entries Figure 10: 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 [RFC4760]. Since MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760]. Since the AFI,
the AFI, SAFI, and NLRI information is already encoded in the SAFI, and NLRI information is already encoded in the RIB Entry Header
MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop or RIB_GENERIC Entry Header, only the Next Hop Address Length and
Address fields are included. The Reserved field is omitted. The Next Hop Address fields are included. The Reserved field is omitted.
attribute length is also adjusted to reflect only the length of the The attribute length is also adjusted to reflect only the length of
Next Hop Address Length and Next Hop Address fields. the Next Hop Address Length and Next Hop Address fields.
4.4. BGP4MP Type 4.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]. The BGP4MP Type has six Subtypes which are defined 4760 [RFC4760]. The BGP4MP Type has six Subtypes, which are defined
as follows: as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
4 BGP4MP_MESSAGE_AS4 4 BGP4MP_MESSAGE_AS4
5 BGP4MP_STATE_CHANGE_AS4 5 BGP4MP_STATE_CHANGE_AS4
6 BGP4MP_MESSAGE_LOCAL 6 BGP4MP_MESSAGE_LOCAL
7 BGP4MP_MESSAGE_AS4_LOCAL 7 BGP4MP_MESSAGE_AS4_LOCAL
4.4.1. BGP4MP_STATE_CHANGE Subtype 4.4.1. BGP4MP_STATE_CHANGE Subtype
This message is used to encode state changes in the BGP finite state This message is used to encode state changes in the BGP finite state
machine. The BGP Finite State Machine (FSM) states are encoded in machine (FSM). The BGP FSM states are encoded in the Old State and
the Old State and New State fields to indicate the previous and New State fields to indicate the previous and current state. In some
current state. In some cases, the Peer AS number may be undefined. cases, the Peer AS Number may be undefined. In such cases, the value
In such cases, the value of this field MAY be set to zero. The of this field MAY be set to zero. The format is illustrated below:
format is illustrated below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: BGP4MP_STATE_CHANGE Subtype Figure 11: 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
6 Established 6 Established
The BGP4MP_STATE_CHANGE message also includes interface index and The BGP4MP_STATE_CHANGE message also includes Interface Index and
Address Family fields. The interface index provides the interface Address Family fields. The Interface Index provides the interface
number of the peering session. The index value is OPTIONAL and MAY number of the peering session. The index value is OPTIONAL and MAY
be zero if unknown or unsupported. The Address Family indicates what be zero if unknown or unsupported. The Address Family indicates what
types of addresses are in the the address fields. At present, the types of addresses are in the address fields. At present, the
following AFI Types are supported: following AFI Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
4.4.2. BGP4MP_MESSAGE Subtype 4.4.2. BGP4MP_MESSAGE Subtype
This Subtype is used to encode BGP messages. It can be used to This subtype is used to encode BGP messages. It can be used to
encode any Type of BGP message. The entire BGP message is encode any Type of BGP message. The entire BGP message is
encapsulated in the BGP Message field, including the 16-octet marker, encapsulated in the BGP Message field, including the 16-octet marker,
the 2-octet length, and the 1-octet type fields. The BGP4MP_MESSAGE the 2-octet length, and the 1-octet type fields. The BGP4MP_MESSAGE
Subtype does not support 4-Byte AS numbers. The AS_PATH contained in Subtype does not support 4-byte AS numbers. The AS_PATH contained in
these messages MUST only consist of 2-Byte AS numbers. The these messages MUST only consist of 2-byte AS numbers. The
BGP4MP_MESSAGE_AS4 Subtype updates the BGP4MP_MESSAGE Subtype in BGP4MP_MESSAGE_AS4 Subtype updates the BGP4MP_MESSAGE Subtype in
order to support 4-Byte AS numbers. The BGP4MP_MESSAGE fields are order to support 4-byte AS numbers. The BGP4MP_MESSAGE fields are
shown below: shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 12: BGP4MP_MESSAGE Subtype Figure 12: 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 subsequent address fields. At present, the following AFI
AFI Types are supported: Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
The Address Family value only applies to the IP addresses contained The Address Family value only applies to the IP addresses contained
in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 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 that may contain
any valid AFI/SAFI values. Only one BGP message SHALL be encoded in any valid AFI/SAFI values. Only one BGP message SHALL be encoded in
the BGP4MP_MESSAGE Subtype. the BGP4MP_MESSAGE Subtype.
4.4.3. BGP4MP_MESSAGE_AS4 Subtype 4.4.3. BGP4MP_MESSAGE_AS4 Subtype
This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte AS This subtype updates the BGP4MP_MESSAGE Subtype to support 4-byte AS
numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to
the BGP4MP_MESSAGE Subtype. The AS_PATH in these messages MUST only the BGP4MP_MESSAGE Subtype. The AS_PATH in these messages MUST only
consist of 4-Byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are consist of 4-byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are
shown below: shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local 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 13: BGP4MP_MESSAGE_AS4 Subtype Figure 13: BGP4MP_MESSAGE_AS4 Subtype
4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 4.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 AS numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP 4-byte AS numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP
FSM states are encoded in the Old State and New State fields to FSM states are encoded in the Old State and New State fields to
indicate the previous and current state. Aside from the extension of indicate the previous and current state. Aside from the extension of
the peer and local AS fields to 4-Bytes, this subtype is otherwise the Peer and Local AS Number fields to 4 bytes, this subtype is
identical to the BGP4MP_STATE_CHANGE Subtype. The otherwise 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype
4.4.5. BGP4MP_MESSAGE_LOCAL Subtype 4.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 indicate 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 BGP local IP and AS number of the collector that generated the BGP
message and the Peer IP and AS fields refer to the recipient of the message, and the Peer IP and AS fields refer to the recipient of the
generated BGP messages. generated BGP messages.
4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 4.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 indicates 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.
4.5. ISIS Type 4.5. ISIS Type
This Type supports the IS-IS routing protocol as defined in RFC 1195 This type supports the IS-IS routing protocol as defined in RFC 1195
[RFC1195]. There is no Type specific header for the ISIS Type. The [RFC1195]. There is no Type-specific header for the ISIS Type. The
Subtype code for this Type is undefined. The ISIS PDU directly Subtype code for this type is undefined. The ISIS PDU directly
follows the MRT Common Header fields. follows the MRT Common Header fields.
4.6. OSPFv3 Type 4.6. OSPFv3 Type
The OSPFv3 Type extends the original OSPFv2 Type to support IPv6 The OSPFv3 Type extends the original OSPFv2 Type to support IPv6
addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340].
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: OSPFv3 Type Figure 15: OSPFv3 Type
5. IANA Considerations 5. 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 have been registered: Type
Codes and Subtype Codes. Type Codes and Subtype Codes are each 16 Codes and Subtype Codes. Type Codes and Subtype Codes are each 16
bits in length. bits in length.
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". Assignments consist of a name and the "First Come First Served". Assignments consist of a name and the
value. value.
5.1. Type Codes 5.1. Type Codes
Type Codes have a range from 0 to 65535, of which 0-64 are reserved. Type Codes have a range from 0 to 65535, of which 0-64 are reserved.
New Type Codes MUST be allocated starting at 65. Type Codes 65 - 511 New Type Codes MUST be allocated starting at 65. Type Codes 65-511
are to be assigned by IETF Review. Type Codes 512 - 2047 are are assigned by IETF Review. Type Codes 512-2047 are assigned based
assigned based on Specification Required. Type Codes 2048 - 64511 on Specification Required. Type Codes 2048-64511 are available on a
are available on a First Come First Served policy. Type Codes 64512 First Come First Served policy. Type Codes 64512 - 65534 are
- 65534 are available for Experimental Use. The Type Code Value 65535 available for Experimental Use. The Type Code Value 65535 is
is reserved. reserved.
5.2. Subtype Codes 5.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
definitions must reference an existing Type Code to which the Subtype definitions must reference an existing Type Code to which the Subtype
belongs. Subtype assignments follow the assignment rules for the belongs. Subtype assignments follow the assignment rules for the
Type Codes to which they belong. Type Codes to which they belong.
5.3. Defined Type Codes 5.3. Defined Type Codes
This document defines the following message Type Codes: This document defines the following message Type Codes:
Name Value Definition Name Value Definition
---- ----- ---------- ---- ----- ----------
NULL 0 See Section B.1.1 NULL 0 See Appendix B.1.1
START 1 See Section B.1.2 START 1 See Appendix B.1.2
DIE 2 See Section B.1.3 DIE 2 See Appendix B.1.3
I_AM_DEAD 3 See Section B.1.4 I_AM_DEAD 3 See Appendix B.1.4
PEER_DOWN 4 See Section B.1.5 PEER_DOWN 4 See Appendix B.1.5
BGP 5 See Section B.2.1 BGP 5 See Appendix B.2.1
RIP 6 See Section B.2.2 RIP 6 See Appendix B.2.2
IDRP 7 See Section B.2.3 IDRP 7 See Appendix B.2.3
RIPNG 8 See Section B.2.4 RIPNG 8 See Appendix B.2.4
BGP4PLUS 9 See Section B.2.5 BGP4PLUS 9 See Appendix B.2.5
BGP4PLUS_01 10 See Section B.2.5 BGP4PLUS_01 10 See Appendix B.2.5
OSPFv2 11 See Section 4.1 OSPFv2 11 See Section 4.1
TABLE_DUMP 12 See Section 4.2 TABLE_DUMP 12 See Section 4.2
TABLE_DUMP_v2 13 See Section 4.3 TABLE_DUMP_V2 13 See Section 4.3
BGP4MP 16 See Section 4.4 BGP4MP 16 See Section 4.4
BGP4MP_ET 17 See Section 4.4 BGP4MP_ET 17 See Section 4.4
ISIS 32 See Section 4.5 ISIS 32 See Section 4.5
ISIS_ET 33 See Section 4.5 ISIS_ET 33 See Section 4.5
OSPFv3 48 See Section 4.6 OSPFv3 48 See Section 4.6
OSPFv3_ET 49 See Section 4.6 OSPFv3_ET 49 See Section 4.6
5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes 5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes
This document defines the following message Subtype Codes for the This document defines the following message Subtype Codes for the
BGP, BGP4PLUS, and BGP4PLUS_01 Types: BGP, BGP4PLUS, and BGP4PLUS_01 Types:
Name Value Definition Name Value Definition
---- ----- ---------- ---- ----- ----------
BGP_NULL 0 See Section B.2.1 BGP_NULL 0 See Appendix B.2.1
BGP_UPDATE 1 See Section B.2.1 BGP_UPDATE 1 See Appendix B.2.1
BGP_PREF_UPDATE 2 See Section B.2.1 BGP_PREF_UPDATE 2 See Appendix B.2.1
BGP_STATE_CHANGE 3 See Section B.2.1 BGP_STATE_CHANGE 3 See Appendix B.2.1
BGP_SYNC 4 See Section B.2.1 BGP_SYNC 4 See Appendix B.2.1
BGP_OPEN 5 See Section B.2.1 BGP_OPEN 5 See Appendix B.2.1
BGP_NOTIFY 6 See Section B.2.1 BGP_NOTIFY 6 See Appendix B.2.1
BGP_KEEPALIVE 7 See Section B.2.1 BGP_KEEPALIVE 7 See Appendix B.2.1
5.5. Defined TABLE_DUMP Subtype Codes 5.5. Defined TABLE_DUMP Subtype Codes
This document defines the following message Subtype Codes for the This document defines the following message Subtype Codes for the
TABLE_DUMP Type: TABLE_DUMP Type:
Name Value Definition Name Value Definition
---- ----- ---------- ---- ----- ----------
AFI_IPv4 1 See Section 4.2 AFI_IPv4 1 See Section 4.2
AFI_IPv6 2 See Section 4.2 AFI_IPv6 2 See Section 4.2
skipping to change at page 23, line 7 skipping to change at page 20, line 23
BGP4MP_MESSAGE 1 See Section 4.4 BGP4MP_MESSAGE 1 See Section 4.4
BGP4MP_ENTRY 2 See Section 4.4 BGP4MP_ENTRY 2 See Section 4.4
BGP4MP_SNAPSHOT 3 See Section 4.4 BGP4MP_SNAPSHOT 3 See Section 4.4
BGP4MP_MESSAGE_AS4 4 See Section 4.4 BGP4MP_MESSAGE_AS4 4 See Section 4.4
BGP4MP_STATE_CHANGE_AS4 5 See Section 4.4 BGP4MP_STATE_CHANGE_AS4 5 See Section 4.4
BGP4MP_MESSAGE_LOCAL 6 See Section 4.4 BGP4MP_MESSAGE_LOCAL 6 See Section 4.4
BGP4MP_MESSAGE_AS4_LOCAL 7 See Section 4.4 BGP4MP_MESSAGE_AS4_LOCAL 7 See Section 4.4
6. Security Considerations 6. Security Considerations
The MRT Format utilizes a structure which can store routing protocol The MRT Format utilizes a structure that 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.
Some information contained in an MRT data structure might be Some information contained in an MRT data structure might be
considered sensitive or private. For example, a BGP peer that sends considered sensitive or private. For example, a BGP peer that sends
a message to an MRT-enabled router might not expect that message to a message to an MRT-enabled router might not expect that message to
be shared beyond the AS to which it is sent. be shared beyond the AS to which it is sent.
Information that could be considered sensitive include BGP peer IP Information that could be considered sensitive includes BGP peer IP
addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such
information could be useful to mount attacks against the BGP protocol information could be useful to mount attacks against the BGP protocol
and routing infrastructure. RFC 4272 [RFC4272] examines a number of and routing infrastructure. RFC 4272 [RFC4272] examines a number of
weaknesses in the BGP protocol which could potentially be exploited. weaknesses in the BGP protocol that could potentially be exploited.
An organization that intends to use the MRT structure to export An organization that intends to use the MRT structure to export
routing information beyond the domain where it normally accessible routing information beyond the domain where it is normally accessible
(e.g., publishing MRT dumps for use by researchers) should verify (e.g., publishing MRT dumps for use by researchers) should verify
with any peers whose information might be included, and possibly with any peers whose information might be included, and possibly
remove sensitive fields. remove sensitive fields.
The proposed geolocation extension to MRT could reveal the location The proposed geolocation extension to MRT could reveal the location
of an MRT router's peers [I- D.ietf-grow-geomrt]. of an MRT router's peers [GEOMRT].
7. References 7. References
7.1. Normative References 7.1. Normative References
[IANA-AF] "Address Family Numbers", [IANA-AF] IANA, "Address Family Numbers",
<http://www.iana.org/numbers.html>. <http://www.iana.org/numbers.html>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[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
dual environments", RFC 1195, December 1990. and dual environments", RFC 1195, December 1990.
[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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
(IPv6) Specification", RFC 2460, December 1998. Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border
Protocol 4 (BGP-4)", RFC 4271, January 2006. Gateway Protocol 4 (BGP-4)", RFC 4271,
January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Writing an IANA Considerations Section in RFCs",
May 2008. BCP 26, RFC 5226, May 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
for IPv6", RFC 5340, July 2008. "OSPF for IPv6", RFC 5340, July 2008.
7.2. Informative References 7.2. Informative References
[IEEE.P1003.1-1990] [GEOMRT] Manderson, T., "Multi-Threaded Routing Toolkit
Institute of Electrical and Electronics Engineers, (MRT) Border Gateway Protocol (BGP) Routing
"P1003.1, Information Technology Portable Operating System Information Export Format with Geo-Location
Interface (POSIX) Part 1: System Application Program Extensions", RFC 6397, October 2011.
Interface (API) [C Language], 1990.", IEEE Standard
P1003.1.
[MRT PROG GUIDE] [MRT_PROG_GUIDE] Labovitz, C., "MRT Programmer's Guide",
Labovitz, C., "MRT Programmer's Guide", November 1999, November 1999, <http://www.merit.edu/
<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. networkresearch/mrtprogrammer.pdf>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [POSIX] Institute of Electrical and Electronics Engineers,
January 1997. "P1003.1, Information Technology Portable Operating
System Interface (POSIX) Part 1: System Application
Program Interface (API) [C Language], 1990.",
IEEE Standard P1003.1.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6",
November 1998. RFC 2080, January 1997.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
RFC 4272, January 2006. November 1998.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities
Analysis", RFC 4272, January 2006.
Appendix A. MRT Encoding Examples Appendix A. MRT Encoding Examples
This appendix, which is not a normative reference, contains MRT This appendix, which is not normative, contains MRT encoding
encoding examples. examples.
The following example shows the encoding for a MRT record type of The following example shows the encoding for an MRT record type of
BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS
numbers are encoded in 4 bytes fields due to the use of the numbers are encoded in 4-byte fields due to the use of the
BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in
hexadecimal. The AS numbers in the ASPATH in the BGP Update are hexadecimal. The AS numbers in the ASPATH in the BGP Update are
encoded as 4 byte values in accord with the MRT BGP4MP_MESSAGE_AS4 encoded as 4-byte values in accord with the MRT BGP4MP_MESSAGE_AS4
subtype. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Subtype = 4 | | Type = 16 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 82 | | Length = 82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 64496 | | Peer AS = 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS = 64497 | | Local AS = 64497 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index = 0 | Address Family = 1 | | Interface Index = 0 | Address Family = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address = 192.0.2.85 | | Peer IP Address = 192.0.2.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address = 198.51.100.4 | | Local IP Address = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Update = | BGP Update =
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03 00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03
00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71 33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71
Figure 16: MRT BGP4MP_MESSAGE_AS4 Example Figure 16: MRT BGP4MP_MESSAGE_AS4 Example
The contents of the BGP Update Message above are as follows: The contents of the BGP Update Message above are as follows:
ORIGIN: INCOMPLETE ORIGIN: INCOMPLETE
ASPATH: 64496 64511 64502 ASPATH: 64496 64511 64502
NEXT_HOP: 198.51.100.188 NEXT_HOP: 198.51.100.188
COMMUNITY: 64496:14 COMMUNITY: 64496:14
NLRI: 203.0.113.0/24 NLRI: 203.0.113.0/24
Figure 17: BGP Message Contents Figure 17: BGP Message Contents
The following example displays the encoding for a MRT record type of The following example displays the encoding for an MRT record type of
TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this
example contains 2 entries. example contains 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 1 | | Type = 13 | Subtype = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 34 | | Length = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID = 198.51.100.4 | | Collector BGP ID = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length = 0 | Peer Count = 2 | | View Name Length = 0 | Peer Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 | | Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 198.51.100.5 | | Peer BGP ID = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address = 198.51.100.5 | | Peer IP Address = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65541 | | Peer AS = 65541 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 | | Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 192.0.2.33 | | Peer BGP ID = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address = 192.0.2.33 | | Peer IP Address = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65542 | | Peer AS = 65542 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: MRT PEER_INDEX_TABLE Example Figure 18: MRT PEER_INDEX_TABLE Example
The following example displays the encoding for a MRT record type of The following example displays the encoding for an MRT record type of
TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to
the NLRI prefix of 2001:0DB8::/32. There is a single entry for this the NLRI prefix of 2001:0DB8::/32. There is a single entry for this
prefix. The entry applies to the peer identified by index location prefix. The entry applies to the peer identified by index location
15 in a preceding MRT PEER_INDEX_TABLE record. 15 in a preceding MRT PEER_INDEX_TABLE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 4 | | Type = 13 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 87 | | Length = 87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number = 42 | | Sequence Number = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preflen = 32 | | Preflen = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix = 2001:0DB8::/32 | | Prefix = 2001:0DB8::/32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count = 1 | | Entry Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index = 15 | | Peer Index = 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) | |Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) |
skipping to change at page 28, line 48 skipping to change at page 26, line 14
The contents of the BGP Path Attribute field above are as follows: The contents of the BGP Path Attribute field above are as follows:
ORIGIN: IGP ORIGIN: IGP
ASPATH: 64496 64511 64502 ASPATH: 64496 64511 64502
MP_REACH_NLRI(IPv6 Unicast) MP_REACH_NLRI(IPv6 Unicast)
NEXT_HOP: 2001:db8:d:ff::187 NEXT_HOP: 2001:db8:d:ff::187
NEXT_HOP: fe80::212:f2ff:fe9f:1b00 NEXT_HOP: fe80::212:f2ff:fe9f:1b00
NLRI: 2001:0DB8::/32 NLRI: 2001:0DB8::/32
Figure 20: BGP Path Attribute contents Figure 20: BGP Path Attribute Contents
Appendix B. Deprecated MRT Types Appendix B. 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. for informational purposes.
B.1. Deprecated MRT Informational Types B.1. Deprecated MRT Informational Types
The initial MRT format defined five Informational Type records. The initial MRT format defined five Informational Type records.
These records were intended to signal the state of an MRT data These records were intended to signal the state of an MRT data
collector and do not contain routing information. These records were collector and do not contain routing information. These records were
intended for use when MRT records were sent over a network to a intended for use when MRT records were sent over a network to a
remote repository store. However, MRT record repository stores have remote repository store. However, MRT record repository stores have
traditionally resided on the same device as the collector and these traditionally resided on the same device as the collector, and these
Informational Types are not known to be implemented. Further, Informational Types are not known to be implemented. Further,
transport mechanisms for MRT records are considered to be outside the transport mechanisms for MRT records are considered to be outside the
scope of this document. scope of this document.
The message field MAY contain an OPTIONAL string for diagnostic The Message field MAY contain an OPTIONAL string for diagnostic
purposes. The message string encoding MUST follow the UTF-8 purposes. The message string encoding MUST follow the UTF-8
transformation format [RFC3629]. The Subtype field is unused for transformation format [RFC3629]. The Subtype field is unused for
these Types and SHOULD be set to 0. these Types and SHOULD be set to 0.
The MRT Informational Types are defined below: The MRT Informational Types are defined below:
0 NULL 0 NULL
1 START 1 START
2 DIE 2 DIE
3 I_AM_DEAD 3 I_AM_DEAD
4 PEER_DOWN 4 PEER_DOWN
B.1.1. NULL Type B.1.1. NULL Type
The NULL Type message causes no operation. The NULL Type message causes no operation.
B.1.2. START Type B.1.2. START Type
The START Type indicates a collector is about to begin generating MRT The START Type indicates that a collector is about to begin
records. generating MRT records.
B.1.3. DIE Type B.1.3. DIE Type
The DIE Type signals a remote MRT repository it SHOULD stop accepting The DIE Type signals a remote MRT repository that it SHOULD stop
messages. accepting messages.
B.1.4. I_AM_DEAD Type B.1.4. I_AM_DEAD Type
An I_AM_DEAD MRT record indicates that a collector has shut down and An I_AM_DEAD MRT record indicates that a collector has shut down and
has stopped generating MRT records. has stopped generating MRT records.
B.1.5. PEER_DOWN Type B.1.5. PEER_DOWN Type
The PEER_DOWN message was intended to indicate that a collector had The PEER_DOWN message was intended to indicate that a collector had
lost association with a BGP peer. However, the MRT format provides lost association with a BGP peer. However, the MRT format provides
BGP state change message types which duplicate this functionality. BGP state change message types that duplicate this functionality.
B.2. Other Deprecated MRT Types B.2. Other Deprecated MRT Types
5 BGP 5 BGP
6 RIP 6 RIP
7 IDRP 7 IDRP
8 RIPNG 8 RIPNG
9 BGP4PLUS 9 BGP4PLUS
10 BGP4PLUS_01 10 BGP4PLUS_01
B.2.1. BGP Type B.2.1. BGP Type
The BGP Type indicates the Message field contains BGP routing The BGP Type indicates that the Message field contains BGP routing
information. The BGP routing protocol is defined in RFC 4271 information. The BGP routing protocol is defined in RFC 4271
[RFC4271]. The information in the message is dependent on the [RFC4271]. The information in the message is dependent on the
Subtype value. The BGP Type and all associated Subtypes below are Subtype value. The BGP Type and all associated Subtypes below are
considered to be deprecated by the BGP4MP Type. considered to be deprecated by the BGP4MP Type.
The following BGP Subtypes are defined for the MRT BGP Type. As with The following BGP Subtypes are defined for the MRT BGP Type. As with
the BGP Type itself, they are all considered to be deprecated. the BGP Type itself, they are all considered to be deprecated.
0 BGP_NULL 0 BGP_NULL
1 BGP_UPDATE 1 BGP_UPDATE
skipping to change at page 30, line 47 skipping to change at page 28, line 21
6 BGP_NOTIFY 6 BGP_NOTIFY
7 BGP_KEEPALIVE 7 BGP_KEEPALIVE
B.2.1.1. BGP_NULL Subtype B.2.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype. The BGP_NULL Subtype is a reserved Subtype.
B.2.1.2. BGP_UPDATE Subtype B.2.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this Subtype is as follows: format of the MRT Message field for this subtype is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 21: BGP_UPDATE Subtype Figure 21: 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 that is generating the BGP
BGP UPDATE messages. The Local AS number and IP address fields UPDATE messages. The Local AS Number and IP Address fields contain
contain the AS number and IP address of the local collector system the AS number and IP address of the local collector system that is
which is archiving the messages. archiving the messages.
B.2.1.3. BGP_PREF_UPDATE Subtype B.2.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined. The BGP_PREF_UPDATE Subtype is not defined.
B.2.1.4. BGP_STATE_CHANGE Subtype B.2.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP
finite state machine. These FSM states are defined in RFC 4271 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 [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 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 BGP_STATE_CHANGE Subtype MRT Message field is as The format of the BGP_STATE_CHANGE Subtype MRT Message field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address | | Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: BGP_STATE_CHANGE Subtype Figure 22: BGP_STATE_CHANGE Subtype
B.2.1.5. BGP_SYNC Subtype B.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 MAY be recorded. The View # was to BGP Table Dump messages MAY be recorded. The View Number was to
correspond to the View # provided in the TABLE_DUMP Type records. correspond to the View Number provided in the TABLE_DUMP Type
There are no known implementations of this subtype and it SHOULD be records. There are no known implementations of this subtype, and it
ignored. The following format applies to this Subtype: SHOULD be 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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: BGP_SYNC Subtype Figure 23: BGP_SYNC Subtype
The File Name is terminated with a NULL (0) character. The File Name is terminated with a NULL (0) character.
B.2.1.6. BGP_OPEN Subtype B.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.
B.2.1.7. BGP_NOTIFY Subtype B.2.1.7. BGP_NOTIFY Subtype
The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages.
The format of the MRT Message field for this Subtype is the same as The format of the MRT Message field for this subtype is the same as
the BGP_UPDATE, however, the last field contains the contents of the the BGP_UPDATE; however, the last field contains the contents of the
BGP NOTIFICATION message. BGP NOTIFICATION message.
B.2.1.8. BGP_KEEPALIVE Subtype B.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.
B.2.2. RIP Type B.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 packets as defined in RFC 2453
2453 [RFC2453]. The Subtype field is currently reserved for this [RFC2453]. The Subtype field is currently reserved for this type and
Type and SHOULD be set to 0. SHOULD be set to 0.
The format of the MRT Message field for the RIP Type is as follows: The format of the MRT Message field for the RIP Type is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address | | Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP address | | Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable) | RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: RIP Type Figure 24: RIP Type
B.2.3. IDRP Type B.2.3. IDRP Type
The IDRP Type was intended to be used to export Inter-Domain-Routing The IDRP Type was intended to be used to export Inter-Domain Routing
Protocol (IDRP) protocol information as defined in the ISO/IEC 10747 Protocol (IDRP) information as defined in the ISO/IEC 10747 standard.
standard. However, this Type has seen no known use and there are no However, this type has seen no known use, and there are no details on
details on protocol encoding for this Type. protocol encoding for this type.
B.2.4. RIPNG Type B.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
RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to
support IPv6. The Subtype field is currently reserved for this Type support IPv6. The Subtype field is currently reserved for this type
and SHOULD be set to 0. and SHOULD be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows: The format of the MRT Message field for the RIPNG Type is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Peer IPv6 address ~ ~ Peer IPv6 Address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Local IPv6 address ~ ~ Local IPv6 Address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable) | RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: RIPNG Type Figure 25: RIPNG Type
B.2.5. BGP4PLUS and BGP4PLUS_01 Types B.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 that became RFC 4760, "Multiprotocol
BGP4PLUS_01 Type was specified to correspond to the -01 revision of Extensions to BGP-4". The BGP4PLUS_01 Type was specified to
this Internet Draft. The two Types share the same definitions in correspond to the -01 revision of that Internet-Draft. The two Types
terms of their MRT format specifications. share the same definitions in terms of their MRT format
specifications.
The Subtype field definitions are shared with the BGP Type, however, The Subtype field definitions are shared with the BGP Type; however,
the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to
16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP BGP4PLUS_01 Types are deprecated as they were superseded by the
Type. BGP4MP Type.
B.2.6. Deprecated BGP4MP Subtypes B.2.6. Deprecated BGP4MP Subtypes
The following two subtypes of the BGP4MP Type are considered to be The following two subtypes of the BGP4MP Type are considered to be
deprecated. deprecated.
2 BGP4MP_ENTRY 2 BGP4MP_ENTRY
3 BGP4MP_SNAPSHOT 3 BGP4MP_SNAPSHOT
B.2.6.1. BGP4MP_ENTRY Subtype B.2.6.1. BGP4MP_ENTRY Subtype
This Subtype is similar to the TABLE_DUMP Type and is used to record This subtype is similar to the TABLE_DUMP Type and is used to record
RIB table entries. It was intended to include true multiprotocol RIB table entries. It was intended to include true multiprotocol
support. However, this Subtype does not support 4-Byte AS numbers support. However, this subtype does not support 4-byte AS numbers
and has not been widely implemented. and has not been widely implemented.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Status | | View Number | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time last change | | Time Last Change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | SAFI | Next-Hop-Len | | Address Family | SAFI | Next-Hop-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address (variable) | | Next Hop Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: BGP4MP_ENTRY Subtype Figure 26: BGP4MP_ENTRY Subtype
B.2.6.2. BGP4MP_SNAPSHOT Subtype B.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 records MAY be recorded. It is similar to the BGP_SYNC BGP4MP_ENTRY records MAY be recorded. It is similar to the BGP_SYNC
Subtype and is deprecated. 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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: BGP4MP_SNAPSHOT Subtype Figure 27: BGP4MP_SNAPSHOT Subtype
Appendix C. Acknowledgements Appendix C. Acknowledgements
The initial MRT specification was developed by Craig Labovitz for use The initial MRT specification was developed by Craig Labovitz for use
in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type
was introduced in the Zebra routing software project by Kunihiro was introduced in the Zebra routing software project by Kunihiro
Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the
Python Routeing Toolkit (PyRT) developed by Richard Mortier while at Python Routing Toolkit (PyRT) developed by Richard Mortier while at
Sprint Advanced Technology Labs. Sprint Advanced Technology Labs.
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
Email: mkarir@merit.edu EMail: mkarir@merit.edu
Craig Labovitz Craig Labovitz
Deepfield Networks Deepfield Networks
Email: labovit@deepfield.net EMail: labovit@deepfield.net
 End of changes. 171 change blocks. 
352 lines changed or deleted 357 lines changed or added

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