[要約] 要約：RFC 7215は、LISPネットワーク要素の展開に関する考慮事項を提供するものである。 目的：このRFCの目的は、LISPプロトコルのネットワーク要素の展開に関連する問題を識別し、解決策を提供することである。
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）の展開シナリオのスナップショットです。プロトコルによって導入された新しいネットワーク要素の配置について説明し、2013年夏の時点でのLISPワーキンググループの考え方を表しています。LISP展開シナリオはそれ以降進化してきた可能性があります。このメモは、その理解の進化における1つの安定点を表しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（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/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.
Copyright（c）2014 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. 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）とルーティングLOCators（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は、このような分離がエッジとコアの間にあると想定し、転送にマッピングとカプセル化を使用します。両方の境界は厳密には定義されていませんが、広く受け入れられている定義の1つは、スタブ自律システムの境界ルーターに配置されます。このルーターは、部分的または完全なデフォルトフリーゾーン（DFZ）ルーティングテーブルを運ぶ場合があります。 LISPの初期設計では、この場所をプロトコル開発のベースラインとして使用していました。ただし、LISPのアプリケーションは、DFZルーティングテーブルのサイズを小さくするだけでなく、エッジネットワークや個々のホストに対するマルチホーミングおよび入力トラフィックエンジニアリング（TE）サポートの改善を含みます。このドキュメント全体を通して、「LISPサイト」という用語を使用して、LISPトンネルルーターの背後にあるこれらのネットワーク/ホストを指します。次の2つの用語を正式に定義します。
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）と呼ばれます。次の2つの機能のいずれかまたは両方を実行します。
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).
最初の機能はIngress Tunnel Router（ITR）によって実行され、2番目の機能はEgress Tunnel Router（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.
最初に取り上げるシナリオは、LISPサイトをアップストリームに接続しているがその制御下にあるルーターにxTR機能が配置されている場合のカスタマーエッジです。そのため、これはxTRの最も一般的な予想されるシナリオであり、このドキュメントでは、他のシナリオをこのシナリオと比較して、参照場所と見なします。
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データヘッダーでLocator-Status-Bitsを正しく設定できます。
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.
トンネルルーターを配置するときに考慮すべきもう1つのことは、MTUの問題です。カプセル化により、各パケットに関連するオーバーヘッドの量が増加します。この追加のオーバーヘッドにより、有効なエンドツーエンドパスMTUが減少します（フラグメンテーションと再構成が使用されない限り）。一部のトランジットネットワークは、エンドホストで使用される一般的なアクセステクノロジー（IEEE 802.3や802.11など）の一般的な値である1500バイトよりも大きいMTU値を提供することが知られています。ただし、このようなネットワークに接続するLISPルーターをカスタマーエッジに配置すると、次のシナリオとは対照的に、プロバイダーへのリンクタイプによってはMTUの問題が発生する可能性があります。トンネリングプロトコルのMTUの考慮事項、および潜在的な問題を軽減する方法については、[RFC4459]を参照してください。それでも、これらの緩和策を使用しても、パス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 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.
LISPルーターを展開するためのコアエッジ境界のもう1つの場所は、インターネットサービスプロバイダーエッジです。この場合の主な動機は、お客様がCEルーターをアップグレードしたり、機器の構成を変更したりする必要がないことです。カプセル化/カプセル化解除はプロバイダーのネットワークで行われ、単一のデバイスで複数の顧客にサービスを提供できる場合があります。 LISPを求める多くの住宅/ビジネス顧客を持つ大規模ISPの場合、各クライアントの場所でソフトウェア（またはハードウェアの場合）をアップグレードする必要がないため、これは重要な節約につながります。代わりに、顧客にサービスを提供するいくつかのPEルーターのソフトウェア（またはハードウェア）をアップグレードできます。このシナリオを図2に示します。
+----------+ +------------------+
| 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の主な利点の1つである入力トラフィックエンジニアリングを失います。プロバイダーが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は、すべてのトラフィックを引き付けるか、トラフィックを取得しないように競合するように構成することもできます。前者は、顧客がボリュームごとに支払う場合に発生し、後者は接続に固定価格がある場合に発生します。解決策は、プロキシ応答を行うようにMap-Serverを構成し、マッピングサービスプロバイダー（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に設定）。 Map-Versioningは別の代替案です[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 ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
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.
ITRによってカプセル化されたパケットは、NATデバイスの観点からは単なる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:
NATテーブルに状態を作成するITRによって送信されたMap-Requestは、信頼できるETRによって生成されたMap-Replyとは異なる5タプルをIPヘッダーに持っています。このパケットの送信元アドレスは要求パケットの宛先アドレスとは異なるため、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に送信します。これを実現する最も簡単な方法は、NATデバイスの外部RLOCからITRのRLOC（コンシューマブロードバンドルーターでは "DMZ"モードと呼ばれる）に1：1 NATモードを構成することです。
o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload.
o ペイロードのITR-AFIおよび「Originating ITR RLOC Address」フィールドを書き換えます。
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デバイスのインターネットに面したロケーターによって外部から到達可能です。 Map-ReplyおよびMap-Registerメッセージで使用できるように、このロケーターを知っている（そしてループバックインターフェイスを構成する）必要があります。したがって、LISP機器では、マッピングデータベースのダイナミックロケータのサポートが必要です。
Again, only one ETR behind the NAT device is supported.
この場合も、NATデバイスの背後にあるETRは1つだけサポートされます。
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' 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].
2つの異なるサイトが同じ転送されたUDPポートで衝突するため、xTRを備えたLISPサイトをキャリアベースのNATの背後に置くことはできません。探索する静的な穴あけの代替手段は、ポート制御プロトコル（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.
完全性のためにこのシナリオのみを含めて、LISPサイトが必要になった場合に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に例を示します。ソース（S）は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 |
| +-------+ +-------+ +-------+
| |
+---------------------------------------+
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を設定するには、ITRはまず、送信パケットで使用される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では、ITRはデータパケットをカプセル化するときに到達可能性ビットを設定します。したがって、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がネットワークの境界に配置されている場合よりも少ないホストにサービスを提供します。キャッシュヒット率は、ユーザーの数に応じて対数的に増加することが示されています[CACHE]。これを考慮に入れると、ITRがホストの近くに配置されている場合、マッピングキャッシュの効果は低くなる可能性があります（つまり、ミス率が高くなります）。これのもう1つの結果は、サイトがより多くのMap-Requestを送信し、分散マッピングデータベースの負荷を増大させる可能性があることです。
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.
これを書いている時点で、2つの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は再帰的に適用することもでき、DFZテーブルサイズに影響を与えることなく、サービスプロバイダーの入口/出口TE機能を提供します。
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を実現する2つのISPには、ISP_AおよびISP_Bのラベルが付いています。それらはそれぞれStub1とStub2にサービスを提供しています。どちらも、独自のxTRを持つLISPサイトである必要があります。このシナリオでは、Stub1とStub2が相互に通信していると想定しています。したがって、ISP_AとISP_Bは、そのような通信の中継を提供します。 ISP_AにはアップストリームIPアドレスとしてRLOC_A1とRLOC_A2があり、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 ... ...
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も、xTRをそれぞれRLOC_A1 / A2とRLOC_B1 / B2に展開し、独自のプライベートマッピングシステムを展開するという二国間合意に達しています。このマッピングシステムには、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を使用するこの展開シナリオには、3つの重要な注意事項があります。まず、2つのISP間でのみ展開することを目的としています。 3つ以上のISPがこのアプローチを使用する場合、参加するISPに展開されているxTRが複数のマッピングシステムにクエリを送信するか、ISPが共通の共有マッピングシステムに同意する必要があります。さらに、この展開シナリオを2つのISPのみに制限すると、2つのエンティティのみが再帰的LISPの使用に同意する必要があり、1つのプライベートマッピングシステムのみが関与するため、スケーラブルなソリューションが維持されます。
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.
第2に、このシナリオは、LISPサイトへの接続を提供するISPにのみ推奨され、再帰的にカプセル化されるパケットのソースRLOCは、そのISPに属します。それ以外の場合、参加するISPは、所有していないプレフィックスを上記のプライベートマッピングシステムに登録する必要があります。その結果、複雑な認証メカニズムが必要になるか、単純なトラフィックリダイレクト攻撃が可能になります。これらの推奨事項に従わないと、このシナリオを展開するときに運用上のセキュリティ問題が発生する可能性があります。
And third, recursive encapsulation models are typically complex to troubleshoot and debug.
3番目に、再帰的なカプセル化モデルは通常、トラブルシューティングとデバッグが複雑です。
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」シナリオは最も有利です。導入が簡単で、場合によっては顧客宅内機器（CPE）のソフトウェアアップグレードのみが必要です。 ）、マッピングサービスの取得、ルーターの構成を行います。 TEの制御とユーザーによるアップストリームの選択を保持します。マルチホームクライアントの場合、サービスへの依存度が低くなるため、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.
ネットワークオペレーターにとって、エッジルーターがLISPをサポートするためにハードウェアのアップグレードが必要な場合（CPEのアップグレードがより簡単な場合があります）を除いて、展開に適したオプションは "PE"シナリオです。 TEの制御、およびプロキシ出力トンネルルーター（PETR）とMap-Server / Map-Resolverの選択を保持します。上記のように、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を分割し、サービスプロバイダー間のトラフィックエンジニアリング用に「再帰的」にします。説明されている機能は次のとおりです。
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に変更はありません。ネットワークインフラストラクチャ：このシナリオでは、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 - - -
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.
Map-ServersとMap-ResolversはLISPマッピングシステムを構成し、[RFC6833]に準拠した、信頼できるEID-to-RLOCマッピング情報を見つける手段を提供します。これらは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].
Map-Serverは、信頼できるソースからEIDからRLOCへのマッピングエントリを学習し、それらを分散マッピングデータベースに公開します。これらのエントリは、信頼できるETRから送信された認証済みのMap-Registerメッセージを通じて学習されます。また、Map-Requestを受信すると、Map-Serverは宛先EIDが信頼できるEID-Prefixと一致することを確認し、再カプセル化して一致するETRに転送します。 Map-Server機能は[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.
Map-Serverは、マッピングサービスプロバイダー（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 DDTプロトコルはLISP MSPによって使用され、これらのプロバイダーのMap-ResolverとMap-Serverの間の到達可能性を提供します。 DDTルートは現在、組織のコレクションによってオープンベースで運営されています。詳細については、[DDT-ROOT]を参照してください。 DNSルートと同様に、ギリシャ語のアルファベットの文字の名前（アルファ、デルタなど）を使用するいくつかの異なるサーバーインスタンスがあり、独立した組織によって運営されています。このドキュメントが公開されたとき、6つのインスタンスがあり、そのうちの1つはエニーキャストされました。 [DDT-ROOT]は、Webサイト上のサーバーインスタンスのリストと、いくつかのMap-Server実装の構成ファイルを提供します。 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ルート組織は、インターネットエッジマルチホーミングおよび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はそのMap-Serverを構成して、クライアントのプレフィックスを分散マッピングデータベースに公開し、ASのETRへのMap-Requestのカプセル化と転送を開始します。これらのETRは、定期的に認証されたMap-Registerメッセージを介して、プレフィックスをMap-Serverに登録します。これに関連して、一部のLISPサイトでは、次のメカニズムが必要です。
o Automatically distribute EID-Prefix(es) shared keys between the ETRs and the EID-registrar Map-Server.
o ETRとEIDレジストラーMap-Serverの間でEIDプレフィックスの共有キーを自動的に配布します。
o Dynamically obtain the address of the Map-Server in the ETR of the AS.
o ASのETRでMap-Serverのアドレスを動的に取得します。
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 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.
Map-Serverは、提供するEIDプレフィックスの到達可能性において重要な役割を果たします。一方では、これらのプレフィックスを分散マッピングデータベースに公開し、他方では、これらのプレフィックスの信頼できるETRにMap-Requestをカプセル化して転送します。障害が発生したMap-Serverが原因であるEIDに対してカプセル化するITRは、カバーするプレフィックスを検索できません。唯一の例外は、ローカルキャッシュにマッピングが既に含まれているITRです。この場合、エントリが期限切れになるまで（通常は24時間）、ITRはETRに到達できます。このため、Map-Serverの冗長な配置が望まれます。同じセットのプレフィックスに高可用性サービスを提供するMap-Serverのセットは、冗長グループと呼ばれます。 ETRは、冗長グループ内のすべてのMap-ServerにMap-Registerメッセージを送信するように構成されています。グループのメンバー間でのフェイルオーバー（または、必要に応じて負荷分散）の構成は、配置されているマッピングシステムの背後にあるテクノロジによって異なります。 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.
さらに、Map-Serverが特定の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].
Map-Resolverは、通常はITRからLISPでカプセル化されたMap-Requestを受け入れ、分散マッピングデータベースを参照して適切なEIDからRLOCへのマッピングを見つけるネットワークインフラストラクチャコンポーネントです。 Map-Resolver機能は[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.
分散マッピングデータベースにアクセスできる人は誰でもMap-Resolverを設定して、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に近いMap-Resolverを使用することをお勧めします。 LISPをサポートするISPはこのサービスを顧客に提供し、ユーザーベースへのアクセスを制限する可能性があります。この位置にないLISPサイトは、可能な場合はオープンアクセスMap-Resolversを使用できます。ただし、オープンアクセスリゾルバーの可用性に関係なく、LISPサイトにMap-Serverを提供するMSPは、そのサイトの使用にMap-Resolverも使用できるようにする必要があります。
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.
中規模から大規模のASでは、Map-ResolverのRLOCを使用してITRを構成する必要があります。このタイプの操作は手動で行うことができます。ただし、小規模オフィス/ホームオフィス（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 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.
任意のサイズのLISPサイトでの手動設定を回避する1つの解決策は、DNSルートサーバーインフラストラクチャと同様に、マップリゾルバーにエニーキャスト[RFC4786] RLOCを使用することです。 LISPはUDPカプセル化を使用するため、エニーキャストの使用は信頼性に影響を与えません。 LISPルーターには、よく知られているMap-Resolver 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.
エニーキャストを使用すると、マッピング検索のパフォーマンスも向上します。大規模MSPは、単一のエニーキャストRLOCを使用して、Map-Resolverインフラストラクチャの数と地理的多様性を高めることができます。 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.
Map-ServerとMap-ResolverはLISPマッピングシステム内で異なる機能を実装していますが、同じデバイス上で共存できます。たとえば、両方のサービスを提供するMSPは、存在する各PoPに単一のMap-Resolver / Map-Serverをデプロイできます。
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はこの役割を果たすことができ、IPv4からIPv6への移行を支援するトンネルブローカーと同様に、早期導入者はLISPの利点を確認できます。サイトは、LISPへの移行時に新しいLISP機能（既存のグローバルLISP配置に比例して）の恩恵を受けるため、必要なトンネルルーターを配置するインセンティブがあります。非LISPサイトから到達可能にするために、2つのオプションがあります。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ルーティングテーブルのサイズを削減するという目標に到達する場合は、2番目のオプションをお勧めします。さらに、2番目のオプションでは、すべてのサイトからのLISPベースの入力トラフィックエンジニアリングが可能です。ただし、PITRの配置は、パフォーマンスと導入のインセンティブに大きく影響します。セクション5は、LISP対応のインターネットへの移行に特化しており、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とは異なり、PETRはすべてのLISPサイトが正しく機能するために必要なわけではありません。それらが非常に役立つ2つのケースがあります。
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.
最初のケースでは、uISPFフィルタリングがLISPサイトのアップストリームプロバイダーのPEルータで適用されます。 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.
2番目の使用例は、IPv4からIPv6への移行です。 IPv4のみをサポートする古いアクセスネットワークハードウェアを使用するサービスプロバイダーは、LISPを実行するCPEデバイス、およびIPv6のみの非LISPサイトとIPv6のみのロケーターを備えたLISPサイトにアクセスするための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.
PETRは、顧客に付加価値サービスを提供したいISPによって導入できます。 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の恩恵を最も受けます。 PETRロケータの自動構成は、DHCPオプションによって、またはMap-NotifyまたはMap-Replyメッセージに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対応のインターネットへの移行をサポートするための配置アーキテクチャについて説明します。大まかに定義された用語「初期移行フェーズ」、「後期移行フェーズ」、および「LISPインターネットフェーズ」は、それぞれ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サイトの比率を増加させると、プレフィックスの集約につながるBGPベースのトラフィックエンジニアリングの必要性が減少する可能性があるため、LISPサイトの数を増やすだけで重要なメリットがあります。その結果、移行後期の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入力トラフィックをルーティングすることは、特にLISPへの移行の最初の段階で、トラフィック量が少ないサイト（現在IPv6トンネルブローカーサービスを使用しているサイトなど）でのみ可能です、多数のレガシーサイトがあります。これは、上記のトラフィックの処理により、クライアントに渡される追加コストが発生する可能性が高いためです。 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.
LISPサイトまたはMSPがBGPを使用してEIDをDFZにアナウンスする代わりに、この機能をサードパーティのPITRサービスプロバイダー（PSP）に外部委託できます。これにより、サイトと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は、対応するEIDプレフィックスをBGPを介してDFZにアドバタイズする、分散されたPITRのセットを管理します。これらのPITRは、LISPサイトのRLOCに向けてそれらのEIDに対して受信するトラフィックをカプセル化し、非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ルートサーバーが導入されています。これは、他のEIDルートサーバーから学習したルートを伝播するか、EIDルートを発信するルーターとして定義されます。 。発信元のEIDルートは、信頼できるものです。 EIDルートサーバーのAS内のProxy-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)
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 Makes minor changes to PITR implementation; no changes to other components
oよりマッピングシステムに依存しない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またはローカルインターネットレジストリ（LIR）である可能性があるMSPから直接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ルートはルートサーバーによって発信され、ASパス64501 64500を使用するPSPのPITRによって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プレフィックスへの最適なパスを選択します。 ASパス長は通常、パスを選択するための重要なメトリックであるため、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.
トラフィックエンジニアリングはLISPレベルで行われるため、DFZへの影響に関して、このアーキテクチャでは、新しい割り当てのルーティングテーブルの増加が遅くなります。 LSPに移行する既存の割り当てでは、MSPがアナウンスされたプレフィックスを集約できるため、DFZが減少する可能性があります。
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.
さらに、Tier 1 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
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と共存し、移行の初期段階では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全体を通して、DFZルーティングテーブルのサイズに対するLISP配置の影響に焦点を合わせたことに注意してください。他のメトリックも影響を受ける可能性がありますが、私たちの知る限りでは、まだ測定されていません。
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]は、EIDプレフィックスを過度に要求してトラフィックを引き付けるETRオペレーターを含むLISP脅威モデルの概要を示します（[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.
この作業を開始したIETF 76プレゼンテーションへの貢献について、Margaret Wassermanに感謝します。著者はまた、Damien Saucez、Luigi Iannone、Joel Halpern、Vince Fuller、Dino Farinacci、Terry Manderson、Noel Chiappa、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] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（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.、Farinacci、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）and Non-LISP Sites between Interworking」、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. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、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.、Balakrishnan、H。、およびR. Morris、「DNSパフォーマンスとキャッシングの効果」、IEEE / ACM Transactions on Networking（TON）、Volume 10、Issue 5ページ589-603、2002年10月。
[DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014, <http://ddt-root.org/>.
[DDT-ROOT]「LISP DDTの概要：DDTルート」、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 Delegated Database Tree」、Work in Progress、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-Security（LISP-SEC）」、Work in Progress、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およびFragmentation Issues with In-the-Network Tunneling」、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、「Operation of Anycast Services」、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、「Locator / ID Separation Protocol（LISP）Map-Versioning」、RFC 6834、2013年1月。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6835] Farinacci、D。およびD. Meyer、「Locator / ID Separation Protocol Internet Groper（LIG）」、RFC 6835、2013年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.、Farinacci、D.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（LISP + ALT）」、RFC 6836、2013年1月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（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ベースのインターネットプレゼンスを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ルーターのOSバージョンを確認してください。 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を変更する前に、Do n't Fragment（DF）ビットが設定されたPxTRからRLOCへの1500バイトのパケットの送信を確認します。
* 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を増やすことができない場合は、パスMTUディスカバリを実行できるように、ICMPがフィルタリングされていないことに注意する必要があります。
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. メンバーのRLOCとその到達可能性を確認します。
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プレフィックス、ロケーター、および2つの値の間のマッピングの重みと優先順位で構成されます。さらに、xTRはMap-Resolver（s）、Map-Server（s）、およびMap-Server（s）に登録するための共有キーで構成する必要があります。必要に応じて、Proxy-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.
* 2つ以上のルーターを使用する場合は、すべてのルーターの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接続を確認するには、LISP接続サイトを見つけてpingします。 LISP接続が機能していない場合でもPITRがパケットを配信する可能性があるため、可能であれば、グローバルBGPルーティングシステムのプレフィックスでカバーされていないping宛先を見つけます。 tracerouteは、これが当てはまるかどうかを判断するのに役立ちます。
* To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser.
* LISP以外のサイトへの接続を確認するには、Webブラウザーを介してランドマーク（主要なインターネットサイトなど）にアクセスしてみてください。
1. Verify site configuration, and then verify active registration on Map-Server(s).
1. サイト構成を確認してから、Map-Serverでのアクティブな登録を確認します。
* 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.
* ガラスサーバー、RouteViewsで経路のアナウンスを確認します。
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.
* インターネット上のtraceroute / pingサーバーからのアクセスを確認します。
* Use a looking glass to check for external visibility of registration via several Map-Resolvers.
* 鏡を使用して、複数のMap-Resolverを介して登録の外部可視性をチェックします。
Authors' Addresses
著者のアドレス
Lorand Jakab Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
Lorand Jakab Cisco Systems 170 Tasman Drive San Jose、CA 95134 USA
EMail: lojakab@cisco.com
Albert Cabellos-Aparicio Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain
カタロニアアルバートカベロスアパリシオ工科大学C /ジョルディジローナ、s / nバルセロナ08034スペイン
EMail: acabello@ac.upc.edu
Florin Coras Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain
フロリンコーラスカタロニア工科大学C / Jordi Girona、s / n BARCELONA 08034スペイン
EMail: fcoras@ac.upc.edu
Jordi Domingo-Pascual Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain
Jordi Domingo-Pascual Technical University of Catalonia C / Jordi Girona、s / n BARCELONA 08034 Spain
EMail: jordi.domingo@ac.upc.edu
Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
Darrel Lewis Cisco Systems 170 Tasman Drive San Jose、CA 95134 USA
EMail: darlewis@cisco.com