Internet Engineering Task Force (IETF) D. Saucez
Request for Comments: 7834 INRIA
Category: Informational L. Iannone
ISSN: 2070-1721 Telecom ParisTech
A. Cabellos
F. Coras
Technical University of Catalonia
April 2016
Internet Engineering Task Force (IETF) D. Saucez
Request for Comments: 7834 INRIA
Category: Informational L. Iannone
ISSN: 2070-1721 Telecom ParisTech
A. Cabellos
F. Coras
Technical University of Catalonia
April 2016
Locator/ID Separation Protocol (LISP) Impact
定位器/ID分离协议（LISP）的影响
Abstract
摘要
The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.
Locator/ID分离协议（LISP）旨在通过利用三个原则来改进Internet路由可伸缩性属性：地址角色分离、封装和映射。在本文中，基于实施工作、部署经验和理论研究，我们将讨论LISP部署对路由基础设施和最终用户的影响。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7834.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7834.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LISP in a Nutshell . . . . . . . . . . . . . . . . . . . . . 4
3. LISP for Scaling the Internet Routing Architecture . . . . . 5
4. Beyond Scaling the Internet Routing Architecture . . . . . . 6
4.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 8
4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 8
4.3. Inter-domain Multicast . . . . . . . . . . . . . . . . . 9
5. Impact of LISP on Operations and Business Models . . . . . . 10
5.1. Impact on Non-LISP Traffic and Sites . . . . . . . . . . 10
5.2. Impact on LISP Traffic and Sites . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LISP in a Nutshell . . . . . . . . . . . . . . . . . . . . . 4
3. LISP for Scaling the Internet Routing Architecture . . . . . 5
4. Beyond Scaling the Internet Routing Architecture . . . . . . 6
4.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 8
4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 8
4.3. Inter-domain Multicast . . . . . . . . . . . . . . . . . 9
5. Impact of LISP on Operations and Business Models . . . . . . 10
5.1. Impact on Non-LISP Traffic and Sites . . . . . . . . . . 10
5.2. Impact on LISP Traffic and Sites . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The Locator/ID Separation Protocol (LISP) relies on three principles to improve the scalability properties of Internet routing: address role separation, encapsulation, and mapping. When invented, LISP was targeted at solving the Internet routing scaling problem [RFC4984]. There have now been years of implementations and experiments examining the impact and open questions of using LISP to improve inter-domain routing scalability. Experience has shown that because LISP utilizes mapping and encapsulation technologies, it can be deployed and used for purposes that go beyond routing scalability. For example, LISP provides a mean for a LISP site to precisely control its inter-domain outgoing and incoming traffic, with the possibility to apply different policies to different domains exchanging traffic with it. LISP can also be used to ease the transition from IPv4 to IPv6 as it allows the transport of IPv4 over IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain multicast.
Locator/ID分离协议（LISP）依赖于三个原则来提高Internet路由的可伸缩性：地址角色分离、封装和映射。LISP发明时，其目标是解决Internet路由扩展问题[RFC4984]。现在已经有多年的实施和实验来检验使用LISP提高域间路由可伸缩性的影响和开放性问题。经验表明，由于LISP利用了映射和封装技术，因此可以将其部署并用于超出路由可伸缩性的目的。例如，LISP为LISP站点提供了精确控制域间传出和传入流量的方法，可以将不同的策略应用于与之交换流量的不同域。LISP还可以用于简化从IPv4到IPv6的转换，因为它允许通过IPv6传输IPv4或通过IPv4传输IPv6。此外，LISP还支持域间多播。
Leveraging implementation and deployment experience, as well as research work, this document describes, at a high level, the impacts and open questions still seen in LISP. This information is particularly useful for considering future approaches and to support further experimentation to clarify some large open questions (e.g., around the operations). LISP utilizes a tunnel-based data plane and a distributed control plane. LISP requires some new functionalities, such as reachability mechanisms. Because LISP is more than a simple encapsulation technology and is a new technology, until even more deployment experience is gained, some open questions related to LISP deployment and operations remain. As an encapsulation technology, there may be concerns on reduced Maximum Transmission Unit (MTU) size in some deployments. An important impact of LISP is on network operations related to resiliency and troubleshooting. As LISP relies on cached mappings and on encapsulation, resiliency during failures and troubleshooting may be more difficult. Also, the use of encapsulation may make failure detection and recovery slower, and it will require more coordination than with a single, non-encapsulated, routing domain solution.
利用实施和部署经验以及研究工作，本文档从较高的层次描述了LISP中仍然存在的影响和开放性问题。这些信息对于考虑未来的方法和支持进一步的实验以澄清一些大型开放性问题（例如，围绕操作）特别有用。LISP使用基于隧道的数据平面和分布式控制平面。LISP需要一些新功能，例如可达性机制。因为LISP不仅仅是一种简单的封装技术，而且是一种新技术，在获得更多的部署经验之前，与LISP部署和操作相关的一些开放性问题仍然存在。作为一种封装技术，在某些部署中可能会考虑减小最大传输单元（MTU）的大小。LISP的一个重要影响是与恢复能力和故障排除相关的网络操作。由于LISP依赖于缓存映射和封装，因此故障期间的恢复能力和故障排除可能更加困难。此外，使用封装可能会降低故障检测和恢复的速度，并且与单一的非封装路由域解决方案相比，它需要更多的协调。
LISP relies on three principles: address role separation, encapsulation, and mapping.
LISP依赖于三个原则：解决角色分离、封装和映射。
The address space is divided into two sets that have different semantic meanings: the Routing Locators (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses typically assigned from the Provider Aggregatable (PA) address space. The EIDs are attributed to the nodes in the edge networks, by a block of contiguous addresses, which are typically Provider Independent (PI). To limit the scalability problem, LISP only requires the PA routes towards the RLOCs to be announced in the provider infrastructure. Whereas for non-LISP deployments, the EIDs need to be propagated as well.
地址空间分为两组，它们具有不同的语义：路由定位器（RLOC）和端点标识符（EID）。RLOC是通常从提供者可聚合（PA）地址空间分配的地址。EID通过连续地址块归属于边缘网络中的节点，这些地址块通常是独立于提供商（PI）的。为了限制可伸缩性问题，LISP只要求在提供商基础设施中宣布通向RLOC的PA路由。而对于非LISP部署，EID也需要传播。
LISP routers are used at the boundary between the EID and the RLOC spaces. Routers used to exit the EID space (towards the provider domain) are called Ingress Tunnel Routers (ITRs), and those used to enter the EID space (from the provider domain) are called the Egress Tunnel Routers (ETRs). When a host sends a packet to a remote destination, it sends it as in the non-LISP Internet. The packet arrives at the border of its site at an ITR. Because EIDs are not routable on the Internet, the packet is encapsulated with the source address set to the ITR RLOC and the destination address set to the ETR RLOC. The encapsulated packet is then forwarded in the provider domain until it reaches the selected ETR. The ETR de-encapsulates the packet and forwards it to its final destination. The acronym xTR stands for Ingress/Egress Tunnel Router and is used for a router playing these two roles.
LISP路由器用于EID和RLOC空间之间的边界。用于退出EID空间（通向提供商域）的路由器称为入口隧道路由器（ITR），用于进入EID空间（来自提供商域）的路由器称为出口隧道路由器（ETR）。当主机向远程目的地发送数据包时，它会像在非LISP Internet中一样发送数据包。数据包到达ITR的站点边界。由于EID不能在Internet上路由，因此数据包被封装为源地址设置为ITR RLOC，目标地址设置为ETR RLOC。然后在提供者域中转发封装的数据包，直到它到达选定的ETR。ETR反封装数据包并将其转发到最终目的地。缩写词xTR代表入口/出口隧道路由器，用于扮演这两个角色的路由器。
The correspondence between EIDs and RLOCs is given by the mappings. When an ITR needs to find ETR RLOCs that serve an EID, it queries a mapping system. With the LISP Canonical Address Format (LCAF) [LISP-LCAF], LISP is not restricted to the Internet protocol for the EID addresses. With LCAF, any address type can be used as EID (the address is only the key for the mapping lookup). LISP can transport, for example, Ethernet frames over the Internet.
EID和RLOCs之间的对应关系由映射给出。当ITR需要查找为EID提供服务的ETR RLOC时，它会查询映射系统。使用LISP标准地址格式（LCAF）[LISP-LCAF]，LISP不限于EID地址的Internet协议。使用LCAF，任何地址类型都可以用作EID（地址只是映射查找的键）。例如，LISP可以通过Internet传输以太网帧。
An introduction to LISP can be found in [RFC7215]. The LISP specifications are given in [RFC6830], [RFC6833], [LISP-DDT], [RFC6836], [RFC6832], and [RFC6834].
有关LISP的介绍，请参见[RFC7215]。LISP规范在[RFC6830]、[RFC6833]、[LISP-DDT]、[RFC6836]、[RFC6832]和[RFC6834]中给出。
The original goal of LISP was to improve the scalability properties of the Internet routing architecture. LISP utilizes traffic engineering and stub Autonomous System (AS) prefixes (not announced anymore in the Default-Free Zone (DFZ)), so that routing tables are smaller and more stable (i.e., they experience less churn). Furthermore, at the edge of the network, information necessary to forward packets (i.e., the mappings) is obtained on demand using a pull model (whereas the current Internet BGP model uses a push model). Therefore, the scalability of edge networks is less dependent on the Internet's size and more related to its traffic matrix. This scaling improvement has been proven by several studies (see below). The research studies cited hereafter are based on the following assumptions:
LISP最初的目标是改进Internet路由体系结构的可伸缩性。LISP利用流量工程和存根自治系统（AS）前缀（在默认自由区（DFZ）中不再公布），因此路由表更小、更稳定（即，它们经历的搅动更少）。此外，在网络边缘，转发数据包（即映射）所需的信息是使用拉模型按需获得的（而当前的互联网BGP模型使用推模型）。因此，边缘网络的可扩展性较少地依赖于互联网的大小，而更多地与其流量矩阵相关。一些研究（见下文）证明了这种缩放改进。下文引用的研究基于以下假设：
o EID-to-RLOC mappings follow the same prefix size as the current BGP routing infrastructure (current PI addresses only);
o EID到RLOC的映射遵循与当前BGP路由基础设施相同的前缀大小（仅限当前PI地址）；
o EIDs are used only at the stub ASes, not in the transit ASes; and
o EID仅用于存根ASE，而不用于传输ASE；和
o the RLOCs of an EID prefix are deployed at the edge between the stubs owning the EID prefix and the providers, allocating the RLOCs in a PA mode.
o EID前缀的RLOC部署在拥有EID前缀的存根和提供者之间的边缘，以PA模式分配RLOC。
The above assumptions are inline with [RFC7215] and current LISP deployments. It is recognized these assumptions may change in the longer term. [KIF13] and [CDLC] explore different EID prefix space sizes and still show results that are consistent and equivalent to the above assumptions.
上述假设与[RFC7215]和当前LISP部署一致。我们认识到，这些假设在长期内可能会发生变化。[KIF13]和[CDLC]探索了不同的EID前缀空间大小，仍然显示了与上述假设一致且等效的结果。
Quoitin et al. [QIdLB07] show that the separation between locator and identifier roles at the network level improves the routing scalability by reducing the Routing Information Base (RIB) size (up to one order of magnitude) and increases path diversity and thus the traffic engineering capabilities. [IB07] and [KIF13] show, based on real Internet traffic traces, that the number of mapping entries that must be handled by an ITR of a network with up to 20,000 users is limited to few tens of thousands; the signaling traffic (i.e., Map-Request/Map-Reply packets) is in the same order of magnitude similar to DNS request/reply traffic; and the encapsulation overhead, while not negligible, is very limited (in the order of few percentage points of the total traffic volume).
Quoitin等人[QIdLB07]表明，在网络级别上，定位器和标识符角色之间的分离通过减小路由信息库（RIB）大小（高达一个数量级）提高了路由可伸缩性，并增加了路径多样性，从而提高了流量工程能力。[IB07]和[KIF13]表明，基于真实的互联网流量跟踪，一个拥有20000个用户的网络的ITR必须处理的映射条目数量限制在数万个；信令业务（即，Map请求/Map应答分组）与DNS请求/应答业务具有相同的数量级；封装开销虽然不可忽略，但非常有限（约占总流量的几个百分点）。
Previous studies consider the case of a timer-based cache eviction policy (i.e., mappings are deleted from the cache upon timeout), while [CDLC] has a more general approach based on the Least Recently Used (LRU) eviction policy, proposing an analytic model for the EID-
先前的研究考虑了基于定时器的高速缓存驱逐策略的情况（即，在超时时从缓存中删除映射），而[CDLC]基于最近最少使用的（LRU）驱逐策略具有更一般的方法，提出了EID的分析模型。
to-RLOC cache size when prefix-level traffic has a stationary generating process. The model shows that miss rate can be accurately predicted from the EID-to-RLOC cache size and a small set of easily measurable traffic parameters. The model was validated using four one-day-long packet traces collected at egress points of a campus network and an academic exchange point considering EID prefixes as being of the same size as BGP prefixes. Consequently, operators can provision the EID-to-RLOC cache of their ITRs according to the miss rate they want to achieve for their given traffic.
当前缀级别的流量具有固定的生成过程时，更改RLOC缓存大小。该模型表明，从EID到RLOC的缓存大小和一小组易于测量的流量参数，可以准确预测未命中率。该模型通过在校园网出口点和学术交换点收集的四个为期一天的数据包跟踪进行了验证，其中考虑到EID前缀与BGP前缀大小相同。因此，运营商可以根据其给定流量想要达到的未命中率，为其ITR的EID到RLOC缓存提供资源。
Results in [CDLC] indicate that for a given target miss ratio, the size of the cache depends only on the parameters of the popularity distribution; the size of the cache is independent of the number of users (the size of the LISP site) and the number of destinations (the size of the EID prefix space). Assuming that the popularity distribution remains constant, this means that as the number of users and the number of destinations grow, the cache size needed to obtain a given miss rate remains constant O(1).
[CDLC]中的结果表明，对于给定的目标未命中率，缓存的大小仅取决于流行度分布的参数；缓存的大小与用户数（LISP站点的大小）和目的地数（EID前缀空间的大小）无关。假设流行度分布保持不变，这意味着随着用户数量和目的地数量的增加，获得给定未命中率所需的缓存大小保持不变O（1）。
LISP usually populates its EID-to-RLOC cache in a pull mode, which means that mappings are retrieved on demand by the ITR. The main advantage of this mode is that the EID-to-RLOC cache size only depends on the traffic characteristics at the ITR and is independent of the size of the provider domain. This benefit comes at the cost of some delay to transmit the packets that do not hit an entry in the cache (for which a mapping has to be learned). This delay is bound by the time necessary to retrieve the mapping from the mapping system. Moreover, similarly to a push model (e.g., BGP), the pull model induces signaling messages that correspond to the retrieval of mappings upon cache miss. The difference being that the signaling load only depends on the traffic at the ITR and is not triggered by external events such as in BGP. [CDLC] shows that the miss rate is a function of the EID-to-RLOC cache size and traffic generation process, and [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in practice, the cache miss rate, and thus the signaling rate, remain low.
LISP通常以拉模式填充其EID到RLOC缓存，这意味着ITR会根据需要检索映射。此模式的主要优点是EID到RLOC缓存大小仅取决于ITR处的流量特征，并且与提供程序域的大小无关。这种好处是以传输未命中缓存中某个条目的数据包（必须学习映射）的延迟为代价的。此延迟受从映射系统检索映射所需的时间限制。此外，与推模型（例如，BGP）类似，拉模型诱导与缓存未命中时的映射检索相对应的信令消息。不同之处在于，信令负载仅取决于ITR的流量，而不是由外部事件（如BGP）触发。[CDLC]显示未命中率是EID到RLOC缓存大小和流量生成过程的函数，[CDLC]、[SDIB08]和[SDIB08]从流量跟踪显示，在实践中，缓存未命中率和信令率保持较低。
LISP is more than just a scalability solution; it is also a tool to provide both incoming and outgoing traffic engineering [S11] [LISP-TE], it can be used as an IPv6 transition at the routing level, and it can be used for inter-domain multicast [RFC6831] [LISP-RE]. Also, LISP has been identified for use to support devices' Internet mobility [LISP-MN] and to support virtual machines' mobility in data centers and multi-tenant VPNs. These last two uses are not discussed further as they are out of the scope of the current LISP Working Group charter.
LISP不仅仅是一个可伸缩性解决方案；它也是一种提供传入和传出流量工程[S11][LISP-TE]的工具，可在路由级别用作IPv6转换，并可用于域间多播[RFC6831][LISP-RE]。此外，LISP已被确定用于支持设备的互联网移动性[LISP-MN]，并支持虚拟机在数据中心和多租户VPN中的移动性。最后两种用法不在当前LISP工作组章程的范围内，因此不作进一步讨论。
A key advantage of the LISP architecture is that it facilitates routing in environments where there is little to no correlation between network endpoints and topological location. In service-provider environments, this application is needed in a range of consumer use cases that require an inline anchor to deliver a service to subscribers. Inline anchors provide one of three types of capabilities:
LISP体系结构的一个关键优势是，它有助于在网络端点和拓扑位置之间几乎没有关联的环境中进行路由。在服务提供商环境中，在一系列需要内联锚向订阅者提供服务的消费者用例中需要此应用程序。内联锚提供三种类型的功能之一：
o enable mobility of subscriber endpoints
o 启用订户端点的移动性
o enable chaining of middlebox functions and services
o 启用中间盒功能和服务的链接
o enable functions to be scaled out seamlessly
o 使功能能够无缝扩展
Without LISP, the approach commonly used by operators is to aggregate service anchors in custom-built boxes. This limits deployments as endpoints can only move on the same mobile gateway, functions can be chained only if traffic traverses the same wire or the same Deep Packet Inspection (DPI) box, and capacity can be scaled out only if traffic fans out to/from a specific load balancer.
如果没有LISP，运营商通常使用的方法是在定制框中聚合服务锚。这限制了部署，因为端点只能在同一个移动网关上移动，功能只能在流量穿过同一条线路或同一个深度数据包检查（DPI）盒时链接，容量只能在流量分散到/从特定负载平衡器时扩展。
With LISP, service providers are able to distribute, virtualize, and instantiate subscriber-service anchors anywhere in the network. Typical use cases for virtualized inline anchors and network functions include Distributed Mobility and Virtualized Evolved Packet Core (vEPC), Virtualized Customer Premise Equipment (vCPE), where functionality previously anchored at a customer premise is now dynamically allocated in the network, Virtualized SGi LAN, Virtual IP Multimedia Subsystems (IMSs), Virtual Session Border Controller (SBC), etc.
使用LISP，服务提供商可以在网络中的任何位置分发、虚拟化和实例化订户服务锚。虚拟化内联锚和网络功能的典型用例包括分布式移动和虚拟化演进包核心（vEPC）、虚拟化客户场所设备（vCPE），其中先前锚定在客户场所的功能现在在网络、虚拟化SGi LAN中动态分配，虚拟IP多媒体子系统（IMS）、虚拟会话边界控制器（SBC）等。
ConteXtream [ConteXtream] has been deploying map-assisted overlay networks since 2006, first with a proprietary solution, then evolving to standard LISP. The solution has been deployed in production in three tier-1 operators spanning hundreds of millions of subscribers. Map-assisted overlays had been primarily used to map subscriber flows to services resources dynamically based on profiles and conditions. Specifically, it has been used to map mobile subscribers to value-added/optimization services, broadband subscribers to telephony services, and fixed-mobile subscribers to Broadband Network Gateway (BNG) functions and Internet access services. The LISP map-assisted overlay architecture is used to optimally resolve subscriber to services, functions, instances, and IP overlay aggregation locations on a per-flow basis and just in time.
ConteXtream[ConteXtream]自2006年以来一直在部署地图辅助覆盖网络，首先使用专有解决方案，然后发展到标准LISP。该解决方案已在三家一级运营商的生产中部署，覆盖数亿用户。地图辅助覆盖主要用于根据配置文件和条件动态地将订户流映射到服务资源。具体而言，它已被用于将移动用户映射到增值/优化服务、宽带用户映射到电话服务、固定移动用户映射到宽带网络网关（BNG）功能和互联网接入服务。LISP map辅助覆盖体系结构用于在每个流的基础上及时优化解决订户到服务、功能、实例和IP覆盖聚合位置的问题。
In the current (non-LISP) routing infrastructure, addresses used by stub networks are globally routable, and the routing system distributes the routes to reach these stubs. With LISP, the EID prefixes of a LISP site are not routable in the DFZ; mappings are needed in order to determine the list of LISP routers to contact to forward packets. This difference is significant for two reasons. First, packets are not forwarded to a site but to a specific router. Second, a site can control the entry points for its traffic by controlling its mappings.
在当前（非LISP）路由基础设施中，存根网络使用的地址是全局可路由的，路由系统分配路由以到达这些存根。使用LISP时，LISP站点的EID前缀不能在DFZ中路由；需要映射来确定要联系以转发数据包的LISP路由器列表。这种差异有两个原因。首先，数据包不会转发到站点，而是转发到特定的路由器。其次，站点可以通过控制其映射来控制其流量的入口点。
For traffic engineering purposes, a mapping associates an EID prefix to a list of RLOCs. Each RLOC is annotated with a priority and a weight. When there are several RLOCs, the ITR selects the one with the highest priority and sends the encapsulated packet to this RLOC. If several RLOCs with the highest priority exist, then the traffic is balanced proportionally to their weight among such RLOCs. Traffic engineering in LISP thus allows the mapping owner to have a fine-grained control on the primary and backup path for its incoming and outgoing packet use. In addition, it can share the load among its links. An example of the use of such a feature is described by Saucez et al. [SDIB08], which shows how to use LISP to direct different types of traffic on different links having different capacity.
出于流量工程目的，映射将EID前缀与RLOC列表相关联。每个RLOC都带有优先级和权重注释。当存在多个RLOC时，ITR选择具有最高优先级的RLOC，并将封装的数据包发送到此RLOC。如果存在多个具有最高优先级的RLOC，则通信量将与其在这些RLOC中的权重成比例地平衡。因此，LISP中的流量工程允许映射所有者对其传入和传出数据包使用的主路径和备份路径进行细粒度控制。此外，它还可以在其链接之间共享负载。Saucez等人[SDIB08]描述了使用这种功能的一个示例，说明了如何使用LISP在具有不同容量的不同链路上引导不同类型的流量。
Traffic engineering in LISP goes one step further, as every Map-Request contains the source EID address of the packet that caused a cache miss and triggered the Map-Request. It is thus possible for a mapping owner to differentiate the answer (Map-Reply) it gives to Map-Requests based on the requester. This functionality is not available today with BGP because a domain cannot control exactly the routes that will be received by domains that are not in the direct neighborhood.
LISP中的流量工程更进一步，因为每个Map请求都包含导致缓存未命中并触发Map请求的数据包的源EID地址。因此，映射所有者可以根据请求者区分它给映射请求的答案（映射回复）。此功能目前在BGP中不可用，因为域无法准确控制不在直接邻居中的域将接收的路由。
The LISP encapsulation mechanism is designed to support any combination of address families for locators and identifiers. It is then possible to bind IPv6 EIDs with IPv4 RLOCs and vice versa. This allows transporting IPv6 packets over an IPv4 network (or IPv4 packets over an IPv6 network), making LISP a valuable mechanism to ease the transition to IPv6.
LISP封装机制旨在支持定位器和标识符的地址族的任意组合。然后可以将IPv6 EID与IPv4 RLOC绑定，反之亦然。这允许通过IPv4网络传输IPv6数据包（或通过IPv6网络传输IPv4数据包），使LISP成为一种有价值的机制，可以简化向IPv6的过渡。
An example is the case of the network infrastructure of a data center being IPv4 only while dual-stack front-end load balancers are used. In this scenario, LISP can be used to provide IPv6 access to servers even though the network and the servers only support IPv4. Assuming
例如，数据中心的网络基础设施仅为IPv4，而使用双堆栈前端负载平衡器。在此场景中，可以使用LISP提供对服务器的IPv6访问，即使网络和服务器仅支持IPv4。假设
that the data center's ISP offers IPv6 connectivity, the data center only needs to deploy one (or more) xTR(s) at its border with the ISP and one (or more) xTR(s) directly connected to the load balancers. The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the load balancer. The load balancer's xTR de-encapsulates the packets and forwards them to the load balancer, which act as a proxy, translating each IPv6 packet into an IPv4 packet. IPv4 packets are then sent to the appropriate servers. Similarly, when the server's response arrives at the load balancer, the packet is translated back into an IPv6 packet and forwarded to its xTR(s), which in turn will tunnel it back, over the IPv4-only infrastructure, to an xTR connected to the ISP. The packet is then de-encapsulated and forwarded to the ISP natively in IPv6.
如果数据中心的ISP提供IPv6连接，则数据中心只需在其与ISP的边界部署一个（或多个）xTR，以及直接连接到负载平衡器的一个（或多个）xTR。ISP边界上的xTR通过IPv4将IPv6数据包传输到直接连接到负载平衡器的xTR。负载平衡器的xTR反封装数据包并将其转发给负载平衡器，负载平衡器充当代理，将每个IPv6数据包转换为IPv4数据包。然后将IPv4数据包发送到相应的服务器。类似地，当服务器的响应到达负载平衡器时，该数据包被转换回IPv6数据包并转发到其xTR，而xTR又将通过仅IPv4的基础设施将其隧道回连接到ISP的xTR。然后，数据包在IPv6中被解除封装并以本机方式转发给ISP。
LISP has native support for multicast [RFC6831]. From the data-plane perspective, at a multicast-enabled xTR, an EID-sourced multicast packet is encapsulated in another multicast packet and subsequently forwarded in an RLOC-level distribution tree. Therefore, xTRs must participate in both EID and RLOC-level distribution trees. Control-plane wise, since group addresses have no topological significance, they need not be mapped. It is worth noting that, to properly function, LISP-Multicast requires that inter-domain multicast be available.
LISP本机支持多播[RFC6831]。从数据平面的角度来看，在启用多播的xTR中，源于EID的多播分组被封装在另一个多播分组中，并随后在RLOC级分发树中转发。因此，XTR必须同时参与EID和RLOC级别的分布树。就控制平面而言，由于组地址没有拓扑意义，因此不需要映射它们。值得注意的是，为了正常工作，LISP多播要求域间多播可用。
LISP Replication Engineering (LISP-RE) [LISP-RE] [CDM12] leverages LISP messages [LISP-MULTI-SIGNALING] for multicast state distribution to construct xTR-based inter-domain multicast distribution trees when inter-domain multicast support is not available. Simulations of three different management strategies for low-latency content delivery show that such overlays can support thousands of member xTRs, support hundreds of thousands of end hosts, and deliver content at latencies close to unicast ones [CDM12]. It was also observed that high client churn has a limited impact on performance and management overhead.
当域间多播支持不可用时，LISP复制工程（LISP-RE）[LISP-RE][CDM12]利用LISP消息[LISP-MULTI-SIGNING]进行多播状态分发，以构造基于xTR的域间多播分发树。对三种不同的低延迟内容交付管理策略的模拟表明，这种覆盖可以支持数千个成员XTR，支持数十万个终端主机，并以接近单播主机的延迟交付内容[CDM12]。还观察到，高客户流失率对性能和管理开销的影响有限。
Similar to LISP-RE, "Signal-Free LISP Multicast" [LISP-SFM] can be used when the core network does not provide multicast support. But instead of using signaling to build inter-domain multicast trees, signal-free exclusively leverages the map server for multicast state storage and distribution. As a result, the source ITR generally performs head-end replication, but it might also be used to emulate LISP-RE distribution trees.
与LISP-RE类似，当核心网络不提供多播支持时，可以使用“无信号LISP多播”[LISP-SFM]。但是，与使用信令构建域间多播树不同，signal free专门利用map服务器进行多播状态存储和分发。因此，源ITR通常执行前端复制，但也可用于模拟LISP-RE分发树。
Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the specifications, and additionally, interoperability tests [Was09] have been successful. A worldwide large deployment in the international lisp4.net testbed, which is currently composed of nodes running at least three different implementations, will allow us to learn further operational aspects related to LISP.
为了评估规范，已经进行了大量的实施工作（[IOSNXOS]、[OpenLISP]、[LISPmob]、[LISPClick]、[LISPcp]和[LISPfritz]），此外，互操作性测试[Was09]也取得了成功。在国际lisp4.net测试床中进行全球范围的大规模部署（目前由运行至少三种不同实现的节点组成）将使我们能够进一步了解与LISP相关的操作方面。
The following sections distinguish the impact of LISP on LISP sites from the impact on non-LISP sites.
以下各节区分LISP对LISP站点的影响和对非LISP站点的影响。
LISP has no impact on traffic that has neither LISP origin nor LISP destination. However, LISP can have a significant impact on traffic between a LISP site and a non-LISP site. Traffic between a non-LISP site and a LISP site is subject to the same issues as those observed for LISP-to-LISP traffic but also has issues specific to the transition mechanism that allow the LISP site to exchange packets with a non-LISP site [RFC6832] [RFC7215].
LISP对既没有LISP来源也没有LISP目的地的流量没有影响。但是，LISP会对LISP站点和非LISP站点之间的通信量产生重大影响。非LISP站点和LISP站点之间的通信会遇到与LISP到LISP通信相同的问题，但也存在特定于转换机制的问题，该转换机制允许LISP站点与非LISP站点交换数据包[RFC6832][RFC7215]。
The transition requires setup of proxy tunnel routers (PxTRs). Proxies cause what is referred to as path stretch (i.e., a lengthening of the path compared to the topological shortest path) and make troubleshooting harder. There are still questions related to PxTRs that need to be answered:
转换需要设置代理隧道路由器（PXTR）。代理导致所谓的路径拉伸（即，与拓扑最短路径相比，路径加长），并使故障排除更加困难。仍有与PXTR相关的问题需要回答：
o Where to deploy PxTRs? The placement in the topology has an important impact on the path stretch.
o 在哪里部署PXTR？拓扑中的放置对路径拉伸有重要影响。
o How many PxTRs? The number of PxTRs has a direct impact on the load and the impact of the failure of a PxTR on the traffic.
o 有多少个PXTR？PxTR的数量直接影响负载以及PxTR故障对流量的影响。
o What part of the EID space? Will all the PxTRs be proxies for the whole EID space, or will it be segmented between different PxTRs?
o EID空间的哪一部分？所有PXTR是整个EID空间的代理，还是在不同的PXTR之间进行分段？
o Who operates PxTRs? An important question to answer is related to the entities that will deploy PxTRs: how will they manage their additional Capital Expenditure (CAPEX) / Operating Expenses (OPEX) associated with PxTRs? How will the traffic be carried with respect to security and privacy?
o 谁操作PXTR？需要回答的一个重要问题与将部署PXTR的实体有关：它们将如何管理与PXTR相关的额外资本支出（CAPEX）/运营支出（OPEX）？在安全和隐私方面，交通将如何进行？
A PxTR will also normally advertise in BGP the EID prefix for which they are proxies. However, if proxies are managed by different entities, they will belong to different ASes. In this case, we need to be sure that this will not cause Multi-Origin AS (MOAS) issues
PxTR通常也会在BGP中公布作为其代理的EID前缀。但是，如果代理由不同的实体管理，则它们将属于不同的ASE。在这种情况下，我们需要确保这不会导致多来源AS（MOA）问题
that could negatively influence routing. Moreover, it is important to ensure that the way EID prefixes will be de-aggregated by the proxies will remain reasonable so as not to contribute to BGP scalability issues.
这可能会对路由产生负面影响。此外，重要的是要确保EID前缀由代理进行反聚合的方式保持合理，以免造成BGP可伸缩性问题。
LISP is a protocol based on the map-and-encap paradigm, which has the positive impacts that we have summarized in the above sections. However, LISP also has impacts on operations:
LISP是一个基于map和encap范式的协议，它具有我们在上述章节中总结的积极影响。然而，LISP也会对运营产生影响：
MTU issue: As LISP uses encapsulation, the MTU is reduced; this has implications on potentially all of the traffic. However, in practice, on the lisp4.net network, no major issue due to the MTU has been observed. This is probably due to the fact that current end-host stacks are well designed to deal with the problem of MTU.
MTU问题：由于LISP使用封装，MTU减少了；这可能会影响所有的流量。然而，在实践中，在lisp4.net网络上，没有观察到MTU引起的重大问题。这可能是因为当前的终端主机堆栈设计良好，能够处理MTU问题。
Resiliency issue: The advantage of flexibility and control offered by the Locator/ID separation comes at the cost of increasing the complexity of the reachability detection. Indeed, identifiers are not directly routable and have to be mapped to locators, but a locator may be unreachable while others are still reachable. This is an important problem for any tunnel-based solution. In the current Internet, packets are forwarded independently of the border router of the network meaning that, in case of the failure of a border router, another one can be used. With LISP, the destination RLOC specifically designates one particular ETR; hence, if this ETR fails, the traffic is dropped, even though other ETRs are available for the destination site. Another resiliency issue is linked to the fact that mappings are learned on demand. When an ITR fails, all its traffic is redirected to other ITRs that might not have the mappings requested by the redirected traffic. Existing studies [SKI12] [SD12] show, based on measurements and traffic traces, that failure of ITRs and RLOC are infrequent but that when such failure happens, a critical number of packets can be dropped. Unfortunately, the current techniques for LISP resiliency, based on monitoring or probing, are not rapid enough (failure recovery on the order of a few seconds). To tackle this issue, [LISP-PRESERVE] and [LISP-ITR-GRACEFUL] propose techniques based on local failure detection and recovery.
弹性问题：定位器/ID分离提供的灵活性和控制的优势是以增加可达性检测的复杂性为代价的。事实上，标识符不能直接路由，必须映射到定位器，但定位器可能无法访问，而其他定位器仍然可以访问。这对于任何基于隧道的解决方案来说都是一个重要问题。在当前的互联网中，数据包的转发独立于网络的边界路由器，这意味着在边界路由器出现故障的情况下，可以使用另一个边界路由器。使用LISP，目标RLOC专门指定一个特定ETR；因此，如果此ETR失败，即使目标站点有其他ETR可用，也会丢弃通信量。另一个弹性问题与映射是按需学习的这一事实有关。当一个ITR失败时，它的所有流量都被重定向到其他可能没有重定向流量请求的映射的ITR。现有研究[SKI12][SD12]表明，基于测量和流量跟踪，ITRs和RLOC的故障很少发生，但当发生此类故障时，可以丢弃临界数量的数据包。不幸的是，当前基于监视或探测的LISP恢复技术不够快速（故障恢复时间仅为几秒钟）。为了解决这个问题，[LISP-PREVICE]和[LISP-ITR-MANAGETE]提出了基于本地故障检测和恢复的技术。
Middleboxes/filters: Because of the increasingly common use of encryption as a response to pervasive monitoring [RFC7258] with LISP providing the option to encrypt traffic between xTRs [LISP-CRYPTO], middleboxes are increasingly likely to be unable to understand encapsulated traffic, which can cause them to drop legitimate packets. In addition, LISP allows triangular or even
中间盒/过滤器：由于加密越来越普遍地用于响应普遍监控[RFC7258]，LISP提供了加密XTR[LISP-CRYPTO]之间通信的选项，因此中间盒越来越可能无法理解封装的通信，这可能会导致它们丢弃合法数据包。此外，LISP还允许三角形或偶数形式
rectangular routing, so it is difficult to maintain a correct state even if the middlebox understands LISP. Finally, filtering may also have problems because they may think only one host is generating the traffic (the ITR), as long as it is not de-encapsulated. To deal with LISP encapsulation, LISP-aware firewalls that inspect inner LISP packets are proposed [lispfirewall].
矩形路由，因此即使中间盒理解LISP，也很难保持正确的状态。最后，过滤也可能有问题，因为他们可能认为只有一个主机在生成流量（ITR），只要它没有被反封装。为了处理LISP封装，提出了检查内部LISP数据包的LISP感知防火墙[lispfirewall]。
Troubleshooting/debugging: The major issue that LISP experimentation has shown is the difficulty of troubleshooting. When there is a problem in the network, it is hard to pinpoint the reason as the operator only has a partial view of the network. The operator can see what is in its EID-to-RLOC cache/database and can try to obtain what is potentially elsewhere by querying the Map Resolvers, but the knowledge remains partial. On top of that, ICMP packets only carry the first few tens of bytes of the original packet, which means that when an ICMP arrives at the ITR, it might not contain enough information to allow correct troubleshooting. Deployment in the beta network has shown that LISP+ALT [RFC6836] was not easy to maintain and control [CCR13], which explains the migration to LISP-DDT [LISP-DDT], based on a massively distributed and hierarchical approach [CCR13].
疑难解答/调试：LISP实验显示的主要问题是疑难解答的难度。当网络出现问题时，很难查明原因，因为运营商对网络只有部分了解。操作员可以查看其EID到RLOC缓存/数据库中的内容，并可以通过查询映射解析程序尝试获取其他地方可能存在的内容，但知识仍然是部分的。除此之外，ICMP数据包只携带原始数据包的前几十个字节，这意味着当ICMP到达ITR时，它可能不包含足够的信息，无法进行正确的故障排除。beta网络中的部署表明LISP+ALT[RFC6836]不易维护和控制[CCR13]，这解释了基于大规模分布式和分层方法[CCR13]向LISP-DDT[LISP-DDT]的迁移。
Business/operational related: Iannone et al. [IL10] have shown that there are economical incentives to migrate to LISP; however, some questions remain. For example, how will the EIDs be allocated to allow aggregation and hence scalability of the mapping system? Who will operate the mapping system infrastructure and for what benefits? What if several operators run different mapping systems? How will they interoperate or share mapping information?
业务/运营相关：Iannone等人[IL10]表明，迁移到LISP有经济激励；然而，仍然存在一些问题。例如，如何分配EID以允许聚合，从而实现映射系统的可伸缩性？谁将运营测绘系统基础设施？有哪些好处？如果几个操作员运行不同的映射系统会怎么样？他们将如何互操作或共享映射信息？
Reachability: The overhead related to RLOC reachability mechanisms is not known.
可达性：与RLOC可达性机制相关的开销未知。
A thorough security and threat analysis of LISP is carried out in detail in [RFC7835]. For LISP and other Internet technologies, most of the threats can be mitigated using Best Current Practices, meaning with careful deployment and configuration (e.g., filter), by activating only features that are really necessary in the deployment, and by verifying all the information obtained from third parties. Unless gleaning (Section 6 of [RFC6830] and Section 3.1 of [RFC7835]) features are used, the LISP data plane shows the same level of security as other IP-over-IP technologies. From a security perspective, the control plane remains the critical part of the LISP architecture. To mitigate the threats on the mapping system, authentication should be used for all control-plane messages. The
[RFC7835]对LISP进行了全面的安全和威胁分析。对于LISP和其他互联网技术，大多数威胁都可以使用当前最佳实践来缓解，这意味着通过谨慎的部署和配置（如过滤器），只激活部署中真正需要的功能，并验证从第三方获得的所有信息。除非使用了收集（RFC6830第6节和RFC7835第3.1节）功能，否则LISP数据平面显示的安全级别与其他IP over IP技术相同。从安全角度来看，控制平面仍然是LISP体系结构的关键部分。为了减轻映射系统上的威胁，应对所有控制平面消息使用身份验证。这个
current specification defines security mechanisms [RFC6836] [LISP-SEC] that can reduce threats in open network environments. The LISP specification defines a generic authentication data field for control-plane messages [RFC6836], which could be used for a general authentication mechanism for the LISP control plane while staying backward compatible.
当前规范定义了可减少开放网络环境中威胁的安全机制[RFC6836][LISP-SEC]。LISP规范为控制平面消息[RFC6836]定义了通用身份验证数据字段，该字段可用于LISP控制平面的通用身份验证机制，同时保持向后兼容。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，DOI 10.17487/RFC6830，2013年1月<http://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <http://www.rfc-editor.org/info/rfc6831>.
[RFC6831]Farinaci，D.，Meyer，D.，Zwiebel，J.，和S.Venaas，“用于多播环境的定位器/ID分离协议（LISP）”，RFC 6831，DOI 10.17487/RFC6831，2013年1月<http://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <http://www.rfc-editor.org/info/rfc6832>.
[RFC6832]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“定位器/ID分离协议（LISP）和非LISP站点之间的互通”，RFC 6832，DOI 10.17487/RFC6832，2013年1月<http://www.rfc-editor.org/info/rfc6832>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <http://www.rfc-editor.org/info/rfc6833>.
[RFC6833]Fuller，V.和D.Farinaci，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，DOI 10.17487/RFC6833，2013年1月<http://www.rfc-editor.org/info/rfc6833>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, <http://www.rfc-editor.org/info/rfc6834>.
[RFC6834]Iannone，L.，Saucez，D.，和O.Bonaventure，“定位器/ID分离协议（LISP）地图版本控制”，RFC 6834，DOI 10.17487/RFC6834，2013年1月<http://www.rfc-editor.org/info/rfc6834>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC6836]Fuller，V.，Farinaci，D.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 6836，DOI 10.17487/RFC6836，2013年1月<http://www.rfc-editor.org/info/rfc6836>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <http://www.rfc-editor.org/info/rfc7215>.
[RFC7215]Jakab，L.，Cabellos Aparicio，A.，Coras，F.，Domingo Pascual，J.，和D.Lewis，“定位器/标识符分离协议（LISP）网元部署注意事项”，RFC 7215，DOI 10.17487/RFC7215，2014年4月<http://www.rfc-editor.org/info/rfc7215>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <http://www.rfc-editor.org/info/rfc7835>.
[RFC7835]Saucez，D.，Iannone，L.，和O.Bonaventure，“定位器/身份分离协议（LISP）威胁分析”，RFC 7835，DOI 10.17487/RFC7835，2016年4月<http://www.rfc-editor.org/info/rfc7835>.
[CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First Measurement Look at the Deployment and Evolution of the Locator/ID Separation Protocol", ACM SIGCOMM Computer Communication Review, Vol. 43, Issue 2, pp. 37-43, DOI 10.1145/2479957.2479963, April 2013.
[CCR13]Saucez，D.，Iannone，L.，和B.Donnet，“定位器/ID分离协议部署和演变的第一次测量研究”，ACM SIGCOMM计算机通信评论，第43卷，第2期，第37-43页，DOI 10.1145/2479957.2479963，2013年4月。
[CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An Analytical Model for Loc/ID Mappings Caches", IEEE/ACM Transactions on Networking, Vol. 24, Issue 1, pp. 506-516, DOI 10.1109/TNET.2014.2373398, February 2014.
[CDLC]Coras，F.，Domingo，J.，Lewis，D.，和A.Cabellos，“Loc/ID映射缓存的分析模型”，IEEE/ACM网络交易，第24卷，第1期，第506-516页，DOI 10.1109/TNET.2014.2373398，2014年2月。
[CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-Domain Multicast", Computer Networks, Vol. 59, pp. 153-170, DOI 10.1016/j.bjp.2013.10.010, February 2014.
[CDM12]Coras，F.，Domingo Pascual，J.，Maino，F.，Farinaci，D.，和A.Cabellos Aparicio，“Lcast：软件定义的域间多播”，计算机网络，第59卷，第153-170页，DOI 10.1016/J.bjp.2013.10.010，2014年2月。
[ConteXtream] ConteXtream Software Company, , "SDN and NFV solutions for carrier networks. (Further details on LISP only through private inquiry.)", <http://www.contextream.com>.
[ConteXtream]ConteXtream软件公司，“运营商网络的SDN和NFV解决方案（仅通过私人查询了解LISP的更多详细信息）。”<http://www.contextream.com>.
[IB07] Iannone, L. and O. Bonaventure, "On the cost of caching locator/ID mappings", in Proceedings of ACM CoNEXT 2007, DOI 0.1145/1364654.1364663, December 2007.
[IB07]Ianone，L.和O.Bonaventure，“缓存定位器/ID映射的成本”，载于ACM CoNEXT 2007年会议记录，DOI 0.1145/1364654.13646632007年12月。
[IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID Split for the Future Internet", IOS Press, pp. 11-20, DOI 10.3233/978-1-60750-539-6-11, May 2010.
[IL10]Iannone，L.和T.Leva，“为未来互联网建模Loc/ID拆分的经济性”，IOS出版社，第11-20页，DOI 10.3233/978-1-60750-539-6-11，2010年5月。
[IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol (LISP)", 2015, <http://lisp4.cisco.com>.
[IOSNXS]思科系统公司，“定位器/ID分离协议（LISP）”，2015年<http://lisp4.cisco.com>.
[KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID mappings: An experimental scalability analysis and its implications", Computer Networks, Vol. 57, Issue 4, DOI 10.1016/j.comnet.2012.11.007, March 2013.
[KIF13]Kim，J.，Iannone，L.，和A.Feldmann，“缓存定位器/ID映射：实验性可伸缩性分析及其影响”，计算机网络，第57卷，第4期，DOI 10.1016/J.comnet.2012.11.007，2013年3月。
[LISP-CRYPTO] Farinacci, D. and B. Weis, "LISP Data-Plane Confidentiality", Work in Progress, draft-ietf-lisp-crypto-03, September 2015.
[LISP-CRYPTO]Farinaci，D.和B.Weis，“LISP数据平面机密性”，正在进行的工作，草案-ietf-LISP-CRYPTO-032015年9月。
[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-03, April 2015.
[LISP-DDT]Fuller，V.，Lewis，D.，Ermagan，V.，和A.Jain，“LISP委托数据库树”，正在进行的工作，草案-ietf-LISP-DDT-032015年4月。
[LISP-ITR-GRACEFUL] Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, "LISP ITR Graceful Restart", Work in Progress, draft-saucez-lisp-itr-graceful-03, December 2013.
[LISP-ITR-MANAGETE]Saucez，D.，Bonaventure，O.，Iannone，L.，和C.Filsfils，“LISP-ITR优雅重启”，正在进行的工作，草稿-Saucez-LISP-ITR-MANAGETE-032013年12月。
[LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, draft-ietf-lisp-lcaf-12, September 2015.
[LISP-LCAF]Farinaci，D.，Meyer，D.，和J.Snijders，“LISP规范地址格式（LCAF）”，正在进行的工作，草稿-ietf-LISP-LCAF-12，2015年9月。
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, draft-meyer-lisp-mn-14, July 2015.
[LISP-MN]Farinaci，D.，Lewis，D.，Meyer，D.，和C.White，“LISP移动节点”，正在进行中的工作，草稿-Meyer-LISP-MN-142015年7月。
[LISP-MULTI-SIGNALING] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", Work in Progress, draft-farinacci-lisp-mr-signaling-06, February 2015.
[LISP-MULTI-SIGNALING]Farinaci，D.和M.Napierala，“LISP控制平面多播信令”，正在进行的工作，draft-Farinaci-LISP-mr-SIGNALING-062015年2月。
[LISP-PRESERVE] Bonaventure, O., Francois, P., and D. Saucez, "Preserving the reachability of LISP ETRs in case of failures", Work in Progress, draft-bonaventure-lisp-preserve-00, July 2009.
[LISP-PRESERVE]Bonaventure，O.，Francois，P.，和D.Saucez，“在发生故障时保持LISP ETR的可达性”，正在进行的工作，草稿-Bonaventure-LISP-PRESERVE-00，2009年7月。
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015.
[LISP-RE]Coras，F.，Cabellos Aparicio，A.，Domingo Pascual，J.，Maino，F.，和D.Farinaci，“LISP复制工程”，在建工程，草稿-Coras-LISP-RE-082015年11月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-10, October 2015.
[LISP-SEC]Maino，F.，Ermagan，V.，Cabellos Aparicio，A.，和D.Saucez，“LISP安全（LISP-SEC）”，正在进行的工作，草案-ietf-LISP-SEC-10，2015年10月。
[LISP-SFM] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Work in Progress, draft-ietf-lisp-signal-free-multicast-01, April 2016.
[LISP-SFM]Moreno，V.和D.Farinaci，“无信号LISP多播”，正在进行的工作，草案-ietf-LISP-Signal-Free-Multicast-01，2016年4月。
[LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", Work in Progress, draft-farinacci-lisp-te-10, September 2015.
[LISP-TE]Farinaci，D.，Kowal，M.，和P.Lahiri，“LISP交通工程用例”，在建工程，草稿-Farinaci-LISP-TE-10，2015年9月。
[LISPClick] Saucez, D. and V. Nguyen, "LISP-Click: A Click implementation of the Locator/ID Separation Protocol", 1st Symposium on Click Modular Router, November 2009, <http://hdl.handle.net/2078.1/79067>.
[LISPClick]Saucez，D.和V.Nguyen，“LISP Click:Locator/ID分离协议的Click实现”，第一届Click模块化路由器研讨会，2009年11月<http://hdl.handle.net/2078.1/79067>.
[LISPcp] "LIP6-LISP open source project", 2014, <https://github.com/lip6-lisp>.
[LISPcp]“LIP6-LISP开源项目”，2014年<https://github.com/lip6-lisp>.
[lispfirewall] "LISP and Zone-Based Firewalls Integration and Interoperability", 2014, <http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/ sec-zbf-lisp-inner-pac-insp.html>.
[lispfirewall]“LISP和基于区域的防火墙集成和互操作性”，2014年<http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ sec_data_zbf/configuration/xe-3s/sec data zbf xe book/sec zbf lisp internal pac insp.html>。
[LISPfritz] "Unsere FRITZ!Box-Produkte", 2014, <http://avm.de/produkte/fritzbox/>.
[LISPfritz]“不安全的FRITZ！盒子产品”，2014年<http://avm.de/produkte/fritzbox/>.
[LISPmob] "An open-source LISP implementation for Linux, Android and OpenWRT", 2015, <http://lispmob.org>.
[LISPmob]“Linux、Android和OpenWRT的开源LISP实现”，2015年<http://lispmob.org>.
[OpenLISP] "The OpenLISP Project", 2013, <http://www.openlisp.org>.
[OpenLISP]“OpenLISP项目”，2013年<http://www.openlisp.org>.
[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/ Identifier Separation", in Proceedings of MobiArch, Article No. 5, DOI 10.1145/1366919.1366926, August 2007.
[QIdLB07]Quoitin，B.，Iannone，L.，de Launois，C.，和O.Bonaventure，“评估定位器/标识符分离的好处”，MobiArch会议记录，第5条，DOI 10.1145/1366919.1366926，2007年8月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, <http://www.rfc-editor.org/info/rfc4984>.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“来自IAB路由和寻址研讨会的报告”，RFC 4984，DOI 10.17487/RFC49842007年9月<http://www.rfc-editor.org/info/rfc4984>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[S11] Saucez, D., "Mechanisms for Interdomain Traffic Engineering with LISP", PhD Thesis, Universite catholique de Louvain, September 2011, <http://hdl.handle.net/2078.1/92231>.
[S11]Saucez，D.“LISP域间流量工程机制”，卢旺天主教大学博士论文，2011年9月<http://hdl.handle.net/2078.1/92231>.
[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in LISP", in Proceedings of IFIP/TC6 Networking, pp. 385-396, DOI 10.1007/978-3-642-30045-5_29, May 2012.
[SD12]Saucez，D.和B.Donnet，“关于LISP中定位器的动态”，载于IFIP/TC6网络会议录，第385-396页，DOI 10.1007/978-3-642-30045-529，2012年5月。
[SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, "Interdomain Traffic Engineering in a Locator/Identifier Separation Context", in Proceedings of Internet Network Management Workshop, DOI 10.1109/INETMW.2008.4660330, October 2008.
[SDIB08]Saucez，D.，Donnet，B.，Iannone，L.，和O.Bonaventure，“定位符/标识符分离上下文中的域间流量工程”，互联网网络管理研讨会论文集，DOI 10.1109/INETMW.2008.46603302008年10月。
[SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. Filsfils, "A Local Approach to Fast Failure Recovery of LISP Ingress Tunnel Routers", in Proceedings of IFIP Networking 2012, pp. 397-408, DOI 10.1007/978-3-642-30045-5_30, May 2012.
[SKI12]Saucez，D.，Kim，J.，Iannone，L.，Bonaventure，O.，和C.Filsfils，“LISP入口隧道路由器快速故障恢复的本地方法”，载于IFIP Networking 2012，第397-408页，DOI 10.1007/978-3-642-30045-5_30，2012年5月。
[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, LISP WG Presentation, November 2009.
[Was09]Wasserman，M.，“LISP互操作性测试”，IETF 76，LISP工作组演示，2009年11月。
Acknowledgments
致谢
Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen Farrel, Wassim Haddad, Kathleen Moriarty, and Hilarie Orman for their thorough reviews, comments, and suggestions.
感谢Deborah Brungard、Ben Campbell、Spencer Dawkins、Stephen Farrel、Wassim Haddad、Kathleen Moriarty和Hilarie Orman的全面审查、评论和建议。
The people that contributed to this document are Alia Atlas, Sharon Barkai, Ron Bonica, Ross Callon, Vince Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel.
对本文件作出贡献的人有Alia Atlas、Sharon Barkai、Ron Bonica、Ross Callon、Vince Fuller、Joel Halpern、Terry Manderson和Gregg Schudel。
The work of Luigi Iannone has been partially supported by the ANR 13 INFR 0009 LISP-Lab Project <http://www.lisp-lab.org>.
Luigi Iannone的工作得到了ANR 13 INFR 0009 LISP实验室项目的部分支持<http://www.lisp-lab.org>.
Authors' Addresses
作者地址
Damien Saucez INRIA 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France
Damien Saucez INRIA 2004 Lucioles路线BP 93 06902 Sophia Antipolis Cedex法国
Email: damien.saucez@inria.fr
Email: damien.saucez@inria.fr
Luigi Iannone Telecom ParisTech 23, Avenue d'Italie, CS 51327 75214 Paris Cedex 13 France
路易吉·伊安诺电信巴黎公司，意大利大道23号，CS 51327 75214巴黎Cedex 13法国
Email: ggx@gigix.net
Email: ggx@gigix.net
Albert Cabellos Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain
加泰罗尼亚艾伯特CabelLOS技术大学C /霍尔迪赫罗纳，S/N 08034西班牙巴塞罗那
Email: acabello@ac.upc.edu
Email: acabello@ac.upc.edu
Florin Coras Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain
加泰罗尼亚佛罗林科拉斯技术大学C／霍尔迪赫罗纳，S/N 08034西班牙巴塞罗那
Email: fcoras@ac.upc.edu
Email: fcoras@ac.upc.edu