--- 1/draft-ietf-grow-mrt-10.txt 2010-03-09 00:11:01.000000000 +0100 +++ 2/draft-ietf-grow-mrt-11.txt 2010-03-09 00:11:01.000000000 +0100 @@ -1,20 +1,28 @@ Network Working Group L. Blunk Internet-Draft M. Karir Intended status: Standards Track Merit Network -Expires: January 14, 2010 C. Labovitz +Expires: September 9, 2010 C. Labovitz Arbor Networks - July 13, 2009 + March 8, 2010 MRT routing information export format - draft-ietf-grow-mrt-10.txt + draft-ietf-grow-mrt-11.txt + +Abstract + + This document describes the MRT format for routing information + export. This format was developed in concert with the Multi-threaded + Routing Toolkit (MRT) from whence the format takes it name. The + format can be used to export routing protocol messages, state + changes, and routing information base contents. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,83 +31,81 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 14, 2010. + This Internet-Draft will expire on September 9, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - This document describes the MRT format for routing information - export. This format was developed in concert with the Multi-threaded - Routing Toolkit (MRT) from whence the format takes it name. The - format can be used to export routing protocol messages, state - changes, and routing information base contents. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 - 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 - 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15 + 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16 + 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17 + 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 - 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 - Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22 - A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22 - A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22 - A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22 - A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22 - A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22 - A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22 - A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25 - A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25 - A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25 - A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26 - A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 + Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23 + A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23 + A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23 + A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23 + A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23 + A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23 + A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23 + A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26 + A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26 + A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26 + A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27 + A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Researchers and engineers often wish to analyze network behavior by @@ -283,24 +289,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attribute... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The View field is normally 0 and is intended for cases where an implementation may have multiple RIB views (such as a route server). - The Sequence field is a simple incremental counter for each RIB - entry. A typical RIB dump will exceed the 16-bit bounds of this - counter and implementation should simply wrap back to zero and - continue incrementing the counter in such cases. + In cases where multiple RIB views are present, an implementation may + use the the view field to distinguish entries from each view. The + Sequence field is a simple incremental counter for each RIB entry. A + typical RIB dump will exceed the 16-bit bounds of this counter and + implementation should simply wrap back to zero and continue + incrementing the counter in such cases. The Prefix field contains the IP address of a particular RIB entry. The size of this field is dependent on the value of the Subtype for this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it is 16 octets in length. The Prefix Length field indicates the length in bits of the prefix mask for the preceding Prefix field. The Status octet is not used in the TABLE_DUMP Type and SHOULD be set to 1. @@ -314,21 +322,21 @@ field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 octet field and an IPv6 address. The Peer AS field contains the AS number of the peer. Attribute length is the length of Attribute field and is 2-octets. The Attribute field contains the attribute information for the RIB entry. 5.3. TABLE_DUMP_V2 Type - The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT + The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte ASN support and full support for BGP Multiprotocol extensions. It also improves upon the space efficiency of the TABLE_DUMP Type by employing an index table for peers and permitting a single MRT record per NLRI entry. The following subtypes are used with the TABLE_DUMP_V2 Type. 1 PEER_INDEX_TABLE 2 RIB_IPV4_UNICAST 3 RIB_IPV4_MULTICAST 4 RIB_IPV6_UNICAST @@ -454,27 +462,30 @@ This Type was initially defined in the Zebra software package for the BGP protocol with multiprotocol extension support as defined by RFC 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The BGP4MP Type has six Subtypes which are defined as follows: 0 BGP4MP_STATE_CHANGE 1 BGP4MP_MESSAGE 4 BGP4MP_MESSAGE_AS4 5 BGP4MP_STATE_CHANGE_AS4 + 6 BGP4MP_MESSAGE_LOCAL + 7 BGP4MP_MESSAGE_AS4_LOCAL 5.4.1. BGP4MP_STATE_CHANGE Subtype This record is used to encode state changes in the BGP finite state machine. The BGP FSM states are encoded in the Old State and New - State fields to indicate the previous and current state. The format - is illustrated below: + State fields to indicate the previous and current state. In some + cases, the Peer AS number may be undefined. In such cases, the value + of this field may be set to zero. The format is illustrated below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -501,26 +512,27 @@ be zero if unknown or unsupported. The Address Family indicates what types of addresses are in the the address fields. At present, the following AFI Types are supported: 1 AFI_IPv4 2 AFI_IPv6 5.4.2. BGP4MP_MESSAGE Subtype This Subtype is used to encode BGP Messages. It can be used to - encode any Type of BGP message. In order to determine the BGP - message Type, the entire BGP message is included in the BGP Message - field. This includes the 16-octet marker, the 2-octet length, and - the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does - not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates - the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The + encode any Type of BGP message. The entire BGP message is + encapsulated in the BGP Message field, including the 16-octet marker, + the 2-octet length, and the 1-octet type fields. Note that the + BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further, + the AS_PATH contained in these messages MUST only consist of 2-Byte + AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the + BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The BGP4MP_MESSAGE fields are shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | @@ -540,67 +552,87 @@ 2 AFI_IPv6 Note that the Address Family value only applies to the IP addresses contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise transparent to the contents of the actual message which may contain any valid AFI/SAFI values. Only one BGP message may be encoded in the BGP4MP_MESSAGE Subtype. 5.4.3. BGP4MP_MESSAGE_AS4 Subtype - This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT + This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is - otherwise identical to the BGP4MP_MESSAGE Subtype. The + otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in + these messages MUST only consist of 4-Byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype - This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT - Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, - the BGP FSM states are encoded in the Old State and New State fields - to indicate the previous and current state. Aside from the extension - of the peer and local AS fields to 32 bits, this subtype is otherwise - identical to the BGP4MP_STATE_CHANGE Subtype. The - BGP4MP_STATE_CHANGE_AS4 fields are shown below: + This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support + 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE + Subtype, the BGP FSM states are encoded in the Old State and New + State fields to indicate the previous and current state. Aside from + the extension of the peer and local AS fields to 4-Bytes, this + subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. + The BGP4MP_STATE_CHANGE_AS4 fields are shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +5.4.5. BGP4MP_MESSAGE_LOCAL Subtype + + Implementations of MRT have largely focused on collecting remotely + generated BGP messages in a passive route collector role. However, + for active BGP implementations, it can be useful to archive locally + generated BGP messages in addition to remote messages. This subtype + is added to indicated a locally generated BGP message. The fields + remain identical to the BGP4MP_MESSAGE type including the Peer and + Local IP and AS fields. The Local fields continue to refer to the + local IP and AS number of the collector which generated the message + and the Peer IP and AS fields refer to the receipient of the + generated BGP messages. + +5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype + + As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally + generated messages. The fields are identical to the + BGP4MP_MESSAGE_AS4 message type. + 5.5. BGP4MP_ET Type This Type was initially defined in the Sprint Labs Python Routing Toolkit (PyRT). It extends the MRT common header field to include a 32BIT microsecond timestamp field. The type and subtype field definitions remain as defined for the BGP4MP Type. The 32BIT microsecond timestamp immediately follows the length field in the MRT common header and precedes all other fields in the message. The 32BIT microsecond field is included in the computation of the length field value. The MRT common header modification is illustrated @@ -670,39 +702,42 @@ specification, in accordance with BCP 26, RFC 5226 [RFC5226]. There are two name spaces in MRT that require registration: Type Codes and Subtype Codes. MRT is not intended as a general-purpose specification for protocol information export, and allocations should not be made for purposes unrelated to routing protocol information export. The following policies are used here with the meanings defined in BCP - 26: "Specification Required", "IETF Consensus". + 26: "Specification Required", "IETF Consensus", "Experimental Use", + "First Come First Served". 6.1. Type Codes - Type Codes have a range from 0 to 65535, of which 0-64 have been + Type Codes have a range from 0 to 65535, of which 1-64 have been allocated. New Type Codes MUST be allocated starting at 65. Type - Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes - 32768 - 65535 are assigned based on Specification Required. + Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 - + 2047 are assigned based on Specification Required. Type Codes 2048 - + 64511 are available on a First Come First Served policy. Type Codes + 64512 - 65534 are available for Experimental Use. The Type Code + Values of 0 and 65535 are reserved. 6.2. Subtype Codes Subtype Codes have a range from 0 to 65535. Subtype definitions are specific to a particular Type Code definition. New Subtype Code definition must reference an existing Type Code to which the Subtype - belongs. As Subtype Codes are specific to Type Codes, new numbers - must be unique for the particular Type Code to which the Subtype - applies. Subtype Codes specific to the Type Codes 0 - 32767 are - assigned by IETF Consensus. Subtype Codes specific to Type Codes - 32768 - 65535 are assigned based on Specification Required. + belongs. Subtype assignmnents to Type Codes 0 - 511 are to be + assigned by IETF Review. Subtype assignments for the remaning Type + Codes follow the assignment rules for the Type Codes to which they + belong. 7. Security Considerations The MRT Format utilizes a structure which can store routing protocol information data. The fields defined in the MRT specification are of a descriptive nature and provide information that is useful to facilitate the analysis of routing data. As such, the fields currently defined in the MRT specification do not in themselves create additional security risks, since the fields are not used to induce any particular behavior by the recipient application. @@ -973,23 +1008,23 @@ The following two subtypes of the BGP4MP Type are considered to be deprecated. 2 BGP4MP_ENTRY 3 BGP4MP_SNAPSHOT A.2.6.1. BGP4MP_ENTRY Subtype This Subtype is similar to the TABLE_DUMP Type and is used to record RIB table entries. It extends the TABLE_DUMP Type to include true - multiprotocol support. However, this Type does not support 32BIT AS + multiprotocol support. However, this Type does not support 4-Byte AS numbers and has not been widely implemented. This Type is deprecated - in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support + in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support and a more compact format. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) |