idnits 2.17.1 draft-ietf-grow-mrt-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2010) is 4968 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1723 (Obsoleted by RFC 2453) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Blunk 3 Internet-Draft M. Karir 4 Intended status: Standards Track Merit Network 5 Expires: March 13, 2011 C. Labovitz 6 Arbor Networks 7 September 9, 2010 9 MRT routing information export format 10 draft-ietf-grow-mrt-12.txt 12 Abstract 14 This document describes the MRT format for routing information 15 export. This format was developed in concert with the Multi-threaded 16 Routing Toolkit (MRT) from whence the format takes it name. The 17 format can be used to export routing protocol messages, state 18 changes, and routing information base contents. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 70 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 72 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 73 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 75 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 76 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 15 78 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 16 79 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 17 80 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 17 81 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 18 82 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 18 83 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 18 84 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 19 85 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 19 87 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 20 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 7.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 22 91 7.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 22 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 96 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 25 97 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 25 98 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 25 99 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 25 100 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 25 101 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 25 102 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 25 103 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 28 104 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 28 105 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 29 106 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 29 107 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 29 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 110 1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Introduction 118 Researchers and engineers often wish to analyze network behavior by 119 studying routing protocol transactions and routing information base 120 snapshots. To this end, the MRT format was developed to encapsulate, 121 export, and archive this information in a standardized data 122 representation. The BGP routing protocol, in particular, has been 123 the subject of extensive study and analysis which has been 124 significantly aided by the availability of the MRT format. The MRT 125 format was initially defined in the MRT Programmer's Guide [MRT PROG 126 GUIDE]. 128 This memo serves to document the MRT format as currently implemented 129 in publicly available software. The format has been extended since 130 its original introduction in the MRT toolset and these extensions are 131 also included in this memo. Further extensions may be introduced at 132 a later date through additional definitions of the MRT Type field and 133 Subtype fields. 135 A number of MRT message types have been documented in some references 136 but are not known to have been implemented. Further, several types 137 were employed in early MRT implementations, but are no longer 138 actively being used. These types are considered to be deprecated and 139 are documented in a separate appendix at the end of this document. 140 Some of the deprecated types may of interest to researchers examining 141 historical MRT archives. 143 Fields which contain multi-octet numeric values are encoded in 144 network octet order from most significant octet to least significant 145 octet. Fields which contain routing message fields are encoded in 146 the same order as they appear in the packet contents. 148 3. Basic MRT Format 150 All MRT format messages have a common header which includes a 151 timestamp, Type, Subtype, and length field. The header is followed 152 by a message field. The MRT common header is illustrated below. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Timestamp | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Subtype | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Message... (variable) 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1: Basic MRT Format 168 Header Field Descriptions: 170 Timestamp: 172 Time in seconds since 1 January 1970 00:00:00 UTC 174 Type: 176 A 2-octet field that indicates the Type of information 177 contained in the message field. Types 0 through 4 are 178 informational messages pertaining to the state of an MRT 179 collector, while Types 5 and higher are used to convey routing 180 information. 182 Subtype: 184 A 2-octet field that is used to further distinguish message 185 information within a particular message Type. 187 Length: 189 A 4-octet message length field. The length field contains the 190 number of octets within the message. The length field does not 191 include the length of the MRT common header. 193 Message: 195 A variable length message. The contents of this field are 196 context dependent upon the Type and Subtype fields. 198 4. MRT Informational Types 200 The MRT format defines five Informational Type messages. These 201 messages are intended to signal the state of an MRT data collector 202 and do not contain routing information. These messages are OPTIONAL 203 and were largely intended for use when MRT messages are sent over a 204 network to a remote repository store. However, MRT message 205 repository stores have traditionally resided on the same device as 206 the collector and these Informational Types have seen limited 207 implementation. Further, transport mechanisms for MRT messages are 208 considered to be outside the scope of this document. 210 The START and I_AM_DEAD messages MAY be used to provide a time 211 reference when a data collector begins and ends the collection 212 process. The time reference is obtained from the Timestamp field in 213 the MRT message header. 215 The message field MAY contain an OPTIONAL message string for 216 diagnostic purposes. The message string encoding MUST follow the 217 UTF-8 transformation format. The Subtype field is unused for these 218 Types and SHOULD be set to 0. 220 The MRT Informational Types are defined below: 222 1 START 223 3 I_AM_DEAD 225 4.1. START Type 227 The START Type indicates a collector is about to begin generating MRT 228 messages. 230 4.2. I_AM_DEAD Type 232 An I_AM_DEAD MRT message indicates that a collector has shut down and 233 has stopped generating MRT messages. 235 5. MRT Routing Information Types 237 The following MRT Routing Information Types are currently defined for 238 the MRT format: 240 11 OSPF 241 12 TABLE_DUMP 242 13 TABLE_DUMP_V2 243 16 BGP4MP 244 17 BGP4MP_ET 245 32 ISIS 246 33 ISIS_ET 247 48 OSPFv3 248 49 OSPFv3_ET 250 5.1. OSPF Type 252 This Type supports the OSPF Protocol as defined in RFC 2328 253 [RFC2328]. The Subtype field may contain two possible values: 255 0 OSPF_STATE_CHANGE 256 1 OSPF_LSA_UPDATE 258 The format of the MRT Message field for the OSPF Type is as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Remote IP address | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Local IP address | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | OSPF Message Contents (variable) 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2: OSPF Type 272 5.2. TABLE_DUMP Type 274 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 275 Information Base (RIB). Each RIB entry is encoded in a distinct 276 sequential MRT record. The Subtype field is used to encode whether 277 the RIB entry contains IPv4 or IPv6 addresses. There are two 278 possible values for the Subtype as shown below. 280 1 AFI_IPv4 281 2 AFI_IPv6 283 The format of the TABLE_DUMP Type is illustrated below. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | View # | Sequence number | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Prefix (variable) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Prefix Length | Status | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Originated Time | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Peer IP address (variable) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Peer AS | Attribute Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | BGP Attribute... (variable) 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3: TABLE_DUMP Type 305 The View field is normally 0 and is intended for cases where an 306 implementation may have multiple RIB views (such as a route server). 307 In cases where multiple RIB views are present, an implementation may 308 use the the view field to distinguish entries from each view. The 309 Sequence field is a simple incremental counter for each RIB entry. A 310 typical RIB dump will exceed the 16-bit bounds of this counter and 311 implementation should simply wrap back to zero and continue 312 incrementing the counter in such cases. 314 The Prefix field contains the IP address of a particular RIB entry. 315 The size of this field is dependent on the value of the Subtype for 316 this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it 317 is 16 octets in length. The Prefix Length field indicates the length 318 in bits of the prefix mask for the preceding Prefix field. 320 The Status octet is unused in the TABLE_DUMP Type and SHOULD be set 321 to 1. 323 The Originated Time contains the 4-octet time at which this prefix 324 was heard. The value represents the time in seconds since 1 January 325 1970 00:00:00 UTC. 327 The Peer IP field is the IP address of the peer which provided the 328 update for this RIB entry. As with the Prefix field, the size of 329 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 330 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 331 octet field and an IPv6 address. The Peer AS field contains the 2 332 octet AS number of the peer. 334 Note that the TABLE_DUMP Type does not permit 4-Byte Peer AS numbers. 335 Nor does it allow the AFI of the peer IP to differ from the AFI of 336 the Prefix field. The TABLE_DUMP_V2 Type must be used in these 337 situations. 339 Attribute Length contains the length of Attribute field and is 340 2-octets. The BGP Attribute field contains the BGP attribute 341 information for the RIB entry. 343 5.3. TABLE_DUMP_V2 Type 345 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte 346 ASN support and full support for BGP Multiprotocol extensions. It 347 also improves upon the space efficiency of the TABLE_DUMP Type by 348 employing an index table for peers and permitting a single MRT record 349 per NLRI entry. The following subtypes are used with the 350 TABLE_DUMP_V2 Type. 352 1 PEER_INDEX_TABLE 353 2 RIB_IPV4_UNICAST 354 3 RIB_IPV4_MULTICAST 355 4 RIB_IPV6_UNICAST 356 5 RIB_IPV6_MULTICAST 357 6 RIB_GENERIC 359 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 360 collector, an optional view name, and a list of indexed peers. 361 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 362 are used to encode RIB table entries. This series of MRT records use 363 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 364 itself and include full MRT record headers. Note that the RIB entry 365 MRT records MUST immediately follow the PEER_INDEX_TABLE MRT record. 367 The header of the PEER_INDEX_TABLE Subtype is shown below. The View 368 Name is optional and, if not present, the View Name Length MUST be 369 set to 0. The View Name encoding MUST follow the UTF-8 370 transformation format. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Collector BGP ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | View Name Length | View Name (variable) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Peer Count | Peer Entries (variable) 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 4: PEER_INDEX_TABLE Subtype 384 The format of the Peer Entries is shown below. The PEER_INDEX_TABLE 385 record contains Peer Count number of Peer Entries. 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Peer Type | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Peer BGP ID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Peer IP address (variable) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Peer AS (variable) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 5: Peer Entries 401 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 402 as indicated by the Peer Count field. The position of the Peer in 403 the PEER_INDEX_TABLE is used as an index in the subsequent 404 TABLE_DUMP_V2 MRT records. The index number begins with 0. 406 The Peer Type field is a bit field which encodes the type of the AS 407 and IP address as follows: 409 Bit 0 - unset for IPv4 Peer IP address, set for IPv6 410 Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits 412 The MRT records which follow the PEER_INDEX_TABLE MRT record contain 413 the RIB entries and include a header which specifies a sequence 414 number, NLRI, and a count of the number of RIB entries which follow. 416 The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, 417 RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 418 The Prefix Length and Prefix fields are encoded in the same manner as 419 the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix 420 field contains address prefixes followed by enough trailing bits to 421 make the end of the field fall on an octet boundary. Note that the 422 value of trailing bits is irrelevant. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Sequence number | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Prefix Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Prefix (variable) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Entry Count | RIB Entries (variable) 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 6: RIB Entry Header 438 The RIB_GENERIC header is shown below. It is used to cover RIB 439 entries which do not fall under the common case entries defined 440 above. It includes Address Family Identifier (AFI), Subsequent AFI 441 and a single NLRI entry. The NLRI information is specific to the AFI 442 and SAFI values. An implementation which does not recognize 443 particular AFI and SAFI values SHOULD discard the remainder of the 444 MRT record. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Sequence number | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Address Family Identifier |Subsequent AFI | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Network Layer Reachability Information (variable) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Entry Count | RIB Entries (variable) 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 7: RIB_GENERIC Entry Header 460 The RIB and RIB_GENERIC Entry Headers are followed by a series of RIB 461 Entries which are repeated Entry Count times. These entries share a 462 common format as shown below. They include a Peer Index from the 463 PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, 464 and the BGP path attribute length and attributes encoded as provided 465 in a BGP Update message. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Peer Index | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Originated Time | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Attribute Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | BGP Attributes... (variable) 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 8: RIB Entries 481 There is one exception to the encoding of BGP attributes for the BGP 482 MP_REACH_NLRI attribute (BGP Type Code 14) RFC 4760 [RFC4760]. Since 483 the AFI, SAFI, and NLRI information is already encoded in the 484 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 485 Address fields are included. The Reserved field is omitted. The 486 attribute length is also adjusted to reflect only the length of the 487 Next Hop Address Length and Next Hop Address fields. 489 5.4. BGP4MP Type 491 This Type was initially defined in the Zebra software package for the 492 BGP protocol with multiprotocol extension support as defined by RFC 493 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 494 The BGP4MP Type has six Subtypes which are defined as follows: 496 0 BGP4MP_STATE_CHANGE 497 1 BGP4MP_MESSAGE 498 4 BGP4MP_MESSAGE_AS4 499 5 BGP4MP_STATE_CHANGE_AS4 500 6 BGP4MP_MESSAGE_LOCAL 501 7 BGP4MP_MESSAGE_AS4_LOCAL 503 5.4.1. BGP4MP_STATE_CHANGE Subtype 505 This record is used to encode state changes in the BGP finite state 506 machine. The BGP FSM states are encoded in the Old State and New 507 State fields to indicate the previous and current state. In some 508 cases, the Peer AS number may be undefined. In such cases, the value 509 of this field may be set to zero. The format is illustrated below: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Peer AS number | Local AS number | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Interface Index | Address Family | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Peer IP address (variable) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Local IP address (variable) | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Old State | New State | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 9: BGP4MP_STATE_CHANGE Subtype 527 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 528 Both the old state value and the new state value are encoded as 529 2-octet numbers. The state values are defined numerically as 530 follows: 532 1 Idle 533 2 Connect 534 3 Active 535 4 OpenSent 536 5 OpenConfirm 537 6 Established 539 The BGP4MP_STATE_CHANGE message also includes interface index and 540 Address Family fields. The interface index provides the interface 541 number of the peering session. The index value is OPTIONAL and MAY 542 be zero if unknown or unsupported. The Address Family indicates what 543 types of addresses are in the the address fields. At present, the 544 following AFI Types are supported: 546 1 AFI_IPv4 547 2 AFI_IPv6 549 5.4.2. BGP4MP_MESSAGE Subtype 551 This Subtype is used to encode BGP Messages. It can be used to 552 encode any Type of BGP message. The entire BGP message is 553 encapsulated in the BGP Message field, including the 16-octet marker, 554 the 2-octet length, and the 1-octet type fields. Note that the 555 BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further, 556 the AS_PATH contained in these messages MUST only consist of 2-Byte 557 AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the 558 BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The 559 BGP4MP_MESSAGE fields are shown below: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Peer AS number | Local AS number | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Interface Index | Address Family | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Peer IP address (variable) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Local IP address (variable) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | BGP Message... (variable) 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 10: BGP4MP_MESSAGE Subtype 576 The interface index provides the interface number of the peering 577 session. The index value is OPTIONAL and MAY be zero if unknown or 578 unsupported. The Address Family indicates what types of addresses 579 are in the the subsequent address fields. At present, the following 580 AFI Types are supported: 582 1 AFI_IPv4 583 2 AFI_IPv6 585 Note that the Address Family value only applies to the IP addresses 586 contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 587 transparent to the contents of the actual message which may contain 588 any valid AFI/SAFI values. Only one BGP message may be encoded in 589 the BGP4MP_MESSAGE Subtype. 591 5.4.3. BGP4MP_MESSAGE_AS4 Subtype 593 This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte 594 Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is 595 otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in 596 these messages MUST only consist of 4-Byte AS numbers. The 597 BGP4MP_MESSAGE_AS4 fields are shown below: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Peer AS number | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Local AS number | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Interface Index | Address Family | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Peer IP address (variable) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Local IP address (variable) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | BGP Message... (variable) 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 11: BGP4MP_MESSAGE_AS4 Subtype 617 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 619 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 620 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE 621 Subtype, the BGP FSM states are encoded in the Old State and New 622 State fields to indicate the previous and current state. Aside from 623 the extension of the peer and local AS fields to 4-Bytes, this 624 subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. 625 The BGP4MP_STATE_CHANGE_AS4 fields are shown below: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Peer AS number | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Local AS number | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Interface Index | Address Family | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Peer IP address (variable) | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Local IP address (variable) | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Old State | New State | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 12: BGP4MP_STATE_CHANGE_AS4 Subtype 645 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype 647 Implementations of MRT have largely focused on collecting remotely 648 generated BGP messages in a passive route collector role. However, 649 for active BGP implementations, it can be useful to archive locally 650 generated BGP messages in addition to remote messages. This subtype 651 is added to indicated a locally generated BGP message. The fields 652 remain identical to the BGP4MP_MESSAGE type including the Peer and 653 Local IP and AS fields. The Local fields continue to refer to the 654 local IP and AS number of the collector which generated the message 655 and the Peer IP and AS fields refer to the receipient of the 656 generated BGP messages. 658 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 660 As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally 661 generated messages. The fields are identical to the 662 BGP4MP_MESSAGE_AS4 message type. 664 5.5. BGP4MP_ET Type 666 This type extends the MRT common header field to include a 32BIT 667 microsecond timestamp field. The type and subtype field definitions 668 remain as defined for the BGP4MP Type. The 32BIT microsecond 669 timestamp immediately follows the length field in the MRT common 670 header and precedes all other fields in the message. The 32BIT 671 microsecond field is included in the computation of the length field 672 value. The MRT common header modification is illustrated below. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Timestamp | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Type | Subtype | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | microsecond timestamp | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Message... (variable) 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 13: BGP4MP_ET Type 690 5.6. ISIS Type 692 This Type supports the IS-IS routing protocol as defined in RFC 1195 693 [RFC1195]. There is no Type specific header for the ISIS Type. The 694 Subtype code for this Type is undefined. The ISIS PDU directly 695 follows the MRT common header fields. 697 5.7. ISIS_ET Type 699 The ISIS_ET Type extends the ISIS Type to support microsecond 700 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 701 timestamp field is appended to the MRT common header after the length 702 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 704 5.8. OSPFv3 Type 706 The OSPFv3 Type extends the original OSPF Type to support IPv6 707 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 708 The format of the MRT Message field for the OSPFv3 Type is as 709 follows: 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Address Family | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Remote IP address (variable) | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Local IP address (variable) | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | OSPF Message Contents (variable) 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 14: OSPFv3 Type 725 5.9. OSPFv3_ET Type 727 The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond 728 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 729 timestamp field is appended to the MRT common header after the length 730 field and its length is included in the calculation of the length 731 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 732 Type. 734 6. Acknowledgements 736 The initial MRT specification was developed by Craig Labovitz for use 737 in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type 738 was introduced in the Zebra routing software project by Kunihiro 739 Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the 740 Python Routeing Toolkit (PyRT) developed by Richard Mortier while at 741 Sprint Advanced Technology Labs. 743 7. IANA Considerations 745 This section provides guidance to the Internet Assigned Numbers 746 Authority (IANA) regarding registration of values related to the MRT 747 specification, in accordance with BCP 26, RFC 5226 [RFC5226]. 749 There are two name spaces in MRT that require registration: Type 750 Codes and Subtype Codes. 752 MRT is not intended as a general-purpose specification for protocol 753 information export, and allocations should not be made for purposes 754 unrelated to routing protocol information export. 756 The following policies are used here with the meanings defined in BCP 757 26: "Specification Required", "IETF Consensus", "Experimental Use", 758 "First Come First Served". 760 7.1. Type Codes 762 Type Codes have a range from 0 to 65535, of which 1-64 have been 763 allocated. New Type Codes MUST be allocated starting at 65. Type 764 Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 - 765 2047 are assigned based on Specification Required. Type Codes 2048 - 766 64511 are available on a First Come First Served policy. Type Codes 767 64512 - 65534 are available for Experimental Use. The Type Code 768 Values of 0 and 65535 are reserved. 770 7.2. Subtype Codes 772 Subtype Codes have a range from 0 to 65535. Subtype definitions are 773 specific to a particular Type Code definition. New Subtype Code 774 definition must reference an existing Type Code to which the Subtype 775 belongs. Subtype assignmnents to Type Codes 0 - 511 are to be 776 assigned by IETF Review. Subtype assignments for the remaning Type 777 Codes follow the assignment rules for the Type Codes to which they 778 belong. 780 8. Security Considerations 782 The MRT Format utilizes a structure which can store routing protocol 783 information data. The fields defined in the MRT specification are of 784 a descriptive nature and provide information that is useful to 785 facilitate the analysis of routing data. As such, the fields 786 currently defined in the MRT specification do not in themselves 787 create additional security risks, since the fields are not used to 788 induce any particular behavior by the recipient application. 790 9. References 792 9.1. Normative References 794 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 795 dual environments", RFC 1195, December 1990. 797 [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional 798 Information", STD 56, RFC 1723, November 1994. 800 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 801 January 1997. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 808 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 809 Protocol 4 (BGP-4)", RFC 4271, January 2006. 811 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 812 "Multiprotocol Extensions for BGP-4", RFC 4760, 813 January 2007. 815 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 816 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 817 May 2008. 819 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 820 for IPv6", RFC 5340, July 2008. 822 9.2. Informative References 824 [MRT PROG GUIDE] 825 Labovitz, C., "MRT Programmer's Guide", November 1999, 826 . 828 Appendix A. Deprecated MRT types 830 This Appendix lists deprecated MRT types. These types are documented 831 for informational purposes only. While documented in some 832 references, they are not known to have been generally implemented. 834 A.1. Deprecated MRT Informational Types 836 The deprecated MRT Informational Types are defined below: 838 0 NULL 839 2 DIE 840 4 PEER_DOWN 842 A.1.1. NULL Type 844 The NULL Type message causes no operation. 846 A.1.2. DIE Type 848 The DIE Type signals a remote MRT repository it should stop accepting 849 messages. 851 A.1.3. PEER_DOWN Type 853 The PEER_DOWN message was intended to indicate that a collector had 854 lost association with a BGP peer. However, the MRT format provides 855 BGP state change message types which duplicate this functionality. 857 A.2. Deprecated MRT Routing Information Types 859 5 BGP 860 6 RIP 861 7 IDRP 862 8 RIPNG 863 9 BGP4PLUS 864 10 BGP4PLUS_01 866 A.2.1. BGP Type 868 The BGP Type indicates the Message field contains BGP routing 869 information. The BGP routing protocol is defined in RFC 4271 870 [RFC4271]. The information in the message is dependent on the 871 Subtype value. The BGP Type and all associated Subtypes below are 872 considered to be deprecated by the BGP4MP Type. 874 The following BGP Subtypes are defined for the MRT BGP Type. As with 875 the BGP Type itself, they are all considered to be deprecated. 877 0 BGP_NULL 878 1 BGP_UPDATE 879 2 BGP_PREF_UPDATE 880 3 BGP_STATE_CHANGE 881 4 BGP_SYNC 882 5 BGP_OPEN 883 6 BGP_NOTIFY 884 7 BGP_KEEPALIVE 886 A.2.1.1. BGP_NULL Subtype 888 The BGP_NULL Subtype is a reserved Subtype. 890 A.2.1.2. BGP_UPDATE Subtype 892 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 893 format of the MRT Message field for this Subtype is as follows: 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Peer AS number | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Peer IP address | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Local AS number | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Local IP address | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | BGP UPDATE Contents (variable) 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Figure 15: BGP_UPDATE Subtype 911 The BGP UPDATE Contents include the entire BGP UPDATE message which 912 follows the BGP Message Header. The BGP Message Header itself is not 913 included. The Peer AS number and IP address fields contain the AS 914 number and IP address of the remote system which are generating the 915 BGP UPDATE messages. The Local AS number and IP address fields 916 contain the AS number and IP address of the local collector system 917 which is archiving the messages. 919 A.2.1.3. BGP_PREF_UPDATE Subtype 921 The BGP_PREF_UPDATE Subtype is not defined. 923 A.2.1.4. BGP_STATE_CHANGE Subtype 925 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 926 finite state machine. These FSM states are defined in RFC 4271 927 [RFC4271], Section 8.2.2. Both the old state value and the new state 928 value are encoded as 2-octet numbers. The state values are defined 929 numerically as follows: 931 1 Idle 932 2 Connect 933 3 Active 934 4 OpenSent 935 5 OpenConfirm 936 6 Established 938 The format of the BGP_STATE_CHANGE Subtype MRT Message field is as 939 follows: 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Peer AS number | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Peer IP address | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Old State | New State | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Figure 16: BGP_STATE_CHANGE Subtype 953 A.2.1.5. BGP_SYNC Subtype 955 The BGP_SYNC Subtype was intended to convey a system file name where 956 BGP Table Dump messages should be recorded. The View # was to 957 correspond to the View # provided in the TABLE_DUMP Type messages. 958 There are no known implementations of this subtype and it SHOULD be 959 ignored. The following format applies to this Subtype: 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | View # | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | File Name... (variable) 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Figure 17: BGP_SYNC Subtype 971 The File Name is terminated with a NULL (0) character. 973 A.2.1.6. BGP_OPEN Subtype 975 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 976 of the MRT Message field for this Subtype is the same as the 977 BGP_UPDATE, however, the last field contains the contents of the BGP 978 OPEN message. 980 A.2.1.7. BGP_NOTIFY Subtype 982 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 983 The format of the MRT Message field for this Subtype is the same as 984 the BGP_UPDATE, however, the last field contains the contents of the 985 BGP NOTIFICATION message. 987 A.2.1.8. BGP_KEEPALIVE Subtype 989 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 990 The format of the MRT Message field for this Subtype is the same as 991 the BGP_UPDATE, however, the last field contains no information. 993 A.2.2. RIP Type 995 The RIP Type is used to export RIP protocol packets as defined in RFC 996 1723 [RFC1723]. The Subtype field is currently reserved for this 997 Type and SHOULD be set to 0. 999 The format of the MRT Message field for the RIP Type is as follows: 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Peer IP address | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Local IP address | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | RIP Message Contents (variable) 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 Figure 18: RIP Type 1013 A.2.3. IDRP Type 1015 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 1016 protocol information as defined in the ISO/IEC 10747 standard. The 1017 Subtype field is unused. This Type is deprecated due to lack of 1018 deployment of IDRP. 1020 A.2.4. RIPNG Type 1022 The RIPNG Type is used to export RIPNG protocol packets as defined in 1023 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 1024 support IPv6. The Subtype field is currently reserved for this Type 1025 and SHOULD be set to 0. 1027 The format of the MRT Message field for the RIPNG Type is as follows: 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | | 1033 ~ Peer IPv6 address ~ 1034 | | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | | 1037 ~ Local IPv6 address ~ 1038 | | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | RIPNG Message Contents (variable) 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 Figure 19: RIPNG Type 1045 A.2.5. BGP4PLUS and BGP4PLUS_01 Types 1047 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 1048 routing information. The BGP4PLUS Type was specified based on the 1049 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 1050 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 1051 this Internet Draft. The two Types share the same definitions in 1052 terms of their MRT format specifications. 1054 The Subtype field definitions are shared with the BGP Type, however, 1055 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1056 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 1057 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1058 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1059 Type. 1061 A.2.6. Deprecated BGP4MP Subtypes 1063 The following two subtypes of the BGP4MP Type are considered to be 1064 deprecated. 1066 2 BGP4MP_ENTRY 1067 3 BGP4MP_SNAPSHOT 1069 A.2.6.1. BGP4MP_ENTRY Subtype 1071 This Subtype is similar to the TABLE_DUMP Type and is used to record 1072 RIB table entries. It extends the TABLE_DUMP Type to include true 1073 multiprotocol support. However, this Type does not support 4-Byte AS 1074 numbers and has not been widely implemented. This Type is deprecated 1075 in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support 1076 and a more compact format. 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Peer AS number | Local AS number | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Interface Index | Address Family | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Peer IP address (variable) | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Local IP address (variable) | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | View # | Status | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Time last change | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Address Family | SAFI | Next-Hop-Len | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Next Hop Address (variable) | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Prefix Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Address Prefix (variable) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Attribute Length | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | BGP Attribute... (variable) 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 20: BGP4MP_ENTRY Subtype 1108 A.2.6.2. BGP4MP_SNAPSHOT Subtype 1110 This Subtype was intended to convey a system file name where 1111 BGP4MP_ENTRY messages should be recorded. It is similar to the 1112 BGP_SYNC message Subtype and is deprecated. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | View # | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | File Name... (variable) 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 21: BGP4MP_SNAPSHOT Subtype 1124 Authors' Addresses 1126 Larry Blunk 1127 Merit Network 1129 Email: ljb@merit.edu 1131 Manish Karir 1132 Merit Network 1134 Email: mkarir@merit.edu 1136 Craig Labovitz 1137 Arbor Networks 1139 Email: labovit@arbor.net