draft-ietf-grow-geomrt-01.txt   draft-ietf-grow-geomrt-02.txt 
Global Routing Operations Working T. Manderson Global Routing Operations Working Group T. Manderson
Group ICANN Internet-Draft ICANN
Internet-Draft December 14, 2010 Intended status: Informational May 23, 2011
Intended status: Informational Expires: November 24, 2011
Expires: June 17, 2011
MRT BGP routing information export format with geo-location extensions MRT BGP routing information export format with geo-location extensions
draft-ietf-grow-geomrt-01.txt draft-ietf-grow-geomrt-02.txt
Abstract Abstract
This document extends the Border Gateway Protocol (BGP) MRT export This document extends the Border Gateway Protocol (BGP) Multi-
format for routing information to include terrestrial coordinates. threaded Routing Toolkit (MRT) export format for routing information
to include terrestrial coordinates of a BGP Collector and its BGP
Peers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 17, 2011. This Internet-Draft will expire on November 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Geo-location aware MRT Routing Information Subtype . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 5 4. Geo-location aware MRT Routing Information Subtype . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.2. GEO_PEER_TABLE and peer entry values. . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Research is underway that analyzes the network behavior of routing Researchers and engineers often wish to analyze network behavior by
protocol transactions from routing information base snapshots in studying routing protocol transactions and routing information base
relation to geographical coordinates. Specifically the BGP routing snapshots in relation to geographical topologies. Usually the Border
protocol is the subject of study and the analysis has been Gateway Protocol [RFC4271] is the subject of study and the analysis
significantly aided by the availability and extension of the "MRT can be significantly aided by the availability and extension of the
format" [I-D.ietf-grow-mrt] originally defined in the MRT "Multi-threaded Routing Toolkit (MRT) format" [I-D.ietf-grow-mrt].
Programmer's Guide [MRT PROG GUIDE]. The MRT format was originally defined in the Multi-threaded Routing
Toolkit Programmer's Guide [MRT-GUIDE].
The addition of geo-location coordinates (longitude and latitude)
pertaining to the geographical location of both the BGP collector and
its BGP peers to BGP export data enables a researcher or enquiring
individual to gain a tererestrial insight to the routes seen by a BGP
speaker. Such data may ultimately aide reserachers in understanding
any disparity between the geographical location of networks and the
topological location of networks in addition to the relationships
between geographical position and routing anomolies. Such insight
could provide future input into network design or network security.
This memo documents an extension to the "MRT format" This memo documents an extension to the "MRT format"
[I-D.ietf-grow-mrt] and introduces an additional definition of a MRT [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
Subtype field. subtype field that includes the terestrial coordinates of a BGP
Collector and its BGP Peers.
3. Geo-location aware MRT Routing Information Subtype 3. Definitions
The additional Subtype is defined for the TABLE_DUMP_v format, which Coordinates: A set of geographic latitude and longitude specifying a
extends the TABLE_DUMP_V2 type. location on the Earth.
3.1. GEO_PEER_TABLE BGP Speaker: A network device which exchanges network routing
information using BGP.
Geo-location: Assigning a set of coordinates to a specific artifact,
in this case a BGP speaker.
BGP Collector: A BGP speaker (usually passive) that stores and
archives BGP routing data from active BGP peers for analysis.
BGP Peer: Either an internal or external BGP peer [RFC4271].
Not A Number (NAN): numeric data type representing an undefined or
unrepresentable value. As defined in IEEE Standard for Floating-
Point Arithmetic [IEEE754].
4. Geo-location aware MRT Routing Information Subtype
An additional subtype (GEO_PEER_TABLE) is defined for the
TABLE_DUMP_v2 format, extending TABLE_DUMP_V2 Type.
4.1. GEO_PEER_TABLE
The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include
Geo-location information in the form of WGS84 [WGS 84] formatted Geo-location information in the form of WGS84 [WGS-84] formatted
coordinates. The MRT subtypes would be as follows. coordinates.
1 PEER_INDEX_TABLE The document adds the 7th subtype number and name below. The first 6
2 RIB_IPV4_UNICAST subtypes are defined by the "MRT format" [I-D.ietf-grow-mrt].
3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST Subtype Number Subtype Name
5 RIB_IPV6_MULTICAST ----------------------------------
6 RIB_GENERIC 7 GEO_PEER_TABLE
7 GEO_PEER_TABLE
The GEO_PEER_TABLE MRT record provides the BGP ID of the collector, The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
Its latitude and longitude in WGS84 [WGS 84] format, and a list of its latitude and longitude in WGS84 [WGS-84] format, and a list of
indexed peers. indexed peers and their respective latitudes and longitudes in WGS84
[WGS-84] format.
The format and function of the Collector BGP ID, Peer Count are as The format and function of the Collector BGP ID, Peer Count are as
defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format. defined by the TABLE_DUMP_V2 PEER_INDEX_TABLE format.
[I-D.ietf-grow-mrt]. [I-D.ietf-grow-mrt].
The Collector Latitude and Collector Longitude are the geographical The Collector Latitude and Collector Longitude are the geographical
coordinates of the collector in WGS84 [WGS 84] datum decimal degrees coordinates of the collector in WGS84 [WGS-84] datum decimal degrees
format stored as a single precision float in the 32 bits allocated to format stored as a single precision float in the 32 bits allocated to
the Collector Latitude and Collector Longitude. The latitude and the Collector Latitude and Collector Longitude. The latitude and
longitude may be a Not A Number (NAN) for situations where the geo- longitude MAY be a Not A Number (NAN) [IEEE754] for situations where
location of the collector is considered private. The Collector the geo-location of the collector is considered private. The
Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84] Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84
datum coordinate and NAN values. [WGS-84] datum coordinate and NAN values.
0 1 2 3 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 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 BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector Latitude | | Collector Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector Longitude | | Collector Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | Peer entries (variable) | Peer Count | Peer entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of the GEO_PEER_TABLE
The format of the peer entries is shown below. The Peer Type and the 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 Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT
[I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer [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 entries in GEO_PEER_TABLE MUST match the order and number as existing
in the PEER_INDEX_TABLE. in the PEER_INDEX_TABLE.
0 1 2 3 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 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 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Latitude | | Peer Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Longitude | | Peer Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of peer entries
The Peer Latitude and Peer Longitude are the geographical coordinates The Peer Latitude and Peer Longitude are the geographical coordinates
of the peer in WGS84 [WGS 84] datum decimal degrees format stored as of the peer in WGS84 [WGS-84] datum decimal degrees format stored as
a single precision float in the 32 bits allocated to the Peer a single precision float in the 32 bits allocated to the Peer
Latitude and Peer Longitude. The latitude and longitude may be a Not 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 A Number (NAN) [IEEE754] for situations where the geo-location of the
considered private. The Peer Latitude and Peer Longitude MUST NOT be peer is considered private. The Peer Latitude and Peer Longitude
a mix of WGS84 [WGS 84] datum coordinate and NAN values for a single MUST NOT be a mix of WGS84 [WGS-84] datum coordinate and NAN values
Peer. for a single Peer.
4. Acknowledgements 4.2. GEO_PEER_TABLE and peer entry values.
Collector BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]
Collector Latitude: Geographic latitude of the BGP collector in WGS84
[WGS-84] datum decimal degrees format stored as a single precision
float.
Collector Longitude: Geographic Longitude of the BGP collector in
WGS84 [WGS-84] datum decimal degrees format stored as a single
precision float.
Peer Count: Defined in the MRT format [I-D.ietf-grow-mrt]
Peer entries: Defined in the MRT format [I-D.ietf-grow-mrt]
Peer Type: Defined in the MRT format [I-D.ietf-grow-mrt]
Peer BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]
Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84]
datum decimal degrees format stored as a single precision float.
Peer Longitude: Geographic Longitude of the BGP peer in WGS84
[WGS-84] datum decimal degrees format stored as a single precision
float.
5. BGP Collector Construction
This section is to aide the reader in understanding the function of a
BGP collector.
The BGP Collector is a device (hardware or software based) which
speaks the Border Gateway Protocol and its intended function is to
store (and archive) the BGP routing data it receives from other BGP
speakers it has peering relationships with, providing data for later
analysis. The general nature of a BGP Collector is that it is a
passive device in that it listens to route updates, and does not
announce nor propagate any information it knows or receives. It
should be noted that this is not always the case, network operators
sometimes enable the collection of BGP routing data on active BGP
speakers to obtain a situational view of the routing system as they
see it at a particular point in time.
As a fully fledged BGP speaker the BGP Collector can fit into any BGP
topology including iBGP, eBGP, and so on. The implementation of a
BGP collector in a network topology is therefore limited by that
network's use of BGP.
6. Acknowledgements
Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard
Barnes, and Jeffrey Haas for reviewing this document. Barnes, and Jeffrey Haas for reviewing this document.
This document describes a small portion of the research towards the This document describes a small portion of the research towards the
author's PhD. author's PhD.
5. IANA Considerations 7. 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" [I-D.ietf-grow-mrt] and Subtype code values This document makes no request to IANA
related to the TABLE_DUMP_v2 type in the MRT namespace, in accordance
with BCP 26, RFC 5226 [RFC5226].
6. Security Considerations 8. Security Considerations
This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields
that are of a descriptive nature and provide information that is that are of a descriptive nature and provide information that is
useful in the analysis of routing systems. As such, the author useful in the analysis of routing systems. As such, the author
believes that they do not constitute an additional security risk. It believes that they do not constitute an additional security risk. It
is recommended that the operators of the BGP collector and Peers is recommended that the operators of the BGP collector and BGP peers
consider their own privacy concerns before supplying geographical consider their own privacy concerns before supplying geographical
coordinates in MRT dumps. coordinates to BGP data collection systems.
7. References 9. References
7.1. Normative References 9.1. Normative References
[I-D.ietf-grow-mrt] [I-D.ietf-grow-mrt]
Blunk, L., Karir, M., and C. Labovitz, "MRT routing Blunk, L., Karir, M., and C. Labovitz, "MRT routing
information export format", draft-ietf-grow-mrt-13 (work information export format", draft-ietf-grow-mrt-14 (work
in progress), September 2010. in progress), April 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 9.2. Informative References
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
7.2. Informative References [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic",
August 2008,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=4610933>.
[MRT PROG GUIDE] [MRT-GUIDE]
Labovitz, C., "MRT Programmer's Guide", November 1999, Labovitz, C., "MRT Programmer's Guide", November 1999,
<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
[WGS 84] Geodesy and Geophysics Department, DoD., "World Geodetic [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", January 2000, <http://earth-info.nga.mil/ System 1984", January 2000, <http://earth-info.nga.mil/
GandG/publications/tr8350.2/wgs84fin.pdf>. GandG/publications/tr8350.2/wgs84fin.pdf>.
Author's Address Author's Address
Terry Manderson Terry Manderson
ICANN ICANN
Email: terry.manderson@icann.org Email: terry.manderson@icann.org
 End of changes. 36 change blocks. 
85 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/