MRT BGP routing information export format with geo-location extensions
draft-grow-geomrt-00.txt

Abstract

This document extends the Border Gateway Protocol (BGP) MRT export format for routing information to include terrestrial coordinates.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on March 11, 2011.

Copyright Notice

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 (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 Simplified BSD License.

Table of Contents

1.  Requirements notation
2.  Introduction
3.  Geo-location aware MRT Routing Information Type
4.  TABLE_DUMP_v2+GEO Type
5.  Implementation Note
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

Research is underway that analyzes the network behavior of routing protocol transactions from routing information base snapshots in relation to geographical coordinates. Specifically the BGP routing protocol is the subject of study and the analysis has been significantly aided by the availability and extension of the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt] originally defined in the MRT Programmer's Guide (Labovitz, C., “MRT Programmer's Guide,” November 1999.) [MRT PROG GUIDE].

This memo documents an extension to the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt] and introduces an additional definition of a MRT Type field and related Subtype fields.

3.  Geo-location aware MRT Routing Information Type

The following additional Type is defined for the TABLE_DUMP_v2+GEO format, which extends the TABLE_DUMP_V2 type.

    [TYPE NUMBER]  TABLE_DUMP_v2+GEO

The TYPE NUMBER, an FCFS entry from the future IANA MRT registry is yet to be assigned.

4.  TABLE_DUMP_v2+GEO Type

The TABLE_DUMP_v2+GEO Type updates the TABLE_DUMP_v2 Type to include Geo-location information in the form of WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] formatted coordinates. The following subtypes as used with the TABLE_DUMP_V2 Type, are used in the TABLE_DUMP_v2+GEO Type and their formats have been augmented to include the WGS84 coordinates.

    1    PEER_INDEX_TABLE
    2    RIB_IPV4_UNICAST
    3    RIB_IPV4_MULTICAST
    4    RIB_IPV6_UNICAST
    5    RIB_IPV6_MULTICAST
    6    RIB_GENERIC

The extended PEER_INDEX_TABLE MRT record provides the BGP ID of the collector, the latitude and longitude in WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] format, an optional view name, and a list of indexed peers.

The format and function of the Collector BGP ID, the View Name Length and View Name, Peer Count are as defined by the TABLE_DUMP_V2 MRT format (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt].

The Collector Latitude and Collector Longitude are the geographical coordinates of the collector in WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Collector BGP ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Collector Latitude                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Collector Longitude                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       View Name Length        |     View Name (variable)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Peer Count           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the peer entries is shown below. The PEER_INDEX_TABLE record contains Peer Count peer entries.

     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 Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Peer BGP ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Peer IP address (variable)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Peer AS (variable)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Peer Latitude                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Peer Longitude                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Peer Type, Peer BGP ID, Peer IP, Peer AS, Peer Latitude, and Peer Longitude fields are repeated as indicated by the Peer Count field. The position of the Peer in the PEER_INDEX_TABLE is used as an index in the subsequent TABLE_DUMP_V2+GEO MRT records. The index number begins with 0.

The Peer Latitude and Peer Longitude are the geographical coordinates of the peer in WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] format.

The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT format (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt].

The records which follow the PEER_INDEX_TABLE record constitute the RIB entries and their formats remain unchanged from TABLE_DUMP_V2+GEO.

That is the common format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains as defined for TABLE_DUMP_V2 and the header is shown below for informational purposes only.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Sequence number                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Prefix (variable)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Entry Count           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Similarly the the RIB_GENERIC format is unchanged and is shown here:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Sequence number                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Address Family Identifier  |Subsequent AFI |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Network Layer Reachability Information (variable)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Entry Count           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The RIB entries that follow the RIB entry headers are also unchanged from MRT (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt]:

     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 Index            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Originated Time                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Attribute Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    BGP Attributes... (variable)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.  Implementation Note

In implementation of the formats above where a Collector has an assigned Latitude and Longitude but a Peer does not. It is currently recommended that the Collector's coordinates are replicated in the Peer's Latitude and Longitude. The inquiring researcher can then make the decision on the interpretation of the routes 'as seen' at those coordinates, or disregard any geographical information for the peer based on the comparison of the Collector and Peer coordinates.

The TABLE_DUMP_v2+GEO format MUST not be used if the Collector's Latitude and Longitude have not been defined.

6.  Acknowledgements

Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, and Jeffrey Haas for reviewing this document.

This document describes a small portion of the research towards the the author's PhD.

7.  IANA Considerations

This section requests the Internet Assigned Numbers Authority (IANA) register the Type code values (as FCFS as defined in the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt] and Subtype code values related to the TABLE_DUMP_v2+GEO type as an entry in the MRT namespaces, in accordance with BCP 26, RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].

8.  Security Considerations

This extension to the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” March 2010.) [I‑D.ietf‑grow‑mrt] defines fields that are of a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the author believes that they do not constitute an additional security risk.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address