Network Working Group E. Chen
Internet Draft N. Shen
Intended Status: Standards Track Cisco Systems
Expiration Date: April 29, 2017 R. Raszuk
Bloomberg LP
October 28, 2016
Carrying Geo Coordinates in BGP
draft-chen-idr-geo-coordinates-02.txt
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 29, 2017.
Copyright Notice
Copyright (c) 2016 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
Chen, Shen & Raszuk [Page 1]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
In this document we specify a new BGP capability - the Geo Coordinate
Capability, and a new BGP attribute - the Geo Coordinate Attribute,
for carrying the Geo Coordinate information in BGP.
1. Introduction
There are several potential applications as described hereby for the
physical location information of BGP speakers [RFC4271] in a network.
In an "overlay network" without IGPs or where the "underlay network"
belongs to a different administrative domain (e.g., using the BGP
Tunnel Encapsulation Attribute [I-D.ietf-idr-tunnel-encaps]), the
geographical location of the BGP speaker that sources the route in
the network can be used to derive some rough sense of "distance" as a
parameter in lieu of the IGP-metric in BGP path selection.
In the applications of "Service Function Chaining" [RFC7665], the Geo
location information of the Service Function Forwarders or the
Service Nodes, can help the design of Service Function Paths with
better traffic pattern and a lower latency.
The knowledge of the physical location of BGP speakers can also be
used to simplify the operational procedures for setting the outbound
"MED" value in route advertisement.
In this document we specify a new BGP capability - the Geo Coordinate
Capability, and a new BGP attribute - the Geo Coordinate Attribute,
for carrying the Geo Coordinate information in BGP.
1.1. Specification of Requirements
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].
Chen, Shen & Raszuk [Page 2]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
2. The Geo Coordinate Capability
The Geo Coordinate Capability is a new BGP capability [RFC5492]. The
Capability Code for this capability is specified in the "IANA
Considerations" section of this document. The Capability Length is
20 octets. The Capability Value consists of the following fields
that specify the location of the speaker using the WGS-84 (World
Geodetic System) reference coordinate system [WGS-84]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|N|E|A|M|R|K| Reserved-1 | Location Uncertainty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat Degrees | Latitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long Degrees | Longitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radius | Reserved-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
U-bit: If the U-bit is set, it indicates that the "Location
Uncertainty" field is specified. If the U-bit is clear, it
indicates the "Location Uncertainty" field is unspecified.
N-bit: If the N-bit is set, it indicates the Latitude is north
relative to the Equator. If the N-bit is clear, it
indicates the Latitude is south of the Equator.
E-bit: If the E-bit is set, it indicates the Longitude is east of
the Prime Meridian. If the E-bit is clear, it indicates the
Longitude is west of the Prime Meridian.
A-bit: If the A-bit is set, it indicates the "Altitude" field is
specified. If the A-bit is clear, it indicates the
"Altitude" field is unspecified.
M-bit: If the M-bit is set, it indicates the "Altitude" is
specified in meters. If the M-bit is clear, it indicates
the "Altitude" is in centimeters.
R-bit: If the R-bit is set, it indicates the "Radius" field is
specified and the encoding is for a circular area. If the
Chen, Shen & Raszuk [Page 3]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
R-bit is clear, it indicates the "Radius" field is
unspecified and the encoding is for a single point.
K-bit: If the K-bit is set, it indicates the "Radius" is specified
in kilometers. If the K-bit is clear, it indicates the
"Radius" is in meters.
Reserved-1: These bits are reserved. They SHOULD be set to zero by
the sender and MUST be ignored by the receiver.
Location Uncertainty: Unsigned 16-bit integer indicating the number
of centimeters of uncertainty for the location.
Latitude Degrees: Unsigned 8-bit integer with a range of 0 - 90
degrees north or south of the Equator (northern or southern
hemisphere, respectively).
Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 -
3,599,999 (i.e., less than 60 minutes).
Longitude Degrees: Unsigned 8-bit integer with a range of 0 - 180
degrees east or west of the Prime Meridian.
Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 -
3,599,999 (i.e., less than 60 minutes).
Altitude: Signed 32-bit integer containing the Height relative to
sea level in centimeters or meters. A negative height
indicates that the location is below sea level.
Radius: Unsigned 16-bit integer containing the radius of a circle
centered at the specified coordinates. The radius is
specified in meters unless the K-bit is specified indicating
specification in kilometers. If the radius is specified,
the geo-coordinates specify the entire area of the circle
defined by the radius and center point. While the use cases
herein do not make use of this field, future use cases may.
Reserved-2: The 16-bit field is reserved. It SHOULD be set to zero
by the sender and MUST be ignored by the receiver.
Chen, Shen & Raszuk [Page 4]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
3. The Geo Coordinate Attribute
The Geo Coordinate Attribute is an optional, transitive BGP attribute
[RFC4271]. The type of the attribute is described in the IANA
Considerations section, and the value of the attribute consists of
one or more of the tuple encoded as shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|N|E|A|M|R|K| Reserved-1 | Location Uncertainty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat Degrees | Latitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long Degrees | Longitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radius | Reserved-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the "AS number" and the "BGP Identifier" fields contain the AS
number and the BGP Identifier [RFC4271, RFC6286] of the BGP speaker
that sources or advertises the route, and the remaining fields
specify the location of the speaker using the WGS-84 (World Geodetic
System) reference coordinate system [WGS-84]. These location related
fields are hereby given the same description as the ones in the "Geo
Coordinate Capability" section.
4. Operations
The Geo Coordinate Capability may be used by a BGP speaker to
advertise its physical location to its neighbor. When an IGP (such
as OSPF or ISIS) is involved and accessible, it could be advantageous
for the Geo Coordinates to be carried in the IGP instead of in the
OPEN for internal BGP ("IBGP") sessions.
When a BGP speakers receives the Geo Coordinate Capability in the
OPEN message from a neighbor, it is up to the speaker and its local
policy to decide how the information would be used.
The Geo Coordinate Attribute may be used by a BGP speaker to encode
Chen, Shen & Raszuk [Page 5]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
the physical location of the speaker in an UPDATE message. In the
case that a route already contains the attribute, the speaker MAY
prepend its AS number, its BGP Identifier, and the Geo coordinate
information in the value field of the attribute, and adjust the
attribute length accordingly. Depending on local policy, the speaker
MAY also override the existing Geo Coordinate Attribute with its own
information in route advertisement.
When a BGP speakers receives the Geo Coordinate Attribute in an
UPDATE message from a neighbor, it is up to the speaker and the local
policy to decide how this attribute would be handled and used.
The Geo Coordinate Capability in an OPEN message does not have any
impact on how the Geo Coordinate Attribute in an UPDATE message
(carried over the same session) would be handled.
5. Error Handling
The Geo Coordinate Attribute in an UPDATE message is considered
malformed if the attribute length is not a non-zero multiple of 28.
An UPDATE message with a malformed Geo Coordinate Attribute SHALL be
handled using the approach of "attribute discard" [RFC7606].
6. IANA Considerations
This documents specifies a BGP capability, the Geo Coordinate
Capability. The capability type needs to be allocated by IANA.
This documents specifies a BGP attribute, the Geo Coordinate
Attribute. The attribute type needs to be allocated by IANA.
7. Security Considerations
The underlying security issues for BGP are discussed in [RFC4271].
Since the Geo coordinates provide the exact location of the routing
devices, disclosure may make the routing devices more susceptible to
physical attacks. In situations where this is a concern (e.g., in
military applications, or the topology of the network is considered
proprietary information), the implementation MUST allow the Geo
Location extension to be removed from the BGP's OPEN and UPDATE
messages.
Chen, Shen & Raszuk [Page 6]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
8. Privacy Considerations
TBD.
9. Acknowledgments
The encoding of the Geo location is adapted from the "Geo Coordinate
LISP Canonical Address Format" specified in the "LISP Canonical
Address Format (LCAF)". We would like to thank the authors of that
Document and particularly Dino Farinacci for subsequent discussions.
Thanks to Yi Yang and Acee Lindem for review and discussions of the
Geo Coordinate encoding.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>.
[RFC6286] Chen, E., and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <http://www.rfc-editor.org/info/rfc6286>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.
[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", NIMA TR8350.2, January 2000, <http://earth-
info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.
Chen, Shen & Raszuk [Page 7]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
10.2. Informative References
[I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-01
(work in progress), December 2015.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7459] Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in the Presence Information
Data Format Location Object (PIDF-LO)", RFC 7459,
DOI 10.17487/RFC7459, February 2015,
<http://www.rfc-editor.org/info/rfc7459>.
[RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
11. Authors' Addresses
Enke Chen
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: enkechen@cisco.com
Naiming Shen
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: naiming@cisco.com
Robert Raszuk
Bloomberg LP
731 Lexington Ave
New York City, NY 10022
USA
Chen, Shen & Raszuk [Page 8]
Internet Draft draft-chen-idr-geo-coordinates-02.txt October 2016
Email:robert@raszuk.net
Chen, Shen & Raszuk [Page 9]