draft-ietf-grow-mrt-11.txt (55535B)
1 2 3 4 Network Working Group L. Blunk 5 Internet-Draft M. Karir 6 Intended status: Standards Track Merit Network 7 Expires: September 9, 2010 C. Labovitz 8 Arbor Networks 9 March 8, 2010 10 11 12 MRT routing information export format 13 draft-ietf-grow-mrt-11.txt 14 15 Abstract 16 17 This document describes the MRT format for routing information 18 export. This format was developed in concert with the Multi-threaded 19 Routing Toolkit (MRT) from whence the format takes it name. The 20 format can be used to export routing protocol messages, state 21 changes, and routing information base contents. 22 23 Status of this Memo 24 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 27 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 32 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 40 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 43 44 This Internet-Draft will expire on September 9, 2010. 45 46 Copyright Notice 47 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 50 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 53 54 55 Blunk, et al. Expires September 9, 2010 [Page 1] 56 57 Internet-Draft MRT Format March 2010 58 59 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 Blunk, et al. Expires September 9, 2010 [Page 2] 112 113 Internet-Draft MRT Format March 2010 114 115 116 Table of Contents 117 118 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 119 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 120 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 121 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 122 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 123 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 124 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 125 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 126 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10 127 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 128 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 129 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 130 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 131 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 132 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16 133 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17 134 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17 135 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 136 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 137 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18 138 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18 139 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19 140 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 141 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 142 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 143 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 144 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 145 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 146 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 147 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23 148 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23 149 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23 150 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23 151 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23 152 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23 153 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23 154 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26 155 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26 156 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26 157 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27 158 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 160 161 162 163 164 165 166 167 Blunk, et al. Expires September 9, 2010 [Page 3] 168 169 Internet-Draft MRT Format March 2010 170 171 172 1. Requirements notation 173 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 Blunk, et al. Expires September 9, 2010 [Page 4] 224 225 Internet-Draft MRT Format March 2010 226 227 228 2. Introduction 229 230 Researchers and engineers often wish to analyze network behavior by 231 studying routing protocol transactions and routing information base 232 snapshots. To this end, the MRT format was developed to encapsulate, 233 export, and archive this information in a standardized data 234 representation. The BGP routing protocol, in particular, has been 235 the subject of extensive study and analysis which has been 236 significantly aided by the availability of the MRT format. The MRT 237 format was initially defined in the MRT Programmer's Guide [MRT PROG 238 GUIDE]. 239 240 This memo serves to document the MRT format as currently implemented 241 in publicly available software. The format has been extended since 242 it's original introduction in the MRT toolset and these extensions 243 are also included in this memo. Further extensions may be introduced 244 at a later date through additional definitions of the MRT Type field 245 and Subtype fields. 246 247 A number of MRT message types have been documented in some references 248 but are not known to have been implemented. Further, several types 249 were employed in early MRT implementations, but are no longer 250 actively being used. These types are considered to be deprecated and 251 are documented in a separate appendix at the end of this document. 252 Some of the deprecated types may of interest to researchers examining 253 historical MRT archives. 254 255 Fields which contain multi-octet numeric values are encoded in 256 network octet order from most significant octet to least significant 257 octet. Fields which contain routing message fields are encoded in 258 the same order as they appear in the packet contents. 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 Blunk, et al. Expires September 9, 2010 [Page 5] 280 281 Internet-Draft MRT Format March 2010 282 283 284 3. Basic MRT Format 285 286 All MRT format messages have a common header which includes a 287 timestamp, Type, Subtype, and length field. The header is followed 288 by a message field. The MRT common header is illustrated below. 289 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Timestamp | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Subtype | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Message... (variable) 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 302 Header Field Descriptions: 303 304 305 Timestamp: 306 307 Time in seconds since 1 January 1970 00:00:00 UTC 308 309 310 Type: 311 312 A 2-octet field that indicates the Type of information 313 contained in the message field. Types 0 through 4 are 314 informational messages pertaining to the state of an MRT 315 collector, while Types 5 and higher are used to convey routing 316 information. 317 318 319 Subtype: 320 321 A 2-octet field that is used to further distinguish message 322 information within a particular message Type. 323 324 325 Length: 326 327 A 4-octet message length field. The length field contains the 328 number of octets within the message. The length field does not 329 include the length of the MRT common header. 330 331 332 333 334 335 Blunk, et al. Expires September 9, 2010 [Page 6] 336 337 Internet-Draft MRT Format March 2010 338 339 340 341 Message: 342 343 A variable length message. The contents of this field are 344 context dependent upon the Type and Subtype fields. 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 Blunk, et al. Expires September 9, 2010 [Page 7] 392 393 Internet-Draft MRT Format March 2010 394 395 396 4. MRT Informational Types 397 398 The MRT format defines five Informational Type messages. These 399 messages are intended to signal the state of an MRT data collector 400 and do not contain routing information. These messages are OPTIONAL 401 and were largely intended for use when MRT messages are sent over a 402 network to a remote repository store. However, MRT message 403 repository stores have traditionally resided on the same device as 404 the collector and these Informational Types have seen limited 405 implementation. Further, transport mechanisms for MRT messages are 406 considered to be outside the scope of this document. 407 408 The START and I_AM_DEAD messages MAY be used to provide a time 409 reference when a data collector begins and ends the collection 410 process. The time reference is obtained from the Timestamp field in 411 the MRT message header. 412 413 The message field MAY contain an OPTIONAL message string for 414 diagnostic purposes. The message string encoding MUST follow the 415 UTF-8 transformation format. The Subtype field is unused for these 416 Types and SHOULD be set to 0. 417 418 The MRT Informational Types are defined below: 419 420 1 START 421 3 I_AM_DEAD 422 423 4.1. START Type 424 425 The START Type indicates a collector is about to begin generating MRT 426 messages. 427 428 4.2. I_AM_DEAD Type 429 430 An I_AM_DEAD MRT message indicates that a collector has shut down and 431 has stopped generating MRT messages. 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 Blunk, et al. Expires September 9, 2010 [Page 8] 448 449 Internet-Draft MRT Format March 2010 450 451 452 5. MRT Routing Information Types 453 454 The following Types are currently defined for the MRT format. Types 455 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type, 456 number 16, was initially defined in the Zebra routing software 457 package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially 458 defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3 459 and OSPFv3_ET Types are newly defined types created for the OSPFv3 460 routing protocol. 461 462 11 OSPF 463 12 TABLE_DUMP 464 13 TABLE_DUMP_V2 465 16 BGP4MP 466 17 BGP4MP_ET 467 32 ISIS 468 33 ISIS_ET 469 48 OSPFv3 470 49 OSPFv3_ET 471 472 5.1. OSPF Type 473 474 This Type supports the OSPF Protocol as defined in RFC 2328 475 [RFC2328]. The Subtype field may contain two possible values: 476 477 0 OSPF_STATE_CHANGE 478 1 OSPF_LSA_UPDATE 479 480 The format of the MRT Message field for the OSPF Type is as follows: 481 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Remote IP address | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Local IP address | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | OSPF Message Contents (variable) 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 492 493 494 495 496 497 498 499 500 501 502 503 Blunk, et al. Expires September 9, 2010 [Page 9] 504 505 Internet-Draft MRT Format March 2010 506 507 508 5.2. TABLE_DUMP Type 509 510 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 511 Information Base (RIB). Each RIB entry is encoded in a distinct 512 sequential MRT record. The Subtype field is used to encode whether 513 the RIB entry contains IPv4 or IPv6 addresses. There are two 514 possible values for the Subtype as shown below. 515 516 1 AFI_IPv4 517 2 AFI_IPv6 518 519 The format of the TABLE_DUMP Type is illustrated below. 520 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | View # | Sequence number | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Prefix (variable) | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Prefix Length | Status | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Originated Time | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Peer IP address (variable) | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Peer AS | Attribute Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | BGP Attribute... (variable) 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 539 The View field is normally 0 and is intended for cases where an 540 implementation may have multiple RIB views (such as a route server). 541 In cases where multiple RIB views are present, an implementation may 542 use the the view field to distinguish entries from each view. The 543 Sequence field is a simple incremental counter for each RIB entry. A 544 typical RIB dump will exceed the 16-bit bounds of this counter and 545 implementation should simply wrap back to zero and continue 546 incrementing the counter in such cases. 547 548 The Prefix field contains the IP address of a particular RIB entry. 549 The size of this field is dependent on the value of the Subtype for 550 this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it 551 is 16 octets in length. The Prefix Length field indicates the length 552 in bits of the prefix mask for the preceding Prefix field. 553 554 The Status octet is not used in the TABLE_DUMP Type and SHOULD be set 555 to 1. 556 557 558 559 Blunk, et al. Expires September 9, 2010 [Page 10] 560 561 Internet-Draft MRT Format March 2010 562 563 564 The Originated Time contains the 4-octet time at which this prefix 565 was heard. The value represents the time in seconds since 1 January 566 1970 00:00:00 UTC. 567 568 The Peer IP field is the IP address of the peer which provided the 569 update for this RIB entry. As with the Prefix field, the size of 570 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 571 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 572 octet field and an IPv6 address. The Peer AS field contains the AS 573 number of the peer. 574 575 Attribute length is the length of Attribute field and is 2-octets. 576 The Attribute field contains the attribute information for the RIB 577 entry. 578 579 5.3. TABLE_DUMP_V2 Type 580 581 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte 582 ASN support and full support for BGP Multiprotocol extensions. It 583 also improves upon the space efficiency of the TABLE_DUMP Type by 584 employing an index table for peers and permitting a single MRT record 585 per NLRI entry. The following subtypes are used with the 586 TABLE_DUMP_V2 Type. 587 588 1 PEER_INDEX_TABLE 589 2 RIB_IPV4_UNICAST 590 3 RIB_IPV4_MULTICAST 591 4 RIB_IPV6_UNICAST 592 5 RIB_IPV6_MULTICAST 593 6 RIB_GENERIC 594 595 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 596 collector, an optional view name, and a list of indexed peers. 597 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 598 are used to encode RIB table entries. This series of MRT records use 599 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 600 itself and include full MRT record headers. The header of the 601 PEER_INDEX_TABLE Subtype is shown below. The View Name is optional 602 and, if not present, the View Name Length MUST be set to 0. The View 603 Name encoding MUST follow the UTF-8 transformation format. 604 605 606 607 608 609 610 611 612 613 614 615 Blunk, et al. Expires September 9, 2010 [Page 11] 616 617 Internet-Draft MRT Format March 2010 618 619 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Collector BGP ID | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | View Name Length | View Name (variable) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Peer Count | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 630 The format of the peer entries is shown below. The PEER_INDEX_TABLE 631 record contains Peer Count peer entries. 632 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Peer Type | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Peer BGP ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Peer IP address (variable) | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Peer AS (variable) | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 645 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 646 as indicated by the Peer Count field. The position of the Peer in 647 the PEER_INDEX_TABLE is used as an index in the subsequent 648 TABLE_DUMP_V2 MRT records. The index number begins with 0. 649 650 The Peer Type field is a bit field which encodes the type of the AS 651 and IP address as follows: 652 653 Bit 0 - unset for IPv4 Peer IP address, set for IPv6 654 Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits 655 656 The records which follow the PEER_INDEX_TABLE record constitute the 657 RIB entries and include a header which specifies a sequence number, 658 NLRI, and a count of the number of RIB entries which follow. 659 660 The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, 661 RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 662 The Prefix Length and Prefix fields are encoded in the same manner as 663 the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix 664 field contains address prefixes followed by enough trailing bits to 665 make the end of the field fall on an octet boundary. Note that the 666 value of trailing bits is irrelevant. 667 668 669 670 671 Blunk, et al. Expires September 9, 2010 [Page 12] 672 673 Internet-Draft MRT Format March 2010 674 675 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sequence number | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Prefix Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Prefix (variable) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Entry Count | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 688 The RIB_GENERIC header is shown below. It includes Address Family 689 Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI 690 information is specific to the AFI and SAFI values. An 691 implementation which does not recognize particular AFI and SAFI 692 values SHOULD discard the remainder of the MRT record. 693 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Sequence number | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Address Family Identifier |Subsequent AFI | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Network Layer Reachability Information (variable) | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Entry Count | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 706 The RIB entry headers are followed by a series of RIB entries which 707 are repeated Entry Count times. These entries share a common format 708 as shown below. They include a Peer Index from the PEER_INDEX_TABLE 709 MRT record, an originated time for the RIB entry, and the BGP path 710 attribute length and attributes encoded as provided in a BGP Update 711 message. 712 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Peer Index | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Originated Time | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Attribute Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | BGP Attributes... (variable) 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 725 726 727 Blunk, et al. Expires September 9, 2010 [Page 13] 728 729 Internet-Draft MRT Format March 2010 730 731 732 There is one exception to the encoding of BGP attributes for the BGP 733 MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the 734 AFI, SAFI, and NLRI information is already encoded in the 735 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 736 Address fields are included. The Reserved field is omitted. The 737 attribute length is also adjusted to reflect only the length of the 738 Next Hop Address Length and Next Hop Address fields. 739 740 5.4. BGP4MP Type 741 742 This Type was initially defined in the Zebra software package for the 743 BGP protocol with multiprotocol extension support as defined by RFC 744 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 745 The BGP4MP Type has six Subtypes which are defined as follows: 746 747 0 BGP4MP_STATE_CHANGE 748 1 BGP4MP_MESSAGE 749 4 BGP4MP_MESSAGE_AS4 750 5 BGP4MP_STATE_CHANGE_AS4 751 6 BGP4MP_MESSAGE_LOCAL 752 7 BGP4MP_MESSAGE_AS4_LOCAL 753 754 5.4.1. BGP4MP_STATE_CHANGE Subtype 755 756 This record is used to encode state changes in the BGP finite state 757 machine. The BGP FSM states are encoded in the Old State and New 758 State fields to indicate the previous and current state. In some 759 cases, the Peer AS number may be undefined. In such cases, the value 760 of this field may be set to zero. The format is illustrated below: 761 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Peer AS number | Local AS number | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Interface Index | Address Family | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Peer IP address (variable) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Local IP address (variable) | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Old State | New State | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 776 777 778 779 780 781 782 783 Blunk, et al. Expires September 9, 2010 [Page 14] 784 785 Internet-Draft MRT Format March 2010 786 787 788 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 789 Both the old state value and the new state value are encoded as 790 2-octet numbers. The state values are defined numerically as 791 follows: 792 793 1 Idle 794 2 Connect 795 3 Active 796 4 OpenSent 797 5 OpenConfirm 798 6 Established 799 800 The BGP4MP_STATE_CHANGE message also includes interface index and 801 Address Family fields. The interface index provides the interface 802 number of the peering session. The index value is OPTIONAL and MAY 803 be zero if unknown or unsupported. The Address Family indicates what 804 types of addresses are in the the address fields. At present, the 805 following AFI Types are supported: 806 807 1 AFI_IPv4 808 2 AFI_IPv6 809 810 5.4.2. BGP4MP_MESSAGE Subtype 811 812 This Subtype is used to encode BGP Messages. It can be used to 813 encode any Type of BGP message. The entire BGP message is 814 encapsulated in the BGP Message field, including the 16-octet marker, 815 the 2-octet length, and the 1-octet type fields. Note that the 816 BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further, 817 the AS_PATH contained in these messages MUST only consist of 2-Byte 818 AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the 819 BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The 820 BGP4MP_MESSAGE fields are shown below: 821 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Peer AS number | Local AS number | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Interface Index | Address Family | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Peer IP address (variable) | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Local IP address (variable) | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | BGP Message... (variable) 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 836 837 838 839 Blunk, et al. Expires September 9, 2010 [Page 15] 840 841 Internet-Draft MRT Format March 2010 842 843 844 The interface index provides the interface number of the peering 845 session. The index value is OPTIONAL and MAY be zero if unknown or 846 unsupported. The Address Family indicates what types of addresses 847 are in the the subsequent address fields. At present, the following 848 AFI Types are supported: 849 850 1 AFI_IPv4 851 2 AFI_IPv6 852 853 Note that the Address Family value only applies to the IP addresses 854 contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 855 transparent to the contents of the actual message which may contain 856 any valid AFI/SAFI values. Only one BGP message may be encoded in 857 the BGP4MP_MESSAGE Subtype. 858 859 5.4.3. BGP4MP_MESSAGE_AS4 Subtype 860 861 This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte 862 Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is 863 otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in 864 these messages MUST only consist of 4-Byte AS numbers. The 865 BGP4MP_MESSAGE_AS4 fields are shown below: 866 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Peer AS number | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Local AS number | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Interface Index | Address Family | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Peer IP address (variable) | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Local IP address (variable) | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | BGP Message... (variable) 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 883 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 884 885 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 886 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE 887 Subtype, the BGP FSM states are encoded in the Old State and New 888 State fields to indicate the previous and current state. Aside from 889 the extension of the peer and local AS fields to 4-Bytes, this 890 subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. 891 The BGP4MP_STATE_CHANGE_AS4 fields are shown below: 892 893 894 895 Blunk, et al. Expires September 9, 2010 [Page 16] 896 897 Internet-Draft MRT Format March 2010 898 899 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Peer AS number | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Local AS number | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Interface Index | Address Family | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Peer IP address (variable) | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Local IP address (variable) | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Old State | New State | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 916 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype 917 918 Implementations of MRT have largely focused on collecting remotely 919 generated BGP messages in a passive route collector role. However, 920 for active BGP implementations, it can be useful to archive locally 921 generated BGP messages in addition to remote messages. This subtype 922 is added to indicated a locally generated BGP message. The fields 923 remain identical to the BGP4MP_MESSAGE type including the Peer and 924 Local IP and AS fields. The Local fields continue to refer to the 925 local IP and AS number of the collector which generated the message 926 and the Peer IP and AS fields refer to the receipient of the 927 generated BGP messages. 928 929 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 930 931 As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally 932 generated messages. The fields are identical to the 933 BGP4MP_MESSAGE_AS4 message type. 934 935 5.5. BGP4MP_ET Type 936 937 This Type was initially defined in the Sprint Labs Python Routing 938 Toolkit (PyRT). It extends the MRT common header field to include a 939 32BIT microsecond timestamp field. The type and subtype field 940 definitions remain as defined for the BGP4MP Type. The 32BIT 941 microsecond timestamp immediately follows the length field in the MRT 942 common header and precedes all other fields in the message. The 943 32BIT microsecond field is included in the computation of the length 944 field value. The MRT common header modification is illustrated 945 below. 946 947 948 949 950 951 Blunk, et al. Expires September 9, 2010 [Page 17] 952 953 Internet-Draft MRT Format March 2010 954 955 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Timestamp | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Type | Subtype | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Length | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | microsecond timestamp | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Message... (variable) 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 970 5.6. ISIS Type 971 972 This Type was initially defined in the Sprint Labs Python Routing and 973 supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. 974 There is no Type specific header for the ISIS Type. The Subtype code 975 for this Type is undefined. The ISIS PDU directly follows the MRT 976 common header fields. 977 978 5.7. ISIS_ET Type 979 980 The ISIS_ET Type extends the ISIS Type to support microsecond 981 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 982 timestamp field is appended to the MRT common header after the length 983 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 984 985 5.8. OSPFv3 Type 986 987 The OSPFv3 Type extends the original OSPF Type to support IPv6 988 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 989 The format of the MRT Message field for the OSPFv3 Type is as 990 follows: 991 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Address Family | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Remote IP address (variable) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Local IP address (variable) | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | OSPF Message Contents (variable) 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 1004 1005 1006 1007 Blunk, et al. Expires September 9, 2010 [Page 18] 1008 1009 Internet-Draft MRT Format March 2010 1010 1011 1012 5.9. OSPFv3_ET Type 1013 1014 The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond 1015 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 1016 timestamp field is appended to the MRT common header after the length 1017 field and its length is included in the calculation of the length 1018 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 1019 Type. 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 Blunk, et al. Expires September 9, 2010 [Page 19] 1064 1065 Internet-Draft MRT Format March 2010 1066 1067 1068 6. IANA Considerations 1069 1070 This section provides guidance to the Internet Assigned Numbers 1071 Authority (IANA) regarding registration of values related to the MRT 1072 specification, in accordance with BCP 26, RFC 5226 [RFC5226]. 1073 1074 There are two name spaces in MRT that require registration: Type 1075 Codes and Subtype Codes. 1076 1077 MRT is not intended as a general-purpose specification for protocol 1078 information export, and allocations should not be made for purposes 1079 unrelated to routing protocol information export. 1080 1081 The following policies are used here with the meanings defined in BCP 1082 26: "Specification Required", "IETF Consensus", "Experimental Use", 1083 "First Come First Served". 1084 1085 6.1. Type Codes 1086 1087 Type Codes have a range from 0 to 65535, of which 1-64 have been 1088 allocated. New Type Codes MUST be allocated starting at 65. Type 1089 Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 - 1090 2047 are assigned based on Specification Required. Type Codes 2048 - 1091 64511 are available on a First Come First Served policy. Type Codes 1092 64512 - 65534 are available for Experimental Use. The Type Code 1093 Values of 0 and 65535 are reserved. 1094 1095 6.2. Subtype Codes 1096 1097 Subtype Codes have a range from 0 to 65535. Subtype definitions are 1098 specific to a particular Type Code definition. New Subtype Code 1099 definition must reference an existing Type Code to which the Subtype 1100 belongs. Subtype assignmnents to Type Codes 0 - 511 are to be 1101 assigned by IETF Review. Subtype assignments for the remaning Type 1102 Codes follow the assignment rules for the Type Codes to which they 1103 belong. 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 Blunk, et al. Expires September 9, 2010 [Page 20] 1120 1121 Internet-Draft MRT Format March 2010 1122 1123 1124 7. Security Considerations 1125 1126 The MRT Format utilizes a structure which can store routing protocol 1127 information data. The fields defined in the MRT specification are of 1128 a descriptive nature and provide information that is useful to 1129 facilitate the analysis of routing data. As such, the fields 1130 currently defined in the MRT specification do not in themselves 1131 create additional security risks, since the fields are not used to 1132 induce any particular behavior by the recipient application. 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 Blunk, et al. Expires September 9, 2010 [Page 21] 1176 1177 Internet-Draft MRT Format March 2010 1178 1179 1180 8. References 1181 1182 8.1. Normative References 1183 1184 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 1185 June 1988. 1186 1187 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1188 dual environments", RFC 1195, December 1990. 1189 1190 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1191 January 1997. 1192 1193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1194 Requirement Levels", BCP 14, RFC 2119, March 1997. 1195 1196 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1197 1198 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1199 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1200 1201 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1202 "Multiprotocol Extensions for BGP-4", RFC 4760, 1203 January 2007. 1204 1205 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1206 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1207 May 2008. 1208 1209 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1210 for IPv6", RFC 5340, July 2008. 1211 1212 8.2. Informative References 1213 1214 [MRT PROG GUIDE] 1215 Labovitz, C., "MRT Programmer's Guide", November 1999, 1216 <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 Blunk, et al. Expires September 9, 2010 [Page 22] 1232 1233 Internet-Draft MRT Format March 2010 1234 1235 1236 Appendix A. Deprecated MRT types 1237 1238 This Appendix lists deprecated MRT types. These types are documented 1239 for informational purposes only. While documented in some 1240 references, they are not known to have been generally implemented. 1241 1242 A.1. Deprecated MRT Informational Types 1243 1244 The deprecated MRT Informational Types are defined below: 1245 1246 0 NULL 1247 2 DIE 1248 4 PEER_DOWN 1249 1250 A.1.1. NULL Type 1251 1252 The NULL Type message causes no operation. 1253 1254 A.1.2. DIE Type 1255 1256 The DIE Type signals a remote MRT repository it should stop accepting 1257 messages. 1258 1259 A.1.3. PEER_DOWN Type 1260 1261 The PEER_DOWN message was intended to indicate that a collector had 1262 lost association with a BGP peer. However, the MRT format provides 1263 BGP state change message types which duplicate this functionality. 1264 1265 A.2. Deprecated MRT Routing Information Types 1266 1267 5 BGP 1268 6 RIP 1269 7 IDRP 1270 8 RIPNG 1271 9 BGP4PLUS 1272 10 BGP4PLUS_01 1273 1274 A.2.1. BGP Type 1275 1276 The BGP Type indicates the Message field contains BGP routing 1277 information. The BGP routing protocol is defined in RFC 4271 1278 [RFC4271]. The information in the message is dependent on the 1279 Subtype value. The BGP Type and all associated Subtypes below are 1280 considered to be deprecated by the BGP4MP Type. 1281 1282 The following BGP Subtypes are defined for the MRT BGP Type. As with 1283 the BGP Type itself, they are all considered to be deprecated. 1284 1285 1286 1287 Blunk, et al. Expires September 9, 2010 [Page 23] 1288 1289 Internet-Draft MRT Format March 2010 1290 1291 1292 0 BGP_NULL 1293 1 BGP_UPDATE 1294 2 BGP_PREF_UPDATE 1295 3 BGP_STATE_CHANGE 1296 4 BGP_SYNC 1297 5 BGP_OPEN 1298 6 BGP_NOTIFY 1299 7 BGP_KEEPALIVE 1300 1301 A.2.1.1. BGP_NULL Subtype 1302 1303 The BGP_NULL Subtype is a reserved Subtype. 1304 1305 A.2.1.2. BGP_UPDATE Subtype 1306 1307 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 1308 format of the MRT Message field for this Subtype is as follows: 1309 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Peer AS number | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Peer IP address | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Local AS number | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Local IP address | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | BGP UPDATE Contents (variable) 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 1324 The BGP UPDATE Contents include the entire BGP UPDATE message which 1325 follows the BGP Message Header. The BGP Message Header itself is not 1326 included. The Peer AS number and IP address fields contain the AS 1327 number and IP address of the remote system which are generating the 1328 BGP UPDATE messages. The Local AS number and IP address fields 1329 contain the AS number and IP address of the local collector system 1330 which is archiving the messages. 1331 1332 A.2.1.3. BGP_PREF_UPDATE Subtype 1333 1334 The BGP_PREF_UPDATE Subtype is not defined. 1335 1336 A.2.1.4. BGP_STATE_CHANGE Subtype 1337 1338 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 1339 finite state machine. These FSM states are defined in RFC 4271 1340 1341 1342 1343 Blunk, et al. Expires September 9, 2010 [Page 24] 1344 1345 Internet-Draft MRT Format March 2010 1346 1347 1348 [RFC4271], Section 8.2.2. Both the old state value and the new state 1349 value are encoded as 2-octet numbers. The state values are defined 1350 numerically as follows: 1351 1352 1 Idle 1353 2 Connect 1354 3 Active 1355 4 OpenSent 1356 5 OpenConfirm 1357 6 Established 1358 1359 The format of the MRT Message field is as follows: 1360 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Peer AS number | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Peer IP address | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Old State | New State | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 1371 A.2.1.5. BGP_SYNC Subtype 1372 1373 The BGP_SYNC Subtype was intended to convey a system file name where 1374 BGP Table Dump messages should be recorded. The View # was to 1375 correspond to the View # provided in the TABLE_DUMP Type messages. 1376 There are no known implementations of this subtype and it SHOULD be 1377 ignored. The following format applies to this Subtype: 1378 1379 0 1 2 3 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | View # | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | File Name... (variable) 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 1387 The File Name is terminated with a NULL (0) character. 1388 1389 A.2.1.6. BGP_OPEN Subtype 1390 1391 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 1392 of the MRT Message field for this Subtype is the same as the 1393 BGP_UPDATE, however, the last field contains the contents of the BGP 1394 OPEN message. 1395 1396 1397 1398 1399 Blunk, et al. Expires September 9, 2010 [Page 25] 1400 1401 Internet-Draft MRT Format March 2010 1402 1403 1404 A.2.1.7. BGP_NOTIFY Subtype 1405 1406 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 1407 The format of the MRT Message field for this Subtype is the same as 1408 the BGP_UPDATE, however, the last field contains the contents of the 1409 BGP NOTIFICATION message. 1410 1411 A.2.1.8. BGP_KEEPALIVE Subtype 1412 1413 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 1414 The format of the MRT Message field for this Subtype is the same as 1415 the BGP_UPDATE, however, the last field contains no information. 1416 1417 A.2.2. RIP Type 1418 1419 The RIP Type is used to export RIP protocol packets as defined in RFC 1420 1058 [RFC1058]. The Subtype field is currently reserved for this 1421 Type and SHOULD be set to 0. 1422 1423 The format of the MRT Message field for the RIP Type is as follows: 1424 1425 0 1 2 3 1426 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 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | Peer IP address | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Local IP address | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | RIP Message Contents (variable) 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 1435 A.2.3. IDRP Type 1436 1437 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 1438 protocol information as defined in the ISO/IEC 10747 standard. The 1439 Subtype field is unused. This Type is deprecated due to lack of 1440 deployment of IDRP. 1441 1442 A.2.4. RIPNG Type 1443 1444 The RIPNG Type is used to export RIPNG protocol packets as defined in 1445 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 1446 support IPv6. The Subtype field is currently reserved for this Type 1447 and SHOULD be set to 0. 1448 1449 The format of the MRT Message field for the RIPNG Type is as follows: 1450 1451 1452 1453 1454 1455 Blunk, et al. Expires September 9, 2010 [Page 26] 1456 1457 Internet-Draft MRT Format March 2010 1458 1459 1460 0 1 2 3 1461 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 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | | 1464 ~ Peer IPv6 address ~ 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | | 1468 ~ Local IPv6 address ~ 1469 | | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | RIPNG Message Contents (variable) 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 1474 A.2.5. BGP4PLUS and BGP4PLUS_01 Types 1475 1476 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 1477 routing information. The BGP4PLUS Type was specified based on the 1478 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 1479 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 1480 this Internet Draft. The two Types share the same definitions in 1481 terms of their MRT format specifications. 1482 1483 The Subtype field definitions are shared with the BGP Type, however, 1484 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1485 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 1486 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1487 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1488 Type. 1489 1490 A.2.6. Deprecated BGP4MP Subtypes 1491 1492 The following two subtypes of the BGP4MP Type are considered to be 1493 deprecated. 1494 1495 2 BGP4MP_ENTRY 1496 3 BGP4MP_SNAPSHOT 1497 1498 A.2.6.1. BGP4MP_ENTRY Subtype 1499 1500 This Subtype is similar to the TABLE_DUMP Type and is used to record 1501 RIB table entries. It extends the TABLE_DUMP Type to include true 1502 multiprotocol support. However, this Type does not support 4-Byte AS 1503 numbers and has not been widely implemented. This Type is deprecated 1504 in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support 1505 and a more compact format. 1506 1507 1508 1509 1510 1511 Blunk, et al. Expires September 9, 2010 [Page 27] 1512 1513 Internet-Draft MRT Format March 2010 1514 1515 1516 0 1 2 3 1517 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 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Peer AS number | Local AS number | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Interface Index | Address Family | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Peer IP address (variable) | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Local IP address (variable) | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | View # | Status | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Time last change | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Address Family | SAFI | Next-Hop-Len | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Next Hop Address (variable) | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Prefix Length | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Address Prefix (variable) | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Attribute Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | BGP Attribute... (variable) 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 1544 A.2.6.2. BGP4MP_SNAPSHOT Subtype 1545 1546 This Subtype was intended to convey a system file name where 1547 BGP4MP_ENTRY messages should be recorded. It is similar to the 1548 BGP_SYNC message Subtype and is deprecated. 1549 1550 0 1 2 3 1551 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 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | View # | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | File Name... (variable) 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 Blunk, et al. Expires September 9, 2010 [Page 28] 1568 1569 Internet-Draft MRT Format March 2010 1570 1571 1572 Authors' Addresses 1573 1574 Larry Blunk 1575 Merit Network 1576 1577 Email: ljb@merit.edu 1578 1579 1580 Manish Karir 1581 Merit Network 1582 1583 Email: mkarir@merit.edu 1584 1585 1586 Craig Labovitz 1587 Arbor Networks 1588 1589 Email: labovit@arbor.net 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 Blunk, et al. Expires September 9, 2010 [Page 29] 1624 1625