TOC 
Global Routing Operations WorkingT. Manderson
GroupICANN
Internet-DraftDecember 14, 2010
Intended status: Informational 
Expires: June 17, 2011 


MRT BGP routing information export format with geo-location extensions
draft-ietf-grow-geomrt-01.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 June 17, 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 Subtype
    3.1.  GEO_PEER_TABLE
4.  Acknowledgements
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address




 TOC 

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



 TOC 

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,” September 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,” September 2010.) [I‑D.ietf‑grow‑mrt] and introduces an additional definition of a MRT Subtype field.



 TOC 

3.  Geo-location aware MRT Routing Information Subtype

The additional Subtype is defined for the TABLE_DUMP_v format, which extends the TABLE_DUMP_V2 type.



 TOC 

3.1.  GEO_PEER_TABLE

The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types 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 MRT subtypes would be as follows.

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

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

The format and function of the Collector BGP ID, Peer Count are as defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format. (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” September 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] datum decimal degrees format stored as a single precision float in the 32 bits allocated to the Collector Latitude and Collector Longitude. The latitude and longitude may be a Not A Number (NAN) for situations where the geo-location of the collector is considered private. The Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] datum coordinate and NAN values.

     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                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Peer Count           |  Peer entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the peer entries is shown below. The Peer Type and the Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” September 2010.) [I‑D.ietf‑grow‑mrt] PEER_INDEX_TABLE format. The order of the Peer entries in GEO_PEER_TABLE MUST match the order and number as existing in the PEER_INDEX_TABLE.

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 Latitude                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Peer Longitude                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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] datum decimal degrees format stored as a single precision float in the 32 bits allocated to the Peer Latitude and Peer Longitude. The latitude and longitude may be a Not A Number (NAN) for situations where the geo-location of the peer is considered private. The Peer Latitude and Peer Longitude MUST NOT be a mix of WGS84 (Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000.) [WGS 84] datum coordinate and NAN values for a single Peer.



 TOC 

4.  Acknowledgements

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

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



 TOC 

5.  IANA Considerations

This section requests the Internet Assigned Numbers Authority (IANA) register the additional Subtype code value as:

    7    GEO_PEER_TABLE

in the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” September 2010.) [I‑D.ietf‑grow‑mrt] and Subtype code values related to the TABLE_DUMP_v2 type in the MRT namespace, in accordance with BCP 26, RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].



 TOC 

6.  Security Considerations

This extension to the "MRT format" (Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” September 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. It is recommended that the operators of the BGP collector and Peers consider their own privacy concerns before supplying geographical coordinates in MRT dumps.



 TOC 

7.  References



 TOC 

7.1. Normative References

[I-D.ietf-grow-mrt] Blunk, L., Karir, M., and C. Labovitz, “MRT routing information export format,” draft-ietf-grow-mrt-13 (work in progress), September 2010 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4271] Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” RFC 4271, January 2006 (TXT).
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” RFC 4760, January 2007 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).


 TOC 

7.2. Informative References

[MRT PROG GUIDE] Labovitz, C., “MRT Programmer's Guide,” November 1999 (HTML).
[WGS 84] Geodesy and Geophysics Department, DoD., “World Geodetic System 1984,” January 2000 (HTML).


 TOC 

Author's Address

  Terry Manderson
  ICANN
Email:  terry.manderson@icann.org