Network Working Group E. Chen
Internet Draft N. Shen
Intended Status: Standards Track Cisco Systems
Expiration Date: August 13, 2016 R. Raszuk
Bloomberg LP
February 11, 2016
Carrying Geo Coordinates in BGP
draft-chen-idr-geo-coordinates-00.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 August 13, 2016.
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-00.txt February 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-00.txt February 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
12 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Latitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Longitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
N: When set to 1 means North, otherwise South.
Latitude Degrees: Valid values range from 0 to 90 degrees above or
below the equator (northern or southern hemisphere,
respectively).
Latitude Minutes: Valid values range from 0 to 59.
Latitude Seconds: Valid values range from 0 to 59.
E: When set to 1 means East, otherwise West.
Longitude Degrees: Value values are from 0 to 180 degrees right or
left of the Prime Meridian.
Longitude Minutes: Valid values range from 0 to 59.
Longitude Seconds: Valid values range from 0 to 59.
Altitude: Height relative to sea level in meters. This is a signed
integer meaning that the altitude could be below sea level. A
value of 0x7fffffff indicates no Altitude value is encoded.
The encoding of the Geo location is adapted from the "Geo Coordinate
LISP Canonical Address Format" [I-D.ietf-lisp-lcaf].
Chen, Shen & Raszuk [Page 3]
Internet Draft draft-chen-idr-geo-coordinates-00.txt February 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Latitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Longitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
Chen, Shen & Raszuk [Page 4]
Internet Draft draft-chen-idr-geo-coordinates-00.txt February 2016
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 20.
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
This extension to BGP does not change the underlying security issues.
8. 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.
Chen, Shen & Raszuk [Page 5]
Internet Draft draft-chen-idr-geo-coordinates-00.txt February 2016
9. References
9.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>.
9.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.
[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>.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in
progress), September 2015.
Chen, Shen & Raszuk [Page 6]
Internet Draft draft-chen-idr-geo-coordinates-00.txt February 2016
10. 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
Email:robert@raszuk.net
Chen, Shen & Raszuk [Page 7]