idnits 2.17.1 draft-ietf-grow-mrt-15.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 (July 6, 2011) is 4675 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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: Informational Merit Network 5 Expires: January 7, 2012 C. Labovitz 6 Deepfield Networks 7 July 6, 2011 9 MRT routing information export format 10 draft-ietf-grow-mrt-15.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 January 7, 2012. 37 Copyright Notice 39 Copyright (c) 2011 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 68 2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 7 70 4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 10 74 4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 11 75 4.3.2. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . 12 76 4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 13 77 4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 13 78 4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 15 80 4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 16 81 4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 17 82 4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 17 83 4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 18 84 4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 18 85 4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 19 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 92 Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 24 93 Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 27 94 B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 27 95 B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 27 96 B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 27 97 B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 27 98 B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 27 99 B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 28 100 B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 28 101 B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 28 102 B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 31 103 B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 31 104 B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 31 105 B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 32 106 B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 32 107 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 110 1. Introduction 112 Researchers and engineers often wish to analyze network behavior by 113 studying routing protocol transactions and routing information base 114 snapshots. To this end, the MRT record format was developed to 115 encapsulate, export, and archive this information in a standardized 116 data representation. 118 The BGP routing protocol, in particular, has been the subject of 119 extensive study and analysis which has been significantly aided by 120 the availability of the MRT format. Two examples of large-scale MRT 121 based BGP archival projects include the University of Oregon Route 122 Views Project and the RIPE NCC Routing Information Service (RIS). 124 The MRT format was initially defined in the MRT Programmer's Guide 125 [MRT PROG GUIDE]. Subsequent extensions were made in the the GNU 126 Zebra software routing suite and the Sprint Advanced Technology Labs 127 Python Routing Toolkit (PyRT). Further extensions may be introduced 128 at a later date through additional definitions of the MRT Type field 129 and Subtype fields. 131 A number of MRT record types listed in the MRT Programmer's Guide 132 [MRT PROG GUIDE] are not known to have been implemented and, in some 133 cases, were incompletely specified. Further, several types were 134 employed in early MRT implementations, but saw limited use and were 135 updated by improved versions. These types are considered to be 136 deprecated and are documented in the Deprecated MRT Types 137 (Appendix B) section at the end of this document. The deprecated 138 types consist of codes 0 through 10 inclusive. Some of the 139 deprecated types may be of interest to researchers examining 140 historical MRT format archives. 142 Fields which contain multi-octet numeric values are encoded in 143 network octet order from most significant octet to least significant 144 octet. Fields which contain routing message fields are encoded in 145 the same order as they appear in the packet contents. 147 1.1. Specification of Requirements 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. MRT Common Header 155 All MRT format records have a Common Header which consists of a 156 Timestamp, Type, Subtype, and Length field. The header is followed 157 by a Message field. The MRT Common Header is illustrated below. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Timestamp | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Subtype | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Message... (variable) 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: MRT Common Header 173 Header Field Descriptions: 175 Timestamp: 177 A 4-octet field whose integer value is the number of seconds, 178 excluding leap seconds, elapsed since midnight proleptic 179 Coordinated Universal Time (UTC). This representation of time 180 is sometimes called "UNIX time" POSIX [IEEE.P1003.1-1990]. 181 This time format cannot represent time values prior to January 182 1, 1970. The latest UTC time value that can be represented by 183 a four-octet integer value is 03:14:07 on January 19, 2038, 184 which is represented by the hexadecimal value 7FFFFFFF. 185 Implementations which wish to create MRT records after this 186 date will need to provide an alternate EPOCH time base for the 187 Timestamp field. Mechanisms for indicating this alternate 188 EPOCH are currently outside the scope of this document. 190 Type: 192 A 2-octet field that indicates the Type of information 193 contained in the message field. Types 0 through 4 are 194 informational messages pertaining to the state of an MRT 195 collector, while Types 5 and higher are used to convey routing 196 information. 198 Subtype: 200 A 2-octet field that is used to further distinguish message 201 information within a particular record Type. 203 Length: 205 A 4-octet message length field. The length field contains the 206 number of octets within the message. The length field does not 207 include the length of the MRT Common Header. 209 Message: 211 A variable length message. The contents of this field are 212 context dependent upon the Type and Subtype fields. 214 3. Extended Timestamp MRT Header 216 Several MRT format record types support a variant type with an 217 extended timestamp field. The purpose of this field is to support 218 measurements at sub-second resolutions. This field, Microsecond 219 Timestamp, contains an unsigned 32BIT offset value in microseconds 220 which is added to the Timestamp field value. The Timestamp field 221 remains as defined in the MRT Common Header. The Microsecond 222 Timestamp immediately follows the length field in the MRT Common 223 Header and precedes all other fields in the message. The Microsecond 224 Timestamp is included in the computation of the length field value. 225 The Extended Timestamp MRT Header is illustrated below. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Timestamp | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Subtype | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Microsecond Timestamp | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Message... (variable) 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: Extended Timestamp MRT Header 243 4. MRT Types 245 The following MRT Types are currently defined for the MRT format. 246 The MRT Types which contain the "_ET" suffix in their names identify 247 those types which use an Extended Timestamp MRT Header. The subtype 248 and message fields in these types remain as defined for the MRT Types 249 of the same name without the "_ET" suffix. 251 11 OSPFv2 252 12 TABLE_DUMP 253 13 TABLE_DUMP_V2 254 16 BGP4MP 255 17 BGP4MP_ET 256 32 ISIS 257 33 ISIS_ET 258 48 OSPFv3 259 49 OSPFv3_ET 261 4.1. OSPFv2 Type 263 This Type supports the OSPFv2 Protocol as defined in RFC 2328 264 [RFC2328]. The Subtype field MAY contain two possible values: 266 0 OSPF_STATE_CHANGE 267 1 OSPF_LSA_UPDATE 269 The format of the MRT Message field for the OSPFv2 Type is as 270 follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Remote IP address | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Local IP address | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | OSPF Message Contents (variable) 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 3: OSPFv2 Type 284 The Remote IP address field contains source IPv4 [RFC0791] address 285 from the IP header of the OSPF message. The Local IP address 286 contains the destination IPv4 address from the IP header. The OSPF 287 Message Contents field contains the complete contents of the OSPF 288 packet following the IP header. 290 4.2. TABLE_DUMP Type 292 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 293 Information Base (RIB). Each RIB entry is encoded in a distinct 294 sequential MRT record. It is RECOMMENDED that new MRT encoding 295 implementations use the TABLE_DUMP_V2 Type (see below) instead of the 296 TABLE_DUMP Type due to limitations in this type. However, due to the 297 significant volume of historical data encoded with this type, MRT 298 decoding applications MAY wish to support this type. 300 The Subtype field is used to encode whether the RIB entry contains 301 IPv4 or IPv6 [RFC2460] addresses. There are two possible values for 302 the Subtype as shown below. 304 1 AFI_IPv4 305 2 AFI_IPv6 307 The format of the TABLE_DUMP Type is illustrated below. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | View # | Sequence number | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Prefix (variable) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Prefix Length | Status | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Originated Time | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Peer IP address (variable) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Peer AS | Attribute Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | BGP Attribute... (variable) 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4: TABLE_DUMP Type 329 The View field is normally 0 and is intended for cases where an 330 implementation may have multiple RIB views (such as a route server). 331 In cases where multiple RIB views are present, an implementation MAY 332 use the the view field to distinguish entries from each view. The 333 Sequence field is a simple incremental counter for each RIB entry. A 334 typical RIB dump will exceed the 16-bit bounds of this counter and 335 implementation SHOULD simply wrap back to zero and continue 336 incrementing the counter in such cases. 338 The Prefix field contains the IP address of a particular RIB entry. 339 The size of this field is dependent on the value of the Subtype for 340 this record. The AFI_IPv4 Subtype value specifies an Address Family 341 [IANA-AF] Identifier (AFI) type of IPv4. It specifies a prefix field 342 length of 4 octets. For AFI_IPv6, it is 16 octets in length. The 343 Prefix Length field indicates the length in bits of the prefix mask 344 for the preceding Prefix field. 346 The Status octet is unused in the TABLE_DUMP Type and SHOULD be set 347 to 1. 349 The Originated Time contains the 4-octet time at which this prefix 350 was heard. The value represents the time in seconds since 1 January 351 1970 00:00:00 UTC. 353 The Peer IP field is the IP address of the peer which provided the 354 update for this RIB entry. As with the Prefix field, the size of 355 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 356 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 357 octet field and an IPv6 address. The Peer AS field contains the 2 358 octet Autonomous System (AS) number of the peer. 360 The TABLE_DUMP Type does not permit 4-Byte Peer AS numbers. Nor does 361 it allow the AFI of the peer IP to differ from the AFI of the Prefix 362 field. The TABLE_DUMP_V2 Type MUST be used in these situations. 364 Attribute Length contains the length of Attribute field and is 365 2-octets. The BGP Attribute field contains the BGP attribute 366 information for the RIB entry. The AS_PATH attribute MUST only 367 consist of 2-Byte AS numbers. The TABLE_DUMP_V2 supports 4-Byte AS 368 numbers in the AS_PATH attribute. 370 4.3. TABLE_DUMP_V2 Type 372 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte 373 Autonomous System Number (ASN) support and full support for BGP 374 Multiprotocol extensions. It also improves upon the space efficiency 375 of the TABLE_DUMP Type by employing an index table for peers and 376 permitting a single MRT record per Network Layer Reachability 377 Information (NLRI) entry. The following subtypes are used with the 378 TABLE_DUMP_V2 Type. 380 1 PEER_INDEX_TABLE 381 2 RIB_IPV4_UNICAST 382 3 RIB_IPV4_MULTICAST 383 4 RIB_IPV6_UNICAST 384 5 RIB_IPV6_MULTICAST 385 6 RIB_GENERIC 387 4.3.1. PEER_INDEX_TABLE Subtype 389 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 390 collector, an OPTIONAL view name, and a list of indexed peers. 391 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 392 are used to encode RIB table entries. This series of MRT records use 393 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 394 itself and include full MRT record headers. The RIB entry MRT 395 records MUST immediately follow the PEER_INDEX_TABLE MRT record. 397 The header of the PEER_INDEX_TABLE Subtype is shown below. The View 398 Name is OPTIONAL and, if not present, the View Name Length MUST be 399 set to 0. The View Name encoding MUST follow the UTF-8 400 transformation format [RFC3629]. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Collector BGP ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | View Name Length | View Name (variable) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Peer Count | Peer Entries (variable) 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 5: PEER_INDEX_TABLE Subtype 414 The format of the Peer Entries is shown below. The PEER_INDEX_TABLE 415 record contains Peer Count number of Peer Entries. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Peer Type | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Peer BGP ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Peer IP address (variable) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Peer AS (variable) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 6: Peer Entries 431 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 432 as indicated by the Peer Count field. The position of the Peer in 433 the PEER_INDEX_TABLE is used as an index in the subsequent 434 TABLE_DUMP_V2 MRT records. The index number begins with 0. 436 The Peer Type field is a bit field which encodes the type of the AS 437 and IP address as identified by the A and I bits, respectively, 438 below. 440 0 1 2 3 4 5 6 7 441 +-+-+-+-+-+-+-+-+ 442 | | | | | | |A|I| 443 +-+-+-+-+-+-+-+-+ 445 Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits 446 Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6 448 Figure 7: Peer Type Field 450 The MRT records which follow the PEER_INDEX_TABLE MRT record consist 451 of the subtypes listed below and contain the actual RIB table 452 entries. They include a header which specifies a sequence number, a 453 NLRI field, and a count of the number of RIB entries contained within 454 the record. 456 4.3.2. AFI/SAFI specific RIB Subtypes 458 The AFI/SAFI specific RIB Subtypes consist of the RIB_IPV4_UNICAST, 459 RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST 460 Subtypes. These specific RIB table entries are given their own MRT 461 TABLE_DUMP_V2 subtypes as they are the most common type of RIB table 462 instances and providing specific MRT subtypes for them permits more 463 compact encodings. These subtypes permit a single MRT record to 464 encode multiple RIB table entries for a single prefix. The Prefix 465 Length and Prefix fields are encoded in the same manner as the BGP 466 NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix field 467 contains address prefixes followed by enough trailing bits to make 468 the end of the field fall on an octet boundary. The value of 469 trailing bits is irrelevant. 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Sequence number | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Prefix Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Prefix (variable) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Entry Count | RIB Entries (variable) 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 8: RIB Entry Header 485 4.3.3. RIB_GENERIC Subtype 487 The RIB_GENERIC header is shown below. It is used to cover RIB 488 entries which do not fall under the common case entries defined 489 above. It consists of an AFI, Subsequent AFI (SAFI) and a single 490 NLRI entry. The NLRI information is specific to the AFI and SAFI 491 values. An implementation which does not recognize particular AFI 492 and SAFI values SHOULD discard the remainder of the MRT record. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Sequence number | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Address Family Identifier |Subsequent AFI | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Network Layer Reachability Information (variable) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Entry Count | RIB Entries (variable) 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 9: RIB_GENERIC Entry Header 508 4.3.4. RIB Entries 510 The RIB Entries are repeated Entry Count times. These entries share 511 a common format as shown below. They include a Peer Index from the 512 PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, 513 and the BGP path attribute length and attributes. All AS numbers in 514 the AS_PATH attribute MUST be encoded as 4-Byte AS numbers. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Peer Index | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Originated Time | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Attribute Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | BGP Attributes... (variable) 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 10: RIB Entries 530 There is one exception to the encoding of BGP attributes for the BGP 531 MP_REACH_NLRI attribute (BGP Type Code 14) RFC 4760 [RFC4760]. Since 532 the AFI, SAFI, and NLRI information is already encoded in the 533 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 534 Address fields are included. The Reserved field is omitted. The 535 attribute length is also adjusted to reflect only the length of the 536 Next Hop Address Length and Next Hop Address fields. 538 4.4. BGP4MP Type 540 This Type was initially defined in the Zebra software package for the 541 BGP protocol with multiprotocol extension support as defined by RFC 542 4760 [RFC4760]. The BGP4MP Type has six Subtypes which are defined 543 as follows: 545 0 BGP4MP_STATE_CHANGE 546 1 BGP4MP_MESSAGE 547 4 BGP4MP_MESSAGE_AS4 548 5 BGP4MP_STATE_CHANGE_AS4 549 6 BGP4MP_MESSAGE_LOCAL 550 7 BGP4MP_MESSAGE_AS4_LOCAL 552 4.4.1. BGP4MP_STATE_CHANGE Subtype 554 This message is used to encode state changes in the BGP finite state 555 machine. The BGP Finite State Machine (FSM) states are encoded in 556 the Old State and New State fields to indicate the previous and 557 current state. In some cases, the Peer AS number may be undefined. 558 In such cases, the value of this field MAY be set to zero. The 559 format is illustrated 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 | Old State | New State | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 11: BGP4MP_STATE_CHANGE Subtype 577 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 578 Both the old state value and the new state value are encoded as 579 2-octet numbers. The state values are defined numerically as 580 follows: 582 1 Idle 583 2 Connect 584 3 Active 585 4 OpenSent 586 5 OpenConfirm 587 6 Established 589 The BGP4MP_STATE_CHANGE message also includes interface index and 590 Address Family fields. The interface index provides the interface 591 number of the peering session. The index value is OPTIONAL and MAY 592 be zero if unknown or unsupported. The Address Family indicates what 593 types of addresses are in the the address fields. At present, the 594 following AFI Types are supported: 596 1 AFI_IPv4 597 2 AFI_IPv6 599 4.4.2. BGP4MP_MESSAGE Subtype 601 This Subtype is used to encode BGP messages. It can be used to 602 encode any Type of BGP message. The entire BGP message is 603 encapsulated in the BGP Message field, including the 16-octet marker, 604 the 2-octet length, and the 1-octet type fields. The BGP4MP_MESSAGE 605 Subtype does not support 4-Byte AS numbers. The AS_PATH contained in 606 these messages MUST only consist of 2-Byte AS numbers. The 607 BGP4MP_MESSAGE_AS4 Subtype updates the BGP4MP_MESSAGE Subtype in 608 order to support 4-Byte AS numbers. The BGP4MP_MESSAGE fields are 609 shown below: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Peer AS number | Local AS number | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Interface Index | Address Family | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Peer IP address (variable) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Local IP address (variable) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | BGP Message... (variable) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 12: BGP4MP_MESSAGE Subtype 626 The interface index provides the interface number of the peering 627 session. The index value is OPTIONAL and MAY be zero if unknown or 628 unsupported. The Address Family indicates what types of addresses 629 are in the the subsequent address fields. At present, the following 630 AFI Types are supported: 632 1 AFI_IPv4 633 2 AFI_IPv6 635 The Address Family value only applies to the IP addresses contained 636 in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 637 transparent to the contents of the actual message which may contain 638 any valid AFI/SAFI values. Only one BGP message SHALL be encoded in 639 the BGP4MP_MESSAGE Subtype. 641 4.4.3. BGP4MP_MESSAGE_AS4 Subtype 643 This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte AS 644 numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to 645 the BGP4MP_MESSAGE Subtype. The AS_PATH in these messages MUST only 646 consist of 4-Byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are 647 shown below: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Peer AS number | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Local AS number | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Interface Index | Address Family | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Peer IP address (variable) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Local IP address (variable) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | BGP Message... (variable) 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 13: BGP4MP_MESSAGE_AS4 Subtype 667 4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 669 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 670 4-Byte AS numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP 671 FSM states are encoded in the Old State and New State fields to 672 indicate the previous and current state. Aside from the extension of 673 the peer and local AS fields to 4-Bytes, this subtype is otherwise 674 identical to the BGP4MP_STATE_CHANGE Subtype. The 675 BGP4MP_STATE_CHANGE_AS4 fields are shown below: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Peer AS number | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Local AS number | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Interface Index | Address Family | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Peer IP address (variable) | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Local IP address (variable) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Old State | New State | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype 695 4.4.5. BGP4MP_MESSAGE_LOCAL Subtype 697 Implementations of MRT have largely focused on collecting remotely 698 generated BGP messages in a passive route collector role. However, 699 for active BGP implementations, it can be useful to archive locally 700 generated BGP messages in addition to remote messages. This subtype 701 is added to indicated a locally generated BGP message. The fields 702 remain identical to the BGP4MP_MESSAGE type including the Peer and 703 Local IP and AS fields. The Local fields continue to refer to the 704 local IP and AS number of the collector which generated the BGP 705 message and the Peer IP and AS fields refer to the recipient of the 706 generated BGP messages. 708 4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 710 As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally 711 generated messages. The fields are identical to the 712 BGP4MP_MESSAGE_AS4 message type. 714 4.5. ISIS Type 716 This Type supports the IS-IS routing protocol as defined in RFC 1195 717 [RFC1195]. There is no Type specific header for the ISIS Type. The 718 Subtype code for this Type is undefined. The ISIS PDU directly 719 follows the MRT Common Header fields. 721 4.6. OSPFv3 Type 723 The OSPFv3 Type extends the original OSPFv2 Type to support IPv6 724 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 725 The format of the MRT Message field for the OSPFv3 Type is as 726 follows: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Address Family | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Remote IP address (variable) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Local IP address (variable) | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | OSPF Message Contents (variable) 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 15: OSPFv3 Type 742 5. IANA Considerations 744 This document has no IANA actions. 746 6. Security Considerations 748 The MRT Format utilizes a structure which can store routing protocol 749 information data. The fields defined in the MRT specification are of 750 a descriptive nature and provide information that is useful to 751 facilitate the analysis of routing data. As such, the fields 752 currently defined in the MRT specification do not in themselves 753 create additional security risks, since the fields are not used to 754 induce any particular behavior by the recipient application. 756 Some information contained in an MRT data structure might be 757 considered sensitive or private. For example, a BGP peer that sends 758 a message to an MRT-enabled router might not expect that message to 759 be shared beyond the AS to which it is sent. 761 Information that could be considered sensitive include BGP peer IP 762 addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such 763 information could be useful to mount attacks against the BGP protocol 764 and routing infrastructure. RFC 4272 [RFC4272] examines a number of 765 weaknesses in the BGP protocol which could potentially be exploited. 767 An organization that intends to use the MRT structure to export 768 routing information beyond the domain where it normally accessible 769 (e.g., publishing MRT dumps for use by researchers) should verify 770 with any peers whose information might be included, and possibly 771 remove sensitive fields. 773 The proposed geolocation extension to MRT could reveal the location 774 of an MRT router's peers [I- D.ietf-grow-geomrt]. 776 7. References 778 7.1. Normative References 780 [IANA-AF] "Address Family Numbers", 781 . 783 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 784 September 1981. 786 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 787 dual environments", RFC 1195, December 1990. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 794 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 795 (IPv6) Specification", RFC 2460, December 1998. 797 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 798 10646", STD 63, RFC 3629, November 2003. 800 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 801 Protocol 4 (BGP-4)", RFC 4271, January 2006. 803 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 804 "Multiprotocol Extensions for BGP-4", RFC 4760, 805 January 2007. 807 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 808 for IPv6", RFC 5340, July 2008. 810 7.2. Informative References 812 [IEEE.P1003.1-1990] 813 Institute of Electrical and Electronics Engineers, 814 "P1003.1, Information Technology Portable Operating System 815 Interface (POSIX) Part 1: System Application Program 816 Interface (API) [C Language], 1990.", IEEE Standard 817 P1003.1. 819 [MRT PROG GUIDE] 820 Labovitz, C., "MRT Programmer's Guide", November 1999, 821 . 823 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 824 January 1997. 826 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 827 November 1998. 829 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 830 RFC 4272, January 2006. 832 Appendix A. MRT Encoding Examples 834 This appendix, which is not a normative reference, contains a MRT 835 encoding examples. 837 The following example shows the encoding for a MRT record type of 838 BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS 839 numbers are encoded in 4 bytes fields due to the use of the 840 BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in 841 hexadecimal. The AS numbers in the ASPATH in the BGP Update are 842 encoded as 4 byte values in accord with the MRT BGP4MP_MESSAGE_AS4 843 subtype. 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type = 16 | Subtype = 4 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Length = 82 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Peer AS = 64496 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Local AS = 64497 | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Interface Index = 0 | Address Family = 1 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Peer IP address = 192.0.2.85 | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Local IP address = 198.51.100.4 | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | BGP Update = 866 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 867 00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03 868 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6 869 33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71 871 Figure 16: MRT BGP4MP_MESSAGE_AS4 Example 873 The contents of the BGP Update Message above are as follows: 875 ORIGIN: INCOMPLETE 876 ASPATH: 64496 64511 64502 877 NEXT_HOP: 198.51.100.188 878 COMMUNITY: 64496:14 879 NLRI: 203.0.113.0/24 881 Figure 17: BGP Message Contents 883 The following example displays the encoding for a MRT record type of 884 TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this 885 example contains 2 entries. 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type = 13 | Subtype = 1 | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Length = 34 | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Collector BGP ID = 198.51.100.4 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | View Name Length = 0 | Peer Count = 2 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Peer Type = 2 | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Peer BGP ID = 198.51.100.5 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Peer IP address = 198.51.100.5 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Peer AS = 65541 | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Peer Type = 2 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Peer BGP ID = 192.0.2.33 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Peer IP address = 192.0.2.33 | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Peer AS = 65542 | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Figure 18: MRT PEER_INDEX_TABLE Example 919 The following example displays the encoding for a MRT record type of 920 TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to 921 the NLRI prefix of 2001:0DB8::/32. There is a single entry for this 922 prefix. The entry applies to the peer identified by index location 923 15 in a preceding MRT PEER_INDEX_TABLE record. 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Type = 13 | Subtype = 4 | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Length = 87 | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Sequence number = 42 | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Preflen = 32 | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Prefix = 2001:0DB8::/32 | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Entry Count = 1 | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Peer Index = 15 | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 |Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Attribute Length = 68 | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | BGP Path Attributes = 950 40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00 951 fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d 952 b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00 953 00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20 954 20 01 0d b8 956 Figure 19: MRT RIB_IPV6_UNICAST Example 958 The contents of the BGP Path Attribute field above are as follows: 960 ORIGIN: IGP 961 ASPATH: 64496 64511 64502 962 MP_REACH_NLRI(IPv6 Unicast) 963 NEXT_HOP: 2001:db8:d:ff::187 964 NEXT_HOP: fe80::212:f2ff:fe9f:1b00 965 NLRI: 2001:0DB8::/32 967 Figure 20: BGP Path Attribute contents 969 Appendix B. Deprecated MRT Types 971 This Appendix lists deprecated MRT types. These types are documented 972 for informational purposes. 974 B.1. Deprecated MRT Informational Types 976 The initial MRT format defined five Informational Type records. 977 These records were intended to signal the state of an MRT data 978 collector and do not contain routing information. These records were 979 intended for use when MRT records were sent over a network to a 980 remote repository store. However, MRT record repository stores have 981 traditionally resided on the same device as the collector and these 982 Informational Types are not known to be implemented. Further, 983 transport mechanisms for MRT records are considered to be outside the 984 scope of this document. 986 The message field MAY contain an OPTIONAL string for diagnostic 987 purposes. The message string encoding MUST follow the UTF-8 988 transformation format [RFC3629]. The Subtype field is unused for 989 these Types and SHOULD be set to 0. 991 The MRT Informational Types are defined below: 993 0 NULL 994 1 START 995 2 DIE 996 3 I_AM_DEAD 997 4 PEER_DOWN 999 B.1.1. NULL Type 1001 The NULL Type message causes no operation. 1003 B.1.2. START Type 1005 The START Type indicates a collector is about to begin generating MRT 1006 records. 1008 B.1.3. DIE Type 1010 The DIE Type signals a remote MRT repository it SHOULD stop accepting 1011 messages. 1013 B.1.4. I_AM_DEAD Type 1015 An I_AM_DEAD MRT record indicates that a collector has shut down and 1016 has stopped generating MRT records. 1018 B.1.5. PEER_DOWN Type 1020 The PEER_DOWN message was intended to indicate that a collector had 1021 lost association with a BGP peer. However, the MRT format provides 1022 BGP state change message types which duplicate this functionality. 1024 B.2. Other Deprecated MRT Types 1026 5 BGP 1027 6 RIP 1028 7 IDRP 1029 8 RIPNG 1030 9 BGP4PLUS 1031 10 BGP4PLUS_01 1033 B.2.1. BGP Type 1035 The BGP Type indicates the Message field contains BGP routing 1036 information. The BGP routing protocol is defined in RFC 4271 1037 [RFC4271]. The information in the message is dependent on the 1038 Subtype value. The BGP Type and all associated Subtypes below are 1039 considered to be deprecated by the BGP4MP Type. 1041 The following BGP Subtypes are defined for the MRT BGP Type. As with 1042 the BGP Type itself, they are all considered to be deprecated. 1044 0 BGP_NULL 1045 1 BGP_UPDATE 1046 2 BGP_PREF_UPDATE 1047 3 BGP_STATE_CHANGE 1048 4 BGP_SYNC 1049 5 BGP_OPEN 1050 6 BGP_NOTIFY 1051 7 BGP_KEEPALIVE 1053 B.2.1.1. BGP_NULL Subtype 1055 The BGP_NULL Subtype is a reserved Subtype. 1057 B.2.1.2. BGP_UPDATE Subtype 1059 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 1060 format of the MRT Message field for this Subtype is as follows: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Peer AS number | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Peer IP address | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Local AS number | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Local IP address | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | BGP UPDATE Contents (variable) 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 21: BGP_UPDATE Subtype 1078 The BGP UPDATE Contents include the entire BGP UPDATE message which 1079 follows the BGP Message Header. The BGP Message Header itself is not 1080 included. The Peer AS number and IP address fields contain the AS 1081 number and IP address of the remote system which are generating the 1082 BGP UPDATE messages. The Local AS number and IP address fields 1083 contain the AS number and IP address of the local collector system 1084 which is archiving the messages. 1086 B.2.1.3. BGP_PREF_UPDATE Subtype 1088 The BGP_PREF_UPDATE Subtype is not defined. 1090 B.2.1.4. BGP_STATE_CHANGE Subtype 1092 The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP 1093 finite state machine. These FSM states are defined in RFC 4271 1094 [RFC4271], Section 8.2.2. Both the old state value and the new state 1095 value are encoded as 2-octet numbers. The state values are defined 1096 numerically as follows: 1098 1 Idle 1099 2 Connect 1100 3 Active 1101 4 OpenSent 1102 5 OpenConfirm 1103 6 Established 1105 The format of the BGP_STATE_CHANGE Subtype MRT Message field is as 1106 follows: 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Peer AS number | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Peer IP address | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Old State | New State | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Figure 22: BGP_STATE_CHANGE Subtype 1120 B.2.1.5. BGP_SYNC Subtype 1122 The BGP_SYNC Subtype was intended to convey a system file name where 1123 BGP Table Dump messages MAY be recorded. The View # was to 1124 correspond to the View # provided in the TABLE_DUMP Type records. 1125 There are no known implementations of this subtype and it SHOULD be 1126 ignored. The following format applies to this Subtype: 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | View # | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | File Name... (variable) 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 Figure 23: BGP_SYNC Subtype 1138 The File Name is terminated with a NULL (0) character. 1140 B.2.1.6. BGP_OPEN Subtype 1142 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 1143 of the MRT Message field for this Subtype is the same as the 1144 BGP_UPDATE, however, the last field contains the contents of the BGP 1145 OPEN message. 1147 B.2.1.7. BGP_NOTIFY Subtype 1149 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 1150 The format of the MRT Message field for this Subtype is the same as 1151 the BGP_UPDATE, however, the last field contains the contents of the 1152 BGP NOTIFICATION message. 1154 B.2.1.8. BGP_KEEPALIVE Subtype 1156 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 1157 The format of the MRT Message field for this Subtype is the same as 1158 the BGP_UPDATE, however, the last field contains no information. 1160 B.2.2. RIP Type 1162 The RIP Type is used to export RIP protocol packets as defined in RFC 1163 2453 [RFC2453]. The Subtype field is currently reserved for this 1164 Type and SHOULD be set to 0. 1166 The format of the MRT Message field for the RIP Type is as follows: 1168 0 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Peer IP address | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Local IP address | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | RIP Message Contents (variable) 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Figure 24: RIP Type 1180 B.2.3. IDRP Type 1182 The IDRP Type was intended to be used to export Inter-Domain-Routing 1183 Protocol (IDRP) protocol information as defined in the ISO/IEC 10747 1184 standard. However, this Type has seen no known use and there are no 1185 details on protocol encoding for this Type. 1187 B.2.4. RIPNG Type 1189 The RIPNG Type is used to export RIPNG protocol packets as defined in 1190 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 1191 support IPv6. The Subtype field is currently reserved for this Type 1192 and SHOULD be set to 0. 1194 The format of the MRT Message field for the RIPNG Type is as follows: 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | | 1200 ~ Peer IPv6 address ~ 1201 | | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | | 1204 ~ Local IPv6 address ~ 1205 | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | RIPNG Message Contents (variable) 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 Figure 25: RIPNG Type 1212 B.2.5. BGP4PLUS and BGP4PLUS_01 Types 1214 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 1215 routing information. The BGP4PLUS Type was specified based on the 1216 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 1217 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 1218 this Internet Draft. The two Types share the same definitions in 1219 terms of their MRT format specifications. 1221 The Subtype field definitions are shared with the BGP Type, however, 1222 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1223 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to 1224 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1225 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1226 Type. 1228 B.2.6. Deprecated BGP4MP Subtypes 1230 The following two subtypes of the BGP4MP Type are considered to be 1231 deprecated. 1233 2 BGP4MP_ENTRY 1234 3 BGP4MP_SNAPSHOT 1236 B.2.6.1. BGP4MP_ENTRY Subtype 1238 This Subtype is similar to the TABLE_DUMP Type and is used to record 1239 RIB table entries. It was intended to include true multiprotocol 1240 support. However, this Subtype does not support 4-Byte AS numbers 1241 and has not been widely implemented. 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Peer AS number | Local AS number | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Interface Index | Address Family | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Peer IP address (variable) | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Local IP address (variable) | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | View # | Status | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Time last change | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Address Family | SAFI | Next-Hop-Len | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Next Hop Address (variable) | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Prefix Length | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Address Prefix (variable) | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Attribute Length | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | BGP Attribute... (variable) 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 Figure 26: BGP4MP_ENTRY Subtype 1273 B.2.6.2. BGP4MP_SNAPSHOT Subtype 1275 This Subtype was intended to convey a system file name where 1276 BGP4MP_ENTRY records MAY be recorded. It is similar to the BGP_SYNC 1277 Subtype and is deprecated. 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | View # | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | File Name... (variable) 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 Figure 27: BGP4MP_SNAPSHOT Subtype 1289 Appendix C. Acknowledgements 1291 The initial MRT specification was developed by Craig Labovitz for use 1292 in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type 1293 was introduced in the Zebra routing software project by Kunihiro 1294 Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the 1295 Python Routeing Toolkit (PyRT) developed by Richard Mortier while at 1296 Sprint Advanced Technology Labs. 1298 Authors' Addresses 1300 Larry Blunk 1301 Merit Network 1303 Email: ljb@merit.edu 1305 Manish Karir 1306 Merit Network 1308 Email: mkarir@merit.edu 1310 Craig Labovitz 1311 Deepfield Networks 1313 Email: labovit@deepfield.net