[要約] RFC 7834は、Locator/ID Separation Protocol (LISP)の影響についての要約です。このRFCの目的は、LISPの導入がネットワークアーキテクチャに与える影響を評価し、LISPの利点と課題を明確にすることです。
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 Separation Protocol（LISP）は、アドレスの役割の分離、カプセル化、およびマッピングという3つの原則を利用して、インターネットルーティングのスケーラビリティプロパティを改善することを目的としています。このドキュメントでは、実装作業、展開経験、および理論的研究に基づいて、LISPの展開がルーティングインフラストラクチャとエンドユーザーの両方に与える影響について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 Separation Protocol（LISP）は、インターネットルーティングのスケーラビリティプロパティを改善するために、アドレスの役割の分離、カプセル化、およびマッピングという3つの原則に依存しています。発明されたとき、LISPはインターネットルーティングスケーリング問題[RFC4984]を解決することを目的としていました。ドメイン間ルーティングのスケーラビリティを向上させるためにLISPを使用することの影響と未解決の問題を調査する実装と実験が何年もありました。経験から、LISPはマッピングおよびカプセル化テクノロジーを利用しているため、ルーティングのスケーラビリティを超える目的で展開および使用できることがわかっています。たとえば、LISPは、LISPサイトがドメイン間の発信および着信トラフィックを正確に制御する手段を提供します。これにより、トラフィックを交換するさまざまなドメインにさまざまなポリシーを適用できます。 LISPを使用すると、IPv4 over IPv6またはIPv6 over 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は、役割の分離、カプセル化、およびマッピングという3つの原則に依存しています。
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.
アドレススペースは、セマンティックの意味が異なる2つのセットに分割されます。ルーティングロケーター（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インターネットの場合と同様にパケットを送信します。パケットは、ITRのサイトの境界に到達します。 EIDはインターネット上でルーティングできないため、パケットは、ソースアドレスがITR RLOCに設定され、宛先アドレスがETR RLOCに設定されてカプセル化されます。カプセル化されたパケットは、選択されたETRに到達するまでプロバイダードメインに転送されます。 ETRはパケットのカプセル化を解除し、最終的な宛先に転送します。頭字語xTRはIngress / Egress Tunnel Routerの略で、これらの2つの役割を果たすルーターに使用されます。
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とRLOCの間の対応は、マッピングによって与えられます。 ITRがEIDを提供するETR RLOCを見つける必要がある場合、ITRはマッピングシステムを照会します。 LISP正規アドレス形式（LCAF）[LISP-LCAF]を使用すると、LISPはEIDアドレスのインターネットプロトコルに制限されません。 LCAFでは、任意のアドレスタイプをEIDとして使用できます（アドレスはマッピングルックアップのキーにすぎません）。 LISPは、たとえばイーサネットフレームをインターネット経由で転送できます。
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の当初の目的は、インターネットルーティングアーキテクチャのスケーラビリティプロパティを改善することでした。 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はスタブASでのみ使用され、トランジットASでは使用されません。そして
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プレフィックスを所有するスタブとプロバイダーの間のエッジにデプロイされ、RLOCをPAモードで割り当てます。
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 et al。 [QIdLB07]は、ネットワークレベルでロケーターと識別子の役割を分離することで、ルーティング情報ベース（RIB）のサイズを削減（最大1桁）することでルーティングのスケーラビリティが向上し、パスの多様性が向上するため、トラフィックエンジニアリング機能が向上することを示しています。 [IB07]と[KIF13]は、実際のインターネットトラフィックトレースに基づいて、最大20,000ユーザーのネットワークのITRで処理する必要があるマッピングエントリの数が数万に制限されていることを示しています。シグナリングトラフィック（つまり、Map-Request / Map-Replyパケット）は、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- 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.
以前の調査では、タイマーベースのキャッシュ削除ポリシー（つまり、タイムアウト時にキャッシュからマッピングが削除される）のケースを検討していましたが、[CDLC]には、最も最近使用された（LRU）削除ポリシーに基づくより一般的なアプローチがあり、分析を提案しますプレフィックスレベルのトラフィックに定常的な生成プロセスがある場合のEID-to-RLOCキャッシュサイズのモデル。このモデルは、EIDからRLOCへのキャッシュサイズと簡単に測定可能なトラフィックパラメーターの小さなセットからミス率を正確に予測できることを示しています。 EIDプレフィックスがBGPプレフィックスと同じサイズであると見なして、キャンパスネットワークの出口ポイントと学術交換ポイントで収集された1日の長さの4つのパケットトレースを使用してモデルが検証されました。その結果、オペレーターは、特定のトラフィックに対して達成したいミス率に従って、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-to-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での仮想マシンのモビリティをサポートするために使用されることが確認されています。これらの最後の2つの使用法は、現在の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アーキテクチャの主な利点は、ネットワークエンドポイントとトポロジーの場所の間の相関がほとんどまたはまったくない環境でのルーティングが容易になることです。サービスプロバイダー環境では、このアプリケーションは、サービスをサブスクライバーに配信するためにインラインアンカーが必要なさまざまなコンシューマーユースケースで必要です。インラインアンカーは、次の3つのタイプの機能のいずれかを提供します。
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）が含まれます。仮想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に進化して、マップ支援オーバーレイネットワークを展開しています。このソリューションは、数億人のサブスクライバーにまたがる3つのTier 1オペレーターの実稼働環境に展開されています。マップ支援オーバーレイは、主に、プロファイルと条件に基づいて加入者フローをサービスリソースに動的にマッピングするために使用されていました。具体的には、モバイル加入者を付加価値/最適化サービスに、ブロードバンド加入者をテレフォニーサービスに、固定モバイル加入者をブロードバンドネットワークゲートウェイ（BNG）機能とインターネットアクセスサービスにマッピングするために使用されています。 LISPマップ支援オーバーレイアーキテクチャは、加入者をサービス、機能、インスタンス、および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ルーターのリストを決定するには、マッピングが必要です。この違いは2つの理由で重要です。まず、パケットはサイトではなく特定のルーターに転送されます。次に、サイトはマッピングを制御することにより、トラフィックのエントリポイントを制御できます。
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間でそれらの重みに比例して分散されます。したがって、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.
すべてのMap-Requestに、キャッシュミスを引き起こしてMap-Requestをトリガーしたパケットの送信元EIDアドレスが含まれているため、LISPのトラフィックエンジニアリングはさらに一歩進んでいます。したがって、マッピング所有者は、リクエスターに基づいて、マップ要求に与える応答（マップ応答）を区別することができます。現在、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にバインドしたり、その逆を行ったりすることができます。これにより、IPv6ネットワーク上の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 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.
例として、デュアルスタックのフロントエンドロードバランサーが使用されているときに、データセンターのネットワークインフラストラクチャがIPv4のみである場合があります。このシナリオでは、ネットワークとサーバーがIPv4のみをサポートしている場合でも、LISPを使用してサーバーにIPv6アクセスを提供できます。データセンターのISPがIPv6接続を提供すると仮定すると、データセンターは、ISPとの境界に1つ（または複数）のxTRと、ロードバランサーに直接接続された1つ（または複数）のxTRのみを展開する必要があります。 ISPの境界にあるxTRは、IPv6パケットをIPv4経由でロードバランサーに直接接続されているxTRにトンネルします。ロードバランサーのxTRはパケットのカプセル化を解除し、それらをプロキシとして機能するロードバランサーに転送し、各IPv6パケットをIPv4パケットに変換します。次に、IPv4パケットが適切なサーバーに送信されます。同様に、サーバーの応答がロードバランサーに到着すると、パケットはIPv6パケットに変換され、xTRに転送されます。xTRは、IPv4のみのインフラストラクチャを介して、接続されているxTRにトンネリングします。 ISP。次に、パケットはカプセル化が解除され、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-Multicastが適切に機能するためには、ドメイン間マルチキャストが利用可能であることが必要です。
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-SIGNALING]を利用してマルチキャストステート配信を行い、ドメイン間マルチキャストサポートが利用できない場合にxTRベースのドメイン間マルチキャスト配信ツリーを構築します。 。低レイテンシのコンテンツ配信のための3つの異なる管理戦略のシミュレーションは、そのようなオーバーレイが数千のメンバー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と同様に、「Signal-Free LISP Multicast」[LISP-SFM]は、コアネットワークがマルチキャストサポートを提供していない場合に使用できます。しかし、シグナリングを使用してドメイン間マルチキャストツリーを構築する代わりに、シグナルフリーは、マルチキャストステートの格納と配信にマップサーバーのみを利用します。その結果、ソース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]が成功しました。現在少なくとも3つの異なる実装を実行しているノードで構成されている国際的な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サイトとパケットを交換できるようにする移行メカニズムに固有の問題もあります[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 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.
また、PxTRは通常、プロキシであるEIDプレフィックスをBGPでアドバタイズします。ただし、プロキシが異なるエンティティによって管理されている場合、それらは異なるASに属します。この場合、ルーティングに悪影響を与える可能性のあるMulti-Origin AS（MOAS）の問題が発生しないことを確認する必要があります。さらに、BGPスケーラビリティの問題に寄与しないように、EIDプレフィックスがプロキシによってデアグリゲートされる方法が妥当なままであることを確認することが重要です。
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-and-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.
復元力の問題：Locator / ID分離によって提供される柔軟性と制御の利点は、到達可能性検出の複雑さを増すことを犠牲にして得られます。実際、識別子は直接ルーティングできないため、ロケーターにマップする必要がありますが、ロケーターに到達できない場合でも、ロケーターに到達できない場合があります。これは、トンネルベースのソリューションにとって重要な問題です。現在のインターネットでは、パケットはネットワークの境界ルーターとは無関係に転送されます。つまり、境界ルーターに障害が発生した場合、別のルーターを使用できます。 LISPでは、宛先RLOCは特定の1つのETRを明示的に指定します。したがって、このETRが失敗すると、宛先サイトで他のETRが使用可能であっても、トラフィックはドロップされます。別の回復力の問題は、マッピングがオンデマンドで学習されるという事実に関連しています。 ITRが失敗すると、そのすべてのトラフィックは、リダイレクトされたトラフィックによって要求されたマッピングを持たない可能性がある他のITRにリダイレクトされます。既存の調査[SKI12] [SD12]は、測定とトラフィックトレースに基づいて、ITRとRLOCの障害はまれであるが、そのような障害が発生すると、重要な数のパケットがドロップされることを示しています。残念ながら、監視またはプローブに基づくLISPの回復力に関する現在の技術は、十分に高速ではありません（数秒程度の障害回復）。この問題に取り組むために、[LISP-PRESERVE]と[LISP-ITR-GRACEFUL]は、ローカルの障害検出と回復に基づく手法を提案しています。
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 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].
Middleboxes / filters：LISPがxTR間のトラフィックを暗号化するオプション[LISP-CRYPTO]を提供するLISPの普及モニタリング[RFC7258]への応答として暗号化がますます一般的に使用されるため、ミドルボックスはカプセル化されたトラフィックを理解できない可能性が高まり、正当なパケットをドロップさせる可能性があります。さらに、LISPでは三角形または長方形のルーティングが可能であるため、ミドルボックスがLISPを理解していても、正しい状態を維持することは困難です。最後に、カプセル化が解除されない限り、1つのホストだけがトラフィック（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に到着したときに、正しいトラブルシューティングを行うための十分な情報が含まれていない可能性があります。ベータネットワークでの展開により、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 et al。 [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 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.
LISPのセキュリティと脅威の徹底的な分析は、[RFC7835]で詳細に実行されています。 LISPおよびその他のインターネットテクノロジーの場合、ほとんどの脅威は、ベストカレントプラクティスを使用して、つまり、展開と構成（フィルターなど）を慎重に行い、展開に本当に必要な機能のみをアクティブ化し、取得したすべての情報を確認することで軽減できます。第三者から。収集機能（[RFC6830]のセクション6および[RFC7835]のセクション3.1）を使用しない限り、LISPデータプレーンは他のIP-over-IPテクノロジーと同じレベルのセキュリティを示します。セキュリティの観点からは、コントロールプレーンはLISPアーキテクチャの重要な部分です。マッピングシステムの脅威を軽減するには、すべてのコントロールプレーンメッセージに認証を使用する必要があります。現在の仕様では、オープンネットワーク環境での脅威を軽減できるセキュリティメカニズム[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]ファリナッチ、D。、フラー、V。、マイヤー、D。、およびD.ルイス、「ロケータ/ ID分離プロトコル（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] Farinacci、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]ルイスD.、マイヤーD.、ファリナッチD.、およびV.フラー「ロケータ/ ID分離プロトコル（LISP）サイトと非LISPサイト間のインターワーキング」、RFC 6832、DOI 10.17487 / RFC6832、1月2013、<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. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、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、「Locator / ID Separation Protocol（LISP）Map-Versioning」、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.、Farinacci、D.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（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、「Locator / Identifier Separation Protocol（LISP）Network Element Deployment Considerations」、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、「Locator / ID Separation Protocol（LISP）Threat Analysis」、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 Computer Communication Review、Vol。 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、「An Locating Model for Loc / ID Mappings Caches」、IEEE / ACM Transactions on Networking、Vol。 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.、Farinacci、D。、およびA. Cabellos-Aparicio、「Lcast：Software-defined Inter-Domain Multicast」、Computer Networks、Vol。 59、pp。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 Software Company、「キャリアネットワーク用の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] Iannone、L.およびO. Bonaventure、「Proceedings of ACM CoNEXT 2007、DOI 0.1145 / 1364654.1364663、December 2007」の「ロケータ/ IDマッピングをキャッシュするコストについて」。
[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>.
[IOSNXOS] Cisco Systems Inc。、「Locator / ID Separation Protocol（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、「Caching Locator / IDマッピング：実験的なスケーラビリティ分析とその影響」、Computer Networks、Vol。 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] Farinacci、D。およびB. Weis、「LISP Data-Plane Confidentiality」、Work in Progress、draft-ietf-lisp-crypto-03、2015年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 Delegated Database Tree」、Work in Progress、draft-ietf-lisp-ddt-03、2015年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-GRACEFUL] Saucez、D.、Bonaventure、O.、Iannone、L。、およびC. Filsfils、「LISP ITR Graceful Restart」、作業中、draft-saucez-lisp-itr-graceful-03、 2013年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] Farinacci、D.、Meyer、D。、およびJ. Snijders、「LISP Canonical Address Format（LCAF）」、Work in Progress、draft-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]ファリナッチ、D。、ルイス、D。、マイヤー、D。、およびC.ホワイト、「LISPモバイルノード」、作業中、draft-meyer-lisp-mn-14、2015年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] Farinacci、D.およびM. Napierala、「LISP Control-Plane Multicast Signaling」、Work in Progress、draft-farinacci-lisp-mr-signaling-06、2015年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の到達可能性の維持」、Work in Progress、draft-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. Farinacci、「LISP Replication Engineering」、Work in Progress、draft-coras-lisp- re-08、2015年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-Security（LISP-SEC）」、Work in Progress、draft-ietf-lisp-sec- 2015年10月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]モレノ、V。およびD.ファリナッチ、「Signal-Free LISP Multicast」、Work in Progress、draft-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] Farinacci、D.、Kowal、M。、およびP. Lahiri、「LISPトラフィックエンジニアリングの使用例」、進行中の作業、draft-farinacci-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：A Click implementation of Locator / ID Separation Protocol」、第1回シンポジウム、クリックモジュラールーター、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-inner-pac-insp.html>。
[LISPfritz] "Unsere FRITZ!Box-Produkte", 2014, <http://avm.de/produkte/fritzbox/>.
[LISPfritz]「Our FRITZ！Box products」、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]「The OpenLISP Project」、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、「Locator / Identifier Separationの利点の評価」、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。、編、Zhang、L。、編、およびK. Fall、編、「ルーティングとアドレッシングに関するIABワークショップからの報告」、RFC 4984、DOI 10.17487 / RFC4984、2007年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、「Pervasive Monitoring Is a Attack」、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月、Universite catholique de Louvain、<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ネットワーキングのプロシーディングス、pp。385-396、DOI 10.1007 / 978-3-642-30045-5_29、5月2012。
[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、「Proceedings in Internet Network Management Workshop、DOI 10.1109 / INETMW.2008.4660330」の「Locator / Identifier Separation Contextにおけるドメイン間トラフィックエンジニアリング」 、2008年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] IFIP Networking 2012の議事録でSaucez、D.、Kim、J.、Iannone、L.、Bonaventure、O。、およびC. Filsfils、「LISP Ingress Tunnel Routers of Fast Failure Recovery to LISP Ingress Tunnel Routers」、 pp。397-408、DOI 10.1007 / 978-3-642-30045-5_30、May 2012。
[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, LISP WG Presentation, November 2009.
[Was09] Wasserman、M。、「LISP Interoperability Testing」、IETF 76、LISP WG Presentation、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-Lab Project <http://www.lisp-lab.org>によって部分的にサポートされています。
Authors' Addresses
著者のアドレス
Damien Saucez INRIA 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France
ダミアンサウセINRIA 2004ルートデルシオレスBP 93 06902ソフィアアンティポリスセデックスフランス
Email: damien.saucez@inria.fr
Luigi Iannone Telecom ParisTech 23, Avenue d'Italie, CS 51327 75214 Paris Cedex 13 France
Luigi Iannone Telecom ParisTech 23、Avenue d'Italie、CS 51327 75214 Paris Cedex 13 France
Email: ggx@gigix.net
Albert Cabellos Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain
アルバートカベロスカタロニア工科大学C / Jordi Girona、s / n 08034バルセロナスペイン
Email: acabello@ac.upc.edu
Florin Coras Technical University of Catalonia C/Jordi Girona, s/n 08034 Barcelona Spain
フロリンコーラスカタロニア工科大学C / Jordi Girona、s / n 08034バルセロナスペイン
Email: fcoras@ac.upc.edu