idnits 2.17.1 draft-ietf-grow-mrt-14.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 (April 20, 2011) is 4755 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: October 22, 2011 C. Labovitz 6 Arbor Networks 7 April 20, 2011 9 MRT routing information export format 10 draft-ietf-grow-mrt-14.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 October 22, 2011. 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. The proposed 760 geolocation extension to MRT could reveal the location of an MRT 761 router's peers [I- D.ietf-grow-geomrt]. An organization that intends 762 to use the MRT structure to export routing information beyond the 763 domain where it normally accessible (e.g., publishing MRT dumps for 764 use by researchers) should verify with any peers whose information 765 might be included, and possibly remove sensitive fields. 767 7. References 769 7.1. Normative References 771 [IANA-AF] "Address Family Numbers", 772 . 774 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 775 September 1981. 777 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 778 dual environments", RFC 1195, December 1990. 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, March 1997. 783 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 785 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 786 (IPv6) Specification", RFC 2460, December 1998. 788 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 789 10646", STD 63, RFC 3629, November 2003. 791 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 792 Protocol 4 (BGP-4)", RFC 4271, January 2006. 794 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 795 "Multiprotocol Extensions for BGP-4", RFC 4760, 796 January 2007. 798 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 799 for IPv6", RFC 5340, July 2008. 801 7.2. Informative References 803 [IEEE.P1003.1-1990] 804 Institute of Electrical and Electronics Engineers, 805 "P1003.1, Information Technology Portable Operating System 806 Interface (POSIX) Part 1: System Application Program 807 Interface (API) [C Language], 1990.", IEEE Standard 808 P1003.1. 810 [MRT PROG GUIDE] 811 Labovitz, C., "MRT Programmer's Guide", November 1999, 812 . 814 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 815 January 1997. 817 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 818 November 1998. 820 Appendix A. MRT Encoding Examples 822 This appendix, which is not a normative reference, contains a MRT 823 encoding examples. 825 The following example shows the encoding for a MRT record type of 826 BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS 827 numbers are encoded in 4 bytes fields due to the use of the 828 BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in 829 hexadecimal. The AS numbers in the ASPATH in the BGP Update are 830 encoded as 4 byte values in accord with the MRT BGP4MP_MESSAGE_AS4 831 subtype. 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type = 16 | Subtype = 4 | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Length = 82 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Peer AS = 64496 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Local AS = 64497 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Interface Index = 0 | Address Family = 1 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Peer IP address = 192.0.2.85 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Local IP address = 198.51.100.4 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | BGP Update = 854 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 855 00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03 856 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6 857 33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71 859 Figure 16: MRT BGP4MP_MESSAGE_AS4 Example 861 The contents of the BGP Update Message above are as follows: 863 ORIGIN: INCOMPLETE 864 ASPATH: 64496 64511 64502 865 NEXT_HOP: 198.51.100.188 866 COMMUNITY: 64496:14 867 NLRI: 203.0.113.0/24 869 Figure 17: BGP Message Contents 871 The following example displays the encoding for a MRT record type of 872 TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this 873 example contains 2 entries. 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type = 13 | Subtype = 1 | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Length = 34 | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Collector BGP ID = 198.51.100.4 | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | View Name Length = 0 | Peer Count = 2 | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Peer Type = 2 | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Peer BGP ID = 198.51.100.5 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Peer IP address = 198.51.100.5 | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Peer AS = 65541 | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Peer Type = 2 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Peer BGP ID = 192.0.2.33 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Peer IP address = 192.0.2.33 | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Peer AS = 65542 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Figure 18: MRT PEER_INDEX_TABLE Example 907 The following example displays the encoding for a MRT record type of 908 TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to 909 the NLRI prefix of 2001:0DB8::/32. There is a single entry for this 910 prefix. The entry applies to the peer identified by index location 911 15 in a preceding MRT PEER_INDEX_TABLE record. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Type = 13 | Subtype = 4 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Length = 87 | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Sequence number = 42 | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Preflen = 32 | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Prefix = 2001:0DB8::/32 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Entry Count = 1 | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Peer Index = 15 | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 |Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Attribute Length = 68 | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | BGP Path Attributes = 938 40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00 939 fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d 940 b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00 941 00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20 942 20 01 0d b8 944 Figure 19: MRT RIB_IPV6_UNICAST Example 946 The contents of the BGP Path Attribute field above are as follows: 948 ORIGIN: IGP 949 ASPATH: 64496 64511 64502 950 MP_REACH_NLRI(IPv6 Unicast) 951 NEXT_HOP: 2001:db8:d:ff::187 952 NEXT_HOP: fe80::212:f2ff:fe9f:1b00 953 NLRI: 2001:0DB8::/32 955 Figure 20: BGP Path Attribute contents 957 Appendix B. Deprecated MRT Types 959 This Appendix lists deprecated MRT types. These types are documented 960 for informational purposes. 962 B.1. Deprecated MRT Informational Types 964 The initial MRT format defined five Informational Type records. 965 These records were intended to signal the state of an MRT data 966 collector and do not contain routing information. These records were 967 intended for use when MRT records were sent over a network to a 968 remote repository store. However, MRT record repository stores have 969 traditionally resided on the same device as the collector and these 970 Informational Types are not known to be implemented. Further, 971 transport mechanisms for MRT records are considered to be outside the 972 scope of this document. 974 The message field MAY contain an OPTIONAL string for diagnostic 975 purposes. The message string encoding MUST follow the UTF-8 976 transformation format [RFC3629]. The Subtype field is unused for 977 these Types and SHOULD be set to 0. 979 The MRT Informational Types are defined below: 981 0 NULL 982 1 START 983 2 DIE 984 3 I_AM_DEAD 985 4 PEER_DOWN 987 B.1.1. NULL Type 989 The NULL Type message causes no operation. 991 B.1.2. START Type 993 The START Type indicates a collector is about to begin generating MRT 994 records. 996 B.1.3. DIE Type 998 The DIE Type signals a remote MRT repository it SHOULD stop accepting 999 messages. 1001 B.1.4. I_AM_DEAD Type 1003 An I_AM_DEAD MRT record indicates that a collector has shut down and 1004 has stopped generating MRT records. 1006 B.1.5. PEER_DOWN Type 1008 The PEER_DOWN message was intended to indicate that a collector had 1009 lost association with a BGP peer. However, the MRT format provides 1010 BGP state change message types which duplicate this functionality. 1012 B.2. Other Deprecated MRT Types 1014 5 BGP 1015 6 RIP 1016 7 IDRP 1017 8 RIPNG 1018 9 BGP4PLUS 1019 10 BGP4PLUS_01 1021 B.2.1. BGP Type 1023 The BGP Type indicates the Message field contains BGP routing 1024 information. The BGP routing protocol is defined in RFC 4271 1025 [RFC4271]. The information in the message is dependent on the 1026 Subtype value. The BGP Type and all associated Subtypes below are 1027 considered to be deprecated by the BGP4MP Type. 1029 The following BGP Subtypes are defined for the MRT BGP Type. As with 1030 the BGP Type itself, they are all considered to be deprecated. 1032 0 BGP_NULL 1033 1 BGP_UPDATE 1034 2 BGP_PREF_UPDATE 1035 3 BGP_STATE_CHANGE 1036 4 BGP_SYNC 1037 5 BGP_OPEN 1038 6 BGP_NOTIFY 1039 7 BGP_KEEPALIVE 1041 B.2.1.1. BGP_NULL Subtype 1043 The BGP_NULL Subtype is a reserved Subtype. 1045 B.2.1.2. BGP_UPDATE Subtype 1047 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 1048 format of the MRT Message field for this Subtype is as follows: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Peer AS number | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Peer IP address | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Local AS number | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Local IP address | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | BGP UPDATE Contents (variable) 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 Figure 21: BGP_UPDATE Subtype 1066 The BGP UPDATE Contents include the entire BGP UPDATE message which 1067 follows the BGP Message Header. The BGP Message Header itself is not 1068 included. The Peer AS number and IP address fields contain the AS 1069 number and IP address of the remote system which are generating the 1070 BGP UPDATE messages. The Local AS number and IP address fields 1071 contain the AS number and IP address of the local collector system 1072 which is archiving the messages. 1074 B.2.1.3. BGP_PREF_UPDATE Subtype 1076 The BGP_PREF_UPDATE Subtype is not defined. 1078 B.2.1.4. BGP_STATE_CHANGE Subtype 1080 The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP 1081 finite state machine. These FSM states are defined in RFC 4271 1082 [RFC4271], Section 8.2.2. Both the old state value and the new state 1083 value are encoded as 2-octet numbers. The state values are defined 1084 numerically as follows: 1086 1 Idle 1087 2 Connect 1088 3 Active 1089 4 OpenSent 1090 5 OpenConfirm 1091 6 Established 1093 The format of the BGP_STATE_CHANGE Subtype MRT Message field is as 1094 follows: 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Peer AS number | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Peer IP address | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Old State | New State | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 22: BGP_STATE_CHANGE Subtype 1108 B.2.1.5. BGP_SYNC Subtype 1110 The BGP_SYNC Subtype was intended to convey a system file name where 1111 BGP Table Dump messages MAY be recorded. The View # was to 1112 correspond to the View # provided in the TABLE_DUMP Type records. 1113 There are no known implementations of this subtype and it SHOULD be 1114 ignored. The following format applies to this Subtype: 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | View # | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | File Name... (variable) 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Figure 23: BGP_SYNC Subtype 1126 The File Name is terminated with a NULL (0) character. 1128 B.2.1.6. BGP_OPEN Subtype 1130 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 1131 of the MRT Message field for this Subtype is the same as the 1132 BGP_UPDATE, however, the last field contains the contents of the BGP 1133 OPEN message. 1135 B.2.1.7. BGP_NOTIFY Subtype 1137 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 1138 The format of the MRT Message field for this Subtype is the same as 1139 the BGP_UPDATE, however, the last field contains the contents of the 1140 BGP NOTIFICATION message. 1142 B.2.1.8. BGP_KEEPALIVE Subtype 1144 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 1145 The format of the MRT Message field for this Subtype is the same as 1146 the BGP_UPDATE, however, the last field contains no information. 1148 B.2.2. RIP Type 1150 The RIP Type is used to export RIP protocol packets as defined in RFC 1151 2453 [RFC2453]. The Subtype field is currently reserved for this 1152 Type and SHOULD be set to 0. 1154 The format of the MRT Message field for the RIP Type is as follows: 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Peer IP address | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Local IP address | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | RIP Message Contents (variable) 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Figure 24: RIP Type 1168 B.2.3. IDRP Type 1170 The IDRP Type was intended to be used to export Inter-Domain-Routing 1171 Protocol (IDRP) protocol information as defined in the ISO/IEC 10747 1172 standard. However, this Type has seen no known use and there are no 1173 details on protocol encoding for this Type. 1175 B.2.4. RIPNG Type 1177 The RIPNG Type is used to export RIPNG protocol packets as defined in 1178 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 1179 support IPv6. The Subtype field is currently reserved for this Type 1180 and SHOULD be set to 0. 1182 The format of the MRT Message field for the RIPNG Type is as follows: 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | | 1188 ~ Peer IPv6 address ~ 1189 | | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | | 1192 ~ Local IPv6 address ~ 1193 | | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | RIPNG Message Contents (variable) 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 25: RIPNG Type 1200 B.2.5. BGP4PLUS and BGP4PLUS_01 Types 1202 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 1203 routing information. The BGP4PLUS Type was specified based on the 1204 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 1205 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 1206 this Internet Draft. The two Types share the same definitions in 1207 terms of their MRT format specifications. 1209 The Subtype field definitions are shared with the BGP Type, however, 1210 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1211 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to 1212 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1213 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1214 Type. 1216 B.2.6. Deprecated BGP4MP Subtypes 1218 The following two subtypes of the BGP4MP Type are considered to be 1219 deprecated. 1221 2 BGP4MP_ENTRY 1222 3 BGP4MP_SNAPSHOT 1224 B.2.6.1. BGP4MP_ENTRY Subtype 1226 This Subtype is similar to the TABLE_DUMP Type and is used to record 1227 RIB table entries. It was intended to include true multiprotocol 1228 support. However, this Subtype does not support 4-Byte AS numbers 1229 and has not been widely implemented. 1231 0 1 2 3 1232 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 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Peer AS number | Local AS number | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Interface Index | Address Family | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Peer IP address (variable) | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Local IP address (variable) | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | View # | Status | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Time last change | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Address Family | SAFI | Next-Hop-Len | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Next Hop Address (variable) | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Prefix Length | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Address Prefix (variable) | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Attribute Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | BGP Attribute... (variable) 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Figure 26: BGP4MP_ENTRY Subtype 1261 B.2.6.2. BGP4MP_SNAPSHOT Subtype 1263 This Subtype was intended to convey a system file name where 1264 BGP4MP_ENTRY records MAY be recorded. It is similar to the BGP_SYNC 1265 Subtype and is deprecated. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | View # | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | File Name... (variable) 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 27: BGP4MP_SNAPSHOT Subtype 1277 Appendix C. Acknowledgements 1279 The initial MRT specification was developed by Craig Labovitz for use 1280 in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type 1281 was introduced in the Zebra routing software project by Kunihiro 1282 Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the 1283 Python Routeing Toolkit (PyRT) developed by Richard Mortier while at 1284 Sprint Advanced Technology Labs. 1286 Authors' Addresses 1288 Larry Blunk 1289 Merit Network 1291 Email: ljb@merit.edu 1293 Manish Karir 1294 Merit Network 1296 Email: mkarir@merit.edu 1298 Craig Labovitz 1299 Arbor Networks 1301 Email: labovit@arbor.net