go-bgp

a collection of golang BGP tools to monitor, archive and serve
git clone git://git.2f30.org/go-bgp
Log | Files | Refs | README

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