Internet Engineering Task Force (IETF) L. Jakab
Request for Comments: 7215 Cisco Systems
Category: Experimental A. Cabellos-Aparicio
ISSN: 2070-1721 F. Coras
J. Domingo-Pascual
Technical University of Catalonia
D. Lewis
Cisco Systems
April 2014
Internet Engineering Task Force (IETF) L. Jakab
Request for Comments: 7215 Cisco Systems
Category: Experimental A. Cabellos-Aparicio
ISSN: 2070-1721 F. Coras
J. Domingo-Pascual
Technical University of Catalonia
D. Lewis
Cisco Systems
April 2014
Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
定位器/标识符分离协议（LISP）网元部署注意事项
Abstract
摘要
This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.
本文档是不同定位器/标识符分离协议（LISP）部署场景的快照。它讨论了协议引入的新网络元素的位置，代表了LISP工作组截至2013年夏季的想法。从那时起，LISP部署场景可能已经发生了变化。这份备忘录代表了这种理解演变的一个稳定点。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc7215.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7215.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Tunnel Routers ..................................................5
2.1. Deployment Scenarios .......................................5
2.1.1. Customer Edge (CE) ..................................5
2.1.2. Provider Edge (PE) ..................................6
2.1.3. Tunnel Routers behind NAT ...........................8
2.1.3.1. ITR ........................................8
2.1.3.2. ETR ........................................9
2.1.3.3. Additional Notes ...........................9
2.2. Functional Models with Tunnel Routers ......................9
2.2.1. Split ITR/ETR .......................................9
2.2.2. Inter-Service-Provider Traffic Engineering .........11
2.3. Summary and Feature Matrix ................................13
3. Map-Servers and Map-Resolvers ..................................14
3.1. Map-Servers ...............................................14
3.2. Map-Resolvers .............................................16
4. Proxy Tunnel Routers ...........................................17
4.1. PITRs .....................................................17
4.2. PETRs .....................................................18
5. Migration to LISP ..............................................19
5.1. LISP+BGP ..................................................19
5.2. Mapping Service Provider (MSP) PITR Service ...............20
5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20
5.4. Migration Summary .........................................23
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................24
Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26
A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26
A.2. Customer Activating LISP Service ...........................28
A.3. Cut-Over Provider Preparation and Changes ..................29
1. Introduction ....................................................3
2. Tunnel Routers ..................................................5
2.1. Deployment Scenarios .......................................5
2.1.1. Customer Edge (CE) ..................................5
2.1.2. Provider Edge (PE) ..................................6
2.1.3. Tunnel Routers behind NAT ...........................8
2.1.3.1. ITR ........................................8
2.1.3.2. ETR ........................................9
2.1.3.3. Additional Notes ...........................9
2.2. Functional Models with Tunnel Routers ......................9
2.2.1. Split ITR/ETR .......................................9
2.2.2. Inter-Service-Provider Traffic Engineering .........11
2.3. Summary and Feature Matrix ................................13
3. Map-Servers and Map-Resolvers ..................................14
3.1. Map-Servers ...............................................14
3.2. Map-Resolvers .............................................16
4. Proxy Tunnel Routers ...........................................17
4.1. PITRs .....................................................17
4.2. PETRs .....................................................18
5. Migration to LISP ..............................................19
5.1. LISP+BGP ..................................................19
5.2. Mapping Service Provider (MSP) PITR Service ...............20
5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20
5.4. Migration Summary .........................................23
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................24
Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26
A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26
A.2. Customer Activating LISP Service ...........................28
A.3. Cut-Over Provider Preparation and Changes ..................29
The Locator/Identifier Separation Protocol (LISP) is designed to address the scaling issues of the global Internet routing system identified in [RFC4984] by separating the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The main protocol specification [RFC6830] describes how the separation is achieved and which new network elements are introduced, and it details the packet formats for the data and control planes.
定位器/标识符分离协议（LISP）旨在通过将当前寻址方案分离为端点标识符（EID）和路由定位器（RLOC）来解决[RFC4984]中确定的全球互联网路由系统的扩展问题。主协议规范[RFC6830]描述了如何实现分离以及引入了哪些新的网络元素，并详细说明了数据和控制平面的数据包格式。
LISP assumes that such separation is between the edge and core and uses mapping and encapsulation for forwarding. While the boundary between both is not strictly defined, one widely accepted definition places it at the border routers of stub autonomous systems, which may carry a partial or complete default-free zone (DFZ) routing table. The initial design of LISP took this location as a baseline for protocol development. However, the applications of LISP go beyond just decreasing the size of the DFZ routing table and include improved multihoming and ingress traffic engineering (TE) support for edge networks, and even individual hosts. Throughout this document, we will use the term "LISP site" to refer to these networks/hosts behind a LISP Tunnel Router. We formally define the following two terms:
LISP假设这种分离在边缘和核心之间，并使用映射和封装进行转发。虽然两者之间的边界没有严格定义，但一个广泛接受的定义将其放在存根自治系统的边界路由器上，存根自治系统可能携带部分或完整的无缺省区（DFZ）路由表。LISP的初始设计将此位置作为协议开发的基线。然而，LISP的应用不仅仅是减小DFZ路由表的大小，还包括改进的对边缘网络甚至单个主机的多归属和入口流量工程（TE）支持。在本文档中，我们将使用术语“LISP站点”来指LISP隧道路由器后面的这些网络/主机。我们正式定义了以下两个术语：
Network element: Facility or equipment used in the provision of a communications service over the Internet [TELCO96].
网元：用于通过互联网提供通信服务的设施或设备[TELCO96]。
LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s).
LISP站点：边缘网络中由单个组织管理控制的单个主机或一组网元，由LISP隧道路由器与其他网络分隔。
Since LISP is a protocol that can be used for different purposes, it is important to identify possible deployment scenarios and the additional requirements they may impose on the protocol specification and other protocols. Additionally, this document is intended as a guide for the operational community for LISP deployments in their networks. It is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered.
由于LISP是一种可用于不同目的的协议，因此确定可能的部署场景以及它们可能对协议规范和其他协议施加的附加要求非常重要。此外，本文档旨在为运营社区在其网络中部署LISP提供指南。预计它将随着LISP部署的进展而发展，并且更好地理解所描述的场景或发现新的场景。
Each subsection considers an element type and discusses the impact of deployment scenarios on the protocol specification. For definitions of terms, please refer to the appropriate documents (as cited in the respective sections).
每一小节考虑一种元素类型，并讨论部署场景对协议规范的影响。有关术语的定义，请参考相应的文件（如各章节所引用）。
This experimental document describes deployment considerations. These considerations and the LISP specifications have areas that require additional experience and measurement. LISP is not recommended for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of LISP mechanisms. Additionally, at the time of this writing there is no standardized security to implement. Beware that there are no countermeasures for any of the threats identified in [LISP-THREATS]. See Section 15 of [RFC6830] for specific known issues that are in need of further work during development, implementation, and experimentation, and see [LISP-THREATS] for recommendations to ameliorate the above-mentioned security threats.
本实验性文档描述了部署注意事项。这些注意事项和LISP规范都有需要额外经验和测量的方面。LISP不建议用于实验环境以外的部署。实验结果可能会导致LISP机制的修改和增强。此外，在撰写本文时，还没有要实现的标准化安全性。请注意，对于[LISP-threats]中确定的任何威胁，都没有应对措施。在开发、实施和实验过程中需要进一步研究的特定已知问题，请参见[RFC6830]第15节，改善上述安全威胁的建议，请参见[LISP-THREATS]。
The device that is the gateway between the edge and the core is called a Tunnel Router (xTR); it performs one or both of two separate functions:
作为边缘和核心之间的网关的设备称为隧道路由器（xTR）；它执行两个单独功能中的一个或两个：
1. Encapsulating packets originating from an end host to be transported over intermediary (transit) networks towards the other endpoint of the communication.
1. 封装来自终端主机的数据包，通过中间（传输）网络传输到通信的另一个端点。
2. Decapsulating packets entering from intermediary (transit) networks, originated at a remote end host.
2. 从中间（传输）网络进入的、源自远程终端主机的解封装数据包。
The first function is performed by an Ingress Tunnel Router (ITR) and the second by an Egress Tunnel Router (ETR).
第一个功能由入口隧道路由器（ITR）执行，第二个功能由出口隧道路由器（ETR）执行。
Section 8 of the main LISP specification [RFC6830] has a short discussion of where Tunnel Routers can be deployed and some of the associated advantages and disadvantages. This section adds more detail to the scenarios presented there and provides additional scenarios as well. Furthermore, this section discusses functional models, that is, network functions that can be achieved by deploying Tunnel Routers in specific ways.
主要LISP规范[RFC6830]的第8节简要讨论了可以在何处部署隧道路由器以及一些相关的优缺点。本节为此处介绍的场景添加了更多细节，并提供了其他场景。此外，本节还讨论了功能模型，即可以通过以特定方式部署隧道路由器来实现的网络功能。
The first scenario we discuss is the customer edge, when xTR functionality is placed on the router(s) that connects the LISP site to its upstream(s) but is under its control. As such, this is the most common expected scenario for xTRs, and this document considers it the reference location, comparing the other scenarios to this one.
我们讨论的第一个场景是客户边缘，当xTR功能放置在将LISP站点连接到其上游但受其控制的路由器上时。因此，这是XTR最常见的预期场景，本文将其视为参考位置，并将其他场景与此场景进行比较。
ISP1 ISP2
| |
| |
+----+ +----+
+--|xTR1|--|xTR2|--+
| +----+ +----+ |
| |
| LISP site |
+------------------+
ISP1 ISP2
| |
| |
+----+ +----+
+--|xTR1|--|xTR2|--+
| +----+ +----+ |
| |
| LISP site |
+------------------+
Figure 1: xTRs at the Customer Edge
图1：客户边缘的XTR
From the LISP site's perspective, the main advantage of this type of deployment (compared to the one described in the next section) is having direct control over its ingress traffic engineering. This makes it easy to set up and maintain active/active, active/backup, or more complex TE policies, adding ISPs and additional xTRs at will, without involving third parties.
从LISP站点的角度来看，这种部署（与下一节中描述的部署相比）的主要优点是可以直接控制其入口流量工程。这使得设置和维护主动/主动、主动/备份或更复杂的TE策略变得容易，可以随意添加ISP和其他XTR，而无需涉及第三方。
Being under the same administrative control, reachability information of all ETRs is easier to synchronize, because the necessary control traffic can be allowed between the locators of the ETRs. A correct synchronous global view of the reachability status is thus available, and the Locator-Status-Bits can be set correctly in the LISP data header of outgoing packets.
在相同的管理控制下，所有ETR的可达性信息更容易同步，因为ETR的定位器之间可以允许必要的控制流量。因此，可以获得可达性状态的正确同步全局视图，并且可以在传出数据包的LISP数据头中正确设置定位器状态位。
By placing the Tunnel Router at the edge of the site, existing internal network configuration does not need to be modified. Firewall rules, router configurations, and address assignments inside the LISP site remain unchanged. This helps with incremental deployment and allows a quick upgrade path to LISP. For larger sites distributed in geographically diverse points of presence (PoPs) and having many external connections and complex internal topology, it may, however, make more sense to both encapsulate and decapsulate as soon as possible, to benefit from the information in the IGP to choose the best path. See Section 2.2.1 for a discussion of this scenario.
通过将隧道路由器放置在站点边缘，不需要修改现有的内部网络配置。LISP站点内的防火墙规则、路由器配置和地址分配保持不变。这有助于增量部署，并允许快速升级到LISP。然而，对于分布在不同地理位置的存在点（POP）中且具有许多外部连接和复杂内部拓扑的较大站点，尽快封装和去封装可能更有意义，以便从IGP中的信息中获益，从而选择最佳路径。有关此场景的讨论，请参见第2.2.1节。
Another thing to consider when placing Tunnel Routers is MTU issues. Encapsulation increases the amount of overhead associated with each packet. This added overhead decreases the effective end-to-end path MTU (unless fragmentation and reassembly are used). Some transit networks are known to provide larger MTU values than the typical value of 1500 bytes for popular access technologies used at end hosts (e.g., IEEE 802.3 and 802.11). However, placing the LISP router connecting to such a network at the customer edge could possibly bring up MTU issues, depending on the link type to the provider as opposed to the following scenario. See [RFC4459] for MTU considerations of tunneling protocols and how to mitigate potential issues. Still, even with these mitigations, path MTU issues are still possible.
放置隧道路由器时要考虑的另一件事是MTU问题。封装增加了与每个数据包相关的开销。这增加的开销减少了有效的端到端路径MTU（除非使用分段和重新组装）。已知一些传输网络提供的MTU值大于终端主机（如IEEE 802.3和802.11）使用的常用接入技术的典型值1500字节。但是，将LISP路由器连接到客户边缘的此类网络可能会带来MTU问题，这取决于与提供商的链接类型，而不是以下情况。有关隧道协议的MTU注意事项以及如何缓解潜在问题，请参见[RFC4459]。尽管如此，即使采取了这些缓解措施，path MTU问题仍然是可能的。
The other location at the core-edge boundary for deploying LISP routers is at the Internet service provider edge. The main incentive for this case is that the customer does not have to upgrade the CE router(s) or change the configuration of any equipment. Encapsulation/decapsulation happens in the provider's network, which may be able to serve several customers with a single device. For
用于部署LISP路由器的核心边缘边界的另一个位置位于Internet服务提供商边缘。这种情况的主要诱因是客户不必升级CE路由器或更改任何设备的配置。封装/去封装发生在提供商的网络中，该网络可能能够使用单个设备为多个客户提供服务。对于
large ISPs with many residential/business customers asking for LISP, this can lead to important savings, since there is no need to upgrade the software (or hardware, if that's the case) at each client's location. Instead, they can upgrade the software (or hardware) on a few PE routers serving the customers. This scenario is depicted in Figure 2.
大型ISP有许多住宅/商业客户要求LISP，这可以节省大量成本，因为不需要在每个客户的位置升级软件（或硬件，如果是这样的话）。相反，他们可以升级为客户服务的一些PE路由器上的软件（或硬件）。此场景如图2所示。
+----------+ +------------------+
| ISP1 | | ISP2 |
| | | |
| +----+ | | +----+ +----+ |
+--|xTR1|--+ +--|xTR2|--|xTR3|--+
+----+ +----+ +----+
| | |
| | |
+--<[LISP site]>---+-------+
+----------+ +------------------+
| ISP1 | | ISP2 |
| | | |
| +----+ | | +----+ +----+ |
+--|xTR1|--+ +--|xTR2|--|xTR3|--+
+----+ +----+ +----+
| | |
| | |
+--<[LISP site]>---+-------+
Figure 2: xTRs at the Provider Edge
图2：提供者边缘的XTR
While this approach can make transition easy for customers and may be cheaper for providers, the LISP site loses one of the main benefits of LISP: ingress traffic engineering. Since the provider controls the ETRs, additional complexity would be needed to allow customers to modify their mapping entries.
虽然这种方法可以让客户更容易地进行转换，而且对提供商来说可能更便宜，但LISP站点失去了LISP的一个主要好处：入口流量工程。由于提供程序控制ETR，因此需要额外的复杂性来允许客户修改其映射条目。
The problem is aggravated when the LISP site is multihomed. Consider the scenario in Figure 2: whenever a change to TE policies is required, the customer contacts both ISP1 and ISP2 to make the necessary changes on the routers (if they provide this possibility). It is, however, unlikely that both ISPs will apply changes simultaneously, which may lead to inconsistent state for the mappings of the LISP site. Since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, to either attract all the traffic or get no traffic. The former will happen if the customer pays per volume, the latter if the connectivity has a fixed price. A solution could be to configure the Map-Server(s) to do proxy-replying and have the Mapping Service Provider (MSP) apply policies.
当LISP站点是多宿主的时，问题就更加严重了。考虑图2中的场景：每当需要更改TE策略时，客户都联系ISP1和ISP2，以便在路由器上进行必要的更改（如果它们提供了这种可能性）。但是，两个ISP不太可能同时应用更改，这可能导致LISP站点映射的状态不一致。由于不同的上游ISP通常是相互竞争的商业实体，ETR甚至可以配置为相互竞争，以吸引所有流量或不获得流量。前者发生在客户按容量付费的情况下，后者发生在连接具有固定价格的情况下。解决方案可以是将映射服务器配置为执行代理应答，并让映射服务提供商（MSP）应用策略。
Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, making it difficult to set the Locator-Status-Bits (LSBs) correctly on encapsulated packets. Because of this, and due to the security concerns about LSBs as described in [LISP-THREATS], their use is discouraged (set the L-bit to 0). Map-Versioning is another alternative [RFC6834].
此外，由于xTR1、xTR2和xTR3位于不同的管理域中，定位器可达性信息不太可能在它们之间交换，这使得很难在封装的数据包上正确设置定位器状态位（lsb）。因此，由于[LISP-THREATS]中描述的LSB的安全问题，不鼓励使用它们（将L位设置为0）。地图版本控制是另一种选择[RFC6834]。
Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the Tunnel Router is closer to the core, where links typically have higher MTUs than edge network links.
与客户边缘场景相比，在提供商边缘部署LISP可能具有减少潜在MTU问题的优势，因为隧道路由器更靠近核心，其中链路的MTU通常高于边缘网络链路。
"NAT" in this section refers to IPv4 network address and port translation.
本节中的“NAT”指IPv4网络地址和端口转换。
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ITR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ITR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 3: ITR behind NAT
图3:NAT后面的ITR
Packets encapsulated by an ITR are just UDP packets from a NAT device's point of view, and they are handled like any UDP packet; there are no additional requirements for LISP data packets.
从NAT设备的角度来看，ITR封装的数据包只是UDP数据包，它们的处理方式与任何UDP数据包一样；对于LISP数据包没有其他要求。
Map-Requests sent by an ITR, which create the state in the NAT table, have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of this packet is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped. To avoid this, the NAT device has to do the following:
ITR发送的映射请求（在NAT表中创建状态）在IP头中的5元组与权威ETR生成的映射应答不同。由于此数据包的源地址不同于请求数据包的目标地址，因此NAT表中不会匹配任何状态，数据包将被丢弃。为了避免这种情况，NAT设备必须执行以下操作：
o Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The simplest way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR's RLOC (called "DMZ" mode in consumer broadband routers).
o 将源端口为4342的所有UDP数据包发送到ITR的RLOC，而不考虑目标端口。实现这一点的最简单方法是将1:1 NAT模式从NAT设备的外部RLOC配置为ITR的RLOC（在消费者宽带路由器中称为“DMZ”模式）。
o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload.
o 重写有效负载中的ITR-AFI和“原始ITR RLOC地址”字段。
This setup supports only a single ITR behind the NAT device.
此设置仅支持NAT设备后面的单个ITR。
An ETR placed behind NAT is reachable from the outside by the Internet-facing locator of the NAT device. It needs to know this locator (and configure a loopback interface with it), so that it can use it in Map-Reply and Map-Register messages. Thus, support for dynamic locators for the mapping database is needed in LISP equipment.
放置在NAT后面的ETR可通过NAT设备的面向Internet的定位器从外部访问。它需要知道这个定位器（并用它配置一个环回接口），这样它就可以在Map Reply和Map Register消息中使用它。因此，LISP设备中需要支持映射数据库的动态定位器。
Again, only one ETR behind the NAT device is supported.
同样，仅支持NAT设备后面的一个ETR。
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ETR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ETR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 4: ETR behind NAT
图4:NAT后的ETR
An implication of the issues described above is that LISP sites with xTRs cannot be behind carrier-based NATs, since two different sites would collide on the same forwarded UDP port. An alternative to static hole-punching to explore is the use of the Port Control Protocol (PCP) [RFC6887].
上述问题的一个含义是，带有XTR的LISP站点不能位于基于运营商的NAT之后，因为两个不同的站点会在同一个转发的UDP端口上发生冲突。要探索的静态打孔的替代方法是使用端口控制协议（PCP）[RFC6887]。
We only include this scenario due to completeness, to show that a LISP site can be deployed behind NAT should it become necessary. However, LISP deployments behind NAT should be avoided, if possible.
由于完整性的原因，我们仅包含此场景，以表明如果必要，可以在NAT后面部署LISP站点。但是，如果可能，应避免在NAT后面部署LISP。
This section describes how certain LISP deployments can provide network functions.
本节介绍某些LISP部署如何提供网络功能。
In a simple LISP deployment, xTRs are located at the border of the LISP site (see Section 2.1.1). In this scenario, packets are routed inside the domain according to the EID. However, more complex networks may want to route packets according to the destination RLOC. This would enable them to choose the best egress point.
在一个简单的LISP部署中，XTR位于LISP站点的边界（参见第2.1.1节）。在这种情况下，根据EID在域内路由数据包。然而，更复杂的网络可能希望根据目的地RLOC路由分组。这将使他们能够选择最佳出口点。
The LISP specification separates the ITR and ETR functionality and allows both entities to be deployed in separated network equipment. ITRs can be deployed closer to the host (i.e., access routers). This way, packets are encapsulated as soon as possible, and egress point selection is driven by operational policy. In turn, ETRs can be deployed at the border routers of the network, and packets are decapsulated as soon as possible. Once decapsulated, packets are routed based on the destination EID according to internal routing policy.
LISP规范将ITR和ETR功能分离，并允许在分离的网络设备中部署这两个实体。ITR可以部署在更靠近主机的位置（即访问路由器）。通过这种方式，数据包被尽快封装，出口点选择由操作策略驱动。反过来，可以在网络的边界路由器上部署ETR，并尽快对数据包进行解封。一旦解除封装，数据包将根据内部路由策略基于目标EID进行路由。
We can see an example in Figure 5. The Source (S) transmits packets using its EID, and in this particular case packets are encapsulated at ITR_1. The encapsulated packets are routed inside the domain according to the destination RLOC and can egress the network through the best point (i.e., closer to the RLOC's Autonomous System (AS)). On the other hand, inbound packets are received by ETR_1, which decapsulates them. Then, packets are routed towards S according to the EID, again following the best path.
我们可以在图5中看到一个示例。源使用其EID发送数据包，在这种特殊情况下，数据包被封装在ITR_1。封装的分组根据目的地RLOC在域内路由，并且可以通过最佳点（即，更接近RLOC的自治系统（AS））离开网络。另一方面，ETR_1接收入站数据包，并将其解封。然后，根据EID将数据包路由到S，同样遵循最佳路径。
+---------------------------------------+
| |
| +-------+ +-------+ +-------+
| | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A |
| +-------+ | +-------+ +-------+
| +-+ | | |
| |S| | IGP | |
| +-+ | | |
| +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+
| |
+---------------------------------------+
+---------------------------------------+
| |
| +-------+ +-------+ +-------+
| | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A |
| +-------+ | +-------+ +-------+
| +-+ | | |
| |S| | IGP | |
| +-+ | | |
| +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+
| |
+---------------------------------------+
Figure 5: Split ITR/ETR Scenario
图5：拆分ITR/ETR场景
This scenario has a set of implications:
此场景具有一系列含义：
o The site must carry more-specific routes in order to choose the best egress point, and typically BGP is used for this, increasing the complexity of the network. However, this is usually already the case for LISP sites that would benefit from this scenario.
o 为了选择最佳出口点，站点必须承载更多特定的路由，通常使用BGP，这增加了网络的复杂性。然而，对于LISP站点来说，这种情况通常已经存在，它们将从这种情况中受益。
o If the site is multihomed to different ISPs and any of the upstream ISPs are doing unicast reverse path forwarding (uRPF) filtering, this scenario may become impractical. To set the correct source RLOC in the encapsulation header, ITRs need to first determine which ETR will be used by the outgoing packet. This adds complexity and reliability concerns.
o 如果站点与不同的ISP进行多址连接，并且任何上游ISP都在进行单播反向路径转发（uRPF）过滤，则这种情况可能变得不切实际。要在封装头中设置正确的源RLOC，ITRs需要首先确定传出数据包将使用哪个ETR。这增加了复杂性和可靠性问题。
o In LISP, ITRs set the reachability bits when encapsulating data packets. Hence, ITRs need a mechanism to be aware of the liveness of all ETRs serving their site.
o 在LISP中，ITRs在封装数据包时设置可达性位。因此，ITR需要一种机制来了解为其站点服务的所有ETR的活动性。
o The MTU within the site network must be large enough to accommodate encapsulated packets.
o 站点网络中的MTU必须足够大，以容纳封装的数据包。
o In this scenario, each ITR is serving fewer hosts than in the case when it is deployed at the border of the network. It has been shown that the cache hit rate grows logarithmically with the amount of users [CACHE]. Taking this into account, when ITRs are deployed closer to the host the effectiveness of the mapping cache may be lower (i.e., the miss rate is higher). Another consequence of this is that the site may transmit a higher amount of Map-Requests, increasing the load on the distributed mapping database.
o 在这种情况下，与部署在网络边界时相比，每个ITR所服务的主机更少。已经证明，缓存命中率随用户数量[缓存]呈对数增长。考虑到这一点，当ITR部署在离主机较近的位置时，映射缓存的有效性可能较低（即，未命中率较高）。这样做的另一个后果是，站点可能会传输更多的地图请求，从而增加分布式地图数据库的负载。
o By placing the ITRs inside the site, they will still need global RLOCs. This may add complexity to intra-site routing configurations and more intra-site issues when there is a change of providers.
o 通过将ITR放置在站点内，他们仍然需要全局RLOC。这可能会增加站点内路由配置的复杂性，并在提供商发生变化时增加更多站点内问题。
At the time of this writing, if two ISPs want to control their ingress TE policies for transit traffic between them, they need to rely on existing BGP mechanisms. This typically means deaggregating prefixes to choose on which upstream link packets should enter. This either is not feasible (if fine-grained per-customer control is required, the very-specific prefixes may not be propagated) or increases DFZ table size.
在撰写本文时，如果两个ISP想要控制它们之间传输流量的入口TE策略，它们需要依赖现有的BGP机制。这通常意味着取消聚合前缀以选择上游链路数据包应进入的位置。这要么是不可行的（如果需要对每个客户进行细粒度控制，则可能不会传播非常特定的前缀），要么会增加DFZ表的大小。
Typically, LISP is seen as applicable only to stub networks; however, LISP can also be applied in a recursive manner, providing service provider ingress/egress TE capabilities without impacting the DFZ table size.
通常，LISP仅适用于存根网络；然而，LISP也可以以递归的方式应用，提供服务提供者入口/出口TE功能，而不影响DFZ表的大小。
In order to implement this functionality with LISP, consider the scenario depicted in Figure 6. The two ISPs willing to achieve ingress/egress TE are labeled as ISP_A and ISP_B. They are servicing Stub1 and Stub2, respectively. Both are required to be LISP sites with their own xTRs. In this scenario, we assume that Stub1 and Stub2 are communicating with each other; thus, ISP_A and ISP_B offer transit for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream IP addresses, while ISP_B has RLOC_B1 and RLOC_B2. The shared goal among ISP_A and ISP_B is to control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2.
为了用LISP实现这个功能，请考虑图6中描述的场景。愿意实现进出TE的两个ISP被标记为ISP_A和ISP_B。它们分别为Stub1和Stub2提供服务。这两个站点都必须是具有自己XTR的LISP站点。在这个场景中，我们假设Stub1和Stub2正在相互通信；因此，ISP_A和ISP_B为此类通信提供传输。ISP_A具有RLOC_A1和RLOC_A2作为上游IP地址，而ISP_B具有RLOC_B1和RLOC_B2。ISP_A和ISP_B的共同目标是控制RLOC_A1/A2和RLOC_B1/B2之间的过境交通流。
_.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ...
_.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ...
Figure 6: Inter-Service-Provider TE Scenario
图6：跨服务提供商TE场景
Both ISPs deploy xTRs on RLOC_A1/A2 and RLOC_B1/B2, respectively and reach a bilateral agreement to deploy their own private mapping system. This mapping system contains bindings between the RLOCs of Stub1 and Stub2 (owned by ISP_A and ISP_B, respectively) and RLOC_A1/ A2 and RLOC_B1/B2. Such bindings are in fact the TE policies between both ISPs, and the convergence time is expected to be fast, since ISPs only have to update/query a mapping to/from the database.
两个ISP分别在RLOC_A1/A2和RLOC_B1/B2上部署XTR，并达成双边协议，部署各自的专用地图系统。该映射系统包含Stub1和Stub2（分别由ISP_A和ISP_B拥有）的RLOC与RLOC_A1/A2和RLOC_B1/B2之间的绑定。实际上，这类绑定是两个ISP之间的TE策略，由于ISP只需更新/查询到/来自数据库的映射，因此聚合时间预计会很快。
The packet flow is as follows. First, a packet originated at Stub1 towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A recursively encapsulates it, and according to the TE policies stored in the private mapping system the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as the outer encapsulation destination. Note that the packet transits between ISP_A and ISP_B double-encapsulated. Upon reception at the xTR of ISP_B, the packet is decapsulated and sent towards Stub2, which performs the last decapsulation.
包流如下所示。首先，从Stub1到Stub2的数据包是由Stub1的xTR封装的LISP。ISP_A的xTR递归地封装它，并且根据存储在私有映射系统中的TE策略，ISP_A xTR选择RLOC_B1或RLOC_B2作为外部封装目的地。请注意，数据包在ISP_A和ISP_B之间传输是双重封装的。在ISP_B的xTR处接收到数据包后，数据包被解封并发送到执行最后一次解封的Stub2。
This deployment scenario, which uses recursive LISP, includes three important caveats. First, it is intended to be deployed between only two ISPs. If more than two ISPs use this approach, then either the xTRs deployed at the participating ISPs must query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Furthermore, keeping this deployment scenario restricted to only two ISPs maintains a scalable solution, given that only two entities need to agree on using recursive LISP and only one private mapping system is involved.
这个使用递归LISP的部署场景包括三个重要的注意事项。首先，它打算只在两个ISP之间部署。如果有两个以上的ISP使用此方法，则部署在参与ISP的XTR必须查询多个映射系统，或者ISP必须就公共共享映射系统达成一致。此外，将此部署场景仅限于两个ISP可以维护一个可扩展的解决方案，因为只有两个实体需要同意使用递归LISP，并且只涉及一个私有映射系统。
Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be recursively encapsulated belong to said ISP. Otherwise, the participating ISPs must register prefixes they do not own in the above-mentioned private mapping system. This results in either requiring complex authentication mechanisms or enabling simple traffic redirection attacks. Failure to follow these recommendations may lead to operational security issues when deploying this scenario.
第二，该场景仅推荐用于提供到LISP站点的连接的ISP，以便递归封装的数据包的源RLOC属于所述ISP。否则，参与的ISP必须在上述专用映射系统中注册他们不拥有的前缀。这导致要么需要复杂的身份验证机制，要么启用简单的流量重定向攻击。在部署此场景时，如果不遵循这些建议，可能会导致操作安全问题。
And third, recursive encapsulation models are typically complex to troubleshoot and debug.
第三，递归封装模型通常很难进行故障排除和调试。
Besides these recommendations, the main disadvantages of this deployment case are:
除了这些建议外，此部署案例的主要缺点是：
o An extra LISP header is needed. This increases the packet size and requires that the MTU between both ISPs accommodate double-encapsulated packets.
o 需要一个额外的LISP标题。这增加了数据包的大小，并要求两个ISP之间的MTU容纳双重封装的数据包。
o The ISP ITR must encapsulate packets and therefore must know the RLOC-to-RLOC bindings. These bindings are stored in a mapping database and may be cached in the ITR's mapping cache. Cache misses lead to an additional lookup latency, unless a push-based mapping system is used for the private mapping system.
o ISP ITR必须封装数据包，因此必须知道RLOC到RLOC的绑定。这些绑定存储在映射数据库中，可以缓存在ITR的映射缓存中。缓存未命中会导致额外的查找延迟，除非专用映射系统使用基于推送的映射系统。
o Maintaining the shared mapping database involves operational overhead.
o 维护共享映射数据库涉及操作开销。
When looking at the deployment scenarios and functional models above, there are several things to consider when choosing an appropriate model, depending on the type of the organization doing the deployment.
当查看上面的部署场景和功能模型时，根据选择部署的组织的类型，在选择合适的模型时需要考虑的因素有很多。
For home users and small sites that wish to multihome and have control over their ISP options, the "CE" scenario offers the most advantages: it's simple to deploy, and in some cases it only requires a software upgrade of the Customer Premises Equipment (CPE), getting mapping service, and configuring the router. It retains control of TE and choosing upstreams by the user. It doesn't provide too many advantages to ISPs, due to the lessened dependence on their services in cases of multihomed clients. It is also unlikely that ISPs wishing to offer LISP to their customers will choose the "CE" model, as they would need to send a technician to each customer and, potentially, a new CPE device. Even if they have remote control over the router and a software upgrade could add LISP support, the operation is too risky.
对于希望多家并控制其ISP选项的家庭用户和小型站点，“CE”方案提供了最大的优势：“CE”方案易于部署，在某些情况下，它只需要对客户场所设备（CPE）进行软件升级、获得映射服务和配置路由器。它保留用户对TE和选择上游的控制。它没有给ISP提供太多的优势，因为在多址客户端的情况下，对ISP服务的依赖性降低了。希望向其客户提供LISP的ISP也不太可能选择“CE”模式，因为他们需要向每个客户派遣一名技术人员，并且可能需要一台新的CPE设备。即使他们可以远程控制路由器，并且软件升级可以添加LISP支持，操作也太危险了。
For a network operator, a good option to deploy is the "PE" scenario, unless a hardware upgrade is required for its edge routers to support LISP (in which case upgrading CPEs may be simpler). It retains control of TE as well as the choice of Proxy Egress Tunnel Router (PETR) and Map-Server/Map-Resolver. It also lowers potential MTU issues, as discussed above. Network operators should also explore the "inter-service-provider TE" (recursive) functional model for their TE needs.
对于网络运营商来说，部署“PE”方案是一个不错的选择，除非其边缘路由器需要硬件升级以支持LISP（在这种情况下，升级CPE可能更简单）。它保留对TE的控制以及代理出口隧道路由器（PETR）和地图服务器/地图解析器的选择。如上所述，它还降低了潜在的MTU问题。网络运营商还应探索“服务提供商间TE”（递归）功能模型，以满足其TE需求。
To optimize their traffic flow, large organizations can benefit the most from the "split ITR/ETR" functional model.
为了优化交通流，大型组织可以从“拆分ITR/ETR”功能模型中获益最大。
The following table gives a quick overview of the features supported by each of the deployment scenarios discussed above (marked with an "x" in the appropriate column): "CE" for customer edge, "PE" for provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-service-provider traffic engineering. The discussed features include:
下表简要概述了上述每个部署场景支持的功能（在相应列中用“x”标记）：“CE”表示客户边缘，“PE”表示提供商边缘，“Split”表示拆分ITR/ETR，而“Recursive”表示服务提供商间流量工程。讨论的特点包括：
Control of ingress TE: This scenario allows the LISP site to easily control LISP ingress traffic engineering policies.
入口TE控制：此场景允许LISP站点轻松控制LISP入口流量工程策略。
No modifications to existing int. network infrastructure: This scenario doesn't require the LISP site to modify internal network configurations.
不修改现有的int.network infrastructure：此场景不需要LISP站点修改内部网络配置。
Locator-Status-Bits sync: This scenario allows easy synchronization of the Locator Status Bits.
定位器状态位同步：此方案允许轻松同步定位器状态位。
MTU/PMTUD issues minimized: The scenario minimizes potential MTU and Path MTU Discovery (PMTUD) issues.
最小化MTU/PMTUD问题：该场景将潜在的MTU和路径MTU发现（PMTUD）问题最小化。
Feature CE PE Split Recursive NAT
--------------------------------------------------------------------
Control of ingress TE x - x x x
No modifications to existing
int. network infrastructure x x - - x
Locator-Status-Bits sync x - x x -
MTU/PMTUD issues minimized - x - - -
Feature CE PE Split Recursive NAT
--------------------------------------------------------------------
Control of ingress TE x - x x x
No modifications to existing
int. network infrastructure x x - - x
Locator-Status-Bits sync x - x x -
MTU/PMTUD issues minimized - x - - -
Map-Servers and Map-Resolvers make up the LISP mapping system and provide a means to find authoritative EID-to-RLOC mapping information, conforming to [RFC6833]. They are meant to be deployed in RLOC space, and their operation behind NAT is not supported.
映射服务器和映射解析器构成LISP映射系统，并提供一种查找权威EID到RLOC映射信息的方法，符合[RFC6833]。它们将部署在RLOC空间，不支持NAT背后的操作。
The Map-Server learns EID-to-RLOC mapping entries from an authoritative source and publishes them in the distributed mapping database. These entries are learned through authenticated Map-Register messages sent by authoritative ETRs. Also, upon reception of a Map-Request, the Map-Server verifies that the destination EID matches an EID-Prefix for which it is authoritative and then re-encapsulates and forwards it to a matching ETR. Map-Server functionality is described in detail in [RFC6833].
映射服务器从权威源学习EID到RLOC的映射条目，并将它们发布到分布式映射数据库中。这些条目是通过权威ETR发送的经过身份验证的映射寄存器消息获取的。此外，在接收到Map请求后，Map服务器会验证目标EID是否匹配其具有权威性的EID前缀，然后重新封装并将其转发给匹配的ETR。[RFC6833]中详细描述了地图服务器功能。
The Map-Server is provided by a Mapping Service Provider (MSP). The MSP participates in the global distributed mapping database infrastructure by setting up connections to other participants according to the specific mapping system that is employed (e.g., Alternative Logical Topology (ALT) [RFC6836], Delegated Database Tree (DDT) [LISP-DDT]). Participation in the mapping database and the storing of EID-to-RLOC mapping data are subject to the policies of the "root" operators, who should check ownership rights for the EID-Prefixes stored in the database by participants. These policies are out of scope for this document.
地图服务器由地图服务提供商（MSP）提供。MSP通过根据所采用的特定映射系统（例如，备选逻辑拓扑（ALT）[RFC6836]，委托数据库树（DDT）[LISP-DDT]）建立与其他参与者的连接，参与全球分布式映射数据库基础设施。参与映射数据库和存储EID到RLOC映射数据受“根”操作员政策的约束，他们应检查参与者在数据库中存储的EID前缀的所有权。这些策略超出了本文档的范围。
The LISP DDT protocol is used by LISP MSPs to provide reachability between those providers' Map-Resolvers and Map-Servers. The DDT root is currently operated by a collection of organizations on an open basis. See [DDT-ROOT] for more details. Similarly to the DNS root, it has several different server instances using names of the letters of the Greek alphabet (alpha, delta, etc.), operated by independent organizations. When this document was published, there were 6 such instances, with one of them being anycasted. [DDT-ROOT] provides the list of server instances on its web site and configuration files for several Map-Server implementations. The DDT root and LISP Mapping Providers both rely on and abide by existing allocation policies as defined by Regional Internet Registries (RIRs) to determine prefix ownership for use as EIDs.
LISP MSP使用LISP DDT协议在这些提供商的地图解析程序和地图服务器之间提供可达性。滴滴涕根目前由一批组织在开放的基础上运作。有关更多详细信息，请参见[DDT-ROOT]。与DNS根目录类似，它有几个不同的服务器实例，使用希腊字母（alpha、delta等）的名称，由独立组织操作。本文档发布时，共有6个此类实例，其中一个为任意类型。[DDT-ROOT]提供了其网站上的服务器实例列表以及几种地图服务器实现的配置文件。DDT根目录和LISP映射提供商都依赖并遵守区域互联网注册中心（RIR）定义的现有分配政策，以确定用作EID的前缀所有权。
It is expected that the DDT root organizations will continue to evolve in response to experimentation with LISP deployments for Internet edge multihoming and VPN use cases.
预计DDT根组织将继续发展，以响应针对Internet边缘多主和VPN用例的LISP部署试验。
In all cases, the MSP configures its Map-Server(s) to publish the prefixes of its clients in the distributed mapping database and start encapsulating and forwarding Map-Requests to the ETRs of the AS. These ETRs register their prefix(es) with the Map-Server(s) through periodic authenticated Map-Register messages. In this context, for some LISP sites, there is a need for mechanisms to:
在所有情况下，MSP都会将其映射服务器配置为在分布式映射数据库中发布其客户端的前缀，并开始封装映射请求并将其转发到AS的ETR。这些ETR通过定期验证的映射注册消息向映射服务器注册其前缀。在这种情况下，对于某些LISP站点，需要以下机制：
o Automatically distribute EID-Prefix(es) shared keys between the ETRs and the EID-registrar Map-Server.
o 在ETR和EID注册器映射服务器之间自动分发EID前缀共享密钥。
o Dynamically obtain the address of the Map-Server in the ETR of the AS.
o 在AS的ETR中动态获取映射服务器的地址。
The Map-Server plays a key role in the reachability of the EID-Prefixes it is serving. On one hand, it is publishing these prefixes into the distributed mapping database, and on the other hand, it is encapsulating and forwarding Map-Requests to the authoritative ETRs of these prefixes. ITRs encapsulating towards EIDs for which a failed Map-Server is responsible will be unable to
地图服务器在其服务的EID前缀的可访问性方面起着关键作用。一方面，它将这些前缀发布到分布式映射数据库中，另一方面，它将映射请求封装并转发到这些前缀的权威ETR。将ITRs封装到故障映射服务器负责的EID将无法
look up any of their covering prefixes. The only exceptions are the ITRs that already contain the mappings in their local caches. In this case, ITRs can reach ETRs until the entry expires (typically 24 hours). For this reason, redundant Map-Server deployments are desirable. A set of Map-Servers providing high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map-Servers in the redundancy group. The configuration for fail-over (or load-balancing, if desired) among the members of the group depends on the technology behind the mapping system being deployed. Since ALT is based on BGP and DDT takes its inspiration from the Domain Name System (DNS), deployments can leverage current industry best practices for redundancy in BGP and DNS. These best practices are out of scope for this document.
查找它们的任何覆盖前缀。唯一的例外是已经在本地缓存中包含映射的ITR。在这种情况下，ITRs可以到达ETRs，直到条目过期（通常为24小时）。因此，需要冗余的映射服务器部署。为同一组前缀提供高可用性服务的一组映射服务器称为冗余组。ETR配置为向冗余组中的所有地图服务器发送地图注册信息。组成员之间的故障转移（或负载平衡，如果需要）配置取决于部署的映射系统背后的技术。由于ALT基于BGP，而DDT的灵感来自域名系统（DNS），因此部署可以利用当前业界最佳做法实现BGP和DNS中的冗余。这些最佳实践超出了本文档的范围。
Additionally, if a Map-Server has no reachability for any ETR serving a given EID block, it should not originate that block into the mapping system.
此外，如果地图服务器无法访问为给定EID块提供服务的任何ETR，则不应将该块发起到地图系统中。
A Map-Resolver is a network infrastructure component that accepts LISP-encapsulated Map-Requests, typically from an ITR, and finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database. Map-Resolver functionality is described in detail in [RFC6833].
映射解析器是一种网络基础设施组件，它接受LISP封装的映射请求（通常来自ITR），并通过查阅分布式映射数据库来查找适当的EID到RLOC映射。[RFC6833]中详细描述了映射解析器的功能。
Anyone with access to the distributed mapping database can set up a Map-Resolver and provide EID-to-RLOC mapping lookup service. Database access setup is mapping system specific.
任何有权访问分布式映射数据库的人都可以设置映射解析器，并提供EID到RLOC映射查找服务。数据库访问设置是特定于映射系统的。
For performance reasons, it is recommended that LISP sites use Map-Resolvers that are topologically close to their ITRs. ISPs supporting LISP will provide this service to their customers, possibly restricting access to their user base. LISP sites not in this position can use open access Map-Resolvers, if available. However, regardless of the availability of open access resolvers, the MSP providing the Map-Server(s) for a LISP site should also make available Map-Resolver(s) for the use of that site.
出于性能原因，建议LISP站点使用拓扑上接近其ITR的映射解析器。支持LISP的ISP将向其客户提供此服务，可能会限制对其用户群的访问。不在此位置的LISP站点可以使用open access地图解析程序（如果可用）。但是，无论开放访问解析程序是否可用，为LISP站点提供映射服务器的MSP也应为该站点的使用提供映射解析程序。
In medium- to large-size ASes, ITRs must be configured with the RLOC of a Map-Resolver; this type of operation can be done manually. However, in Small Office/Home Office (SOHO) scenarios, a mechanism for autoconfiguration should be provided.
在中型到大型ASE中，ITRs必须配置Map解析器的RLOC；这种类型的操作可以手动完成。但是，在小型办公室/家庭办公室（SOHO）场景中，应提供自动配置机制。
One solution to avoid manual configuration in LISP sites of any size is the use of anycast [RFC4786] RLOCs for Map-Resolvers, similar to the DNS root server infrastructure. Since LISP uses UDP
避免在任何大小的LISP站点中进行手动配置的一个解决方案是使用anycast[RFC4786]RLOCs作为映射解析程序，类似于DNS根服务器基础结构。因为LISP使用UDP
encapsulation, the use of anycast would not affect reliability. LISP routers are then shipped with a preconfigured list of well-known Map-Resolver RLOCs, which can be edited by the network administrator, if needed.
封装时，使用anycast不会影响可靠性。然后，LISP路由器附带一个预配置的著名地图解析程序RLOC列表，如果需要，网络管理员可以编辑该列表。
The use of anycast also helps improve mapping lookup performance. Large MSPs can increase the number and geographical diversity of their Map-Resolver infrastructure, using a single anycasted RLOC. Once LISP deployment is advanced enough, very large content providers may also be interested in running this kind of setup, to ensure minimal connection setup latency for those connecting to their network from LISP sites.
使用anycast还有助于提高映射查找性能。大型MSP可以使用一个任意浇铸的RLOC增加其地图解析器基础设施的数量和地理多样性。一旦LISP部署足够先进，大型内容提供商也可能有兴趣运行这种设置，以确保从LISP站点连接到其网络的用户的连接设置延迟最小。
While Map-Servers and Map-Resolvers implement different functionalities within the LISP mapping system, they can coexist on the same device. For example, MSPs offering both services can deploy a single Map-Resolver/Map-Server in each PoP where they have a presence.
虽然映射服务器和映射解析器在LISP映射系统中实现不同的功能，但它们可以共存于同一设备上。例如，提供这两种服务的MSP可以在其存在的每个PoP中部署单个映射解析程序/映射服务器。
Proxy Ingress Tunnel Routers (PITRs) are part of the non-LISP/LISP transition mechanism, allowing non-LISP sites to reach LISP sites. They announce via BGP certain EID-Prefixes (aggregated, whenever possible) to attract traffic from non-LISP sites towards EIDs in the covered range. They do the mapping system lookup and encapsulate received packets towards the appropriate ETR. Note that for the reverse path, LISP sites can reach non-LISP sites by simply not encapsulating traffic. See [RFC6832] for a detailed description of PITR functionality.
代理入口隧道路由器（PITR）是非LISP/LISP转换机制的一部分，允许非LISP站点到达LISP站点。他们通过BGP宣布某些EID前缀（尽可能聚合），以吸引来自非LISP站点的流量进入覆盖范围内的EID。它们执行映射系统查找，并将收到的数据包封装到相应的ETR。请注意，对于反向路径，LISP站点可以通过简单地不封装流量到达非LISP站点。有关PITR功能的详细说明，请参见[RFC6832]。
The success of new protocols depends greatly on their ability to maintain backwards compatibility and interoperate with the protocol(s) they intend to enhance or replace, and on the incentives to deploy the necessary new software or equipment. A LISP site needs an interworking mechanism to be reachable from non-LISP sites. A PITR can fulfill this role, enabling early adopters to see the benefits of LISP, similar to tunnel brokers helping the transition from IPv4 to IPv6. A site benefits from new LISP functionality (proportionally with existing global LISP deployment) when migrating to LISP, so it has the incentives to deploy the necessary Tunnel Routers. In order to be reachable from non-LISP sites, it has two options: keep announcing its prefix(es) with BGP, or have a PITR announce prefix(es) covering them.
新协议的成功在很大程度上取决于它们保持向后兼容性和与它们打算增强或替换的协议互操作的能力，以及部署必要的新软件或设备的激励。LISP站点需要一种互通机制，以便从非LISP站点访问。PITR可以发挥这一作用，使早期采用者能够看到LISP的好处，类似于帮助从IPv4过渡到IPv6的隧道代理。当迁移到LISP时，站点会从新的LISP功能（与现有的全局LISP部署成比例）中获益，因此它有动机部署必要的隧道路由器。为了能够从非LISP站点访问，它有两个选项：使用BGP继续声明其前缀，或者使用PITR声明前缀覆盖它们。
If the goal of reducing the DFZ routing table size is to be reached, the second option is preferred. Moreover, the second option allows LISP-based ingress traffic engineering from all sites. However, the placement of PITRs significantly influences performance and deployment incentives. Section 5 is dedicated to the migration to a LISP-enabled Internet and includes deployment scenarios for PITRs.
如果要达到减少DFZ路由表大小的目标，则首选第二个选项。此外，第二个选项允许从所有站点进行基于LISP的入口流量工程。然而，PITR的放置显著影响绩效和部署激励。第5节专门介绍迁移到支持LISP的Internet，并包括PITR的部署场景。
In contrast to PITRs, PETRs are not required for the correct functioning of all LISP sites. There are two cases where they can be of great help:
与PITR相比，所有LISP站点的正常运行不需要PETR。有两种情况下，他们可以提供很大帮助：
o LISP sites with unicast reverse path forwarding (uRPF) restrictions, and
o 具有单播反向路径转发（uRPF）限制的LISP站点，以及
o Communication between sites using different address family RLOCs.
o 使用不同地址系列RLOC的站点之间的通信。
In the first case, uRPF filtering is applied at the LISP site's upstream provider's PE router. When forwarding traffic to non-LISP sites, an ITR does not encapsulate packets, leaving the original IP headers intact. As a result, packets will have EIDs in their source address. Since we are discussing the transition period, we can assume that a prefix covering the EIDs belonging to the LISP site is advertised to the global routing tables by a PITR, and the PE router has a route towards it. However, the next hop will not be on the interface towards the CE router, so non-encapsulated packets will fail uRPF checks.
在第一种情况下，在LISP站点的上游提供商的PE路由器上应用uRPF过滤。当将流量转发到非LISP站点时，ITR不会封装数据包，从而使原始IP头保持不变。因此，数据包的源地址中将包含EID。由于我们正在讨论过渡期，我们可以假设覆盖属于LISP站点的EID的前缀通过PITR播发到全局路由表，并且PE路由器有一条通向它的路由。但是，下一个跃点将不在通向CE路由器的接口上，因此非封装的数据包将无法通过uRPF检查。
To avoid this filtering, the affected ITR encapsulates packets towards the locator of the PETR for non-LISP destinations. Now the source address of the packets, as seen by the PE router, is the ITR's locator, which will not fail the uRPF check. The PETR then decapsulates and forwards the packets.
为了避免这种过滤，受影响的ITR将数据包封装到非LISP目的地的PETR定位器。现在，PE路由器看到的数据包的源地址是ITR的定位器，它不会使uRPF检查失败。然后，PETR解封装并转发数据包。
The second use case is IPv4-to-IPv6 transition. Service providers using older access network hardware that only supports IPv4 can still offer IPv6 to their clients by providing a CPE device running LISP, and PETR(s) for accessing IPv6-only non-LISP sites and LISP sites, with IPv6-only locators. Packets originating from the client LISP site for these destinations would be encapsulated towards the PETR's IPv4 locator. The PETR is in a native IPv6 network, decapsulating and forwarding packets. For non-LISP destinations, the packet travels natively from the PETR. For LISP destinations with IPv6-only locators, the packet will go through a PITR in order to reach its destination.
第二个用例是IPv4到IPv6的转换。使用仅支持IPv4的旧接入网络硬件的服务提供商仍然可以通过提供运行LISP的CPE设备，以及用于访问仅限IPv6的非LISP站点和仅限IPv6的定位器的PETR，向其客户端提供IPv6。来自这些目的地的客户端LISP站点的数据包将封装到PETR的IPv4定位器中。PETR位于本机IPv6网络中，用于解封装和转发数据包。对于非LISP目的地，数据包从PETR本地传输。对于只有IPv6定位器的LISP目的地，数据包将通过PITR到达目的地。
For more details on PETRs, see [RFC6832].
有关PETR的更多详细信息，请参阅[RFC6832]。
PETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with PITRs, PETRs too may introduce path stretch (the ratio between the cost of the selected path and that of the optimal path). Because of this, the ISP needs to consider the tradeoff of using several devices close to the customers to minimize it, or fewer devices farther away from the customers to minimize cost instead.
希望向客户提供增值服务的ISP可以部署PETR。与PITR的情况一样，PETR也可能引入路径拉伸（所选路径的成本与最佳路径的成本之比）。正因为如此，ISP需要考虑使用接近客户的多个设备以最小化它，或者更少的设备远离客户以最小化成本的折衷。
Since the deployment incentives for PITRs and PETRs are different, it is likely that they will be deployed in separate devices, except for the Content Delivery Network (CDN) case, which may deploy both in a single device.
由于PITR和PETR的部署激励不同，它们很可能部署在单独的设备中，但内容交付网络（CDN）情况除外，后者可能同时部署在单个设备中。
In all cases, the existence of a PETR involves another step in the configuration of a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit most from PETRs. Autoconfiguration of the PETR locator could be achieved by a DHCP option or by adding a PETR field to either Map-Notify or Map-Reply messages.
在所有情况下，PETR的存在涉及LISP路由器配置的另一个步骤。通常由DHCP配置的CPE路由器从PETR中获益最大。可以通过DHCP选项或向映射通知或映射回复消息添加一个PETR字段来实现PETR定位器的自动配置。
This section discusses a deployment architecture to support the migration to a LISP-enabled Internet. The loosely defined terms "early transition phase", "late transition phase", and "LISP Internet phase" refer to time periods when LISP sites are a minority, a majority, or represent all edge networks, respectively.
本节讨论支持迁移到支持LISP的Internet的部署体系结构。定义松散的术语“早期过渡阶段”、“晚期过渡阶段”和“LISP Internet阶段”分别指LISP站点为少数、多数或代表所有边缘网络的时间段。
For sites wishing to migrate to LISP with their Provider-Independent (PI) prefix, the least disruptive way is to upgrade their border routers to support LISP and register the prefix into the LISP mapping system, but to keep announcing it with BGP as well. This way, LISP sites will reach them over LISP, while legacy sites will be unaffected by the change. The main disadvantage of this approach is that no decrease in the DFZ routing table size is achieved. Still, just increasing the number of LISP sites is an important gain, as an increasing LISP/non-LISP site ratio may decrease the need for BGP-based traffic engineering that leads to prefix deaggregation. That, in turn, may lead to a decrease in the DFZ size and churn in the late transition phase.
对于希望使用其独立于提供商（PI）前缀迁移到LISP的站点，中断最少的方法是升级其边界路由器以支持LISP，并将前缀注册到LISP映射系统中，但也要不断向BGP宣布。这样，LISP站点将通过LISP到达它们，而遗留站点将不受更改的影响。这种方法的主要缺点是没有减少DFZ路由表的大小。不过，仅仅增加LISP站点的数量是一个重要的收益，因为增加LISP/非LISP站点的比率可能会减少对基于BGP的流量工程的需求，从而导致前缀解聚集。这反过来可能会导致DFZ规模的减小，并在后期过渡阶段导致客户流失。
This scenario is not limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy as well during the early LISP deployment phase, depending on the cost/benefit analysis of the individual networks. Since this leads to an increase in the DFZ size, the following architecture should be preferred for new allocations.
这种情况并不局限于已经用BGP公布了前缀的站点。新分配的EID块也可以在早期LISP部署阶段遵循此策略，具体取决于各个网络的成本/效益分析。由于这会导致DFZ大小的增加，因此对于新的分配，应首选以下体系结构。
In addition to publishing their clients' registered prefixes in the mapping system, MSPs with enough transit capacity can offer PITR service to them as a separate service. This service is especially useful for new PI allocations to sites without existing BGP infrastructure wishing to avoid BGP altogether. The MSP announces the prefix into the DFZ, and the client benefits from ingress traffic engineering without prefix deaggregation. The downside of this scenario is added path stretch.
除了在地图系统中发布其客户的注册前缀外，具有足够运输能力的MSP还可以作为单独的服务向其提供PITR服务。此服务对于向没有希望完全避免BGP的现有BGP基础设施的站点分配新PI特别有用。MSP将前缀宣布到DFZ中，客户端将从入口流量工程中受益，而无需前缀解聚集。这种情况的缺点是增加了路径拉伸。
Routing all non-LISP ingress traffic through a third party that is not one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today), especially in the first stage of the transition to LISP, with a significant number of legacy sites. This is because the handling of said traffic is likely to result in additional costs, which would be passed down to the client. When the LISP/non-LISP site ratio becomes high enough, this approach can prove increasingly attractive.
通过不是其ISP之一的第三方路由所有非LISP入口流量仅适用于流量适中的站点（如今天使用IPv6隧道代理服务的站点），特别是在向LISP过渡的第一阶段，具有大量传统站点。这是因为对所述流量的处理可能会导致额外的成本，这些成本将转嫁给客户。当LISP/非LISP站点比率足够高时，这种方法会越来越有吸引力。
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study.
与LISP+BGP相比，该方法避免了因流量工程目的的前缀解聚集而导致的DFZ膨胀，从而在新分配的情况下导致路由表增加较慢，并可能减少现有分配。此外，为具有相邻可聚合前缀的不同客户端提供服务的MSP可能会导致额外的减少，但要量化这种减少还需要进一步的研究。
Instead of a LISP site or the MSP announcing its EIDs with BGP to the DFZ, this function can be outsourced to a third party, a PITR Service Provider (PSP). This will result in a decrease in operational complexity at both the site and the MSP.
该功能可以外包给第三方，即PITR服务提供商（PSP），而不是LISP站点或MSP向DFZ宣布其带有BGP的EID。这将降低现场和MSP的操作复杂性。
The PSP manages a set of distributed PITR(s) that will advertise the corresponding EID-Prefixes through BGP to the DFZ. These PITRs will then encapsulate the traffic they receive for those EIDs towards the RLOCs of the LISP site, ensuring their reachability from non-LISP sites.
PSP管理一组分布式PITR，这些PITR将通过BGP向DFZ公布相应的EID前缀。然后，这些PITR将封装它们为这些EID接收的流向LISP站点RLOCs的流量，确保它们可以从非LISP站点访问。
While it is possible for a PSP to manually configure each client's EID-Routes to be announced, this approach offers little flexibility and is not scalable. This section presents a scalable architecture that offers automatic distribution of EID-Routes to LISP sites and service providers.
虽然PSP可以手动配置每个客户端的EID路由，但这种方法提供的灵活性很小，不可扩展。本节介绍一个可扩展的体系结构，该体系结构提供了到LISP站点和服务提供商的EID路由的自动分发。
The architecture requires no modification to existing LISP network elements, but it introduces a new (conceptual) network element, the EID-Route Server, which is defined as a router that either propagates routes learned from other EID-Route Servers or originates EID-Routes. The EID-Routes that it originates are those for which it is authoritative. It propagates these routes to Proxy-ITRs within the AS of the EID-Route Server. It is worth noting that a BGP-capable router can also be considered an EID-Route Server.
该体系结构不需要修改现有的LISP网络元素，但它引入了一个新的（概念上的）网络元素EID Route Server，它被定义为传播从其他EID Route Server学习的路由或发起EID路由的路由器。它发起的EID路由是它所授权的路由。它将这些路由传播到EID路由服务器内的代理ITR。值得注意的是，支持BGP的路由器也可以被视为EID路由服务器。
Further, an EID-Route is defined as a prefix originated via the Route Server of the MSP, which should be aggregated if the MSP has multiple customers inside a single large continuous prefix. This prefix is propagated to other PITRs both within the MSP and to other PITR operators with which it peers. EID-Route Servers are operated by either the LISP site, MSPs, or PSPs and may be collocated with a Map-Server or PITR, but they are functionally discrete entities. They distribute EID-Routes, using BGP, to other domains according to policies set by participants.
此外，EID路由被定义为经由MSP的路由服务器发起的前缀，如果MSP在单个大的连续前缀中具有多个客户，则应聚合该前缀。此前缀被传播到MSP内的其他PITR以及与之对等的其他PITR运算符。EID路由服务器由LISP站点、MSP或PSP操作，可以与地图服务器或PITR并置，但它们是功能上独立的实体。他们根据参与者设置的策略，使用BGP将EID路由分发到其他域。
MSP (AS64500)
RS ---> PITR
| /
| _.--./
,-'' /`--.
LISP site ---,' | v `.
( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,'
`--. / _.-'
| `--''
v /
PITR
PSP (AS64501)
MSP (AS64500)
RS ---> PITR
| /
| _.--./
,-'' /`--.
LISP site ---,' | v `.
( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,'
`--. / _.-'
| `--''
v /
PITR
PSP (AS64501)
Figure 7: PITR-RD Architecture
图7:PITR-RD体系结构
The architecture described above decouples EID origination from route propagation, with the following benefits:
上述体系结构将EID发起与路由传播分离，具有以下优点：
o Can accurately represent business relationships between PITR operators
o 能够准确表示PITR运营商之间的业务关系
o Is more mapping system agnostic
o 更多的地图系统是不可知的吗
o Makes minor changes to PITR implementation; no changes to other components
o 对PITR实施进行微小更改；对其他组件没有更改
In the example in Figure 7, we have a MSP providing services to the LISP site. The LISP site does not run BGP and gets an EID allocation directly from a RIR, or from the MSP, which may be a Local Internet Registry (LIR). Existing PI allocations can be migrated as well. The MSP ensures the presence of the prefix in the mapping system and runs an EID-Route Server to distribute it to PSPs. Since the LISP site does not run BGP, the prefix will be originated with the AS number of the MSP.
在图7中的示例中，我们有一个MSP为LISP站点提供服务。LISP站点不运行BGP，直接从RIR或MSP（可能是本地Internet注册表（LIR））获取EID分配。现有PI分配也可以迁移。MSP确保映射系统中存在前缀，并运行EID路由服务器将其分发给PSP。由于LISP站点不运行BGP，因此前缀将以MSP的AS编号开始。
In the simple case depicted in Figure 7, the EID-Route of a LISP site will be originated by the Route Server and announced to the DFZ by the PSP's PITRs with AS path 64501 64500. From that point on, the usual BGP dynamics apply. This way, routes announced by the PITR are still originated by the authoritative Route Server. Note that the peering relationships between MSPs/PSPs and those in the underlying forwarding plane may not be congruent, making the AS path to a PITR shorter than it is in reality.
在图7所示的简单示例中，LISP站点的EID路由将由路由服务器发起，并由PSP的PITR以路径64501 64500通知DFZ。从那时起，通常的BGP动态将适用。这样，PITR宣布的路由仍然由权威路由服务器发起。注意，msp/psp与底层转发平面中的那些之间的对等关系可能不一致，使得到PITR的AS路径比实际更短。
The non-LISP site will select the best path towards the EID-Prefix according to its local BGP policies. Since AS-path length is usually an important metric for selecting paths, careful placement of PITRs could significantly reduce path stretch between LISP and non-LISP sites.
非LISP站点将根据其本地BGP策略选择通向EID前缀的最佳路径。由于路径长度通常是选择路径的一个重要指标，因此仔细放置PITR可以显著减少LISP和非LISP站点之间的路径拉伸。
The architecture allows for flexible policies between MSPs/PSPs. Consider the EID-Route Server networks as control plane overlays, facilitating the implementation of policies necessary to reflect the business relationships between participants. The results are then injected into the common underlying forwarding plane. For example, some MSPs/PSPs may agree to exchange EID-Prefixes and only announce them to each of their forwarding plane customers. Global reachability of an EID-Prefix depends on the MSP from which the LISP site buys service and is also subject to agreement between the above-mentioned parties.
该体系结构允许MSP/PSP之间采用灵活的策略。考虑EID路由服务器网络作为控制平面覆盖，便于实现反映参与者之间业务关系所必需的策略。然后将结果注入公共底层转发平面。例如，一些MSP/PSP可能同意交换EID前缀，并且只向其每一位转发飞机客户宣布它们。EID前缀的全局可达性取决于LISP站点从中购买服务的MSP，也取决于上述各方之间的协议。
In terms of impact on the DFZ, this architecture results in a slower routing table increase for new allocations, since traffic engineering will be done at the LISP level. For existing allocations migrating to LISP, the DFZ may decrease, since MSPs may be able to aggregate the prefixes announced.
就对DFZ的影响而言，这种体系结构导致新分配的路由表增加较慢，因为流量工程将在LISP级别完成。对于迁移到LISP的现有分配，DFZ可能会减少，因为MSP可能能够聚合所宣布的前缀。
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study.
与LISP+BGP相比，该方法避免了因流量工程目的的前缀解聚集而导致的DFZ膨胀，从而在新分配的情况下导致路由表增加较慢，并可能减少现有分配。此外，为具有相邻可聚合前缀的不同客户端提供服务的MSP可能会导致额外的减少，但要量化这种减少还需要进一步的研究。
The flexibility and scalability of this architecture do not come without a cost, however: A PSP operator has to establish either transit or peering relationships to improve its connectivity.
然而，这种架构的灵活性和可扩展性并非没有成本：PSP运营商必须建立传输或对等关系以改善其连接性。
Registering a domain name typically entails an annual fee that should cover the operating expenses for publishing the domain in the global DNS. This situation is similar for several other registration services. A LISP MSP client publishing an EID-Prefix in the LISP mapping system has the option of signing up for PITR services as well, for an extra fee. These services may be offered by the MSP itself, but it is expected that specialized PSPs will do it. Clients that do not sign up will be responsible for getting non-LISP traffic to their EIDs (using the LISP+BGP scenario).
注册域名通常需要支付年费，以支付在全球DNS中发布域名的运营费用。其他一些注册服务的情况也类似。在LISP映射系统中发布EID前缀的LISP MSP客户端也可以选择注册PITR服务，但需额外付费。这些服务可能由MSP自己提供，但预计专业PSP会提供。未注册的客户端将负责将非LISP通信量发送到其EID（使用LISP+BGP方案）。
Additionally, Tier 1 ISPs have incentives to offer PITR services to non-subscribers in strategic places just to attract more traffic from competitors and thus more revenue.
此外，一级ISP有动机在战略位置向非用户提供PITR服务，以吸引竞争对手的更多流量，从而获得更多收入。
The following table presents the expected effects that the transition scenarios at various phases will have on the DFZ routing table size:
下表显示了不同阶段的过渡场景对DFZ路由表大小的预期影响：
Phase | LISP+BGP | MSP PITR | PITR-RD
-----------------+--------------+-----------------+----------------
Early transition | no change | slower increase | slower increase
Late transition | may decrease | slower increase | slower increase
LISP Internet | considerable decrease
Phase | LISP+BGP | MSP PITR | PITR-RD
-----------------+--------------+-----------------+----------------
Early transition | no change | slower increase | slower increase
Late transition | may decrease | slower increase | slower increase
LISP Internet | considerable decrease
It is expected that PITR-RD will coexist with LISP+BGP during the migration, with the latter being more popular in the early transition phase. As the transition progresses and the MSP PITR and PITR-RD ecosystem gets more ubiquitous, LISP+BGP should become less attractive, slowing down the increase of the number of routes in the DFZ.
预计PITR-RD将在迁移期间与LISP+BGP共存，后者在早期过渡阶段更受欢迎。随着过渡进程的推进，MSP PITR和PITR-RD生态系统变得更加普遍，LISP+BGP的吸引力应该会降低，从而减缓DFZ中路由数量的增加。
Note that throughout Section 5 we focused on the effects of LISP deployment on the DFZ routing table size. Other metrics may be impacted as well but to the best of our knowledge have not been measured as yet.
注意，在第5节中，我们重点讨论了LISP部署对DFZ路由表大小的影响。其他指标也可能受到影响，但据我们所知，目前尚未对其进行衡量。
All security implications of LISP deployments are to be discussed in separate documents. [LISP-THREATS] gives an overview of LISP threat models, including ETR operators attracting traffic by overclaiming an EID-Prefix (Section 4.4.3 of [LISP-THREATS]). Securing mapping lookups is discussed in [LISP-SEC].
LISP部署的所有安全影响将在单独的文档中讨论。[LISP-THREATS]概述了LISP威胁模型，包括ETR运营商通过过度使用EID前缀吸引流量（见[LISP-THREATS]第4.4.3节）。[LISP-SEC]中讨论了如何保护映射查找。
Many thanks to Margaret Wasserman for her contribution to the IETF 76 presentation that kickstarted this work. The authors would also like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul Vinciguerra, Fred Templin, Brian Haberman, and everyone else who provided input.
非常感谢Margaret Wasserman为IETF 76演示文稿所做的贡献，该演示文稿启动了这项工作。作者还要感谢Damien Saucez、Luigi Iannone、Joel Halpern、Vince Fuller、Dino Farinaci、Terry Manderson、Noel Chiapa、Hannu Flinck、Paul Vinciguerra、Fred Templin、Brian Haberman和其他提供意见的人。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“定位器/ID分离协议（LISP）和非LISP站点之间的互通”，RFC 6832，2013年1月。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833]Fuller，V.和D.Farinaci，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，2013年1月。
[CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", IEEE/ACM Transactions on Networking (TON), Volume 10, Issue 5, pages 589-603, October 2002.
[CACHE]Jung，J.，Sit，E.，Balakrisnan，H.，和R.Morris，“DNS性能和缓存的有效性”，IEEE/ACM网络交易（TON），第10卷，第5期，第589-603页，2002年10月。
[DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014, <http://ddt-root.org/>.
[DDT-ROOT]“LISP DDT简介：DDT-ROOT”，2014年3月<http://ddt-root.org/>.
[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, March 2013.
[LISP-DDT]Fuller，V.，Lewis，D.，Ermagan，V.，和A.Jain，“LISP委托数据库树”，正在进行的工作，2013年3月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, October 2013.
[LISP-SEC]Maino，F.，Ermagan，V.，Cabellos Aparicio，A.，Saucez，D.，和O.Bonaventure，“LISP安全（LISP-SEC）”，正在进行的工作，2013年10月。
[LISP-THREATS] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", Work in Progress, April 2014.
[LISP-THREATS]Saucez，D.，Iannone，L.，和O.Bonaventure，“LISP威胁分析”，正在进行的工作，2014年4月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，2006年12月。
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Zhang，L.，和K.Fall，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013.
[RFC6834]Iannone，L.，Saucez，D.，和O.Bonaventure，“定位器/ID分离协议（LISP）地图版本控制”，RFC 6834，2013年1月。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6835]Farinaci，D.和D.Meyer，“定位器/身份分离协议互联网搜索器（LIG）”，RFC 68352013年1月。
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836]Fuller，V.，Farinaci，D.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 68362013年1月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[TELCO96] Federal Communications Commission, "Telecommunications Act of 1996", 1996, <http://transition.fcc.gov/telecom.html>.
[TELCO96]联邦通信委员会，《1996年电信法》，1996年<http://transition.fcc.gov/telecom.html>.
To help the operational community deploy LISP, this informative section offers a step-by-step guide for migrating a BGP-based Internet presence to a LISP site. It includes a pre-install/ pre-turn-up checklist, and customer and provider activation procedures.
为了帮助运营社区部署LISP，本信息性章节提供了将基于BGP的Internet存在迁移到LISP站点的分步指南。它包括预安装/预启动检查表，以及客户和提供商激活程序。
1. Determine how many current physical service provider connections the customer has, and their existing bandwidth and traffic engineering requirements.
1. 确定客户当前有多少物理服务提供商连接，以及他们现有的带宽和流量工程要求。
This information will determine the number of routing locators, and the priorities and weights that should be configured on the xTRs.
此信息将确定路由定位器的数量，以及应在XTR上配置的优先级和权重。
2. Make sure the customer router has LISP capabilities.
2. 确保客户路由器具有LISP功能。
* Check the OS version of the CE router. If LISP is an add-on, check to see if it is installed.
* 检查CE路由器的操作系统版本。如果LISP是一个附加组件，请检查它是否已安装。
This information can be used to determine if the platform is appropriate to support LISP, in order to determine if a software and/or hardware upgrade is required.
此信息可用于确定平台是否适合支持LISP，以确定是否需要软件和/或硬件升级。
* Have the customer upgrade (if necessary, software and/or hardware) to be LISP capable.
* 让客户升级（如有必要，软件和/或硬件）以支持LISP。
3. Obtain the current running configuration of the CE router. A suggested LISP router configuration example can be customized to the customer's existing environment.
3. 获取CE路由器的当前运行配置。建议的LISP路由器配置示例可以根据客户的现有环境进行定制。
4. Verify MTU handling.
4. 验证MTU处理。
* Request an increase in MTU to 1556 or more on service provider connections. Prior to the MTU change, verify the transmission of a 1500-byte packet from the PxTR to the RLOC with the Don't Fragment (DF) bit set.
* 请求将服务提供商连接的MTU增加到1556或更多。在MTU更改之前，使用DOT to FRAGENT（DF）位集验证1500字节数据包从PxTR传输到RLOC。
* Ensure that the customer is not filtering ICMP Unreachable or Time Exceeded messages on their firewall or router.
* 确保客户没有在其防火墙或路由器上过滤ICMP无法访问或超时的消息。
LISP, like any tunneling protocol, will increase the size of packets when the LISP header is appended. If increasing the MTU of the access links is not possible, care must be taken that ICMP is not being filtered in order to allow Path MTU Discovery to take place.
与任何隧道协议一样，LISP在附加LISP头时会增加数据包的大小。如果无法增加访问链路的MTU，则必须注意ICMP未被过滤，以便进行路径MTU发现。
5. Validate member prefix allocation.
5. 验证成员前缀分配。
This step checks to see whether the prefix used by the customer is a direct (Provider-Independent) prefix or a prefix assigned by a physical service provider (Provider Aggregatable). If the prefixes are assigned by other service providers, then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider.
此步骤检查客户使用的前缀是直接（独立于提供商）前缀还是物理服务提供商分配的前缀（提供商可聚合）。如果前缀由其他服务提供商分配，则需要通过代理服务提供商发布前缀的协议书。
6. Verify the member RLOCs and their reachability.
6. 验证成员RLOCs及其可达性。
This step ensures that the RLOCs configured on the CE router are in fact reachable and working.
此步骤确保CE路由器上配置的RLOC实际上可以访问并工作。
7. Prepare for cut-over.
7. 准备割伤。
* If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch.
* 如果可能，将所有安全和筛选策略之外的主机连接到边缘路由器或交换机的控制台端口。
* Make sure the customer has access to the router in order to configure it.
* 确保客户可以访问路由器以进行配置。
1. The customer configures LISP on CE router(s) according to the configuration recommended by the service provider.
1. 客户根据服务提供商建议的配置在CE路由器上配置LISP。
The LISP configuration consists of the EID-Prefix, the locators, and the weights and priorities of the mapping between the two values. In addition, the xTR must be configured with Map-Resolver(s), Map-Server(s), and the shared key for registering to Map-Server(s). If required, Proxy-ETR(s) may be configured as well.
LISP配置包括EID前缀、定位器以及两个值之间映射的权重和优先级。此外，xTR必须配置映射解析程序、映射服务器和用于注册到映射服务器的共享密钥。如果需要，还可以配置代理ETR。
In addition to the LISP configuration:
除了LISP配置之外：
* Ensure that the default routes(s) to next-hop external neighbors is included and RLOCs are present in the configuration.
* 确保包括到下一跳外部邻居的默认路由，并且配置中存在RLOC。
* If two or more routers are used, ensure that all RLOCs are included in the LISP configuration on all routers.
* 如果使用两个或多个路由器，请确保所有路由器上的LISP配置中包含所有RLOC。
* It will be necessary to redistribute the default route via IGP between the external routers.
* 有必要通过IGP在外部路由器之间重新分配默认路由。
2. When transition is ready, perform a soft shutdown on existing eBGP peer session(s).
2. 当转换准备就绪时，对现有eBGP对等会话执行软关闭。
* From the CE router, use the LISP Internet Groper (LIG) [RFC6835] to ensure that registration is successful.
* 从CE路由器，使用LISP Internet Groper（LIG）[RFC6835]确保注册成功。
* To verify LISP connectivity, find and ping LISP connected sites. If possible, find ping destinations that are not covered by a prefix in the global BGP routing system, because PITRs may deliver the packets even if LISP connectivity is not working. Traceroutes may help determine if this is the case.
* 要验证LISP连接，请查找并ping LISP连接的站点。如果可能，在全局BGP路由系统中查找不包含前缀的ping目的地，因为即使LISP连接不起作用，PITR也可能传递数据包。跟踪路由可能有助于确定情况是否如此。
* To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser.
* 要验证与非LISP站点的连接，请尝试通过web浏览器访问地标（例如，主要Internet站点）。
1. Verify site configuration, and then verify active registration on Map-Server(s).
1. 验证站点配置，然后验证地图服务器上的活动注册。
* Authentication key.
* 身份验证密钥。
* EID-Prefix.
* EID前缀。
2. Add EID space to map-cache on proxies.
2. 将EID空间添加到代理上的映射缓存。
3. Add networks to BGP advertisement on proxies.
3. 将网络添加到代理上的BGP广告。
* Modify route-maps/policies on PxTRs.
* 修改PXTR上的路线图/策略。
* Modify route policies on core routers (if non-connected member).
* 修改核心路由器上的路由策略（如果未连接成员）。
* Modify ingress policies on core routers.
* 修改核心路由器上的入口策略。
* Ensure route announcement in looking glass servers, RouteViews.
* 确保在looking glass服务器、RouteView中发布路线公告。
4. Perform traffic verification test.
4. 执行流量验证测试。
* Ensure that MTU handling is as expected (PMTUD working).
* 确保MTU处理符合预期（PMTUD工作）。
* Ensure Proxy-ITR map-cache population.
* 确保代理ITR映射缓存填充。
* Ensure access from traceroute/ping servers around Internet.
* 确保从Internet上的跟踪路由/ping服务器进行访问。
* Use a looking glass to check for external visibility of registration via several Map-Resolvers.
* 使用观察镜通过多个地图解析器检查注册的外部可见性。
Authors' Addresses
作者地址
Lorand Jakab Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号罗兰雅加布思科系统公司，邮编95134
EMail: lojakab@cisco.com
EMail: lojakab@cisco.com
Albert Cabellos-Aparicio Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain
艾伯特CabelOS加泰罗尼亚阿巴里西奥技术大学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 BARCELONA 08034 Spain
加泰罗尼亚佛罗林科拉斯技术大学C／霍尔迪赫罗纳，S/N巴塞罗那08034西班牙
EMail: fcoras@ac.upc.edu
EMail: fcoras@ac.upc.edu
Jordi Domingo-Pascual Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain
霍尔迪·多明戈·帕斯卡尔加泰罗尼亚技术大学C/C霍尔迪赫罗纳，S/N巴塞罗那08034西班牙
EMail: jordi.domingo@ac.upc.edu
EMail: jordi.domingo@ac.upc.edu
Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134
EMail: darlewis@cisco.com
EMail: darlewis@cisco.com