Network Working Group D. Farinacci
Internet-Draft V. Fuller
Intended status: Experimental D. Meyer
Expires: May 14, 2008 Cisco
November 11, 2007
LISP Alternative Topology (LISP-ALT)
draft-fuller-lisp-alt-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Farinacci, et al. Expires May 14, 2008 [Page 1]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
Abstract
This document describes a method of building an alternative, logical
topology for managing Endpoint Identifier to Routing Locator mappings
using the Locator/ID Separation Protocol. The logical network is
built as an overlay on the public Internet using existing
technologies and tools, specifically the Border Gateway Protocol and
the Generic Routing Encapsulation. An important design goal for
LISP-ALT is to allow for the relatively easy deployment of an
efficient mapping system while minimizing changes to existing
hardware and software.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 7
5. LISP-ALT: Basic Overview . . . . . . . . . . . . . . . . . . . 8
5.1. EID assignment - hierarchy and topology . . . . . . . . . 8
5.2. The EID Prefix Aggregator (EPA) . . . . . . . . . . . . . 8
5.3. Use of GRE tunnels between EPAs . . . . . . . . . . . . . 8
6. How the LAVN uses BGP . . . . . . . . . . . . . . . . . . . . 10
6.1. Subsequent Address Family Identifier (SAFI) . . . . . . . 10
6.2. Alternative Autonomous System numbering space . . . . . . 10
7. EID prefix aggregation . . . . . . . . . . . . . . . . . . . . 11
8. Connecting sites to the LAVN . . . . . . . . . . . . . . . . . 12
8.1. ETRs originating information into the LISP-ALT network . . 12
8.2. ITRs receiving information from the LAVN . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Farinacci, et al. Expires May 14, 2008 [Page 2]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
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].
Farinacci, et al. Expires May 14, 2008 [Page 3]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
2. Introduction
This document describes a method of building an alternative logical
topology for managing Endpoint Identifier to Routing Locator mappings
using the Locator/ID Separation Protocol [LISP]. This logical
topology uses existing technology and tools, specifically the Border
Gateway Protocol [RFC4271] and its multi-protocol extension
[RFC2858], along with the Generic Routing Encapsulation [RFC2784]
protocol to construct an overlay network of Endpoint Identifier
Prefix Aggregators. Endpoint Identifier Prefix Aggregators hold
hierarchically-assigned pieces of the Endpoint Identifier space
(i.e., prefixes) and their next hops toward the network element which
is responsible for Endpoint Identifier-to-Routing Locator mapping for
that prefix. Tunnel routers can use this overlay to make queries
against and respond to mapping requests made against the distributed
Endpoint Identifier-to-Routing Locator mapping database.
Note that an important design goal of LISP-ALT is to minimize the
number of changes to existing hardware and/or software changes that
are required to deploy the mapping system. It is envisioned that in
most cases existing technology can be used to implement and deploy
LISP-ALT.
The remainder of this document is organized as follows: Section 3
provides the definitions of terms used in this document. Section 4
outlines the basic LISP 1.5 model. Section 5 provides a basic
overview of the LISP-ALT architecture, and Section 6 describes how
LISP-ALT uses BGP to propagate Endpoint Identifier reachability over
the overlay network. Section 7 describes the construction of the
LISP-ALT aggregation hierarchy, and Section 8 discusses how the
elements of the LISP-ALT topology are connected to form the overlay
network.
Farinacci, et al. Expires May 14, 2008 [Page 4]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
3. Definition of Terms
LISP-ALT operates on two name spaces and introduces a new network
element, the EID Prefix Aggregators (see below). This section
provides high-level definitions of the LISP-ALT name spaces, network
elements, and message types.
Endpoint ID (EID): A 32- or 128-bit value used in the source and
destination fields of the first (most inner) LISP header of a
packet. A packet that is emitted by a system contains EIDs in its
headers and and LISP headers are prepended only when the packet
hits an Ingress Tunnel Router (ITR) on the data path to the
destination EID.
In LISP-ALT, EID-prefixes MUST BE assigned in a hierarchical
manner (in power-of-two or larger chunks) such that they can be
aggregated by EID Prefix Aggregators (or EPAs; see below). In
addition, a site may have site-local structure in how EIDs are
topologically organized (subnetting) for routing within the site;
this structure is not visible to the global routing system.
EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable
in the [RFC4632] sense. That is, an EID-Prefix aggregate is
defined to be a single contiguous power-of-two EID-prefix block.
Such a block is characterized by a prefix and a length.
Routing Locator (RLOC): An IP address of an egress tunnel router
(ETR). It is the output of a EID-to-RLOC mapping lookup. An EID
maps to one or more RLOCs. Typically, RLOCs are numbered from
topologically-aggregatable blocks that are assigned to a site at
each point to which it attaches to the global Internet; where the
topology is defined by the connectivity of provider networks,
RLOCs can be thought of as Provider Aggregatable (PA) addresses.
EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that
can be used to reach the EID. We use the term "mapping" in this
document to refer to a EID-to-RLOC mapping.
EID Prefix Reachability: Reachability to the ETR (or its proxy)
that is responsible for a given EID-to-RLOC mapping.
The LISP Alternative Virtual Network (LAVN): The virtual overlay
network made up of Generic Routing Encapsulation (GRE) tunnels
between EID Prefix Aggregators. The Border Gateway Protocol (BGP)
runs between these devices and is used to carry reachability
information for EID prefixes.
Farinacci, et al. Expires May 14, 2008 [Page 5]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
Legacy Internet: The portion of the Internet which does not run LISP
and does not participate in the LAVN.
EID Prefix Aggregator (EPA): The devices which are used to build the
LAVN. EPAs are deployed in a hierarchy which matches the EID
prefix allocation hierarchy. EPAs at each level in the this
hierarchy are responsible for aggregating all EID prefixes learned
from EPAs logically "below" them and advertising summary prefixes
to the EPAs logically "above" them. All prefix learning and
propagation between levels is done using BGP. EPAs at the lowest
level, or "edge", of the LAVN learn EID prefixes either over a BGP
or TCP session to ETRs. See Section 6 for details on how BGP is
configured between the different network elements.
It is important to note that the primary function of of the EPAs
is provide a forwarding infrastructure for LISP control-plane
messages (Map-Request and Map-Reply), and to transport data
packets when the packet has the same destination address in both
the inner (encapsulated) destination and outer destination
addresses (i.e., a data probe packet).
Farinacci, et al. Expires May 14, 2008 [Page 6]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
4. The LISP 1.5 model
As documented in [LISP], the LISP 1.5 model uses the same basic
query/response protocol machinery as LISP 1.0. In particular, LISP-
ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings
(both of these techniques are described in more detail in
Section 8.2):
Data Probe: An ITR may send the first few data packets into the
LISP-ALT topology (hereafter "ALT topology") to minimize packet
loss and to probe for the mapping; the authoritative ETR will
respond to the ITR with a Map-Reply message when it receives the
data packet over the ALT topology.
Map-Request: An ITR may also send a Map-Request message into the ALT
topology to request the mapping. As in the data probe case, the
authoritative ETR will respond to the ITR with a Map-Reply
message. See [LISP] for the format of Map-Request and Map-Reply
packets.
Like LISP 1.0, EIDs are routable and can be used, unaltered, as the
source and destination addresses in IP datagrams. Unlike in LISP
1.0, LISP 1.5 EIDs are not routed on the public Internet; instead,
they are only routable over a separate, virtual topology referred to
as the LISP Alternative Virtual Network. This network is built as an
overlay on the public Internet using GRE tunnels to interconnect EID
Prefix Aggregators (EPAs). BGP is run over these tunnels to
propagate EID prefix reachability information. Importantly, while
the ETRs are the source(s) of the unaggregated EID prefix data, LISP-
ALT uses existing BGP mechanisms to aggressively aggregate this
information. Finally, note that ETRs are not required to participate
(or prevented from participating) in the LAVN; they may choose
communicate their mappings to their serving EPA(s) at subscription
time via configuration.
Farinacci, et al. Expires May 14, 2008 [Page 7]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
5. LISP-ALT: Basic Overview
LISP-ALT is a hybrid push/pull architecture. Aggregated EID prefixes
are "pushed" among the EPAs and, optionally, out to ITRs (which may
elect to receive the aggregated information, as opposed to simply
using a "default" EID prefix). Specific EID-to-RLOC mappings are
"pulled" by ITRs when they either send explicit LISP requests or data
packets on the alternate topology that result in triggered replies
being generated by ETRs.
The basic idea underlying LISP-ALT is to use BGP, running over a GRE
overlay, to build the LAVN reachability required to route data
probes, Map-Requests, and Map-Replies. The LAVN RIB is comprised of
EID prefixes (and associated next hops). The EPAs talk eBGP to each
other in order to propagate EID reachability information, which is
learned either over eBGP connections from the responsible ETR, or by
configuration. ITRs may also eBGP peer with one or more EPAs in
order to route data probe packets or Map-Requests (more likely, an
ITR will have a default route pointing at one or more EPAs).
In summary, the LAVN uses BGP to propagate reachability information
used by ITRs and ETRs to forward Map-Requests, Map-Replies, and data
probes. This reachability is carried as IPv4 or IPv6 NLRI without
modification (since the EID space has the same syntax as IPv4 or
IPv6). EPAs eBGP peer with one another, forming the LAVN. An EPA
near the edge learns EID prefixes which are originated by
authoritative ETRs, which either eBGP peer with them or by
configuration. EPAs aggregate EID prefixes, and forward data probes,
Map-Requests, and Map-Replies.
5.1. EID assignment - hierarchy and topology
TBD, but connections between EPAs in the LAVN, and between EPAs and
ETRs, should follow the EID allocation hierarchy so that the
opportunity to aggregate the EID space is optimized.
5.2. The EID Prefix Aggregator (EPA)
TBD, but its just a BGP speaker in the LAVN overlay. It uses
standard BGP machinery to implement its policy, if any.
5.3. Use of GRE tunnels between EPAs
The use of GRE [RFC2784] tunnels between EPAs offers many advantages,
including:
Farinacci, et al. Expires May 14, 2008 [Page 8]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
IGP: Running over GRE leaves open the possibility that the LAVN
could run an IGP on the inter-EPA links.
Assurance of Authenticity: A bogus Map-Reply can't be injected,
since an EPA knows it's not valid unless it comes over a GRE
interface.
other?
Farinacci, et al. Expires May 14, 2008 [Page 9]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
6. How the LAVN uses BGP
As described in Section 8.2, an ITR may send either a Map-Request or
a data probe to find a given EID-to-RLOC mapping. The LAVN provides
the infrastructure that allows these requests to reach the
responsible ETR, and possibly for the reply to find its way back to
the requesting ITR (the ETR might choose to UDP encapsulate the Map-
Reply and send it directly to the requesting ITR, bypassing the
LAVN).
The LAVN propagates reachability information for use by ITRs (when
making Map-Requests or sending data probes), and ETRs (if the ETR is
configured to send Map-Replies back to the requesting ITR over the
LAVN) using eBGP [RFC4271]. eBGP is run on the inter-EPA links, and
and possibly between an edge EPA and an ETR or between an edge EPA
and an ITR. The LAVN eBGP RIB consists of aggregated EID prefixes
and their next hops towards the responsible ETR for that EID prefix.
An ITR or ETR may choose not to run an eBGP instance with the LAVN.
Rather, the ITR or ETR may have a default route (for the LAVN)
pointing at its EPA. In this case, data probe and Map-Requests
messages are sent to the default EPA, and are routed over the LAVN to
the responsible ETR. The ETR may send the Map-Reply message back
over the LAVN, or it may choose to send the message UDP encapsulated
directly back to the requesting ITR, bypassing the LAVN.
Finally, note that LISP-ALT requires no modification to the BGP
protocol, and is designed to be deployable without additional
protocol machinery.
6.1. Subsequent Address Family Identifier (SAFI)
TBD [RFC2858]
6.2. Alternative Autonomous System numbering space
TBD
Farinacci, et al. Expires May 14, 2008 [Page 10]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
7. EID prefix aggregation
TBD
Farinacci, et al. Expires May 14, 2008 [Page 11]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
8. Connecting sites to the LAVN
8.1. ETRs originating information into the LISP-ALT network
ETRs have two ways of originating EID information into the LAVN:
eBGP: ETRs may originate information by participating in the LAVN
via eBGP. In this case, The ETR advertises reachability for its
EID prefixes over this eBGP connection to the EPAs. The EPAs
propagate and aggregate this information into the LAVN. That is,
here the ETR is simply a peer of an EPA at the edge of the LAVN.
An EPA should aggregate the received EID-prefixes (where
possible).
Configuration: An EPA may be configured with the EID-prefix of the
responsible ETR, which is connected to the EPA via TCP connection
(port TBD). This TCP connection is used to route Map-Requests to
the ETR (if necessary), and for the ETR to respond with Map-
Replies. Of course, the EPA could also serve as a proxy for its
TCP-connected ETRs. Finally, depending on configuration and which
prefixes an ETR is responsible for, an ETR may need to connect to
more than one EPA to have all of its prefixes routed via the LAVN.
8.2. ITRs receiving information from the LAVN
In order to source Map-Requests to the LAVN and receive Map-Replies
from the LAVN, or to route a data probe packet over the LAVN, each
ITR participating in the LAVN establishes a connection to one or more
EPAs. These connections can be either eBGP or TCP (as described
above).
In the case in which the ITR is running eBGP, the peer EPAs use these
connections to advertise highly aggregated EID-prefixes to the peer
ITRs. The ITR then installs the received prefixes into a forwarding
table that is used to to send LISP Map-Requests to the appropriate
EPA. In most cases, an EPA will send a "default" EID prefix to its
client ITRs so that they can send request for any EID prefix into the
LAVN.
In the case in which the ITR is connected to some set of EPAs without
eBGP (i.e., over a TCP connection), the ITR sends Map-Requests to any
of its connected EPAs, and receives Map-Replies from the EPA that has
the "shortest path" to the authoritative ETR.
An ITR may also chose to send the first few data packets over the
LAVN, in order to minimize packet loss and reduce mapping latency.
In this case, the data packet serves as a mapping probe, and the ETR
which receives the data packet (over the LAVN) responds with a Map-
Farinacci, et al. Expires May 14, 2008 [Page 12]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
Reply that is either routed back over the LAVN, or UDP encapsulated
and sent directly back to the source ITR.
In general, an ITR will establish connections only to EPAs at the
"edge" of the LAVN topology (typically two for redundancy) but there
may also be situations where an ITR would connect to other EPAs to
receive more detailed information about a portion of the LAVN
topology of interest to it. This can be accomplished by establishing
a GRE tunnel between the ITR and the set of EPAs the ITR is
interested in. This is a purely local policy issue between the ITR
and the EPAs in question.
Farinacci, et al. Expires May 14, 2008 [Page 13]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
9. IANA Considerations
The IANA SHOULD assign port TBD for ITR and ETR to EPA TCP
connections as described in Section 8.
Farinacci, et al. Expires May 14, 2008 [Page 14]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
10. Security Considerations
TBD
Farinacci, et al. Expires May 14, 2008 [Page 15]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
11. Acknowledgments
Many of the ideas described in this document developed during
detailed discussions with Scott Brim and Darrel Lewis, who made many
insightful comments on earlier versions of this document.
Farinacci, et al. Expires May 14, 2008 [Page 16]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
12.2. Informative References
[LISP] Farinacci, D., Oran, D., Fuller, V., and D. Meyer,
"Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-04.txt (work in progress), July 2007.
Farinacci, et al. Expires May 14, 2008 [Page 17]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
Authors' Addresses
Dino Farinacci
Cisco
Tasman Drive
San Jose, CA 95134
USA
Email: dino@cisco.com
Vince Fuller
Cisco
Tasman Drive
San Jose, CA 95134
USA
Email: vaf@cisco.com
Dave Meyer
Cisco
Tasman Drive
San Jose, CA 95134
USA
Email: dmm@cisco.com
Farinacci, et al. Expires May 14, 2008 [Page 18]
Internet-Draft LISP Alternative Topology (LISP-ALT) November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Farinacci, et al. Expires May 14, 2008 [Page 19]