draft-ietf-grow-mrt-10.txt   draft-ietf-grow-mrt-11.txt 
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft M. Karir Internet-Draft M. Karir
Intended status: Standards Track Merit Network Intended status: Standards Track Merit Network
Expires: January 14, 2010 C. Labovitz Expires: September 9, 2010 C. Labovitz
Arbor Networks Arbor Networks
July 13, 2009 March 8, 2010
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-10.txt draft-ietf-grow-mrt-11.txt
Abstract
This document describes the MRT format for routing information
export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state
changes, and routing information base contents.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes the MRT format for routing information described in the BSD License.
export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state
changes, and routing information base contents.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6
4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10
5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14
5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15
5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16
5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16
5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17
5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17
5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17
5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18
5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18
5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23
A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23
A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23
A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23
A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23
A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23
A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23
A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26
A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26
A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26
A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27
A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Researchers and engineers often wish to analyze network behavior by Researchers and engineers often wish to analyze network behavior by
skipping to change at page 10, line 30 skipping to change at page 10, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | Attribute Length | | Peer AS | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable) | BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The View field is normally 0 and is intended for cases where an The View field is normally 0 and is intended for cases where an
implementation may have multiple RIB views (such as a route server). implementation may have multiple RIB views (such as a route server).
The Sequence field is a simple incremental counter for each RIB In cases where multiple RIB views are present, an implementation may
entry. A typical RIB dump will exceed the 16-bit bounds of this use the the view field to distinguish entries from each view. The
counter and implementation should simply wrap back to zero and Sequence field is a simple incremental counter for each RIB entry. A
continue incrementing the counter in such cases. typical RIB dump will exceed the 16-bit bounds of this counter and
implementation should simply 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 message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
is 16 octets in length. The Prefix Length field indicates the length is 16 octets in length. The Prefix Length field indicates the length
in bits of the prefix mask for the preceding Prefix field. in bits of the prefix mask for the preceding Prefix field.
The Status octet is not used in the TABLE_DUMP Type and SHOULD be set The Status octet is not used in the TABLE_DUMP Type and SHOULD be set
to 1. to 1.
skipping to change at page 11, line 12 skipping to change at page 11, line 22
field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
octet field and an IPv6 address. The Peer AS field contains the AS octet field and an IPv6 address. The Peer AS field contains the AS
number of the peer. number of the peer.
Attribute length is the length of Attribute field and is 2-octets. Attribute length is the length of Attribute field and is 2-octets.
The Attribute field contains the attribute information for the RIB The Attribute field contains the attribute information for the RIB
entry. entry.
5.3. TABLE_DUMP_V2 Type 5.3. TABLE_DUMP_V2 Type
The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte
ASN support and full support for BGP Multiprotocol extensions. It ASN support and full support for BGP Multiprotocol extensions. It
also improves upon the space efficiency of the TABLE_DUMP Type by also improves upon the space efficiency of the TABLE_DUMP Type by
employing an index table for peers and permitting a single MRT record employing an index table for peers and permitting a single MRT record
per NLRI entry. The following subtypes are used with the per NLRI entry. The following subtypes are used with the
TABLE_DUMP_V2 Type. TABLE_DUMP_V2 Type.
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
skipping to change at page 14, line 11 skipping to change at page 14, line 24
This Type was initially defined in the Zebra software package for the This Type was initially defined in the Zebra software package for the
BGP protocol with multiprotocol extension support as defined by RFC BGP protocol with multiprotocol extension support as defined by RFC
4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
The BGP4MP Type has six Subtypes which are defined as follows: The BGP4MP Type has six Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
4 BGP4MP_MESSAGE_AS4 4 BGP4MP_MESSAGE_AS4
5 BGP4MP_STATE_CHANGE_AS4 5 BGP4MP_STATE_CHANGE_AS4
6 BGP4MP_MESSAGE_LOCAL
7 BGP4MP_MESSAGE_AS4_LOCAL
5.4.1. BGP4MP_STATE_CHANGE Subtype 5.4.1. BGP4MP_STATE_CHANGE Subtype
This record is used to encode state changes in the BGP finite state This record is used to encode state changes in the BGP finite state
machine. The BGP FSM states are encoded in the Old State and New machine. The BGP FSM states are encoded in the Old State and New
State fields to indicate the previous and current state. The format State fields to indicate the previous and current state. In some
is illustrated below: cases, the Peer AS number may be undefined. In such cases, the value
of this field may be set to zero. The format is illustrated below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 11 skipping to change at page 15, line 30
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 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
5.4.2. BGP4MP_MESSAGE Subtype 5.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. In order to determine the BGP encode any Type of BGP message. The entire BGP message is
message Type, the entire BGP message is included in the BGP Message encapsulated in the BGP Message field, including the 16-octet marker,
field. This includes the 16-octet marker, the 2-octet length, and the 2-octet length, and the 1-octet type fields. Note that the
the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further,
not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the AS_PATH contained in these messages MUST only consist of 2-Byte
the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the
BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The
BGP4MP_MESSAGE fields are shown below: BGP4MP_MESSAGE fields are shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | Local AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP address (variable) | | Peer IP address (variable) |
skipping to change at page 15, line 50 skipping to change at page 16, line 22
2 AFI_IPv6 2 AFI_IPv6
Note that the Address Family value only applies to the IP addresses Note that the Address Family value only applies to the IP addresses
contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise
transparent to the contents of the actual message which may contain transparent to the contents of the actual message which may contain
any valid AFI/SAFI values. Only one BGP message may be encoded in any valid AFI/SAFI values. Only one BGP message may be encoded in
the BGP4MP_MESSAGE Subtype. the BGP4MP_MESSAGE Subtype.
5.4.3. BGP4MP_MESSAGE_AS4 Subtype 5.4.3. BGP4MP_MESSAGE_AS4 Subtype
This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte
Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
otherwise identical to the BGP4MP_MESSAGE Subtype. The otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in
these messages MUST only consist of 4-Byte AS numbers. The
BGP4MP_MESSAGE_AS4 fields are shown below: BGP4MP_MESSAGE_AS4 fields are shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype
This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support
Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE
the BGP FSM states are encoded in the Old State and New State fields Subtype, the BGP FSM states are encoded in the Old State and New
to indicate the previous and current state. Aside from the extension State fields to indicate the previous and current state. Aside from
of the peer and local AS fields to 32 bits, this subtype is otherwise the extension of the peer and local AS fields to 4-Bytes, this
identical to the BGP4MP_STATE_CHANGE Subtype. The subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype.
BGP4MP_STATE_CHANGE_AS4 fields are shown below: The 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5. BGP4MP_MESSAGE_LOCAL Subtype
Implementations of MRT have largely focused on collecting remotely
generated BGP messages in a passive route collector role. However,
for active BGP implementations, it can be useful to archive locally
generated BGP messages in addition to remote messages. This subtype
is added to indicated a locally generated BGP message. The fields
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 number of the collector which generated the message
and the Peer IP and AS fields refer to the receipient of the
generated BGP messages.
5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype
As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally
generated messages. The fields are identical to the
BGP4MP_MESSAGE_AS4 message type.
5.5. BGP4MP_ET Type 5.5. BGP4MP_ET Type
This Type was initially defined in the Sprint Labs Python Routing This Type was initially defined in the Sprint Labs Python Routing
Toolkit (PyRT). It extends the MRT common header field to include a Toolkit (PyRT). It extends the MRT common header field to include a
32BIT microsecond timestamp field. The type and subtype field 32BIT microsecond timestamp field. The type and subtype field
definitions remain as defined for the BGP4MP Type. The 32BIT definitions remain as defined for the BGP4MP Type. The 32BIT
microsecond timestamp immediately follows the length field in the MRT microsecond timestamp immediately follows the length field in the MRT
common header and precedes all other fields in the message. The common header and precedes all other fields in the message. The
32BIT microsecond field is included in the computation of the length 32BIT microsecond field is included in the computation of the length
field value. The MRT common header modification is illustrated field value. The MRT common header modification is illustrated
skipping to change at page 19, line 19 skipping to change at page 20, line 19
specification, in accordance with BCP 26, RFC 5226 [RFC5226]. specification, in accordance with BCP 26, RFC 5226 [RFC5226].
There are two name spaces in MRT that require registration: Type There are two name spaces in MRT that require registration: Type
Codes and Subtype Codes. Codes and Subtype Codes.
MRT is not intended as a general-purpose specification for protocol MRT is not intended as a general-purpose specification for protocol
information export, and allocations should not be made for purposes information export, and allocations should not be made for purposes
unrelated to routing protocol information export. unrelated to routing protocol information export.
The following policies are used here with the meanings defined in BCP The following policies are used here with the meanings defined in BCP
26: "Specification Required", "IETF Consensus". 26: "Specification Required", "IETF Consensus", "Experimental Use",
"First Come First Served".
6.1. Type Codes 6.1. Type Codes
Type Codes have a range from 0 to 65535, of which 0-64 have been Type Codes have a range from 0 to 65535, of which 1-64 have been
allocated. New Type Codes MUST be allocated starting at 65. Type allocated. New Type Codes MUST be allocated starting at 65. Type
Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 -
32768 - 65535 are assigned based on Specification Required. 2047 are assigned based on Specification Required. Type Codes 2048 -
64511 are available on a First Come First Served policy. Type Codes
64512 - 65534 are available for Experimental Use. The Type Code
Values of 0 and 65535 are reserved.
6.2. Subtype Codes 6.2. Subtype Codes
Subtype Codes have a range from 0 to 65535. Subtype definitions are Subtype Codes have a range from 0 to 65535. Subtype definitions are
specific to a particular Type Code definition. New Subtype Code specific to a particular Type Code definition. New Subtype Code
definition must reference an existing Type Code to which the Subtype definition must reference an existing Type Code to which the Subtype
belongs. As Subtype Codes are specific to Type Codes, new numbers belongs. Subtype assignmnents to Type Codes 0 - 511 are to be
must be unique for the particular Type Code to which the Subtype assigned by IETF Review. Subtype assignments for the remaning Type
applies. Subtype Codes specific to the Type Codes 0 - 32767 are Codes follow the assignment rules for the Type Codes to which they
assigned by IETF Consensus. Subtype Codes specific to Type Codes belong.
32768 - 65535 are assigned based on Specification Required.
7. Security Considerations 7. Security Considerations
The MRT Format utilizes a structure which can store routing protocol The MRT Format utilizes a structure which can store routing protocol
information data. The fields defined in the MRT specification are of information data. The fields defined in the MRT specification are of
a descriptive nature and provide information that is useful to a descriptive nature and provide information that is useful to
facilitate the analysis of routing data. As such, the fields facilitate the analysis of routing data. As such, the fields
currently defined in the MRT specification do not in themselves currently defined in the MRT specification do not in themselves
create additional security risks, since the fields are not used to create additional security risks, since the fields are not used to
induce any particular behavior by the recipient application. induce any particular behavior by the recipient application.
skipping to change at page 26, line 47 skipping to change at page 27, line 47
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
A.2.6.1. BGP4MP_ENTRY Subtype A.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 extends the TABLE_DUMP Type to include true RIB table entries. It extends the TABLE_DUMP Type to include true
multiprotocol support. However, this Type does not support 32BIT AS multiprotocol support. However, this Type does not support 4-Byte AS
numbers and has not been widely implemented. This Type is deprecated numbers and has not been widely implemented. This Type is deprecated
in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support
and a more compact format. and a more compact format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
 End of changes. 26 change blocks. 
77 lines changed or deleted 112 lines changed or added

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