IETF P. Cheng, Ed. Internet-Draft UCLA IRL Intended status: Informational H. Yan, Ed. Expires: August 19, 2009 K. Burnett, Ed. D. Massey, Ed. CSU-Netsec Group L. Zhang, Ed. UCLA IRL Feb 15, 2009 BGP routing information in XML format draft-cheng-grow-bgp-xml-00 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. Internet-Drafts are draft documents valid for a maximum of six months 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 August 19, 2009. Copyright Notice Copyright (c) 2009 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 (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. Cheng, et al. Expires August 19, 2009 [Page 1] Internet-Draft BGP in XML Feb 2009 Abstract This document describes the XML format for BGP routing information (XFB). It can be used to describe both BGP messages and BGP control information. Compared with MRT, XFB is more extensible, human and machine-readable and can serve as a common interface for a variety of tools. Requirements Language 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 RFC 2119 [RFC2119]. Cheng, et al. Expires August 19, 2009 [Page 2] Internet-Draft BGP in XML Feb 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. XML Notations . . . . . . . . . . . . . . . . . . . . . . 5 3. BGP Monitoring Service . . . . . . . . . . . . . . . . . . . . 5 4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. The XFB Data Model . . . . . . . . . . . . . . . . . . . . . . 7 5.1. BGP_MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. PEERING . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Representing the message . . . . . . . . . . . . . . . . . 10 5.5. OCTET_MESSAGE (BGP Message in Octet Format) . . . . . . . 10 5.6. ASCII_MSG (BGP Message in ASCII Format) . . . . . . . . . 11 5.6.1. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6.1.1. Defining and Processing the Parameter Value field . . . . . . . . . . . . . . . . . . . . . . 13 5.6.1.1.1. AUTHENTICATION . . . . . . . . . . . . . . . . 15 5.6.1.1.2. CAPABILITIES . . . . . . . . . . . . . . . . . 15 5.6.2. The UPDATE element . . . . . . . . . . . . . . . . . . 16 5.6.3. PATH_ATTRIBUTES Class . . . . . . . . . . . . . . . . 17 5.6.4. The KEEPALIVE . . . . . . . . . . . . . . . . . . . . 20 5.6.5. The ROUTE_REFRESH . . . . . . . . . . . . . . . . . . 20 5.6.6. The CISCO_ROUTE_REFRESH element . . . . . . . . . . . 21 5.6.7. The NOTIFICATION . . . . . . . . . . . . . . . . . . . 21 5.6.7.1. Example . . . . . . . . . . . . . . . . . . . . . 23 5.7. STATUS_MSG . . . . . . . . . . . . . . . . . . . . . . . . 23 5.7.1. BGPMON . . . . . . . . . . . . . . . . . . . . . . . . 23 5.7.2. QUEUE_STATUS / QUEUE . . . . . . . . . . . . . . . . . 24 5.7.3. CHAIN_STATUS / CHAIN . . . . . . . . . . . . . . . . . 25 5.7.4. SESSION_STATUS / SESSION . . . . . . . . . . . . . . . 26 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. BGP Open Message . . . . . . . . . . . . . . . . . . . . . 28 6.2. BGP Update Message . . . . . . . . . . . . . . . . . . . . 29 6.3. BGP Keepalive Message . . . . . . . . . . . . . . . . . . 34 6.4. BGP Notification Message . . . . . . . . . . . . . . . . . 35 6.5. Status Message . . . . . . . . . . . . . . . . . . . . . . 35 6.5.1. Queue Status Message . . . . . . . . . . . . . . . . . 35 6.5.2. Session Status Message . . . . . . . . . . . . . . . . 37 7. The XFB Schema . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.1. Normative References . . . . . . . . . . . . . . . . . . . 52 11.2. Informative References . . . . . . . . . . . . . . . . . . 53 Appendix A. Storage Size Comparison . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Cheng, et al. Expires August 19, 2009 [Page 3] Internet-Draft BGP in XML Feb 2009 1. Introduction BGP routing information is an essential resource for both researchers and operation communities in Internet routing. In order to facilitate the collection of BGP data from multiple sources and the usage of the collected data by multiple parties, it is important to define a standard format to encapsulate, export, and archive it. A well designed format should have the following nice properties o Human and machine-readable o Easily accessible o Suitable for further processing by existing tools o Easy to add user annotations o Easy to reconstuct raw BGP messages / ability to replay into router o Record full control information o Support BGP extensions In this document, we describe XFB, a XML-based format for BGP routing information, which is designed to meet these requirements. XML (eXensible Markup Language) is a general-purpose markup language; its primary purpose is to facilitate the message exchange across different information systems, particularly via the Internet. Using XML as the base for our XFB markup provides the following advantages: o XFB is human and machine-readable. By using CSS or XSL, XFB can be easily displayed on websites. Because XFB is based on XML which is a common interface to many applications, XFB can be processed by a variety of existing tools. o XFB can easily be extended with additional information based on the raw BGP routing information. The BGP data is simply annotated with additional attributes and/or elements; programs which are not looking for this new information will simply ignore it. This allows us to easily modify XFB in general (or particular BGPmons) to allow for newly required information. We include guidelines for adding new standard elements in each section. o XFB messages can be used to reconstruct the raw BGP messages, if needed. Though XFB pays a storage cost since a compact binary message is Cheng, et al. Expires August 19, 2009 [Page 4] Internet-Draft BGP in XML Feb 2009 unpacked into ASCII text together with additional tags, our experiments shows that by using the default compression parameters for bzip2, we can still store XFB data efficiently. For details, please refer to the section of storage size comparison (Appendix A). In addition to XFB, we will briefly describe BGPmon (BGP Monitoring Service), an implementation of a service to collect BGP data and make it available in XFB format. Currently there are two types of BGP routing information encoded in XFB: BGP messages which come "over the wire" and may or may not be tagged with additional "helper" information, and BGP control/status information that originates from the BGPmon itself. 2. Terminology 2.1. XML Notations The syntax of XFB, being an extension of XML, is very simple. There are only three terms throughout the XFB file: o An "element" refers to a start tag, an end tag, and all the characters in between, e.g., "text and/or nested elements". o An "empty element" combines the start tag and the end tag, e.g., "". o An "attribute" is part of an element. If present, they occur in the start tag, e.g., "". Of course, they can also appear in empty elements, e.g., "". 3. BGP Monitoring Service BGP Monitoring System (BGPMon) is designed to monitor realtime BGP updates and routing tables from peering BGP routers. It supports distributed delployment to concurrently monitor many BGP routers. Most importantly, BGPmon can produce XFB stream for realtime processing and storage. The XFB format can accurately encode BGP data without losing any information and can be easiliy extended to represent new BGP features. More specifically, BGPMon generates two types of messages: the BGP messages come "over the wire" and the status messages which periodically report the operational status of BGPMon itself. The status messages carry useful information such as the peering relationship between BGPMon and operational routers. Currently Cheng, et al. Expires August 19, 2009 [Page 5] Internet-Draft BGP in XML Feb 2009 status messages convey three kind of information: BGPMON BGPMon information, currently only includes server up and down events. SESSION Peering information, including operation status such as uptime, the number of resets, the number of messages received, the number of announce/withdrawl received, etc. CHAIN Chaining information. Chaining is a unique feature by which BGPMon servers can be linked together to achieve high scalability and performance. Chaining information includes the operation status such as uptime, the number of messages received, etc. QUEUE Queue information, indicating the BGPMon internal queue usage for administrative purpose. Please refer to BGPMon [1] for detail information Moreover, please note that XFB is independent from BGPMon. Any other application is free to read and produce, or even extend XFB messages. We simpliy includes BGPMon here to demonstrate the ease of usage and flexibility of the XFB format. 4. Data Types The purpose of XFB is to represent information relevent to BGP, therefore it only supports limited number of data types. XFB uses standard datatypes defined by W3C XML schema. Please refer to XML Schema [2] for detail datatype definition. INTEGER A integer is represented by the INTEGER data type. Integer data MUST be encoded in Base 10. STRING A single character is represented by the CHARACTER data type. A character string is represented by the STRING data type. Special characters must be encoded using entity references. Cheng, et al. Expires August 19, 2009 [Page 6] Internet-Draft BGP in XML Feb 2009 HEXBIN A binary octet string is represented by the HEXBIN data type. Specifically, each octet is encoded by two hexadecimal digits. ENUM A enumerated type is represented by the ENUM data type, and consist of an ordered list of acceptable values. Each value has a representative keyword DATETIME A date-time string is represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported 5. The XFB Data Model In the following sections, the XFB format will be discussed in detail. 5.1. BGP_MESSAGE BGP_MESSAGE is the top level message class. Every routing information is encoded in exactly one BGP_MESSAGE xml element. +--------------------+ | BGP_MESSAGE | +--------------------+ | STRING xmlns | | STRING version |<>----------[ TIME ] | INTEGER length |<>--{0..1}--[ PEERING ] | |<>--{0..1}--[ ASCII_MSG ] | |<>--{0..1}--[ OCTET_MSG ] | |<>--{0..1}--[ STATUS_MSG ] +--------------------+ Figure 1: The root BGP_MESSAGE element The BGP_MESSAGE class contains the following element classes: TIME One. The time associated with the BGP message PEERING Zero or one. The connection information of from which peer the message was received over. Cheng, et al. Expires August 19, 2009 [Page 7] Internet-Draft BGP in XML Feb 2009 ASCII_MSG Zero or one. BGP message encoded in ascii xml format. OCTET_MSG Zero or one. BGP message encoded in hexadecimal format. A BGP_MESSAGE message SHOULD contain at least one of asciimsg and octests element, except the status messages. STATUS_MSG Zero or one. Periodic status message in ascii xml format.Applications which only care about BGP messages can safely ignore this element The BGPData class has two attributes: xmlns Required. STRING. The namespace of XFB specification. Required for validation. version Required. STRING. The XFB specification version number. length Required. INTEGER. The total length of the message in characters, including the BGP_MESSAGE tag itself. 5.2. TIME Every BGP_MESSAGE MUST contain a child time element, indicating the time when the BGP message has been received/generated. The time can be represented in either or both of timestamp and human readable formats; additional formats MAY be included as well. +--------------------+ | TIME | +--------------------+ | |<>----------[ TIMESTAMP ] | |<>--{0..1}--[ DATETIME ] | |<>--{0..1}--[ PRECISION_TIME ] +--------------------+ Figure 2: TIME Class The time class contains the following element classes: Cheng, et al. Expires August 19, 2009 [Page 8] Internet-Draft BGP in XML Feb 2009 TIMESTAMP One. Unix timestamp (number of seconds since midnight UTC, January 1, 1970). The UNIX timestamp is recommended when it is expected that the data will be processed entirely by programs without human intervention. DATETIME Zero or one. Human readable time in DATETIME format (ex: 2008-12- 30T01:26:42Z) PRECISION_TIME Zero or one. If it is desired for the time to be given more accurately, an additional precisiontime element MAY be used; if given, this element SHOULD contain the number of microseconds past the second that the message arrived. 5.3. PEERING PEERING element uniquely identify the connection over which the data arrived. +--------------------+ | PEERING | +--------------------+ | |<>----------[ SRC_ADDR ] | |<>----------[ SRC_PORT ] | |<>--{0..1}--[ SRC_AS ] | |<>----------[ DST_ADDR ] | |<>----------[ DST_PORT ] | |<>--{0..1}--[ DST_AS ] +--------------------+ The peering_session element contains the following four subelements. SRC_ADDR One. The source(local) address. DST_ADDR One. The destination(remote) address. SRC_PORT One. The source(local) port. DST_PORT One. The destination(remote) port Other information MAY be inferred from the above elements; however, If it is desired to explicitly include the source and destination AS, Cheng, et al. Expires August 19, 2009 [Page 9] Internet-Draft BGP in XML Feb 2009 the following elements MAY be used. SRC_AS Zero or one. The source(local) AS number. DST_AS Zero or one. The destination(local) AS number. The address elements (SRC_ADDR/DST_ADDR) has a AFI attribute to indicate the corresponding address family. Currently, the expected values for the AFI attribute are "IPv4" and "IPv6", while additional families are allowed. 5.4. Representing the message BGP routing information MAY be sent in either binary or ascii format. Binary messages contain BGP information exactly as it comes over the wire. They take up less space than ASCII messages, can be easily converted to play directly into routers. ASCII messages are human- readable and can be played into scripts. Messages MUST be sent in at least one of these two formats. If possible, implmentations SHOULD prefer to send BGP messages in both formats; if only one is used, they SHOULD prefer binary 5.5. OCTET_MESSAGE (BGP Message in Octet Format) The OCTET_MSG element simply embed a hexadecimal string. +--------------------+ | OCTET_MSG | +--------------------+ | |<>----------[ MARKER ] | |<>----------[ LENGTH ] | |<>----------[ TYPE ] | |<>----------[ OCTETS ] +--------------------+ Figure 3: Octets Message Class The OCTET_MSG element contains the following subelements. MARKER Required. HEXBIN. The Marker (Mask) field in octets. Cheng, et al. Expires August 19, 2009 [Page 10] Internet-Draft BGP in XML Feb 2009 LENGTH Required. INTEGER. The length of the message in octets. TYPE Required. ENUM. BGP message type. Message types 1-5 are defined in RFC 4271 [RFC4271]and RFC 2918 [RFC2918]; additional types MAY be handled as well. In the event of an unrecognized type, the type element MUST contain the value "UNKNOWN".. 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 5 - ROUTE-REFRESH 6+ - UNKNOWN OCTETS Required. HEXBIN. BGP message in octets 5.6. ASCII_MSG (BGP Message in ASCII Format) The ASCII_MSG represents the BGP information in a hierarchical tree structure. +--------------------+ | ASCII_MSG | +--------------------+ | |<>--------[ MARKER ] | |<>--------[ LENGTH ] | |<>--------[ TYPE ] | |<>---+----[ OPEN ] | | |----[ UPDATE ] | | |----[ NOTIFICATION ] | | |----[ KEEPALIVE ] | | |----[ ROUTE-REFRESH ] | | |----[ CISCO-ROUTE-REFRESH ] | | |----[ UNKNOWN ] +--------------------+ Figure 4: ASCII_MSG Class Cheng, et al. Expires August 19, 2009 [Page 11] Internet-Draft BGP in XML Feb 2009 The ASCII_MSG element contains the following child elements MARKER Required. HEXBIN. The Marker (Mask) field in octets. LENGTH Required. INTEGER. The length of the message in octets. TYPE Required. ENUM. BGP message type. Message types 1-5 are defined in RFC 4271 [RFC4271]and RFC 2918 [RFC2918]; additional types MAY be handled as well. In the event of an unrecognized type, the type element MUST contain the value "UNKNOWN".. The ASCII_MSG element contains one of the following subelements, determined by the value of the type attribute. OPEN Zero or one. BGP open message. UPDATE Zero or one. BGP update message. NOTIFICATION Zero or one. BGP notification message. KEEPALIVE Zero or one. BGP keepalive message. ROUTE_REFRESH Zero or one. BGP route-refresh message. CISCO_ROUTE_REFRESH Zero or one. BGP cisco-route-refresh message. UNKNOWN Zero or one. Unrecognized BGP message. Binary data would be preserved in this element. In the following sections, we would describe each message type individually. 5.6.1. OPEN The OPEN element represent the BGP open messages. Cheng, et al. Expires August 19, 2009 [Page 12] Internet-Draft BGP in XML Feb 2009 +--------------------+ | OPEN | +--------------------+ | |<>----------[ VERSION ] | |<>----------[ SRC_AS ] | |<>----------[ HOLD_TIME ] | |<>----------[ SRC_BGP ] | |<>----------[ OPT_PAR_LEN ] | |<>----------[ OPT_PAR ] +--------------------+ Figure 5: OPEN class The open element contains the following subelements. VERSION One. The protocol version number, in decimal. SRC_AS One. The Autonomous System number of the sender. HOLD_TIME One. the sender-proposed hold time, in second. SRC_BGP One. the BGP identifier of the sender. OPT_PAR_LEN One. The length of the optional parameters field in octets OPT_PAR One. The container of optional parameters. 5.6.1.1. Defining and Processing the Parameter Value field OPT_PAR is a container class for zero or more parameter subelements. +--------------------+ | OPT_PAR | +--------------------+ | INTEGER count |<>--{0..*}--[ PARAMETER ] +--------------------+ Figure 6: OPT_PAR Class The opt_par element has the following attributes. Cheng, et al. Expires August 19, 2009 [Page 13] Internet-Draft BGP in XML Feb 2009 count Required. INTEGER. The number of parameters. The opt_par element contains the following subelements. PARAMETER Zero or more. The optional parameters. For each optional parameter, the OPT_PAR element contains a PARAMETER subelement with attribute "code" containing the integer code for the parameter type. Each PARAMETER contains three subelements: a LENGTH tag giving the length of the data in octets, a TYPE tag giving the name of the parameter, and a tag whose label is the name of the parameter and which contains parameter-defined elements. If the code is not recognized, TYPE is set to OTHER and the OTHER element holds unprocessed hexadecimal data. The last element s processed differently depending on the type of parameter. This section describes the most common parameter types. Additional parameter types MAY be defined, and MUST confirm to the following format. Every parameter has attribute "code" giving the integer value of its type, element LENGTH giving the length in octets of its data, and element TYPE giving its name. It then contains an element whose label is the name of the parameter. This element may have attributes and subelements defined as desired; however, attributes SHOULD describe the data, and the actual data SHOULD be in the form of subelements. Parameters do not need to contain information; self-closing elements are permitted. Thus, every parameter will be in the following format: +--------------------+ | PARAMETER | +--------------------+ | INTEGER code |<>--------[ LENGTH ] | |<>--------[ TYPE ] | |<>---+----[ AUTHENTICATION ] | | |----[ CAPABILITIES ] | | |----[ OTHER ] +--------------------+ The parameter element has the following attributes. code Required. INTEGER. The integer code for the parameter type The parameter element contains the following subelements. Cheng, et al. Expires August 19, 2009 [Page 14] Internet-Draft BGP in XML Feb 2009 LENGTH One. The length of the data in octets TYPE One. The name of the parameter AUTHENTICATION/CAPABILITES/OTHER One. Two most common paraameter type: authentication or capabilities. Additional parameter types can be defined by the OTHER element. 5.6.1.1.1. AUTHENTICATION An authentication parameter is stored with type "AUTHENTICATION" and additional attribute "code". This element contains hexadecimal authentication data. +--------------------+ | AUTHENTICATION | +--------------------+ | INTEGER code | | | +--------------------+ Figure 7: AUTHENTICATION class For example, this parameter is expressed as int AUTHENTICATION hexadecimal data 5.6.1.1.2. CAPABILITIES The capabilities parameter is encoded in CAPABILITIES element and one or more child CAP elements, as well as an attribute "count" giving the number of such elements. Each CAP element contains LENGTH, TYPE, and subelements decided by the type value. Cheng, et al. Expires August 19, 2009 [Page 15] Internet-Draft BGP in XML Feb 2009 +---------------+ | CAPABILITIES | +---------------+ +---------+ | INTEGER count |<>-{0..*}- | CAP | | | +---------+ +---------------+ | |<>----[ LENGTH ] | |<>----[ TYPE ] | |<>-+--[ MULTIPROTOCOL ] +---------+ |--[ ROUTE_REFRESH ] |--[ CISCO_ROUTE_REFRESH ] |--[ OTHER ] Figure 8: CAPABILITIES Class For example, this parameter is expressed as int CAPABILITIES int ROUTE_REFRESH 5.6.2. The UPDATE element The following subelements are included in the UPDATE message: , , , , and . +--------------------+ | UPDATE | +--------------------+ | |<>----------[ WITHDRAWN_LEN ] | |<>----------[ WITHDRAWN ] | |<>----------[ PATH_ATTRIBUTES_LEN ] | |<>----------[ PATH_ATTRIBUTES ] | |<>----------[ NLRI ] +--------------------+ Figure 9 The UPDATE element contains the following subelements: Cheng, et al. Expires August 19, 2009 [Page 16] Internet-Draft BGP in XML Feb 2009 WITHDRAWN_LEN One. the total length of the withdrawn routes field in octets WITHDRAWN One. contains zero or more PREFIX subelements, each of which contains an address prefix. This element has attribute "count" giving the total number of PREFIX subelements. PREFIX represents an address prefix. Each PREFIX also has an attirbute "label", which carries additional information associated with this prefix, such as new announcement, duplicated announcement, etc. These labels are uniquely produced by BGPMon, wich add meaningful information to prefixes. PATH_ATTRIBUTES_LEN One. the total length of the path attributes field in octets PATH_ATTRIBUTES One. contains zero or more ATTRIBUTE elements and a "count" attribute giving the number of such elements. NLRI One. contains zero or more PREFIX subelements, each of which contains an address prefix. This element has attribute "count" giving the total number of PREFIX subelements 5.6.3. PATH_ATTRIBUTES Class PATH_ATTRIBUTES contains zero or more ATTRIBUTE. +-----------------+ | PATH_ATTRIBUTES | +-----------------+ +---------------+ | INTEGER counT |<>--{0..*}--| ATTRIBUTE | | | +---------------+ +-----------------+ | INTEGER code |<>----[ FLAGS ] | |<>----[ LENGTH ] | |<>----[ TYPE ] | |<>-+--[ ORIGIN ] +---------------+ |--[ AS_PATH ] |... Moreover, the ATTRIBUTE element contains the following attributes: count Required. INTEGER. The number of attributes. The ATTRIBUTE element contains the following subelements: Cheng, et al. Expires August 19, 2009 [Page 17] Internet-Draft BGP in XML Feb 2009 FLAGS One. This element contains an attribute "code" giving the flag byte as an octet. Additionally, it contains subelements for all defined flags. The subelements for the current flags, as defined in RFC 1771, are OPTIONAL, TRANSITIVE, PARTIAL, and EXTENDED. LENGTH One. The attribute length TYPE One. The name of the attribute type Each type correponds to a specific element. For brevitiy, the attribute types are summarized in the following table. Please refer to the schema and example sections for details. +------+----------------------+-------------------------------------+ | Code | Type | Description | +------+----------------------+-------------------------------------+ | 1 | ORIGIN | This is a well-known mandatory | | | | attribute with value IGP, EGP, or | | | | INCOMPLETE. | | 2 | AS_PATH | This is a well-known mandatory | | | | attribute with "type" attribute set | | | | to either as_set or as_sequence. | | | | It contains one or more AS | | | | subelements, each of which holds an | | | | Autonomous System number. | | 3 | NEXT_HOP | This is a well-known mandatory | | | | attribute that holds the next hop | | | | address as its value. | | 4 | MULTI_EXIT_DISC | This is an optional non-transitive | | | | attribute with integer value. | | 5 | LOCAL_PREF | This is a well-known discretionary | | | | attribute with integer value. | | 6 | ATOMIC_AGGREGATE | This is a well-known discretionary | | | | attribute with no value; the | | | | ATOMIC_AGGREGATE element is | | | | self-closing. | | 7 | AGGREGATOR | This is an optional transitive | | | | attribute containing two | | | | subelements: AS, containing an AS | | | | number, and ADDR, containing an | | | | address. | | 8 | COMMUNITITIES | This is an optional transitive | | | | attribute containing a 32-bit | | | | integer. [RFC1997] | Cheng, et al. Expires August 19, 2009 [Page 18] Internet-Draft BGP in XML Feb 2009 | 9 | ORIGINATOR_ID | This is an optional non-transitive | | | | attribute containing a 32-bit | | | | integer. | | 10 | CLUSTER_LIST | This is an optional non-transitive | | | | attribute containing zero or more | | | | ID subelements and a "count" | | | | attribute giving the number of such | | | | subelements. | | 12 | ADVERTISER | This is an optional non-transitive | | | | attribute containing an address. | | 13 | RCID_PATH | This is an optional non-transitive | | | | attribute containing zero or more | | | | ID subelements and a "count" | | | | attribute giving the number of such | | | | subelements. | | 15 | MP_REACH_NLRI | This is an optional non-transitive | | | | attribute that contains the | | | | following subelements: AFI contains | | | | the name of the Address Family | | | | Identifier being used. SAFI | | | | contains the Subsequent Address | | | | Family Identifier. NEXT_HOP | | | | contains the network address of the | | | | next hop. SNPA_LIST_LEN contains | | | | the length of the SNPA_LIST in | | | | octets. SNPA_LIST contains zero or | | | | more SNPA elements and a "count" | | | | attribute giving the total number | | | | of SNPA elements it contains. | | | | Furthermore, each SNPA represents a | | | | address. NLRI contains one or more | | | | PREFIX elements and a "count" | | | | attribute giving the number of such | | | | elements.[RFC4760] | | 15 | MP_UNREACH_NLRI | This is an optional non-transitive | | | | attribute containing the following | | | | subelements: AFI contains the name | | | | of the Address Family Identifier | | | | being used. SAFI contains the | | | | Subsequent Address Family | | | | Identifier. WITHDRAWN contains one | | | | or more PREFIX elements and a | | | | "count" attribute giving the number | | | | of such elements. | | 16 | EXTENDED_COMMUNITIES | This is an optional non-transitive | | | | attribute containing the octets | | | | value.[Rosen] | Cheng, et al. Expires August 19, 2009 [Page 19] Internet-Draft BGP in XML Feb 2009 | .7 | AS4_PATH | This is a well-known mandatory | | | | attribute with "type" attribute set | | | | to either as_set or as_sequence. | | | | It contains one or more AS | | | | subelements, each of which holds an | | | | Autonomous System number. | | | | [RFC4893] | | 18 | AS4_AGGREGATOR | This is an optional transitive | | | | attribute containing two | | | | subelements: AS, containing an AS | | | | number, and ADDR, containing an AFI | | | | address. | +------+----------------------+-------------------------------------+ Additional attributes MAY be defined; they MUST follow the structure described above. Suppose that data is stored in the element or in subelements.In the event that the element contains one subelement that may appear a number of times, the main tag should include a "count" attribute. The element may have any desired attributes and elements, but attributes SHOULD describe the data while elements SHOULD contain the data. If the code value is not defined, the subelement has the value "UNKNOWN". 5.6.4. The KEEPALIVE The KEEPALIVE element is self-closing and contains no attributes or subelements. +--------------------+ | keepalive | +--------------------+ | | +--------------------+ Figure 10: Keepalive Class 5.6.5. The ROUTE_REFRESH The ROUTE_REFRESH element is self-closing and contains no attributes or subelements. +--------------------+ | ROUTE_REFRESH | +--------------------+ | | +--------------------+ Figure 11: ROUTE_REFRESH Class Cheng, et al. Expires August 19, 2009 [Page 20] Internet-Draft BGP in XML Feb 2009 5.6.6. The CISCO_ROUTE_REFRESH element The CISCO_ROUTE_REFRESH is self-closing and contains no attributes or subelements. +---------------------+ | CISCO_ROUTE_REFRESH | +---------------------+ | | +---------------------+ Figure 12: CISCO_ROUTE_REFRESH 5.6.7. The NOTIFICATION The notification element contains the information for bgp notification. +------------------+ | NOTIFICATION | +------------------+ | |<>----------[ CODE ] | |<>----------[ SUBCODE ] | |<>----------[ DATA ] +------------------+ Figure 13: NOTIFICATION Class The notification element contains the following subelements. CODE One. Human readable error string cooresponding to a numberic 'value' attribute. SUBCODE One. Human readable sub error string cooresponding to a numberic 'value' attribute DATA One. The remainder of the message, whose content depends on the error code and subcode. The element is set according to the value of the "code" attribute: Cheng, et al. Expires August 19, 2009 [Page 21] Internet-Draft BGP in XML Feb 2009 +-------+----------------------------+ | code | error_code | +-------+----------------------------+ | 1 | Message Header Errori | | 2 | OPEN Message Error | | 3 | UPDATE Message Error | | 4 | Hold Timer Expired | | 5 | Finite State Machine Error | | 6 | Cease | | 7-255 | Undefined code | +-------+----------------------------+ The element is set according to the value of the "subcode" attribute: +------+---------+-------------------------------------+ | code | subcode | error_subcode | +------+---------+-------------------------------------+ | 1 | 1 | Connection Not Synchronized | | 1 | 2 | Bad Message Length | | 1 | 3 | Bad Message Type | | 2 | 1 | Unsupported Version Number | | 2 | 2 | Bad Peer AS | | 2 | 3 | Bad BGP Identifier | | 2 | 4 | Unsupported Optional Parameter | | 2 | 5 | Authentication Failure | | 2 | 6 | Unacceptable Hold Time | | 3 | 1 | Malformed Attribute List | | 3 | 2 | Unrecognized Well-known Attribute | | 3 | 3 | Missing Well-known Attribute | | 3 | 4 | Attribute Flags Error | | 3 | 5 | Attribute Length Error | | 3 | 6 | Invalid ORIGIN Attribute | | 3 | 7 | AS Routing Loop | | 3 | 8 | Invalid NEXT_HOP Attribute | | 3 | 9 | Optional Attribute Error | | 3 | 10 | Invalid Network Field | | 3 | 11 | Malformed AS_PATH | | 6 | 1 | Maximum Number of Prefixes Reached" | | 6 | 2 | Administrative Shutdown" | | 6 | 3 | Peer De-configured" | | 6 | 4 | Administrative Reset" | | 6 | 5 | Connection Rejected" | | 6 | 6 | Other Configuration Change" | | 6 | 7 | Connection Collision Resolution" | | 6 | 8 | Out of Resources" | +------+---------+-------------------------------------+ Cheng, et al. Expires August 19, 2009 [Page 22] Internet-Draft BGP in XML Feb 2009 For all other codes, the subelement has the value "Undefined error subcode". The BGPmon MAY handle additional error subcodes. 5.6.7.1. Example The NOTIFICATION message might look like this: Bad Message Type AS Routing Loop hexadecimal 5.7. STATUS_MSG The STATUS_MSG contains one of four kinds of messages: QUEUE_STATUS, SESSION_STATUS, and CHAIN_STATUS, BGPMON_STATUS, representing the operation status of the BGPMon internal quque, BGP peering routers, peering BGPMon server, and BGPMon server itself respectively. +---------------+ | STATUS_MSG | +---------------+ | |<>-----[ BGPMON ] | |<>--+--[ SESSION_STATUS ] | | |--[ CHAIN_STATUS ] | | |--[ QUEUE_STATUS ] | | |--[ BGPMON_STATUS ] +---------------+ Figure 14: STATUS_MSG class 5.7.1. BGPMON Because of the BGPMon chaining feature, it is possilbe that a client could receive status messages originated from multiple BGPMon servers. This BGPMON element is used by clients to identify the origin of the status message. +---------------+ | BGPMON | +---------------+ | |<>---------[ ADDR ] | |<>---------[ PORT ] | |<>-{0..1}--[ AS ] +---------------+ Figure 15: BGPMON The BGPMON element contains the following elements Cheng, et al. Expires August 19, 2009 [Page 23] Internet-Draft BGP in XML Feb 2009 ADDR One. The BGPMon network address, usually identical to the address which accepts user connections. PORT One. The BGPMon port AS Zero or one. Optional AS number 5.7.2. QUEUE_STATUS / QUEUE QUEUE_STATUS includes zero or multiple child QUEUE elements, which in turn carry the information about BGPMon internal message queues. +---------------+ | QUEUE_STATUS | +---------------+ +---------+ | INTEGER count |<>-{0..*}- | QUEUE | | | +---------+ +---------------+ | |<>----[ NAME ] | |<>----[ ITEM ] | |<>----[ READER ] | |<>----[ WRITER ] | |<>----[ PACING ] +---------+ Figure 16: QUEUE_STATUS The QUEUE_STATUS contains the following attributes: count Required. INTEGER. The number of QUEUE elements. The QUEUE_STATUS contains the following elements QUEUE Zero or more. The QEUEU element which is described as the following. The QUEUE element contains the following elements NAME One. Human readalbe name ITEM One. The statistic information about the queue usage. Cheng, et al. Expires August 19, 2009 [Page 24] Internet-Draft BGP in XML Feb 2009 READER One. Ths statistic information about the queue reader. WRITER One. The statistic information about the queue writer. PACING One. Configuration and statistic information about the queue pacing machanism. Pacing is used to maintain stable queu usage. Please refer BGPMon specification for detail information +-----------+ | PACING | +-----------+ | |<>----[ FLAG ] | |<>----[ COUNT ] | |<>----[ WRITE_LIMIT ] +-----------+ Figure 17: QUEUE_STATUS 5.7.3. CHAIN_STATUS / CHAIN CHAIN_STATUS includes zero or multiple child CHAIN elements. +---------------+ | CHAIN_STATUS | +---------------+ +-------+ | INTEGER count |<>-{0..*}- | CHAIN | | | +-------+ +---------------+ | |<>--------[ ADDR ] | |<>--------[ PORT ] | |<>-{0..1}-[ AS ] | |<>-{0..1}-[ STATE ] | |<>-{0..1}-[ STATE_CHANGE ] | |<>-{0..1}-[ OPTIME ] | |<>-{0..1}-[ RECV_MESSAGE ] | |<>-{0..1}-[ RESET ] +-------+ Figure 18: CHAIN_STATUS The CHAIN_STATUS contains the following attributes: count Required. INTEGER. The number of CHAIN elements. The CHAIN_STATUS contains the following elements Cheng, et al. Expires August 19, 2009 [Page 25] Internet-Draft BGP in XML Feb 2009 CHAIN Zero or more. The CHAIN element which is described as the following. The QUEUE element contains the following elements ADDR One. The address of the peering BGPMon server ITEM One. The port of the peering BGPMon server AS Zero or one. The AS number of the peering BGPMon server STATE Zero or one. The current state STATE_CHANGE Zero or one. The state change OPTIME Zero or one. The operation time, such as uptime, last down, etc. RECV_MESSAGE Zero or one. The statstic information about the number of messages received RESET One. The statistic information about the number of chain resets. 5.7.4. SESSION_STATUS / SESSION SESSION_STATUS includes zero or multiple child SESSION elements. Cheng, et al. Expires August 19, 2009 [Page 26] Internet-Draft BGP in XML Feb 2009 +----------------+ | SESSION_STATUS | +----------------+ +-------+ | INTEGER count |<>-{0..*}-|SESSION| | | +-------+ +----------------+ | |<>--------[ ADDR ] | |<>--------[ PORT ] | |<>-{0..1}-[ AS ] | |<>-{0..1}-[ STATE ] | |<>-{0..1}-[ STATE_CHANGE ] | |<>-{0..1}-[ OPTIME ] | |<>-{0..1}-[ RECV_MESSAGE ] | |<>-{0..1}-[ RESET ] | |<>-{0..1}-[ PREFIX ] | |<>-{0..1}-[ ATTRIBUTE ] | |<>-{0..1}-[ MEMORY_USAGE ] | |<>-{0..1}-[ ANNOUNCEMENT ] | |<>-{0..1}-[ DUP_ANNOUNCEMENT ] | |<>-{0..1}-[ SAME_PATH ] | |<>-{0..1}-[ DIFF_PATH ] | |<>-{0..1}-[ WITHDRWAL ] | |<>-{0..1}-[ DUP_WITHDRWAL ] +-------+ Figure 19: SESSION_STATUS The CHAIN_STATUS contains the following attributes: count Required. INTEGER. The number of CHAIN elements. The CHAIN_STATUS contains the following elements SESSION Zero or more. The SESSION element which is described as the following. The QUEUE element contains the following elements. Please refer to CHAIN for identical elements. PREFIX Zero or one. The statstic information about the number of prefixes received ATTRIBUTE Zero or one. The statstic information about the number of path attributes received Cheng, et al. Expires August 19, 2009 [Page 27] Internet-Draft BGP in XML Feb 2009 MEMORY_USAGE One. The statistic information about the memory usage ANNOUNCEMENT Zero or one. The statstic information about the number of announcements received DUP_ANNOUNCEMENT Zero or one. The statstic information about the number of duplicate announcements received SAME_PATH Zero or one. The statstic information about the number of same as path received DIFF_PATH Zero or one. The statstic information about the number of different as path received WITHDRWAL Zero or one. The statstic information about the number of withdrawl received DUP_WITHDRWAL Zero or one. The statstic information about the number of duplicate withdrawal received 6. Examples 6.1. BGP Open Message 89.149.178.10 129.82.138.6 139 139 3257 6447 Cheng, et al. Expires August 19, 2009 [Page 28] Internet-Draft BGP in XML Feb 2009 1122220 4.0 3593 2943 89.149.22.11 646 AUTHENTICATION 234 FFDDEE00E039D2 CAPABILITIES 2700 11 26 CAP_STRING 13 6 CAP_STRING Unknown 1087 123423A3D3BBEE FFFFFFFFFFFFF... 6.2. BGP Update Message 89.149.178.10 129.82.138.6 139 139 3257 6447 1110011122 5781 66.231.212 66.186.174 814 343 ORIGIN IGP 343 AS4_PATH 1524 5936 178 Cheng, et al. Expires August 19, 2009 [Page 30] Internet-Draft BGP in XML Feb 2009 343 NEXT_HOP 1.1.1.1 343 MULTI_EXIT_DISC 1905 343 LOCAL_PREFERENCE 3678 343 ATOMIC_AGGREGATE 343 AGGREGATOR 3547 1.2.2.2 343 COMMUNITY 6891 343 ORIGINATOR_ID 977 Cheng, et al. Expires August 19, 2009 [Page 31] Internet-Draft BGP in XML Feb 2009 343 CLUSTER_LIST CLUSTER_ID1 CLUSTER_ID2 CLUSTER_ID3 343 ADVERTISER 10.1.1.1 343 RCID_PATH RCID1 RCID2 343 MP_REACH_NLRI IPv6 sub_afi 10.2.2.2 8890 1.1.1.1 1.1.2.1 1.1.3.1 2.2.2.1 2.2.3.1 2.2.4.1 343 Cheng, et al. Expires August 19, 2009 [Page 32] Internet-Draft BGP in XML Feb 2009 MP_UNREACH_NLRI IPv6 1.1.1.1 1.1.2.1 1.1.3.1 343 EXTENDED_COMMUNITIES ext_community_string 343 AS4_PATH 5717 3336 2132 343 AS4_AGGREGATOR 5289 10.1.1.2 66.231.212.1 66.186.174.2 66.186.177.3 Cheng, et al. Expires August 19, 2009 [Page 33] Internet-Draft BGP in XML Feb 2009 FFFFFFA.. 6.3. BGP Keepalive Message 89.149.178.10 129.82.138.6 139 139 3257 6447 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 19 KEEPALIVE FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 19 KEEPALIVE FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF001304 Cheng, et al. Expires August 19, 2009 [Page 34] Internet-Draft BGP in XML Feb 2009 6.4. BGP Notification Message 89.149.178.10 129.82.138.6 139 139 3257 6447 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 19 NOTIFICATION Bad Message Type AS Routing Loop hexadecimal FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 19 NOTIFICATION FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF001304 6.5. Status Message 6.5.1. Queue Status Message Cheng, et al. Expires August 19, 2009 [Page 35] Internet-Draft BGP in XML Feb 2009 ipv4any 4321 6447 65.49.129.101 179 3043 PeerQueue 0 5 1 0 192 LabelQueue 11856 3 1 0 197 XMLQueue 13216 1 1 0 678 ', Cheng, et al. Expires August 19, 2009 [Page 36] Internet-Draft BGP in XML Feb 2009 6.5.2. Session Status Message ipv4any 4321 6447 65.49.129.101 179 3043 65.49.129.101 179 3043 6 64516 10477308 0 275527 47661 13562636 287747 29513778 4820 92837 12220 0 205.167.76.241 179 10876 6 64515 10383216 0 273496 47395 Cheng, et al. Expires August 19, 2009 [Page 37] Internet-Draft BGP in XML Feb 2009 12829036 287055 29225124 2239 59761 13559 0 89.149.178.10 179 3257 6 64515 245796 0 271825 47476 14745401 290449 0 175480 77044 18624 0 7. The XFB Schema XML Format for BGP Information v0.1, see RFC XXX Cheng, et al. Expires August 19, 2009 [Page 38] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 39] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 40] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 41] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 42] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 43] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 44] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 45] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 46] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 47] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 48] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 49] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 50] Internet-Draft BGP in XML Feb 2009 Cheng, et al. Expires August 19, 2009 [Page 51] Internet-Draft BGP in XML Feb 2009 8. Acknowledgements 9. IANA Considerations This document uses URNs to describe an XML namespace and schema. Two registrations are needed: (1) registration for the XFB namespace: urn:ietf:params:xml:ns:xfb-0.1 and (2) registration for the XFB XML schema: urn:ietf:params:xml:schema:xfb-0.1 10. Security Considerations The XFB format untilizes XML to flexibly represent BGP information. The XFB document structure and fields are only descriptive and do not create additional security risks. 11. References 11.1. Normative References [I-D.ietf-grow-mrt] Blunk, L., Karir, M., and C. Labovitz, "MRT routing information export format", draft-ietf-grow-mrt-08 (work in progress), July 2008. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Cheng, et al. Expires August 19, 2009 [Page 52] Internet-Draft BGP in XML Feb 2009 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007. 11.2. Informative References [Rosen] Rosen, Eric., "draft-ramachandra-bgp-ext-communities-00.txt", March 1999. URIs [1] [2] Appendix A. Storage Size Comparison Experiment results are promising using the default compression parameters for bzip2. As shown in the table below, the uncompressed XFB require more space, but the compressed XFB require less space. Compared with bgpdump format, less storage will be used in compressed XFB format. Even compared with MRT [I-D.ietf-grow-mrt] binary format, XFB almost consumes the same storage. This table shows the size of data used in the above comparison, using MRT as the baseline. +---------+--------------+-------+------------+-------+ | format | umcompressed | ratio | compressed | ratio | +---------+--------------+-------+------------+-------+ | XFB | 74389091 | 7.22 | 2200472 | 1.03 | | bgpdump | 54466310 | 5.29 | 2418845 | 1.13 | | MRT | 10298545 | 1.0 | 2142657 | 1.00 | +---------+--------------+-------+------------+-------+ Storage Size Comparison Cheng, et al. Expires August 19, 2009 [Page 53] Internet-Draft BGP in XML Feb 2009 Authors' Addresses Peichun Cheng (editor) UCLA IRL Los Angeles, CA US Phone: Fax: Email: pccheng@cs.ucla.edu URI: He Yan (editor) CSU-Netsec Group Fort Collins, CO US Phone: Fax: Email: yanhe@cs.colostate.edu URI: Kevin Burnett (editor) CSU-Netsec Group Fort Collins, CO US Phone: Fax: Email: burnet@cs.colostate.edu URI: Daniel F. Massey (editor) CSU-Netsec Group Fort Collins, CO US Phone: Email: massey@cs.colostate.edu Cheng, et al. Expires August 19, 2009 [Page 54] Internet-Draft BGP in XML Feb 2009 Lixia Zhang (editor) UCLA IRL Los Angeles, CA US Phone: Fax: Email: lixia@cs.ucla.edu URI: Cheng, et al. Expires August 19, 2009 [Page 55]