Global Routing Operations Working                           T. Manderson
Group                                                              ICANN
Internet-Draft                                         September 8,                                         December 14, 2010
Intended status: Informational
Expires: March 12, June 17, 2011

 MRT BGP routing information export format with geo-location extensions
                     draft-ietf-grow-geomrt-00.txt
                     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 March 12, 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  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Geo-location aware MRT Routing Information Type  . Subtype . . . . . .  5
   4.  TABLE_DUMP_v2+GEO Type . . . . . . .
     3.1.  GEO_PEER_TABLE . . . . . . . . . . . . .  6
   5.  Implementation Note  . . . . . . . . . . . . . . . . . . . . .  9
   6.  5
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1. 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2. 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 11

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

   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" [I-D.ietf-grow-mrt] originally defined in the MRT
   Programmer's Guide [MRT PROG GUIDE].

   This memo documents an extension to the "MRT format"
   [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
   Type field and related
   Subtype fields. field.

3.  Geo-location aware MRT Routing Information Type Subtype

   The following additional Type Subtype is defined for the TABLE_DUMP_v2+GEO TABLE_DUMP_v 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

3.1.  GEO_PEER_TABLE

   The TABLE_DUMP_v2+GEO Type GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Type Types to include
   Geo-location information in the form of WGS84 [WGS 84] formatted
   coordinates.  The following MRT subtypes would be 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. 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 extended PEER_INDEX_TABLE GEO_PEER_TABLE MRT record provides the BGP ID of the collector, the
   Its latitude and longitude in WGS84 [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 PEER_INDEX_TABLE format.
   [I-D.ietf-grow-mrt].

   The Collector Latitude and Collector Longitude are the geographical
   coordinates of the collector in WGS84 [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 [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                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       View Name Length        |     View Name (variable)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          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
   [I-D.ietf-grow-mrt] PEER_INDEX_TABLE
   record contains format.  The order of the Peer Count peer entries.
   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 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 collector peer in WGS84 [WGS 84] datum decimal degrees format stored as
   a single precision float in the 32 bits allocated to the Peer
   Latitude and Longitude.

   The Peer Type field remains as defined in the TABLE_DUMP_V2 MRT
   format [I-D.ietf-grow-mrt]. Longitude.  The records which follow the PEER_INDEX_TABLE record constitute the
   RIB entries latitude and their formats remain unchanged from TABLE_DUMP_V2+
   GEO.

   That is the common format longitude may be a Not
   A Number (NAN) for situations where the RIB_IPV4_UNICAST,
   RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST remains
   as defined for TABLE_DUMP_V2 and geo-location of the header peer 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           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   considered private.  The RIB entries that follow the RIB entry headers are also unchanged
   from MRT [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 Longitude MUST not NOT be used if the Collector's
   Latitude
   a mix of WGS84 [WGS 84] datum coordinate and Longitude have not been defined.

6. NAN values for a single
   Peer.

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.

7.

5.  IANA Considerations

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

       7    GEO_PEER_TABLE

   in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values
   related to the
   TABLE_DUMP_v2+GEO TABLE_DUMP_v2 type as an entry in the MRT namespaces, namespace, in accordance
   with BCP 26, RFC 5226 [RFC5226].

8.

6.  Security Considerations

   This extension to the "MRT format" [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.  It
   is recommended that the operators of the BGP collector and Peers
   consider their own privacy concerns before supplying geographical
   coordinates in MRT dumps.

7.  References

9.1.

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-11 draft-ietf-grow-mrt-13 (work
              in progress), March September 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

9.2.

7.2.  Informative References

   [MRT PROG GUIDE]
              Labovitz, C., "MRT Programmer's Guide", November 1999,
              <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.

   [WGS 84]   Geodesy and Geophysics Department, DoD., "World Geodetic
              System 1984", January 2000, <http://earth-info.nga.mil/
              GandG/publications/tr8350.2/wgs84fin.pdf>.

Author's Address

   Terry Manderson
   ICANN

   Email: terry.manderson@icann.org