draft-ietf-grow-mrt-06.txt   draft-ietf-grow-mrt-07.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: May 22, 2008 C. Labovitz Expires: August 28, 2008 C. Labovitz
Arbor Networks Arbor Networks
November 19, 2007 February 25, 2008
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-06.txt draft-ietf-grow-mrt-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the MRT format for routing information This document describes the MRT format for routing information
export. This format was developed in concert with the Multi-threaded export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state format can be used to export routing protocol messages, state
changes, and routing information base contents. changes, and routing information base contents.
Table of Contents Table of Contents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10
5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10
5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11
5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11
5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11
5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12
5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12
5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12
5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12
5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13
5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14
5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14
5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16
5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18
5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19
5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20
5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20
5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 21 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 22
5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22
5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 22 5.10. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 23
5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23
5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23
5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23
5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 6, line 5 skipping to change at page 5, line 24
format was initially defined in the MRT Programmer's Guide [MRT PROG format was initially defined in the MRT Programmer's Guide [MRT PROG
GUIDE]. GUIDE].
This memo serves to document the MRT format as currently implemented This memo serves to document the MRT format as currently implemented
in publicly available software. The format has been extended since in publicly available software. The format has been extended since
it's original introduction in the MRT toolset and these extensions it's original introduction in the MRT toolset and these extensions
are also included in this memo. Further extensions may be introduced are also included in this memo. Further extensions may be introduced
at a later date through additional definitions of the MRT Type field at a later date through additional definitions of the MRT Type field
and Subtype fields. and Subtype fields.
Fields which contain multi-byte numeric values are encoded in network
byte order from most significant byte to least significant byte.
Fields which contain routing message fields are encoded in the same
order as they appear in the packet contents.
3. Basic MRT Format 3. Basic MRT Format
All MRT format messages have a common header which includes a All MRT format messages have a common header which includes a
timestamp, Type, Subtype, and length field. The header is followed timestamp, Type, Subtype, and length field. The header is followed
by a message field. The 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 |
skipping to change at page 10, line 43 skipping to change at page 10, line 43
[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 are Subtype value. The BGP Type and all associated Subtypes 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. The following BGP Subtypes are defined for the MRT BGP Type.
0 BGP_NULL 0 BGP_NULL
1 BGP_UPDATE 1 BGP_UPDATE
2 BGP_PREF_UPDATE 2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE 3 BGP_STATE_CHANGE
4 BGP_SYNC *DEPRECATED* 4 BGP_SYNC
5 BGP_OPEN 5 BGP_OPEN
6 BGP_NOTIFY 6 BGP_NOTIFY
7 BGP_KEEPALIVE 7 BGP_KEEPALIVE
5.1.1. BGP_NULL Subtype 5.1.1. BGP_NULL Subtype
The BGP_NULL Subtype is a reserved Subtype. The BGP_NULL Subtype is a reserved Subtype.
5.1.2. BGP_UPDATE Subtype 5.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this Subtype is as follows: format of the MRT Message field for this Subtype is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number | | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable) | BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE contents include the entire BGP UPDATE message which The BGP UPDATE Contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not follows the BGP Message Header. The BGP Message Header itself is not
included. included. The Peer AS number and IP address fields contain the AS
number and IP address of the remote system which are generating the
BGP UPDATE messages. The Local AS number and IP address fields
contain the AS number and IP address of the local collector system
which is archiving the messages.
5.1.3. BGP_PREF_UPDATE Subtype 5.1.3. BGP_PREF_UPDATE Subtype
The BGP_PREF_UPDATE Subtype is not defined. The BGP_PREF_UPDATE Subtype is not defined.
5.1.4. BGP_STATE_CHANGE Subtype 5.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states and their numeric encodings finite state machine. These FSM states are defined in RFC 4271
are defined in RFC 4271 [RFC4271], Appendix 1. Both the old state [RFC4271], Section 8.2.2. Both the old state value and the new state
value and the new state value are encoded as 2-octet numbers. The value are encoded as 2-octet numbers. The state values are defined
format of the MRT Message field is as follows: numerically as follows:
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Established
The format of the MRT Message field is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.5. BGP_SYNC Subtype 5.1.5. BGP_SYNC Subtype
The BGP_SYNC Subtype was intended to convey a system file name where The BGP_SYNC Subtype was intended to convey a system file name where
BGP Table Dump messages should be recorded. The View # was to BGP Table Dump messages should be recorded. The View # was to
correspond to the View # provided in the TABLE_DUMP Type messages. correspond to the View # provided in the TABLE_DUMP Type messages.
This Type is considered to be deprecated. The following format There are no known implementations of this subtype and it SHOULD be
applies to this Subtype: ignored. The following format applies to this Subtype:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | | View # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The File Name is terminated with a NULL (0) character. The File Name is terminated with a NULL (0) character.
skipping to change at page 13, line 8 skipping to change at page 13, line 16
The RIP Type is used to export RIP protocol packets as defined in RFC The RIP Type is used to export RIP protocol packets as defined in RFC
1058 [RFC1058]. The Subtype field is currently reserved for this 1058 [RFC1058]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0. Type and SHOULD be set to 0.
The format of the MRT Message field for the RIP Type is as follows: The format of the MRT Message field for the RIP Type is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable) | RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. IDRP Type 5.3. IDRP Type
The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
protocol information as defined in the ISO/IEC 10747 standard. The protocol information as defined in the ISO/IEC 10747 standard. The
Subtype field is unused. This Type is deprecated due to lack of Subtype field is unused. This Type is deprecated due to lack of
deployment of IDRP. deployment of IDRP.
skipping to change at page 13, line 33 skipping to change at page 13, line 41
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 Subtype field is currently reserved for this RFC 2080 [RFC2080]. The Subtype field is currently reserved for this
Type and SHOULD be set to 0. Type and SHOULD be set to 0.
The format of the MRT Message field for the RIPNG Type is as follows: The format of the MRT Message field for the RIPNG Type is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable) | RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. BGP4PLUS and BGP4PLUS_01 Types 5.5. BGP4PLUS and BGP4PLUS_01 Types
The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
routing information. The BGP4PLUS Type was specified based on the routing information. The BGP4PLUS Type was specified based on the
initial Internet Draft for Multiprotocol Extensions to BGP-4. The initial Internet Draft for Multiprotocol Extensions to BGP-4. The
BGP4PLUS_01 Type was specified to correspond to the -01 revision of BGP4PLUS_01 Type was specified to correspond to the -01 revision of
skipping to change at page 14, line 20 skipping to change at page 14, line 28
[RFC2328]. The Subtype field may contain two possible values: [RFC2328]. The Subtype field may contain two possible values:
0 OSPF_STATE_CHANGE 0 OSPF_STATE_CHANGE
1 OSPF_LSA_UPDATE 1 OSPF_LSA_UPDATE
The format of the MRT Message field for the OSPF Type is as follows: The format of the MRT Message field for the OSPF Type is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address | | Remote IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address | | Local IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. TABLE_DUMP Type 5.7. TABLE_DUMP Type
The TABLE_DUMP Type is used to encode the contents of a BGP Routing The TABLE_DUMP Type is used to encode the contents of a BGP Routing
Information Base (RIB). Each RIB entry is encoded in a distinct Information Base (RIB). Each RIB entry is encoded in a distinct
sequential MRT record. The Subtype field is used to encode whether sequential MRT record. The Subtype field is used to encode whether
the RIB entry contains IPv4 or IPv6 addresses. There are two the RIB entry contains IPv4 or IPv6 addresses. There are two
skipping to change at page 15, line 30 skipping to change at page 15, line 30
| 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 The Sequence field is a simple incremental counter for each RIB
entry. A typical RIB dump will exceed the 16-bit bounds of this entry. A typical RIB dump will exceed the 16-bit bounds of this
counter and implementation should simply wrap back to zero and counter and implementation should simply wrap back to zero and
continue incrementing the counter in such cases. continue incrementing the counter in such cases.
The Prefix field contains the IP address of a particular routing RIB The Prefix field contains the IP address of a particular RIB entry.
entry. The size of this field is dependent on the value of the The size of this field is dependent on the value of the Subtype for
Subtype for this message. For AFI_IPv4, this field is 4 octets, for this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
AFI_IPv6, it is 16 octets in length. The Prefix Length field is 16 octets in length. The Prefix Length field indicates the length
indicates the length in bits of the prefix mask for the preceding in bits of the prefix mask for the preceding Prefix field.
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.
The Originated Time contains the 4-octet time at which this prefix The Originated Time contains the 4-octet time at which this prefix
was heard. The value represents the time in seconds since 1 January was heard. The value represents the time in seconds since 1 January
1970 00:00:00 UTC. 1970 00:00:00 UTC.
The Peer IP field is the IP address of the peer which provided the The Peer IP field is the IP address of the peer which provided the
update for this RIB entry. As with the Prefix field, the size of update for this RIB entry. As with the Prefix field, the size of
skipping to change at page 16, line 8 skipping to change at page 16, line 7
field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
octet field and an IPv6 address. The Peer AS field contains the AS octet field and an IPv6 address. The Peer AS field contains the AS
number of the peer. number of the peer.
Attribute length is the length of Attribute field and is 2-octets. Attribute length is the length of Attribute field and is 2-octets.
The Attribute field contains the attribute information for the RIB The Attribute field contains the attribute information for the RIB
entry. entry.
5.8. TABLE_DUMP_V2 Type 5.8. TABLE_DUMP_V2 Type
The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32-bit The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT
ASN support and full support for BGP Multiprotocol extensions. It ASN support and full support for BGP Multiprotocol extensions. It
also improves upon the space efficiency of the TABLE_DUMP Type by also improves upon the space efficiency of the TABLE_DUMP Type by
employing an index table for peers and permitting a single MRT record employing an index table for peers and permitting a single MRT record
per NLRI entry. The following subtypes are used with the per NLRI entry. The following subtypes are used with the
TABLE_DUMP_V2 Type. TABLE_DUMP_V2 Type.
1 PEER_INDEX_TABLE 1 PEER_INDEX_TABLE
2 RIB_IPV4_UNICAST 2 RIB_IPV4_UNICAST
3 RIB_IPV4_MULTICAST 3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST 4 RIB_IPV6_UNICAST
5 RIB_IPV6_MULTICAST 5 RIB_IPV6_MULTICAST
6 RIB_GENERIC 6 RIB_GENERIC
An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
collector, an optional view name, and a list of indexed peers. collector, an optional view name, and a list of indexed peers.
Following the PEER_INDEX_TABLE MRT record, a series of MRT records Following the PEER_INDEX_TABLE MRT record, a series of MRT records
are used to encode RIB table entries. The header of the are used to encode RIB table entries. This series of MRT records use
subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record
itself and include full MRT record headers. The header of the
PEER_INDEX_TABLE Subtype is shown below. The View Name is optional PEER_INDEX_TABLE Subtype is shown below. The View Name is optional
and, if not present, the View Name Length MUST be set to 0. The View and, if not present, the View Name Length MUST be set to 0. The View
Name encoding MUST follow the UTF-8 transformation format. Name encoding MUST follow the UTF-8 transformation format.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID | | Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length | View Name (variable) | | View Name Length | View Name (variable) |
skipping to change at page 19, line 5 skipping to change at page 19, line 5
MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop
Address fields are included. The Reserved field is omitted. The Address fields are included. The Reserved field is omitted. The
attribute length is also adjusted to reflect only the length of the attribute length is also adjusted to reflect only the length of the
Next Hop Address Length and Next Hop Address fields. Next Hop Address Length and Next Hop Address fields.
5.9. BGP4MP Type 5.9. BGP4MP Type
This Type was initially defined in the Zebra software package for the This Type was initially defined in the Zebra software package for the
BGP protocol with multiprotocol extension support as defined by RFC BGP protocol with multiprotocol extension support as defined by RFC
4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
The BGP4MP Type has four Subtypes which are defined as follows: The BGP4MP Type has six Subtypes which are defined as follows:
0 BGP4MP_STATE_CHANGE 0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE 1 BGP4MP_MESSAGE
2 BGP4MP_ENTRY *DEPRECATED* 2 BGP4MP_ENTRY *DEPRECATED*
3 BGP4MP_SNAPSHOT *DEPRECATED* 3 BGP4MP_SNAPSHOT *DEPRECATED*
4 BGP4MP_STATE_CHANGE_AS4 4 BGP4MP_STATE_CHANGE_AS4
5 BGP4MP_MESSAGE_AS4 5 BGP4MP_MESSAGE_AS4
5.9.1. BGP4MP_STATE_CHANGE Subtype 5.9.1. BGP4MP_STATE_CHANGE Subtype
This record is used to encode state changes in the BGP finite state This record is used to encode state changes in the BGP finite state
machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states
are encoded in the Old State and New State fields to indicate the are encoded in the Old State and New State fields to indicate the
previous and current state. The format is illustrated below: previous and current state. The format is illustrated below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE
message, it also includes interface index and Address Family fields. message, it also includes interface index and Address Family fields.
As with the BGP_STATE_CHANGE message, the FSM states and their As with the BGP_STATE_CHANGE message, the FSM states are defined in
numeric encodings are defined in RFC 4271 [RFC4271], Appendix 1. The RFC 4271 [RFC4271], Section 8.2.2 with the numeric values for these
interface index provides the interface number of the peering session. states defined inthe BGP_STATE_CHANGE section. The interface index
The index value is OPTIONAL and MAY be zero if unknown or provides the interface number of the peering session. The index
unsupported. The Address Family indicates what types of addresses value is OPTIONAL and MAY be zero if unknown or unsupported. The
are in the the address fields. At present, the following AFI Types Address Family indicates what types of addresses are in the the
are supported: address fields. At present, the following AFI Types are supported:
1 AFI_IPv4 1 AFI_IPv4
2 AFI_IPv6 2 AFI_IPv6
5.9.2. BGP4MP_MESSAGE Subtype 5.9.2. BGP4MP_MESSAGE Subtype
This Subtype is used to encode BGP Messages. It is similar to the This Subtype is used to encode BGP Messages. It is similar to the
BGP_UPDATE Subtype, except that is can be used to encode any Type of BGP_UPDATE Subtype, except that is can be used to encode any Type of
message (not just BGP UPDATES). In order to determine the BGP message (not simply BGP UPDATES). In order to determine the BGP
message Type, the entire BGP message, including the BGP header, is message Type, the entire BGP message is included in the BGP Message
included in the BGP Message field. The BGP4MP_MESSAGE fields are field. This includes 16-octet marker, 2-ocet length, and 1-octet
shown below: type fields. Note that the BGP4MP_MESSAGE Subtype does not support
32BIT AS numbers nor IPv6 addresses. The BGP4MP_MESSAGE_AS4 Subtype
updates the BGP4MP_MESSAGE Subtype in order to support these. The
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The interface index provides the interface number of the peering The interface index provides the interface number of the peering
session. The index value is OPTIONAL and MAY be zero if unknown or session. The index value is OPTIONAL and MAY be zero if unknown or
unsupported. The Address Family indicates what types of addresses unsupported. The Address Family indicates what types of addresses
are in the the subsequent address fields. At present, the following are in the the subsequent address fields. At present, the following
AFI Types are supported: AFI Types are supported:
skipping to change at page 20, line 47 skipping to change at page 20, line 50
Note that the Address Family value only applies to the IP addresses Note that the Address Family value only applies to the IP addresses
contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise
transparent to the contents of the actual message which may contain transparent to the contents of the actual message which may contain
any valid AFI/SAFI values. Only one BGP message may be encoded in any valid AFI/SAFI values. Only one BGP message may be encoded in
the BGP4MP_MESSAGE Subtype. the BGP4MP_MESSAGE Subtype.
5.9.3. BGP4MP_ENTRY Subtype 5.9.3. 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 32-bit AS multiprotocol support. However, this Type does not support 32BIT 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 32-bit AS number support in favor of the TABLE_DUMP_V2 which includes 32BIT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number | | Peer AS number | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View # | Status | | View # | 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 |
skipping to change at page 22, line 4 skipping to change at page 22, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable) | File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype
This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT
Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype,
the BGP FSM states are encoded in the Old State and New State fields the BGP FSM states are encoded in the Old State and New State fields
to indicate the previous and current state. Aside from the extension to indicate the previous and current state. Aside from the extension
of the source and destination AS fields to 32 bits, this subtype is of the peer and local AS fields to 32 bits, this subtype is otherwise
otherwise identical to the BGP4MP_STATE_CHANGE Subtype. The identical to the BGP4MP_STATE_CHANGE Subtype. The
BGP4MP_STATE_CHANGE_AS4 fields are shown below: BGP4MP_STATE_CHANGE_AS4 fields are shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number | | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State | | Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.9.6. BGP4MP_MESSAGE_AS4 Subtype 5.9.6. BGP4MP_MESSAGE_AS4 Subtype
This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
below: otherwise identical to the BGP4MP_MESSAGE Subtype. The
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | | Peer AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number | | Local AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family | | Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Peer IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable) | BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.10. BGP4MP_ET 5.10. 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
32-bit 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 32-bit 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 32- common header and precedes all other fields in the message. The
bit microsecond field is included in the computation of the length 32BIT microsecond field is included in the computation of the length
field value. The MRT common header modification is illustrated field value. The MRT common header modification is illustrated
below. below.
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 23, line 34 skipping to change at page 23, line 41
5.11. ISIS Type 5.11. ISIS Type
This Type was initially defined in the Sprint Labs Python Routing and This Type was initially defined in the Sprint Labs Python Routing and
supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195].
There is no Type specific header for the ISIS Type. The Subtype code There is no Type specific header for the ISIS Type. The Subtype code
for this Type is undefined. The ISIS PDU directly follows the MRT for this Type is undefined. The ISIS PDU directly follows the MRT
common header fields. common header fields.
5.12. ISIS_ET Type 5.12. ISIS_ET Type
The ISIS_ET Type extends the the ISIS Type to support microsecond The ISIS_ET Type extends the ISIS Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
timestamp field is appended to the MRT common header after the length timestamp field is appended to the MRT common header after the length
field. The ISIS_ET Type is otherwise identical to the ISIS Type. field. The ISIS_ET Type is otherwise identical to the ISIS Type.
5.13. OSPFv3 Type 5.13. OSPFv3 Type
The OSPFv3 Type extends the original OSPF Type to support IPv6 The OSPFv3 Type extends the original OSPF Type to support IPv6
addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740].
The format of the MRT Message field for the OSPFv3 Type is as The format of the MRT Message field for the OSPFv3 Type is as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) | | Remote IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) | | Local IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable) | OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.14. OSPFv3_ET Type 5.14. OSPFv3_ET Type
The OSPFv3_ET Type extends the the OSPFv3 Type to support microsecond The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond
timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
timestamp field is appended to the MRT common header after the length timestamp field is appended to the MRT common header after the length
field and its length is included in the calculation of the length field and its length is included in the calculation of the length
field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
Type. Type.
6. IANA Considerations 6. IANA Considerations
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 2434 [RFC2434]. specification, in accordance with BCP 26, RFC 2434 [RFC2434].
skipping to change at page 29, line 7 skipping to change at page 29, line 7
Email: mkarir@merit.edu Email: mkarir@merit.edu
Craig Labovitz Craig Labovitz
Arbor Networks Arbor Networks
Email: labovit@arbor.net Email: labovit@arbor.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 61 change blocks. 
84 lines changed or deleted 107 lines changed or added

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